Ceph tapasztalatok, javaslatok

Linux-haladó

Ceph cluster-t aktívan használó, üzemeltető HUPperek tapasztalataira lennék kíváncsi itt összegyűjtve.

Előzmények itt: http://hup.hu/node/141249

  • 3657 megtekintés

( junior013 | 2015. 06. 30., k – 16:56 )

Személy szerint egy (jelenleg) 5 node-ból, 26 OSD-ből (SATA disk-ek) álló clustert építek/üzemeltetek, ami 2db KVM host ~30 virtuális gépét és azok adatait tárolja.
Legalábbis errefelé tartok, de még nem mertem teljesen mindent átterhelni erre a rendszerre, mivel nem hozza a megfelelő teljesítményt.
Virt. gépeken raw disk írás max. 60MB/s, virt. Samba szerveren át ez valósan kb. 20MB/s - viszont 1-2 párhuzamos szállal megterhelve gyakorlatilag lehal az egész annélkül, hogy a ceph oldaláról bármelyik ponton kiugró terhelést látnék :(

Mennyit segíthet vajon SSD cache a node-okba? SSD journal az OSD-khez?

-------------------------------^v-----------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Az a baj, hogy nálam még a 2Gbit sem koppan ki (3-400Mbit/node a max.) - akkor legalább látnám, hogy az a szűk keresztmetszet.
(2x1Gbit LACP/node, a 2 HP 1910-es switch között 4x1Gbit LACP)

-------------------------------^v-----------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Én igen. A főnökömet még győzködöm ez ügyben :)

(ha 1 SSD-re több OSD journal-ja kerül, az mennyire gáz? Tudom, hogy az 1-1 lenne a szép, de az egyelőre nem járható. Mondjuk így is max. 2 OSD/SSD-re gondoltam, ha pukkan az SSD, több OSD-t ne vigyen magával)

-------------------------------^v-----------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Nálunk is 1:4-be megy az ssd-journal:hdd-Osd-data arány.
Itt szépen össze van szedve hogy számolhatod ki. http://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-test-if-your-ss…
Valamint a fenti linken páran összedobtuk az olcsó SSD-k ceph journal képességeit. Nagyon nem mindegy milyen ssd-t vesztek.
Nálunk kb. ilyen a felállás, nagyon nem a legjobb de "szegény ember vízzel főz"
.most 3 node van, node-onként: 2db. ssd, 3-4 sata disk. 4gbit háló, olvasásnál ki tud koppanni a 4gbit.
Itt minidg az a dilemma, hogy 2 replikációval fasza az írás de gyatra az olvasás, 3 replikációval fasza az olvasás gyatra az írás.
felállás:
1 ssd a journal
1 ssd cache tier-nek, ennek is ssd-re került a jorunalja.
a többi sata disk osd data.
Nem basz oda a sebesség, kicsit jobbat vártam, de eddig úgy tűnik elfogadható.
Amivel lehet tuningolni kicsit, ezeket jól ki kell tesztelni, nem mindig nem mindenkinek hoz bármennyit is, meg lehet köpködni:
HDD-nél: echo cfq > /sys/block/sdX/queue/scheduler
SSD-nél: echo noop > /sys/block/sdX/queue/scheduler
ceph config ba:
osd recovery max active = 1
osd max backfills = 1

xfs mount opciók: "rw,noatime,inode64,logbsize=256k,logbufs=8,delaylog,allocsize=4M"

debug kikapcsolás:
debug lockdep = 0/0
debug context = 0/0
debug crush = 0/0
debug buffer = 0/0
debug timer = 0/0
debug journaler = 0/0
debug osd = 0/0
debug optracker = 0/0
debug objclass = 0/0
debug filestore = 0/0
debug journal = 0/0
debug ms = 0/0
debug monc = 0/0
debug tp = 0/0
debug auth = 0/0
debug finisher = 0/0
debug heartbeatmap = 0/0
debug perfcounter = 0/0
debug asok = 0/0
debug throttle = 0/0

kvm guesten, virtio disk-re: echo 4096 /sys/block/vdX/queue/read_ahead_kb

--------------------
http://grant-it.com/

Az mindenképp hasznos, de szerintem sok helyen - így nálunk is - egy skálázható Ceph cluster a redundáns, "dobozos" NAS/SAN _olcsóbb_ alternatívája. Hogy csak a node-ok közti hálózat többmilliós költség legyen, legtöbb helyen sajnos nem fér bele :/

