NFS VPN mögött: csatolás indításkor vagy igény szerinti automatikus csatolás?

Két konfiguráció oldja meg ugyanazt a problémát, és ellentétes irányban vall kudarcot. A megosztás indításkori csatolása minden szolgáltatásnak ad egy fájlrendszert, amely vagy ott van, vagy megindokolja, miért akadt meg az indítás. Az igény szerinti automatikus csatolás gyors indítást ad a gépnek, és a várakozást annak adja át, aki először hozzáér az útvonalhoz. VPN mögött a második általában a jobb üzlet, és az ok az, hogy az alagút olyan sorrendet kényszerít, amelyet az indítási sorrend nem lát.

Indításkori csatolás kontra automatikus csatolás

Az indításkori csatolás könnyen átgondolható. A fájlrendszer-cél a csatolásra vár, az attól függőséget deklaráló szolgáltatások utána indulnak, és ha a kiszolgáló nem érhető el, a gép vagy vár, vagy meghibásodik az opcióktól függően. Minden, ami lejjebb van, ezt az egyetlen döntést örökli.

Az automatikus csatolás ezt megfordítja. Az útvonal azonnal létezik, a tényleges csatolás akkor történik, amikor valami megnyitja, és a korán induló szolgáltatások nem akadnak el egy olyan alagúton, amely még nem jött fel.

Az összehasonlítás arról szól, kinek kell elnyelnie a késleltetést. Egy munkaállomás, amelynek a megosztásra a felhasználó munkája előtt szüksége van, valószínűleg várjon. Egy táskában induló laptop, vagy egy kiszolgáló, amelynek a megosztása opcionális, ne várjon.

Egyik opció sem javítja a hiányzó útvonalat. Mindkettő csak azt dönti el, mikor figyelhető meg a hiba.

Az fstab-sor, opcióról opcióra

Tegyük fel, hogy egy meglévő OpenVPN-ügyfélpéldány [email protected], a kiszolgáló files.corp.example, a csatolási pont pedig /mnt/work. Cserélje ki mindhármat a saját telephelye engedélyezett értékeire. Egy működő sor így néz ki:

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

A(z) _netdev hálózatot igénylőként jelöli meg a csatolást, és egyáltalán nem nevez meg alagutat. A(z) nofail opcionálisan tartja a megosztást a normál fájlrendszer-cél számára. A(z) x-systemd.automount az igény szerinti kiváltót hozza létre az azonnali csatolás helyett.

A(z) x-systemd.requires= az a rész, amely a csatolási kísérletet a VPN-egységhez köti, és a csatolási művelethez tartozik, nem a kiváltóhoz. Széles sorrendet tenni magára az automatikus csatolási egységre az a mód, ahogyan az emberek ciklusokat hoznak létre, amelyekről a systemd aztán olyan nyelven panaszkodik, amelyet senki nem olvas el kétszer.

A(z) x-systemd.mount-timeout=30s korlátozza a kezdeti csatolási parancsot. Semmit nem korlátoz, ami utána történik, és ez a leggyakoribb félreértés ezzel az opcióval kapcsolatban.

Mit nem jelent az „elindult”

Ellenőrizze, mit jelent az aktív állapot a megnevezett VPN-egységnél. Egy alagútszolgáltatás jelentheti magát elindultnak, mielőtt a fájlkiszolgáló felé vezető útvonal létezik, vagy mielőtt a privát név feloldódik, és az utána való sorrendezés akkor semmit nem ad. Ebben a résben él szinte minden sikertelen kísérlet. Ez akkor is láthatatlan, ha nem az útvonalat és a feloldót nézi az egység állapota helyett.

Használja a kapcsolat tulajdonosának saját készültségi jelét további előfeltételként, ahol létezik ilyen. A rögzített alvás olyan tipp, amely az asztalán működik, és lassabb hálózaton vagy újracsatlakozás után elbukik.

Vizsgálja meg a példaútvonalhoz generált egységeket: mnt-work.automount és mnt-work.mount. Egy átnézett fstab-módosítás után töltse újra a systemd-t, és kezelje ezeket az egységeket közvetlenül, ahelyett hogy egy átfogó csatolási parancsot futtatna, amely nem kapcsolódó bejegyzéseket gyakoroltat.

Ide tartozik még egy figyelmeztetés. Az a szolgáltatás, amely indításkor hozzáér a(z) /mnt/work elemhez, továbbra is kiváltja a csatolást, és továbbra is vár rá, tehát a megosztás opcionálisként jelölése nem teszi türelmessé minden alkalmazást.

A csatolás után más a hiba

Amint az NFS csatolva van, a fájlrendszer újrapróbálkozási és helyreállítási viselkedése határozza meg, mit tesz egy későbbi kiesés egy olvasással vagy írással. A beállított csatolási időkorlát erre nincs hatással.

A lágy csatolás lerövidít néhány várakozást és megváltoztatja a hibák szemantikáját, olyan adatintegritási következményekkel, amelyeket könnyű figyelmen kívül hagyni, amikor a cél a gyorsabb indítás. Kiválasztani két indítási másodperc megnyeréséért ritkán jó üzlet. Ha a követelmény valóban egy korlátozott művelet kiesés közben, az alkalmazásszintű döntés, nem fstab-kapcsoló.

Döntse el, mi történjen azzal a folyamattal, amely éppen írás közben van, amikor az alagút leesik, és írja le. Az a válasz hasznosabb bármely opciókarakterláncnál.

Négy állapotot teszteljen, ne egyet

A normál indítás elérhető alagúttal a könnyű eset, és szinte semmit nem bizonyít. Megerősíti, hogy a karakterlánc helyesen van leírva, és semmi többet. Tesztelje az első hozzáférést VPN nélkül, majd a helyreállást, amikor feljön, majd egy ellenőrzött kiesést sikeres csatolás után.

Négy állapot, négy megfigyelés, és a jegyzetek az fstab-bejegyzés mellé kerülnek. A következő ember viselkedést örököl egy konfiguráció helyett, amelyet visszafejtenie kell.