アットマーク・アイティ @IT@IT情報マネジメント@IT自分戦略研究所QA@ITイベントカレンダー  
 
 @IT > Oracle RAC 10g+HP Serviceguardの勘どころ
 
@IT[FYI]

 

 

Oracle 10g最強利用術──クラスタウェア有効活用法(1)
Oracle RAC 10g+HP Serviceguardの勘どころ

本記事は、日本ヒューレッド・パッカードのHP-UX Developer Edgeに掲載された記事を許諾を得て、再構成したものです。詳しくは、HP-UX Developer Edgeの以下の記事をご参照ください。(要登録、登録無料)

『Oracle RAC 10g+HP Serviceguardの勘どころ』

 Oracle Database 10gのクラスタ・テクノロジReal Application Clusters 10g(以下、RAC 10g)では、オラクルが開発したクラスタウェアCluster Ready Services(以下、CRS)の利用が必須となった。しかしCRSは、個々のOSレベルで最適化された障害検出やフェイルオーバーの能力は備えていない。そのためミッションクリティカル用途では、例えば業界標準のクラスタウェアであるHP ServiceguardとCRSを組み合わせて使うことで、より優れた可用性が得られる。ここでは、この両者の組み合わせの勘どころを探ってみたい。

  HAクラスタとOracle RACの違い

 まずは、通常のHAクラスタ(高可用性クラスタ)とRACによるクラスタの違いについて再確認しておきたい。

 ご存じのとおりHAクラスタでは、1台の共有ディスクを複数のノードに接続する構成が一般的である(HAクラスタについて詳しくは、HP-UX技術情報サイトHP-UX Developer Edgeの記事「HAクラスタの疑問を解く」を参照していただきたい)。たとえばHAクラスタ上でOracleデータベースを運用するケースを考えてみよう。プライマリ・ノードの障害時には、スタンバイ・ノード側で共有ディスクのボリュームをマウントし直したあと、Oracleインスタンスを起動する。その後、スタンバイ・ノードによってサービスが再開される。共有ディスク上のデータベースをオープンできるのは、つねに1つのノードに限定されている。

 一方RACによるクラスタでも、1台の共有ディスクを複数のノードに接続するという構成は変わらない。異なるのは、すべてのノード上でOracleインスタンスが常時起動しており、それぞれが共有ディスク上のデータベースを同時にオープンしている点だ(図1)。もちろん、普通のデータベースでこのようなことをすれば、共有ディスクにI/O負荷が極端に集中するし、データの整合性も維持できない。

図1:HAクラスタとRACの違い

 この2つの問題を解決するのが、RACの要である分散キャッシュ機能、Global Cache Service(以下、GCS)である。GCSは、各ノードのそれぞれのキャッシュを統合し、1つの仮想的なキャッシュ(Cache Fusion)を実現する。例えば、ノードBが必要とするデータがノードAのキャッシュにあるときは、ノードAからBへとキャッシュ内容が瞬時にネットワーク転送される。このメカニズムにより、共有ディスクがボトルネックとなることを防ぎ、クラスタ全体で優れたスケーラビリティが得られる。また同時に、各ノードがデータベース・レコードのロックを分散管理することで、データの整合性も確保される仕組みだ(図2)。

図2:Cache Fusionのメカニズム

 こうしたアーキテクチャの違いから、RACによるクラスタは、通常のHAクラスタでは得られない以下のようなメリットを提供する。

  • インスタンス起動が不要なため短時間でフェイルオーバーできる
  • 負荷分散によりスケーラビリティが大幅に向上する

 HAクラスタでのフェイルオーバーでは、Oracleインスタンスの起動のために数十秒〜数分の時間を要する。これに対し、RACではOracleインスタンスの起動はすべてのノードで動作しているため、あらためて起動する時間がかからない。さらにRACではCache Fusionによる負荷分散のおかげで、すべてのノードのプロセッサとメモリを活用でき、格段に高いスケーラビリティを実現できる。この2点がRACのアドバンテージである。

