Najlepsza kompresja dla ZFS send / recv

Wysyłam przyrostowe migawki ZFS przez linię T1 point-to-point i jesteśmy w punkcie, w którym dzienne migawki ledwo zdążą przejść przez drut przed rozpoczęciem kolejnej kopii zapasowej. Nasza komenda send / recv to:

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | bzip2 -c | \
ssh offsite-backup "bzcat | zfs recv -F tank/vm"

Mam dużo cykli procesora do stracenia. Czy istnieje lepszy algorytm kompresji lub alternatywna metoda, której można użyć, aby przesłać mniej danych przez linię?

Wygląda na to, że wypróbowałeś wszystkie najlepsze mechanizmy kompresji i wciąż jesteś ograniczony przez prędkość linii. Zakładając, że szybsze uruchamianie linii nie wchodzi w rachubę, czy zastanawiałeś się nad rzadszym uruchamianiem kopii zapasowych, aby mieć więcej czasu na uruchomienie?

Poza tym, czy istnieje jakiś sposób na zmniejszenie ilości zapisywanych danych? Bez znajomości stosu aplikacji trudno jest powiedzieć, jak to zrobić, ale pomocne może być po prostu upewnienie się, że aplikacje zastępują istniejące pliki zamiast tworzenia nowych. I upewnij się, że nie zapisujesz kopii zapasowych plików temp / cache, których nie potrzebujesz.

Oto, czego się nauczyłem, robiąc dokładnie to samo, co robisz. Sugeruję użycie mbuffera. Podczas testowania w moim środowisku pomogło to tylko po stronie odbierającej, bez niego wysyłanie spowolniłoby, podczas gdy odbiór był nadrobiony.

Kilka przykładów: http://everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/

Strona główna z opcjami i składnią http://www.maier-komor.de/mbuffer.html

Polecenie send z mojego skryptu replikacji:

zfs send -i tank/pool@oldsnap tank/pool@newsnap | ssh -c arcfour remotehostip "mbuffer -s 128k -m 1G | zfs receive -F tank/pool"

uruchamia to mbuffer na zdalnym hoście jako bufor odbiorczy, więc wysyłanie przebiega tak szybko, jak to możliwe. Uruchomiłem linię 20mbit i stwierdziłem, że mbuffer po stronie wysyłającej również nie pomógł, również moje główne pudełko ZFS używa całego RAM-u jako pamięci podręcznej, więc przekazanie nawet 1 g mbufora wymagałoby ode mnie zmniejszenia niektórych rozmiarów pamięci podręcznej.

Ponadto, i to nie jest naprawdę mój obszar specjalizacji, myślę, że najlepiej po prostu pozwolić kompresji ssh. W twoim przykładzie myślę, że używasz bzip, a następnie ssh, który domyślnie używa kompresji, więc SSH próbuje skompresować skompresowany strumień. Skończyło się na użyciu arcfour jako szyfru, ponieważ jest to procesor najmniej obciążający i to było dla mnie ważne. Możesz mieć lepsze wyniki z innym szyfrem, ale zdecydowanie sugeruję zezwolenie SSH na kompresję (lub wyłączenie kompresji ssh, jeśli naprawdę chcesz użyć czegoś, czego nie obsługuje).

Bardzo interesujące jest to, że użycie mbuffer podczas wysyłania i odbierania na localhost również przyspiesza:

zfs send tank/pool@snapshot | mbuffer -s 128k -m 4G -o - | zfs receive -F tank2/pool

Odkryłem, że 4g dla transferów localhost wydaje mi się być słodkim miejscem. To po prostu pokazuje, że wysyłanie / odbieranie zfs tak naprawdę nie lubi opóźnień ani żadnych innych przerw w strumieniu, aby działać najlepiej.

Tylko moje doświadczenie, mam nadzieję, że to pomaga. Zajęło mi to trochę czasu, żeby to wszystko zrozumieć.

Oto odpowiedź na konkretne pytanie:

