1 PB adat tárolása

Linux-haladó

Sziasztok,

Egy projekt kapcsán felmerült, hogy 1 PB adatot miképpen lehetne tárolni. Nyilván lehetne ekkor storage-t vásárolni, esetleg Ceph (esetleg DRBD) clustert építeni. Nektek melyikkel van tapasztalatotok? DRBD-vel, storage-gal foglalkoztam de körülbelül ennek tized méretében. Ti mit ajánlatátok? Miket nézzek meg, próbáljak ki?

A rendszer kimenete végső soron Samba megosztás is lehet, Windowsból kell látni. A területeknek nem kell feltétlenül egyben lennie, több mérés fájljairől van szó, amelyek magukban egységek és néhány x 100 GB nagyságú (300 GB a max/egy mérés). Az adatokhoz gyors hozzáférés kellene, míg a feldolgozás fut rajtuk, ez akár 1-10 GB/s sebességet is jelenthet. Párhuzamosan 5-10 helyi gép vagy virtuális gép férne hozzá az adatokhoz. Gépenként jó lenne az adatátvitel sebességét 200MB/s körül tartani, de még 500 MB/s sebesség esetén sem volt a CPU a szűk keresztmetszet (ezt flash storage-n teszteltem). Ezek adatmozgása nem mindig egyforma, a feldolgozás elején inkább olvasnak, olvasnak, majd inkább az írás válik jellemzővé. A fájlok mérete 1-100 MB általában, de így is viszonylag sok van belőlük. Később lassabban is elérhető, de akkor is hirtelen kell az egész 300 GB-os projekt.

Előre is köszönöm!

KAMI

  • 3341 megtekintés

( szs v | 2015. 02. 06., p – 11:37 )

mekkora iops kell?
szalag?
dedupolható?

( szekelyk | 2015. 02. 06., p – 11:44 )

EMC Isilon Scale-out NAS, ha NAS megfelel 1G vagy 10G Ethernet. A teljes 1PB-t egy fájlrendszerben látod, NFS,SMB, és egyéb protokollokat beszél. 30+PB-ig skálázható. A teljesítmény igényeknek megfelelően többféle model áll rendelkezésre, ezek egy rendszeren (cluster) belül keverhetők is. Az eltérő modellek CPU, RAM, és diszk konfigurációban térnek el (SSD, SAS, NL-SAS).
Gyakorlatilag független x86 node-ok alkotják, infiniband összeköttetéssel kommunikálnak. Az alapja FreeBSD, de nyilván gyártói szoftverréteg biztosítja a funkcionalitást.
Ha érdekes lehet keress meg magánban.

( htmm v | 2015. 02. 06., p – 11:58 )

Nemreg Glusterrel kiserleteztem. Attol fuggoen, hogy milyen adat es mekkora sebesseggel akarod irni-olvasni (a stat() lassu) jo lehet.

--
http://blog.htmm.hu/

( uid_228 | 2015. 02. 06., p – 12:00 )

Van, ahol ezt 2 db. FreeBSD szerverrel tervezik megoldani. :) Bár csak a nyers kapacitás van 1 PB fölött, de hátha ihletet ad:

http://kateleyco.com/?p=815

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

( Mcsiv v | 2015. 02. 06., p – 13:23 )

Tárolni kell csak, vagy aktív hozzáférés is kell hozzá, nem mind1;)

// Happy debugging, suckers
#define true (rand() > 10)

(y) köszi, igazából elég gyorsan kellene hozzáférni. De igaz, próbálok pontosítani ahol tudok :D

KAMI | 神
Firefox OS: https://is.gd/fxoshu Linux Mint: http://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes!

( freeoli v | 2015. 02. 06., p – 13:47 )

Tág a megfogalmazás, a keret és a cél.

Adatforgalom, adat elérési idők, sok mindent tisztázni kell. Két véglet lehetséges látatlanban. Szalagon szalagtárban vagy teljesen elosztott módon, pl ceph de ceph tárológyártótól is vehető vagy egyéb hasonló megoldás.

( uid_6201 v | 2015. 02. 06., p – 13:54 )

Vagy alacsonyszinten akarod megoldani azt hogy ekkora partíciód lehessen (fsck egy életig tart rajta),
vagy a Google modszerével tárolod, azaz több kisebb tárolóterület és az alkalmazás megfelelő módon szórja szét rájuk a sok információt.
Kereséskor szintén hasonlóképp eljárva az alkalmazás össze tudja szedni a kiszolgálandót.

( _Franko_ v | 2015. 02. 06., p – 14:13 )

Egészen konkrétan mi a feladat, ami miatt egyben kell látni egy fájlrendszerként 1PB területet?

Köszi, igyekeztem pontosítani. Nem feltétlenül storage a legjobb megoldás, de a teljes tárterület miatt ezt gondoltam. Ennek nem kell egyben lennie feltétlenül. Legalábbis most ezt a helyzet. :)

KAMI | 神
Firefox OS: https://is.gd/fxoshu Linux Mint: http://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes!

( asm v | 2015. 02. 06., p – 15:04 )

10 GB/s?
Ehhez ugye 100 Gb (aggregalt) linkre van szukseg, ahol meg nem igazan tart a technologia...

( _Franko_ v | 2015. 02. 06., p – 15:43 )

Ha sok (viszonylag) kis mérési érték és idősoros adatok tárolása a lényeg, akkor Cassandra (http://en.wikipedia.org/wiki/Apache_Cassandra), tulajdonképpen erre találták ki...

Ha viszont fájlok állnak elő és ezeket fel kell dolgozni és a projekt két vége már készen van, csak nincs hol tárolni az adatokat (tervezési hiányosság?), akkor nem lesz jó, kivéve, ha a létrehozás során/után egy feldolgozó betolja Cassandra-ba olvasáskor pedig onnan kerül előállításra a fájl vagy a stream.

( tompos v | 2015. 02. 06., p – 20:40 )

Gondolkozom, de a drbd miert ad vagy elvesz megoldashoz egy picit is?

Amugy fogsz egy kedvedre valo clusterfs-t, osszerakod es elvezed: szivni fogsz.

A glusterfs elvileg tokjol tudja, de a valosagban egy kalap szar. Plane, ha windows-ok vannak a penisz masik vegen.
Van meg pl. moosefs (iraskor nem szabalyos), lustre (nincs replikacio), fhgfs, cephfs (nem production ready allitolag, de vannak, akik hasznaljak), meg ki tudja meg mennyi es mi.

Vegeredmenyben az a tapasztalatom, h megfelelo celiranyos tapasztalat hijan ultrarizikos.
Masreszt ebben a meretben mar valoszinuleg tenyleg jobban megeri modositani a felteteleken es pl. cassandrat hasznalni, ahogy Franko irta.

( bra | 2015. 02. 06., p – 22:27 )

A legolcsóbban a megadott feltételeket valószínűleg így tudod teljesíteni:
veszel négyet mondjuk ebből, telerakod 3-4T-s diszkekkel: http://www.supermicro.nl/products/chassis/4U/847/SC847DE26-R2K02JBOD.cfm
veszel mellé egy erősebb gépet, beleraksz annyi SAS vezérlőt, ahány dobozod, csatornád van, és összekötöd őket.

A hostba esetleg tehetsz SSD-t is, ha cache-elni érdemes, és csinálhatsz rajta akár virtuális gépeket is, bár ezzel vsz. nem érdemes lassítani a feldolgozást.

Ez kb. a legalja, amit még vsz. érdemes lehet választani (persze kevés az info) innentől van felfelé. :)

( szilas | 2015. 02. 06., p – 22:58 )

Lehet nem publikus, de ennek köze van a CERN-hez? Csak kíváncsiság.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

( ScOut3R | 2015. 02. 06., p – 23:12 )

En valoszinuleg Ceph RBD alapon oldanam meg, cache tiering-gel es EC cold storage pool-lal. Hogy miert? Mert ezt ismerem es az elmult evek tapasztalatai alapjan bevalt. (Igaz, a cache tiering es EC pool meg uj feature, de tobbek kozott az altalad emlitett use case-re is valo.) Az RBD(-ket) pedig egy (tobb) kliens tovabboszthatja az igenyelt protokollon keresztul.

( chx | 2015. 02. 07., szo – 07:30 )

"Párhuzamosan 5-10 helyi gép vagy virtuális gép férne hozzá az adatokhoz."

Én ebből arra következtetek hogy a méréseket feldolgozó infrastruktúra még nincs kialakítva. Olyat nem lehet hogy a méréseket feldolgozó infrastruktúrát rátolod a "storage" gépre?

- brand gép annyi CPU-val és RAM-mal, hogy 10 klienst ki tudjon szolgálni (nem is kell feltétlenül VM, inkább local userek + desktop sharing)
- SSD-kből RAID5 alapú 1PB storage
- NFS share készítése és kiajánlása usereknek
- client-ek közvetlenül, párhuzamosan és nagyon gyorsan érik el az adatokat, sehol semmi bottleneck, és közben a saját desktop előtt ülnek
- a network-öt nem terheli a mérési adatok forgalmazása

Ez még mindig jóval olcsóbb mint egy komoly NAS, ráadásul NAS esetén a bottleneck még mindig ott lesz: a network.

Hosszú idejű biztonságos tárolásra meg tape, de ez már másik történet.
____________________
echo crash > /dev/kmem

( freeoli v | 2015. 02. 07., szo – 12:32 )

Az adatok mekkora részének kell gyorsan elérhetőnek lennie?