Nodeに鞭打って障害発生時の動作検証にトライします。稼働系のサーバをシャットダウンしてその時の切替動作を見てきました。今回はちょっと違ったパターンで切替の様子を見てみましょう。通常アクティブなインスタンスが、あるひとつのサーバ上でのみ動作しているので、スタンバイ側が停止していても何ら通常の動作に影響はないはずです。スタンバイ側に相当するサーバをメンテナンスのために停止しているような場合などが考えられます。インターコネクトはどうでしょう。処理には影響がないような気がします。いえ、少し気になるので一応確認しておきましょう。停止させて障害をシミュレートしてみます。インタフェースを停止させます。以下のコマンドを実行します。downとくに変化は、、、、、で、でた。なにやら、ノード2に接続している作業用のターミナルがぱたぱたぱたと閉じて行くではありませんか。おーっとログインできません。状態を確認してみます。フェイルオーバーしています。インタフェースが接続できていないためクラスタの一部としては機能できないためでしょう。インターコネクトは正常に通信できる状態にしておかなければならないということのようです。要があると言い換えることができるでしょう。**では最後にストレージとインターコネクトの多重障害をシミュレーションしてみます。いうところのスプリットブレインの状態になったため、優先ノードが生き残ったように見えます。その際、優先ノードがストレージへアクセスできなくなっていたらどうなるでしょうか。域にハートビートの情報が書き込まれるため、それぞれのノードは相手の死活状態を把握することができます。その結果、最も優先度が高いノード(あるいはノード群)が生き残ります。領域へのアクセス障害をシミュレートしてみます。同様の動作をするのであれば、今度はノード2側が生き残るはずです。領域)へのアクセスができなければ、ノード1側のハートビートの情報が書き込めないからです。初期状態を確認します。oel55sv01------------------------------------------------------------では、ノード1側のCRS領域へのパーミッションを変更して書き込みできなくし、同時にインターコネクト用のインタフェースを停止させます。領域のデバイスは以下の3つです。コマンドStatusは失敗したか、またはエラーのある状態で完了しました。再起動が開始.....さらに、ノード1が停止......うーん、想定外。次回、なにが起こったのか再度確認してみます。reserved.トップページ企業概要プライバシーポリシ。