-------------------------------^v-----------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Nezd, alabb lehet adni a hardverigenyeket, de akkor alabb kell adni a storage-dzsel szembeni igenyeket is, ez mar csak ilyen. Ha gyenge halozat van alatta, akkor nem lesz ertelmes teljesitmenye, kovetkezeskeppen nem szabad nyiglodni, hogy lassu, meg nem megy.

Ha VM-ek ala raknak "koltseghatekony" storaget, az tipikusan az a szitu szokott lenni, hogy raengednek 10-15 VM-et, abbol egy elkezd swappelni, a tobbi meg all es nezi. Marmint, megall, es nezi. Es a 10-15 VM az meg nem is olyan nagy szam, egy kozepes ceg is pillanatok alatt eri el ezt a szamot, ha magas rendelkezesreallast akar - marpedig mi a gyosznek csinalna redundans storage-t, ha SPOF-okkal akarja teletolni?

Sajnos a SAN az olyan, hogy a gepeken sporolhatsz, a diszkeken sporolhatsz, a szunetmentesen sporolhatsz - a halozaton nem sporolhatsz. Mert egy SAN-t lehet horizontalisan es vertikalisan is skalazni, de ha a halozat nem kepes kiszolgalni a teljesitmenyigenyt, akkor te rakhatsz moge annyi dzsuvas gepet, amennyit csak akarsz, ha egyszer kikoppan a node-k fele a sav, akkor az ki lesz koppanva.

A kicsit is komolyabb switchek/kartyak mar tamogatjak legalabb a jumbo frame-t, szoval attol nem lesz soktizmillios koltseged, mert ilyen eszkozoket akarsz venni, csak ne a kategoria legaljarol akarjatok valogatni, mert a HP/DELL ujramarkazott joarasitott eszkozei vagy nem fogjak tudni, vagy tudni fogjak, csak nem leszel boldogabb tole, mert annyira gyengek hardveresen, hogy szammal kifejezheto teljesitmenyt produkalni nem tudnak.

--
Blog | @hron84
Üzemeltető macik

az, hogy 10 gbit legyen a SAN vagy NAS hálón, a cégek és oktatási intézmények 95%-a nem engedheti meg
itt nem csak arról van szó, hogy switcheket kell venni, hanem a blade keretekbe (ha egyáltalán támogatják) meg kell venned a 10 gbit interface-eket illetve
ha fizikai gépeid vannak, akkor pedig többszörösen
Sajnos ez, amit felsoroltam, 5-10 milliónál kezdődik....és csak a NAS-ról beszélek

Emiatt hekkelik a bound-okkal meg az etherchannel-ekkel a meglévő gigabites architekturájukat a "szegények", hátha jó lesz, de sajna kiderül, nem lesz az...hacsak nem dedikálsz 5 vm-enként külön klaszerokat

"turájukat a "szegények", hátha jó lesz, de sajna kiderül, nem lesz az...hacsak nem dedikálsz 5 vm-enként külön klaszerokat"

A szegenyek ne akarjanak teljesitmenyt a bondolt interfeszen, ennel tobbet nem tudsz tenni.

Lehet bondolt interfeszen is SAN-t epiteni, de akkor nem lehet VM-eket ratetnni, maskepp kell felepiteni a rendszert. Ha pl. a Samba/Apache/NFS van a SAN-on, es a node-k lokalis winyojan pedig annak a par vmnek a rendszerdiszkje, ami az ilyen koltseghatekony gepekre rafer, akkor jobb lesz a teljesitmeny.

Mondom, nem a lowcost halozattal van a gond, hanem azzal, hogy esszeruen, logikusan be kell latni, hogy egy adott IOPS teljesitmenyt csak egy adott halozati infrastruktura tud biztositani. Ezt meg a "szegenyeknek" is meg kell erteniuk, es ugy kellene felepiteni a halozatukat, hogy tudomasul veszik a korlatokat. De amikor azt latom, hogy folyamat sir az emberek szaja, hogy milyen bun lassu a rendszer, es kozben nincs mogotte ertelmes modon megtervezett halozat, csak ugy odacsaptak "jo lesz ez" alapon, akkor igazabol nincs szakmai segitseg, a hulyesegre nincs orvossag.
--
Blog | @hron84
Üzemeltető macik

