NFS-Migrationscheckliste für umbenannte Datensätze und stabile Dateihandles

Der sichere Ansatz besteht darin, eine Migration eines ruhenden Exports, die den für Clients sichtbaren Namespace nach Möglichkeit beibehält und Clients bei einer Änderung der Handle-Identität gezielt neu einhängt, als eine Abfolge überprüfbarer Kontrollpunkte zu behandeln und nicht als einzelnen Befehl.

Bei der Migration eines von Home-Server-Clients verwendeten NAS-Datasets auf einem Linux-NFS-Server besteht das praktische Risiko darin, dass das Umbenennen oder Verschieben eines exportierten Datasets zu veralteten NFS-Dateihandles oder Fehlern beim erneuten Einhängen führen kann. Erfassen Sie die aktuelle Identität und den Wiederherstellungspunkt, beginnen Sie mit dem am wenigsten invasiven Unterscheidungsmerkmal, werten Sie erfolgreiche und fehlgeschlagene Ergebnisse aus, bevor Sie eine weitere Variable ändern, und halten Sie an, sobald der Speicher instabil wird oder nur noch eine wiederherstellbare Kopie offengelegt würde. Der folgende Ablauf endet erst, wenn die ursprüngliche Arbeitslast erfolgreich ausgeführt wird oder die Beweislage eine Eskalationsgrenze erreicht.

Export und Abhängigkeiten von Dateihandles erfassen

Erfassen Sie die Identität des Quell-Dateisystems oder -Datasets, den serverseitigen Pfad, die NFSv4-Pseudo-Root, Exportoptionen, explizite fsid-Werte, Client-Einhängepfade, autofs- oder systemd-Einheiten sowie jeden Container und jede Anwendung, die den Mount verwendet. Erfassen Sie aktive Mounts und geöffnete Dateien, bevor Sie eine Ausfallzeit planen.

NFS-Dateihandles kodieren die vom Server ausgewählte Objektidentität. Daher garantiert eine unveränderte Pfadzeichenfolge nach dem Verschieben eines Dateisystems kein stabiles Handle. Die unabhängige Erklärung der Mechanismen veralteter NFS-Dateihandles erläutert, wie gelöschte, neu erstellte oder neu zugeordnete Exporte veraltete Handles erzeugen, selbst wenn das Verzeichnis sichtbar vorhanden ist.

Entscheiden Sie, ob das Ziel in der Stabilität des Namespace oder in der Kontinuität aktiver Handles besteht. Die Beibehaltung des für Clients sichtbaren Pfads reduziert Konfigurationsänderungen, doch beim Verschieben der Daten auf ein anderes Dateisystem kann weiterhin erforderlich sein, dass jeder Client ausgehängt wird und neue Handles erhält.

Ziel vorbereiten, während Clients am Quellserver bleiben

Erstellen Sie das Ziel-Dataset, kopieren Sie die Daten unter Beibehaltung von ACLs, Eigentümern, erweiterten Attributen, Hardlinks, Sparse-Dateien und Zeitstempeln und vergleichen Sie Anzahlen sowie repräsentative Hashes. Gleichen Sie Exportsicherheit und Identitätszuordnung ab, bevor Sie das Ziel für Produktionsclients freigeben.

Verwenden Sie den ZimaSpace-Leitfaden zur NFSv4-Identitätszuordnung, um NFSv4-Identitäten zwischen Linux-Servern abzugleichen. Stabile Dateihandles lösen weder Abweichungen bei numerischen Eigentümern noch bei Namensdomänen, daher müssen Sie sowohl die Dateidentitätsebene als auch die Benutzeridentitätsebene unabhängig voneinander prüfen.

Führen Sie eine erste Synchronisierung durch, während die Quelle aktiv ist, sofern die Kopiermethode dies unterstützt, und planen Sie anschließend eine abschließende Synchronisierung der Änderungen nach dem Anhalten. Exportieren Sie nicht beide Kopien mit Schreibzugriff unter demselben Client-Namespace, da sich Schreibvorgänge unbemerkt auseinanderentwickeln können.

Clients anhalten und den Export umschalten

Stoppen Sie auf jedem Client Anwendungen, Container und geplante Aufgaben, die Schreibvorgänge ausführen, und überprüfen Sie anschließend, dass kein wichtiger Prozess Dateien unterhalb des Mounts geöffnet hält. Hängen Sie die Clients sauber aus. Nach der abschließenden Synchronisierung entfernen Sie den Export der Quelle oder machen Sie sie schreibgeschützt, wechseln Sie den serverseitigen Mount oder Export auf das Ziel und laden Sie die Exporte neu.

Ein Bericht des GitLab-Engineering-Teams über einen Fall mit NFS-Umbenennung und veraltetem Zustand zeigt, dass das Verhalten bei Umbenennungen und Delegierungen zu veralteten oder inkonsistenten Beobachtungen auf Clients führen kann. Die sichere betriebliche Reaktion besteht in einem geplanten Anhalten und erneuten Einhängen, nicht in wiederholten Befehlen zum Leeren von Caches, während Anwendungen weiter schreiben.

Wenn sich die Identität des Dateisystems auf dem Ziel ändert, rechnen Sie mit neuen Handles und hängen Sie die Clients neu ein. Halten Sie den ursprünglichen Export unter einem nicht für die Produktion verwendeten Wiederherstellungsnamen verfügbar, lassen Sie jedoch niemals den alten und den neuen Verzeichnisbaum konkurrierende Schreibvorgänge annehmen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Jeden Client neu einhängen und die neue Identität prüfen

Hängen Sie zuerst einen Canary-Client neu ein und testen Sie Auflisten, Lesen, Erstellen, Umbenennen, Löschen, Dateisperren und Eigentümer. Starten Sie die davon abhängige Anwendung neu und überprüfen Sie die ursprüngliche Arbeitslast. Gehen Sie anschließend die übrigen Clients durch und dokumentieren Sie Mount-Quelle und NFS-Version sowie das Ausbleiben von Fehlern wegen veralteter Handles.

Starten Sie einen Canary-Client neu oder den Automount-Dienst, um zu bestätigen, dass die dauerhafte Konfiguration auf den stabilen, für Clients sichtbaren Namespace verweist. Prüfen Sie Serverprotokolle, Client-Kernel, Sicherungsaufgaben und Container auf verborgene alte Pfade. Ein erfolgreicher manueller Mount beweist nicht, dass Startreihenfolge oder Dienstabhängigkeiten korrekt sind.

Geben Sie die Quelle erst auf, wenn alle Clients neu eingehängt wurden, reguläre Aufgaben erfolgreich sind, eine Sicherung erfolgreich war und eine Wiederherstellung getestet wurde. Führen Sie bei einem Fehlschlag des Canary-Clients einen Rollback durch, bevor neue Schreibvorgänge akzeptiert werden. Sobald Schreibvorgänge auf dem Ziel begonnen haben, halten Sie an und führen Sie einen bewussten Abgleich durch, statt die Exporte wiederholt hin- und herzuschalten.