Az utóbbi időben csodával határos módon, kezdtem beérni magamat a munkámmal. Ahhoz, hogy ez az áldatlan állapot ne tartson túl sokáig, elkezdtem új lehetőségek és kihívások után keresgélni. Így jutott eszembe, hogy foglalkozhatnék akár a DRBD-vel is.

Úgy indult az egész projekt, hogy munkahelyen van több tucat elavult, asztali használatra teljesen alkalmatlan, kis túlzással a kacat és az ipari hulladék között evickélő konfiguráció. De ilyet nem mondunk előttük, így legyenek szimplán tartalék alkatrészek. A másik tucatot pedig úgy hívják, hogy selejt raktár, ők legyenek a megmentendők. Szóval őket összelegózva bármilyen komolyabb használatra alkalmatlan, ugyanakkor működőképes konfiguráció keletkezik. Ők lesznek a kis történetem főszereplői.

Előkészületek

DRBD?

Distributed Replicated Block Device. Elosztott, replikált blokk eszköz. Sokkal közelebb vagy, ugye? Gondoltam. :) Most nem nagyon mennék bele a részletekbe, legyen elég annyi, hogy RAID1-et valósít meg hálózaton keresztül. A RAID1 bal lába van a helyi gépen. A jobb lába viszont egy, a hálózaton lévő csomóponton van. Így mikor írsz, az adatok átutazva a hálózaton megjelennek a másik csomóponton is. Idővel. :) A kettő között sem történik varázslat, de nem szeretnék lelőni egy potenciális nagy cikk jelöltet. :)

Miért?

Nincs az jól, ha a sok, szép korú alkatrész csak úgy porosodik valahol és majd a következő selejtezésen elviszik őket bezúzni, de annak sincs értelme, hogy feleslegesen foglalják a helyet és porosodjanak. Főleg, hogy muzeális értékük még nincs.

Ahogy telik-múlik az idő, úgy lesz egyre kevesebb és kevesebb esély arra, hogy bármikor is lesz hozzájuk olyan eszköz, amivel még meg lehet hajtani, azaz kárba vesz(het)nek azok is, amiket még lehetne valamire használni. A DRBD előtt gondolkoztam még azon, hogy régi emlékeimet felelevenítve egy 2.4-es Linuxra épített, Mosix clustert rakok össze. Azonban továbbgondolva a projektet rájöttem hogy ez anno' is csak egy egész jó technikai demó volt, semmi több. A „szabadidős projektnek” azonban valamilyen haszna is kellene, hogy legyen, valami olyannak kellene lennie, amivel nem csak az időm megy, hanem később elmondhatom magamról, hogy igen, tapasztalatom van vele. Így (is) esett a választásom a DRBD-re.

Végül, de nem utolsósorban, mérnökhallgatóként tisztelettel gondolok az eszközeimre, legyenek azok akár újabbak, akár régebbiek, és sajnálnám, ha a még működőképes darabok mennének a levesbe.

A DRBD jó, de egymagában nem az igazi. Valami komolyabb esetleg?

Mint említettem, selejtezésre váró vagy oda készülő gépekkel fogok dolgozni. Az lesz a szerencsém, ha találok olyan CPU-t, amiben már van virtualizációs kiegészítés. Így akármennyire is szeretném belevetni magamat a jóval nagyobb és komplexebb megoldások rejtelmeibe, megvannak a korlátaim.

De kísérletezhetnél virtuális gépeken is…

Valóban! Azonban a virtuális rendszereken nem jönnek elő olyan új tapasztalatok, melyekkel igaz sokat szívok, de tapasztalatot jelentenek. Ilyen pl. mikor az egyik Maxtor Fireball lemez 1-1,2s közötti _válaszidőt_ generált, szemben a többi lemez 0,2s körüli idejével. A SMART szerint DMA checksum gondok voltak. (Kontakt)hibás lehetett a PATA kábel azon fele, ami felé nézett, mert egy átszervezés után rendbe jött.

