Jump to content 日本-日本語

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

Oracle RAC 10g+HP Serviceguardの勘どころ・前編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
Oracle RAC 10g+HP Serviceguardの勘どころ・前編
Oracle RAC 10g+HP Serviceguardの勘どころ・前編
HAクラスタとOracle RACの違い
CRSとは何か

Cluster Ready Services(CRS)とは何か


CRSは、オラクルが開発したRAC専用のクラスタウェアである。あくまでRAC専用であるため、CRSが監視するのはもっぱらOracle関連のプロセスであり、その他のアプリケーションの監視には利用できない。

CRSは、以下の3種類のコンポーネントから構成されている。

  • CRSリソース ―― CRSが管理するデータベース・プロセスやサービス、IPアドレスなど
  • CRSデーモン群 ―― CRS本体を構成するソフトウェア
  • その他 ―― 構成レジストリやロック・ディスクなど

図3は、HP-UX上でSGeRACとCRSを併用する場合のそれぞれの位置づけを示した図である。

  図3:CRSの構成
図3:CRSの構成
  以下、CRSの個々のコンポーネントについて概観しよう。

CRSリソース


まずは、CRSリソースである。これはCRSが管理するさまざまなリソースの総称であり、SGeRACにおけるパッケージに相当する。具体的には以下のものが含まれる。

  • サービス ―― Oracle RAC 10gでは、負荷分散やワークロード管理を目的として「サービス」という概念が新たに導入された。その詳細はここでは触れないが、おおざっぱに言ってサービス=アプリケーションと考えてよい
  • データベース ―― Oracle RAC 10gを構成する各種プロセスである。CRSではこれらのプロセスの稼働状況を監視し、フェイルオーバ時には起動や停止を制御する
  • ノード・アプリケーション ―― 各ノードのVIP(Virtual IP)、Oracleリスナ、そしてONS(Oracle Notification Service)を指す。VIPはSGeRACにおけるリロケータブルIPに相当するもので、フェイルオーバ時にはダウンしたノードのVIPを他のノードが引き継ぐ。なおONSはアプリケーション・サーバへの障害通知に利用する

CRSデーモン群


一方、これらのCRSリソースを管理するソフトウェアが、CRSデーモン群である。

  • CRS(Cluster Ready Servies)デーモン――CRSリソースの監視や起動、停止などを担当する(図4)
  • CSS(Cluster Synchronization Servies)デーモン――クラスタウェア機能を提供。ハートビートによる障害検出、クラスタ再構成、スプリット・ブレイン解決を担当する。ベンダー製クラスタウェア併用時は自動的にその配下で動作する
  • EVM(Event Manager)デーモン――イベント管理を担当。CRSデーモンから障害イベントを受け取ったり、ONSへイベント通知を行ったりする
  • OPROCD(Processor)デーモン――ベンダー製クラスタウェアが存在しない場合に起動する。ノードのストール状態を検出し、自動リブートを行う
  図4:CRSデーモンによるCRSリソースの管理・監視
図4:CRSデーモンによるCRSリソースの管理・監視

その他のコンポーネント


以上のCRSリソースおよびCRSデーモン群以外に、以下のコンポーネントが存在する。

  • OCR(Oracle Cluster Registry) ―― Oracle RAC 10gで利用される共有ディスク上のレジストリ。CRSリソースやCSS、ノード間インターコネクトなどの構成や状態を保持する。OCRが壊れるとCRSを起動できない
  • Voting Disk ―― スプリット・ブレイン解決のために用いられる共有ディスク上の領域。SGeRACのロック・ディスクやクォーラム・サーバに相当する

CRSとSGeRACの組み合わせ


ここまで見てきたとおり、CRSはクラスタウェアとしての一通りの機能を備えている。

とはいえ、CRSは今のところ、SGeRACほどOSレベルで最適化された障害検出やフェイルオーバの能力は備えていない。たとえばSGeRACでは、HP-UXのイベント管理ツールHP EMS(Event Monitoring Service)との連携により、プロセッサーやメモリ、NICカード、ディスクドライブなどのデバイス障害をOSレベルで検知し、即座にフェイルオーバを開始できる。またSGeRACでは、業務で必要なジョブスケジュールを行うアプリケーションなど、RAC以外のアプリケーションの監視やフェイルオーバが可能だ。

さらに、HP-UX対応のワークロード管理ツールHP WLM(Workload Manager)と組み合わせれば、データベースやWebサーバのレスポンス時間などを監視し、サービスレベルが一定値を下回った場合に強制的にフェイルオーバさせることも可能だ。これに対し、CRSではOracle関連プロセスやハートビートの状態監視だけで障害を検知する。

またフェイルオーバ時間にも大きな差がある。HPが今年6月にリリースした高速フェイルオーバ・オプションServiceguard Extension for Faster Failover(SGeFF)を使えば、障害検出からRACのフェイルオーバまでが数秒で完了する。一方CRS単体の場合、デフォルトでは障害検出までに30秒を要し、またフェイルオーバには数10秒程度かかる。こうした事情から、ミッションクリティカル環境でのRAC構成時には、いままで同様にSGeRACを併用するケースが少なくないだろう。

CRS+SGeRAC構成によって得られるメリットについてまとめると次のようになる。

表1:CRS+SGeRAC構成より得られるメリット
 

CRS+SGeRAC

Oracle以外のアプリ監視とフェイルオーバ
HP EMS連携によるデバイスレベルの障害検知
HP WLM連携によるサービスレベルの障害検知
プライベート・ネットワークの冗長化
障害検知時間 2秒(SGeFF利用時)
フェイルオーバ時間* 数秒〜
* 障害内容によるフェイルオーバ時間の違いについては特集2を参照のこと

ここでは、Oracle RAC 10gから導入されたクラスタウェアCRSについて説明し、SGeRAC併用によるメリットを概観した。つづく後編では、CRS+SGeRAC構成におけるフェイルオーバの動作メカニズムについて掘り下げる。

トップへ 戻る   次へ

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

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

日本ITフォーラム
 

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

 
 

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