"a mar meglevo 10 gigas halozatodra (mert majdnem mindenkinek mar az van)" - azért ez nagyon erős túlzás, szerintem. Úgy érzem, a "nagyok" és a "kicsik" baromira elbeszélnek egymás mellett.
Az, hogy már otthon is szinte mindenkinél gigabit van, az rendben, hiszen szinte egy árban van a 100-as eszközökkel. De azért a 10G sajnos még bőven több, mint 10x drágább az gigabitnélnél, olyannyira, hogy átlag, nyilvános (magyar!) kereskedelmi árlistákban nem is nagyon találni 10G-s eszközöket.

Másrészről, senki nem akar "szarból várat" építeni, csak a lehetőségeihez méri az igényeit. Természetes, hogy egy 4x1G-s hálózattol nem várok 4*10G-s teljesítményt, de amíg a 2x1G-t sem tömi ki a rendszer, addig ott nem a hálózat a szűk keresztmetszet - szerintem.

-------------------------------^v-----------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

egy sima rados bench nalam kitolja a 2x10Gbitet. lefogadom, hogy a replikacios forgalommal egyutt nalad is ki van tolva a 4x1gbit. de persze fugg a forgalomtol - olyan ez, mint borju az ujkapura: van, aki radocsalkozik arra, hogy "jee, a 7200 RPM-es 4TB-os diszkem csak ~4MB/s-el tud irni randomban?!". na, azzal nehez kitolni.

szamolj utana: vegyunk egy sima 3 gepes clustert, tegyuk fel, hogy SSD journaling van, 4x1Gbit/s nodeonkent, es irunk. a kliens gep mind a harom node-ra fog irni (a PG-g primaryjeinek az eloszlasa az osdk kozott pszeudorandom), es tegyuk fel a kliens felol van vegtelen savszelesseg.

ha X sebesseggel ir n1-re [tehat 3*X-el ir eppen], az n2 es n3-ra is replikalni akar X sebesseggel; igen am, de a tobbi node ugyanezt jatssza le. ha megnezed, gepenkent a kovetkezokepp jon ki a savszelesseg eloszlas:
- X (bejovo iras)
- 2*X (kimeno replikaciok a masik ket gepre)
- 2*X (bejovo replikaciok a tobbi geprol)

azaz 5*X halozati terheles van minden gepen. a legtobb gigabites switch nem fogja tuni neked lineraten az osszes portjan a gigabitet. tegyuk fel, hogy a tied tudja. ekkor limitalva vagy savszelessegileg ~800Mbitre (ez a kliensen viszont mar 3.2Gbit/s-es irasnak felel meg).

SSD journal nelkul mar bejon az altalam emlitett rossz random rw performanciaja a SATA diszkeknek (es a 2x-es write penalty), amit nagy clusterekben tud ellensulyozni a summa[osd](randrw))>>kliensigeny, viszont a latency ott is borzalmas.

#define turheto.

Vehetsz olcso eszkozoket, amiket cserelgethetsz evente-ketevente, meg lesznek vele problemaid, vagy koltotok az infrara, es akkor az egy egyszeri kiadas marad.

Nekem a turheto ar az, amiert normalis hardvereket kapok, de meg nem rokkan bele a ceg.
--
Blog | @hron84
Üzemeltető macik

Azert ha a jumbo frame sincs tamogatva, az az infra egeszen erett mar a kukara, vagy legalabbis nem szabad tole semmi olyat varni, ami ugy kezdodik, hogy megbizhatosag meg magas rendelkezesreallas. Jatszos kornyezetnek persze tokeletes az ilyen, de produktiv rendszer ala... hat, csak akkor, ha a rajta tarolt adatok erteke nulla, vagy valaminek a tizensokadik replikaja.
--
Blog | @hron84
Üzemeltető macik

Több ETH IF-hez milyen bondingot használtok? Mert szinte "szabvány" az LACP, de az 1 adott kapcsolatra csak 1 IF-t tud használni - azaz 1Gbit. Elegendő ez ahhoz, hogy az egész cluster node-jai közti kommunikáció eloszoljon a több IF között (nekem úgy tűnik, hogy nem - még xmit_hash_policy layer3+4 beállítással sem), vagy inkább round-robin bondingot érdemes használni?

