Jump to content 日本-日本語

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

Oracle RACフェイルオーバを高速化するSGeFF・後編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
Oracle RACフェイルオーバを高速化するSGeFF・後編

Oracle 9i RAC+SGeFFのクラスタ構築手順


Oracle RACフェイルオーバを高速化するSGeFF・後編
Quorum Serverとロック・ディスクの違い
Oracle 9i RAC+SGeFFのクラスタ構築手順

Oracle 9i RAC+SGeFFのクラスタ構築手順は、従来の手順とほとんど同じである。具体的には、以下の順番で作業を進めていく。

  1. Quorum Serverの構築
  2. Quorum Serverのホスト名登録(DNSや/etc/hosts)
  3. 共有ディスク領域作成(SLVM)
  4. Serviceguardクラスタ設定
  5. Oracle 9i RACのインストール
  6. Oracleデータベース作成
  7. OracleインスタンスおよびServiceguardパッケージ作成

SGeFFにおける相違点は、4.のServiceguardクラスタ設定の部分のみである。前編でも説明したとおり、新規追加されたパラメータFAILOVER_OPTIMIZATIONの設定に加え、2系統のハートビート設定、そしてQuorum Server設定を行う。

Serviceguardパッケージの作成


Serviceguardパッケージの作成についても、SGeFFの追加にともなって変化する点はない。パッケージにリロケータブルIP(移動可能IP)を割り振り、OracleリスナやOracleインスタンスの起動を設定する。また、Oracleの各種プロセスの監視や、必要に応じてアプリケーション・サーバ側LANの監視を設定しておく。これにより、障害を検出すると、Oracleリスナやなどがプライマリ・ノードからセカンダリ・ノードへとフェイルオーバする仕組みだ。こうしたパッケージは「DBインスタンスServiceguardパッケージ」と呼ばれる。
 
図3:DBインスタンスServiceguardパッケージ
図3:DBインスタンスServiceguardパッケージ
   
 

以上のように、SGeFFの導入にともない、Oracle 9i RAC構築手順に大きく変化する部分はない。またクラスタの運用手順についても、フェイルオーバ時間が短縮する点を除けば、以前と同じ体制で運用が可能だ。


SGeFFによるフェイルオーバを検証する


ここで、SGeFFの導入によって、クラスタのフェイルオーバが具体的にどの程度高速かされるのか、日本ヒューレット・パッカードによる検証結果を紹介しよう。この検証作業では、図4の検証環境が使用された。

  図4:SGeFFの検証環境

SGeFF検証環境の仕様

Serviceguardクラスタ

サーバ HP Integrity rx2600 x 2
(1.5GHz, 4GB メモリ)
ストレージ EVA5000(36GB×28)
ボリューム・グループ数:2
OS HP-UX 11.23
Oracle Oracle Enterprise Edition 9.2.0.5 or 10.1.0.2
SGA:約2GBDB
容量:約30GB
Serviceguard A.11.16.00
SGeRAC A.11.16.00
SGeFF A.01.00.00

Quorum Server(兼クライアント)

サーバ HP 9000 rp3430
(1.0GHz, 4GB メモリ)
Quorum Server A.02.00.00
  図4:SGeFFの検証環境  
 
 

今回の検証では、Oracle 9iおよび10gのEnterprise Editionを搭載した2台のHP IntegrityでServiceguardクラスタを構成し、「Oracleシングル・インスタンス構成」と「Oracle RAC構成」の双方についてフェイルオーバ時間を計測した。また、クライアント兼Quorum Serverとして、HP 9000 rp3430を用意した。

図5は、検証によって計測された「DBリカバリ開始までの時間」をグラフ化したものである(DBリカバリに要する時間は含まれない)。


図5:DBリカバリ開始までの時間
図5:DBリカバリ開始までの時間

図5において、「9i SI」および「10g SI」と記されているグラフは、Oracleシングル・インスタンス構成での結果、そして「9i RAC」はOracle RAC構成での結果を表している。

上記グラフが示すとおり、シングル・インスタンス構成およびOracle RAC構成のいずれについても、SGeFFによるクラスタ再構成は5秒で終了している(デフォルトの設定)。さらにOracle 9i RACとの組み合わせでは、リカバリ開始までの処理が10秒を切るという高速性が確認できた。


Oracle 9i RAC+Serviceguardのベストプラクティス


最後に、Oracle 9i RAC+Serviceguardの組み合わせで生じるいくつかの考慮点について、日本ヒューレット・パッカードが推奨する「3つのベストプラクティス」を紹介し、本特集の締めくくりとしよう。

ノードダウン時のIP消失への対応


例えば障害やメンテナンスによるノードのダウン時には、「IPアドレスが存在しなくなる状態」がアプリケーションの動作に大きく影響する。なぜならアプリケーション側では、TCPタイムアウト(HP-UXのデフォルトでは約1分)が発生するまでは、別ノードのRACインスタンスへ再接続しないからだ。

この問題を回避するには、「リロケータブルIPのみのパッケージをフェイルオーバさせる」という策がある。このパッケージには、OracleリスナやOracleインスタンスは含めないのがポイントだ。これにより、アプリケーション側ではTCPタイムアウトを待たずに障害を検知し、再接続を開始できる。


多重障害によるインターコネクトLANのダウン


GCS通信に用いるインターコネクトLANは冗長化が必須である。しかし、このLANで万が一にも多重障害が発生すると、Oracle 9i RACがそれを検出するまでに長い時間を要してしまう。

この長時間にわたるダウンを回避するには、「ServiceguardのハートビートLANを1系統のみとし、インターコネクトLANと兼用する」という方法が考えられる。これにより、GCS通信のダウンをServiceguard側で即座に検知し、フェイルオーバを開始することが可能になる。


SGeFFにおける多重障害への対応


もっとも、SGeFF利用時は2系統のハートビートLANが必須であるため、この方策は選択できない。そこで、SGeFFにおけるインターコネクトLAN多重障害への対処方法としては、以下の2つが考えられる。

  • VLANによるハートビートLANの集約
  • GCS監視パッケージの作成
  図6:VLANによるハートビートLANの集約
図6:VLANによるハートビートLANの集約
   
 

前者は、インターコネクトLAN用のスイッチ上にVLANを設けることで、2系統のハートビートLANも同じスイッチで収容するという方法。後者は、Serviceguardのサブネット監視機能を使い、インターコネクトLANの監視を実施する方法だ。いずれの方法でも、スイッチの多重障害をSGeFFが検出し、フェイルオーバを迅速に開始できる。なお、これらの対策についての詳細は「関連リンク」を参考にしていただきたい。

これらが、日本ヒューレット・パッカードの推奨する3つのベストプラクティスだ。もちろん、冗長化されたLANの多重障害が実際に発生することは極めてまれである。しかし、例えばテレコム分野などのミッションクリティカル環境では、こうした多重障害でさえもシステム構築段階で想定しておくことがしばしば求められる。そうした高度な要求に応える日本ヒューレット・パッカードのコンサルティング能力があってこそ、SGeFFがその真価を発揮できると言えるだろう。

関連リンク

 
HP & Oracle 共同サイト HOVAC - MC3技術情報
 
トップへ 戻る    

記事の内容に関するご意見・ご質問・お問い合わせ

  日本ITフォーラムにて承っております(別途、会員登録が必要です)。

日本ITフォーラム
 

本ページの内容は執筆時の情報に基づいており、異なる場合があります。
印刷用画面へ
プライバシー ご利用条件・免責事項