クラスターとは、ひとつのタスクを行うために連動して機能する 2 つ以上のコンピューターを指します(ノード または メンバー と呼ばれる)。クラスターには主に以下の 4 つのタイプがあります。

ストレージクラスターは、クラスター内の複数のサーバーに対して一貫性のあるファイルシステムイメージを提供し、ひとつの共有ファイルシステムに対する読み書きを同時に行えるようにします。アプリケーションのインストールやパッチの適用を任意のファイルシステムに制限することでストレージの管理を簡略化します。また、クラスター全体に一つのファイルシステムを持たせることでアプリケーションデータのコピーを重複して持たせる必要性が解消されるためバックアップや障害からの復元が簡略化されます。High Availability Add-On では、Red Hat GFS2 (Resilient Storage Add-On の一部) と併用することでストレージのクラスタ化を提供します。

高可用性クラスターは、単一点障害を排除し、ひとつのクラスターノードが動作不能になった場合にサービスを 1 つのクラスターノードから別のクラスターノードにフェイルオーバーすることにより、連続的にサービスの可用性を提供します。通常、高可用性クラスター内のサービスはデータの読み取りや書き込みを行います (read-write でファイルシステムがマウントされる)。従って、1 つのクラスターノードが別のクラスターノードからサービスの制御を引き継ぐ時点で、高可用性クラスターはデータの整合性を維持しなければなりません。高可用性クラスター内のノードの障害はクラスターの外側にあるクライアントからは見えません (高可用性クラスターはフェイルオーバークラスターと呼ばれることもあります)。High Availability Add-On では、高可性サービス管理コンポーネントの rgmanager を介して高可用性のクラスタ化を提供します。

負荷分散クラスターは、ネットワークサービス要求を複数のクラスターノードに分配して、クラスターノード間の要求負荷のバランスを取ります。負荷要件に応じてノード数を調節することができるため、対費用効果の高いスケーラビリティーを提供します。負荷分散クラスター内の 1 つのノードが動作不能になると、負荷分散ソフトウェアにより障害が検出され、要求が別のクラスターノードにリダイレクトされます。負荷分散クラスター内のノードの障害は、クラスターの外側にあるクライアントからは見えません。負荷分散機能は Load Balancer Add-On で利用できます。

ハイパフォーマンスクラスターは、クラスターノード群を使用して並列演算を行います。複数のアプリケーションが並行して動作できるため、アプリケーションのパフォーマンスが向上します (ハイパフォーマンスクラスターは演算クラスターまたはグリッドコンピューティングとも呼ばれます)。

High Availability Add-On は、パフォーマンス、高可用性、負荷分散、スケーラビリティー、ファイル共有、対費用効果など、ニーズに応じてさまざまな設定で導入できるソフトウェアコンポーネントの統合セットです。

High Availability Add-On は、以下の主要なコンポーネントから構成されています。

以下のコンポーネントで、High Availability Add-On を補足することができます。

High Availability Add-On のクラスターインフラストラクチャーは、コンピューター (ノードまたはメンバーと呼ばれる) の集合体が 1 つのクラスターとして連動して機能するための基本的な機能を提供します。クラスターインフラストラクチャーを使用してクラスターを形成した後、ニーズに合わせて他のコンポーネントを使用します (例えば、GFS2 ファイルシステムでファイルを共有するためクラスターをセットアップする、サービスのフェイルオーバーを設定するなど)。クラスターインフラストラクチャーでは次のような機能を実行できます。

定足数とは CMAN で使用される投票アルゴリズムです。

クラスターが正しく機能するのは互いにメンバーの状態に関して一般的な同意がある場合のみです。大多数のノードが正しく動作し、他の動作中のメンバーと通信、同意している場合、定足数を獲得していると表現します。たとえば、13 台のノードを持つクラスターの場合、7 台以上のノードが通信を行っている場合にのみ定足数に達したと言います。13 台のうち 7 台が停止してしまうと定足数を失ってしまうためクラスターは正しく機能しなくなります。

split-brain の問題を防ぐには定足数を維持する必要があります。定足数を実施していなかった場合、上述の 13 台のノード上で通信エラーが発生すると、13 台のうちの 6 台と別の 6 台が別々に同じ共有ストレージで動作してしまような状態を招く可能性があります。通信エラーのため、2 つに分離されたクラスターの一部同士がディスク領域を上書きするためファイルシステムが破損します。定足数のルールを実施すると、片方のみが共有ストレージを使用するためデータの整合性を確保することができます。

定足数が split-brain 状態を防ぐわけではありませんが、定足数によりクラスター内で優先して動作させるノードが決定されます。split-brain が発生した場合には、複数のノードグループが同時に動作しないよう防ぎます。

定足数はクラスターノード間で行われるイーサネット経由のメッセージ通信で確定されます。オプションでイーサネットに加え 定足数ディスク も組み合わせたメッセージ通信で確定することもできます。イーサネット経由の定足数の場合、定足数とは単純に過半数になります (全ノード数の 50% + 1)。定足数ディスクを設定する場合は、定足数はユーザーが指定した条件になります。

フェイルオーバードメインは、サービスがバインドされる可能性のあるメンバーの順序付けられたサブセットです。フェイルオーバードメインは、クラスターのカスタマイズには役立ちますが操作に必須ではありません。

以下に、フェイルオーバードメインの動作に影響を与える複数の設定オプションについて、これらを規定するセマンティクスをリストします。

