ProHoster > Blog > Administrim > Kopjimi i rezervave, pjesa 2: Përmbledhje dhe testim i mjeteve për kopje rezervë bazuar në rsync

Kopjimi i rezervave, pjesa 2: Përmbledhje dhe testim i mjeteve për kopje rezervë bazuar në rsync

Kopjimi i rezervave, pjesa 2: Përmbledhje dhe testim i mjeteve për kopje rezervë bazuar në rsync
Ky kjo shënim vazhdon

ciklin mbi kopjet rezervë

  1. Kopjimi i rezervave, pjesa 1: Pse është e nevojshme kopjimi i rezervave, një përmbledhje e metodave, teknologjive
  2. Kopja rezervë, pjesa 2: Pasqyrë dhe testim i mjeteve të kopjimit bazuar në rsync
  3. Kopja rezervë, pjesa 3: Pasqyrë dhe testim i duplicity, duplicaty, deja dup
  4. Kopjimi i rezervave, pjesa 4: PĂ«rmbledhje dhe testim i zbackup, restic, borgbackup
  5. Kopjimi i rezervave, pjesa 5: Testimi i bacula dhe veeam backup për linux
  6. Kopjimi i rezervave, pjesa 6: Krahasimi i mjeteve për kopje rezervë
  7. Kopjimi i rezervave, pjesa 7: PĂ«rfundime

Siç kemi shkruar në artikullin e parë, ka një numër të madh të programeve të kopjimit rezervë që bazohen në rsync.

Nga ato që janë më të përshtatshme për kushtet tona, do të shqyrtoj 3: rdiff-backup, rsnapshot dhe burp.

Këto janë grupe skedarësh të testimit

Grupet e skedarëve për testim do të jenë të njëjta për të gjithë kandidatët, përfshirë artikujt e ardhshëm.

Grupi i parĂ«: 10 GB skedarĂ«sh mediatikĂ« dhe rreth 50 MB — kodi burimor i faqes nĂ« php, madhĂ«sitĂ« e skedarĂ«ve nga disa kilobajtĂ« pĂ«r kodin burimor, deri nĂ« dhjetĂ«ra megabajt pĂ«r skedarĂ«t mediatikĂ«. QĂ«llimi Ă«shtĂ« imitim i njĂ« faqjeje me statikĂ«.

Grupi i dytë: rezulton nga i pari duke riemëruar nënkatalogun me skedarë mediatikë me madhësi 5 GB. Qëllimi është studimi i sjelljes së sistemit të kopjimit rezervë në riemërimin e katalogut.

Grupi i tretë: rezulton nga i pari duke fshirë 3 GB skedarë mediatikë dhe duke shtuar 3 GB skedarë mediatikë të rinj. Qëllimi është studimi i sjelljes së sistemit të kopjimit rezervë gjatë një operacioni standard për përditësimin e faqes.

Marrja e rezultateve

Çdo kopjim rezervĂ« kryhet tĂ« paktĂ«n 3 herĂ« dhe shoqĂ«rohet me rikthimin e caches tĂ« sistemit tĂ« skedarĂ«ve me komandat sync dhe echo 3 > /proc/sys/vm/drop_caches si nĂ« anĂ«n e serverit tĂ« testimit ashtu edhe tĂ« serverit tĂ« ruajtjes sĂ« kopjeve rezervĂ«.

NĂ« serverin, i cili do tĂ« jetĂ« burimi i kopjeve rezervĂ«, Ă«shtĂ« instaluar softueri pĂ«r monitorim — netdata, me anĂ« tĂ« tĂ« cilit do tĂ« vlerĂ«sohet ngarkesa nĂ« server gjatĂ« kopjimit, kjo Ă«shtĂ« e nevojshme pĂ«r vlerĂ«simin e ngarkesĂ«s sĂ« serverit nga procesi i kopjimit rezervĂ«.

