Waar het allemaal over gaat :
Als je denkt of discussieert over Ceph, de meest voorkomende vraag die in je opkomt is “Welke Hardware Moet Ik Kiezen Voor Mijn CEPH Storage Cluster ?” en ja als je echt dacht aan deze vraag in je hoofd, gefeliciteerd je lijkt serieus te zijn over Ceph technologie en dat zou je moeten zijn want Ceph IS DE TOEKOMST VAN STORAGE.
Ceph draait op Commodity hardware, Ohh Yeah !! iedereen weet het nu. Het is ontworpen om een multi-petabyte storage cluster te bouwen terwijl het enterprise ready features biedt. Geen enkel punt van mislukking, schalen tot exabytes, zelfbeheer en zelfgenezing (bespaart operationele kosten), draait op commodity-hardware (geen vendor locking, bespaart kapitaalinvestering)
Ceph Overzicht :-

De enige van ceph opslag cluster is RADOS (Reliable Autonomic Distributed Object Store). Ceph maakt gebruik van krachtige CRUSH ( Controlled Replication Under Scalable Hashing ) algoritme voor het optimaliseren van gegevens plaatsing , zelf te beheren en zelf te genezen. De RESTful interface wordt geleverd door Ceph Object Gateway (RGW) aks Rados GateWay en virtuele schijven worden geleverd door Ceph Block Device (RBD)

Ceph Overview – Image Credit : Inktank

# Ceph OSD ( Object Storage Daemons ) slaat gegevens op in objecten, beheert gegevensreplicatie, herstel, herbalancering en levert etappe-informatie aan Ceph Monitor. Het wordt aanbevolen om 1 OSD per fysieke schijf te gebruiken.
# Ceph MON ( Monitors ) houdt de algehele gezondheid van het cluster bij door de clustermap-status bij te houden, waaronder Monitor map , OSD map , Placement Group ( PG ) map , en CRUSH map . Monitors ontvangt state informatie van andere componenten om maps te onderhouden en deze maps te circuleren naar andere Monitor en OSD nodes.
# Ceph RGW ( Object Gateway / Rados Gateway ) RESTful API interface compatibel met Amazon S3 , OpenStack Swift .
# Ceph RBD ( Raw Block Device ) Biedt Block Storage aan VM / bare metal en reguliere klanten , ondersteunt OpenStack en CloudStack . Bevat Enterprise-functies zoals snapshot , thin provisioning , compressie.
# CephFS ( File System ) gedistribueerde POSIX NAS-opslag.
Weinig vuistregels :-

• Uitvoeren OSD op een speciale opslagknooppunt ( server met meerdere schijven ) , de werkelijke gegevens worden opgeslagen in de vorm van objecten.
• Uitvoeren Monitor op een aparte speciale hardware of naast ceph client nodes ( andere dan OSD node ), zoals RGW , CephFS node . Voor productie wordt aanbevolen om monitoren op speciale goedkope servers uit te voeren, aangezien monitoren geen hulpbronnen nodig hebben.

Monitor Hardware Configuratie :-
Monitor houdt de gezondheid van het gehele cluster bij, het bevat PG-logboeken en OSD-logboeken. Een minimum van drie monitornodes wordt aanbevolen voor een quorum van het cluster. Ceph monitor nodes zijn niet resource hongerig ze kunnen goed werken met vrij lage cpu en geheugen. Een 1U server met een goedkope processor E5-2603, 16GB RAM en een 1GbE netwerk zou in de meeste gevallen voldoende moeten zijn. Als PG-, Monitor- en OSD-logs worden opgeslagen op de lokale schijf van het monitorknooppunt, zorg er dan voor dat je voldoende lokale opslag hebt, zodat deze niet volloopt.
Ongezonde clusters hebben meer opslagruimte voor logs nodig, die kan oplopen tot GB en zelfs honderden GB als het cluster voor een zeer lange tijd ongezond wordt gelaten. Als verbose output is ingesteld op monitor nodes, dan zijn deze gebonden aan het genereren van grote hoeveelheden logging informatie. Raadpleeg de ceph documentatie voor monitor log instellingen.
Its aanbevolen om monitor op verafgelegen nodes uit te voeren in plaats van op alle op één node of op virtuele machines op fysiek gescheiden machines om single point of failure te voorkomen.
De planningsfase :-
Het uitrollen van een ceph cluster in productie vereist een beetje huiswerk, u moet de onderstaande informatie verzamelen zodat u een beter en betrouwbaarder en schaalbaar ceph cluster kunt ontwerpen dat in uw IT behoeften past. Deze zijn zeer specifiek voor uw behoeften en uw IT omgeving. Deze informatie zal u helpen om uw opslagvereiste beter te ontwerpen.