-------------------------------^v-----------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Igen, javulni fog a sebesség az LACPvel, ha persze támogatja a switched. A Ceph akár 10-20 TCP kapcsoloatot is nyithat a node-ok között terheléstől függően egy kisebb klaszteren is. Ha még nagyobb Jumbot is tudsz hozzáadni, akkor akár 40%-kal is javulhat, persze csak al előzőhöz képest....csodákat ne várj.
A probléma az, hogy rengeteg switchportot megeszik a cucc, ha mondjuk egy 6 node-os klaszter hálókarijait LACP-zed. Sajna ez is "drága" lesz, ugyanis az LACP-s switchek drágábbak, persze relatíve.
Ilyenkor gondolkodik el az ember azon, hogy egy használt infinibandet vesz inkább kártyákkal, switchhel, mint gigabiteket LACP-zik.....

30 vm io terheléses sok a 26 SATA diszknek. Próbáld megnézni a diszkek termelését, szvsz. biztos izzadnak. Egy SATA diszkre 80IOPS terhelést tervezz! Ebből a szerverek felé kihozható IOPS még függ a RAID védelemtől és a read/write aránytól legalábbis hagyományos esetben. Ceph nem tudom mit használ. Ha van mód valami durva cachelésre memóriában vagy SSD meghajtókkal azzal szerintem sokat javíthatsz a helyzeten.

Az SSD journal, ha jó SSD-t választasz az minden esetben jobb lesz a sima hdd felállásnál, de azt mondják a spinning diszket sem szabad lebecsülni journal szempontjából, ezt még nem teszteltem. Ha van rá lehetőséged próbálj ki egy journal HDD-t kezdetnek két 2 OSD-nek.

SSD cache szerintem:
pro:
- kis latency
- gyors írás
- ha erasual coded pool-t raksz mögé több tárhely
kontra:
- addig lassú amíg be nem kerül az adat a cache-be, tipikusan a ritkán olvasott fájlok mozgatása,olvasása, lassan indul meg.
- kicsit bonyolultabb tervezés és managelés.

--------------------
http://grant-it.com/

( NagyZ v | 2015. 06. 30., k – 17:12 )

egy kis onreklam, a 33. slide korul nezegetni; nem latom hirtelen hogy a performance talkunk slidejai kint vannak-e publicban.

Ha már önreklámozunk, akkor azt emeljük ki, hogy ez egy
- hands-on-lab volt, amit
- Magyarországon is előadtunk, és ahol
- 50-100 darab külön cloudot húztunk fel két óra alatt, hogy
- ugyanennyien a laptopjuk előtt ülve kipróbálják, milyen is
- működő ceph storage clustert építeni.
- Tokyo summiton is előadjuk, ha szavaznak ránk elegen :-)

A performance talk slide-jai pedig hipertitkosak, úgyhogy nem tettem még ki a githubomra :-)

( wyx v | 2015. 06. 30., k – 21:48 )

Sajnos a Ceph performancia katasztrófális sima mezei hardveren, értem itt a SATA HDDk + 4-5 db 5-8éves szerver node +Gigabit (vagy 2 Gbit) ethernet interlink.
Ezen valamit segítget néhány SSD pool a Crushmap-ben, meg az SSD journal, de csodát ne várjatok tőle. Mi sokat teszteltük ezt.
A struktúra és filozófia olyan, hogy legaglább 10G ethernet kell közé, és legalább 10-15 node 15k SAS diszkekkel, vagy SSD-kkel.
Azon lehet alkotni.

Ha az van, amit először írtam, a kliens gépeken örülünk ha elérjük a 30-50 Mb/s sebességet summázva.

A 10Gbit igazabol alap barmilyen storage halozat eseteben, ahol nem harom webszervert kell kiszolgalni, hanem folyamatos terheles van (50-100+ gepes virtualizacio alatti storage pl. tipikusan ilyen).

Excegnel natur DRBD-iSCSI alapokon epitettunk ilyesmit, es ha nem 10 Gbit volt alatta, akkor szemmel lathatatlan volt a teljesitmenye (ertsd: a rajzolt csiga az szelsebes volt hozza kepest). A belso storage kommunikacio mindenkepp 10 Gbit kell legyen, de - terhelestol fuggoen - lehet, hogy a node-okkal valo kommunikaciot is celszeru nem csigabittel megoldani.
--
Blog | @hron84
Üzemeltető macik

( STP | 2015. 07. 06., h – 23:29 )

Két kérdésem lenne ezzel kapcsolatban;
1) mivel többen is 1x SSD cache-t emlegetnek, van e tapasztalat ha a cache device elhalálozik?
2) Infiniband-del használja e valaki?