Jump to content 日本-日本語
日本HPホーム 製品＆サービス サポート＆ドライバー ソリューション ご購入方法
≫  お問い合わせ
日本HPホーム
製品とサービス  >  ソフトウェアとOS  >  HP- UX Developer Edge

Oracle AS＋HP Serviceguardでつくる盤石のAPサーバ・後編
特集　「実機体感センター」体験レポート、サーバー解体ショーって？
UNIXの教科書 期末試験
新連載！“まるごと仮想化”のここが「ツボ」
コンテンツに進む
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インスタンスに接続するというふるまいになった。

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

本ページの内容は執筆時の情報に基づいており、異なる場合があります。
印刷用画面へ
プライバシー 本サイト利用時の合意事項 ウェブマスターに連絡
© 2009 Hewlett-Packard Development Company, L.P.