NFS aiz VPN: montāža sāknēšanas laikā vai automātiska montāža pēc pieprasījuma?

Divas konfigurācijas risina vienu un to pašu problēmu un cieš neveiksmi pretējos virzienos. Koplietojamā resursa montāža sāknēšanas laikā dod katrai servisai failu sistēmu, kas vai nu ir, vai paskaidro, kāpēc sāknēšana apstājās. Automātiskā montāža pēc pieprasījuma dod mašīnai ātru sāknēšanu un nodod gaidīšanu tam, kurš pirmais pieskaras ceļam. Aiz VPN otrais parasti ir labākais darījums, un iemesls ir tas, ka tunelis uzspiež kārtību, kuru sāknēšanas secība nespēj saskatīt.

Montāža sāknēšanas laikā pret automātisko montāžu

Montāža sāknēšanas laikā ir vienkārši saprotama. Failu sistēmas mērķis gaida montāžu, servisas, kas deklarē atkarību no tās, startē pēc tam, un, ja serveris nav sasniedzams, mašīna vai nu gaida, vai cieš neveiksmi atkarībā no opcijām. Viss lejupējais manto šo vienu lēmumu.

Automātiskā montāža to apgriež. Ceļš pastāv uzreiz, īstā montāža notiek, kad kaut kas to atver, un servisas, kas startē agri, neiestrēgst tunelī, kas vēl nav uzcelts.

Salīdzinājums nonāk pie tā, kuram jāuzņemas aizkavēšanās. Darbstacijai, kurai koplietojamais resurss vajadzīgs pirms lietotājs var strādāt, droši vien vajadzētu gaidīt. Klēpjdatoram, kas sāknējas somā, vai serverim, kura koplietojamais resurss ir neobligāts, nevajadzētu.

Neviena opcija neizlabo trūkstošu maršrutu. Abas vienkārši izlemj, kad neveiksme tiks novērota.

fstab rinda, opcija pa opcijai

Pieņemsim, ka esošā OpenVPN klienta instance ir [email protected], serveris ir files.corp.example, bet montāžas punkts ir /mnt/work. Aizstājiet visus trīs ar jūsu vietnes atļautajām vērtībām. Viena darbspējīga rinda izskatās šādi:

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

_netdev atzīmē montāžu kā tādu, kam vajadzīgs tīkls, un tā nosauc nevienu tuneli. nofail saglabā koplietojamo resursu neobligātu parastajam failu sistēmas mērķim. x-systemd.automount izveido trigeri pēc pieprasījuma, nevis montē uzreiz.

x-systemd.requires= ir daļa, kas montāžas mēģinājumu saista ar VPN vienību, un tā pieder montāžas operācijai, nevis trigerim. Plašas kārtības uzlikšana pašai automātiskās montāžas vienībai ir veids, kā cilvēki rada ciklus, par kuriem systemd pēc tam sūdzas valodā, ko neviens nelasa divreiz.

x-systemd.mount-timeout=30s ierobežo sākotnējo montāžas komandu. Tā neierobežo neko, kas notiek pēc tam, un tas ir visizplatītākais pārpratums par šo opciju.

Ko „startēts“ nenozīmē

Pārbaudiet, ko aktīvs nozīmē jūsu nosauktajai VPN vienībai. Tuneļa servisa var ziņot par sevi kā startētu, pirms pastāv maršruts uz failu serveri vai pirms tiek atrisināts privātais nosaukums, un kārtot pēc tā tad jums neko nedod. Tieši šajā spraugā dzīvo gandrīz katrs neveiksmīgais mēģinājums. Tā ir arī neredzama, ja vien neskatāties uz maršrutu un atrisinātāju, nevis uz vienības stāvokli.

Izmantojiet paša savienojuma īpašnieka gatavības signālu kā papildu priekšnosacījumu, kur tāds ir. Fiksēts miegs ir minējums, kas strādā uz jūsu galda un neizdodas lēnākā tīklā vai pēc atkārtotas savienošanas.

Pārbaudiet ģenerētās vienības piemēra ceļam: mnt-work.automount un mnt-work.mount. Pēc pārskatītas fstab izmaiņas pārlādējiet systemd un pārvaldiet šīs vienības tieši, nevis palaidiet vispārēju montāžas komandu, kas trenē nesaistītus ierakstus.

Šeit pieder vēl viens brīdinājums. Servisa, kas sāknēšanā pieskaras /mnt/work, joprojām izraisa montāžu un joprojām gaida to, tāpēc koplietojamā resursa atzīmēšana par neobligātu nepadara katru lietotni pacietīgu.

Pēc montāžas tā ir cita neveiksme

Kad NFS ir montēts, failu sistēmas atkārtošanas un atjaunošanas uzvedība nosaka, ko vēlāks pārrāvums dara ar lasīšanu vai rakstīšanu. Jūsu iestatītais montāžas taimauts uz to neietekmē.

Mīkstā montāža saīsina dažas gaidīšanas un maina kļūdu semantiku, ar datu integritātes sekām, kuras ir viegli nepamanīt, ja mērķis ir ātrāka sāknēšana. Tās izvēle, lai iegūtu divas sāknēšanas sekundes, reti ir labs darījums. Ja prasība patiešām ir ierobežota operācija pārrāvuma laikā, tas ir lēmums lietotnes līmenī, nevis fstab karodziņš.

Izlemiet, kam jānotiek ar procesu, kas ir rakstīšanas vidū, kad tunelis krīt, un pierakstiet to. Šī atbilde ir noderīgāka par jebkuru opciju virkni.

Pārbaudiet četrus stāvokļus, nevis vienu

Parasta sāknēšana ar pieejamu tuneli ir vieglais gadījums un gandrīz neko nepierāda. Tā apstiprina, ka virkne ir uzrakstīta pareizi, un ne vairāk. Pārbaudiet pirmo piekļuvi bez VPN, tad atjaunošanos, kad tas paceļas, tad kontrolētu pārrāvumu pēc veiksmīgas montāžas.

Četri stāvokļi, četri novērojumi, un piezīmes iet blakus fstab ierakstam. Nākamais cilvēks manto uzvedību, nevis konfigurāciju, kas viņam jārekonstruē.