Stutt samanburður á SDS arkitektúr eða að finna rétta geymslupallinn (GlusterVsCephVsVirtuozzoStorage)

Þessi grein var skrifuð til að hjálpa þér að velja réttu lausnina fyrir þig og skilja muninn á SDS eins og Gluster, Ceph og Vstorage (Virtuozzo).

Í textanum eru tenglar á greinar með ítarlegri uppljóstrun um ákveðin vandamál, þannig að lýsingarnar verða eins stuttar og hægt er, þar sem lykilatriði eru notuð án óþarfa flúrs og kynningarupplýsingar sem þú getur, ef þú vilt, nálgast sjálfstætt á netinu.

Reyndar krefjast umfjöllunarefnin auðvitað tóna textans, en í nútímanum líkar fleiri og fleiri ekki að lesa mikið))), svo þú getur fljótt lesið og valið, og ef eitthvað er ekki ljóst, fylgdu krækjunum eða gúgglaðu óljós orð))), og þessi grein er eins og gagnsæ umbúðir fyrir þessi djúpu efni, sem sýnir fyllinguna - helstu lykilatriði hverrar ákvörðunar.

Glans

Byrjum á Gluster, sem er virkur notaður af framleiðendum ofursamsettra kerfa með SDS byggt á opnum uppspretta fyrir sýndarumhverfi og er að finna á RedHat vefsíðunni í geymsluhlutanum, þar sem þú getur valið um tvo SDS valkosti: Gluster eða Ceph.

Gluster samanstendur af stafla af þýðendum - þjónustu sem framkvæma alla vinnu við að dreifa skrám o.s.frv. Brick er þjónusta sem þjónustar einn disk, Volume er bindi (laug) sem sameinar þessa múrsteina. Næst kemur þjónustan til að dreifa skrám í hópa með því að nota DHT (distributed hash table) aðgerðina. Við munum ekki hafa Sharding þjónustuna með í lýsingunni þar sem hlekkirnir hér að neðan munu lýsa vandamálunum sem tengjast henni.

Þegar skrifað er er öll skráin geymd í múrsteinum og afrit hennar er samtímis skrifað í múrsteinn á öðrum þjóninum. Næst verður önnur skráin skrifuð í seinni hópinn af tveimur múrsteinum (eða fleiri) á mismunandi netþjónum.

Ef skrárnar eru um það bil sömu stærðar og rúmmálið samanstendur af aðeins einum hópi, þá er allt í lagi, en við aðrar aðstæður munu eftirfarandi vandamál koma upp úr lýsingunum:

• pláss í hópum nýtist ójafnt, það fer eftir stærð skráa og ef það er ekki nóg pláss í hópnum til að skrifa skrá færðu villu, skráin verður ekki skrifuð og verður ekki endurdreift í annan hóp ;
• þegar þú skrifar eina skrá fer IO aðeins í einn hóp, restin er aðgerðalaus;
• þú getur ekki fengið IO af öllu hljóðstyrknum þegar þú skrifar eina skrá;
• og almenna hugtakið lítur minna afkastamikið út vegna skorts á gagnadreifingu í blokkir, þar sem auðveldara er að jafnvægi og leysa vandamálið við samræmda dreifingu, en ekki eins og nú fer öll skráin í blokk.

Frá opinberri lýsingu arkitektúr við komumst líka ósjálfrátt að þeim skilningi að gluster virkar sem skráageymsla ofan á klassískt vélbúnaðar RAID. Þróunartilraunir hafa verið gerðar til að klippa (Sharding) skrár í blokkir, en allt er þetta viðbót sem veldur afköstum á núverandi byggingaraðferð, auk notkunar á svo frjálslega dreifðum íhlutum með takmarkanir á frammistöðu eins og Fuse. Það eru engar lýsigagnaþjónustur, sem takmarkar frammistöðu og bilanaþolsgetu geymslunnar þegar skrám er dreift í blokkir. Hægt er að sjá betri frammistöðuvísa með „Dreifðum endurteknum“ stillingum og fjöldi hnúta ætti að vera að minnsta kosti 6 til að skipuleggja áreiðanlega eftirmynd 3 með bestu álagsdreifingu.

Þessar niðurstöður tengjast einnig lýsingu á upplifun notenda Glans og þegar borið er saman við ceph, og það er líka lýsing á reynslunni sem leiðir til skilnings á þessari afkastameiri og áreiðanlegri uppsetningu „Afritað dreift“.


