Administrace komentářů

To znamená režim master-slave s ručním překlopením. Když padne primár, je na adminovi, zda ten primár opraví, nebo nahodí VM v záloze.

Režim master-slave s ručním překlopením nevyžaduje moc režií. Režim master-master je o dost složitější a náročnější.
Nevím, jak je na tom KVM (Hyper-V to neumí), ale třeba vmware to řeší tak, že dělá online replikaci běžící VM na vzdálený storage + replikuje i obsah paměti. Když primár padne, automaticky nahodí VM v záloze, což je otázkou pár sekund.
Toto vyžaduje určité licence a dobře naddimenzovanou síťovou infrastrukturu + navíc to umožňuje jen u VM, které mají myslím max 4x vCPU (možná u novější verze umí více, ale v té max licenci).

Mít storage cluster mezi dvěma lokalitama vyžaduje též dobrou infrastrukturu (a výkonný storage). Musíš zajistit, že do vzdálené lokality ti vedou aspoň dvě trasy dvěma různými směry, protože když ti někdo překopne lajnu, tak asi nechceš, aby se ti na záloze všechno automaticky nahodilo a porušila se ti konzistence replikovaných dat vůču primáru.

Z toho důvodu je nejlepší master-slave řešení. Dva servery, dva storage. Na jednom serveru+storage běží půlka věcí, na druhém druhá půlka. Mezi storage async replikace v nějakých intervalech (třeba co 5min). Když padne jedna strana, nebude fungovat půlka služeb, dokud je ručně nenahodíš na druhé straně. Pokud bude replikace řešena čistě v rámci storage, tak VM budou ve stavu, jako by jsi natvrdo vypnul proud. To v dnešní době přežije všechno.

Pokud ti záleží na minimálním rollbacku dat při překlopení v případě pádu, tak než to všechno řešit drahým řešením a na úrovni VM (což mnohdy nejde, viz limit na vCPU apod.), můžeš to řešit na aplikační úrovni. Tj. mít pro kritické aplikaci dvě VM, jednu v primární lokalitě, druhou v záložní a syncovat data na aplikační úrovni (db sync mezi databázema apod.).

Já na aplikační úrovni syncuju třeba tyto VM/služby : dns, ntp, nginx reverzní proxy servery, aplikační servery (jako např. IIS), oracle databáze atd.
Zdar Max