Docker swarm + Glusterfs? Vagy más 3 node high availability + san/storage, ami 1 node esetén is megy?

Fórumok

Helló

Alapvetően olyan megoldást kerestem, ami free / open source és 3 hasonló (épp kéznél lévő laptop/régi desktop gép) szerver esetén akkor is működik, ha csak 1 node működik. Úgy, hogy a szinkronizáló storage is a gépeken van, nincs külső shared storage.

Optimálisan pár perces üzemkimaradással lenne jó megoldani, de még jobb lenne minél gyorsabban, akár 1 percnél rövidebb idő alatt. 2 vm / docker image amit futtatni kellene, az egyik egy monitoring, a másik meg Linux, nas és általános funkciókkal, kis terheléssel, de lehet 1 vmbe is bele tudom tenni. Lokálisan kell működni, hogy menjen a nas funkció mindig.

Ahogy már korábban is írtátok, a legoptimálisabb legalább 3 azonos szerver  (stonith / fencing, satöbbi) redundáns tápokkal, redundáns hálózat (2 vagy több switch), legalább 2 független szünetmentes. Arról is szó volt, hogy 1 vagy 3 gép legyen, ne 2. Így most háromról beszélünk. Sajnos, az itt felsoroltak nem adottak.

Ami rendelkezésre áll, hogy kihozzam a maximumot: 3 darab gigabites 8 portos switch, 3 darab legalább 4 magos, 8-32 gb-os Pc, raid 1 üzemmódra több hdd/ssd. Van Raspberry Pi 3B is 3 darab, sd memóriakártyával. Rendszeres mentés interneten keresztüli tárhelyre meg lesz oldva, azzal nem kell most foglalkozni. Van egy szünetmentes, azon most csak az router+wifi van.

Funkciók amik kellenek: ha a 3 gépből 1 is működik, működjön a vm vagy ami ezt megoldja. Ha visszajön a 2. és 3. node, akkor álljanak automatikusan szinkronba. Ebből az jön, hogy legyen mindegyiken shared storage is. Legyen így high availabilty, és tudja a live migrationt, ha karban kell tartani a futó gépet. Ezek az igények. Kevesebb igény esetén már találtam sok megoldást. Erre még nem.

Amiket olvastam és sejtek, az alapján:

1. Itt a Proxmox kiesett, mert úgy tudom a Ceph csak 2 node esetén írható, 1 node esetén csak olvasható. Ha 2 gép mindig menne, a Proxmox megoldás lenne Ceph használattal.

2. A Vmware elvileg tudja mindezt (ha, live migration), csak fizetős, így a hobbi projekt miatt ez nem fér bele. Nem akarok neten "talált" szériál számmal meg ilyenekkel próbálkozni.

3. Halizard: 2 géppel működik, de 3 gép esetén a mostani drbd verzió miatt nem működik, mert ha jól olvastam csak a 8.x verzió támogatott, és a drbd a 9-es verziótól tud 3 node multi mastert megfelelően. Ez még nem készült itt el. Ha ezt elkészítik megoldás lehetne.

4. Xcp-ng: elvileg ha drbd 9 lenne, akkor tudná, itt van valami béta XCP-ng - XOSTOR beta registration. Próbálta valaki? Vagy a mostani drbd verzióval vagy mással is megoldható? Xcp-ng milyen módon tudna shared storage is lenni, mindegyik node? Működne 1 node esetén is minden?

5. Xen server esetén ott a Xosanv2 ami elvileg pont az, amit akarok, de még closed béta, ki tudja mikor lesz használható, mert fizetős talán. De az ingyenes Xen nem tudja a ha-t, így kiesett.

6. Kubernetes használattal valami megosztott file rendszeren?

7. oVirt esetén nem találtam ilyen shared storage megoldást

8. Docker swarmról olvastam, hogy Glusterfs használattal kb az általam várt funkcionalitás megoldható. Van erről tapasztalata valakinek? A manager nodeon is fut minden? Vagy mik a lehetőségek?

