HA Storage Cluster webkiszolgáláshoz

Linux-haladó

Sziasztok!

Storage megoldást keresek 2 egyidőben futó webszerver kiszolgálásához. Sarkítva: 1 mappa egyszerre 2 helyen van jelen, 2 helyről olvasható, esetleg 2 helyről írható, bár ez nem feltétel.

Jelenlegi állapot: 2 node, mindkét node-on drbd adja a közös diszket, ezen ocfs adja a közös fájlrendszert. Az egész debian aktuális stabil kiadása alól megy.
Az elmúlt 10 évben egész stabilan ment, leszámítva 3-4 évente egy-egy drbd széthullást és split-brain állapotot.
Az utóbbi időben viszont vállalhatatlanul instabillá vált. A drbd még talán stabil, de az ocfs mostanában nem áll össze, ha összeáll, fél nap alatt beragadnak az I/O-k. Egyik lockolja a másikat. Csak a reboot segít. Korábban belefutottunk kernel frissítés után rejtélyes ocfs bugba, downgrade segített.

Ezzel kellene valamit kezdeni vagy teljesen más technológiára áttérni. Így azért nehezen vállalható.

A cél: egyszerre 2-3 webszerver elérje a fájlokat. Ha csak az egyik webszerver írhatja a fájlrendszert, nem gond. Proxyból megoldható, hogy az írásműveletet végző admint csak dedikált webszerver szolgálja ki.

Ötletek:

1. dobozos storage, ami a fekete dobozon belül minden redundanciát megold, NFS-t ad. Probléma, hogy a régi használt hálózati storage-k még nem tudnak NFS-t (beszállító partner szerint), az újak amik tudják ezt, aránytalanul drágák a projekthez mérve. A keret kb 0.5-1M Ft diszkek nélkül.

2. DRBD marad, de OCFS repül és GFS-re váltunk. Kérdés, aki használja, mi a tapasztalat? Ezek azért nem a tömeg "termékek". Kevés róla az olvasható tapasztalat. Nem szeretnénk egy döcögő projektre váltani.

Hogy csinálják nagyvállalati környezetben, ahol több webszerver szolgál ki egy időben azonos tartalmakat? Drága storage + NFS? Nekem már maga az NFS is egyfajta visszalépésnek tűnik, de perpill nincs az ismereteim között jobb ötlet.

  • 745 megtekintés

( andrej_ v | 2022. 02. 13., v – 11:16 )

Ha nincs MySQL, vagy egyéb adatbázis, amit szinkronban kell tartani, akkor legyen egy "admin" node ahol feltöltesz és onnan rsync-kel szétszorod a file-okat időnként. Ezt több megoldásban használtuk már, és egyszerű, de nagyszerűnek bizonyult.

Rsync nekem is eszembe jutott, de az még az NFS-nél is "parasztosabb" megoldásnak tűnt, bár én is azt találom a legbiztosabbnak. Köszönöm a megerősítést :)
Azért várok még ötleteket. Tényleg kíváncsi vagyok, a szakma mit szokott ilyenkor alkalmazni. Kicsit feketöves témának érzem, kevés a hal ebben a tóban :)

Oké, nézzük az rsync megoldást. Hogy oldanád meg a szinkronban tartást mondjuk 300GByte media tartalomnál? 5 percenként rsync, ami 5 percenként átnyálazza a mappa struktúrát mindkét oldalon és megnézi, hogy hol van diff? Elég erőforrás igényesnek tűnik. Van esetleg trükk, hogy 5 percen belüli változásokat figyeljen és hagyja békén a túloldalt diff után kutatva?

Meg ugye az 5 perc is sok lehet, ha a felettes proxy pont a második node-ra küldi a kérést, ahol még nincs ott a tartalom, akkor 404-t dob a webszerver.

Másik ötlet: inotify -vel összekötni valahogy, legalább közel real-time lenne.

