NFS în spatele unui VPN: montare la pornire sau montare automată la cerere?

Două configurații rezolvă aceeași problemă și eșuează în direcții opuse. Montarea partajării la pornire dă fiecărui serviciu un sistem de fișiere care fie există, fie explică de ce pornirea s-a oprit. O montare automată la cerere dă mașinii o pornire rapidă și predă așteptarea celui care atinge primul calea. În spatele unui VPN, a doua este de obicei schimbul mai bun, iar motivul este că tunelul impune o ordine pe care secvența de pornire nu o poate vedea.

Montare la pornire versus montare automată

O montare la pornire este simplu de analizat. Ținta sistemului de fișiere așteaptă montarea, serviciile care declară o dependență de ea pornesc după aceea, iar dacă serverul nu este accesibil mașina fie așteaptă, fie eșuează în funcție de opțiuni. Tot ce urmează moștenește acea singură decizie.

O montare automată inversează asta. Calea există imediat, montarea reală are loc când ceva o deschide, iar serviciile care pornesc devreme nu se blochează pe un tunel care nu a urcat încă.

Comparația se reduce la cine ar trebui să absoarbă întârzierea. O stație de lucru care are nevoie de partajare înainte ca utilizatorul să poată lucra ar trebui probabil să aștepte. Un laptop care pornește într-o geantă, sau un server a cărui partajare este opțională, nu ar trebui.

Niciuna dintre opțiuni nu repară o rută lipsă. Ambele decid doar când este observată defecțiunea.

Linia din fstab, opțiune cu opțiune

Să presupunem că o instanță de client OpenVPN existentă este [email protected], serverul este files.corp.example, iar punctul de montare este /mnt/work. Înlocuiți toate trei cu valorile autorizate din propriul site. O linie funcțională arată așa:

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

_netdev marchează montarea ca având nevoie de rețea și nu numește niciun tunel. nofail păstrează partajarea opțională pentru ținta normală a sistemului de fișiere. x-systemd.automount creează declanșatorul la cerere în loc să monteze imediat.

x-systemd.requires= este partea care leagă încercarea de montare de unitatea VPN și aparține operației de montare, nu declanșatorului. A pune o ordine largă pe unitatea de montare automată în sine este modul în care oamenii creează cicluri de care systemd se plânge apoi într-o limbă pe care nimeni nu o citește de două ori.

x-systemd.mount-timeout=30s limitează comanda de montare inițială. Nu limitează nimic din ce se întâmplă după aceea, și aceasta este cea mai frecventă neînțelegere despre această opțiune.

Ce nu înseamnă „pornit”

Verificați ce înseamnă activ pentru unitatea VPN pe care ați numit-o. Un serviciu de tunel se poate raporta ca pornit înainte ca ruta către serverul de fișiere să existe sau înainte ca numele privat să se rezolve, iar ordonarea după el atunci nu vă aduce nimic. În acest gol trăiește aproape fiecare încercare eșuată. Este și invizibil dacă nu vă uitați la rută și la resolver în loc de starea unității.

Folosiți propriul semnal de disponibilitate al proprietarului conexiunii ca precondiție suplimentară acolo unde există. O așteptare fixă este o presupunere care funcționează pe biroul dumneavoastră și eșuează pe o rețea mai lentă sau după o reconectare.

Inspectați unitățile generate pentru calea din exemplu: mnt-work.automount și mnt-work.mount. După o modificare de fstab revizuită, reîncărcați systemd și gestionați acele unități direct, în loc să rulați o comandă generală de montare care exersează intrări fără legătură.

Aici încape încă o avertizare. Un serviciu care atinge /mnt/work la pornire declanșează în continuare montarea și o așteaptă în continuare, așa că marcarea partajării ca opțională nu face fiecare aplicație răbdătoare.

După montare defecțiunea este alta

Odată ce NFS este montat, comportamentul de reîncercare și recuperare al sistemului de fișiere guvernează ce face o întrerupere ulterioară unei citiri sau unei scrieri. Timeout-ul de montare pe care l-ați setat nu are nicio influență asupra acestui lucru.

O montare soft scurtează unele așteptări și schimbă semantica erorilor, cu consecințe asupra integrității datelor ușor de trecut cu vederea când obiectivul este o pornire mai rapidă. Alegerea ei pentru a câștiga două secunde de pornire este rareori un schimb bun. Dacă cerința este într-adevăr o operație mărginită în timpul unei întreruperi, aceea este o decizie la nivel de aplicație, nu un steag din fstab.

Decideți ce ar trebui să se întâmple cu un proces care este la mijlocul unei scrieri când tunelul cade, și scrieți asta. Acel răspuns este mai util decât orice șir de opțiuni.

Testați patru stări, nu una

O pornire normală cu tunelul disponibil este cazul ușor și nu demonstrează aproape nimic. Confirmă că șirul este scris corect și nimic mai mult. Testați primul acces fără VPN, apoi recuperarea când urcă, apoi o întrerupere controlată după o montare reușită.

Patru stări, patru observații, iar notițele merg lângă intrarea din fstab. Următoarea persoană moștenește comportament în loc de o configurație pe care trebuie să o reconstruiască.