9. Néztem különböző Freenas és egyebet, ott menne talán hogy 3 node esetén ha 1 megy, akkor is működik a storage, viszont nem tud vmet futtatni.

10. Synology Nas esetén tud Ha jellegű működést, de 120000 Ft a legolcsóbb 2 lemezes, ebből 3 darab az sok, és ez nem biztos, hogy tud live migrationt, ez csak a storage lenne.

11. Qnap is hasonló, mint a Synology, nekem vannak hardverek amiket fel akarok használni.

Akikek van ezekkel vagy mással tapasztalata, megválaszolhatná, ahogy amit szeretnék, hogy, mi módon lehet kivitelezni.

Jelenleg a 8. lehetőségben látom a reményt, mert még nem tudok róla eleget... :)

Biztosan én nem találtam meg, de meglepő lenne, ha 2022ben nem lenne egy open source, kész megoldás erre a ha + shared storage + 1 node is működjön kihívásra.

Hozzászólások

Szerkesztve: 2022. 02. 16., sze – 19:11

A Cephnél megakadt a szemem...

Ceph-et lehet single nodeként indítani. több diszk kell (vagy egy több partícióra osztva) és editálni kell a CRUSH Alg-ot.

De majd mindjárt elolvasom normálisan, mert nem ez volt a kérdés :D

Igen, jól értetted, ha konténerben tudnak futni a programok, úgy is jó. A kubernetes esetén is 1 szerver futása esetén is minden működik, és ha a másik 2 elérhető lesz, szinkronba kerülnek? Ott milyen file rendszeren vagy megoldással van megoldva a szinkronba kerülés?

A konténerek külön futnak a node-k alatt egy docker image-ből. Ha jól van beállítva a konfig, akkor minden deploy előtt pull-olja a registry-ből a docker image-t, ergó a konténerek szinkronban lesznek. (itt ha jól értem, akkor replikákat szeretnél külön node-k alatt tehát multi node szervert, mint HA)

A perzisztens adattárolásra pedig olyan volume-t kell választanod ami működik több node alatt is. A hostPath pl pont nem ilyen, az a host-ról mountol, ott pl nem működne.

 

ISCSI-vel pl működhetne, mert ahhoz kell egy iscsi szerver. Én most pl truenas alatt játszadozom vele. Ugyanez menne nfs-el is. Cephfs is ilyen, de azt még nem ismerem.

Gagyi hekkelős módszerrel még az is működhetne, hogy a host gépen valamivel felmountolsz egy központi gépről egy mappát és azt húzod be hostPath-al, de ez igazi gány megoldás lenne és nem biztonságos, mert több esélye van, hogy eltörik valami.

Mindenesetre ezeknél a hálózat a szűk keresztmetszet, ha a storage és a node között nem atombiztos, akkor lehetnek belőle incidenseid.

Longhornhoz nem kell hostpath, nem kell külőn pv-ket sem létrehozni csak pvc ben a longhornt adja meg storagclassnak, és az replikálja is neki az adatot 3 node ra, de ezt amúgy tetszés szerint állíthatja, meg hozhat létre új storageclass-t akár node meg diskselectoeokal

Szerkesztve: 2022. 02. 16., sze – 20:41

3 Proxmox+CEPH és 2 proxmox node raspberryn.

A ceph elmegy 1 működő nodedal is, bár nem nagyon javasolnám. (+ sima gigabites hálózaton sebességet se nagyon várjál)

A gond 2 gép kiesése esetén a proxmox lesz, ami automatán nem fog HA-t adni. Ehhez kell a + 2 raspberry proxmox-al.

Ez volt az elmélet, de én azért prodban nem használnám...

Ja és 3ból 2 gép kiesése esetén szerintem a split brain probléma miatt semmi nem fog menni, így a swarm sem. (ami ráadásul VM-t nem fog neked futtatni)

Freenas (truenas) úgy tom tud VM et futtatni

proxmox linstor (alul drbd), 3-as redundanciaval talan mukodhet.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

supermicro vas, lsi hw raid, sima kommersz ssd raid5-ben. 2x1 gigas linken osszekotve. most epp pve 6.4 (de regota megvan ez a felallas). nincs performancia tesztem, de erezhetoen nem lassu. de nem is kell lobogni a hajunknak, nem vilagegyenletet szamolunk :) ide kis eroforrasigenyu cuccok vannak osszeterelve. gombot valasztottuk a kabathoz.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

a legtöbb cluster megoldás azért nem fog menni ilyen módon amit fentebb is említettek: split brain szituáció.

honnan fogja tudni a rendszered hogy nem a hálózattal van gond a két node között és alakul ki két kis sziget, mondjuk 1 darab 1 node-os és 1 darab 2 node-os felosztásban?

én a helyedben valamilyen orchestrator irányba mennék, pl kubernetes (lehet nomad egyszerűbb, de ott nem tudom hogy van-e minden tool out of the box), a hostokon szinkronizálnám az adatot és mindig egy lenne amire írnék (egy verzióban engedném futni a nas konténert), de itt is ugye előjön a split brain kérdés, akárhogy is csavarjuk:) nézegettem most a drbd 9-et, de nem láttam hirtelen a doksijában a 3 node-os multi master lehetőséget és hogy hogy kezeli ezeket a szituációkat, de ha jól, akkor végülis ez így megoldás lehet.

A legtöbb clustering megoldás írói tisztában vannak azzal, hogy mi az a split brain, és próbálják megoldani :)

Az általad említett 2:1 példa tipikusan olyan, amivel nincs gond. A legtöbb 3+ nodeos cluster jellemzően valami majority vote algoritmust alkalmaz, magyarán a kettő tudni fogja, hogy ők az igazság, az egyedül maradt meg azt, hogy nem ő az.

Szerkesztve: 2022. 02. 18., p – 19:29

Nem próbáltam igy 3/1 , 3 replikával 3 x250 Gb diskkel marad ugyan 68Gb szabad hely, viszont  mennnie kell 1 node-dal is , esetleg a CRUSH mappa mődosításával, Ceph-esek majd kijavitanak, ha rosszul gondoltam:

250*0.8=200 GB (osd ) 

200*3=600 Gb hely összesen

600/3=200  hely replikáció után 

200/3=66  Gb hely gépenként 

66 *2=132 2 csomopont kiesése

200-132=68  ennyi az összes  használható hely 

 

De kipróbálhatód proxmox+Ceph alatt akár egy gépen proxmox nested virtualizációval, pár kattintás. 

Miért ilyen lényeges feltétel, hogy ha van 3 node-od, akkor egy node esetén is minden működjön?

Ha olyan cluster-ben gondolkozol, amiből direkt kikapcsolva akarsz tartani 1-2 node-ot (tehát a node-ok nem műszaki hiba van karbantartás miatt állnak ideiglenesen), akkor felejtős a cluster úgy ahogy van...

Én is gondolkoztam már ilyenen, az én egész konkrét esetem az az, hogy van 3 http node és mindegyiken szeretném localban tartani az adatot a sebesség miatt (jelenleg drbd+heartbeat+nfs van és lassú), de azt is szeretném ha épp kettő node beszarik (vagy bármilyen okból le akarnám állítani őket) akkor az az egy maradék is tudjon önállóan működni. Felteszem a kérdező is ilyesmit akar csak ő virtualizációra

Ilyet nem lehet elméletileg sem, legalábbis ha a konzisztenciát tartani akarod. Olyat lehet legfeljebb, hogy a maradék 1 átmegy read-onlyba, de az sem igazán jó, mert ugye mi van, ha másik kettő igazából még működik, csak elszakadt attól az egytől. Ilyenkor ugye a másik kettő jogosan mondhatja magát élőnek és írják a saját tartalmukat, tehát a read-only példányod már érvénytelen adatokat fog tartalmazni és visszaadni.

