RAC One Node の検証 その８
＜RAC One Node の検証 その８＞
ペンネーム : ダーリン
さてさて、RAC One Node でHW系の障害が発生した際の挙動を検証
していますが、前回はインターコネクトとノード１側の CRS 領域
への書き込み障害をシミュレートしたところ、両方のノードでサー
ビスが停止してしまうという(こちらの勝手な)想定外の事象に遭遇
してしまいました。
ノード１側でサービスが停止するであろうとは考えていましたが、
まさか、ノード２側も停止してしまうとは。。。
で、その後再度挑戦してみましたが、やはり同じ事態になってしま
いました。この状態でどうすればサービスを再開できるかを確認し
たところ、以下の結論に達しました。
【結論】 インターコネクトを復旧し、CRSへの書き込みを正常に戻し ノード１および２を OS レベルで再起動する必要がある。
要は障害を取り除いてOS再起動する必要があったということです。
これが(信じたくはありませんが)仕様なのか、不具合なのかの整理
は現時点では整理できていないのでいろいろと調べる必要がありそ
うです。
今回の検証から確認できている状況を整理すると、、、
ノード１ ノード２
+------------+ +------------+
| eth1 |X --------| |
| | | |
|(アクティブ)| | |
+------------+ +------------+
| |
| +-----------+ |
+--- X| +CRS |----+
| | | |
+-----| +DATA |----+
| |
+-----------+
【障害状況】
- ノード１側からの CRS 領域への書き込みが不可 - ノード１側のインターコネクト側の NIC が停止( eth1 を down)
【事象】
- ノード２側の CRS が停止。 - ノード２側の OS が停止・再起動。 - ノード１側の CRS が停止。 - ノード２側の OS は起動するが、CRS 起動せず。
この状態からは、待てど暮らせど、データベースが起動する気配
がない。(そもそも CRS が起動しない)
そこで、インターコネクトのみ通常の状態に復旧させると、、
– ノード２側の CRS が起動。
（※ ただしリトライしている期間を超えた場合は OS 再起動要）
– データベースが起動しようとするが、以下のエラーで停止。
USER (ospid: 4932): terminating the instance due to error 304
エラーの意味は、こういうことらしい。
---------------------------------------------------------
ORA-00304: 要求したINSTANCE_NUMBERは使用中です。
原因: すでに使用中の初期化パラメータINSTANCE_NUMBERの値を
使用してインスタンスを起動しようとしました。
処置: 次のいずれかの処置を行ってください。
a）別のINSTANCE_NUMBERを指定する。
b）この番号で実行中のインスタンスを停止する。
c）この番号で実行中のインスタンスで、インスタンス・
リカバリが終了するまで待機する。
---------------------------------------------------------
※ 参考資料
「Oracle Databaseエラー・メッセージ 11gリリース2（11.2）」
alert.log をみると起動しようとしているインスタンスは、直前ま
で起動していたインスタンス（今回は RON_1）で特に問題はなさそ
うなので、上記処置の a) は該当しません。
そもそもデータベースがどちらのノードでも起動していないので処
置の 2) も該当しない。3) も同様。
どうも、ノード１で実行中のステータスが障害発生時に開放されて
いないようにも見えます。
というわけで、ノード１側の CRS 領域への書き込み状態を正常に
戻して、ノード１側の CRS を起動させると（当然ですが）データ
ベースは正常に起動してきました。
ただし、”ノード１”側で。 （つまり切り替わっていない？？？？）
残念ながら、今回のインターコネクトとストレージ障害（ CRS 領
域への書き込み不可）においては、どうにもしっくりこない結果と
なってしまいました。
…
もうひとつあらたに確認できた事象について、少しふれておきます。
前々回の検証で、インターコネクトの断線をシミュレートしました。
ノード１側でインスタンスがアクティブな状態で、インターコネク
ト側の NIC を無効化して行った検証です。
この時は、サービスに直接関係なさそうなノード２が停止・再起動
していました。
ノード１ ノード２ +------------+ +------------+ | eth1 |X --------|[停止および | | | | 再起動]| |(アクティブ)| | | +------------+ +------------+
もし、ノード２側でインスタンスがアクティブな場合はどうなるの
か気になっていたので、Omotion でノード 2 側にインスタンスを移
動し同様に、ノード 1 側のインタコネクト側の NIC を停止してみ
ました。
当然、ノード２はそのまま稼働することを期待しています。
ノード１ ノード２(停止しないことを期待) +------------+ +------------+ | eth1 |X --------| | | | | | | | |(アクティブ)| +------------+ +------------+
が、、、なんと、ノード２側のサーバで再起動が行われてしまいま
した。
データベースはというと、ノード１側で起動しようとしています。
しかも、途中で停止しているではありませんか。
alert.log でみるとこのあたりで止まります。
----------------------------------------------------------- Starting up: and Real Application Testing options. Using parameter settings in server-side pfile /u01/app/oracle/product/11.2.0/dbhome_1/dbs/initRON_2.ora System parameters with non-default values: processes = 150 spfile = "+DATA/ron/spfileron.ora" nls_language = "JAPANESE" nls_territory = "JAPAN" : : open_cursors = 300 diagnostic_dest = "/u01/app/oracle" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----------------------------------------------------------
なんどトライしてみても同じです。素晴らしく再現性があります。
残念ながらノード２を停止させないようにする方法については確認
できませんでした。これも仕様なのか、あるいは不具合なのかにつ
いても現時点では見当が付きません。
ただし、ノード１側でインスタンスが起動しない点については、次
の隠しパラメータに TRUE を設定することで回避できそうです。
_disable_interface_checking
これは、eth1 が動作していることを確認する機能を無効化するため
のパラメータです。今回インターコネクトの断線を eth1 の無効化
で代替していたため、この機能が働きデータベースが起動できなか
ったようです。
物理的にLANのケーブルを抜線（断線）するようなケースでは上記パ
ラメータを変更しなくても問題なくデータベースは切り替わったか
もしれません。
上記の隠しパラメータについては、Oracle 社に問い合わせの上、注
意して設定してください。
今回の挙動をみる限り、何か障害が発生すると優先ノードを残すと
いう RAC の性格は残っているように見えます。
障害発生時に無用な切替が発生しないようにするために、通常運用
時はアクティブ側に寄せた状態で使用するほうが安全かもしれませ
んね。
さて、ちょっと想定外の挙動を示したため、いつも通りドタバタし
てしまいましたが、次回は検証結果のおさらいと、構築時にちょっ
とばかり気を使った点についてお話します。