Përshëndetje, kohët e fundit më ra në dorë një detyrë interesante për të konfiguruar një ruajtje për backup-in e një sërë të madhe të pajisjeve blok.
Çdo javë ne bëjmë kopje rezervë të të gjitha makinave virtuale në cloud-in tonë, kështu që duhet të jemi në gjendje të menaxhojmë mijëra kopje rezervë dhe ta bëjmë këtë sa më shpejt dhe efikasht.
Fatkeqësisht, konfigurimet standarde RAID5, RAID6 në këtë rast nuk na përshtaten për shkak se procesi i rikuperimit në disqe të tillë të mëdhenj si tonat do të ishte shumë i gjatë dhe me siguri nuk do të përfundojë kurrë.
Le të shqyrtojmë cilat janë alternativat:
— Analogu i RAID5, RAID6, por me një nivel të konfigurueshëm pariteti. Në këtë rast, rezervimi nuk bëhet për çdo blok, por për secilin objekt veçmas. Mënyra më e thjeshtë për të provuar erasure coding është të vendosni .
— kjo është një mundësi që nuk është lëshuar ende për ZFS. Ndryshe nga RAIDZ, DRAID ka një paritet të shpërndarë dhe gjatë rikuperimit angazhon menjëherë të gjitha disqet e grumbullit, duke e bërë atë më të qëndrueshëm ndaj dështimeve të disqeve dhe më të shpejtë në rikuperim pas një defekti.
Në dispozicion kemi një server Fujitsu Primergy RX300 S7 me procesor Intel Xeon CPU E5-2650L 0 @ 1.80GHz, me nëntë modulet e memories Samsung DDR3-1333 8Gb PC3L-10600R ECC Registered (M393B1K70DH0-YH9), raft diskesh Supermicro SuperChassis 847E26-RJBOD1, i lidhur përmes Dual LSI SAS2X36 Expander dhe 45 disqe Seagage ST6000NM0115-1YZ110 për 6TB çdo.
Para se të marrim vendime, na nevojitet të testojmë gjithçka siç duhet.
Për këtë, u përgatita dhe kreva teste të konfiguracioneve të ndryshme. Përdora minio, i cili shërbeu si një backend S3 dhe e drejtoja në mënyra të ndryshme me numra të ndryshëm targetesh.
Këtu kryesisht u testua rasti i minio në kodimin e shkatërrimit në krahasim me RAID-në softuerike me të njëjtin numër disqesh dhe disqe pariteti, të cilat janë: RAID6, RAIDZ2 dhe DRAID2.
Për referencë: kur e drejtoni minion me një vetëm target, atëherë minio funksionon në modalitetin S3-gateway duke ju dhënë sistemin tuaj lokal të skedarëve si një ruajtje S3. Nëse e drejtoni minion me shumë targete, modaliteti i Kodimit të Shkatërrimit aktivizohet automatikisht, i cili do të shpërndajë të dhënat midis targeteve tuaja duke ofruar qëndrushmëri ndaj dështimeve.
Në mënyrë standarde, minio ndan qëllimet në grupe prej 16 disqesh, ku çdo grup ka 2 paritet. Kjo do të thotë që dy disqe mund të dështojnë në të njëjtën kohë pa humbje të të dhënave.
Për testimin e performancës, përdora 16 disqe me nga 6TB secili dhe shkruaja objekte të vogla me madhësi 1MB, kjo përshkruante me saktësi ngarkesën tonë të ardhshme, pasi të gjithë mjetet moderne për backup ndaj të dhënave i ndajnë ato në blloqe disa megabajtesh dhe i shkruajnë në këtë mënyrë.
Për kryerjen e bënchmarkut u përdor utilitari s3bench, i cili u ekzekutua në një server të largët dhe dërgonte në minio dhjetëra mijëra objekte të tilla në një qind rrjedha. Pasi që u përpoq të kërkonte ato përsëri në të njëjtën mënyrë.
Rezultatet e bënchmarkut janë në tabelën e mëposhtme:
Siç e shohim, minio në modin e vet erasure coding punon ndjeshëm më keq në shkrim, se sa minio i lançuar mbi RAID6 softueror, RAIDZ2 dhe DRAID2 në të njëjtën konfigurim.
Veçmas, unë të testoja minio mbi ext4 vs XFS. Çuditërisht, për llojin tim të ngarkesës, XFS rezultoi të ishte ndjeshëm më e ngadaltë se ext4.
Në grupin e parë të testeve, Mdadm tregoi përparësi mbi ZFS, por më vonë , se mund të përmirësoj performancën e ZFS duke vendosur opsionet e mëposhtme:
xattr=sa atime=off recordsize=1Mdhe pas kësaj testet me ZFS u përmirësuan nd significantlyeshëm.
Gjithashtu, mund të vërehet se DRAID nuk ofron ndonjë përfitim të veçantë në performancë krahasuar me RAIDZ, por në teori duhet të jetë shumë më i sigurt.
Në dy testet e fundit, përpiqesha gjithashtu të shpërngulja metadatat (special) dhe ZIL (log) në një pasqyrë nga SSD. Por shpërngulja e metadatat nuk dha ndonjë përfitim të dukshëm në shpejtësinë e shkruajtur, dhe kur shpërngulja e ZIL, unë u ndesha me një kufi me 100% të përdorimit, kështu që unë e konsideroj këtë test si të dështuar. Nuk përjashtoj që po të kisha SSD më të shpejtë, ndoshta kjo do të përmirësonte ndjeshëm rezultatet e mia, por fatkeqësisht nuk i kisha.
Në fund, vendosa të ndalem në përdorimin e DRAID dhe pavarësisht statusit të tij beta, ai është zgjidhja më e shpejtë dhe efikase për ruajtje në rastin tonë.
Krijova një DRAID2 të thjeshtë në konfigurimin me tre grupe dhe dy rezervat e shpërndara:
# 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 errorsMirë, me ruajtjen u merret, tani për atë se çfarë do të bënë backup. Këtu menjëherë do të doja të flisja për tri zgjidhje që arrin të provoj, dhe ato janë:
— fork , një zgjidhje e specializuar për backup-in e pajisjeve bllokuese, ka një integrim të ngushtë me Ceph. Mund të marrë diferencat midis snapshot-eve dhe të formojë një backup inkremental prej tyre. Mbështet një numër të madh backend-esh për ruajtjen, mes të cilave ka si lokale ashtu edhe S3. Kërkon një bazë të veçantë të dhash, për të ruajtur tabelën e heshave për deduplication. Nga disavantazhet: është shkruar në python, ka një interface CLI disi jo të përgjegjshëm.
— fork , një mjet i njohur dhe i provuar për backup, mund të bëjë backup të të dhënave dhe i deduplication ato mirë. Mund të ruajë backup-et si lokalisht ashtu edhe në një server të largët përmes scp. Mund të bëjë backup të pajisjeve bllokuese nëse ekzekutohet me flagun --special, nga disavantazhet: kur krijohet një backup, repository plotësisht bllokohet, prandaj për çdo makinë virtuale rekomandohet të krijohet një repository i veçantë, në parim kjo nuk është një problem, pasi ato krijohen shumë lehtë.
— një projekt në rritje aktiv, i shkruar në go, mjaft i shpejtë dhe mbështet një numër të madh backend-esh për ruajtje, përfshirë si ruajtjen lokale ashtu edhe scp, S3 dhe shumë të tjera. Vlen të theksohet se ka një e krijuar posaçërisht për restic, e cila lejon eksportimin më të shpejtë të ruajtjes për përdorim të largët. Nga të gjitha të mësipërmet, më pëlqeu më shumë. Mund të bëjë backup nga stdin. Nuk ka disavantazhe të dukshme, por ka disa veçori:
Së pari, kam provuar ta përdor këtë në mënyrë të përgjithshme për të gjitha virtualet (si Benji) dhe kjo përveç se punoi mirë, operacionet e rikuperimit zgjatën mjaft gjatë, pasi çdo herë para rikuperimit, restic përpiqet të lexojë metadata-t e të gjitha backup-eve. Ky problem u zgjidh lehtësisht, si me borg, duke krijuar një depo të veçantë për secilën virtuale. Ky qasje doli të ishte shumë efektiv gjithashtu për menaxhimin e kopjeve rezervë. Depo të veçanta mund të kenë një fjalëkalim të veçantë për qasje në të dhëna dhe gjithashtu mund të mos kemi frikë se depo globale mund të dështojë ndonjëherë. Krijimi i depot të reja është po aq i lehtë sa në borg backup.
Në çdo rast, deduplication bëhet vetëm në raport me versionin e mëparshëm të backup-it, backup-i i mëparshëm përcaktohet nga path për backup-in e caktuar, kështu që nëse po backuponi objekte të ndryshme nga stdin në një depo të përbashkët, mos harroni të shënoni opsionin
--stdin-filename, ose të shënoni qartë çdo herë opsionin--parent.
Në anën tjetër, rikthimi në stdout merr shumë më tepër kohë sesa rikthimi në sistemin e skedarëve për shkak të paraleleve të tij. Në të ardhmen, është planifikuar të shtohet mbështetje më e ngushtë për backup-et për pajisjet bllok.
Në anën e tretë, për momentin rekomandohet të përdoret , pasi versioni 0.9.6 ka një defekt me rikthimin e ngadaltë të skedave të mëdhenj.
Për të testuar efektivitetin e backup-it dhe shpejtësinë e shkrimit / rikthimit nga rezervimi, krijova një repository të veçantë dhe provoja të bënte backup një imazh të vogël të makinerisë virtuale (21 GB). U kryen dy backup-e pa ndryshuar origjinalin, duke përdorur secilën nga zgjidhjet e listuara për të verifikuar se sa më shpejt / ngadalë kopjohen të dhënat e deduplikuara.
Siç mund të vërejmë, Borg Backup ka koeficientin më të mirë të efikasitetit në backup-in e parë, por humbet në shpejtësi si në shkrim ashtu dhe në rikthim.
Restic u tregua më i shpejtë se Benji Backup, por rikthen ngadalë në stdout, dhe të shkruajë drejtpërdrejt në pajisjen bllok, për fat të keq, nuk e di ende.
Pas pesha të gjitha pro dhe kundra, vendosa të ndalem në restic me rest-server si zgjidhja më komode dhe premtuese për backup.
Në këtë skrin kast ju mund të shihni si një kanali 10-gigabit shfrytëzohet plotësisht gjatë disa operacioneve të backup-it që bëhen njëkohësisht. Vlen të theksohet se shfrytëzimi i diskëve gjatë kësaj kohe nuk kalon 30%.
Jam shumë i kënaqur me zgjidhjen e marrë!
Burimi: habr.com
