Acest articol a fost scris pentru a vă ajuta să alegeți soluția potrivită pentru dvs. și să înțelegeți diferențele dintre SDS, cum ar fi Gluster, Ceph și Vstorage (Virtuozzo).
Textul folosește link-uri către articole cu o dezvăluire mai detaliată a anumitor probleme, astfel încât descrierile vor fi cât mai succinte, folosind puncte cheie fără pufuri inutile și informații introductive pe care, dacă doriți, le puteți obține în mod independent pe Internet.
De fapt, desigur, subiectele abordate necesită tonurile textului, dar în lumea modernă tot mai multor oameni nu le place să citească mult))), așa că puteți citi rapid și face o alegere, iar dacă ceva este nu este clar, urmați link-urile sau google cuvinte neclare))), iar acest articol este ca un înveliș transparent pentru aceste subiecte profunde, arătând umplerea - principalele puncte cheie ale fiecărei decizii.
Gluster
Să începem cu Gluster, care este folosit activ de producătorii de platforme hiperconvergente cu SDS bazate pe open source pentru medii virtuale și poate fi găsit pe site-ul RedHat în secțiunea de stocare, unde poți alege dintre două opțiuni SDS: Gluster sau Ceph.
Gluster constă dintr-un teanc de traducători - servicii care efectuează toată munca de distribuire a fișierelor etc. Brick este un serviciu care deservește un singur disc, Volumul este un volum (pool) care unește aceste cărămizi. Urmează serviciul de distribuire a fișierelor în grupuri folosind funcția DHT (distributed hash table). Nu vom include serviciul Sharding în descriere, deoarece linkurile de mai jos vor descrie problemele asociate cu acesta.
La scriere, întregul fișier este stocat în cărămidă, iar copia sa este scrisă simultan pe cărămidă pe al doilea server. Apoi, al doilea fișier va fi scris în al doilea grup de două cărămizi (sau mai multe) pe servere diferite.
Dacă fișierele au aproximativ aceeași dimensiune și volumul este format dintr-un singur grup, atunci totul este în regulă, dar în alte condiții vor apărea următoarele probleme din descrieri:
- spațiul în grupuri este utilizat neuniform, depinde de dimensiunea fișierelor și dacă nu există suficient spațiu în grup pentru a scrie un fișier, veți primi o eroare, fișierul nu va fi scris și nu va fi redistribuit către alt grup ;
- când scrieți un fișier, IO merge doar la un grup, restul sunt inactiv;
- nu puteți obține IO din întregul volum când scrieți un fișier;
- iar conceptul general pare mai puțin productiv din cauza lipsei de distribuție a datelor în blocuri, unde este mai ușor să echilibrezi și să rezolvi problema distribuției uniforme, și nu ca acum întregul fișier intră într-un bloc.
Din descrierea oficială De asemenea, involuntar ajungem la înțelegerea că gluster funcționează ca stocare de fișiere pe deasupra RAID-ului hardware clasic. Au existat încercări de dezvoltare de a tăia fișierele (Sharding) în blocuri, dar toate acestea sunt o adăugare care impune pierderi de performanță abordării arhitecturale deja existente, plus utilizarea unor astfel de componente distribuite liber cu limitări de performanță precum Fuse. Nu există servicii de metadate, ceea ce limitează performanța și capacitățile de toleranță la erori ale stocării la distribuirea fișierelor în blocuri. Indicatori de performanță mai buni pot fi observați cu configurația „Distributed Replicated” iar numărul de noduri ar trebui să fie de cel puțin 6 pentru a organiza o replică fiabilă 3 cu distribuție optimă a sarcinii.
Aceste constatări sunt, de asemenea, legate de descrierea experienței utilizatorului iar in comparatie cu , și există, de asemenea, o descriere a experienței care duce la înțelegerea acestei configurații mai productive și mai fiabile
Imaginea arată distribuția încărcării la scrierea a două fișiere, unde copiile primului fișier sunt distribuite pe primele trei servere, care sunt combinate în grupul de volum 0, iar trei copii ale celui de-al doilea fișier sunt plasate pe al doilea grup de volum1 din trei. servere. Fiecare server are un disc.
Concluzia generală este că puteți utiliza Gluster, dar cu înțelegerea că vor exista limitări în performanță și toleranță la erori care creează dificultăți în anumite condiții ale unei soluții hiperconvergente, unde sunt necesare și resurse pentru încărcările de calcul ale mediilor virtuale.
Există și câțiva indicatori de performanță Gluster care pot fi atinși în anumite condiții, limitate la
ceph
Acum să ne uităm la Ceph din descrierile arhitecturii pe care le-am putut Există și o comparație între , unde puteți înțelege imediat că este recomandabil să implementați Ceph pe servere separate, deoarece serviciile sale necesită toate resursele hardware sub încărcare.
Arhitectură mai complex decât Gluster și există servicii precum serviciile de metadate, dar întregul teanc de componente este destul de complex și nu foarte flexibil pentru utilizarea într-o soluție de virtualizare. Datele sunt stocate în blocuri, ceea ce arată mai productiv, dar în ierarhia tuturor serviciilor (componentelor), există pierderi și latență în anumite sarcini și condiții de urgență, de exemplu următoarele
Din descrierea arhitecturii, inima este CRUSH, datorită căruia este selectată locația pentru stocarea datelor. Urmează PG - aceasta este cea mai dificilă abstractizare (grup logic) de înțeles. PG-urile sunt necesare pentru a face CRUSH mai eficient. Scopul principal al PG este de a grupa obiecte pentru a reduce consumul de resurse, a crește performanța și scalabilitatea. Adresarea obiectelor direct, individual, fără a le combina într-un PG ar fi foarte costisitoare. OSD este un serviciu pentru fiecare disc individual.
Un cluster poate avea unul sau mai multe pool-uri de date pentru scopuri diferite și cu setări diferite. Pool-urile sunt împărțite în grupuri de plasare. Grupurile de plasare stochează obiecte pe care le accesează clienții. Aici se termină nivelul logic și începe nivelul fizic, deoarece fiecărui grup de plasare i se alocă un disc principal și mai multe discuri replica (câte depind exact de factorul de replicare al pool-ului). Cu alte cuvinte, la nivel logic obiectul este stocat într-un anumit grup de plasare, iar la nivel fizic - pe discurile care îi sunt alocate. În acest caz, discurile pot fi amplasate fizic pe diferite noduri sau chiar în diferite centre de date.
În această schemă, grupurile de plasament arată ca un nivel necesar pentru flexibilitatea întregii soluții, dar în același timp, ca o verigă suplimentară în acest lanț, ceea ce sugerează involuntar o pierdere a productivității. De exemplu, atunci când scrieți date, sistemul trebuie să le împartă în aceste grupuri și apoi la nivel fizic în discul principal și discuri pentru replici. Adică funcția Hash funcționează la căutarea și inserarea unui obiect, dar există un efect secundar - costuri foarte mari și restricții la reconstruirea hash-ului (când adăugați sau eliminați un disc). O altă problemă de tip hash este locația clară a datelor care nu pot fi modificate. Adică, dacă cumva discul este sub încărcare crescută, atunci sistemul nu are posibilitatea de a nu scrie pe el (prin selectarea unui alt disc), funcția hash obligă datele să fie localizate conform regulii, oricât de rău ar fi discul este, așa că Ceph mănâncă multă memorie la reconstruirea PG-ului în caz de auto-vindecare sau de creștere a stocării. Concluzia este că Ceph funcționează bine (deși lent), dar numai atunci când nu există scalare, situații de urgență sau actualizări.
Există, desigur, opțiuni pentru creșterea performanței prin cache și partajare cache, dar acest lucru necesită hardware bun și vor exista în continuare pierderi. Dar, în general, Ceph pare mai tentant decât Gluster pentru productivitate. De asemenea, atunci când utilizați aceste produse, este necesar să luați în considerare un factor important - acesta este un nivel ridicat de competență, experiență și profesionalism, cu un mare accent pe Linux, deoarece este foarte important să implementați, să configurați și să mențineți totul corect, ceea ce impune şi mai multă responsabilitate şi povară administratorului.
Vstorage
Arhitectura pare și mai interesantă , care poate fi folosit împreună cu un hypervisor pe aceleași noduri, pe același , dar este foarte important să configurați totul corect pentru a obține o performanță bună. Adică, implementarea unui astfel de produs din cutie pe orice configurație fără a ține cont de recomandările în conformitate cu arhitectura va fi foarte ușoară, dar nu productivă.
Ce poate coexista pentru stocare pe langa serviciile hypervisorului kvm-qemu, iar acestea sunt doar cateva servicii in care s-a gasit o ierarhie optima compacta a componentelor: client service montat prin FUSE (modificat, nu open source), serviciu de metadate MDS (Serviciul de metadate), blocuri de date de serviciu Chunk, care la nivel fizic este egal cu un disc și atât. În ceea ce privește viteza, desigur, este optim să folosiți o schemă tolerantă la erori cu două replici, dar dacă utilizați cache și log-uri pe unități SSD, atunci codarea tolerantă la erori (erase coding sau raid6) poate fi overclockată decent pe un schema hibridă sau chiar mai bună pe toate flash-urile. Există un anumit dezavantaj cu EC (erase coding): la schimbarea unui bloc de date, este necesar să se recalculeze sumele de paritate. Pentru a ocoli pierderile asociate cu această operațiune, Ceph scrie la EC amânat și pot apărea probleme de performanță în timpul unei anumite solicitări, când, de exemplu, toate blocurile trebuie citite, iar în cazul Virtuozzo Storage, se realizează scrierea blocurilor modificate. folosind abordarea „sistem de fișiere structurate în jurnal”, care minimizează costurile de calcul al parității. Pentru a estima aproximativ opțiunile cu accelerarea lucrului cu și fără EC, există – cifrele pot fi aproximative în funcție de coeficientul de precizie al producătorului de echipamente, dar rezultatul calculelor este de un bun ajutor în planificarea configurației.
O diagramă simplă a componentelor de depozitare nu înseamnă că aceste componente nu absorb dar dacă calculezi toate costurile în avans, poți conta pe colaborare lângă hypervisor.
Există o schemă de comparare a consumului de resurse hardware de către serviciile de stocare Ceph și Virtuozzo.
Dacă anterior se putea compara Gluster și Ceph folosind articole vechi, folosind cele mai importante linii din ele, atunci cu Virtuozzo este mai dificil. Nu există multe articole despre acest produs și informațiile pot fi adunate doar din documentația de pe sau în rusă dacă considerăm Vstorage ca stocare folosită în unele soluții hiperconvergente în companii precum și Acronis.
Voi încerca să ajut cu o descriere a acestei arhitecturi, deci va fi puțin mai mult text, dar este nevoie de mult timp pentru a înțelege singur documentația, iar documentația existentă poate fi folosită doar ca referință prin revizuirea tabelului de conținut sau căutarea după cuvinte cheie.
Să luăm în considerare procesul de înregistrare într-o configurație hardware hibridă cu componentele descrise mai sus: înregistrarea începe să meargă la nodul de la care clientul a inițiat-o (serviciul punct de montare FUSE), dar componenta principală a Serviciului de metadate (MDS) va fi bineînțeles. direcționează clientul direct către serviciul chunk dorit (serviciu de stocare blocuri CS), adică MDS nu participă la procesul de înregistrare, ci pur și simplu direcționează serviciul către blocul necesar. În general, putem da o analogie înregistrării cu turnarea apei în butoaie. Fiecare butoi este un bloc de date de 256 MB.
Adică, un disc este un anumit număr de astfel de butoaie, adică volumul discului împărțit la 256MB. Fiecare copie este distribuită la un nod, a doua aproape în paralel cu alt nod etc... Dacă avem trei replici și există discuri SSD pentru cache (pentru citirea și scrierea jurnalelor), atunci confirmarea scrierii va avea loc după scriere. jurnalul pe SSD și resetarea paralelă de pe SSD va continua pe HDD, ca în fundal. În cazul a trei replici, înregistrarea va fi comisă după confirmarea de la SSD-ul celui de-al treilea nod. Poate părea că suma vitezei de scriere a trei SSD-uri poate fi împărțită la trei și vom obține viteza de scriere a unei replici, dar copiile sunt scrise în paralel, iar viteza de latență a rețelei este de obicei mai mare decât cea a SSD-ului, și de fapt performanța de scriere va depinde de rețea. În acest sens, pentru a vedea IOPS reale, trebuie să încărcați corect întregul Vstorage de , adică testarea încărcării reale, și nu a memoriei și a cache-ului, unde este necesar să se țină cont de dimensiunea corectă a blocului de date, numărul de fire etc.
Jurnalul de înregistrare menționat mai sus de pe SSD funcționează în așa fel încât, de îndată ce datele intră în el, acesta este citit imediat de serviciu și scris pe HDD. Există mai multe servicii de metadate (MDS) per cluster și numărul acestora este determinat de un cvorum, care funcționează conform algoritmului Paxos. Din punctul de vedere al clientului, punctul de montare FUSE este un folder de stocare cluster care este vizibil simultan pentru toate nodurile din cluster, fiecare nod având un client montat conform acestui principiu, astfel încât această stocare este disponibilă fiecărui nod.
Pentru realizarea oricăreia dintre abordările descrise mai sus, este foarte important, în etapa de planificare și implementare, să se configureze corect rețeaua, unde va exista echilibrare datorită agregării și lățimii de bandă a canalului de rețea selectate corect. În agregare, este important să alegeți modul de hashing și dimensiunile cadrelor potrivite. Există, de asemenea, o diferență foarte puternică față de SDS-ul descris mai sus, aceasta este fuzionarea cu tehnologia de cale rapidă în Virtuozzo Storage. Care, pe lângă siguranța modernizată, spre deosebire de alte soluții open source, crește semnificativ IOPS-ul și vă permite să nu fiți limitat de scalarea orizontală sau verticală. În general, în comparație cu arhitecturile descrise mai sus, aceasta pare mai puternică, dar pentru o asemenea plăcere, desigur, trebuie să cumpărați licențe, spre deosebire de Ceph și Gluster.
Pentru a rezuma, putem evidenția topul celor trei: Virtuozzo Storage ocupă primul loc în ceea ce privește performanța și fiabilitatea arhitecturii, Ceph ocupă locul doi, iar Gluster ocupă locul trei.
Criteriile după care a fost selectat Virtuozzo Storage: este un set optim de componente arhitecturale, modernizate pentru această abordare Fuse cu cale rapidă, un set flexibil de configurații hardware, un consum mai mic de resurse și capacitatea de a partaja cu calculul (calculator/virtualizare), adică este complet potrivit pentru o soluție hiperconvergentă, din care face parte. Pe locul al doilea se află Ceph pentru că este o arhitectură mai productivă în comparație cu Gluster, datorită funcționării sale în blocuri, precum și a scenariilor mai flexibile și a capacității de a lucra în clustere mai mari.
Există planuri de a scrie o comparație între vSAN, Space Direct Storage, Vstorage și Nutanix Storage, testarea Vstorage pe echipamentele HPE și Huawei, precum și scenarii pentru integrarea Vstorage cu sisteme de stocare hardware externe, așa că dacă ți-a plăcut articolul, ar fi Mă bucur să primesc feedback de la tine, care ar putea crește motivația pentru articole noi, ținând cont de comentariile și dorințele tale.
Sursa: www.habr.com