ZFS Sync przez niewiarygodną, ​​wolną sieć WAN. Replikacja ZFS, czy rsync?

10

Zadanie polegało na tworzeniu kopii zapasowej poza witryną za pośrednictwem sieci WAN. Oba urządzenia do przechowywania to urządzenia NAS oparte na FreeBSD z systemem ZFS.

Raz lub dwa razy w tygodniu 15-60 koncertów danych fotograficznych zostaje zrzuconych na biurowy serwer NAS. Moim zadaniem jest dowiedzieć się, jak uzyskać te dane poza witryną tak niezawodnie, jak to możliwe, korzystając z połączenia BARDZO WOLNEGO DSL (przesyłanie ~ 700 Kb / s). Skrzynka odbiorcza jest w znacznie lepszym stanie, z prędkością 30 Mb / s w dół, 5 Mb / s w górę.

Wiem, że przenoszenie dysku twardego poza witrynę znacznie przyspieszy przenoszenie danych, ale w tym przypadku nie jest to możliwe.

Moje opcje wydają się albo:

  • Przyrostowe wysyłanie ZFS przez ssh
  • Rsync

rsync to uświęcone czasowo rozwiązanie, które ma niezwykle ważną możliwość wznowienia wysyłania, jeśli coś zostanie przerwane. Wadą jest iteracja wielu plików i brak wiedzy na temat deduplikacji.

Wysyłanie migawek ZFS może przesyłać nieco mniej danych (wie dużo więcej o systemie plików, może wykonać deduplikację, może spakować zmiany metadanych bardziej efektywnie niż rsync) i ma tę zaletę, że poprawnie powiela stan systemu plików, a nie tylko kopiuje pliki osobno (co wymaga więcej miejsca na dysku).

Niepokoi mnie wydajność replikacji ZFS [1] (choć ten artykuł ma już rok). Niepokoi mnie również możliwość wznowienia transferu, jeśli coś się nie powiedzie - wydaje się, że funkcja migawki tego nie obejmuje. Cały system musi być całkowicie bezobsługowy.

