Я сознательно наивно подхожу к настройке сервера NFS с теплым резервом. У меня есть два сервера (CentOS 7.7), которые совместно используют каталог (а не файловую систему) через NFS. Этот каталог синхронизируется на обоих серверах с помощью rsync. Файл / etc / exports на обоих серверах использует один и тот же fsid для экспорта. У меня есть служебный IP-адрес для службы NFS, которая используется клиентами. Клиенты используют "мягкие, безотказные" варианты монтирования.
Теперь я дважды протестировал ручное переключение для этого IP-адреса и наблюдал за поведением клиента (и молча надеялся, что он «просто работает» ...). К сожалению, мои надежды не оправдались, но поведение клиента «непоследовательно» ИМХО, и я хочу знать в образовательных целях, почему это не «просто работает», и что можно сделать, чтобы заставить его работать (помимо специальных настроек высокой доступности, таких как кардиостимулятор).
С первой попытки моя установка, казалось, работала для некоторых клиентов (мог получить доступ к общему ресурсу на новом сервере, не замечая переключателя), другие показали ошибку «устаревший дескриптор файла» (которую я разрешил с помощью umount -fl и remount).
При второй попытке (с использованием arping для более быстрого переключения IP) у некоторых клиентов снова были ошибки «устаревшего дескриптора файла», другие, казалось, полностью потеряли монтирование (исчезли из вывода «mount»), но все еще оставалась строка в / proc / fs / nfsfs / volume для монтирования. Когда я перемонтировал общий ресурс для этих клиентов, я «иногда» получал дублирующиеся записи в / proc / fs / nfsfs / volume (которые, похоже, не причиняют вреда). На этот раз клиенты не «просто работали».
Может ли кто-нибудь объяснить (вероятно, очевидные) причины, по которым этот подход не работает?
большое спасибо
Сервер NFS не так просто failover. Вот как минимум две причины:
file handles поскольку дескрипторы файлов nfs являются постоянными, после отработки отказа клиент будет ожидать, что существующие дескрипторы все еще действительны и указывают на тот же самый объект файловой системы. В вашей настройке вы экспортируете разные файловые системы, поэтому дескрипторы файлов разные.
NFSv4 state если ваш клиент монтируется с NFSv4.x, они ожидают, что после прозрачный аварийное переключение все состояния остаются в силе. Это возможно только тогда, когда оба сервера имеют общее хранилище состояний.
Эти два требования делают невозможными простые (или наивные) настройки аварийного переключения, подобные вашей.
Протокол NFSv4 позволяет миграцию жизненного сервера, но, AFIK, только сервер Oracle Solaris 11 с ZFS реализует его.
на сервере nfs, /var/lib/nfs содержит информацию о сеансе для клиентов nfs.
При переключении IP-адреса другой узел не знает о содержимом / var / lib / nfs, которое пусто.