This site best when viewed with a modern standards-compliant browser. We recommend Firefox Get Firefox!.

Linux-HA project logo
Providing Open Source High-Availability Software for Linux and other OSes since 1999.

USA Flag UK Flag

Japanese Flag

ホームページ

サイトについて

コンタクト情報

使用条件

協力方法

セキュリティ

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.

2010.1.28
追加パッケージ集リニューアル
追加パッケージ集は、こちらから

2008.8.28
RHEL用rpm更新
更新情報はこちらから

2008.8.18
Heartbeat 2.1.4
リリース!
Downloadはこちらから

2007.11.13
Linux-ha-japan日本語ML移植しました

2007.10.5
日本語サイトOPEN
日本語MLも開設しました

2007.10.5
OSC2007 Tokyo/Fall で Heartbeat紹介
発表資料を公開しました

Last site update:
2017-12-14 03:25:44

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

クラスタ・リソース・マネージャは、以下のコンポーネントから構成されます:

クラスタ・リソース・マネージャは、他のクラスタノード上の クラスタ・リソース・マネージャ・デーモン指定コーディネータと通信するために、IPCを使用してメッセージや Heartbeatメッセージをサブシステムに送信します。

See also

クラスタ・リソース・マネージャ/セットアップ, クラスタ・リソース・マネージャ/バグレポート, クラスタ・リソース・マネージャ/関連項目, クラスタ情報ベース/ユーザーガイド


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

#pragma section-numbers on

これはあくまでもドラフトです。

  • <!> この文書に記載されているアイデアは、まだしっかりとは分類されておらず、 未完成です。私(筆者)自身、まだ満足のいかない表現もあります。また、さらに 説明が必要なアイデアもあります。紹介したアイデアの大部分は、最終版ではありません。 それらは、体験談から構成されています。

    しかも、まだドラフト版です!!!!!! ?

Title: Design of a Cluster Resource Manager
Revision: $Id: crm.txt,v 1.2 2003/12/01 14:10:14 lars Exp $
Author: Lars Marowsky-Brée <lmb@suse.de>
Acknowledgements:
  Andrew Beekhof <andrew@beekhof.net>
  Luis Claudio R. Goncalves <lclaudio@conectiva.com.br>
  Fábio Olivé Leite <olive@conectiva.com.br>
  Alan Robertson <alanr@unix.sh>


このドキュメントのグローバルなTODOリスト

このセクションでは、今後、本ドキュメントで実施する予定の作業をお知らせします。 あまり関心を持たれない内容かもしれませんので、最終版ではこのセクションは削除する予定です;-)

  • 主要部分(CIB、ポリシーエンジンなど)をそれぞれ別のドキュメントに分類する。
  • 使用するサブ機能に参照を追加し、ここでは多くの情報を反復しない。 参照は、機能リストの機能IDの形態をとる。
  • コンポーネントを参照する際の用語を統一する。
  • doc書類に変換する(急ぎではない)。


要約

  • この文書では、Heartbeatが提供するオープン・クラスタ・フレームワーク(OCF) インフラストラクチャへの追加および改善を実行するクラスタ化された リカバリー/リソースマネージャの設計を概説します。 目的は、Nノードのクラスタにおいて、柔軟なリソース割り当てとグローバルな 順序付けを許可し、障害発生時に、ダイナミックにリソースを割り当てる(「フェイルオーバ」)か、 またはクラスタに管理上の変更を施す(「スイッチオーバ」)ことです。 この新しいクラスタ・リソース・マネージャは、現在使用されているHeartbeatの 「リソースマネージャ」を置き換えるためのものです。


概要

要件の概要

CRMは、以下の機能を提供する必要があります:

  • 安全
  • シンプル
  • Heartbeatは、すでに上記2つの特性を備えており、新しいリソースマネージャで 安全性が低下するようなことは決してあってはなりません。開発者、 そして特にユーザーの)健全性と安定性のため、複雑化は最小限に留めなければなりません (ただし、これ以上シンプルにはなりません)
  • 3ノード以上のサポート
  • 耐障害性(ノード、ネットワーク、リソースの障害が考えられます)
  • リソースの割り当てと依存関係に関する複雑なポリシーを取り扱う能力。例:
    • グローバルな順序の開始順序をサポート
    • 複製されたリソースへの対応を改善するための割り当てプロセスにおけるフィードバックをサポート
    • 偽の依存関係など
  • リソースの移行、新しいリソースの追加、リソースの削除などの管理要求をオンラインで行う能力
  • 拡張性のあるフレームワーク

