Onderwerp: Ceph als SAN

Beste Whters,

Ik lees veel over Ceph en heb hier en daar al wat opgezet om te testen. Het is een mooi en uitgebreid systeem waaraan nog wekelijks geupdate word, wat mooi is. Nu vraag ik me echter af, word Ceph tegenwoordig ook al veel gebruikt als SAN, al dan niet met bijv SSD's? Volgens mij draait PCextreme erop, maar ik vraag me af of meerdere dit al gebruiken.

Indien het door je gebruikt word, gebruik je het dan meer als backup oplossing/data opslag, of echt als je 'enterprise storage' voor bijv je virtuele machines? Heb je al issues meegemaakt wat in dit geval alles offline trok? Hoe is de performance met veel iops i.p.v grotere datatransfers?

Ben benieuwd als je het aantal iops omhoog drukt doordat je een gedeelte op SSD's draait, of de capaciteit tussen de nodes dit dan ook trekt als je start met meerdere 1 GBps links. Iemand met deze dingen al ervaring?

Bedankt alvast voor je antwoord.

1 Gbps links zijn eigenlijk geen optie. Vooral omdat de latency dan veel hoger is. Alles wordt naar 3 (*) nodes gesynced voordat een write wordt geacked, dus als je latency ook maar iets hoger is gaan je iops drastisch omlaag. In principe is Ceph stabiel, zolang je maar de recovery/healing heel erg capped, anders zou (indien je weinig Ceph nodes hebt) de recovery/healing je storage zeer traag kunnen maken. Recommended is sowieso minimaal 5-6 Ceph nodes.

Je kunt de journals van Ceph op SSD opslaan, waardoor je tragere /grotere disks kunt gebruiken voor je echte storage.






* 2 is ook mogelijk, en eventueel opties als erasure coding

Oorspronkelijk geplaatst door SF-Jeroen

1 Gbps links zijn eigenlijk geen optie. Vooral omdat de latency dan veel hoger is. Alles wordt naar 3 (*) nodes gesynced voordat een write wordt geacked, dus als je latency ook maar iets hoger is gaan je iops drastisch omlaag. In principe is Ceph stabiel, zolang je maar de recovery/healing heel erg capped, anders zou (indien je weinig Ceph nodes hebt) de recovery/healing je storage zeer traag kunnen maken. Recommended is sowieso minimaal 5-6 Ceph nodes.

Je kunt de journals van Ceph op SSD opslaan, waardoor je tragere /grotere disks kunt gebruiken voor je echte storage.






* 2 is ook mogelijk, en eventueel opties als erasure coding

Bedankt voor je heldere uitleg! Zijn er ook al mensen die eigenlijk 'alles' op SSD's hebben opgeslagen? Ik kan me voorstellen dat voor minder belangrijke doeleinden je bijv desktop SSD's kan inzetten met een grote vorm van redundantie als je veel IOP's wil. Een 10Gbps link is dus een must have begrijp ik, wil je willen kunnen werken met kleine snelle writes.

Worden de IOP's ook goed geloadbalanced? Stel een stukje data staat op NODE1 en word ontzettend veel aangevraagd(hot block), terwijl NODE2 eigenlijk weinig tot geen IOP's heeft. Word er dan gekeken om dit stukje data te verdelen over NODE1 en NODE2 als voorbeeld, zoals bijvoorbeeld DELL doet?

Ceph slaat alles in 4 MB objecten op. Even heel grof gezegd: Als je dus een bestand van 3 MB opslaat wordt dat bij reads vanaf 1 osd (dus 1 disk gelezen). Er zijn geen parallele reads in Ceph, dus de 2 replicas worden niet gebruikt voor reads. Als je meer dan 4 MB opslaat wordt het automatisch verdeeld over meerdere osd's, en heb je dus ook meer read iops.

Of er ook geloadbalanced wordt door replicas te promoten naar primary wanneer deze overloaded zijn weet ik niet. Hiervan zijn wel blueprints, maar of die al in Hammer zitten: geen idee.

Bedankt voor je uitleg! Ik begreep dat als je met iscsi werkt, je grotere blokken aanmaakt en daarin de data stopt. Volgens mij worden die blokken dan weer opgehakt in stukjes van 4MB en dus vanaf meerdere nodes tegelijk geleverd. Dit zal er dan langzaamaan voorzorgen dat je een lichte vorm van loadbalancing hebt, denk ik.

Misschien kan @Wido ons dit uitleggen. Ik zie dat hij erg betrokken is bij Ceph en zie de naam steeds vaker opduiken op fora en het internet. Zo te zien is die lid op het forum. Zou leuk zijn als die de info wil delen

Tja, hier kan ik een héél verhaal gaan schrijven over Ceph en wat het doet.

Het klopt dat de Aurora Compute cloud van PCextreme op Ceph draait. Dat is een 700TB omgeving bestaande uit 52 machines verdeeld over 3 kasten.

Vergeet iSCSI en NFS, Ceph praat zijn eigen protocol met de naam RADOS.

Ceph werkt intern volledig met objecten. Standaard worden block devices in stukjes van 4MB objecten opgehakt en elk 4MB object krijgt zijn unieke plek in het cluster.

