RAC One Node の検証 その２
＜RAC One Node の検証 その２＞
ペンネーム : ダーリン
前回は RAC One Node の特徴を整理しながら、「実は IT インフ
ラの統合(データベースの統合)にフィットするはず」という考え
方を紹介しました。
今回からは RAC One Node を操作しながら、実際にどんな挙動を
示すのか、運用するに際して注意しないといけないことがあるの
かという点について、見ていきましょう。
＜＜ RAC One Node の検証環境＞＞
OS : Oracle Enterprise Linux 5.5 32bit
( on Oracle VM 2.2 )
Oracle VM Server 2.2.1
Oracle VM Manager 2.2.0
DB : Oracle Database Enterprise Edition 11.2.0.1 32bit
Oracle RAC One Node
HW :
CPU Intel(R) Xeon(TM) CPU 3.20GHz x 2 CPU
Memory 4GB
CPU Intel(R) Xeon(TM) CPU 3.20GHz x 1 CPU
Memory 1.7GB
上記のとおり、今回は Oracle VM を利用します。
物理サーバ 1 台にゲスト OS を 2 環境構築し、これらを RAC One
Node のアクティブ側、スタンバイ側として利用します。
また、上記以外に仮想環境の管理用に Oracle VM Manager を別サー
バで構築しています。
Oracle VM に関しては「Oracle VM に関する検証」シリーズが詳し
いので、こちらを参照してください。
https://old.insight-tec.com/mailmagazine/ora3/vol430.html
RAC One Node の構築はおおむね、RAC 環境の構築と同じです。
DBCA でデータベースを作成する際に、作業しているノードのみを
選択することと、データベース作成後にパッチの適用が必要なこと
が大きな違いです。
なお、11gR2 では従来 CRS と呼ばれていた機能の後継として Grid
Infrastructure が導入されるなど構成が変わっています。
RAC One Node 環境の構築に際して注意が必要な点については、別途
紹介する予定ですので、今回は実際の動作についてフォーカスして
いきます。
では、早速 grid ユーザで CRS のリソース状況を確認してみましょ
う。
(grid ユーザで実行)
$ crsctl stat resource -t ------------------------------------------------------------ NAME TARGET STATE SERVER STATE_DETAILS ------------------------------------------------------------ Local Resources ------------------------------------------------------------ ora.CRS.dg ONLINE ONLINE oel55sv01 ONLINE ONLINE oel55sv02 ora.DATA.dg ONLINE ONLINE oel55sv01 ONLINE ONLINE oel55sv02 ora.LISTENER.lsnr : : ------------------------------------------------------------ Cluster Resources ------------------------------------------------------------ ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE oel55sv01 ora.oc4j 1 OFFLINE OFFLINE 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 ora.scan1.vip 1 ONLINE ONLINE oel55sv01
今回作成したデータベースおよびサービスのリソースが確認でき
ます。
データベース ： ora.ron.db サービス ： ora.ron.srvron1.svc
また、それぞれのリソースが oel55sv01 側で起動していることが
わかります。
では、oracle ユーザで Omotion を実行してみましょう。
ちなみに Omotion とは、RAC One Node のインスタンスを、稼働中
のノードから別のノードに移動させるための機能です。 明示的に
インスタンスを移動できるので、サーバメンテナンスのシーンで
効果を発揮します。
実行前に、まず、おまじないが必要です。
これを忘れると前回のようなエラーが発生します。
(oracle ユーザで実行)
$ export LANG=C $ export LC_ALL=C $ export NLS_LANG=American_America.UTF8
いざっ！！
$ Omotion ----------------------------------------------------------- RAC One Node databases on this cluster: # Database Server === ======== ============================== [1] RON oel55sv01 Fix Required ============ N Enter number of the database to migrate [1]: 1 <<<< (1) Specify maximum time in minutes for migration to complete (max 30) [30]: 2 <<<< (2) Available Target Server(s) : # Server Available === ================== ========= [1] oel55sv02 Y Enter number of the target node [1]: 1 <<<< (3) Omotion Started... Starting target instance on oel55sv02... Migrating sessions... Stopping source instance on oel55sv01... Omotion Completed... === Current Status === Database RON is running on node oel55sv02 ---------------------------------------------------------------------------
入力内容の確認：
(1) 複数の DB が存在する場合にどの DB を Omotion の対象にする
かを指定します。
(2) Omotion にかかる時間の上限を指定します。
(3) 最後に Omotion で DB を移動させるノードを指定します。
実際に Omotion の処理が始まるのは、上記 (3) で DB を移動する
ノードを指定してからです。処理が始まってから全て終了するまで
( プロンプトが返ってくるまで )、およそ 2 分 40 秒かかりました。
その間、CRS のリソースは以下のような状態になります。
なお、状態変化が確認できた部分のみきりだしています。
(A) Omotion ( 開始前 )
------------------------------------------------------------ NAME TARGET STATE SERVER STATE_DETAILS ------------------------------------------------------------ Cluster Resources ------------------------------------------------------------ ora.ron.db 1 ONLINE ONLINE oel55sv01 Open ora.ron.srvron1.svc 1 ONLINE ONLINE oel55sv01 ------------------------------------------------------------
(B) Omotion ( 開始直後 )
------------------------------------------------------------ ora.ron.db 1 ONLINE ONLINE oel55sv01 Open 2 ONLINE OFFLINE ora.ron.srvron1.svc 1 ONLINE ONLINE oel55sv01 ------------------------------------------------------------
※ Omotion の処理が始まると同時に 移動先のノードで Oracle
インスタンスの起動処理が始まります。ただし STATE はまだ
OFFLINE です。
(C) Omotion ( 移動先のインスタンス起動終了 )
------------------------------------------------------------ ora.ron.db 1 ONLINE ONLINE oel55sv01 Open 2 ONLINE ONLINE oel55sv02 Open ora.ron.srvron1.svc 1 ONLINE ONLINE oel55sv01 ------------------------------------------------------------
※ 移動先のインスタンスが起動した時点で、一時的に 2 ノードの
RAC と同じ状態になります。
(D) Omotion ( 移動元のインスタンス停止処理開始 )
------------------------------------------------------------ ora.ron.db 1 OFFLINE ONLINE oel55sv01 Open 2 ONLINE ONLINE oel55sv02 Open ora.ron.srvron1.svc 1 ONLINE ONLINE oel55sv02 ------------------------------------------------------------
※ 移動元のインスタンスで終了処理が始まります。
と同時に、サービスのリソースが移動先のノード ( oel55sv02 )
へと切り替わります。
(E) Omotion ( 移動元のインスタンス停止処理終了 )
------------------------------------------------------------ ora.ron.db 1 OFFLINE OFFLINE Instance Shutdown 2 ONLINE ONLINE oel55sv02 Open ora.ron.srvron1.svc 1 ONLINE ONLINE oel55sv02 ------------------------------------------------------------
※ 移動元のインスタンスが停止しました。
(F) Omotion ( 移動元の処理終了 )
------------------------------------------------------------ ora.ron.db 2 ONLINE ONLINE oel55sv02 Open ora.ron.srvron1.svc 1 ONLINE ONLINE oel55sv02 ------------------------------------------------------------
※ 最後に、移動元のエントリが削除されて Omotion が終了します。
ところで、Omotion 自体の処理時間は先のとおり 2 分以上かかり
ました。（今回の検証環境では 2 分 40 秒程度）
実際にアプリケーションが接続できない時間がどのくらいなのか気
になります。 そこで 5 秒間隔で connect/disconnect を繰り返す
テストスクリプトでアプリケーションをシミュレートし、接続でき
なくなるタイミングを確認してみました。
(後述の「インスタンス接続テストスクリプト」参照)
上記 Omotion を実行した状態からの切り戻しで時間を確認してみま
す。
時刻、インスタンス名 と インスタンスのステータス が確認できて
いるタイミングでは接続できています。
TIME INSTANCE STATUS ---------- -------- ------ 14:57:13 RON_2 OPEN <<< Omotion 処理開始 (移動先指定) 14:57:18 RON_2 OPEN 14:57:23 RON_2 OPEN 14:57:28 RON_2 OPEN 14:57:34 RON_2 OPEN 14:57:39 RON_2 OPEN 14:57:45 RON_2 OPEN 14:57:50 RON_2 OPEN ERROR: ORA-01033: Oracleの初期化またはシャットダウン中です。 プロセスID: 0 セッションID: 0、シリアル番号: 0 : << : ERROR: ORA-01033: Oracleの初期化またはシャットダウン中です。 プロセスID: 0 セッションID: 0、シリアル番号: 0 14:58:27 RON_1 OPEN 14:58:32 RON_1 OPEN 14:58:38 RON_1 OPEN 14:58:43 RON_1 OPEN 14:58:49 RON_2 OPEN <<< 一時的に元のインスタンスへも接続 14:58:54 RON_1 OPEN 14:59:00 RON_1 OPEN 14:59:05 RON_1 OPEN 14:59:10 RON_1 OPEN 14:59:16 RON_1 OPEN 14:59:21 RON_1 OPEN 14:59:26 RON_1 OPEN 14:59:31 RON_1 OPEN 14:59:36 RON_1 OPEN 14:59:41 RON_1 OPEN 14:59:47 RON_1 OPEN 14:59:52 RON_1 OPEN <<< Omotion 処理終了 ---------- -------- ------
Omotion 処理開始(14:57:13)から終了(14:59:52)までは、およそ
2 分 39 秒 です。
その中で DB への接続が途絶えてしまう時間は、14:57:50 から
14:58:27 の約 32 秒でした。
# 上記の間隔は 37 秒ですが、インターバルの 5 秒を引いて誤差
# を相殺しています。
# また必ずしも 30 ～ 40 秒程度で終了するとは限らないようです。
# サービスの切替のタイミングで一時的に接続ができなくなるケー
# スも確認しています。
# 断続的ではありますが、接続できない時間の合計は最長で 60～
# 90 秒程度になるかもしれません。
上記で接続できなくなるタイミングは、移行先のインスタンスが起
動し終わったころとほぼ同じタイミングでした。
その後、一時的に移行先と移行元のインスタンスがともに起動した
状態になります。
その間は接続先がいずれかのインスタンスに振り分けられるようで、
移行先・移行元のそれぞれのインスタンス名が確認されました。
実際 REMOTE_LISTENER パラメータも設定されているため、リスナー
ロードバランスが有効な状態です。
さて少々長くなりましたので、今回はここまでです。
次回も引き続きインスタンスの移動に関する検証を行います。
==
補足1「インスタンス接続テストスクリプト」
------------------------------- #!/bin/sh while : ; do sqlplus -s system/******@ron <<_EOF_ set head off set linesize 200 col time for a8 col instance_name for a7 col status for a7 select to_char(systimestamp,'hh24:mi:ss') time ,instance_name ,status from v$instance ; exit _EOF_ sleep 5 done exit -------------------------------
補足2「接続識別子」
——————————-
上記、スクリプト内に記述している connect で指定している接続
識別子は、 DBCA で DB 構築時に作成される tnsnames.ora の設定
をそのまま利用しています。
HOST で指定されている “oel55sv-cluster-scan” は SCAN名です。
SCANとは Single client Access Name の略称で 11gR2 の新機能
です。
SCAN名はクラスタワイドに設定される名称で、クラスタ配下のサー
バに対してその物理的な位置を意識しなくてもSCAN名を指定する
ことで接続できるようになります。
従来の仮想IPと似ていますが、ノード数と同じだけ必要ではありま
せん。クラスタ配下のノード数が増えてきたときなど IP アドレス
の管理などが容易になりそうです。
(oracle)
$ORACLE_HOME/network/admin/tnsnames.ora ------------------------------------------------------ RON = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = oel55sv-cluster-scan)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = RON) ) ) ------------------------------------------------------