Lista kontrolna migracji NFS dla przemianowanych zbiorów danych i stabilnych uchwytów plików

Bezpieczne podejście polega na traktowaniu migracji eksportu po wstrzymaniu, która w miarę możliwości zachowuje przestrzeń nazw widoczną dla klienta i celowo ponownie montuje klientów, gdy zmienia się tożsamość uchwytów, jako sekwencji obserwowalnych bramek, a nie pojedynczego polecenia.

W przypadku migracji w systemie Linux serwera NFS zbioru danych NAS używanego przez klientów domowego serwera praktyczne ryzyko polega na tym, że zmiana nazwy lub przeniesienie eksportowanego zbioru danych może pozostawić klientów ze starymi uchwytami plików NFS albo spowodować błędy ponownego montowania. Zapisz bieżącą tożsamość i punkt odzyskiwania, zacznij od najmniej inwazyjnego rozróżnika, interpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej oraz zatrzymaj się, gdy pamięć masowa stanie się niestabilna lub jedyna możliwa do odzyskania kopia zostałaby ujawniona. Poniższa procedura kończy się dopiero wtedy, gdy pierwotne obciążenie zakończy się powodzeniem albo dowody doprowadzą do granicy eskalacji.

Przeprowadź inwentaryzację eksportu i zależności uchwytów plików

Zapisz tożsamość źródłowego systemu plików lub zbioru danych, ścieżkę po stronie serwera, pseudo-korzeń NFSv4, opcje eksportu, jawne wartości fsid, ścieżki montowania klientów, jednostki autofs lub systemd oraz każdy kontener lub każdą aplikację korzystającą z montowania. Przed zaplanowaniem przestoju przechwyć informacje o aktywnych montowaniach i otwartych plikach.

Uchwyty plików NFS kodują tożsamość obiektu wybraną przez serwer, więc niezmieniona ścieżka tekstowa nie gwarantuje stabilnego uchwytu po przeniesieniu systemu plików. Niezależne wyjaśnienie mechanizmów nieaktualnych uchwytów plików NFS pokazuje, jak usunięte, odtworzone lub ponownie mapowane eksporty powodują powstawanie nieaktualnych uchwytów, nawet gdy katalog jest widoczny.

Określ, czy celem jest stabilność przestrzeni nazw, czy ciągłość aktywnych uchwytów. Zachowanie ścieżki widocznej dla klienta ogranicza liczbę zmian konfiguracji, ale przeniesienie danych do innego systemu plików może nadal wymagać od każdego klienta odmontowania zasobu i uzyskania nowych uchwytów.

Przygotuj cel, pozostawiając klientów przy źródle

Utwórz docelowy zbiór danych, skopiuj dane z zachowaniem list kontroli dostępu, właścicieli, atrybutów rozszerzonych, dowiązań twardych, plików rzadkich i znaczników czasu oraz porównaj liczbę elementów i reprezentatywne skróty. Przed udostępnieniem celu klientom produkcyjnym dopasuj zabezpieczenia eksportu i mapowanie tożsamości.

Skorzystaj z przewodnika ZimaSpace dotyczącego mapowania tożsamości NFSv4, aby ujednolicić tożsamości NFSv4 między serwerami Linux. Stabilne uchwyty plików nie rozwiązują problemów z numerycznymi właścicielami ani niezgodnością domen nazw, dlatego niezależnie zweryfikuj zarówno warstwę tożsamości plików, jak i warstwę tożsamości użytkowników.

Wykonaj początkową synchronizację, gdy źródło jest aktywne, tylko jeśli używana metoda kopiowania to obsługuje, a następnie zaplanuj końcową synchronizację różnicową po zatrzymaniu. Nie eksportuj obu kopii z prawem zapisu w tej samej przestrzeni nazw klienta, ponieważ zmiany mogą się rozbiegać bez wyraźnego błędu.

Wstrzymaj klientów i przełącz eksport

Zatrzymaj procesy zapisujące aplikacji, kontenery i zadania zaplanowane na każdym kliencie, a następnie sprawdź, czy żaden ważny proces nie ma otwartych plików poniżej punktu montowania. Odpowiednio odmontuj zasoby na klientach. Po końcowej synchronizacji wycofaj eksport źródła lub przełącz je w tryb tylko do odczytu, zmień montowanie po stronie serwera albo eksport na cel i przeładuj eksporty.

Opis przypadku zmiany nazwy i nieaktualnego stanu w NFS przygotowany przez zespół GitLab Engineering pokazuje, że zachowanie związane ze zmianą nazw i delegowaniem może prowadzić do nieaktualnych lub niespójnych obserwacji po stronie klienta. Bezpieczną reakcją operacyjną jest zaplanowane wstrzymanie i ponowne montowanie, a nie wielokrotne wykonywanie poleceń czyszczenia pamięci podręcznej, gdy aplikacje nadal zapisują dane.

Jeśli cel zmienia tożsamość systemu plików, spodziewaj się nowych uchwytów i ponownie zamontuj klientów. Zachowaj oryginalny eksport pod nazwą odzyskiwania inną niż produkcyjna, ale nigdy nie pozwalaj, aby stare i nowe drzewa przyjmowały konkurencyjne zapisy.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Ponownie zamontuj każdego klienta i zweryfikuj nową tożsamość

Najpierw ponownie zamontuj zasób na jednym kliencie testowym i sprawdź wyświetlanie listy, odczyt, tworzenie, zmianę nazwy, usuwanie, blokowanie plików oraz własność. Uruchom ponownie zależną aplikację i zweryfikuj pierwotne obciążenie. Następnie przejdź przez pozostałych klientów, zapisując źródło montowania, wersję NFS i brak błędów dotyczących nieaktualnych uchwytów.

Uruchom ponownie system lub usługę automatycznego montowania na kliencie testowym, aby potwierdzić, że trwała konfiguracja wskazuje stabilną przestrzeń nazw klienta. Sprawdź dzienniki serwera, jądra klientów, zadania kopii zapasowych i kontenery pod kątem ukrytych starych ścieżek. Pomyślne ręczne montowanie nie dowodzi, że kolejność uruchamiania ani zależności usług są prawidłowe.

Wycofaj źródło dopiero po ponownym zamontowaniu zasobu przez wszystkich klientów, pomyślnym wykonaniu zwykłych zadań, udanej kopii zapasowej i przetestowaniu jednego przywracania. Jeśli klient testowy zakończy się niepowodzeniem, wycofaj zmianę przed zaakceptowaniem nowych zapisów; po rozpoczęciu zapisu do celu zatrzymaj się i świadomie uzgodnij dane, zamiast wielokrotnie przełączać eksporty.