Gjithashtu, mendoj se serveri i ruajtjes sĂ« kopjeve rezervĂ« Ă«shtĂ« mĂ« i ngadalshĂ«m nĂ« procesor sesa serveri kryesor, por ka disqe mĂ« tĂ« mĂ«dha me shpejtĂ«si tĂ« vogĂ«l tĂ« regjistrimit rastĂ«sor — situata mĂ« e zakonshme gjatĂ« kopjimit rezervĂ«, dhe pĂ«r arsyen se serveri i kopjimit rezervĂ« normalisht nuk duhet tĂ« kryejĂ« detyra tĂ« tjera pĂ«rveç kopjimit rezervĂ«, ngarkesĂ«n e tij me ndihmĂ«n e netdata nuk do ta monitoroj.

Gjithashtu, kam ndryshuar serverët mbi të cilët do të testoj sistemet e ndryshme për kopjimin rezervë.

Tani karakteristikat e tyre janë si më poshtëProcesori

sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (using system LuaJIT 2.0.4)

Duke testin me opsionet e mëposhtme:
Numri i thread-Ă«ve: 2
Inicijalizimi i gjeneratorit të numrave të rastësishëm nga koha aktuale


Shkalla e numrave prim: 20000

Inicijalizimi i thread-ëve punëtorë...

Thread-Ă«t filluan!

Shpejtësia e CPU:
    ngjarje për sekondë:  1081.62

Statistikat e përgjithshme:
    koha totale:                          30.0013s
    numri total i ngjarjeve:              32453

Vonesa (ms):
         min:                                    1.48
         avg:                                    1.85
         max:                                    9.84
         95-ta percentile:                        2.07
         shuma:                                59973.40

Drejtësia e thread-ëve:
    ngjarje (avg/stddev):           16226.5000/57.50
    koha e ekzekutimit (avg/stddev):   29.9867/0.00

Memoria e përkohshme, leximi


sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run
sysbench 1.0.17 (using system LuaJIT 2.0.4)

Duke testuar shpejtësinë e memories me opsionet e mëposhtme:
Numri i thread-Ă«ve: 4
Inicijalizimi i gjeneratorit të numrave të rastësishëm nga koha aktuale


Duke testuar shpejtësinë e memories me opsionet e mëposhtme:
  madhësia e bllokut: 1KiB
  madhësia totale: 102400MiB
  operacioni: lexim
  skopa: globale

Inicijalizimi i thread-ëve punëtorë...

Thread-Ă«t filluan!

Operacionet totale: 104857600 (5837637.63 për sekondë)

102400.00 MiB të transferuar (5700.82 MiB/sec)


Statistikat e përgjithshme:
    koha totale:                          17.9540s
    numri total i ngjarjeve:              104857600

Vonesa (ms):
         min:                                    0.00
         avg:                                    0.00
         max:                                   66.08
         95-ta percentile:                        0.00
         shuma:                                18544.64

Drejtësia e thread-ëve:
    ngjarje (avg/stddev):           26214400.0000/0.00
    koha e ekzekutimit (avg/stddev):   4.6362/0.12


 dhe shk writing

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.0.17 (using system LuaJIT 2.0.4)

Duke testuar shpejtësinë e memories me opsionet e mëposhtme:
Numri i thread-Ă«ve: 4
Inicijalizimi i gjeneratorit të numrave të rastësishëm nga koha aktuale


Duke testuar shpejtësinë e memories me opsionet e mëposhtme:
  madhësia e bllokut: 1KiB
  madhësia totale: 102400MiB
  operacioni: shk writing
  skopa: globale

Inicijalizimi i thread-ëve punëtorë...

Thread-Ă«t filluan!

Operacionet totale: 91414596 (3046752.56 për sekondë)

89272.07 MiB të transferuar (2975.34 MiB/sec)


Statistikat e përgjithshme:
    koha totale:                          30.0019s
    numri total i ngjarjeve:              91414596

Vonesa (ms):
         min:                                    0.00
         avg:                                    0.00
         max:                                 1022.90
         95-ta percentile:                        0.00
         shuma:                                66430.91

Drejtësia e thread-ëve:
    ngjarje (avg/stddev):           22853649.0000/945488.53
    koha e ekzekutimit (avg/stddev):   16.6077/1.76

Disku në serverin burim të të dhënave

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (duke përdorë system LuaJIT 2.0.4)

Duke ekzekutuar testin me këto opsione:
Numri i thread-eve: 4
Duke inicializuar gjeneruesin e numrave të rastësishëm nga koha e tanishme


