2 gépes megoldás kerestetik: hyper-converged storage + live migration, max 5 perc leállással

Szerverek

Sziasztok, nem vagyok szaki, hobbi projektem ez. Van 2 darab elfekvő gépem, 8gb memória és 4 mag, több 300,500,1000gb Hddvel per gép, több háló kártya, alapból 1 gigabit per gép. Proxmoxszal szívtam, Ceph meg minden, de 2 géppel nem az igazi. Próbáltam úgy, hogy a 3. gép az egyik gépen egy  Vm, hogy legyen 3 a Cephnek, de macera volt elindítani és nem is volt jó. Aztán raktam egyikre 2 Vmet másikra 1 Vmet, mindegyikhez külön hdd-t dedikáltan a Cephnek, de ez sem volt az igazi, bár működött, csak nagyon nem szép. A 3. fizikai gép csak ideiglenes mentésre alkalmas, néha fog menni. Ebből akarnám kihozni, hogy legyen shared storage, ami szinkronba tud állni a 3. gépen is akár, mint mentés,valamint az 1. és 2. gépen futó Vmnél lehessen live migrationt. Xcp-ng tudná a live migrationt,csak kellene harmadik gép mint shared storage hozzá, de az nem fér bele. Meg lehet Xcp-ngvel oldani, hogy egyben  is legyen az Xcp-ng 2 szervere? Proxmox és Drbd elméletben jó lehet, de nem csináltam ilyet és sok problémás esetről olvastam. Ha ez lenne, hogy kellene feltelepíteni, használni, hogy menjen Proxmox alatt a live migration Drbdvel? Vagy kérlek mondjatok bármi mást, ami házi fájl szerverre és egyéb folyamatosan futó programok futtatására egy vmben alkalmas, ami tudja a live migrationt 2 gép esetén, de 3 gép esetén is. Ha 1-2, max 5 percre megáll, az még beleférne. Csak minimum 2 géppel menjen, így is sokat fognak fogyasztani, ha mindig mennek.

 

Frissítés 1:

Adott a 2 szerver ami régi desktop gép valójában, benne 2 gigabites hálókártyával, egyik alaplapi. Felraktam a legújabb xcp-ng 8.1.0-2 verziót a 2 gépre, linux raid 1, csak 2 hdd a gépekbe, azon minden. Létrehoztam egy közös xcp-ng poolt a 2 gépen, az még kellett a telepítés előtt. Halizardról letöltöttem az install scriptet ami 10 kbyte, az lehúzott minden csomagot. Megadtam az ip címeket, mi legyen a közös sannak az ip címe, és kész. Figyelmeztetett, hogy töröl mindent a poolból, de hát üres volt. A Drbd szinkronba állt, a második háló kártyán kommunikálva, létrehoztam egy linux vmet erre a közös tárolóra, futtattam rajta programokat és néztem, live migráltam egyiket a másikra, oda vissza, tök gyorsan ment. Azt is néztem, hogy a kettes gépre live migráltam a vmet, az elsőt kikapcsoltam. Majd ahogy visszajött, akkor szinkronba állt automatikusan, és újra live migrálás az első gépre. Tehát így megoldottam az automatikus mentést is. Ha akarom, így csak 1 gép megy, ha otthon vagyok, ha meg nem vagyok, bekapcsolom a másikat, és ha az első megáll, ott a másik.
Még azt fogom megnézni, ha az első gépen fut, majd áramtalanítom az első gépet, mi történik. Ahogy néztem be tudom állítani hány perc után indítsa el a közös tárolóról a maradék gép a vmet, meg van még sok opció.
Úgy, hogy mást csináltam közben, pár óra volt az egészet felrakni. Nem számítottam ilyen olajozott működésre.

  • 1544 megtekintés

( slinky v | 2020. 07. 17., p – 17:11 )

a minimum 2 magaban foglalja a 3-at is.....

linuxakademian volt hozza vmi hack, drbdvel. nezd meg.

A 2 gép menne folyamatosan, a 3. csak néha, mint mentés, vagy olyasmi. Megnézem azt. Erre gondoltál?

https://devopsakademia.com/course/szerver-virtualizacio-xen-es-drbd/

https://xcp-ng.org/blog/2020/01/24/xcp-ng-and-linbit-alliance/

https://www.youtube.com/watch?v=jvhUY81pBw0

