| 1ページ 2ページ 3ページ
Oracle VMおよびOracle Enterprise Linuxでの独自のOracle RAC拡張クラスタの構築（続き）
このガイドに記載されている情報については、オラクルによる検証またはサポートはおこなわれていません。これらの情報は、ご自身の責任において、学習目的でのみご使用ください。
9. フェイルオーバー機能のテスト
前述の orajdbcstat（執筆時点ではベータ版）と呼ばれる無償のGPL-d Javaアプリケーションを使用することで、障害が発生した場合（およびパフォーマンスの評価時）にクライアントでインスタンスを切り替える方法を簡単に確認することができます。
ERAC1におけるインスタンス障害
まず、アイドル状態にあるデータベースでorajdbcstatを実行します。
[vnull@xeno orajdbcstat]$
./orajdbcstat.sh -d ERAC -i ERAC1 -i ERAC2 1
------ ------conntime------ -----------stmt-------------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
15:35:22 ERAC 2 0 49 1 3 0 2 2 0
15:35:22 +ERAC1 1 0 45 1 19 0 2 2 0
15:35:22 +ERAC2 2 0 60 2 4 0 2 14 0
15:35:23 ERAC 1 0 44 1 3 0 2 3 0
15:35:23 +ERAC1 1 0 65 1 2 0 2 3 0
15:35:23 +ERAC2 2 0 46 2 3 0 3 2 0
[..utility still running, output trimmed for clarity..]
|
上記の出力から、メイン・スレッド（"ERAC" TNS記述子）が番号1のインスタンスに接続されていることがわかります。"conntime"には、RACインスタンスと主要なTNS記述子に対する新規接続のタイミングが示されています（また、フェイルオーバー機能に"tcpping"が現在実装されていないことも表示されています）。 "stmt"の下の項目では、FCF（高速接続フェイルオーバー）プールからの接続、つまり現在のRACインスタンス数と単純なSQL文のタイミングを監視できます。 コマンドラインの最後の"1"は、orajdbcstatにおいて統計が1秒ごとに出力されるように指定するものです。
以下のコマンドを実行し、番号1のRACインスタンスのクラッシュをシミュレートします。
[oracle@rac1 ~]$
srvctl stop instance -d erac -i erac1 -o abort
[oracle@rac1 ~]$
|
orajdbcstatによるSSHセッションでは、以下の出力が得られます（説明は抜粋の下にあります）。
15:36:55 ERAC 1 0 45 1 3 0 1 3 0
15:36:55 +ERAC1 1 0 42 1 43 0 2 2 0
15:36:55 +ERAC2 2 0 49 2 3 0 4 2 0
------ ------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
15:36:56 ERAC 2 0 49 1->X [ E!17008 ]
15:36:56 +ERAC1 -1 E!01092 E!01092 1->X [ E!17008 ]
15:36:56 +ERAC2 2 0 67 2 17 0 4 2 0
15:36:57 ERAC 2 0 46 X->2 [ E!17008 ]
15:36:57 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:36:57 +ERAC2 2 0 67 2 17 0 4 2 0
15:36:58 ERAC 2 0 46 X->2 [ E!17008 ]
15:36:58 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:36:58 +ERAC2 2 0 67 2 17 0 4 2 0
15:36:59 ERAC 2 0 46 X->2 [ E!17008 ]
15:36:59 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:36:59 +ERAC2 2 0 67 2 17 0 4 2 0
15:37:00 ERAC 2 0 46 X->2 [ E!17008 ]
15:37:00 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:00 +ERAC2 2 0 67 2 17 0 4 2 0
15:37:01 ERAC 2 0 56 2 12 0 7 3 0
15:37:01 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:01 +ERAC2 2 0 51 2 131 0 5 3 0
15:37:02 ERAC 2 0 59 2 178 0 17 29 0
15:37:02 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:02 +ERAC2 2 0 73 2 121 0 203 36 0
------ ------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
15:37:03 ERAC 2 0 68 2 2 0 3 2 0
15:37:03 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:03 +ERAC2 2 0 45 2 3 0 2 3 0
15:37:04 ERAC 2 0 48 2 7 0 3 2 0
15:37:04 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:04 +ERAC2 2 0 86 2 2 0 3 4 0
15:37:05 ERAC 2 0 47 2 2 0 3 2 0
15:37:05 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:05 +ERAC2 2 0 53 2 3 0 3 3 0
15:37:06 ERAC 2 0 48 2 3 0 2 2 0
15:37:06 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:06 +ERAC2 2 0 46 2 10 0 2 10 0
15:37:07 ERAC 2 0 48 2 2 0 3 3 0
15:37:07 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:07 +ERAC2 2 0 83 2 10 0 3 2 0
15:37:08 ERAC 2 0 48 2 3 0 2 2 0
15:37:08 +ERAC1 -z E!12521 E!12521 X [ E!17008 ]
15:37:08 +ERAC2 2 0 50 2 2 0 3 2 0
15:37:09 ERAC 2 0 48 2 2 0 2 2 0
15:37:09 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:09 +ERAC2 2 0 44 2 3 0 2 3 0
[..utility still running, output trimmed for clarity..]
|
ここでは以下の処理がおこなわれています。
- 15:36:56に、ERAC1に対するすべての新規接続についてのエラー検出が開始し、それと同時にERAC1に対するFCFプールの全接続における通常のアクションが停止しています。 また、メイン・データベース（ERAC TNS記述子）のFCFプールで障害が検出され、そのあとフェイルオーバーが開始しています。
- 15:36:57（障害発生の1秒後）に、メインのFCFプールによりRAC#2インスタンスへの再接続が開始しています（"X->2"）。
- 15:37:00から15:37:01（障害発生の4～5秒後）には、使用可能な状態にあるERAC2インスタンスへのFCFプール接続が再構築されています。
"E!NNNNN"文字列は、SQL接続においてORA-NNNNNというエラーが発生したことを示しています。 （エラーをデコードする場合は、Oracle error utilityを使用してください。） リカバリ（インスタンスERAC1の開始）後は、次のようになります。
15:47:37 ERAC 2 0 64 2 3 0 2 3 0
15:47:37 +ERAC1 -1 E!01033 E!01033 X [ E!17008 ]
15:47:37 +ERAC2 2 0 57 2 8 0 13 1 0
15:47:38 ERAC 2 0 54 2 3 0 3 2 0
15:47:38 +ERAC1 1 0 481 X->1 [ E!17008 ]
15:47:38 +ERAC2 2 0 52 2 3 0 2 4 0
------ ------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
15:47:39 ERAC 2 0 54 2 3 0 3 2 0
15:47:39 +ERAC1 1 0 167 1 14 0 4 2 0
15:47:39 +ERAC2 2 0 56 2 8 0 27 3 0
|
上記の出力からわかるとおり、ERAC1のFCFプールでは、手動による操作をおこなうことなくインスタンスが起動し、動作が再開していることが検出されています。
致命的なサイト障害
拡張RACクラスタ構築のおもな目的は、致命的な影響を及ぼすサイト障害（RACノードおよびSANのクラッシュ）を切り抜ける能力を得ることです。ここで再度、ワークステーションからorajdbcstatを起動します。
------ ------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
17:24:18 ERAC 1 0 46
2 11 0 2 2 0
17:24:18 +ERAC1 1 0 45 1 4 0 3 2 0
17:24:18 +ERAC2 2 0 46 2 4 0 3 3 0
17:24:19 ERAC 1 0 45
2 2 0 4 3 0
17:24:19 +ERAC1 1 0 44 1 15 0 3 2 0
17:24:19 +ERAC2 2 0 44 2 3 0 3 3 0
|
ここでは、メインのFCFプールでRAC#2インスタンスが使用されていることがわかります。このため、RAC#2サイト全体（iscsi2およびrac2ノード）をクラッシュさせてみます。
[root@quadovm ~]#
xm list
Name ID Mem VCPUs State Time(s)
132_rac1 1 2048 1 -b---- 1845.0
134_rac2 6 2048 1 r----- 152.2
Domain-0 0 512 4 r----- 665.3
iscsi1 3 768 1 -b---- 194.0
iscsi2 5 768 1 -b---- 44.3
[root@quadovm ~]#
xm destroy 134_rac2 && date && xm destroy iscsi2 && date
Sat May 31 17:25:55 CEST 2008
Sat May 31 17:25:56 CEST 2008
[root@quadovm ~]#
|
ここで、orajdbcstatセッションに戻ります。
17:25:56 ERAC 2 0 44 2 3 0 3 2 0
17:25:56 +ERAC1 1 0 79 1 8 0 3 2 0
17:25:56 +ERAC2 2 0 44 2 11 0 3 2 0
17:25:57 ERAC 2 0 44 2 3 0 3 2 0
17:25:57 +ERAC1 1 0 79 1 8 0 3 2 0
17:25:57 +ERAC2 2 0 44 2 11 0 3 2 0
17:25:58 ERAC 2 0 44 2 3 0 3 2 0
17:25:58 +ERAC1 1 0 79 1 8 0 3 2 0
17:25:58 +ERAC2 -1 E!12170 E!12170 2 11 0 3 2 0
17:25:59 ERAC 2 0 44 2 3 0 3 2 0
17:25:59 +ERAC1 1 0 79 1 8 0 3 2 0
17:25:59 +ERAC2 -1 E!12170 E!12170 2 11 0 3 2 0
------ ------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
17:26:00 ERAC 2 0 44 2 3 0 3 2 0
17:26:00 +ERAC1 1 0 79 1 8 0 3 2 0
17:26:00 +ERAC2 -1 E!12170 E!12170 2 11 0 3 2 0
17:26:01 ERAC 2 0 44 2 3 0 3 2 0
17:26:01 +ERAC1 1 0 79 1 8 0 3 2 0
17:26:01 +ERAC2 -1 E!12170 E!12170 2 11 0 3 2 0
17:26:02 ERAC 2 0 44 2 3 0 3 2 0
17:26:02 +ERAC1 1 0 79 1 8 0 3 2 0
17:26:02 +ERAC2 -1 E!12170 E!12170 2 11 0 3 2 0
17:26:03 ERAC 2 0 44 2 3 0 3 2 0
17:26:03 +ERAC1 1 0 79 1 8 0 3 2 0
17:26:03 +ERAC2 -1 E!12170 E!12170 2->X [ E!03113 ]
17:26:04 ERAC -1 E!12170 E!12170 2 3 0 3 2 0
17:26:04 +ERAC1 1 0 43 X [ E!03113 ]
17:26:04 +ERAC2 -1 E!12170 E!12170 2->X [ E!03113 ]
17:26:05 ERAC -1 E!12170 E!12170 2 3 0 3 2 0
17:26:05 +ERAC1 1 0 43 X->1 [ E!03113 ]
17:26:05 +ERAC2 -1 E!12170 E!12170 2->X [ E!03113 ]
17:26:06 ERAC -1 E!12170 E!12170 2 3 0 3 2 0
17:26:06 +ERAC1 1 0 43 X->1 [ E!03113 ]
17:26:06 +ERAC2 -1 E!12170 E!12170 2->X [ E!03113 ]
|
上記から、ERAC1インスタンスを含め、拡張RAC全体がブロックされていることがわかります。 これは、ERAC1インスタンス（おもにDBWRおよびLGWR）が、書込み不可能なiscsi2のiSCSIストレージに対して書込みのリトライを続けているためです。 TCP iSCSI接続でiSCSIタイムアウトが発生した場合、I/OエラーはOracleソフトウェア（Oracle Clusterware、Oracle ASM、およびOracle Database）に返されます。
これまで見てきたように、rac1とrac2のiSCSIスタックは120秒でリトライするように構成されています（/etc/iscsi/iscsid.confのパラメータnode.session.timeo.replacement_timeout）。 この120秒間に、カーネルによるI/O操作のリトライがおこなわれると同時に、すべてのアプリケーションにおいて、ハングしていると考えられるストレージに対してfiledescriptors（fd）が使用されます。 詳細については、dmesgコマンドとOracle ASMのアラート・ログ・ファイルの出力で確認できます。
このあと、以下の出力が表示されます。
17:28:17 ERAC -1 E!12571 E!12571 X [ E!03113 ]
17:28:17 +ERAC1 1 0 43 X->1 [ E!03113 ]
17:28:17 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:18 ERAC -1 E!12571 E!12571 X [ E!03113 ]
17:28:18 +ERAC1 1 0 75 X [ E!03113 ]
17:28:18 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:19 ERAC -1 E!12571 E!12571 X [ E!03113 ]
17:28:19 +ERAC1 1 0 91 X->1 29 0 23 23 0
17:28:19 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:20 ERAC -1 E!12571 E!12571 X [ E!03113 ]
17:28:20 +ERAC1 1 0 43 1 8 0 4 1 0
17:28:20 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:21 ERAC -1 E!12571 E!12571 X [ E!03113 ]
17:28:21 +ERAC1 1 0 42 1 8 0 4 2 0
17:28:21 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:22 ERAC -1 E!12571 E!12571 X->1 4 0 8 9 0
17:28:22 +ERAC1 1 0 42 1 7 0 2 2 0
17:28:22 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
------------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
17:28:23 ERAC 1 0 45 1 3 0 3 3 0
17:28:23 +ERAC1 1 0 43 1 2 0 3 2 0
17:28:23 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:24 ERAC 1 0 43 1 2 0 2 2 0
17:28:24 +ERAC1 1 0 43 1 2 0 2 2 0
17:28:24 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:25 ERAC 1 0 44 1 19 0 3 2 0
17:28:25 +ERAC1 1 0 43 1 2 0 3 2 0
17:28:25 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:26 ERAC 1 0 44 1 3 0 2 3 0
17:28:26 +ERAC1 1 0 43 1 2 0 1 2 0
17:28:26 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:27 ERAC 1 0 43 1 3 0 1 2 0
17:28:27 +ERAC1 1 0 42 1 2 0 3 2 0
17:28:27 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:28 ERAC 1 0 43 1 8 0 3 2 0
17:28:28 +ERAC1 1 0 43 1 4 0 3 2 0
17:28:28 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
|
ここでは、次のような処理がおこなわれています。
- 17:28:17から17:28:19までの間（障害発生から2分14秒後）は、ERAC1 TNSにおける新しい接続の再構築が可能となっています。
- 17:28:19（障害発生から2分16秒後）、ERAC1 FCFプールは正常に機能しています。
- 17:28:19から17:28:22まで（障害発生から2分16秒後）には、マスターERAC FCFプールでERAC1に対するフェイルオーバーが試行されています。
- 17:28:22（障害発生から2分19秒後）に、マスターERAC FCFプールでのERAC1に対するフェイルオーバーに成功します。 この時点で、すべての接続が正常に動作しています。 障害グループDATA1_0001では、ディスクのマウント・ステータスがCACHEDからMISSINGに変更されています。
SQL>
col path format a36
SQL>
col diskgroup format a10
SQL>
col failgroup format a10
SQL>
SELECT path, dg.name diskgroup, failgroup, mount_status, mode_status FROM v$asm_disk d JOIN v$asm_diskgroup dg ON (d.group_number=dg.group_number) ORDER BY 1;
PATH DISKGROUP FAILGROUP MOUNT_S MODE_ST
------------------------------------ ---------- ---------- ------- -------
/dev/iscsi/racdata1.asm1/lun0/part1 DATA1 DATA1_0000 CACHED ONLINE
DATA1 DATA1_0001 MISSING OFFLINE
SQL>
|
待機時間の影響とパフォーマンス低下
警告： ここに記載されているテストは、このガイドの目的のために設計されたものであり、本番環境での実際のテストではなく、拡張RACクラスタについての実際のパフォーマンス評価に値するものではありません。
拡張RAC構成の重要な要素として、RACノードとストレージ・アレイ間の距離があります。 この問題を解決するにあたって、高価なハードウェアを使用することなく待機時間のシミュレーションをおこなうために、ここではLinuxに組み込まれたネットワーク・トラフィック・シェイピング機能を使用します。この機能は、QoS（Quality of Source）と呼ばれることもあります。 ここではSANの構成がiSCSIに基づいているため、この地理的な要素により発生する可能性がある問題は、イーサネット・レイヤーでの不規則な待機時間、パケットの再配列、パケット・ドロップなどとなります。 （これはNFSの場合も当てはまり、現在開発されているFcoEにも同じことがいえる可能性があります。） また、RACノード間のインターコネクトの場合も同様です。
このシナリオでは、dom0の内部Xenネットワーク・デバイスを構成し、複数の仮想マシン間で遅延が発生するようにします。 Linuxのトラフィック・シェイピングを構成するためのおもなユーティリティは、"tc"（Traffic Controlの頭文字から）と呼ばれています。 問題が生じるのは、詳細に目を向けたときです。 標準のOracle VM Server dom0カーネルは、250HZで実行しています。つまり、dom0のカーネル内の時間関連の処理はすべて4ミリ秒の間隔でおこなわれていることになります。 Linux netemのキューイング制御によって発生する遅延は、カーネルの周波数によって異なるため、1ミリ秒の遅延をシミュレートするには、異なる周波数の設定によるカーネルを使用する必要があります（1ミリ秒の遅延のシミュレーションを適切におこなうには、少なくとも1,000Hzのカーネルが必要です）。
カーネルのコンパイルは手間のかかる作業であるため、実行準備済みのdom0カーネルRPMを こちらからダウンロードすることをお勧めします。 dom0 Xenカーネルの構築手順については、このあと"Oracle VM Server 2.1 Xen dom0用のカーネルの構築"の項で簡単に説明します。 この項では、新しいカーネルのインストール手順もあわせて解説します。
Xenネットワーク・インタフェースで遅延が発生するように構成する場合、qosracinit.plと呼ばれる簡単なスクリプトが利用できます。ここでは、これをdom0で実行しました。 qosracinit.plは、 こちらからダウンロードできます。
各自の環境を反映するように変数を変更してから、以下を実行します。
[root@quadovm ~]#
./qosracinit.pl > /tmp/qos && bash /tmp/qos
[root@quadovm ~]#
|
あらゆる遅延を回避するQoSルールを消去するため、以下を実行します。
[root@quadovm ~]#
./qosracinit.pl clear > /tmp/qos && bash /tmp/qos
[root@quadovm ~]#
|
テストは、Dominic Gilesによる Swingbench 2.3のOrder Entryベンチマークを使用して実行しました。 Swingbenchの設定は、Oracle RAC環境で使用できる簡単なものです。 "最小思考"時間および"最大思考"時間は、このインストールで実行される可能性のあるトランザクション処理を完全に活用するために、0に設定されています。 （"思考"時間は、次のトランザクションを遅らせるために必要な時間です。）
今回のテストでは、15のJDBC接続で構成された2つの負荷生成装置（Minibench）により、個々のRACノードに負荷をかけています。 負荷生成装置は、"xeno"ワークステーションから実行しました。 SOEユーザーとしてレポートされた実際のデータベースのサイズは、以下のようになります。
SQL>
conn soe/soe
Connected.
SQL>
select sum(bytes)/1024/1024 mb from user_segments;
MB
----------
2250.72656
SQL>
|
おもなパラメータの設定には、以下の値を使用しました。
- sga_target = 1G
- db_cache_size = 512M
- pga_aggregate_target = 256M
- memory_target = 0（無効）
ここでは、db_cache_sizeの設定を低くすることで、OracleデータベースでインターコネクトとSANに強制的に負荷をかけ、待機時間の影響にさらされるように設定しています。
待機時間なしの場合
まず、仮想マシン間の実際の待機時間を測定します。 （注：すべてのpingテストは、Swingbenchの完全ロード時に収集したものです。）
[oracle@rac2 ~]$
ping -c 10 -i 0.2 -q -s 1200 10.97.1.1; ping -c 10 -i 0.2 -q -s 1200 10.98.1.101; ping -c 10 -i 0.2 -q -s 1200 10.98.1.102
PING 10.97.1.1 (10.97.1.1) 1200(1228) bytes of data.
--- 10.97.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1816ms
rtt min/avg/max/mdev = 0.067/
0.091/0.113/0.018 ms
PING 10.98.1.101 (10.98.1.101) 1200(1228) bytes of data.
--- 10.98.1.101 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1804ms
rtt min/avg/max/mdev = 0.083/
0.106/0.132/0.020 ms
PING 10.98.1.102 (10.98.1.102) 1200(1228) bytes of data.
--- 10.98.1.102 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1799ms
rtt min/avg/max/mdev = 0.079/
0.108/0.193/0.034 ms
[oracle@rac2 ~]$
|
このテストにより、RAC2と以下の3つとの間で発生する待機時間が示されます。
- 10.97.1.1（インターコネクトを介したRAC1）
- 10.98.1.101（SANを介したiscsi1 OpenFiler）
- 10.98.1.102（SANを介したiscsi2 OpenFiler）
ICMPでは、1,200バイトを使用してパケットをエコーしています。 ここでは、拡張RACの重要な要素となるため、平均のラウンドトリップ時間に注目します。 以下の結果からわかるように、ベンチマークは5460 TPM以下となっています。
[oracle@rac1 ~]$
sqlplus -s / as sysdba @tpm
6356
5425
4924
5162
5430
Average = 5459.4
PL/SQL procedure successfully completed.
[oracle@rac1 ~]$
|
次に、トレーニング・システム上で待機時間を発生させ、それによるシステムへの実際の影響を確認します。 この処理をおこなうには、以下に示すtpm.sqlスクリプトを使用します。
set termout on
set echo off
set serveroutput on
DECLARE
val1 NUMBER;
val2 NUMBER;
diff NUMBER;
average NUMBER := 0;
runs NUMBER := 5;
BEGIN
FOR V IN 1..runs LOOP
SELECT SUM(value) INTO val1
FROM gv$sysstat WHERE name IN ('user commits','transaction rollbacks');
DBMS_LOCK.SLEEP(60);
SELECT SUM(value) INTO val2
FROM gv$sysstat WHERE name IN ('user commits','transaction rollbacks');
diff := val2-val1;
average := average + diff;
DBMS_OUTPUT.PUT_LINE(diff);
END LOOP;
DBMS_OUTPUT.PUT_LINE('Average = ' || average/runs);
END;
/
exit
|
1ミリ秒の待機時間を発生させる場合
前述の手順でおこなったように、まず、実際の平均ラウンドトリップ時間を測定します。
[oracle@rac2 ~]$
ping -c 10 -i 0.2 -q -s 1200 10.97.1.1; ping -c 10 -i 0.2 -q -s 1200 10.98.1.101; ping
-c 10 -i 0.2 -q -s 1200 10.98.1.102
PING 10.97.1.1 (10.97.1.1) 1200(1228) bytes of data.
--- 10.97.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1809ms
rtt min/avg/max/mdev = 2.693/
3.482/3.863/0.389 ms
PING 10.98.1.101 (10.98.1.101) 1200(1228) bytes of data.
--- 10.98.1.101 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1854ms
rtt min/avg/max/mdev = 2.481/
3.850/6.621/1.026 ms
PING 10.98.1.102 (10.98.1.102) 1200(1228) bytes of data.
--- 10.98.1.102 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1812ms
rtt min/avg/max/mdev = 0.080/
0.135/0.233/0.051 ms
[oracle@rac2 ~]$
|
上記の出力から、Linuxのネットワーク・キューに1ミリ秒を追加すると、実際の平均ラウンドトリップ時間が最大で3.5ミリ秒から3.8ミリ秒増加したことがわかります。 これは、送信ICMPエコー・リクエスト・パケットが約1ミリ秒遅延し、応答側からの返信も1ミリ秒遅れているためです。残りの2ミリ秒近くについては、システム全体をロードしているときに、オーバーブッキングされていたシステム上でXenスケジューリングのコンテキストを切り替えたためだと考えられます。 （注：ここでは、4つの仮想マシンをシミュレートしていますが、本番環境での実際のIO処理は、クアッドコアのCPUマシン上で実行されている5番目の仮想マシン、dom0によって実行されています。）
[oracle@rac1 ~]$
sqlplus -s / as sysdba @tpm
5173
5610
5412
5094
5624
Average = 5382.6
PL/SQL procedure successfully completed.
[oracle@rac1 ~]$
|
3ミリ秒の待機時間を発生させる場合
[oracle@rac2 ~]$
ping -c 10 -i 0.2 -q -s 1200 10.97.1.1; ping -c 10 -i 0.2 -q -s 1200 10.98.1.101; ping
-c 10 -i 0.2 -q -s 1200 10.98.1.102
PING 10.97.1.1 (10.97.1.1) 1200(1228) bytes of data.
--- 10.97.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1819ms
rtt min/avg/max/mdev = 6.326/
7.631/9.839/0.881 ms
PING 10.98.1.101 (10.98.1.101) 1200(1228) bytes of data.
--- 10.98.1.101 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1806ms
rtt min/avg/max/mdev = 6.837/
7.643/8.544/0.426 ms
PING 10.98.1.102 (10.98.1.102) 1200(1228) bytes of data.
--- 10.98.1.102 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1801ms
rtt min/avg/max/mdev = 0.076/
0.149/0.666/0.172 ms
[oracle@rac2 ~]$
|
上記のテスト結果から、Xenのスケジューリング機能とシステムのオーバーブッキングによって1.5から2ミリ秒が追加されているものと結論づけることができます（7.5ミリ秒 – 2x3ミリ秒 = 1.5ミリ秒）。
[oracle@rac1 ~]$
sqlplus -s / as sysdba @tpm
5489
4883
5122
5512
4965
Average = 5194.2
PL/SQL procedure successfully completed.
[oracle@rac1 ~]$
|
上記の結果では、人為的なテスト環境において、待機時間のある場合で最大5200 TPM、待機時間のない場合では最大5460 TPMのパフォーマンス低下が発生したことがわかります。
10. トラブルシューティングおよびそのほかの情報
この項では、拡張RACのアーキテクチャ実装時に発生する可能性のある各種の問題について取り上げます。
Oracle RACへの接続時のORA-12545の回避
新しく構成したOracle RACクライアントに接続すると、ORA-12545エラー（"Connect failed because target host or object does not exist"）が発生する場合があります。 これを解決するには、各インスタンスのLOCAL_LISTENERパラメータを個別に修正します。
SQL>
ALTER SYSTEM SET local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=10.99.1.91)(PORT=1521))' SID='erac1';
System altered.
SQL>
ALTER SYSTEM SET local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=10.99.1.92)(PORT=1521))' SID='erac2';
System altered.
|
また代替手段として、DNSを設定してRACノードを登録する方法や、クライアントを再構成してOracle RACホスト名をIPアドレスにする方法もあります。ホスト名をIPアドレスに変更する場合は、UNIXなどのJDBCクライアントで、該当するホスト名を/etc/hostsに追加します。
10.99.1.191 vmrac1-vip vmrac1
10.99.1.192 vmrac2-vip vmrac2
|
Oracle VM Server 2.1 Xen dom0用のカーネルの構築
筆者の経験では、dom0カーネルをセルフコンパイルするには、Oracle VMに以下のRPMがアップロードされるようにする必要があります。
[vnull@xeno Downloads]$
scp -r RPMS_OVM21_kernel_compile root@10.99.1.2:.
root@10.99.1.2's password:
m4-1.4.5-3.el5.1.i386.rpm 100% 133KB 133.2KB/s 00:00
rpm-build-4.4.2-37.el5.0.1.i386.rpm 100% 547KB 547.5KB/s 00:00
kernel-2.6.18-8.1.6.0.18.el5.src.rpm 100% 48MB 9.6MB/s 00:05
kernel-headers-2.6.18-8.el5.i386.rpm 100% 723KB 723.5KB/s 00:00
glibc-devel-2.5-12.i386.rpm 100% 2034KB 2.0MB/s 00:00
elfutils-0.125-3.el5.i386.rpm 100% 164KB 163.7KB/s 00:00
glibc-headers-2.5-12.i386.rpm 100% 605KB 604.6KB/s 00:00
patch-2.5.4-29.2.2.i386.rpm 100% 64KB 64.0KB/s 00:00
redhat-rpm-config-8.0.45-17.el5.0.1.noarch.rpm 100% 52KB 52.5KB/s 00:00
libgomp-4.1.1-52.el5.i386.rpm 100% 69KB 69.3KB/s 00:00
cpp-4.1.1-52.el5.i386.rpm 100% 2673KB 2.6MB/s 00:01
gcc-4.1.1-52.el5.i386.rpm 100% 5067KB 5.0MB/s 00:00
elfutils-libs-0.125-3.el5.i386.rpm 100% 105KB 105.2KB/s 00:00
[vnull@xeno Downloads]$
|
次に、インストール・パッケージをコピーしてから、そのパッケージをOracle VM Serverにインストールします。
[root@quadovm RPMS_OVM21_kernel_compile]#
rpm -Uhv *.rpm
[..]
[root@quadovm ~]#
cd /usr/src/redhat/SPECS/
[root@quadovm SPECS]#
vi kernel-2.6.spec
|
カーネル2.6.のスペックでは、以下の変数を設定する必要があります。
- %define buildboot 0
- %define buildxenovs 1
[root@quadovm SPECS]#
rpmbuild -bp --target=`uname -m` kernel-2.6.spec
Building target platforms: i686
Building for target i686
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.29959
+ umask 022
[..]
[root@quadovm SPECS]#
cd ../BUILD/kernel-2.6.18/linux-2.6.18.i686/
[root@quadovm linux-2.6.18.i686]#
grep HZ .config
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_MACHZ_WDT=m
CONFIG_NO_IDLE_HZ=y
[root@quadovm linux-2.6.18.i686]#
vi .config
|
.configを以下のように編集し、周波数が1,000Hzに設定されていることを確認します。
# CONFIG_HZ_100：未設定
# CONFIG_HZ_250：未設定
CONFIG_HZ_1000 = y
CONFIG_HZ = 1000
以下のようにMakefileを編集し、新規カーネルを区別して構築します。
[root@quadovm linux-2.6.18.i686]#
vi Makefile
change
EXTRAVERSION to e.g.:
-8.1.6.0.18.el5xen_vnull03
[root@quadovm linux-2.6.18.i686]#
make oldconfig
[..]
[root@quadovm linux-2.6.18.i686]#
make config
[..disable KERNEL DEBUG!...]
[root@quadovm linux-2.6.18.i686]#
make rpm
scripts/kconfig/conf -s arch/i386/Kconfig
[..]
|
新規に構築したカーネルは、/usr/src/redhat/RPMS/i386ディレクトリで使用可能な状態になります。
新規カーネルのインストール
新規カーネルのインストールは日常的に発生する処理ですが、セルフコンパイルされたカーネルではgrubbyインストーラを使用しないため、一部のカーネルのインストール・ステップについては手動で実行する必要があります。
[root@quadovm ~]#
rpm -ihv kernel-2.6.188.1.6.0.18.el5xen_vnull03-1.i386.rpm
Preparing... ########################################### [100%]
1:kernel ########################################### [100%]
[root@quadovm ~]#
depmod -a 2.6.18-8.1.6.0.18.el5xen_vnull03
[root@quadovm ~]#
mkinitrd /boot/initrd-2.6.18-8.1.6.0.18.el5xen_vnull03.img 2.6.18-8.1.6.0.18.el5xen_vnull03
|
次に、GRUBブート・ローダーを変更し、新規カーネルをブートする必要があります。
[root@quadovm ~]#
cd /boot/grub
[root@quadovm grub]#
vi menu.lst
|
まず、menu.lstファイルで、default=0のように、デフォルトが"0"に設定されていることを確認します。この設定により、デフォルトで、menu.lst内で最初に検出されたカーネル・エントリがブートされることになります。以下のGRUBカーネルの構成エントリを最初に（ほかのエントリの直前に）配置します。
title Oracle VM Server vnull03
root (hd0,0)
kernel /xen.gz console=ttyS0,57600n8 console=tty dom0_mem=512M
module /vmlinuz-2.6.18-8.1.6.0.18.el5xen_vnull03 ro root=/dev/md0
module /initrd-2.6.18-8.1.6.0.18.el5xen_vnull03.img
|
致命的なサイト障害からの迅速なリカバリ
ここでは、シミュレートした障害のあと、iscsi2アレイとrac2ノードが完全に機能するように復旧する手順を簡単に説明します。 注：このシナリオでは、障害発生前はiscsi2のLUNに配置されていたOCRミラーが失われています。
- システムiscsi2を起動します（たとえば、/OVS/running_pool/64_iscsi2でxm create vm.cfgを実行することで起動できます）。
- rac1ノードで、iscsi2に対するiSCSI接続を回復させます（/var/log/messagesに、"iscsid: connection4:0 is operational after recovery (314 attempts)"というようなメッセージが表示されます）。
- ALTER DISKGROUP DATA1 ONLINE ALLon +ASM1インスタンスを実行します。
- 不足している障害グループの同期が実行され、以下のようになります。
PATH DISKGROUP FAILGROUP MOUNT_S MODE_ST
------------------------------------ ---------- ---------- ------- -------
/dev/iscsi/racdata1.asm1/lun0/part1 DATA1 DATA1_0000 CACHED ONLINE
/dev/iscsi/racdata2.asm1/lun0/part1 DATA1 DATA1_0001 CACHED SYNCING
|
- しばらくすると、Oracle ASM障害グループが完全に処理可能な状態となります（MODE_STATUS=ONLINE）。
- 投票ディスクが、CSSデーモンによって自動的にオンライン化されます。
- Ocrcheckにより、OCRミラーの1つが同期されていないことが示されます。
[root@rac1 bin]#
./ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 2
Total space (kbytes) : 327188
Used space (kbytes) : 3848
Available space (kbytes) : 323340
ID : 2120916034
Device/File Name : /dev/iscsi/racdata1.ocr/lun0/part1
Device/File integrity check succeeded
Device/File Name : /dev/iscsi/racdata2.ocr/lun0/part1
Device/File needs to be synchronized with the other device
Cluster registry integrity check succeeded
[root@rac1 bin]#
|
- これは、ocrconfigを実行するだけで修正できます。実行後の同期化された新しいOCRミラー（置換え処理中のアクション）に関する情報は、/u01/app/crs/log/rac1/crsd/crsd.logで確認できます。
[root@rac1 bin]#
./ocrconfig -replace ocrmirror /dev/iscsi/racdata2.ocr/lun0/part1
[root@rac1 bin]#
|
- システムrac2を起動すると、完全に機能する拡張クラスタが形成されます。
11. 次のステップ
RACクラスタの障害に対する耐性をさらに強化する方法は数多くあります。この1つに、Linuxのバウンディング・ドライバを使用して冗長なインターコネクトを作成する方法が挙げられます。 また、iSCSIによるIOマルチ・パスを使用することもできます。 パフォーマンス向上やテストのためには、より多くのディスクを使用できれば、それに越したことはありません。とくに、iSCSI OpenFilerシステム専用のディスクの場合は、少しでも多く使用することをお勧めします。
12. 謝辞
次の方々に感謝を申し上げます。
- Oracleの魅力を教えてくれた指導者、Radosław Mańkowski
- Poznan University of Technologyでのプロジェクトとして拡張RACについての論文記述を許可してくれた、Mariusz MasewiczとRobert Wrembel
- この文書の基盤となったRACインストールに関する過去最高の記事を著した、Jeffrey Hunter
- 拡張RACに関する（Direct）NFSについて技術的なディスカッションを示してくれた、Kevin Closson（ http://kevinclosson.wordpress.com/）とDan Norris（ http://www.dannorris.com/）
Jakub Wartak [ jakub.wartak@gmail.com]は、2008年2月にポーランドのPoznan University of Technologyでコンピュータ・サイエンスの学士号を取得し、現在はコンピュータ・サイエンス分野の理学修士取得を目指しています。 Oracle 10gのOracle Certified Associate（DBA）であると同時に、Sun認定Solaris 10システム管理者、Sun認定Solaris 10ネットワーク管理者でもあり、フリーランスのUNIX/Linux管理者としての経歴もあります。 また、2008年9月以降は、GlaxoSmithKlineでjunior DBAとして活躍しています。
1ページ 2ページ 3ページ
|
Articles
Printer View