On Fri, 19 Jun 2009, Derek J. Balling wrote: > On Jun 19, 2009, at 5:55 PM, [email protected] wrote: >> I claim that it's not possible for a two servers to have the same state. or >> at least not with acceptable performance. > > You can claim that, but I think there's evidence to the contrary. VMotion > works by getting the target-host up to speed, and matching its state in lock > step, including changes since that portion of the "state" was migrated, etc., > etc. We used to VMotion our web servers from host to host all the time, and > we measure our responsiveness, per-request, down to the millisecond. We never > noticed any performance issue before/during/after a vmotion event.
when you pull the plug on a busy server, how much data is in ram that hasn't yet been replicated? remember that one significant performance bottleneck on current systems is the rate at which the various portions of memory (cache) _in_the_same_chip_ can propogate updates, and significant performance improvements happen by people refactoring things so that it's not nessasary to access the same memory from two different cores at the same time. with vmware failover you not only need to go down through several layers of cache out to the ram, you then need to go out the PCI buss to the network card, over the network to the other machine. it's not _possible_ to replicate all memory writes in real time to another machine with commodity hardware (or with anything close to the same performance even on custom hardware) >> even if you limit your definition of 'state' to the contents of the logical >> disks, you can't have real-time replication of disk contents between >> machines at anything close to the same speed that you can make changes to >> the local disk. > > In the usual configuration, the disks are "the same"... ie., both the "live" > and "slave" simply look at the same SAN/NAS mount. So there's no issue there. except that until the application does fsync() the data may not be on the disk yet. the changes are still in ram. >> these bandwidth limits mean that even 'live migration' doesn't mean zero >> outage, at some point you need to pause the VM on one machine to copy the >> last of the changes to the new machine and start it up. vmware takes >> advantage of the fact that most memory/disk id not normally changed, so it >> copies everything, and then goes back and copies everything that has >> changed, until it decides that it's not making sufficiant progress, at >> which time it must pause the app to move it. This normally makes the outage >> small enough that most people don't notice it, but it's not a case of 'not >> a moment of outage' as another poster in this thread commented. > > One could, I presume, make the claim that ESX migration would not be > sufficient for RTOS purposes, but for the majority of folks out there, > including high-I/O, high-memory usages, the impact of the migration-pause is > completely unnoticeable. for the vast majority of systems, a couple of seconds of outage as systems failvoer in sompletely unnoticable.;-) >> and at some point simple bandwidth and latency (speed of light) limits mean >> that you can't eliminate all downtime. > > And I think for MOST organizations, the level of "risk" you're describing is > not one which we encounter. :-) I don't disagree with this. what I object to is the tendancy for applications to not pay any attention to failover/DR requirements on the theory that it will be run under vmware, and vmware will solve all the problems by making sure that _nothing_ is lost if a machine fails. 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. I fully believe that an application could be written to do this, but it would need to specificly take action to make sure that the DR system knew the new password before it changed it on the system, but just changing it and depending on vmware to replicate the changes in memory before the system crashes isn't the same guarantee. David Lang _______________________________________________ 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/