シナリオの説明

  • この文書で概説する設計は、以下の特性を備えたクラスタを対象としています。 以下は、特性にかんする具体的な内容です。
  • クラスタは、OCFドキュメントに概説され、Ram PaiによるCCM実装がそうであるように、 コンセンサス・メンバーシップ・レイヤーを提供します(このレイヤーは、クラスタメンバーシップに 関する表示をパーティション内の全てのノードに提供し、これによって完全に接続されたノードの 最大セットを計算します)。
  • 特定パーティションのノードは、分散決定を行わずに、パーティション内の 全ノードに同じ方法で順序付けすることができます。これは、全ノード上で同じ 順序でメンバーシップを返すか、または特徴的な属性を各ノードに与えることに よって行われます。
  • クラスタは、ブロードキャストメッセージングだけでなく、ユニキャスト メッセージングの通信機構を提供します。メッセージは、必ずしも決まった 順番に並べられている必要はありませんが、アトミックメッセージとして扱われます。
  • ビザンチン故障は、まれにしか発生せず、外部に影響を及ぼしません。 安定ストレージは安定しており、そうでない場合でも損傷しません。 偽のネットワークパケットなどは発生していません。 これらのエラーは、上位へ伝播しないように適切な対策 (チェックサム、認証、エラー回復、フェイルファスト)が 講じられている各コンポーネントで食い止められます。
  • 時刻はクラスタ全体で同期されます。ネットワークパーティションが 存在しても、時刻のずれは、ある一定を上回ることはありません。 これは、クラスタ内の全ノードでNTPを実行すれば、確実にできます。
  • クラスタ内ではIOフェンシング機構を利用することができます。 フェンシング機構により、特定のフェンシング要求が成功したかどうか、 フィードバックが提供されます。
  • ノードは、現在保有しているリソースおよびその状態(実行中/障害発生/停止済み)を 識別しており、問い合わせに応じてこの情報を提供し、CRM/に状態変更を通知することができます (この部分は、ローカル・リソース・マネージャによって提供されます)。

基本的なアルゴリズム

  • 基本的なアルゴリズムは、以下のとおりです:

  1. 全てのパーティションは「指定コーディネータ(DC)」を選択します。 このノードは、特別なロジックを起動し、クラスタ内の全てのノードにおける復旧と 管理操作を調整します。
    • a1) DCは、管理ポリシーの最新コピー、フェンシングされたノードに関する情報に加え、 入手可能(あるいは取得可能)なクラスタの完全な状態を保有しています。 これは、「クラスタ情報ベース」と呼ばれます。
    b) 管理要求、メンバーシップサービスによるノード障害、あるいは関与している LRMによって報告されたリソース障害など、クラスタイベントが発生すると、 「指定コーディネータ」に転送されます。
    • b1) 管理要求について、DCは、それらをCIBに受け入れるかどうかを決定し、 これらの最新情報に通し番号を振ります。つまり、実行不可能なポリシー変更、 あるいはクラスタの不調和状態につながりうるポリシー変更は、 (明示的に上書きされない限り)拒否されます。
    c) 次にDCは、ポリシーエンジンによって以下を計算します:
    • c1) 新しいCIB c2) 遷移グラフ(現在のクラスタ状態から、CIBが示すクラスタ状態にできる限り
      • 近づけるために必要な操作を依存関係順に示したグラフ)
    d) 対象の状態への移行を進めます:
    • d1) 新しいCIBを全てのクライアントに複製します。 d2)遷移グラフの各手順を依存関係順に実行します(場合によっては並列処理します)

    e) 任意のイベントまたは障害が発生した場合は、例外を処理します。

    • e1) アルゴリズムが適切に中断されます。保留中の操作を終了することは 許可されますが、新しいコマンドがクライアントに発行されます(特に第d2段階において)。 e2)アルゴリズムが再び最初から実行されます(ここで、特にDCが再選択されない場合、依存関係ツリーの一部を再計算したり、また、特に完全なCIPを毎回配信しないだけでも 、最適化の余地はあります。ただし、これによって、実装が複雑化するため、第1段階では必要ありません)。

