Jak rozwiązać problem nieaktualnych uchwytów plików NFS po zmianie nazwy zbioru danych

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 Resolve Stale NFS File Handles After Renaming a Dataset - Zima Store Online

Nieaktualne uchwyty plików NFS po zmianie nazwy zestawu danych zwykle oznaczają, że klient nadal przechowuje odwołania do obiektów lub tożsamości eksportu, które zmieniły się na serwerze.

Najbezpieczniejsza procedura odzyskiwania polega na ustaleniu, czy nieaktualny jest tylko jeden klient, czy zmieniła się sama tożsamość eksportu, zatrzymaniu aplikacji aktywnie korzystających z montowania, sprawdzeniu, czy zmieniony zestaw danych jest eksportowany z właściwej ścieżki, a następnie kontrolowanym ponownym zamontowaniu klientów. Nie uruchamiaj ponownie wszystkich maszyn ani nie odtwarzaj zestawu danych, dopóki nie ustalisz, czy nieaktualny uchwyt dotyczy jednego buforowanego montowania klienta, czy każdego klienta uzyskującego dostęp do zmienionego eksportu.

Potwierdź, że błąd pojawił się po zmianie nazwy zestawu danych

Zapisz starą nazwę zestawu danych i punkt montowania, nową nazwę zestawu danych i punkt montowania, eksportowaną ścieżkę oraz pierwszą operację klienta, która zwróciła ESTALE. Porównaj jeden klient, którego dotyczy problem, z klientem, który zamontował udział dopiero po zmianie nazwy.

Niedawny artykuł dotyczący rozwiązywania problemów z NFS wyjaśnia, że nieaktualny uchwyt oznacza jego zmianę, a nie po prostu niedostępność ścieżki sieciowej.

Jeśli świeże montowanie klienta działa, a stare nie, zmieniony eksport jest prawdopodobnie osiągalny, a bezpośrednim problemem jest stan buforowany na starym kliencie. Jeśli również świeże montowania kończą się błędem, kontynuuj analizę eksportu serwera i tożsamości zestawu danych.

Sprawdź, czy eksport wskazuje teraz właściwy zestaw danych

Po zmianie nazwy sprawdź aktywną listę eksportów serwera oraz tabelę zamontowanych systemów plików. Ścieżka może nadal istnieć, ale wskazywać teraz na inny zestaw danych, pusty punkt montowania lub katalog znajdujący się pod niewłaściwym systemem plików.

OneUptime zauważa, że zmiany eksportu mogą unieważnić uchwyty, gdy obiekty, eksporty, identyfikatory systemu plików lub przywrócone dane zmienią się pod istniejącym odwołaniem klienta.

Skoryguj cel eksportu przed modyfikowaniem klientów. Ponowne zamontowanie niewłaściwej ścieżki po stronie serwera może pozornie usunąć błąd ESTALE, jednocześnie niepostrzeżenie kierując aplikacje do innego drzewa katalogów.

Zatrzymaj procesy, które nadal używają starego montowania

Użyj narzędzi klienta do obsługi montowań i procesów, aby zidentyfikować powłoki, serwery multimediów, zadania kopii zapasowych, kontenery lub procesy baz danych, które nadal mają otwarte stare montowanie NFS. Przed wymuszonym odmontowaniem zatrzymaj najmniejszy możliwy zakres usług, których dotyczy problem.

Skoncentrowany przewodnik odzyskiwania w systemie Linux zaleca znalezienie procesów przed ponownym montowaniem, aby procedura odzyskiwania nie pozostawiła procesu w częściowo odłączonym widoku systemu plików.

Jeśli tylko jeden kontener korzysta z nieaktualnej ścieżki, najpierw zatrzymaj ten kontener. Jeśli montowanie jest współdzielone przez wiele usług, zaplanuj krótkie okno serwisowe zamiast od razu stosować leniwe odmontowania w aktywnym stosie aplikacji.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zamontuj ponownie klienta, gdy ścieżka serwera będzie stabilna

