Despre ce este vorba :
Dacă vă gândiți sau discutați despre Ceph, cea mai frecventă întrebare care vă vine în minte este “Ce hardware ar trebui să selectez pentru clusterul meu de stocare CEPH?” și da, dacă chiar v-ați gândit la această întrebare în minte, felicitări, se pare că sunteți serios în legătură cu tehnologia Ceph și ar trebui să fiți, deoarece CEPH este viitorul stocării.
Ceph rulează pe hardware Commodity, Ohh Da!!! toată lumea o știe acum. Este conceput pentru a construi un cluster de stocare multi-petabyte, oferind în același timp caracteristici pregătite pentru întreprinderi. Nu există un singur punct de eșec, scalabilitate până la exabytes, autogestionare și autovindecare (economisește costurile operaționale), rulează pe hardware de bază (fără blocare de furnizor, economisește investițiile de capital)
Ceph Overview :-

Singurul cluster de stocare ceph este RADOS (Reliable Autonomic Distributed Object Store). Ceph utilizează puternicul algoritm CRUSH ( Controlled Replication Under Scalable Hashing ) pentru optimizarea plasării datelor , autogestionare și autovindecare. Interfața RESTful este furnizată de Ceph Object Gateway (RGW) aks Rados GateWay, iar discurile virtuale sunt provizionate de Ceph Block Device (RBD)

Ceph Overview – Image Credit : Inktank

# Ceph OSD ( Object Storage Daemons ) stochează datele în obiecte, gestionează replicarea datelor, recuperarea, reechilibrarea și furnizează informații de etapă către Ceph Monitor. Se recomandă utilizarea a 1 OSD pe fiecare disc fizic.
# Ceph MON ( Monitors ) menține starea generală de sănătate a clusterului prin păstrarea stării hărții clusterului, inclusiv a hărții Monitor, a hărții OSD, a hărții Placement Group ( PG ) și a hărții CRUSH. Monitors primește informații de stare de la alte componente pentru a menține hărțile și face să circule aceste hărți către alte noduri Monitor și OSD.
# Ceph RGW ( Object Gateway / Rados Gateway ) Interfață API RESTful compatibilă cu Amazon S3 , OpenStack Swift .
# Ceph RBD ( Raw Block Device ) Oferă stocare în bloc pentru VM / bare metal precum și pentru clienții obișnuiți , suportă OpenStack și CloudStack . Include caracteristici Enterprise cum ar fi snapshot , thin provisioning , compresie.
# CephFS ( File System ) stocare distribuită POSIX NAS.
Câteva reguli de bază :-

• Executați OSD pe un nod de stocare dedicat ( server cu mai multe discuri ) , datele reale sunt stocate sub formă de obiecte.
• Executați Monitorul pe un hardware dedicat separat sau coexistă cu noduri client ceph ( altele decât nodul OSD ) cum ar fi RGW , nodul CephFS . Pentru producție se recomandă rularea Monitoarelor pe servere dedicate cu costuri reduse, deoarece Monitoarele nu sunt mari consumatoare de resurse.

