Hei, törmäsin äskettäin mielenkiintoiseen ongelmaan: tallennustilan määrittäminen useiden lohkolaitteiden varmuuskopiointiin.
Varmuuskopioimme joka viikko kaikki pilvessämme olevat virtuaalikoneet, joten meidän on kyettävä palvelemaan tuhansia varmuuskopioita ja tehdä se mahdollisimman nopeasti ja tehokkaasti.
Valitettavasti vakiokokoonpanot RAID5, RAID6 tässä tapauksessa emme saa tehdä niin, koska palautusprosessi niin suurilla levyillä kuin meillä on tuskallisen pitkä eikä todennäköisesti lopu koskaan.
Katsotaanpa, mitä vaihtoehtoja on:
— Samanlainen kuin RAID5, RAID6, mutta konfiguroitavalla pariteettitasolla. Tässä tapauksessa varausta ei tehdä lohko kerrallaan, vaan jokaiselle kohteelle erikseen. Helpoin tapa kokeilla poistokoodausta on laajentaa .
on tällä hetkellä julkaisematon ZFS-ominaisuus. Toisin kuin RAIDZ:ssä, DRAIDissa on hajautettu pariteettilohko ja se käyttää palautuksen aikana kaikkia taulukon levyjä kerralla, mikä tekee siitä selviävän paremmin levyvioista ja toipumaan nopeammin vian jälkeen.
Tarjolla on palvelin Fujitsu Primegy RX300 S7 prosessorin kanssa Intel Xeon CPU E5-2650L 0 @ 1.80 GHz, yhdeksän tikkua RAM-muistia Samsung DDR3-1333 8Gb PC3L-10600R ECC rekisteröity (M393B1K70DH0-YH9), levyhylly Supermicro SuperChassis 847E26-RJBOD1, yhdistetty kautta Dual LSI SAS2X36 Expander ja 45 levyä Seagage ST6000NM0115-1YZ110 päälle 6TB kukin.
Ennen kuin päätämme mitään, meidän on ensin testattava kaikki kunnolla.
Tätä varten valmistelin ja testasin erilaisia kokoonpanoja. Tätä varten käytin minioa, joka toimi S3-taustajärjestelmänä ja käynnisti sen eri tiloissa eri määrällä kohteita.
Periaatteessa minio-koteloa testattiin erokoodauksessa vs. ohjelmistoraidissa samalla levymäärällä ja levypariteetilla, ja nämä ovat: RAID6, RAIDZ2 ja DRAID2.
Viitteeksi: kun käynnistät minion vain yhdellä kohteella, minio toimii S3-yhdyskäytävätilassa ja toimittaa paikallisen tiedostojärjestelmän S3-tallennustilan muodossa. Jos käynnistät minion määrittämällä useita kohteita, Erasure Coding -tila käynnistyy automaattisesti, mikä jakaa tiedot kohteidesi välillä ja tarjoaa vikasietoisuuden.
Oletuksena minio jakaa kohteet 16 levyn ryhmiin, joissa on 2 pariteettia ryhmää kohden. Nuo. Kaksi levyä voi epäonnistua samanaikaisesti menettämättä tietoja.
Suorituskyvyn testaamiseksi käytin 16:ta 6 Tt:n levyä ja kirjoitin niihin pieniä, 1 Mt:n kokoisia objekteja, mikä kuvasi tarkimmin tulevaa kuormitustamme, koska kaikki nykyaikaiset varmuuskopiointityökalut jakavat tiedot useiden megatavujen lohkoihin ja kirjoittavat ne tällä tavalla.
Testin suorittamiseen käytimme s3bench-apuohjelmaa, joka käynnistettiin etäpalvelimella ja joka lähettää kymmeniä tuhansia tällaisia objekteja miniolle sadoissa säikeissä. Sen jälkeen yritin pyytää niitä takaisin samalla tavalla.
Vertailuarvojen tulokset näkyvät seuraavassa taulukossa:
Kuten näemme, minio omassa poistokoodaustilassaan toimii huomattavasti huonommin kirjoittamisessa kuin minio, joka toimii ohjelmistojen RAID6, RAIDZ2 ja DRAID2 päällä samassa kokoonpanossa.
Minä erikseen testaa minio ext4 vs XFS. Yllättäen XFS osoittautui työtaakkaani huomattavasti hitaammaksi kuin ext4.
Ensimmäisessä testierässä Mdadm osoitti paremman ZFS:n, mutta myöhemmin että voit parantaa ZFS:n suorituskykyä asettamalla seuraavat asetukset:
xattr=sa atime=off recordsize=1Mja sen jälkeen ZFS:n testit paranivat huomattavasti.
Voit myös huomata, että DRAID ei tarjoa paljon suorituskykyä RAIDZ:iin verrattuna, mutta teoriassa sen pitäisi olla paljon turvallisempi.
Kahdessa viimeisessä testissä yritin myös siirtää metatiedot (erikois) ja ZIL (loki) peiliin SSD:ltä. Mutta metatietojen poistaminen ei tuonut paljon lisäystä tallennusnopeuteen, ja kun poistin ZIL, my osui kattoon 100 %:n käyttöasteella, joten pidän tätä testiä epäonnistuneena. En sulje pois sitä, että jos minulla olisi nopeammat SSD-asemat, ehkä tämä voisi parantaa tuloksiani huomattavasti, mutta valitettavasti minulla ei ollut niitä.
Lopulta päätin käyttää DRAIDia ja beeta-tilastaan huolimatta se on meidän tapauksessamme nopein ja tehokkain tallennusratkaisu.
Loin yksinkertaisen DRAID2:n kokoonpanossa, jossa on kolme ryhmää ja kaksi hajautettua varaosaa:
# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
draid2:3g:2s-0 ONLINE 0 0 0
sdy ONLINE 0 0 0
sdam ONLINE 0 0 0
sdf ONLINE 0 0 0
sdau ONLINE 0 0 0
sdab ONLINE 0 0 0
sdo ONLINE 0 0 0
sdw ONLINE 0 0 0
sdak ONLINE 0 0 0
sdd ONLINE 0 0 0
sdas ONLINE 0 0 0
sdm ONLINE 0 0 0
sdu ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdk ONLINE 0 0 0
sds ONLINE 0 0 0
sdag ONLINE 0 0 0
sdi ONLINE 0 0 0
sdq ONLINE 0 0 0
sdae ONLINE 0 0 0
sdz ONLINE 0 0 0
sdan ONLINE 0 0 0
sdg ONLINE 0 0 0
sdac ONLINE 0 0 0
sdx ONLINE 0 0 0
sdal ONLINE 0 0 0
sde ONLINE 0 0 0
sdat ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdn ONLINE 0 0 0
sdv ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdc ONLINE 0 0 0
sdar ONLINE 0 0 0
sdl ONLINE 0 0 0
sdt ONLINE 0 0 0
sdah ONLINE 0 0 0
sdap ONLINE 0 0 0
sdj ONLINE 0 0 0
sdr ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdao ONLINE 0 0 0
sdh ONLINE 0 0 0
sdp ONLINE 0 0 0
sdad ONLINE 0 0 0
spares
s0-draid2:3g:2s-0 AVAIL
s1-draid2:3g:2s-0 AVAIL
errors: No known data errorsSelvä, olemme selvittäneet tallennustilan. Puhutaan nyt siitä, mitä varmuuskopioimme. Tässä haluaisin heti puhua kolmesta ratkaisusta, joita onnistuin kokeilemaan, ja nämä ovat:
- haarukka , erikoistunut ratkaisu lohkolaitteiden varmuuskopiointiin, on tiiviisti integroitu Cephin kanssa. Voi ottaa eroja tilannekuvien välillä ja muodostaa niistä varmuuskopion. Tukee suurta määrää tallennustaustaohjelmia, mukaan lukien sekä paikalliset että S3. Vaatii erillisen tietokannan duplikoinnin hajautustaulukon tallentamiseksi. Miinuksista: kirjoitettu pythonilla, siinä on hieman reagoimaton kli.
- haarukka , pitkään tunnettu ja hyväksi havaittu varmuuskopiointityökalu, joka voi varmuuskopioida tiedot ja poistaa niiden kopiot hyvin. Pystyy tallentamaan varmuuskopiot sekä paikallisesti että etäpalvelimelle scp:n kautta. Voi varmuuskopioida laitteet, jos ne käynnistetään lipulla --special, yksi miinuksista: varmuuskopiota luotaessa arkisto on kokonaan estetty, joten on suositeltavaa luoda erillinen arkisto jokaiselle virtuaalikoneelle, periaatteessa tämä ei ole ongelma, onneksi ne luodaan erittäin helposti.
on aktiivisesti kehittyvä projekti, joka on kirjoitettu gossa, melko nopea ja tukee useita tallennustaustaohjelmia, mukaan lukien paikallista tallennustilaa, scp:tä, S3:a ja paljon muuta. Erikseen haluaisin huomauttaa, että on olemassa erityisesti luotu for restic, jonka avulla voit nopeasti viedä tallennustilaa etäkäyttöä varten. Kaikista edellä mainituista pidin siitä eniten. Voi varmuuskopioida stdinistä. Siinä ei juuri ole havaittavia haittoja, mutta siinä on useita ominaisuuksia:
Ensinnäkin yritin käyttää sitä yleisessä arkistotilassa kaikille virtuaalikoneen (kuten Benji) ja se jopa toimi melko hyvin, mutta palautusoperaatiot kestivät hyvin kauan, koska... Joka kerta ennen palautusta, restic yrittää lukea kaikkien varmuuskopioiden metatiedot. Tämä ongelma ratkesi helposti, kuten borgin kanssa, luomalla erillinen arkisto jokaiselle virtuaalikoneelle. Tämä lähestymistapa on osoittautunut erittäin tehokkaaksi myös varmuuskopioiden hallinnassa. Erillisillä arkistoilla voi olla erillinen salasana tietojen käyttöä varten, eikä meidän myöskään tarvitse pelätä, että globaali repo voisi jotenkin rikkoutua. Voit luoda uusia tietovarastoja yhtä helposti kuin borg-varmuuskopiossa.
Joka tapauksessa duplikointi suoritetaan vain suhteessa varmuuskopion edelliseen versioon. Edellinen varmuuskopio määräytyy määritetyn varmuuskopion polun mukaan, joten jos varmuuskopioit eri objekteja stdinistä yhteiseen arkistoon, älä unohda määrittää vaihtoehto
--stdin-filename, tai määritä vaihtoehto erikseen joka kerta--parent.
Toiseksi palautus stdoutiin kestää paljon kauemmin kuin palautus tiedostojärjestelmään sen rinnakkaisluonteen vuoksi. Tulevaisuudessa aiomme lisätä tiiviimmän tuen varmuuskopioille lohkolaitteille.
Kolmanneksi sen käyttöä suositellaan tällä hetkellä , koska versiossa 0.9.6 on bugi, joka sisältää pitkiä palautumisaikoja suurille tiedostoille.
Testatakseni varmuuskopion tehokkuutta ja varmuuskopiosta kirjoittamisen/palautuksen nopeutta loin erillisen arkiston ja yritin varmuuskopioida pienen kuvan virtuaalikoneesta (21 Gt). Kaksi varmuuskopiota tehtiin muuttamatta alkuperäistä, käyttäen kutakin lueteltua ratkaisua sen tarkistamiseksi, kuinka nopeammin/hitaammin kopioitu tieto kopioitiin.
Kuten näemme, Borg Backupilla on paras alkuperäisen varmuuskopioinnin tehokkuussuhde, mutta se on huonompi sekä kirjoitus- että palautusnopeuden suhteen.
Restic osoittautui nopeammaksi kuin Benji Backup, mutta sen palauttaminen stdoutiin kestää kauemmin, eikä se valitettavasti vielä osaa kirjoittaa suoraan lohkolaitteeseen.
Punnitsin kaikki edut ja haitat, päätin tyytyä tasainen с lepo-palvelin kätevimpänä ja lupaavimpana varmuuskopiointiratkaisuna.
Tässä kuvalähetyksessä näet kuinka 10 gigabitin kanava on täysin hyödynnetty useiden varmuuskopiointitoimintojen aikana samanaikaisesti. On syytä huomata, että levyn kierrätys ei nouse yli 30%.
Olin enemmän kuin tyytyväinen saamaani ratkaisuun!
Lähde: will.com
