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

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

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

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

「クラスタ再構成」とは、障害を検知してから、クラスタをどのように再構成すればよいか決定するまでのプロセスである。その詳細については、以前の特集「HAクラスタの疑問を解く・後編」で解説したとおりだ。

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

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

なぜSGeFFは高速なのか

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

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

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

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