Моя текущая установка: 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
).