RACによるクラスタ環境の構築

 HAクラスタと同様に、RACにおいてもノードやネットワーク、Oracleインスタンスなどの障害をきっかけとしてフェイルオーバーが開始される。HAクラスタとは異なり、RACではOracleインスタンスの起動や共有ディスクのボリュームのマウントは不要だ。ただしそのほかのフェイルオーバー処理、例えば障害の検知をはじめ、スプリット・ブレイン(障害によりクラスタが分裂する現象)の解決、クラスタの再構成、IPアドレスの引き継ぎといった処理は、HAクラスタと同じく必要になる。またダウンしたOracleインスタンスの代わりを務めるOracleインスタンスでは、共有ディスク上に残されたREDOログをもとにトランザクションのロール・フォワードやキャッシュのリカバリなどを実施する。

 Oracle RAC 10gからは、RACのフェイルオーバーを実現する手段として、オラクル製のクラスタウェアCluster Ready Service(CRS)が標準コンポーネントとし て提供されるようになった。

 そこで以下ではCRSがどのように構成されているかを概観し、システム、OSレベルのイベント、RAC以外のアプリケーションの監視に必要となるそのほかのクラスタウェアと共存させる際に考慮すべきポイントを説明したい。本記事では、HP-UX対応クラスタウェアHP ServiceguardのOracle RAC対応版、Serviceguard Extension for RAC(以下、SGeRAC)との組み合わせを検証する。

  Cluster Ready Services(CRS)とは何か

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

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

  • CRSリソース ―― CRSが管理するデータベース・プロセスやサービス、IPアドレスなど

  • CRSデーモン群 ―― CRS本体を構成するソフトウェア

  • そのほか―― 構成レジストリやロック・ディスクなど

 図3は、HP-UX上でSGeRACと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リソースの管理・監視

そのほかのコンポーネント

 以上の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秒を要し、またフェイルオーバーには数十秒程度かかる。こうした事情から、ミッションクリティカル環境でのRAC構成時には、いままで同様にSGeRACを併用するケースが少なくないだろう。

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

表1:CRS+SGeRAC構成より得られるメリット
CRS+SGeRAC
Oracle以外のアプリ監視とフェイルオーバー
HP EMS連携によるデバイスレベルの障害検知
HP WLM連携によるサービスレベルの障害検知
プライベート・ネットワークの冗長化
障害検知時間
2秒(SGeFF利用時)
フェイルオーバー時間
数秒〜


日本HP+日本オラクルによる検証結果

 日本HPと日本オラクルが共同運営する検証体制MC3(Mission Critical Certified Center)では、RAC 10gとSGeRACの組み合わせによるフェイルオーバーの実地検証を行った。この検証作業では、ノード障害やインスタンス障害、ネットワーク障害などのさまざまなパターンが実際に再現され、RACとSGeRACの連携によりフェイルオーバーを短縮可能なことが確認されている。

 さらにMC3では、これらのさまざまなケースにおいて最良の結果を得られるベスト・プラクティスを紹介している。このMC3による検証レポートは、HP-UX Developer Edgeの記事「Oracle RAC 10g+HP Serviceguardの勘どころ・後編 」にて詳しく説明されているので、興味のある方はぜひ参照していただきたい。

    第2回

index
@IT [FYI]
Oracle 10g最強利用術──クラスタウェア有効活用法(1)
第1回
Oracle RAC 10g+HP Serviceguardの勘どころ
  第2回
Oracle RACフェイルオーバーを高速化するSGeFF


提供:日本ヒューレット・パッカード株式会社
企画:アイティメディア 営業局
制作:@IT 編集部
掲載内容有効期限:2005年6月9日
 
関連リンク

@IT [FYI] 関連記事

@IT News/記事
Oracle 10gとHPサーバが2冠、TPC-Hベンチマーク (@IT News)
Oracle 10gがTPC-Cで世界記録、トップ10の半分を制覇 (@IT News)
フィオリーナの次はNCR出身者、HPが新CEOを決定 (@IT News)
史上最高のパフォーマンスを10分の1の価格で実現、HP (@IT News)
情報漏えいの原因は持ち出せること。日本HPの対策は? (@IT News)
Javaパフォーマンスチューニングのルール (Java Solution)
IT管理者のための仮想化技術入門 (System Insider)

HPの掲げるIT基盤「Adaptive Infrastructure」とは? (System Insider)
実行スピードに挑戦するJavaアーキテクチャの変遷をたどる (Java Solution)
「最重要製品の位置付け」、HP 新ブレード戦略の中身は (@IT News)
64ビット化と仮想化でエンタープライズ市場を制す、HP (@IT News)
HP、サーバ仮想化技術のマルチOS化を含む強化計画 (@IT News)
国内UNIXサーバ市場の“リーダー”はHP、IDC Japan (@IT News)
ユーティリティ化に見るHPがユニークな点 (@IT News)
メインフレームを駆逐せよ! HPのオープン戦略 (@IT News)
SolarisエンジニアをHP-UX陣営に取り込むHPの秘策 (@IT News)
日本HPと日本BEA、二度目の握手を交わす (@IT News)



 
@ITトップ@IT Special インデックス会議室利用規約プライバシーポリシーサイトマップ