![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
.I'm sorry, I was giggling reading this. You guys are funny :>
HA is protection for virtual machines from hardware failure. It isn't fault tolerant which means if a failure does occur it REBOOTS or powers on the VM on a different ESX(i) host so it is basically a cold power on from a crash. VMware FT (which does have a lot of limitations) live streams the state of a virtual machine and changes to a secondary ESX(i) server, it does require twice the memory. Memory cannot dedupe via TPS across hosts. Fault tolerance means a VM will stay up when the host the primary or secondary is running on DIES, as long as one of the other stays up, the VM keeps running. However, this doesn't help you if an application crashes, or during patches. Once it crashes, it crashes on BOTH sides, and if you stop a service to patch... it stops on both sides. It protects you against a single ESX(i) host failure, that is it and it still has a lot of limitations that make it rarely used (in my experience). However FT is completely compatible with vMotion and DRS as of vSphere 4.1... things change
vMotion is the ability to migrate a virtual machine hot from one host to another. It has nothing to do with 'protecting' virtual machines like HA or FT. What it does allow, is for you to clear a single host off of all its VMs without taking down time for the VMs to do maintenance, or if you have DRS it load balances the ESX(i) hosts as the workload changes throughout the day, etc.
vMotion, HA, and FT are completely separate, and none of those protect you like an application level clustering solution, like MSCS/WFC. It all depends on what you need exactly. Setting up MSCS / WFC in a VMware environment across hosts is still a bit of a pita, so it really boils down to whether or not you can sustain a few minutes of down time.
Was it my video on YouTube?
I think most of your questions have been answered. vMotion is to move machines without downtime for maintenance or load redistribution in the cluster. VMware HA will restart a VM should it or the host it's residing on crash. VMware FT keeps an active "shadow VM" on a second host which is in lockstep with the primary. It takes resources on both hosts as you can't "share" memory across two hosts. FT also has many limitations as described in this thread.
. Every decision you make has an impact on the result. There are 3 ways to tell the VMware environment in what way to keep resources available in case of a failure. There is no 'right' way to do it every time, it always depends. I'd go over to www.yellow-bricks.com and read the HA deep dive. It will help you a lot. The rabbit hole gets deep, there is a lot more to it than I have mentioned here. It is really easy to go through and turn on HA, but it is another thing entirely to understand all the impacts / caveats.MassiveOverkill said:
I think this would be a very use case specific statement. I'd bet good money on even a bunch of SMB VMware shops running on software iSCSI and the performance is just fine for their need. I personally get better performance with the Microsoft iSCSI initiator connected to an EQL array with Dell's MPIO driver than with a properly MPIO configured software iSCSI to the same array in vSphere (Enterprise Plus license). I had a long running ticket about that with EQL and they eventually closed it with the remark that the unit works as advertised. That's just as a side note.
Who are you people and how come you are still in business considering all the things you don't do.
Nah, I am just extremely opinionated.
Stupid question but what uptime does VMware FT state it supports. I assume this predicted uptime supports the business SLA / KPI's for the application being hosted - all this technology talk is fine but I hope one doesn't forget that you're underpinning a contractual commitment.
I've seen MSCS cluster papers claiming 99.999% uptime -whether that is true or not I have no idea but I've put a fair few in and they've never failed. I do hate them though cos yeah they are a terrible pain to support
Personally, if I had the choice I'd probably go for a Stratus server rather than any of the above solutions - though I haven't seen them used on VMware to be honest.
On the post with the points, I've added some comments below. They might not be what you want to hear but you need to be "honest" rather than come up with reasons that are easy bounced.
Point 3 - true but MSCS clusters (or whatever the new name is now) is far easier due to the verification wizard (if you want a real trial in pain though try setting one up on Windows Core - a half arsed attempt if ever there was one)
Point 6 - you can have more than 2 nodes in a cluster.... (http://support.microsoft.com/kb/288778)
Point 7 - same with the ESX storage?
Point 9 - yes but as others point out on the flip side this is actually an advantage that gains you that little bit more of uptime (potentially - IF you need it)
Point 10 - dont understand this one - buy cluster components from MS HCL and you shoudl be ok?
Point 11 - incorrect, refer to support doc above for example
Point 12 - incorrect, both should be resilient to the loss of a single node. I suppose a MS cluster should be able to cope with more losses in theory (to be honest I've only ever done dual nodes)
Point 13 - this is probably true as you still need Enterprise / Datacenter OS to run a cluster and you need to license each node. On the other hand, buy an Enterprise license and you get 4 "free" Windows virtual licenses and maybe you need Ent anyway. But I tend to agree with this statement for what its worth.
Point 14 - notwithstanding the complexity of MSCS its pretty much the same process. I dont know VMware FT that well so maybe someone can confirm whether its 1:1 sync across 2 nodes or it can handle more (I always thought it was the former but probably wrong!)
Hope this helps
No worries, I'm sure I'll learn something about FT out of all of this (my first try in production wasn't that successful!)
Some comments back to your comments
Point 3 - Somewhat true, most apps failover fine in the generic cluster type - its very easy to setup. (http://msdn.microsoft.com/en-us/library/aa369166(v=VS.85).aspx). But to setup the app in the cluster, its normally a customised install that means you may well fall out of support from the vendor. This actually is a new point, the original nos 3 for me was defining the hosting platform as opposed to the supportability of apps.
Point 7 - the cluster manager failover snap-in is used - example of failing over a Hyper-V VM for comparison (http://technet.microsoft.com/en-us/library/dd759225.aspx) although note that this is not a great comparison as the two services are not equal in the vritual world. Its pretty easy to failover / failback services in a cluster.
Point 14 - may well be, adding a new node into an existing cluster should be easy - there is a wizard for it (http://technet.microsoft.com/en-us/library/cc730998.aspx) but I think VMware is easier.