Flukset shtesë të hapjes së skedarëve: (asnjë)
128 skedarë, 8MiB secili
1GiB total i madhësisë së skedarëve
Madhësia e bllokut 4KiB
Numri i kërkesave IO: 0
Raporti Lexo/Shkruaj për testin e kombinuar IO të rastësishëm: 1.50
FSYNC periodik i aktivizuar, duke thirrur fsync() çdo 100 kërkesa.
Duke thirrur fsync() në fund të testit, Aktivizuar.
Duke përdorur modin sinkron I/O
Duke bërë testin e rastësishëm r/w
Duke inicializuar thread-et e punës...

Thread-et filluan!


Operacionet e skedarëve:
    lexime/s:                      4587.95
    shkruaj/ s:                     3058.66
    fsyncs/s:                     9795.73

Kapaciteti:
    lexim, MiB/s:                  17.92
    shkruar, MiB/s:               11.95

Statistikat e përgjithshme:
    koha totale:                          60.0241s
    numri total i ngjarjeve:              1046492

Latenca (ms):
         min:                                    0.00
         mesatar:                                    0.23
         max:                                   14.45
         95-ta percentile:                        0.94
         shuma:                               238629.34

Blerja e thread-eve:
    ngjarje (mesatare / standard deviasioni):           261623.0000 / 1849.14
    koha e ekzekutimit (mesatare / standard deviasioni):   59.6573 / 0.00

Disku në serverin e ruajtjes së kopjeve rezervë

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (duke përdorur system LuaJIT 2.0.4)

Duke ekzekutuar testin me këto opsione:
Numri i thread-eve: 4
Duke inicializuar gjeneruesin e numrave të rastësishëm nga koha e tanishme


Flukset shtesë të hapjes së skedarëve: (asnjë)
128 skedarë, 8MiB secili
1GiB total i madhësisë së skedarëve
Madhësia e bllokut 4KiB
Numri i kërkesave IO: 0
Raporti Lexo/Shkruaj për testin e kombinuar IO të rastësishëm: 1.50
FSYNC periodik i aktivizuar, duke thirrur fsync() çdo 100 kërkesa.
Duke thirrur fsync() në fund të testit, Aktivizuar.
Duke përdorur modin sinkron I/O
Duke bërë testin e rastësishëm r/w
Duke inicializuar thread-et e punës...

Thread-et filluan!


Operacionet e skedarëve:
    lexime/s:                      11.37
    shkruaj/s:                     7.58
    fsyncs/s:                     29.99

Kapaciteti:
    lexim, MiB/s:                  0.04
    shkruar, MiB/s:               0.03

Statistikat e përgjithshme:
    koha totale:                          73.8868s
    numri total i ngjarjeve:              3104

Latenca (ms):
         min:                                    0.00
         mesatar:                                   78.57
         max:                                 3840.90
         95-ta percentile:                      297.92
         shuma:                               243886.02

Blerja e thread-eve:
    ngjarje (mesatare / standard deviasioni):           776.0000 / 133.26
    koha e ekzekutimit (mesatare / standard deviasioni):   60.9715 / 1.59

Shpejtësia e rrjetit midis serverëve

iperf3 -c backup
Duke koneksionin me hostin backup, port 5201
[  4] lokale x.x.x.x port 59402 e lidhur me y.y.y.y port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sek   419 MBytes  3.52 Gbits/sec  810    182 KBytes
[  4]   1.00-2.00   sek   393 MBytes  3.30 Gbits/sec  810    228 KBytes
[  4]   2.00-3.00   sek   378 MBytes  3.17 Gbits/sec  810    197 KBytes
[  4]   3.00-4.00   sek   380 MBytes  3.19 Gbits/sec  855    198 KBytes
[  4]   4.00-5.00   sek   375 MBytes  3.15 Gbits/sec  810    182 KBytes
[  4]   5.00-6.00   sek   379 MBytes  3.17 Gbits/sec  765    228 KBytes
[  4]   6.00-7.00   sek   376 MBytes  3.15 Gbits/sec  810    180 KBytes
[  4]   7.00-8.00   sek   379 MBytes  3.18 Gbits/sec  765    253 KBytes
[  4]   8.00-9.00   sek   380 MBytes  3.19 Gbits/sec  810    239 KBytes
[  4]   9.00-10.00  sek   411 MBytes  3.44 Gbits/sec  855    184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sek  3.78 GBytes  3.25 Gbits/sec  8100             dërgues
[  4]   0.00-10.00  sek  3.78 GBytes  3.25 Gbits/sec                  marrës

