Ceph 3/2 vagy 3/1

( Darkfish | 2020. 08. 27., cs - 08:48 )
Virtualizáció

Adott egy Ceph cluster, rajta egy nagy pool-al  size 3 és min_size 2-es  paraméterekkel, ha az egyik node-ot karbantartás miatt le kell állítani 1-2 órára, akkor ha jól értem BÁRMELYIK hdd kiesése esetén a teljes pool read-only lesz?

Ebben az esetben érdemes-e 3/1-re állítani?

+ mi szól az ellen, hogy eleve 3/1-ben hagyjam?

( csardij v | 2020. 08. 27., cs - 09:19 )

Ezt te tudod eldönteni, hogy mi a fontosabb:

  • Mindig tudjál írni
  • Tuti biztos, hogy ne vesszen el adat

Persze de két kérdés újra:

 - jól értem-e, hogy ha 1 node karbantartása közben 1db HDD kiesik, akkor a teljes pool megáll 3/2-nél

- Mi a veszélye a 3/1-nek ami miatt alapból nem érdemes ezt a beállítást használni?

3/1 esetén a node újrainduláskor+ha 1 HDD elhalt ÉS rossz az időbeállítás akkor hibázhat a helyreállításkor?

A ceph-es tapasztalataim régiek, de:

- ha egy teljes node karbantartásra leáll, akkor 3/2 esetén ugyan még van redundancia, de ha ezen idő alatt a működő node-oknál kiesik egy HDD, akkor az előírt redundancia, hogy egy adatnak legalább két helyen meg kell lennie, már nem lehetséges, tehát az érdemi adatvesztés elkerülése érdekében a Ceph RO-ba teszi a pool-t. Tehát nem áll meg, de csak olvasni fogod tudni, írni nem. Adatod viszont nem vész el, mert a másik diszken még megvan.

- a 3/1 azt jelenti, hogy addig engedi a Ceph az írást, amíg legalább egy diszkre az adat leírható. Azért nem érdemes ezt használni, mert ilyen esetben a pool csak akkor vált RO-ba, amikor már annyi diszk kiesett, hogy adatvesztésed is van. Ez nyilván nem szerencsés.

"az érdemi adatvesztés elkerülése érdekében a Ceph RO-ba teszi a pool-t. Tehát nem áll meg, de csak olvasni fogod tudni, írni nem."

Ez igaz, de a gyakorlatban az összes arról futó VM megáll.

"mert ilyen esetben a pool csak akkor vált RO-ba, amikor már annyi diszk kiesett, hogy adatvesztésed is van. Ez nyilván nem szerencsés."

Szerencsésnek persze hogy nem szerencsés, ugyanakkor én arra vagyok kíváncsi, hogy jó gyakorlat-e az, ha a node karbantartásának idejére csökkentem a min_size-t?

Nyilván ha észreveszem, hogy kiesett még egy HDD a karbantartás alatt, akkor a leghamarabb visszakapcsolom a node-t, és megvárom, míg az egész helyreállítja magát ÉS visszaállítom a min_size-t 2-re.

De e nélkül meg azt kockáztatom, hogy a karbantartás alatti HDD hiba kilövi az összes VM-et.

Ezért ennek így elsőre több előnyét látom, mint veszélyét.

Pl, 3 másolatból egyik az offline node-on van, ami sértetlen, csak régi, a másik két másolat alól pedig kidöglik a vinyo (mondjuk mert egy meghal, elkezd rebalancolni aztán terhelés alatt egy másik is kidől). Biztos láttál már sima raid5/6 stb tömbnél is olyat, hogy rebuild közben dölt ki másik hdd.

( ggallo | 2020. 08. 27., cs - 14:30 )

Én most állítottam össze életem első igazi (mármint fizikai) Ceph klaszterét, amit majd megfelelő kiismerés és tesztelés után élesben is szeretnénk használni. Így olvasd, amit írok.
Eléggé költség hatékonynak kell lennünk, mert ez a rendszer egy próba projekt, és ha bejön, akkor majd tudjuk fejleszteni, de elsőre nem akartunk és nem is tudtunk nagyon nagy összeget belefektetni.

Az összes megelőző információ gyűjtés után arra jutottam, hogy egy majdani éles rendszerben az abszolut minimum a 4 node, és node-onként minimum 2 OSD legyen már indulásnak is (itt speciel 4 lett, 2 SSD és 2 HDD formában, külön pool-ban). A Ceph 3/2 beállítással megy, és a fenti kalkulátor segítségével a nearfull értéket is jelentősen lejjebb vettem a kevés node miatt (gyárilag 0.85, nekem most 0.7).

