Jump to content 日本-日本語

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

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

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

FCFによる高速接続フェイルオーバー

一般的なAPサーバとOracle RACを組み合わせる場合、Oracleデータベースに障害が発生したときに以下のような問題が起こりうる。
Oracle AS+HP Serviceguardでつくる盤石のAPサーバ・前編
Oracle ASの高可用性アーキテクチャ
FCFによる高速接続フェイルオーバー

  • SQL実行前にDB障害が発生した場合――アプリケーションがAPサーバの接続プールから論理接続を取得した際に、障害が発生したDBへの接続を獲得してしまう。
  • SQL実行中にDB障害が発生した場合――SQLへのレスポンスが途絶え、タイムアウトするまでリクエストの処理が中断する(Oracle ASのOHSの場合、タイムアウトのデフォルト値は300秒)。
こうした問題が発生する原因は、「APサーバ側ではDB障害をリアルタイムに検知できない」点にある。そこでOracle ASのFast Connection Failover(FCF)では、DB障害をOracle ASにリアルタイムに通知することで、こうした問題の発生を防ぐ。

FCFのメカニズム
図4:FCFのメカニズム

FCFで中心的な役割を果たすのが、前述のOPMNと、Oracle RACに備わるONS(Oracle Notification Service)である。RACインスタンスの障害をONSが検知すると、ONSはそれをOracle ASのOPMNへ通知する。これを受けたOPMNは、OC4Jの接続プールを再確認し、障害DBに接続している物理接続を破棄する。これにより、上述のようなタイムアウトを待たずして、別のRACインスタンスへのすばやい切り替えを促す仕組みだ。

Oracle ASの弱点とは

ここまで説明したとおり、Oracle ASは、Oracle RACとの密接な連携により一般的なAPサーバ製品やDB製品の組み合わせよりも優れた可用性を実現する。とはいえ、そこには弱点がないわけではない。なぜなら、Oracle ASの高可用性をつかさどるOPMNが、あくまで「プロセスの監視」しか実行していないからだ。OC4JやOHSなどのプロセス単体の障害であれば、OPMNがそれを検出し、フェイルオーバーを実施できる。しかしOracle ASが稼働するノード全体の障害や、クラスタを結ぶネットワークの障害が発生すると、OPMNでは対処できないのである。

例えばノード障害のケースを考えてみよう。

ノード障害の例
図5:ノード障害の例

ノード障害が発生すると、その上で動作するOPMNも動作を停止し、クラスタ上のほかのOPMNへ障害の通知は届かない。また、ノードが持っていたIPアドレスもネットワーク上に存在しなくなり、同ノードへ送信されたリクエストはタイムアウトするまで待機状態となる。図5は、ノード障害の発生したOC4Jに対しOHSがリクエストを送信してしまい、タイムアウト(デフォルト値は300秒)するまで該当するリクエストの処理が中断する例を示している。このタイムアウトの後に、mod_oc4j内部のルーティング・テーブルが更新され、障害ノードへのリクエスト転送を中止してセッション・フェイルオーバーを実行する手順となる。

次に、ネットワーク障害のケースを考えてみたい。例えば、OC4Jが稼働するノードのネットワーク・ケーブルが断線し、クラスタのほかのノードとの通信が遮断された状況である。

ネットワーク障害の例
図6:ネットワーク障害の例

この場合もまた、遮断されたノードのOPMNからほかのOPMNへの障害通知は届かない。また、OPMNはプロセス監視のツールであるため、一般的なクラスタウェアのようにハートビートによるノード間の死活管理などは実施していない。生き残ったノードが自律的に障害を検知しクラスタを再構成するといったメカニズムが存在しないため、やはりOHSのタイムアウトを待ってからフェイルオーバーを実施するという手順になる。  このようにOracle AS単体では、ノード障害やネットワーク障害への対処が万全ではないという弱点がある。この弱点を補うのが、HP Serviceguardだ。

そこで後編では、Oracle ASとHP Serviceguardによるクラスタの構築手法を説明し、実地検証の結果を紹介したい。

Oracle RAC 10g R2アップグレードのベストプラクティス

Oracle RAC 10g R2へのアップグレードでは、システム構成や管理手法が大幅に変更されるため、従来までの“アップグレード”とはまったく異なる周到な準備作業なしでは長期間のサービス停止が余儀なくされてしまう。そこで日本ヒューレット・パッカードと日本オラクルの共同検証センター「ミッション・クリティカル・サーティファイド・センター(MC3)」では、旧バージョンのOracle RACから最新版であるOracle RAC 10g R2へのアップグレード手法をまとめたドキュメント「Oracle RAC 10g R2 へのアップグレード このリンクをクリックすると、HP社外へリンクします。」を公開した。このドキュメントでは、このアップグレードにともなうサービス停止を最小限に短縮するための、さまざまなテクニックや考慮点を集約している。Oracle RACのアップグレードを検討している方はぜひ参照していただきたい。
トップへ 戻る    

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

 
 

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

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

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

ショールーム

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