Ky këtij artikulli shkruhet për të ndihmuar në zgjedhjen e zgjidhjes së përshtatshme dhe për të kuptuar dallimet midis SDS si Gluster, Ceph dhe Vstorage (Virtuozzo).
NĂ« tekst pĂ«rdoren lidhje nĂ« artikuj me njĂ« shpjegim mĂ« tĂ« detajuar tĂ« problemeve tĂ« caktuara, prandaj pĂ«rshkrimet do tĂ« jenĂ« sa mĂ« tĂ« shkurtra, duke pĂ«rdorur pika kyçe pa informacione tĂ« panevojshme dhe hyrĂ«se, tĂ« cilat mund tâi kĂ«rkoni vetĂ« nĂ« internet.
NĂ« fakt, temat e prekur kĂ«rkojnĂ« njĂ« ton specifik tĂ« tekstit, por nĂ« botĂ«n moderne gjithnjĂ« e mĂ« shumĂ« njerĂ«z nuk pĂ«lqejnĂ« tĂ« lexojnĂ« shumĂ«))), prandaj mund tĂ« lexoni shpejt dhe tĂ« bĂ«ni zgjedhjen tuaj, dhe nĂ«se ka diçka qĂ« nuk kuptoni, mund tĂ« kaloni nĂ« lidhjet ose tĂ« hidhni njĂ« sy nĂ« fjalĂ«t e panjohura))), dhe ky artikull funksionon si njĂ« mbĂ«shtjellĂ«s transparent pĂ«r kĂ«to tema tĂ« thella, duke treguar pĂ«rmbajtjen â pikat kryesore tĂ« çdo zgjidhjeje.
Gluster
Të fillojmë me Gluster, i cili përdoret gjerësisht nga prodhuesit e platformave hiper-konverguese me SDS të bazuar në open source për mjedise virtuale dhe mund të gjendet në faqen e RedHat në seksionin storage, ku ofrohet zgjedhja midis dy opsioneve SDS: Gluster ose Ceph.
Gluster pĂ«rbĂ«het nga njĂ« grup shĂ«rbimesh â shĂ«rbime qĂ« kryejnĂ« tĂ« gjitha punĂ«t e shpĂ«rndarjes sĂ« skedarĂ«ve dhe tĂ« tjera. Brick â shĂ«rbimi qĂ« shĂ«rben njĂ« disk, Volume â vĂ«llimi (puli) qĂ« bashkon kĂ«to brick. MĂ« tej shĂ«rbimi i shpĂ«rndarjes sĂ« skedarĂ«ve nĂ« grupe pĂ«rmes funksionit DHT (distributed hash table). ShĂ«rbimi i Sharding nuk do tĂ« pĂ«rfshihet nĂ« pĂ«rshkrim, pasi nĂ« lidhjet e mĂ«poshtme do tĂ« ketĂ« pĂ«rshkrime tĂ« problemeve tĂ« lidhura me tĂ«.
Kur shkruhet, skedari i plotĂ« vendoset nĂ« brick dhe kopja e tij shkruhet paralelisht nĂ« brick nĂ« serverin e dytĂ«. MĂ« pas, skedari i dytĂ« do tĂ« regjistrohet nĂ« grupin e dytĂ« tĂ« dy briŃk (ose mĂ« shumĂ«) nĂ« serverĂ« tĂ« ndryshĂ«m.
Nëse skedarët janë afërsisht të një madhësie dhe vëllimi do të përbëhet vetëm nga një grup, gjithçka është në rregull, por në kushtet e tjera do të lindin problemet e mëposhtme nga përshkrimet:
- hapĂ«sira nĂ« grupe pĂ«rdoret nĂ« mĂ«nyrĂ« tĂ« pabarabartĂ«, kjo varet nga madhĂ«sitĂ« e skedarĂ«ve dhe nĂ«se grupi nuk ka mjaft hapĂ«sirĂ« pĂ«r tĂ« regjistruar skedarin â ju do tĂ« merrni njĂ« gabim, skedari nuk do tĂ« regjistrohet dhe nuk do tĂ« shpĂ«rndahet nĂ« njĂ« grup tjetĂ«r;
- kur shkruhet një skedar, IO ndodhet vetëm në një grup, grupet e tjera nuk punojnë;
- nuk është e mundur të arrihet IO i tërë vëllimit kur shkruhet një skedar;
- dhe koncepti i përgjithshëm duket se është më pak efektiv për shkak të mungesës së shpërndarjes së të dhënave në blloqe, ku është më e lehtë të realizohet balancimi dhe të zgjidhet problemi i shpërndarjes së barabartë, sesa siç është tani kur fakti vendoset si një bllok i tërë.
Nga pĂ«rshkrimi zyrtar duhet tĂ« kuptohet se gluster funksionon si njĂ« depo e skedarĂ«ve mbi RAID-in klasik. Ka pasur pĂ«rpjekje pĂ«r tĂ« zhvilluar ndarjen (Sharding) e skedarĂ«ve nĂ« blloqe, por kĂ«to janĂ« plotĂ«sime qĂ« imponojnĂ« humbje nĂ« performancĂ« pĂ«r qasjen arkitektonike ekzistuese, plus pĂ«rdorimin e komponentĂ«ve tĂ« tillĂ« tĂ« lira me kufizime nĂ« performancĂ« si Fuse. Nuk ka shĂ«rbime metadatan, qĂ« kufizojnĂ« mundĂ«sitĂ« e performancĂ«s dhe qĂ«ndrueshmĂ«risĂ« sĂ« depozitĂ«s nĂ« shpĂ«rndarjen e skedarĂ«ve nĂ« blloqe. TĂ« dhĂ«na mĂ« tĂ« mira tĂ« performancĂ«s mund tĂ« vĂ«rehen nĂ« konfigurimin âDistributed Replicatedâ dhe numri i nodĂ«ve duhet tĂ« jetĂ« tĂ« paktĂ«n 6 pĂ«r organizimin e njĂ« replike tĂ« sigurt me 3 me shpĂ«rndarjen optimale tĂ« ngarkesĂ«s.
Këto konkluzione gjithashtu lidhen me përshkrimin e përvojës së përdorimit dhe në krahasim me , si dhe ka një përshkrim të përvojës për të arritur këtë konfigurim më të qëndrueshëm dhe më të besueshëm
NĂ« figurĂ« shikohet shpĂ«rndarja e ngarkesĂ«s gjatĂ« shkrimit tĂ« dy skedarĂ«ve, ku kopjet e skedarit tĂ« parĂ« ndahen nĂ« tre serverĂ«t e parĂ«, tĂ« cilĂ«t janĂ« tĂ« bashkuar nĂ« grupin volume 0 dhe tre kopjet e skedarit tĂ« dytĂ« vendosen nĂ« grupin e dytĂ« volume1 nga tre serverĂ«. Ădo server ka njĂ« disk.
Konkluzioni i përgjithshëm është se Gluster mund të përdoret, por me kuptimin se do të ketë kufizime në performancë dhe qëndrueshmëri, që krijojnë vështirësi në disa kushte të zgjidhjes hiper-konverguese, ku burimet janë gjithashtu të nevojshme për ngarkesat llogaritëse të mjeteve virtuale.
Ka disa pasqyra gjithashtu të performancës së Gluster, të cilat mund të arrihen në kushte të caktuara duke u kufizuar në
Ceph
Tani le të shqyrtojmë Ceph nga përshkrimet e arkitekturës që kam arritur Ka gjithashtu një krahasim midis , ku mund të kuptohet menjëherë se Ceph preferohet të implementohet në servera të veçantë, pasi shërbimet e tij kërkojnë të gjitha burimet e harduerit nën ngarkesë.
Arkitektura më shpesh më e komplikuar se Gluster dhe ka shërbime si shërbimet e metadatat, por e gjithë stina e komponentëve është mjaft e komplikuar dhe jo shumë fleksibël për ta përdorur në një zgjidhje virtualizimi. Të dhënat organizohen në blloqe, që duket se është më e efektshme, por ka humbje dhe latency në hierarkinë e të gjitha shërbimeve (komponentëve) nën disa ngarkesa dhe kushte emergjente, siç është shembulli i mëposhtëm.
Nga përshkrimi i arkitekturës, në qendër është CRUSH, i cili përcakton vendin e ruajtjes së të dhënave. Më pas vjen PG - kjo është abstraksioni më i komplikuar (grupi logic) për t'u kuptuar. PG janë të nevojshme për të bërë CRUSH më efikas. Qëllimi kryesor i PG është grupimi i objekteve për të ulur konsumimin e burimeve, për të përmirësuar performancën dhe shkallëzueshmërinë. Adresimi i objekteve në mënyrë të drejtpërdrejtë, veçmas, pa i bashkuar ato në PG do të ishte shumë i shtrenjtë. OSD - është shërbimi për çdo disk të veçantë.
Klusteri mund të ketë një ose shumë rezervarë të dhënash me qëllime të ndryshme dhe me konfigurime të ndryshme. Reservarët ndahen në grupe vendosjeje. Në grupet e vendosjes ruhen objekte, të cilat kërkohen nga klientët. Në këtë nivel logjik përfundon, dhe fillon ai fizik, sepse secilës grup vendosjeje i është caktuar një disk kryesor dhe disa disqe-replika (sesa shumë varet nga faktori i replikimit të rezervarit). Me fjalë të tjera, në nivelin logjik, objekti ruhet në një grup konkret vendosjeje, ndërsa në nivelin fizik - në disqet që janë caktuar për të. Megjithatë, disqet fizikisht mund të jenë në nodo të ndryshme ose madje në qendra të ndryshme të të dhënave.
NĂ« kĂ«tĂ« skemĂ«, grupet e vendosjes duken si njĂ« nivel i nevojshĂ«m pĂ«r fleksibilitetin e tĂ«rĂ« zgjidhjes, por njĂ«kohĂ«sisht edhe si njĂ« lidhje e tepĂ«rt nĂ« kĂ«tĂ« zinxhir, qĂ« pa dashje ngjall mendime pĂ«r humbjen e performancĂ«s. PĂ«r shembull, gjatĂ« regjistrimit tĂ« tĂ« dhĂ«nave, sistemi duhet t'i ndajĂ« ato nĂ« kĂ«to grupe dhe mĂ« pas nĂ« nivelin fizik nĂ« diskun kryesor dhe nĂ« diskĂ«t pĂ«r replika. Pra, funksioni i hash-it punon gjatĂ« kĂ«rkimit dhe vendosjes sĂ« objektit, por ka njĂ« efekt anĂ«sor â kĂ«to janĂ« shpenzime tĂ« mĂ«dha dhe kufizime nĂ« rinovimin e hash-it (kur shtohet ose hiqet njĂ« disk). NjĂ« tjetĂ«r problem me hash-in Ă«shtĂ« vendosja e fiksuar e tĂ« dhĂ«nave, tĂ« cilat nuk mund tĂ« ndryshohen. Pra, nĂ«se ndonjĂ« disk pĂ«rjeton njĂ« ngarkesĂ« tĂ« rritur, sistemi nuk ka mundĂ«si tĂ« mos shkruajĂ« nĂ« tĂ« (duke zgjedhur njĂ« disk tjetĂ«r), funksioni i hash-it e detyron vendosjen e tĂ« dhĂ«nave sipas njĂ« rregulli, pa marrĂ« parasysh se sa keq ndjehet disku, prandaj Ceph konsumon shumĂ« memorie gjatĂ« rinovimit tĂ« PG-sĂ« nĂ« rastin e vetĂ«-riparimit ose rritjes sĂ« magazinĂ«s. PĂ«rfundimi Ă«shtĂ« se Ceph punon mirĂ« (edhe pse ngadalĂ«), por vetĂ«m kur nuk ka zgjerim, situata emergjente ose azhurnim.
Natyrisht, ka mundësi për rritjen e performancës përmes keshtimi dhe keshtirjes, por për këtë nevojitet hardware i mirë dhe gjithsesi do të ketë humbje. Por në përgjithësi Ceph duket më tërheqës se Gluster për produktivitet. Gjithashtu, gjatë përdorimit të këtyre produkteve duhet të merret parasysh një faktor i rëndësishëm - niveli i lartë i kompetencave, përvojës dhe profesionalizmit me një theks të madh në linux, pasi është shumë e rëndësishme të gjitha të vendosen, konfigurohen dhe mbahen siç duhet, gjë që krijon më shumë përgjegjësi dhe ngarkesë ndaj administratorit.
Vstorage
Arkitektura duket edhe më interesante te , e cila mund të përdoret së bashku me hipervizorin në të njëjtat nyje, në të njëjtin , por është shumë e rëndësishme ta konfigurosh gjithçka siç duhet për të arritur një performancë të mirë. Pra, duke vendosur një produkt të tillë nga kutia në një konfigurim të rastësishëm pa marrë parasysh rekomandimet në përputhje me arkitekturën do të jetë shumë e lehtë, por jo produktive.
ĂfarĂ« mund tĂ« bashkĂ«jetojĂ« pĂ«r ruajtje pranĂ« shĂ«rbimeve tĂ« hipervizorit kvm-qemu, dhe kjo janĂ« vetĂ«m disa shĂ«rbime, ku Ă«shtĂ« gjetur njĂ« hierarki kompakt optimale komponentesh: shĂ«rbimi i klientit i montuar pĂ«rmes FUSE (i modifikuar, jo open source), shĂ«rbimi i metadatanĂ« MDS (ShĂ«rbimi i Metadatanave), shĂ«rbimi i bllokut tĂ« tĂ« dhĂ«nave Chunk service, i cili nĂ« nivelin fizik Ă«shtĂ« i barabartĂ« me njĂ« disk dhe ajo Ă«shtĂ« e gjitha. Sigurisht, pĂ«r shpejtĂ«si Ă«shtĂ« optimale tĂ« pĂ«rdoret njĂ« skemĂ« e qĂ«ndrueshme me dy kopje, por nĂ«se aktivizohet caching dhe regjistrat nĂ« disqet SSD, atĂ«herĂ« kodimi i qĂ«ndrueshĂ«m (erase coding ose raid6) mund tĂ« pĂ«rshpejtohet ndjeshĂ«m nĂ« njĂ« skemĂ« hibride ose madje edhe mĂ« mirĂ« nĂ« all flash. Me EC (erase coding) ka disa disavantazhe: kur modifikohet njĂ« bllok i tĂ« dhĂ«nave, Ă«shtĂ« e nevojshme tĂ« llogaritet pĂ«rsĂ«ri somat e paritetit. PĂ«r tĂ« shmangur humbjet nĂ« kĂ«tĂ« operacion Ceph shkruan nĂ« EC si tĂ« vonuar dhe problemi me performancĂ«n mund tĂ« ndodhi nĂ« njĂ« kĂ«rkesĂ« tĂ« caktuar, kur pĂ«r shembull nevojitet tĂ« llogariten tĂ« gjitha blloqet, ndĂ«rsa nĂ« rastin e Virtuozzo Storage, regjistrimi i blloqeve tĂ« modifikuara bĂ«het duke pĂ«rdorur qasjen âlog-structured file systemâ, qĂ« minimizon shpenzimet mbi llogaritjen e paritetit. PĂ«r tĂ« paramenduar pĂ«rafĂ«rsisht opsionet pĂ«r pĂ«rshpejtimin e punĂ«s me EC dhe pa, ka â numrat mund tĂ« jenĂ« pĂ«rafĂ«rsisht tĂ« varur nga koeficienti i saktĂ«sisĂ« sĂ« prodhuesit tĂ« pajisjeve, por rezultati i llogaritjeve ndihmon shumĂ« pĂ«r tĂ« planifikuar konfigurimin.
Një skemë e thjeshtë e komponentëve të ruajtjes nuk do të thotë se këta komponentë nuk konsumojnë por nëse llogariten të gjitha shpenzimet paraprakisht, atëherë mund të pritet një bashkëpunim pranë hipervizorit.
Ka një skemë krahasimi të konsumit të burimeve harduerike nga shërbimet Ceph dhe Virtuozzo storage.
Nëse më parë, krahasimi i Gluster dhe Ceph mund të bëhej sipas artikujve të vjetër, duke përdorur rreshtat më të rëndësishëm prej tyre, tani me Virtuozzo është më e komplikuar. Artikujt për këtë produkt nuk janë aq të shumtë dhe informacioni mund të merret vetëm nga dokumentacioni në ose në rusisht nëse merret parasysh Vstorage si një ruajtje e përdorur në disa zgjidhje hiper të konverguara në kompani si dhe Acronis.
Do ta provoj ndihmoj me përshkrimin e kësaj arkitekture, prandaj teksti do të jetë pak më i gjatë, por për të kuptuar dokumentacionin vetë, kërkohet shumë kohë, dhe dokumentacioni ekzistues mund të përdoret vetëm si referencë duke rishikuar përmbajtjen ose duke kërkuar me fjalë kyçe.
Le tĂ« shqyrtojmĂ« procesin e regjistrimit nĂ« njĂ« konfigurim hibrid tĂ« harduerit me komponentĂ«t e pĂ«rshkruar mĂ« sipĂ«r: regjistrimi fillon nĂ« atĂ« nyje nga e cila e iniciatoi klienti (shĂ«rbimi i pikĂ«s sĂ« montimit FUSE), por komponenti kryesor i shĂ«rbimit tĂ« metadata (MDS) natyrisht do ta drejtojĂ« klientin direkt te shĂ«rbimi i çankut qĂ« i nevojitet (shĂ«rbimi i ruajtjes sĂ« blloqeve CS), dmth MDS nuk merr pjesĂ« nĂ« procesin e regjistrimit, ai vetĂ«m e drejton atĂ« te shĂ«rbimi i nevojshĂ«m tĂ« çankut. NĂ« thelb, mund tĂ« sjellim njĂ« analogji tĂ« regjistrimit me derdhjen e ujit nĂ« fuçi. Ădo fuçi Ă«shtĂ« njĂ« bllok tĂ« dhĂ«nash prej 256MB.
Pra, njĂ« disk Ă«shtĂ« njĂ« sasi e caktuar e tillĂ« fuçish, dmth vĂ«llimi i diskut Ă«shtĂ« i ndarĂ« nĂ« 256MB. Ădo kopje derdhet nĂ« njĂ« nyje, e dyta pothuajse paralelisht nĂ« njĂ« nyje tjetĂ«r, etj... NĂ«se kemi tre replika dhe disk SSD pĂ«r kujtesĂ«n (pĂ«r lexim dhe revista regjistrimi), atĂ«herĂ« konfirmimi i regjistrimit do tĂ« ndodhĂ« pas regjistrimit tĂ« revistĂ«s nĂ« SSD, dhe shĂ«nimi paralel nga SSD do tĂ« vazhdojĂ« nĂ« HDD, siç do tĂ« ishte nĂ« njĂ« mĂ«nyrĂ« sfond. NĂ« rastin e tre replikave, komiti i regjistrimit do tĂ« ndodhĂ« pas konfirmimit nga SSD i nyjĂ«s sĂ« tretĂ«. Mund tĂ« duket se shpejtĂ«sia e regjistrimit tĂ« tre SSD mund tĂ« ndahet nĂ« tre dhe do tĂ« marrim shpejtĂ«sinĂ« e regjistrimit tĂ« njĂ« replike, por regjistrimi i kopjave ndodh nĂ« paralel dhe latency e rrjetit zakonisht Ă«shtĂ« mĂ« e lartĂ« se ajo e SSD, dhe nĂ« thelb, performanca e regjistrimit do tĂ« varet nga rrjeti. PĂ«r kĂ«tĂ« arsye, pĂ«r tĂ« parĂ« IOPS reale, Ă«shtĂ« e nevojshme tĂ« ngarkoni nĂ« mĂ«nyrĂ« tĂ« duhur tĂ« gjithĂ« Vstorage sipas , dmth tĂ« testoni ngarkesĂ«n reale, jo kujtesĂ«n dhe ĐșĐ”Ńin, ku duhet tĂ« merren parasysh madhĂ«sia e saktĂ« e bllokut tĂ« tĂ« dhĂ«nave, numri i rrjedhave etj.
Revista de logare menÈionatÄ mai sus pe SSD funcÈioneazÄ astfel ĂźncĂąt, imediat ce datele ajung Ăźn ea, sunt citite de serviciu Èi scrise pe HDD. ExistÄ mai multe servicii de metadate (MDS) pe cluster, iar numÄrul lor este determinat de cvorumul care funcÈioneazÄ pe baza algoritmului Paxos. Din perspectiva clientului, punctul de montare FUSE este un folder de stocare a clusterului, care este vizibil tuturor nodurilor clusterului, fiecare nod avĂąnd un client montat conform acestui principiu, astfel ĂźncĂąt fiecare nod are acces la acest stocaj.
Pentru performanÈa oricÄruia dintre abordÄrile menÈionate mai sus, este foarte important, Ăźn faza de planificare Èi desfÄÈurare, sÄ se configureze corect reÈeaua Ăźn care va avea loc echilibrarea prin agregare Èi sÄ se selecteze corect lÄÈimea de bandÄ a canalului de reÈea. Ăn agregare, este esenÈial sÄ se selecteze corect modul de hash Èi dimensiunile cadrelor. ExistÄ, de asemenea, o diferenÈÄ semnificativÄ faÈÄ de SDS-urile menÈionate mai sus, Èi anume FUSE cu tehnologia fast path Ăźn Virtuozzo Storage. Aceasta, pe lĂąngÄ FUSE-ul modernizat, Ăźn contrast cu celelalte soluÈii open source, creÈte semnificativ IOPS-urile Èi permite scalarea atĂąt orizontalÄ, cĂąt Èi verticalÄ. Ăn general, comparativ cu arhitecturile menÈionate anterior, aceasta pare mai puternicÄ, dar pentru acest privilegiu, cu siguranÈÄ, este necesar sÄ se achiziÈioneze licenÈe, spre deosebire de Ceph Èi Gluster.
Ăn concluzie, se poate evidenÈia topul format din trei: primul loc Ăźn ceea ce priveÈte performanÈa Èi fiabilitatea arhitecturii este ocupat de Virtuozzo Storage, al doilea loc este pentru Ceph, iar al treilea pentru Gluster.
Criteriile pentru care a fost ales Virtuozzo Storage sunt: un set optim de componente ale arhitecturii, FUSE-ul modernizat pentru aceastÄ abordare cu fast path, un set flexibil de configuraÈie hardware, un consum mai mic de resurse Èi posibilitatea de a fi utilizat ĂźmpreunÄ cu compute (calculare/virtualizare), ceea ce Ăźl face complet potrivit pentru o soluÈie hiperconvergentÄ, Ăźn cadrul cÄreia este inclus. Al doilea loc este ocupat de Ceph, deoarece este o arhitecturÄ mai performantÄ comparativ cu Gluster, datoritÄ operÄrii cu blocuri, precum Èi scenariilor mai flexibile Èi capacitÄÈii de a lucra Ăźn clustere de dimensiuni mai mari.
Në planet tona është dëshira të shkruajmë një krahasim ndërmjet vSAN, Space Direct Storage, Vstorage dhe Nutanix Storage, për të testuar Vstorage në pajisje HPE, Huawei, si dhe skenarët e integrimit të Vstorage me pajisje të jashtme të SHTM-ve, prandaj nëse ky artikull ju ka pëlqyer, do të ishte mirë të merrnim nga ju komente që mund të forcojnë motivimin për artikuj të rinj, duke pasur parasysh vërejtjet dhe dëshirat tuaja.
Burimi: habr.com
