I know what you mean about daft applications.
Yeah specifically I mean the limit of 1 vCPU. Generally speaking, an application that is important enough to genuinely require a zero RTO will need more than 1 CPU.
If you wanted to build it out on using a vMSC, then you would do:
Synchronous replication with merged FC fabric Peer Persistence with Quorum Witness and Automated failover VMware FT on top of that
that being said, here's the issue. The shadow VM will be in the other datacenter, and will have suboptimal paths to it's vmdk since the vmdk is mounted in datacenter A, but the shadow VM is in datacenter B. So depending on your intersite link, the performance of the VM could degrade (remember that VMware FT vm's are kept in lockstep).
The other issue is this: VMware FT does not help you one iota in cases of OS faults. So if your VM blue screens on one side, it's going to blue screen on the far end. If you are familiar with the two generals' problem, or byzantine failures, this can be an issue as well. The idea is that when things fail, they don't always fail nicely. Say your primary datacenter has a failure that results in it spewing corrupt data, then your issues there will translate to the backup site.
I have implemented a policy going forward that any application that is deemed "Mission Critical" in it's importance MUST be scalable and have application level HA. If it doesn't have it, we don't buy it.
|