やっぱり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側でクライアントをデバッグ。
参考サイト：
しかし参ったなぁ。明日の朝また落ちるのかな。。。
— 追記(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
これがめっちゃ出続けてる。これっぽいなぁ。
とりあえず一旦バックアップのスクリプトを止めて調査だな。
こうやって一つ一つ見えてくる感じがいいね。