NFS za VPN: pripojenie pri boote alebo automatické pripojenie na požiadanie?

Dve konfigurácie riešia ten istý problém a zlyhávajú v opačných smeroch. Pripojenie zdieľaného adresára pri boote dá každej službe súborový systém, ktorý buď existuje, alebo vysvetlí, prečo sa boot zasekol. Automatické pripojenie na požiadanie dá stroju rýchly boot a čakanie odovzdá tomu, kto sa cesty dotkne prvý. Za VPN je druhá možnosť zvyčajne lepšia výmena, a dôvod je ten, že tunel vnucuje poradie, ktoré sekvencia bootu nevidí.

Pripojenie pri boote verzus automatické pripojenie

Pripojenie pri boote sa ľahko chápe. Cieľ súborového systému čaká na pripojenie, služby, ktoré deklarujú závislosť od neho, štartujú potom, a ak je server nedostupný, stroj buď čaká, alebo zlyhá podľa volieb. Všetko nasledujúce dedí to jedno rozhodnutie.

Automatické pripojenie to obracia. Cesta existuje okamžite, skutočné pripojenie nastane, keď ju niečo otvorí, a služby, ktoré štartujú skoro, neblokujú na tuneli, ktorý ešte nie je hore.

Porovnanie sa redukuje na to, kto má absorbovať oneskorenie. Pracovná stanica, ktorá potrebuje zdieľaný adresár predtým, než používateľ môže pracovať, by mala pravdepodobne čakať. Notebook, ktorý sa bootuje v batohu, alebo server, ktorého zdieľaný adresár je voliteľný, by nemal.

Ani jedna voľba neopraví chýbajúcu trasu. Obe len rozhodujú, kedy sa zlyhanie pozoruje.

Riadok fstab, voľba po voľbe

Predpokladajme, že existujúca klientska inštancia OpenVPN je [email protected], server je files.corp.example a prípojný bod je /mnt/work. Nahraďte všetky tri autorizovanými hodnotami z vášho pracoviska. Jeden funkčný riadok vyzerá takto:

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

_netdev označuje pripojenie ako vyžadujúce sieť a neuvádza žiadny tunel. nofail drží zdieľaný adresár voliteľný pre bežný cieľ súborového systému. x-systemd.automount vytvára spúšťač na požiadanie namiesto okamžitého pripojenia.

x-systemd.requires= je časť, ktorá viaže pokus o pripojenie na VPN unit, a patrí k operácii pripojenia, nie k spúšťaču. Práve široké poradie na samotnej automatickej mount unit je spôsob, akým ľudia vytvárajú cykly, na ktoré si potom systemd sťažuje jazykom, ktorý nikto nečíta dvakrát.

x-systemd.mount-timeout=30s obmedzuje počiatočný príkaz pripojenia. Neobmedzuje nič, čo sa stane potom, a to je najčastejšie nedorozumenie o tejto voľbe.

Čo „spustené“ neznamená

Overte, čo znamená aktívny pre VPN unit, ktorú ste uviedli. Služba tunela sa môže hlásiť ako spustená skôr, než existuje trasa k súborovému serveru alebo než sa preloží privátne meno, a radenie po nej vám potom nič neprinesie. Práve v tejto medzere žije takmer každý neúspešný pokus. Je tiež neviditeľná, ak sa nepozeráte na trasu a resolver namiesto stavu unitu.

Použite vlastný signál pripravenosti vlastníka spojenia ako ďalší predpoklad, kde existuje. Pevný sleep je odhad, ktorý funguje na vašom stole a zlyhá na pomalšej sieti alebo po opätovnom pripojení.

Preskúmajte vygenerované unity pre cestu z príkladu: mnt-work.automount a mnt-work.mount. Po skontrolovanej zmene fstab znovu načítajte systemd a spravujte tieto unity priamo, namiesto spúšťania plošného príkazu na pripojenie, ktorý precvičuje nesúvisiace záznamy.

Sem patrí ešte jedna výhrada. Služba, ktorá sa pri štarte dotkne /mnt/work, stále spúšťa pripojenie a stále naň čaká, takže označenie zdieľaného adresára za voliteľný neurobí trpezlivou každú aplikáciu.

Po pripojení je to iné zlyhanie

Keď je NFS pripojený, správanie súborového systému pri opakovaní a obnove určuje, čo neskorší výpadok urobí s čítaním alebo zápisom. Časový limit pripojenia, ktorý ste nastavili, na to nemá vplyv.

Mäkké pripojenie skracuje niektoré čakania a mení sémantiku chýb, s dôsledkami pre integritu údajov, ktoré sa ľahko prehliadnu, keď je cieľom rýchlejší boot. Vybrať ho, aby ste získali dve sekundy štartu, je málokedy dobrá výmena. Ak je požiadavkou skutočne obmedzená operácia počas výpadku, je to rozhodnutie na úrovni aplikácie, nie prepínač fstab.

Rozhodnite, čo sa má stať s procesom, ktorý práve zapisuje, keď tunel spadne, a zapíšte to. Tá odpoveď je užitočnejšia než akýkoľvek reťazec volieb.

Testujte štyri stavy, nie jeden

Normálny štart s dostupným tunelom je ľahký prípad a nedokazuje takmer nič. Potvrdzuje, že reťazec je napísaný správne, a nič viac. Otestujte prvý prístup bez VPN, potom obnovu, keď naskočí, potom riadený výpadok po úspešnom pripojení.

Štyri stavy, štyri pozorovania a poznámky idú vedľa záznamu fstab. Ďalší človek dedí správanie namiesto konfigurácie, ktorú musí reverzne inžinierovať.