PDA

Bekijk Volledige Versie : Ceph als SAN



mgerritsen
05/05/15, 23:30
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;).

SF-Jeroen
06/05/15, 09:19
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

mgerritsen
06/05/15, 11:16
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?

SF-Jeroen
06/05/15, 14:04
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.

mgerritsen
06/05/15, 15:24
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:)

Wido
06/05/15, 15:41
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

visser
06/05/15, 16:53
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 ?

Wido
06/05/15, 17:15
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.

ju5t
06/05/15, 17:32
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.

Wido
06/05/15, 18:08
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!

mgerritsen
06/05/15, 23:13
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?

Wido
07/05/15, 01:14
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.

rensariens
07/05/15, 11:24
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).

Wido
07/05/15, 11:33
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.

Barend
08/05/15, 14:19
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.

Wido
08/05/15, 14:30
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.

Bij storage gaat het vooral om latency. De latency van 10Gbit is gauw 4x zo laag als die van 1Gbit, maar 40Gbit is weer niet significant sneller dan 10Gbit.

De bandbreedte is het probleem eigenlijk nooit bij storage, latency, latency, latency.

Overigens kan je Ceph ook als product kant en klaar kopen. Fujitsu en SanDisk verkopen gewoon appliances.

Grote omgevingen zoals CERN en Yahoo! draaien inmiddels al op Ceph en nog velen gaan volgen. Het is een serieuze concurrent voor EMC, NetApp en EqualLogic.

Pantsy
08/05/15, 17:34
Equallogic? Die komt in de verste verte niet in de buurt van Ceph als je het mij vraagt kwa functionaliteit. Je vergeet wel 3PAR naar mijn mening ;)

NibeP
26/11/15, 21:00
Bumpje. Wist niet zo goed of ik hier een nieuw topic voor moest aanmaken.

Welke hardware gebruiken jullie voor Ceph en wat voor disks?

RayManZ
27/11/15, 09:15
Volgens dit artikel: http://www.ispam.nl/archives/54967/storage-stories-de-cloudomgeving-van-pcextreme/

De cloudomgeving draait op hardware van Supermicro. Er wordt een mix gebruikt van HDD en SSD. Voor de HDD’s worden schijven van Western Digital en Seagate door elkaar gebruikt. Wat betreft de SSD’s wordt er weliswaar nog Samsung gebruikt maar hoofdzakelijk zijn ze van Intel. Dit merk blijkt het betrouwbaarst, aldus Den Hollander.

Hij vertelt verder dat dit geen enterprise drives zijn maar consumer grade producten. “De HDD’s zijn gewone 7200 rpm schijven van 3TB. De reden om consumentendrives te gebruiken is dat Ceph de opslag regelt. Ceph is gebouwd voor falende hardware en ondervangt het uitvallen van schijven. Daarom is ook geen dure RAID hardware nodig.” Het is duidelijk dat Ceph aanzienlijke besparingen op de investeringen
mogelijk maakt.

CharlieRoot
27/11/15, 12:23
Bumpje. Wist niet zo goed of ik hier een nieuw topic voor moest aanmaken.

Welke hardware gebruiken jullie voor Ceph en wat voor disks?

Wij hebben een opstelling gemaakt met HP Proliant DL380Gen9 servers, hier passen SAS en SSD disken in. Wij gebruiken nu 900GB SAS en de performance is fenomenaal. Reden dat wij voor de 380 hebben gekozen is het aantal disken wat er in kan, zeer flexibel en uitbreidbaar. Daarnaast heeft dit model 4x 1Gbps ethernet die we als LACP trunk configureren. Andere optie is die vervangen voor 2x 10Gbps.

NibeP
27/11/15, 12:28
Bedankt voor jullie reacties.

Ik zit nog te twijfelen tussen SAS en normale SATA HDD's. Daarnaast gebruik maken van cache tiering met SSD's. Hoeveel IOPS haal je me die 900GB SAS in Ceph, CharlieRoot?

CharlieRoot
27/11/15, 12:39
Bedankt voor jullie reacties.

Ik zit nog te twijfelen tussen SAS en normale SATA HDD's. Daarnaast gebruik maken van cache tiering met SSD's. Hoeveel IOPS haal je me die 900GB SAS in Ceph, CharlieRoot?

