Proxmox cluster szakadás

Fórumok

Sziasztok!

Egy kis segítségre volna szükségem, hogy megértsem a működést. Tegyük fel, hogy van két épületem, mindkettőben 4-4 Proxmox node, 1-1 storage. Az összes (8) node clusterben van, hogy működjön a replikáció (ugye csak clusteren belül működik?).

Mi történik, ha megszakad az összeköttetés a két épület között? Működik majd a 4-4 node egymástól függetlenül is? Változik a helyzet, ha változik a node-ok száma?

Mi történik, ha ezután helyreáll a kapcsolat?

 

Köszönöm a válaszokat!

Hozzászólások

Szerintem erdemes lenne egy 3. valamit bevonni (akar egy kutyakozonseges vps-t valahol) hogy legyen quorumod, mert igy ha szetszakad a 2 , honnan tudnak csak csakadas, vagy minden beszart a tuloldalon?!

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Nem akarok HA-t, csak a replikáció, és a könnyebb managelhetőség miatt lenne a cluster. Így is annyira gáz? Mindkét oldalon futnak különböző VM-ek, de nem HA-znak. Mi történik szakadás esetén? Megállnak a VM-ek? Vagy a saját épületükből működőnek fognak látszani?

Ilyenkor a szálszakadás javításának idejére leállítva a két oldali maradék-clustert, és javítás után újrabootolva elindul normálisan újra? (Értem ekkor még mindig bennemarad, hogy a hüjeinformatikus kihúzza  a kábelt egy időre, aztán visszadugja cluster leállítás nélkül...)

"Mi történik szakadás esetén? Megállnak a VM-ek"

3 node-os klaszterrel játszottam. Szándákosan kitűzfalaztam az egyik node-ot. Minden megy tovább, de nem engedi menedzselni, mert a közös /etc/pve közös mappa nem tud szinkronizálódni.

Meg lehet neki mondani, hogy ha nem döntés képes, hogy "pvecm expected 2" és akkor nem vár harmadikat, ha kettőt lát már boldog és menedzselhető. A menedzselés alatt történő módosítás miatt viszont kézzel kell összeszinkronizálnod később azt a mappát. Ilyen tesztet már nem végeztem.

Ha viszont nem akarod eközben leállítani, meg memóriát módosítani, gond nélkül fut minden. Csak webről látod leszakadva a node-ot, meg kérdőjelesnek a VM-eket. Megkockáztatom, CLI-ből sem engedné piszkálni.

Én használom 2 telephelyen, ahol az egyik telephelyen csak 1db node-van. Néha beszakad, de a VM életében soha nem okozott problémát.
Nem hiszem, hogy itt számít,, de én lokál diszkkel/ssd-vel használom.

Vigyázz vele, mert 1 node-al megoldja, de többel nem biztos. Az egy node felismeri, hogy a többin nagyobb a változás és alkalmazkodik (nem ismerem a cocorsync-et behatóan, nem tudom, hogy hívja pontosan), vagy kézzel sync-eled, de ha pl 3-2 állapotban jön vissza a hálózat, bedőlhet az egész. A VM-ek futni fognak, de a többi node-ra azt mondja, hogy inaktív. Ez után nem lehet csak úgy kiléptetni a clusterből és újra beléptetni a "másikba" Én szívtam már ilyennel.

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Hát a legnagyobb szívásom igen érdekes volt, nyolc node-os cluster-el. vihar alatt egy villám kiütötte a szünetmentest. A nyomorult szerkezetnek annyi ereje ereje volt még mielőtt beadta a kulcsot, hogy átment bypass-ra. Na ezt szívtuk meg, mert ezután fél óra alatt nyolcszor(!) ment el az áram és jött vissza. A szerverek power on-ra voltak állítva persze és szépen indultak. Indulás közben áram el, utána áram vissza és indulás újra. Többféle vas különböző boot idővel, és switch is ezt játszotta. A vége a teljes káosz lett. Mire "megjavult" az áram, az összes node(!) azt állította, hogy mindenki más offline. Próbáltuk megnézni a naplókból a szétesés sorrendjét, de annyira káosz volt, hogy nem jöttünk rá, meg aztán időnk sem volt küzdeni vele.