Az éles rendszert szeretném ha működőképes maradna 2 tökéletesen működő node esetén (tehát 2 node teljesen jó, és rajtuk az összes OSD). A végén valami DC-ben lesz, ahová nem tudunk azonnal menni, és emiatt fontos, hogy ha egy node kiesik, és a maradék hármon van OSD hiba, akkor még ne álljon meg a rendszer. Ezt elvileg úgy érem el, hogy 3/2 a size és eléggé alacsony a nearfull, hogy minden adatom 3 példánya el is férjen ezen a 2 teljesn node-on végszükség esetén. Persze ez így rettentő nagy a kapacitás bukó, de ez az ára a kevés node+magas rendelkezésre állás igénynek az olvasmányaim alapján. Most több node nem fért bele a kitűzött keretbe.

Ilyen felállás mellett, ha karbantartok egy node-ot, akkor még mindig elromolhat OSD, vagy akár komplett node anélkül, hogy a rendszer megállna és/vagy 2-nél kevesebb példány lenne bármiből. Én nem mernék éles rendszernél olyant bevállalni, hogy lehet, hogy csak 1 példány van (nincs semennyi redundancia), mert onnan irtózat könnyű adatot veszíteni. Szerintem olyannal számolni kell, hogy pl. egy node hiányában bármelyik OSD read error-t produkál és ha 3/1 a beállítás, és pont a hibás OSD-n van olyan adat, amiből csak 1 példány van, akkor már meg is van a baj. Ráadásul ha nagyon nagyok az OSD-k, akkor sokkal tovább is tart, mire a rendszer helyre áll, és több idő alatt nagyon az esélye egy újabb hiában (ráadáusul a self healing azért elég strapás a rendszernek ahogy olvasom - éles tapasztalatom még nincs).

Azért nem gondolkodtam EC-ben (ami sokkal takarékosabb a tárhellyel), mert ahhoz a 4 node nagyon kevés, ugyanis ott is tartanám a minimum 2 OSD/node hibatűrési szintet, amihet kapásból dupla ennyi node kellene.

 

Természetesen ha az egészet vagy részét nem jól írtam/értelmeztem a leiratokból, akkor a hozzáértőket kérem javítsatok ki, hogy mást ne vezessek félre, és tanulhassak belőle.

Én ehhez csak annyit tennék hozzá, hogy a CEPH replikáció az nem backup.
Simán lehet pl egy elrontott pg repairrel inkonzisztenciát gyártani, és ez ilyenkor nyilván sok objectet érint, ha rbd-t is használsz, akkor pedig egy ilyen után sok block device-ban lesznek hibás chunkok, ezt rémálom javítani.
 

Nyilván! Erre elfelejtettem kitérni, de jogos és fontos kérdés. Én úgy tekintek a Ceph tárolóra, mint egy sima szerver sima diszkjére ilyen szempontból. A (nekem legjobban bevált) 3-2-1 backupnak Ceph esetén is meg kell lennie.

De ha a rendszer minél több hibát tud elviselni működőképesen és konzisztensen, annál kevésbé kell a (jellemzően lassú) backup-ból visszaálláshoz folyamodni, és annál kevesebb lesz az offline töltött idő.

"Az éles rendszert szeretném ha működőképes maradna 2 tökéletesen működő node esetén (tehát 2 node teljesen jó, és rajtuk az összes OSD)."

Na ez megint necces lesz.

4 node 3/2-ben az azt jelenti, ha lekapcsolsz (vagy alaplap hibás lesz) 2db nodeot, akkor pg-k 33%nál a két másolat azokon a node-okon lesz ami épp áll...  tehát nem fogsz működni.

Működni 4/2-nél fogsz, mert ott valóban kieshet 2 node a 4-ből.

 

szerk.: ha 1 node esik ki, de van ideje a clusternek rebalance-olni, akkor természetesen kieshet a 2. is. (Csak hát azt néhány napot végig kell izgulni..  :-))) )

Ez teljesen jogos! Mondjuk ha 1 node kiesése után a rendszer helyreáll 3 node-dal, és akkor esik ki OSD, akkor működik tovább (de már több hibának nincs helye...). Ha a helyreállás közben esik ki OSD, akkor nagy eséllyel ez a megállás bekövetkezhet. De akkor csak a 4/2 a biztos megoldás, hogy 1 node kiesés és ezen felül egy teszőleges OSD kiesés biztos ne járjon (VM) leállással?

4 node, 8x 1.92TB SSD 3/2 esetén a "safe capacity" 3480 GB, 4/2 esetén már csak 2610 GB. Az azért eléggé kevés a 13920 GB nyers tárterületből.

