«Ошибка имени узла 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 и сервером поддержки активности . Сначала я подумал, что iptables может быть виновником, но их очистка на обеих машинах не останавливает ошибку.

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

1
задан 23 May 2016 в 13:21
1 ответ

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

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

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

.
1
ответ дан 3 December 2019 в 23:45

Теги

Похожие вопросы