Ceph teszt #1

Nos jónapot. Küzdünk a storage oldali SPOF problémájával, kicsit közelebbről megnéztem a Ceph-et, mint esélyes versenyzőt eme probléma kiküszöbölésére.
Utánaolvasgattam a dolognak és lassan megértettem az elvi alapjait. Mint ismeretes, az Openstack alapját képező klaszterezett (disztributált) filerendszerről van szó, amelybe a Canonical 1 millió dollárt rakott, fejlesztésre.
Node mi is kellett nekem: hát az, hogy a reverse proxy mögötti webszervereinken legyen egy olyan filerendszer, amely nagyjából POSIX kompatibilis, konkurensen írható és ha lehet, még redundáns is. Persze az NFS-en feljnödögélt társadalom aszt mondja, erre ott van ő, mégha azt nehéz is kezelni, ha elszáll az NFS kiszolgáló, akkor a webszervereinkről hova tűnik az adat...Persze itt is van tükrözéses megoldás, meg pl. aktív-aktív DRBD, meg esetlegesen failover dolgok, de ezek nálam mindig valahol elhaláloztak gyakorlati megvalósításnál. Meg aztán nézegettem másokat is, úgymint glusterfs meg xtreemfs meg lustre, de a ceph-nél maradtam, mert biza a feature listája jónak tűnik.

Mondom, összedobok egy ceph klasztert, egyelőre virtuálisan.
A leírás alapján nehézkesnek tűnik a konfig, mert ugye szétválasztható minden funkció, meg van blokkszintú és fileszintű megvalósítási lehetőség is, de így utólag látva már nem is tűnik olyan veszélyesnek. Nos, legalább 3db adat node-ot ajánlanak a ceph-nek, el is helyeztem őket három virtuális gépben, amelyek három különböző hypervisor-on voltak, kettő XCP-n, egy pedig egy régi ESXi 3.5-ön (nehogymár a hypervisor halálakor 1db-nál több ceph node-om halálozzon el:).
Gondoltam, Debian. Nos, itt volt az első bukó, ugyanis legújabb Debian (ekkor: 6.0.5) alá betehető apt repo alól ugyan telepíthető a ceph, de ennek csak a korábbi "argonaut" release-e. Ez pedig akárhogyan is körítem, instabil volt a Debian alapkernellel, egyszerűen panic-os lett egy idő után. Írják is az okosok, ne ezt használjuk. Csak későn vettem észre. Nos akkor Ubuntu. 13.04beta2 server, gondoltam jó lesz, és tényleg, jó lett.
Adtam 5 Gb-ot mindenhol az alaprendszernek, illetve 10 Gb-ot egy másik virtuális diszken a ceph-nek. Fontos már itt megjegyeznem, hogy a ceph diszk ha lehet, erős IO alatt legyen, pl. virtualizált környezetben a lokális diszken (ami nálunk egy IO erős SAS diszk), vagy hasonlón. Nem baj, ha ez elszáll, nem kell redundánsnak lenni (hacsak a sebesség miatt nem - RAID0 csíkozás pl.), a redundanciát úgyis a klaszter adja majd.
Adtam ethernet gigabitet a VM-eknek, amelyen keresztül a VM-ek klaszter felé nyúló hálókarija kommunikál majd a többivel. Lemértem a bandwith-et a kliensek között iperf segítségével, a legrosszabb esetben is 30-40 Mbyte/s volt peer-to-peer, amely nem tűnt rossznak első ránézésre. (hozzáteszem, azért voltak switchek a virtuálisgépek között, nomeg a hálózati emuláció overhead-je). A régi ESXi-n persze feltettem a vmware-tools nevű szépséget az Ubuntura, mint kiderült, az emulált (vmxnet) típusú hálókarihoz kellett is. Ennek a karinak a sebessége többszöröse volt a default (flexible) típusúval szemben. Az XCP alatt nem kellett változtatni.

Node hogy is készült a klaszter, mire figyeltem még, illetve miket tapasztaltam? Ezt majd egy második kiadásban elmesélem, ha érdekel valakit...

