Tere, puutusin hiljuti kokku huvitava probleemiga: salvestusruumi seadistamine suure hulga plokkseadmete varundamiseks.
Varundame igal nädalal kõik oma pilves olevad virtuaalsed masinad, seega peame suutma hoida tuhandeid varukoopiaid ning teha seda võimalikult kiiresti ja tõhusalt.
Kahjuks standardkonfiguratsioonid RAID5, RAID6 sel juhul meil seda teha ei lubata, kuna nii suurte ketaste nagu meie oma taasteprotsess on piinavalt pikk ega lõpe suure tõenäosusega kunagi.
Vaatame, millised alternatiivid on olemas:
— Sarnaselt RAID5-le, RAID6-le, kuid konfigureeritava paarsustasemega. Sel juhul ei tehta broneeringut mitte plokkide kaupa, vaid iga objekti kohta eraldi. Lihtsaim viis kustutamiskodeerimise proovimiseks on laiendada .
on praegu avaldamata ZFS-i funktsioon. Erinevalt RAIDZ-ist on DRAIDil hajutatud paarsusplokk ja ta kasutab taastamise ajal kõiki massiivi kettaid korraga, mis võimaldab tal paremini kettatõrkeid üle elada ja pärast riket kiiremini taastuda.
Server saadaval Fujitsu Primergy RX300 S7 protsessoriga Intel Xeon CPU E5-2650L 0 @ 1.80 GHz, üheksa pulka RAM-i Samsung DDR3-1333 8Gb PC3L-10600R ECC registreeritud (M393B1K70DH0-YH9), ketta riiul Supermicro SuperChassis 847E26-RJBOD1, ühendatud kaudu Kahekordne LSI SAS2X36 laiendaja ja 45 plaati Seagage ST6000NM0115-1YZ110 edasi 6TB kõik.
Enne kui midagi otsustame, peame kõigepealt kõike korralikult testima.
Selleks valmistasin ette ja katsetasin erinevaid konfiguratsioone. Selleks kasutasin miniot, mis toimis S3 taustaprogrammina ja käivitas selle erinevates režiimides erineva arvu sihtmärkidega.
Põhimõtteliselt testiti minio korpust kustutamise kodeerimise vs tarkvara raid sama arvu ketaste ja ketaste paarsusega ning need on: RAID6, RAIDZ2 ja DRAID2.
Võrdluseks: kui käivitate minio ainult ühe sihtmärgiga, töötab minio S3 lüüsirežiimis, edastades teie kohaliku failisüsteemi S3 salvestusruumi kujul. Kui käivitate minio, määrates mitu sihtmärki, lülitub kustutamise kodeerimise režiim automaatselt sisse, mis jaotab andmed teie sihtmärkide vahel, tagades tõrketaluvuse.
Vaikimisi jagab minio sihtmärgid 16 ketta rühmadesse, kus iga rühma kohta on 2 pariteeti. Need. Kaks ketast võivad korraga rikki minna ilma andmeid kaotamata.
Jõudluse testimiseks kasutasin 16 6 TB ketast ja kirjutasin neile väikesed 1 MB suurused objektid, see kirjeldas kõige täpsemalt meie tulevast koormust, kuna kõik kaasaegsed varundustööriistad jagavad andmed mitme megabaidisteks plokkideks ja kirjutavad need sel viisil.
Võrdlusuuringu läbiviimiseks kasutasime utiliiti s3bench, mis käivitati kaugserveris ja mis saadab sadade lõimede kaupa miniole kümneid tuhandeid selliseid objekte. Pärast mida proovisin neid samamoodi tagasi nõuda.
Võrdlusuuringu tulemused on näidatud järgmises tabelis:
Nagu näeme, töötab minio oma kustutamiskoodirežiimis kirjutamisel oluliselt halvemini kui minio, mis töötab tarkvara RAID6, RAIDZ2 ja DRAID2 peal samas konfiguratsioonis.
Mina eraldi testi miniot ext4 vs XFS-is. Üllataval kombel osutus XFS minu tüüpi töökoormuse jaoks oluliselt aeglasemaks kui ext4.
Esimeses katsepartiis näitas Mdadm ZFS-i üle paremust, kuid hiljem et saate ZFS-i jõudlust parandada, määrates järgmised suvandid:
xattr=sa atime=off recordsize=1Mja peale seda muutusid ZFS-iga testid palju paremaks.
Samuti võite märkida, et DRAID ei anna RAIDZ-iga võrreldes palju jõudlust, kuid teoreetiliselt peaks see olema palju turvalisem.
Kahes viimases testis proovisin SSD-lt ka metaandmeid (spetsiaalne) ja ZIL-i (logi) peeglisse üle kanda. Kuid metaandmete eemaldamine ei andnud palju salvestuskiirust ja ZIL-i eemaldamisel minu tabas lakke 100% kasutusega, seega pean seda testi ebaõnnestunuks. Ma ei välista, et kui mul oleksid kiiremad SSD-draivid, võib see minu tulemusi oluliselt parandada, kuid kahjuks mul neid polnud.
Lõpuks otsustasin kasutada DRAID-i ja vaatamata oma beeta-olekule on see meie puhul kiireim ja tõhusaim salvestuslahendus.
Lõin lihtsa DRAID2 konfiguratsioonis kolme rühma ja kahe hajutatud varuosaga:
# 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 errorsOlgu, oleme salvestusruumi korrastanud, nüüd räägime sellest, mida varundame. Siinkohal tahaksin kohe rääkida kolmest lahendusest, mida mul õnnestus proovida, ja need on:
- kahvel , spetsialiseeritud lahendus plokkseadmete varundamiseks, on tihedalt integreeritud Cephiga. Saab teha hetktõmmiste vahel erinevusi ja moodustada neist järkjärgulise varukoopia. Toetab suurt hulka salvestuse taustaprogramme, sealhulgas nii kohalikke kui ka S3. Deduplikatsiooni räsitabeli salvestamiseks on vaja eraldi andmebaasi. Puudused: kirjutatud pythonis, on veidi mittereageeriva klikiga.
- kahvel , kaua tuntud ja end tõestanud varundustööriist, suudab andmeid varundada ja neid hästi dubleerida. Võimalus salvestada varukoopiaid nii lokaalselt kui ka kaugserverisse scp kaudu. Saate varundada seadmeid, kui need käivitatakse lipuga --special, üks miinustest: varukoopia tegemisel on hoidla täielikult blokeeritud, seega on soovitatav iga virtuaalmasina jaoks eraldi hoidla luua, põhimõtteliselt pole see probleem, õnneks tekivad need väga lihtsalt.
on aktiivselt arenev projekt, mis on kirjutatud go-s, üsna kiire ja toetab paljusid salvestuse taustaprogramme, sealhulgas kohalikku salvestusruumi, scp-d, S3-d ja palju muud. Eraldi tahaksin märkida, et on olemas spetsiaalselt loodud for restic, mis võimaldab kiiresti eksportida salvestusruumi kaugkasutuseks. Kõigist eelnevatest meeldis see mulle kõige rohkem. Saab varundada stdinist. Sellel pole peaaegu mingeid märgatavaid puudusi, kuid sellel on mitmeid funktsioone:
-
Esiteks proovisin seda kasutada üldhoidla režiimis kõigi virtuaalmasinate jaoks (näiteks Benji) ja see töötas isegi päris hästi, kuid taastamistoimingud võtsid väga kaua aega, sest... Iga kord enne taastamist proovib restic lugeda kõigi varukoopiate metaandmeid. Seda probleemi sai hõlpsasti lahendada, nagu ka borgi puhul, luues iga virtuaalmasina jaoks eraldi hoidla. See lähenemisviis on osutunud väga tõhusaks ka varukoopiate haldamisel. Eraldi hoidlates võib andmetele juurdepääsuks olla eraldi parool, samuti ei pea me kartma, et globaalne repo võib kuidagi katki minna. Saate luua uusi hoidlaid sama lihtsalt kui borgi varukoopias.
Igal juhul tehakse dubleerimine ainult varukoopia eelmise versiooni suhtes; eelmise varukoopia määrab kindlaks määratud varukoopia tee, nii et kui varundate erinevaid objekte stdinist ühisesse hoidlasse, ärge unustage määrata valik
--stdin-filenamevõi määrake valik iga kord selgesõnaliselt--parent.
-
Teiseks võtab stdout-i taastamine selle paralleelse olemuse tõttu palju kauem aega kui failisüsteemi taastamine. Tulevikus plaanime lisada plokkseadmete varukoopiate tihedama toe.
-
Kolmandaks on praegu soovitatav kasutada , sest versioonil 0.9.6 on viga suurte failide pika taastamisega.
Varundamise tõhususe ja varukoopiast kirjutamise/taastamise kiiruse testimiseks lõin eraldi hoidla ja proovisin varundada virtuaalmasina väikest pilti (21 GB). Tehti kaks varukoopiat ilma originaali muutmata, kasutades iga loetletud lahendust, et kontrollida, kui kiiremini/aeglasemalt deduplikeeritud andmed kopeeriti.
Nagu näeme, on Borg Backupil parim algse varundamise efektiivsuse suhe, kuid see on madalam nii kirjutamise kui ka taastamise kiiruse osas.
Restic osutus kiiremaks kui Benji Backup, kuid stdouti taastamine võtab kauem aega ja kahjuks ei tea see veel, kuidas otse plokkseadmesse kirjutada.
Pärast kõigi plusside ja miinuste kaalumist otsustasin leppida rahulik с rest-server kui kõige mugavam ja paljutõotav varulahendus.
Selles ekraanisaates näete, kuidas 10-gigabitine kanal on mitme samaaegselt töötamise ajal täielikult ära kasutatud. Väärib märkimist, et ketaste ringlussevõtt ei tõuse üle 30%.
Jäin saadud lahendusega rohkem kui rahule!
Allikas: www.habr.com