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