Ordering (順序付け)、restriction (制限)、nofailback (フェイルバックなし) はフラグであり、ほぼすべての組み合わせ (ordered+restricted、unordered+unrestricted など) が可能です。これらの組み合わせは、初回の定足数形成後のサービスを起動する場所や、サービスが失敗した場合にどのクラスターメンバーがサービスを引き継ぐかに影響を与えます。

RGManager には、管理者がサービスごとカスタマイズできる 3 つのサービスリカバリーポリシーがあります。

<service name="myservice" max_restarts="3" restart_expire_time="300" ...>
  ...
</service>

以下は、リソースツリーの構造を図示しており、各領域の定義を以下にリストします。

    <service name="foo" ...>
        <fs name="myfs" ...>
            <script name="script_child"/>
        </fs>
        <ip address="10.1.1.2" .../>
    </service>

以下の操作は、仮想マシンにのみ有効な移行操作を除き、サービスと仮想マシンの両方に適用されます。

RGManager は、VM 以外の他のサービスとは少し異なる方法で仮想マシンを扱います。

RGManager は、リソースエージェントから以下の戻り値を予期します。

DLM のロッキングモデルは、多数のロッキングモードのセットと、同期/非同期の両方の実行を提供します。アプリケーションは、ロックリソース上でロックを取得します。ロックリソースとロックの間には 1 対多の関係があります。単一のロックリソースには、これに関連付けられた複数のロックが含めることができます。

ロックリソースは、ファイル、データ構造、データベース、または実行可能なルーチンなどの実際のオブジェクトに対応させることができますが、必ずしもこれらのいずかに対応させる必要はありません。ロックリソースに関連付けるオブジェクトは、ロックの粒度を定めるものです。例えば、データベース全体のロックは粒度の粗いロックと見なされ、データベース内の各項目のロックは粒度の細かいロックと見なされます。

DLM のロッキングモデルは以下をサポートします。

DLM は、ロックトラフィックを管理するためのノード間通信や、ノード障害の発生後のロックのリマスタリングまたはノードがクラスターに入る際のロック移行を行うリカバリープロトコルなどのロック機能をサポートする独自の仕組みを提供します。ただし、DLM はクラスター自体を実際に管理する仕組みは提供しません。従って DLM は、以下の最低要件を満たす他のクラスターインフラストラクチャー環境と連動してクラスター内で動作することが予期されます。

DLM は、上記の最低要件を満たすすべてのクラスターインフラストラクチャー環境で機能します。オープンソースまたはクローズドソース環境のどちらを使用するについてはユーザーが決定できます。ただし DLM には、複数の環境を使って実施されるテスト量に関して主な制限があります。

ロックの状態は、ロック要求の現在の状態を示します。ロックは常に以下の 3 つの状態のいずれかになります。

ロックの状態は、その要求されるモードと同じリソース上の他のロックのノードによって決定されます。

Red Hat High Availability Add-On ソフトウェアの管理では、クラスターコンポーネント間の関係を指定するために設定ツールが使用されます。以下のクラスター設定ツールは、Red Hat High Availability Add-On で利用できます。

RHEL HA と RHEV はどちらも高可用性の仮想マシンを提供する仕組みを提供します。機能が重複していることを考慮すると、具体的なユースケースに適している製品を慎重に選択する必要があります。以下は、RHEL HA と RHEV のどちらを VM の高可用性を提供する製品として選択するかについての考慮すべきいくつかのガイドラインになります。

仮想マシンおよび物理ホスト数:

仮想マシンの使用:

RHEL 5 は、2 つの仮想化プラットフォームをサポートします。Xen は RHEL 5.0 リリース以降サポートされており、RHEL 5.4 では KVM が導入されました。

RHEL 6 は、仮想化プラットフォームとして KVM のみをサポートしています。

RHEL 5 AP クラスターは、ホストクラスターインフラストラクチャーで管理される仮想マシンの実行に、KVM と Xen の両方の使用をサポートします。

RHEL 6 HA は、ホストクラスターインフラストラクチャーで管理される仮想マシンの実行に使用される KVM をサポートしています。

以下は、Red Hat によって現在サポートされているデプロイメントシナリオのリストです。

管理対象リソースとして実行される仮想マシンがどの種類であるかは、問題にはなりません。RHEL で Xen または KVM のいずれかによってサポートされているすべてのゲストを高可用性ゲストとして使用できます。これには、各種の RHEL (RHEL3、RHEL4、 RHEL5) や Microsoft Windows のいくつかの種類が含まれます。RHEL のドキュメンテーションを参照し、各ハイパーバイザーでサポートされるゲストオペレーティングシステムの最新リストを確認してください。

これは、各種の仮想化プラットフォーム上で仮想化されたゲスト内で実行される RHEL Cluster/HA に関連するものです。このユースケースでは、ゲスト内で実行されるアプリケーションの高可用性を維持するために RHEL クラスタリング/HA が主に使用されます。このユースケースは、RHEL クラスタリング/HA がベアメタルホストで常に使用されてきた方法と類似しています。相違点は、クラスタリングがゲスト内で実行される点です。

以下は、仮想化プラットフォームと RHEL Cluster/HA を使用してゲストクラスターを実行するために現在利用できるサポートレベルのリストです。以下のリストでは、RHEL 6 のゲストは、High Availability (コアクラスタリング) と Resilient Storage アドオン (GFS2、clvmd および cmirror) の両方をサポートします。