Covirtualize! With and Beyond Virtual Machines
Having been indoctrinated in the ways of Virtual Machines by VMware, where I spent the last four years plus (from 2002 to 2006), I feel like I'm committing heresy when I say that VMs aren't the sole answer to Data Center ills.
Don't get me wrong. I like VMware, and I'm a huge believer in the power of Virtual Machines. I think that for development it's hard to beat the utility of having full multi-tier systems, virtually networked together, inside a single physical machine -- and it's super-convenient to have packaged VMs to trade to other folks for easy replication of scenarios.
But there are two challenges faced by all hypervisor vendors, that won't be solved any time soon: performance and networking (LAN and Storage). (No, VMware VI3 doesn't even touch, much less solve these issues). I joined Scalent because I love startups with bright ideas that meet a real need -- and Scalent is one of those.
The performance challenge is straightforward, and therefore not worth much discussion.
Hypervisors take up CPU cycles, are a potential point of failure (if the hypervisor fails, the whole set of VMs are lost), and due to the "round-robin" nature of their scheduling, can actually mask race conditions in tests. Honest hypervisor vendors will always admit this point quite openly -- in fact, I’m proud that during my tenure, VMware quite openly stated "don’t virtualize applications above a certain threshold CPU, network or disk I/O level".
The point? To test and run many multi-tier production applications, such as Citrix, SQL Server, SAP, etc, you want to run on bare metal. This unfortunately raises the challenge of movement between physical and virtual (P2V & V2P), as well as raising the second challenge, networking.
Networking is a more subtle challenge, because it's out-of-box. Hypervisors control in-box -- the moment data leaves the physical machine, bound out to another physical box via NIC to LAN or to storage via HBA to SAN (or NIC to NAS), it has left the hypervisor's control.
What does this mean, or matter? Well, envision your nice multi-tier application -- Webservers, App servers, databases -- built in VMs and "cabled" inside single physical machine "A".
Works great.
Now, take one of those VMs, and put it on a different physical machine "B" (running a hypervisor) that's somewhere else.
Unless that physical machine is on the same LAN subnet, with the same SAN access, you've just broken your data center. The server (VM) you just moved is reaching out to LAN and SAN paths that don't physically exist any more, because machine "B" doesn't have them.
Not to mention that little part about machine B already having to be running a hypervisor... (and if you can't get to machine B to turn it on and install that hypervisor, such as in a DR case, then what?). Don't say "oh gosh, that will all be fixed by virtual HBAs and NPIV", either -- NPIV requires a full data-center rollout, supported across all hardware (!)(got legacy switches, anyone?), and virtual HBAs make a bad problem worse... now you have even more bound HBAs. (Heaven forfend that you're allowed to change virtual HBAs like virtual MACs, that'd create an even worse problem, as without locking, people would duplicate HBAs and kill off entire SANs by accident...)
But what's the solution? Ideally you'd be able to do a few things:
* Move easily between physical and virtual
* Move what was running on your physical machines around as easily as what was running on your virtual machines. So you could remote-start machine B, above. (For bonus points, remote-start hypervisors like ESX Server or Xen, too)
* Take the network topology, LAN and SAN, with you. So no more SAN configuration adjustments, or opening all SAN LUNs to all machines (sheesh!)
Scalent lets you do those three things. That's why my colleagues in the virtualization space are impressed -- it's a technically tough thing to do, but our team seems to have gotten it right. Also, the technology has all sorts of interesting business uses (got standby DR machines? Use 'em for QA, rolling topologies on and off in minutes, then use for DR as needed!). But don't take my word for it -- try it for yourself. Give us a call, and take care of the rest of your datacenter. Covirtualize!
-- Kevin Epstein, VP Marketing, July 2006
Don't get me wrong. I like VMware, and I'm a huge believer in the power of Virtual Machines. I think that for development it's hard to beat the utility of having full multi-tier systems, virtually networked together, inside a single physical machine -- and it's super-convenient to have packaged VMs to trade to other folks for easy replication of scenarios.
But there are two challenges faced by all hypervisor vendors, that won't be solved any time soon: performance and networking (LAN and Storage). (No, VMware VI3 doesn't even touch, much less solve these issues). I joined Scalent because I love startups with bright ideas that meet a real need -- and Scalent is one of those.
The performance challenge is straightforward, and therefore not worth much discussion.
Hypervisors take up CPU cycles, are a potential point of failure (if the hypervisor fails, the whole set of VMs are lost), and due to the "round-robin" nature of their scheduling, can actually mask race conditions in tests. Honest hypervisor vendors will always admit this point quite openly -- in fact, I’m proud that during my tenure, VMware quite openly stated "don’t virtualize applications above a certain threshold CPU, network or disk I/O level".
The point? To test and run many multi-tier production applications, such as Citrix, SQL Server, SAP, etc, you want to run on bare metal. This unfortunately raises the challenge of movement between physical and virtual (P2V & V2P), as well as raising the second challenge, networking.
Networking is a more subtle challenge, because it's out-of-box. Hypervisors control in-box -- the moment data leaves the physical machine, bound out to another physical box via NIC to LAN or to storage via HBA to SAN (or NIC to NAS), it has left the hypervisor's control.
What does this mean, or matter? Well, envision your nice multi-tier application -- Webservers, App servers, databases -- built in VMs and "cabled" inside single physical machine "A".
Works great.
Now, take one of those VMs, and put it on a different physical machine "B" (running a hypervisor) that's somewhere else.
Unless that physical machine is on the same LAN subnet, with the same SAN access, you've just broken your data center. The server (VM) you just moved is reaching out to LAN and SAN paths that don't physically exist any more, because machine "B" doesn't have them.
Not to mention that little part about machine B already having to be running a hypervisor... (and if you can't get to machine B to turn it on and install that hypervisor, such as in a DR case, then what?). Don't say "oh gosh, that will all be fixed by virtual HBAs and NPIV", either -- NPIV requires a full data-center rollout, supported across all hardware (!)(got legacy switches, anyone?), and virtual HBAs make a bad problem worse... now you have even more bound HBAs. (Heaven forfend that you're allowed to change virtual HBAs like virtual MACs, that'd create an even worse problem, as without locking, people would duplicate HBAs and kill off entire SANs by accident...)
But what's the solution? Ideally you'd be able to do a few things:
* Move easily between physical and virtual
* Move what was running on your physical machines around as easily as what was running on your virtual machines. So you could remote-start machine B, above. (For bonus points, remote-start hypervisors like ESX Server or Xen, too)
* Take the network topology, LAN and SAN, with you. So no more SAN configuration adjustments, or opening all SAN LUNs to all machines (sheesh!)
Scalent lets you do those three things. That's why my colleagues in the virtualization space are impressed -- it's a technically tough thing to do, but our team seems to have gotten it right. Also, the technology has all sorts of interesting business uses (got standby DR machines? Use 'em for QA, rolling topologies on and off in minutes, then use for DR as needed!). But don't take my word for it -- try it for yourself. Give us a call, and take care of the rest of your datacenter. Covirtualize!
-- Kevin Epstein, VP Marketing, July 2006
posted by Scalent Systems at 4:43 PM
0 Comments:
Post a Comment
<< Home