アットマーク・アイティ @IT@IT情報マネジメント@IT自分戦略研究所QA@ITイベントカレンダー  
 
 @IT > Oracle RACフェイルオーバーを高速化するSGeFF
 
@IT[FYI]

 

 

Oracle 10g最強利用術──クラスタウェア有効活用法(2)
Oracle RACフェイルオーバーを高速化するSGeFF

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

『Oracle RACフェイルオーバーを高速化するSGeFF』

 前回の「Oracle RAC 10g+HP Serviceguardの勘どころ」では、クラスタウェアHP ServiceguardとOracle RACの組み合わせによりフェイルオーバー時間を最適化する技法を紹介した。HPから昨年6月より提供されているServiceguard Extension for Faster Failover(以下、SGeFF)は、このHP Serviceguardのフェイルオーバーをさらに高速化するオプション製品である。SGeFFを使えば、クラスタの再構成にかかる時間を「数秒程度」にまで短縮可能だ。ここでは、SGeFFがどのようにして大幅な時間短縮を実現するのか、その動作メカニズムを掘り下げてみたい。

  Serviceguardの歴史は時間短縮の歴史

 Serviceguardの歴史は、「クラスタ再構成」の時間短縮の歴史といえる。まずは、図1を見ていただきたい。

図1:Serviceguardのクラスタ再構成時間の変遷

 図1が示すように、「障害の発生」から「サービスの回復」までのフェイルオーバー時間には、以下の2つの処理が含まれる。

  • クラスタ再構成
  • そのほかのリカバリ処理

 「クラスタ再構成」とは、障害を検知してから、クラスタをどのように再構成すればよいか決定するまでのプロセスである(その詳細については、HP-UX技術情報サイトHP-UX Developer Edgeの記事「HAクラスタの疑問を解く・後編」に解説がある)。

 一方、「そのほかのリカバリ処理」としては、共有ディスクの活性化やデータベースの再起動(シングル・インスタンスの場合)、データベースのクラッシュ・リカバリが含まれる。この処理に要する時間はデータベースの規模や障害状況によって大きく変化するため、事前の予測は困難だ。

 この2つの処理のうち、前者の「クラスタ再構成時間」を可能な限り短くするのが、クラスタウェアに課せられた使命だ。そこでServiceguardでは、後述するQuorum Serverや今回リリースされたSGeFFといったユニークな新技術を順次投入し、クラスタ再構成の高速化を達成してきた。最終的にSGeFFでは、クラスタ再構成時間が数秒程度にまで短縮されている。

なぜSGeFFは高速なのか

 では、なぜSGeFFではそれほどまでの高速化が可能になったのだろうか。図2は、通常のServiceguardとSGeFFのフェイルオーバー手順の違いを示した図である。

図2:フェイルオーバー手順の違い

 まず異なる点は、従来は必要であった「エレクション(election)」の手順がSGeFFでは省略されている点だ。「エレクション」とは、障害検出の後に生き残った各ノードが「新たに形成されるHAクラスタに参加する権利」を獲得するための手続きである。SGeFFでは、この手順を省略しつつも、ノード間の競合が発生しないメカニズムを実現している。

 高速化されたもう1つの手順は、「クラスタ・ロック取得」である。クラスタ・ロックとは、新しいHAクラスタへの参加権をあらわすフラグのようなものだ。例えば「クラスタがちょうど半数ずつに分断された」としよう。この状況は「スプリット・ブレイン(split brain)」と呼ばれる。このときに実行されるのが、「クラスタ・ロックの取得」である。つまり、いずれか1つのノード・グループがクラスタ・ロックを先取りすることで、スプリット・ブレインを回避する仕組みである。SGeFFでは、その実装手段としてQuorum Serverの利用を必須とすることで、クラスタ・ロック取得時間を大幅に短縮している(これについて、詳しくは後述する)。

 ではつづいて、SGeFFの導入の実際を詳しく見ていこう。

  SGeFFの導入の実際

 SGeFFを動作させるためには、以下の動作環境を用意する必要がある。

SGeFFの動作環境
ハードウェア HP 9000サーバ
HP Integrityサーバ
ソフトウェア HP-UX 11i v1(11.11)もしくはHP-UX 11i v2(11.23)
Serviceguard A.11.16以降
Quorum Server A.02.00以降(無償)
オプション・ソフトウェア Serviceguard Extension for RAC A.11.16以降
Serviceguard Manager A.04.00以降(無償)

 上述したとおり、SGeFFはServiceguardのオプション製品であり、最新バージョンである11.16以降で動作する。プラットフォームとしては、HP-UX 11i v1(11.11)もしくはHP-UX 11i v2(11.23)が動作するHP 9000サーバかHP Integrityサーバをサポートする。また、標準のServiceguardではオプション扱いであったQuorum Serverの利用が必須となる。

 ちなみに、SGeFFをOracle RACのフェイルオーバーに使用する場合は、Serviceguardのもう1つのオプション製品であるServiceguard Extension for RAC(以下、SGeRAC)との併用が不可欠となる。なお、ServiceguardやSGeRACが必要とする以上のメモリおよびディスク容量、ポートなどをSGeFFが使用することはない。

SGeFFの設定方法

 SGeFFの設定方法は、Serviceguardのそれと大幅に異なる部分はない。設定方法が変化するのは、以下の3つのパラメータだ。

