Marathon Technologies played a pivotal role in the development of the XenServer HA functionality unveiled today in XenServer 5. In addition to leading the development of the basic XenServer HA functionality that is included in XenServer, Marathon also offers enhanced levels of HA through the use of everRun VM.
In order to understand the enhanced levels of HA that everRun VM offers, it’s important to first understand what XenServer HA does and does not address. Because many readers here are probably already familiar with VMware HA, I’ll make some comparisons below.
- First, XenServer HA is a best effort solution; there is no guarantee of a restart on another host. This is because XenServer HA does not ensure that resources are allocated on other hosts, so it’s possible that a host failure might result in a situation where there is not enough resources to restart the VMs from that failed host. This would be similar to disabling availability constraints in VMware HA and allowing the HA cluster to power on more VMs than could be supported in the event of a host failure. In this regard, XenServer HA is a bit less powerful than VMware HA.
- Second, XenServer HA heartbeats will not only leverage network interfaces, but will also send heartbeats across storage adapters as well. This is a significant advantage over VMware HA, as it helps to eliminate the dependency upon the network connectivity to the Service Console/Dom0.
With that in mind, adding everRun VM to an existing XenServer HA implementation now adds some useful new functionality:
- everRun will setup a separate compute environment (another VM) on a separate host to reserve memory in the event of a failure. This enables everRun to provide guaranteed recovery in the event of a host failure.
- everRun VM provides component-level fault tolerance, meaning that if a host’s storage connectivity is lost, it can fail that connectivity over to a different host. This is accomplished through the use of private interconnects between members of the everRun VM resource pool. In my mind, this is pretty powerful stuff. Being able to fail disk I/O from the HBA in this server to the HBA in a different server over a set of interconnects is really powerful.
In the future, everRun VM will be extended again to provide “VM mirroring” functionality where two VMs are kept in lockstep with each other on two different hosts. In the event of any sort of failure—component or host—everything will fail over to the surviving host(s).
The addition of everRun VM to a XenServer 5 implementation can provide some significant features and functionality to help improve business continuity and help minimize downtime due to unplanned migrations.
Tags: Citrix, Virtualization, VMwareHA, Xen
6 comments
Comments feed for this article
Trackback link
http://blog.scottlowe.org/2008/09/15/marathon-and-xenserver-ha/trackback/
Monday, September 22, 2008 at 7:02 pm
Trackback from When will you v-Available? - Understanding XenServer HA...
Wednesday, September 17, 2008 at 2:06 pm
Anil Madhavapeddy
Hey Scott, just one minor correction here… XenServer HA does very comprehensive failure planning to guarantee that protected VMs can be restarted on an alternative host in the event of failure. This planning is also done dynamically by the resource pool (unlike, I believe, VMWare’s more static Virtual Centre-based planning).
I’ve posted some more details of how XenServer HA works on my blog at: http://community.citrix.com/x/O4KZAg
We aim to do VM restart as well as possible in XenServer, and if you need even more safety, then everRun is the next step forward — I/O fault tolerance and eventually VM mirroring as you note. It’s all great technology, I love it!
Wednesday, September 17, 2008 at 4:24 pm
slowe
Anil, the comments made to me by Marathon themselves was that the built-in XenServer HA functionality did not provide guaranteed restart and did not reserve resources elsewhere to ensure that they were available. If XenServer HA does indeed do more than that, someone should probably tell Marathon that.
Monday, September 22, 2008 at 5:11 pm
Michael Bilancieri
Scott,
Hopefully the following clarification can clear things up.
When we (Marathon) state that we reserve resources and that XenServer HA does not, we mean that we actually reserve the resources on a specific host and have a complete VM ready to go if necessary, whereas XenServer HA will calculate across the pool what resources are available for VM restarts.
As Anil states, XenServer HA certainly does do failure planning, and our comments on the differences between XenServer HA and everRun VM are not at all intended to knock HA. From our understanding, and without trying to get into a technical discussion of the exact intricacies of how XenServer HA works (Anil is better suited for that task), XenServer HA will calculate how many hosts within a Xen pool can fail and still have their VM’s restart on other hosts. As additional VM’s are started, available resources within the pool are diminished resulting in a recalculation of the restart plan, which could reduce the number of hosts that could fail and successfully restart. If users aren’t careful, they could use up too many resources and ‘protected’ VM’s may not be able to restart, depending on how many hosts suffer a failure. With everRun VM, we know that we can restart upon a host failure since we have a fully configured VM on another host. If a new VM is started it doesn’t change whether or not we are still protected as we’ve already allocated those resources on the secondary host.
Anil said it right in his last comment, XenServer HA attempts to restart as well as possible, which for many applications/environments is perfectly sufficient. For those applications/environments that warrant more protection, everRun provides the next levels of availability. XenServer HA and everRun are extremely complimentary and allow customers to choose the right level of protection for a broader set of their applications.
Thursday, September 25, 2008 at 11:57 am
slowe
Michael, Anil,
I stand by my initial statement that XenServer HA provides only “best effort” restart. Based on both of your comments, it appears that it’s possible to allocate resources in the cluster or resource pool that would otherwise be necessary to sustain a host failure. As I stated in the initial post, this is akin to disabling admission control for VMware HA, and it does introduce the possibility, as Michael stated, that protected VMs would not restart on another host due to lack of resources. This is what I call “best effort,” not “guaranteed restart.” I suppose if you ensured that you did not over-allocate the resource pool, then XenServer HA could be said to have “guaranteed restart,” but in that case VMware HA with admission control enabled could also be said to have “guaranteed restart.”
Or am I still missing something here?
Monday, September 29, 2008 at 8:55 am
Anil Madhavapeddy
Scott, you are correct, but it’s important to note that XenServer provides both modes of operation. If you disable XenServer overcommit protection (the “ha-allow-overcommit” parameter on the pool parameter list in the CLI), then you can indeed cause the lower priority VMs to fail upon restart. But if you leave overcommit protection on, as is recommended, this won’t happen. If the pool is overcommitted, then prominent warnings are also displayed.
The HA planning algorithms exist to generate a *guaranteed* failure plan which statically allocates pool resources, to move VMs in the event of a certain number of host failures. If overcommit protection is on, then these resources will definitely be present and can be depended since the tool-stack makes sure they are free. Any attempts to violate the plan will be blocked by the toolstack (just like VMWare’s admission control does).
Marathon offer an interesting alternative: rather than depending on static failure planning algorithms, they actually run two VMs and use that alternative VM in the event of failure. This makes the process have far fewer moving parts for single-host failure, but does require falling back to standard VM restart if both hosts fail simultaneously.
We’re aiming to give customers as much “flexibility vs simplicity” as possible, so that one of the deployment modes (admission control on/off, reserved VMs with Marathon) is appropriate for the threat model which is being protected against.