( andrej_ v | 2020. 07. 17., p – 17:56 )

Ha az egyik gépen van a storage és az áll meg, akkor mi a koncepció az átállásra? Ezek a gépek redundáns táposak, külön UPS-re tudod tenni a gépeket?

Jahogy úgy shared, igazából szerintem az distributed. :) A shared-et általában a több gép által elérhetőre használják, ami 1 doboz. A Xen és DRBD-t le kell tesztelni, hogy most mit tud. Ahol ilyenre van szükség, ott valamilyen cluster megoldást alkalmazok, általában egy FC vagy iSCSI storage-dzsel megtámogatva (dual controller).

Amit keresel szerintem azt úgy nevezik hogy hyper-converged storage. A koncepció lényege, hogy a hypervisorokon futnak VPS-ek, amik shared storageot valósítanak meg, gluster pl.: redundánsan. Majd ezt használha vissza a hypervisor és teszi rá többi VPS-t 

Látható, hogy ehhez inkább SSD-k kellenek a sebességek miatt, akkor meg min 10GbE stbstb. Persze még mindig olcsóbb mint külön redundáns SAN hálózatot összedobni.

Fedora 41, Thinkpad x280

Mit ertunk az alatt, hogy "menjen"? Nincs penz hostolni? Osregi a vas, ezert barmikor elszallhat a rakba?

Mert amugy el nem tudom kepzelni, miert ne lehetne folyamatosan online a gep, meg ha VPS-ek nem is kerulnek ra. A Proxmoxnal tudomasom szerint megadhato, hogy mikor mi tortenjen, ha eleve keves memoriat raksz a gepbe (vegulis csak witnessnek kell a clusterbe), akkor nem nagyon fog odapakolni semmit. 

A Proxmox HA eseten viszont egyaltalan nem opcionalis, hogy a 3. gep folyamatosan menjen. Ha csak 2 gep megy, es az egyik megdogik, elegge haromeselyes hogy osszeall-e ujra a cluster. Raadasul a splitted brain veszelye miatt nagyon fontos a paratlan szamu gep a clusterben.

Adatvesztes ritkan lehet belole, raadasul ha a Proxmox alatt szet is esik a cluster, a gepek ebbol mit sem vesznek eszre. Akar ujra is epitheted a Proxmox clustert alatta, a Qemu/KVM nem fog megallni emiatt. Inkabb az a problema, hogy eleg trukkos ujrahuzni a clustert, foleg, ha nem tudod, hogyan kell, vagy nem tudod egyaltlaan, mi a problema. Meg ha tudod se egyszeru. Ezert en semmikepp sem javaslom, hogy a clustert 3-nal kevesebb geppel futtasd barmikor. 

Ahogy mondtam, a Proxmoxnal szabalyozhato, mit hol inditasz, ha az a felelem, hogy valami a gyenge gepen indul el - ne aggodj, nem fog, ha nem akarod. Viszont, cluster witnessnek egy kenyerpirito is alkalmas, es sokkal nagyobb hasznot hajt (szivasi idoben) mint amennyibe az uzemeltetese kerul. 

Blog | @hron84

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

via @snq-

Nem kell Ceph.
Proxmox HA esetén 3-node (3db gép) kell, nem fogja elindítani - kézzel kell indítanod.
Az alaplapi hálókártyákat nem preferálom, dedikált PCI-E kártyán lévő portokat érdemes (egyazon kártyán lévőket).
Aggregált sebességet nem mindegyik switch támogatja, tehát csak max 1G lesz akkor is a sebesség.

DRBD az blokk eszközt emulál, ami megjelenik az összes hoszton, de csak egy adott hoszt írhatja egyidőben - többi nem (fencing),
a fenti megoldások pedig "fájlrendszer replikációt" csinálnak - képes elosztott IO-ra (hasonló megoldás mint a Microsft Storage Spaces).

(bonding) " dedikált PCI-E kártyán lévő portokat érdemes (egyazon kártyán lévőket). " - ezzel megoldod azt, hogyha a kártya rotty, akkor a bonding interfész mindenestől rotty. A bondingot a rendelkezésreállást _is_ növelő megoldásként célszerű összerakni, azaz két fizikailag független adapter/eszköz legyen lehetőleg a kábel mindkét végén. Szerintem...