機能分析

  • 以下の基準を満たしています:
  • 分散決定はできるだけ行わないので、ポリシーエンジンに複数のノードを 取り扱う能力を持たせるのは簡単です。1つのノードだけが移行を進め、参加する ノードを調整します。ローカルノードは、自分の状態さえ認識していればいいのです。 コーディネータに障害が発生した場合、必要な状態はDCによって簡単に復元されます。
  • 障害が起こったノードから発生す事柄、あるいは新しいポリシールールの追加要求が イベントとなる場合があります(つまり、新しいリソース、割り当てポリシーに対する変更など)。 これにより、実行時の管理要求の取り扱い要件が満たされます。
  • 新しい種類のポリシーやリソースタイプなどのサポートは、ポリシーエンジンによって 追加することができます。
  • このモジュール設計により、1つのコンポーネントが複雑になることはありません。

アルゴリズムの安定性

  • 長期間にわたって新しいイベントが発生しない場合、このアルゴリズムは最終的に収束します。
    • /!\ TODO: 安定性に影響を与える要素についての説明を追加するか、 あるいはこのセクションを完全に削除する

コンポーネント

  • このアプローチによって、作業は、各コンポーネントにきれいに分類されます:

  • クラスタインフラストラクチャ
    • heartbeat
    • コンセンサス・クラスタ・メンバーシップ
    • メッセージング
  • クラスタ・リソース・マネージャ
    • ポリシーエンジン
    • クラスタ情報ベース
    • トランジショナー
  • ローカル・リソース・マネージャ
    • エグゼキューショナー
    • リソースエージェント

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

注:このセクションは、クラスタ全体のリソース管理の観点からLRMに対する要件を 記載したものです。詳細については、lclaudioによるドキュメントをご参照ください。

  • /!\ TODO: 提供され次第、lclaudioのドキュメントへの参照を追加する

このコンポーネントは、ノードが現在保有しているリソース、およびそのステータス (実行中、実行中/障害発生、停止中、停止済み、停止済み/障害発生など)を識別し、 この情報をCRMに通知することができます。このコンポーネントは、要求に応じて、 リソースを起動/再起動/停止します。また、サポートするリソースタイプをCRMに通知します。

このコンポーネントは、ローカルノードに適用および限定される任意の復旧操作を開始し、 その他全てのイベントをCRMにエスカレーションします。

このサービスは、クラスタ内のノードによって実行されます。 サービスの実行時に障害が発生したノードは、排除および分離されます。

このノードは、リソースの開始時にCIBにアクセスしてリソースパラメータを取得します。

注:監視操作を成功させるには、リソースを起動したときと同じインスタンスパラメータを 用いて実行しなければなりません。また、CIBは実行時に変化してしまう可能性があるため、 データのコピーを保存しておく必要があります。

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

CRMは、クラスタにおけるローカル以外の全ての対話を調整します。CRMは、以下のコンポーネントと対話します:

  • メンバーシップレイヤー
  • ローカル・リソース・マネージャ
  • ローカル以外のCRM
  • 管理コマンド
  • フェンシング機能

任意のパーティション上で同時に「指定コーディネータ」を実行できるノードは、 1つだけです。その他全てのノードは、インプットをこのノードへ転送し、その決定を ローカルのLRMへ中継します。

コーディネータは「首席」であり、理論的には、あらゆるCRMがこの方法で動作することができますが、 アービトレーションアルゴリズムが指定ノードを区別します。

指定CRMの障害への対処

  • ここでは、よくある障害を2つ紹介します。CRMを実行しているノード全体に 障害が発生した場合は、基本的なメンバーシップアルゴリズムがこの障害に対処します。 CRMのロジックに障害が発生した場合は、内部の整合性チェックによって、 これが検出され、apphbdへのローカルハートビートが直ちに停止し、 「自己終了」してフェイルファスト機構を提供します。 ただし、今のところ、CRMに障害は発生しないと見込んでいます。 内部障害を内部で処理することは困難ですが、CRMの「相互監視」を行い、 必要に応じてフェンシングを行えば、後から改善することができます。 ただし、この方法には多くの問題点があり、本来は適切とは言えません。

DCの選択アルゴリズム

  • 選択アルゴリズムでは、特定のパーティション内でノードにグローバルな順序が 存在することを利用し、単純に最初のノードを選択します。このノードは、自らが 「区別」され、制御されていることを認識しています。 アルゴリズムにおける最初の動作は、全てのノードからステータスを収集することです。 これによって、任意のノードに新たに選択されたリーダーについての情報が伝えらるのです。 新たなメンバーシップが成立するまで任意のノードがDCを務めていた場合 (クラスタパーティショニングが回復した場合)には、このノードは操作を中止し、 順次制御を引き継ぎます。