Myndin sýnir álagsdreifingu þegar tvær skrár eru skrifaðar, þar sem afrit af fyrstu skránni er dreift yfir fyrstu þrjá netþjónana, sem eru sameinuð í bindi 0 hópinn, og þrjú afrit af annarri skránni eru sett á seinni hópinn bindi1 af þremur netþjóna. Hver þjónn hefur einn disk.

Almenn niðurstaða er sú að hægt er að nota Gluster, en með þeim skilningi að það verða takmarkanir á frammistöðu og bilanaþoli sem skapa erfiðleika við ákveðnar aðstæður fyrir ofsamruna lausn, þar sem einnig þarf fjármagn fyrir tölvuálag sýndarumhverfis.

Það eru líka nokkrir Gluster frammistöðuvísar sem hægt er að ná við ákveðnar aðstæður, takmarkað við bilanaþol.

ceph

Nú skulum við líta á Ceph út frá arkitektúrlýsingunum sem ég gat finna. Það er líka samanburður á milli Glusterfs og Ceph, þar sem þú getur strax skilið að það er ráðlegt að setja Ceph á aðskilda netþjóna, þar sem þjónusta þess krefst allra vélbúnaðarauðlinda undir álagi.

arkitektúr Ceph flóknari en Gluster og það eru þjónusta eins og lýsigagnaþjónusta, en allur staflan af íhlutum er frekar flókinn og ekki mjög sveigjanlegur til að nota hann í sýndarvæðingarlausn. Gögnin eru geymd í blokkum, sem lítur út fyrir að vera afkastameiri, en í stigveldi allra þjónustu (íhluta) eru tap og leynd við ákveðnar álag og neyðaraðstæður, til dæmis eftirfarandi grein.

Frá lýsingunni á arkitektúrnum er hjartað CRUSH, þökk sé því sem staðsetningin til að geyma gögn er valin. Næst kemur PG - þetta er erfiðasta abstrakt (rökréttur hópur) að skilja. Það þarf PG til að gera CRUSH áhrifaríkari. Megintilgangur PG er að flokka hluti til að draga úr auðlindanotkun, auka afköst og sveigjanleika. Að taka á hlutum beint, hver fyrir sig, án þess að sameina þá í PG væri mjög dýrt. OSD er þjónusta fyrir hvern einstakan disk.

Þyrping getur haft einn eða marga gagnasafn í mismunandi tilgangi og með mismunandi stillingar. Laugum er skipt í staðsetningarhópa. Staðsetningarhópar geyma hluti sem viðskiptavinir fá aðgang að. Þetta er þar sem rökrétta stigið endar og líkamlega stigið byrjar, vegna þess að hverjum staðsetningarhópi er úthlutað einum aðaldiski og nokkrum eftirlíkingum af diskum (hversu margir eru nákvæmlega háðir hópafritunarstuðlinum). Með öðrum orðum, á rökréttu stigi er hluturinn geymdur í tilteknum staðsetningarhópi og á líkamlegu stigi - á diskunum sem honum er úthlutað. Í þessu tilviki geta diskarnir verið líkamlega staðsettir á mismunandi hnútum eða jafnvel í mismunandi gagnaverum.

Í þessu kerfi líta staðsetningarhópar út eins og nauðsynlegt stig fyrir sveigjanleika allrar lausnarinnar, en á sama tíma sem auka hlekkur í þessari keðju, sem ósjálfrátt bendir til taps á framleiðni. Til dæmis, þegar gögn eru skrifuð, þarf kerfið að skipta þeim í þessa hópa og síðan á líkamlegu stigi í aðaldiskinn og diska fyrir eftirlíkingar. Það er að segja að Hash-aðgerðin virkar þegar leitað er og settur inn hlutur, en það er aukaverkun - það er mjög mikill kostnaður og takmarkanir á að endurbyggja kjötkássa (þegar verið er að bæta við eða fjarlægja disk). Annað hassvandamál er greinilega negld staðsetning gagna sem ekki er hægt að breyta. Það er að segja, ef diskurinn er einhvern veginn undir auknu álagi, þá hefur kerfið ekki möguleika á að skrifa ekki á hann (með því að velja annan disk), kjötkássaaðgerðin skyldar gögnin til að vera staðsett samkvæmt reglunni, sama hversu slæm diskurinn er, þannig að Ceph étur mikið af minni þegar hann endurbyggir PG ef um er að ræða sjálfsheilun eða aukið geymslupláss. Niðurstaðan er sú að Ceph virkar vel (að vísu hægt), en aðeins þegar það er engin mælikvarði, neyðartilvik eða uppfærslur.

