Tento článek pokračuje
v seriálu o zálohování
- Zálohování, část 2: Přehled a testování prostředků zálohování založených na rsync
- Zálohování, část 3: Přehled a testování duplicity, duplicaty, deja dup
- Zálohování, část 4: Přehled a testování zbackup, restic, borgbackup
- Zálohování, část 5: Testování Bacula a Veeam Backup pro Linux
- Zálohování, část 6: Srovnání nástrojů pro zálohování
- Zálohování, část 7: Závěry
Jak jsme už psali v prvním článku, existuje poměrně velké množství programů pro zálohování, založených na rsync.
Z těch, které nejlépe vyhovují našim podmínkám, se budu zabývat 3: rdiff-backup, rsnapshot a burp.
Testovací sady souborů
Sady souborů pro testování budou totožné pro všechny uchazeče, včetně budoucích článků.
První sada: 10 GB mediálních souborů a přibližně 50 MB — zdrojový kód webu na php, velikosti souborů od několika kilobajtů pro zdrojový kód až po desítky megabajtů pro mediální soubory. Cíl — simulace statického webu.
Druhá sada: vzniká z první přejmenováním podadresáře s mediálními soubory o velikosti 5 GB. Cíl — zkoumání chování zálohovacího systému při přejmenování adresáře.
Třetí sada: vzniká z první odstraněním 3 GB mediálních souborů a přidáním nových 3 GB mediálních souborů. Cíl — zkoumání chování zálohovacího systému při typické operaci aktualizace webu.
Získávání výsledků
Jakékoli zálohování se provádí minimálně 3krát a je doprovázeno vymazáním mezipaměti souborového systému příkazy sync a echo 3 > /proc/sys/vm/drop_caches jak na straně testovacího serveru, tak na serveru pro ukládání záloh.
Na serveru, který bude zdrojem záloh, je nainstalováno monitorovací software — netdata, pomocí kterého bude hodnoceno zatížení serveru při zálohování, což je potřeba pro posouzení zatížení serveru procesem zálohování.
Také považuji, že server pro ukládání záloh je pomalejší po procesoru než hlavní server, ale má prostornější disky s relativně nízkou rychlostí náhodného zápisu — což je nejčastější situace při zálohování, a protože server pro zálohování by v ideálním případě neměl vykonávat jiné úkoly kromě zálohování, jeho zátěž pomocí netdata sledovat nebudu.
Také jsem změnil servery, na kterých budu testovat různé systémy pro zálohování.
Nyní mají následující vlastnostiProcesor
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Spuštění testu s následujícími možnostmi:
Počet vláken: 2
Inicializace generátoru náhodných čísel z aktuálního času
Limit prvočísel: 20000
Inicializace pracovních vláken...
Vláken bylo spuštěno!
Rychlost CPU:
události za sekundu: 1081.62
Obecné statistiky:
celkový čas: 30.0013s
celkový počet událostí: 32453
Latence (ms):
min: 1.48
průměr: 1.85
max: 9.84
95. percentile: 2.07
součet: 59973.40
Spravedlnost vláken:
události (prům/stddev): 16226.5000/57.50
doba provádění (prům/stddev): 29.9867/0.00
RAM, čtení…
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)
Spuštění testu s následujícími možnostmi:
Počet vláken: 4
Inicializace generátoru náhodných čísel z aktuálního času
Spuštění testu rychlosti paměti s následujícími možnostmi:
velikost bloku: 1KiB
celková velikost: 102400MiB
operace: čtení
rozsah: globální
Inicializace pracovních vláken...
Vláken bylo spuštěno!
Celkový počet operací: 104857600 (5837637.63 za sekundu)
102400.00 MiB přeneseno (5700.82 MiB/sec)
Obecné statistiky:
celkový čas: 17.9540s
celkový počet událostí: 104857600
Latence (ms):
min: 0.00
průměr: 0.00
max: 66.08
95. percentile: 0.00
součet: 18544.64
Spravedlnost vláken:
události (prům/stddev): 26214400.0000/0.00
doba provádění (prům/stddev): 4.6362/0.12
… a zápis
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)
Spuštění testu s následujícími možnostmi:
Počet vláken: 4
Inicializace generátoru náhodných čísel z aktuálního času
Spuštění testu rychlosti paměti s následujícími možnostmi:
velikost bloku: 1KiB
celková velikost: 102400MiB
operace: zápis
rozsah: globální
Inicializace pracovních vláken...
Vláken bylo spuštěno!
Celkový počet operací: 91414596 (3046752.56 za sekundu)
89272.07 MiB přeneseno (2975.34 MiB/sec)
Obecné statistiky:
celkový čas: 30.0019s
celkový počet událostí: 91414596
Latence (ms):
min: 0.00
průměr: 0.00
max: 1022.90
95. percentile: 0.00
součet: 66430.91
Spravedlnost vláken:
události (prům/stddev): 22853649.0000/945488.53
doba provádění (prům/stddev): 16.6077/1.76
Disk na serveru se zdrojem dat
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)
Spuštění testu s následujícími možnostmi:
Počet vláken: 4
Inicializace generátoru náhodných čísel z aktuálního času
Extra příznaky pro otevření souboru: (žádné)
128 souborů, každý o velikosti 8MiB
Celková velikost souboru 1GiB
Velikost bloku 4KiB
Počet IO požadavků: 0
Poměr čtení/zápisu pro kombinovaný náhodný IO test: 1.50
Povolený periodický FSYNC, volání fsync() každých 100 požadavků.
Volání fsync() na konci testu, povoleno.
Používání synchronního I/O režimu
Provádění náhodného r/w testu
Inicializace pracovních vláken...
Vlákna byla spuštěna!
Operace se soubory:
čtení/s: 4587.95
zápisy/s: 3058.66
fsyncs/s: 9795.73
Průchodnost:
čtení, MiB/s: 17.92
zapsáno, MiB/s: 11.95
Obecná statistika:
celkový čas: 60.0241s
celkový počet událostí: 1046492
Zpoždění (ms):
min: 0.00
avg: 0.23
max: 14.45
95. percentil: 0.94
součet: 238629.34
Spravedlnost vláken:
události (průměr/odchylka): 261623.0000/1849.14
doba vykonávání (průměr/odchylka): 59.6573/0.00
Disk na serveru pro ukládání záloh
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)
Spuštění testu s následujícími možnostmi:
Počet vláken: 4
Inicializace generátoru náhodných čísel z aktuálního času
Extra příznaky pro otevření souboru: (žádné)
128 souborů, každý o velikosti 8MiB
Celková velikost souboru 1GiB
Velikost bloku 4KiB
Počet IO požadavků: 0
Poměr čtení/zápisu pro kombinovaný náhodný IO test: 1.50
Povolený periodický FSYNC, volání fsync() každých 100 požadavků.
Volání fsync() na konci testu, povoleno.
Používání synchronního I/O režimu
Provádění náhodného r/w testu
Inicializace pracovních vláken...
Vlákna byla spuštěna!
Operace se soubory:
čtení/s: 11.37
zápisy/s: 7.58
fsyncs/s: 29.99
Průchodnost:
čtení, MiB/s: 0.04
zapsáno, MiB/s: 0.03
Obecná statistika:
celkový čas: 73.8868s
celkový počet událostí: 3104
Zpoždění (ms):
min: 0.00
avg: 78.57
max: 3840.90
95. percentil: 297.92
součet: 243886.02
Spravedlnost vláken:
události (průměr/odchylka): 776.0000/133.26
doba vykonávání (průměr/odchylka): 60.9715/1.59
Rychlost sítě mezi servery
iperf3 -c backup
Připojení k hostiteli backup, port 5201
[ 4] místní x.x.x.x port 59402 připojeno k y.y.y.y port 5201
[ ID] Interval Přenos Šířka pásma 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 Přenos Šířka pásma Retr
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 odesílatel
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec příjemce
Metodika testování
- Na testovacím serveru se připravuje souborový systém s prvním testovacím souborem, na serveru pro ukládání záloh se v případě potřeby inicializuje repozitář.
Spouští se proces zálohování a měří se jeho doba. - Na testovacím serveru probíhá migrace souborů do druhého testovacího souboru. Spouští se proces zálohování a měří se jeho doba.
- Na testovacím serveru probíhá migrace do třetího testovacího souboru. Spouští se proces zálohování a měří se jeho doba.
- Získaný třetí testovací soubor je přijat jako nový první; body 1-3 se opakují ještě dvakrát.
- Data se vkládají do souhrnné tabulky, přidávají se grafy s netdata.
- Vytváří se zpráva pro jednotlivou metodu zálohování.
Očekávané výsledky
Protože všechny 3 kandidáti jsou založeni na stejné technologii (rsync), očekáváme, že výsledky budou blízké obvyklému rsync, včetně všech jeho výhod, a to:
- Soubory v repozitáři budou uchovávány „tak jak jsou“.
- Velikost repozitáře poroste pouze zahrnutím rozdílu mezi zálohami.
- Bude relativně velká zátěž na síť při přenosu dat, stejně jako malá zátěž na procesor.
Testovací běh běžného rsync bude použit jako měřítko, jeho výsledky
jsou následující
Úzké místo bylo na serveru pro ukládání záloh ve formě disku na bázi HDD, což je jasně vidět na grafech v podobě pil.
Data byla zkopírována za 4 minuty a 15 sekund.
Testování rdiff-backup
První kandidát — rdiff-backup, skript v pythonu, který provádí zálohování jednoho adresáře do druhého. Přičemž aktuální záloha se uchovává „tak, jak je“, a zálohy provedené dříve se ukládají do speciální podadresáře inkrementálně, čímž se šetří místo.
Budeme kontrolovat typický režim práce, tj. spuštění procesu zálohování iniciuje klient sám, zatímco na straně serveru se spouští proces pro zálohování, který přijímá data.
Podívejme se, co dokáže v našich podmínkách.
Doba běhu každého testovacího spuštění:
První spuštění
Druhý pokus
Třetí pokus
První sada
16m32s
16m26s
16m19s
Druhá sada
2h5m
2h10m
2h8m
Třetí sada
2h9m
2h10m
2h10m
Rdiff-backup velmi bolestivě reaguje na jakoukoli velkou změnu dat a také plně nevyužívá síť.
Testování rsnapshot
Druhý kandidát — rsnapshot, představuje skript v perlu, hlavní požadavek na jeho efektivní provoz — podpora pevných odkazů. Tím se šetří místo na disku. Přičemž nezměněné od poslední zálohy soubory budou odkazovat na originální soubor pomocí pevných odkazů.
Také byla invertována logika procesu zálohování: server aktivně „chodí“ sám po svých klietech a vyzvedává data.
Výsledky testování
výsledky jsou následující
První spuštění
Druhý pokus
Třetí pokus
První sada
4m22s
4m19s
4m16s
Druhá sada
2m6s
2m10s
2m6s
Třetí sada
1m18s
1m10s
1m10s
Pracoval velmi a velmi rychle, mnohem rychleji než rdiff-backup a velmi blízko čistému rsync.
Testování burp
Další variantou — realizace na C nad librsync — burp, má klient-server architekturu včetně autorizace klientů, a také přítomnost webového rozhraní (není součástí základního balení). Další zajímavou vlastností je zálohování bez práva obnovení pro klienty.
Podívejme se navýkonu.
První spuštění
Druhý pokus
Třetí pokus
První sada
11m21s
11m10s
10m56s
Druhá sada
5m37s
5m40s
5m35s
Třetí sada
3m33s
3m24s
3m40s
Pracoval dvakrát pomaleji než rsnapshot, přesto také dost rychle, a rozhodně rychleji než rdiff-backup. Grafy jsou mírně pilovité — výkonnost se opět odráží v diskovém subsystému serveru pro ukládání záloh, i když to není tak výrazné jako u rsnapshot.
Výsledky
Velikost repozitářů u všech kandidátů byla přibližně stejná, tj. nejprve nárůst na 10 GB, poté nárůst na 15 GB, poté nárůst na 18 GB atd., což souvisí s charakteristikou práce rsync. Také stojí za zmínku, že všichni kandidáti byly jednovláknové (zatížení CPU kolem 50 % na dvoujádrovém stroji). Všichni 3 kandidáti poskytli možnost obnovit poslední zálohu „jak je“, což znamená, že bylo možné obnovit soubory bez použití jakýchkoli externích programů, včetně těch, které byly použity k vytvoření repozitářů. To je také „rodové dědictví“ rsync.
Závěry
Čím složitější je systém zálohování a čím více má různých možností – tím pomaleji bude pracovat, ale pro méně náročné projekty vyhoví každá z nich, kromě možná rdiff-backup.
Oznámení
Tato poznámka navazuje na cyklus o zálohování
Zálohování, část 2: Přehled a testování nástrojů pro zálohování založených na rsync
Zálohování, část 3: Přehled a testování duplicity, duplicaty, deja dup
Zálohování, část 4: Přehled a testování zbackup, restic, borgbackup
Zálohování, část 5: Testování Bacula a Veeam Backup pro Linux
Zálohování, část 6: Srovnání nástrojů pro zálohování
Zálohování, část 7: Závěry
Autor publikace: Pavel Demkovič
Zdroj: habr.com
