I noticed the term “Stratus vCenter Uptime Appliance” a couple of weeks ago but couldn’t find any details on it. It appears that Stratus has now officially announced their vCenter Uptime Appliance. The appliance is built on the company’s fault-tolerant, Intel® processor-based ftServer architecture. In short, these systems are kept in lockstep and if one fails the other one will take over.
Not totally unexpected Stratus compares its solution to vCenter Heartbeat, which they say is more expensive and more complicated to implement. The Stratus solution is roughly $ 6.5k (source), but keep in mind that this is for a 4u physical system and you will need to add the cost of power/cooling/rackspace on top of that, where of course you could run vCenter Heartbeat perfectly virtual. It is not difficult to compare the price, but I’d rather see a cost comparison. Anyway, lets look at the architecture used. The following diagram, created by Stratus, compares the two solutions. I guess it is obvious straight away what the main difference is:
The difference is that Heartbeat is two instances being kept in sync where Stratus is a single instance. Although Stratus takes the “simplicity” approach to compare both architectures, in my opinion this also shows the strength of vCenter Heartbeat. That second instance could be running in a different datacenter / location. I guess each of these have its advantages / disadvantages.
Both of the solutions are definitely worth looking in to when deploying critical environments, but before you make a decision list the benefits/ costs / complexity / resiliency and weight them against each other. Nevertheless it is great to see solutions like these being developed.
Or you can just use MS SQL replication to another physical host, and the follow VMware KB 5850444 in case of a disaster.
My company has been running vCenter Heartbeat to protect 2 servers (vCenter and SQL) across subnets/datacenters (WAN configuration), but it hasn’t worked out too well. Hiccups on the WAN cause failovers to occur on vCenter, but not SQL, or the other way around. Then we wind up with a vCenter talking to a database across the WAN, syncing issues, etc. Not good. It made a somewhat simple and reliable application unreliable and very complicated. This was already in place when I arrived at the company, and my recommendation at the moment is to remove vCSHB and go with separate vCenters at each datacenter. Unfortunately, it doesn’t look like the Stratus solution will work across a WAN, it’s more of a redundant hardware solution (from the limited info I can find…)
Duncan, I’m reading your new DRS/HA book now, it’s excellent!
I suppose it depends on how serious you are about high availability.
If you are serious about high availability for vCenter, you probably have two ftServers at different locations with vCenter heartbeat.
Since the Stratus servers run off-the shelf OS…
Who is to say you don’t have a vCenter Uptime appliance, and a backup vCenter server somewhere else, on a different vendor’s ft server hardware based on a different CPU family with vCenter heartbeat to deal with failure of the Stratus appliance?
Duncan you hit the mark that users need to look at the cost / benefits / risks etc of each type of solution, particularly as vCenter availability becomes increasingly critical. {Disclaimer} I work for Stratus and developed this solution.
This is just one of many ways users deploy fault tolerant servers to solve the most challenging VMware issues. Several customers had seen the benefits of running vCenter on an ftServer motivated us to package us as a hardware appliance. Consistently we heard for SEs at users, partners, and yes even at VMW, that the current solutions for vCenter were just too complicated or unreliable.
Stop by and see us at PEX booth 300
BTW – ask about our $50,000 VMware Uptime Guarantee