私の現在のセットアップ:同じディレクトリを同じコンテンツで共有する2台のNFSサーバー、SLBとして(またはこのシナリオではフェイルオーバー用に)1台のkeepalived
サーバー、VIPを介してマウントする1台のNFSv4クライアント。すべてのシステムはCentOS6(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マウントは機能しているようですが、ストレステストは行っていません。私が気づいたことの1つは、フェイルオーバー中の期間です。つまり、NFSサーバーの1つをシャットダウンして、keepalived
にサービスを別のNFSサーバーに移動させ、クライアントが応答する前にしばらくハングしているように見えることです。これは90秒の猶予期間によるものだと思います。
私を悩ませている問題は、NFSサーバーでは、このログ行が数秒ごとに表示され続け、ログが溢れることです。
kernel: nfsd: peername failed (err 107)!
tcpdump
を使用してトラフィックの原因を確認し、NFSサーバーとkeepalived
サーバー間で繰り返される交換を見つけました。最初はiptables
が原因である可能性があると思いましたが、両方のマシンでそれらをフラッシュしてもエラーは停止しません。
エラーを抑制する方法がある場合、私はそれを1日と呼ぶかもしれませんが(ありますか?)、私の好奇心の質問:このシナリオでNFSサーバーはkeepalived
サーバーと通信しようとする理由がありますか?または、NFS HAをこのように設定すると、機能しているように見えても、根本的に何か問題があるのでしょうか。
さらに詳しく調べると、エラーkernel: nfsd: peername failed (err 107)!
が約6秒ごとに表示されます。この番号は、confファイルのconnection_timeout
オプションに対応しているようです。実際、keepalived
サービスを停止すると、エラーは完全に表示されなくなります。
ポート2049でTCP_CHECK
を使用すると、keepalived
がプロトコルに従ってNFSメッセージを送信しないため、NFSサーバーは「不正な」接続試行をログに記録するようです。
最後に、代わりにMISC_CHECK
を使用してNFSサーバーの状態をチェックします(rpcinfo
を呼び出すカスタムシェルスクリプトを使用)。