We had a number of VMs with FT enabled, and experienced none of what David is describing.
The IO doesn't have to be replicated, as the VM sits on shared-storage. All that is replicated from one to the other is memory/CPU state. And if the "failover" host doesn't hear from the original for a certain number of heartbeats, it just, bang, completes the VMotion and continues onward. Because that's all FT really is: a VMotion that never finishes until the original VM vanishes. On Sep 8, 2012, at 1:45 AM, Michael Ryder <mryder1...@gmail.com> wrote: > I'm spawning a new thread on this topic -- > > Does anyone have first-hand experience with VMware's FT technology, > good or bad? And if so, would you be willing/able to share details or > at least whether this was vSphere 4 or 5? > > Mike > > On Sat, Sep 8, 2012 at 12:09 AM, <da...@lang.hm> wrote: >> On Fri, 7 Sep 2012, Michael Ryder wrote: >> >>> David, I don't dispute your information, but I'm curious -- are these >>> your actual experiences with VMware FT? Have you seen vLockstep fail >>> in any way? >> >> >> no, this is not experience, this is reasoning through the technology >> limitations. It takes time to get the data from one system to the other, and >> during that time they will be out of sync. >> >> If you were willing to accept the horrible slowdown of sending all the data >> to the other side and getting confirmation that it had the data safely >> before passing it to the local VM (think two phase commit on every piece of >> I/O, every network packet, every clock tick, etc) you would come very close >> to what they are claiming, but the overhead of doing that would cripple your >> system performance, even over a fast, local network. >> >> Sending the data over and replaying it as it arrives, without waiting for >> the confirmation will still add a significant amount of load to the system >> >> even so, you had better hope you don't do too much disk I/O, since it all >> needs to be sent over the network as well and local disks are faster than >> networks. >> >> >> I had a system at work a few years ago that had multiple motherboards in it, >> with their clocks hardware synced together to provide "ultimate" >> reliability, the thing cost a fortune (well over 20x what a single box with >> the same spec cost), and the list of disclaimers about corner cases that >> almost, or usually worked was impressive. That system had the boards just a >> few inches apart with very specialized hardware to tie them together. >> >> vmware is claming better results with commodity hardware over normal >> ethernet networks (not even requireing super-low latency network hardware >> like infiniband or better) >> >> >> I've read too much about the problems that OS developers have in defining >> 'now' and making operations or changes 'simultanious' even across different >> CPUs in a single system to believe that perfect replication across different >> systems is possible. Modern OSs go to great effort to try and relax any such >> 'simultanious effect' requirements even within different cores on the same >> CPU die because of the performance implications. >> >> FT is the right answer for some problems, and it's a very attractive answer >> for many problems. But it can't be perfect. I don't mind imperfect solutions >> (they are all imperfect), but I want to know where the edges are. >> >> David Lang >> >> >>> FT goes beyond the capabilities of Microsoft clustering, for example, >>> which will *completely* lose all I/O and memory-state being handled by >>> the primary node; an interruption of the application-servicing is >>> guaranteed. In VMware FT, all non-deterministic I/O is being logged >>> and shipped to the secondary. All I/O outputs are duplicated by the >>> secondary (though ignored by the secondary's hypervisor), and >>> continued functioning of the application is guaranteed. In a properly >>> configured VMware cluster, there is no data loss whatsoever. >>> >>> VMware FT is dependant on low latency -- less than 1ms is pretty-much >>> required, though maybe a few ms wouldn't concern most applications -- >>> that would affect how quickly the client computers are able to >>> reconnect to the FT-protected VM. Going cross-country with VMware FT >>> would definitely be a no-no, and I would be concerned about anyone >>> saying that such a configuration is viable. (If memory serves, >>> typical latency from NJ to CA is ~50-100ms on a 1gb segment) >>> >>> There are definitely use-cases where VMware FT is not going to work -- >>> if your app requires multiple cores, for example. >>> >>> Mike >>> >>> On Fri, Sep 7, 2012 at 9:03 PM, <da...@lang.hm> wrote: >>> >>>> executing the exact same x86 instruction sequences will give you >>>> different >>>> random numbers >>>> >>>> timing differences will result in different results when there are race >>>> conditions, etc >>>> >>>> non-deterministic events (input, I/O, etc) are copied from one machine to >>>> the other and replayed. There is a window here where the primary is in a >>>> different state then the backup, if the failure happens to hit at this >>>> time, >>>> you can be in trouble. >>>> >>>> This is still far better than trying to mirror the state of the system. >>>> >>>> I'm also not disputing that there are cases where this is your only (or >>>> even >>>> best) choice due to software not doing clustering well. >>>> >>>> I'm just claiming that it's not going to be perfect the way that the >>>> marketing material makes it sound. >>>> >>>> This may not be a problem for you. It all depends on what the impact will >>>> be >>>> if it's not perfect. >>>> >>>> For a webserver, the worst case could be that some connections get broken >>>> in >>>> the transition, not a big deal. >>>> >>>> But I had an application that was responsible for changeing passwords on >>>> production systems that was climing that this sort of thing provided >>>> perfect >>>> reliability (even between a primary and backup system running on the east >>>> and west coasts of the US). In that situation the worst case would have >>>> been >>>> having the root password changed to something that nothing and nobody >>>> knows, >>>> resulting in an unmaintainable system. In that case the cost was not >>>> acceptable (especially since competing systems did real clustering and >>>> were >>>> not dependant on this sort of vm syncing) >>>> >>>> David Lang >>> >>> >> > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
