Tere, hiljuti sattusin huvitava ülesande juurde, et seadistada suure hulga plokkseadmete varundamiseks salvestusruum.
Iga nädal teeme varukoopiaid kõigist meie pilves olevatest virtuaalmasinatest, seega tuleb suuta hallata tuhandeid varukoopiaid ja teha seda võimalikult kiiresti ja tõhusalt.
Kahjuks ei sobi standardkonfiguratsioonid RAID5, RAID6 selles olukorras meile, kuna taastamisprotsess nii suurte ketaste, nagu meie omad, puhul on kohutavalt pikk ja tõenäoliselt ei lõppe kunagi.
Vaadakem, millised on alternatiivid:
— RAID5, RAID6 analoog, kuid reguleeritava pariteetasetusega. Samuti tehakse varundamine mitte plokkide kaupa, vaid iga objekti eraldi. Lihtsaim viis erasure codingu proovimiseks on juurutada .
— see on sel hetkel veel väljaandmata ZFS funktsioon. Erinevalt RAIDZ-st on DRAID-il jaotatud pariteediketta süsteem ning taastamisel kasutatakse kohe kõiki rikka kettaid, mis võimaldab tal paremini taluda ketaste tõrkeid ja kiiremini taastuda peale riket.
Käepärast on server Fujitsu Primergy RX300 S7 protsessoriga Intel Xeon CPU E5-2650L 0 @ 1.80GHz, üheksa RAM-moodulit Samsung DDR3-1333 8Gb PC3L-10600R ECC registreeritud (M393B1K70DH0-YH9), ketasalus Supermicro SuperChassis 847E26-RJBOD1, ühendatud läbi Dual LSI SAS2X36 laiendaja ja 45 ketast Seagage ST6000NM0115-1YZ110 kohta 6TB igal.
Enne midagi otsustamist peame kõik korralikult testima.
Selleks valmistusin ja viisin läbi erinevate konfiguratsioonide testimise. Kasutasin minio, mis toimis S3-tagavarana ja jooksin seda erinevates režiimides erineva ehtemärkide arvuga.
Peamiselt testiti minio juhtumit erasure coding vs tarkvararaid sama ketaste ja pariteetketaste arvuga, mis oli: RAID6, RAIDZ2 ja DRAID2.
Teadaanne: kui käitate minio ühe ehtemärgiga, töötab minio S3-tiivina, edastades teie kohalikku failisüsteemi S3-salvestusena. Kui aga käitate minio mitme ehtemärgiga, aktiveeritakse automaatselt Erasure Coding mode, mis jagab andmeid teie tegurite vahel, pakkudes talitlushäired.
Vaikimisi jagab minio sihtmärke 16 plaadi rühmadesse, kus iga rühma jaoks on 2 pariteeti. See tähendab, et korraga võivad väljuda kaks ketast ilma andmete kaotuseta.
Soojade testide käigus kasutasin 16 plaati, igaühe suurus oli 6TB, ja kirjutasin neile väikseid objekte, mille suurus oli 1MB. See kirjeldas maksimaalselt täpselt meie tulevasi koormusi, kuna kõik moodsad varundustööriistad jagavad andmeid mitme megabaidi plokkidesse ja kirjutavad neid sellisel kujul.
Bänkimise läbiviimiseks kasutati s3bench utiliiti, mis käivitati eemalserveris ja saatis miniosse kümneid tuhandeid selliseid objekte sadades voogudes. Pärast seda prooviti neid samamoodi tagasi küsida.
Bänkimise tulemused on esitatud järgmises tabelis:
Nagu näeme, töötab minio oma erasure coding režiimis kirjutamisel oluliselt aeglasemalt kui minio, mis on käivitatud programmse RAID6, RAIDZ2 ja DRAID2 peal samas konfiguratsioonis.
Eraldi paluti mul Esimeses testide osas näitas Mdadm ZFS-i ees üleolekut, kuid hiljem
gmelikov , et ZFS-i jõudlust on võimalik parandada, seadistades järgmised valikud:
xattr=sa atime=off recordsize=1Mja pärast seda olid ZFS-i testid palju paremad.
Samuti võib märgata, et DRAID ei anna RAIDZ-i ees suurt jõudluskasvu, kuid teoreetiliselt peaks see olema palju turvalisem.
Viimastes kahes testis proovisin ka eraldada metaandmed (special) ja ZIL (log) SSD-peegelduse peale. Kuid metaandmete eraldamine ei andnud erilist kirjutaspeedi kasvu, ja ZIL-i eraldades minu sattusid 100% kasutuse piirangusse, seega pean selle testi ebaõnnestunuks. Ma ei välista, et kui mul oleks olnud kiirem SSD, võinuks see minu tulemusi märkimisväärselt parandada, kuid kahjuks polnud mul neid.
Seetõttu otsustasin jääda DRAID-i kasutamise juurde ja vaatamata oma beetastaatuses, on see meie puhul kõige kiirem ja tõhusam lahendus.
Loomisin lihtsa DRAID2, mille konfiguratsioonis on kolm rühma ja kaks jaotatud varu:
# 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 errorsHästi, hoidla on selge, nüüd räägime, millega varundame. Siin tahaksin kohe rääkida kolmest lahendusest, mida sain proovida, nimelt:
— fork , spetsialiseeritud lahendus plokkseadmeste varundamiseks, millel on tihe integreeritus Cephiga. Suudab saada erodeerimisi snapshot'ide vahel ja moodustada neist inkrementaalse varukoopia. Toetab suurt hulka salvestusbackende, sealhulgas nii lokaalset kui ka S3. Vajab dedupeeringu hulkade loendi säilitamiseks eraldi andmebaasi. Miinustest: kirjutatud Pythonis, on veidi mitteaktiivne CLI.
— fork , pikka aega tuntud ja tõestatud varundamisvahend, mis oskab andmeid varundada ja hästi dedupuleerida. Suudab varundada andmeid nii kohapeal kui ka kaugserveris läbi SCP. Suudab varundada plokkseadmeid, kui seda käivitada lipuga --special, miinustest: varukoopia loomisel on kogu repo täielikult lukus, seetõttu soovitatakse iga virtuaalmasina jaoks luua eraldi repo, mis pole sisuliselt probleem, kuna neid on väga lihtne luua.
— kiiresti arenev projekt, kirjutatud go keeles, piisavalt kiire ja toetab paljusid salvestuslahendusi, sealhulgas nii kohalikku salvestust kui ka scp, S3 ja palju muud. Erakordselt tasub märkida, et on olemas spetsiaalselt loodud restic'i jaoks, mis võimaldab kõige kiiremini eksportida salvestust kaugkasutuseks. Kõigist eeltoodud variantidest meeldis see mulle kõige rohkem. Suudab varundada stdin'ist. Märkimisväärseid puudusi on peaaegu puuduvad, kuid mõned eripärad on olemas:
Esiteks proovisin seda kasutada kõigile virtuaalmasinatele ühise repozitooriumi režiimis (nagu Benji) ja see töötas isegi päris hästi, kuid taastamisoperatsioonid kestsid üsna kaua, kuna iga kord enne taastamist üritab restic lugeda kõigi varukoopiate metainformatsiooni. Seda probleem lahendati kergesti, nagu borgiga, luues eraldi repozitooriumi iga virtuaalmasina jaoks. See lähenemine osutus väga tõhusaks ka varukoopiate haldamiseks. Eraldi repozitooriumidel võivad olla eraldi paroolid andmetele juurdepääsuks, samuti ei pea me muretsema, et globaalne repozitoorium võiks mingil moel puruneda. Uute repozitooriumide loomine on samuti sama lihtne nagu borg backup.
Igal juhul toimub deduplikatsioon ainult varasema varukoopia versiooni suhtes, eelmine varukoopia määratletakse antud varukoopia path'i järgi, seega, kui varundate erinevaid objekte stdin'ist ühisesse repozitooriumisse, ärge unustage määrata valikut
--stdin-filename, või öelda iga kord valik selgelt--parent.
Teiseks, taastamine stdout-s võtab oluliselt rohkem aega kui taastamine failisüsteemile, kuna see toimub paralleelselt. Tulevikus plaanitakse lisada tihedamat toetust blokiseadmiste varukoopiatele.
Kolmandaks, praegu soovitatakse kasutada , kuna versioon 0.9.6-l on suurte failide pika taastamise vigadega.
Katasin varukoopia efektiivsuse ja taastamise kiirus, lõin eraldi hoidla ja proovisin varundada väikest virtuaalse masina pilti (21 GB). Tehti kaks varukoopiat ilma originaali muutmata, kasutades iga loetletud lahendust, et kontrollida, kui kiiresti/aeglaselt dedupliceeritud andmed kopeeritakse.
Nagu me märkame, on Borg Backupil parim algse varukoopia efektiivsuse koefitsient, kuid see kaotab nii kirjutamise kui ka taastamise kiiruselt.
Restic osutus Benji Backupist kiiremaks, kuid taastab stdout-s kauem, ja kahjuks ei oska ta kirjutada otse bloki seadmesse.
Kaaludes kõiki plusse ja miinuseid, otsustasin jääda restic koos rest-server kui kõige mugavam ja perspektiivikam lahendus varundamiseks.
Sellest ekraanipildist näete, kuidas 10-gigabitiset kanalit kasutatakse täielikult mitme samaaegselt läbi viidud varundamisoperatsiooni käigus. Tuleb märkida, et ketaste kasutamine ei tõuse sel juhul üle 30%.
Olen saadud lahendusega rohkem kui rahul!
Allikas: habr.com
