Onderwerp: Ceph - Beginners vraagjes

Ik ben nu al een paar dagen met Ceph aan het spelen en ik ben een beetje stomverbaasd van de robuustheid van het ding.. Je moet echt al wel heel veel doen om het naar de kloten te helpen zoals we dat in België zeggen..

Nu heb ik echter toch wel een aantal vragen waar ik mee zit:

-> Wanneer we gewone servers in RAID 1 zetten op SSDs dan mixen we steeds disken van 2 vendors door elkaar. Op onze Ceph omgeving hebben we zoals aanbevolen de Journal disk op een SSD gezet en de OSDs zo gemaakt dat deze de SSD als journal disk gebruiken. Echter valt die journal disk weg dan vallen ook meteen al je bijhorende OSDs weg en is je 'node' dus plat zeg maar. Ceph rebuilt dat wel mooi maar ik zat hier dan te denken. In een 3 node cluster gaan dan de Journal SSDs niet quasi allemaal op hetzelfde moment gaan falen waardoor je het risico loopt dat alles down gaat ?
Kun je op een of andere manier 2 journal disks steken in een node en 2 disken gebruiken om je OSDs naar te laten journalen zodat je er steeds toch eentje mag verliezen op je node ?

->Oké, mijn journal disk is kapot , al mijn OSDs zijn down. Ik installeer vervolgens een nieuwe journal disk maar dan lijkt het niet zo eenvoudig te zijn om al die OSDs terug online te krijgen. Ceph heeft ondertussen op de achtergrond het cluster al mooi herbouwt dus het eenvoudigste lijkt mij om alle OSDs te wipen en vervolgens gewoon nieuwe OSDs aan te maken op die node en mee terug in de cluster te trekken.. Ceph gaat terug herbalanceren en klaar..
Enige nadeel hier is dat dit herbalanceren wel een impact heeft op performance natuurlijk..
Maar ik vermoed dat er een andere betere procedure is die minder impact heeft op de omgeving dan mijn botte oplossing..

-> Ik zou eens heel graag de performance van die setup testen, wat is de meest 'aanbevolen' manier om dit te doen ?

Dat was precies wel een heel botte oplossing :-)

Je kan deze test's gebruiken

I/O test: wget https://www.janyksteenbeek.nl/linux/iotest.sh -O - -o /dev/null|bash

IOPS test: wget https://www.janyksteenbeek.nl/linux/iops.sh -O - -o /dev/null|bash

Netwerk test: wget https://www.janyksteenbeek.nl/linux/bench.sh -O - -o /dev/null|bash

CPU test: wget https://www.janyksteenbeek.nl/linux/sysbench.sh -O - -o /dev/null|bash

Bron: https://www.janyksteenbeek.nl/linux/

Ik zou geen raid gebruiken als ik jou was.
Je kan binnen ceph instellen hoe vaak je data wilt repliceren.

Oorspronkelijk geplaatst door bibawa

Ik ben nu al een paar dagen met Ceph aan het spelen en ik ben een beetje stomverbaasd van de robuustheid van het ding.. Je moet echt al wel heel veel doen om het naar de kloten te helpen zoals we dat in België zeggen..

Nu heb ik echter toch wel een aantal vragen waar ik mee zit:

-> Wanneer we gewone servers in RAID 1 zetten op SSDs dan mixen we steeds disken van 2 vendors door elkaar. Op onze Ceph omgeving hebben we zoals aanbevolen de Journal disk op een SSD gezet en de OSDs zo gemaakt dat deze de SSD als journal disk gebruiken. Echter valt die journal disk weg dan vallen ook meteen al je bijhorende OSDs weg en is je 'node' dus plat zeg maar. Ceph rebuilt dat wel mooi maar ik zat hier dan te denken. In een 3 node cluster gaan dan de Journal SSDs niet quasi allemaal op hetzelfde moment gaan falen waardoor je het risico loopt dat alles down gaat ?
Kun je op een of andere manier 2 journal disks steken in een node en 2 disken gebruiken om je OSDs naar te laten journalen zodat je er steeds toch eentje mag verliezen op je node ?

