Niniejszym notatką kontynuujemy
cykl poświęcony tworzeniu kopii zapasowych
- Kopie zapasowe, część 2: Przegląd i testowanie narzędzi do tworzenia kopii zapasowych opartych na rsync
- Kopie zapasowe, część 3: Przegląd i testowanie duplicity, duplicaty, deja dup
- Kopia zapasowa, część 4: Przegląd i testowanie zbackup, restic, borgbackup
- Kopie zapasowe, część 5: Testowanie bacula i veeam backup for linux
- Kopie zapasowe, część 6: Porównanie narzędzi do tworzenia kopii zapasowych
- Kopie zapasowe, część 7: Wnioski
Jak już pisaliśmy w pierwszym artykule, istnieje wiele programów do tworzenia kopii zapasowych opartych na rsync.
Spośród tych, które najbardziej odpowiadają naszym wymaganiom, rozważę 3: rdiff-backup, rsnapshot i burp.
Zestawy plików testowych
Zestawy plików do testów będą identyczne dla wszystkich kandydatów, w tym również dla przyszłych artykułów.
Pierwszy zestaw: 10 GB plików multimedialnych oraz około 50 MB – kod źródłowy strony w PHP, rozmiary plików od kilku kilobajtów dla kodu źródłowego do dziesiątek megabajtów dla plików multimedialnych. Celem jest symulacja strony z statyką.
Drugi zestaw: pochodzi z pierwszego przez zmianę nazwy podkatalogu z plikami multimedialnymi o wadze 5 GB. Celem jest badanie zachowania systemu kopii zapasowych podczas zmiany nazwy katalogu.
Trzeci zestaw: pochodzi z pierwszego przez usunięcie 3 GB plików multimedialnych i dodanie nowych 3 GB plików multimedialnych. Celem jest badanie zachowania systemu kopii zapasowych podczas typowej operacji aktualizacji strony.
Uzyskiwanie wyników
Każda kopia zapasowa jest wykonywana minimum 3 razy i towarzyszy jej czyszczenie pamięci podręcznej systemu plików poleceniami sync i echo 3 > /proc/sys/vm/drop_caches zarówno po stronie serwera testowego, jak i serwera przechowywania kopii zapasowych.
Na serwerze, który będzie źródłem kopii zapasowych, zainstalowane jest oprogramowanie monitorujące – netdata, za pomocą którego będzie oceniana obciążenie serwera podczas kopiowania, co jest niezbędne do oceny obciążenia serwera procesem tworzenia kopii zapasowej.
Uważam również, że serwer przechowywania kopii zapasowych jest wolniejszy pod względem procesora niż główny serwer, ale ma dyski o większej pojemności z stosunkowo niską prędkością losowego zapisu – najczęstsza sytuacja podczas tworzenia kopii zapasowych, a ponieważ serwer kopii zapasowych w zasadzie nie powinien wykonywać innych zadań poza tworzeniem kopii zapasowych, jego obciążenie z pomocą netdata nie będę monitorować.
Mam również zmienione serwery, na których będę testował różne systemy do tworzenia kopii zapasowych.
Obecnie mają następujące parametryProcesor
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Uruchamianie testu z następującymi opcjami:
Liczba wątków: 2
Inicjowanie generatora liczb losowych na podstawie bieżącego czasu
Limit liczb pierwszych: 20000
Inicjowanie wątków roboczych...
Wątki uruchomione!
Wydajność CPU:
zdarzeń na sekundę: 1081.62
Ogólne statystyki:
całkowity czas: 30.0013s
całkowita liczba zdarzeń: 32453
Opóźnienie (ms):
min: 1.48
avg: 1.85
max: 9.84
95. percentyl: 2.07
suma: 59973.40
Sprawiedliwość wątków:
zdarzenia (avg/stddev): 16226.5000/57.50
czas wykonania (avg/stddev): 29.9867/0.00
Pamięć operacyjna, odczyt…
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)
Uruchamianie testu z następującymi opcjami:
Liczba wątków: 4
Inicjowanie generatora liczb losowych na podstawie bieżącego czasu
Uruchamianie testu wydajności pamięci z następującymi opcjami:
rozmiar bloku: 1KiB
całkowity rozmiar: 102400MiB
operacja: odczyt
zakres: globalny
Inicjowanie wątków roboczych...
Wątki uruchomione!
Łączna liczba operacji: 104857600 (5837637.63 na sekundę)
102400.00 MiB transferowane (5700.82 MiB/sek)
Ogólne statystyki:
całkowity czas: 17.9540s
całkowita liczba zdarzeń: 104857600
Opóźnienie (ms):
min: 0.00
avg: 0.00
max: 66.08
95. percentyl: 0.00
suma: 18544.64
Sprawiedliwość wątków:
zdarzenia (avg/stddev): 26214400.0000/0.00
czas wykonania (avg/stddev): 4.6362/0.12
… i zapis
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)
Uruchamianie testu z następującymi opcjami:
Liczba wątków: 4
Inicjowanie generatora liczb losowych na podstawie bieżącego czasu
Uruchamianie testu wydajności pamięci z następującymi opcjami:
rozmiar bloku: 1KiB
całkowity rozmiar: 102400MiB
operacja: zapis
zakres: globalny
Inicjowanie wątków roboczych...
Wątki uruchomione!
Łączna liczba operacji: 91414596 (3046752.56 na sekundę)
89272.07 MiB transferowane (2975.34 MiB/sek)
Ogólne statystyki:
całkowity czas: 30.0019s
całkowita liczba zdarzeń: 91414596
Opóźnienie (ms):
min: 0.00
avg: 0.00
max: 1022.90
95. percentyl: 0.00
suma: 66430.91
Sprawiedliwość wątków:
zdarzenia (avg/stddev): 22853649.0000/945488.53
czas wykonania (avg/stddev): 16.6077/1.76
Dysk na serwerze źródłowym danych
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)
Uruchamianie testu z następującymi opcjami:
Liczba wątków: 4
Inicjalizacja generatora liczb losowych z bieżącego czasu
Dodatkowe flagi otwierania plików: (brak)
128 plików, po 8MiB każdy
Łączny rozmiar pliku: 1GiB
Rozmiar bloku: 4KiB
Liczba żądań IO: 0
Stosunek odczytów do zapisów w przypadku kombinowanego testu IO losowego: 1.50
Okresowy FSYNC włączony, wywołując fsync() co 100 żądań.
Wywoływanie fsync() na koniec testu, włączone.
Używanie trybu IO synchronicznego
Wykonywanie losowego testu r/w
Inicjalizacja wątków roboczych...
Wątki uruchomione!
Operacje na plikach:
odczyty/s: 4587.95
zapisy/s: 3058.66
fsyncs/s: 9795.73
Przepustowość:
odczyt, MiB/s: 17.92
zapisany, MiB/s: 11.95
Statystyki ogólne:
całkowity czas: 60.0241s
całkowita liczba zdarzeń: 1046492
Opóźnienie (ms):
min: 0.00
avg: 0.23
max: 14.45
95. percentyl: 0.94
suma: 238629.34
Sprawiedliwość wątków:
zdarzenia (avg/stddev): 261623.0000/1849.14
czas wykonywania (avg/stddev): 59.6573/0.00
Dysk na serwerze przechowywania kopii zapasowych
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)
Uruchamianie testu z następującymi opcjami:
Liczba wątków: 4
Inicjalizacja generatora liczb losowych z bieżącego czasu
Dodatkowe flagi otwierania plików: (brak)
128 plików, po 8MiB każdy
Łączny rozmiar pliku: 1GiB
Rozmiar bloku: 4KiB
Liczba żądań IO: 0
Stosunek odczytów do zapisów w przypadku kombinowanego testu IO losowego: 1.50
Okresowy FSYNC włączony, wywołując fsync() co 100 żądań.
Wywoływanie fsync() na koniec testu, włączone.
Używanie trybu IO synchronicznego
Wykonywanie losowego testu r/w
Inicjalizacja wątków roboczych...
Wątki uruchomione!
Operacje na plikach:
odczyty/s: 11.37
zapisy/s: 7.58
fsyncs/s: 29.99
Przepustowość:
odczyt, MiB/s: 0.04
zapisany, MiB/s: 0.03
Statystyki ogólne:
całkowity czas: 73.8868s
całkowita liczba zdarzeń: 3104
Opóźnienie (ms):
min: 0.00
avg: 78.57
max: 3840.90
95. percentyl: 297.92
suma: 243886.02
Sprawiedliwość wątków:
zdarzenia (avg/stddev): 776.0000/133.26
czas wykonywania (avg/stddev): 60.9715/1.59
Prędkość sieci między serwerami
iperf3 -c backup
Łączenie z hostem backup, port 5201
[ 4] lokalny x.x.x.x port 59402 połączony z y.y.y.y port 5201
[ ID] Interwał Transfer Szerokość pasma Retr Cwnd
[ 4] 0.00-1.00 sek 419 MBytes 3.52 Gbit/s 810 182 KBytes
[ 4] 1.00-2.00 sek 393 MBytes 3.30 Gbit/s 810 228 KBytes
[ 4] 2.00-3.00 sek 378 MBytes 3.17 Gbit/s 810 197 KBytes
[ 4] 3.00-4.00 sek 380 MBytes 3.19 Gbit/s 855 198 KBytes
[ 4] 4.00-5.00 sek 375 MBytes 3.15 Gbit/s 810 182 KBytes
[ 4] 5.00-6.00 sek 379 MBytes 3.17 Gbit/s 765 228 KBytes
[ 4] 6.00-7.00 sek 376 MBytes 3.15 Gbit/s 810 180 KBytes
[ 4] 7.00-8.00 sek 379 MBytes 3.18 Gbit/s 765 253 KBytes
[ 4] 8.00-9.00 sek 380 MBytes 3.19 Gbit/s 810 239 KBytes
[ 4] 9.00-10.00 sek 411 MBytes 3.44 Gbit/s 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interwał Transfer Szerokość pasma Retr
[ 4] 0.00-10.00 sek 3.78 GBytes 3.25 Gbit/s 8100 nadawca
[ 4] 0.00-10.00 sek 3.78 GBytes 3.25 Gbit/s odbiorca
Metodyka testowania
- Na serwerze testowym przygotowywany jest system plików z pierwszym zestawem testowym, a w serwerze przechowywania kopii zapasowych inicjowany jest repozytorium, jeśli zajdzie taka potrzeba.
Rozpoczynany jest proces tworzenia kopii zapasowych i mierzony jest jego czas. - Na serwerze testowym przeprowadzana jest migracja plików do drugiego zestawu testowego. Rozpoczynany jest proces tworzenia kopii zapasowych i mierzony jest jego czas.
- Na serwerze testowym przeprowadzana jest migracja do trzeciego zestawu testowego. Rozpoczynany jest proces tworzenia kopii zapasowych i mierzony jest jego czas.
- Otrzymany trzeci zestaw testowy przyjmowany jest jako nowy pierwszy; punkty 1-3 powtarzane są jeszcze 2 razy.
- Dane są wprowadzane do tabeli podsumowującej, dodawane są wykresy z netdata.
- Tworzony jest raport dotyczący osobnej metody tworzenia kopii zapasowych.
Oczekiwane wyniki
Ponieważ wszyscy 3 kandydaci opierają się na tej samej technologii (rsync), oczekuje się, że wyniki będą zbliżone do zwykłego rsync, w tym wszystkie jego zalety, a mianowicie:
- Pliki w repozytorium będą przechowywane "tak jak są".
- Rozmiar repozytorium będzie rósł tylko o różnicę między kopiami zapasowymi.
- Będzie stosunkowo duże obciążenie sieci podczas przesyłania danych, a także niewielkie obciążenie procesora.
Test próbny zwykłego rsync będzie stosowany jako punkt odniesienia, jego wyniki
są następujące
Wąskim gardłem był serwer przechowywania danych w postaci dysku HDD, co jasno widać na wykresach w formie zębatki.
Dane zostały skopiowane w ciągu 4 minut i 15 sekund.
Testowanie rdiff-backup
Pierwszym kandydatem jest rdiff-backup, skrypt w Pythonie, który wykonuje kopię zapasową jednego katalogu w innym. W tym przypadku aktualna kopia zapasowa jest przechowywana „tak jak jest”, a wcześniejsze kopie zapasowe są zbierane w specjalnym podkatalogu inkrementalnie, dzięki czemu oszczędza się miejsce.
Będziemy sprawdzać typowy tryb działania, tzn. uruchomienie procesu tworzenia kopii zapasowej inicjuje samodzielnie klient, a po stronie serwera uruchamiany jest proces, który przyjmuje dane.
Zobaczmy, na co go stać w naszych warunkach.
Czas pracy każdego testu:
Pierwsze uruchomienie
Drugie uruchomienie
Trzecie uruchomienie
Pierwszy zestaw
16m32s
16m26s
16m19s
Drugi zestaw
2h5m
2h10m
2h8m
Trzeci zestaw
2h9m
2h10m
2h10m
Rdiff-backup dość bolesne reaguje na każde większe zmiany danych, także nie do końca wykorzystuje sieć.
Testowanie rsnapshot
Drugim kandydatem jest rsnapshot, który jest skryptem w Perlu, którego głównym wymaganiem do efektywnej pracy jest wsparcie dla twardych linków. W ten sposób oszczędza się miejsce na dysku. Przy tym pliki, które nie zmieniły się od poprzedniej kopii zapasowej, będą odnosić się do oryginalnego pliku za pomocą twardych linków.
Logika procesu tworzenia kopii zapasowej została również zainwertowana: serwer aktywnie „chodzi” do swoich klientów i zbiera dane.
Wyniki testowania
uzyskano następujące
Pierwsze uruchomienie
Drugie uruchomienie
Trzecie uruchomienie
Pierwszy zestaw
4m22s
4m19s
4m16s
Drugi zestaw
2m6s
2m10s
2m6s
Trzeci zestaw
1m18s
Działał bardzo szybko, znacznie szybciej niż rdiff-backup i bardzo blisko czystego rsync.
Działał bardzo szybko, znacznie szybciej niż rdiff-backup i bardzo blisko czystego rsync.
Testowanie burp
Kolejną opcją jest implementacja w C na bazie librsync — burp, która ma architekturę klient-serwer, w tym autoryzację klientów, a także dostępność interfejsu webowego (nie wchodzi w skład dostawy podstawowej). Jeszcze jedną interesującą cechą jest kopia zapasowa bez prawa do przywrócenia u klientów.
Zobaczmy na
11m21swydajność.
Pierwsze uruchomienie
Drugie uruchomienie
Trzecie uruchomienie
Pierwszy zestaw
11m10s
10m56s
5m37s
Drugi zestaw
3m33s
5m40s
5m35s
Trzeci zestaw
3m24s
3m40s
Działał dwukrotnie wolniej niż rsnapshot, jednak też wystarczająco szybko, a na pewno szybciej niż rdiff-backup. Wykresy są nieco ząbkowane — wydajność znowu napotyka na system dyskowy serwera przechowywania kopii zapasowych, chociaż nie jest to tak wyraźne jak w przypadku rsnapshot.
Działał dwa razy wolniej niż rsnapshot, ale wciąż wystarczająco szybko, a na pewno szybciej niż rdiff-backup. Wykresy są nieco ząbkowane — wydajność znowu ogranicza się do systemu dyskowego serwera przechowywania kopii zapasowych, chociaż nie jest to tak wyraźne jak w przypadku rsnapshot.
Wyniki
Rozmiar repozytoriów wszystkich kandydatów był mniej więcej taki sam, tzn. najpierw wzrost do 10 GB, potem wzrost do 15 GB, następnie wzrost do 18 GB itd., co jest związane z cechami działania rsync. Warto także zwrócić uwagę na jednowątkowość wszystkich kandydatów (obciążenie procesora wynosi około 50% przy dwurdzeniowej maszynie). Wszyscy trzej kandydaci oferowali możliwość przywrócenia ostatniej kopii zapasowej „jak jest”, co oznacza, że można było przywracać pliki bez korzystania z jakichkolwiek zewnętrznych programów, w tym tych, które były używane do tworzenia repozytoriów. To także „dziedzictwo” rsync.
Wnioski
Im bardziej skomplikowany system kopii zapasowych i im więcej ma różnych możliwości – tym wolniej będzie działać, ale dla mniej wymagających projektów będzie odpowiedni każdy z nich, z wyjątkiem być może rdiff-backup.
Ogłoszenie
Niniejsza notatka kontynuuje cykl dotyczący kopii zapasowych.
Kopie zapasowe, część 2: Przegląd i testowanie narzędzi do tworzenia kopii zapasowych opartych na rsync
Kopie zapasowe, część 3: Przegląd i testowanie duplicity, duplicaty, deja dup
Kopia zapasowa, część 4: Przegląd i testowanie zbackup, restic, borgbackup
Kopie zapasowe, część 5: Testowanie bacula i veeam backup for linux
Kopie zapasowe, część 6: Porównanie narzędzi do tworzenia kopii zapasowych
Kopie zapasowe, część 7: Wnioski
Autor publikacji: Paweł Demkowicz
Źródło: habr.com
