Kyçi i kësaj shënimi vazhdon
cikli i kopjimit të rezervës
- Kopjimi i rezervës, pjesa 2: Përmbledhje dhe testim i mjeteve të kopjimit të bazuara në rsync
- Kopjimi i rezervës, pjesa 3: Përmbledhje dhe testim i duplicity, duplicaty, deja dup
- Kopjimi, pjesa 4: PĂ«rmbledhje dhe testim i zbackup, restic, borgbackup
- Kopjimi, pjesa 5: Testimi i bacula dhe veeam backup për linux
- Backup, pjesa 6: Krahasimi i mjeteve të backup-it
- Kopjimi, pjesa 7: PĂ«rfundimet
Siç e kemi shkruar në artikullin e parë, ka një numër të madh programesh për kopjimin e rezervës të bazuara në rsync.
Nga këto, që janë më të përshtatshme për kushtet tona, do të shqyrtoj 3: rdiff-backup, rsnapshot dhe burp.
Grupet e skedave
Grupet e skedave për testim do të jenë të njëjta për të gjithë kandidatët, duke përfshirë artikujt e ardhshëm.
Grupi i parë: 10 GB skedare mediatikë dhe afërsisht 50 MB - kodi burimor i përmbajtjes në php, madhësitë e skedarëve nga disa kilobajt për kodin burimor, deri në disa dhjetëra megabajt për skedarët mediatikë. Qëllimi është imitim i një uebsajti static.
Grupi i dytë: del nga i pari duke rinisur nën grupin e skedareve mediatikë me madhësi 5 GB. Qëllimi është të shqyrtohet sjellja e sistemit të kopjimit të rezervës në rinovimin e grupit.
Grupi i tretë: del nga i pari duke fshirë 3 GB skedare mediatikë dhe duke shtuar 3 GB skedare të rinj mediatikë. Qëllimi është të shqyrtohet sjellja e sistemit të kopjimit të rezervës gjatë një operacioni tipik të azhurnimit të uebsajtit.
Marrja e rezultateve
Cdo kopjim i rezervës kryhet të paktën 3 herë dhe shoqërohet me lirimin e cache-it të sistemit të skedarëve me komandat sync dhe echo 3 > /proc/sys/vm/drop_caches si në serverin testues ashtu edhe në serverin e ruajtjes së kopjimeve të rezervës.
Në serverin që do të jetë burimi i kopjimeve të rezervës, është instaluar një program për monitorim - netdata, me ndihmën e të cilit do të vlerësohet ngarkesa në server gjatë kopjimit, kjo është e nevojshme për të vlerësuar ngarkesën e serverit nga procesi i kopjimit të rezervës.
Po ashtu mendoj se serveri i ruajtjes së kopjimeve të rezervës është më i ngadaltë në procesor sesa serveri kryesor, por ka disqe më të mëdha me shpejtësi relativisht të vogël të shkrimit të rastësishëm - situata më e zakonshme gjatë kopjimit të rezervës, dhe pasi që serveri i kopjimit të rezervës siç duhet nuk duhet të kryejë detyra të tjera përveç kopjimit të rezervës, nuk do ta monitoroj ngarkesën e tij me netdata.
Po gjithashtu ndryshuan serverat, në të cilët do të testoj sistemet e ndryshme për kopjimin e rezervës.
Tani ata kanë karakteristika të mëposhtmeProcesori
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (duke përdorur sistemin LuaJIT 2.0.4)
Duke ekzekutuar testin me opsionet e mëposhtme:
Numri i thread-eve: 2
Duke inicializuar gjeneratorin e numrave të rastësishëm nga kohë aktuale
Limiti i numrave kryesorë: 20000
Duke inicializuar thread-et punuese...
Thread-et filluan!
Shpejtësia e CPU:
ngjarje për sekond: 1081.62
Statistikat e përgjithshme:
koha totale: 30.0013s
numri total i ngjarjeve: 32453
Latency (ms):
minimum: 1.48
mesatare: 1.85
maksimum: 9.84
percentili i 95-të: 2.07
shuma: 59973.40
Drejtësia e thread-eve:
ngjarje (mesatare/standard devijimi): 16226.5000/57.50
koha e ekzekutimit (mesatare/standard devijimi): 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 (duke përdorur sistemin LuaJIT 2.0.4)
Duke ekzekutuar testin e shpejtësisë së memories me opsionet e mëposhtme:
Numri i thread-eve: 4
Duke inicializuar gjeneratorin e numrave të rastësishëm nga koha aktuale
Duke ekzekutuar testin e shpejtësisë së memories me opsionet e mëposhtme:
madhësia e blokut: 1KiB
madhësia totale: 102400MiB
operacioni: lexim
shtrirja: globale
Duke inicializuar thread-et punuese...
Thread-et filluan!
Operacione totale: 104857600 (5837637.63 për sekond)
102400.00 MiB të transferuara (5700.82 MiB/sec)
Statistikat e përgjithshme:
koha totale: 17.9540s
numri total i ngjarjeve: 104857600
Latency (ms):
minimum: 0.00
mesatare: 0.00
maksimum: 66.08
percentili i 95-të: 0.00
shuma: 18544.64
Drejtësia e thread-eve:
ngjarje (mesatare/standard devijimi): 26214400.0000/0.00
koha e ekzekutimit (mesatare/standard devijimi): 4.6362/0.12
⊠dhe shkrimi
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 (duke përdorur sistemin LuaJIT 2.0.4)
Duke ekzekutuar testin e shpejtësisë së memories me opsionet e mëposhtme:
Numri i thread-eve: 4
Duke inicializuar gjeneratorin e numrave të rastësishëm nga koha aktuale
Duke ekzekutuar testin e shpejtësisë së memories me opsionet e mëposhtme:
madhësia e blokut: 1KiB
madhësia totale: 102400MiB
operacioni: shkruar
shtrirja: globale
Duke inicializuar thread-et punuese...
Thread-et filluan!
Operacione totale: 91414596 (3046752.56 për sekond)
89272.07 MiB të transferuara (2975.34 MiB/sec)
Statistikat e përgjithshme:
koha totale: 30.0019s
numri total i ngjarjeve: 91414596
Latency (ms):
minimum: 0.00
mesatare: 0.00
maksimum: 1022.90
percentili i 95-të: 0.00
shuma: 66430.91
Drejtësia e thread-eve:
ngjarje (mesatare/standard devijimi): 22853649.0000/945488.53
koha e ekzekutimit (mesatare/standard devijimi): 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 (në përdorim LuaJIT 2.0.4)
Duke e ekzekutuar testin me opsionet e mëposhtme:
Numri i thread-eve: 4
Inizializimi i gjeneruesit të numrave të rastësishëm nga koha aktuale
Flagasit e hapjes së skedareve ekstra: (asnjë)
128 skedare, 8MiB secili
1GiB madhësia totale e skedarit
Madhësia e bllokut 4KiB
Numri i kërkesave IO: 0
Raporti Lexo/Shkruaj për testin e kombinuar të IO-ve të rastit: 1.50
FSYNC periodik i aktivizuar, duke e thirrur fsync() çdo 100 kërkesa.
Duke e thirrur fsync() në fund të testit, e aktivizuar.
Duke përdorur modalitetin e I/O-s sinkron
Duke bërë testin e rastësishëm të r/w
Duke inicializuar thread-et punuese...
Thread-et janë nisur!
Operacionet mbi skedarë:
lexime/s: 4587.95
shkruaj/s: 3058.66
fsync/s: 9795.73
Kapaciteti:
lexuar, 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
mesatarja: 0.23
maks: 14.45
percentili 95: 0.94
shuma: 238629.34
Drejtësia e thread-eve:
ngjarje (mesatar/standev): 261623.0000/1849.14
koha e ekzekutimit (mesatar/standev): 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 (në përdorim LuaJIT 2.0.4)
Duke e ekzekutuar testin me opsionet e mëposhtme:
Numri i thread-eve: 4
Inizializimi i gjeneruesit të numrave të rastësishëm nga koha aktuale
Flagasit e hapjes së skedareve ekstra: (asnjë)
128 skedare, 8MiB secili
1GiB madhësia totale e skedarit
Madhësia e bllokut 4KiB
Numri i kërkesave IO: 0
Raporti Lexo/Shkruaj për testin e kombinuar të IO-ve të rastit: 1.50
FSYNC periodik i aktivizuar, duke e thirrur fsync() çdo 100 kërkesa.
Duke e thirrur fsync() në fund të testit, e aktivizuar.
Duke përdorur modalitetin e I/O-s sinkron
Duke bërë testin e rastësishëm të r/w
Duke inicializuar thread-et punuese...
Thread-et janë nisur!
Operacionet mbi skedarë:
lexime/s: 11.37
shkruaj/s: 7.58
fsync/s: 29.99
Kapaciteti:
lexuar, 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
mesatarja: 78.57
maks: 3840.90
percentili 95: 297.92
shuma: 243886.02
Drejtësia e thread-eve:
ngjarje (mesatar/standev): 776.0000/133.26
koha e ekzekutimit (mesatar/standev): 60.9715/1.59
Shpejtësia e rrjetit midis serverëve
iperf3 -c backup
Duke u lidhur me hostin backup, porti 5201
[ 4] lokal x.x.x.x port 59402 i 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/s 810 182 KBytes
[ 4] 1.00-2.00 sek 393 MBytes 3.30 Gbits/s 810 228 KBytes
[ 4] 2.00-3.00 sek 378 MBytes 3.17 Gbits/s 810 197 KBytes
[ 4] 3.00-4.00 sek 380 MBytes 3.19 Gbits/s 855 198 KBytes
[ 4] 4.00-5.00 sek 375 MBytes 3.15 Gbits/s 810 182 KBytes
[ 4] 5.00-6.00 sek 379 MBytes 3.17 Gbits/s 765 228 KBytes
[ 4] 6.00-7.00 sek 376 MBytes 3.15 Gbits/s 810 180 KBytes
[ 4] 7.00-8.00 sek 379 MBytes 3.18 Gbits/s 765 253 KBytes
[ 4] 8.00-9.00 sek 380 MBytes 3.19 Gbits/s 810 239 KBytes
[ 4] 9.00-10.00 sek 411 MBytes 3.44 Gbits/s 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sek 3.78 GBytes 3.25 Gbits/s 8100 dërguesi
[ 4] 0.00-10.00 sek 3.78 GBytes 3.25 Gbits/s marrësi
Metodologjia e testimit
- Sistemi i skedarëve përgatitet në serverin testues me paketën e parë të testit, në serverin e ruajtjes së kopjeve rezervë, repo inicializohet nëse është e nevojshme.
Procesi i kopjimit të rezervës është në proces dhe koha e tij po matet. - Në serverin testues, skedarët migrohen në paketën e dytë të testit. Procesi i kopjimit të rezervës është në proces dhe koha e tij po matet.
- Në serverin testues, migrimi bëhet në paketën e tretë të testit. Procesi i kopjimit të rezervës është në proces dhe koha e tij po matet.
- Paketa e tretë e testit pranohet si e para e re; pika 1-3 përsëriten edhe 2 herë.
- Të dhënat janë regjistruar në një tabelë përmbledhëse, grafikët me netdata janë shtuar.
- Raporti mbi metodën e veçantë të kopjimit të rezervës është përgatitur.
Rezultatet e pritura
Duke qenë se të gjitha 3 kandidaturat janë të bazuara në të njëjtën teknologji (rsync), pritet që rezultatet të jenë të ngjashme me rsync-un e zakonshëm, duke përfshirë të gjitha avantazhet e tij, që do të thotë:
- Skedarët në repo do të ruhen «ashtu si janë».
- Madhësia e repo-s do të rritet vetëm duke përfshirë diferencën midis kopjeve rezervë.
- Do të ketë një ngarkesë mjaft të madhe në rrjet gjatë transferimit të të dhënave, si dhe një ngarkesë të vogël në procesor.
Testimi i zakonshëm i rsync do të përdoret si standard, rezultatet e tij
janë si më poshtë
Bllokimi ndodhi në serverin e ruajtjes së të dhënave në formën e një disku HDD, e cila duket qartë në grafikët e formës së grimcave.
Të dhënat u kopjuan për 4 minuta dhe 15 sekonda.
Testimi i rdiff-backup
Kandidati i parĂ« â rdiff-backup, njĂ« skript nĂ« python, i cili kryen kopjimin e njĂ« katalogu nĂ« njĂ« tjetĂ«r. NdĂ«rsa backup-i aktual ruhet «ashtu si Ă«shtë», kopjet e mĂ«parshme grumbullohen nĂ« njĂ« nĂ«nkatalog tĂ« veçantĂ« nĂ« mĂ«nyrĂ« inkrementale, duke kursyer kĂ«shtu hapĂ«sirĂ«.
Do të verifikojmë modalitetin standard të punës, dmth. nisja e procesit të kopjimit të rezervës do të inicohet nga klienti, ndërsa në anën e serverit do të nisë një proces për kopjimin e rezervave i cili pranon të dhënat.
Le të shohim, çfarë është në gjendje të bëjë në kushtet tona.
Koha e ekzekutimit për çdo test:
Ngritja e parë
Ngritja e dytë
Ngritja e tretë
Grupi i parë
16m32s
16m26s
16m19s
Grupi i dytë
2h5m
2h10m
2h8m
Grupi i tretë
2h9m
2h10m
2h10m
Rdiff-backup reagoi shumë ndjeshëm ndaj çdo ndryshimi të madh të të dhënave, gjithashtu nuk përdor plotësisht rrjetin.
Testimi i rsnapshot
Kandidati i dytĂ« â rsnapshot, Ă«shtĂ« njĂ« skript nĂ« perl, kĂ«rkesa kryesore pĂ«r funksionimin efikas tĂ« tĂ« cilit Ă«shtĂ« mbĂ«shtetje pĂ«r lidhje tĂ« forta. KĂ«shtu, ruhet hapĂ«sira nĂ« disk. NĂ« kĂ«tĂ« mĂ«nyrĂ«, skedarĂ«t qĂ« nuk kanĂ« ndryshuar qĂ« nga kopja e fundit rezervĂ« do tĂ« referohen nĂ« skedarin origjinal nĂ«pĂ«rmjet lidhjeve tĂ« forta.
Po ashtu, logjika e procesit të kopjimit rezervë është e invertuar: serveri aktivisht "shkonte" vetë te klientët e tij dhe merrte të dhënat.
Rezultatet e testimit
rezultatet ishin si më poshtë
Ngritja e parë
Ngritja e dytë
Ngritja e tretë
Grupi i parë
4m22s
4m19s
4m16s
Grupi i dytë
2m6s
2m10s
2m6s
Grupi i tretë
1m18s
1m10s
1m10s
Punoi shumë shpejt, dukshëm më shpejt se rdiff-backup dhe shumë afër rsync të pastër.
Testimi burp
NjĂ« tjetĂ«r variant â implementimi nĂ« C mbi librsync â burp, ka njĂ« arkitekturĂ« klient-server duke pĂ«rfshirĂ« autorizimin e klientĂ«ve dhe jetesĂ«n e njĂ« ndĂ«rfaqeje web (nuk Ă«shtĂ« pjesĂ« e paketimit bazĂ«). NjĂ« tipar tjetĂ«r interesant â kopjimi rezervĂ« pa tĂ« drejtĂ« rikuperimi nga klientĂ«t.
Le të shohimperformanca.
Ngritja e parë
Ngritja e dytë
Ngritja e tretë
Grupi i parë
11m21s
11m10s
10m56s
Grupi i dytë
5m37s
5m40s
5m35s
Grupi i tretë
3m33s
3m24s
3m40s
Punoi dy herĂ« mĂ« ngadalĂ« se rsnapshot, megjithatĂ« gjithashtu mjaft shpejt, dhe sigurisht mĂ« shpejt se rdiff-backup. Grafikat janĂ« paksa tĂ« pjerrĂ«ta â performanca, pĂ«rsĂ«ri, varet nga sistemi disk tĂ« serverit pĂ«r ruajtjen e kopjeve rezervĂ«, ndonĂ«se kjo nuk Ă«shtĂ« aq e dukshme si te rsnapshot.
Rezultatet
Madhësia e depozitave për të gjithë kandidatët ishte përafërsisht e njëjtë, domethënë fillimisht rritja deri në 10 GB, pastaj rritja deri në 15 GB, pastaj rritja deri në 18 GB etj., e cila është e lidhur me veçoritë e funksionimit të rsync. Po ashtu, duhet të theksohet njëprocesi i të gjithë kandidatëve (ngarkesa mbi procesorin rreth 50% në një makinë me dy bërthama). Të gjithë 3 kandidatët ofronin mundësinë e rikuperimit të kopjes rezervë më të fundit "siç është", domethënë mund 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 rsync.
PĂ«rfundimet
Sa mĂ« e komplikuar tĂ« jetĂ« sistemi i kopjimit rezervĂ« dhe sa mĂ« shumĂ« mundĂ«si tĂ« ketĂ« â aq mĂ« ngadalĂ« do tĂ« punojĂ«, por pĂ«r projekte jo shumĂ« kĂ«rkuese, çdo njĂ«ri prej tyre do tĂ« ishte i pĂ«rshtatshĂ«m, pĂ«rveç, ndoshta, rdiff-backup.
Ankandi
Ky shënim vazhdon ciklin për kopjimin rezervë
Kopjimi, pjesa 2: Përmbledhje dhe testim i mjeteve për kopjimin që bazohen në rsync
Kopjimi i rezervës, pjesa 3: Përmbledhje dhe testim i duplicity, duplicaty, deja dup
Kopjimi, pjesa 4: PĂ«rmbledhje dhe testim i zbackup, restic, borgbackup
Kopjimi, pjesa 5: Testimi i bacula dhe veeam backup për linux
Backup, pjesa 6: Krahasimi i mjeteve të backup-it
Kopjimi, pjesa 7: PĂ«rfundimet
Autori i publikimit: Pavel Demkoviç
Burimi: habr.com