Það eru auðvitað möguleikar til að auka afköst með skyndiminni og deilingu skyndiminni, en þetta krefst góðs vélbúnaðar og tap verður samt. En á heildina litið virðist Ceph meira freistandi en Gluster fyrir framleiðni. Einnig, þegar þessar vörur eru notaðar, er nauðsynlegt að taka tillit til mikilvægs þáttar - þetta er mikil hæfni, reynsla og fagmennska með mikla áherslu á Linux, þar sem það er mjög mikilvægt að dreifa, stilla og viðhalda öllu rétt, sem leggur enn meiri ábyrgð og byrðar á stjórnandann.

Vgeymsla

Arkitektúrinn lítur enn áhugaverðari út Virtuozzo geymsla (Vstorage), sem hægt er að nota í tengslum við hypervisor á sömu hnútum, á sama kirtill, en það er mjög mikilvægt að stilla allt rétt til að ná góðum árangri. Það er, að dreifa slíkri vöru úr kassanum á hvaða uppsetningu sem er án þess að taka tillit til ráðlegginga í samræmi við arkitektúrinn verður mjög auðvelt, en ekki afkastamikið.

Hvað getur verið samhliða geymslu við hliðina á þjónustu kvm-qemu hypervisor, og þetta eru aðeins nokkrar þjónustur þar sem samsett ákjósanlegt stigveldi íhluta hefur fundist: viðskiptavinaþjónusta sett upp í gegnum FUSE (breytt, ekki opinn uppspretta), MDS lýsigagnaþjónusta (Lýsigagnaþjónusta), þjónusta Chunk þjónustugagnablokkir, sem á líkamlegu stigi jafnast á við einn disk og það er allt. Hvað varðar hraða er auðvitað ákjósanlegt að nota villuþolið kerfi með tveimur eftirlíkingum, en ef þú notar skyndiminni og logs á SSD drifum, þá er hægt að yfirklukka villuþolna kóðun (eyða kóðun eða raid6) þokkalega á a hybrid kerfi eða jafnvel betra á all flash. Það er einhver ókostur við EC (eyðakóðun): þegar einni gagnablokk er breytt er nauðsynlegt að endurreikna jöfnunarupphæðirnar. Til að komast framhjá tapinu sem tengist þessari aðgerð skrifar Ceph til EC seint og frammistöðuvandamál geta komið upp á meðan á ákveðinni beiðni stendur, þegar til dæmis þarf að lesa alla kubba, og þegar um Virtuozzo Storage er að ræða, fer fram ritun breyttra kubba. með því að nota „log-structured file system“ nálgunina, sem lágmarkar kostnað við jöfnunarútreikning. Til að áætla um það bil valkostina með hröðun vinnu með og án EC, það eru reiknivél. – tölurnar geta verið áætluð eftir nákvæmnisstuðul framleiðanda búnaðarins, en niðurstaða útreikninganna er góð hjálp við að skipuleggja uppsetninguna.

Einföld skýringarmynd af geymsluíhlutum þýðir ekki að þessir íhlutir gleypi ekki járnauðlindir, en ef þú reiknar allan kostnað fyrirfram geturðu treyst á samvinnu við hlið yfirsýnarans.
Það er kerfi til að bera saman neyslu á vélbúnaðarauðlindum Ceph og Virtuozzo geymsluþjónustu.

Ef áður var hægt að bera saman Gluster og Ceph með gömlum greinum, með því að nota mikilvægustu línurnar úr þeim, þá er það erfiðara með Virtuozzo. Það eru ekki margar greinar um þessa vöru og upplýsingar er aðeins hægt að fá úr skjölunum á á ensku eða á rússnesku ef við lítum á Vstorage sem geymslu sem notað er í sumum ofsamræmdum lausnum í fyrirtækjum eins og Rosplatforma og Acronis.

Ég skal reyna að aðstoða við lýsingu á þessum arkitektúr, svo það verður aðeins meiri texti, en það tekur mikinn tíma að skilja skjölin sjálfur og aðeins er hægt að nota þau skjöl sem fyrir eru til viðmiðunar með því að endurskoða töfluna af innihaldi eða leit eftir lykilorði.

Við skulum íhuga upptökuferlið í blandaðri vélbúnaðarstillingu með íhlutunum sem lýst er hér að ofan: upptakan byrjar að fara í hnútinn sem viðskiptavinurinn hóf hana frá (FUSE-tengipunktaþjónustan), en lýsigagnaþjónustan (MDS) aðalhlutinn mun að sjálfsögðu beina viðskiptavininum beint í þá hlutaþjónustu sem óskað er eftir (geymsluþjónustu CS blokkir), það er að segja að MDS tekur ekki þátt í upptökuferlinu heldur beinir þjónustunni einfaldlega að tilskildum hluta. Almennt séð getum við gefið hliðstæðu við upptöku með því að hella vatni í tunnur. Hver tunna er 256MB gagnablokk.