IOps worden niet gebalanceerd in het cluster. Dat lijkt in het begin leuk, maar je moet Ceph veel verder dan dat trekken. Ceph is vooral goed in grotere omgevingen en dan doel ik direct op minimaal 10 machines waar je het op draait.

Je I/O balanceren gebeurd doordat je veel clients er voor hebt staan. Die clients doen de I/O verzoeken richting al je verschillende servers en zo zie je uiteindelijk een redelijk nette verdeling over al je nodes heen.

Wat hier boven terecht wordt aangegeven is dat je met 10Gbit aan de slag moet. 10Gbit heeft een veel lagere latency dan 1Gbit en dat merk je héél erg met Ceph. Hoe minder latency hoe beter.

Ik zou als ik jou was een paar filmpjes op Youtube kijken om een beter idee te krijgen: https://www.youtube.com/user/inktankstorage

Oorspronkelijk geplaatst door Wido

Tja, hier kan ik een héél verhaal gaan schrijven over Ceph en wat het doet.

Het klopt dat de Aurora Compute cloud van PCextreme op Ceph draait. Dat is een 700TB omgeving bestaande uit 52 machines verdeeld over 3 kasten.

Vergeet iSCSI en NFS, Ceph praat zijn eigen protocol met de naam RADOS.

Ceph werkt intern volledig met objecten. Standaard worden block devices in stukjes van 4MB objecten opgehakt en elk 4MB object krijgt zijn unieke plek in het cluster.

IOps worden niet gebalanceerd in het cluster. Dat lijkt in het begin leuk, maar je moet Ceph veel verder dan dat trekken. Ceph is vooral goed in grotere omgevingen en dan doel ik direct op minimaal 10 machines waar je het op draait.

Je I/O balanceren gebeurd doordat je veel clients er voor hebt staan. Die clients doen de I/O verzoeken richting al je verschillende servers en zo zie je uiteindelijk een redelijk nette verdeling over al je nodes heen.

Wat hier boven terecht wordt aangegeven is dat je met 10Gbit aan de slag moet. 10Gbit heeft een veel lagere latency dan 1Gbit en dat merk je héél erg met Ceph. Hoe minder latency hoe beter.

Ik zou als ik jou was een paar filmpjes op Youtube kijken om een beter idee te krijgen: https://www.youtube.com/user/inktankstorage

Ik heb 0,0 Ceph ervaring, maar met wat je hier zegt (en wat ik meen te weten van Ceph) verwacht ik dat het erg/relatief slecht zal zijn in dingen als korte IO transacties . (stat, create,misschien locking ), en dat storage die met heel kleine latency een diskblok kan benaderen (lokale disk, of FC ) daarin veel sneller zal zijn Ceph.

Klopt dat ?

Oorspronkelijk geplaatst door visser

Ik heb 0,0 Ceph ervaring, maar met wat je hier zegt (en wat ik meen te weten van Ceph) verwacht ik dat het erg/relatief slecht zal zijn in dingen als korte IO transacties . (stat, create,misschien locking ), en dat storage die met heel kleine latency een diskblok kan benaderen (lokale disk, of FC ) daarin veel sneller zal zijn Ceph.

Klopt dat ?

Klopt volledig. Alles gaat over het netwerk heen en wordt berekend.

Ceph haal zijn performance uit veel parallele I/O. Serieële I/O, denk aan databases, is Ceph niet de beste in.

Cloud workloads waar heel veel VMs op je storage staan te hameren is een perfecte use-case voor Ceph. Maar om je MySQL databases 100.00 IOps te geven vanaf NVM-Express SSD's niet.

Ceph is super interessant, maar soms lopen we nog wel eens tegen zaken aan wat we niet kunnen oplossen. We komen met de RADOS gateway agent bijvoorbeeld problemen tegen waar we de foutmelding alleen van kunnen terug vinden in de broncode. Dat is vervelend, maar misschien niet zo zeer gerelateerd aan Ceph zelf, want dat draait eigenlijk gewoon goed. Ook met de RADOS gateway zelf als object store gaat het goed, maar die federated config krijgen we niet stabiel.

Oorspronkelijk geplaatst door getUP

Ceph is super interessant, maar soms lopen we nog wel eens tegen zaken aan wat we niet kunnen oplossen. We komen met de RADOS gateway agent bijvoorbeeld problemen tegen waar we de foutmelding alleen van kunnen terug vinden in de broncode. Dat is vervelend, maar misschien niet zo zeer gerelateerd aan Ceph zelf, want dat draait eigenlijk gewoon goed. Ook met de RADOS gateway zelf als object store gaat het goed, maar die federated config krijgen we niet stabiel.

De RADOS Gateway zie ik zelf niet als onderdeel van Ceph, het is eerder een project wat gebruik maakt van Ceph.

Ik ben zelf vaak wel goed bekend met de source, dus daar zoek ik alles in op. Maar ik begrijp wel wat je bedoeld idd.

Ceph zelf is in ieder geval lekker stable. Laatst nog een >1PB cluster gebouwd en dat ging perfect!