Ti hogy szoktátok megoldani?

Ahol rsynceltunk ott napi nehany, GB koruli file frissult. Felpakoltak elore, vagy elesitettek elore, es akkor napi nehany alkalommal felnyalta az rsync. A felhasznalok tudtak, hogy X idoben, idonkent fut, es ehhez kepest tudtak szervezodni. Ha olyan volt, akkor kezzel rasegitettunk, de nagyon ritkan. Persze ez az igenyekre volt szabva, es megfelelt a faek egyszeruseg. Ha azonnal mindenkepp frissulni kell, akkor van rsyncd, illetve akinel ez kell az ajanlotta az lsyncet.

( ggallo | 2022. 02. 13., v – 11:37 )

A vázolt helyzetre szerintem egy használt szerverből épített NAS (pl. Dell R720XD vagy R730-ból) és rá egy TrueNAS Core lehet egy megoldás. Ez simán megvan diszkekkel is a jelzett keretből. NFS-en kiajánlod amit szeretnél, és aránylag költséghatékonyan van osztott tárterületed. Nekem eddig nagyon jó tapasztalataim vannak TrueNAS-sal (FreeNAS 8 néven futott még, amikortól használom).

Mondanám, hogy Ceph és azon CephFS, de két node esetén nagyon nem szerencsés (nem is ajánlott), és 6-7 node alatt eléggé tárhely pazarló a replikáció alapú redundancia (nekünk 4 node-on fut Ceph).

Egyébként mi a felhasználási terület, hogy azonos tartalmat több webszervernek kell elérnie? Valami load balancer mögötti nagyobb teljesítményű kiszolgálás?

NFS-hez egy alap debian is elég. Érdekességképp: futtatok egy HP microserver gen 10-en, 30TB raid 5, fele foglalt, vm backup image-k keletkeznek rajta több proxmox szerver által, 181Mbyte rendszermemóriát foglal :)

Na de ez most komolyabb dolog. A fent vázolt NAS-os megoldás sajnos nem ad redundáns storage-t. Egy gépből nem gond megoldani, de ha megáll, baj van. Ezért muszáj valahogy redundánssá tenni az adatok prezentálását is.

Ceph-t én is nagy falatnak érzem ide, max 3 gép lenne hadrendbe állítva.
Igen, load balancer mögötti nagyobb teljesítményű kiszolgálás az egyik indok, a másik pedig a kiesés mentesség meghibásodás/karbantartás idejére is.

3 gépen már remekül lehet Ceph-et használni! De 3/2 replikációnál (ilyenkor 2 géppel még írható marad a pool és marad redundancia, aztán 1 gépnél vált read-only módba) elbukod a beépített tárkapacitás 2/3-át. Cserébe maximálisan szinkronban van minden és igazi HA tároló megoldásod lesz. Az mondjuk igaz, hogy érdemes 10G kapcsolatra ültetni úgy a replikációs mint a publikus hálózatát. De ez manapság már nem annyira drága, hogy ne lehetne meglépni. Nekünk rezes 10G-n megy a 4 host-os Proxmox cluster Ceph tárolással, egyenlőre jól teljesít.

Ha ilyen komoly igény van HA-ra, akkor csak a HA-nak szánt megoldások jöhetnek szóba (minden más nem lesz HA valójában, csak jobban érzi magát tőle az ember amíg nincs baj).

Esetleg nézhetnétek használt storage eszközt. Aránylag olcsón (a megjelölet keretbe beleférősen) szokott lenni Dell ez-az, dual controller kivitelben, általában iSCSI, FC és SAS csatolóval is egyaránt fellelhető ilyesmi. Egy olyan azért eléggé komoly redundanciát ad, lehet annyi elég is lenne számotokra.

( GhostPunk | 2022. 02. 13., v – 13:56 )

Muszaj FS szinten elerned a fajlokat, object storage(pl minio) nem johet szoba?

