NFS за VPN: монтування під час завантаження чи автоматичне монтування на вимогу?

Дві конфігурації розв'язують ту саму задачу і зазнають невдачі в протилежних напрямках. Монтування ресурсу під час завантаження дає кожній службі файлову систему, яка або є, або пояснює, чому завантаження зупинилося. Автоматичне монтування на вимогу дає машині швидке завантаження і передає очікування тому, хто першим торкнеться шляху. За VPN другий варіант зазвичай вигідніший, і причина в тому, що тунель нав'язує порядок, якого послідовність завантаження не бачить.

Монтування під час завантаження проти автоматичного

Монтування під час завантаження просто осмислити. Ціль файлової системи чекає на монтування, служби, що оголосили залежність від нього, запускаються після, а якщо сервер недоступний, машина або чекає, або зазнає невдачі залежно від опцій. Усе нижче за течією успадковує це єдине рішення.

Автоматичне монтування перевертає це. Шлях існує одразу, справжнє монтування відбувається, коли щось його відкриває, а служби, що запускаються рано, не блокуються на ще не піднятому тунелі.

Порівняння зводиться до того, хто має взяти затримку на себе. Робочій станції, якій потрібен ресурс до того, як користувач зможе працювати, ймовірно, варто зачекати. Ноутбуку, який завантажується в сумці, або серверу, чий ресурс необов'язковий, — ні.

Жоден варіант не виправляє відсутній маршрут. Обидва лише вирішують, коли збій буде помічено.

Рядок fstab, опція за опцією

Припустімо, наявний екземпляр клієнта OpenVPN — це [email protected], сервер — files.corp.example, а точка монтування — /mnt/work. Замініть усі три на дозволені значення вашого сайту. Один робочий рядок виглядає так:

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

_netdev позначає монтування як таке, що потребує мережі, і взагалі не називає жодного тунелю. nofail залишає ресурс необов'язковим для звичайної цілі файлової системи. x-systemd.automount створює тригер на вимогу замість негайного монтування.

x-systemd.requires= — це частина, яка прив'язує спробу монтування до юніта VPN, і вона належить до операції монтування, а не до тригера. Саме широке впорядкування на самому юніті автоматичного монтування створює цикли, на які потім скаржиться systemd мовою, яку ніхто не читає двічі.

x-systemd.mount-timeout=30s обмежує початкову команду монтування. Він не обмежує нічого, що відбувається далі, і це найпоширеніше непорозуміння щодо цієї опції.

Що «запущено» не означає

Перевірте, що означає активність для названого вами юніта VPN. Служба тунелю може повідомити про себе як про запущену до того, як з'явиться маршрут до файлового сервера або розв'яжеться приватне ім'я, і впорядкування після неї тоді нічого не дає. Саме в цій прогалині живе майже кожна невдала спроба. Він також невидимий, якщо не дивитися на маршрут і резолвер замість стану юніта.

Використовуйте власний сигнал готовності власника з'єднання як додаткову передумову там, де він є. Фіксований сон — це здогад, який працює на вашому столі й підводить у повільнішій мережі або після перепідключення.

Дослідіть згенеровані юніти для шляху з прикладу: mnt-work.automount і mnt-work.mount. Після перевіреної зміни fstab перезавантажте systemd і керуйте цими юнітами напряму, замість запуску загальної команди монтування, яка задіює сторонні записи.

Тут доречне ще одне застереження. Служба, яка торкається /mnt/work під час запуску, все одно викликає монтування і все одно чекає на нього, тож позначення ресурсу необов'язковим не робить кожен застосунок терплячим.

Після монтування збій інший

Щойно NFS змонтовано, поведінка файлової системи під час повторних спроб і відновлення визначає, що пізніший збій робить із читанням або записом. Встановлений вами тайм-аут монтування на це не впливає.

М'яке монтування скорочує деякі очікування і змінює семантику помилок, із наслідками для цілісності даних, які легко проґавити, коли мета — швидше завантаження. Вибирати його заради двох секунд запуску рідко є добрим обміном. Якщо вимога справді в обмеженій операції під час збою, це рішення рівня застосунку, а не прапорець fstab.

Вирішіть, що має статися з процесом, який перебуває посеред запису, коли тунель падає, і запишіть це. Ця відповідь корисніша за будь-який рядок опцій.

Перевіряйте чотири стани, а не один

Звичайний запуск із доступним тунелем — легкий випадок, і він майже нічого не доводить. Він підтверджує, що рядок написано правильно, і не більше. Перевірте перше звернення без VPN, потім відновлення, коли тунель піднімається, потім контрольований збій після успішного монтування.

Чотири стани, чотири спостереження, і нотатки йдуть поруч із записом fstab. Наступна людина успадковує поведінку замість конфігурації, яку треба реконструювати.