Mehet a bonding/teaming, csak célszerű két fizikailag független kártyára rakni. Így ha az egyik fizikai lábát kiszolgáló kártya megkotlik, a másik még -fele sávszélességgel- el tudja vinni a forgalmat addig, amíg a karbantartáshoz (kártyacsere) szükséges leállásra időt lehet szakítani. Ugyanezért célszerű (ha van rá eszköz) a másik oldalon két switchet használni (stackelve), és úgy kialakítani a lacp trönköt a túloldlaon is - így egy switch kiesését is "túléli" a rendszered.

Hasznos. 2 kulon halozati kartya, 2 switch. Ha a routerem megall, akkor ugysem erem el wifin a gepeken levo vmet, amiben ott a fajl szerver. Meg nem eri el a wifis cuccokat. Meg nem lesz net. De ez masik problema lehetőség. Lehet ezt meg bonyolitani, nem kicsit. 2 router, 2-3 switch, dizel aramgenerator, olomfalu bunkerben, 1 ev szaraz elelemmel es oxigénnel :)
 

Ha a 2 halokartyabol az egyik megkotlik, akkor perec van, mert a masikon meg csinalok egy live migrationt, atallok a masik gepre, lekapcsolom es halo kartyat vagy hddt cserelek. Ha kesz, vissza live migration. Jo otlet, koszi.

 

 

Gondolom arra utal, amire énis probáltam, hogy szép a HA, de azért vasból sem jó bármit alászórni, illetve minimum két külön szünetmentes kell. Lelkileg én még ott járok, hogy a HA cluster jellemzően akkora ráfordítást igényel (hogy az munka vagy eszköz ár, az most lényegtelen), hogy egyáltalán nem biztos, hogy nyersz vele annyit valójában. Ha desktop szerű dolgokból rakod össze, pláne desktop diszkekkel és nincs hotswap opciód, akkor ha kísérleti/hobbi projekt, akkor szerintem ok, de élesben inkább egy jóféle rendundás szerverrel próbálkoznék. Aztán ha az üzleti igények kilőnek az égbe, akkor prezentáljuk a költségét a szuperHA-sohanemállmeg c. sztorinak és rögtön nagyon el szoktak gondolkodni.

A szűk keresztmetszetek általában az áramellátás és az internet kapcsolat vagy a helyi hálózat, nem a hardware. Hardware fronton nagyon kényelmes, hogy az ember livemigrál, node-ot frissít, akár még ki is porolja (kompresszorral kirobbantja az előző év féltonna porát) és mindezt munkaidőben és mindezt szolgáltatás kiesés nélkül. A másik szűk keresztmetszet az a cluster megoldás mondjuk úgy "elszakadása a valóságtól". Partnernek volt Proxmox hálózat megállási problémája, gyakorlatilag semmi se ment sehova, ismerősnél a Ceph köszönt el és sokórás állásideje volt. Én Windows-os vonalon láttam, hogy a szerintük "seamless rolling update" az inkább volt hegyomlás, mert nem vette észre, hogy a másik cluster node még azért frissít és leküldte a másikat is, mindezt persze éjjel 3-kor. A clusternyugalomban töltött szundiidő után meg fél8-kor kellett mindenfélét trükközni, hogy egyáltalán távolról nyakon lehessen vágni a gépeket. Amik abszolút stabil részei voltak a clustereknek, azok a két controlleres FC vagy iSCSI storage-ek, bár más meg ebből látott nagy fejreállást.

Szóval arra próbálok utalni, hogy a rendszered bonyolításával ezzel négyzetesen arányos (minden bonyolító lépéssel...) problémacsomagot veszel a nyakadba. Úgy indulnék neki, hogy alulról a hw-ből elindulva megnézném, hogy önmagában vagy párban mire számíthatok, milyen az áramhelyzet és a nethelyzet, a gépek hálózati elérhetősége mennyire lehet redundáns. Ha példul van egy egytápos switch a gépek előtt (melyik UPS-re kötöd...), vagy ha egy switch van, akkor máris ott a szűk keresztmetszeted. Persze egy switch ritkán hal meg, de itt mindíg lehetőségekről és azok kizárásáról beszélünk, amivel csökken a szolgáltatás előrhetőségének vagy leállásának veszélye.

Van egy szinuszos régi szünetmentesem új akkukkal, azon van a net, router, switch meg ez a 2 gép. Fájl szerver és a hobbi Home Assistant futna ezen, meg ami még kell majd. Családi célra, semmi üzletileg kritikus nincs itt. Csak jó lenne ha menne és nem lenne adatbukta. Kicsit kihívásból is 2 gép, meg mert van.