Lehet bármi más értelmes verzió 4 node esetén, ami nem bánik ennyire pazarlóan a kapacitással, de a fenti meghibásodást biztosan tűri?

Elméletileg, vagy gyakorlatilag? Én gyakorlatban nem építenék páros számú node-ból clustert, akkor már 3 node és az árból több kis SSD. pl nodeonkén 6db 1T-s. Itt SSD hiba esetén többfelé tudja a rendszer szétszórni az adatokat. Ráadásul 3nodenál még lehet értelmes mesh hálót csinálni és akkor a hálózati eszköz kiesésével sem kell számolni.

De egy komplett node leállása esetén sem fogsz állni, hisz 2 node-dal még megy a rendszer. Ha meg látod, hogy áll akkor meg hajrá-hajrá gyerünk cserélni. Azért reálisan a HDD/SSD-k nagyobb eséllyel pusztulnak meg mint maga a node.

Már tudom, hogy nem igazán praktikus, de a páros számú node már adott, meg a benne lévő SSD-k és HDD-k is. A HDD-ket sajna nem tudjuk elfogadható bukóval SSD-re konvertálni, de a jövőbeni fejlesztésnél már csak SSD-k kerülnek majd be. Így a fizikai felálláson érdemben változtatni már nem tudok.

A hálózat is már adott, 2 db 10 GbE switch megvan, elsősorban azért már az elején, hogy ha újabb node áll majd be idővel, akkor a (remélhetőleg már élesben működő) rendszert ne kelljen alapjaiban átvariálni a bővítés miatt.

De a 4/2-es replikációt megfontolom, hogy 1 node + 1 OSD elvesztése miatt ne legyen read-only a tároló.

Red Hat-ék dobták:

The RADOS-level cache tiering feature has been deprecated. The feature does not provide any performance improvements for most Ceph workloads and introduces stability issues to the cluster when activated.

Alternative cache options will be provided by using the dm-cache feature in future versions of Red Hat Ceph Storage.

És mivel kb. java részét ők tolják be a kódnak, ezt ők nem fejlesztik, más se nagyon.

Én is olvastam már, hogy a Luminous után már nem javasolt a cache tier Ceph szinten. Ha mégis cache-re van szükség (használata segít bizonyos fajta terheléseknél), akkor néhány féle LVM cache megoldás közül lehet választani. De ilyen bonyolításba már nem mennék bele, szerintem nekem nem hozna semmit, csak plusz komplexitást.

A HDD-k mellett van M.2-es NVMe SSD RocksDB/WAL céljából (igaz, nem enterprise kategória, mert olyant nem találtunk értelmes áron, kis méretben), egyenlőre a 2 db HDD 1-1 50GB-os szeletet kap az M.2-ből (tudom, 30 GB elég lenne, vagy 300 GB a következő hasznos lépcső, de annyi már nem telik ki per HDD).

4 node-dal hogyan? Nem merültem bele még nagyon, de nem k=2 és m=2 kellene legyen, és 50% szabad hely a vége? Vagy lehet ha jobban elolvasnám, akkor 4 node esetén nem lehet m=2-vel működni sehogyan sem, az egyszeres hibatűrés meg olyan lenne kb., mint a 3/1-es vagy 2/1-es replikáció.

De több helyen olvasom, hogy nagyságrendekkel rosszabb a teljesítménye, mint a replikált verziónak, VM-ek alá nem javasolja senki, csak nagy mennyiségű, nem IOPS kritikus adat alá. De ahhoz meg kevés a 4 node és a node-onként 2 OSD szerintem.

És még valami, szegény Ceph elosztási algoritmusa néha elég vicces. Most épp azon küzdök, hogy a nodeban lévő 8 HDD-nál 5. rebalance után is az egyik HDD 60%on van a másik meg 85%-on...

Ezzel csak azt akarom mondani, hogy a tárhelyet bőven számold túl...

 

ui.: és a legszebb hogy 85%-nál kapott új HDD-t hogy legyen hely, épp most rakosgatja a dolgait, de az az OSD már 88%-on van, szóval még csak véletlenül sem annak az tehermentesítésével  kezdett...

Tudom, de hiába van, ha a sokadik rebalance UTÁN az OSD.11 1 reweight érték mellett 59%-os telítettségen van, az OSD.17 a 0,94-es reweight-nél meg 83%-on.

Ja és mindehhez az OSD.16 nearfull, aminek a telítettsége 81%, tehát kevesebb mint a OSD.17 a 83%os telítettsége. (minden node és HDD egyforma).

Szóval néha nehéz követni mit miért csinál.

Mindazon által nyugodtabban alszok, mióta használjuk.

( NagyZ v | 2020. 08. 28., p - 11:44 )

