Повторный экспорт NFS через VPN — это не пересылка пакетов
Средняя машина — клиент и сервер, а не маршрутизатор. Идентификаторы файловых систем, обёрнутые файловые дескрипторы и отсутствие поддержки блокировок меняют проект.
Машина Linux подключается к VPN, монтирует удалённый экспорт NFS, а затем отдаёт это монтирование другому набору клиентов. Такая схема выглядит как маршрутизация с лишними шагами, и это первое ошибочное допущение. Средняя машина — клиент вышестоящего сервера и сервер для нижестоящих клиентов, и она участвует в обеих связях файлового обслуживания. Пересылка пакетов ничего не говорит о файловых дескрипторах, блокировках или идентичности файловой системы; повторный экспорт говорит.
Начните с вопроса, могли бы нижестоящие клиенты обратиться к исходному серверу напрямую. Если да, средняя машина необязательна.
Три модели, три истории согласованности
Прямое монтирование — самое простое: каждый клиент монтирует исходный сервер через туннель, и политика экспорта этого сервера управляет доступом. Повторный экспорт — это средняя машина, представляющая другую границу сервиса, что полезно, когда сеть со стороны клиентов не должна напрямую достигать сервера. Репликация — третья модель, и она переносит вопрос с согласованности на синхронизацию и разрешение конфликтов.
Не описывайте реплицированную копию так, будто это живой повторный экспорт. Режимы отказа различаются, и пользователь, ожидающий, что каждая операция достигнет исходной файловой системы, будет удивлён при обрыве связи.
Идентичность переживает команду монтирования
Повторному экспорту нужен явный идентификатор файловой системы, и эта идентичность должна переживать перезапуски и пересборки конфигурации. Документация ядра ясно говорит об этом требовании, и она также предупреждает, что crossmnt не устраняет необходимости экспортировать дочерние файловые системы с их собственными идентификаторами. Дерево каталогов, которое пользователю кажется непрерывным, может пересекать несколько границ файловых систем. Современные nfs-utils могут автоматически выделять идентификаторы для поддерживаемых конфигураций, и когда они это делают, их база данных становится частью состояния шлюза. Относитесь к этим идентификаторам как к идентичности сервиса, а не как к одноразовым файлам.
Файловые дескрипторы — другая граница идентичности: повторный экспорт оборачивает исходный дескриптор, что делает его больше и может превысить лимит клиента. Успешное монтирование не доказывает, что каждая схема экспорта совместима.
Не каждая возможность NFS переживает среднюю машину
Руководство ядра по повторному экспорту утверждает, что сервер, выполняющий повторный экспорт, не поддерживает блокировки или запросы делегирования. Приложениям, зависящим от этих операций, нужен другой путь или проект, проверенный на них. Успешное монтирование и работающий список каталога не показывают, что реальные операции приложения работают.
Идентичность пользователя и политика экспорта также важны на каждом шаге. Вход в VPN доказывает, что участник сети прошёл аутентификацию; он не авторизует пользователя NFS и не передаёт учётные данные клиента через шлюз.
У шлюза две вышестоящие зависимости
Шлюз зависит от VPN для вышестоящего монтирования и от вышестоящего сервера для самой файловой системы. Локальный процесс экспорта, который всё ещё работает, не может сделать недоступное хранилище здоровым. Планируйте порядок запуска, поведение при переподключении и перезапуски сервера, включая то, что происходит с файловыми дескрипторами, которые клиенты уже держат. Клиенту, смонтировавшему через шлюз и потерявшему дескриптор, нужна повторная монтировка, и это операционное событие, а не прозрачное восстановление.
Если всё, что когда-либо требовалось, — это доступность частных IP-адресов, прямой маршрут к исходному серверу — более простая архитектура. Повторный экспорт должен существовать ради причины, которая переживёт запись.
Проверяйте рабочую нагрузку, а не монтирование
Отработайте реальную файловую нагрузку в контролируемой среде: операции, которые выполняет приложение, размеры файлов, которые оно использует, и ожидаемую параллельность. Следите за пробелами в возможностях, а не только за ошибками транспорта. Затем запишите, какую модель вы выбрали и почему, иначе следующий человек будет считать шлюз маршрутизатором.
Повторный экспорт оправдан, когда существует по осознанной причине, например изолированная клиентская сеть или контролируемая граница версии. Это плохая случайность, и разница в том, решил ли это кто-то.