Metodologjia e testimit

  1. Në serverin testues po përgatitet sistemi i skedarëve me grupin e parë të testeve, në serverin për ruajtjen e kopjeve rezervë po inicializohet repositori nëse është e nevojshme.
    Po niset procesi i kopjimit rezervë dhe po mashet koha e tij.
  2. Në serverin testues bëhet migrimi i skedarëve në grupin e dytë të testeve. Po niset procesi i kopjimit rezervë dhe po mashet koha e tij.
  3. Në serverin testues bëhet migrimi në grupin e tretë të testeve. Po niset procesi i kopjimit rezervë dhe po mashet koha e tij.
  4. Grupi i tretë i testeve pranohet si i pari i ri; pikat 1-3 përsëriten edhe 2 herë.
  5. Të dhënat regjistrohen në një tabelë përmbledhëse, grafiket me netdata shtohen.
  6. Krijohet një raport për metodën e veçantë të kopjimit rezervë.

Rezultatet e pritura

Duke qenë se të 3 kandidatë janë të bazuar në të njëjtën teknologji (rsync), pritet që rezultatet të jenë të ngjashme me rsync-in e zakonshëm, duke përfshirë të gjitha avantazhet e tij, që janë:

  1. Skedarët në repositor do të ruhen "siç janë".
  2. Madhësia e repositorit do të rritet vetëm duke përfshirë diferencën midis kopjeve rezervë.
  3. Do të ketë një ngarkesë relativisht të madhe në rrjet gjatë transmetimit të të dhënave, si dhe një ngarkesë të vogël në procesor.

Testimi i zakonshëm i rsync do të përdoret si një standard, rezultatet e tij

janë të tillaKopjimi i rezervave, pjesa 2: Përmbledhje dhe testim i mjeteve për kopje rezervë bazuar në rsync

Ngushtica ishte në serverin për ruajtjen e të dhënave në një disk të bazuar në HDD, gjë që është mjaft parë qartë në grafiket si një brusht.

Të dhënat u kopjuan për 4 minuta dhe 15 sekonda.

Testimi i rdiff-backup

Kandidati i parë është rdiff-backup, një skript në python që kryen kopjim të një katalogu në një tjetër. Në këtë mënyrë, kopja aktuale ruhet "ashtu si është", ndërsa kopjet e bëra më parë vendosen në një nënkatalog të veçantë në mënyrë inkrementale, duke kursyer kështu hapësirë.

Do ta kontrollojmë modin standard të funksionimit, dmth. fillimi i procesit të kopjimit inicihet nga klienti vetë, dhe në anën e serverit aktivizohet një proces për kopjimin që pranon të dhënat.

Le ta shohim, çfarë është në gjendje të bëjë në kushtet tona.

Kopjimi i rezervave, pjesa 2: Përmbledhje dhe testim i mjeteve për kopje rezervë bazuar në rsync

Koha e punës për secilën nisje testuese:

Çelja e parĂ«
Çelja e dytĂ«
Çelja e tretĂ«

Grupi i parë
16m32s
16m26s
16m19s

Grupi i dytë
2h5m
2h10m
2h8m

Grupi i tretë
2h9m
2h10m
2h10m

Rdiff-backup reagon shumë ndjeshëm ndaj çdo ndryshimi të madh të të dhënave, dhe gjithashtu nuk e shfrytëzon plotësisht rrjetin.

Testimi i rsnapshot

Kandidati i dytë është rsnapshot, një skript në perl, kërkesa kryesore për funksionimin efikas është mbështetje për lidhjet e forta. Kështu kursen hapësirë në disk. Ndërkohë, skedarët që nuk janë ndryshuar që nga kopja e mëparshme do të lidhen me skedarin origjinal përmes lidhjeve të forta.

Gjithashtu logjika e procesit të kopjimit është e inversuar: serveri shkon aktivisht tek klientët e tij dhe merr të dhënat.

Rezultatet e testimit

