halozat/infrastruktura bovites, ceph es OpenStack tapasztalat #1

akarmennyi eroforrast raksz ala, a felhasznalok mindig el fogjak hasznalni ;-)

november elejen inditottunk egy belso, helyi felhot (van par a cegen belul, de kellett egy olyan, ami svajcban van, helyiek uzemeltetik, es hozzaferunk "alul" is), es bizony kinottuk. elkezdtuk elokesziteni a bovitest...

az elso dolog, ami kelleni fog, az egy uj rack (pipa), illetve egy uj switch. a kedvencem mostanaban az IBM G8264 ToR switch.
4x40Gbit SQFP+ port, 48x10Gbit SFP+ port. hirtelen megneztem az arat a magyar piacon, nem tul barati (6M+fa korul talalja a google),
igy gondolom sok ember nem fut bele. ez lesz a masodik ilyen most a kezem alatt, valoszinulseg az uj rackekbe (mostanaban rackesevel
bovitjuk majd a hardwaret) is ilyet rakok.

kicsomagolas utan:

es az uplink mar bekotve:

ha minden jol megy, a heten megjon a 6xIBM x3650 M4 BD, ok lesznek a ceph nodeok,
plusz ket masik gep adja majd az SSD tiert (a firefly-tol felfele lesz supported tiering, ket pool kozott, majd irok rola bovebben egy kovetkezo
bejegyzesben). igy lesz 3x replikacio mellett 48TB hasznalhato hely egyelore.

a terv a kovetkezo:
- 2db gep (2x6 mag, 64/128GB RAM) lesz vSphere-el a management cluster (ezen lesz a DC, DNS, DB2, OpenStack-es API GW es network controller)
- 8db gep (2x6 mag, 256GB RAM) lesz a compute node
- 2db gep (1x6 mag, 16GB) ram lesz a staging area (git commit es review utan ide megy fel a kod rogton, majd futnak le a tesztek)
- 2db gep (ugyanez) lesz az abszolut teszt rendszer

a ceph-bol vagy iSCSI-t, vagy FCoE-t fogok kiajanlani (meg tesztelnem kell, hogy az intel halokarikon lehet-e teljesen offloaded FCoE-t csinalni, mindenfele ugyeskedes nelkul).

elvileg jovoheten megerkeznek a vasak, folyt. kov. :)

( anr | 2014. 03. 09., v – 06:28 )

Anno a koleszban mi azon rohogyunk, hogy az eggyel nagyobb wincsi 2 hétig elég :)
---

Ha az ember nem sajat maganak dolgozik, akkor nehezen tanulja meg, hogy dobni kell a draga, keves/semmi haszonnal nem jaro dolgokat a specifikaciokbol.

--
Live free, or I f'ing kill you.

( wachag | 2014. 03. 09., v – 07:05 )

Nice. Végképp elköteleződtél a Ceph mellett vagy pl. GlusterFS-t is néznél valamikor (más világ kicsit)?

ha megjon a hardware, igertem par embernek, hogy csinalok GPFS es glusterfs tesztet is. ami nem tetszik a glusterben (de javits ki, ha tevedek), hogy mivel ugye fajlrendszer,
igy fajlonkent valaszt brickeket - tehat lehet egy fajlom ami szet van dobva 3 eszkozre, es szinkronban tartva; na, a fajlban tarolassal bejon megegy indirekcio (VM blokk eszkoz -> fajl -> blokk eszkoz), plusz nem tudom, hogy tud-e
- tieringet
- a brickeket lehet-e stripeolni mas brickekkel

cephnel nagyon tetszik, hogy lenyegeben "minden" diszk dolgozik mindig, igy a terhelesed nagyon szepen eloszlik es skalazodik.

ami most nagy szivas, hogyha nem egyenletesen hasznalja a diszkeket (bar mi 0.64.x-et futtatunk egyelore elesben, nem 0.7x-et), illetve hogy amikor atirja az ember a crush mapet (milyen adat hogy helyezkedjen el), akkor iscsitgt-n keresztuli rbd map teljesen meghal (100% iowaitbe megy az rbd blokk eszkoz a kernelen belul, igy a rajta levo vmware datastoreok nem szeretik), de ezt mar hatha javitottak - az uj hwre a legujabb, 0.78 megy majd

A glusterfs tieringet (meg) nem tud.
Egyebkent vmware ala tudtommal nagyon bena, vagy legalabbis az volt korabban. NFS-en el tudja erni, ami aztan olyan, amilyen, a nativ implementaciojuk.

En hasznalok glusterfs-t elesben, de szerencsere replikacio nelkul.
Olvasva a levlistajukat a replikacio nem igazan mukodik tokeletesen, nekem meg anelkul is vannak vele mindenfele problemaim (igaz, nem VM-ek alatt hasznalom, teljesen mas use case).

Egy esetben rughat labdaba a glusterfs szerintem, ha a geo-replikacio-ra van szukseg, azt mintha a ceph nem tudna.

t

( AiRLAC v | 2014. 03. 09., v – 08:02 )

sed -i 's/tearing/tiering/g'

Ha jól értelmezem :)

( Mico v | 2014. 03. 09., v – 08:34 )

Ez a switch viszont önmagában spof, nem?

ha csak ezen lenne a teljes infrastruktura, akkor teljes mertekben. ket megoldas van (van egy masik rack, ahol most futnak a cuccok, annak a tetejen is ugyanez a switch):
- minden gep egyik laba egyik switchre, masik laba masik switchre
- minden funkciobol fele egyik rack, fele masik rack

meg nem talaltuk ki, melyik legyen, de semmikeppen sem szeretnenk spofot

itt dolgozom, nem titok :)

a kollegak sokmindent csinalnak a vmeken, nyilvan fogalmam sincs, pontosan mit, hiszen abba nem latok bele. az intranet id-vel be lehet lepni (a filter az, hogy a mi business unitunk foglalkoztassa), es minden usernek van 10 VM, 64GB RAM illetve 1TB diszk limitje - keresre emeljuk.

az egyik konkret dolog, amirol tudok, az a GPFS uj verzioinak a tesztelese; illetve hadoop felhasznalas.

( uid_228 | 2014. 03. 09., v – 09:40 )

Mi ilyen SoHo switcheket legföljebb ott használunk, ahol nincs komoly infrastruktúra, csak inkább kliensek. :)

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

( lajos22 | 2014. 03. 10., h – 15:04 )

Ez a switch egyenesen sexy, csak többe van, mint egy csaj. :p

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

( kicca | 2014. 03. 11., k – 21:18 )

infrastruktura bovitessel kapcsolatban:
van supermicro altal gyartott geciolcso storage akar ceph ala jopar ilyet :). Foleg rackhely-sporolas miatt erdemes lehet elgondolkodni rajta.
Fullon feltoltve rammal 72x4T sataval mindennel egyutt. $30-40k korul van.

https://dl.dropboxusercontent.com/u/5004161/hurkale/smst1.jpg
https://dl.dropboxusercontent.com/u/5004161/hurkale/smst2.jpg
https://dl.dropboxusercontent.com/u/5004161/hurkale/smst4.jpg

288T sata ment bele storagenek
+2 rendszernek
Ilyeneket kb 2 honapja hasznalok backupra szoval hosszutavu tapasztalatom nincs vele, de eddig nem allt le :)
Fogyasztasa egy ilyennek:
The Highest Peak (W) 1156
Average (W) 838

Ilyen hardverekről én csak olvasok, élőben még messziről sem láttam, hasonlót sem. Az eredeti posztról nem is beszélve, csak ez a 72db HDD bő 3 millió HUF. Mikro- és kisvállalkozásoknál nem találkozok ilyen volumennel.

Szöget ütött a fejemben, hogy milyen szervezésben oldható meg, hogy ilyen sok eszközzel ilyen kevés redundancia legyen. Ha jól gondolom, akkor a HW és SW RAID megoldások sem szeretnek ilyen sok lemezt egy kötetben (RAID6 70+2 vagy RAID5 2x 35+1 vagy mi?).

WD RED 4.0TB-os HDD-re a non-recoverable read error rate 10^14 (ami desktop kategória), ami kb. 11.36TB. Ez nagyon is partiban van az én olvasatomban (sőt...) a 70x4 TB tárhellyel és a 8TB kieső kapacitással.

A serverthehome.com RAID megbízhatósági kalkulátora szerint 72x4TB RAID6-ban 98%-os eséllyel okoz adatvesztést az első évben, de még RAID50 esetén is 40% az esély adatvesztésre azonos időszakra. Csak ebben a két felállásban tudom elképzelni a 2 kieső lemezt egyenlőre.

Vagy rosszul gondolom az egészet? Nem vagyok járatos ebben a témakörben, de nagyon érdekel.

Értem. Viszont akkor nem sántít a két node, node-onként nagyon sok diszk felállás? Nem lenne biztosabb több node, darabonként kevesebb HDD-vel? Mert ennyi adatnál megáll az egyik, a CEPH elkezdi megoldani. Közben simán megállhat a másik is. Pont ugyan az a gond, mintha sima RAID lenne.
Az oké, hogy backup-ból helyreállítható, de ennyi adatot visszamásolni sem 5 perc.

ki nem szarja le? ha megserul majd helyreallitja magat. :D En ilyenen nem izgulok.
Amugy persze jobb lenne ha raidkartyankent mehetne tonkre 2. De ez a vonat mar elment, majd ha beleall a gorcs akkor ugy epitem ujra mar :) De lehet, hogy holnap mar ujracsinalom raidet rajtuk attol fugg hogy lesz kedvem

Amugy az hogy 2 mehet tonkre az azt jelenti, hogy 1 mehet tonkre mert kettesevel lehet kivenni diskeket :DDD

Amugy ha belecsapna a gombvillam a kabeltvbe es bemaszna a szerverekhez akkor is helyre tudom allitani az adatokat aranylag gyorsan garantaltan kieses nelkul.