NFS hinter einem VPN: Boot-Mount oder Automount auf Abruf?

Zwei Konfigurationen lösen dasselbe Problem und scheitern in entgegengesetzte Richtungen. Die Freigabe beim Booten einzubinden gibt jedem Dienst ein Dateisystem, das entweder da ist oder einen Grund, warum der Boot hängen blieb. Ein Automount auf Abruf gibt der Maschine einen schnellen Start und reicht das Warten an den weiter, der den Pfad zuerst berührt. Hinter einem VPN ist die zweite Variante meist der bessere Tausch, und der Grund ist, dass der Tunnel eine Reihenfolge erzwingt, die die Boot-Sequenz nicht sehen kann.

Boot-Mount gegenüber Automount

Ein Mount beim Booten ist einfach zu durchdenken. Das Dateisystem-Ziel wartet auf den Mount, Dienste, die eine Abhängigkeit davon erklären, starten danach, und wenn der Server nicht erreichbar ist, wartet die Maschine entweder oder scheitert, je nach den Optionen. Alles Nachgelagerte erbt diese eine Entscheidung.

Ein Automount kehrt das um. Der Pfad existiert sofort, der echte Mount passiert, wenn etwas ihn öffnet, und Dienste, die früh starten, blockieren nicht auf einem Tunnel, der noch nicht oben ist.

Der Vergleich läuft darauf hinaus, wer die Verzögerung absorbieren soll. Eine Workstation, die die Freigabe braucht, bevor der Benutzer arbeiten kann, sollte wohl warten. Ein Laptop, der in einer Tasche bootet, oder ein Server, dessen Freigabe optional ist, sollte nicht.

Keine der beiden Optionen repariert eine fehlende Route. Beide entscheiden nur, wann der Fehler beobachtet wird.

Die fstab-Zeile, Option für Option

Nehmen Sie an, eine bestehende OpenVPN-Client-Instanz ist [email protected], der Server ist files.corp.example und der Einhängepunkt ist /mnt/work. Ersetzen Sie alle drei durch die autorisierten Werte Ihres Standorts. Eine brauchbare Zeile sieht so aus:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev markiert den Mount als netzwerkabhängig und nennt überhaupt keinen Tunnel. nofail hält die Freigabe für das normale Dateisystem-Ziel optional. x-systemd.automount erzeugt den Auslöser auf Abruf, statt sofort zu mounten.

x-systemd.requires= ist der Teil, der den Mount-Versuch an die VPN-Unit bindet, und er gehört an die Mount-Operation, nicht an den Auslöser. Weitreichende Reihenfolge auf die Automount-Unit selbst zu legen ist der Weg, auf dem Leute Zyklen erzeugen, über die sich systemd dann in einer Sprache beschwert, die niemand zweimal liest.

x-systemd.mount-timeout=30s begrenzt den anfänglichen Mount-Befehl. Es begrenzt nichts, was danach passiert, und das ist das häufigste Missverständnis über diese Option.

Was „gestartet“ nicht bedeutet

Prüfen Sie, was aktiv bedeutet für die VPN-Unit, die Sie genannt haben. Ein Tunnel-Dienst kann sich als gestartet melden, bevor die Route zum Dateiserver existiert oder bevor der private Name aufgelöst wird, und danach zu ordnen bringt Ihnen dann nichts. In dieser Lücke lebt fast jeder fehlgeschlagene Versuch. Sie ist auch unsichtbar, wenn Sie nicht auf Route und Resolver schauen statt auf den Unit-Zustand.

Nutzen Sie das eigene Bereitschaftssignal des Verbindungseigners als zusätzliche Voraussetzung, wo es eines gibt. Ein festes Sleep ist eine Vermutung, die auf Ihrem Schreibtisch funktioniert und in einem langsameren Netz oder nach einem Reconnect scheitert.

Untersuchen Sie die erzeugten Units für den Pfad im Beispiel: mnt-work.automount und mnt-work.mount. Nach einer geprüften fstab-Änderung laden Sie systemd neu und verwalten diese Units direkt, statt einen pauschalen Mount-Befehl auszuführen, der unbeteiligte Einträge mitübt.

Eine weitere Einschränkung gehört hierher. Ein Dienst, der beim Start /mnt/work berührt, löst den Mount weiterhin aus und wartet weiterhin darauf, also macht eine optionale Freigabe nicht jede Anwendung geduldig.

Nach dem Mount ist es ein anderer Fehler

Sobald NFS eingebunden ist, bestimmt das Wiederholungs- und Wiederherstellungsverhalten des Dateisystems, was ein späterer Ausfall mit einem Lese- oder Schreibvorgang macht. Das von Ihnen gesetzte Mount-Timeout hat darauf keinen Einfluss.

Ein Soft-Mount verkürzt manche Wartezeiten und ändert die Fehlersemantik, mit Folgen für die Datenintegrität, die leicht übersehen werden, wenn das Ziel ein schnellerer Boot ist. Ihn zu wählen, um zwei Sekunden Startzeit zu gewinnen, ist selten ein guter Tausch. Wenn die Anforderung wirklich ein begrenzter Vorgang während eines Ausfalls ist, ist das eine Entscheidung auf Anwendungsebene, kein fstab-Flag.

Entscheiden Sie, was mit einem Prozess geschehen soll, der mitten im Schreiben ist, wenn der Tunnel wegfällt, und schreiben Sie es auf. Diese Antwort ist nützlicher als jede Optionszeichenkette.

Testen Sie vier Zustände, nicht einen

Ein normaler Start mit verfügbarem Tunnel ist der leichte Fall und beweist fast nichts. Er bestätigt, dass die Zeichenkette richtig geschrieben ist, und mehr nicht. Testen Sie den ersten Zugriff ohne VPN, dann die Erholung, wenn es hochkommt, dann einen kontrollierten Ausfall nach einem erfolgreichen Mount.

Vier Zustände, vier Beobachtungen, und die Notizen kommen neben den fstab-Eintrag. Die nächste Person erbt Verhalten statt einer Konfiguration, die sie rückwärts entwickeln muss.