Pozdrav, nedavno sam naišao na zanimljiv problem: postavljanje pohrane za sigurnosno kopiranje velikog broja blok uređaja.
Svaki tjedan stvaramo sigurnosnu kopiju svih virtualnih strojeva u našem oblaku, tako da moramo biti u mogućnosti održavati tisuće sigurnosnih kopija i to što je moguće brže i učinkovitije.
Nažalost, standardne konfiguracije RAID5, RAID6 u ovom slučaju to nam neće biti dopušteno jer će proces oporavka na tako velikim diskovima kao što je naš biti bolno dug i najvjerojatnije nikada neće završiti.
Pogledajmo koje alternative postoje:
— Slično RAID5, RAID6, ali s podesivom razinom pariteta. U ovom slučaju, rezervacija se ne provodi blok po blok, već za svaki objekt zasebno. Najlakši način da isprobate kodiranje za brisanje je proširivanje .
je trenutno neobjavljena značajka ZFS-a. Za razliku od RAIDZ-a, DRAID ima distribuirani paritetni blok i tijekom oporavka koristi sve diskove niza odjednom, što ga čini sposobnijim za preživljavanje kvarova diskova i brži oporavak nakon kvara.
Server dostupan Fujitsu Primergy RX300 S7 s procesorom Intel Xeon CPU E5-2650L 0 @ 1.80 GHz, devet komada RAM-a Samsung DDR3-1333 8Gb PC3L-10600R ECC registriran (M393B1K70DH0-YH9), polica za disk Supermicro SuperChassis 847E26-RJBOD1, povezan putem Dual LSI SAS2X36 Expander i 45 diskova Seagage ST6000NM0115-1YZ110 na 6TB svaki.
Prije nego bilo što odlučimo, prvo moramo sve pravilno testirati.
Da bih to učinio, pripremio sam i testirao različite konfiguracije. Da bih to učinio, koristio sam minio, koji je djelovao kao S3 backend i pokretao ga u različitim načinima rada s različitim brojem ciljeva.
Uglavnom, minio kućište je testirano u kodiranju za brisanje naspram softverskog raida s istim brojem diskova i paritetom diskova, a to su: RAID6, RAIDZ2 i DRAID2.
Za referencu: kada pokrenete minio sa samo jednim ciljem, minio radi u S3 gateway modu, isporučujući vaš lokalni datotečni sustav u obliku S3 pohrane. Ako pokrenete minio navodeći nekoliko ciljeva, automatski će se uključiti način rada Erasure Coding, koji će rasporediti podatke između vaših ciljeva, istovremeno pružajući toleranciju na pogreške.
Prema zadanim postavkama, minio dijeli ciljeve u grupe od 16 diskova, s 2 pariteta po grupi. Oni. Dva diska mogu otkazati u isto vrijeme bez gubitka podataka.
Za testiranje performansi koristio sam 16 diskova od po 6TB i na njih zapisivao male objekte veličine 1MB, što je najtočnije opisalo naše buduće opterećenje, budući da svi moderni backup alati dijele podatke u blokove od nekoliko megabajta i tako ih zapisuju.
Za provedbu benchmarka koristili smo uslužni program s3bench, pokrenut na udaljenom poslužitelju i slao desetke tisuća takvih objekata u minio u stotinama niti. Nakon čega sam ih pokušao zatražiti natrag na isti način.
Rezultati usporedne analize prikazani su u sljedećoj tablici:
Kao što možemo vidjeti, minio u svom vlastitom načinu kodiranja za brisanje radi znatno lošije pri pisanju nego minio koji radi povrh softverskih RAID6, RAIDZ2 i DRAID2 u istoj konfiguraciji.
Odvojeno ja testiraj minio na ext4 protiv XFS. Iznenađujuće, za moju vrstu posla, XFS se pokazao znatno sporijim od ext4.
U prvoj seriji testova, Mdadm je pokazao superiornost nad ZFS-om, ali kasnije da možete poboljšati performanse ZFS-a postavljanjem sljedećih opcija:
xattr=sa atime=off recordsize=1Ma nakon toga su testovi sa ZFS-om postali puno bolji.
Također možete primijetiti da DRAID ne daje puno povećanje performansi u odnosu na RAIDZ, ali u teoriji bi trebao biti mnogo sigurniji.
U posljednja dva testa također sam pokušao prenijeti metapodatke (specijalne) i ZIL (log) na mirror sa SSD-a. Ali uklanjanje metapodataka nije dalo veliku dobit u brzini snimanja, a prilikom uklanjanja ZIL-a, moj pogodio plafon sa 100% iskoristivosti, tako da ovaj test smatram neuspješnim. Ne isključujem da kad bih imao brže SSD diskove, onda bi to možda moglo uvelike poboljšati moje rezultate, ali, nažalost, nisam ih imao.
Na kraju sam odlučio koristiti DRAID i unatoč beta statusu, to je najbrže i najučinkovitije rješenje za pohranu u našem slučaju.
Napravio sam jednostavan DRAID2 u konfiguraciji s tri grupe i dvije raspodijeljene rezerve:
# 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 errorsU redu, riješili smo pohranu, sada razgovarajmo o tome što ćemo sigurnosno kopirati. Ovdje bih odmah želio govoriti o tri rješenja koja sam uspio isprobati, a to su:
- vilica , specijalizirano rješenje za backup blok uređaja, ima usku integraciju s Cephom. Može uzeti razlike između snimki i formirati inkrementalnu sigurnosnu kopiju iz njih. Podržava velik broj pozadina za pohranu, uključujući lokalne i S3. Za pohranu hash tablice deduplikacije potrebna je zasebna baza podataka. Nedostaci: napisano u pythonu, ima cli koji malo ne reagira.
- vilica , odavno poznat i provjeren alat za sigurnosno kopiranje, može sigurnosno kopirati podatke i dobro ih ukloniti duplikate. Mogućnost spremanja sigurnosnih kopija i lokalno i na udaljeni poslužitelj putem scp-a. Može sigurnosno kopirati blokirane uređaje ako se pokrene s oznakom --special, jedan od minusa: prilikom izrade sigurnosne kopije, repozitorij je potpuno blokiran, pa je preporučljivo izraditi zasebno repozitorij za svaki virtualni stroj, u principu to nije problem, srećom stvaraju se vrlo lako.
je projekt koji se aktivno razvija, napisan je u go, prilično je brz i podržava velik broj pozadinskih sustava za pohranu, uključujući lokalnu pohranu, scp, S3 i još mnogo toga. Zasebno bih želio napomenuti da postoji posebno stvoren za restic, koji vam omogućuje brzi izvoz pohrane za korištenje na daljinu. Od svega navedenog najviše mi se svidjela. Može backup iz stdin. Gotovo da nema primjetnih nedostataka, ali ima nekoliko značajki:
-
Prvo, pokušao sam ga koristiti u općem načinu repozitorija za sve virtualne strojeve (kao što je Benji) i čak je radio prilično dobro, ali operacije vraćanja trajale su jako dugo, jer... Svaki put prije vraćanja, restic pokušava pročitati metapodatke svih sigurnosnih kopija. Ovaj problem je lako riješen, kao i kod borga, stvaranjem zasebnog repozitorija za svaki virtualni stroj. Ovaj se pristup pokazao vrlo učinkovitim i za upravljanje sigurnosnim kopijama. Zasebna spremišta mogu imati zasebnu lozinku za pristup podacima, a također se ne moramo bojati da bi se globalni repo mogao nekako pokvariti. Nova spremišta možete pokrenuti jednako lako kao u borg sigurnosnoj kopiji.
U svakom slučaju, deduplikacija se izvodi samo u odnosu na prethodnu verziju sigurnosne kopije; prethodna sigurnosna kopija određena je stazom za navedenu sigurnosnu kopiju, pa ako sigurnosno kopirate različite objekte iz stdin-a u zajedničko spremište, ne zaboravite navesti opcija
--stdin-filenameili svaki put izričito navedite opciju--parent.
-
Drugo, oporavak na stdout traje mnogo dulje od oporavka na datotečni sustav zbog njegove paralelne prirode. U budućnosti planiramo dodati bližu podršku za sigurnosne kopije za blok uređaje.
-
Treće, trenutno se preporučuje korištenje , jer verzija 0.9.6 ima grešku s dugim oporavkom velikih datoteka.
Kako bih testirao učinkovitost sigurnosne kopije i brzinu pisanja/vraćanja iz sigurnosne kopije, napravio sam zasebno spremište i pokušao sigurnosno kopirati malu sliku virtualnog stroja (21 GB). Izvedene su dvije sigurnosne kopije bez mijenjanja originala, korištenjem svakog od navedenih rješenja kako bi se provjerilo koliko su brže/sporije kopirani deduplicirani podaci.
Kao što vidimo, Borg Backup ima najbolji početni omjer učinkovitosti sigurnosnog kopiranja, ali je inferioran u pogledu brzine pisanja i vraćanja.
Ispostavilo se da je Restic brži od Benji Backupa, ali potrebno je više vremena za vraćanje na stdout i, nažalost, još ne zna pisati izravno na blok uređaj.
Nakon što sam odvagao sve prednosti i nedostatke, odlučio sam ostati restičan с rest-server kao najpovoljnije i najperspektivnije rezervno rješenje.
U ovom screencastu možete vidjeti kako je 10-gigabitni kanal u potpunosti iskorišten tijekom nekoliko operacija sigurnosnog kopiranja koje se izvode istovremeno. Vrijedno je napomenuti da se recikliranje diska ne penje iznad 30%.
Bio sam više nego zadovoljan dobivenim rješenjem!
Izvor: www.habr.com