Jak reorganizować zbiory danych NFS bez zmiany ścieżek eksportu widocznych dla klientów

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How to Reorganize NFS Datasets Without Changing Client-Visible Export Paths - Zima Store Online

Zbiory danych NFS można reorganizować bez powodowania nieaktualnych uchwytów po stronie klientów, jeśli widoczna dla klienta przestrzeń eksportu pozostaje niezmienna, a pamięć masowa jest przenoszona za tą granicą.

Zapobiegawczo należy oddzielić ścieżkę montowaną przez klientów od fizycznej nazwy zbioru danych, którą można później zmienić. Utwórz stabilne drzewo eksportu, celowo mapuj do niego zbiory danych, w miarę możliwości zachowuj tożsamość systemu plików, odłącz klientów przed destrukcyjnymi zamianami i po przełączeniu sprawdź tę samą ścieżkę eksportu. Jeśli serwer musi usunąć i ponownie utworzyć system plików używany jako zaplecze, potraktuj to jako zmianę tożsamości i zaplanuj skoordynowane ponowne montowanie przez klientów, zamiast obiecywać niewidoczną ciągłość.

Utwórz stabilną przestrzeń nazw eksportu nad zbiorami danych

Użyj dedykowanego katalogu głównego eksportów NFS, którego nazwy widoczne dla klientów nie odzwierciedlają każdej wewnętrznej nazwy zbioru danych ZFS lub Btrfs. Dzięki temu administratorzy pamięci masowej mogą reorganizować zbiory danych zaplecza bez konieczności uczenia każdego klienta nowej ścieżki montowania.

Omówienie projektu NFSv4 wyjaśnia, jak montowania bind tworzą stabilne eksporty w ramach celowo zarządzanego pseud systemu plików.

Udokumentuj ścieżkę klienta jako umowę zgodności. Wewnętrzne nazwy zbiorów danych można później zmienić, ale dopiero po ponownym zmapowaniu warstwy eksportu i przetestowaniu jej przy użyciu tej samej ścieżki.

Przypisz tożsamość eksportu zamiast polegać na kolejności wykrywania

Zapisz UUID systemu plików, ścieżkę eksportu, wersję NFS oraz jawne ustawienia fsid używane przez bieżący serwer. Sama identyczna nazwa widocznego katalogu nie wystarczy, gdy serwer NFS identyfikuje bazowy system plików inaczej po przeniesieniu.

SUSE zauważa, że NFS identyfikuje każdy eksportowany system plików, zamiast traktować eksport jako zwykły alias ścieżki.

Używaj jawnych identyfikatorów tylko tam, gdzie obsługuje je Twoja implementacja NFS, i dbaj o unikatowość każdej wartości. Nie kopiuj wartości fsid do dwóch jednocześnie eksportowanych systemów plików tylko po to, aby wyglądały na identyczne.

Przygotuj nowy zbiór danych za tą samą ścieżką eksportu

Utwórz lub odbierz zastępczy zbiór danych w tymczasowej ścieżce po stronie serwera, skopiuj lub zreplikuj jego zawartość, sprawdź uprawnienia, a następnie w oknie serwisowym zmapuj go do stabilnego drzewa eksportu. Zachowaj stary zbiór danych na potrzeby wycofania zmian, ale nie aktywuj go pod tą samą tożsamością eksportu.

Przykład eksportu NFS pokazuje, jak montowane poddrzewa wymagają celowych eksportów, gdy pod jedną przestrzenią nazw NFS znajduje się kilka systemów plików.

Przełączenie powinno zmienić jedno mapowanie po stronie serwera, a nie jednocześnie definicję montowania klienta i tożsamość zbioru danych. Ułatwia to analizę problemów, jeśli nowe drzewo okaże się nieprawidłowe.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Wstrzymaj zapisy przed zamianą bazowego systemu plików

Zatrzymaj lub wstrzymaj usługi, które aktywnie zapisują dane przez montowanie NFS, a następnie potwierdź, że żaden ważny klient nie wykonuje długotrwałej operacji na pliku podczas przełączenia. Ostateczną synchronizację wykonaj dopiero po wstrzymaniu zapisów.

IBM opisuje, dlaczego stan NFSv4 wymaga stabilnej pamięci masowej, ponieważ stan klienta jest częścią ciągłości działania, a nie tylko zawartością plików po stronie serwera.

W przypadku serwera domowego cel jest prostszy niż w przypadku klastrowego przełączania awaryjnego: unikaj zmiany tożsamości plików podczas działania aplikacji. Krótka, kontrolowana przerwa jest bezpieczniejsza niż zmuszanie klientów baz danych, multimediów lub kopii zapasowych do przetrwania wymiany systemu plików w trakcie pracy.

Dowiedz się, kiedy ponowne montowanie przez klienta jest nieuniknione

Jeśli reorganizacja usuwa i ponownie tworzy system plików, przywraca migawkę jako nowy system plików lub zmienia tożsamość uchwytów plików po stronie serwera, zaplanuj skoordynowane odmontowanie i ponowne zamontowanie po ustabilizowaniu ścieżki na serwerze.

Aktualny przewodnik rozwiązywania problemów z NFS stwierdza, że zmiany tożsamości serwera powodują nieaktualność uchwytów i zaleca sprawdzenie stabilnej tożsamości serwera, gdy problem się powtarza.

Nie reklamuj konserwacji „bez ponownego montowania”, jeśli bazowa tożsamość rzeczywiście się zmienia. Udokumentowane okno na ponowne montowanie jest lepsze niż dopuszczenie do tego, by aplikacje napotkały błąd ESTALE podczas zwykłych zapisów.

Przetestuj ścieżkę klienta przed wycofaniem starego zbioru danych

Zamontuj eksport na świeżym kliencie oraz na jednym istniejącym kliencie niekrytycznym, a następnie porównaj tożsamość katalogu, uprawnienia, reprezentatywne odczyty, jeden odwracalny zapis oraz oczekiwaną przez aplikację ścieżkę. Uruchom ponownie jednego klienta, aby potwierdzić, że trwała konfiguracja montowania się nie zmieniła.

W przypadku Arch Linux stwierdzono, że stabilny katalog główny NFS zapobiega ESTALE po zmianach bazowego systemu plików.

Reorganizację można uznać za zakończoną, gdy klienci nadal korzystają z pierwotnej eksportowanej ścieżki, a stary zbiór danych można wycofać bez ukrytych odwołań. Powiązany artykuł ZimaSpace na temat nieaktualnych uchwytów po zmianie nazwy zbioru danych opisuje ścieżkę odzyskiwania, jeśli błąd ESTALE już wystąpił.