Ky artikull është shkruar për t'ju ndihmuar të zgjidhni zgjidhjen e duhur për veten tuaj dhe të kuptoni ndryshimet midis SDS si Gluster, Ceph dhe Vstorage (Virtuozzo).
Teksti përdor lidhje me artikujt me një zbulim më të detajuar të problemeve të caktuara, kështu që përshkrimet do të jenë sa më të shkurtra, duke përdorur pika kyçe pa push të panevojshme dhe informacione hyrëse që mund t'i merrni, nëse dëshironi, në mënyrë të pavarur në internet.
Në fakt, sigurisht, temat e ngritura kërkojnë tonet e tekstit, por në botën moderne gjithnjë e më shumë njerëzve nuk u pëlqen të lexojnë shumë))), kështu që ju mund të lexoni shpejt dhe të bëni një zgjedhje, dhe nëse diçka është jo e qartë, ndiqni lidhjet ose google fjalët e paqarta))), dhe ky artikull është si një mbështjellës transparent për këto tema të thella, duke treguar mbushjen - pikat kryesore kryesore të çdo vendimi.
gluster
Le të fillojmë me Gluster, i cili përdoret në mënyrë aktive nga prodhuesit e platformave të hiperkonvergjuara me SDS bazuar në burim të hapur për mjediset virtuale dhe mund të gjendet në faqen e internetit RedHat në seksionin e ruajtjes, ku mund të zgjidhni nga dy opsione SDS: Gluster ose Ceph.
Gluster përbëhet nga një pirg përkthyesish - shërbime që kryejnë të gjithë punën e shpërndarjes së skedarëve, etj. Brick është një shërbim që shërben një disk, Volume është një vëllim (pool) që bashkon këto tulla. Më pas vjen shërbimi për shpërndarjen e skedarëve në grupe duke përdorur funksionin DHT (tabela hash e shpërndarë). Ne nuk do të përfshijmë shërbimin Sharding në përshkrim pasi lidhjet e mëposhtme do të përshkruajnë problemet që lidhen me të.
Kur shkruani, i gjithë skedari ruhet në tullë dhe kopja e tij shkruhet njëkohësisht në tullë në serverin e dytë. Më pas, skedari i dytë do të shkruhet në grupin e dytë prej dy tullash (ose më shumë) në serverë të ndryshëm.
Nëse skedarët kanë përafërsisht të njëjtën madhësi dhe vëllimi përbëhet nga vetëm një grup, atëherë gjithçka është në rregull, por në kushte të tjera problemet e mëposhtme do të lindin nga përshkrimet:
- hapësira në grupe përdoret në mënyrë të pabarabartë, varet nga madhësia e skedarëve dhe nëse nuk ka hapësirë të mjaftueshme në grup për të shkruar një skedar, do të merrni një gabim, skedari nuk do të shkruhet dhe nuk do të rishpërndahet në një grup tjetër. ;
- kur shkruani një skedar, IO shkon vetëm në një grup, pjesa tjetër janë boshe;
- nuk mund të merrni IO të të gjithë vëllimit kur shkruani një skedar;
- dhe koncepti i përgjithshëm duket më pak produktiv për shkak të mungesës së shpërndarjes së të dhënave në blloqe, ku është më e lehtë të balancohet dhe të zgjidhet problemi i shpërndarjes uniforme, dhe jo si tani i gjithë skedari shkon në një bllok.
Nga përshkrimi zyrtar ne gjithashtu arrijmë në mënyrë të pavullnetshme të kuptojmë se gluster funksionon si ruajtje skedarësh në krye të RAID-it klasik të harduerit. Ka pasur përpjekje zhvillimi për të prerë skedarët (Sharding) në blloqe, por e gjithë kjo është një shtesë që imponon humbje të performancës në qasjen tashmë ekzistuese arkitekturore, plus përdorimin e komponentëve të tillë të shpërndarë lirisht me kufizime të performancës si Fuse. Nuk ka shërbime të meta të dhënave, gjë që kufizon performancën dhe aftësitë e tolerancës së gabimeve të ruajtjes kur shpërndahen skedarë në blloqe. Treguesit më të mirë të performancës mund të vërehen me konfigurimin "Distributed Replicated" dhe numri i nyjeve duhet të jetë të paktën 6 për të organizuar një kopje të besueshme 3 me shpërndarje optimale të ngarkesës.
Këto gjetje lidhen gjithashtu me përshkrimin e përvojës së përdoruesit dhe kur krahasohet me , dhe ka gjithashtu një përshkrim të përvojës që çon në një kuptim të këtij konfigurimi më produktiv dhe më të besueshëm
Fotografia tregon shpërndarjen e ngarkesës kur shkruani dy skedarë, ku kopjet e skedarit të parë shpërndahen nëpër tre serverët e parë, të cilët kombinohen në grupin e vëllimit 0, dhe tre kopje të skedarit të dytë vendosen në grupin e dytë vëllimi 1 prej tre. serverët. Çdo server ka një disk.
Përfundimi i përgjithshëm është se mund të përdorni Gluster, por duke kuptuar se do të ketë kufizime në performancë dhe tolerancë ndaj gabimeve që krijojnë vështirësi në kushte të caktuara të një zgjidhjeje hiperkonvergjente, ku nevojiten burime edhe për ngarkesat llogaritëse të mjediseve virtuale.
Ekzistojnë gjithashtu disa tregues të performancës Gluster që mund të arrihen në kushte të caktuara, të kufizuara në
ceph
Tani le të shikojmë Ceph nga përshkrimet e arkitekturës që kam mundur Ekziston edhe një krahasim midis , ku mund të kuptoni menjëherë se këshillohet vendosja e Ceph në serverë të veçantë, pasi shërbimet e tij kërkojnë të gjitha burimet e harduerit nën ngarkesë.
Arkitekturë më komplekse se Gluster dhe ka shërbime të tilla si shërbimet metadata, por e gjithë grupi i komponentëve është mjaft kompleks dhe jo shumë fleksibël për ta përdorur atë në një zgjidhje virtualizimi. Të dhënat ruhen në blloqe, të cilat duken më produktive, por në hierarkinë e të gjitha shërbimeve (komponentëve), ka humbje dhe vonesë në ngarkesa të caktuara dhe kushte emergjente, për shembull:
Nga përshkrimi i arkitekturës, zemra është CRUSH, falë së cilës zgjidhet vendndodhja për ruajtjen e të dhënave. Më pas vjen PG - ky është abstraksioni (grupi logjik) më i vështirë për t'u kuptuar. PG-të janë të nevojshme për ta bërë CRUSH më efektiv. Qëllimi kryesor i PG është të grupojë objektet për të reduktuar konsumin e burimeve, për të rritur performancën dhe shkallëzueshmërinë. Adresimi i objekteve drejtpërdrejt, individualisht, pa i kombinuar ato në një PG do të ishte shumë i shtrenjtë. OSD është një shërbim për çdo disk individual.
Një grup mund të ketë një ose shumë grupe të dhënash për qëllime të ndryshme dhe me cilësime të ndryshme. Pishinat ndahen në grupe vendosjeje. Grupet e vendosjes ruajnë objektet që klientët i qasen. Këtu përfundon niveli logjik dhe fillon niveli fizik, sepse secilit grup vendosjeje i caktohet një disk kryesor dhe disa disqe kopje (sa saktësisht varen nga faktori i replikimit të grupit). Me fjalë të tjera, në nivelin logjik, objekti ruhet në një grup të caktuar vendosjeje, dhe në nivelin fizik - në disqet që i janë caktuar. Në këtë rast, disqet mund të vendosen fizikisht në nyje të ndryshme apo edhe në qendra të ndryshme të të dhënave.
Në këtë skemë, grupet e vendosjes duken si një nivel i domosdoshëm për fleksibilitetin e të gjithë zgjidhjes, por në të njëjtën kohë, si një hallkë shtesë në këtë zinxhir, që sugjeron në mënyrë të pavullnetshme një humbje produktiviteti. Për shembull, kur shkruani të dhëna, sistemi duhet t'i ndajë ato në këto grupe dhe më pas në nivel fizik në diskun kryesor dhe disqe për kopje. Kjo do të thotë, funksioni Hash funksionon kur kërkoni dhe futni një objekt, por ka një efekt anësor - është kosto shumë e lartë dhe kufizime në rindërtimin e hash-it (kur shtoni ose hiqni një disk). Një problem tjetër hash është vendndodhja e qartë e gozhduar e të dhënave që nuk mund të ndryshohet. Kjo do të thotë, nëse disi disku është nën ngarkesë të shtuar, atëherë sistemi nuk ka mundësinë të mos shkruajë në të (duke zgjedhur një disk tjetër), funksioni hash detyron që të dhënat të vendosen sipas rregullit, sado të këqija. disku është, kështu që Ceph ha shumë memorie kur rindërton PG në rast të vetë-shërimit ose rritjes së ruajtjes. Përfundimi është se Ceph funksionon mirë (megjithëse ngadalë), por vetëm kur nuk ka shkallëzime, situata emergjente ose përditësime.
Sigurisht, ka opsione për rritjen e performancës përmes caching dhe ndarjes së cache, por kjo kërkon harduer të mirë dhe do të ketë ende humbje. Por në përgjithësi, Ceph duket më joshëse se Gluster për produktivitetin. Gjithashtu, kur përdorni këto produkte, është e nevojshme të merret parasysh një faktor i rëndësishëm - ky është një nivel i lartë i kompetencës, përvojës dhe profesionalizmit me një theks të madh në Linux, pasi është shumë e rëndësishme të vendosni, konfiguroni dhe mirëmbani gjithçka në mënyrë korrekte, gjë që i imponon edhe më shumë përgjegjësi dhe barrë administratorit.
Vstorage
Arkitektura duket edhe më interesante , i cili mund të përdoret së bashku me një hipervizor në të njëjtat nyje, në të njëjtat , por është shumë e rëndësishme të konfiguroni gjithçka në mënyrë korrekte për të arritur performancë të mirë. Kjo do të thotë, vendosja e një produkti të tillë nga kutia në çdo konfigurim 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 këto janë vetëm disa shërbime ku është gjetur një hierarki kompakte optimale e komponentëve: shërbimi i klientit i montuar nëpërmjet FUSE (i modifikuar, jo me burim të hapur), shërbimi i meta të dhënave MDS (Shërbimi metadata), shërbimi i blloqeve të të dhënave të shërbimit Chunk, i cili në nivel fizik është i barabartë me një disk dhe kaq. Për sa i përket shpejtësisë, natyrisht, është optimale të përdoret një skemë tolerante ndaj gabimeve me dy kopje, por nëse përdorni memorien e memories dhe regjistrat në disqet SSD, atëherë kodimi tolerant ndaj gabimeve (kodimi i fshirjes ose bastisja 6) mund të mbingarkohet mirë në një skemë hibride ose edhe më mirë në të gjithë blicët. Ka disa disavantazhe me EC (kodimi i fshirjes): kur ndryshoni një bllok të dhënash, është e nevojshme të rillogaritni shumat e barazisë. Për të anashkaluar humbjet që lidhen me këtë operacion, Ceph i shkruan EC me vonesë dhe problemet e performancës mund të ndodhin gjatë një kërkese të caktuar, kur, për shembull, të gjitha blloqet duhet të lexohen, dhe në rastin e Virtuozzo Storage, kryhet shkrimi i blloqeve të ndryshuara. duke përdorur qasjen e "sistemit të skedarëve të strukturuar me log", e cila minimizon kostot e llogaritjes së barazisë. Për të vlerësuar afërsisht opsionet me përshpejtimin e punës me dhe pa EC, ekzistojnë – shifrat mund të jenë të përafërta në varësi të koeficientit të saktësisë së prodhuesit të pajisjeve, por rezultati i llogaritjeve është një ndihmë e mirë në planifikimin e konfigurimit.
Një diagram i thjeshtë i përbërësve të ruajtjes nuk do të thotë që këta përbërës nuk thithen por nëse i llogaritni të gjitha kostot paraprakisht, mund të mbështeteni në bashkëpunimin pranë hipervizorit.
Ekziston një skemë për krahasimin e konsumit të burimeve harduerike nga shërbimet e ruajtjes Ceph dhe Virtuozzo.
Nëse më parë ishte e mundur të krahasoheshin Gluster dhe Ceph duke përdorur artikuj të vjetër, duke përdorur linjat më të rëndësishme prej tyre, atëherë me Virtuozzo është më e vështirë. Nuk ka shumë artikuj për këtë produkt dhe informacioni mund të merret vetëm nga dokumentacioni në vazhdim ose në rusisht nëse e konsiderojmë Vstorage si ruajtje që përdoret në disa zgjidhje hiperkonvergjente në kompani si p.sh dhe Acronis.
Do të përpiqem të ndihmoj me një përshkrim të kësaj arkitekture, kështu që do të ketë pak më shumë tekst, por kërkon shumë kohë për ta kuptuar vetë dokumentacionin dhe dokumentacioni ekzistues mund të përdoret si referencë vetëm duke rishikuar tabelën të përmbajtjes ose kërkimi me fjalë kyçe.
Le të shqyrtojmë procesin e regjistrimit në një konfigurim harduerik hibrid me komponentët e përshkruar më sipër: regjistrimi fillon të shkojë në nyjen nga e cila klienti e ka inicuar atë (shërbimi i pikës së montimit FUSE), por komponenti kryesor i shërbimit meta të dhënave (MDS) sigurisht që do drejtojeni klientin drejtpërdrejt në shërbimin e dëshiruar të copës (blloqet CS të shërbimit të ruajtjes), domethënë, MDS nuk merr pjesë në procesin e regjistrimit, por thjesht e drejton shërbimin në pjesën e kërkuar. Në përgjithësi, mund të japim një analogji me regjistrimin me derdhjen e ujit në fuçi. Çdo fuçi është një bllok të dhënash 256 MB.
Kjo do të thotë, një disk është një numër i caktuar i fuçive të tilla, domethënë vëllimi i diskut i ndarë me 256 MB. Çdo kopje shpërndahet në një nyje, e dyta pothuajse paralelisht me një nyje tjetër, etj... Nëse kemi tre kopje dhe ka disqe SSD për cache (për leximin dhe shkrimin e regjistrave), atëherë konfirmimi i shkrimit do të ndodhë pas shkrimit. regjistri në SSD dhe rivendosja paralele nga SSD do të vazhdojë në HDD, sikur në sfond. Në rastin e tre kopjeve, regjistrimi do të kryhet pas konfirmimit nga SSD i nyjës së tretë. Mund të duket se shuma e shpejtësisë së shkrimit të tre SSD-ve mund të ndahet me tre dhe do të marrim shpejtësinë e shkrimit të një kopje, por kopjet shkruhen paralelisht dhe shpejtësia e vonesës së rrjetit është zakonisht më e lartë se ajo e SSD, dhe në fakt performanca e shkrimit do të varet nga rrjeti. Në këtë drejtim, për të parë IOPS të vërtetë, duhet të ngarkoni saktë të gjithë Vstorage nga , domethënë testimi i ngarkesës reale, dhe jo i memories dhe cache, ku është e nevojshme të merret parasysh madhësia e saktë e bllokut të të dhënave, numri i temave, etj.
Regjistri i lartpërmendur i regjistrimit në SSD funksionon në atë mënyrë që sapo të futen të dhënat në të, lexohet menjëherë nga shërbimi dhe shkruhet në HDD. Ekzistojnë disa shërbime metadata (MDS) për grup dhe numri i tyre përcaktohet nga një kuorum, i cili funksionon sipas algoritmit Paxos. Nga këndvështrimi i klientit, pika e montimit FUSE është një dosje e ruajtjes së grupit që është njëkohësisht e dukshme për të gjitha nyjet në grup, çdo nyje ka një klient të montuar sipas këtij parimi, kështu që kjo ruajtje është e disponueshme për çdo nyje.
Për performancën e cilësdo prej qasjeve të përshkruara më sipër, është shumë e rëndësishme, në fazën e planifikimit dhe vendosjes, të konfigurohet saktë rrjeti, ku do të ketë balancim për shkak të grumbullimit dhe gjerësisë së brezit të kanalit të rrjetit të zgjedhur saktë. Në grumbullim, është e rëndësishme të zgjidhni mënyrën e duhur të hashimit dhe madhësitë e kornizës. Ekziston gjithashtu një ndryshim shumë i fortë nga SDS i përshkruar më sipër, ky është siguresa me teknologjinë e rrugës së shpejtë në Virtuozzo Storage. E cila, përveç siguresës së modernizuar, ndryshe nga zgjidhjet e tjera me burim të hapur, rrit ndjeshëm IOPS dhe ju lejon të mos kufizoheni nga shkallëzimi horizontal ose vertikal. Në përgjithësi, krahasuar me arkitekturat e përshkruara më sipër, kjo duket më e fuqishme, por për një kënaqësi të tillë, natyrisht, duhet të blini licenca, ndryshe nga Ceph dhe Gluster.
Për ta përmbledhur, mund të theksojmë majën e tre: Virtuozzo Storage zë vendin e parë për sa i përket performancës dhe besueshmërisë së arkitekturës, Ceph zë vendin e dytë dhe Gluster zë vendin e tretë.
Kriteret me të cilat u zgjodh Virtuozzo Storage: është një grup përbërësish arkitekturor optimal, i modernizuar për këtë qasje Fuse me rrugë të shpejtë, një grup fleksibël konfigurimesh harduerike, më pak konsum burimesh dhe aftësi për të ndarë me llogaritjen (kompjuterim/virtualizim), domethënë, është plotësisht i përshtatshëm për një zgjidhje hiperkonvergjente, pjesë e së cilës ai është. Vendi i dytë është Ceph sepse është një arkitekturë më produktive në krahasim me Gluster, për shkak të funksionimit të tij në blloqe, si dhe skenarëve më fleksibël dhe aftësisë për të punuar në grupime më të mëdha.
Ka plane për të shkruar një krahasim midis vSAN, Space Direct Storage, Vstorage dhe Nutanix Storage, testimin e Vstorage në pajisjet HPE dhe Huawei, si dhe skenarë për integrimin e Vstorage me sistemet e ruajtjes së harduerit të jashtëm, kështu që nëse ju pëlqeu artikulli, do të ishte është mirë të marr komente nga ju, të cilat mund të rrisin motivimin për artikuj të rinj, duke marrë parasysh komentet dhe dëshirat tuaja.
Burimi: www.habr.com