Tämä artikkeli on kirjoitettu auttamaan sinua valitsemaan oikean ratkaisun itsellesi ja ymmärtämään eroja SDS:n, kuten Gluster, Ceph ja Vstorage (Virtuozzo), välillä.
Tekstissä käytetään linkkejä artikkeleihin, joissa on yksityiskohtaisempi selvitys tietyistä ongelmista, joten kuvaukset ovat mahdollisimman lyhyitä, käyttäen avainkohtia ilman turhaa pörröilyä ja johdantotietoja, jotka voit halutessasi hankkia itsenäisesti Internetistä.
Itse asiassa nostetut aiheet tietysti vaativat tekstin sävyjä, mutta nykymaailmassa yhä useammat ihmiset eivät halua lukea paljon))), joten voit nopeasti lukea ja tehdä valinnan, ja jos jotain on epäselvä, seuraa linkkejä tai google epäselviä sanoja))), ja tämä artikkeli on kuin läpinäkyvä kääre näille syville aiheille, joka näyttää täytteen - jokaisen päätöksen tärkeimmät avainkohdat.
Kiilto
Aloitetaan Glusterista, jota aktiivisesti käyttävät hyperkonvergoitujen alustojen valmistajat avoimeen lähdekoodiin perustuvalla virtuaaliympäristöjen SDS:llä ja joka löytyy RedHat-verkkosivuston tallennusosiosta, jossa voit valita kahdesta SDS-vaihtoehdosta: Gluster tai Ceph.
Gluster koostuu joukosta kääntäjiä - palveluita, jotka suorittavat kaiken tiedostojen jakelutyön jne. Brick on palvelu, joka palvelee yhtä levyä, Volume on taltio (pooli), joka yhdistää nämä palikat. Seuraavaksi tulee palvelu tiedostojen jakamiseksi ryhmiin DHT (distributed hash table) -toiminnolla. Emme sisällytä Sharding-palvelua kuvaukseen, koska alla olevat linkit kuvaavat siihen liittyviä ongelmia.
Kirjoitettaessa koko tiedosto tallennetaan brickiin ja sen kopio kirjoitetaan samanaikaisesti tiileksi toiselle palvelimelle. Seuraavaksi toinen tiedosto kirjoitetaan kahden (tai useamman) lohkon toiseen ryhmään eri palvelimilla.
Jos tiedostot ovat suunnilleen samankokoisia ja taltio koostuu vain yhdestä ryhmästä, niin kaikki on kunnossa, mutta muissa olosuhteissa kuvauksista tulee seuraavat ongelmat:
- ryhmissä tilaa käytetään epätasaisesti, se riippuu tiedostojen koosta ja jos ryhmässä ei ole tarpeeksi tilaa tiedoston kirjoittamiseen, saat virheilmoituksen, tiedostoa ei kirjoiteta eikä sitä jaeta toiseen ryhmään ;
- kun kirjoitetaan yhtä tiedostoa, IO menee vain yhteen ryhmään, loput ovat valmiita;
- et voi saada koko aseman IO:ta, kun kirjoitat yhtä tiedostoa;
- ja yleinen konsepti näyttää vähemmän tuottavalta, koska dataa ei ole jaettu lohkoihin, joissa on helpompi tasapainottaa ja ratkaista yhtenäisen jakelun ongelma, eikä niin kuin nyt koko tiedosto menee lohkoon.
Virallisesta kuvauksesta tulemme myös tahattomasti ymmärtämään, että gluster toimii tiedostovarastona klassisen laitteisto-RAIDin päällä. Kehitysyrityksiä on yritetty leikata (Sharing) tiedostoja lohkoiksi, mutta kaikki tämä on lisäys, joka aiheuttaa suorituskyvyn heikkenemistä jo olemassa olevalle arkkitehtoniselle lähestymistavalle sekä sellaisten vapaasti jaettujen komponenttien käyttöön, joilla on suorituskykyrajoituksia, kuten Fuse. Metatietopalveluita ei ole, mikä rajoittaa tallennustilan suorituskykyä ja vikasietokykyä jaettaessa tiedostoja lohkoihin. Parempia suorituskykyindikaattoreita voidaan havaita "Distributed Replicated" -kokoonpanolla, ja solmujen lukumäärän tulee olla vähintään 6 luotettavan replikan 3 järjestämiseksi optimaalisella kuormituksen jakautumisella.
Nämä havainnot liittyvät myös käyttökokemuksen kuvaukseen ja verrattuna , ja siellä on myös kuvaus kokemuksesta, joka johtaa tämän tuottavamman ja luotettavamman kokoonpanon ymmärtämiseen
Kuvassa näkyy kuormituksen jakautuminen kahta tiedostoa kirjoitettaessa, jolloin ensimmäisen tiedoston kopiot on jaettu kolmelle ensimmäiselle palvelimelle, jotka yhdistetään volyymiryhmään 0 ja toisesta tiedostosta kolme kopiota sijoitetaan toiseen ryhmään volyymi1 kolmesta. palvelimia. Jokaisella palvelimella on yksi levy.
Yleinen johtopäätös on, että voit käyttää Glusteria, mutta ymmärtäen, että suorituskyvyssä ja vikasietoisuudessa on rajoituksia, jotka aiheuttavat vaikeuksia tietyissä hyperkonvergoidun ratkaisun olosuhteissa, joissa resursseja tarvitaan myös virtuaaliympäristöjen laskentakuormitukseen.
On myös joitain Glusterin suorituskykyindikaattoreita, jotka voidaan saavuttaa tietyissä olosuhteissa
kef
Katsotaanpa nyt Cephiä arkkitehtuurikuvauksista, joihin pystyin On myös vertailua , jossa voit heti ymmärtää, että Ceph on suositeltavaa ottaa käyttöön erillisillä palvelimilla, koska sen palvelut vaativat kaikki kuormitetut laitteistoresurssit.
Arkkitehtuuri monimutkaisempi kuin Gluster ja on palveluita, kuten metatietopalvelut, mutta koko komponenttipino on melko monimutkainen eikä kovin joustava käytettäväksi virtualisointiratkaisussa. Tiedot tallennetaan lohkoihin, mikä näyttää tuottavammalta, mutta kaikkien palveluiden (komponenttien) hierarkiassa esiintyy häviöitä ja latenssia tietyissä kuormituksissa ja hätätilanteissa, esim.
Arkkitehtuurin kuvauksesta sydän on CRUSH, jonka ansiosta datan tallennuspaikka valitaan. Seuraavaksi tulee PG - tämä on vaikein abstraktio (looginen ryhmä) ymmärtää. PG:itä tarvitaan CRUSHin tehostamiseksi. PG:n päätarkoitus on ryhmitellä objekteja resurssien kulutuksen vähentämiseksi, suorituskyvyn ja skaalautuvuuden lisäämiseksi. Kohteiden osoittaminen suoraan, yksittäin yhdistämättä niitä PG:ksi olisi erittäin kallista. OSD on palvelu jokaiselle yksittäiselle levylle.
Klusterilla voi olla yksi tai useampi tietovarasto eri tarkoituksiin ja eri asetuksilla. Altaat on jaettu sijoitusryhmiin. Sijoitteluryhmät tallentavat objektit, joita asiakkaat voivat käyttää. Tässä looginen taso päättyy ja fyysinen taso alkaa, koska jokaiselle sijoitusryhmälle on määritetty yksi päälevy ja useita replikalevyjä (kuinka monta tarkkaan ottaen riippuu poolin replikointitekijästä). Toisin sanoen loogisella tasolla objekti on tallennettu tiettyyn sijoitusryhmään ja fyysisellä tasolla - sille osoitetuille levyille. Tässä tapauksessa levyt voivat sijaita fyysisesti eri solmuissa tai jopa eri tietokeskuksissa.
Tässä kaaviossa sijoitusryhmät näyttävät välttämättömältä tasolta koko ratkaisun joustavuuden kannalta, mutta samalla ylimääräiseltä lenkkiltä tässä ketjussa, mikä tahattomasti viittaa tuottavuuden menetykseen. Esimerkiksi kirjoitettaessa tietoja järjestelmän on jaettava se näihin ryhmiin ja sitten fyysisellä tasolla päälevyyn ja levykkeisiin replikoita varten. Toisin sanoen Hash-toiminto toimii haettaessa ja lisättäessä objektia, mutta sillä on sivuvaikutus - se on erittäin korkeat kustannukset ja rajoitukset hashin uudelleenrakentamiselle (kun lisäät tai poistat levyä). Toinen hash-ongelma on tietojen selkeästi naulattu sijainti, jota ei voi muuttaa. Eli jos levy on jotenkin lisääntyneen kuormituksen alaisena, niin järjestelmällä ei ole mahdollisuutta olla kirjoittamatta sille (valitsemalla toinen levy), hash-toiminto velvoittaa tiedot paikantamaan säännön mukaan riippumatta siitä, kuinka huonosti levy on, joten Ceph syö paljon muistia rakentaessaan uudelleen PG:tä, jos se korjaa itseään tai lisää tallennustilaa. Johtopäätös on, että Ceph toimii hyvin (tosin hitaasti), mutta vain silloin, kun ei ole skaalausta, hätätilanteita tai päivityksiä.
Tietysti on vaihtoehtoja parantaa suorituskykyä välimuistin ja välimuistin jakamisen avulla, mutta tämä vaatii hyvää laitteistoa ja häviöitä tulee silti. Mutta kaiken kaikkiaan Ceph näyttää houkuttelevammalta kuin Gluster tuottavuuden kannalta. Lisäksi näitä tuotteita käytettäessä on otettava huomioon tärkeä tekijä - tämä on korkea pätevyys, kokemus ja ammattitaito, jossa painotetaan paljon Linuxia, koska on erittäin tärkeää ottaa käyttöön, konfiguroida ja ylläpitää kaikkea oikein, mikä asettaa järjestelmänvalvojalle entistä enemmän vastuuta ja taakkaa.
Vstorage
Arkkitehtuuri näyttää vielä mielenkiintoisemmalta , jota voidaan käyttää yhdessä hypervisorin kanssa samoissa solmuissa, samassa , mutta on erittäin tärkeää määrittää kaikki oikein hyvän suorituskyvyn saavuttamiseksi. Eli tällaisen tuotteen käyttöönotto laatikosta missä tahansa kokoonpanossa ottamatta huomioon arkkitehtuurin mukaisia suosituksia on erittäin helppoa, mutta ei tuottavaa.
Mitä voi esiintyä tallennuksen rinnalla kvm-qemu hypervisorin palveluiden rinnalla, ja nämä ovat vain muutamia palveluita, joissa on löydetty kompakti optimaalinen komponenttihierarkia: FUSE:n kautta asennettu asiakaspalvelu (muokattu, ei avoimen lähdekoodin), MDS-metadatapalvelu (Metadata-palvelu), palvelu Chunk-palvelutietolohkot, joka fyysisellä tasolla vastaa yhtä levyä ja siinä kaikki. Nopeuden kannalta on tietysti optimaalista käyttää vikasietojärjestelmää kahdella kopiolla, mutta jos käytät välimuistia ja lokeja SSD-asemilla, niin virheensietoinen koodaus (erase coding tai raid6) voidaan ylikellottaa kohtuullisesti hybridimalli tai jopa parempi kaikissa salamissa. EC:ssä (erase coding) on haittana: yhtä datalohkoa vaihdettaessa on tarpeen laskea pariteettimäärät uudelleen. Ohitakseen tähän toimintoon liittyvät häviöt Ceph kirjoittaa viivästyneesti EC:hen ja suoritusongelmia voi ilmetä tietyn pyynnön aikana, kun esimerkiksi kaikki lohkot on luettava, ja Virtuozzo Storagen tapauksessa muutettuja lohkoja kirjoitetaan. käyttämällä "lokirakenteista tiedostojärjestelmää" -lähestymistapaa, joka minimoi pariteetin laskentakustannukset. On olemassa vaihtoehtoja arvioida suunnilleen työn kiihtyvyys EC:n kanssa ja ilman – luvut voivat olla likimääräisiä laitevalmistajan tarkkuuskertoimen mukaan, mutta laskelmien tulos on hyvä apu konfiguraation suunnittelussa.
Yksinkertainen kaavio säilytyskomponenteista ei tarkoita, että nämä komponentit eivät imeydy mutta jos lasket kaikki kustannukset etukäteen, voit luottaa yhteistyöhön hypervisorin rinnalla.
Ceph- ja Virtuozzo-tallennuspalveluiden laitteistoresurssien kulutuksen vertailuun on olemassa järjestelmä.
Jos aiemmin Glusteria ja Cephiä oli mahdollista verrata vanhojen artikkeleiden avulla käyttämällä niiden tärkeimpiä rivejä, niin Virtuozzon kanssa se on vaikeampaa. Tästä tuotteesta ei ole paljon artikkeleita, ja tiedot voidaan poimia vain asiakirjoista tai venäjäksi, jos pidämme Vstoragea tallennustilana, jota käytetään joissakin hyperkonvergoiduissa ratkaisuissa yrityksissä, kuten ja Acronis.
Yritän auttaa tämän arkkitehtuurin kuvauksessa, joten tekstiä tulee hieman enemmän, mutta dokumentaation ymmärtäminen itse vie paljon aikaa ja olemassa olevaa dokumentaatiota voi käyttää vain viitteenä taulukkoa tarkistamalla sisällöstä tai hakusanalla.
Tarkastellaan tallennusprosessia hybridilaitteistokokoonpanossa yllä kuvatuilla komponenteilla: tallennus alkaa mennä solmuun, josta asiakas aloitti sen (FUSE-liitospistepalvelu), mutta Metadata Service (MDS) -pääkomponentti ohjata asiakas suoraan haluttuun osapalveluun (tallennuspalvelun CS-lohkot), eli MDS ei osallistu tallennusprosessiin, vaan yksinkertaisesti ohjaa palvelun haluttuun osaan. Yleisesti ottaen voimme antaa analogian tallentamiseen veden kaatamisesta tynnyreihin. Jokainen piippu on 256 Mt:n tietolohko.
Eli yksi levy on tietty määrä tällaisia tynnyreitä, eli levytilavuus jaettuna 256 megatavulla. Jokainen kopio jaetaan yhdelle solmulle, toinen lähes rinnakkain toiseen solmuun jne... Jos meillä on kolme kopiota ja SSD-levyt välimuistia varten (lokien lukemista ja kirjoittamista varten), vahvistus kirjoituksesta tapahtuu kirjoittamisen jälkeen loki SSD:lle ja rinnakkaispalautus SSD:ltä jatkuu kiintolevyllä ikään kuin taustalla. Kolmen replikan tapauksessa tietue sitoutuu kolmannen solmun SSD:n vahvistuksen jälkeen. Vaikuttaa siltä, että kolmen SSD-levyn kirjoitusnopeuden summa voidaan jakaa kolmella ja saamme yhden replikan kirjoitusnopeuden, mutta kopiot kirjoitetaan rinnakkain ja verkon latenssinopeus on yleensä suurempi kuin SSD:n, ja itse asiassa kirjoitussuorituskyky riippuu verkosta. Tässä suhteessa, jotta voit nähdä todellisen IOPS:n, sinun on ladattava koko Vstorage oikein , eli testataan todellista kuormitusta, ei muistia ja välimuistia, jossa on tarpeen ottaa huomioon oikea tietolohkon koko, säikeiden lukumäärä jne.
Yllä mainittu tallennusloki SSD:llä toimii siten, että heti kun siihen pääsee dataa, palvelu lukee sen välittömästi ja kirjoitetaan kiintolevylle. Yhtä klusteria kohden on useita metadatapalveluita (MDS) ja niiden lukumäärän määrää Paxos-algoritmin mukaan toimiva päätösvaltaisuus. Asiakkaan näkökulmasta FUSE-liitospiste on klusterin tallennuskansio, joka on samanaikaisesti kaikkien klusterin solmujen näkyvissä, jokaisessa solmussa on tämän periaatteen mukaisesti asennettu asiakas, joten tämä tallennustila on jokaisen solmun käytettävissä.
Minkä tahansa edellä kuvatun lähestymistavan suorituskyvyn kannalta on erittäin tärkeää suunnittelu- ja käyttöönottovaiheessa konfiguroida oikein verkko, jossa tapahtuu tasapainotusta yhdistämisen ja oikein valitun verkkokanavan kaistanleveyden vuoksi. Aggregoinnissa on tärkeää valita oikea hajautustila ja kehyskoot. Siinä on myös erittäin vahva ero yllä kuvattuun SDS:ään, tämä on sulake Virtuozzo Storagen nopean polun teknologiaan. Joka modernisoidun sulakkeen lisäksi, toisin kuin muut avoimen lähdekoodin ratkaisut, lisää merkittävästi IOPS:ää ja sallii, ettei vaaka- tai pystyskaalaus rajoita sinua. Yleensä verrattuna yllä kuvattuihin arkkitehtuureihin tämä näyttää tehokkaammalta, mutta tällaista nautintoa varten sinun on tietysti ostettava lisenssit, toisin kuin Ceph ja Gluster.
Yhteenvetona voimme korostaa kolmesta huippua: Virtuozzo Storage on ensimmäisellä sijalla suorituskyvyn ja arkkitehtuurin luotettavuuden suhteen, Ceph on toinen ja Gluster kolmas.
Kriteerit, joilla Virtuozzo Storage valittiin: se on optimaalinen joukko arkkitehtonisia komponentteja, jotka on modernisoitu tätä Fuse-lähestymistapaa varten nopealla polulla, joustavalla laitteistokokoonpanolla, pienemmällä resurssien kulutuksella ja kyvyllä jakaa laskennan kanssa (laskenta/virtualisointi), eli se sopii täysin hyperkonvergoituun ratkaisuun, johon hän on osa. Toinen sija on Ceph, koska se on Glusteriin verrattuna tuottavampi arkkitehtuuri, koska se toimii lohkoissa, sekä joustavammat skenaariot ja kyky työskennellä suuremmissa klustereissa.
Suunnitelmissa on kirjoittaa vertailu vSAN:n, Space Direct Storagen, Vstoragen ja Nutanix Storagen välillä, testata Vstoragea HPE- ja Huawei-laitteilla sekä skenaariot Vstoragen integroimiseksi ulkoisiin laitteistotallennusjärjestelmiin, joten jos pidit artikkelista, se olisi Mukava saada sinulta palautetta, joka voi lisätä motivaatiota uusiin artikkeleihin, kun huomioidaan kommentit ja toiveesi.
Lähde: will.com