整合性監査

  • DCは、さまざまな整合性チェックを実行することができます。:
    • リソースの排他的割り当て
    • 全てのノードには、ノード上で実行されるリソースに必要なリソースエージェントがあります。
    • ポリシーエンジンによるターゲット状態の計算が妨げられる場合は、 管理要求(ルールの追加)が拒否される場合があります。
    あらゆる監査は任意で実装します。

CRMとLRM間の通信

  • システム内の全てのリソースは、「UUID」によってCIB内で明確に識別されます。このUUIDは、CRMとLRM間で使用されるキーです。
    (これにより、「リソース名/タイプ」の組み合わせをキーとして使用していた フェイルセーフの問題などを回避することができます。ただし、キーが競合するため、 例えば、2つのファイルシステム - プロダクションシステムとテストシステム - を/usr/sapに マウントしたりすることは極めて困難です。しかしながら、リソースが同じノード上で 起動されない限り、全く問題のない組み合わせです。適切な否定的依存関係によって 回避することもできます。「リソース優先度」と組み合わせると、優先度の高い プロダクションシステムが優先度の低いテストシステムを排除し、操作を継続します。)

    • /!\ TODO: 全ての詳細を把握しなくてもいいように、Heartbeat IPCレイヤーと ラッパーライブラリに基づき、プロトコルとチャンネルを決定する必要がある。AI lclaudio

遷移グラフの実行

  • 算出された依存関係グラフの実行も、DCが行うべき作業です。このグラフは、 依存関係順に検討および評価されます。グラフの全てのノードが1つの操作に 相当し、それらの間のリンクが依存関係になります。全ての依存関係が 満たされたノードだけが実行されます。ただし、CRMには、これらを並列処理 することが許可されます。作業を評価することができず、最終的に失敗したと 考えざるを得ない場合には、これはハード障害として取り扱われます。 そのような場合、現在保留中の作業は完了するまで実行され、CIBに制約が追加され (「ノードN1上でリソースXを開始することができません」など)、グラフの実行が 中止されます。復旧した場合は、再び上位へエスカレーションします (復旧アルゴリズムの再実行をトリガします)。
    • /!\ さらに検討の必要あり。特に、障害パスは、ここに記載したロジックを 単純化し、グラフでは通常のノードとして取り扱われる可能性がある。 復旧アルゴリズムを再実行しても効果がない作業(上位のノードのために 障害が発生したリソース階層のマーキングなど)については、ポリシーエンジンが 必要な代替操作をあらかじめ予測しておく場合がある。v1.0で実装しなかった点を 今後拡張する可能性がある。

      /!\ TODO:概説したような純粋な依存関係のグラフでは、「OR」条件を 表現することが難しく、「AND」条件しか使用できない。ノードが複数の機構によって 分離される場合、およびフォールバックとして各機構を順番に試さなければならない場合は、 「OR」条件が便利である。この作業は、順番に試す操作のリストをグラフ内のノードに 与えることで実装できる。

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

CIBも、クラスタ内の全てのノード上で実行されます。基本的に、 CIBは、DCによって全ての更新に通し番号が振られ、各ノード自身が 自らの最新ステータスを認識していることを利用し、弱いトランザクション セマンティクスを備えた分散データベースを提供します。

CIBの内容

  • CIBは、「構成」データと「実行時」データの2つの主要部分に分かれます。 a) データベースの構成部分は、管理者が設定します。特定ノード上に存在するこの構成には、 バーション管理されます。タイムスタンプと世代数の組み合わせを使用するのがいいでしょう。 このように、パーティション内での最新バージョンは、常に明確に識別および選択されます。
  • 構成されたリソース
    • リソース識別子
    • リソース・インスタンス・パラメータ
  • 特別なノード属性
  • 管理ポリシー
    • リソース配置の制約
    • リソースの依存関係
    b) 以下を含むランタイム情報:
  • 現在パーティションに参加しているノードに関する情報
    • 各ノード上に存在するリソースエージェント
    • ノード上でアクティブなリソースおよびそのステータス
    • ノード自体のオプションステータス
  • フェンシングデータ
    • 結果:タイムスタンプ済みのフェンシング要求結果
    • メタデータ:各ノードは、利用可能なフェンシングデバイスのリストを提供する

      /!\ TODO: これは「静的」な構成データ部分か?

  • ダイナミック管理ポリシーおよび制約:
    • 障害などに応じて、リソースをノード上に配置することを拒否する一時的な制約
    • 管理者によるリソース移行要求(この要求を無視しないと安定した状態が得られない場合、 あるいは「ノードが再起動されるまで」のようにライフタイムが限られている場合には、 この要求はポリシーエンジンから無視されることがあります)
    ランタイムデータは、全てのノードが有効なデータを保有していることを利用し、 パーティション内で入手可能な全てのデータをマージして構成されます。

