This web page is no longer maintained. Information presented here exists only to avoid breaking historical links.
The Project stays maintained, and lives on: see the Linux-HA Reference Documentation.
To get rid of this notice, you may want to browse the old wiki instead.

Linux-HAアーキテクチャ（リリース2）

リリース2 は、ハイアベイラビリティ・クラスタ管理機能を実装するコンポーネントを備えています。 このページでは、これらのコンポーネントが適合するアーキテクチャの概要を紹介します。

以下のコンポーネントがあります:

• heartbeat - 強力な認証通信モジュール

• CRM - クラスタ・リソース・マネージャ

  • PE - CRM ポリシーエンジン

  • TE - CRM トランジションエンジン

  • CIB - クラスタ情報ベース

• CCM - 強力に連結されたコンセンサス・クラスタ・メンバーシップ

• LRM - ローカル・リソース・マネージャ

• Stonith Daemon - ノード・リセット・サービスを提供する

• logd - ノン・ブロッキング・ログ・デーモン

• apphbd - アプリケーションレベルのウォッチドッグ・タイマ・サービス

• Recovery Manager - アプリケーション回復サービス

• インフラストラクチャ

  • PILS - プラグイン・インターフェース読み込みシステム

  • IPC - プロセス間通信

  • #clplumbing:"クラスタ「プラミング」ライブラリ"

• CTS - クラスタ・テスト・システム - クラスタのストレステスト

• Glib に関する特記事項

アーキテクチャ図

heartbeat - 強力な認証通信モジュール

機能：起動、終了、強力な認証通信

IPベースかどうかに関係なく、全てのメディアを通じて、ローカルで管理された マルチ・キャスト・メッセージングを提供します。

現時点では、以下のメディア・プラグイン・タイプを通じて通信します。:

• ユニキャスト UDP ipv4

• ブロードキャスト UDP ipv4

• マルチキャスト UDP ipv4

• シリアル リンク（非IP） - iptablesを使用するファイアウォールなどでの使用に適している。

• openais - ja/OpenAIS_ja のevs通信レイヤーを通信メディアとして使用する。

• 疑似メンバーシップ通信サービス:

  • ping - 個々のルーターにpingを送信する。これを疑似メンバーとして扱うことができる。

  • ping_group - グループのいずれかのメンバーが動作していれば、グループが動作していると判断されることを除いて、pingに似ている

  • hbaping - ファイバー・チャネル・ディスクに「ping」し、接続性を確認する

Heartbeatは、0.5秒未満でノード障害を確実に検出することができます。 低遅延パッチ（そして、恐らくバグフィックスなど）により、 検出時間を大幅に短縮することが可能です。

構成に応じて、システム・ウォッチドッグ・タイマを登録します。

HeartbeatレイヤーのAPIは、以下のサービスを提供します。:

• クラスタ内通信 - クラスタノードとの間でパケットを送受信する。
• 構成のクエリ
• クエリと状態変化通知に対する接続性情報（現在のノードは、どこからパケットを受信できるか）
• 基本的なグループ・メンバーシップ・サービス

クラスタ・リソース・マネージャ

クラスタ・リソース・マネージャ（CRM）はLinux-HAの頭脳です。 CRMは、リソース構成を保持し、どのリソースをどこで実行するか、 あるいは現在の状態から適切な場所で動作する状態へどのように 移行するかを決定します。 さらに、これら全ての操作を実行する際LRMを管理します。 CRMは、システム内のあらゆるコンポーネントと通信します。:

• heartbeat を通信に使用する。

• CCM からメンバーシップの更新を受け取る。

• LRM の作業を指示し、LRMから通知を受け取る。

• デーモン"に、いつ何をリセットするかを命令する。

• ログデーモンを使用してログを記録する。

PE、TE、およびTEをCRMのコンポーネントと見なすことができます。

CRMポリシーエンジン（PE）

ポリシーエンジンの第一目標は、現状から 遷移グラフを計算することです。 この遷移グラフでは、現在の場所、リソースの状態、ノードの可用性、 現在の静的構成（現在のクラスタ状態）が計算に入れられます。

CRMトランジションエンジン（TE）

トランジションエンジンは、PEから生成された 遷移グラフを効果的に実行し、 予測を実現しようとします。つまり、計算されたクラスタの次の状態や 操作リストを受け取り、リモートノード上のLRMにリソースの開始/終了を 命令して目標に到達しようと試みます。

クラスタ情報ベース（CIB）

CIBは、CRMで確認されたクラスタリソースと ノード情報の自動複製レポジトリです。この情報には、依存関係などの 静的情報に加え、リソースが動作している場所やリソースの状態などの動的情報が含まれます。

CIB内の全ての情報は、最大限の操作性を確保するため、XMLで表記されます。 CIBで管理する全ての情報を定義した注釈付きの DTD を用意しています。

このため、CRM の多くの機能を注釈付きのDTDで理解することができます。

コンセンサス・クラスタ・メンバーシップ