Það er að segja að einn diskur er ákveðinn fjöldi slíkra tunna, það er diskurmagn deilt með 256MB. Hvert eintak er dreift á einn hnút, sá seinni er næstum samsíða öðrum hnút o.s.frv... Ef við erum með þrjár eftirlíkingar og það eru SSD diskar fyrir skyndiminni (til að lesa og skrifa logs), þá mun staðfesting á rituninni eiga sér stað eftir ritun skráin yfir á SSD, og ​​samhliða endurstilling frá SSD mun halda áfram á HDD, eins og í bakgrunni. Ef um er að ræða þrjár eftirlíkingar verður skráningin framin eftir staðfestingu frá SSD þriðja hnútsins. Það kann að virðast sem hægt sé að deila summan af skrifhraða þriggja SSD-diska með þremur og við fáum skrifhraða einnar eftirmyndar, en afritin eru skrifuð samhliða og biðhraði netkerfisins er venjulega hærri en SSD-disksins, og í raun mun skrifframmistaðan ráðast af netkerfinu. Í þessu sambandi, til að sjá alvöru IOPS, þarftu að hlaða öllu Vstorage rétt eftir aðferðafræði, það er að prófa raunverulegt álag, en ekki minni og skyndiminni, þar sem nauðsynlegt er að taka tillit til réttrar gagnablokkastærðar, fjölda þráða o.s.frv.

Ofangreind upptökuskrá á SSD-disknum virkar þannig að um leið og gögn berast inn í hann eru þau strax lesin af þjónustunni og skrifuð á harða diskinn. Það eru nokkrir lýsigagnaþjónustur (MDS) á hverjum klasa og fjöldi þeirra er ákvarðaður af ályktun, sem virkar samkvæmt Paxos reikniritinu. Frá sjónarhóli viðskiptavinarins er FUSE festingarpunkturinn klasageymslumöppu sem er sýnileg öllum hnútum í klasanum samtímis, hver hnút er með uppsettan viðskiptavin samkvæmt þessari meginreglu, þannig að þessi geymsla er aðgengileg hverjum hnút.

Til að framkvæma einhverja af ofangreindum aðferðum er mjög mikilvægt, á skipulags- og dreifingarstigi, að stilla netið rétt, þar sem jafnvægi verður vegna samsöfnunar og rétt valinnar bandbreiddar netrásar. Í samlagningu er mikilvægt að velja rétta kjötkássaham og rammastærðir. Það er líka mjög mikill munur frá SDS sem lýst er hér að ofan, þetta er öryggi með hraðbrautartækni í Virtuozzo Storage. Sem, auk nútímavæddu öryggisins, ólíkt öðrum opnum lausnum, eykur IOPS verulega og gerir þér kleift að takmarkast ekki af láréttri eða lóðréttri stærðargráðu. Almennt séð, miðað við arkitektúrinn sem lýst er hér að ofan, lítur þessi út fyrir að vera öflugri, en fyrir slíka ánægju þarftu auðvitað að kaupa leyfi, ólíkt Ceph og Gluster.

Til að draga saman þá getum við bent á toppinn af þremur: Virtuozzo Storage tekur fyrsta sæti hvað varðar frammistöðu og áreiðanleika arkitektúrsins, Ceph í öðru sæti og Gluster í þriðja sæti.

Viðmiðin sem Virtuozzo Storage var valin eftir: þetta er ákjósanlegt sett af byggingarhlutum, nútímavædd fyrir þessa Fuse nálgun með hröðum slóðum, sveigjanlegu setti vélbúnaðarstillinga, minni auðlindanotkun og getu til að deila með tölvu (tölvu/sýndarvæðingu), það er, það er alveg hentugur fyrir hyperconverged lausn, sem hann er hluti af. Í öðru sæti er Ceph vegna þess að það er afkastameiri arkitektúr samanborið við Gluster, vegna virkni hans í blokkum, auk sveigjanlegra atburðarása og getu til að vinna í stærri klasa.

Það eru áform um að skrifa samanburð á vSAN, Space Direct Storage, Vstorage og Nutanix Storage, prófa Vstorage á HPE og Huawei búnaði, sem og sviðsmyndir til að samþætta Vstorage við ytri vélbúnaðargeymslukerfi, þannig að ef þér líkar við greinina, þá væri það gaman að fá viðbrögð frá þér, sem gæti aukið hvatningu fyrir nýjar greinar, að teknu tilliti til athugasemda þinna og óska.

Heimild: www.habr.com