Ik heb nog geen test gedaan in het daadwerkelijk aantal IOPS. Zoals Wido- terecht noemt vond ik reactiesnelheid/latency meer van belang. Ik heb een vergelijk gemaakt tussen onze HP EVA (7200rpm disken), HP MSA (SAS15K) en Ceph (SAS15K). Ceph is overduidelijk winnaar in alle opzichten. Ter verduidelijking, wij draaien Xenapp/Terminal servers er op. De gebruiker(s) merken dus álle vertraging voor zover die er is.

Enige wat ik qua IOPS heb gezien (feiten die ik heb) is dat de EVA met 7200rpm schijven stikte bij 3000 iops. De hele load verplaatsen van de EVA naar Ceph zorgde voor éxtreem winst in snelheid/gebruikerservaring en inmiddels is de load minimaal 4 keer zo hoog geworden.

Wido
27/11/15, 15:13
Bumpje. Wist niet zo goed of ik hier een nieuw topic voor moest aanmaken.

Welke hardware gebruiken jullie voor Ceph en wat voor disks?

Klopt, wij gebruiken gewone 3TB 7200RPM disks en gaan voor nieuwe servers naar 4TB. Gewoon de goedkope 7200RPM desktop disks. Faalt er 1, jammer dan, dan vervangen we die.


Bedankt voor jullie reacties.

Ik zit nog te twijfelen tussen SAS en normale SATA HDD's. Daarnaast gebruik maken van cache tiering met SSD's. Hoeveel IOPS haal je me die 900GB SAS in Ceph, CharlieRoot?
Ik zou geen SAS pakken, je kan beter voor die prijs 2x zo veel SATA kopen. Meer opslag en meer IOps. Houdt er wel rekening mee, bij Ceph moet je I/O parallel gaan draaien. Niet 1x bonnie++ starten en je daar op blind staren.

Verder is de cache tiering niet goed bruikbaar samen met de block devices, die vervuilen de cache te veel.

NibeP
10/12/15, 20:10
Bedankt voor de informatie!

Ik zit zelf te denken aan de Dell R320, 2x 10 Gbit en 2x Seagate 4 TB + 2x WD Red 4 TB. Mij lijkt de Dell R320 geschikt, iemand ervaring mee i.c.m. Ceph?

SF-Jeroen
10/12/15, 21:34
Ik zou voor zo goedkoop mogelijke servers gaan met dubbele voeding. WD Red is nu wel wat extreem budget, kies dan liever voor een 7200 rpm model. Wat Wido ook al zegt, Ceph is beter in parallele performance, niet in het behalen van maximale iops. Zeker op writes zal je niet veel meer dan 400 iops halen. Kies wel voor een SSD in elke node als journal met dergelijke trage disks. Dan profiteer je ook meteen van het sequentieel kunnen wegschrijven van data. Ik ben trouwens zelf geen groot fan van de Broadcom NICs van Dell. Ik kies zelf dan eerder voor een Intel of SolarFlare NIC.

NibeP
11/12/15, 01:04
Hmm, ik dacht dat de WD Red 7200 RPM had.. Bedankt voor de scherpe reactie!

Ook de journals op een SSD in elke node is goed om te weten. Ik ben zelf erg fan van Intel, dus er zullen waarschijnlijk Intel kaarten in komen.

Voor de servers moet ik nog even goed kijken.

Marcellow
11/12/15, 09:54
De wd red is naar mijn weten een variabel toerental, de wd red pro is 7200 toeren.
Overigens een prima keuze, heb er bijna 100 van 4 TB in gebruik in leeftijd varierend
tussen de 1 en 2 jaar.
De eerste moet nog kapot gaan, dat gezegd hebbende zal ik wel een drukke week krijgen....

Wido
11/12/15, 10:56
Hmm, ik dacht dat de WD Red 7200 RPM had.. Bedankt voor de scherpe reactie!

Ook de journals op een SSD in elke node is goed om te weten. Ik ben zelf erg fan van Intel, dus er zullen waarschijnlijk Intel kaarten in komen.

