Novell Doc: High Availability ガイド

1.4 アーキテクチャ

このセクションではHigh Availability Extensionアーキテクチャについて簡単に説明します。アーキテクチャコンポーネントと、その相互運用方法について説明します。

1.4.1 アーキテクチャ層

High Availability Extensionは階層化されたアーキテクチャになっています。Figure 1-6に異なる層と関連するコンポーネントを示します。

Figure 1-6 アーキテクチャ

メッセージングおよびインフラストラクチャ層

プライマリ、または最初の層は、メッセージングおよびインフラストラクチャ層で、OpenAIS層とも呼ばれています。この層には、I'm alive信号やその他の情報を含むメッセージを送信するコポーネントが含まれます。High Availability Extensionのプログラムはメッセージングおよびインフラストラクチャ層に常駐しています。

リソース割り当て層

次の層はリソース割り当て層です。この層は最も複雑で、次のコンポーネントから構成されていいます。

CRM (クラスターリソースマネージャ)

リソース割り当て層のすべてのアクションは、クラスターリソースマネージャを通過します。リソース割り当て層の他のコンポーネント(または上位層のコンポーネント)による通信の必要性が発生した場合は、ローカルCRM経由で行います。

CRMは各ノードにを持っており、ここにはすべてのクラスタオプション、ノード、リソース、関係の定義や現在の状態が含まれています。クラスタ内の1つのCRMがDC(指定コーディネータ)として選択され、マスタCIBがそこに保存されます。クラスタ内のその他すべてのCIBはマスタCIBのレプリカです。CIBに対する通常の読み書き操作は、マスタCIBによってシリアルに処理されます。DCは、ノードのフェンシングやリソースの移動など、クラスタ全体に及ぶ変更が必要かどうかを判断できる、クラスタ内で唯一のエンティティです。

CIB (クラスタ情報ベース)

クラスタ情報ベースは、メモリ内でクラスタ全体の設定や現在の状態をXML形式で表すものです。すべてのクラスタオプション、ノード、リソース、制約、相互関係の定義が含まれます。CIBはすべてのクラスタノードへの更新の同期化も行います。DCが管理するマスタCIBがクラスタ内に1つあります。その他のノードにはCIBのレプリカが含まれます。

PE (ポリシーエンジン)

指定コーディネータがクラスタ全体に及ぶ変更(新しいCIBへの反映)が必要になった場合、ポリシーエンジンが現在の状態と設定に基づき、クラスタの次の状態を計算します。PEは(リソース)アクションのリストと、次のクラスタ状態に移るために必要な依存性を含む遷移グラフも作成します。PEはDCのフェールオーバー速度を上げるため、各ノードで実行されます。

LRM(ローカルリソースマネージャ)

LRMはCRMに代わってローカルリソースエージェントを呼び出します(リソース層を参照)。そのため、操作の開始、停止、監視を行い、結果をCRMに報告します。リソースエージェントに対してサポートされているスクリプト標準規格(OCF、LSB、Heartbeat Version 1)間の違いも非表示にします。LRMはそのローカルノード上にある全リソースに関連する情報の信頼されたソースです。

リソース層

最も上位の層はリソース層です。リソース層には1つ以上のリソースエージェント(RA)が含まれます。リソースエージェントは通常シェルスクリプトなど、特定の種類のサービス(リソース)を開始、停止、監視するためのプログラムです。リソースエージェントの呼び出しはLRMだけが行います。サードパーティはファイルシステム内の定義された場所に独自のエージェントを配置して、自社ソフトウェア用に、すぐに使えるクラスタ統合機能を提供することができます。

1.4.2 プロセスフロー

はPacemakerをCRMとして使用します。CRMは各クラスタノード上にインスタンスを持つデーモン(crmd)として実装されます。Pacemakerは、マスタとして動作する1つのcrmdインスタンスを選択し、クラスタのすべての意思決定を一元化します。選択したcrmdプロセス(またはその下のノード)で障害が発生したら、新しいcrmdプロセスが確立されます。

クラスタの構成とクラスタ内のすべてのリソースの現在の状態を反映したCIBが、各ノードに保存されます。CIBのコンテンツはクラスタ全体で自動的に同期化されます。

クラスタ内で実行するアクションの多くは、クラスタ全体に及ぶ変更を伴います。これらのアクションにはクラスタリソースの追加や削除、リソース制約の変更などがあります。このようなアクションを実行すると、クラスタ内でどのような変化が発生するのかを理解することが重要です。

たとえば、クラスタIPアドレスリソースを追加するとします。そのためには、コマンドラインツールかGUIを使用してCIBを変更できます。DC上でアクションを実行する必要はなく、クラスタ内の任意のノードでいずれかのツールを使用すれば、DCに反映されます。そして、DCがすべてのクラスタノードにCIBの変更を複製します。

CIBの情報に基づき、PEがクラスタの理想的な状態と実行方法を計算し、指示リストをDCに送ります。DCはメッセージングおよびインフラストラクチャ層を経由してコマンドを送信し、他のノードのcrmdピアがこれらを受信します。各crmdはLRM(lrmdとして実装)を使用してリソースを変更します。lrmdはクラスタに対応しておらず、リソースエージェント(スクリプト)と直接通信します。

すべてのピアノードは操作結果をDCに返送します。DCが、すべての必要な操作がクラスタ内で成功したことを確認すると、クラスタはアイドル状態に戻り、次のイベントを待機します。予定通り実行されなかった操作があれば、CIBに記録された新しい情報を元に、PEを再度呼び出します。

場合によっては、共有データの保護や完全なリソース復旧のためにノードの電源を切らなければならないことがあります。このPacemakerにはフェンシングサブシステムとしてstonithdが内蔵されています。STONITHはShoot The Other Node In The Head(他のノードの即時強制終了)の略語で、通常はリモート電源スイッチを使用して実装されます。Pacemaker、STONITHデバイスはリソースとしてモデル化され(CIB内で環境設定)、障害を簡単に監視できるようにします。ただし、stonithdはクライアントがフェンシングの必要なノードを指定するだけで、残りの作業を処理できるような、STONITHトポロジを把握します。