NFS za VPN: připojení při bootu, nebo automatické připojení na vyžádání?

Dvě konfigurace řeší stejný problém a selhávají v opačných směrech. Připojení sdíleného adresáře při bootu dá každé službě souborový systém, který buď existuje, nebo vysvětlí, proč se boot zasekl. Automatické připojení na vyžádání dá stroji rychlý boot a čekání předá tomu, kdo se cesty dotkne první. Za VPN je druhá varianta obvykle lepší výměna, a důvod je ten, že tunel vnucuje pořadí, které sekvence bootu nevidí.

Připojení při bootu versus automatické připojení

Připojení při bootu se snadno chápe. Cíl souborového systému čeká na připojení, služby, které deklarují závislost na něm, startují potom, a pokud je server nedostupný, stroj buď čeká, nebo selže podle voleb. Všechno navazující dědí toto jediné rozhodnutí.

Automatické připojení to obrací. Cesta existuje okamžitě, skutečné připojení nastane, když ji něco otevře, a služby, které startují brzy, neblokují na tunelu, který ještě není nahoru.

Srovnání se redukuje na to, kdo má zpoždění absorbovat. Pracovní stanice, která sdílený adresář potřebuje dřív, než uživatel může pracovat, by pravděpodobně měla čekat. Notebook, který se bootuje v batohu, nebo server, jehož sdílený adresář je volitelný, ne.

Ani jedna volba neopraví chybějící trasu. Obě jen rozhodují, kdy se selhání pozoruje.

Řádek fstab, volba po volbě

Předpokládejme, že existující klientská instance OpenVPN je [email protected], server je files.corp.example a přípojný bod je /mnt/work. Nahraďte všechny tři autorizovanými hodnotami z vašeho pracoviště. Jeden funkční řádek vypadá 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 připojení jako vyžadující síť a nepojmenovává žádný tunel. nofail drží sdílený adresář volitelný pro běžný cíl souborového systému. x-systemd.automount vytváří spouštěč na vyžádání místo okamžitého připojení.

x-systemd.requires= je část, která váže pokus o připojení na VPN unit, a patří k operaci připojení, ne ke spouštěči. Právě široké pořadí na samotné automatické mount unit je způsob, jakým lidé vytvářejí cykly, na které si pak systemd stěžuje jazykem, který nikdo nečte dvakrát.

x-systemd.mount-timeout=30s omezuje počáteční příkaz připojení. Neomezuje nic, co se stane potom, a to je nejčastější nedorozumění ohledně této volby.

Co „spuštěno“ neznamená

Ověřte, co znamená aktivní pro VPN unit, kterou jste uvedli. Služba tunelu se může hlásit jako spuštěná dřív, než existuje trasa k souborovému serveru nebo než se přeloží privátní jméno, a řazení po ní vám pak nic nepřinese. Právě v této mezeře žije téměř každý neúspěšný pokus. Je také neviditelná, pokud se nedíváte na trasu a resolver místo na stav unitu.

Použijte vlastní signál připravenosti vlastníka spojení jako další předpoklad, kde existuje. Pevný sleep je odhad, který funguje na vašem stole a selže na pomalejší síti nebo po opětovném připojení.

Prohlédněte vygenerované unity pro cestu z příkladu: mnt-work.automount a mnt-work.mount. Po zkontrolované změně fstab znovu načtěte systemd a spravujte tyto unity přímo, místo abyste spouštěli plošný příkaz pro připojení, který procvičuje nesouvisející záznamy.

Sem patří ještě jedna výhrada. Služba, která se při startu dotkne /mnt/work, stále spouští připojení a stále na něj čeká, takže označení sdíleného adresáře za volitelný neudělá trpělivou každou aplikaci.

Po připojení je to jiné selhání

Jakmile je NFS připojen, chování souborového systému při opakování a obnově určuje, co pozdější výpadek udělá se čtením nebo zápisem. Časový limit připojení, který nastavíte, na to nemá vliv.

Měkké připojení zkracuje některá čekání a mění sémantiku chyb, s důsledky pro integritu dat, které se snadno přehlédnou, když je cílem rychlejší boot. Vybrat ho, abyste získali dvě sekundy startu, je málokdy dobrá výměna. Pokud je požadavkem skutečně omezená operace během výpadku, je to rozhodnutí na úrovni aplikace, ne přepínač fstab.

Rozhodněte, co se má stát s procesem, který právě zapisuje, když tunel spadne, a zapište to. Ta odpověď je užitečnější než jakýkoli řetězec voleb.

Testujte čtyři stavy, ne jeden

Normální start s dostupným tunelem je snadný případ a nedokazuje téměř nic. Potvrzuje, že řetězec je napsán správně, a nic víc. Otestujte první přístup bez VPN, pak obnovu, když naskočí, pak řízený výpadek po úspěšném připojení.

Čtyři stavy, čtyři pozorování a poznámky jdou vedle záznamu fstab. Další člověk dědí chování místo konfigurace, kterou musí reverzně inženýrovat.