Voor de servers moet ik nog even goed kijken.

Zo veel mogelijk kleine servers, dáár komt je performance vandaan.

Je kan kijken naar de Intel S3500, S3700 of eventueel de Samsung SM836 SSD's. Beide kunnen goed overweg met veel writes, dat hebben journals nodig.

Een Ceph cluster draait naar mijn mening pas lekker vanaf 10 fysieke nodes (ex de monitors). Daarna wordt het alleen maar beter als het groter wordt.

Recentelijk een 180 nodes, 1800 disks Ceph cluster gemaakt. Daar voel je één node uit zetten gewoon nagenoeg niet.

NibeP
11/12/15, 11:01
Zo veel mogelijk kleine servers, dáár komt je performance vandaan.

Je kan kijken naar de Intel S3500, S3700 of eventueel de Samsung SM836 SSD's. Beide kunnen goed overweg met veel writes, dat hebben journals nodig.

Een Ceph cluster draait naar mijn mening pas lekker vanaf 10 fysieke nodes (ex de monitors). Daarna wordt het alleen maar beter als het groter wordt.

Recentelijk een 180 nodes, 1800 disks Ceph cluster gemaakt. Daar voel je één node uit zetten gewoon nagenoeg niet.

Bedankt voor de informatie!

Heb je al die servers met 2x 10 Gbit aangesloten?

SF-Jeroen
11/12/15, 11:23
10 Gbps is wel een must. Wij hadden elke Ceph node met 2x 10 Gbps uitgerust en elke hypervisor met 4x 10 Gbps (apart storage netwerk). De switches onderling met 2x 40 Gbps. Wanneer Ceph gaat recoveren trek je de links zo vol.

NibeP
11/12/15, 12:31
10 Gbps is wel een must. Wij hadden elke Ceph node met 2x 10 Gbps uitgerust en elke hypervisor met 4x 10 Gbps (apart storage netwerk). De switches onderling met 2x 40 Gbps. Wanneer Ceph gaat recoveren trek je de links zo vol.

Oke, ik vernam ook dat de latency met glas een groot verschil kan maken. Goed om te weten dat Ceph die links flink zal benutten.

Voor de SSD; hebben jullie hier zowel journal als OS op staan? Als ik een server heb met ruimte voor vier 3.5" disks, kan ik drie benutten voor Ceph storage en dan één voor een SSD (OS+journaal).

Wido
11/12/15, 14:11
Bedankt voor de informatie!

Heb je al die servers met 2x 10 Gbit aangesloten?

Ja, alles is 10Gbit.


Bedankt voor de informatie!

Heb je al die servers met 2x 10 Gbit aangesloten?

En vooral latency. De Latency over 10G is ongeveer 3 tot 4x lager dan via 1G. Dat is wat je wil.

CharlieRoot
11/12/15, 15:27
10 Gbps is wel een must. Wij hadden elke Ceph node met 2x 10 Gbps uitgerust en elke hypervisor met 4x 10 Gbps (apart storage netwerk). De switches onderling met 2x 40 Gbps. Wanneer Ceph gaat recoveren trek je de links zo vol.

Wij draaien alle ceph nodes nu met 4x 1Gbps en tot op heden nog geen enkele issue mee gehad. Hangt natuurlijk wel van het aantal nodes af. Heb je ergens een voorbeeld van de performance winst als je naar 10Gbps gaat? Onze nodes komen nooit boven 2-3 Gbit aan traffic uit (nu)

Wido
11/12/15, 15:42
Wij draaien alle ceph nodes nu met 4x 1Gbps en tot op heden nog geen enkele issue mee gehad. Hangt natuurlijk wel van het aantal nodes af. Heb je ergens een voorbeeld van de performance winst als je naar 10Gbps gaat? Onze nodes komen nooit boven 2-3 Gbit aan traffic uit (nu)

Latency, latency, latency. Dat is het hele verhaal. Bandbreedte is niet zo boeiend, latency wel. Hoe lager, hoe beter

tomadmiraal
11/12/15, 18:17
Dit is een hele mooie topic! Er wordt veel over de disken gesproken en wat hierbij gebruikt wordt, maar wat ik mis is het netwerk gedeelte. Vandaar mijn volgende vraag:

