NFS agter ’n VPN: opstartmontering of outomontering op aanvraag?

Twee konfigurasies los dieselfde probleem op en faal in teenoorgestelde rigtings. Om die deel by die opstart te monteer, gee elke diens ’n lêerstelsel wat óf daar is óf ’n rede waarom die opstart gestol het. ’n Aanvraaggestuurde outomontering gee die masjien ’n vinnige opstart en gee die wag oor aan wie ook al eerste aan die pad raak. Agter ’n VPN is die tweede gewoonlik die beter ruil, en die rede is dat die tonnel ’n ordening oplê wat die opstartreeks nie kan sien nie.

Opstartmontering teenoor outomontering

’n Opstartmontering is eenvoudig om oor te redeneer. Die lêerstelselteiken wag vir die montering, dienste wat ’n afhanklikheid daarvan verklaar, begin daarna, en as die bediener onbereikbaar is, wag die masjien óf dit misluk, afhangende van die opsies. Alles wat daarop volg, erf daardie enkele besluit.

’n Outomontering keer dit om. Die pad bestaan onmiddellik, die werklike montering gebeur wanneer iets dit oopmaak, en dienste wat vroeg begin, blokkeer nie op ’n tonnel wat nog nie opgekom het nie.

Die vergelyking kom daarop neer wie die vertraging moet absorbeer. ’n Werkstasie wat die deel nodig het voordat die gebruiker kan werk, moet waarskynlik wag. ’n Skootrekenaar wat in ’n sak opstart, of ’n bediener wie se deel opsioneel is, moet nie.

Geen van die opsies herstel ’n ontbrekende roete nie. Albei besluit bloot wanneer die fout waargeneem word.

Die fstab-reël, opsie vir opsie

Neem aan ’n bestaande OpenVPN-kliëntinstansie is [email protected], die bediener is files.corp.example en die monteerpunt is /mnt/work. Vervang al drie met die gemagtigde waardes van jou eie terrein. Een werkbare reël lyk so:

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

_netdev merk die montering as een wat netwerk nodig het, en dit noem hoegenaamd geen tonnel nie. nofail hou die deel opsioneel vir die gewone lêerstelselteiken. x-systemd.automount skep die aanvraaggestuurde sneller in plaas daarvan om onmiddellik te monteer.

x-systemd.requires= is die deel wat die monteerpoging aan die VPN-eenheid koppel, en dit hoort by die monteerbewerking eerder as by die sneller. Om breë ordening op die outomonteringseenheid self te plaas, is hoe mense siklusse skep waaroor systemd dan kla in taal wat niemand twee keer lees nie.

x-systemd.mount-timeout=30s beperk die aanvanklike monteeropdrag. Dit beperk niks wat daarna gebeur nie, en dit is die enkele mees algemene misverstand oor hierdie opsie.

Wat gestart beteken, beteken nie dieselfde nie

Kyk wat aktief beteken vir die VPN-eenheid wat jy genoem het. ’n Tonneldiens kan homself as gestart rapporteer voordat die roete na die lêerbediener bestaan of voordat die private naam oplos, en om daarna te orden, lewer dan niks op nie. Dit is die gaping waar byna elke mislukte poging sit. Dit is ook onsigbaar tensy jy na die roete en die oplosser kyk eerder as na die eenheid se toestand.

Gebruik die verbindingseienaar se eie gereedheidsein as ’n bykomende voorvereiste waar een bestaan. ’n Vaste slaap is ’n raaiskoot wat op jou lessenaar werk en op ’n stadiger netwerk of ná ’n herverbinding misluk.

Ondersoek die gegenereerde eenhede vir die voorbeeldpad: mnt-work.automount en mnt-work.mount. Nadat ’n nagegane fstab-wysiging gedoen is, herlaai systemd en bestuur daardie eenhede direk eerder as om ’n oorkoepelende monteeropdrag te loop wat onverwante inskrywings oefen.

Nog een voorbehoud hoort hier. ’n Diens wat /mnt/work by die opstart aanraak, veroorsaak steeds die montering en wag steeds daarvoor, so om die deel opsioneel te merk maak nie elke toepassing geduldig nie.

Ná die montering is dit ’n ander fout

Sodra NFS gemonteer is, bepaal die lêerstelsel se herprobeer- en herstelgedrag wat ’n latere onderbreking aan ’n lees of ’n skryf doen. Die monteertydperk wat jy stel, het geen invloed daarop nie.

’n Sagte montering verkort sommige wagte en verander foutsemantiek, met dataintegriteitsgevolge wat maklik oor die hoof gesien word wanneer die doel ’n vinniger opstart is. Om dit te kies om twee sekondes opstart te wen, is selde ’n goeie ruil. As die vereiste werklik ’n begrensde bewerking tydens ’n onderbreking is, is dit ’n besluit op toepassingsvlak, nie ’n fstab-vlag nie.

Besluit wat moet gebeur met ’n proses wat midde-in ’n skryf is wanneer die tonnel val, en skryf dit neer. Daardie antwoord is nuttiger as enige opsiereël.

Toets vier toestande, nie een nie

Normale opstart met die tonnel beskikbaar is die maklike geval en bewys byna niks. Dit bevestig dat die string korrek gespel is en niks meer nie. Toets die eerste toegang met die VPN afwesig, dan die herstel wanneer dit opkom, dan ’n beheerde onderbreking ná ’n suksesvolle montering.

Vier toestande, vier waarnemings, en die notas gaan langs die fstab-inskrywing. Die volgende persoon erf gedrag eerder as ’n konfigurasie wat hulle moet terugontleed.