Szóval ha már csinálok valamit, akkor szeretném, hogy a valós rendszerek valós problémái jöjjenek szembe. Igaz, hogy nem 1-2-sok TB-nyi adattal dolgozom, hanem mindössze 40 GB-tal (azt is olykor kínkeserves összeszervezni), de úgy gondolom, hogy ez esetben nem a méret a lényeg, no meg 40 GB így is másfél óráig szinkronizál 100 MBiten, most 1 TB egy élet lenne… vagy kettő. Ugyanazok a gondok jöhetnek ki itt is, mint jóval nagyobb adatmennyiségeknél. A DRBD szoftveres oldalán és a Linux kernelben mindenképp. Ugyanúgy hibásodik meg az ócska hardver is, és lényegében ugyanazokkal a gondokkal szembesülök, mintha modernebb eszközökkel foglalkoznék, csak más dimenzióban. Kísérletező terep, K+F, ahogy tetszik.

A bekerülés feltételei

Ahhoz, hogy valamely eszköz bekerüljön a projektbe, a következőknek kell megfelelnie:

• Alaplap esetén: Vagy 2 PATA port vagy 1 PATA és legalább 1 SATA port
• Merevlemez esetén: Minimum 20 GB-os legyen és ezt a tárhelyet maradéktalanul ismerje is fel a BIOS. Legyen hozzá elegendő jumper vagy tudjak olyan konfigurációt létrehozni, ahol nem gond ha nincs, mert szerencsésen jött ki a jumper mentes „felállás”. Végül jó lenne ha legalább az elején nem lenne nagy gond az adatok visszaolvasása. De több feltétel nincs. Nem kell se hibamentes SMART, se semmi olyan, ami a nagyobb, megbízhatóbb rendszerek építésekor fontos.

Szóval elég alacsony a küszöb. Van is jelentkező rendesen. Nagyrészt 20 GB-os Maxtorok (pl. az említett Maxtor Fireball), de akadnak 20-40-es WD Protégé csodák is. Igen, a múlt évezred technológiájával dolgozom, de pont ez a pláne benne. Jut eszembe: félek a Mercury tápoktól!

Előre is elnézést kérek, de ha már IDE:
– Milyen az az alaplap, amin nincs IDE port?
– Idétlen. :)
Sajnos nem saját találmány, az érdem Vivien nevű ismerősömet illeti @G+.

Készletek felmérése

Az előzetes felmérések alapján a rendelkezésemre áll 7 db 20 GB-os 4 db 40 GB-os Maxtor, WD, IBM(!) lemez, és még nem voltam mindenhol. :)

Alaplapok tekintetében sajnos már nem ilyen rózsás a helyzet, elég nehéz volt olyat guberálni, amelyik hibátlanul megy és van rajta elég PATA és/vagy SATA csatlakozó.

Ami a házakat illeti, szerettem volna olyat találni, ahol kereszthuzatot tudok csinálni, így megfelelő hűtést kapna a gépezet és nem azért pusztulna meg, mert megfő a saját levében. Sikerült is, ők a kis kedvenceim.

Alaplap keresgélés és aktív fejvakargatás közben egy kicsit elgondolkoztam azon, hogy nem lenne esetleg célszerűbb PXE-vel bebootoltatni a DRBD node-nokat, így nem lenne szükség a plusz lemezre és elég lett volna 1 PATA port. Ez azonban külön macera lenne, ráadásul nincs is hozzá megfelelő környezet kiépítve, a projektre fordítható szabadidőm pedig véges és ahogy ismerem a formámat, hamarosan újra negatív előjellel fog kezdődni.

Hogy melyik lenne az időtakarékosabb, nem tudom. Lehet, hogy a PXE összehozásával elment idő visszajönne a keresgetésből esetleg majd a későbbi lemezhalálok miatti újratelepítésekből, de az is lehet, hogy nem. Eddig volt két lemezhalálom. Egyiknél kattogás, majd visítás jelezte, hogy feladta a küzdelmet. A másikra már nem is emlékszek. Úgy veszem észre, hogy meghálálják ezek a kis „dögök” a törődést (aktív hűtés).

Irány a munkahely!

Miután a lemez teljesítette az alapvető követelményeket, bekerül a megfelelő RAID tömbbe. A cél, hogy node-onként 40 GB-ot össze tudjak állítani, ami nem is olyan egyszerű.