Wat voor nics en switches gebruiken jullie? Gestacked?

Zelf zijn we bezig met het uitrollen van een ceph-clustertje met 22 osd nodes, 44 disken, 3 monitoring nodes en 1 management node.

Op dit moment gaat dit over 2gbit per node. Kan uitgebreid worden naar 4gbit of naar 10gbit. Waar ik hier bijvoorbeeld mee zit is het aantal switchpoorten en hoe dit het beste opgesteld kan worden. Momenteen heb ik hiervoor 2x 48 poorten gestacked.
Wido & SF-Jeroen, wat voor hardware gebruiken jullie voor het netwerk?
CharlieRoot, hoe heb jij je gbit netwerk opgesteld?

CharlieRoot
11/12/15, 18:44
CharlieRoot, hoe heb jij je gbit netwerk opgesteld?
Dat is nogal een vraag. Welk deel? :-)

SF-Jeroen
11/12/15, 23:40
Wij gebruiken Huawei CloudEngine CE6810-48S4Q-EI switches, deze zijn uitgerust met 48x 10 Gbps SFP+ poorten en 4x 40 Gbps QSFP+. Kosten de helft van een Juniper EX4550. Absoluut een aanrader, we hebben ze al maanden onder full load in productie hangen, nog geen enkele issue gezien. Wat betreft NICs, deze zijn vooral Intel 82599 gebaseerd.

Wido
12/12/15, 11:38
Dit is een hele mooie topic! Er wordt veel over de disken gesproken en wat hierbij gebruikt wordt, maar wat ik mis is het netwerk gedeelte. Vandaar mijn volgende vraag:

Wat voor nics en switches gebruiken jullie? Gestacked?

Zelf zijn we bezig met het uitrollen van een ceph-clustertje met 22 osd nodes, 44 disken, 3 monitoring nodes en 1 management node.

Op dit moment gaat dit over 2gbit per node. Kan uitgebreid worden naar 4gbit of naar 10gbit. Waar ik hier bijvoorbeeld mee zit is het aantal switchpoorten en hoe dit het beste opgesteld kan worden. Momenteen heb ik hiervoor 2x 48 poorten gestacked.
Wido & SF-Jeroen, wat voor hardware gebruiken jullie voor het netwerk?
CharlieRoot, hoe heb jij je gbit netwerk opgesteld?

Ik werk veelal als Ceph consultant, bijna de hele week door, dus ik heb nogal wat Ceph cluster gebouwd. Van enkele nodes tot honderden nodes groot.

Welke hardware? SuperMicro, Dell, HP, allemaal gebruikt. Switching zelfde, Cisco, Dell, Extreme Networks, Brocade, ook allemaal gezien.

Ik herhaal het nog een keer: latency, daar wil je op letten. Ook je failure domains. Verspreid je replica's in Ceph over failure domains.

tomadmiraal
12/12/15, 12:39
Dat is nogal een vraag. Welk deel? :-)

Het gedeelte van het netwerk tussen de cephnodes ;)

Wat voor switches heb je er tussen hangen en hoe zijn deze opgesteld? maak je gebruik van pair bonding?

tomadmiraal
12/12/15, 12:42
Wij gebruiken Huawei CloudEngine CE6810-48S4Q-EI switches, deze zijn uitgerust met 48x 10 Gbps SFP+ poorten en 4x 40 Gbps QSFP+. Kosten de helft van een Juniper EX4550. Absoluut een aanrader, we hebben ze al maanden onder full load in productie hangen, nog geen enkele issue gezien. Wat betreft NICs, deze zijn vooral Intel 82599 gebaseerd.

Dank je voor de info. dat ziet er inderdaad netjes uit. Ik begrijp dat jullie alles over glas hebben lopen.

Zit er veel verschil tussen 10gbps over glas en over koper?

Ik neem aan dat je de switches redundant hebt opgesteld. heb je deze gestackt?

CharlieRoot
13/12/15, 15:50
Het gedeelte van het netwerk tussen de cephnodes ;)

Wat voor switches heb je er tussen hangen en hoe zijn deze opgesteld? maak je gebruik van pair bonding?

