ども。こんばんは。

ReadyNAS 6.6.0にあげてからものすごくNFSの調子が悪い件、解決できたかもです。
→まだ解決してませんでした！

以下、事の顛末。

・不調に気づいたきっかけ
NFSマウントしているサーバ(CentOS 5.11)で、謎のiowaitと、NFSマウント失敗。
どうやら毎朝のAcronisのバックアップのコピーのタイミングでやられている。

・ReadyNASのログ(いわゆる/var/log/messagesやkern.log/kernel.log)を見つけるのに時間がかかった
→Web-UIからダウンロードできた。
※本当はどこにあるか見つけたいけどそれはもういいや・・・。

・根本原因
上記でダウンロードしたログに含まれるkernel.logで確認できた以下ログ。

nfsd: too many open connections, consider increasing the number of threads

どうやら、同時起動できるnfsdの限界を超えた？らしい。
※以前のバージョンでこの辺りどうなっていたのかは今となっては不明。。。

・解決策(まだ様子見中)

RPCNFSDCOUNTを調整する。
参考：Red Hat Enterprise Linux – Optimal Number of nfsd Threads (RPCNFSDCOUNT)

これ、ReadyNAS(と言うかDebian？)では罠がありました。

NFSの設定は以下起動スクリプト内で行われています。

/etc/init.d/nfs-kernel-server

　以下、設定箇所抜粋。

# Read config
DEFAULTFILE=/etc/default/nfs-kernel-server
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS=

ここを変えて再起動！あれ？反映されない。。。
この起動スクリプトの続きはこうなっている！

PROCNFSD_MOUNTPOINT=/proc/fs/nfsd
if [ -f $DEFAULTFILE ]; then
    . $DEFAULTFILE
fi

（#^ω^）

ってなわけで「/etc/default/nfs-kernel-server」を修正。

こんな感じ。

RPCNFSDCOUNT=64
RPCNFSDARGS= –no-nfs-version 4
RPCMOUNTDOPTS=–manage-gids –no-nfs-version 4
NEED_SVCGSSD=
RPCSVCGSSDOPTS=

　で再起動して確認してみる。

# cat /proc/net/rpc/nfsd

rc 0 142900 84
fh 0 0 0 0 0
io 20480 1170506176
th 64 0 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
ra 128 1 0 0 0 0 0 0 0 0 0 2
net 142984 0 142984 638
rpc 142984 0 0 0 0
proc2 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
proc3 22 4 27 1 7 7 0 3 142899 0 0 0 0 0 0 0 0 0 0 12 6 0 15
proc4ops 71 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

　ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

　とりあえず、これでAcronisのバックアップでこけなくなりました。

　あと、これ64が本当に正しいのか？はわかりません。。。

まぁとりあえず直った直った。

・・・直ってなかったorz

念のためこの記事書きながらもう一度バックアップを実行してたんです。
再発しました。。。

そして今気づいた。
NFSのTCPセッションがどんどん増えてる？

# netstat -an |grep 2049 |grep ESTABLISHED |wc -l
209
# netstat -an |grep 2049 |grep ESTABLISHED |wc -l
214
# netstat -an |grep 2049 |grep ESTABLISHED |wc -l
215
# netstat -an |grep 2049 |grep ESTABLISHED |wc -l
216

なにこれもうしんどい。

ではでは。またの機会に。

やっぱりReadyNASだなぁ。

こいつ本当にバージョナップしないほうが吉のやつだわ。

朝４時のCronの処理でバックアップを取っているが、そのあたりからNFSが応答しない。

not respondingとOKを繰り返している模様。

挙句のはてにマウントできなくなってしまう。何故かバージョンアップ後からSNMPでCPU使用率が取れないのでReadyNAS側でその時の負荷状況は見えないが、朝見てみるとすでに落ち着いている模様。
→CPU使用率、取れてました。hrProcessorLoadのCPUのIDが変わってたみたい。でも大した負荷じゃないな・・・。

質が悪いのがumountしてもマウント解除できない。「-f」でもダメなので「-l」でアンマウントするが、nfsのrestartは愚かOSの再起動もできなくなってしまう。

困った。。。。

原因がバージョンアップにあるとしか思えないので、取り合えすNFSのデバッグ方法について調べてみた。

■rpcdebug

NFSのデバッグ。デバッグのオプションをセット/クリアする。

使い方例：クライアント側でデバッグ。

# rpcdebug -m nfs -s all

これでフラグがセットされる。後はログとして「/var/log/messages」に書き込まれるみたい。結構な量出そう・・・。

調査が終わったら解除

# rpcdebug -m nfs -c all

モジュールやフラグの意味は適当に調べる。
※サーバの場合は「-m nfsd」みたい。ReadyNASで効くかわからないのでまずはCentOS側でクライアントをデバッグ。

参考サイト：

NFS/トラブルシューティング

しかし参ったなぁ。明日の朝また落ちるのかな。。。

— 追記(2016/12/20)

ReadyNAS 6.6.0のリリースノート見てたら不穏な記載が・・・

改善箇所:

• Amazon Cloud Driveバックアップシェアがオプションで利用可能

• ボリュームでのスナップショットプルーニング設定が、共有とLUNで最低でも直近の2つのスナップショットで保持されます。

• SNMPロケーションとコンタクトの設定に対応

• アプリ削除時の動作改善

• OSのコアベースをアップデート(Debian 7から8へ)

思うに最後のやつじゃね・・・。

— 追記(2016/12/21)

どうやら毎朝のAcronisのバックアップでやられてるみたい。
んで、ReadyNASのmessagesなり、kern.logのありかがわからない。。

右往左往しつつGUIからログダウンロードしたらあっさり中に入ってた。。。

で、kernel.logこんなエラーが

nfsd: too many open connections, consider increasing the number of threads

これがめっちゃ出続けてる。これっぽいなぁ。

とりあえず一旦バックアップのスクリプトを止めて調査だな。

こうやって一つ一つ見えてくる感じがいいね。