Pacemakerリソースエージェントのエラー処理

1. はじめに Pacemakerは、このメソッドの実行中にエラーが発生した場合、各リソースエージェントが提供するオペレーション(開始、停止など)を呼び出すことでリソース制御を実現します。実行された操作とエラーの種類に応じて、異なるエラー処理を実行します。

2. エラーの種類

Pacemaker は、エラーをソフト、ハード、致命的な 3 つのカテゴリに分類し、後者の 2 つは環境または構成の問題に属し、手動介入なしでは自動的に修復できません。サービスプロセスのクラッシュ、ネットワーク障害などの一般的な障害では、戻り値として OCF_ERR_GENERIC が使用されます。OCF_ERR_GENERIC はソフトタイプに属します。

http://clusterlabs.org/doc/en-US/Pacemaker/1.1-plugin/html-single/Pacemaker_Explained/index.html#_how_are_ocf_return_codes_interpreted

B.3.OCF リターンコードはどのように解釈されますか?

クラスターが最初に行うことは、リターンコードを予期された結果と照合することです。結果が予期された値と一致しない場合、操作は失敗したとみなされ、障害回復には 3 つのタイプがあります。 .3.クラスターによって実行されるリカバリの種類

タイプ	説明	クラスターによって実行されるアクション
ソフト	一時的なエラーが発生しました	リソースを再起動するか、新しい場所に移動します
ハード	A非一時的現在のノードに固有のエラーが発生しました	リソースを別の場所に移動し、現在のノードで再試行されないようにします
致命的	すべてのクラスターノードに共通する非一時的なエラー(例:不正な構成が指定されました)	リソースを停止し、どのクラスターノードでも開始されないようにします

アクションが失敗したと見なされると仮定して、次の表は、さまざまな OCF リターンコードと、それを受信したときにクラスターが開始するリカバリの種類の概要を示しています。

B.4.OCF リターンコード

表 B.4。 OCF リターンコードとそのリカバリタイプ

RC	OCF エイリアス	説明	RT
0	OCF_SUCCESS	成功。コマンドは正常に完了しました。これは、すべての開始、停止、プロモート、およびデモートのコマンドで予期される結果です。	soft
1	OCF_ERR_GENERIC	一般的な「問題が発生しました」エラーコード。	柔らかい
2	OCF_ERR_ARGS	リソースの構成はこのマシンでは有効ではありません。例えば。ノード上に見つからない場所/ツールを指します。	難しい
3	OCF_ERR_UNIMPLEMENTED	要求されたアクションは実装されていません。	hard
4	OCF_ERR_PERM	リソースエージェントには、タスクを完了するための十分な権限がありません。	難しい
5	OCF_ERR_INSTALLED	リソースに必要なツールがこのマシンにインストールされていません。	hard
6	OCF_ERR_CONFIGURED	リソースの構成が無効です。例えば。必要なパラメータがありません。	致命的
7	OCF_NOT_RUNNING	リソースは安全に停止されました。クラスターは、いかなるアクションに対してもこれを返すリソースを停止しようとしません。	該当なし
8	OCF_RUNNING_MASTER	リソースはマスターモードで実行されています。	soft
9	OCF_FAILED_MASTER	リソースはマスターモードですが、失敗しました。リソースは降格され、停止され、その後再び開始 (場合によっては昇格) されます。	ソフト
その他	NA	カスタムエラーコード。	柔らかい

直感に反しますが、0 (別名 OCF_SUCCESS) を返すアクションでも失敗したと見なすことができます。

3. エラー処理

各リソース操作には、エラーの処理方法を制御するための on-fail 属性があります。

http://clusterlabs.org/doc/en-US/Pacemaker/1.1-plugin/html-single/Pacemaker_Explained/index.html#_monitoring_resources_for_failure

表5.3. オペレーションのプロパティ

フィールド	説明
id	アクションの名前。ユニークでなければなりません。
name	実行するアクション。一般的な値: 監視、開始、停止
間隔	操作を実行する頻度 (秒単位)。デフォルト値: 0 (決してしないことを意味します)。
timeout	アクションが失敗したと宣言するまでの待機時間。
on-fail	このアクションが失敗した場合に実行するアクション。許可される値:* ignore - リソースが失敗しなかったふりをします* block - リソースに対してそれ以上の操作を実行しません* stop - リソースを停止し、他の場所で開始しません* restart - リソースを停止しますリソースを再起動して (おそらく別のノードで)* fence - リソースが失敗したノードを STONITH* standby - リソースが失敗したノードからすべてのリソースを移動します。停止操作のデフォルトは次のとおりです。 STONITH が有効な場合はフェンスし、それ以外の場合はブロックします。他のすべての操作はデフォルトで停止します。
enabled	false の場合、操作は存在しないものとして扱われます。許可される値: true、false

しかし、実際にテスト検証を行ったところ、on-failをどのように設定しても効果は変わらず、常にデフォルトの動作となることが分かりました。

リソースエージェントの各操作が OCF_ERR_GENERIC を返した場合のリソースマネージャーの処理は次のとおりです。 count= 1000000

このノードで呼び出し停止他のノードでリソースを開始stopfail-count=1000000を設定

	restart
	リソースのそれ以上の操作を防止すると、リソースは管理外になりますFAILED ステータスは以下の通りです dummy(ocf::heartbeat:Dummy2):Started srdsdevapp69 (unmanaged) FAILED	block
monitor	Setfail-count+=1 このノードで stop、start、monitor を順番に呼び出します。それでもモニターが失敗する場合は、失敗回数が移行しきい値に達するまで停止、開始、モニターを繰り返し、リソースを停止状態に保ちます。	restart
promote	Setfail-count+=1 このノードでdemote、stop、startを順番に呼び出します。他のノードでプロモートを呼び出して、マスターへの他のノードのリソースを増やします	restart
demote	fail-count+=1を設定しますこのノードでstop、start、demoteを順番に呼び出します。それでも降格が失敗する場合は、失敗回数が移行しきい値に達するまで停止、開始、降格を繰り返し、リソースを停止状態に保ちます。	再起動
通知	無視	無視