最新CIBの生成プロセス

  • 必要に応じて、DCはCIB情報を各ノードから取得し、このデータから最新のCIBを 計算して、結果を全ノードに配信します。CIBを結合するアルゴリズムは極めて単純です:
  • 全ノードから最新の構成を選択します。この操作は、管理者が互換性のない 変更を別々のクラスタパーティションに行わないことを前提としています。 管理者がこのような変更を行った場合、一部の構成変更が失われる(ほかの変更によって上書きされる) 可能性がありますが、とは言え、これは典型的なPEBKACです。より複雑なマージアルゴリズムは、 後からでも考案できます。簡単な方法として、明確に検出されたこの問題をはっきりと訴え、 強制されない限り、低下したクラスタでの構成変更を拒否します。 クラスタ内の任意のノードが構成のコピーを保有している場合、 そのクラスタは処理を続行することができます。これが当てはまらないケースは まれであり、障害が複数発生する場合だけです。このシナリオの最悪のケースは、 構成変更が元の状態に戻ってしまうことです。
  • ランタイムデータをマージします。
    • パーティション内に存在するノードは、現在のステータスや 保有リソースなど、自身に関するデータを必ず保有しているものと 想定されます。このノードは、他のノードから送られてくる自身に 関するあらゆるデータを上書きします。 (噂に対する「事実の規範的能力」)
    • パーティション内に存在しないノードについては、ほかのノードで 提供される部分的な情報から最新ステータスが特定されます。つまり、 ノードが問題なく終了されたか、すでに問題なく分離されているか、 あるいはフェンシングの試行中に障害が発生したかを判断することができます。
  • 必要に応じて、タイムスタンプと生成カウンタを更新します。
  • ローカルでコミットし、配信します。

CIBへの更新が処理される仕組み

  • 構成への更新は、DCによって通し番号が振られます。更新は検証され、 自身のCIBにコミットされ、パーティション内の全てのノードに増分の 更新として配信されます。CIBのランタイム部分に関する更新は、 単純に全てのノードに配信されます。DCもこの更新を受け取り、 その他全てのノードは、(新しい)DCが新しいCIBを計算する場合に備え、 後から参照できるように更新を保存します。

ポリシーエンジン

提供される機能

  • 最初のうちは、(恐らく最初の2タイプのうち)簡単に実装できる単純な 依存関係しかサポートされていないかもしれませんが、このモデルは簡単に 拡張することができます。

必要な制約

  • resXの後にresXと同じノード上で起動する
  • {A, B, C}のセットのノードで起動する

今後の拡張

  • resXの後に起動するが、特定のノードに限定せず、グローバルな順序を割り当てる
  • resXと同じノード上では実行されない(一般に、否定制約と呼ばれる)
  • FOO属性を持つノード上にしか配置されない(FC-ALラックへの接続、XX MB以上のメモリなど)

アルゴリズムの実装について

  • あるクラスタに関して、ルールセットと現在のクラスタ状態(基本的にCIBに含まれる 全ての情報が利用可能)からターゲット状態/遷移グラフを得るためのプロセスは、 「制約ソルバー」によって実装されます。
  • 構成に含まれる依存関係グラフを分析します。
  • 各サブツリーに関してふさわしいノードを計算します (依存関係サブツリー内のリソースに関して構成されたノードの交差)
  • それらのノードに優先順やスティッキー性などに従って順序を付け、ターゲットノードを選択します。
    • ターゲット以外のノードは、パーティションに入れるか、あるいは分離しなければいけません。

...

  • /!\ TODO: 未完成

    /!\ TODO: その他の実装:GNU Prologから有限ドメインソルバーを借用したり、 http://www.cs.washington.edu/research/constraints/cassowary/ から制約ソルバーを 借用したりすることにより、ポリシーを直感的な制約として表現する。 これは良い考えだと思う。評価が必要。

