Ceph teszt #3 snapshotting

Nos, a helyzet az, hogy azt látom, kezd terjedni a cucc (ceph), több helyről látok próbálkozásokat.

A jelenlegi felállásban csinálunk egy KVM/libvirt alapú virtualizációt, amely jelenleg kernel RBD modul alatt importálja be az OSD-ket (rbd pool), majd ezeken futnak a virtuális gépek.

Szívás volt az IDE emulációval, ugye szereti a libvirt a virtio megoldásokat, amelyhez azoban pl. Windows VM alatt drivert kellett telepíteni.
Jobban szeretjük a sima "drive" (azaz IDE) diszk emulációt, teszteink alapján a performancia nem rossz.
Eme két típusnál próbálgatjuk a VM save funkciót, amely érdekes módon jól működik, de csak offline.

A qcow típusú diszkeknél az online snapshot remek! Pillanatok alatt készíti a snapshotokat online, és pl. Windows alatt tesztelve egy "revert" online (!) visszanyomja a régi verziót a VM-re, ami nagyon cool cucc. Hatalmas performancia romlást realizálnak ennél a diszk típusnál, egyelőre ezt a mi szintünkön még nem látjuk, nincs nagy különbség.

Hajrá ceph! :)

( kmARC v | 2014. 12. 20., szo – 21:31 )

> amely jelenleg kernel RBD modul alatt importálja be az OSD-ket (rbd pool), majd ezeken futnak a virtuális gépek.

Van qemu patch is ehhez, miert nem azt hasznaljatok? Direktbe tud a qemu librbd-n keresztul beszelni a clusterral.
http://ceph.com/docs/v0.71/rbd/qemu-rbd/

( NagyZ v | 2014. 12. 21., v – 13:26 )

a sima ide driverrel szar lesz a performancia, ha kicsit is komolyabb diszk alrendszer megy ra; illetve 3.17-es kerneltol van multi-queue support a virtio driverben (18-tol pedig be lehet kapcsolni sima SATA diszkekre is mindenfele hackeles nelkul)

mekkora a clusteretek?

Igen, ezt is tudjuk. jelenleg a testfázisban elég ez, kényelmesebb.

Több klaszterünk is van, tesztelési céllal most építünk egy sima 3 fizikai gépes Ceph klasztert SATA RAID1 OSD-kkel, illetve minden gépen SSD journal-lal. Ez utóbbi ügyben neked vannak tapasztalataid, szívesen várjuk a tuning lehetőségeket.
A hálózati része 2xGigabit Ethernet lesz (bond) Etherchanellel klaszternode-onként. Maga a konfig pár 100e Ft-ból összehozható, lesz rajta kb. 2 Tbyte szabad kapacitás Ceph-FS-nek és RBD-nek. Azt még nem látjuk, hogy pl. CephFS poolonként hogyan méretezhető - azaz fix méretet lásson belőle a kliens - ha van ötlet, itt is várjuk.

Maga a klaszter egy Cloudstack/KVM alapját fogja képviselni, ez is folyamatban van.

Azt akarod mondani, hogy alkalmazzunk raid0-t (vagy különálló diszkeket) az adattárolásra?
Korábban raid0 volt, hogy sebesség legyen, ott figyelni kellett arra, hogy ne essen szét a tömb, de a különálló diszkes (vagy lvm stripe-os) megoldást is használtuk.
De el is mondhatod, te mit javasolsz?

semmifele raidet nem kell hasznalni*. siman a diszkeket oda kell adni neki, mint osd; majd a ceph foglalkozik a replikacioval. mar masik topicban is volt ilyen teveszme, hogy kell ala raid, csak azt tudnam, honnan szeditek? :)

*: egyetlen elonye lehet egy _egy_ diszkes RAID0-nak: be lehet kapcsolni rajta a write cachet normalis raid kontrollerrel, es igy a journal write latencyje kisebb lesz.

Persze az, hogy mi a "téveszme", a gyakorlat mutatja. Kinek ez, kinek az.
A raid1 előnye hogy diszkhiba esetén nem kell a node-ot leállítani hoszabb időre, és az olvasási sebesség akár még jobb is lehet, mint különálló diszkes esetben. Egyébként egyetértek, bízzuk a Ceph-re a replikációt, csak sajna nem nagyon látsz bele abba egy nagyobb klaszternél, mit hova (melyik node-ra) replikál a Ceph, így nem tudod skálázni a különálló diszkes esetben a performanciát, csak saccolgatsz. Persze ez sajna a raid-es osd-knél is néha igaz, ekkor jön az, amit először írtam.

nem a gyakorlat, a ceph architectura...

miert kell leallitani diszkcserehez a gepet? regi diszk ki, uj be, osd-t kicserelni, es kesz.

_teljes_ kontrollod van a folott, hogy mi, mikor, hova van replikalva. a crush mapet ugy alakitod, ahogy akarod. mit jelent a nagy cluster, es milyen konkret problemad volt vele, amit nem tudtal megoldani? (marmint a replikacio elhelyezeset illetoen)

tekintve hogy az ajanlott az, hogy a teljes diszket add oda osd-nek, igy nem ertem, hogy az OS mit keres rajta. az kulon raid1en van, a ceph osd-k pedig a kulon diszkek...

elobb meg azt mondtad, hogy nem latod, hogy mit, hova replikal, most pedig azt, hogy nem is akarod tudni. ellentmondast erzek felfedezni :)

Persze, hogy ajánlott, de hát szegény ember vízzel főz, nem mindenhol van +2 diszk a boot-ra. Soxor alkalmaztuk a raid1 boot + osd diszk megoldást, probléma nélkül. (illetve hát te is említetted, minek pazarolni a tárhelyet... lehet a boot diszkeken is osd tároló)

Második megjegyzésedre: nem ellentmondás, csak lustaság....

Apropó? A journal-t te kiteszed SSD partícióra? Van ötleted az optimális méretének beállítsára? Márcsak azért is, mert 80 Gb SSD-tnem akaruk teljesen mértékben elpazarolni...

ezt csak te tudhatod, marmint, hogy mekkora a jo neked. attol fugg, mekkora savszelt tudnak a gepek kitolni az SSD-krol. a doksiban van erre vonatkozolag keplet, ha jol remlik.

nem pazarlas, journalnak hasznalod. sot, mivel gondolom a "kis penz, kis foci" elv alapjan nem S3700-at hasznaltok, igy nem is baj, ha nincs masra hasznalva, foleg egy ilyen pici SSD.

( vfero v | 2014. 12. 26., p – 00:21 )

1, Ketyeg még az összeállítás? ;)
2, Kösz a post-ot!
3, sub
vfero

pl. az, hogy lehetőségeinkhez képest próbálunk erősíteni az egyszerű core2duo-s sata-s deszktop gépeken.
Első lépésben hardveresen (ssd, 2xGigabitEthernet, gyorsabb sata diszkek, több ram, profibb switch, etherchannel), majd később szoftveresen (jumbo frame, filerendszer és egyéb tuning opciók, stb.).