Możesz wypróbować rzip , ale działa on nieco inaczej niż kompres / bzip / gzip:

rzip oczekuje, że będzie w stanie odczytać cały plik, więc nie można go uruchomić w potoku. To znacznie zwiększy wymagania dotyczące lokalnej pamięci masowej i nie będziesz w stanie uruchomić kopii zapasowej i wysłać kopii zapasowej przewodowo w jednej rurze. To powiedziawszy, wynikowe pliki, przynajmniej zgodnie z tym testem, są nieco mniejsze.

Jeśli ograniczeniem zasobów jest twoja rura, i tak będziesz tworzyć kopie zapasowe 24x7, więc będziesz musiał po prostu ciągle kopiować migawki i mieć nadzieję, że i tak nadążysz.

Twoim nowym poleceniem byłoby:

remotedir=/big/filesystem/on/remote/machine/
while 
  snaploc=/some/big/filesystem/
  now=$(date +%s)
  snap=snapshot.$now.zfssnap
  test -f $snaploc/$snap
do
  sleep 1
done

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > $snaploc/$snap &&
rzip $snaploc/$snap &&
ssh offsite-backup "
        cat > $remotedir/$snap.rzip && 
        rzip -d $remotedir/$snap.rzip && 
        zfs recv -F tank/vm < $remotedir/$snap &&
        rm $remotedir/$snap " < $snaploc/$snap &&
rm $snaploc/$snap

Będziesz chciał zastosować lepszą korekcję błędów i będziesz chciał rozważyć użycie czegoś takiego jak rsync do przesyłania skompresowanych plików, więc jeśli transfer nie powiedzie się w środku, możesz zacząć od miejsca, w którym przerwałeś.

Od czasu opublikowania tego pytania wiele się zmieniło:

1: ZFS obsługuje teraz skompresowaną replikację, wystarczy dodać flagę -c do polecenia zfs send, a bloki, które zostały skompresowane na dysku, pozostaną skompresowane, gdy będą przechodzić przez potok do drugiego końca. Może być jeszcze więcej kompresji do uzyskania, ponieważ domyślną kompresją w ZFS jest lz4

2: Najlepszym kompresorem do zastosowania w tym przypadku jest ZSTD (ZStandard), teraz ma tryb „adaptacyjny”, który zmieni poziom kompresji (między obsługiwanymi poziomami 19+, a nowymi szybszymi poziomami ZSTD-Fast) na podstawie prędkość łącza między wysyłaniem zfs i recf zfs. Kompresuje jak najwięcej, utrzymując kolejkę danych oczekujących na wyjście z potoku do minimum. Jeśli twój link jest szybki, nie marnuje czasu na bardziej kompresowanie danych, a jeśli twój link jest powolny, będzie pracował, aby bardziej skompresować dane i ostatecznie zaoszczędzić czas. Obsługuje również kompresję wątkową, więc mogę skorzystać z wielu rdzeni, których nie robią gzip i bzip, poza specjalnymi wersjami, takimi jak pigzip.

Zakładam, że po prostu nie możesz zwiększyć przepustowości swojej witryny ...

Możesz nie zauważyć kompresji na hoście.

Jeśli użyjesz czegoś takiego jak optymalizator wan, będzie on w stanie zoptymalizować transfer znacznie lepiej, jeśli nie skompresujesz pliku przed wysłaniem, tj. Zrobisz dokładnie to, co robisz, ale usuniesz bzip2 z potoku. Po kilku cyklach tworzenia kopii zapasowej optymalizator WAN zbuforuje bardzo dużą część rzeczy, które widzi w transferze, i zobaczysz ogromną poprawę prędkości transferu.

Jeśli jesteś na ograniczonej drgnąć, to może być w stanie zobaczyć podobną poprawę za pomocą rsync i rsyncing do nieskompresowanego migawkę, tj:

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > /path/to/snapshotdir/snapshotfile
rsync /path/to/snapshotdir/snapshotfile offsite-backup:/remote/path/to/snapshotfile
ssh offsite-backup 'zfs recv -F tank/vm < /remote/path/to/snapshotfile'

