Узел кластера NFS RHCS 5 не освобождает TCP 2049 при перемещении
Представьте, что у вас есть 2-узелный кластер Red Hat NFS; каждый узел RHEL5.4 64bit, и они совместно используют SAN LUN для данных. Основной интерфейс на каждом сервере связан с отказоустойчивостью HA (bond0, eth0+eth1), и для NFS существует стандартный IP-ресурс плавающего кластера. Конфигурация кластера настраивается с помощью стандартных инструментов Red Hat, а NFS имеет статические порты, определенные в / etc / sysconfig / nfs для работы через брандмауэр. Пока все хорошо, правда? Очень по книге, лучшие практики - ничего странного или странного в настройке сервера или кластера.
Суть проблемы заключается в том, что клиенты используют TCP для монтирования экспортированного общего ресурса NFSv4; при перемещении службы кластера на другой узел вновь пассивный узел сохраняет установленное соединение 2049/tcp (nfs daemon), используя отсутствующий 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 выполните стандартнуюкоманду clusvcadm -r nfs-svc -m node-B, чтобы переместить NFS на узел B; в обоих системных журналах узла A и узла B вы видите правильные сообщения - NFS останавливается, IP освобождается / перемещается, SAN размонтируется / монтируется и так далее. На клиенте NFS вы видите несколько сообщений системного журнала о том, что сервер NFS не отвечает, затем он возвращается, и все в порядке. По сути, перемещение NFS на узел 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.
И здесь это становится важным - если это фантомное соединение 2049 с TCP все еще находится на узле A, и теперь вы переместили службу NFS обратно на узел A (таким образом, он снова получает этот кластерный IP-адрес), все клиенты останавливаются и умирают с NFS монтирует, находится ли фантомное соединение в состоянии ESTABLISHED или FIN_WAIT1. Только когда это фантомное соединение окончательно исчезнет с узла A, клиенты NFS смогут восстановить свое монтирование NFS - это порядка 5–15 минут.
Мы протестировали это несколько раз, убедившись, что это не связано с брандмауэром, и это было проблемой, а не просто случайностью. По прошествии многих часов единственным реальным решением было перевести клиентов в UDP и полностью избежать этой проблемы. Я действительно хочу знать, что сломано и как это исправить.
2 ответа
У меня сложилось впечатление, что с NFS через TCP вы не сможете перейти от A->B->A за короткий промежуток времени. Смотрите, например, http://www.spinics.net/lists/cluster/msg08758.html
Использование netstat -p чтобы выяснить PID процесса, который слушает (или, ну, вы сказали, что это был NFSD, так что найдите его PID из ps), а затем сделать strace на нем, и вы можете, возможно, выяснить, что происходит с ним. Или, может быть, вы можете сделать strace на это, прежде чем сделать clusvcadm введите команду и посмотрите, получает ли он какие-либо сигналы или что-то в этом роде (возможно, это зависание в обработчике сигналов или ожидание возврата какого-либо системного вызова...).
Если худшее приходит к худшему, вы можете создать отладочную версию nfsd и запустить ее под gdb, выполнить команду clustervcadm и посмотреть , что именно она делает...