jak jednokierunkowo wykonać kopię lustrzaną całej puli ZFS do innej puli ZFS

Mam jedną pulę ZFS zawierającą kilka zvoli i zestawów danych, z których niektóre są również zagnieżdżone. Wszystkie zestawy danych i wartości Zvols są okresowo migawkowane przez zfs-auto-snapshot. Wszystkie zestawy danych i wartości Zvols mają również ręcznie utworzone migawki.

Skonfigurowałem zdalną pulę, na której z powodu braku czasu wstępne kopiowanie przez lokalną szybką sieć za pośrednictwem Zfs send -R nie zostało zakończone (niektórych zestawów danych brakuje, niektóre zestawy danych są przestarzałe lub brakuje migawek).

Teraz pula jest fizycznie zdalna przez połączenie o niskiej prędkości i muszę okresowo synchronizować pulę zdalną z pulą lokalną, co oznacza, że ​​dane obecne w puli lokalnej muszą zostać skopiowane do puli zdalnej, dane usunięte z puli lokalnej muszą zostać usunięte z puli zdalnej, a dane obecne w puli zdalnej, ale nie w puli lokalnej, należy usunąć z puli zdalnej, używając danych oznaczających „zvols”, „zestawy danych” lub „migawki”.

Gdybym robił to między dwoma zwykłymi systemami plików za pomocą rsync, byłoby to „-axPHAX --delete” (tak właśnie robię, aby wykonać kopię zapasową niektórych systemów).

Jak skonfigurować zadanie synchronizacji, aby zvols i zestawy danych puli zdalnej (w tym ich migawki) mogły być zsynchronizowane z lokalnymi zvols, zestawami danych i migawkami?

Chciałbym uniknąć przesyłania przez ssh, ze względu na niską przepustowość ssh; Wolałbym zamiast tego mbuffer lub iscsi.

Oświadczenie: Ponieważ nigdy nie korzystałem z Zvols, nie mogę powiedzieć, czy różnią się one w replikacji od zwykłych systemów plików lub migawek. Zakładam, że tak, ale nie wierz mi na słowo.

Twoje pytanie to tak naprawdę wiele pytań, staram się na nie odpowiadać osobno:

Jak replikować / utworzyć kopię lustrzaną kompletnej puli w lokalizacji zdalnej

Musisz podzielić zadanie na dwie części: po pierwsze, początkowa replikacja musi być kompletna, następnie możliwa jest replikacja przyrostowa, o ile nie zadzierasz z migawkami replikacji . Aby włączyć przyrostową replikację, musisz zachować ostatnie migawki replikacji, wszystko przed tym można usunąć. Jeśli usuniesz poprzednią migawkę, zfs recvnarzeka i przerywa replikację. W takim przypadku musisz zacząć wszystko od nowa, więc staraj się tego nie robić.

Jeśli potrzebujesz tylko odpowiednich opcji, są to:

• zfs send:
  • -R: wyślij wszystko w ramach danej puli lub zestawu danych (replikacja rekurencyjna, potrzebna cały czas, obejmuje -p). Ponadto podczas odbierania wszystkie usunięte migawki źródłowe są usuwane w miejscu docelowym.
  • -I: uwzględnij wszystkie migawki pośrednie między ostatnią migawką replikacji a bieżącą migawką replikacji (potrzebne tylko przy wysyłkach przyrostowych)
• zfs recv:
  • -F: rozwiń pulę docelową, w tym usunięcie istniejących zestawów danych, które są usuwane w źródle
  • -d: odrzuć nazwę puli źródłowej i zastąp ją nazwą docelowej puli (pozostałe ścieżki systemu plików zostaną zachowane, aw razie potrzeby również utworzone)
  • -u: nie montuj systemu plików na miejscu docelowym

Jeśli wolisz pełny przykład, oto mały skrypt:

#!/bin/sh

# Setup/variables:

# Each snapshot name must be unique, timestamp is a good choice.
# You can also use Solaris date, but I don't know the correct syntax.
snapshot_string=DO_NOT_DELETE_remote_replication_
timestamp=$(/usr/gnu/bin/date '+%Y%m%d%H%M%S')
source_pool=tank
destination_pool=tank
new_snap="$source_pool"@"$snapshot_string""$timestamp"
destination_host=remotehostname

# Initial send:

# Create first recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Initial replication via SSH.
zfs send -R "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"

# Incremental sends:

# Get old snapshot name.
old_snap=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$source_pool"@"$snapshot_string" | tail --lines=1)
# Create new recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Incremental replication via SSH.
zfs send -R -I "$old_snap" "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Delete older snaps on the local source (grep -v inverts the selection)
delete_from=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$snapshot_string" | grep -v "$timestamp")
for snap in $delete_from; do
    zfs destroy "$snap"
done

Użyj czegoś szybciej niż SSH

Jeśli masz wystarczająco zabezpieczone połączenie, na przykład tunel IPSec lub OpenVPN i oddzielną sieć VLAN, która istnieje tylko między nadawcą a odbiorcą, możesz przełączyć się z SSH na nieszyfrowane alternatywy, takie jak mbuffer, jak opisano tutaj , lub możesz użyć SSH ze słabym / brakiem szyfrowania i wyłączono kompresję, która jest szczegółowo opisana tutaj . Była też strona internetowa na temat ponownego przeliczania SSH, aby była znacznie szybsza, ale niestety nie pamiętam adresu URL - zmodyfikuję go później, jeśli go znajdę.

