Ky shënim vazhdon
cikli rreth rezervimit
- Rezervimi Pjesa 2: Rishikimi dhe testimi i mjeteve rezervë të bazuara në rsync
- Rezervimi Pjesa 3: Rishikimi dhe testimi i dyfishimit, dyfishimit, deja dup
- Rezervimi Pjesa 4: Rishikimi dhe testimi i zbackup, restic, borgbackup
- Rezervimi Pjesa 5: Testimi i kopjes rezervë të bakulës dhe veeam për linux
- Rezervimi Pjesa 6: Krahasimi i mjeteve rezervë
- Pjesa rezervë 7: Përfundime
Siç kemi shkruar tashmë në artikullin e parë, ekziston një numër shumë i madh i programeve rezervë të bazuar në rsync.
Nga ato që i përshtaten më mirë kushteve tona, unë do të konsideroj 3: rdiff-backup, rsnapshot dhe gromësirë.
Testimi i grupeve të skedarëve
Grupet e skedarëve të testimit do të jenë të njëjta për të gjithë kandidatët, përfshirë artikujt e ardhshëm.
Seti i parë: 10 GB skedarë mediash dhe afërsisht 50 MB - kodi burimor i faqes në PHP, madhësia e skedarëve nga disa kilobajt për kodin burimor, deri në dhjetëra megabajt për skedarët mediatikë. Qëllimi është të imitoni një vend statik.
Seti i dytë: marrë nga i pari kur riemërtoni një nëndirektor me skedarë mediash 5 GB. Qëllimi është të studiohet sjellja e sistemit rezervë kur riemërtoni një drejtori.
Seti i tretë: marrë nga e para duke fshirë 3 GB skedarë media dhe duke shtuar 3 GB skedarë të rinj mediash. Qëllimi është të studiohet sjellja e sistemit rezervë gjatë një operacioni tipik të përditësimit të faqes.
Marrja e rezultateve
Ădo kopje rezervĂ« kryhet tĂ« paktĂ«n 3 herĂ« dhe shoqĂ«rohet me rivendosjen e cache-ve tĂ« sistemit tĂ« skedarĂ«ve me komanda sync Đž echo 3 > /proc/sys/vm/drop_caches si nĂ« anĂ«n e serverit testues ashtu edhe nĂ« serverin e ruajtjes rezervĂ«.
Në serverin që do të jetë burimi i kopjeve rezervë, është instaluar softueri monitorues - 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 në server gjatë procesit të kopjimit.
Unë gjithashtu besoj se serveri i ruajtjes rezervë është më i ngadalshëm për sa i përket procesorit sesa serveri kryesor, por ka disqe më të gjerë me një shpejtësi relativisht të ulët të shkrimit të rastësishëm - situata më e zakonshme gjatë kopjimeve, dhe për shkak të faktit se serveri rezervë nuk duhet të bëj siç duhet Unë nuk do të gjurmoj detyra të tjera përveç rezervimit, ngarkimin e tij duke përdorur netdata.
Kam ndryshuar gjithashtu serverët në të cilët do të kontrolloj sisteme të ndryshme për kopje rezervë.
Tani ata kanë karakteristikat e mëposhtmeprocesor
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 2
Initializing random number generator from current time
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 1081.62
General statistics:
total time: 30.0013s
total number of events: 32453
Latency (ms):
min: 1.48
avg: 1.85
max: 9.84
95th percentile: 2.07
sum: 59973.40
Threads fairness:
events (avg/stddev): 16226.5000/57.50
execution time (avg/stddev): 29.9867/0.00
RAM, duke lexuar...
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)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: read
scope: global
Initializing worker threads...
Threads started!
Total operations: 104857600 (5837637.63 per second)
102400.00 MiB transferred (5700.82 MiB/sec)
General statistics:
total time: 17.9540s
total number of events: 104857600
Latency (ms):
min: 0.00
avg: 0.00
max: 66.08
95th percentile: 0.00
sum: 18544.64
Threads fairness:
events (avg/stddev): 26214400.0000/0.00
execution time (avg/stddev): 4.6362/0.12
...dhe regjistrimi
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)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global
Initializing worker threads...
Threads started!
Total operations: 91414596 (3046752.56 per second)
89272.07 MiB transferred (2975.34 MiB/sec)
General statistics:
total time: 30.0019s
total number of events: 91414596
Latency (ms):
min: 0.00
avg: 0.00
max: 1022.90
95th percentile: 0.00
sum: 66430.91
Threads fairness:
events (avg/stddev): 22853649.0000/945488.53
execution time (avg/stddev): 16.6077/1.76
Disku në serverin e burimit 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 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...
Threads started!
File operations:
reads/s: 4587.95
writes/s: 3058.66
fsyncs/s: 9795.73
Throughput:
read, MiB/s: 17.92
written, MiB/s: 11.95
General statistics:
total time: 60.0241s
total number of events: 1046492
Latency (ms):
min: 0.00
avg: 0.23
max: 14.45
95th percentile: 0.94
sum: 238629.34
Threads fairness:
events (avg/stddev): 261623.0000/1849.14
execution time (avg/stddev): 59.6573/0.00
Disku në serverin e ruajtjes rezervë
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...
Threads started!
File operations:
reads/s: 11.37
writes/s: 7.58
fsyncs/s: 29.99
Throughput:
read, MiB/s: 0.04
written, MiB/s: 0.03
General statistics:
total time: 73.8868s
total number of events: 3104
Latency (ms):
min: 0.00
avg: 78.57
max: 3840.90
95th percentile: 297.92
sum: 243886.02
Threads fairness:
events (avg/stddev): 776.0000/133.26
execution time (avg/stddev): 60.9715/1.59
Shpejtësia e rrjetit ndërmjet serverëve
iperf3 -c backup
Connecting to host backup, port 5201
[ 4] local x.x.x.x port 59402 connected to y.y.y.y port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 419 MBytes 3.52 Gbits/sec 810 182 KBytes
[ 4] 1.00-2.00 sec 393 MBytes 3.30 Gbits/sec 810 228 KBytes
[ 4] 2.00-3.00 sec 378 MBytes 3.17 Gbits/sec 810 197 KBytes
[ 4] 3.00-4.00 sec 380 MBytes 3.19 Gbits/sec 855 198 KBytes
[ 4] 4.00-5.00 sec 375 MBytes 3.15 Gbits/sec 810 182 KBytes
[ 4] 5.00-6.00 sec 379 MBytes 3.17 Gbits/sec 765 228 KBytes
[ 4] 6.00-7.00 sec 376 MBytes 3.15 Gbits/sec 810 180 KBytes
[ 4] 7.00-8.00 sec 379 MBytes 3.18 Gbits/sec 765 253 KBytes
[ 4] 8.00-9.00 sec 380 MBytes 3.19 Gbits/sec 810 239 KBytes
[ 4] 9.00-10.00 sec 411 MBytes 3.44 Gbits/sec 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 sender
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec receiver
Metodologjia e Testimit
- Në serverin e testimit, përgatitet një sistem skedari me grupin e parë të provës, dhe në serverin e ruajtjes rezervë, nëse është e nevojshme, inicializohet depoja.
Fillon procesi i rezervimit dhe matet koha e tij. - Në serverin e testimit, skedarët migrohen në grupin e dytë të testimit. Fillon procesi i rezervimit dhe matet koha e tij.
- Në serverin e testimit, migrimi kryhet deri në grupin e tretë të provës. Fillon procesi i rezervimit dhe matet koha e tij.
- Grupi i tretë i testit që rezulton pranohet si i pari i ri; Hapat 1-3 përsëriten edhe 2 herë të tjera.
- Të dhënat futen në një tabelë kryesore dhe shtohen grafikët me të dhëna net.
- Një raport gjenerohet për metodën individuale të rezervimit.
Rezultatet e pritura
Meqenëse të 3 kandidatët bazohen në të njëjtën teknologji (rsync), rezultatet pritet të jenë afër rsync-it të rregullt, duke përfshirë të gjitha avantazhet e tij, përkatësisht:
- Skedarët në depo do të ruhen "siç është".
- Madhësia e depove do të rritet vetëm duke përfshirë ndryshimin midis kopjeve rezervë.
- Do të ketë një ngarkesë relativisht të madhe në rrjet gjatë transferimit të të dhënave, si dhe një ngarkesë të vogël në procesor.
Një test test i rsync-it të rregullt do të përdoret si referencë, rezultatet e tij
këto janë
Gryka e ngushtë ishte në serverin rezervë të ruajtjes së të dhënave në formën e një disku të bazuar në HDD, i cili është mjaft i dukshëm në grafikët e dhëmbëve të sharrës.
Të dhënat u kopjuan në 4 minuta e 15 sekonda.
Testimi i ndiff-backup
Kandidati i parë është rdiff-backup, një skrip python që ruan një dosje në tjetrën. Në këtë rast, kopja rezervë aktuale ruhet "siç është", dhe kopjet rezervë të bëra më herët ruhen gradualisht në një nëndrejtori të veçantë dhe kështu kursejnë hapësirë.
Ne do të kontrollojmë mënyrën tipike të funksionimit, d.m.th. Nisja e procesit të kopjimit inicohet nga vetë klienti dhe në anën e serverit për kopje rezervë, nis një proces që merr të dhëna.
Le t'i hedhim një sy, për çfarë është i aftë në kushtet tona?.
Koha e funksionimit të çdo testi:
ĐĐ”ŃĐČŃĐč Đ·Đ°ĐżŃŃĐș
Nisja e dytë
Nisja e tretë
Seti i parë
16 m32s
16 m26s
16 m19s
Seti i dytë
2 orë e 5 minuta
2 orë e 10 minuta
2 orë e 8 minuta
Seti i tretë
2 orë e 9 minuta
2 orë e 10 minuta
2 orë e 10 minuta
Rdiff-backup reagon me shumë dhimbje ndaj çdo ndryshimi të madh të të dhënave, dhe gjithashtu nuk e përdor plotësisht rrjetin.
testimi rsnapshot
Kandidati i dytë, rsnapshot, është një skrip Perl, kërkesa kryesore e të cilit për funksionim efektiv është mbështetja për lidhjet e forta. Kjo kursen hapësirën në disk. Në këtë rast, skedarët që nuk kanë ndryshuar që nga rezervimi i mëparshëm do të lidhen me skedarin origjinal duke përdorur lidhje të forta.
Logjika e procesit të rezervimit është gjithashtu e përmbysur: serveri "ecën" në mënyrë aktive midis klientëve të tij dhe merr të dhëna.
Rezultatet e provës
rezultoi e mëposhtme
ĐĐ”ŃĐČŃĐč Đ·Đ°ĐżŃŃĐș
Nisja e dytë
Nisja e tretë
Seti i parë
4 m22s
4 m19s
4 m16s
Seti i dytë
2 m6s
2 m10s
2 m6s
Seti i tretë
1 m18s
1 m10s
1 m10s
Ai funksionoi shumë, shumë shpejt, shumë më shpejt se rdiff-backup dhe shumë afër rsync-ut të pastër.
Testimi i gromësirës
Një opsion tjetër është një implementim C në krye të librsync - burp, i cili ka një arkitekturë klient-server duke përfshirë autorizimin e klientit, si dhe një ndërfaqe në internet (nuk përfshihet në paketën bazë). Një tjetër veçori interesante janë kopjet rezervë jo-rikuperuese nga ana e klientit.
Le të hedhim një vështrimperformanca.
ĐĐ”ŃĐČŃĐč Đ·Đ°ĐżŃŃĐș
Nisja e dytë
Nisja e tretë
Seti i parë
11 m21s
11 m10s
10 m56s
Seti i dytë
5 m37s
5 m40s
5 m35s
Seti i tretë
3 m33s
3 m24s
3 m40s
Ajo funksionoi 2 herë më ngadalë se rsnapshot, por gjithsesi mjaft shpejt dhe sigurisht më shpejt se rdiff-backup. Grafikët janë pak me sharrë - performanca përsëri varet nga nënsistemi i diskut të serverit të ruajtjes rezervë, megjithëse kjo nuk është aq e theksuar sa me rsnapshot.
Gjetjet
Madhësia e depove për të gjithë kandidatët ishte afërsisht e njëjtë, d.m.th., së pari ato u rritën në 10 GB, pastaj u rritën në 15 GB, pastaj u rritën në 18 GB, etj., gjë që është për shkak të veçantisë se si funksionon rsync. Vlen gjithashtu të përmendet se të gjithë kandidatët janë me një fije të vetme (ngarkesa e procesorit është rreth 50% në një makinë me dy bërthama). Të 3 kandidatët dhanë mundësinë për të rivendosur rezervën e fundit "siç është", domethënë, ishte e mundur të rivendoseshin skedarët pa përdorur ndonjë program të palëve të treta, përfshirë ato të përdorura për krijimin e depove. Kjo është gjithashtu "trashëgimia stërgjyshore" e rsync.
Gjetjet
Sa më kompleks të jetë sistemi rezervë dhe sa më shumë aftësi të ndryshme të ketë, aq më i ngadalshëm do të funksionojë, por për projekte jo shumë kërkuese ndonjëri prej tyre do të jetë i përshtatshëm, përveç, ndoshta, rdiff-backup.
Shpallje
Ky shënim vazhdon ciklin e rezervimit
Rezervimi Pjesa 2: Rishikimi dhe testimi i mjeteve rezervë të bazuara në rsync
Rezervimi Pjesa 3: Rishikimi dhe testimi i dyfishimit, dyfishimit, deja dup
Rezervimi Pjesa 4: Rishikimi dhe testimi i zbackup, restic, borgbackup
Rezervimi Pjesa 5: Testimi i kopjes rezervë të bakulës dhe veeam për linux
Rezervimi Pjesa 6: Krahasimi i mjeteve rezervë
Pjesa rezervë 7: Përfundime
Autor i botimit: Pavel Demkovich
Burimi: www.habr.com
