A virtual vision

As president and CEO of Linuxcare, Avery Lyford is betting heavily on enterprise adoption of the Linux OS. The company’s Levanta software is used to provision, configure, and manage virtual Linux servers on IBM zSeries mainframes. InfoWorld Test Center Senior Analyst Wayne Rash and Senior Editor Doug Dineley sat down with Lyford in his San Francisco office to discuss the benefits and challenges of server consolidation and virtualization.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft

What does virtualization mean from an IT perspective?

Today the unit of work is the box, and you manage the box. But the reality is no one has great joy in managing boxes. They usually prefer to manage workloads or applications. So the way to think about it is: The unit of work is no longer the box; the unit of work is the object, the workload. And what you do is you move that workload into a virtual environment so you can allocate it however you want.

Now the beauty of this is that from the application developer’s standpoint you’ve preserved the architecture they’ve developed. If they have a separate LDAP server or a separate DNS server, you’ve preserved all of that. And if one guy is the system administrator for all LDAP servers across all apps, you don’t mess with any of that. You don’t change people’s jobs.

What are the cost implications? Does virtualization actually reduce costs, or does it just move them to different places?

The value of virtualization is that it allows your application team to continue working the way they have been, and yet the infrastructure can be managed in a very different way. It decouples what you have to manage from the way you develop your application, which is a pretty big decoupling of logical vs. physical. So it could have huge value if you manage that physical infrastructure in a different way by taking advantage of that virtualization.

What are the challenges of managing a virtualized environment?

I’ll give you an example. Typically, the networking guy is different than the guy who’s [managing] the compute platform. And in some cases, people have done disaster recovery by taking the same IP address and doing a “stay alive.” If they stop seeing response from one IP address, they’ll fail-over to the other IP address. Well, if you virtualize both of those servers and all that traffic is now pulled inside the system on a virtualized LAN, well, now the networking group no longer has visibility for a stay-alive packet. It’s all internal to the machine.

One of our big surprises was, gee, virtualization is not just about getting the distributed team to talk to the datacenter team because now there’s also networking involved. You’re messing with wide-area network architectures. You talk about moving someone’s IP addresses, and all of a sudden the network group says, “Whoa, wait a sec. We counted on visibility for those addresses, and now you’re virtualizing the system. We want to understand exactly what’s going on here, what are the security implications, and can there be beaconing if you’re doing a virtual network."

Do the benefits of server consolidation and virtualization necessarily involve the mainframe?

No, it could involve anything. It just so happens that the mainframe has a good virtualizing environment. But there’s no panacea architecture.

One of the really interesting things [is that] because a lot of the databases never moved off the mainframe — they’re running DB2, they’re running Oracle — … people want to Web-enable all of that data. So what happened for a couple of years there, people just threw a whole bunch of systems at it. "We’ll take this data, and we’ll cache it off of this system; and then we’ll manipulate it and do a join between two databases on that system; and then we’ll do a Web server off that through the firewall." So now I just described five different physical boxes. And now people start looking at that and at the issues of doing disaster recovery.

What are the security implications for everything on the same box? Can you virtualize the firewall while you’re at it?

You can actually do a virtual firewall. From the standpoint of the individual instances being able to march onto another instance and having an impact, that’s extremely well partitioned. That is the natural question whenever you talk about virtualization; if things are virtual, how do you make sure that there’s a hard — in a sense — a hard partition. And the nice thing that I find about z/VM [IBM’s zSeries/Virtual Machine] is that it’s a very well architected system. It's been around for a long time, and as a result, like any well-used code, people have just kind of run the thing dry.

Right.I'm not sure I believe that, but OK.

[Alternatively] you could run that wire into your system, you get a virtual LAN inside, you make one of those instances into a firewall, and then that, in turn, is the firewall for all the other instances. But now I know exactly why the networking group wants to have an opinion.

Why exactly does virtualization make disaster recovery easier?

The whole idea of disaster recovery is that you can re-create your current structure in a different location. That's the essence of disaster recovery. So the looser the logical-to-physical mapping, the easier disaster recovery will be, because disaster recovery is about changing all of the physical. An example of that — and I'm going to go completely outside the computing realm and into the networking realm — … if for some reason one of your applications has got a latency demand for communications of, let’s say, half a second and now your [disaster-recovery] site has a 2-second latency to initiate that transaction, it doesn’t matter whether your whole physical compute structure is the same. You have a dependency on a physical network attribute that will cripple you.