A 40 GB két módon jöhet össze. Az egyik, hogy a rendelkezésemre áll egy 40 GB és két 20 GB méretű lemez. Ilyenkor a két 20-as RAID0-ba szervezve képzi a felette lévő RAID1 bal lábát. A 40-es lemez pedig a jobbot.
A másik eset az lehet, hogy nincs 40 GB-os vasreszelékpörgető, de akad 4 db 20 GB-os lemez. Ekkor páronként RAID0-ba szervezve kijön a 2x40GB, amire mehet a RAID1.

Egyik megoldás sem egy életbiztosítás, de az egyik oldal teljes kipusztulását is elviseli, és talán a resync elviselhető idő alatt lefut (mielőtt valamelyik párja sztrájkolni kezdene).

Ami a munkakörülményeket illeti: a lemezek olyan házban kerültek elhelyezésre, ahol egy ventilátor pont rájuk fúj. Cserébe nincs légkondicionálás, így évszaknak megfelelően ingadozik a hőmérséklet.

A szoftveres alapja a rendszernek egy Ubuntu 14.04.2. Azért Ubuntu, mert megbízható és egy node teljes kiesésekor (rendszerlemez csatt) nagyon egyszerű és gyors az újratelepítés. Cserébe nem egy Gentoo, de most nem ez a lényeg.

Igen, vannak konfiguráció menedzsment és távtelepítő megoldások, mellyel pikk-pakk meg lehet ütni egy reinstallt, a helyreállított node-on akár anélkül, hogy bármi mást csinálnék a hardver cseréjén vagy életre keltésén kívül, de jelenleg ilyen rendszer nincs bevezetve (mert nem kell), így marad a kézi konfiguráció. Vagyis inkább a konfigurációs állományok helyükre másolása.

Hogyan működik?

DRBD

Az alkalmazások felé teljesen transzparens az egész. A DRBD nevének megfelelően nem mutatkozik másnak, mint egy blokk eszköznek (ugye Distributed Replicated Block Device). Ennek megfelelően nem árt, ha fájlrendszer is van rajta. Ezután a mount minden további nélkül képes csatolni. A sebessége teljesen jó, a rendszer nem vár a hálózatra, hanem ha sikerült a háttértárra az adatot kiírni, akkor rendben van, majd ráér a hálózat szinkronizálni. Ezért is lehet(ne) vicces a primary-primary felállás, ahol mindkét node egyszerre írhat a blokkeszközre. Ha ugyanazt módosítják, akkor melyik adat marad meg? Ugye… nos, jelenleg úgy oldom meg a problémát, hogy nincs primary-primary felállás.

Primary-primary

Maga a DRBD azonban nem kifejezetten a nyers adatokkal dolgozik, hanem még fölé van húzva egy virtuális gép. Később így lesz megoldva a fentebb említett primary-primary probléma: két fizikai gép, több virtuális géppel és mindenki a saját kis virtuális lemezén garázdálkodik, nincs lehetőségük egymás adatába belepiszkálni, azaz nem fog fájni a fejem. Profit!

Virtuális gépek

Egy virtuális gép nagyjából nem több mint két állomány: a konfigurációs XML és a virtuális merevlemez. Így praktikus: ha valami technikai hiba miatt nagyobb gond akad a működés során, és az elsődleges host megpusztul, akkor percekben mérhető az az idő, míg primary-re állítom a párját és a kérdéses virtuális gépet elindítom. Ezzel az idővel nem lehet versenyezni, praktikussá és mobilissá teszi a tesztet. Sokat lendítene persze, ha egy Pacemakert is be tudnék építeni, és gyönyörűen magát állítaná a rendszer, én pedig ráérnék csak a hardverek buksiját simogatni. Ugyanakkor a rozoga konfigurációk miatt (és hogy a virtuális gép nem kritikus) túlliheghetné a feladatát. Jobb, ha kézzel intézek mindent, hiszen lehet, hogy a RAID alrendszer rémült meg valamelyik lemez csuklásától. Vagy frissült a systemd és elcseszett valamit.

Feladat

