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-13 11:48:09

LRMの概要

ローカル・リソース・マネージャは、新しいHeartbeat設計の一要素です。 リソース・エージェント・スクリプトを使用して作業を実行し、 リソースに対して操作を実行する責任を負います。

ローカル・リソース・マネージャは、単独でデータ処理能力を持っているわけではありません。 つまり、独自に操作を実行することはほとんどなく、クライアントの指示を厳密に実行します。 これは、ポリシーフリーのサーバーです。

ローカル・リソース・マネージャが実行する操作の最終目標は、 リソースインスタンスに対して操作を行い、 リソースタイプに関する情報を提供することです。

それ自身で操作を開始することはありませんが、リソースインスタンスの監視などの操作に 障害が発生するとイベントを生成し、現在のクライアントに通知します。

クライアントから実行を要求できる操作

ご利用方法については、ローカル・リソース・マネージャの インターフェースをご参照ください。

インプリメンテーションの詳細

概要図

以下は、このサブシステムの最新のアーキテクチャ図です:

アランR(AlanR)さんは、上の図は実行されるジョブを説明できていることを認めつつも、 細部については異論を唱えています。これについては後ほどご説明します。

リソースインスタンスの子プロセスの処理

リソース・エージェント・スクリプトでは、作業の実行にかなりの時間がかかるため、 今すぐ開始する操作を許可するようにローカル・リソース・マネージャのインターフェースを 設計し、作業に成功したことを後から非同期的に報告させる必要があります。

LRMを設定して、多くの子プロセスを分岐して管理できるようにします。 リソース管理操作に対する複数の要求を一度に受け取る可能性があります。 指定されたリソースインスタンスのために、操作を直列化します。

クライアントとLRMとの対話

ローカル・リソース・マネージャは独立したプロセスなので、 クライアントはリモート・プロシージャ・コールのようなインターフェースを 通じて通信する必要があります。複雑なオブジェクトにポインタを渡す作業には 手間がかかるので、なるべく避けてください。

特に、ローカル・リソース・マネージャはネットワーク上で対話しません。 リモートリクエストはクラスタリソースマネージャ経由で ローカル・リソース・マネージャに リレーされます。ローカル・リソース・マネージャは、IPCコード経由で受信する ローカルリクエストだけを認識して処理します。

LRMでのイベント処理

LRMについては、入力メッセージを受信するためにgmainloopイベント処理コードを使用し、 それらのコードをFSM経由で配信すべきであるとの提案があります。

その場合、クライアントは、監視する操作に障害が発生した場合に通知を受け取るように登録でき、 詳細なIPCメッセージを受け取ることができます。

リソースインスタンスの識別

リソースインスタンスは、 一意の識別子であるUUIDにより、 ローカル・リソース・マネージャに一意に識別されます。 クライアントが リソースインスタンスで実行する操作を要求するか、 または状態の変化に関するイベントがクライアントに送信された場合は、 UUIDを使用してリソースを識別しなければなりません。

UUIDは、リソースインスタンスが最初に開始またはインスタンス化されたときに、 クライアント経由で割り当てられます。システムログでリソースインスタンスを 識別するため、各リソースインスタンスには、UUIDに加え、 HumanNameを提供する必要があります。リソースインスタンスに 操作を実行する場合には、HumanNameリソースインスタンスに関する ログメッセージに含めてください。

LRM自身の開始/再起動処理

LRMが初めて起動した時点では、構成済みのリソースは含まれていません。 アクティブ、エラー、非アクティブのリソースは、いずれも存在しません。 必要な情報がなく、実行できないため、アクティブなリソースインスタンスの 自動検出も実行しません。

最終的に透過的アップグレードの機能を追加する場合、 システムは、実行中のリソースに関する情報を不揮発性の記憶領域にキャッシュし、リソースを 停止することなく終了し、再起動時にはリソース情報を復元する必要があります。 CRMとの関係性から考えると、監視を自動的に再開することは、適切なやり方ではありません。 透過的アップグレード機能を提供することには、多くの疑問が残っています。

CRMからLRMへの要求

  • 操作:リソースに操作を実行する。
    • - これらの操作は、95%の時間を以下の実行に費やす。
      • 起動
      • 停止
      • 状態
      • 再起動
      • リソースの監視を開始
      • リソースの監視を停止
  • 障害: 監視操作に障害が発生した場合は、ユーザーに通知する。これは、操作からの標準的な非同期の戻りコードとなる。

  • 最後の操作:特定のリソースについて要求された最後の操作、および戻りコードを通知する。

指定コーディネータは、選択された後で、最後の操作と状態操作の結果を組み合わせ、 クラスタ内の全てのリソースの現状を計算します。特に最後の指定コーディネータに 致命的なエラーが発生した場合、選択プロセスの最中に状況が変化することがあるので、 この作業を行ってください。

参照: ローカル・リソース・マネージャの未解決の問題, ローカル・リソース・マネージャの解決済みの問題