->Oké, mijn journal disk is kapot , al mijn OSDs zijn down. Ik installeer vervolgens een nieuwe journal disk maar dan lijkt het niet zo eenvoudig te zijn om al die OSDs terug online te krijgen. Ceph heeft ondertussen op de achtergrond het cluster al mooi herbouwt dus het eenvoudigste lijkt mij om alle OSDs te wipen en vervolgens gewoon nieuwe OSDs aan te maken op die node en mee terug in de cluster te trekken.. Ceph gaat terug herbalanceren en klaar..
Enige nadeel hier is dat dit herbalanceren wel een impact heeft op performance natuurlijk..
Maar ik vermoed dat er een andere betere procedure is die minder impact heeft op de omgeving dan mijn botte oplossing..

-> Ik zou eens heel graag de performance van die setup testen, wat is de meest 'aanbevolen' manier om dit te doen ?

1. Geen raid-1 gebruiken, dat is verspilling van ruimte en doet de performance weinig goed. Iedere disk maak je een raid-0 van (anders willen sommige raid controllers de disk niet herkennen) en iedere disk een losse OSD. Dit geeft je meer snelheid, meer ruimte en ceph doet replicatie over meer disken.

2. Ik zou nu juist de journal wél op een raid-1 zetten precies om de redenen die jij noemt.

3. Testen zou ik met FIO doen, daar komen de meest betrouwbare resultaten uit:
https://wiki.mikejung.biz/Benchmarki...n_Ubuntu_14.10

Alle disken staan inderdaad allemaal als losse RAID-0 sets ingesteld had ik zo ook begrepen :-) Die journal disken in een RAID-1 setup is dan misschien inderdaad wel een goeie tip ! Maar dan heb ik mijn servers wel te klein genomen kunnen nu maar 6 disken in en eentje ervan is de bootdisk van Proxmox.. Of is dat te riskeren dat te draaien van een interne USB/SD / SATADOM ?

Kleine impressie van de beperkte test setup :-)

Een beetje afhankelijk van je set-up zal je over de loop van tijd nodes bijplaatsen, en dan is het niet nodig om een RAID-1 set-up van je journals te maken (ze zullen dan immers niet meer tegelijk stuk gaan, voor zover dat überhaupt het geval is). Ik zou de bootdisk inderdaad op een USB/SATADOM zetten.

Wat betreft de penalty wanneer je journal wegvalt, dat hangt helemaal van je set-up af. Als je genoeg Ceph nodes hebt (en je aan de aanbevolen set-up qua aantal disks hebt gehouden e.d.) + dat je hele dikke netwerkverbindingen tussen je nodes hebt, merk je niks van het herstellen van Ceph als er een node wegvalt.

Oorspronkelijk geplaatst door bibawa

Maar dan heb ik mijn servers wel te klein genomen kunnen nu maar 6 disken in en eentje ervan is de bootdisk van Proxmox.. Of is dat te riskeren dat te draaien van een interne USB/SD / SATADOM ?

Niet te druk om maken. Wij draaien sommige nodes vanaf een SD kaart waar ook de journals op staan Stelt niets voor.

- - - Updated - - -

Oorspronkelijk geplaatst door SF-Jeroen

Wat betreft de penalty wanneer je journal wegvalt, dat hangt helemaal van je set-up af. Als je genoeg Ceph nodes hebt (en je aan de aanbevolen set-up qua aantal disks hebt gehouden e.d.) + dat je hele dikke netwerkverbindingen tussen je nodes hebt, merk je niks van het herstellen van Ceph als er een node wegvalt.

Ons cluster is 156TB op 5 nodes met allen 2x 10Gbit. Bij uitval of reboot van één node merk je inderdaad niet heel veel. Maar toen ik slim dacht te zijn en 2 nodes ging patchen en rebooten merkte je toch wel dat hij het er wat moeilijker mee had

Oorspronkelijk geplaatst door CharlieRoot

Niet te druk om maken. Wij draaien sommige nodes vanaf een SD kaart waar ook de journals op staan Stelt niets voor.

- - - Updated - - -



Ons cluster is 156TB op 5 nodes met allen 2x 10Gbit. Bij uitval of reboot van één node merk je inderdaad niet heel veel. Maar toen ik slim dacht te zijn en 2 nodes ging patchen en rebooten merkte je toch wel dat hij het er wat moeilijker mee had

Mag ik vragen welke servers je hiervoor gebruikt? Heb je hier losse servers voor, of bijvoorbeeld een R710 voor virtualisatie en daar direct ceph in (zoals proxmox dat doet)?

Oorspronkelijk geplaatst door Peter Bin

Mag ik vragen welke servers je hiervoor gebruikt? Heb je hier losse servers voor, of bijvoorbeeld een R710 voor virtualisatie en daar direct ceph in (zoals proxmox dat doet)?

Losse servers (HP DL380 en Dell R720) voor Ceph met 2x 10Gbit per server op een dedicated fiber switch. Virtualisatie helemaal los daarvan op andere nodes.

En Ceph kun je altijd (ook met Proxmox) los draaien:
https://pve.proxmox.com/wiki/Ceph_Server

The Ceph storage services are usually hosted on external, dedicated storage nodes. Such storage clusters can sum up to several hundreds of nodes, providing petabytes of storage capacity.

Zo gaan wij er ook mee beginnen, ceph en proxmox samen en moet zeggen dat gaat wel goed..
Enkel had ik beter wat grotere servers genomen ipv R610's 6 disken is krap per server..

Oorspronkelijk geplaatst door CharlieRoot

Losse servers (HP DL380 en Dell R720) voor Ceph met 2x 10Gbit per server op een dedicated fiber switch. Virtualisatie helemaal los daarvan op andere nodes.

En Ceph kun je altijd (ook met Proxmox) los draaien:
https://pve.proxmox.com/wiki/Ceph_Server

Dank voor je reactie.

Wat zou een reden zijn om Proxmox en Ceph niet op één node te draaien, buiten wat CPU verlies om? Ik begrijp dat het fijn is om zaken te scheiden, maar ben benieuwd of het hier goed te merken is.

Oorspronkelijk geplaatst door Peter Bin

Dank voor je reactie.

Wat zou een reden zijn om Proxmox en Ceph niet op één node te draaien, buiten wat CPU verlies om? Ik begrijp dat het fijn is om zaken te scheiden, maar ben benieuwd of het hier goed te merken is.

Ik werk niet met Proxmox maar ik zou nooit mijn virtuele laag willen combineren met storage, al is het maar voor mijn overzicht en administratie. Dingen gescheiden houden maakt zoeken naar een issue eenvoudiger, garandeert de performance en zorgt dat dingen niet door elkaar lopen. Ieder zijn voorkeur.

@CharlieRoot , @ SF-Jeroen

Ondertussen ben ik zelf aardig opgeschoten met het Ceph cluster en begint eea echt wel 'te werken' en begin ik zelf ook wel door te hebben hoe het achterliggend allemaal wat in elkaar haakt. Maar toch graag even bevestiging van de correctheid van de setup en vooral hoe ik die crushmap gemaakt heb (boeiende materie..)

3 fysieke hosts met elk 4 OSDs in, gesplits over 2 racks:

Rack-E10 -> Prox11 + Prox12
Rack-E13 -> Prox13

Als ik een ceph OSD weight draai dan zie ik mooi de volgende structuur onstaan welke ook correct is, de weight van elke osd = 1 omdat elke disk 1TB is (stond zo in de ceph docu dat weight 1 = 1TB.. )

Code:

ID WEIGHT  TYPE NAME                UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 3.00000 pool distributed-storage
-5 2.00000     rack rack-E10
-2 4.00000         host prox11
 0 1.00000             osd.0             up  1.00000          1.00000
 1 1.00000             osd.1             up  1.00000          1.00000
 2 1.00000             osd.2             up  1.00000          1.00000
 3 1.00000             osd.3             up  1.00000          1.00000