S3 API amivel ismerkedni akarsz akkor. A kerdes, hogy az alkalmazas ami kezeli a fajlok feltolteset tudja-e ezt hasznalni, ahelyett, hogy local FS-re irogat. Ha sajat alkalmazas, akkor szolsz a fejlesztonek es megoldja par ora/nap alatt, ha nem sajat, akkor marad a remeny, de manapsag azert eleg standard.

A minio ezt az S3 API-t adja neked kifele, a fajlok replikalasat pedig megoldja (ha ugy allitod be), ezt nyered vele. Utana mar csak egy HTTP(S) endpointot kell HA-va tenned, erre van millio megoldas, de mind sokkal egyszerubb mint amivel eddig szivtal.

( tompos v | 2022. 02. 13., v – 14:17 )

Fuggoen a peremfeltetelektol:

- glusterfs: ha nincs csillio sok file (szinte tuti igaz) es posix jellegu fs kell

- rsync: ha posix eleres kell es OK, ha a fo node elszall, akkor manualis a megoldo process (mit neked kell kitalalni), nincs csillio sok file es OK az async mukodik

- lsync: ld. rsync, csak meg kevesebb file, cserebe sokkal kozelebb a real-time mukodeshez

- web api jellegu eleres (S3, mogilefs, mongodb): ha nem akarod szopatni magad replikacioval, plane nem mountpointtal

 

Valoszinutlen, h a felvazolt parameterek alapjan a nagyvallalati megoldasokat akarod mintanak venni, tevutra fog vinni.

( jenkara | 2022. 02. 13., v – 15:57 )

Nagyon gyorsan elhalt a TrueNas otlet, pedig reszemrol +1

Illetve kiegeszitenem valami zfs alapu tarolas + syncoid otletenek bedobasaval.

Illetve... regebbe, amikor rsync-et nezegettem hasonlo indittatasbol, akkor ratalaltam valami scriptre(?) -sajnos mar nincs meg csak az emlekezete- ami tobb szalon rsync-elt. Ezzel gyorsitotta a folyamatot. (Ha ratalalok, bekulodom a linket.)

TrueNas jöhet, ha tudsz clusterben futni. Ezt talátlam, érdemes vele foglalkozni? https://www.truenas.com/docs/truecommand/clustering/

syncoid új, megnézem.

Csupa hasznos kulcsszó, ami ha más nem, máskor jól jöhet. Köszönet érte mindenkinek! :)

Érdemes lenne ránézned akkor a TrueNAS SCALE verzióra. Most 02.22-én jelenik meg az első GA kiadása (több év fejlesztés és eléggé sok tesztelés után, szóval nem fog megállni a prodiction-ready kiadás, ha ezt választjátok), FreeBSD helyett Debian alapú, az ingyenes verzióban is támogat cluster építést. Érdemes lehet tesztelni vele egyet.

"'Sima" TrueNAS Core esetében ZFS replikációt ajánlanék, ami ugye blokk szintű, nem file szintű (nagyságrendekkel gyorsabb és megbízhatóbb véleményem szerint mint bármilyen file alapú sync megoldás), és eléggé gyakorira (pár perc) is lehet ütemezni. Igaz, itt még mindig van időablak a két példány között, nem igazi HA megoldás.

( Vizibirka | 2022. 02. 13., v – 17:45 )

Mivel volt itt mar CEPH és hát az sem egy egyszerű jószág, ezért kövezzetek meg érte, de leírom : Windows Storage Spaces.
Tud rendes HA storage cluster-t és iSCSI vagy SMB amin el lehet érni. 
Nyilván az egyik block device a másik meg fájl alapú.

De ehhez kell egy csomó licenc csilliárt pénzért, nem?

Alapból bármilyen Windows HA csak AD-vel van, azt meg illik külön gépen futtatni (legalább kettőn, hogy az is HA legyen), így mindjárt 3-4 Windows Server licenc mind a megfelelő magszámra, és ez csak a kezdet. Ez azért jelentőset dob a költségvetésen, figyelembe kell venni.

