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...
zrubi.hu
Ez így, ebben a formában nem igaz, nem csak a VMware.
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."
É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....
zrubi.hu
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."
Tehát, onlyan mint a VMware FT?
Ehhez tudnál valami doksit/linket is?
zrubi.hu
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."
:)
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.
zrubi.hu
> 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
via @snq-
Most a proxmoxról vagy a vmware-ről beszélünk? Bár vmware-nek meg nincs konténeres cucca.
Domain, tárhely és webes megoldások: aWh
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."
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?
Domain, tárhely és webes megoldások: aWh
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.
zrubi.hu
És azért vannak limitációi valamint a sebességbe is lassít.
Domain, tárhely és webes megoldások: aWh
nyilván, ez sem kompromisszum mentes, ahogy más egyéb FT, HA, DR megoldás sem.
zrubi.hu
THX. Lehet tudni mekkora a teljesítményvesztés?
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 ;)
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.
?
Csak átkonfigolni nem tudod, az alap HA teszi a dolgát
Pénzdíjas
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.
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).
Konténer esetén. VM-nél nem kell leállni.
"A megoldásra kell koncentrálni nem a problémára."
Az lenne a legjobb ha nem lenne kiesés, és de igen induljon újra a másikon.
Csiti
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
Igen, így:
https://pve.proxmox.com/wiki/High_Availability_Cluster
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)
É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?
persze.
de azért Te is ránéztél a projektre?
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.
É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...
é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...
OK, de azért a grafikonokon még így is befigyel egy 50-70% teljesítményesés...
Van egy ilyen is: https://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster