[MEGOLDVA] 250TB tárterület, Ceph -el?

Red Hat, Fedora, CentOS

Sziasztok!

Szükségem lenne egy megoldásra aminek a segítségével kitudok ajánlani 250TB -ot, windows/linux szervereknek. Nincs szükség nagy sebességre, csak a tárterületen van a lényeg. Illetve nagy rendelkezésre állóságról is beszélünk. Én Ceph -ben gondolkodom, de nyitott vagyok az ötletekre.

Előre is köszönöm az építő hozzászólásokat!

  • 9434 megtekintés

( tompos v | 2015. 03. 26., cs – 16:13 )

A kerdes az, h block storage-kent akarod vagy NAS-kent?

Azaz iscsi-kent vagy nfs/samba-val?

Elso korben tisztazd a peremfelteteleket.

Mit jelent a nagy rendelkezesre allas?
Mennyi ideig allhat a szolgaltatas: 1 sec, 1 perc, 15 perc, 1 ora?
Mennyi adat veszhet el crash eseten? Ha elveszhet vmennyi, akkor eleg aszinkron replikacio?

Van OS kotottseged?

Van HW kotottseged (adott HW-bol kell dolgoznod)?

Mit jelent a gyakorlatban, h a sebesseg nem fontos?

Lesz backupod, vagy azt meg akarod sporolni vmi modon okosan?

Mivel van tapasztalatod. Mennyire megengedett hibazni es tapasztalatot gyujteni menet kozben?

Milyen extra feature-oket kell tudnia? Milyen kliensek fogjak hasznalni es hogyan?

Nehany opcio a teljesseg igenye nelkul:

- ceph backend + head
- cephfs (allitolag nem stabil, de hasznaljak mar tobben productionben, feltetelezem bizonyos feature-okre nem stabil).
- glusterfs: alapbol menekulj tole, de ha nem kell nagy sebesseg, akkor igazabol megfelel, csak ne hasznalj replikaciot
- gyari NAS dobozok es csokolom
- DAS(ok) + head
- Lustre

tompos

ps.: Miert epp ceph-re gondoltal? Abbol konkretan hogyan?

Huh... Oké :D

Nos nem para az esetleges 1 órás leállás.
Backup -on spórolnánk. OS kötöttségről annyit, hogy jó lenne SLES v. CentOS akár. De Debian is rendben lehet. :D
HW kötöttségről még nincs elég infóm.
Az, hogy irreleváns a sebesség, azt jelenti, hogy ez inkább archívum lesz. Így nem napi használatra kell. Egyszer rátöltik a motyót aztán néha egy-egy fájlt lehúznak róla. A költség miatt nem tape technológia felé megyünk.
Egyáltalán nem probléma ha menet közben tanulunk. Hibázásról meg annyit, hogy először úgy is teszt környezet játszik majd.
Linux és MS kliensek is fogják használni.
Ceph -el fogalmam nincs, hogy :D csak elkezdtem olvasgatni videókat nézni a témával kapcsolatba és skálázhatóság szempontból ez tűnt szimpinek. De abszolút nyitott vagyok. Illetve jó lenne opensource megoldás nem valami ScaleIO csilliárdokért...

Köszi

EliteBook 8540p
Fedora 21
Startup finished in 2.637s (kernel) + 875ms (initrd) + 1.777s (userspace) = 5.290s

En nem mennek el a kunsztos megoldasok fele, raadasul inkabb darabolnam a dolgot, nem tartanam egyben.

Amit csinalnek az kello szamu extra kapacitasu szerver valamilyen izles szerinti linuxxal. Gepbol egy 16 diszkes supermicro hazba pakolnek valamilyen singlesocket sm lapot. Diszkbol 16x6T menne belle raid6+hotspare megoldasban es igy 13x6TB lenne a hasznos hely, ami 78TB. Az os-t kulon diszkrol indulna.

Valszin 4db ilyen gep kell, hogy ha valodi 250T-t szeretnel. A diszkek arahoz kepest az osszes tobbi alkatresz ara el fog torpulni. :)

Node ha 2-3 szervert vesz és JBOD-ozik, az mitől lesz olcsóbb, mintha venne 4db szervert soksok diszkkel? Nekem kicsit SPOF érzésem van ezeknél, mert ha több gépre disztributálnak (archive01, 02 stb), akkor ha meg is hal egy gép, akkor is csak egy része esik ki a kapacitásnak.

(Nyilván ha akar vehet fullos SAS RAID-et egy sima SAS HBA helyett, nem fog érdemi költséget növelni. Diszkekre fogja a pénze 3/4-ét költeni. :) )

Ahha, kezdhetted volna ezzel, hogy archivum lesz.

Pl. a glusterfs-nel van olyanja, hogy write once, read many vagy vmi ilyesmi. Azaz kifejezettem novekmenyes teruletekre jo.
Viszont ha csak erre kell, akkor az ujonnan bejelentett Amazon Cloud Drive nem pont megfelel neked?

Az OS kotottsegnel OS-re gondoltam, nem linux disztribuciora:)

Az altalad leirtak alapjan vagy vmilyen cloud-os megoldas iranyaba mennek amennyiben az opcio.

Vagy alternativ megoldaskent linux v. opensolaris + zfs. egy head gep + nehany DAS (vannak igen olcsok is). Amennyiben valoban kell az 1 oras SLA, akkor szuksegetek lesz min. 1 csere DAS-ra, HBA kartyakra, + szerverre v. fobb szerver alkatreszekre.
Idoszakosan, pl. orankent csinaljatok snapshotot. De szabaly szeruen a legjobb, ha felepitetek belole megegyet es replikaltok ra, plane hogy kezdok lesztek es el fogtok rontani dolgokat torvenyszeruen.
A poolba 8+2/3 diszkes raidz2/3 raidsetek javasoltak, nagyobb semmikepp.

Minden helyben lerakott rendszer valoszinuleg dragabban jon ki, mint vmilyen cloud-os megoldas. Akkor lehet letjogosultsaga, ha az az interfesz nem felel meg, amit nyujtani tud az alternativa.

Az a baj, hogy a projekt részletei még nem teljesen világosak. Másrészről pedig igen disztrókat írtam, de ez egyben válasz az os kérdésre is legalább is az én olvasatom szerint ;)
Azt hiszem jobban utána kell nézni, illetve ha több részlet lesz tiszta akkor jobban lehet majd elmenni valamelyik irányba.
Köszi mindenkinek a segítséget. Mindenképpen jelentkezem még ha fejlemény lesz...

EliteBook 8540p
Fedora 21
Startup finished in 2.637s (kernel) + 875ms (initrd) + 1.777s (userspace) = 5.290s

> Az a baj, hogy a projekt részletei még nem teljesen világosak. Másrészről pedig igen disztrókat írtam, de ez egyben válasz az os kérdésre is legalább is az én olvasatom szerint ;)

Igen, csak tisztazni akartam, h nem beszelunk el egymas mellett.

> Azt hiszem jobban utána kell nézni

Meg nem talalkoztam olyan feladattal, ami nem igy volt:)

Marmint ket glusterfs cluster, nem?

Akkor szerencses vagy, nekem nem ez a tapasztalatom:)
Igaz, Ubuntu LTS, de ezen kivul semmi extra:

Volume Name: w-vol
Type: Distribute
Volume ID: ebaa67c4-7429-4106-9ab3-dfc85235a2a1
Status: Started
Number of Bricks: 5
Transport-type: tcp
Bricks:
Brick1: gl0:/mnt/brick1/data
Brick2: gl1:/mnt/brick1/data
Brick3: gl2:/mnt/brick1/data
Brick4: gl3:/mnt/brick1/data
Brick5: gl4:/mnt/brick1/data
Options Reconfigured:
server.allow-insecure: on
performance.cache-size: 4GB
performance.flush-behind: on
diagnostics.client-log-level: WARNING

Valo igaz egyebkent, fuse mounttal egesz jol mukodik, sot nfs-sel is rendben volt.
Viszont tobbsegeben windows-os kliensek vannak. A libgfapi-s megosztas full hasznalhatatlan, random hibakat dobal az alkalmazas.
Ha fuse mount, majd azt kiajanlom, akkor hasznalhato, de mindenfele hibak. Pl. ott van a file, megis azt mondja, h read error. Meg effele josagok.

Kb. 20-30 (VFX) kliens egyidejuleg. Elsosorban olvasas, tobbnyire viszonylag izmosabb folyamatos sebesseggel (~1 Gb sessiononkent).

Pelda:

> [2015-05-23 05:03:57.099342] W [fuse-bridge.c:1261:fuse_err_cbk] 0-glusterfs-fuse: 1713284477: REMOVEXATTR() /1420_PWK/60_Elements/Prod/PWK_120/PWK_120_050/CG/PWK_120_050-cg_li_v002/masterLayer/Arnold_Indirect_Specular/PWK_120_050-cg_li_v002_masterLayer.Arnold_Indirect_Specular.1162.exr => -1 (No data available)

Csak warning, de a francnak szemeteli tele a logot, amikor valojaban megcsak warning sem (1 nap alatt 30M logot termel, ami rohadt sok).

> [2015-05-22 04:29:52.882055] W [fuse-bridge.c:1261:fuse_err_cbk] 0-glusterfs-fuse: 1676025749: SETXATTR() / => -1 (Permission denied)

Franc tudja mibaja es ami meg lenyegesebb, a franc tudja h erdemben milyen problemat okoz.

Ja es egy ujabb hiba: 5-bol 2 node kisebb, szoval a masik 3 hasznos helye sem lehet tobb nala (ill. vhogy vmikor igen, nem sikerult meg rajonnom a logikara erdemben).

> [2015-05-20 07:34:25.620125] W [fuse-bridge.c:1001:fuse_fd_cbk] 0-glusterfs-fuse: 1613941528: OPEN() /.fs_is_mounted => -1 (Permission denied)

Ez egy file checkolni, h ha letezik, akkor az fs mountolva van es olvashato.

-rw-rw-r-- 1 root root 0 Jan 5 11:18 /W/Projects/.fs_is_mounted

Szoval mi a problema?:)

Szerintem rohadtul kezelhetetlen, lekovethetetlen.
Persze siman lehet, h az Ubuntu okozza a gondot (de miert tenne?), vagy csak szimplan nem ertek hozza.

OK, akkor neked meg nekem mas a node.

Szoval nekem a cluster a full stack, a node az a cluster egy darabja (=szerver).

1-1 replika mukodott, amikor es amennyire probaltam. Ill. addig mukodott, amig nem remove-oltam az egyik labat vhogyan. Onnantol okadta a logba, h hianyzik neki. De tovabbra is tudta irni, sot, azota is mukodik evek ota (sw based nfs server:).

Gondolom, nagysagrendileg be tudtatok loni az arat amit raszantok, szoval nem is jar a fejetekben, hogy apropenzel meg fog oldodni, igy merem javasolni az OOB megoldasokat:
EMC VNX5200 nem olcso, de legalabb draga, nalunk 1 ev free support is volt benne. Persze ezt jo lenne megduplazni, ha mar ennyi a love, meg a biztonsag sem az utolso.
Dell EqualLogic FS7600 Meg ezzel sem losz nagyon fole, es az ara is joval baratsagosabb.

Milyen alkalmazás archiválna?
Kérdés, hogy van-e az archívum felé követelmény valamiféle megfelelőségre, megőrzési idő, változtathatatlanság? Mindenképpen WORM terület kell neki? Milyen méretű fájlokat pakolnál rá, mennyi darabot?
Adatvédelem szintje, kapacitás overhead, folyamatos integritás ellenőrzés? DR megoldás, lesz párja másik helyen, kell-e replikáció?
Brand gyártóknak NAS rendszerekhez van WORM funkció (EMC, NetApp), EMC Centera kimondottan diszk alapú archiváló rendszer. De van még a tarsolyban EMC Isilon, Atmos, ECS ami szintén bír WORM funkcióval. Ezek némelyike tud tömörítést, deduplikációt, amivel adott esetben hely takarítható meg.

( Batman | 2015. 03. 27., p – 12:37 )

Én helyedben vetnék egy pillantást MooseFs-re is. Nagyon kis egyszerű és hibátlanul működik.
Egyszerűbb szerintem telepíteni mint Ceph-et.

http://www.moosefs.org/

( NagyZ v | 2015. 03. 30., h – 12:30 )

a ceph a de-facto scale-out storage, ha ugy dontesz, megkuzdesz azzal, hogy ez blokk, nem FS, es rarakod az NFS/sambsat, akkor boldog leszel vele.

fent irtak, hogy kell a SAS diszk, meg a brand szerver, ezek jok ha vannak, es ha van ra keret, mindenkepp, viszont a ceph elonye, hogy szinte barmit tulel, igy ha nincs keret, csak kell a sok hely (de az nem tul gyorsan...), akkor vegyel par tescos gepet, belerakod gepenkent az alaplapi satakra a diszkeket, aztan szevasz.

a halozat az a resze, ahol nem sporolnek, kell rendes gigabites switch (vagy ha van ra keret, 10gbe), olyan, ami nem 1:5324 oversubscribed belul, hanem tenyleg line-rate. ebbol ketto, a redundancia miatt.

ha egy diszk kiesik, a ceph kirohogi, megy tovabb.
ha egy gep kiesik, a ceph kirohogi, megy tovabb.
ha leall a halozatod, akkor minden meghalt.

a tompos altal ajanlott ZFS is franko megoldas, ha egybe tudsz ekkora tarhelyet rakni - ez tipikusan sufnialkatreszekbol mar nem fog menni, kell legalabb egy brand haz, ami millios tetel. (Supermicronak a 90 diszkes JBOD haza ~7000 dollar)

Sosem fér bele, csak azt gondolják. :) Amikor megáll, akkor "jajjúristen rögtön kell 850GB-nyi akármi" c. műsor jön, aminek a lemásolása önmagában is hosszú idő.

Én továbbra is kitartok a szegmentálás mellett, méghozzá géppárrokkal, páronként olyan 78TB hasznos hellyel. (16x6TB WD Se vagy azzal egyenértékű diszk, RAID6+hotspare konfigban.) Gyors fejszámolás után (4 géppárral kb. 10 millió nettó körüli összegben vannak csak a diszkek. A villanyszámla pedig a havi 60e-t fogja verdesni csak a gépekre nézve!, hűtés nélkül, ha odafigyelnek a nagy hatásfokú tápokra és olyan 120-150W körül sikerül 1-1 gépet megállítani. Sokkal inkább tűnik úgy, hogy mindenestül simán 100e per hónap lesz, csak az hogy mennek a gépek. (Géppárokkal azért számolok, mert heti 1x lehetne rsync-elni egy lazát, hogy legalább valami legyen. Ha replikáció van, akkor az nem véd a törlés ellen, mert rögtön törli mindenhonnan az adatot.)

Ha mindenképp egyben akarják és jön a CEPH-es vonal, akkor a többszörös replikáció miatt és gondolom van valamilyen master node, abból is több, mégjobban elszállnak a költségek.

> Sosem fér bele, csak azt gondolják.

Eppenseggel forditva szokott lenni.

Mindig az van, hogy HA kell (ld. fent), majd amikor jon a matek, hogy mennyibe kerulnek a 9-esek es mennyibe kerul 1-2 ora leallas es annak mekkora a varhato gyakorisaga, akkor kiderul, hogy nem HA kell (ld. fent).

Az esetek elenyeszo reszeben igenylik valoban azt.
Fokozottan igaz manapsag, amikor sokkal nagyobb megbizhatosaguak a hardverek (bar ez szubjektiv megallapitas). Vagy legalabbis olcsobban lehet ilyen kategoriaju HW-t beszerezni.

( gthomas | 2015. 03. 30., h – 13:49 )

Hello,

Ha nem nagyon törlitek a fájlokat, akkor: https://github.com/chrislusf/weed-fs
Vagy még jobb: camlistore.org
Bár ez utóbbi kicsit nagyobb léptékű, de sokkal nagyobb lehetőségekkel (pl. automatikus blokk-szintű deduplikációt tud).

( gabrielakos v | 2015. 03. 31., k – 11:54 )

glusterfs-t nézted?
amennyit én eddig foglalkoztam vele, az alapján elég jó cuccnak tűnik.

--
Gábriel Ákos
http://ixenit.com