Adatbukta az valóban nemfinom, de én többfelé mentéssel védekéznék ellene. Akár egy kicsi NAS-sal (inkább erre használnám el a másik gépet, úgy hogy a másik gép problémája esetén ezen is mehessenek a szolgáltatások) másik UPS-en és úgy beállítva, hogy áramszünet esetén hamar lekapcsoljon, e mellett valamilyen felhős szolúcióba szinkronizálnék. Extra mentés, hogy hetente vagy havonta egy külső HDD-re mentenék, amit bár lakáson belül lehetőség szerint messze tárolnám. A két gép párhuzamos futásának a villanya se túl barátságos, illetve nagyban csökkenti a szünetmentes áthidalási idejét.

A klasszikust idézve: az a jó cluster megoldás, ami nem csökkenti a rendelkezésre állást. A két node-os felállás, a kevés üzemeltetési tapasztalat azt mondatja, hogy a fenti rendszer nem lesz jó megoldás.

Ha a legjobb rendelkezésre állást akarod kihozni a 2 gépből, akkor én az egyik gépet hidegtartaléknak használnám, ezzel jóval egyszerűbb lesz a software stacked, kevesebb hibalehetőseggel, és a HW hibák esetén is van hova nyúlni azonnal.

Hát ja. Egyszerűbb lenne, ha 1 gépes lenne, a másik meg tartalék. De ha Xcp-ng és halizarddal megcsinálom a 2-3 gépes ha clustert, még akkor is lehet az, hogy csak 1 megy, karbantartáskor vagy frissítéskor bekapcsolom a másikat, ha szinkronban van, live migration, aztán kicsit a másik megy. Tanulságos lesz, hogy mi lesz.

2 gép lehet, de automata failovert ne akarj. Split brain esetén majd te tudod, hogy melyik maradt abban az állapotban, amelyik használható. 2 gépes cluster nem fog jó döntést hozni magától. Illetve van rá 50% esélyed, hogy igen. Ha ez neked jó, csináld.

Ha egy fázisod van, akkor ebből kettő jó. Ha 2 fázisod van, akkor bonyolodik a helyzet, mert a két gépet nyilván külön fázisra teszed, de a STONITH eszköz vezérlése másik fázison kéne hogy legyen mint ami vezérelve van (vagy akkun) és ez azt nem tudja. Ha egy fázisod van, az viszont nem valami jó HA, mert pl egy zárlatos táp egyszerre fogja lerántani a gépeket.

A redundáns tápos szerverek és a dedikált porton figyelő IPMI alapú STONITH gyakran a legegyszerűbb megoldás.

Az lesz a gond, hogy ha meghal a táp, akkor megáll az ipmi, és a STONITH nem lesz nyugtázva amire reagálhat úgy a cluster, hogy a potenciális split-brain helyzet miatt nem migrál (unclean node). Fel tudod úgy scriptelni/konfigolni, hogy ebben az esetben vegye úgy hogy halott az alany, de erre külön gondot kell fordítanod. Ezért hasznos ha a fencing device tápja eleve redundáns vagy legalább független az alany betápjától — egy gonddal kevesebb.

Ja nem.  Joval dragabban lattam univerzalis ipmi kartyat, orultem is ennek. Korai öröm.

Hogy szokták megoldani a stonith / fencinget megoldani ipmi nelkuli szervereknel? Veszek valami wifis vagy ethernetes relay kapcsolot, legalabb 2 portosat, es egyik gep lekapcsolja a masikat?  Mondjuk nem tunik szep modszernek lekapcsolni az aramot, de ha ez kell... Az nem jo, hogy egymast le tudjak kapcsolni sshn shutdownnal?

Kell ez az egész? A halizard nem lehet, hogy kezeli ezt is szoftveresen? Lehet osszerakom hetvegen halizardra a gepeket, 2 halo kartyaval, 2 switchen. Megirom a tapasztalatokat majd.

En nem ragaszkodom a halizardhoz, csak nem talaltam mas, kesz cuccot erre.

