第13章 クラスターイベントのスクリプトのトリガー
Pacemaker クラスターはイベント駆動型のシステムで、イベントはリソースやノードの障害、設定の変更、またはリソースの開始や停止になります。Pacemaker クラスターアラートを設定すると、クラスターイベントの発生時に外部で一部の処理を行うことができます。クラスターアラートを設定するには、以下の 2 つの方法の 1 つを使用します。
- Red Hat Enterprise Linux 7.3 より、アラートエージェントを使用して Pacemaker アラートを設定できるようになりました。アラートエージェントは、リソース設定と操作を処理するためにクラスター呼び出しのリソースエージェントと同様にクラスターが呼び出す外部プログラムです。Pacemaker アラートエージェントの説明は 「Pacemaker アラートエージェント (Red Hat Enterprise Linux 7.3 以降)」 を参照してください。
ocf:pacemaker:ClusterMonリソースはクラスターのステータスを監視し、各クラスターイベントでアラートをトリガーできます。このリソースは、crm_mon コマンドを一定間隔でバックグラウンドで実行します。ClusterMonリソースの詳細は 「モニタリングのリソースを使ったイベント通知」 を参照してください。
13.1. Pacemaker アラートエージェント (Red Hat Enterprise Linux 7.3 以降)
クラスターイベントの発生時に Pacemaker アラートエージェントを作成して外部で一部の処理を行うことができます。クラスターは、環境変数を用いてイベントの情報をエージェントに渡します。エージェントは、E メールメッセージの送信、ログのファイルへの記録、監視システムの更新など、この情報を自由に使用できます。
- Pacemaker は、デフォルトで
/usr/share/pacemaker/alertsにインストールされるアラートエージェントのサンプルを複数提供します。これらのサンプルスクリプトは、コピーしてそのまま使用したり、目的に合わせて編集するテンプレートとして使用することもできます。対応する全属性は、サンプルエージェントのソースコードを参照してください。サンプルアラートエージェントを使用するアラートの基本的な設定手順の例は、「サンプルアラートエージェントの使用」 を参照してください。 - アラートエージェントの設定および管理に関する一般的な情報は、「アラートの作成」、「アラートの表示、編集、および削除」、「アラートの受信側」、「アラートメタオプション」、および 「アラート設定コマンドの例」 を参照してください。
- Pacemaker アラートの独自のアラートエージェントを作成することができます。アラートエージェントの作成に関する詳細は、「アラートエージェントの作成」 を参照してください。
13.1.1. サンプルアラートエージェントの使用
サンプルアラートエージェントの 1 つを使用するとき、スクリプトがニーズにあっていることを確認してください。サンプルエージェントは、特定のクラスター環境用のカスタムスクリプトを作成するためのテンプレートとして提供されます。Red Hat は、Pacemaker との通信にアラートエージェントスクリプトが使用するインターフェイスをサポートしますが、カスタムエージェント自体にはサポートを提供していないことに注意してください。
サンプルアラートエージェントの 1 つ を使用するには、クラスターの各ノードにエージェントをインストールする必要があります。たとえば、以下のコマンドは、
alert_file.sh.sample スクリプトを alert_file.sh としてインストールします。
# install --mode=0755 /usr/share/pacemaker/alerts/alert_file.sh.sample /var/lib/pacemaker/alert_file.sh
スクリプトをインストールしたら、スクリプトを使用するアラートを作成できます。
以下の例では、インストールされた
alert_file.sh アラートエージェントを使用してイベントをファイルに記録するアラートを設定します。アラートエージェントは、最低限のパーミッションを持つ hacluster ユーザーとして実行します。
この例では、イベントの記録に使用するログファイル
pcmk_alert_file.log を作成します。また、アラートエージェントを作成し、その受信先としてログファイルへのパスを追加します。
#touch /var/log/pcmk_alert_file.log#chown hacluster:haclient /var/log/pcmk_alert_file.log#chmod 600 /var/log/pcmk_alert_file.log#pcs alert create id=alert_file description="Log events to a file." path=/var/lib/pacemaker/alert_file.sh#pcs alert recipient add alert_file id=my-alert_logfile value=/var/log/pcmk_alert_file.log
以下の例では、
alert_snmp.sh.sample スクリプトを alert_snmp.sh としてインストールし、インストールされた alert_snmp.sh アラートエージェントを使用してクラスターイベントを SNMP トラップとして送信するアラートを設定します。デフォルトでは、正常な監視呼び出し以外のすべてのイベントを SNMP サーバーに送信します。この例では、タイムスタンプの形式をメタオプションとして設定します。メタオプションの詳細は、「アラートメタオプション」 を参照してください。この例では、アラートの設定後にアラートの受信側が設定され、アラート設定が表示されます。
#install --mode=0755 /usr/share/pacemaker/alerts/alert_snmp.sh.sample /var/lib/pacemaker/alert_snmp.sh#pcs alert create id=snmp_alert path=/var/lib/pacemaker/alert_snmp.sh meta timestamp-format="%Y-%m-%d,%H:%M:%S.%01N"#pcs alert recipient add snmp_alert value=192.168.1.2#pcs alertAlerts: Alert: snmp_alert (path=/var/lib/pacemaker/alert_snmp.sh) Meta options: timestamp-format=%Y-%m-%d,%H:%M:%S.%01N. Recipients: Recipient: snmp_alert-recipient (value=192.168.1.2)
次の例では、
alert_smtp.sh エージェントをインストールし、インストールされたアラートエージェントを使用するアラートを設定して、クラスターイベントを電子メールメッセージとして送信します。この例では、アラートの設定後に受信側が設定され、アラート設定が表示されます。
#install --mode=0755 /usr/share/pacemaker/alerts/alert_smtp.sh.sample /var/lib/pacemaker/alert_smtp.sh#pcs alert create id=smtp_alert path=/var/lib/pacemaker/alert_smtp.sh options email_sender=donotreply@example.com#pcs alert recipient add smtp_alert value=admin@example.com#pcs alertAlerts: Alert: smtp_alert (path=/var/lib/pacemaker/alert_smtp.sh) Options: email_sender=donotreply@example.com Recipients: Recipient: smtp_alert-recipient (value=admin@example.com)
13.1.2. アラートの作成
次のコマンドは、クラスターアラートを作成します。設定するオプションは、追加の環境変数として指定するパスで、アラートエージェントスクリプトに渡されるエージェント固有の設定値です。
id の値を指定しないと、値が生成されます。アラートメタオプションの詳細は、「アラートメタオプション」 を参照してください。
pcs alert create path=path [id=alert-id] [description=description] [options [option=value]...] [meta [meta-option=value]...]
複数のアラートエージェントを設定できます。クラスターは、各イベントに対して、すべてのアラートエージェントを呼び出します。アラートエージェントはクラスターノードでのみ呼び出されます。アラートエージェントは、Pacemaker リモートノードが関係するイベントに対して呼び出されますが、このようなノードでは呼び出されません。
以下の例は、各イベントに対して
myscript.sh を呼び出す簡単なアラートを作成します。
# pcs alert create id=my_alert path=/path/to/myscript.sh
サンプルアラートエージェントの 1 つを使用するクラスターアラートの作成方法の例は、「サンプルアラートエージェントの使用」 を参照してください。
13.1.3. アラートの表示、編集、および削除
次のコマンドは、設定されたすべてのアラートと、設定されたオプションの値を表示します。
pcs alert [config|show]
以下のコマンドは、指定した alert-id 値を持つ既存のアラートを更新します。
pcs alert update alert-id [path=path] [description=description] [options [option=value]...] [meta [meta-option=value]...]
以下のコマンドは、指定の alert-id 値を持つアラートを削除します。
pcs alert remove alert-id
代わりに pcs alert delete コマンドを実行できます。これは pcs alert remove コマンドと同じです。pcs alert delete コマンドおよび pcs alert remove コマンドの両方を使用すると、複数のアラートを削除できます。
13.1.4. アラートの受信側
通常、アラートは受信側に送信されます。したがって、各アラートには、1 人以上の受信者を追加で設定できます。クラスターは、受信側ごとに別々にエージェントを呼び出します。
受信側は、IP アドレス、メールアドレス、ファイル名、特定のエージェントがサポートするものなど、アラートエージェントが認識できるものを設定します。
次のコマンドは、新しい受信側を指定のアラートに追加します。
pcs alert recipient add alert-id value=recipient-value [id=recipient-id] [description=description] [options [option=value]...] [meta [meta-option=value]...]
次のコマンドは、既存のアラート受信側を更新します。
pcs alert recipient update recipient-id [value=recipient-value] [description=description] [options [option=value]...] [meta [meta-option=value]...]
次のコマンドは、指定のアラート受信側を削除します。
pcs alert recipient remove recipient-id
代わりに pcs alert recipient delete コマンドを実行できます。これは pcs alert recipient remove コマンドと同じです。pcs alert recipient remove コマンドおよび pcs alert recipient delete コマンドの両方を使用すると、複数のアラート受信者を削除できます。
以下のコマンド例は、受信側 ID が
my-recipient-id のアラート受信側 my-alert-recipient をアラート my-alert に追加します。これにより、各イベントの my-alert 用に設定されたアラートスクリプトを呼び出すようにクラスターが設定され、受信者 some-address が環境変数として渡されます。
# pcs alert recipient add my-alert value=my-alert-recipient id=my-recipient-id options value=some-address13.1.5. アラートメタオプション
リソースエージェントと同様に、メタオプションをアラートエージェントに対して設定すると、Pacemaker の呼び出し方法を調整できます。表13.1「アラートメタオプション」 は、アラートメタオプションを示しています。メタオプションは、アラートエージェントごと、または受信側ごとに設定できます。
| メタ属性 | デフォルト | 説明 |
|---|---|---|
timestamp-format
|
%H:%M:%S.%06N
|
イベントのタイムスタンプをエージェントに送信するときにクラスターが使用する形式です。
date(1)コマンドで使用される文字列です。
|
timeout
|
30s
|
アラートエージェントがこの時間内に完了しないと終了させられます。
|
以下の例では、
myscript.sh スクリプトを呼び出すアラートを設定し、2 つの受信側をアラートに追加します。最初の受信側には、ID が my-alert-recipient1 で、2 番目の受信側の ID は my-alert-recipient2 になります。スクリプトは各イベントで 2 回呼び出され、呼び出しのタイムアウト値はそれぞれ 15 秒です。1 つの呼び出しは受信者 someuser@example.com に渡され、タイムスタンプの形式は %D %H:%M になります。もう 1 つの呼び出しは受信者 otheruser@example.com に渡され、タイムスタンプの形式は %c になります。
#pcs alert create id=my-alert path=/path/to/myscript.sh meta timeout=15s#pcs alert recipient add my-alert value=someuser@example.com id=my-alert-recipient1 meta timestamp-format="%D %H:%M"#pcs alert recipient add my-alert value=otheruser@example.com id=my-alert-recipient2 meta timestamp-format=%c
13.1.6. アラート設定コマンドの例
以下の例は、基本的なアラート設定コマンドの一部と、アラートの作成、受信側の追加、および設定されたアラートの表示に使用される形式を表しています。アラートエージェント自体はクラスター内の各ノードにインストールする必要がありますが、pcs コマンドの実行は 1 回だけで済みます。
以下のコマンドは簡単なアラートを作成し、アラートに 2 つの受信側を追加した後、設定された値を表示します。
- アラート ID の値が指定されていないため、
alertのアラート ID を作成します。 - 最初の受信者の作成コマンドは、
rec_valueの受信者を指定します。このコマンドには受信側 ID が指定されていないため、alert-recipientの値が受信側 ID として使用されます。 - 2 番目の受信者の作成コマンドは、
rec_value2の受信者を指定します。このコマンドは、宛先にmy-recipientの受信者 ID を指定します。
#pcs alert create path=/my/path#pcs alert recipient add alert value=rec_value#pcs alert recipient add alert value=rec_value2 id=my-recipient#pcs alert configAlerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value) Recipient: my-recipient (value=rec_value2)
以下のコマンドは、2 番目のアラートとそのアラートの受信側を追加します。2 番目のアラートのアラート ID は
my-alert で、受信側の値は my-other-recipient です。受信側 ID が指定されていないため、受信側 ID は my-alert-recipient となっています。
#pcs alert create id=my-alert path=/path/to/script description=alert_description options option1=value1 opt=val meta timeout=50s timestamp-format="%H%B%S"#pcs alert recipient add my-alert value=my-other-recipient#pcs alertAlerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value) Recipient: my-recipient (value=rec_value2) Alert: my-alert (path=/path/to/script) Description: alert_description Options: opt=val option1=value1 Meta options: timestamp-format=%H%B%S timeout=50s Recipients: Recipient: my-alert-recipient (value=my-other-recipient)
以下のコマンドは、my-alert、受信側
my-alert -recipient の アラート 値を変更します。
#pcs alert update my-alert options option1=newvalue1 meta timestamp-format="%H%M%S"#pcs alert recipient update my-alert-recipient options option1=new meta timeout=60s#pcs alertAlerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value) Recipient: my-recipient (value=rec_value2) Alert: my-alert (path=/path/to/script) Description: alert_description Options: opt=val option1=newvalue1 Meta options: timestamp-format=%H%M%S timeout=50s Recipients: Recipient: my-alert-recipient (value=my-other-recipient) Options: option1=new Meta options: timeout=60s
以下のコマンドは、アラートから受信側
my- alert -recipient を削除します。
#pcs alert recipient remove my-recipient#pcs alertAlerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value) Alert: my-alert (path=/path/to/script) Description: alert_description Meta options: timestamp-format="%M%B%S" timeout=50s Meta options: m=newval meta-option1=2 Recipients: Recipient: my-alert-recipient (value=my-other-recipient) Options: option1=new Meta options: timeout=60s
次のコマンドは、設定から
myalert を削除します。
#pcs alert remove my-alert#pcs alertAlerts: Alert: alert (path=/my/path) Recipients: Recipient: alert-recipient (value=rec_value)
13.1.7. アラートエージェントの作成
Pacemaker アラートには、ノードアラート、フェンスアラート、およびリソースアラートの 3 種類があります。アラートエージェントに渡された環境変数は、アラートのタイプにより異なる可能性があります。表13.2「アラートエージェントに渡される環境変数」 は、アラートエージェントに渡される環境変数を示し、環境変数が特定のアラートタイプに関連付けられるタイミングを指定します。
| 環境変数 | 説明 |
|---|---|
CRM_alert_kind
|
アラートの種類 (ノード、フェンス、またはリソース)
|
CRM_alert_version
|
アラートを送信する Pacemaker のバージョン
|
CRM_alert_recipient
|
設定された送信側
|
CRM_alert_node_sequence
|
アラートがローカルノードで発行されるたびに増加するシーケンス番号。これは、Pacemaker によりアラートが発行された順序を参照するのに使用できます。後で発生したイベントのアラートは、先に発生したイベントのアラートよりもシーケンス番号が大きくなります。この番号は、クラスター全体を対象とする番号ではないことに注意してください。
|
CRM_alert_timestamp
| timestamp-format メタオプションで指定された形式で、エージェントの実行前に作成されたタイムスタンプ。これにより、エージェントは、エージェント自体が呼び出されたタイミング (システムの負荷やその他の状況により遅延する可能性があります) に関係なく、信頼できる高精度のイベント発生時間を使用できます。
|
CRM_alert_node
|
影響を受けるノードの名前
|
CRM_alert_desc
|
イベントの詳細。ノードアラートの場合は、ノードの現在の状態 (番号または lost) になります。フェンスアラートの場合は、フェンス操作の要求元、ターゲット、フェンス操作のエラーコードなどを含む要求されたフェンス操作の概要になります。リソースアラートの場合、これは
CRM_alert_status と同等の文字列です。
|
CRM_alert_nodeid
|
状態が変更したノードの ID (ノードアラートの場合のみ提供)。
|
CRM_alert_task
|
要求されたフェンスまたはリソース操作 (フェンスおよびリソースアラートの場合のみ提供)。
|
CRM_alert_rc
|
フェンスまたはリソース操作の数値の戻りコード (フェンスおよびリソースアラートの場合のみ提供)。
|
CRM_alert_rsc
|
影響を受けるリソースの名前 (リソースアラートのみ)。
|
CRM_alert_interval
|
リソース操作の間隔 (リソースアラートのみ)
|
CRM_alert_target_rc
|
操作の予期される数値の戻りコード (リソースアラートのみ)。
|
CRM_alert_status
|
Pacemaker が、操作の結果を示すために使用する数値コード (リソースアラートのみ)。
|
アラートエージェントを記述する際は、以下を考慮する必要があります。
- アラートエージェントは受信者なしで呼び出されることがあります (受信者が設定されていない場合)。したがって、エージェントは、このような状況では終了しかしない場合でも、この状態に対応できなければなりません。設定を段階的に変更し、後で受信側を追加することもできます。
- 1 つのアラートに複数の受信側が設定されると、アラートエージェントは受信側ごとに 1 回呼び出されます。エージェントが同時に実行できない場合は、受信側を 1 つのみ設定する必要があります。エージェントは、受信側をリストとして解釈することができます。
- クラスターイベントの発生時、すべてのアラートは別々のプロセスとして同時に発生します。設定されているアラートと受信者の数、およびアラートエージェント内で行われている内容に応じて、負荷が急激に増加する可能性があります。たとえば、リソースを大量に消費するアクションを直接実行するのではなく、別のインスタンスのキューに追加することで、これを考慮に入れるようにエージェントを作成できます。
- アラートエージェントは、最低限のパーミッションを持つ
haclusterユーザーとして実行されます。エージェントに追加の特権が必要な場合は、適切な特権を持つ別のユーザーとしてエージェントが必要なコマンドを実行できるように、sudo を設定することが推奨されます。 CRM_alert_timestamp（それらのコンテンツは、ユーザーが設定したtimestamp-formatで指定される）、CRM_alert_recipient、およびすべてのアラートオプションなど、ユーザーが設定したパラメーターを検証およびサニタイズすることに注意してください。これは、設定エラーから保護するために必要です。さらに、一部のユーザーがクラスターノードへのhacluster-level アクセスがなくても CIB を変更できる場合は、セキュリティー上の問題となる可能性があるため、コードの挿入の可能性を回避する必要があります。onfailパラメーターが fence に設定されている操作を持つリソースがクラスターに含まれる場合、障害発生時に複数のフェンス通知が発生します（このパラメーターが設定されているリソースごとに 1 つと、追加の通知 1 つが含まれます）。STONITH デーモンとcrmdデーモンの両方が通知を送信します。この場合、送信される通知の数に関係なく、Pacemaker は 1 つのフェンス操作のみを実際に実行します。
注記
アラートインターフェイスは、
ocf:pacemaker:ClusterMon リソースで使用される外部スクリプトインターフェイスと後方互換性を持つように設計されています。この互換性を維持するために、アラートエージェントに渡される環境変数に CRM_notify_ および CRM_alert_ が追加されます。互換性違反の 1 つは、ClusterMon リソースが root ユーザーとして外部スクリプトを実行し、アラートエージェントは hacluster ユーザーとして実行されることです。ClusterMon によってトリガーされるスクリプトの設定については、「モニタリングのリソースを使ったイベント通知」 を参照してください。