Po poprawieniu eksportu serwera i zatrzymaniu zależnych usług odmontuj i zamontuj ponownie udział NFS na jednym kliencie testowym. Użyj tego samego adresu serwera, ścieżki eksportu, wersji NFS i opcji montowania, które pozostaną używane w środowisku produkcyjnym.

Opis przypadku migracji NFS pokazuje, że klienci potrzebują świeżego montowania po przeniesieniu pamięci masowej, nawet gdy uprawnienia i skopiowane dane są poza tym prawidłowe.

Przed ponownym zamontowaniem wszystkich pozostałych klientów przetestuj wyświetlanie zawartości katalogu, jeden odczyt, jeden odwracalny zapis oraz rzeczywistą ścieżkę aplikacji. Jeśli ten sam klient natychmiast ponownie zgłasza nieaktualny uchwyt, wróć do analizy tożsamości serwera zamiast powtarzać samo ponowne montowanie.

Sprawdź, czy zmiana nazwy zmieniła tożsamość uchwytów plików

Uchwyty plików NFS nie są zwykłymi ciągami ścieżek. Zawierają definiowaną przez serwer tożsamość, która może obejmować informacje związane z systemem plików i i-węzłem, dlatego zastąpienie, przywrócenie lub przeniesienie bazowego systemu plików może mieć znaczenie, nawet gdy widoczna ścieżka eksportu wygląda podobnie.

Szczegółowa analiza uchwytów plików pokazuje, że uchwyty plików odwzorowują tożsamość serwera, a nie działają jak zakładki do tekstowej ścieżki.

Jeśli zmiana nazwy była w rzeczywistości częścią usunięcia i ponownego utworzenia zestawu danych, operacji receive, klonowania lub przywracania, udokumentuj tę szerszą zmianę tożsamości. Właściwym rozwiązaniem może być skoordynowane ponowne zamontowanie wszystkich klientów, a nie próba bezterminowego zachowania starych uchwytów.

Po ponownym uruchomieniu sprawdź, czy każdy klient korzysta z nowego eksportu

Gdy pierwszy klient przejdzie testy, montuj ponownie pozostałych klientów pojedynczo, przywracaj zależne usługi i sprawdzaj, czy skonfigurowane jednostki montowania lub ścieżki bind kontenerów wskazują właściwy eksport. Następnie uruchom ponownie jeden niekrytyczny klient jako test trwałości konfiguracji.

Artykuł dotyczący rozwiązywania problemów z pamięcią masową wyjaśnia, że nieaktualne montowania przetrwają aplikacje, dopóki faktycznie nie zostaną odświeżone procesy korzystające z udziału i stan montowania.

Naprawę można uznać za zakończoną, gdy nowe i ponownie uruchomione klienty montują zmieniony zestaw danych bez błędu ESTALE, a aplikacje odczytują oczekiwane pliki. Powiązany przewodnik ZimaSpace dotyczący stabilnych ścieżek montowania domowego serwera dotyczy sąsiedniego obszaru, gdy zmiany nazw zestawów danych zmieniły również lokalne ścieżki bind lub ścieżki aplikacji.

Często zadawane pytania

Czy nieaktualny uchwyt pliku NFS może oznaczać awarię dysku?

Nie sam w sobie. ESTALE oznacza, że buforowany uchwyt klienta nie identyfikuje już oczekiwanego obiektu po stronie serwera. Jeśli serwer zgłasza również błędy wejścia/wyjścia lub systemu plików, osobno sprawdź stan pamięci masowej.

Czy ponowne uruchomienie usługi NFS zawsze rozwiąże problem?

Nie. Jeśli eksport wskazuje teraz na zestaw danych o innej tożsamości, stare uchwyty klienta nadal będą nieprawidłowe. Najpierw sprawdź eksport, a następnie celowo odśwież montowania klientów.

Czy po zmianie nazwy zestawu danych należy ponownie uruchomić każdego klienta?

Zwykle nie. Kontrolowane zatrzymanie usług i ponowne montowanie wystarczą, jeśli eksport serwera jest prawidłowy. Ponowne uruchomienie jest potrzebne tylko wtedy, gdy klient nie może poprawnie zwolnić nieaktualnego montowania, albo jako końcowy test trwałości konfiguracji.