Przewodnik po migracji zestawów danych ZFS: przenoszenie danych bez zmiany ścieżek kontenerów

Bezpieczne podejście polega na traktowaniu replikacji, weryfikacji i atomowego przełączenia oryginalnego punktu montowania, z zachowaniem zbioru danych umożliwiającego wycofanie zmian, jako sekwencji obserwowalnych bramek, a nie pojedynczego polecenia.

W przypadku zbiorów danych ZFS obsługujących stos kontenera serwera domowego praktyczne ryzyko polega na konieczności przeniesienia zbioru danych ZFS przy zachowaniu ścieżek bind mountów używanych przez kontenery. Zapisz bieżącą tożsamość i punkt odzyskiwania, zacznij od najmniej inwazyjnego testu rozróżniającego, zinterpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej oraz zatrzymaj się, gdy pamięć masowa stanie się niestabilna albo jedyna możliwa do odzyskania kopia byłaby narażona. Poniższy przebieg kończy się dopiero po pomyślnym uruchomieniu pierwotnego obciążenia albo po osiągnięciu granicy eskalacji wynikającej z dowodów.

Spisz inwentaryzację zbioru danych i kontraktu ścieżki

Zapisz źródłowy zbiór danych, elementy podrzędne, migawki, punkt montowania, wartość canmount, główny obiekt szyfrowania, limity, rezerwacje, sposób obsługi list ACL oraz każdy bind mount kontenera, który znajduje się w jego obrębie. Kontraktem jest ścieżka hosta widoczna dla kontenerów; nazwa puli i zbioru danych może zmienić się pod tą ścieżką.

Replikacja ZFS może zachować migawki i właściwości, dlatego strumień rekurencyjny wymaga celowego przeglądu właściwości, a nie bezrefleksyjnego odbioru. Niezależny przewodnik migracji za pomocą ZFS send i receive pokazuje, jak send i receive służą do wewnętrznej migracji zbiorów danych oraz dlaczego hierarchię docelową należy sprawdzić przed przełączeniem.

Utwórz bieżącą zewnętrzną kopię zapasową albo potwierdź możliwość odtworzenia istniejącej kopii przed migracją. Zatrzymaj się, jeśli źródło zawiera ukryte podrzędne zbiory danych, nieznaną zależność od klucza szyfrowania lub punkt montowania nakładający się na inny aktywny zbiór danych; te warunki mogą sprawić, że prawidłowy strumień zostanie zamontowany w niewłaściwym miejscu.

Odbierz pierwszą kopię bez montowania jej na produkcji

Utwórz rekurencyjną migawkę, na przykład zfs snapshot -r oldpool/apps@move-0, a następnie wyślij ją do docelowego zbioru danych odebranego z wyłączonym montowaniem lub z tymczasowym punktem montowania. Użyj flag odpowiednich dla wymagań dotyczących szyfrowania i właściwości; nie zakładaj, że surowy strumień zaszyfrowany i odszyfrowany odbiór mają takie samo zachowanie kluczy.

Po odebraniu porównaj zfs list -r -t filesystem,snapshot oraz zfs get -r mountpoint,canmount,encryptionroot,quota,reservation w obu drzewach. Dyskusja na forum o replikowanych właściwościach punktu montowania pokazuje, dlaczego replikowane właściwości punktu montowania mogą zaskoczyć mimo pomyślnej migracji.

Pierwsza kopia przechodzi test, gdy zbiór danych i dziedziczenie migawek są zgodne, a cel pozostaje odizolowany od ścieżki produkcyjnej. Jeśli zostanie zamontowany na źródle lub zmieni pliki widoczne dla kontenerów, wyeksportuj cel albo odmontuj go i popraw właściwości przed wysłaniem jakiejkolwiek przyrostowej różnicy.

Zamknij lukę zapisu i przełącz punkt montowania

Wykonaj kolejną migawkę źródła i wyślij przyrostową różnicę, gdy aplikacja nadal działa. Na potrzeby końcowego przełączenia zatrzymaj wszystkich zapisujących, potwierdź, że żaden proces nie ma otwartych plików w ścieżce bind mountu, wykonaj końcową migawkę i wyślij tylko tę różnicę. Ogranicz przestój do końcowej synchronizacji i przełączenia ścieżki.

Ustaw źródło na nieprodukcyjny punkt montowania albo canmount=noauto, następnie przypisz oryginalną ścieżkę hosta do celu i zamontuj go. Nigdy nie pozostawiaj dwóch zbiorów danych zgłaszających ten sam punkt montowania. Uruchom bazę danych i usługi zależne przed interfejsem aplikacji, aby błędy wskazywały właściwą warstwę.

Jeśli końcowe wysłanie zakończy się niepowodzeniem, zamontuj źródło ponownie pod oryginalną ścieżką i uruchom ponownie stos; nie mieszaj nowych zapisów w obu kopiach. Warunek wycofania zmian jest jednoznaczny: źródło pozostaje nienaruszone, a na celu nie jest akceptowany żaden produkcyjny zapis, dopóki końcowy strumień i kontrole właściwości nie zakończą się pomyślnie.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Zweryfikuj kontenery pod niezmienioną ścieżką

Sprawdź bind mounty w środowisku uruchomieniowym kontenerów, otwórz reprezentatywne pliki, utwórz i usuń plik tymczasowy za pośrednictwem aplikacji oraz potwierdź właściciela, listy ACL, atrybuty rozszerzone i raportowanie wolnego miejsca. Uruchom stos ponownie dwa razy i sprawdź, czy ZFS jest montowany przed startem kontenerów.

Przeprowadź scrub lub inną kontrolę kondycji puli zgodnie z planem konserwacji, ale nie używaj jej jako jedynego dowodu migracji. Porównaj identyfikatory GUID migawek lub reprezentatywny manifest skrótów, odtwórz jeden mały element i użyj testu ZimaSpace, aby sprawdzić, czy replikację ZFS można wznowić po przerwaniu, zanim wycofasz źródłową linię pochodzenia.

Zachowaj źródło w trybie tylko do odczytu do czasu pomyślnego zakończenia co najmniej jednego zwykłego cyklu kopii zapasowej i aplikacji. Wycofaj je dopiero wtedy, gdy kontenery korzystają z oryginalnych ścieżek, zaplanowane zadania wskazują nowy zbiór danych, replikacja jest kontynuowana z zamierzonej linii pochodzenia, a wycofanie zmian nie jest już potrzebne; w przeciwnym razie przywróć punkt montowania i zachowaj obie historie.