RAC One Node の検証 その７
＜RAC One Node の検証 その７＞
ペンネーム : ダーリン
「創造的破壊」ほど高尚ではありませんが、今回も RAC One Node
に鞭打って障害発生時の動作検証にトライします。
前回まで 3 回にわたって RAC One Node の稼働系のサーバをシャッ
トダウンしてその時の切替動作を見てきました。今回はちょっと違っ
たパターンで切替の様子を見てみましょう。
RAC One Node では通常アクティブなインスタンスが、あるひとつの
サーバ上でのみ動作しているので、スタンバイ側が停止していても
何ら通常の動作に影響はないはずです。たとえば、スタンバイ側に
相当するサーバをメンテナンスのために停止しているような場合な
どが考えられます。
では、インターコネクトはどうでしょう。
仮に通信できていなくても RAC One Node の処理には影響がないよ
うな気がします。
とはいえ、少し気になるので一応確認しておきましょう。
** インターコネクト障害のシミュレーション **
今回はノード１側でプライベート LAN の N/W を停止させて障害を
シミュレートしてみます。
( grid ユーザで実施)
<pre.
————————————————————
NAME TARGET STATE SERVER STATE_DETAILS
————————————————————
Cluster Resources
————————————————————
ora.oel55sv01.vip
1 ONLINE ONLINE oel55sv01
ora.oel55sv02.vip
1 ONLINE ONLINE oel55sv02
ora.ron.db
1 ONLINE ONLINE oel55sv01 Open
ora.ron.srvron1.svc
1 ONLINE ONLINE oel55sv01
————————————————————
この状態で、プライベート LAN のインタフェースを停止させます。
この環境では eth1 をプライベート LAN に割り当てているので、
以下のコマンドを実行します。
では、、、
(root ユーザで実施)
# ifconfig eth1 down
とくに変化は、、、、、で、でた。
なにやら、ノード２に接続している作業用のターミナルがぱたぱた
ぱたと閉じて行くではありませんか。
おーっとログインできません。これはもしやサーバリブート！？
ノード１側で CRS の状態を確認してみます。
( grid ユーザで実施)
------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
------------------------------------------------------------
Cluster Resources
------------------------------------------------------------
ora.oel55sv01.vip
1 ONLINE ONLINE oel55sv01
ora.oel55sv02.vip
1 ONLINE INTERMEDIATE oel55sv01 FAILED OVER
ora.ron.db
1 ONLINE ONLINE oel55sv01
ora.ron.srvron1.svc
1 ONLINE ONLINE oel55sv01
ora.scan1.vip
1 ONLINE ONLINE oel55sv01
------------------------------------------------------------
ノード２側の仮想 IP (ora.oel55sv02.vip) がフェイルオーバーし
ています。
その後、ノード２の OS は自動的に再起動したものの、CRS は起動
してきません。プライベート LAN のインタフェースが接続できてい
ないためクラスタの一部としては機能できないためでしょう。
結局、RAC One Node でもインターコネクトは正常に通信できる状態
にしておかなければならないということのようです。これはデータ
ベースというよりも、クラスタ構成ノードが正常に動作している必
要があると言い換えることができるでしょう。
** インターコネクトとストレージの同時障害シミュレーション **
では最後にストレージとインターコネクトの多重障害をシミュレー
ションしてみます。
上記のインターコネクト障害では、通常の RAC でいうところのスプ
リットブレインの状態になったため、優先ノードが生き残ったよう
に見えます。ではその際、優先ノードがストレージへアクセスでき
なくなっていたらどうなるでしょうか。
通常の RAC ではインターコネクト間の通信が途絶えた場合、CRS 領
域にハートビートの情報が書き込まれるため、それぞれのノードは
相手の死活状態を把握することができます。その結果、最も優先度
が高いノード（あるいはノード群）が生き残ります。
今回の検証環境において、インターコネクトの断線と、ノード１側
での CRS 領域へのアクセス障害をシミュレートしてみます。RAC
One Node でも通常の RAC と同様の動作をするのであれば、今度は
ノード２側が生き残るはずです。なぜなら、ノード１側でストレー
ジ( CRS 領域)へのアクセスができなければ、ノード１側のハート
ビートの情報が書き込めないからです。
では、まず、初期状態を確認します。
( grid ユーザで実施)
------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
------------------------------------------------------------
Cluster Resources
------------------------------------------------------------
ora.oel55sv01.vip
1 ONLINE ONLINE oel55sv01
ora.oel55sv02.vip
1 ONLINE ONLINE oel55sv02
ora.ron.db
1 ONLINE ONLINE oel55sv01
ora.ron.srvron1.svc
1 ONLINE ONLINE oel55sv01
------------------------------------------------------------
では、ノード１側のCRS領域へのパーミッションを変更して書き込
みできなくし、同時にインターコネクト用のインタフェースを停止
させます。
なお、今回の検証環境における CRS 領域のデバイスは以下の3つです。
/dex/xvdb
/dex/xvdc
/dex/xvdd
( root ユーザで実施 )
# ls -la /dev/xvd* brw-rw---- 1 grid asmadmin 202, 16 9月 14 05:26 /dev/xvdb brw-rw---- 1 grid asmadmin 202, 32 9月 14 05:26 /dev/xvdc brw-rw---- 1 grid asmadmin 202, 48 9月 14 05:26 /dev/xvdd
パーミッション変更
# chmod 440 /dev/xvd[bcd] # ls -la /dev/xvd* br--r----- 1 grid asmadmin 202, 16 9月 14 05:27 /dev/xvdb br--r----- 1 grid asmadmin 202, 32 9月 14 05:27 /dev/xvdc br--r----- 1 grid asmadmin 202, 48 9月 14 05:27 /dev/xvdd
続いて、インターコネクト断線
# ifconfig eth1 down
す・る・と、、、、
まず、ノード２側でCRSが停止、、、、
$ crsctl status resource -t CRS-4535: Cluster Ready Servicesと通信できません CRS-4000: コマンドStatusは失敗したか、またはエラーのある状態で完了しました。
続いて、ノード２で OS の再起動が開始…..
さらに、ノード１が停止……
うーん、想定外。
次回、なにが起こったのか再度確認してみます。