Oorspronkelijk geplaatst door Wido

Tja, hier kan ik een héél verhaal gaan schrijven over Ceph en wat het doet.

Het klopt dat de Aurora Compute cloud van PCextreme op Ceph draait. Dat is een 700TB omgeving bestaande uit 52 machines verdeeld over 3 kasten.

Vergeet iSCSI en NFS, Ceph praat zijn eigen protocol met de naam RADOS.

Ceph werkt intern volledig met objecten. Standaard worden block devices in stukjes van 4MB objecten opgehakt en elk 4MB object krijgt zijn unieke plek in het cluster.

IOps worden niet gebalanceerd in het cluster. Dat lijkt in het begin leuk, maar je moet Ceph veel verder dan dat trekken. Ceph is vooral goed in grotere omgevingen en dan doel ik direct op minimaal 10 machines waar je het op draait.

Je I/O balanceren gebeurd doordat je veel clients er voor hebt staan. Die clients doen de I/O verzoeken richting al je verschillende servers en zo zie je uiteindelijk een redelijk nette verdeling over al je nodes heen.

Wat hier boven terecht wordt aangegeven is dat je met 10Gbit aan de slag moet. 10Gbit heeft een veel lagere latency dan 1Gbit en dat merk je héél erg met Ceph. Hoe minder latency hoe beter.

Ik zou als ik jou was een paar filmpjes op Youtube kijken om een beter idee te krijgen: https://www.youtube.com/user/inktankstorage

Bedankt voor de reacties allen
Draaien alle VM's samen op de cloud niet juist erg veel korte io's? Gaat het cluster hier wel goed mee om? Ik neem aan dat hier ook bepaalde sites op draaien met noemenswaardige mysql databases en vraag me dan af hoe dit performeert bijv. Maak je hier al reeds veel gebruik van SSD's, of is het enkel journals op SSD en de normale storage op SAS/SATA disks? 52 Machines is een mooie grote wolk, al is gehad dat er één of meerdere machines uitvielen? Bleef alles netjes reageren, of was er een grote drop/latency merkbaar? Heb eigenlijk nog geen ervaring met indien een node uitvalt en deze later weer teruggeplaatst word. Kan die dan de missende data aanvullen, of is het de bedoeling dat de node leeg is en hij zodoende als nieuwe node opnieuw gevuld word?

Oorspronkelijk geplaatst door mgerritsen

Bedankt voor de reacties allen
Draaien alle VM's samen op de cloud niet juist erg veel korte io's? Gaat het cluster hier wel goed mee om? Ik neem aan dat hier ook bepaalde sites op draaien met noemenswaardige mysql databases en vraag me dan af hoe dit performeert bijv. Maak je hier al reeds veel gebruik van SSD's, of is het enkel journals op SSD en de normale storage op SAS/SATA disks? 52 Machines is een mooie grote wolk, al is gehad dat er één of meerdere machines uitvielen? Bleef alles netjes reageren, of was er een grote drop/latency merkbaar? Heb eigenlijk nog geen ervaring met indien een node uitvalt en deze later weer teruggeplaatst word. Kan die dan de missende data aanvullen, of is het de bedoeling dat de node leeg is en hij zodoende als nieuwe node opnieuw gevuld word?

In de cloud kom je van alles qua I/O tegen. Het cluster kan er prima mee overweg, maar bij distributed storage moet je nooit de performance als die van local storage verwachten.

Databases kan je ook horizontaal schalen, dus meerdere naast elkaar dan één grote. Zo doe je dat ook op de "cloud manier". Daar komt je performance en beschikbaarheid uit.

SSD's maken we gebruik van. Zowel voor journals als voor opslag, wisselt per disk die je kiest.

Uiteraard hebben we meerdere keren uitval mee gemaakt. Je merkt dan wel een latency verhoging en performance drop omdat het cluster moet rebalancen. Naar mate het cluster groter wordt is de impact van een enkele failure kleiner.

En de cache tiering al volwassen Wido? Heb het nog niet geprobeerd, maar de implementatie lijkt me niet ideaal (file uit cold storage moet eerst naar cache laag bij eerste request).

Oorspronkelijk geplaatst door rensariens

En de cache tiering al volwassen Wido? Heb het nog niet geprobeerd, maar de implementatie lijkt me niet ideaal (file uit cold storage moet eerst naar cache laag bij eerste request).

Al wel getest, maar alleen in zeer specifieke situaties in te zetten. Bij VMs moet je het niet doen omdat je cache continue vervuilt raakt.

Ik heb laatst gelezen (weet helaas niet meer waar) dat 10Gbit zelfs al wat te optimistisch is en dat je beter kunt gaan voor 20Gbit, 30Gbit of zelfs 40Gbit. Uiteraard hoe hoger hoe beter en hoe duurder.

Waar het op neer komt is het vooral nog heel veel zelfbouw (vinden veel mensen leuk) en dat het nog behoorlijk wat tijd en kennis kost eer je het stabiel krijgt. Wat wel als voordeel heeft dat het geheel behoorlijk is aan te passen naar eigen wensen in tegenstelling tot de commerciële kant en klare producten op de markt.