Jump to content 日本-日本語

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

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

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
Oracle AS+HP Serviceguardでつくる盤石のAPサーバ・後編
Oracle ASは、Oracle RACとの密接な連携により、一般的なAPサーバ製品やDB製品の組み合わせよりも優れた可用性を実現する。とはいえ、そこには弱点もある。それは、Oracle ASの高可用性をつかさどるOPMNが「プロセスの監視」しか実行していない点だ。そのため、Oracle ASが稼働するノード全体の障害や、クラスタを結ぶネットワークの障害が発生すると、OPMNでは対処できない。この弱点を補うのが、HP Serviceguardだ。本特集の後編では、Oracle ASとHP Serviceguardによるクラスタの構築手法を説明し、MC3による検証結果を紹介していこう。
Oracle AS+HP Serviceguardでつくる盤石のAPサーバ・後編
Oracle AS+HP Serviceguardのメリット
ノード障害時のフェイルオーバー・メカニズム
2007年12月
テクニカルライター 吉川和巳

Oracle AS+HP Serviceguardのメリット

前編で説明したとおり、Oracle AS単体では、ノード障害やネットワーク障害への対処が万全ではない。そこで、フル機能を備えたクラスタウェアであるHP ServiceguardをOracle ASと組み合わせることで、この弱点をカバーした盤石のASサーバ・クラスタ構築が可能となる。

では、具体的にはどのようにOracle ASとHP Serviceguardを組み合わせればよいのだろうか。その答えを示したのが図1だ。

Oracle ASとHP Serviceguardの組み合わせ例
図1:Oracle ASとHP Serviceguardの組み合わせ例

1台のWebサーバ(OHS)と2台のAPサーバ(OC4J)で構成されたクラスタにHP Serviceguardを導入した例である。このように、それぞれのAPサーバにはHP Serviceguardのパッケージを構成し、仮想IPを割り振る。Webサーバは、この仮想IPを通じてAPサーバにアクセスする。また、2台のAPサーバ間にはHP Serviceguardがハートビートを交換するための独立したLANを設け、互いの死活監視を行う。

では、この構成においてノード障害やネットワーク障害が起きた場合の動作メカニズムを説明しよう。

ノード障害時のフェイルオーバー動作例
図2:ノード障害時のフェイルオーバー動作例

図2の左側にあるノード1で障害が発生すると、HP Serviceguardのハートビートがノード2に届かなくなり、数秒〜数十秒のうちにHP Serviceguardによるフェイルオーバーが起動する。これにより、ノード1側に割り当てられていた仮想IP1がノード2に移動する。ここでのポイントは、「HP Serviceguardには仮想IPの移動だけを行わせる」という点だ。つまり、ノード1で動作していたOC4J全体をノード2へフェイルオーバーするわけではない。

その後OHSは、これまで通りに仮想IP1へリクエストを転送する。しかし仮想IP1はノード2が引き継いでおり、そのノード2上には仮想IP1に対応するOC4Jは動作していない(仮想IP2に対応するOC4Jのみ動作する)。よってOHSに対して直ちにエラーが返り、OHSはそれを受けてmod_oc4jのルーティング・テーブルを更新し、それ以降はノード1へのリクエストをすべてノード2に転送する。

このようにHP Serviceguardは、「ノード障害やネットワーク障害をいち早く検出し、仮想IPの移動を通じてそれをOHSに通知する」という役割を担う。障害の検出と通知のみを担当し、OC4J自体のフェイルオーバーはmod_oc4jの機能をそのまま利用する仕組みである。これにより、前編で説明したような障害時のタイムアウト待ちがなくなり、数秒〜数十秒単位でのフェイルオーバーが実現する。

Oracle AS+HP Serviceguardの可用性検証

今回MC3では、Oracle ASとHP Serviceguardによる上述の組み合わせで実装されたAPサーバが、実際にどのように動作するのかを検証している。APサーバ間でセッション・レプリケーションを動作させた状態でさまざまな障害を再現し、セッション情報が正しく引き継がれることを確認し、またフェイルオーバーに要する時間を計測した。

検証環境の構成
図3:検証環境の構成

図3は、今回の検証で用いられたハードウェアとソフトウェアの構成である。Webサーバは、HP ProLiant DL320G4、RedHat Enterprise Linux AS4、およびOracle AS 10gで構成。一方のAPサーバは、HP Integrity rx2660、HP-UX 11i v2、Oracle AS 10g、およびHP Serviceguard 11.17で構成している。

この構成において、ノード障害を再現した場合の結果を以下に示す。

ノード障害の検証結果
障害 障害発生ノードの動作 正常動作ノードの動作 接続の挙動
マシンのリセット SGクラスタの再構成、およびSGの仮想IPの移動 前回のHTTPリクエストから次のHTTPリクエストが発行されるまでの時間により、接続の挙動は異なる。
A. 60秒以内
→ Serviceguardの仮想IP移動後に異常検出し、再送
B. 60秒以上経過
→ 数十秒以内に異常検出し、再送
どちらの場合もレプリケーションにより、HTTPセッションの内容は引き継がれる

この検証では、サーバ・マシンをリセットすることで、擬似的なノード障害を発生させている。その結果によると、「前回のHTTPリクエストから次のHTTPリクエストが発行されるまでの時間」によって接続の挙動が変化することがわかった。

まず「A」のパターン、すなわち前回のHTTPリクエストから60秒以内に次のHTTPリクエストがきた場合は、HP Serviceguardの仮想IPが移動した後にHTTPサーバが障害をただちに検知し、別のOC4Jインスタンスに接続する。これに対して、前回のHTTPリクエストから60秒以上たって次のHTTPリクエストがくる「B」のパターンでは、数十秒程度で別のOC4Jインスタンスに接続するというふるまいになった。

では、このふるまいの詳細について、後半でもう少し説明しよう。
トップへ   次のページへ

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

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

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

ショールーム

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