Ky artikull është shkruar për të ndihmuar në zgjedhjen e zgjidhjes së duhur dhe për të kuptuar dallimet midis SDS si Gluster, Ceph dhe Vstorage (Virtuozzo).
Në tekst janë përdorur lidhje në artikuj me një shpjegim më të detajuar të problemeve të ndryshme, ndaj përshkrimet do të jenë sa më të shkurtër duke përdorur pika kyçe pa ujë të tepërt dhe informacion hyrëse, të cilat mund t'i gjeni vetë në hapësirën e internetit.
Në të vërtetë, temat që trajtohen kërkojnë një ton të caktuar, por në botën moderne, gjithnjë e më shumë njerëz nuk e duan të lexojnë shumë))), ndaj mund të bëhet një lexim i shpejtë dhe të bësh një zgjedhje, dhe nëse ka diçka të paqartë mund të kalosh në lidhje ose të gurgullosh fjalë të paqarta))), dhe ky artikull është si një mbështjellës transparent për këto tema të thella, duke treguar përmbajtjen - momentet kryesore të secilës zgjidhje.
Gluster
Le të fillojmë me Gluster, i cili përdoret aktivisht nga prodhuesit e platformave hiper-konvergjente me SDS të bazuar në open source për mjedise virtuale dhe mund të gjendet në faqen e internetit të RedHat në seksionin storage, ku ofrohet mundësia të zgjidhni 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Ă« skedareve etj. Brick â shĂ«rbimi qĂ« trajton njĂ« disk, Volume â njĂ« vĂ«llim (pools) â qĂ« bashkon kĂ«to brick. MĂ« pas ka njĂ« shĂ«rbim pĂ«r shpĂ«rndarjen e skedareve nĂ« grupe falĂ« funksionalitetit DHT (tabela e shkallĂ«zuar e shpĂ«rndarjes). Nuk do ta pĂ«rfshijmĂ« shĂ«rbimin Sharding nĂ« kĂ«tĂ« pĂ«rshkrim pasi nĂ« lidhjet e paraqitura mĂ« poshtĂ« do tĂ« gjeni pĂ«rshkrime tĂ« problemeve qĂ« lidhen me tĂ«.
Kur shkruhet një skedar, ai shkruhet krejtësisht në brick dhe një kopje e tij shkruhet paralelisht në brick në serverin e dytë. Më pas, skedari i dytë do të shkruhet në grupin e dytë të dy brick'ave (ose më shumë) në servera të ndryshëm.
Nëse skedarët kanë përafërsisht të njëjtën madhësi dhe vëllimi do të përbëhet vetëm nga një grup, gjithçka është në rregull, por në kushte të tjera do të lindin problemet e përshkruara si më poshtë:
- vendet në grupe shpërndahet në mënyrë të pabarabartë, kjo varet nga përmasat e skedarëve dhe nëse në grup nuk ka mjaftueshëm vend për të shkruar skedarin - do të merrni një gabim, skedari nuk do të shkruhet dhe nuk do të shpërndahet në një grup tjetër;
- kur shkruhet një skedar, IO ndodh vetëm në një grup, grupet e tjera mbeten të papërdorura;
- nuk është e mundur të marrësh IO të gjithë volumit kur shkruan një skedar;
- dhe koncepti i përgjithshëm duket më pak efikas për shkak të mungesës së shpërndarjes së të dhënave në blloqe, ku është më e lehtë të realizosh balancimin dhe të zgjidhësh problemin e shpërndarjes së barabartë, përveçse siç është tani që skedari vendoset në bllok të tërë.
Nga pĂ«rshkrimi zyrtar vjen edhe ndjenjĂ« e paqĂ«llimshme se gluster funksionon si njĂ« ruajtĂ«s skedari mbi RAID-in klasik harduerik. Ishte tentuar tĂ« zhvillohej ndarje (Sharding) e skedarĂ«ve nĂ« blloqe, por kĂ«to janĂ« shtesa qĂ« sjellin humbje tĂ« performancĂ«s mbi qasjen ekzistuese arkitekturore, plus pĂ«rdorimi i komponentĂ«ve tĂ« lĂ«shuar falas me kufizime nĂ« performancĂ« si Fuse. Nuk ka shĂ«rbime tĂ« metadatas, qĂ« e kufizon performancĂ«n dhe disponueshmĂ«rinĂ« e ruajtjes gjatĂ« shpĂ«rndarjes sĂ« skedarĂ«ve nĂ« blloqe. Performanca mĂ« e mirĂ« mund tĂ« vĂ«rehet nĂ« konfigurimin âDistributed Replicatedâ dhe numri i nodave duhet tĂ« jetĂ« tĂ« paktĂ«n 6 pĂ«r tĂ« organizuar njĂ« replikim tĂ« besueshĂ«m nĂ« 3 me shpĂ«rndarje optimale tĂ« ngarkesĂ«s.
Këto përfundime janë gjithashtu të lidhura me përshkrimin e përvojës së përdorimit dhe gjatë krahasimit me , si dhe ka një përshkrim të përvojës në kuptimin e kësaj konfigurimi më të avancuar dhe më të besueshëm
NĂ« imazh tregohet shpĂ«rndarja e ngarkesĂ«s gjatĂ« regjistrimit tĂ« dy skedarĂ«ve, ku kopjet e skedarit tĂ« parĂ« shpĂ«rndahen nĂ« tre serverat e parĂ«, tĂ« cilĂ«t janĂ« tĂ« grupuar nĂ« grupin volume 0, dhe tre kopjet e skedarit tĂ« dytĂ« vendosen nĂ« grupin e dytĂ« volume 1 tĂ« tre serverĂ«ve. Ădo server ka njĂ« disk.
Konkluzioni është se mund të përdoret Gluster, por me kuptimin se ka kufizime në performancë dhe qëndrueshmëri, të cilat krijojnë vështirësi në kushte të caktuara të zgjidhjeve hiper-konverguese, ku burimet nevojiten gjithashtu për ngarkesa të llogaritjeve të mjediseve virtuale.
Ka disa gjithashtu tregues të performancës së Gluster që mund të arrihen nën kushte të caktuara.
Ceph
Tani le të shqyrtojmë Ceph nga përshkrimet e arkitekturës, të cilat kam arritur të gjej. Ka gjithashtu një krahasim midis , ku mund të kuptohet menjëherë se Ceph preferohet të vendoset në servera të veçantë, pasi shërbimeve të tij u nevojiten të gjitha burimet e harduerit nën ngarkesa.
Arkitektura më e komplikuar se Gluster, dhe ka shërbime si shërbimet e meta-datat, por e gjithë staka e komponentëve është mjaft e ndërlikuar dhe jo shumë fleksibile për t'u përdorur në zgjidhjet e virtualizimit. Të dhënat janë të vendosura në blloqe, që duket se është më e efektshme, por ka humbje dhe latency në hierarkinë e të gjitha shërbimeve (komponentëve) në disa ngarkesa dhe kushte emergjente, për shembull, e mëposhtme.
Nga pĂ«rshkrimi i arkitekturĂ«s, zemra Ă«shtĂ« CRUSH, falĂ« tĂ« cilit zgjidhet vendi pĂ«r vendosjen e tĂ« dhĂ«nave. MĂ« pas vjen PG â kjo Ă«shtĂ« abstraksioni mĂ« i komplikuar (grupi logjik) pĂ«r t'u kuptuar. PG-tĂ« janĂ« tĂ« nevojshme qĂ« CRUSH tĂ« jetĂ« mĂ« efikas. QĂ«llimi kryesor i PG-sĂ« Ă«shtĂ« grumbullimi i objekteve pĂ«r tĂ« reduktuar konsumimin e burimeve, pĂ«r tĂ« rritur performancĂ«n dhe shkallĂ«zueshmĂ«rinĂ«. Adresimi i objekteve direkt, veç e veç, pa i grupuar ato nĂ« PG do tĂ« ishte shumĂ« i kushtueshĂ«m. OSD â Ă«shtĂ« shĂ«rbimi pĂ«r çdo disk tĂ« veçantĂ«.
Klusteri mund tĂ« ketĂ« njĂ« ose shumĂ« grupe tĂ« dhĂ«nash me qĂ«llime tĂ« ndryshme dhe me cilĂ«sime tĂ« ndryshme. Grupet ndahen nĂ« grupe vendosjeje. NĂ« grupet vendosjeje ruhen objektet qĂ« aksesohen nga klientĂ«t. NĂ« kĂ«tĂ« nivel logjik pĂ«rfundon dhe fillon niveli fizik, pasi çdo grup vendosjeje Ă«shtĂ« i lidhur me njĂ« disk kryesor dhe disa disqe replikĂ« (sa tĂ« tilla, varet nga faktori i replikimit tĂ« grupit). Me fjalĂ« tĂ« tjera, nĂ« nivelin logjik, objekti ruhet nĂ« njĂ« grup vendosjeje tĂ« caktuar, ndĂ«rsa nĂ« nivelin fizik â nĂ« disqet qĂ« janĂ« lidhur me tĂ«. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, disqet fizikisht mund tĂ« qĂ«ndrojnĂ« nĂ« nyje 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 gjithsej zgjidhjes, por njĂ«kohĂ«sisht si njĂ« lidhje e tepĂ«rt nĂ« kĂ«tĂ« zinxhir, qĂ« pa dashje ndihmon nĂ« mendime pĂ«r humbjet nĂ« performancĂ«. PĂ«r shembull, kur regjistrohen tĂ« dhĂ«nat, sistemi duhet t'i ndajĂ« ato nĂ« kĂ«to grupe dhe mĂ« pas nĂ« nivelin fizik nĂ« diskun kryesor dhe nĂ« diskun e replikave. KĂ«shtu, funksioni hash funksionon gjatĂ« kĂ«rkimit dhe vendosjes sĂ« objektit, por ka njĂ« efekt anĂ«sor â kjo kĂ«rkon shpenzime shumĂ« tĂ« mĂ«dha dhe kufizime nĂ« rindĂ«rtimin e hash-it (nĂ« rastin e shtimit ose fshirjes sĂ« disku). NjĂ« problem tjetĂ«r i hash-it Ă«shtĂ« vendosja e dhĂ«nave qĂ« Ă«shtĂ« e ngurtĂ« dhe nuk mund tĂ« ndryshohet. KĂ«shtu, nĂ«se ndonjĂ« disk pĂ«rjeton njĂ« ngarkesĂ« tĂ« madhe, sistemi nuk ka mundĂ«si tĂ« shkruajĂ« nĂ« tĂ« (duke zgjedhur njĂ« disk tjetĂ«r); funksioni hash e detyron vendosjen e tĂ« dhĂ«nave sipas njĂ« rregulli, pavarĂ«sisht se sa i keq i Ă«shtĂ« situata diskut. Prandaj, Ceph konsumon shumĂ« memorie gjatĂ« rindĂ«rtimit tĂ« PG nĂ« rastin e vetĂ«-shĂ«rimit ose zgjerimit tĂ« ruajtjes. Konkluzioni Ă«shtĂ« se Ceph funksionon mirĂ« (ndonĂ«se ngadalĂ«), por vetĂ«m kur nuk ka zgjerim, situata emergjente ose pĂ«rditĂ«sim.
Sigurisht ka mundësi për të përmirësuar performancën përmes caching dhe cache-tiering, por kjo kërkon harduer të mirë dhe do të ketë humbje gjithsesi. Sidoqoftë, në përgjithësi Ceph duket më tërheqës se Gluster për produktet. Gjithashtu, kur përdorni këto produkte, duhet të keni parasysh një faktor të rëndësishëm - niveli i lartë i kompetencës, përvojës dhe profesionalizmit me një theks të madh në Linux, pasi është shumë e rëndësishme që gjithçka të vihet në punë, konfigurohet dhe mbahen siç duhet, që i vë edhe më shumë përgjegjësi dhe ngarkesë mbi administratorin.
Vstorage
Arkitektura duket edhe më interesante te , që 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 konfiguroni siç duhet për të arritur një performancë të mirë. Pra, duke instaluar një produkt të tillë nga kutia në çdo lloj konfigurimi pa marrë parasysh rekomandimet sipas arkitekturës do të jetë shumë e lehtë, por jo produktive.
ĂfarĂ« mund tĂ« bashkĂ«jetojĂ« pĂ«r ruajtjen afĂ«r shĂ«rbimeve tĂ« hipervizorit kvm-qemu, dhe kjo Ă«shtĂ« vetĂ«m njĂ« grup shĂ«rbimesh, ku shihet njĂ« hierarki e kompaktĂ« optimale e komponentĂ«ve: shĂ«rbimi i klientit i montuar pĂ«rmes FUSE (i modifikuar, jo open source), shĂ«rbimi i metadata MDS (Metadata service), shĂ«rbimi i blloqeve tĂ« tĂ« dhĂ«nave Chunk service, i cili nĂ« nivelin fizik Ă«shtĂ« i barabartĂ« me njĂ« disk dhe kjo Ă«shtĂ« gjithçka. NĂ« shpejtĂ«si natyrisht, Ă«shtĂ« optimal tĂ« pĂ«rdorim njĂ« skemĂ« tĂ« qĂ«ndrueshmĂ«risĂ« me dy kopje, por nĂ«se pĂ«rdoren caching dhe regjistrat nĂ« disk SSD, atĂ«herĂ« kodimi pĂ«r mbrojtje nga ndĂ«rprerjet (erase coding ose raid6) mund tĂ« pĂ«rshpejtohet dukshĂ«m nĂ« njĂ« skemĂ« hibride ose madje edhe mĂ« mirĂ« nĂ« all flash. Me EC (erase coding) ka njĂ« disavantazh: kur ndryshohet njĂ« bllok tĂ« dhĂ«nash, nevojitet tĂ« llogaritet pĂ«rsĂ«ri shuma e paritetit. PĂ«r tĂ« zgjidhur humbjet nĂ« kĂ«tĂ« operacion, Ceph shkruan nĂ« EC rezerva dhe problemi me performancĂ«n mund tĂ« ndodhĂ« gjatĂ« njĂ« kĂ«rkese tĂ« caktuar, kur, pĂ«r shembull, nevojitet tĂ« llogariten tĂ« gjithĂ« blloqet, ndĂ«rsa nĂ« rastin e Virtuozzo Storage, regjistrimi i blloqeve tĂ« ndryshuara bĂ«het duke pĂ«rdorur qasjen âlog-structured file systemâ, e cila minimizon kostot pĂ«r llogaritjen e paritetit. PĂ«r tĂ« marrĂ« njĂ« ide tĂ« pĂ«rafĂ«rt pĂ«r alternativat me pĂ«rshpejtim tĂ« punĂ«s me EC dhe pa, ka â numrat mund tĂ« jenĂ« tĂ« pĂ«rafĂ«rt nĂ« varĂ«si tĂ« koeficientit tĂ« saktĂ«sisĂ« sĂ« prodhuesit tĂ« pajisjeve, por rezultati i llogaritjeve ndihmon mirĂ« nĂ« planifikimin e konfiguracionit.
Një skemë e thjeshtë e komponentëve të ruajtjes nuk do të thotë që këta komponentë nuk konsumojnë por nëse llogariten të gjitha shpenzimet paraprakisht, atëherë mund të shpresohet për një bashkëpunim përkrah hipervizorit.
Ka një skemë krahasimi të konsumit të burimeve të harduerit 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 nga ata, tani është më e vështirë me Virtuozzo. 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 shqyrtohet Vstorage si një ruajtje e përdorur në disa zgjidhje hiperzhvistuese në kompani të tilla si dhe Acronis.
Do të provoj të ndihmoj me përshkrimin e kësaj arkitekture, prandaj teksti do të jetë pak më i gjatë, por për t'u kuptuar dokumentacioni kërkon shumë kohë, dhe dokumentacionin e disponueshëm mund ta përdorim vetëm si udhëzues duke e shqyrtuar 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 nisi klienti (shĂ«rbimi i pikĂ«s sĂ« montimit FUSE), por komponenti i shĂ«rbimit tĂ« metadatat (MDS) sigurisht qĂ« do ta drejtojĂ« klientin drejtpĂ«rdrejt nĂ« shĂ«rbimin e nevojshĂ«m tĂ« bllokut (shĂ«rbimi i ruajtjes CS), domethĂ«nĂ« MDS nuk merr pjesĂ« nĂ« procesin e regjistrimit, por thjesht drejton nĂ« shĂ«rbimin e nevojshĂ«m tĂ« bllokut. NĂ« pĂ«rgjithĂ«si, mund tĂ« japim njĂ« analogji tĂ« regjistrimit, si derdhja e ujit nĂ« fuçi. Ădo fuçi Ă«shtĂ« njĂ« bllok tĂ« dhĂ«nash prej 256MB.
Pra ndaj, njĂ« disk Ă«shtĂ« njĂ« sasi e tillĂ« barrĂ«, qĂ« do tĂ« thotĂ« qĂ« volumi i diskut ndahen nĂ« 256MB. Ădo kopje shpĂ«rndahet nĂ« njĂ« nĂ«nyrĂ«, e dyta pothuajse paralelisht nĂ« njĂ« nĂ«nyrĂ« tjetĂ«r etj... NĂ«se kemi tre replika dhe gjithashtu SSD pĂ«r caching (pĂ«r lexim dhe regjistrat e shkrimit), konfirmimi i shkrimit do tĂ« ndodhĂ« pas regjistrimit tĂ« regjistrit nĂ« SSD, dhe ndĂ«rkohĂ«, shkarkimi paralel nga SSD do tĂ« vazhdojĂ« nĂ« HDD, si njĂ« proces nĂ« prapavijĂ«. NĂ« rastin e tre replikave, konfirmimi i shkrimit do tĂ« jetĂ« pas konfirmimit nga SSD e nĂ«nyrĂ«s sĂ« tretĂ«. Mund tĂ« duket se shpejtĂ«sia e shkrimit tĂ« tre SSD-ve mund tĂ« ndajĂ« nĂ« tre dhe do tĂ« kemi shpejtĂ«sinĂ« e shkrimit tĂ« njĂ« replike, por shkruarja e kopjeve ndodh paralelisht dhe latenca e rrjetit Ă«shtĂ« zakonisht mĂ« e lartĂ« se ajo e SSD-ve, dhe nĂ« esencĂ«, performanca e shkrimit do tĂ« varet nga rrjeti. Prandaj, pĂ«r tĂ« parĂ« IOPS reale, Ă«shtĂ« e nevojshme tĂ« ngarkohet saktĂ«sisht e gjithĂ« Vstorage sipas , qĂ« do tĂ« thotĂ«, tĂ« testosh ngarkesĂ«n reale, dhe jo memorien dhe cache, ku Ă«shtĂ« e nevojshme tĂ« merret parasysh madhĂ«sia e duhur e bllokut tĂ« tĂ« dhĂ«nave, numri i rrjedhave etj.
Revista e përmendur mbi SSD funksionon në mënyrë që sa herë që të dhënat arrijnë, ato menjëherë lexohen nga shërbimi dhe shkruhen në HDD. Ka disa shërbime të metadatat (MDS) për grumbullin dhe numri i tyre përcaktohet nga kuorumi, i cili operon sipas algoritmit Paxos. Nga pikëpamja e klientit, pika e montimit FUSE është një dosje e ruajtjes së grumbullit, e cila është e dukshme për të gjitha nodet e grumbullit; çdo nodë ka një klient të montuar në këtë mënyrë, prandaj kjo ruajtje është e aksesueshme për çdo nyje.
Për performancën e secilës nga qasjet e përmendura më sipër, është shumë e rëndësishme, në fazën e planifikimit dhe implementimit, të konfigurohet siç duhet rrjeti, ku do të bëhet balancimi përmes agregimit dhe zgjedhjes së duhur të kapacitetit të kanalit rrjetë. Në agregim është e rëndësishme të përzgjidhen në mënyrë të duhur modet e hash-it dhe madhësitë e frame-ve. Ka gjithashtu një dallim shumë të fortë nga SDS-të e përmendura më sipër, kjo është fuse me teknologjinë fast path në Virtuozzo Storage. I cili, përveç fuse të modernizuar, ndryshe nga zgjidhjet e tjera open source, ndjeshëm rrit IOPS-të dhe lejon që të mos kufizoheni në horizontal ose vertikal. Në përgjithësi, në krahasim me arkitekturat e përmendura më sipër, kjo duket më e fuqishme, por për këtë kënaqësi, natyrisht, nevojiten licenca, ndryshe nga Ceph dhe Gluster.
Duke përmbledhur, mund të theksojmë tri të parat: vendi i parë për performancë dhe besueshmëri në arkitekturë i takon Virtuozzo Storage, vendi i dytë Ceph dhe vendi i tretë Gluster.
Kriteret për të cilat u zgjodh Virtuozzo Storage: ky është një set optimal komponentësh arkitekture, i modernizuar për këtë qasje Fuse me fast path, një grup fleksibil konfigurimi të harduerit, konsum më të ulët të burimeve dhe mundësinë e ndarjes me compute (llogaritjet/virtualizimin), që do të thotë se është plotësisht i përshtatshëm për një zgjidhje hiper-konvergjente, me të cilën ai shkon. Vendi i dytë Ceph, sepse kjo është një arkitekturë më e fuqishme përpara Gluster, për shkak të operimit me blloqe, si dhe skenarëve më fleksibël dhe mundësisë për të punuar në klastera më të mëdhenj.
Në planet është dëshira për të shkruar një krahasim midis vSAN, Space Direct Storage, Vstorage dhe Nutanix Storage, testimi i Vstorage në pajisjet HPE, Huawei, si dhe skenarët e integrimit të Vstorage me pajisje të jashtme të sistemit të ruajtjes, prandaj nëse artikulli ju pëlqeu, do të ishte mirë të merrnim nga ju komente, të cilat mund të forcojnë motivimin për artikuj të rinj duke marrë parasysh vërejtjet dhe kërkesat tuaja.
Burimi: habr.com
