(9)高度な設定

リモートマシンからの接続

Pacemakerがインストールしてあれば、異なるクラスタのマシンにも接続できます。いくつかの環境変数を設定して通常と同じコマンドを実行することで可能です。

リモートのCIBに接続するために使用する環境変数

c001n01がアクティブなクラスタノードで、1234ポートで接続をリスンしている、haclientグループのsomeuserとします。以下のコマンドを実行すると、someuserのパスワードを求め、そして現在のクラスタの設定を返します。

# export CIB_port=1234; export CIB_server=c001n01; export CIB_user=someuser;
# cibadmin -Q

セキュリティ上の理由から、クラスタはデフォルトではリモート接続をリスンしていません。リモートアクセスを行いたい場合には、remote-tls-port(暗号化)またはremote-clear-port(非暗号化)のCIBプロパティーを設定する必要があります。(これらはnum_updateやepochなどのようにcibタグに保存されます。)

リモートアクセスのための特別な最上位CIBプロパティー

定期的な処理を実行する時間を指定する

定期的なアクションは、デフォルトではそのリソースが開始した時点に応じて決まります。例えば14:32にリソースを開始した場合、バックアップを24時間ごとに取得する設定にしたばあい場合には、バックアップが常に業務時間内に行われることになります。これは適切ではありません。

動作の基準とする時間はinterval-originで指定します。クラスタはこの時点で動作するように、起点+(間隔×N)で求められるstart-delayを計算します。

例えば、動作の間隔が24hで、interval-originが02:00であり、現在14:32だった場合、クラスターは11時間28分のstart-delayで動作を開始します。

intervalとinterval-originに指定できる値はISO8601に準じます。例えば2009年の最初の月曜以降の毎月曜に動作させたいのであれば、以下のようになります。

<op id="my-weekly-action" name="custom-action" interval="P7D" interval-origin="2009-W01-1"/>

リソース障害に対処する

リソースに障害が起きた場合、Pacemakerはデフォルトではリソースを再起動します。この時に行うオペレーションは細かく設定することができます。

フェイルカウント

Pacemakerはノード、リソース、オペレーション(start, stop, monitor等)ごと障害回数(フェイルカウント)を記録しています。crm_failcountコマンドを使用することでリソースの全動作のフェイルカウントを確認することができます。

以下の例では、node1ノードでmyrscリソースのmonitorが10秒間に何回障害が起きたかを表示します。

# crm_failcount --query -r myrsc -N node1 -n monitor -I 10s

ノード名を指定しない場合にはローカルノードの情報が表示されます。動作とインターバルを指定しない場合にはノードで起きたそのリソースのすべてのオペレーションのフェイルカウントが表示されます。

フェイルカウントを消去したい場合にはcrm_resource –cleanupまたはcrm_failcount –deleteコマンドを使用します。例えば、上記のフェイルカウントを消したい場合には以下のコマンドを使用します。

# crm_resource --cleanup -r myrsc -N node1 -n monitor -I 10s

ここでリソース名を省略した場合には、全リソースのフェイルカウントを消去します。ノードを省略した場合には、全ノードが、オペレーションとインターバルを省略した場合にはそのノードの全オペレーションが消去されます。

注記 : 一つのオペレーションのみを消去した場合であっても、すべてのオペレーションのフェイルカウントが消去されます。また、この際にはリソースの現在の状態の再チェックが行われます。

また、crm_mon –failcountsコマンドでリソースごとのフェイルカウントを確認することもできます。

障害時の動作

稼働中のリソースに障害が発生した場合、Pacemakerは一度停止させてから再起動を試みます。Pacemakerは都度適切な場所を選んで起動しようとしますが、また同じノードで起動して再度障害が起きてしまう可能性があります。

繰り返しリソースに障害が起きる場合には、そのノードには何かの問題があると考えられるため、別のノードで起動したほうがよく、このような場合にはmigration-thresholdというメタ属性を使用します。

リソースにmigration-threshold=Nを設定すると、N回障害が起きると以後そのノードでは起動が禁止されます。