• Business Requirement
• Budget ?
• Heeft u Ceph cluster nodig voor dagelijks gebruik of SPECIAL
• Technical Requirement
• Welke toepassingen zullen er op uw ceph cluster draaien ?
• Welke soort data zal op uw ceph cluster worden opgeslagen ?
• Wordt het ceph cluster geoptimaliseerd voor capaciteit en performance ?
• Wat zou de bruikbare opslagcapaciteit moeten zijn ?
• Wat is de verwachte groeisnelheid ?
• Hoeveel IOPS moet het cluster ondersteunen ?
• Hoeveel doorvoer moet het cluster ondersteunen
• Hoeveel data replicatie ( betrouwbaarheidsniveau ) heb je nodig ?

Verzamel zoveel mogelijk informatie tijdens de planningsfase , het zal alle antwoorden geven die nodig zijn om een beter ceph cluster te construeren.
De fysieke node en clusteringstechniek:-
Naast de hierboven verzamelde informatie, moet ook rekening worden gehouden met de rackdichtheid en het stroombudget , de kosten van het tempo van de ruimte in het datacenter om de optimale nodeconfiguratie te bepalen. Ceph repliceert gegevens over meerdere nodes in een opslagcluster om redundantie van gegevens en een hogere beschikbaarheid te bieden. Het is belangrijk om te overwegen.

• Moet de gerepliceerde node zich in hetzelfde rack of in meerdere racks bevinden om SPOF te voorkomen?
• Moet het OSD-verkeer binnen het rack blijven of zich over het rack uitstrekken in een speciaal of gedeeld netwerk?
• Hoeveel storingen van nodes kunnen worden getolereerd?
• Als de nodes over meerdere racks zijn verspreid, neemt het netwerkverkeer toe en moet de impact van latency en het aantal netwerk switch hops worden overwogen.
Ceph zal zich automatisch herstellen door data van de falende nodes opnieuw te kopiëren met behulp van secundaire kopieën die op andere nodes in het cluster aanwezig zijn. Een defecte node heeft dus verschillende effecten.
• De totale capaciteit van het cluster wordt met enkele fracties verminderd.
• De totale doorvoer van het cluster wordt met enkele fracties verminderd.
• Het cluster gaat een schrijf zwaar herstelproces in.

Een algemene vuistregel om de hersteltijd in een ceph cluster te berekenen gegeven 1 schijf per OSD node is :
Hersteltijd in seconden = schijfcapaciteit in Gigabits / ( netwerksnelheid *(nodes-1) )

# POC-omgeving – Kan minimaal 3 fysieke nodes met elk 10 OSD’s hebben. Dit biedt 66% clusterbeschikbaarheid bij uitval van een fysieke node en 97% uptime bij uitval van een OSD. RGW en Monitor nodes kunnen op OSD nodes worden gezet maar dit kan de performance beïnvloeden en wordt niet aanbevolen voor productie.
# Productie omgeving – een minimum van 5 fysiek gescheiden nodes en een minimum van 100 OSD @ 4TB per OSD de cluster capaciteit is meer dan 130TB en biedt 80% uptime bij een fysieke node storing en 99% uptime bij een OSD storing. RGW en monitoren moeten zich op afzonderlijke nodes bevinden.
Gebaseerd op de resultaten van de planningsfase en de fysieke nodes en clusteringfase bekijkt u de hardware die op de markt verkrijgbaar is volgens uw budget.
OSD CPU-selectie :-
< Onder constructie … Blijf op de hoogte >