For those of you who weren’t able to attend or were there but didn’t get an up-close look at our everRun VM Lockstep demo, Michael Keen (a.k.a. C1tr1xguru) shot this video of our CTO, Jerry Melnick, giving an in-depth demonstration of system-level fault tolerance for virtual environments. Thanks for stopping by Michael.

Our demonstration gave visitors an inside look at all three levels of availability:

1. XenServer HA: Level One: Failover High Availability standard with XenServer 5 Enterprise and Platinum Editions for failure detection and auto-restart and failover capabilities applications that cannot endure extended periods of downtime.

2. everRun VM: Level Two: Component-Level Fault Tolerance for business-critical applications, which require little or no downtime (such as ERP and CRM).

3. everRun VM Lockstep Option: Level Three: System-Level Fault Tolerance (available Q1 2009) for the most critical applications, which require zero downtime and zero data loss.

If you had a chance to attend the demonstration we would love to hear your feedback.

First, here’s a good post written by Anil Madhavapeddy at Citrix discussing how the overall architecture of XenServer HA works. Second, Scott Lowe has put together a great summary of why Citrix and Marathon worked together to develop XenServer HA.

If you want more details, please leave us a comment.

1. No component-level fault tolerance. The most common failures that result in unplanned downtime are component failures such as storage, NIC or controller failures. Yet VMware Fault Tolerance doesn’t do anything to protect against I/O, storage or network failures. By not addressing these primary sources of failures, VMware appears to be saying that you/the customer are on your own do figure out how to protect your storage and network connections. This may be okay for the very largest IT staffs in the world, but for the other 98%; it will not be sufficient.

2. Complexity on top of complexity. In order to use VMware Fault Tolerance, you’ll first have to install both VMware HA and DRS. No small feat in and of themselves. Then, because VMware FT requires NIC teaming, you’ll also have to manually install paired NICs. Then you’ll need to manually setup dual storage controllers (with the software to manage them) because it requires multi-pathing. And to top it all off, you’re required to use an expensive, and often complicated, SAN.

3. Limited CPU fault tolerance. With VMware FT, you’ll need to setup what VMware refers to as a “record/replay” capability on both a primary and secondary server. If something happens to the primary server, the record is stored on the SAN and then restarted on the secondary server. Two things to point out here. First, the whole thing depends on the quality of the SAN. Second, in the words of the VMware engineer who presented at VMworld, “this can take a couple of seconds.” So what happens to your application state in those couple of seconds?

4. For VMware virtual environments only. VMware FT will only work in VMware environments. It won’t work with other hypervisors, and most importantly, you can’t use for business critical and mission critical applications that you want to keep on physical server platforms (i.e., non-virtualized environments which still represent the vast majority of customer use cases). Oh well, only the vast majority of critical applications run in physical environments anyway.

It’s great to see VMware recognizing the need for fault tolerance, but we’re puzzled why they decided not to address the biggest source of failures – component failure. And we wonder how many mid-market companies will be able to justify the cost and complexity of getting VMware FT setup and keep it running.

If you had a chance to attend the session what were your thoughts?