A hw-től építkezel felfelé. Amit papíron kitalálsz, azt végig kell tesztelni mindenféle esetre. A sima puff kikapcsolás nem túl nyerő. Olyat szoktak, hogy A és B út van a két szerver között, akár mindkettő hálózati és ennek függvényében megy az átállás/kikapcsolás. A fő problémád az lehet, hogy mindkét gépet azt hiszi, hogy ő maga az elő cluster, pláne ha a storage is mindkettőn ott van. Arra próbálunk rávezetni, hogy adott esetben többet árt, mint használ egy ilyen történet. Minden esetre a választott megoldást ha összerakod, akkor mindenképp teszteld mindenféle esetekre, hogy hogyan viselkedik.

Amiket én láttam, ott "ezt megoldja a rendszer" szinten voltak ezek kezelve, illetve ott az FC vagy iSCSI storage*, amin ott figyel a quorum -ra használt LUN. E mellett a hálózat és elektromos ellátás független volt, illetve a redundáns tápokat tudtuk különféle UPS-eken variálni, akár 3-4-en, ezzel próbáltuk a fölösleges átállási procedúrát elkerülni.

* A storage-et defacto elpusztulhatatlannak vettük a dupla controller és dupla táp és minden miatt, ott kellett meghúzzuk a határt, mert az anyagi keretek miatt nem tudjuk duplázni/replikálni.

Hogy szokták megoldani a stonith / fencinget megoldani ipmi nelkuli szervereknel?

Az a kánagy igazság, hogy a rendes fencinghez külső hardver kell, az ideális pl. a külső intelligens storage eszköz, ami egyszerre adja a közös diszkeket (és akkor nem kell drbd-vel se bohóckodni), plusz ezen keresztül egy nagyon egyszerű fencing mechanizmust is tud adni (akinek nem szabad működnie, azt nem engedi oda az adatokhoz, így nem tud benne kárt tenni).

Ez a stonith, ez a szegény ember fencingje. Kicsit savanyúbb, kicsit sárgább...

Az nem jo, hogy egymast le tudjak kapcsolni sshn shutdownnal?

Azt ugyan hogy csinálják, amikor éppen mondjuk rebootol a másik gép? Vagy szimplán nem megy a kernel? Vagy amikor fizikailag ki van kapcsolva a másik gép, mert beszart a tápja?

es egyik gep lekapcsolja a masikat?

Az az eset megvan ugye, hogy ha mind a kettő kikapcsolja a másikat, akkor egyik sem fog kiszolgálni?

( Elbandi v | 2020. 07. 21., k – 21:01 )

https://www.linbit.com/linstor-setup-proxmox-ve-volumes/

promoxnal csak akkor kell 2 tobb gep ha automata vm inditgatast akarsz, stb. amugy ketto geppel is kivaloan mukodik, ha megpusztul az egyik node, akkor kezzel kell inditani a masik node-on a vmeket (de ez hazi gepnel belefer). ha kell az automata cucc, akkor tegyel hozza egy rpi vagy valami alacsony fogyasztasu gepet.

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

Nekem eszembe sem jutott az ipmi kartya, az itteni szakik javasoltak, gondolom okkal. Home Assistantot akarok hasznalni, vezetek nelkuli szenzorokkal, relékkel, öntöző rendszer, redőny, ki tudja még mi jut eszembe. Gondoltam jo lenne valami megbizhato megoldas, ami folyamatosan megy. Igy jutottam idaig. Nyilvan allhat 5 percet, akar orakat is, de ha nyaralni megyek, jol lenne, ha mukodnenek az elore kitalált rendszeres folyamatok, ez a gep meg felugyelne. Aztan ott a file szerver, ha mar lesz ez a 2 gép, az is legyen ezen, a vmben. Kicsit kihivas, hogy jo lesz-e, meg ha maceranis megcsinalni. Maximalizmus, ami nem indokolt. Ha meg lehet oldani, hogyha megall az elso gep, a masodikon ujra elindul a vm, automatikusan, akkor miert ne? Egyszerubb lenne egy hp mikroszerver, csak 1, aztan kesz, de ha van vele valami es nem vagyok ott, az sem katasztrofa, de mivel adott a 2 gep, kihozom belole a ha clustert, ha megoldhato.
 5-7-9 szerver is lehetne, elosztva kulonbozo foldrajzi helyen, duplan tappal, sok halo kartyaval, vagy helyben kulonbozo switcheken, de nyilvan ez mar az overkill overkillje lenne. En megelegszem a sima overkillel, 2 geppel, sima, jo tapokkal, erre keresem amit ki lehet hozni szoftveresen. Ha megall mind a 2 gep, megall, de megprobaltam. Tobb eselyem van, mint 1 geppel ha megall vagy adatbukta lesz. Attol, hogy neked overkill, felesleges, tulbonyolitott, nekem meg lehet pont jo es hasznos.

Volt, hogy régen a Desktop Linuxomra mindent csomagbol forditottam, amikor nagyon lassu gepem volt. Hogy gyorsabb lesz. Nem ereztem, hogy gyorsabb lett volna, de legalabb onnantol nem tudtam csomagokkal frissiteni a fuggosegek miatt. Nem sikerult, aztan ujra telepitettem mindent csomagokkal es ugy karbantarthatobb lett. Azota ketszer is meggondolom, hogy mit rakok fel kezi forditassal. De kiprobaltam.

vagy 1, vagy 3 gep legyen. 2 semmikepp. igen, ha 1 van, es megall, akkor megallt, de ezek azert nem tortennek meg olyan surun igazi szerver vasakkal.

 

en azt javaslom vegyel hasznalt szervert ami nem olyan regi (mondjuk dellt v supermicrot), ezeket olyan 60-120k korul utanad vagjak darabonkent, aztan mar csak penztarca kerdese hogy 1 v 3 lesz.

Én hiszek nekik, csak nem hoax, idézet:

"It's official, we are the number one solution around the world when it comes to Citrix Xenserver and High Availability on two-node clusters using standard internal storage! It's easy to use, 100% reliable and no strain on hardware resources. Best of all, it's free with no purchase requirements, no adware, and no hidden code."

arra akarnak rávilágítani, ha 2 gép van, le vannak szakadva egymástól és mindkettő magát gondolja az egyedüli gépnek qrvanagy szívásnak nézhetsz elébe.
A 3. gép pedig arra való, hogy megerősítse a gépet abbéli hitében hogy tényleg csak ő működik. De ezt is leírták más sokan.

Hinni a templomban kell. Ők azt mondják, hogy ebből a fos felállásból ők tudják a legjobbat kihozni (csak kicsit marketingesül fogalmazták meg). De ebből egyáltalán nem következik, hogy ez abszolút értékben is jó valami lesz (amúgy nem lesz, a lehetetlent ők sem tudják megugrani).

Na, lassan csak kiderul a "miert" is:)

Ha tenyleg ennyi, akkor szerintem felejtsd el ezt az egesz bonyolult dolgot amit kitalaltal. Futtasd az egyik gepen a HA-ot, az sqliteot mented 5 percenkent backup apival, rsynceled a masik gepre, a konfig fajlokat szinten. Van telepitve ott is egy HA-od, ami nem fut, amig a masik nem all le. Ha leall felhuzod azon a gepen az IP-t, es elinditod amit el kell. Ha van MySQL-ed akkor csinalz egy master-slavet, ha van Prometheus akkor futtatsz mindket gepen, stb. App oldalon sokkal konnyebben megoldod, mint ha tapasztalat nelkul akarsz megbizhato ket nodeos clustert epiteni. Ahogy szinte mindig: kiveve ha tanulni akarsz, es nem szamit ha all:)

Hat, amit leirtal az talan nagyobb melo, mint xcp-ngt felrakni es ra a halizardot, es megy is. Onnantol meg eleg 1 vmet kezelni.

Tanulni akarok, de a te javaslatod nem oldja meg, ha nem vagyok ott es megall a Ha. Mentesem lesz, de ennyi. Mondjuk az is tobb, mint a semmi. Ilyen alapon felhobe is menthetnek majdnem.

Ha nem lenne 2 gepem erre, es nem erdekelne, hogy menni fog vagy nem a 2 gepes hazi ha cluster, berelnek valami olcso felhos vmet.

No offense, peace meg minden, de aki le akar beszelni a 2 gepes ha clusterrol, ti probaltatok a gyakorlatban is elkesziteni es uzemeltetni, hasznalni? Peldaul azt a halizardot? Mert elvileg mindent megold magatol. Bocs a hülye kérdésért.

Hat, amit leirtal az talan nagyobb melo, mint xcp-ngt felrakni es ra a halizardot, es megy is. Onnantol meg eleg 1 vmet kezelni.

hajra, csinald akkor:)

Tanulni akarok, de a te javaslatod nem oldja meg, ha nem vagyok ott es megall a Ha. Mentesem lesz, de ennyi. Mondjuk az is tobb, mint a semmi. Ilyen alapon felhobe is menthetnek majdnem.

ooo, elinditod? leirtam ezt is, a megvalositas a fantaziadra van bizva, olyan 20 sor lehet bashben.

No offense, peace meg minden, de aki le akar beszelni a 2 gepes ha clusterrol, ti probaltatok a gyakorlatban is elkesziteni es uzemeltetni, hasznalni? Peldaul azt a halizardot? Mert elvileg mindent megold magatol. Bocs a hülye kérdésért.

igen. halizardot nem, soha nem hallottam rola. a 2 nodeos cluster alapvetoen egy elmeleti problema, amit szepen korbe lehet bastyazni mindenfele "hekkekkel", de ehhez  vegig kell gondolnod sokmindent, nem eleg egy random IPMI kartyat megrendelni netrol. dap leirt sokat ebbol (neki is hihetsz, o is latott mar ilyet:), de ettol meg boven lesz hazi feladatod, ha az nagy melonak hangzik, amit leirtam. ketsegkivul jobb ha csak a fu szarad ki, mint ha a fonokod hiv fel orditozva, hogy miert all minden, ezert mondtam, hogy ha tanulni akarsz, akkor hajra:)

"Home Assistantot akarok hasznalni, vezetek nelkuli szenzorokkal, relékkel, öntöző rendszer, redőny, ki tudja még mi jut eszembe"

Aha, na ettől kezdve overkill az egész topik. Ezt százan megcsinálták már előtte valami mikrovezérlőre. Akár arduino, 433MHz rádiós adó-vevőkkel beszélnek a modulok a központi arduinoval és kész. Ha kevés az atmel, lehet stm32 irányba nézelődni. Ezek nem állnak meg és nem fogyasztanak száz wattokat, mint a felvázolt borzadalom :)

Egyébként meg, ha a modulokon van egy RTC, a központi mikrovezérlőtől megkapják az ütemezést, mikor kell locsolni, redőnyt leereszteni és ha lefagyott a központ, elmennek a korábban kapott ütemezés szerint.

A redőny vezérlőhöz köthetsz helyben fényérzékelőt, de igazából az RTC-ből is sejti, hogy este van...nem kell a központra támaszkodni.

És akkor az ész nem centralizálva van, ha annyira félsz, hogy fejreáll, akkor megállt mindent. Bár, ha megáll, minden mi van? Pár millió ember elmegy nyaralni ilyen cuccok megléte nélkül is és semmi nem történik.

Szóval az egész annyira rossz végén lett megfogja, hogy hűha :)

Nem vagyok én rádióműszerésforrasztófénykardmester. :) Beleolvastam itt sok mikroelektronikai, arduinos temaba, hat mindenki mashogy neheziti az eletet. Haverom Xiaomi kész wifis okosotthon termékekkel Raspberryn használ Home Assistantot, jo lassu, meg megdoglott az sd kartyaja es mindene elveszett, kezdhette ujra az egeszet. Meg elotte is valami volt es lagalabb haromszor ujra beallitott mindent. En ezt probalom elkerulni ezzel. Neki kulon Nas van, nekem az egyik gepen most linux es samba megosztasok, lamp, stb. Ezek kerulnek majdba vmbe a Home Assistanttal egyutt. Mi abban az overkill, hogy amugy is megy egy gep, ami mindenes linux, most vmben fut majd, 2 gepen? Fogyaszt majd a 2 gép 50-90 wattot, drága hobbi.

Én nem mondtam, hogy mindenki hülye, sőt, ti vagytok a szakik, és onnan nézve csak én a hülye kezdő amatőr kontár inkompetens machinátor. A te szóhasználatoddal: javaslatot várnék tőletek, ha már úgy is sz*pni fogok, a legkevésbé kelljen. Mert lehet kicsit, közepesen, nagyon, 1 és 2 bubival is.

( raziiii v | 2020. 07. 22., sze – 12:44 )