Ami pozitív volt, hogy a qemu-t marhára nem érdekelte az egész, és egy virtuál gép sem döglött meg, mind node ment szépen tovább egyedül. Mondjuk sok köze nincs is a quemu-nak a cluster-hez. Sebaj gondoltuk, majd kézzel visszacsináljuk a clustert. Sajnos ennél az ügyfélnél nem volt megvéve a support, így nem tudtuk bevonni őket, pedig igazán jó lett volna. Na itt egy napos szívás után B terv lett. Meglepő, de a bajunk a cluster szervizzel volt :) Volt olyan gép ahol egyszerűen nem állt le, akár mit csináltunk. Disable, restart, akkor meg nem indult el. Másolhattunk akármit akárhová, rakás hiba a logba és nem indul. Én játszottam volna tovább, de az ügyfél morcos lett. Végül, mivel éppen a 4-ről 5-re váltást terveztük, és a pont a cluster hálózat átalakítását is, reinstall lett a vége. Egy gépről áttettük a VM-eket egy másikra, reinstall, aztán vissza, következő gép reinstall, be az új cluster-be és VM-ek rá. Így lépegetve egy nap alatt megvoltunk. Szerencsére a proxmox telepítési ideje van vagy 5 perc :)

Na azóta ahol nem muszáj, kerülöm az "ac loss auto restart" beállítás a szervereken...

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Szerkesztve: 2020. 06. 17., sze - 08:14

Én ezt nem csinálnám, mert ilyen esetben szétesik a cluster és azt rendbe rakni nem éppen egyszerű. Annyira kritikus a cluster-nek a hálózat, hogy a proxmox nem is egy hálózatot ajánl, hanem legalább kettőt, külön fizikai eszközökkel, hogy legyen redundancia. A 6-os verziótól ezt már össze tudod kattintgatni a GUI-n. Nekem volt szerencsétlenségem egy 8 node-os szétesett cluterhez, nem tartozik a legjobb emlékeim közé...

Ha nincs megbízható hálózat a két épület között, inkább két külön clusterben és valamilyen keresztbe mentésen gondolkozz.

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Köszönöm a tanácsot! Annyira kezdek elveszni már a shared storage, replikáció, két épület, zfs... varázslatokban, hogy kell ilyen külső szemlélős jótanács! Köszi mégegyszer!:)

Ha két külön clustert csinálok, akkor a replikáció (ami csak zfs-el működik) nem fog menni. Viszont scriptből zfs send/receive-vel elvileg meg lehet csinálni manuálisan? Mennyire lesz ez így konzisztens? Ismer valaki már esetleg kész scriptet erre?

A cél egy disaster recovery site létrehozása.

Az épületek közötti clustert mostmár elvetettem, a pve-zsync szépen tud "replikálni" clusteren kívüli gépre is, azzal fogom megoldani.

Igen, úgy tűnik, minden node zfs lesz, pont a replikáció miatt. Bár borsódzik tőle a hátam, mert belefutottam már olyanba, hogy a zfs-en lévő VM iszonyat módon belassult egy év használat után, és éppen nem volt több szabad tárterületem... Most abban reménykedem, hogy lesz elég tárhelyem:) Különben legszívesebben LVM-el csinálnám meg, csak azzal meg a replikáció macerás. A mentésből visszaállok meg azért nem ideális, mert alig fér bele 1 napba a mentése a VM-eknek. Ez az opció megmarad vésztartaléknak, de mellette most megpróbálkozom a replikálással is. Egyenlőre van tesztkörnyezetem, abban játszom.

Ez a téma engem is foglalkoztat, de pont a zfs lassulástól tartok.

Egyébként az egyik backup szerveren, ami alatt zfs van, a használhatatlan szintre lassult, amikor fogyott/betelt a diszk. Ahogy nagy nehezen sikerült törölnöm, úgy gyorsult. Meg azért a zfs szereti felnyalni a RAM-ot :)