強力に連結されたコンセンサス・クラスタ・メンバーシップ・サービスを提供します。 計算されたメンバーシップ内の全てのノードが同じメンバーシップ内のどのノードとも 通信できることを確認します。OCFドラフトメンバーシップAPIとSAF AISメンバーシップAPIの 両方を実装しています。通常は、メンバーシップを1秒未満で計算します。

ローカル・リソース・マネージャ

ローカル・リソース・マネージャは、 基本的にリソースエージェントの抽象化です。 CRMからの指示に従い、リソースを起動、停止、および監視します。

これはプラグイン構成になっており、リソースエージェントの多くを サポートすることが可能です。現時点では、以下のタイプがサポートされています。

• OCF - Open Cluster Framework
• Heartbeat（リリース1）スタイルのリソースエージェント
• LSB - Linux Standards Base（標準のinitスクリプト）リソースエージェント

• stonith - Stonith:デーモンが使用するSTONITHオブジェクトをインスタンス化

  • するためのリソース・エージェント・インターフェース

ほかのシステムとの互換性のために、ほかのタイプを簡単に追加できます。

Stonithデーモン

STONITHデーモンは、改良されたリリース2のstonith APIを使用して、 クラスタ全体でのノードのリセット機能を提供します。

Stonithライブラリには、約10種類の「C」STONITHプラグインのサポート、 スクリプトベースのプラグインのネイティブサポートが含まれます。これにより、 スクリプト言語で記述されたスクリプトを正式なSTONITHプラグインとして 処理することができます。

Stonithデーモンは、それ自身をメモリにロックし、「C」ベースのプラグインが stonithデーモンによってプレロードされるので、ディスクI/Oは「C」メソッドを 使用するSTONITH操作に要求されません。

Stonithデーモンは非対称のSTONITH構成を完全にサポートします。 これにより、特定のSTONITHデバイスには、クラスタ内のノードの サブセットからのみアクセスすることができます。

現時点では、リソース粒度の細かいフェンシングを提供するために Stonithデーモンを使用することは意図していません。リソース粒度の 細かいフェンシングに関する現在の考え方では、そのようなフェンシングを クローンリソースエージェントで実行する必要があります。フェンシングが 必要なリソースは、ほかのリソースに応じて決まります。ピアリソースが開始/停止すると、 クローンリソースエージェントに通知が送信されます。

logd - ノンブロッキング・ログ・デーモン

syslog、ファイル、またはその両方にログを記録します。logdはブロック化を行いません。 メッセージがブロック化よりも大きく遅れると、メッセージは失われます。次にメッセージ出力が 可能になったときに、失われたメッセージの数が出力されます。 キューのサイズは、アプリケーションごとか、または全体的に制御できます。

アプリケーションHeartbeatデーモン（apphbd）

アプリケーションHeartbeatデーモンは、HA対応アプリケーションに ウォッチドッグタイマ機能を提供する汎用サービスです。アプリケーションが 指定された時間内に通知を行わなかった場合、関係するユーザーに通知され、 （恐らく）復旧操作が実行されます。このデーモンは簡潔であり、システムで 最も信頼できるコンポーネントかもしれません。多くのLinux-HAシステムコンポーネントが これに取り組んでいますが、このドキュメントの執筆時点では一般的に 有効になっていません。これは要求に応じて、システム・ウォッチドッグ・タイマを登録します。

リカバリー・マネージャ・デーモン

プロセスがハートビートを送信せず、予期せず終了した場合、apphbdが リカバリー・マネージャ・デーモンに通知します。その後、リカバリー・ マネージャ・デーモンは、アプリケーションを（終了してから）再起動する 操作を実行します。

インフラストラクチャ

順調な実装の鍵となったのは、全ての主要コンポーネントに一貫性、柔軟性、 信頼性にすぐれた一般的なインフラストラクチャを採用したことです。

このインフラストラクチャには、重要な要素がいくつかあります:

• 柔軟な汎用プラグインメカニズム
• ノンブロッキングIPCレイヤー
• 完全なスレッドの回避（今までのところ）

• Glib のメインループを 一貫したディスパッチ（スケジュール）およびイベント処理方法として使用

• 高い一貫性と相互の統合

PILS - プラグイン・インターフェース読み込みシステム

PILSは、Linux-HAで幅広く使用される 一般的なプラグイン読み込みシステムを提供します。

これにより、実行するシステムのサイズを最小限に抑えながら、 システムの柔軟性と処理能力を高めることができます。 プラグインを使用するサブシステムのアーキテクチャが改善されます。 さらに、ホストサーバー上のLinux-HAシステムのリソース消費量を 最低限に抑えつつ、処理能力を高めることができます。

想定していなかったプラグインのメリットは、 コアメンバー以外からの貢献がプラグイン領域に集中していることです。

プラグインは、通信、認証、stonith、リソースエージェント、 圧縮、apphbd通知方式の各分野で使用されています。

IPCライブラリ

全てのプロセス間通信は、柔軟なキュー手順を使用してIPCへの ノンブロッキングアクセスを提供し、統合フロー制御を内蔵する ごく一般的なIPCライブラリを使用して行われます。このIPC APIは ソケットを必要としませんが、現在使用可能なインプリメンテーションは UNIX（ローカル）ドメインソケットを使用します。

