NFS za VPN: montowanie przy starcie czy automatyczne montowanie na żądanie?

Dwie konfiguracje rozwiązują ten sam problem i zawodzą w przeciwnych kierunkach. Montowanie udziału przy starcie daje każdej usłudze system plików, który albo jest, albo wyjaśnia, dlaczego start się zatrzymał. Automatyczne montowanie na żądanie daje maszynie szybki start i przekazuje czekanie temu, kto pierwszy dotknie ścieżki. Za VPN drugie jest zwykle lepszą wymianą, a powód jest taki, że tunel narzuca kolejność, której sekwencja startu nie widzi.

Montowanie przy starcie kontra automatyczne montowanie

Montowanie przy starcie jest łatwe do przemyślenia. Cel systemu plików czeka na montowanie, usługi, które deklarują od niego zależność, startują potem, a jeśli serwer jest nieosiągalny, maszyna albo czeka, albo zawodzi w zależności od opcji. Wszystko poniżej dziedziczy tę jedną decyzję.

Automatyczne montowanie odwraca to. Ścieżka istnieje od razu, rzeczywiste montowanie następuje, gdy coś ją otworzy, a usługi startujące wcześnie nie blokują się na tunelu, który jeszcze nie wstał.

Porównanie sprowadza się do tego, kto ma wchłonąć opóźnienie. Stacja robocza, która potrzebuje udziału, zanim użytkownik może pracować, prawdopodobnie powinna poczekać. Laptop, który startuje w torbie, albo serwer, którego udział jest opcjonalny, nie powinien.

Żadna z opcji nie naprawia brakującej trasy. Obie tylko decydują, kiedy awaria zostanie zaobserwowana.

Linia fstab, opcja po opcji

Załóżmy, że istniejąca instancja klienta OpenVPN to [email protected], serwer to files.corp.example, a punkt montowania to /mnt/work. Zastąp wszystkie trzy wartościami autoryzowanymi z twojej witryny. Jedna działająca linia wygląda tak:

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

_netdev oznacza montowanie jako wymagające sieci i nie nazywa żadnego tunelu. nofail utrzymuje udział jako opcjonalny dla zwykłego celu systemu plików. x-systemd.automount tworzy wyzwalacz na żądanie zamiast montować od razu.

x-systemd.requires= to część, która wiąże próbę montowania z jednostką VPN, i należy ona do operacji montowania, a nie do wyzwalacza. Umieszczanie szerokiej kolejności na samej jednostce automatycznego montowania to sposób, w jaki ludzie tworzą cykle, na które potem systemd narzeka w języku, którego nikt nie czyta dwa razy.

x-systemd.mount-timeout=30s ogranicza początkową komendę montowania. Nie ogranicza niczego, co dzieje się później, i to jest najczęstsze nieporozumienie dotyczące tej opcji.

Czego nie oznacza „uruchomione”

Sprawdź, co aktywność oznacza dla wskazanej jednostki VPN. Usługa tunelu może zgłosić się jako uruchomiona, zanim istnieje trasa do serwera plików albo zanim rozwiąże się prywatna nazwa, i porządkowanie po niej nic wtedy nie daje. W tej luce żyje prawie każda nieudana próba. Jest też niewidoczna, jeśli nie patrzysz na trasę i resolver zamiast na stan jednostki.

Użyj własnego sygnału gotowości właściciela połączenia jako dodatkowego warunku tam, gdzie istnieje. Stały sen to zgadywanka, która działa na twoim biurku, a zawodzi w wolniejszej sieci lub po ponownym połączeniu.

Sprawdź wygenerowane jednostki dla ścieżki z przykładu: mnt-work.automount i mnt-work.mount. Po przejrzanej zmianie fstab ponownie wczytaj systemd i zarządzaj tymi jednostkami bezpośrednio, zamiast uruchamiać ogólną komendę montowania, która ćwiczy niepowiązane wpisy.

Tu należy się jeszcze jedno zastrzeżenie. Usługa, która dotyka /mnt/work przy starcie, nadal wyzwala montowanie i nadal na nie czeka, więc oznaczenie udziału jako opcjonalnego nie czyni każdej aplikacji cierpliwą.

Po montowaniu to już inna awaria

Gdy NFS jest zamontowany, zachowanie ponowień i odzyskiwania systemu plików rządzi tym, co późniejsza awaria robi z odczytem lub zapisem. Ustawiony limit czasu montowania nie ma na to wpływu.

Miękkie montowanie skraca niektóre oczekiwania i zmienia semantykę błędów, z konsekwencjami dla integralności danych, które łatwo przeoczyć, gdy celem jest szybszy start. Wybieranie go, by zyskać dwie sekundy startu, rzadko jest dobrą wymianą. Jeśli wymaganiem jest naprawdę ograniczona operacja podczas awarii, to decyzja na poziomie aplikacji, a nie flaga fstab.

Zdecyduj, co ma się stać z procesem, który jest w połowie zapisu, gdy tunel padnie, i zapisz to. Ta odpowiedź jest użyteczniejsza niż dowolny ciąg opcji.

Testuj cztery stany, nie jeden

Normalny start z dostępnym tunelem to łatwy przypadek i prawie niczego nie dowodzi. Potwierdza, że ciąg jest poprawnie zapisany, i nic więcej. Przetestuj pierwszy dostęp bez VPN, potem odzyskanie, gdy wstanie, potem kontrolowaną awarię po udanym montowaniu.

Cztery stany, cztery obserwacje, a notatki idą obok wpisu fstab. Następna osoba dziedziczy zachowanie zamiast konfiguracji, którą musi odtworzyć.