On Fri, 19 Jun 2009, Derek J. Balling wrote:

> On Jun 19, 2009, at 6:34 PM, [email protected] wrote:
>> I've seen a password manager application (it goes out and changes the root 
>> password on your production systems) that when asked about failover/DR 
>> issues responded with "we run under vmware and it takes care of 
>> everything". they didn't even use a shared disk (the DR scenerio is with 
>> systems across the US from each other, no shared disk available), but they 
>> claimed that there was zero chance that the california system could ever 
>> change a password and then crash in such a way that the Georgia system 
>> would not have the new password.
>
> Then they were just blatantly lying to you. Up until two weeks ago, VMware 
> didn't even *have* "Constant Availability". Their prior HA[1] solution was 
> more of a "oh, that unit is down, let me restart another copy of the guest 
> somewhere else using the same disk", which - without shared storage - 
> wouldn't work either. It was essentially "power-fail redundancy"... the new 
> VM started up as if the power had been yanked out, but only if the "backup" 
> server had access to the disks.
>
> ie., VMware wasn't even capable of *pretending* to do anything for them.

I've seen descriptions and presentaions from numerous vm teams claiming to 
implement 'seamless failover' or 'live migration' for many years.

> Just because that particular company was clueless[2] is no reason to paint 
> the virtualization HA solutions with a broad brush. :)

they are the most detailed example, but far from the only one.

the problem is the terms have been abused for so long that it's impossible 
to tell if the person is using the term correctly or not.

David Lang

> D
>
> [1] which, we'll all agree, is *NOT* "HA", but that's what it was branded, so 
> that's what I'm calling it, and hence why they started referring to their new 
> solution as "CA"/Constant availabilty in their PPT slides when they came by 
> for the dog-n-pony-show, to differentiate it....
> [2] It's possible they were pairing VMware HA with some SAN hardware's 
> real-time replication so that the HA device would be pointing to a different 
> LUN somewhere else that was replicated at the SAN level from the master, but 
> [a] you haven't mentioned that, and [b] I'm not even sure VMware supports 
> that
>
_______________________________________________
Discuss mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to