ZFS łączy system plików, menedżera woluminów i RAID w jednym stosie przestrzeni dyskowej. Ponieważ StateWarden działa na poziomie bloków i urządzeń, ochrona systemu opartego na ZFS polega na wybraniu właściwego urządzenia blokowego jako źródła kopii zapasowej. Ten artykuł wyjaśnia, co zabezpieczać na hostach ZFS, co zawiera kopia zapasowa ZVOL i których błędów w wyborze unikać.
1. ZVOL a datasety
ZFS udostępnia dwa rodzaje obiektów przestrzeni dyskowej:
- Datasets (zbiory danych) to obiekty na poziomie systemu plików, montowane do drzewa katalogów (na przykład
/tank/home). Zawierają pliki i katalogi i nie mają reprezentacji w postaci urządzenia blokowego. - ZVOL (woluminy ZFS) to urządzenia blokowe tworzone poleceniem
zfs create -V. ZVOL pełni zazwyczaj rolę dysku maszyny wirtualnej, urządzenia macierzystego dla LUN iSCSI albo surowego woluminu dla bazy danych.
W systemie Linux każdy ZVOL pojawia się pod dwiema ścieżkami urządzeń:
/dev/zvol/<pool>/<name>- stabilny, czytelny dla człowieka dowiązanie symboliczne (na przykład/dev/zvol/tank/vm-100)./dev/zd<N>- bazowe urządzenie blokowe jądra (na przykład/dev/zd0).
Przy konfigurowaniu źródeł kopii zapasowych identyfikuj ZVOL po ścieżce /dev/zvol/.... Ścieżka koduje pulę i nazwę woluminu, więc pozostaje stabilna między restartami, podczas gdy numeracja zd może się zmieniać wraz z dodawaniem i usuwaniem urządzeń. W panelu ZVOL pojawiają się na liście woluminów w zakładce Dyski i kopie urządzenia, obok innych urządzeń blokowych.
StateWarden jest agentem kopii zapasowych na poziomie bloków. Chroni ZVOL bezpośrednio. Nie potrafi przechwycić zamontowanego datasetu (drzewa katalogów takiego jak /tank/home), ponieważ dataset nie jest urządzeniem blokowym. Jeśli dane wymagające ochrony znajdują się w datasecie, zmigruj je do systemu plików umieszczonego na ZVOL.
2. Zalecenie: zabezpieczaj ZVOL
Przy każdym wykonaniu kopii zapasowej ZVOL StateWarden korzysta z natywnych migawek ZFS, aby uzyskać spójne źródło. Copy-on-write w ZFS sprawia, że utworzenie migawki jest praktycznie natychmiastowe i nie wstrzymuje zapisów w warstwie przestrzeni dyskowej. Kopia zapasowa przechwytuje zatem dokładny, zamrożony obraz blokowy woluminu z pojedynczego punktu w czasie.
Co daje kopia zapasowa ZVOL:
- Punktowy w czasie obraz zawartości woluminu, deduplikowany i kompresowany na węźle pamięci jak każda inna kopia na poziomie bloków.
- Granularność przywracania na poziomie woluminu: można przywrócić pojedynczy ZVOL bez dotykania reszty puli.
Czego nie daje:
- Semantyki plików na poziomie datasetów. Kopia zapasowa zawiera surowe bajty urządzenia blokowego - czyli system plików zapisany wewnątrz ZVOL przez system gościa lub aplikację. Nie zawiera hierarchii datasetów puli ani metadanych na poziomie ZFS.
- Historii migawek ZFS. Lokalne migawki ZVOL nie są przenoszone na węzeł pamięci. Kopia zapasowa jest obrazem blokowym, a nie strumieniem replikacji ZFS. Przywracanie odtwarza wolumin według stanu z punktu kopii, a nie lokalny łańcuch migawek, klony ani właściwości ZFS, takie jak
recordsizeczycompression.
3. Nie zabezpieczaj dysków członkowskich puli
Nie dodawaj fizycznych dysków tworzących pulę ZFS (na przykład /dev/sdc) do polityki kopii zapasowych. To ta sama zasada, która obowiązuje dla woluminów fizycznych LVM i członków programowego RAID (zobacz Kopie zapasowe w środowisku LVM: najlepsze praktyki).
Pula rozdziela dane między swoje vdev-y w grupach transakcji (TXG). Kopia zapasowa poszczególnych dysków członkowskich działającej puli przechwytuje każdy dysk w stanie innej grupy transakcji. Przy przywracaniu dysków nie da się złożyć w spójną pulę, a wynikiem jest uszkodzenie danych. Należy pamiętać, że redundancja ZFS (mirror, RAIDZ) jest mechanizmem dostępności, a nie kopią zapasową: wybieraj ZVOL, a dyski członkowskie puli pozostaw nieprzypisane.
4. Obciążenia maszyn wirtualnych i baz danych na ZVOL
Kopia zapasowa ZVOL oparta na migawce jest spójna awaryjnie (crash-consistent): przechwycony obraz odpowiada stanowi, jaki widać po nieoczekiwanej utracie zasilania. Nowoczesne systemy plików i bazy danych odtwarzają się z tego stanu automatycznie, ale spójność awaryjna to nie to samo, co spójność na poziomie aplikacji. Bufory przechowywane w pamięci przez aplikację nie są częścią obrazu.
W przypadku obciążeń wymagających spójności na poziomie aplikacji wyciszaj je wokół okna wykonywania kopii:
- Maszyny wirtualne: korzystaj z agenta gościa hipernadzorcy lub mechanizmu zamrażania systemu plików, aby system gościa opróżnił swoje systemy plików w chwili wykonywania kopii, i planuj kopie na okresy niskiego obciążenia I/O gościa.
- Bazy danych: skoordynuj natywny mechanizm opróżniania buforów lub kopii gorącej bazy danych (na przykład flush z blokadą odczytu) z harmonogramem kopii zapasowych albo zaakceptuj spójność awaryjną i weryfikuj ją regularnymi testami przywracania.
Zasada ogólna: warstwa przestrzeni dyskowej zamraża bloki; zadbanie o czysty stan aplikacji w tym momencie należy do obciążenia.
5. Współdziałanie kompresji i deduplikacji
Kompresja ZFS (compression=lz4 i podobne) jest przezroczysta w warstwie blokowej. Odczyty ZVOL zwracają logiczną, zdekompresowaną zawartość, więc potok kopii zapasowej widzi te same bajty, które zapisał system gościa lub aplikacja. Dwie praktyczne konsekwencje:
- Kompresja ZFS na ZVOL ani nie pomaga, ani nie szkodzi współczynnikom deduplikacji i kompresji po stronie kopii zapasowych. Szacuj oczekiwania przestrzenne na podstawie samych danych obciążenia, a nie wskaźników
compressrationa poziomie puli. - Dane już skompresowane lub zaszyfrowane powyżej warstwy blokowej - archiwa, pliki multimedialne, bazy danych z wewnętrzną kompresją albo szyfrowanie dysków na poziomie gościa - obniżają współczynniki deduplikacji i kompresji, dokładnie tak samo jak na każdym innym typie woluminu.
6. Zastosowanie Smart CBT
Smart CBT w systemie Linux jest zbudowany na śledzeniu zmian dm-era i nie ma zastosowania do ZVOL. Woluminy ZVOL są migawkowane natywnie dla zachowania spójności i odczytywane w całości podczas kopii zapasowej; wydajność przestrzenna wynika z deduplikacji na poziomie bloków, a nie ze śledzenia zmienionych bloków. Panel raportuje stan CBT każdego woluminu; wskaźniki stanów i zachowanie awaryjne opisuje artykuł Smart CBT: przyrostowe kopie zapasowe.
7. Lista kontrolna
| Obciążenie | Źródło kopii zapasowej | Ocena |
|---|---|---|
| Dysk maszyny wirtualnej na ZFS | ZVOL, na przykład /dev/zvol/tank/vm-100 | Zalecane |
| LUN iSCSI oparty na ZVOL | Urządzenie macierzyste /dev/zvol/... na hoście ZFS | Zalecane |
| Surowy wolumin bazy danych | ZVOL, z wyciszeniem zgodnie z sekcją 4 | Zalecane |
Zamontowany dataset (na przykład /tank/home) | Nie jest urządzeniem blokowym; zmigruj dane do systemu plików na ZVOL | Nieobsługiwane |
Dysk członkowski puli (na przykład /dev/sdc) | Brak; pozostaw nieprzypisany | Nigdy nie zabezpieczaj pojedynczo |