Érdemes megnézni, hogy mi az a CAP theorem, vagy pl. a Cassandra consistency level.

Erre a split-brain problémára (persze "rendes" cluster, tehát minimum 3, és lehetőleg páratlan számú node esetére) azért már vannak elég jól működő megoldások. Maga a Corosync is jó ideje támogat több ring-et (értsd: kapcsolatot a node-ok között), melyeket előre beállított prioritással használ a cluster épségének, a node-ok elérhetőségének ellenőrzésére.

Mi pl. úgy használjuk, hogy redundáns switch-ek mellett nem egy, hanem három ring-en kommunikálhat a Corosync (ez fut a Proxmox esetében is), így akár 1-2 ring (cluster kapcsolat) kiesése esetén is meg tudja állapítani, hogy egy-egy node része még a clusternek, vagy elveszett. Nyilván ennek megbízhatósága fokozható, ha nem egy többportos hálózati kártyán megy mindezt a node-okban, hanem több, fizikailag különböző hálózati csatoló kártyán. Aztán persze fontos a megfelelő fencing konfigurálása. A Proxmox alapból soft watchdog-gal működik, amit a Corosync reset-el a beállított timeout-on belül folyamatosan, amíg tud kommunikálni a többiekkel. Amint egyik ring-en sem tud kommunikálni, nem reset-eli a watchdog-ot, ami az OS újraindítását eredményezi (nyilván ettől a cluster nem áll helyre, ha fizikai kommunikációs gond van, de legalább mindenki tudja, hogy ki kivel van).

Ezen felül nagyon könnyen megvalósítható (akár Proxmox környezetben is) a Corosync-el, hogy a szerver BMC-je segítségével lekapcsolja az adott node-ot teljesen, ami a többi node közös szavazása alapján elérhetetlenné vált. Így megakadályozható, hogy az az egyedül maradt node önállóan működővé váljon egy ilyen újraindulás után (mondjuk egy 3 node-os cluster esetén egy node szóló elindulása esetén nem kezd semmit csinálni, mert tudja, hogy ketten hiányoznak, ami elfogadhatatan). De ugyan így könnyű megvalósítani vele pl. fizikai leválasztást, hogy a megfelelő switch portokat vagy PDU táp kimeneteket is le tudja kapcsolni a Corosync (nagyon sok eszközhöz van példa konfig és vezérlő modul).

Két gép az nem cluster. Kettő géppel annyit lehet megvalósítani, hogy szinkronban (jellemzően aszinkron módon) tartják az adatokat, konfigokat, és az egyik gép megállása esetén az utolsó szinkronizált állapottal el lehet indítani (kézzel vagy félig kintről automatizáltan) a másik (tartalék) gépet. Két geppel nem lehet valódi, megbízható HA megoldást építeni, csak csökkenteni lehet az állásidőt és az adatveszteséget az egy gépes üzemhez képest. Véleméynem szerint persze,

A Kubernetes csak orkesztrál, konkrét megoldást nem ad semmire, az előnye, hogy egységes felületen tudod kezelni az infrastruktúrát. Szerintem, ahhoz amit ide leírtál, egyszerre sok és kevés. (Sokat fogsz szívni vele és nem pont a te problémádat oldja meg.)

Ha a VM funkcionalitása csak NAS (és mondjuk nem adatbázisok futnak, hanem tényleg tiszta fájlszerverek), akkor szerintem nem érdemes magukat a  VM-eket szinkronizálni, nagyon elbonyolítja az egészet.

Syncthing-ben vagy BTSync-ben nem gondolkodtál? Így csak a valós tartalmat kell szinkronizálnod, maguk a VM/konténer image-k lehetnek statikusak. Persze így csak esetleges lesz a konzisztencia a gépek között, de cserébe faék egyszerűségű, könnyen kezelhető megoldásod lesz.

oVirt -ben van gluster támogatás (ha már RH fejleszti mind a kettőt)

de glusternél replica 3 esetén egy node nem fog menni, mint írták fentebb split-brain...