heartbeatのクラスタマネージャとしての役割は、 クラスタの1つのマシンに障害が発生しても、 クラスタがクライアントへのサービスを継続できるようにすることです。 heartbeatがクラスタサービスとして管理するアプリケーションには、 次のようなものがあります。

基本的には、どのようなサーバアプリケーションでも heartbeatによりクラスタサービスとして管理できます。

heartbeatにより管理されるサービスは、 通常は起動時に開始されずに、システム起動構成から削除されます。 これらのサービスは、クラスタ構成と状態により必要に応じてクラスタマネージャが開始および停止します。 特定のサービスの実行中に、マシン(物理クラスタノード)に障害が発生すると、 heartbeatがクラスタの別のマシンで障害が発生したサービスを開始します。 heartbeatが実行するこの操作は、一般に(自動) フェイルオーバと呼ばれます。

1つのクラスタノードからもう一方へ手動で介入してクラスタサービスを移行することを、 手動フェイルオーバと呼びます。 これはいくらか矛盾した呼び方であるため、 本ガイドでは スイッチオーバという用語を使用します。

heartbeatを使用して、 障害が発生したノードが回復したらすぐに、リソースをこのノードに自動的に再移行することもできます。 この処理は フェイルバックと呼ばれます。

一般に、heartbeatが管理するクラスタサービスをノードで開始するには、 特定の要件を満たす必要があります。 一般的なデータベース駆動型Webアプリケーションの例を考えてみましょう。

heartbeatが制御するサービスおよびサービスが依存する追加要件を、 heartbeatの用語ではリソースと呼びます。 このリソースが相互に依存する集合を形成します。 この集合をリソースグループと呼びます。

heartbeatは、RA (リソースエージェント)と呼ばれる 標準化されたシェルスクリプトを呼び出してリソースを管理します。 heartbeatクラスタでは、次のようなタイプのリソースエージェントを使用できます。

heartbeatはUDPベースの通信プロトコルを使用し、 ノードの可用性を定期的にチェックします("heartbeat" proper)。 このために、heartbeatでは次のような通信方法を使用することができます。

中でも、IPマルチキャストとIPブロードキャストが広く使用されています。 クラスタが安定して動作するための最低要件として2つの独立した通信チャネルが必要です。

	重要項目
	ボンディングネットワークインタフェース (bondingドライバを使用した 物理インタフェースの仮想集積体)は、 1つのheartbeat通信チャネルを構成します。 ボンディングリンクは、bondingドライバの既知のバグや不明のバグから保護されません。 さらに、ボンディングリンクは 一般に同一のネットワークインタフェースモデルを使用して形成されるため、 NICドライバのバグに対しても脆弱です。 独立した第2のheartbeat通信チャネルがない場合は、 こうした問題によりクラスタ分割が発生する可能性があります。 したがって、第1のチャネルがボンディングインタフェースを使用するという理由で、 クラスタ構成から第2のheartbeatリンクを省略することは お勧めできません。