-3 4.00000         host prox12
 4 1.00000             osd.4             up  1.00000          1.00000
 5 1.00000             osd.5             up  1.00000          1.00000
 6 1.00000             osd.6             up  1.00000          1.00000
 7 1.00000             osd.7             up  1.00000          1.00000
-6 1.00000     rack rack-E13
-4 4.00000         host prox13
 8 1.00000             osd.8             up  1.00000          1.00000
 9 1.00000             osd.9             up  1.00000          1.00000
10 1.00000             osd.10            up  1.00000          1.00000
11 1.00000             osd.11            up  1.00000          1.00000

In de toekomst zullen er uiteraard meer nodes toegevoegd worden, maar wat ik dus wil bereiken is dat de data replicated opgeslagen is tussen racks E13 en rack E10 zodat bij uitval van een volledig rack alles nog blijft doordraaien

Ik heb hiervoor een pool 'distributed-storage' aangemaakt als volgt, met daarin de 2 fysieke racks:

Code:

pool distributed-storage {
        id -1           # do not change unnecessarily
        # weight 2.000
        alg straw
        hash 0  # rjenkins1
        item rack-E10 weight 2.000
        item rack-E13 weight 1.000
}

Vervolgens heb ik hier een ruleset aan gekoppeld:

Code:

rule distributed {
        ruleset 0
        type replicated
        min_size 1
        max_size 10
        step take distributed-storage
        step chooseleaf firstn 0 type host
        step emit
}

En het is hier in deze laatste rule waar ik de parameters mi n_size 1 en max_size 10 niet goed geinterpreteerd krijg, uit de ceph documentatie leidt ik af dat wanneer een pool minder dan min_size replicas maakt of meer dan max_size replicas maakt hij deze rule skipt.
Maar wat bedoelt men da juist met een 'replica' slaagt dit op het volgende ?

Code:

root@prox11:/tmp# ceph osd dump | grep -E 'distributed-storage'
pool 2 'distributed-storage' replicated size 3 min_size 1 crush_ruleset 0 object_hash rjenkins pg_num 8 pgp_num 8 last_change 75 flags hashpspool stripe_width 0

Is het dan juist wanneer ik in simpele woorden zeg "repliceer alle data naar 3 nodes en zorg ervoor dat wanneer er slechts 1 bereikbaar is alles nog werkt ? " ?

Wil dit dan zeggen dat wanneer je op termijn extra nodes toevoegd je deze parameter moet aanpassen waarbij replicated size = aantal nodes in je cluster ?

Is er een manier om bevestigd te zien dat data effectief gesplitst staat over de 2 racks ?

Toch nog wat onduidelijkheid :-)

Waar staan je Ceph monitors? Want die draaien een soort van Paxos (consensus protocol), wat met een quorum werkt. Er moet altijd een meerderheid
van je monitors online zijn (bij 3 dus 2, bij 5 dus 3 enzovoort). Als die dus op je OSD-nodes zelf draaien zal normaal gezien je E13 rack read-only worden
wanneer E10 down is. Als je dat anders in de configuratie probeert te hacken (waarbij je aangeeft dat 1 node online voldoende is) krijg je waarschijnlijk een situatie dat bij een split tussen die 2 racks je split-brain data krijgt (beide delen zullen writes accepteren op dezelfde data).

RedHat geeft in de recommendations aan dat je eigenlijk minimaal 6 Ceph OSD nodes moet hebben en 3 monitors (welke wel op een Ceph node mogen staan).

Bedankt voor de feedback !

Momenteel zijn het inderdaad maar 3 nodes , maar naarmate ons vmware cluster gaat slinken komen die er weer bij in beide racks.. maar als ik het dan goed begrijp kan ik best 1 monitor nog in een 3de rack steken ? (2-2-1)Aangezien je met 2 racks in het slechtste geval nooit een meerderheid kan halen ?



Net dit artikel nog gevonden http://www.admin-magazine.com/HPC/Ar...nd-Ceph-Part-2

Daarin staat oa die min en max size wat uitgelegd en daaruit concludeer ik ook dat m'n crushmap momenteel verkeerd is en dat ik in de rule de bucket op rack ipv host moet zetten .. (step chooseleaf...)