W przypadku bardzo dużych zestawów danych i powolnych połączeń może być również przydatna pierwsza transmisja za pośrednictwem dysku twardego (użyj szyfrowanego dysku do przechowywania zpool i przesłania go w zapieczętowanej paczce za pośrednictwem kuriera, poczty lub osobiście). Ponieważ metoda przesyłania nie ma znaczenia dla wysyłania / odbierania, możesz przesłać wszystko do dysku, wyeksportować pulę, wysłać dysk do miejsca docelowego, zaimportować pulę, a następnie przesłać wszystkie przyrostowe wysyłki za pośrednictwem protokołu SSH.

Problem z pomieszanymi migawkami

Jak wspomniano wcześniej, jeśli usuniesz / zmodyfikujesz migawki replikacji, otrzymasz komunikat o błędzie

cannot send 'pool/fs@name': not an earlier snapshot from the same fs

co oznacza, że ​​twoje polecenie było złe lub jesteś w niespójnym stanie, w którym musisz usunąć migawki i zacząć wszystko od nowa.

Ma to kilka negatywnych implikacji:

1. Nie można usunąć migawki replikacji, dopóki nowa migawka replikacji nie zostanie pomyślnie przesłana. Ponieważ te migawki replikacji obejmują stan wszystkich innych (starszych) migawek, puste miejsce na usuniętych plikach i migawki zostaną odzyskane tylko po zakończeniu replikacji. Może to prowadzić do tymczasowych lub trwałych problemów z miejscem w puli, które można naprawić tylko poprzez ponowne uruchomienie lub zakończenie pełnej procedury replikacji.
2. Będziesz miał wiele dodatkowych migawek, które spowalniają polecenie listy (z wyjątkiem Oracle Solaris 11, gdzie to zostało naprawione).
3. Może być konieczne zabezpieczenie migawek przed (przypadkowym) usunięciem, z wyjątkiem samego skryptu.

Istnieje możliwe rozwiązanie tych problemów, ale sam tego nie próbowałem. Możesz użyć zfs bookmarknowej funkcji w OpenSolaris / illumos stworzonej specjalnie do tego zadania. To uwolniłoby cię od zarządzania migawkami. Jedynym minusem jest to, że obecnie działa tylko dla pojedynczych zestawów danych, a nie rekurencyjnie. Będziesz musiał zapisać listę wszystkich starych i nowych zbiorów danych, a następnie przeglądać je, dodawać do zakładek, wysyłać i odbierać, a następnie aktualizować listę (lub małą bazę danych, jeśli wolisz).

Jeśli spróbujesz trasy z zakładkami, chciałbym usłyszeć, jak Ci się udało!

Osobiście stworzyłbym sobie listę zvoli, zestawów danych itp. Na zdalnym serwerze, które nie mają aktualnych migawek, a następnie zaktualizowałem te migawki zfs send, nawet jeśli jest to czasochłonne i zużywa dużo przepustowości.

Wtedy mógłbym po prostu kontynuować używanie zfs sendod tego momentu i nie musiałbym ponownie wymyślać koła, pisząc własny kod synchronizacji. rsyncjest miły dla starszych systemów plików, ale zfs sendjest znacznie lepszy dla ZFS - wie dokładnie, które bloki zmieniły się w migawce i wysyła tylko je, podczas gdy rsync musi porównywać poszczególne pliki i / lub znaczniki czasu między serwerami lokalnymi i zdalnymi. to samo dotyczy btrfs sendpuli btrfs.

Jeśli masz tylko niewielką liczbę migawek, które wymagają aktualizacji, można to zrobić ręcznie. W przeciwnym razie, aby zrobić to automatycznie, potrzebujesz listy najnowszych lokalnych migawek vs zdalnych migawek oraz skrypt do porównywania wersji, a następnie zfs sendlokalnych migawek, które są nieaktualne na serwerze rmeote.

Wystarczy, jeśli zależy ci tylko na najnowszej migawce dla każdego zestawu danych. Jeśli zależy Ci na wszystkich poprzednich migawkach, oczywiście skrypt również będzie musiał je obsłużyć ... i to staje się o wiele bardziej skomplikowane. W niektórych przypadkach konieczne może być wycofanie na zdalnym serwerze, aby można było ponownie wysłać pośrednie / brakujące migawki.

Jeśli chcesz mieć bezpieczne połączenie ze zdalnym serwerem, naprawdę nie masz innego wyboru, jak tylko użyć ssh- a może skonfigurować tunel z openvpnczymś i użyć netcat.

Rzuć okiem na `zrepl 'na FreeBSD, który może ułatwić Ci życie, a każdy jest o wiele łatwiejszy. Został zaprezentowany kilka dni temu podczas BSDCan2018 w Ottawie. Wygląda obiecująco i może być rozwiązaniem twoich problemów

zrep to fajne rozwiązanie typu „wszystko w jednym” ORAZ posiada dokumentację + informacje o tym, jak uzyskać szybsze transfery niż zwykłe transfery SSH

https://github.com/bolthole/zrep

jest także crosssplatform: obsługiwany w systemach Linux, Freebsd i Solaris / Illumos