( daroczig | 2013. 04. 11., cs – 00:46 )

Mi volt a gond a GlusterFS kapcsán?

( Elbandi v | 2013. 04. 11., cs – 02:11 )

kb 1 honapja tesztelgetem a cephfs reszt. a blokk device mokat (= disk qemu/kvm ala) nem probaltam.
tapasztalatok:
- az elv szinte tokeletes, de a cucc meg erosen alpha valtozat: hibakezeles legtobbszor egy assert(..), kifos sok-sok logot meg dumpot, es elszall.
- monitorbol paratlan kell, 3 eseten ha egy kiesett akkor mar voltak problemak, igy most 5 monitor van. mon kb 1-2 G disket eszik, keves cpu, keves ram. de tilos olyan gepre rakni ahol sok iras van, mert fsyncelget, es ettol beall a gep nagyon pici azt meg a mon nemszereti. virtualis gepben egymagaban jol elvan. viszonylag stabil, ha config valtozas van, akkor szeret elszallni, de restart utan megy rendesen.
- multi mds (set_max_mds X)meg veletlenul se csinalj, meg nem egeszen kiforrott. mds nem ir a diskre, ram viszont kell. _nagyon_ szeret elszallni.
- osd is viszonylag stabil, config valtozasnal (uj mon, uj mds, mds del) neha elpilled, restart utan megy tovabb az elet.
- rohadtul nincsen leirva a doksiban az egyeb parancsok. (set_max_mds, add_data_pool, stb), bele kell nezni a forrasba, ott megtalalhato mik a parancsok.
- mountra van fuse meg nativ kernel modul. elobbi siman megy, csak lassu. utobbihoz leheto legfrisebb kernel (raringban 3.8 van, de linux-image meg linux-image-extra csomag is kell)
- a mount nagyon nemszereti ha bajvan (eltunik mon, mds), van amikor magaba fordul, es csak a reset segit
- osd-ken lehet public/privat halo. ilyenkor az osdk kozotti forgalom a privat halon megy (2-N peldany atkuldese, "rebuild", stb), a kifele meno forgalom a public halon.

nalunk tesztnek 5 osd, dl380 g7, raid5 8 disk, no cache.
- egy szalu iras/olvasas eleg gyer, de ha parhuzamosan megy sok akkor osszeadodik: 1 szalu iras 200-300mbit. 3 szal mar majdnem 1G-t elerte.
- fuse olvasas sok szalon ugy 1G korul van. nativ kernellel ~5G (300 szal)

- ha bugot fogsz, es normalisan bekuldod trackerbe (logok, config, stb), es ha megtalaljak a hibat akkor javitjak. irc is viszonylag aktiv. a programozok LA-ban vannak este 5 es ejjel 2 kozott lehet veluk beszelni.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