Op dit moment:
2x HP 5800 switches als stack (20G tussen de twee)

Alle servers aangesloten met:
4x 1Gbps op de twee stacked switches. Hierdoor kunnen we 4Gbps benutten maar bij uitval is altijd nog 2Gbps beschikbaar.

bibawa
13/12/15, 18:39
Ik heb zelf nog niet met Ceph gespeeld maar er al veel over gelezen..
Maar door het feit dat je zoveel nodes nodig hebt, wordt het toch ook een dure grap qua hardware , stroom en colocatie van het geheel? Of wordt dat dan weer goedgemaakt omdat het zo goed is ?

SF-Jeroen
13/12/15, 20:06
Dank je voor de info. dat ziet er inderdaad netjes uit. Ik begrijp dat jullie alles over glas hebben lopen.

Zit er veel verschil tussen 10gbps over glas en over koper?

Ik neem aan dat je de switches redundant hebt opgesteld. heb je deze gestackt?

Ik heb geen ervaring met 10 Gbps over koper, dus dat antwoord moet ik je schuldig blijven. De switches zijn inderdaad gestacked, maar ze ondersteunen ook MLAG. Het is dat we alle andere switches ook als stack hebben draaien, maar anders was ik voor MLAG gegaan. Vooral omdat Juniper (die we ook een hoop hebben) NSSU "toch niet helemaal" blijkt te ondersteunen.

bibawa: Als je nu maar een paar servertjes hebt is het inderdaad duur, maar als je nu al tientallen racks hebt met dure storage appliances dan is het juist heel goedkoop, en belangrijker: schaalbaar. Je NetApp / ZFS server schaalt namelijk niet door qua performance (en maar tot een bepaald getal als je kijkt naar capaciteit.). Ook qua redundancy zit je beter met Ceph. Dus eigenlijk 3 voordelen ;) Overigens is het idee van Ceph dat je zo goedkoop mogelijke hardware gebruikt (maar wel met 2 voedingen!).

NibeP
13/12/15, 21:22
Ik heb geen ervaring met 10 Gbps over koper, dus dat antwoord moet ik je schuldig blijven. De switches zijn inderdaad gestacked, maar ze ondersteunen ook MLAG. Het is dat we alle andere switches ook als stack hebben draaien, maar anders was ik voor MLAG gegaan. Vooral omdat Juniper (die we ook een hoop hebben) NSSU "toch niet helemaal" blijkt te ondersteunen.

bibawa: Als je nu maar een paar servertjes hebt is het inderdaad duur, maar als je nu al tientallen racks hebt met dure storage appliances dan is het juist heel goedkoop, en belangrijker: schaalbaar. Je NetApp / ZFS server schaalt namelijk niet door qua performance (en maar tot een bepaald getal als je kijkt naar capaciteit.). Ook qua redundancy zit je beter met Ceph. Dus eigenlijk 3 voordelen ;) Overigens is het idee van Ceph dat je zo goedkoop mogelijke hardware gebruikt (maar wel met 2 voedingen!).

Ik vraag me af waarom er zo wordt gehamerd op twee voedingen. Als er een node uitvalt, is dat toch niet zo erg?

tomadmiraal
13/12/15, 22:03
Ik vraag me af waarom er zo wordt gehamerd op twee voedingen. Als er een node uitvalt, is dat toch niet zo erg?

Een node die uitvalt is niet erg. Maar als de helft van je cluster uitvalt is dat een ander verhaal. Dus tenzij je 30 verschillende feeds hebt, is het nadig om 2 voedingen te hebben....

NibeP
14/12/15, 11:30
Een node die uitvalt is niet erg. Maar als de helft van je cluster uitvalt is dat een ander verhaal. Dus tenzij je 30 verschillende feeds hebt, is het nadig om 2 voedingen te hebben....

Duidelijk, bedankt!

CharlieRoot
14/12/15, 13:04
Een node die uitvalt is niet erg. Maar als de helft van je cluster uitvalt is dat een ander verhaal. Dus tenzij je 30 verschillende feeds hebt, is het nadig om 2 voedingen te hebben....

