Ezt a problémát nem akarod platform szinten megoldani, mert ugyan elméletben megoldható, hálózaton szinkronban tartani két memória tartalmát és CPU órajelet drága és lassú.
A default megoldás az aktív-passzív klaszter, amit csináltál, ekkor az egyik fizikai host elpusztításakor a VM újraindul a másik host-on. Ez percekben mérhető kiesést okoz, és olyan az alkalmazás/db számára, mintha kirúgtad volna belőle a tápot, az jó eséllyel az utolsó félbeszakadt tranzakció rollback, amit le kell tudni kezelni. Ez a világ problémáinak 99%-ára megoldás, nagyon ritka, hogy nem bír ki ennyi döccenőt az üzlet. Karbantartáskor ugye nincs kiesés, a kézi mozgatás megy röptében live motion-nel, egy redundáns szerver meg ritkán döglik meg full, azaz hacsak nem egy redundancia nélküli dzsunka pc a szervered, évi 0.5-2 eset közt várható 2-5p kiesés. Ennél több kiesést okoz majd a hálózat meg az egyéb emberi hiba, amit 2 node egymás mellett tuti nem véd ki.
Ha mégis az 1%-ba esel és nem elfogadható a fenti kiesés, akkor alkalmazás szinten kell törekedni az aktív-aktív kialakításra lehetőleg geo-redundáns módon. Ha az alkalmazás kódját nem tudod piszkálni, akkor az input-ot érdemes elkapni elosztott esemény tárban, és onnan etetni a több kvázi független példányt, de ez komoly architektúra és fejlesztési kérdéseket feszeget.
De amúgy jó indikátor, hogy nincs pénz a fent említett VMware licencre, tuti nincs akkora üzleti értéke az alkalmazásnak, hogy az aktív-passzív lokál klaszteren túlgondold.