Configurarea hardware a Monitorului :-
Monitorul menține starea de sănătate a întregului cluster , acesta conține jurnalele PG și jurnalele OSD . Se recomandă un minim de trei noduri de monitoare pentru un cvorum de cluster. Nodurile de monitorizare Ceph nu sunt mari consumatoare de resurse, acestea pot funcționa bine cu cpu și memorie destul de scăzute. Un server 1U cu un procesor low cost E5-2603, 16GB RAM și o rețea 1GbE ar trebui să fie suficient în majoritatea cazurilor. În cazul în care jurnalele PG, Monitor și OSD sunt stocate pe discul local al nodului monitor , asigurați-vă că aveți o cantitate suficientă de stocare locală astfel încât să nu se umple.
Clusterele nesănătoase necesită mai multă stocare pentru jurnale , poate ajunge până la GB și chiar sute de GB dacă clusterul este lăsat nesănătos pentru o perioadă foarte lungă de timp . Dacă ieșirea verbose este setată pe nodurile de monitorizare, atunci acestea sunt obligate să genereze o cantitate uriașă de informații de logare. Consultați documentația ceph pentru setarea jurnalului de monitorizare.
Se recomandă să rulați monitorul pe noduri îndepărtate mai degrabă pe toate pe un singur nod sau pe mașini virtuale pe mașini fizice separate pentru a preveni un singur punct de eșec.
Etapa de planificare :-
Desfășurarea unui cluster ceph în producție necesită un pic de temă pentru acasă, ar trebui să adunați informațiile de mai jos, astfel încât să puteți proiecta un cluster ceph mai bun, mai fiabil și mai scalabil care să se potrivească nevoilor dumneavoastră IT. Acestea sunt foarte specifice nevoilor dumneavoastră și mediului dumneavoastră IT. Aceste informații vă vor ajuta să vă proiectați mai bine cerința de stocare.

• Exigențe de afaceri
• Buget ?
• Aveți nevoie de clusterul Ceph pentru funcționarea de zi cu zi sau SPECIAL
• Exigențe tehnice
• Ce aplicații vor rula pe clusterul dvs. ceph?
• Ce tip de date vor fi stocate pe clusterul dvs. ceph ?
• Ar trebui ca clusterul ceph să fie optimizat pentru capacitate și performanță?
• Ce capacitate de stocare utilizabilă ar trebui să fie?
• Ce rată de creștere preconizată?
• Câte IOPS ar trebui să suporte clusterul?
• Cât de mult debit ar trebui să suporte clusterul
• Cât de multă replicare a datelor ( nivel de fiabilitate ) aveți nevoie?

Colectați cât mai multe informații în timpul etapei de planificare , acestea vor oferi toate răspunsurile necesare pentru a construi un cluster ceph mai bun.
Nodul fizic și tehnica de clusterizare:-
În plus față de informațiile colectate mai sus , luați în considerare, de asemenea, densitatea rack-ului și bugetul de energie , costul ritmului spațiului centrului de date pentru a dimensiona configurația optimă a nodurilor. Ceph a replicat datele pe mai multe noduri într-un cluster de stocare pentru a asigura redundanța datelor și o disponibilitate mai mare. Este important să se ia în considerare.

• Ar trebui ca nodul replicat să se afle pe același rack sau pe mai multe rack-uri pentru a evita SPOF?
• Ar trebui ca traficul OSD să rămână în interiorul rack-ului sau să se extindă pe rack-uri într-o rețea dedicată sau partajată?
• Câte defecțiuni ale nodurilor pot fi tolerate?
• Dacă nodurile sunt separate pe mai multe rafturi, traficul de rețea crește și ar trebui să se ia în considerare impactul latenței și numărul de salturi ale comutatorului de rețea.

# Mediul POC – Poate avea un minim de 3 noduri fizice cu 10 OSD-uri fiecare. Acest lucru asigură o disponibilitate a clusterului de 66% în cazul unei defecțiuni a unui nod fizic și un timp de funcționare de 97% în cazul unei defecțiuni OSD. Nodurile RGW și Monitor pot fi puse pe noduri OSD, dar acest lucru poate avea un impact asupra performanței și nu este recomandat pentru producție.
# Mediu de producție – un minim de 5 noduri separate fizic și minim 100 OSD @ 4TB pe OSD capacitatea clusterului este de peste 130TB și asigură o disponibilitate de 80% în cazul unei defecțiuni a nodului fizic și 99% în cazul unei defecțiuni a OSD. RGW și monitoarele ar trebui să se afle pe noduri separate.
În funcție de rezultatul etapei de planificare și a nodurilor fizice și a etapei de clusterizare, aruncați o privire asupra hardware-ului disponibil pe piață, în funcție de buget.
Selecția CPU OSD :-
< În curs de realizare … Stay Tuned >