kanë rezultuar si të mëposhtmetKopjimi i rezervave, pjesa 2: Përmbledhje dhe testim i mjeteve për kopje rezervë bazuar në rsync

Çelja e parĂ«
Çelja e dytĂ«
Çelja e tretĂ«

Grupi i parë
4m22s
4m19s
4m16s

Grupi i dytë
2m6s
2m10s
2m6s

Grupi i tretë
1m18s
1m10s
1m10s

E shkoi shumë dhe shumë shpejt, shumë më shpejt se rdiff-backup dhe shumë pranë rsync-it të pastër.

Testimi i burp

NjĂ« tjetĂ«r variant Ă«shtĂ« implementimi nĂ« C mbi librsync — burp, ka njĂ« arkitekturĂ« klient-server duke pĂ«rfshirĂ« autorizimin e klientĂ«ve, si dhe ekzistencĂ«n e njĂ« ndĂ«rfaqe web (nuk pĂ«rfshihet nĂ« paketĂ«n bazĂ«). NjĂ« karakteristikĂ« tjetĂ«r interesante Ă«shtĂ« kopjimi pa tĂ« drejtĂ« rikuperimi te klientĂ«t.

Le ta shohim nëe përmirësuar.

Kopjimi i rezervave, pjesa 2: Përmbledhje dhe testim i mjeteve për kopje rezervë bazuar në rsync

Çelja e parĂ«
Çelja e dytĂ«
Çelja e tretĂ«

Grupi i parë
11m21s
11m10s
10m56s

Grupi i dytë
5m37s
5m40s
5m35s

Grupi i tretë
3m33s
3m24s
3m40s

E punoi dy herĂ« mĂ« ngadalĂ« se rsnapshot, megjithatĂ« gjithashtu mjaft shpejt, dhe sigurisht shumĂ« mĂ« shpejt se rdiff-backup. Grafikat ishin paksa me zigzag — performanca pĂ«rsĂ«ri ngre nĂ« sistemin e diskut tĂ« serverit qĂ« ruan kopjet rezervĂ«, megjithĂ«se kjo nuk Ă«shtĂ« aq e shprehur sa tek rsnapshot.

Rezultatet

Madhësia e depozitave te të gjithë kandidatëve ishte afërsisht e njëjtë, pra fillimisht rritje deri në 10 GB, më pas rritje deri në 15 GB, më pas rritje deri në 18 GB e kështu me radhë, e cila lidhët me veçoritë e funksionimit të rsync. Gjithashtu, duhet të theksohet se të gjithë kandidatët ishin njëra-fillim (ngarkesa në procesor rreth 50% në një makinë me dy bërthama). Të 3 kandidatët ofruan mundësinë e rikuperimit të kopjes më të fundit rezervë "ashtu siç është", pra ishte e mundur të rikuperoheshin skedarët pa përdorimin e ndonjë programi të jashtëm përfshirë ato që ishin përdorur për krijimin e depozitave. Kjo gjithashtu është një "trashëgimi e natyrshme" e rsync.

PĂ«rfundimet

Sa më e komplikuar të jetë sistemi i kopjimit dhe sa më shumë mundësi të ketë, aq më ngadalë do të punojë, por për projektet që nuk kërkojnë shumë mund të përshtatet çdo njëra prej tyre, ndoshta përjashto rdiff-backup.

Njoftim

Ky shënim vazhdon ciklin mbi kopjimin

Kopjimi i rezervave, pjesa 1: Pse është e nevojshme kopjimi i rezervave, një përmbledhje e metodave, teknologjive
Kopjimi i rezervave, pjesa 2: Përmbledhje dhe testim i mjeteve për kopje rezervë bazuar në rsync
Kopja rezervë, pjesa 3: Pasqyrë dhe testim i duplicity, duplicaty, deja dup
Kopjimi i rezervave, pjesa 4: PĂ«rmbledhje dhe testim i zbackup, restic, borgbackup
Kopjimi i rezervave, pjesa 5: Testimi i bacula dhe veeam backup për linux
Kopjimi i rezervave, pjesa 6: Krahasimi i mjeteve për kopje rezervë
Kopjimi i rezervave, pjesa 7: PĂ«rfundime

Autori i publikimit: Pavel Demkovich

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster