HAクラスタの疑問を解く・後編

≫ HP-UX 11i
Knowledge-on-Demand

≫コラム

≫連載
≫特集、特別企画

ドキュメント/ツール

HPラボ

≫Webキャスト

フェイルオーバの全体像

HAクラスタにおけるフェイルオーバの全体像を理解するために、まずは、図1を見てほしい。

図1：フェイルオーバ処理の内訳

同図は、Serviceguardのフェイルオーバで実行される一連の処理を表したものだ。この図が示すように、フェイルオーバでは大きく分けて以下の2つの処理が実行される。

クラスタソフトのフェイルオーバ処理
アプリケーションの起動

たとえばServiceguardの場合、前者には最短で30秒を要する。また、後述する高速フェイルオーバ機能を利用すれば、その時間は5秒にまで短縮が可能だ。

しかし、HAクラスタのダウンタイムにもっとも大きく影響するのは、後者のアプリケーションの起動である。たとえば一般的なデータベースの場合、フェイルオーバ後にはデータベース・インスタンスの起動をはじめ、トランザクションのロールバックやロールフォワードといった比較的時間のかかる処理を実行しなくはならない。もしこの処理が数分に及べば、クラスタソフトのフェイルオーバ処理の速さはあまり重要ではなくなる。一方、メール・サーバやWebサーバ、またはOracleデータベースのクラスタ機能であるRAC（Real Application Clusters）のように数秒で切り替え可能なアプリケーションであれば、逆にクラスタソフトの処理時間の方が相対的に長くなる。HAクラスタを構築する際には、この2つの時間のバランスを考慮しながらクラスタソフトを適切に設定する必要があるだろう。

このポイントをふまえた上で、以下ではトラブル時に最初に実行されるServiceguardのフェイルオーバ処理に注目してみたい。

	Serviceguardのフェイルオーバ処理

図1が示すように、Serviceguardのフェイルオーバ処理は大きく分けて以下の3つの段階から成っている。

障害の検知
クラスタの再構成
パッケージのリカバリ

フェイルオーバは、第1段階の「障害の検知」をきっかけにスタートする。たとえばプライマリ・ノードからの音信がしばらく途絶えているといった事象をもとに、同ノードにトラブルが発生していると判断する。この障害の検知につづいては、第2段階「クラスタの再構成」に進む。具体的には、障害ノードを切り離し、生き残ったノードからなる新しいHAクラスタを構成するための一連の手順が実施される。そして最後の第3段階は、「パッケージのリカバリ」である。この段階では、アプリケーション移行先のスタンバイ・ノードを決定し、次にアプリケーションが障害直前まで使用していたシステム・リソース（共有ディスクのボリュームやIPアドレスなど）をスタンバイ・ノードに引き渡し、利用可能な状態にする。これで、スタンバイ・ノードにおいてアプリケーションを再起動する準備が整うことになる。

では、これら3つの段階について、より詳細な動作メカニズムについて掘り下げていこう。

第1段階：障害の検知

まずは、第1段階である障害の検知のメカニズムから説明しよう。Serviceguardでは、以下の3種類の障害を検知することができる。

ノード障害
ネットワーク障害
アプリケーション障害

「ノード障害」とは、すなわちハードウェアやOSのトラブルによってノード全体がダウンした状況を指す。Serviceguardでは、ノード障害を検出するために、「ハートビート」と呼ばれるメッセージをクラスタのネットワーク上で交換している。

ServiceguardによるHAクラスタでは、いずれか1台のノードがクラスタ全体を統括する「クラスタ・コーディネータ」として振る舞う。クラスタ・コーディネータは、以下の図2が示すように、他のすべてのノードに向けてハートビートを1秒間隔で送信する。

図2：ハートビートの送受信

ハートビートを受信した各ノードは、ただちに返信のハートビートをクラスタ・コーディネータに送り返す。そして、あらかじめ設定したタイムアウト時間（デフォルトは 2 秒、推奨値は5～8秒程度）が経過しても返信がない場合、そのノードに障害が発生したと判断する。また逆に、クラスタ・コーディネータからのハートビートが途絶えてしまった場合は、同コーディネータのノード障害と判断され、残りのノードのいずれかが新しいコーディネータとして選出される仕組みだ。

このハートビートの交換は、ServiceguardによるHAクラスタの命綱ともいえるメカニズムだ。仮に、ネットワークの輻輳によってハートビートのパケットが紛失するような状況になると、HAクラスタ全体の統率に混乱をきたすことになる。よって、より高い可用性が求められる用途では、ハートビート専用のLANを設け、さらにそれを二重化することが推奨されている。

一方、Serviceguardでは、ネットワーク・インタフェース・カード（NIC）やスイッチのトラブル、すなわち「ネットワーク障害」の検知も行う。各ノードのすべてのNICを通じてデータリンク層のパケットを2秒間隔で送受信することで、NICやネットワークの正常動作を常に監視している。また、Serviceguardの最新バージョンA.11.16では、NIC障害を判定する基準について、以前のバージョンよりも柔軟な設定が可能になり、たとえばパケットの受信のみ不具合があるような状況でも障害として検出できるようになった。NICのドライバ・ソフトウェアから発せられたエラーを捕らえてフェイルオーバを開始することも可能だ。

Serviceguardが検知可能なもうひとつのトラブルは、「アプリケーション障害」である。特集1で説明したとおり、Serviceguardでは、パッケージと呼ばれる単位で個々のアプリケーションを管理している。プライマリ・ノードにおいてパッケージが起動すると、それに含まれるアプリケーションのプロセス、そしてアプリケーションが利用するシステム・リソース（共有ディスクのボリュームなど）の監視を開始する。そして、これらの状態に異常を検知した場合、アプリケーション障害としてフェイルオーバを開始するメカニズムである。

ちなみに、アプリケーション障害の場合、プライマリ・ノードそのものがダウンしてしまったわけではないため、次に説明するクラスタの再構成の処理はスキップされる。よって、Serviceguardによるフェイルオーバ処理の時間は大幅に短縮されることになる。