Dus, je wilt een Ceph cluster bouwen?

Ik ben een grote fan van Ceph, de open-source, massaal schaalbare software-gedefinieerde opslag oplossing. Het vermogen om zichzelf te herstellen en om te gaan met anders traumatische clustergebeurtenissen (oh, je bent een node kwijt? geen probleem!), gecombineerd met het ontbreken van single points of failure, maakt het een favoriet van mij.

Hieronder staan drie eenvoudige principes die kunnen helpen bij het ontwerp van grote of kleine clusters.

Als je je vooral richt op dollars per megabyte opslagruimte, dan ga je natuurlijk voor de servers met het grootste aantal schijven en de grootste schijven die je kunt krijgen.

Doe hier voorzichtig aan. Er zijn een paar overwegingen bij ‘smalle en diepe’ clusters:

1. Elke node bevat een groter percentage van de gegevens van je cluster. Voorbeeld: in een cluster met drie knooppunten bevat elk knooppunt 33% van uw gegevens. In een cluster met tien node’s is dat slechts 10% per node. Het verlies van een enkele node in een klein cluster zal resulteren in aanzienlijk meer gegevensmigratie, vooral wanneer het cluster zich begint te vullen, en mogelijk een uitval als u de volledige en bijna-vol ratio’s van uw cluster niet correct hebt geconfigureerd.
2. Het forceren van meer netwerkverkeer over minder nodes. Ceph is een netwerk-gebaseerd opslagsysteem, dus met minder nodes dwing je veel client verkeer over minder NICs. Dit wordt erger naarmate het aantal schijven per node toeneemt, omdat je meer OSD’s hebt die strijden om beperkte bandbreedte. Erger nog, tijdens recovery-events concurreert uw recovery-verkeer met client-I/O over uw netwerk, wat de gebruikerservaring verder beïnvloedt.
3. Bij een hoog aantal schijven per node kan de schijfcontroller een knelpunt vormen als deze niet voldoende bandbreedte heeft om al uw schijven op volle snelheid te transporteren.
4. Toenemende herstel- en hersteltijd wanneer u een volledige node verliest, omdat meer gegevens moeten worden gerepliceerd en hersteld.

De geaggregeerde clusterprestaties schalen zeer goed naarmate het aantal nodes toeneemt. Hier vindt u een vergelijking van een 3-node vs 5-node cluster met BlueStore.

Als u een groot cluster nastreeft, weersta dan de verleiding om alle schijven in zo weinig mogelijk nodes te proppen.

Om samen te vatten:

• Ceph schaalt zeer goed als het aantal nodes toeneemt.
• Het hebben van te weinig nodes in het cluster plaatst meer van uw clusterdata op elke node, waardoor de I/O en hersteltijden toenemen.
• U kunt beginnen met slechts drie nodes, maar als u het zich kunt veroorloven om uw schijven over meer nodes te verspreiden, is het beter om dat te doen.

Ben royaal met de netwerken

Het heeft geen zin om snelle media in een server te stoppen en ze vervolgens te hinderen met een 1GbE netwerkverbinding. Streef minimaal naar 10GbE voor productie, en beter nog, kijk of je meerdere 10Gb interfaces kunt binden met Link Aggregation Control Protocol (LACP) voor meer bandbreedte. Ceph is een netwerkgebaseerd opslagsysteem, dus één ding waar het cluster geen gebrek aan mag hebben is netwerkbandbreedte.

Scheid altijd uw publiek-facing netwerk van uw interne clusternetwerk. Het publieke netwerk zal client verkeer dragen, terwijl het interne netwerk heartbeat, replicatie en herstel verkeer tussen OSD’s zal dragen. Als u de NIC’s kunt missen, draag deze twee netwerken dan over afzonderlijke interfaces. Door ze te scheiden wordt de responsiviteit voor clients tijdens recovery events verbeterd, en worden recovery events sneller voltooid omdat recovery I/O niet concurreert met client I/O op dezelfde NIC.

