ProHoster >> Blog >> Administrimi >> Ruajtje backup për mijëra makina virtuale me mjete të lira

Ruajtje backup për mijëra makina virtuale me mjete të lira

Ruajtje backup për mijëra makina virtuale me mjete të lira

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:

Erasure Coding — 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 minio.

DRAID — 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.

Ruajtje backup për mijëra makina virtuale me mjete të lira

Ruajtje backup për mijëra makina virtuale me mjete të lira

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:

Ruajtje backup për mijëra makina virtuale me mjete të lira

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Ă« u kĂ«rkova 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ë gmelikov ka sugjerova, se mund të përmirësoj performancën e ZFS duke vendosur opsionet e mëposhtme:

xattr=sa atime=off recordsize=1M

dhe 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ë SSDSC2KI128G8 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 errors

Mirë, 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ë:

Benji Backup — fork Backy2, 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.

Borg Backup — fork Attic, 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Ă«.

Restic — 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Ă« rest-server 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 versioni nga master, 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.

Ruajtje backup për mijëra makina virtuale me mjete të lira

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.

Ruajtje backup për mijëra makina virtuale me mjete të lira

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

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster