Sunt un mare fan al Ceph, soluția de stocare definită prin software, open-source și masiv scalabilă. Capacitatea sa de a se autovindeca și de a se descurca în fața unor evenimente de cluster altfel traumatizante (oh, ați pierdut un nod? nicio problemă!), combinată cu lipsa punctelor unice de eșec, o face să fie una dintre favoritele mele.
Mai jos sunt trei principii simple care pot ajuta la proiectarea de clustere mari sau mici.
Dacă obiectivul dvs. principal sunt dolarii pe megabyte de stocare, atunci, în mod natural, s-ar putea să gravitați spre serverele care pot lua cel mai mare număr de discuri, și cele mai mari discuri pe care le puteți obține.
Căutați cu atenție aici. Există câteva considerații cu clusterele „înguste și adânci”:
- Care nod deține un procent mai mare din datele clusterului dumneavoastră. Exemplu: într-un cluster cu trei noduri, fiecare nod deține 33% din datele dumneavoastră. Într-un cluster cu zece noduri, este de numai 10% pe nod. Pierderea unui singur nod într-un cluster mic va avea ca rezultat o migrare a datelor substanțial mai mare, în special pe măsură ce clusterul începe să se umple și, potențial, o întrerupere dacă nu ați configurat corect ratele complete și aproape complete ale clusterului dumneavoastră.
- Forțarea unui trafic de rețea mai mare pe mai puține noduri. Ceph este un sistem de stocare bazat pe rețea, așa că, cu mai puține noduri, forțați o mulțime de trafic client pe mai puține NIC-uri. Acest lucru se înrăutățește pe măsură ce crește numărul de discuri pe nod, deoarece aveți mai multe OSD-uri care concurează pentru o lățime de bandă limitată. Mai rău, în timpul evenimentelor de recuperare, traficul de recuperare concurează cu I/O al clientului pe rețeaua dvs., afectând și mai mult experiența utilizatorului.
- Pentru un număr mare de discuri pe nod, controlerul de discuri poate fi un gât de îmbulzeală dacă nu are suficientă lățime de bandă pentru a transporta toate discurile dvs. la viteză maximă.
- Creșterea timpului de recuperare și vindecare atunci când pierdeți un nod întreg, deoarece mai multe date trebuie să fie replicate și recuperate.
Performanța clusterului agregat se scalează foarte bine pe măsură ce crește numărul de noduri. Aici puteți găsi o comparație între un cluster de 3 noduri și unul de 5 noduri cu BlueStore.
Dacă vizați un cluster mare, rezistați tentației de a împacheta toate discurile în cât mai puține noduri posibil.
Pentru a rezuma:
- Ceph se scalează foarte bine pe măsură ce crește numărul de noduri.
- Având prea puține noduri în cluster plasează mai multe date ale clusterului dvs. pe fiecare nod, crescând I/O de recuperare și timpii de recuperare.
- Puteți începe cu doar trei noduri, dar dacă vă puteți permite să distribuiți discurile pe mai multe noduri, este mai bine să faceți acest lucru.
Să fiți generos cu rețeaua
Nu are rost să puneți medii rapide într-un server și apoi să le împiedicați cu o conexiune de rețea de 1GbE. Țintiți spre 10GbE pentru producție, cel puțin, și mai bine căutați să aveți mai multe interfețe de 10Gb conectate cu Link Aggregation Control Protocol (LACP) pentru o lățime de bandă mai mare. Ceph este un sistem de stocare bazat pe rețea, așa că un lucru de care clusterul nu ar trebui să ducă lipsă este lățimea de bandă a rețelei.
Separați întotdeauna rețeaua publică de rețeaua internă a clusterului dvs. Rețeaua publică va transporta traficul clienților, în timp ce rețeaua internă va transporta traficul de heartbeat, replicare și recuperare între OSD-uri. Dacă vă puteți lipsi de NIC-uri, transportați aceste două rețele pe interfețe separate. Separarea lor îmbunătățește capacitatea de reacție a clienților în timpul evenimentelor de recuperare și ajută la finalizarea mai rapidă a evenimentelor de recuperare, deoarece E/S de recuperare nu concurează cu E/S de client pe aceeași NIC.
Rețineți, de asemenea, că rețeaua internă transportă traficul de replicare, astfel încât fiecare scriere pe rețeaua publică va determina (n-1) scrieri pe rețeaua internă, unde n este numărul de replici. Ceph va confirma o scriere către client doar atunci când aceasta a fost scrisă în jurnalul/WAL al tuturor replicilor – deci nu doriți ca scrierile de replicare să fie blocate în rețea. Dacă utilizați intensiv pool-uri replicate, luați în considerare dimensionarea rețelei clusterului dvs. pentru a fi de n-1 ori mai mare decât rețeaua publică.
În cele din urmă, pentru redundanță, asigurați-vă că vă cablați nodurile la switch-uri redundante de top of rack. Nu doriți să pierdeți un întreg nod – sau un set de noduri – din cauza unei singure defecțiuni a unui singur comutator!
În concluzie:
- 10Gbit Ethernet pentru producție, cel puțin.
- Separați-vă rețelele publice și de cluster, în mod ideal pe NIC-uri diferite, dar cel puțin în VLAN-uri/subrețele diferite.
- Amintiți-vă regula de bază (n-1) pentru datele replicate – luați în considerare dimensionarea rețelei interne pentru a fi de n-1 ori mai mare decât cea publică.
- Nu uitați să vă cablați pentru redundanță și să vă stabiliți corect legăturile la nivelul sistemului de operare.
- Și ca un extra: nu uitați de cadrele jumbo pe interfețele dumneavoastră!
Mediu flash pentru metadatele BlueStore.
Ceph confirmă o scriere către client numai după ce datele au fost scrise în jurnalul write-ahead (WAL) al OSD-ului primar și în WAL-urile tuturor replicilor. Așadar, cu cât este mai rapidă scrierea în WAL, cu atât mai repede Ceph va recunoaște scrierea și cu atât mai bune vor fi IOPS-urile de scriere pentru client.
WAL-urile dvs. și, în mod ideal, metadatele BlueStore RocksDB, ar trebui să fie pe cel mai rapid suport pe care îl puteți obține – SSD cel puțin și NVMe dacă este posibil. Dacă construiți un cluster full-HDD, luați în considerare cu tărie posibilitatea de a cheltui puțin mai mult pe nod și de a adăuga cel puțin două dispozitive media rapide pentru metadate și WAL.
Pentru a evita blocajele pe dispozitivul media rapid, luați în considerare viteza de scriere susținută a discurilor de date și comparați-o cu viteza de scriere susținută a dispozitivului dvs. rapid. Dacă HDD-ul dvs. poate scrie la 100 MB/s susținut, iar SSD-ul dvs. poate gestiona 500 MB/s susținut, atunci mai mult de 4-5 OSD-uri pe SSD și veți fi gâtuit de SSD pentru scriere. NVMe este perfect pentru acest caz de utilizare, având în vedere că vitezele lor de scriere susținută pot ajunge la gigabytes pe secundă.
În cele din urmă, aveți întotdeauna mai mult de un dispozitiv SSD/NVMe pe nod pentru metadate/WAL pentru a vă asigura că nu veți pierde toate OSD-urile de pe nod în cazul în care un dispozitiv de metadate cedează.
Pentru a rezuma:
- Ceph recunoaște o scriere către un client atunci când aceasta a fost scrisă în WAL a OSD-ului primar și în WAL-urile tuturor replicilor. Face acest lucru pentru a păstra integritatea datelor dumneavoastră.
- WAL și RocksDB ar trebui să fie pe cel mai rapid suport pe care îl puteți obține – în mod ideal NVMe – pentru a obține un răspuns către client cât mai repede posibil.
- Nu suprasolicitați dispozitivele rapide pentru WAL/RocksDB. Dacă o faceți, nu faceți decât să mutați gâtul de îmbulzeală către dispozitivul dvs. rapid.
- Aveți mai multe dispozitive rapide pentru a evita pierderea tuturor OSD-urilor de pe un nod dacă dispozitivul dvs. WAL cedează.
Sumând
Ceph este un sistem de stocare definit prin software bazat pe rețea care se scalează orizontal excepțional de bine. Cele de mai sus sunt doar câteva principii care să vă ajute să alcătuiți un sistem de înaltă performanță – nu mergeți prea îngust sau prea adânc, mențineți clusterul alimentat cu lățime de bandă și folosiți medii rapide pentru metadate și WAL.
.