Bedenk ook dat het interne netwerk je replicatieverkeer vervoert, dus elke schrijfactie op het publieke netwerk zal (n-1) schrijfacties op het interne netwerk veroorzaken, waarbij n het aantal replica’s is. Ceph zal een schrijf aan de client alleen bevestigen als het naar het journaal/WAL’s van alle replica’s is geschreven – dus je wilt niet dat de replicatieschrijven een knelpunt vormen op het netwerk. Als je veel gebruik maakt van gerepliceerde pools, overweeg dan om je clusternetwerk n-1 keer groter te maken dan het publieke netwerk.

Ten slotte, voor redundantie, zorg ervoor dat je je nodes bekabeld naar redundante top of rack switches. Je wilt niet een hele node – of set van nodes – verliezen omdat een enkele switch faalt!

Om samen te vatten:

• 10Gbit Ethernet voor productie op een minimum.
• Scheid uw openbare en clusternetwerken, idealiter op verschillende NIC’s, maar op zijn minst in verschillende VLAN’s/subnetten.
• Houd rekening met de (n-1) vuistregel voor gerepliceerde gegevens – overweeg de dimensionering van uw interne netwerk om n-1 keer groter te zijn dan het openbare.
• Vergeet niet te bekabelen voor redundantie, en uw verbindingen correct op te zetten op het niveau van het besturingssysteem.
• En als extraatje: vergeet jumbo frames op uw interfaces niet!

Flash media voor BlueStore metadata.

Ceph erkent een write naar de client pas als de data naar het write-ahead log (WAL) van het primaire OSD en naar de WAL’s van alle replica’s is geschreven. Dus, hoe sneller de schrijf naar de WAL, hoe sneller Ceph de schrijf zal bevestigen, en hoe beter de schrijf IOPS voor de client.

Uw WAL’s, en idealiter uw BlueStore RocksDB metadata, moeten op de snelste media staan die u kunt krijgen – SSD op zijn minst, en NVMe indien mogelijk. Als je een full-HDD cluster bouwt, overweeg dan sterk om per node wat extra uit te geven en minstens twee snelle media devices toe te voegen voor metadata en WAL.

Om knelpunten op je snelle media device te voorkomen, overweeg de aanhoudende schrijfsnelheid van je data schijven en vergelijk het met de aanhoudende schrijfsnelheid van je snelle device. Als uw HDD kan schrijven met 100MB/s aanhoudend, en uw SSD kan 500MB/s aanhoudend aan, dan zal meer dan 4-5 OSD’s per SSD een knelpunt vormen voor de SSD voor schrijven. NVMe is perfect voor dit gebruik, gezien hun aanhoudende schrijfsnelheden kunnen oplopen tot in de gigabytes per seconde.

Ten slotte, heb altijd meer dan één SSD / NVMe-apparaat per node voor metadata / WAL om ervoor te zorgen dat u niet alle OSD’s op de node verliest als een metadata-apparaat uitvalt.

Om samen te vatten:

• Ceph erkent een schrijf naar een client wanneer deze is geschreven naar de WAL van de primaire OSD en de WAL’s van alle replica’s. Het doet dit om de integriteit van uw gegevens te bewaren.
• WAL en RocksDB moeten op de snelste media staan die u kunt krijgen – idealiter NVMe – om zo snel mogelijk een reactie op de client te krijgen.
• Schrijf uw snelle apparaten niet te veel voor uw WAL/RocksDB. Als u dat doet, verschuift u gewoon de bottleneck naar uw snelle apparaat.
• Heb meer dan één snel apparaat om te voorkomen dat u alle OSD’s op een knooppunt verliest als uw WAL-apparaat faalt.

Samenvattend

Ceph is een netwerkgebaseerd software-gedefinieerd opslagsysteem dat uitzonderlijk goed horizontaal schaalt. Hierboven zijn slechts een paar principes om u te helpen een systeem met hoge prestaties samen te stellen – ga niet te smal of diep, houd het cluster gevoed met bandbreedte, en gebruik snelle media voor uw metadata en WAL.