Het hele idee achter Ceph is dat je je nodes niet in één kast of op één locatie hangt. Je kunt met de Crushmap instellen dat je 3 sites hebt, per site rooms hebt, per room racks hebt en per rack nodes. Ceph zal op basis van deze zones data gaan plaatsen en dus is uitval van een node of zelfs een rack niet direct meer een issue.

SF-Jeroen
14/12/15, 13:40
Het hele idee achter Ceph is dat je je nodes niet in één kast of op één locatie hangt. Je kunt met de Crushmap instellen dat je 3 sites hebt, per site rooms hebt, per room racks hebt en per rack nodes. Ceph zal op basis van deze zones data gaan plaatsen en dus is uitval van een node of zelfs een rack niet direct meer een issue.

Een node of een rack niet nee, maar als de hele A of B feed in het DC wegvalt heb je dus 50% uitval. Dit jaar nog gebeurd bij ons in het DC (generator startte 1 seconde te langzaam op, en viel daardoor terug op de niet werkende "normale" stroom == 1 feed 40 minuten plat). Ben blij dat ik bijna overal 2 voedingen in had zitten. Meerdere DC's is met Ceph (nog) niet echt mogelijk, omdat er nog geen async replicatie is. Dan moet je (helaas) voor GlusterFS gaan.

CharlieRoot
14/12/15, 14:18
Een node of een rack niet nee, maar als de hele A of B feed in het DC wegvalt heb je dus 50% uitval. Dit jaar nog gebeurd bij ons in het DC (generator startte 1 seconde te langzaam op, en viel daardoor terug op de niet werkende "normale" stroom == 1 feed 40 minuten plat). Ben blij dat ik bijna overal 2 voedingen in had zitten. Meerdere DC's is met Ceph (nog) niet echt mogelijk, omdat er nog geen async replicatie is. Dan moet je (helaas) voor GlusterFS gaan.

Ik zie niet helemaal waarom het niet zou werken met 2 DC's? Daarvoor kun je toch met Zones (Crushmap) werken? Je zult alleen moeten zorgen dat de data altijd over de twee locaties opgeslagen is. Maar misschien lees ik jouw reactie verkeerd.

The-BosS
15/12/15, 02:03
Een node of een rack niet nee, maar als de hele A of B feed in het DC wegvalt heb je dus 50% uitval.

Of je zet 1/3 van je nodes op A feed, 1/3 van je nodes op B feed en 1/3 van je nodes op A+B feed, bespaar je toch al 2/3 uit aan dual voedingen ;).

Nu wat die multiple datacenters betreft zal het veelal ook te maken hebben met de afstand tussen de datacenters neem ik aan, als dit maar 500 meter is zal het uiteraard wel beter werken dan dat er 500 km tussen zit (kwa latency dan).

CharlieRoot
15/12/15, 12:45
Of je zet 1/3 van je nodes op A feed, 1/3 van je nodes op B feed en 1/3 van je nodes op A+B feed, bespaar je toch al 2/3 uit aan dual voedingen ;).

Nu wat die multiple datacenters betreft zal het veelal ook te maken hebben met de afstand tussen de datacenters neem ik aan, als dit maar 500 meter is zal het uiteraard wel beter werken dan dat er 500 km tussen zit (kwa latency dan).

Onze dark-fiber connecties zijn +/- 80 km lang en hebben een latency van 2ms. Het is een beetje afhankelijk van hoe je ceph ontsluit naar je servers toe of je hier de effecten van merkt. Je kunt werken met "controllers", waarop je de volumes mount en doorschiet via iScsi naar de servers. Dan houd je altijd je traffic tussen servers/SAN lokaal (in één DC).

SF-Jeroen
15/12/15, 12:54
Ik snap niet hoe je writes dan binnen 1 DC houdt. Misschien kun je dat nog toelichten? Aangezien Ceph geen async replicatie doet lijkt het me dat deze 2 ms latency hebben, wat het onwerkbaar voor hosting maakt (althans voor onze klanten). Als je bijvoorbeeld videostreaming doet is het natuurlijk een ander verhaal. Of je moet writes op die SAN async wegschrijven naar Ceph, maar dan verlies je door die SAN eigenlijk een hoop voordelen van Ceph.