RAC One Node の検証 その7

<RAC One Node の検証 その7>
ペンネーム : ダーリン

「創造的破壊」ほど高尚ではありませんが、今回も RAC One Node
に鞭打って障害発生時の動作検証にトライします。

前回まで 3 回にわたって RAC One Node の稼働系のサーバをシャッ
トダウンしてその時の切替動作を見てきました。今回はちょっと違っ
たパターンで切替の様子を見てみましょう。

RAC One Node では通常アクティブなインスタンスが、あるひとつの
サーバ上でのみ動作しているので、スタンバイ側が停止していても
何ら通常の動作に影響はないはずです。たとえば、スタンバイ側に
相当するサーバをメンテナンスのために停止しているような場合な
どが考えられます。

では、インターコネクトはどうでしょう。
仮に通信できていなくても RAC One Node の処理には影響がないよ
うな気がします。
とはいえ、少し気になるので一応確認しておきましょう。

** インターコネクト障害のシミュレーション **

今回はノード1側でプライベート 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

とくに変化は、、、、、で、でた。

なにやら、ノード2に接続している作業用のターミナルがぱたぱた
ぱたと閉じて行くではありませんか。

おーっとログインできません。これはもしやサーバリブート!?
ノード1側で 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
------------------------------------------------------------

ノード2側の仮想 IP (ora.oel55sv02.vip) がフェイルオーバーし
ています。

その後、ノード2の OS は自動的に再起動したものの、CRS は起動
してきません。プライベート LAN のインタフェースが接続できてい
ないためクラスタの一部としては機能できないためでしょう。

結局、RAC One Node でもインターコネクトは正常に通信できる状態
にしておかなければならないということのようです。これはデータ
ベースというよりも、クラスタ構成ノードが正常に動作している必
要があると言い換えることができるでしょう。

** インターコネクトとストレージの同時障害シミュレーション **

では最後にストレージとインターコネクトの多重障害をシミュレー
ションしてみます。

上記のインターコネクト障害では、通常の RAC でいうところのスプ
リットブレインの状態になったため、優先ノードが生き残ったよう
に見えます。ではその際、優先ノードがストレージへアクセスでき
なくなっていたらどうなるでしょうか。

通常の RAC ではインターコネクト間の通信が途絶えた場合、CRS 領
域にハートビートの情報が書き込まれるため、それぞれのノードは
相手の死活状態を把握することができます。その結果、最も優先度
が高いノード(あるいはノード群)が生き残ります。

今回の検証環境において、インターコネクトの断線と、ノード1側
での CRS 領域へのアクセス障害をシミュレートしてみます。RAC
One Node でも通常の RAC と同様の動作をするのであれば、今度は
ノード2側が生き残るはずです。なぜなら、ノード1側でストレー
ジ( CRS 領域)へのアクセスができなければ、ノード1側のハート
ビートの情報が書き込めないからです。

では、まず、初期状態を確認します。

( 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
------------------------------------------------------------

では、ノード1側の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

す・る・と、、、、

まず、ノード2側でCRSが停止、、、、

  $ crsctl status resource -t
  CRS-4535: Cluster Ready Servicesと通信できません
  CRS-4000: コマンドStatusは失敗したか、またはエラーのある状態で完了しました。

続いて、ノード2で OS の再起動が開始…..
さらに、ノード1が停止……

うーん、想定外。

次回、なにが起こったのか再度確認してみます。