Представьте, что у вас есть кластер Red Hat NFS с двумя узлами; каждый узел является 64-битным RHEL5.4, и они совместно используют LUN SAN для данных. Первичный интерфейс на каждом сервере связан с аварийным переключением HA (bond0, eth0 + eth1), и для NFS существует стандартный плавающий IP-адрес ресурса кластера. Конфигурация кластера настраивается с помощью стандартных инструментов Red Hat, а в NFS есть статические порты, определенные в / etc / sysconfig / nfs для работы через брандмауэр. Пока все хорошо, правда? Собственно говоря, передовой опыт - ничего странного или странного не использовалось при настройке сервера или кластера.
Суть проблемы в том, что клиенты используют TCP для монтирования экспортированного общего ресурса NFSv4; при перемещении службы кластера на другой узел новый пассивный узел сохраняет соединение 2049 / tcp (демон nfs) УСТАНОВЛЕННОЕ с использованием теперь отсутствующего IP-адреса кластера для клиентов, даже если это технически невозможно (насколько мне известно). «Решением» было перейти к использованию UDP при монтировании с клиентов, поскольку мы не могли понять, что происходит (и, что более важно, как это исправить). Любые подсказки относительно того, почему приветствуются, подробности ниже.
Cluster IP: 1.1.1.10
Client IP: 2.2.2.100
Вначале служба NFS работает на узле A, узел A имеет IP-адрес кластера с псевдонимом bond0: 0 и смонтирован SAN. Клиент NFS подключен через NFSv4 TCP к IP-адресу кластера, и все работает нормально. В нашей netstat на узле-A мы видим:
1.1.1.10:2049 2.2.2.2.100:915 ESTABLISHED
Все как должно быть. На узле-A запустите стандартный "кластерыvcadm -r nfs-svc -m узел-B‘Команда переместить NFS на узел-B; в обоих системных журналах узла-A и узла-B вы видите соответствующие сообщения - NFS остановлен, IP-адрес освобождается / перемещается, SAN отключен / смонтирован и так далее. На клиенте NFS вы видите несколько сообщений системного журнала о том, что сервер NFS не отвечает, затем он возвращается в норму, и все в порядке. В принципе, NFS relocate to node-B работает нормально.
тем не мение, вернувшись к узлу A, который больше не владеет IP-адресом кластера 1.1.1.10, вы все еще видите в netstat соединение на 2049 году! Быстрый 'rcpinfo -p'Подтверждает, что на этом порту все еще используется nfsd.
1.1.1.10:2049 2.2.2.2.100:915 ESTABLISHED
Конечно, на узле B вы видите то же самое, что и это правильно. Вопрос на 10 миллионов долларов: почему он все еще отображается на узле A? Как только IP исчез, который должен был быть сброшен ... если вы просто перезапустите nfsd, состояние соединения на узле A изменится на FIN_WAIT1, и в конечном итоге время истечет. IP-адрес кластера больше не отображается как интерфейс на узле A, чтобы быть понятным, только в netstat.
И вот где это становится важным - если это TCP-фантомное соединение 2049 все еще находится на узле-A, и теперь вы перемещаете службу NFS обратно на узел-A (чтобы он снова получил этот IP-адрес кластера), все клиенты останавливаются и умирают с NFS монтировать вне зависимости от того, находится ли фантомное соединение в состоянии ESTABLISHED или FIN_WAIT1. Только когда это фантомное соединение окончательно исчезнет с узла A, клиенты NFS смогут восстановить свое монтирование NFS - это займет от 5 до 15 минут.
Мы тестировали это несколько раз, чтобы убедиться, что это не связано с брандмауэром и повторялось как проблема, а не как случайность. По прошествии многих часов единственным работоспособным решением было переместить клиентов на UDP и полностью избежать проблемы. Я действительно хочу знать, что сломалось и как это исправить.
Использовать netstat -p чтобы выяснить PID процесса, который слушает (или, ну, вы сказали, что это nfsd, поэтому найдите его PID вне ps), а затем выполните strace на нем, и вы, возможно, сможете понять, что с ним происходит. Или, может быть, ты сможешь сделать strace на нем, прежде чем делать clusvcadm и посмотрите, получает ли он какие-либо сигналы или что-то в этом роде (возможно, он зависает в обработчике сигнала или ожидает возврата какого-либо системного вызова ...).
В худшем случае вы можете создать отладочную версию nfsd, запустить ее под gdb, выполнить команду clustervcadm и посмотреть именно что он делает ...
У меня сложилось впечатление, что с NFS через TCP вы не можете перейти от A-> B-> A за короткое время. См., Например, http://www.spinics.net/lists/cluster/msg08758.html