Tárhelyoptimalizálás - ötletelés

Van két site, mindkét helyen két-két fizikai gép, gépenként másfél TiB diszk (ssd), ami most egy plusz fél felosztásban működik, a kisebbikre megy a mentés, ami rsync-kel van a két site között szinkronizálva, a nagyobbik területen megy egy replikált DB fürt dolgozik.
Lassan kezd elfogyni a mentési terület, úgyhogy azon kezdtem el gondolkodni, hogy a négy gépen rendelkezésre álló mentési területből kéne egy hálózatos repliklát tárterületet csinálni, site és host szintű redundanciával.
 

Relative nem sok fájl, (párszáz darab) méretben  az átlag valahol 10-20MB között lehet, úgyhogy inkább a folyamatos írási sebességre lenne célszerű kihegyezni, ha jól gondolom. (Ha mentésből kellene visszaállni, akkor kisebb gond is nagyobb lenne annál, hogy a restore esetleg x perccel tovább fut...)

A "történelem előtti időkben" a drbd-t vettem volna elő, igaz drbd-ből raid10-et csinálni kifejezetten perverz dolognak tűnik :-) ergo ezen a szinten illendően túllépve ceph kontra gluster maradt (egyelőre, ha nem lesz jobb ötlet) - a kérdés az, hogy az, akinek ezekkel van tapasztalata, hajlandó-e megörvendeztetni pro és kontra érvekkel, egyik vagy másik mellett avagy ellenében.

Az OS RHEL7, RAM, illetve CPU nem azt mondom, hogy rogyásig, de van, úgyhogy az írási sebesség, megbízhatóság, hibatűrés, kezelhetőség fontosabb paraméterek. Ja, a gépek 10G-n beszélgetnek  egymással, a site-ok között is Gbit-es sávszél áll rendelkezésre. Az 1TiB - 500GiB felosztás is "tologatható", ha szükséges.

Szóval ötleteket, gyakorlati tapasztalatokat várok elosztott fájlrendszerrel kapcsolatban. Köszönöm.

( tompos v | 2020. 12. 25., p – 22:31 )

Mitol fogja ez kivaltani a backup-ot?

Azt ertem, h bovited a prod kornyezetet. De mi fogja elladni a backupot?

 

Vennek bele diszket. Vagy ha muszaj, optimalizalnam a mentest, ahol lehet, pl. zfs+compression.

Vagy kimaradt vmi info, pl. h nincs szukseg a backup-ra.

 

t

A backup marad, csak a most négy gépre szétszórt tárterületet szeretném egyben látni, és arra megy majd a mentés. Diszket venni bele azért nem olyan egyszerű - egyrészt, mert mind a négy gép fullra van pakolva, azaz a meglévő ki/új vissza működne, ami 32 darab ssd cseréjét jelentené,  miközben a működéshez és mentéshez szükséges tárterület a jelenlegi környezetben is rendelkezésre áll. (Most backup helyben, ~500GB, rsync a másik site-ra, amit ki akarok váltani "4x500+GB összefogva egybe" területre mentéssel.)
 

Hogyan megy arra a mentes is, ha azon a production is fut?

Lehet, h most 32 db SSD, de az ujak mar nem lennenek annyian, hisz ami most 1TB, azt meg tudod oldani az X db helyett mar pl. 2x2TB-tal is. Ha nagyvonaluan szamolunk, akkor is 8x2TB SSD-rol van szo.

 

A comment tobbit reszet nem ertem, nem ertem a topologiat. A hozzaszolasok szamabol itelve talan masok sem.

Darabra lehet, hogy kijönne a kevesebb ssd, de nem minden raid-level esetében.
Több lépésben történik a mentés, kifejezetten azért, hogy a tényleges prod. rendszert minél rövidebb ideig terhelje. Azaz első lépésben helyben készül egy mentés (gyakorlatilag másolat a fájlokról), és ezt követően kerül ez a másolat a másodlagos site-on lévő gépre, illetve a tényleges offline/offsite mentést készítő szerverre át.

"nem ertem a topologiat"

Négy egyforma gép: srv1.pdc, srv2.pdc au egyik gépteremben, srv3.bdc, srv4.bdc a másikban. Gépek között 10G, két site között sötétszál, szükség szerint sok csigabittel.
Ez a négy gép egy DB-szerver fürt (is), és mindegyiken van ~500GB terület, amire _jelenleg_ még elfér a teljes DB mentése (azaz a backup mérete <500GB). A mentés az egyik gépen helyben fut le, és az oda lerakott fájlok kerülnek át a másik site (pdc->bdc) valamelyik gépére - így a site-szintű redindancia megoldott. Ez a mentés kerül később offline/offsite szerveren tárolásra (VTL, illetve szalag), de ez a része lényegtelen.

A cél az, hogy négy szerveren, mentési jellegű terhelésre (azaz néhányszáz fájl, szumma ~500GB, ami 6-700GB fölé várhatóan nem fog menni a rendszer életciklusa alatt) ki kéne alakítani egy osztott, közös fájlrendszert úgy, hogy ami oda kiírásra kerül, az bármelyik site vagy szerver elvesztése esetén is használható maradjon.

Szóval 4x500GB-ból írásra optimális tárterületként ceph, gluster vagy más?

A "miért készül a mentés első példánya helyben"-re több, kifejezetten nem publikus válasz is van, de épp emiatt nem fogom részletezni. Az adott fürt az infrastruktúra olyan szeletében van egyébként, hogy ha oda bejut egy támadó, akkor az ott elkövetett károkozása lesz a legkisebb probléma. Ez az egyik.
A másik, hogy mindenkor legalább két korábbi teljes mentés és a régebbi állapot óta keletkező változások (ezek gyakorlatilag pár másodpercenként) átkerülnek az offline/offsite mentéseket kezelő szerverre, azaz bármikor vissza lehet állni a kettővel korábbi teljes mentés óta eltelt időszak kvázi bármelyik pillanatára, úgyhogy ha épp a helyben gyorsan összerakott mentési fájlkészlet készítése után, de annak az offsite/offline mentéseket tartalmazó gépre másolása előtt bombázza le valaki a cluster mind a négy kiszolgálóját, akkor is előállítható egy, a katasztrófa előtti, elvártnál nem nagyobb adatvesztéssel járó állapot. Amikor meg a helyben készült fájkészlet átkerül az offsite/offline mentőszerverre, akkor (és csak akkor) történik meg ott az egyel korábbi mentést megelőző változások és teljes mentés(ek) kitakarítása.