[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html

Korzystając z którejkolwiek z opcji, powinienem móc zmienić priorytet ruchu, kierując go przez określony port, a następnie używając QOS na routerach. Podczas każdego transferu muszę unikać poważnego negatywnego wpływu na użytkowników w obu witrynach, ponieważ zajmie to kilka dni.

Więc ... tak myślę w tej sprawie. Czy przegapiłem jakieś dobre opcje? Czy ktoś jeszcze ustawił coś podobnego?

backup freebsd rsync zfs wide-area-network Paul McMillan
źródło
Rozważ Unisona .
sampablokuper

Odpowiedzi:

8

  1. Jeśli możesz przesłać maksymalnie 6 GB dziennie (przy założeniu zerowego obciążenia i zerowego ruchu konkurencyjnego) i musisz przenosić „15–60 koncertów” z częstotliwością „raz lub dwa razy w tygodniu”, co daje wynik 15–120 GB na tydzień lub w dowolnym miejscu od 2-17 GB na dzień. Ponieważ konieczne jest zaplanowanie maksymalnego zapotrzebowania, a 17 GB znacznie przewyższa nawet teoretyczne maksimum 6 GB, prawdopodobnie masz bardzo poważny problem z przepustowością. Co trzeba zrobić, aby zaktualizować połączenie? Jeśli aktualizacja połączenia jest niemożliwa, rozważ opcję wysyłania fizycznych nośników zgodnie z harmonogramem (np. Co tydzień).

  2. Zakładając, że matematyka przepustowości może być nieco bardziej sensowna, rsync będzie prawdopodobnie najlepszą opcją. Świadomość deduplikacji byłaby niezwykle cenna przy replikacji wysoce redundantnych danych (np. Obrazów maszyn wirtualnych), ale nie powinna przynosić żadnych korzyści, jeśli chodzi o unikalne treści cyfrowe (audio, wideo, zdjęcia) ... chyba że użytkownicy są oczywiście niezamierzone przechowywanie duplikatów kopii identycznych plików.

Podniebny Jastrząb
źródło
Myślę, że mogę wykorzystać dostępną przepustowość, a większość zrzutów danych zmierza w kierunku mniejszego końca zakresu. Praktycznie będzie to średnio około 2-3 koncertów dziennie, sądząc z danych z ostatniego miesiąca. Nie potrzebuję replikacji natychmiast.
Paul McMillan,
I tak, przesyłanie mediów fizycznych jest znacznie lepsze ... Chciałbym, żeby to była opcja.
Paul McMillan,
Dobra uwaga na temat dedupcji. Większość tego, co zostanie skopiowane, nie zostanie powielona - użytkownicy nie są aż tak gęsi.
Paul McMillan,
1
Jedyne, co chciałbym dodać, to może nie używać rsync. Ja również doświadczyłem powolności rsync, ponieważ używałem go jako procesu przesyłania, a nie procesu synchronizacji. Potem zdałem sobie sprawę, że większość moich istniejących danych nie uległa zmianie i tylko nowe dane musiały zostać skopiowane, dla mnie użyłem cp tylko na nowych plikach i było to znacznie szybsze. Gdybym miał pliki, które się zmieniły (lub tylko ich części), użyłbym rsync. Sugeruję więc oddzielenie nowych plików i wybranie wznawiającej metody przesyłania. Ponadto kompresja byłaby kompromisem między procesorem a pamięcią RAM / przepustowością (na obu końcach).
Scott McClenning, 10.10
Hmm ... Przeczytałem, że przy odpowiedniej konfiguracji rsync może działać stosunkowo szybko. Ile próbowałeś optymalizacji?
Paul McMillan,
13

Po przeprowadzeniu badań uważam, że masz rację co do wysyłania migawek. ZFS SENDi RECEIVEpolecenia mogą być przesyłane do bzip2, a następnie plik ten może być rsynchronizowany na innym komputerze.

Oto niektóre źródła, z których korzystałem:

Nie znalazłem żadnych postów z opublikowanymi skryptami replikacji, ale znalazłem kogoś, kto opublikowałby swój skrypt kopii zapasowej . To powiedziawszy, nie zrozumiałem, więc może to być śmieci.

Wiele stron mówiło o ustawianiu zadania CRON, aby często to robić. W takim przypadku można dokonać replikacji / tworzenia kopii zapasowych przy mniejszym wpływie na przepustowość i użytkowników oraz być dobrą funkcją odzyskiwania po awarii, ponieważ dane poza siedzibą są bardziej aktualne. (To znaczy po początkowym fragmencie danych na początku).

Ponownie myślę, że miałeś dobry pomysł wysyłania migawek, wydaje się, że korzystanie z SEND/ ma wiele zalet RECEIVE.

EDIT: Właśnie oglądałem VIDEO1 VIDEO2 które mogą pomaga suports wykorzystanie SEND/ RECEIVEi mówi o rsync (zaczyna się od 3m49s). Mówcą był Ben Rockwood, a tutaj jest link do jego bloga .

Scott McClenning
źródło
1
Wydaje mi się, że użycie rsync ogranicza się do funkcji pauzy / wznowienia, a nie do faktycznego różnicowania plików. Ma to sens, ponieważ sam system plików (i generowane przez niego pliki zmian) wiedzą lepiej niż rsync o tym, co się dzieje.
Paul McMillan,
Jako dodatkowa uwaga: ZSTD, nowoczesny szybszy zamiennik gzip i bzip, obsługuje wiele wątków i ponad 20 poziomów kompresji. Posiada również opcjonalną funkcję zwaną „kompresją adaptacyjną”. W tym trybie poziom kompresji jest automatycznie dostrajany w górę i w dół, zgodnie z potrzebami, aby utrzymać pełny poziom potoku sieciowego, jednocześnie wykonując jak najwięcej kompresji, aby zaoszczędzić czas. Zapobiega to tak dużej kompresji, że staje się wąskim gardłem lub utratą kompresji, którą możesz wykonać, ponieważ sieć jest zbyt wolna.
Allan Jude,
2

Do czego służą kopie zapasowe i jak będą dostępne?

Jeśli kopie zapasowe służą głównie do odzyskiwania po awarii, preferowane mogą być migawki ZFS, ponieważ system plików można przywrócić do stanu, w jakim znajdował się w momencie ostatniego przyrostu.

Jeśli jednak kopie zapasowe mają również zapewniać użytkownikom dostęp do plików, które mogły zostać przypadkowo usunięte, uszkodzone itp., Lepszym rozwiązaniem może być rsync. Użytkownicy końcowi mogą nie rozumieć koncepcji migawek lub być może Twój serwer NAS nie zapewnia użytkownikom końcowym dostępu do poprzednich migawek. W obu przypadkach możesz użyć rsync, aby zapewnić kopię zapasową, która jest łatwo dostępna dla użytkownika za pośrednictwem systemu plików.

Za pomocą rsync możesz użyć flagi --backup, aby zachować kopie zapasowe plików, które zostały zmienione, a flagą --suffix możesz kontrolować, jak zmieniane są nazwy starych wersji plików. Ułatwia to tworzenie kopii zapasowej, w której można było datować stare wersje plików, takie jak

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

Możesz łatwo połączyć to z cronjobem zawierającym polecenie find, aby w razie potrzeby wyczyścić wszystkie stare pliki.

Oba rozwiązania powinny być w stanie zachować wystarczającą liczbę metainformacji o plikach, aby mogły działać jako kopie zapasowe (rsync zapewnia flagi --perms, --owner itp.). Używam rsync do tworzenia kopii zapasowych dużych ilości danych między centrami danych i jestem bardzo zadowolony z instalacji.

Deutsch
źródło
2

ZFS powinien otrzymać funkcję „wznawiania wysyłania”, która pozwoli kontynuować przerywaną replikację około marca tego roku. Ta funkcja została ukończona przez Matta Ahrensa i kilka innych osób i wkrótce powinna zostać udostępniona.

Allan Jude
źródło
Tylko uwaga, że ​​„wznawianie wysyłania” jest już od dłuższego czasu w OpenZFS (na FreeBSD, Linux, MacOS itp.). Teraz dostępna jest również funkcja „skompresowanego wysyłania”, w której dane pozostaną skompresowane tak, jak na dysku, jako część strumienia replikacji.
Allan Jude,
0

Może urządzenie kompresujące WAN byłoby rozwiązaniem ...? korzystamy z Riverbed i jesteśmy z nich całkiem zadowoleni (np. NetApp SnapMirror jest bardzo dobrze skompresowany, do 80-90%)

toffitomek
źródło