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?
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/
