リリース2 は、ハイアベイラビリティ・クラスタ管理機能を実装するコンポーネントを備えています。 このページでは、これらのコンポーネントが適合するアーキテクチャの概要を紹介します。
以下のコンポーネントがあります:
heartbeat - 強力な認証通信モジュール
CRM - クラスタ・リソース・マネージャ
CCM - 強力に連結されたコンセンサス・クラスタ・メンバーシップ
LRM - ローカル・リソース・マネージャ
Stonith Daemon - ノード・リセット・サービスを提供する
logd - ノン・ブロッキング・ログ・デーモン
apphbd - アプリケーションレベルのウォッチドッグ・タイマ・サービス
Recovery Manager - アプリケーション回復サービス
CTS - クラスタ・テスト・システム - クラスタのストレステスト
Glib に関する特記事項
機能:起動、終了、強力な認証通信
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のコンポーネントと見なすことができます。
ポリシーエンジンの第一目標は、現状から 遷移グラフを計算することです。 この遷移グラフでは、現在の場所、リソースの状態、ノードの可用性、 現在の静的構成(現在のクラスタ状態)が計算に入れられます。
トランジションエンジンは、PEから生成された 遷移グラフを効果的に実行し、 予測を実現しようとします。つまり、計算されたクラスタの次の状態や 操作リストを受け取り、リモートノード上のLRMにリソースの開始/終了を 命令して目標に到達しようと試みます。
CIBは、CRMで確認されたクラスタリソースと ノード情報の自動複製レポジトリです。この情報には、依存関係などの 静的情報に加え、リソースが動作している場所やリソースの状態などの動的情報が含まれます。
CIB内の全ての情報は、最大限の操作性を確保するため、XMLで表記されます。 CIBで管理する全ての情報を定義した注釈付きの DTD を用意しています。
このため、CRM の多くの機能を注釈付きのDTDで理解することができます。
強力に連結されたコンセンサス・クラスタ・メンバーシップ・サービスを提供します。 計算されたメンバーシップ内の全てのノードが同じメンバーシップ内のどのノードとも 通信できることを確認します。OCFドラフトメンバーシップAPIとSAF AISメンバーシップAPIの 両方を実装しています。通常は、メンバーシップを1秒未満で計算します。
ローカル・リソース・マネージャは、 基本的にリソースエージェントの抽象化です。 CRMからの指示に従い、リソースを起動、停止、および監視します。
これはプラグイン構成になっており、リソースエージェントの多くを サポートすることが可能です。現時点では、以下のタイプがサポートされています。
stonith - Stonith:デーモンが使用するSTONITHオブジェクトをインスタンス化
ほかのシステムとの互換性のために、ほかのタイプを簡単に追加できます。
STONITHデーモンは、改良されたリリース2のstonith APIを使用して、 クラスタ全体でのノードのリセット機能を提供します。
Stonithライブラリには、約10種類の「C」STONITHプラグインのサポート、 スクリプトベースのプラグインのネイティブサポートが含まれます。これにより、 スクリプト言語で記述されたスクリプトを正式なSTONITHプラグインとして 処理することができます。
Stonithデーモンは、それ自身をメモリにロックし、「C」ベースのプラグインが stonithデーモンによってプレロードされるので、ディスクI/Oは「C」メソッドを 使用するSTONITH操作に要求されません。
Stonithデーモンは非対称のSTONITH構成を完全にサポートします。 これにより、特定のSTONITHデバイスには、クラスタ内のノードの サブセットからのみアクセスすることができます。
現時点では、リソース粒度の細かいフェンシングを提供するために Stonithデーモンを使用することは意図していません。リソース粒度の 細かいフェンシングに関する現在の考え方では、そのようなフェンシングを クローンリソースエージェントで実行する必要があります。フェンシングが 必要なリソースは、ほかのリソースに応じて決まります。ピアリソースが開始/停止すると、 クローンリソースエージェントに通知が送信されます。
syslog、ファイル、またはその両方にログを記録します。logdはブロック化を行いません。 メッセージがブロック化よりも大きく遅れると、メッセージは失われます。次にメッセージ出力が 可能になったときに、失われたメッセージの数が出力されます。 キューのサイズは、アプリケーションごとか、または全体的に制御できます。
アプリケーションHeartbeatデーモンは、HA対応アプリケーションに ウォッチドッグタイマ機能を提供する汎用サービスです。アプリケーションが 指定された時間内に通知を行わなかった場合、関係するユーザーに通知され、 (恐らく)復旧操作が実行されます。このデーモンは簡潔であり、システムで 最も信頼できるコンポーネントかもしれません。多くのLinux-HAシステムコンポーネントが これに取り組んでいますが、このドキュメントの執筆時点では一般的に 有効になっていません。これは要求に応じて、システム・ウォッチドッグ・タイマを登録します。
プロセスがハートビートを送信せず、予期せず終了した場合、apphbdが リカバリー・マネージャ・デーモンに通知します。その後、リカバリー・ マネージャ・デーモンは、アプリケーションを(終了してから)再起動する 操作を実行します。
順調な実装の鍵となったのは、全ての主要コンポーネントに一貫性、柔軟性、 信頼性にすぐれた一般的なインフラストラクチャを採用したことです。
このインフラストラクチャには、重要な要素がいくつかあります:
Glib のメインループを 一貫したディスパッチ(スケジュール)およびイベント処理方法として使用
PILSは、Linux-HAで幅広く使用される 一般的なプラグイン読み込みシステムを提供します。
これにより、実行するシステムのサイズを最小限に抑えながら、 システムの柔軟性と処理能力を高めることができます。 プラグインを使用するサブシステムのアーキテクチャが改善されます。 さらに、ホストサーバー上のLinux-HAシステムのリソース消費量を 最低限に抑えつつ、処理能力を高めることができます。
想定していなかったプラグインのメリットは、 コアメンバー以外からの貢献がプラグイン領域に集中していることです。
プラグインは、通信、認証、stonith、リソースエージェント、 圧縮、apphbd通知方式の各分野で使用されています。
全てのプロセス間通信は、柔軟なキュー手順を使用してIPCへの ノンブロッキングアクセスを提供し、統合フロー制御を内蔵する ごく一般的なIPCライブラリを使用して行われます。このIPC APIは ソケットを必要としませんが、現在使用可能なインプリメンテーションは UNIX(ローカル)ドメインソケットを使用します。
さらに、このAPIは、組み込みのピアプロセス認証を内蔵し、 ほとんどのPOSIXライクなOSに移植可能です。
これらのAPIでメインループを使用しなければならないわけでは ありませんが、簡単で便利なメインループとの統合を実現しています。
クラスタ・プラミング・ライブラリは、メインコンポーネントの 多くで使用される各種サービスを提供する非常に便利な関数の集まりです。 以下に、このライブラリで提供される主なオブジェクトを挙げます:
IPCの メインループ統合、 分かりやすいファイル記述子、シグナルなど。つまり、これらのさまざまなイベントソースは、 全てが一貫して管理され、ディスパッチされる。
ユーザーの報告には、2種類のバグが含まれます。それは、 テストでは発見されなかったが、本来発見されるべきであったバグです。 Linux-HAは、バグの発生率は非常に低く、「テスト中に発見されるべきであった」 バグは極めて少ないです。
バグ発生率が低く抑えられる要因として、クラスタテストシステム(CTS)が挙げられます。
CTSは、ランダムなストレステストをクラスタに実行する自動化された クラスタ・テスト・システムです。CTSは、単純なテストを行う地味なシステムですが、 極めて高い効果を持っていることが分っています。
基本的な手順は、ソフトウェアが停止するまで酷使することです。 このテストは、Bamm-Bammテストとも呼ばれます。
CTSは、全体が各部の単なる合計を超えるシステムの一例です。
Linux-HAプロジェクトでは、バージョン2のGnome Glibライブラリを幅広く使用しています。 特別な使用方法には、メインループ・イベントの 処理構造があります。 メインループを使用すると、多くの操作が簡単に均一化されます。スレッドを完全に 回避することができ、移植性とデバッグの問題も発生していません。
全ての通信は heartbeat レイヤーで開始され、ほかのクラスタメンバーと通信するどのコンポーネントも heartbeat レイヤー を通じて通信します。さらに、Heartbeatレイヤーは、接続性情報を提供し、 相手ノードとの通信が失われたことを通知し、復旧した場合にも通知します。