Jump to content 日本-日本語
日本HPホーム 製品 & サービス サポート & ドライバー ソリューション ご購入方法
≫  お問い合わせ

製品とサービス  >  ソフトウェアとOS  >  HP- UX Developer Edge

Oracle RAC 10g+HP Serviceguardの勘どころ・後編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
Oracle RAC 10g+HP Serviceguardの勘どころ・後編
日本ヒューレット・パッカードと日本オラクルが共同運営する検証体制MC3(Mission Critical Certified Center)では、Oracle Real Application Clusters 10g(以下、RAC 10g)とServiceguard Extension for RAC(以下、SGeRAC)の組み合わせによる検証を行った。この検証作業では、ノード障害やインスタンス障害、ネットワーク障害などのさまざまなパターンが実際に再現され、RACとSGeRACの連携によりフェイルオーバを短縮可能なことが確認された。ここではMC3による報告をもとに、RACとSGeRAC連携のポイントや連携によるメリットを明らかにする。
Oracle RAC 10g+HP Serviceguardの勘どころ・後編
RAC+SGeRAC検証環境
ノード障害時の動作メカニズム
2004年10月
テクニカルライター 吉川和巳

RAC+SGeRAC検証環境


まずは今回のMC3による検証作業に用いられた環境を確認しておこう。図1を見ていただきたい。
  図1:HAクラスタとRACの違い
図1:検証環境の構成図
 

今回の検証では、2台のHP Integrity rx2600-2でクラスタを構成した。クラスタウェアとしては、Oracle Database 10g Enterprise Edition 10.1.0.2に付属のCRSをはじめ、SGeRAC 11.15およびRAC対応オプションSGeRAC 11.15を併用する。また共有ディスクとしてはHP StorageWorks Enterprise Virtual Array(以下、HP EVAディスクアレイ)を用意し、ボリュームマネージャにはHP-UXのLVMを利用している。

2台のノードは「Publicネットワーク」および「Privateネットワーク」という2つのネットワークによって結ばれている。Publicネットワークは、OracleクライアントがRACに接続するために利用される。一方Privateネットワークは、RACのGCS(Global Cache Service)による分散キャッシュ通信に加え、CRSやSGeRACのハートビート送受信、クラスタ再構成に用いられる。

またテスト用のOracleクライアントのtnsnames.oraファイルは、図2のように設定する。

 

―tnsnames.oraの設定―
CRM =
 (DESCRIPTION =
  (ADDRESS_UST =
   (ADDRESS = (PROTOCOL = TCP)(HOST = rac1_vip)(PORT = 1521))
   (ADDRESS = (PROTOCOL = TCP)(HOST = rac2_vip)(PORT = 1521))
   (LOAD_BALANCE = no)
  )
  (CONNECT_DATA =
   (SERVICE_NAME = OLTP)
  )
 )

図2:Oracleクライアントのtnsnames.ora設定
  図2のとおり、アドレスリストにはrac1_vipおよびrac2_vipという2つのホスト名を記述する。これはOracleクライアント接続時のフェイルオーバおよび負荷分散のための設定で、rac1_vipが高負荷状態やダウン状態の場合はrac2_vipに接続する仕組みだ。ちなみに今回は、RACとSGeRACによる可用性検証が目的であるため、負荷分散機能およびTAF(Transparent Application Failover)は利用していない。

障害テストの結果


今回の検証作業では、上述した検証環境においてノード障害やネットワーク障害などのいくつかの障害パターンを再現し、それぞれのケースにおいてCRSとSGeRACがどのような挙動を示すかが確認された。表1はその結果をまとめたものだ。

表1:障害テスト結果

ノード障害

SGeRACの動作

CRSの動作

クライアントへの影響

ノード障害 プロセッサーやOSなどの障害によりノード全体がダウンするケース 障害検知、フェイルオーバ(クラスタ再構成) フェイルオーバ(クラスタ再構成、VIP移動、リソース再構成、リカバリ) 接続失敗もしくはセッション切断(TCPタイムアウト後に別ノードへ再接続)
インスタンス障害 Oracle関連プロセス(LGWRやLMSx)などが停止するケース なし フェイルオーバ(リソース再構成、リカバリ) 接続失敗もしくはセッション切断(即座に別ノードへ再接続)
ディスク障害 FibreChannelスイッチやケーブル、ディスク・コントローラなどの障害 なし なし 接続可能およびセッション継続可能(約10秒間の停止)
CRS障害 CRSデーモン群の障害 フェイルオーバ(クラスタ再構成) フェイルオーバ(クラスタ再構成、VIP移動、リカバリ) 接続失敗もしくはセッション切断(TCPタイムアウト後に別ノードへ再接続)
Publicネットワーク障害 Oracleクライアントが利用するPublicネットワークのNICやスイッチの障害 なし なし 接続失敗もしくはセッション切断(TCPタイムアウト後に別ノードへ再接続)
Privateネットワーク障害 RACおよびSGeRACが利用するPrivateネットワークのNICやスイッチの障害 障害検知、フェイルオーバ(スタンバイNICへIP移動) なし 接続可能およびセッション継続可能

これらの各ケースのうち、Oracleクライアントへの影響がもっとも少ないのは「ディスク障害」と「Privateネットワーク障害」だ。たとえばディスク障害のテストでは、2台のノードとHP EVAディスクアレイをつなぐFibreChannelスイッチやそのケーブルの障害が再現された。この場合、HP-UXに備わるディスクパス冗長化機能SecurePathによるフェイルオーバが瞬時に働くため、約10秒程度のI/O停止が発生するだけでRACやSGeRACへの影響は皆無だ。またネットワーク障害でも、SGeRACによるNICの切り替えがすぐに実施されるため、RACおよびOracleクライアントは通常運用を継続できる。

続いて、Oracleクライアントへの影響は避けられないものの、比較的短時間でフェイルオーバ可能なケースが「インスタンス障害」である。このテストでは、Oracle関連のプロセス(LGWRやLMSxなど18種類)をkillすることで、Oracleインスタンスの障害がシミュレートされた。この場合、プロセスの種類によってはOracleデータベースの運用にまったく影響を及ぼさないものもあった(アーカイバやジョブ・キュー・コーディネータなど)。一方、ログ・ライター(LGWR)やRAC関連の主要プロセス(LMSx)などがダウンすると、CRSはOracleインスタンスの再起動を開始する。この場合、同インスタンスに接続中であったセッションはすぐさま切断され、再接続を余儀なくされる。

とはいえ、インスタンス障害によるフェイルオーバは比較的短時間で完了する。なぜなら障害ノードのOracleリスナは依然としてアクセス可能であり、Oracleクライアントに「即座」にORA-03113エラーを返すため、別ノードへのすばやい切り替えが可能になるからだ。

これに対し、「ノード障害」や「CRS障害」、「Publicネットワーク障害」の各ケースでは、OracleクライアントがRACに向けて発したTCP接続要求(もしくは既存のTCP接続)がタイムアウトするまで待たなくてはならない。これらのケースでは、さらに高速なフェイルオーバを実現できる余地がある。

ここからは、ノード障害におけるCRS+SGeRACの動作メカニズムを掘り下げ、より高速なフェイルオーバを実現するためにMC3が推奨する手法を解説しよう。

トップへ   次のページへ

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

オンラインサポート
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項 ウェブマスターに連絡