Моя текущая настройка: 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 таким образом, хотя кажется, что он работает?
При дальнейшем осмотре, ошибка ядра: nfsd: peername failed (err 107)!
появляется примерно каждые 6 секунд. Номер кажется соответствующим опции connection_timeout
в файле conf, и действительно, останавливая службу keepalived
, ошибка перестает появляться полностью.
Кажется, что используя TCP_CHECK
на порту 2049, серверы NFS будут регистрировать "плохие" попытки соединения, так как keepalived
не посылает NFS сообщения по протоколу.
В конце концов я использую MISC_CHECK
вместо этого для проверки работоспособности серверов NFS (с помощью пользовательского скрипта оболочки, вызывающего rpcinfo
).