設計の検討

  • 以下では、このアプローチに関する一般的な質問にお答えします:

リソースグループを取り扱うべきですか、それともリソースと依存関係「だけ」を取り扱うべきですか?

  • 一見したところでは、フェイルセーフのリソースグループは、幸いにも分かりやすくなっています。 このようなグループはアトミックユニットとして取り扱うことができ、リソース割り当てポリシーが さらにシンプルになり、CRMは単にリソースグループを割り当て/再割り当てすればいいだけで、 リソースを識別する必要はありません。このような方法でリソースをグループ化することは自然であり、 関連する全てのリソースをリソースグループにまとめれば完了です。
  • しかし、この方法には限界もあります。リソースと提供サービスとの間の論理マッピングが 停止された場合、リソースグループは、扱いにくくなります。例えば、1つのノード上で 実行されるべき要素は、1つのリソースグループにまとめてしまうのが自然な方法ですが、 後でこれが不要になった場合、リソースグループを分割することは困難です。 (マージと同様に)リソースグループを生み出す依存関係も、一般に要求されます。
  • つまり、リソースグループは、別のリソースグループと同じノード上で実行するべきでは ありません。また、たとえ1つか2つのリソースしかないのに、全てのリソースに関して リソースグループを持たなければならない場合も、依存関係は煩雑になります。 その場合、グループにまとめても、メリットはほとんどありません。
  • 決定によっては、単独のリソースとリソースグループに境界が生じますが、この場合はCRMが 再び両方を識別する必要があります。例えば、リソースグループの割り当てポリシーは、 各リソース自体が割り当てられる方法と一致しなければなりません。
  • 要するに、リソースグループは、大きなクラスタを扱いやすくするには不十分であり、 柔軟性にも欠けます。
  • 今のところ、リソースと、リソース間の依存関係、そして外的な制約だけを取り扱う方が 自然なように思われます。結局、どちらも見方が違うだけであり、どちらの方が難しい ということはありませんので、問題なく実装できる方を選択してください。
  • 注意すべき重要なポイントは、この文書は構成の内部について説明したもので あるという点です。適切な構成ウィザードを使用すれば、(機能は制限されますが、簡単に) 「リソースグループ」スタイルのフロントエンドをユーザーに提供してくれます。

なぜ遷移グラフを使用するのですか?

  • グラフに含まれる依存関係情報を使用すると、復旧をスピードアップするために 操作を並列処理することができます(全ての要件を満たす操作は、並列に処理することができます)。
  • グラフは(DCで集中化されているため)「グローバル」であり、「防壁」となる可能性があります。 つまり、リソースが別のノードで起動されている場合に限って、リソースが起動されます。

1つのノード上でのリソース操作を命令するのは、どのコンポーネントですか?

  • LRMは、理論上、非ローカルの操作(リソース操作、フェンシングなど)に 依存する可能性があるため、ローカルノードについて、リソース操作(起動、停止など)を 命令できるだけの十分な情報を持っていません。
  • 情報を持っているのは、DCによって構成された遷移グラフだけです。
  • ここで考えられる最適化は、DCが、特定ノードに対するシングルブロックとして、 外的なイベントに依存しない全ての操作をあるノードに転送し、そのノードが しかるべく処理を進めることです。はじめは、操作を1つずつ発行するだけで十分です。

エグゼキューショナー

統合

  • エグゼキューショナーは、要求に応じてノードのフェンシングを行います。 エグゼキューショナーは、各ノード上のローカルコンポーネントであり、 どのフェンシングデバイスが利用できるかを識別します。
  • この情報は、CIBに提供されます。
  • エグゼキューショナーは、(DCから中継された)CRMの要求に基づいて フェンシングを試み、ステータスを返します。当然ながらCRMは、成功するまで、 当該ノードを複数のノードから分離しようとします。
  • 詳細については、「executioner.txt」を参照してください。

