Bună ziua, am întâlnit recent o problemă interesantă: configurarea spațiului de stocare pentru a face copii de rezervă pentru un număr mare de dispozitive bloc.
În fiecare săptămână, facem backup pentru toate mașinile virtuale din cloudul nostru, așa că trebuie să fim capabili să menținem mii de backup și să o facem cât mai rapid și eficient posibil.
Din păcate, configurații standard RAID5, RAID6 în acest caz, nu ne va fi permis să facem acest lucru, deoarece procesul de recuperare pe discuri atât de mari ca al nostru va fi dureros de lung și cel mai probabil nu se va termina niciodată.
Să ne uităm la ce alternative există:
— Similar cu RAID5, RAID6, dar cu nivel de paritate configurabil. În acest caz, rezervarea se realizează nu bloc cu bloc, ci pentru fiecare obiect separat. Cel mai simplu mod de a încerca codarea de ștergere este extinderea .
este o caracteristică ZFS nelansată în prezent. Spre deosebire de RAIDZ, DRAID are un bloc de paritate distribuită și, în timpul recuperării, utilizează toate discurile matricei simultan, ceea ce îl face mai capabil să supraviețuiască eșecurilor de disc și să se recupereze mai rapid după o defecțiune.
Server disponibil Fujitsu Primergy RX300 S7 cu procesor CPU Intel Xeon E5-2650L 0 @ 1.80 GHz, nouă stick-uri de memorie RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC înregistrat (M393B1K70DH0-YH9), raft pentru discuri Supermicro SuperChassis 847E26-RJBOD1, conectat prin Expansor dublu LSI SAS2X36 și 45 de discuri Seagage ST6000NM0115-1YZ110 pe 6TB fiecare.
Înainte de a decide ceva, trebuie mai întâi să testăm totul în mod corespunzător.
Pentru a face acest lucru, am pregătit și testat diverse configurații. Pentru a face acest lucru, am folosit minio, care a acționat ca un backend S3 și l-a lansat în diferite moduri cu un număr diferit de ținte.
Practic, carcasa minio a fost testată în codare de ștergere vs raid software cu același număr de discuri și paritate de discuri, iar acestea sunt: RAID6, RAIDZ2 și DRAID2.
Pentru referință: când lansați minio cu o singură țintă, minio funcționează în modul gateway S3, oferind sistemul dvs. de fișiere local sub formă de stocare S3. Dacă lansați minio specificând mai multe ținte, modul Erasure Coding se va activa automat, ceea ce va răspândi datele între ținte, oferind în același timp toleranță la erori.
În mod implicit, minio împarte ținte în grupuri de 16 discuri, cu 2 parități per grup. Acestea. Două discuri pot eșua în același timp fără a pierde date.
Pentru a testa performanța, am folosit 16 discuri de 6TB fiecare și am scris obiecte mici de 1MB în dimensiune, acest lucru a descris cel mai precis încărcarea noastră viitoare, deoarece toate instrumentele moderne de backup împart datele în blocuri de câțiva megaocteți și le scriu în acest fel.
Pentru a efectua benchmark-ul, am folosit utilitarul s3bench, lansat pe un server la distanță și care trimite zeci de mii de astfel de obiecte către minio în sute de fire. După care am încercat să le solicit înapoi în același mod.
Rezultatele benchmark-ului sunt prezentate în următorul tabel:
După cum putem vedea, minio în propriul mod de codare de ștergere are rezultate semnificativ mai slabe la scriere decât minio care rulează pe software-ul RAID6, RAIDZ2 și DRAID2 în aceeași configurație.
Separat eu testați minio pe ext4 vs XFS. În mod surprinzător, pentru tipul meu de sarcină de lucru, XFS s-a dovedit a fi semnificativ mai lent decât ext4.
În primul lot de teste, Mdadm a arătat superioritate față de ZFS, dar mai târziu că puteți îmbunătăți performanța ZFS setând următoarele opțiuni:
xattr=sa atime=off recordsize=1Miar după aceea testele cu ZFS au devenit mult mai bune.
De asemenea, puteți observa că DRAID nu oferă un câștig de performanță prea mare față de RAIDZ, dar, teoretic, ar trebui să fie mult mai sigur.
În ultimele două teste, am încercat și să transfer metadate (speciale) și ZIL (log) în oglindă de pe SSD. Dar eliminarea metadatelor nu a oferit un câștig prea mare în viteza de înregistrare, iar la eliminarea ZIL, a mea a lovit plafonul cu o utilizare de 100%, așa că consider acest test un eșec. Nu exclud că dacă aș avea unități SSD mai rapide, atunci poate că acest lucru ar putea îmbunătăți foarte mult rezultatele, dar, din păcate, nu le-am avut.
Până la urmă, am decis să folosesc DRAID și, în ciuda statutului său beta, este cea mai rapidă și eficientă soluție de stocare în cazul nostru.
Am creat un DRAID2 simplu într-o configurație cu trei grupuri și două piese de schimb distribuite:
# 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 errorsBine, am rezolvat spațiul de stocare, acum să vorbim despre ce vom face backup. Aici aș vrea să vorbesc imediat despre trei soluții pe care am reușit să le încerc și acestea sunt:
- furculiță , o soluție specializată pentru blocarea backup-ului dispozitivului, are o integrare strânsă cu Ceph. Poate face diferențe între instantanee și poate forma o copie de rezervă incrementală din acestea. Acceptă un număr mare de backend-uri de stocare, inclusiv atât locale, cât și S3. Necesită o bază de date separată pentru a stoca tabelul hash de deduplicare. Dintre minusuri: scris în python, are un cli ușor neresponsibil.
- furculiță , un instrument de backup de mult cunoscut și dovedit, poate face backup pentru date și le poate deduplica bine. Capabil să salveze copii de siguranță atât local, cât și pe un server la distanță prin scp. Poate bloca dispozitivele de rezervă dacă sunt lansate cu steag --special, unul dintre minusuri: la crearea unei copii de rezervă, depozitul este complet blocat, așa că este recomandat să creați un depozit separat pentru fiecare mașină virtuală, în principiu nu este o problemă, din fericire acestea se creează foarte ușor.
este un proiect în curs de dezvoltare, scris în go, destul de rapid și suportă un număr mare de backend-uri de stocare, inclusiv stocare locală, scp, S3 și multe altele. Separat, aș dori să remarc că există un special creat pentru restic, care vă permite să exportați rapid spațiul de stocare pentru utilizare de la distanță. Dintre toate cele de mai sus, mi-a plăcut cel mai mult. Se poate face backup de la stdin. Nu are aproape deloc dezavantaje vizibile, dar există mai multe caracteristici:
-
În primul rând, am încercat să-l folosesc în modul de depozit general pentru toate mașinile virtuale (cum ar fi Benji) și chiar a funcționat destul de bine, dar operațiunile de restaurare au durat foarte mult, pentru că... De fiecare dată înainte de restaurare, restic încearcă să citească metadatele tuturor copiilor de rezervă. Această problemă a fost rezolvată cu ușurință, ca și în cazul borg, prin crearea unui depozit separat pentru fiecare mașină virtuală. Această abordare s-a dovedit a fi foarte eficientă și pentru gestionarea backup-urilor. Arhivele separate pot avea o parolă separată pentru accesarea datelor și, de asemenea, nu trebuie să ne temem că depozitul global s-ar putea rupe cumva. Puteți genera depozite noi la fel de ușor ca în backup-ul borg.
În orice caz, deduplicarea se efectuează numai în raport cu versiunea anterioară a copiei de rezervă. opțiune
--stdin-filename, sau specificați în mod explicit opțiunea de fiecare dată--parent.
-
În al doilea rând, recuperarea către stdout durează mult mai mult decât recuperarea către sistemul de fișiere, datorită naturii sale paralele. În viitor, intenționăm să adăugăm un suport mai strâns pentru backup-urile pentru dispozitivele blocate.
-
În al treilea rând, în prezent se recomandă utilizarea , deoarece versiunea 0.9.6 are o eroare cu recuperare îndelungată a fișierelor mari.
Pentru a testa eficacitatea copiei de rezervă și viteza de scriere/restaurare dintr-o copie de rezervă, am creat un depozit separat și am încercat să fac o copie de rezervă a unei imagini mici a unei mașini virtuale (21 GB). Au fost efectuate două copii de siguranță fără modificarea originalului, folosind fiecare dintre soluțiile enumerate pentru a verifica cât de rapid/mai lent au fost copiate datele deduplicate.
După cum putem vedea, Borg Backup are cel mai bun raport de eficiență inițială a backup-ului, dar este inferior atât în ceea ce privește viteza de scriere, cât și cea de restaurare.
Restic s-a dovedit a fi mai rapid decât Benji Backup, dar restabilirea în stdout durează mai mult și, din păcate, încă nu știe să scrie direct pe un dispozitiv bloc.
După ce am cântărit toate argumentele pro și contra, am decis să mă mulțumesc liniștit с rest-server ca cea mai convenabilă și promițătoare soluție de rezervă.
În acest screencast puteți vedea cum un canal de 10 gigabit este complet utilizat în timpul mai multor operațiuni de backup care rulează simultan. Este de remarcat faptul că utilizarea discului nu crește peste 30%.
Am fost mai mult decât mulțumit de soluția primită!
Sursa: www.habr.com