それは突然おきた。

クラスタノードを追加して、Autobalanceされる様子を見守っていたときのことなんですが、突然3号機がノードダウンしたようです。発生時刻は16時5分。

Status一覧を見てみると3号機が真っ赤になり、HDD情報が読み取れなくなっています。

おおう、まさかこのタイミングでー・・・とおもってびっくり。画面保持できなかったのですが、どうやら3号機はメモリダンプを吐いてリブートしたようです。そして、これも部分的にしか情報が取れなかったのですが、すべてのバックグラウンドジョブが自動的にPauseされた状態になってました。

この時のとある生存ノードのパフォーマンスグラフが下図で、ノードダウンを起こしたときにディスクIOが突然止まっていることがわかると思います。この時走ってた重複排除処理とAutobalance処理が停止したことが要因と考えられます。

エラーログの確認

こんなエラーログが出てました。

Status Offlineイベントは結構頻繁に繰り返し出力されていました。

アクセスはできたのか？

停止中、メールサーバからNFS対象領域の参照をしましたが、少し応答が遅かったものの、ちゃんと応答が帰ってきました。ここはIsilonの可用性がきちんと担保してくれたようです。

その後3号機はどうなったか？

リブートし、何事もなかったかのように復帰しました。3号機はESXi1号機に載っていて、当該ESXiサーバは結構メモリをパンパンに使っていたことから、メモリの不良領域をフンでしまったのかもしれません。

ClusterOverview画面でもほらこの通り。 オンラインになったことを示すイベントが表示されてました。

これらの挙動を眺めて

意外とノード復帰は早く行われるんだなぁというのが大きな印象です。大抵はこういうことが起きると、全体の再スキャンだの再構築処理が走るだのして、その後の処理が大わらわになることが多いのですが、そこまでひどい状態になることはなかったように見えます。

そもそもが、クラスタへの復帰処理を手動でしなくて良いのは、運用管理の観点においては大きなメリットになるのかもしれないです。逆にその挙動をつかみにくいというのはデメリットなのかなと言う気がしないでもないですが・・・