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

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?

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.

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:

• Oracle Solaris ZFS Administrator Guide strona 211 (lub wersja internetowa tutaj ) zaczyna mówić o tym.

• Znalazłem również post na blogu, który podał prosty tego przykład. Na tym blogu pokazano również przesyłanie strumienia bitów przez bzip2 i wysyłanie go.

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 .

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.

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.

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%)