さらに、このAPIは、組み込みのピアプロセス認証を内蔵し、 ほとんどのPOSIXライクなOSに移植可能です。

これらのAPIでメインループを使用しなければならないわけでは ありませんが、簡単で便利なメインループとの統合を実現しています。

Cluster Plumbing Library

クラスタ・プラミング・ライブラリは、メインコンポーネントの 多くで使用される各種サービスを提供する非常に便利な関数の集まりです。 以下に、このライブラリで提供される主なオブジェクトを挙げます:

• 圧縮API（基本の圧縮プラグインを含む）
• ノンブロッキングログAPI
• サービスを継続的に実行するためのメモリ管理
• 階層的な名前と値のペアメッセージング機能 - 移植性とバージョンアップグレードの互換性を向上させ、 オプションでメッセージ圧縮機能を提供する。
• シグナルの統合 - シグナルがメイン・ループ・イベントとして表示される。
• コアダンプ管理ユーティリティ - 均一な方法で、全ての状況でコアダンプを保存する。
• タイマ（glibメインループタイマに似ているが、時計が狂ったときでも動作する）
• 子プロセスの管理 - 子プロセスが消失すると、子プロセス消失のメッセージが表示され、プロセスオブジェクトが呼び出される。
• トリガ - ソフトウェアによってトリガされる任意のイベント
• リアルタイム管理 - 高い優先度を設定または設定解除し、プロセスのメモリ属性にロックされる。
• 64ビットHZ粒度の時間操作 (longclock_t)
• セキュリティのためのユーザーID管理 - root特権が必要なプロセス向け

• IPCの メインループ統合、 分かりやすいファイル記述子、シグナルなど。つまり、これらのさまざまなイベントソースは、 全てが一貫して管理され、ディスパッチされる。

クラスタ・テスト・システム

ユーザーの報告には、2種類のバグが含まれます。それは、 テストでは発見されなかったが、本来発見されるべきであったバグです。 Linux-HAは、バグの発生率は非常に低く、「テスト中に発見されるべきであった」 バグは極めて少ないです。

バグ発生率が低く抑えられる要因として、クラスタテストシステム（CTS）が挙げられます。

CTSは、ランダムなストレステストをクラスタに実行する自動化された クラスタ・テスト・システムです。CTSは、単純なテストを行う地味なシステムですが、 極めて高い効果を持っていることが分っています。

基本的な手順は、ソフトウェアが停止するまで酷使することです。 このテストは、Bamm-Bammテストとも呼ばれます。

CTSは、全体が各部の単なる合計を超えるシステムの一例です。

Glibの使用方法

Linux-HAプロジェクトでは、バージョン2のGnome Glibライブラリを幅広く使用しています。 特別な使用方法には、メインループ・イベントの 処理構造があります。 メインループを使用すると、多くの操作が簡単に均一化されます。スレッドを完全に 回避することができ、移植性とデバッグの問題も発生していません。

R2でのデータフロー

1. 全ての通信は heartbeat レイヤーで開始され、ほかのクラスタメンバーと通信するどのコンポーネントも heartbeat レイヤー を通じて通信します。さらに、Heartbeatレイヤーは、接続性情報を提供し、 相手ノードとの通信が失われたことを通知し、復旧した場合にも通知します。

2. これらの接続性の変化イベントは、メンバーシップレイヤー（CCM）に通知されます。 その後、CCMがクラスタ内のピアにパケットを送信し、どのノードが現在のメンバーに含まれるか、 あるいはどのノードがメンバーから外れたかを正確に把握します。
3. 新しいメンバーシップを計算すると、CCMはクライアントにメンバーシップの変更を通知します。 CCMの最も重要なクライアントはCRMとCIBです。
4. CCMから新しいメンバーシップを受け取ると、CIBは最新のメンバーシップ更新からの 情報を使用してCIBを更新し、CIBが更新されたことをクライアントに通知します。
5. CRMがCIBの変更を認識すると、次はポリシーエンジン（PE）に通知します。
6. PEはCIB（statusセクションを含む）を確認し、（CIBのstatusセクションに表示されている） クラスタの状態を定義されたポリシーと一致させるために実行しなければならない操作を認識します。
7. PEは、クラスタをポリシーと一致させるために実行すべき操作（存在する場合）のグラフを作成し、CRMに渡します。
8. CRMは、これらの操作をトランジションエンジン（TE）に通知し、実行に移します。
9. TEは（CRMを通じて）クラスタ内のさまざまなLRMに、指定した操作を実行するよう指示します。
10. 操作が完了するか、またはタイムアウトになるたびに、TEは状態の通知を受け取ります。
11. TEは、渡されたグラフに従って、引き続きLRMにその他の操作を要求します。
12. 全ての操作が完了すると、TEはCRMに成功したことを報告します。.

Linux-HA サイト built by the Linux-HA crowd. HTML4 / CSS2