fent eleg jol leirtak hogy miert ne futtasson senki min_size=1-es clustert; en ket dolgot szeretnek hozzatenni, mert ugy latom ebben tobben tevednek fent:

- ugyan a beallitas a poolon van, ez nem a poolon van ervenyesitve, hanem PG szinten, igy siman lehet irhato PG is akkor ha meghalt egy diszk azutan hogy egy nodeot kivettel, mikozben egy masik PG meg be van allva mint a szog

- amint kiesik az osd egy pgbol (down + grace period) utana a pg kap egy ideiglenes HDD assignt, es mar nem [a,b,c] lesz benne, hanem mondjuk [a,b, c, tmp1], ideiglenesen, igy _uj adat_ irasakor sincs megallas (hiszen ha ketto pukkan el akkor [a, b, c, tmp1, tmp2] lesz benne), csak meglevo adat felulirasakor IMHO

ha ki van kapcsolva minden onjavitasi beallitas akkor nyilvan nem fog ez megtortenni, es akkor az iras is beallhat a PGn mint a szog, ahogy fent irtam

Akkor ha jól értem, a 4 node esetén 3/2-vel futó pool (PG) egy node kivétele, majd (self heal előtt) 1 OSD elvesztése esetén sem 100%, hogy minden VM leáll, mert nem tud írni.

Mi úgy számoltuk, hogy node hardver hiba miatt elég ritkán fog kiesni, mert rendes szerver hardver esetén szóló üzemben sem jellemző az ilyen megállás. Diszk hiba valószínű sokkal gyakrabban lesz, de arra sem heti/havi rendszerességgel számítunk ilyen kis darabszámok mellett.

Az itt összeszedett információk alapján én jelenleg elfogadható rendelkezésre állásnak látom a 4 host, size 3/2 pool felállást akkor. Pláne úgy, hogy ez a majdani rendszer egy szóló szerver helyére kerül, amivel eddig nem volt igazán sok gond hardver megállás téren. Szoftverrel sokkal többet bénáztunk amiből leállás volt... :-)

Még egy kérdés: jól gondolom, hogy ha 5 node lenne, és ugyan úgy size 3/2 esetén, 1 node + 1 OSD elveszítés esetben semmivel nem lenne jobb a helyzet, mint 4 node esetén? Mert 5 node esetén is a 3 példányból kieshet kettő (1 a kieső node-on és 1 a kieső OSD-n), és akkor az a PG átmenetileg min_size alatt lesz, ergo nem írható addig, amíg a self heal legalább még egy példányt létre nem hoz működő OSD-n (gondolom ez alatt az idő alatt vagy megáll vagy hibázik az érintett VM).
Az ilyen esetekre való készülést (igazából pool tervezést) hol lehet úgy elolvasni, hogy halandó is megértse belőle a szempontokat és lehetőségeket, és tudjon olyan beállítást gyártani, ami ezt az esetet megoldja biztosan? Vagy ez csak a gyakolat + az előforduló esetek alapos/részletes átgondolása?

mi 2 geppel, 2xes replikacioval indultunk, min_size=1-el. mai fejjel mar nem csinalnam, de ez meg az osidokben volt (szerintem mienk volt az egyik elso ceph cluster svajcban).

a kerdes az, hogy definialjuk az elvesztest: ha egy gep kiesik, akkor amint lejar a grace period (300 sec altalaban) a PG ki lesz bovitve [a,b,c]-rol [a,b,c(halott),d]-re, es elkezd az adat szepen atmozogni d-re ami a c-n lenne. HDDn ez nyilvan tovabb tart, mint SSD eseten. ha e kozben elhal egy diszked, akkor sincs gond, mert ahogy irtam, [a,b,c(halott),d]-rol [a,b(halott),c(halott),d,e] lesz, es maris tud irni a+e-re.

tehat abban az esetre ha veletlen halnak el komponensek akkor a rendelkezesre allas sosem serul, a cluster elerheto lesz folyamatosan.

 

remelem igy mar tisztabb!

Picit igen, mert az nem rémlett, hogy image szinten garantálni kéne, hogy az összes OSD részt vegyen benne. Mert ez ugye azt is jelenti, hogy indulóban felvett probléma esetén annak ellenére, hogy csak néhány PG érintett, mégis MINDEN imagenek lesz read only része. (Persze ha mázlim van,akkor pont az a része amit épp nem piszkál a rendszer.)

Ennél biztonság szempontjából lehet hatékonyabb lenne, ha nem akarná az összes OSD-t bevonni, teljesítmény szempontból most sem garantálható, hogy egyformán használja az OSD-ket, csak az, hogy hiba esetén mindenkit értint.