注記 : フェイルカウントがオペレーションごとに記録されていても、migration-thresholdはリソースごとに扱われます。オペレーションのフェイルカウントはmigration-thresholdに対しては合算して扱われます。

デフォルトでは、手動でcrm_resource –cleanupまたはcrm_failcount -deleteコマンドを使用するまではフェイルカウントはそのまま残っています(フェイルカウントを消去する前に障害原因を解消してください)。ただし、failure-timeoutをリソースメタ属性に設定することでフェイルカウントを自動的に期限が来たら消すことができます。

重要 : オペレーションが成功しても、その過去分のフェイルカウントは消えません。定期的なmonitorオペレーションが一回失敗し、その後問題なく動作していて、後日再度失敗したような場合、フェイルカウントは2です。フェイルカウントは手動でクリアするか、failure-timeoutが過ぎた場合にのみ消去されます。

例えば、migration-threshold=2とfailure-timeout-60sを設定していた場合には、2回の障害後に別のノードにリソースが移動し、1分後に(resource-stickinessと制約条件にもよりますが)元のノードに戻ることができるようになります。

注記 : failure-timeoutは一番新しい障害の時点から計測されます。このため古い障害が個別にタイムアウトしてフェイルカウントが減っていくことはありません。つまり、タイムアウト時間内に新しい障害が発生しなければ、すべてのフェイルカウントが同時にタイムアウトして、0にリセットされることになります。

migration-thresholdに関しては2つの例外があります。それはリソースのstartオペレーションに失敗した場合と、stopオペレーションに失敗した場合です。

クラスタプロパティのstart-failure-is-fatalがtrueに設定されていると(デフォルト)、リソースのstartに失敗した場合にはフェイルカウントがINFINITYになり、即座にリソースは別のノードに移動します。

stopに失敗した場合には少々異なる動作になります。リソースのstopに失敗した時にSTONITHが有効であれば、リソースを他の場所で起動できるようにそのノードはフェンシングされます。STONITHが無効であれば、クラスタは何もせず、また他の場所で起動も行いません。ただしfailure-timeoutの経過後に再度stop処理を行おうとします。

リソースの移動

リソースを手動で移動する

リソースを現在の場所から別のノードに移動させたい場合には基本的には2つのケースがあると思います。ノード全体をメンテナンスする場合と、リソース単独で移動させたい場合です。

スタンバイモード

リソースをあるノード上で動作させたくない場合はスコアを調節によって可能です。この際、直接スコアを調節するのではなく、crm_standbyコマンドを使う事で楽に操作できます。

以下のコマンドでコマンドを実行したノードをスタンバイモードにすることができ、このノード上で全てのリソースが起動できなくなります。

# crm_standby -v on

スタンバイモードを解除する場合には以下のコマンドを実行します。

# crm_standby -v off

また、現在ノードがスタンバイ状態であるかはcrm_monコマンドで確認できますが、以下でも確認ができます。

# crm_standby -G

crm_standbyコマンドは、–nodeオプションを付けると他のノードに対しても操作や確認が可能です。

リソースを単独で移動する

リソースを1つだけ移動させたい場合には、位置制約を用いてこれを行う事ができます。crm_resourceというコマンドを使って行えます。

例えば、sles-1ノードでEmailというリソースが動作していて、sles-2ノードに移動させたい場合には以下のコマンドを使います。

# crm_resource -M -r Email -H sles-2

上記のコマンドを実行すると、背後では以下のような位置制約が設定されています。

<rsc_location rsc="Email" node="sles-2" score="INFINITY"/>

ただし、このコマンドは累積的な効果を持たない点に注意してください。

つまり、例えば以下のコマンドを続けて実行した場合には、最初のコマンドは無視されることになります。

# crm_resource -M -r Email -H sles-2
# crm_resource -M -r Email -H sles-3

リソースをもとの場所に戻す場合には以下のコマンドを実行します。

# crm_resource -U -r Email

しかしながら、resource-stickinessの設定によっては戻りません。確実に元に戻したい場合には、crm_resource -Uを実行する前にsles-1に移動させておきます。

# crm_resource -M -r Email -H sles-1
# crm_resource -U -r Email

あるいは、現在のノードでリソースを稼働させたくない場合には以下のコマンドを実行してもよいでしょう。

# crm_resource -B -r Email

この場合には以下の位置制約が設定されることになります。

<rsc_location rsc="Email" node="sles-1" score="-INFINITY"/>

この位置制約の設定を消したい場合にも、以下のコマンドを実行することで行えます。

crm_resource -U -r Email

接続状態に応じてリソースを移動する

クラスタ外部への接続ができなくなった際にリソースを移動させる設定を行うことも可能です。

接続状態をPacemakerに伝える

ocf:pacemaker:pingリソースを追加することで、pingdが指定のマシン(DNSホスト名またはIPv4/v6アドレス)にpingが到達するかどうかをチェックし、この結果をノード属性に渡します。

通常はpingリソースはすべてのクラスタノードで動作する必要があるため、クローンを作成します。以下にパラメータとあわせてテンプレートとなる例を示します。

pingリソースのオプション：

毎分ごとに接続チェックを行うpingリソースの例：

<clone id="Connected">
   <primitive id="ping" provider="pacemaker" class="ocf" type="ping">
    <instance_attributes id="ping-attrs">
      <nvpair id="pingd-dampen" name="dampen" value="5s"/>
      <nvpair id="pingd-multiplier" name="multiplier" value="1000"/>
      <nvpair id="pingd-hosts" name="host_list" value="my.gateway.com www.bigcorp.com"/>
    </instance_attributes>
    <operations>
      <op id="ping-monitor-60s" interval="60s" name="monitor"/>
    </operations>
   </primitive>
</clone>

接続状態による判断をPacemakerに伝える

接続状態に関する情報を扱うには様々な方法があります。

もっとも基本的なものは、接続できないノードでクラスタを動作させないものです。以下の例は1つのping確認先(例：デフォルトゲートウェイ)を設定するものです。

<rsc_location id="WebServer-no-connectivity" rsc="Webserver">
   <rule id="ping-exclude-rule" score="-INFINITY" >
    <expression id="ping-exclude" attribute="pingd" operation="not_defined"/>
   </rule>
</rsc_location>

または、3つ以上のping確認先に接続できているノードでのみリソースが起動できる設定例は以下です：

<primitive id="ping" provider="pacemaker" class="ocf" type="ping">
... <一部省略>
      <nvpair id="pingd-multiplier" name="multiplier" value="1000"/>
...
</primitive>
...
<rsc_location id="WebServer-connectivity" rsc="Webserver">
   <rule id="ping-prefer-rule" score="-INFINITY" >
      <expression id="ping-prefer" attribute="pingd" operation="lt" value="3000"/>
   </rule>
</rsc_location>

あるいは、最も接続状態がよいノード1つだけを選ぶこともできます。この時、multiplierをresource-stickinessよりも大きくなるように設定します。

<primitive id="ping" provider="pacemaker" class="ocf" type="ping">
... <一部省略>
      <nvpair id="pingd-multiplier" name="multiplier" value="1000"/>
...
</primitive>
...
<rsc_location id="WebServer-connectivity" rsc="Webserver">
   <rule id="ping-exclude-rule" score="-INFINITY" >
    <expression id="ping-exclude" attribute="pingd" operation="lt" value="3000"/>
   </rule>
   <rule id="ping-prefer-rule" score-attribute="pingd" >
    <expression id="ping-prefer" attribute="pingd" operation="defined"/>
   </rule>
</rsc_location>

リソースのマイグレーション

通常リソースを移動する場合にはリソースは再起動されます。

しかしXenの仮想ゲストなどは状態を保ったまま移動させることができます(ライブマイグレーションやホットマイグレーションとも呼ばれます)。Pacemakerではこれをリソースマイグレーションと呼んでおり、再起動なしに移動させる設定を行うことができます。

ただし、すべてのリソースのマイグレーションができるわけではありません。条件を満たしたもののみです。

• 元のロケーションでリソースが正常な状態でアクティブであること、かつ
• 新旧両方のロケーションでリソースが正常に動作できること

クラスタはリソースエージェントに2つの特別なアクションを要求することでpushとpullのマイグレーションモデルに対応しています。migrate_to(現在のロケーションで実行)とmigrate_from(行先で実行)です。

ノードの健全性チェック

クラスタメンバシップのうえではノードが正常に動作しているように見えても、実際には「不健全な」状態であることがあります。SMARTエラーが出ていたり、CPU負荷が高いような場合です。

Pacemakerはそのような不適切なノードからリソースを移動させる手段を提供します。

ノード健全性属性

Pacemakerは#healthで始まるノード属性をノード健全性の使用として使用します。以下の値があります。

ノード健全性ストラテジー

Pacemakerはすべてのノード健全性属性の値の合計値として、ノード健全性スコアを各ノードに与えます。この値はノードの全リソースに適用される位置制約として使用されます。

node-health-strategyクラスタオプションはノード健全性属性の変化への反応やred,yellow,greenのスコアへの換算を制御します。

ノード健全性ストラテジ

ノード健全性の計測

Pacemakerはノード健全性をノード属性から算出するので、ノード属性を設定する操作はノード健全性に影響します。一般的にはリソースエージェントや、個別のデーモンです。

Pacemakerはそのまま、あるいはカスタムして使用できる雛型を用意しています。ocf:pacemaker:HealthCPUおよびocf:pacemaker:HealthSMARTリソースエージェントはCPUとディスクパラメータに基づきノード健全性を設定します。ipmiservicelogdデーモンはIPMI値に基づき　ノード健全性属性を設定します(ocf:pacemaker:SystemHealthリソースエージェントは、デーモンをクラスタリソースとして扱うことができます)。

設定変更後のサービスのリロード

クラスタは管理するサービスの設定変更があると自動的に検知します。通常は(古い設定を使って)停止してから(新しい設定を使って)起動します。しかし、再起動をせずに新しいオプションのセットを使うことができます。

この機能を使うためにはリソースエージェントは以下の条件を満たしている必要があります。

(1) reloadオペレーションに対応し、要求されるアクションを行えること。アクションについてはアプリケーションに依存します。

例：reloadをサポートするDRBDリソースエージェント

case $1 in
    start)
        drbd_start
        ;;
    stop)
        drbd_stop
        ;;
    reload)
        drbd_reload
        ;;
    monitor)
        drbd_monitor
        ;;
    *)
        drbd_usage
        exit $OCF_ERR_UNIMPLEMENTED
        ;;
esac
exit $?

(2) actionsセクションでreload操作が通知されること

例：reloadオペレーションをサポートし、通知を行うDRBDリソースエージェント

<?xml version="1.0"?>
  <!DOCTYPE resource-agent SYSTEM "ra-api-1.dtd">
  <resource-agent name="drbd">
    <version>1.1</version>
    <longdesc>
      Master/Slave OCF Resource Agent for DRBD
    </longdesc>
    ...

    <actions>
      <action name="start"   timeout="240" />
      <action name="reload"  timeout="240" />
      <action name="promote" timeout="90" />
      <action name="demote"  timeout="90" />
      <action name="notify"  timeout="90" />
      <action name="stop"    timeout="100" />
      <action name="meta-data"    timeout="5" />
      <action name="validate-all" timeout="30" />
    </actions>
  </resource-agent>

(3) reloadコマンドで、影響のある1つまたは複数のパラメータが通知されること。

以下のようにしてuniqueセットが０のすべてのパラメータが対象。

例：reloadを使って変更することのできるパラメータ

<parameter name="drbdconf" unique="0">
    <longdesc>Full path to the drbd.conf file.</longdesc>
    <shortdesc>Path to drbd.conf</shortdesc>
    <content type="string" default="${OCF_RESKEY_drbdconf_default}"/>
</parameter>

これらの条件を満たしていれば、uniqueでないフィールドの変更があった時にクラスタは自動的にリロードしたリソースを検知します。

注記：メタデータはリソースが起動時にしか再読み込みされません。そのためPacemakerでunique=0に変更していたとしても、最初にリソースが再起動されます。

注記：同時にuniqueと非uniqueのフィールドが変更された場合には、リソースは再起動します。