( hackac | 2022. 02. 13., v – 18:08 )

A NAS felvetést tovább cizellálva: 2 Synology NAS? Nem kell reszelni kézzel, a méretezés meg teljesítmény igény szerint. Ha számít az energia felhasználás is, hosszú távon nem feltétlenül drágább.

( zsolt | 2022. 02. 13., v – 18:12 )

Szerkesztve: 2022. 02. 13., v – 19:15

-

( _Franko_ v | 2022. 02. 13., v – 18:52 )

Ha nem számít nagyon a sebesség, akkor tudom ajánlani a GlusterFS-t, több helyen stabilan használom, teljesen gondozásmentes, nagyjából SPOF mentes. Csak lassú.

https://iotguru.cloud

Is-is. De nem a sávszélesség a baj, hanem a latency, amíg három példányban kiírja vagy elkéri egy másik host-ról azt a fájltöredéket, ami nincs meg nála; és a CPU igény.

Ilyen a fizikai storage egy-egy node-on:

# dd if=/dev/zero of=test count=1024 ibs=1M
1024+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.78414 s, 186 MB/s
# dd if=test of=/dev/null count=1024 ibs=1M
1024+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.13032 s, 504 MB/s

És ezt tudja a GlusterFS, három replikával:

# dd if=/dev/zero of=test count=1024 ibs=1M
1024+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 213.888 s, 5.0 MB/s
# dd if=test of=/dev/null count=1024 ibs=1M
1024+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 16.424 s, 65.4 MB/s

Vannak praktikák a javítására, de nem foglalkoztam vele, amire kell, arra bőven jó ez is így.

https://iotguru.cloud

Egyszer tervezem kipróbálni,  de közben azt látom a neten másoknál is, amit mértél, illetev ugyanezt  CEPH-nél is. Tippre azt mondanám, a "sima"ssd-k szinkron irása kb ennyi, ezt "tuningolják át" nem szinkronra, látok 30 MB/sec -et leírásokban (VM optimalizált).

https://blog.claryel.hu

Érdekesség képpen Proxmox/Ceph környzetben (kb. 30 futó VM, nem nagy terheléssel), a GlusterFS-es mintához viszonyítás miatt:

SSD OSD-n futó VM-ben mérve:

# dd if=/dev/zero of=test count=1024 ibs=1M
1024+0 beolvasott rekord
2097152+0 kiírt rekord
1073741824 bájt (1,1 GB, 1,0 GiB) másolva, 5,28791 s, 203 MB/s
# dd if=test of=/dev/null count=1024 ibs=1M
1024+0 beolvasott rekord
2097152+0 kiírt rekord
1073741824 bájt (1,1 GB, 1,0 GiB) másolva, 1,63944 s, 655 MB/s

HDD OSD-n futó VM-ben mérve:

# dd if=/dev/zero of=test count=1024 ibs=1M
1024+0 beolvasott rekord
2097152+0 kiírt rekord
1073741824 bájt (1,1 GB, 1,0 GiB) másolva, 5,62777 s, 191 MB/s
# dd if=test of=/dev/null count=1024 ibs=1M
1024+0 beolvasott rekord
2097152+0 kiírt rekord
1073741824 bájt (1,1 GB, 1,0 GiB) másolva, 4,6494 s, 231 MB/s

4 node, 3/2 replikáció, 10 GbE rezes hálózat van a Ceph-nek.

Írásra vagy olvasásra is? Az OCFS2 is lassú volt írásra, főleg törlésre, mert a túloldallal le kellett egyeztetnie mindent. Ha attól nem lassabb, jó lesz, köszi a felvetést.
mod: mi 3x1G-s linken használtuk bondingban, ami redudanciát adott, tempó többletet nem, mivel ugyanazok a párok.