Byłoby to szybsze, ponieważ rsync przenosiłby tylko różnice między wczorajszym snapshotem a dzisiejszym. W zależności od tego, jak działa proces tworzenia migawek, między tymi dwoma może być nadal dużo redundancji, nawet jeśli tak naprawdę nie są wcale tym samym plikiem.

Optymalizator WAN jest zdecydowanie bardziej prawdopodobnym sposobem na rozwiązanie tego problemu (cóż, metro Ethernet jest najbardziej prawdopodobnym sposobem na rozwiązanie tego problemu, ale zostawimy go poza stołem). Rsync to po prostu dzikie ujęcie w ciemności, które warto przetestować (lokalnie; rsync powie ci, ile czasu zaoszczędził na prostej kopii) na danych lokalnych przed wypisaniem dużego czeku na światłowód lub instalację koryta rzeki.

Tyle ile jest warte. Nie zrobiłbym bezpośredniego wysłania kompresować | rozpakować | Odbieranie może prowadzić do problemów na końcu odbierającym, jeśli linia transferu zostanie zatrzaśnięta, a pule będą w trybie offline przez długi czas podczas odbierania. Wysyłamy do lokalnego pliku, następnie gzip migawkę i przesyłamy za pomocą rsync (z korytem rzeki), a następnie otrzymujemy z pliku. Koryto nie optymalizuje ruchu, ALE jeśli występuje problem z transferem i należy go ponownie uruchomić koryto przyspiesza ponowne wysyłanie.

Przyjrzeliśmy się, aby nie kompresować przyrostowej migawki, używając kompresji Rsync i nie używając żadnej kompresji innej niż koryto rzeki. Trudno powiedzieć, która jest najlepsza, ale gdy przesyłamy archiwa dziennika z Oracle z kompresją rsync, szybkość transferu jest około dwa razy większa niż w przypadku zwykłych plików i koryta rzeki (z RSync).

Jeśli masz koryto rzeki, użyj rsync not ssh, ponieważ koryto rozumie rsync i spróbuje go zoptymalizować oraz doda dane do pamięci podręcznej (patrz wyżej, ponowne uruchamianie transferów).

Z mojego doświadczenia wynika, że zfs sendjest dość gwałtowny, mimo że jest znacznie szybszy (średnio) niż następny krok kompresji. Moja kopia zapasowa wstawia znaczne buforowanie po zfs sendi więcej po gzip:

zfs send $SNAP | mbuffer $QUIET -m 100M | gzip | mbuffer -q -m 20M | gpg ... > file

W moim przypadku urządzenie wyjściowe jest podłączone przez USB (nie sieć), ale buforowanie jest ważne z podobnego powodu: Całkowity czas tworzenia kopii zapasowej jest krótszy, gdy dysk USB jest zajęty w 100%. Nie możesz wysłać mniejszej ilości bajtów (na żądanie), ale nadal możesz ukończyć wcześniej. Buforowanie zapobiega zatrzymaniu kroku kompresji związanego z procesorem.

Używam pbzip2 cały czas (równoległy bzip2) podczas wysyłania przez WAN. Ponieważ jest wątkowy, możesz określić liczbę wątków, które będą używane z opcją -p. Najpierw zainstaluj pbzip2 na hostach wysyłających i odbierających, instrukcje instalacji znajdują się na stronie http://compression.ca/pbzip2/ .

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
ssh offsite-backup "pbzip2 -dc | zfs recv -F tank/vm"

Głównym kluczem jest tworzenie migawek w częstych odstępach czasu (~ 10 minut), aby zmniejszyć rozmiar migawki, a następnie wysyłanie każdej migawki. ssh nie wznawia działania ze zepsutego strumienia migawki, więc jeśli masz ogromną migawkę do wysłania, potokuj strumień do pbzip2, a następnie podziel na porcje o rozsądnych rozmiarach, następnie rsync podziel pliki na hosta odbierającego, a następnie potokuj do zfs, aby odzyskać połączone pliki pbzip2.

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
split -b 500M - /somedir/snap-inc-10-to-12.pbzip2--