Én biztos nem bonyolítanám túl ennyire a sztorit :D
 Ha mindenképp 2 géppel akarod megoldani, szerintem egy x időnkénti rsync a fő gépről a másikra, illetve a második gép mondjuk folyamatosan pingelné az elsőt. Amennyiben hosszútávon kimaradást észlel az első gép irányába (x>5perc mondjuk),  akkor a második gép elindítja az adott szolgáltatásokat és ha IP érzékeny a dolog akkor a gép címét is átvésné. Max egy rebootot lehet közbeiktatni. Amikor meg hazaérsz mindent visszadobsz kézzel/automatizálva. (Reflektálva az öntözőrendszer, stb részre)

Nem a világ legjobb megoldása, de ez ilyen "lowbudeget-homemade HA" lehetne.

Úgy értem, ha van az a halizard peldaul, ahol xcp-ng-hez megcsinaltak a drbd, iscsi, stb modon a mukodest, scriptelve ami logikus, akkor en nem akarnek csinalni ilyet magamnak nullarol vagy egy felkesz modszert tokeletesre, ha ez mar elerheto. Megirom a halizard tapasztalatot, aztan kiderul bevalik vagy nem. Koszonom a segitseged neked es itt mindenkinek.

( influencer | 2020. 07. 29., sze – 17:23 )

Frissítés 1:

Adott a 2 szerver ami régi desktop gép valójában, benne 2 gigabites hálókártyával, egyik alaplapi. Felraktam a legújabb xcp-ng 8.1.0-2 verziót a 2 gépre, linux raid 1, csak 2 hdd a gépekbe, azon minden. Létrehoztam egy közös xcp-ng poolt a 2 gépen, az még kellett a telepítés előtt. Halizardról letöltöttem az install scriptet ami 10 kbyte, az lehúzott minden csomagot. Megadtam az ip címeket, mi legyen a közös sannak az ip címe, és kész. Figyelmeztetett, hogy töröl mindent a poolból, de hát üres volt. A Drbd szinkronba állt, a második háló kártyán kommunikálva, létrehoztam egy linux vmet erre a közös tárolóra, futtattam rajta programokat és néztem, live migráltam egyiket a másikra, oda vissza, tök gyorsan ment. Azt is néztem, hogy a kettes gépre live migráltam a vmet, az elsőt kikapcsoltam. Majd ahogy visszajött, akkor szinkronba állt automatikusan, és újra live migrálás az első gépre. Tehát így megoldottam az automatikus mentést is. Ha akarom, így csak 1 gép megy, ha otthon vagyok, ha meg nem vagyok, bekapcsolom a másikat, és ha az első megáll, ott a másik.
Még azt fogom megnézni, ha az első gépen fut, majd áramtalanítom az első gépet, mi történik. Ahogy néztem be tudom állítani hány perc után indítsa el a közös tárolóról a maradék gép a vmet, meg van még sok opció.
Úgy, hogy mást csináltam közben, pár óra volt az egészet felrakni. Nem számítottam ilyen olajozott működésre.

Másik edge case: egyik gépet leállítod, a másikon változtatsz valamit, aztán azt is leállítod, és beindítod az elsőt (nyilván a múltbéli állapotból fog továbbmenni), csinálsz rajta valamit, majd beindítod a második gépet. A helyes kérdés ugye az, hogy melyik adatod fog elveszni, és csendben, vagy szól.

Ha nincs otthon, akkor a magasabb rendelkezésre állás miatt beindítja a második gépet is, volt az alapvetés. Én mondjuk azt csinálnám, hogy alapvetően az "a" gép lenne a master, akarom mondani elsődleges és a "b" gép a sla... izé, másodlagos kiszolgáló.
Power off/on esetére beállítanám a b-t, hogy maradjon kikapcsolt állapotban, a-t pedig hogy kapcsoljon be. Ezzel az áramszünet után csak az "a" gép indul el, és riasztja a gazdát, hogy oldja meg a helyzetet (Humán quorum).
Automatizálva meg azt lehet, hogy ugyanígy csak az "a" bootol  fel, de szolgáltatások nélkül, majd elindítja a "b"-t, és vár x percet, hogy az is elinduljon (link a direkt kábelen, illetve a b ip-je válaszoljon mondjuk ssh-n).
Ez után az "a" meg kell nézze, melyik gép volt az, aki legutóbb a szolgáltatásokat "vitte" (hol van frissebb "i_am_the_master" állapot rögzítve (ezt az elsődleges kiszolgálónak kell lokálisan és rendszeresen touch-olni pl.)), és azt az állapotot kell scriptelve visszaállítani. Ezzel az áramszünet előtti "borulás" is kezelve van.