ha a mon/mds/osd daemon assertra fut, akkor csinal egy halom logot (backtrace, utolso 1000 uzenet, config, stb), es kilep.
a mountpoint mar rosszab: mivel a addig var amig meglesz az elerheto mon/mds/osd szerver (*) es ezt egy syscallban csinalja, igy az a process D allapotba kerul (kilohetetlen :( ), ha rendbejon a cluster es ezt a cephfs modul is eszreveszi, akkor megy tovabb az elet, de ha nem akkor onnantol mehet a reboot (neha csak reset).

ertelem szeruen ez motani "alpha" allapot miatt ilyen, ha megirjak bele a rendes hibakezelest, meg kigyomlaljak a bugokat, akkor majd jo lesz.

* multi-mds eseten felosztoznak a konyvtarszerkezeten az mds-ek, igy volt olyan hogy egyik konyvtar ment, masik konyvtar meg nem.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Azert kerdeztem, mert ha a processz van olyan rendes, es kitakarodik a hibauzenet utan, akkor esetleg lehet hozza egy monit figyelest irni, ami automatikusan ujra elinditja a megfelelo szervizt. Valami ilyesmire gondoltam: 


# /etc/monit/conf.d/mds
check process mds with pidfile /var/run/ceph/mds.pid
  start program = "/etc/init.d/ceph-mds start"
  stop program  = "/etc/init.d/ceph-mds stop"
  if 5 restart within 5 cycles then timeout

Et cetera.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ez utóbbi esetben kicsit bonyolultabb a helyzet, de ezt majd taglalni fogom a folytatásban. Annyit előre, hogy van egy látencia a fileok és könyvtárak kezelésében, illetve vannak még bugok is, de úgy néz ki, eme utóbbaik nem kritikusak. Pl. egy file törlése esetén ugyan eltűnik a node-okról (1-2s azért van benne), de az objektumtárolóban még foglalja a helyet, így a szabad hely jelzése is érdekessé válhat. Erre történtek javítások, hogy ne kelljen félórákat várni a purgálódásra, illetve ne kelljen restartolni az osd-ket. Persze, vannak még hibás pontok, de ez utóbbi verzióban erősen ráfeküdtek a hiobajavításra és a performancia növelésre.

jah de vicces volt a srac. valtottunk par levelet az elejen, amikor meg nemnagyon akart osszeallni a cucc (meg en is hulyebb voltam). 4 level utan felajanlotta a cegjet, hogy milyen kiralyok tavoli supportot adnak, stb. aham 250$/felora aron. kosz.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

jo ertem en hogy a tudast megkell fizetni, csakhogy nem arra kertem hogy rakjon ossze egy cephfs-t, hanem par parameter optimalis ertekerol. meghat mi nem ibm vagyunk, hanem egy kisceg itt a balkanon, igy nekunk az az ar egy kicsit sok volt.

de a tema szempontjabol ez mar off, aki ki tudja fizetni a 100k-s orabert, batran forduljon Haas kollegahoz

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!


        Iozone: Performance Test of File I/O
                Version $Revision: 3.308 $
                Compiled for 64 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root.

        Run began: Thu Apr 11 13:58:56 2013

        Record Size 4096 KB
        File size set to 4194304 KB
        Command line used: iozone -b results.xls -r 4m -s 4g -t 6 -i 0 -i 1 -i 2
        Output is in Kbytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 Kbytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
        Throughput test with 6 processes
        Each process writes a 4194304 Kbyte file in 4096 Kbyte records

        Children see throughput for  6 initial writers  =  164369.04 KB/sec
        Parent sees throughput for  6 initial writers   =  140913.14 KB/sec
        Min throughput per process                      =   26744.46 KB/sec
        Max throughput per process                      =   28736.76 KB/sec
        Avg throughput per process                      =   27394.84 KB/sec
        Min xfer                                        = 3903488.00 KB

        Children see throughput for  6 rewriters        =  176754.60 KB/sec
        Parent sees throughput for  6 rewriters         =  155923.15 KB/sec
        Min throughput per process                      =   28642.79 KB/sec
        Max throughput per process                      =   30299.46 KB/sec
        Avg throughput per process                      =   29459.10 KB/sec
        Min xfer                                        = 3969024.00 KB

        Children see throughput for  6 readers          =  845228.28 KB/sec
        Parent sees throughput for  6 readers           =  841792.77 KB/sec
        Min throughput per process                      =  138810.48 KB/sec
        Max throughput per process                      =  145167.39 KB/sec
        Avg throughput per process                      =  140871.38 KB/sec
        Min xfer                                        = 4022272.00 KB

        Children see throughput for 6 re-readers        =  852642.17 KB/sec
        Parent sees throughput for 6 re-readers         =  851631.59 KB/sec
        Min throughput per process                      =  139987.23 KB/sec
        Max throughput per process                      =  145284.44 KB/sec
        Avg throughput per process                      =  142107.03 KB/sec
        Min xfer                                        = 4042752.00 KB

        Children see throughput for 6 random readers    =  543067.55 KB/sec
        Parent sees throughput for 6 random readers     =  542913.49 KB/sec
        Min throughput per process                      =   88160.69 KB/sec
        Max throughput per process                      =   94856.21 KB/sec
        Avg throughput per process                      =   90511.26 KB/sec
        Min xfer                                        = 3899392.00 KB

        Children see throughput for 6 random writers    =  171232.25 KB/sec
        Parent sees throughput for 6 random writers     =  144945.15 KB/sec
        Min throughput per process                      =   28173.28 KB/sec
        Max throughput per process                      =   29134.65 KB/sec
        Avg throughput per process                      =   28538.71 KB/sec
        Min xfer                                        = 4059136.00 KB



"Throughput report Y-axis is type of test X-axis is number of processes"
"Record size = 4096 Kbytes "
"Output is in Kbytes/sec"

"  Initial write "  164369.04

"        Rewrite "  176754.60

"           Read "  845228.28

"        Re-read "  852642.17

"    Random read "  543067.55

"   Random write "  171232.25


iozone test complete.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

osd, 2x1G bonding rr-ben (igy ki tudja hajtani a 2G-at). a "client" az 10G.

Most ideglenesen bekapcsoltam a cachet a smart arrayban (25/75 arany, 256M-os rammal): 


        Children see throughput for  6 initial writers  =  280174.19 KB/sec
        Parent sees throughput for  6 initial writers   =  203715.20 KB/sec
        Min throughput per process                      =   44902.63 KB/sec
        Max throughput per process                      =   52192.79 KB/sec
        Avg throughput per process                      =   46695.70 KB/sec
        Min xfer                                        = 3612672.00 KB

        Children see throughput for  6 rewriters        =  278966.02 KB/sec
        Parent sees throughput for  6 rewriters         =  240915.91 KB/sec
        Min throughput per process                      =   45897.35 KB/sec
        Max throughput per process                      =   48636.66 KB/sec
        Avg throughput per process                      =   46494.34 KB/sec
        Min xfer                                        = 3960832.00 KB

        Children see throughput for  6 readers          =  705150.75 KB/sec
        Parent sees throughput for  6 readers           =  704476.78 KB/sec
        Min throughput per process                      =  116517.86 KB/sec
        Max throughput per process                      =  118721.60 KB/sec
        Avg throughput per process                      =  117525.12 KB/sec
        Min xfer                                        = 4120576.00 KB

        Children see throughput for 6 re-readers        =  696220.31 KB/sec
        Parent sees throughput for 6 re-readers         =  695585.27 KB/sec
        Min throughput per process                      =  113932.77 KB/sec
        Max throughput per process                      =  117291.01 KB/sec
        Avg throughput per process                      =  116036.72 KB/sec
        Min xfer                                        = 4079616.00 KB

        Children see throughput for 6 random readers    =  577164.52 KB/sec
        Parent sees throughput for 6 random readers     =  576846.08 KB/sec
        Min throughput per process                      =   93131.39 KB/sec
        Max throughput per process                      =  100922.02 KB/sec
        Avg throughput per process                      =   96194.09 KB/sec
        Min xfer                                        = 3874816.00 KB

        Children see throughput for 6 random writers    =  275476.05 KB/sec
        Parent sees throughput for 6 random writers     =  231065.98 KB/sec
        Min throughput per process                      =   44582.47 KB/sec
        Max throughput per process                      =   47736.16 KB/sec
        Avg throughput per process                      =   45912.68 KB/sec
        Min xfer                                        = 3919872.00 KB



"Throughput report Y-axis is type of test X-axis is number of processes"
"Record size = 4096 Kbytes "
"Output is in Kbytes/sec"

"  Initial write "  280174.19

"        Rewrite "  278966.02

"           Read "  705150.75

"        Re-read "  696220.31

"    Random read "  577164.52

"   Random write "  275476.05


iozone test complete.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( LGee | 2013. 04. 11., cs – 15:13 )

OCFS2? Vagy csak nem figyeltem, es az nem tudja valamelyik feature-t?

( kmARC v | 2013. 04. 11., cs – 18:44 )

Csak ne ezt a leírást bővítsd-toldozd-foldozd, mert azt mindig nehéz követni, ha lehet. "Ceph teszt, #n", az elején linkekkel a régi bejegyzésre sokkal ügyesebb.

( NagyZ v | 2013. 07. 17., sze – 11:19 )

nekialltam cephezni en is, majd bloggolok rola.