A következő lépés, hogy feladatot kell találni a virtuális tesztgépnek. Olyan feladatot, amire elég egy Ubuntu, 1 GB RAM és még haszna is van. Így lett ő az új, elsődleges DNS gyorsítótár, feladata továbbá különböző statisztikák gyűjtése Muninnel, a többi szerver naplózásának összegyűjtése és további elemzésre PostgreSQL adatbázisban való tárolása. Ez naponta, olyan 50-60 MB-ot jelent, ami ha pesszimistán számolunk, akkor ~1,8 GB havonta. Nincs egy észveszejtő I/O igényem, az biztos, szóval a közeljövőben kitalálok még valamit. Ami hasznos, megmozgatja öreg csontjait és megvan 40 GB-on.

Ingerküszöb emelése, riasztások enyhítése

Mivel leharcoltak az eszközök, szinte az első pillanattól kezdve folyamatosak a riasztások. „Ég” a Munin mint a karácsonyfa, szünet nélküliek a szerinte kritikus hibák. Viszont amíg működik, addig működik, nem igaz? A rendszert pont hibatűrésre hoztam létre, szóval nem szabad, hogy egy közepes méretű hiba nagy galibát okozzon.

Így lettek a riasztások a mindennapjaim részei. Ahogy a SMART „Raw_Read_Error” és egyéb hibái is. Vagy hogy a hddtemp szerint 170-180 fokos a lemez, ami néha képes visszahűlni 30-35 körülre is. Esetleg az APIC Incompatibility hibaüzenettel F1-re váró BIOS-ok. Szép az élet. :)

A projekt célja

Rövid távon

Rövid távon folytatom az eddigi teszteket és igyekszem fokozatosan emelni az I/O terhelést. Igazán kíváncsi vagyok, hogy mennyit és mennyi ideig bír még el, lehetőleg anélkül, hogy CPU limitet okoznék. Az lesz szerintem a legjobb, hogy a lehető legtöbb szálon, slave-ként beépítem a jelenlegi infrastruktúrába. Így a kimaradása nem lesz hatással a rendszer működésére, ugyanakkor melegtartalékként üzemel majd vész esetére és szépen lesz terhelve is. Mindenesetre, ahogy időm engedi, nézegetem a további alternatívákat is, főleg ha már nagyobb, főleg gyakorlati, rálátásom lesz a dolgokra.

Középtávon

Középtávon reménykedek, hogy mondjuk 2-3 hónap múlva kint lesz a DRBD 9.0, (vagy találok valami jobbat) amivel már normálisan (egymásra építés nélkül) képes lehetek a meglévő eszközökből, három vagy több node-ból álló rendszert építeni, amivel szignifikánsan növelhetném az üzem és adatbiztonságot. Nem mellesleg a jelenleginél jóval több helyet kaphatnának a felhasználók a mentéseiknek. Megfelelő tesztelés után elképzelhetőnek tartom, hogy egy tervezett karbantartás idejében a teljes rendszert átültetem. Mindenki boldog lenne, főleg én, mert minél megbízhatóbb a rendszer, annál több időm jutna más projektekre, amik ha beérnek talán még több szabad projekt időt adnak… és a végén be se kell mennem dolgozni, mert a rendszer önfenntartó lesz, engem meg rezsicsökkentés címén kitesznek… :D Aztán máshol kezdhetem előröl a dolgokat: goto title;

Hosszútávon

Hosszabb távon sem hiszem, hogy a meglévő eszközökből többet ki lehetne hozni, attól pedig nem félek, hogy lehetőségem lesz ilyen célokra bármit is beszerezni. Bár mindenki jól járna, ez tény, de maradjunk a földön és legyünk kreatívak.
Annyi biztos, hogy mindenképp keresem a számunkra elérhető legjobb megoldásokat.

Ha nagyot álmodnék, (és miért ne, nemde?) akkor mondhatnám, hogy a végső utáni cél egy belső, privát felhő létrehozása, mondjuk Ceph és OpenStack segítségével. :)

Kicsit elkalandoztam, ezek már nagyon a jövő zenéi. „Kis lépésekben, Ellie, kis lépésekben.” Ismerős? Ha nem, ajánlom „A kapcsolat" című film megtekintését!