NFS achter een VPN: mounten bij het opstarten of automatisch mounten op verzoek?

Twee configuraties lossen hetzelfde probleem op en falen in tegenovergestelde richtingen. De share bij het opstarten mounten geeft elke dienst een bestandssysteem dat er ofwel is, ofwel een reden waarom het opstarten vastliep. Een automatische mount op verzoek geeft de machine een snelle start en geeft het wachten aan wie het pad als eerste aanraakt. Achter een VPN is de tweede meestal de betere ruil, en de reden is dat de tunnel een ordening oplegt die de opstartreeks niet kan zien.

Mount bij het opstarten tegenover automatische mount

Een mount bij het opstarten is eenvoudig te beredeneren. Het bestandssysteemdoel wacht op de mount, diensten die een afhankelijkheid daarvan verklaren starten daarna, en als de server onbereikbaar is wacht de machine of faalt zij, afhankelijk van de opties. Alles stroomafwaarts erft die ene beslissing.

Een automatische mount keert dat om. Het pad bestaat meteen, de echte mount gebeurt wanneer iets het opent, en diensten die vroeg starten blokkeren niet op een tunnel die nog niet actief is.

De vergelijking komt neer op wie de vertraging moet absorberen. Een werkstation dat de share nodig heeft voordat de gebruiker kan werken, zou waarschijnlijk moeten wachten. Een laptop die in een tas opstart, of een server waarvan de share optioneel is, zou dat niet moeten.

Geen van beide opties herstelt een ontbrekende route. Beide bepalen alleen wanneer de fout wordt waargenomen.

De fstab-regel, optie voor optie

Stel dat een bestaande OpenVPN-clientinstantie [email protected] is, de server files.corp.example en het mountpunt /mnt/work. Vervang alle drie door de geautoriseerde waarden van uw eigen locatie. Eén werkbare regel ziet er zo uit:

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

_netdev markeert de mount als netwerkbehoevend, en het noemt helemaal geen tunnel. nofail houdt de share optioneel voor het normale bestandssysteemdoel. x-systemd.automount maakt de trigger op verzoek in plaats van onmiddellijk te mounten.

x-systemd.requires= is het deel dat de mountpoging aan de VPN-unit bindt, en het hoort bij de mountoperatie, niet bij de trigger. Brede ordening op de automatische mount-unit zelf zetten is de manier waarop mensen cycli creëren waarover systemd daarna klaagt in een taal die niemand twee keer leest.

x-systemd.mount-timeout=30s begrenst het eerste mountcommando. Het begrenst niets van wat daarna gebeurt, en dat is het meest voorkomende misverstand over deze optie.

Wat «gestart» niet betekent

Controleer wat actief betekent voor de VPN-unit die u hebt genoemd. Een tunneldienst kan zichzelf als gestart rapporteren voordat de route naar de bestandsserver bestaat of voordat de privénaam wordt opgelost, en daarna ordenen levert u dan niets op. In deze kloof leeft bijna elke mislukte poging. Het is ook onzichtbaar tenzij u naar de route en de resolver kijkt in plaats van naar de status van de unit.

Gebruik het eigen gereedheidssignaal van de verbindingseigenaar als extra voorwaarde waar dat bestaat. Een vaste slaap is een gok die op uw bureau werkt en faalt op een langzamer netwerk of na een herverbinding.

Onderzoek de gegenereerde units voor het pad uit het voorbeeld: mnt-work.automount en mnt-work.mount. Na een beoordeelde fstab-wijziging laadt u systemd opnieuw en beheert u die units rechtstreeks in plaats van een algemeen mountcommando te draaien dat niet-gerelateerde vermeldingen oefent.

Hier hoort nog een waarschuwing bij. Een dienst die bij het starten /mnt/work aanraakt, activeert nog steeds de mount en wacht er nog steeds op, dus de share optioneel markeren maakt niet elke toepassing geduldig.

Na de mount is het een andere fout

Zodra NFS is gemount, bepaalt het herhaal- en herstelgedrag van het bestandssysteem wat een latere storing doet met een lees- of schrijfactie. De mount-timeout die u hebt ingesteld heeft daar geen invloed op.

Een zachte mount verkort sommige wachttijden en verandert de foutsemantiek, met gevolgen voor de gegevensintegriteit die gemakkelijk over het hoofd worden gezien wanneer het doel een snellere start is. Hem kiezen om twee seconden opstarttijd te winnen is zelden een goede ruil. Als de eis echt een begrensde bewerking tijdens een storing is, is dat een beslissing op toepassingsniveau, geen fstab-vlag.

Bepaal wat er moet gebeuren met een proces dat midden in een schrijfactie zit wanneer de tunnel wegvalt, en schrijf het op. Dat antwoord is nuttiger dan welke optiereeks dan ook.

Test vier toestanden, niet één

Een normale start met de tunnel beschikbaar is het gemakkelijke geval en bewijst bijna niets. Het bevestigt dat de reeks correct is gespeld en niets meer. Test de eerste toegang zonder de VPN, dan het herstel wanneer die opkomt, dan een gecontroleerde storing na een geslaagde mount.

Vier toestanden, vier observaties, en de notities komen naast de fstab-vermelding. De volgende persoon erft gedrag in plaats van een configuratie die hij moet terugrekenen.