Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP- UX Developer Edge

Oracle AS+HP Serviceguardでつくる盤石のAPサーバ・後編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
Oracle AS+HP Serviceguardでつくる盤石のAPサーバ・後編

ノード障害時のフェイルオーバー・メカニズム

Aのパターン(前回のHTTPリクエストから60秒以内に次のHTTPリクエストが発行されるケース)では、以下のようなメカニズムでフェイルオーバーが働く。
Oracle AS+HP Serviceguardでつくる盤石のAPサーバ・後編
Oracle AS+HP Serviceguardのメリット
ノード障害時のフェイルオーバー・メカニズム

パターンAでのフェイルオーバー動作
図4:パターンAでのフェイルオーバー動作

  1. ノード障害が発生、HP Serviceguardにより仮想IPが移動する。
  2. 前回のHTTPリクエストから60秒以内に次のHTTPリクエストが発行される。
  3. OHSは、前回のHTTPリクエストで確立されたTCP接続をそのまま用いてリクエストを発行するが、仮想IPの移動によりノード1のOC4Jの不在を検知する。
  4. OHSはルーティング・テーブルを更新し、ノード2のOC4Jにリクエストを再送する。
  5. ノード2のOC4Jにはセッション情報がコピーされているため、リクエストの処理を継続できる。
このように、HTTPリクエストの間隔が60秒以内である場合は、HP Serviceguardによる仮想IPの移動とOHSの障害検出が想定通りに動作し、数秒〜数十秒でのフェイルオーバーが実現する。

これに対し、Bのパターン(HTTPリクエストの間隔が60秒を超える場合)では、OHSが新しいTCP接続を確立することになる。そのため、TCP接続の確立にともなうタイムアウトが発生するまでの数十秒間は、OHSによる障害検出が遅れてしまう。もっとも、それでもHP Serviceguardを用いない場合に発生する長時間のタイムアウト待ち(デフォルトでは300秒)に比べれば、大幅な時間短縮が実現されている。

このほかMC3の検証作業では、プロセス障害やネットワーク障害における動作検証も実施された。いずれのケースでも、HP ServiceguardおよびOracle ASのフェイルオーバー機能がスムーズに動作し、速やかな障害検出と運用継続が可能であることが実証された。詳細については、MC3のWebサイトで公開されているドキュメントを参照していただきたい。

FCFの動作検証

また今回の検証では、前編で紹介したFCFによるOracle ASとOracle RACの相互連携も実際にテストされた。DBサーバの障害発生時に接続が切断され、リトライ時に別ノードに再接続されることを確認するのを目的とした。

FCF検証の構成図
図5:FCF検証の構成概要

ここでは、図5のようにAPサーバとDBサーバがそれぞれ2ノードずつ配置された構成において、DBサーバにて障害を発生させ、その際にFCFによるAPサーバへの障害通知が正しく動作するか検証した。またAPサーバ上で動作させる検証アプリケーションでは、実行完了までに60秒ほどを要するSQLを発行し、「SQL実行中のDBダウン」を再現した。さらに、SQL実行時にエラーが発生した場合は、10秒間のスリープ後にSQLを再実行するリトライのメカニズムを組み込み、DB接続の可用性の検証を行った。なお、ここではOracle RACのサービス構成として「優先―優先」を選択している。

検証環境
図6:検証環境

実際の検証環境は図6になります。

HTTP サーバには、ProLiant DL320 G4、RedHat Enterprise Linux AS4、Oracle AS 10gを用いている。

次にAP サーバにはHP Integrityサーバ rx2660を使用し、HP-UX 11i v2とServiceguardでSGクラスタを構築し、Serviceguardの仮想IP上にOracle AS 10g(10.1.3.1)をインストールしている。このAPサーバのSGクラスタが利用するQuorum Serviceは、DBサーバのSGeRACクラスタ上で動作させている。

最後にDBサーバにも、HP Integrityサーバ rx2660を使用し、HP-UX 11i v2とServiceguard とServiceguard Extension for RAC (SGeRAC)でSGeRACクラスタを構築し、さらに今回は、クラスタ再構成時間をより高速にするためにServiceguard Extension for Faster Failover(SGeFF)も導入している。このDBサーバのSGeRACクラスタが利用するQuorum Serviceは、APサーバのSGクラスタ上で動作させている。

このようにDBサーバにSGeRACクラスタ、APサーバにSGクラスタといった、2つのクラスタを作成しているが、これは、Serviceguard+SGeRACが動作するノードとServiceguardのみが動作するノードを1つのSGクラスタに共存させることができないためである。

また、ネットワークについては、DBサーバとAPサーバの通信はクローズ・ネットワークで構築しているが、ONSとOPMNの通信がHTTPサーバ、APサーバ、DBサーバ(RAC)間すべてでできるように、別のパブリック・ネットワークも用意している。

RACのCSS/Cluster Interconnect/SGのハートビートに関しては、CSS/Cluster Interconnect/SGのハートビート用にプライマリNICとスタンバイNIC、そしてSGeFFのために別のSGのハートビート用NICも用意している。

DBノード障害時のFCFの動作(前半)
図7:DBノード障害時のFCFの動作(前半)

クライアントPCからのリクエストに基づいてAPサーバ上で検証アプリケーションが起動すると、上述した「時間のかかるSQL」の実行が開始する。その処理途中でRACインスタンスのひとつ(RAC1)でノード障害を発生させた。このとき、HP ServiceguardおよびOracle ClusterwareによるOracle RACのクラスタ再構成が速やかに開始し、再構成の終了とともに「NODE DOWNイベント」がONSおよびOPMNを通じて各APサーバに通知される。これを受けたAPサーバは、接続プール内の該当する物理接続をクローズし、SQL実行中のアプリケーションにエラーを返す。これにより、アプリケーション側ではOracle RACのノード障害を速やかに検出し、SQLの再実行といった対応を取ることが可能となる。

では続いて、その後のOracle RACのフェイルオーバー動作を見てみよう。

DBノード障害時のFCFの動作(後半)
図8:DBノード障害時のFCFの動作(後半)

上述のとおり、検証アプリケーションではSQLのエラーを検知し、10秒のスリープの後にSQLを再実行するロジックが記述されている。またAPサーバではRAC1との物理接続をクローズしているため、SQL再実行ではRAC2との物理接続が用いられる。一方、Oracle RAC側ではRAC再構成とリカバリが完了し、SQLの実行を受け付け可能な準備が整う。検証アプリケーションが10秒のスリープ後にSQLを再実行すると、今度はRAC2側でSQLが正常に実行される。今回の検証では、ノード障害の発生からSQL再実行まで、およそ20秒ほどであった。

このように、FCFのメカニズムによってDBのノード障害がほぼリアルタイムにAPサーバにも伝わり、Oracle RACの高可用性がそのままOracle ASの高可用性として引き継がれていることが実際に確認できたと言えるだろう。

以上、今回はOracle ASとHP Serviceguardの組み合わせによるAPサーバ構築の手法を取り上げた。本特集で見てきたとおり、この両者を活用するコツはまさしく「適材適所」の使い分けにある。HP Serviceguardの優れた障害検出能力が、Oracle ASに備わる先進的なフェイルオーバーの能力を上手に引き出せる様子が理解いただけたはずだ。

トップへ 戻る    

その他のコラム(特集)もお読み下さい

 
 

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

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

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

ショールーム

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