У меня есть 2 узла HAE-кластера с сервером NFS, экспортирующим файловую систему через виртуальный IP. Для виртуального IP-адреса у меня есть Azure Internal Load Balancer (Standard) с включенным Session Persistence None и Floating IP (Direct server return). В основном настройка в соответствии с этим Microsoft статья.
Я тестирую с одним клиентом NFS с монтированием NFS: mount lb-nfs:/export/transCP3 /mnt/test -o nfsvers=4.1,hard,nofail
Это устанавливает TCP-соединение от привилегированного порта (например, 940) на клиенте к порту 2049 на сервере NFS с активным ресурсом CRM.
Когда я переключаю ресурс на другой узел (который также переключает виртуальный IP-адрес), клиент не может продолжать использовать общий ресурс. Он просто пытается повторно отправить SYN-пакеты без ответа. Tcpdump показывает, что балансировщик нагрузки все еще «маршрутизирует» пакеты на теперь неактивный узел сервера NFS. В то же время новое соединение (Telnet на порт 2049) правильно маршрутизируется на новый активный узел.
Из tcpdump я вижу, что клиент пробует новые и новые TCP-соединения (разные порядковые номера), но все еще использует тот же исходный порт. Документация по Load Balancer состояния If a backend endpoint's health probe fails, established TCP connections to this backend endpoint continue. Но из tcpdump не только установленные TCP-соединения, но и новые попытки подключения с того же порта.
Я также пробовал NFS с исходными портами> 1024, и теперь клиент пытается каждую новую попытку TCP-подключения с нового исходного порта и может восстановить общий ресурс.
Такое поведение не согласуется ни с документацией по Load Balancer, ни с собственным учебным курсом Microsoft по HA-NFS.
Кто-нибудь знает, почему он так себя ведет? Работает ли для кого-то HA NFS через Azure ILB? Есть ли другой способ заставить его работать, кроме включения "небезопасных" опций NFS?