Назад | Перейти на главную страницу

«Сбой имени узла nfsd», но функции службы NFSv4

Моя текущая установка: 2 сервера NFS, использующие один и тот же каталог с идентичным содержимым, 1 keepalived сервер как SLB (или, скорее, для аварийного переключения в этом сценарии), и 1 клиент NFSv4, монтируемый через VIP. Все системы работают под управлением CentOS 6 (2.6.32-573.26.1.el6.x86_64). А поскольку это тестовая среда, все машины находятся в одной подсети (192.168.66.xx). Для справки, IP-адреса указаны ниже.

99 VIP
100 nfs01
101 nfs02
102 client
103 keepalived01

Серверы NFS настроены следующим образом:

/root/share 192.168.66.0/24(ro,fsid=0,sync,no_root_squash

Что касается keepalived, Я запускаю его в режиме DR (режим NAT вообще не работает).

vrrp_instance nfs {
        interface eth0
                state MASTER
                virtual_router_id 51
                priority 103    # 103 on master, 101 on backup
                authentication {
                        auth_type PASS
                        auth_pass hiServer
                }
        virtual_ipaddress {
                192.168.66.99/24 dev eth0
        }
}

virtual_server 192.168.66.99 2049 {
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    protocol TCP

    real_server 192.168.66.100 2049 {
            weight 100
            TCP_CHECK {
                    connect_timeout 6
                    connect_port 2049
            }
    }

    real_server 192.168.66.101 2049 {
            weight 102
            TCP_CHECK {
                    connect_port 2049
                    connect_timeout 6
            }
    }
}

Наконец, клиент подключается с помощью этой команды:

mount -t nfs4 192.168.66.99:/ /nfsdata

Крепление NFSv4, похоже, работает, хотя я не тестировал его под нагрузкой. Одна вещь, которую я заметил, - это период времени во время аварийного переключения, то есть я выключаю один из серверов NFS, keepalived чтобы переместить службу на другой сервер NFS, чтобы клиент некоторое время зависал, прежде чем ответить. Я считаю, что это связано с 90-секундным льготным периодом.

Проблема, которая меня беспокоит, заключается в том, что на серверах NFS эта строка журнала отображается каждые или около того секунды, переполняя журналы.

kernel: nfsd: peername failed (err 107)!

Я пробовал использовать tcpdump чтобы увидеть, что вызывает трафик, и обнаружил повторяющиеся обмены между сервером NFS и keepalived сервер. Сначала я подумал iptables может быть виновником, но их очистка на обеих машинах не устраняет ошибку.

Если есть способ подавить ошибку, я могу назвать это днем ​​(есть ли?), Но мои любопытные вопросы: есть ли у сервера NFS причина пытаться связаться с keepalived сервер в этом сценарии? Или, может быть, что-то в корне не так при настройке NFS HA ​​таким образом, хотя кажется, что это работает?

При дальнейшем осмотре ошибка kernel: nfsd: peername failed (err 107)! появляется примерно каждые 6 секунд. Номер, кажется, соответствует connection_timeout вариант в файле conf, и действительно, остановив keepalived service ошибка вообще перестает появляться.

Кажется, используя TCP_CHECK на порту 2049 серверы NFS будут регистрировать «плохие» попытки подключения, поскольку keepalived не отправляет сообщения NFS согласно протоколу.

В конце концов я использую MISC_CHECK вместо этого для проверки работоспособности серверов NFS (с помощью специального сценария оболочки, вызывающего rpcinfo).