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!
- 732 megtekintés
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...
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
És mégis a konténer vajon hogy éli túl ha alatta KIESIK az egyik node?
nem leállítod, vagy megkéred hogy költözzön át, hanem lefagy, tönkremegy, elfüstől a táp, ilyenek....
- A hozzászóláshoz be kell jelentkezni
Félreértettél. A konténer nem megy át leállás nélkül.
A VM megy át leállás nélkül. Akkor is, ha a node-on kihal mindkét táp egyszerre.
"A megoldásra kell koncentrálni nem a problémára."
- A hozzászóláshoz be kell jelentkezni
A VM megy át leállás nélkül. Akkor is, ha a node-on kihal mindkét táp egyszerre.
Tehát, onlyan mint a VMware FT?
Ehhez tudnál valami doksit/linket is?
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
és a memóriakép sajnos ment a lecsóba.
:)
De akkor a guest OS így mégiscsak lefagy, és jó esetben újra fog indulni egy másik node-on.
Vagy csak én nem értek valamit.
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
Most a proxmoxról vagy a vmware-ről beszélünk? Bár vmware-nek meg nincs konténeres cucca.
- A hozzászóláshoz be kell jelentkezni
Proxmox.
Hiteltelen lenne, ha én VMware-ről beszélnék, mert azzal még nem foglalkoztam. :)
"A megoldásra kell koncentrálni nem a problémára."
- A hozzászóláshoz be kell jelentkezni
Mond már meg akkor kérlek, hogy mi az a feature a Proxmox-ba, ami leállás nélkül csinal failovert úgy, hogy kidöglig a node ahol futtatja a gépet?
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
És azért vannak limitációi valamint a sebességbe is lassít.
- A hozzászóláshoz be kell jelentkezni
nyilván, ez sem kompromisszum mentes, ahogy más egyéb FT, HA, DR megoldás sem.
- A hozzászóláshoz be kell jelentkezni
THX. Lehet tudni mekkora a teljesítményvesztés?
- A hozzászóláshoz be kell jelentkezni
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 ;)
- A hozzászóláshoz be kell jelentkezni
Mi van akkor ha a vCenter közben megdöglik?
VMWARE implementációjában ha nincs vCenter akkor szinte semmi se működik a HA-ból, ez igen nagy tervezési hiba.
- A hozzászóláshoz be kell jelentkezni
?
Csak átkonfigolni nem tudod, az alap HA teszi a dolgát
- A hozzászóláshoz be kell jelentkezni
Pénzdíjas
- A hozzászóláshoz be kell jelentkezni
Nem tudok róla hogy a Proxmox HA pénzdíjas lenne.
Hol van erről egy weblink?
Ingyenes és a fizetős között tudtommal nincs fukncionalításbeli különbség.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
Konténer esetén. VM-nél nem kell leállni.
"A megoldásra kell koncentrálni nem a problémára."
- A hozzászóláshoz be kell jelentkezni
Az lenne a legjobb ha nem lenne kiesés, és de igen induljon újra a másikon.
Csiti
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
És az megvan, hogy mivel jár, ha a RAM-ot folyamatosan szinkronban akarod tartani egy olyan csatornán keresztül, ami a RAM sávszélességének a töredékét tudja csak?
- A hozzászóláshoz be kell jelentkezni
persze.
de azért Te is ránéztél a projektre?
- A hozzászóláshoz be kell jelentkezni
Mit nézzek rajta? Hogy a fizikailag lehetetlent megvalósították, vagy hogy nem? Az elsőt úgysem hiszem el, a másik meg a várt eredmény, vakon is tudom.
- A hozzászóláshoz be kell jelentkezni
Én próbáltam rákeresni, de csak 10évnél régebbi dolgokat találtam. Picit furának fest, hogy két gép RAMját szinkronban tartsd, még akár egy 10G hálózaton is...
- A hozzászóláshoz be kell jelentkezni
é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...
- A hozzászóláshoz be kell jelentkezni
OK, de azért a grafikonokon még így is befigyel egy 50-70% teljesítményesés...
- A hozzászóláshoz be kell jelentkezni
Van egy ilyen is: https://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster
- A hozzászóláshoz be kell jelentkezni