FAILOVER_OPTIMIZATION(新パラメータ)
FAILOVER_OPTIMIZATION TWO_NODE
2系統のハートビート設定の確認(既存パラメータ)
NODE_NAME node1
NETWORK_INTERFACE lan2
HEARTBEAT_IP 192.168.1.51→ハートビート#1
NETWORK_INTERFACE lan6
HEARTBEAT_IP 192.168.2.51→ハートビート#2
Quorum Server設定の確認(既存パラメータ)
QS_HOST node3
QS_POLLING_INTERVAL 300000000
QS_TIMEOUT_EXTENSION 0

 まず、SGeFF独自のパラメータとして、「FAILOVER_OPTIMIZATION」が追加された。同パラメータには「NONE」もしくは「TWO_NODE」のいずれかを指定でき、SGeFF利用時には後者を選択する。

 残る2つは、いずれも既存パラメータである。1つ、ハートビートLANの設定を2系統について実施するためのパラメータ。もう1つは、必須となるQuorum Server設定を実施するパラメータである。

  Quorum Serverのメカニズム

 ここで、SGeFFによるクラスタ再構成の高速化において重要な役割を担っているQuorum Server(HP Serviceguard Quorum Server)についてあらためて説明しておこう。

 Serviceguardでは、クラスタ・ロックを実現する手段として、以下の2つの方法をサポートしている。

  • ロック・ディスク
  • Quorum Server
図3:ロック・ディスクとQuorum Serverの構成の違い

 ロック・ディスクとは、共有ディスクの特定領域をクラスタ・ロックとして利用する方法である。クラスタ・ロックを取得するノードは、ディスク領域にマークを付けることで、ロックの取得を表明する。一方、Quorum Serverは、HAクラスタ外部のノード上のソフトウェアによって実現されるクラスタ・ロックである。いずれも、スプリット・ブレインを解消するという役割は同じである。

 Serviceguard以外のクラスタウェアでは、クラスタ・ロックの実装方法として、ロック・ディスクを用いるのが一般的だ。一方Serviceguardでは、Quorum Serverという独立したソフトウェアによって、クラスタ・ロックを実現することができる。このユニークな設計によって、クラスタ再構成時間の大幅な短縮、さらには可用性の向上を可能にしている。

 Quorum Serverとロック・ディスク、いずれもクラスタ・ロックという役割は同じである。では、なぜ前者はクラスタ再構成の高速化に貢献するのだろうか。以下の表は、この両者の特徴を比較したものである。

表:Quorum Serverとロック・ディスクの比較
Quorum Server
ロック・ディスク
実装形態 クラスタ外のサーバ上のソフトウェア 共有ディスク上の領域
通信方法 LAN(TCP/IP) I/Oバス(FibreChannel/SCSI)
クラスタ・ロック取得に要する時間 数秒 約10秒(SCSI)〜約32秒(FibreChannel)
サポート可能なクラスタ数 最大50クラスタ/最大100ノード 最大1クラスタ
ロック機能障害時のクラスタの動作 継続動作 継続動作
クラスタ・ロック障害の修復方法 クラスタ運用を継続したままQuorum Serverを交換 共有ディスク(通常はディスクアレイ)を修理
必要リソース 7MBメモリ、1MBディスク 数KB

 ロック・ディスクとQuorum Serverの基本的な違いは、前者は共有ディスクによる実装であるのに対し、後者がソフトウェアによる実装である点だ。ロック・ディスクの場合は、FibreChannelなどのI/Oバスのリセットが必要であり、クラスタ・ロックの取得に数十秒の時間を要する。これに対しQuorum Serverの場合は、LAN経由で同サーバに接続するため、取得時間は数秒で済むのである。

 また、クラスタ構成の自由度や多重障害発生時の修復方法にこの両者には差がある。ロック・ディスクは1つのクラスタしかサポートできないが、Quorum Serverは最大50クラスタを1台でサポート可能だ。ロック・ディスクの単一障害時は、どちらの場合でもServiceguardクラスタは継続動作するので可用性としては変わらない。が、多重障害等でクラスタ・ロックを交換する必要が生じた場合、ロック・ディスクの場合は、クラスタを止めて共有ディスクを修復する場合もありうるが、Quorum Server障害時はクラスタを止めずに交換できる。

Oracle RAC構築のベスト・プラクティス

 このように、SGeFFのすばやいフェイルオーバーは、こうしたQuorum Serverの高速性とスケーラビリティ、高可用性に支えられて実現されていることがお分かりいただけたはずだ。

 日本HPでは、このSGeFFとOracle 9i RACの組み合わせによるフェイルオーバー検証作業を実施した。その結果、クラスタ再構成にかかる処理が5秒程度にまで短縮されていることが確認された。この検証結果は、HP-UX Developer Edgeの記事「Oracle RACフェイルオーバーを高速化するSGeFF・後編 」にて公開されている。また同記事では、さまざまなトラブル状況を考慮したベスト・プラクティスも紹介しているので、Oracle RAC導入を検討されている方はぜひ参考にしていただきたい。

第1回  

index
@IT [FYI]
Oracle 10g最強利用術──クラスタウェア有効活用法(2)
  第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 インデックス会議室利用規約プライバシーポリシーサイトマップ