Ezt a cikket azért írtuk, hogy segítsen kiválasztani a megfelelő megoldást, és megértse az olyan SDS-ek közötti különbségeket, mint a Gluster, Ceph és Vstorage (Virtuozzo).
A szöveg cikkekre mutató hivatkozásokat használ bizonyos problémák részletesebb feltárásával, így a leírások a lehető legrövidebbek lesznek, a kulcsfontosságú pontokat használva felesleges szöszmötölés nélkül, és bevezető információkat, amelyeket ha kíván, önállóan is megszerezhet az interneten.
Valójában persze a felvetett témák megkívánják a szöveg hangvételét, de a modern világban egyre többen nem szeretnek sokat olvasni))), így gyorsan tudsz olvasni és válogatni, és ha valami nem egyértelmű, kövesse a linkeket vagy a google-ban a nem egyértelmű szavakat))), és ez a cikk olyan, mint egy átlátszó borító ezekhez a mély témákhoz, megmutatja a kitöltést - az egyes döntések fő kulcspontjait.
Csillogás
Kezdjük a Glusterrel, amit a hiperkonvergens platformok gyártói aktívan használnak nyílt forráskódú SDS-sel virtuális környezetekhez, és megtalálható a RedHat honlapján a tárolási szekcióban, ahol két SDS lehetőség közül választhatunk: Gluster vagy Ceph.
A Gluster egy köteg fordítóból áll - olyan szolgáltatásokból, amelyek elvégzik a fájlok terjesztésének összes munkáját stb. A Brick egy olyan szolgáltatás, amely egy lemezt szolgál ki, a Volume pedig egy kötet (pool), amely egyesíti ezeket a téglákat. Ezután következik a fájlok csoportokba osztása a DHT (distributed hash table) funkció segítségével. A Sharding szolgáltatást nem fogjuk belefoglalni a leírásba, mivel az alábbi linkek leírják a vele kapcsolatos problémákat.
Íráskor a teljes fájl téglában tárolódik, és a másolata egyidejűleg téglába íródik a második szerveren. Ezután a második fájl a két (vagy több) téglából álló második csoportba lesz írva különböző szervereken.
Ha a fájlok megközelítőleg azonos méretűek, és a kötet csak egy csoportból áll, akkor minden rendben van, de más feltételek mellett a következő problémák merülnek fel a leírásokból:
- A csoportok helye egyenlőtlenül kihasználható, ez a fájlok méretétől függ, és ha nincs elég hely a csoportban egy fájl írásához, akkor hibaüzenetet kap, a fájl nem kerül kiírásra és nem kerül újraosztásra másik csoportba ;
- egy fájl írásakor az IO csak egy csoportba megy, a többi tétlen;
- nem kaphatja meg a teljes kötet IO-ját egy fájl írásakor;
- és az általános koncepció kevésbé tűnik produktívnak az adatok blokkokba való szétosztásának hiánya miatt, ahol könnyebb az egyensúlyozás és az egyenletes elosztás problémája, és nem úgy, ahogy most a teljes fájl blokkba kerül.
A hivatalos leírásból önkéntelenül is arra a felismerésre jutunk, hogy a gluster fájltárolóként működik a klasszikus hardveres RAID mellett. Voltak fejlesztési kísérletek a (Sharding) fájlok blokkokra vágására, de mindez egy olyan kiegészítés, amely teljesítményveszteséget ró a már meglévő architekturális megközelítésre, valamint olyan szabadon terjesztett, teljesítménykorlátozásokkal rendelkező komponensek használatára, mint a Fuse. Nincsenek metaadat-szolgáltatások, amelyek korlátozzák a tároló teljesítményét és hibatűrési képességeit a fájlok blokkokba való felosztása során. Jobb teljesítménymutatók figyelhetők meg az „Elosztott replikált” konfigurációval, és a csomópontok számának legalább 6-nak kell lennie, hogy megbízható replika 3 legyen optimális terheléselosztással.
Ezek a megállapítások a felhasználói élmény leírásához is kapcsolódnak és ha összehasonlítjuk , és van egy leírás a tapasztalatokról is, amelyek ennek a termelékenyebb és megbízhatóbb konfigurációnak a megértéséhez vezetnek
A képen a terhelés eloszlása látható két fájl írásakor, ahol az első fájl másolatai az első három szerver között vannak elosztva, amelyek a 0 kötet csoportba vannak egyesítve, és a második fájl három példánya a második csoportban, a volume1 háromból kerül. szerverek. Minden szervernek egy lemeze van.
Az általános következtetés az, hogy használhatja a Glustert, de azzal a tudattal, hogy a teljesítmény és a hibatűrés korlátai lesznek, amelyek nehézségeket okoznak a hiperkonvergens megoldás bizonyos feltételei között, ahol erőforrásokra van szükség a virtuális környezetek számítási terheléséhez is.
Vannak olyan Gluster-teljesítménymutatók is, amelyek bizonyos feltételek mellett elérhetők, de ezekre korlátozva
ceph
Most nézzük meg Ceph-et az építészeti leírások alapján, amelyekre sikerült Összehasonlítás is van között , ahol azonnal érthető, hogy a Ceph-t célszerű külön szervereken telepíteni, mivel szolgáltatásai terhelés alatt minden hardver erőforrást igényelnek.
építészet bonyolultabb, mint a Gluster, és vannak olyan szolgáltatások, mint például a metaadatszolgáltatások, de az összetevők teljes kötege meglehetősen összetett, és nem túl rugalmas ahhoz, hogy virtualizációs megoldásban használják. Az adatok blokkokban vannak tárolva, ami produktívabbnak tűnik, de az összes szolgáltatás (komponens) hierarchiájában bizonyos terhelések és vészhelyzetek esetén veszteségek és késleltetések vannak, például az alábbiak
Az architektúra leírásából a szív a CRUSH, ennek köszönhetően kerül kiválasztásra az adatok tárolásának helye. Ezután következik a PG – ez a legnehezebben érthető absztrakció (logikai csoport). PG-kre van szükség a CRUSH hatékonyabbá tételéhez. A PG fő célja az objektumok csoportosítása az erőforrás-felhasználás csökkentése, a teljesítmény és a méretezhetőség növelése érdekében. Az objektumok közvetlen, egyenkénti megszólítása anélkül, hogy PG-vé egyesítené őket, nagyon költséges lenne. Az OSD egy szolgáltatás minden egyes lemezhez.
Egy fürtnek egy vagy több adatkészlete lehet különböző célokra és különböző beállításokkal. A medencék elhelyezési csoportokra vannak osztva. Az elhelyezési csoportok olyan objektumokat tárolnak, amelyekhez az ügyfelek hozzáférnek. Itt ér véget a logikai szint, és kezdődik a fizikai szint, mivel minden elhelyezési csoporthoz egy főlemez és több replikalemez van hozzárendelve (a készletreplikációs tényezőtől függ, hogy pontosan hány darab). Más szóval, logikai szinten az objektumot egy adott elhelyezési csoportban tárolják, fizikai szinten pedig a hozzárendelt lemezeken. Ebben az esetben a lemezek fizikailag különböző csomópontokon vagy akár különböző adatközpontokban is elhelyezkedhetnek.
Ebben a sémában az elhelyezési csoportok a teljes megoldás rugalmasságához szükséges szintnek tűnnek, ugyanakkor a lánc plusz láncszemének, ami önkéntelenül is a termelékenység csökkenését sugallja. Például az adatok írásakor a rendszernek fel kell osztania azokat ezekre a csoportokra, majd fizikai szinten a főlemezre és a replikák lemezeire. Vagyis a Hash funkció működik egy objektum keresése és beillesztése során, de van egy mellékhatása - nagyon magas költségek és korlátozások a hash újraépítésére (lemez hozzáadásakor vagy eltávolításakor). Egy másik hash probléma az adatok egyértelműen körülhatárolt helye, amely nem változtatható meg. Vagyis ha valahogy a lemez megnövelt terhelés alatt van, akkor a rendszernek nincs lehetősége arra, hogy ne írjon rá (másik lemez kiválasztásával), a hash funkció kötelezi az adatok szabály szerinti elhelyezkedését, bármilyen rossz is legyen. a lemez az, így a Ceph rengeteg memóriát eszik a PG újraépítésekor öngyógyítás vagy tárhely növelés esetén. A következtetés az, hogy a Ceph jól működik (ha lassan is), de csak akkor, ha nincs méretezés, vészhelyzetek vagy frissítések.
Természetesen vannak lehetőségek a teljesítmény növelésére gyorsítótárral és gyorsítótár-megosztással, de ehhez jó hardverre van szükség, és továbbra is lesznek veszteségek. De összességében a Ceph a termelékenység szempontjából csábítóbbnak tűnik, mint a Gluster. Ezen termékek használatakor egy fontos tényezőt is figyelembe kell venni - ez a magas szintű kompetencia, tapasztalat és professzionalizmus, nagy hangsúlyt fektetve a Linuxra, mivel nagyon fontos mindent helyesen telepíteni, konfigurálni és karbantartani, ami még nagyobb felelősséget és terhet ró az ügyintézőre.
Vtárhely
Az építészet még érdekesebbnek tűnik , amely egy hipervizorral együtt használható ugyanazokon a csomópontokon, ugyanazon , de nagyon fontos mindent helyesen beállítani a jó teljesítmény elérése érdekében. Vagyis egy ilyen termék telepítése a dobozból bármilyen konfigurációban az architektúrának megfelelő ajánlások figyelembevétele nélkül nagyon egyszerű, de nem produktív.
Mi létezhet a tárolásra a kvm-qemu hypervisor szolgáltatásai mellett, és ez csak néhány szolgáltatás, ahol a komponensek kompakt, optimális hierarchiáját sikerült megtalálni: FUSE-n keresztül csatlakoztatott ügyfélszolgálat (módosított, nem nyílt forráskódú), MDS metaadat szolgáltatás (Metaadat szolgáltatás), szolgáltatás Chunk szolgáltatás adatblokkok, ami fizikai szinten egyenlő egy lemezzel, és ennyi. Sebesség szempontjából természetesen optimális a hibatűrő séma használata két replikával, de ha gyorsítótárazást és naplózást használunk SSD-meghajtókon, akkor a hibatűrő kódolás (kódtörlés vagy raid6) tisztességesen túlhajtható. hibrid séma vagy még jobb minden vakunál. Van némi hátránya az EC-nek (törlés kódolás): egy adatblokk megváltoztatásakor újra kell számolni a paritásösszegeket. Az ezzel a művelettel járó veszteségek megkerülésére a Ceph késleltetetten ír az EC-nek, és teljesítményproblémák léphetnek fel egy adott kérés során, amikor például az összes blokkot be kell olvasni, és a Virtuozzo Storage esetében a megváltozott blokkok írása történik. a „log-strukturált fájlrendszer” megközelítést használja, amely minimalizálja a paritásszámítási költségeket. Az EC-vel és anélküli munkagyorsítási lehetőségek hozzávetőleges becsléséhez rendelkezésre állnak – a számok hozzávetőlegesek lehetnek a berendezés gyártójának pontossági együtthatójától függően, de a számítások eredménye jó segítség a konfiguráció tervezésében.
A tárolóelemek egyszerű diagramja nem jelenti azt, hogy ezek az alkatrészek nem szívódnak fel de ha minden költséget előre kiszámol, akkor a hypervisor mellett számíthat az együttműködésre.
Létezik egy séma a Ceph és a Virtuozzo tárolási szolgáltatások hardver erőforrás-fogyasztásának összehasonlítására.
Ha korábban a Glustert és a Ceph-t lehetett összehasonlítani a régi cikkek segítségével, ezekből a legfontosabb sorokat felhasználva, akkor a Virtuozzóval ez nehezebb. Nem sok cikk található erről a termékről, és az információk csak a dokumentációból nyerhetők vagy oroszul, ha a Vstorage-ot tárolónak tekintjük, amelyet egyes hiperkonvergens megoldásokban használnak olyan cégeknél, mint pl és Acronis.
Megpróbálok segíteni ennek az architektúrának a leírásában, így lesz egy kicsit több szöveg, de sok időbe telik a dokumentáció megértése, és a meglévő dokumentáció csak referenciaként használható a táblázat átdolgozásával tartalom vagy kulcsszó szerinti keresés.
Tekintsük a rögzítési folyamatot hibrid hardverkonfigurációban a fent leírt komponensekkel: a rögzítés abba a csomópontba indul, ahonnan a kliens kezdeményezte (a FUSE csatolási pont szolgáltatás), de természetesen a Metadata Service (MDS) főkomponense a klienst közvetlenül a kívánt csonk szolgáltatáshoz irányítja (tárolási szolgáltatás CS blokkok), vagyis az MDS nem vesz részt a rögzítési folyamatban, hanem egyszerűen a kívánt csonkhoz irányítja a szolgáltatást. Általában analógiát adhatunk a hordókba víz öntésével történő felvételhez. Minden hordó egy 256 MB-os adatblokk.
Ez azt jelenti, hogy egy lemez bizonyos számú ilyen hordó, azaz a lemez térfogata osztva 256 MB-tal. Minden másolat egy csomóponthoz kerül kiosztásra, a második szinte párhuzamosan egy másik csomóponthoz stb... Ha három replikánk van, és vannak SSD lemezek a gyorsítótárhoz (naplók olvasásához és írásához), akkor az írás megerősítése az írás után történik a naplózás az SSD-re, és a párhuzamos visszaállítás az SSD-ről folytatódik a HDD-n, mintha a háttérben lenne. Három replika esetén a rekord a harmadik csomópont SSD-jétől kapott megerősítést követően kerül véglegesítésre. Úgy tűnhet, hogy három SSD írási sebességének összege osztható hárommal, és egy replika írási sebességét kapjuk, de a másolatok párhuzamosan íródnak, és a hálózati késleltetési sebesség általában nagyobb, mint az SSD-é, és valójában az írási teljesítmény a hálózattól függ. Ebben a tekintetben a valódi IOPS megtekintéséhez helyesen kell betöltenie a teljes Vstorage-ot , vagyis a valós terhelés tesztelése, és nem a memória és a gyorsítótár, ahol figyelembe kell venni a helyes adatblokk méretét, szálak számát stb.
A fent említett rögzítési napló az SSD-n úgy működik, hogy amint adat kerül bele, azonnal beolvassa a szolgáltatás, és kiírja a HDD-re. Klaszterenként több metaadatszolgáltatás (MDS) létezik, és ezek számát a Paxos algoritmus szerint működő határozatképesség határozza meg. A kliens szemszögéből a FUSE beillesztési pont egy fürttároló mappa, amely egyidejűleg látható a fürt összes csomópontja számára, minden csomóponthoz ezen elv szerint van csatlakoztatott kliens, így ez a tárhely minden csomópont számára elérhető.
A fent leírt megközelítések bármelyikének teljesítéséhez nagyon fontos a tervezési és telepítési szakaszban a hálózat helyes konfigurálása, ahol az aggregáció és a helyesen kiválasztott hálózati csatorna sávszélessége miatt egyensúly lesz. Az összesítés során fontos a megfelelő kivonatolási mód és keretméretek kiválasztása. A fent leírt SDS-hez képest is nagyon erős különbség van, ez a Virtuozzo Storage gyorsút technológiájával való biztosíték. Amely a modernizált biztosítékon kívül más nyílt forráskódú megoldásokkal ellentétben jelentősen megnöveli az IOPS-t, és lehetővé teszi, hogy ne korlátozza a vízszintes vagy függőleges skálázás. Általánosságban elmondható, hogy a fent leírt architektúrákhoz képest ez erősebbnek tűnik, de ehhez az örömhöz természetesen licenceket kell vásárolnia, ellentétben a Ceph-sel és a Glusterrel.
Összefoglalva, a három közül kiemelhetjük a legjobbat: a Virtuozzo Storage az architektúra teljesítménye és megbízhatósága tekintetében az első, a Ceph a második, a Gluster pedig a harmadik helyen.
A Virtuozzo Storage kiválasztásának kritériumai: ez az architekturális összetevők optimális készlete, modernizálva a Fuse megközelítéshez gyors útvonallal, rugalmas hardverkonfigurációkkal, kevesebb erőforrás-felhasználással és a számítástechnikával való megosztás lehetőségével (számítás/virtualizáció), vagyis teljesen alkalmas hiperkonvergens megoldásra , aminek ő is része. A második helyen a Ceph található, mivel a blokkokban való működésének, valamint a rugalmasabb forgatókönyveknek és a nagyobb klaszterekben való munkavégzésnek köszönhetően termelékenyebb architektúra a Glusterhez képest.
A tervek között szerepel a vSAN, a Space Direct Storage, a Vstorage és a Nutanix Storage összehasonlítása, a Vstorage tesztelése HPE és Huawei berendezéseken, valamint a Vstorage külső hardveres tárolórendszerekkel való integrálásának forgatókönyvei, tehát ha tetszett a cikk, akkor Örülök, hogy visszajelzést kapok Öntől , ami növelheti az új cikkek iránti motivációt, figyelembe véve megjegyzéseit és kívánságait.
Forrás: will.com