フェンシングアルゴリズム

  • 復旧プロセスの開始時に、CRMは、各ノードから通信できるデバイスのリストを検証します。 これは、デバイスから現在のCIBを問い合わせる際に実行されます。
  • 次にCRMは、各デバイスを通じて、分離可能なノードのリストを取得します。このリストを 過去にすでに取得している場合は、キャッシュから再利用します (新たなノードがクラスタに追加された場合などに限ってリロードされます)。
  • 分離する対象のノードに関し、依存関係を遷移グラフに追加する必要があります。 これらの操作により、特定デバイスへの同時アクセスが防止され、 可能な場合は別のデバイス上でフェンシング要求が再試行されます。
  • 検討事項:最終手段のフォールバックフェンシングとして「人的操作」を 追加することにより、対災害性のある設定が実現します。1つのサイトで全面的な 障害が発生した場合、管理者がスイッチを切り替えると、遷移グラフが処理を実行します。 これにより、要件リストのこの部分にうまく対応することができます。

フェンシングの解除

  • 進行中のフェンシングまたはSTONITH操作の中止はサポートしていません。

フェンシングに成功した場合

  • あるノードが分離されました。このノードは、どのようにして再びクラスタに参加するのでしょうか。
  • 例えば、ノードn1は、不適切に終了されたことを起動時に検知した場合、 自身がSTONITHされたものと見なします(特に稼働時間が極めて短い場合)。
  • このノードは、いつフラグを解消し、自ら復旧/起動操作を開始するのでしょうか。
  • これに対する回答は、6.2の「検討事項」に関連しているように思われます。 いずれにしても、リソースグループの復旧操作が開始される時点です。 追加オプションとして、「リソースグループのノードの50%以上が自分の パーティションに含まれる場合、処理を進めます。同等の場合は、「不適切な」フラグが いずれかのノードに立てられない限り、復旧操作の処理を進めない」ということが考えられます
  • (これにより、不適切なフラグがCIBのランタイム部分に移動されます)
  • フラグは、大部分のリソースとの通信が回復した後に解消されます。

フェンシング要求保留中のノードの再参加

  • 回答:実行中のフェンシング要求を中止することはできません。 残念ながらこのケースでは、フェンシング要求のために、そのノードはまもなく 削除される可能性があります。リソースのピンポン状態を防止するため、このノードがすでに 「ダウン」していたものと見なす対応を取ります。

    /!\ TODO: パーティションのために、n1がn2を分離しようとした(あるいはその逆)が STONITHデバイスを通じて障害が発生し、管理者に通知した。パーティションは解消される。 システムは管理者のリクエストを中止するべきではないか?管理者のリクエストに関して 特例を設定するべきか?それとも単に管理者がこれを検出するべきか?

過去にフェンシングに失敗したノードの再参加

  • 2つのオプションが考えられます。ノードがクラスタに再参加した場合、 そのノードに関して「フェンシング失敗」のフラグは解消され、クラスタは 通常どおり処理を続行します(これが適切だと思われます)。
  • もう1つのオプションは、ノードに自己終了を要求することです。この場合も、 クラスタパーティションが解消されると、この操作が困難になり、両者が自己終了 してしまいます。これは賢明な方法ではありません。
  • ローカルの異常停止(スケジューラのバグ、電源管理の異常)が失敗の原因である 場合に関しては、ここでは説明しません。そのようなノードの状態をローカルで監視する 場合は、上記の失敗が原因ではないかどうか、責任を持って確認し、適切に対処してください。

定数との対話

  • /!\ TODO: 全くの未完成!

要約:CRMは定数を必要としませんが、「定数」を別のリソースとして簡単に計算することができます。

実は、この設計には「定数」が不要です。このことは、フェンシングを含む全ての依存関係を 満たすリソースしか取り扱わないというポリシーエンジン/CRMに暗黙的に含まれています。

実際のところ、これはより粒度の細かい定数です。これにより、 クラスタは、以下のようなシナリオで処理を続行することができます:

  • {a,b,c,d} がクラスタを形成する。{a,b}がリソース(R1)を共有し、{c,d}が リソース(R2)を共有する。クラスタが{a,b}と{c,d}に分割される場合は、 フェンシングを実行する必要がなく、クラスタ操作が通常どおり続行される。

当然ながら、{a,b,c,d}を生成するグローバルなリソースが追加された場合は、 これが実際に「グローバル定数」と解釈されます。

ここから判断すると、グローバル定数が実際に要求される場合、この設計における 定数は、グローバル定数をグローバルな(「全てのノードで構成された」)リソースに マッピングすることによって、また、このリソースを回復できた場合(あるいは回復に失敗した場合)に 定数が存在することをパーティションに通知することによって、最もうまく表現されます。