Nalunk jo ideje fut mar ZFS, nem tapasztaltunk belassulast. Lehet, hogy a ZoL korabbi verzioi ki voltak teve ennek,de a 6-osban nem tapasztaltunk ilyet, pedig eleg sok VM fut nalunk ZFS/Proxomox alol.

Blog | @hron84

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

via @snq-

Mi erre írtunk saját scripet.
Az egész PVE API + ZFS send/receive-re épül.

Kb. hasonló mint amit te keresel

  • backup gép beléptetve a cluster-be
  • létezik online és offline backup
  • minden backup PVE snapshottal kezdődik
  • a snapshot pedig szépen ZFS send-el megy backup gépre, értelemszerűen block copy miatt csak a változások.
  • meg tudod határozni hogy cluster oldalon, és backup oldalon mennyi snapshotot tartasz meg.

pve_zsync-el a problémák:

  • VM állapotot nem tudsz neki beállítani, tehát pl. nem tudod neki megmondani hogy adott gépet állítsa le snapshot előtt, majd indítsa újra.
  • a forrás és a cél oldalon is egyezik a snapshotok száma, ami azért gáz, mert ha pl. szeretnék 60 napi backup-ot, akkor ennek a forrás oldalon is meg kell lennie, és helyet foglal.

Volt még pár dolog amikor próbáltuk, de a fentiek voltak a legnagyobb gondok.

Szerkesztve: 2020. 06. 17., sze - 22:48

Reszben ez a "mukodik" definiciojatol is fugg. Elso korben az a kerdes, hogy a halozat hogy van kialakitva, erdemes a management/storage/cluster szamara dedikalt halozatot csinalni, es a net fele egy masikat. 

A Proxmox alapvetoen ket reszbol all: 

- QEMU server
- Proxmox cluster

Ebbol a QEMU szerver igazabol nem clusterezheto, es ez vegzi a virtualizaciot, kovetkezeskeppen a Proxmox cluster akarmennyire is el van pusztulva, ami addig mukodott VM, hacsak nem stoppolja le valaki, mukodni fog tovabb. A kernel panik mar egy necces kerdes...

A Proxmox cluster az vegulis a kulonfele konfigok szinkronban tartasaert, az esetleges HA dolgok megvalositasaert felelos (meg meg sok minden masert). Csinaltunk mar olyat, hogy egy teljesen megborult Proxmox Clustert ujrahuztunk nullarol ugy, hogy a VM-ek meg csak nem is pislogtak kozben. 

Ami nagyon fontos, hogy a /etc/pve alatti dolgokat rendszeresen mentsetek, ez a cluster lelke, itt van minden erdemi konfig a node-ok szamara. Ha valamiert teljesen szetesik a cluster, fejbol meg nem mondom mi a parancs, de el lehet inditani a node-t cluster nelkul is (egy szingli node-os cluster lesz belole), es ki lehet menteni a VM konfig valtozasokat. 

A kerdesbeli setuppal kapcsolatban: en mindenkeppen kulon clustert csinalnek a DR site-on, ket cluster kisebb esellyel hullik atomjaira, mint egy. A ZFS jol replikalhato, de ha sebesseget is szeretnel, akkor olyan megoldast keress, ami nem SSH-n keresztul masolgat, hanem netcat-tel vagy hasonlo, nyers TCP/IP alapu megoldassal. Ennek ugye az a rizikoja, hogy ha nem termen belul van a DR site, akkor erzekeny adatok utazhatnak titkositas nelkul. A gyors es biztonsagos replikacio kozul csak az egyik valaszthato... Nagy kerdes, hogy a DR-nek mennyire kell percrekesznek lennie, ha belefer akar 24 ora diletacio is, akkor inkabb biztonsagosan replikalj, mint gyorsan.

Amit meg erdemes lehet megnezni, az a Cockpit. Siman felrakhato Proxmox 6-ra, es a megfelelo plugin telepitesevel egy nagyon powerful menedzsment eszkozt kapsz a ZFS kezelesehez (es eleg jo dolgokat tud amugy is). A ZFS menedzsmentjehez legalabb 122-es Cockpit fog kelleni, de nem reg landolt a buster-backports repoban pont ez a verzio. 

Blog | @hron84

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

via @snq-