Proxmox magas rendelkezésre állás 2node

Fórumok

Sziasztok !

Adott két darab szerver, mindkettőn ssd-re telepített proxmox fut. A szervernek egy közös iSCSI tárolója van. Clustert kialakítottam tárolót bekonfiguráltam felcsatoltam. Hálózaton a szerverek 10g-s portokon külön cluster tartományban összekötve. Hogyan tudom megoldani azt, ha a master szerver elhasal akkor a második szerveren fusson tovább a vm, és ha a master visszaáll akkor a vm is álljon vissza rá ?

Válaszokat előre is köszönöm!

Hozzászólások

tudtommal  ilyen fícsört  csak a VMware Fault Tolerance biztosít számodra.

 

A proxmox-szal max HA cluster tudsz építeni, de ahhoz is minimum 3 node kell, és a VM-ek lefagynak az egyik node halálakor, majd jó esetben újraindulnak egy másikon...

tudtommal  ilyen fícsört  csak a VMware Fault Tolerance biztosít számodra.

Ez így, ebben a formában nem igaz, nem csak a VMware.

 

a VM-ek lefagynak az egyik node halálakor, majd jó esetben újraindulnak egy mási

A konténerek. VM-ekl ugyebár pingvesztés nélkül, röptiben költöznek a másik node-ra.

Ez a szolgáltatása fizetős.

"A megoldásra kell koncentrálni nem a problémára."

Nem teljesen. A node crash esetén nem live a migrálás, de pár sec, és a memóriakép sajnos ment a lecsóba.

Ha kézzel migrálsz, akkor egy ping sem veszik el.

Nem tudom, hogy a 6.2-es Proxmoxban ez fejlődött-e...

 

Konténer esetében nyilván mindenképp (akár crash autmatában, akár manuálisan) shutdown-boot a folyamat.

"A megoldásra kell koncentrálni nem a problémára."

>  a memóriakép sajnos ment a lecsóba.

Ezt mifelenk restartnak (vagy, ahogy te fogalmazol, shutdown-boot) hivjak. Marmint, attol, hogy a diszk image-t atmigralja (hogyan? es az se par perc...), attol meg nem lesz VM migralas. Se live, se nem live, Az restart lesz.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Idézet a VMware Fault Tolerance leírásából:

"After failover, vSphere FT automatically creates a new, secondary virtual machine to deliver continuous protection for the application."

 

Nekem úgy tűnik, ez is csak simán indít egy másik gépet...

Aki meg már látta is igaziból, az tudja, hogy az FT bekapcsolásakor készít egy shadow VM-et egy másik node-on.

Futás közben pedig mind a memória tartalmat, mind pedig a CPU műveleteket szinkronizálja a kettő között.

És igen, a gyakorlatban a végeredmény egy igen magas rendelkezésre állású VM, ami akkor is zökkenőmentesen működik tovább, ha kiesik alóla a fizikai node. Ezt továbbra is kizárólag a VMware tudja.

 

 

szerintem.

Kérdés hogy egy statikus hello world oldalt szolgál-e ki a szervered, vagy pl egy durván írásra hajtott redis-t. Minden memória írás művelet szinkron (visszaigazolással) át kell hogy menjen a hálózaton. Függ a csomagmérettől, az átlagos memóriafoglalási egység mérettől és ezek arányától és még sok mástól. Izgalmas lehet egy teljesítmény hangolás ;)

Szerkesztve: 2020. 06. 24., sze – 23:47

Köszönöm a választ.

Mit gondolsz/gondoltok a corosync cluster-el nem lehet megoldani? Sajnos a VMware hasonló megoldása meglehetősen drága.

Csiti

a második szerveren fusson tovább a vm

Tovább? Akarod mondani: induljon újra a másikon (cold boot, mint egy reset után).

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. 

A szerverek nagyon jó minőségű új eszközök vélhetően ezeknek az ára vitte el a projekt büdzsét. Nincs olyan megoldás ami kihasználja a közös tárót, itt gondolva arra, hogy így nincs szükség állandó szinkronra, csak az adott virtuális gépeknek kellene elindulni hiba esetén a második nodon?

Csiti

Jó lenne ha be lehetne állítani úgy, hogy csak a vm confot vigye át de már kipróbáltam és mindenáron migrálni szeretné az egész vm-et, mivel közös a tároló a vm már ott van így hiába próbálja másolni nem tudja, így nem működik.

Csiti

"Jó lenne ha be lehetne állítani úgy, hogy csak a vm confot vigye át"

Jobb a helyzet. Közös /etc/pve-ből dolgozik minden node, mindenki látja. 

" mivel közös a tároló a vm már ott van így hiába próbálja másolni nem tudja"

Ha közös a storage is, a legjobb. A live migration gyorsabb mint local disk - local disk között. Ha fut a VM, akkor a memóriát dobja át, ez pár pillantás alatt megvan (memória méret függvénye persze). Ha áll a VM, akkor tényleg 1 db másodperc az egész.

Ha te másolni és nem mozgatni akarod, akkor clone. Ezt is viszonylag hamar elvégzi storage tudása és a diszkek sebességge függvényében.

Hát, ha az osztott tároló ellenére a Proxmox mégis másolni/mozgatni akarja a VM-et mindenestől (live) migration esetén, akkor valami nem jól van konfigurálva.

Jól működő ossztott tároló esetén csak a memória tartalmat replikálja, majd egy forrás VM pause után egy különbözeti memória replikáció (általában néhány 10 ms), és már fut is a VM (tovább) a másik node-on. Ilyenkor megy az, hogy a normál 1 mp-es ping ki sem esik kliens felől nézve.

Emlékeim szerint a Xen Kemari egy olyan patch, ahol a VM túléli, ha a futtató hostból kihúzod a delejt, gyakorlatilag tovább fut a másik hoston.
(gyanítom a RAM-ot tartja folyamatosan szinkronban)

én sem találtam frissebbet. 
itt a slide a működésről amit az adott eseményen mutatott be: http://www-archive.xenproject.org/files/xensummitboston08/tamura_xen_summit_presentation_final.pdf

már itt is Infinband-et használt, ami 2007-ben is tudott már 64G átvitelt (8x linken) most a 8x link 400G-t tud...