spowoduje to utworzenie plików o nazwach po 500 MB:

/somedir/snap-inc-10-to-12.pbzip2--aa
/somedir/snap-inc-10-to-12.pbzip2--ab
/somedir/snap-inc-10-to-12.pbzip2--ac
...

rsync do odbierania hosta wiele razy (możesz rsync nawet przed ukończeniem wysyłania zfs lub gdy zobaczysz pełny fragment 500 MB), naciśnij ctrl + c w dowolnym momencie, aby anulować:

while [[ true ]]; do rsync -avP /somedir/snap-inc-10-to-12.pbzip2--* offsite-backup:/somedir ; sleep 1; done;

zfs otrzymują:

cat /somedir/snap-inc-10-to-12.pbzip2--* | pbzip2 -dc | zfs recv -Fv tank/vm

Wspomniany użytkownik: Za ile jest wart. Nie zrobiłbym bezpośredniego wysłania kompresować | rozpakować | Odbieranie może prowadzić do problemów na końcu odbierającym, jeśli linia transferu zostanie zatrzaśnięta, a pule będą w trybie offline przez długi czas podczas odbierania. - Wcześniej miałem problemy ze starszymi wersjami ZFS <28 na hoście odbierającym, jeśli ciągłe wysyłanie / odbieranie jest przerywane przez spadki sieci, ale nie w stopniu, w jakim pule są przesunięte. To interesujące. Ponownie wyślij migawkę tylko wtedy, gdy „zfs recv” zakończyło się na końcu odbierającym. W razie potrzeby zabij ręcznie „zfs recv”. Zfs send / recv jest teraz znacznie ulepszony we FreeBSD lub Linux.

Możesz wybrać szybszy szyfr dla ssh, może blowfish-cbc, spróbuj także przełączników -123456789

-1 (or --fast) to -9 (or -best)

Będziesz musiał przetestować swoje dane. Wystarczy wysłać go do pliku i skompresować za pomocą każdej metody.

Dla nas gzip zrobił ogromną różnicę i przez to wszystko przeszliśmy, ale nie było nawet 1% różnicy między gzip i bzip lub 7z.

Jeśli wolisz T1, musisz zapisać go w pliku i zsynchronizować.

Dla tych (nie ciebie), którzy są nieco bardziej ograniczeni przez procesor niż przepustowość, jak lstvan powiedział, że inny szyfr, taki jak arcfour128, przyspiesza. Używamy tego wewnętrznie podczas przenoszenia rzeczy.

Eksperymentuj z włączaniem deduplikacji dla wysyłania zfs za pomocą -D. Oszczędności zależą oczywiście od tego, ile kopii jest w twoich danych.

„Najlepszy” algorytm kompresji zależy od tego, jaki rodzaj danych posiadasz - jeśli naciskasz kompresję kolekcji MP3, prawdopodobnie spowolni proces, podczas gdy tekst / pliki dziennika mogą być znacznie kompresowane gzip -9.

Ile danych przesyłasz każdego dnia?

Czy zastanawiałeś się nad dostrojeniem stosu TCP / IP, aby bufor i rozmiary okien były nieco większe? możesz użyć nddnarzędzia w systemie Solaris do tego lub sysctlnarzędzia w systemie Linux / BSD / Mac OSX. Solaris, szukasz dla /dev/tcp tcp_max_bufi /dev/tcp tcp_cwnd_maxwartości, a na Linux sysctl, czego szukasz net.ipv4.tcp_mem, net.ipv4.tcp_rmemi net.ipv4.tcp.wmemwartości.

Te linki mogą również stanowić dodatkową pomoc:

Tuning wydajności Solaris TCP

Na dole tej strony znajduje się zestaw linków, które wyjaśnią, jak zrobić to samo w przypadku Linux / BSD / OSX.