Pacemaker 1.1 Configuration Explained – (5) クラスタリソース
(5)クラスタリソース
クラスタリソースとは
クラスタによって可用性を高められたサービスをリソースと呼びます。もっともシンプルな例はプリミティブリソースです。もう少し複雑なものにグループリソースやクローンリソースなどがあります。
すべてのプリミティブリソースにはリソースエージェントがあります。リソースエージェントは提供するサービスを取り出したり、クラスタに対して可視状態にするための外部プログラムです。
Pacemakerクラスタは管理するリソース自体の内部動作は把握していません。start, stop, monitorといったコマンドを通してのみ管理します。このため、各コマンドが正常に動作するよう、リソースエージェントのテストを行うことが非常に重要です。
リソースエージェントは通常はシェルスクリプトですが、CやPython、Perlなど何でもかまいません。
リソースクラス
Pacemakerはエージェントに以下のクラスを用意しています。
- OCF
- LSB
- Upstart
- Systemd
- Service
- Fencing
- Nagios Plugins
Open Cluster Framework(OCF)
OCFは後述するLinux Standard Baseを拡張したもので、オプションの利用が可能です。
作成においては、戻り値は規則に厳格に従う必要があります。
OCFクラスはもっとも標準的な形式として推奨するものです。柔軟性が高く、自己記述的であり、パラメータを非定位置で渡すことができます。
OCFの詳細はこちらをご参照ください
http://www.linux-ha.org/wiki/OCF_Resource_Agents
Linux Standard Base(LSB)
/etc/init.d配下にあるものがLSBスクリプトです。
通常はディストリビュータが提供するものであり、LSB規則に従っている必要があります。
注意：ディストリビュータがLSBに準拠していると主張していても、実際にはLSBと完全な互換性がないケースもあります。InitスクリプトがLSBと互換性があるか確認するには、以下を参照してください。
http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ap-lsb.html
代表的な問題のあるパターンには以下のようなものがあります。
- ステータス情報を得る動作を実装していない
- start/stop/statusの正しい戻り値を得ていない
- 起動しているリソースを起動しようとするとエラーになる
- 停止しているリソースを停止しようとするとエラーになる
重要：マシンの起動時にサービスが起動しないようにしてください。クラスタの管理のもとで起動させる必要があります。
Systemd
新しいディストリビューションではSysVに代わってSystemdが使用されているものがあります。Pacemakerはinitスクリプトの代わりにunitスクリプトを利用することができます。
重要：マシンの起動時にサービスが起動しないようにしてください。クラスタの管理のもとで起動させる必要があります。
Upstart
新しいディストリビューションではSysVに代わってUpstartを使用しているものがあります。
Pacemakerはinitスクリプトの代わりにUpstartのjobを利用することができます。
重要：マシンの起動時にサービスが起動しないようにしてください。クラスタの管理のもとで起動させる必要があります。
SystemServices
systemdやupstart、lsbなど様々な種類のサービスがあるため、Pacemakerはserviceというエイリアスを用意しており、クラスタノード内でどれが使用されているかを判別することができます。
Serviceを使用した場合には、通常は以下の順番でサービスを探します。
- LSB
- Systemd
- Upstart
STONITH
このSTONITHクラスはフェンシング機能に関連するリソースです。詳細は13章で扱います。
Nagios Pligin
このプラグインを使用するとリモートホストからサービスを監視することができます。
主な利用シーンとしては、リソースコンテナ(通常は仮想マシン)に関連するリソースを設定しており、このリソースに異常があればコンテナを再起動させる場合です。
あるいはネットワークを介してホストやサービスを監視するという通常リソースとしての利用があります。
ソースプロパティ
リソースプロパティとは、リソースが使用するリソースエージェントを特定したり、その
リソースエージェントがどのような規則で書かれているかを指定するものです。
以下はprimitiveリソースのプロパティーです
プロパティー | 説明 |
id | リソース名 |
class | リソースエージェントの形式。指定できるのは : lsb, Nagios, ocf, service, stonith, system, upstart |
type | 表示させるリソースエージェント名 |
provider | OCFは同じリソースエージェントに対して複数のベンダーが提供することができる。例えばHeartbeatプロジェクトが提供するリソースエージェントを使用したい場合にはheartbeatをプロパティーに指定する。 |
注記：システムサービス(LSB、systemd、Upstart)には、パラメータを指定することができない欠点があります。
リソースオプション
リソースにはメタ属性とインスタンス属性の２つのオプションがあります。メタ属性はすべてのリソースに設定可能ですが、インスタンス属性については各リソースエージェントごとに異なります。
リソースメタ属性
メタ属性はリソースの挙動を制御します。crm_resourceコマンドで—metaオプションを付けて実行することで設定することが可能です。
属性名 | デフォルト | 説明 |
priority | 0 | 全てのリソースをアクティブにできない場合に、優先するリソースを起動させるために優先度の低いリソースを停止する。 |
target-role | started | クラスタが対象のリソースに保たせる状態 |
is-managed | TRUE | クラスタがリソースを起動・停止できるかどうか。trueまたはfalse |
resource-stikiness | rsc_defaultsセクションのresource-stikinessの値 | どの程度リソースがもとのノードに留まろうとするか |
requires | fencing | リソースの起動できる条件(1.1.8以降から) |
migration-threshold | INFINITY | リソースが何回失敗すると該当ノードで起動できなくなるかの回数。 |
failure-timeout | 0 | 指定した時間(秒)の経過後に該当のリソース障害のカウントをゼロに戻す |
multiple-active | stop_start | 2つ以上のノードでリソースが起動していることを検知した際の挙動 |
allow-migrate | TRUE(ocf:pacemaker:remoteリソースの場合) | “live migrate”を行うかどうか。TLUEまたはFALSE |
remote-node | – | リモートノード名を規定する。 |
remote-port | 3121 | リソースをリモートノードとして有効にすると共に、リモートノードを特定するために使用する一意の名前を定義する。特に他のパラメータで設定されていない場合、この値はremote-nodeで規定するポートが接続を行うホスト名とされる。注意：この値は他のリソースやノードIDと重複することはできない。 |
remote-addr | remote-nodeの値 | リモートノード名がゲストのホスト名ではない場合のIPアドレスまたはホスト名 |
remote-connect-timeout | 60ｓ | ペンディングしているゲストのコネクションがタイムアウトするまでの時間 |
リソースメタ属性のグローバル設定
rsc_defaultsセクションに記載することで、リソースオプションのデフォルト値を設定することができます。
この操作はcrm_attributeコマンドで行うことができます。
例：
# crm_attribute --type rsc_defaults --name is-managed --update false
上記を行うと、各リソースで個別にis-managedをtrueに設定しない限り、クラスタ内に設定してあるリソースはstartもstopもできなくなります。
リソースインスタンス属性
リソースクラスによっては、リソースエージェントや、その制御するインスタンスの挙動を決定するためのパラメータを与えることができます(lsb, system, upstartは対応していません)。
crm_resourceコマンドでipアドレスを与える例
# crm_resource --resource Public-IP --set-parameter ip --parameter-value 192.0.2.2
リソースオペレーション
オペレーションとは、クラスターがリソースエージェントを使用してリソースに行わせることができる動作です。リソースエージェントは少なくともstart, stop, monitorオペレーションを行うことができます。それに加えて、リソースエージェントによってはその他のオペレーションに対応しています。
また、monitorオペレーションは1つのリソースに対しては、同じ名前や間隔でない限り複数を設定することができます。
以下はオペレーションに対するプロパティーの表です。
属性名 | デフォルト | 説明 |
id | 一意のオペレーション名 | |
name | 実行する操作。エージェントが対応していれば何でもよい。共通する値は、monitor, start, stop | |
interval | 0 | 操作を行う頻度を秒単位で指定する。0の場合には行わない。正の値を指定すると定期的に動作する。主にmonitorに使用する。 |
timeout | 操作が失敗したとみなすまでの時間 | |
on-fail | restart(stop操作を除き、STONITHが有効な場合にはデフォルトでfenceであり、そうでなければblock) | 操作が失敗した時にとる動作。 |
enabled | TRUE | falseの場合は本オプションは無効になる。これは特定のモニター処理を停止させる場合などに使用する。例えば、本機能のみで設定済みのモニター処理をブロックすることはないため、各リソースがunmanaged(is-managed=false)であることを補完できる。動作を無効にすることは任意のタイプの全動作を抑制するわけではない。 |
record-pending | FALSE | trueの場合、操作を試行したことを記録し、GUIやCUIツールで操作の進行状況を確認できるようにする。これが運用時のデフォルト設定として最適である。 |
role | クラスタが最適と判断するノードでのみ動作を行う。本オプションは定期的なモニター処理に対してのみ意味がある。 |
障害に備えたモニタリング
Pacemakerがリソースを起動したときには、最初に一回monitorオペレーションを行います。これはリソースがあるべきノードで起動しており、起動すべきでないノードで起動していないことを確認するために行われます。
最初の一回のmonitor以降、Pacemakerはリソースが正常に稼働し続けるものと想定し、デフォルトではmonitorアクションを行いません。monitorを行う場合は明示的に指定する必要があります。
また、monitorにはtarget-roleプロパティーを指定できます。例えばinterval=10 role=Startedを設定すれば10秒ごとにリソースが起動していることを確認します。
リソースを管理していない状態でのモニタリング
monitor処理はリソースの管理状況によって異なります。
- リソースがunmanaged状態(is-managed=false)の場合
：monitor処理は停止しません。
unmanaged状態のリソースがノード上で停止しても、クラスタはそれが起動したままだと判断します。クラスタがそのリソースが停止していることを検知して報告しても、monitorが失敗したとは判断しません。そのため再びmanaged状態になるまでリソースの再起動処理は行われません。
- ノードがstandbyの場合
：前リソースがそのノードから取り除かれ、monitor処理は停止します。ただし、明示的にrole=Stoppedであるリソースについてはmonitorが行われます。
- ノードがメンテナンスモードの場合
：全リソースはunmanaged状態になり、monitor処理も全て停止します(role=Stoppedのリソースを除き)。
グローバルデフォルトを設定する
CIBのconfigurationセクションのop_defaultsで、クラスタ全体のオペレーションプロパティーを設定することができます。
あるいは、以下のようにcrm_attributeコマンドを使って設定することもできます。
# crm_attribute --type op_defaults --name timeout --update 20s
モニターオペレーションを無効にする
monitor処理を停止したい場合には、その設定を消すことで実現できます。
しかし、単に一時的に停止したいような場合には、そのmonitor設定行の末尾にenabled=”false”を追加すれば当該monitorは停止します。