( gabrielakos v | 2022. 02. 13., v – 21:39 )

Ez így elég kevés infó ahhoz, hogy jó választ lehessen adni.

Az eddigiek mellé felvetném még a caching opciót (pl. varnish), ekkor a szinkronizációval sem kell vesződni, "csak" a TTL-eket kell jól belőni.

zászló, zászló, szív

( Sixday v | 2022. 02. 13., v – 21:50 )

Szerkesztve: 2022. 02. 13., v – 21:53

GlusterFS lesz a te baratod. Ugyanerre hasznaltuk, kb. 10 db webszerver volt osszekotve, mind irt/olvasott, tokeletesen mukodott, sose volt vele baj, node kieseseket is toleralta, stb.

Semmilyen extra kulso device nem kell hozza, csak beszorod az ssd-ket a webszerverekbe es kesz. Raid se kell, megoldja azt is brick replication-el, ezen is csomo penzt lehet sporolni. 

NFS GlusterFS-hez kepest egy kokorszaki vacak, neki se allj, felesleges.

( egeresz | 2022. 02. 14., h – 18:02 )

Stabilitás, sebesség, funkcionalitás. Válasz körültekintően egyetlen egyet.

 

Sebesség mind felett:

HA a módosítás (upload) nagyságrendekkel kisebb az olvasásnál (download) AKKOR a webszerveren legyen lokális diszk, azon lokális filesystem (XFS, EXT4, ZFS bánomisén), az upload szerveren valami userspace cucc, ami átmozgatja a download webszerverekre. Például rsync és társai. ==> bármeddig skálázható a teljesítmény. Ez egy jól bevált, követhető és kezelhető dolog. A legszebb úgy megcsinálni, ha az admin (upload) program tudja egyből a download webszerverek felé teríteni, webdav, rsync, scp, bármi lehet. Kissé munkás az ideiglenesen kiesett webszerver visszaillesztése a munkába. Legjobb, ha az upload webszerver logot ír a változásokról.

Ebben az árkategóriában nem nagyon van más.

Ha másik gépről NFS -t adsz, akkor a DISZK -> NFS -> HTTP download megöli a sebességét, az NFS nagyon csapnivaló lokális FS-hez képest. Lehetne azzal játszani, hogy a fő HTTP download szerver adja hátra az NFS-t az upload szervernek, de ekkor nem lehet több HTTP download szerver. (bár egynek jó lesz a sebessége, de a többinek nem.)

Lehet ceph/ocfs/glusterfs dologgal játszani, ezeknek nagyon szép a funkcionalitásuk. Azonban ELVILEG sem lehetnek gyorsak, a több szerveres erőforráskezelés disztributív lockot feltételez, bizonyos metaadatműveletnél (cache validáció, metaadat-modify) kénytelen körbekérdezni, vagy egy mastertól kérdezni. Ezek közös jellegzetessége, hogy szélsőséges helyzetekben (betelt filesystem vagy erős terhelés) kezdenek extrém rosszul viselkedni. A drbd sajnálatosan nem barrier-proof, nem lehet elvárni tőle, hogy a felette lévő filesystem egyszerre legyen stabil és gyors. Vagy hogy egyáltalán stabil legyen.

Ha a terhelés lényegi részét a módosítás (upload) teszi ki, akkor ez egy elég nehéz helyzet. Gyakorlatilag nem lehet általánosan jól skálázni, legfeljebb akkor, ha valami algoritmussal osztható az adat, központi vezérlő gép nélkül.

 

Végül is, ha van 10k file 100GB, akkor mindegy mit csinálsz, jó lesz. Ha van 100M file, 100TB méretben, akkor nagyon oda kell figyelni, hogy egyáltalán működjön.

(reklám) azért megoldjuk 1000M file, 1PB méretben is a webszeveredet, de határozottan nem az 1-2M Ft nagyságrend. (/reklám)