ただし、CRMでは「サブ定数」も許可されます。つまり、定数を要求するアプリケーションが 動作する例を考えてみると、アプリケーションは、通常、関連リソースに適したノードの 定数にしか反応しません。従って、報告するクライアントによって、定数が異なる 可能性があります。

クォーラムに関して

  • /!\ TODO: 必ず仕上げること ;-)

ほかのプロジェクトとの統合

Heartbeatとの統合

  • /!\ TODO: 補足が必要 このコンポーネントは、現在、Heartbeatに含まれる「リソースマネージャ」を 置き換えることになる。対処・留意すべき問題は以下のとおりです。

  • 起動順序:Heartbeatは、CRMの起動がローカルで問題なく完了された場合に限って、クラスタに参加する。
  • CRMは、Heartbeatのライブラリ(IPC、HBcomm、STONITH、PILSなど)を幅広く使用する。
  • ..

CCMとの統合

  • /!\ TODO: 必要に応じて補足する CRMはCCMのクライアントである。CCMはパーティション内のノードを提供し、CRMはこのデータ上でのみ動作する。 ノードのパーティションへの参加を許可する前に、CCMがポリシーを実施する (時刻が大きくずれていない、CRM/LRMなどが動作している、その他気付いたことなど)のが いいでしょう。

グループサービスとの統合

  • グループサービスの機能(特にグループメッセージング)が利用できる場合、 必然的に、厳密なセマンティクスを考慮に入れなければなりません。 このコンポーネントによって可能な簡略化として、CRMが、ノードに加えて、 メッセージング基本命令を構築したり、これらの基本命令をフィルタリングしたりせずに、 クラスタ内で分散プロセスグループを形成できることが、まず挙げられます。

Heartbeat以外のクラスタとの統合

  • 理論上、このソフトウェアは、いかなる「適合」環境でも動作します。 例えばCompaq CIや、Service-Availability Forum AISへ簡単に移植できるはずです。 これにより、それぞれの機能リストが補完されるとともに、そのような相互運用が 実際に可能であることが実証され、OCFに大きな優位性がもたらされます。

    /!\ TODO: コードの設計時には、この点に考慮する。 下位レベルとの対話をカプセル化すること。

クラスタ対応アプリケーションとの統合

  • クラスタ対応ボリュームマネージャ、ファイルシステム、分散アプリケーション (データベース)などのソフトウェアは、リソース・エージェントベースの ソフトウェアと同様に「復旧」ツリーに統合する必要があります。 必要なトリガを遷移グラフに適切な順に挿入すればいいため、この仕組みは単純ですが、 これらのクライアントは、外部のフレームワークであらかじめ考慮されているため、 自身でフェンシングを提供する必要はありません。

OCFとの関連

  • 該当する全てのOCF仕様が実装されます。OCFにまだ規定されていない分野は、 プロトタイプとして実装され、OCFに関する議論の基礎として機能することが期待されます。

監視

ヘルスモニタリングとの統合

  • ヘルスモニタリングにより、クラスタソフトウェアが「問題のある」ノードで 起動することを防止します(「この60分間に12回も再起動しました。 クラスタソフトウェアをオンラインにすることは、あまり賢明とは言えませんね」)。 ローカル・リソース・マネージャによって処理するべきでしょうか?ヘルスモニタリングに よって、DCに以下のようなイベントが通知されます:
  • クラッシュしそうなので、可能な間に全てのデータを移行すること
  • 過負荷が発生したので、可能であれば一部のリソースを移行すること、など

CRMの監視

  • 監視ソフトウェアは、CIBに問い合わせて、全てのデータへのアクセスを取得することができます。

    /!\ トラップ/イベントを別のコンポーネントの内部からトリガするべきか、 それともクライアントにCIBの特定部分に「登録」して変更が生じた場合に 通知を受けられるようにするのがいいか?これは、SNMP/CIMトラップに役立つと 思われる(後者は、フェイルセーフのcdbdと多少似ている)


注意:ここは未調査の分野であり、このライン以下の記述については、
考えが整理されておらず、まだ全体的な構成に組み込まれていない。

X. ...

  • 質問:リソースを別のノードに移すことが基本的な操作でないのはなぜですか?
    • 回答:このような操作には2つ以上のノードが関係し、指定されたCRMによって調整する必要があるためです。
  • 質問:あるサイトが物理的に離れており、もう一方を分離することが不可能な場合、 対災害性のある設定はどのように取り扱われますか?
    • 回答:「Hangman」の「注」をご参照ください。