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. Следующий человек наследует поведение вместо конфигурации, которую нужно реконструировать.