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-11 11:50:32

Contents

  1. Heartbeatバージョン2に関するよくある質問と回答
    1. crmadminが使用中のリソースをアクティブでないと認識してしまうのはなぜでしょうか?
    2. OCF準拠のリソースエージェントを作成するには?
    3. Heartbeatに、自分で用意したInitスクリプトを対応することはできますか?
    4. リソースの障害を監視するには?
    5. モニタがリソースの停止を検出すると、どうなるのですか?
    6. Heartbeatを再起動せずに、新しいcib.xml構成ファイルをHeartbeatに読み込むことはできますか?
    7. cib.xmlをほかのノードと同期してもいいですか?
    8. 各種のタイマ/タイムアウトの違いは何ですか?
    9. Heartbeatが正確にインストールされていることを確認するには?
    10. バージョン2ではhb_standbyが動作しないのはなぜですか?
    11. クラスタノードを置き換えるには?
    12. 関連情報

このページの最後に含まれるその他のFAQ項目

  1. ja/v2/faq/forced failover ja
  2. ja/v2/faq/manual recovery ja
  3. ja/v2/faq/pingd ja
  4. ja/v2/faq/resource too active ja
  5. ja/v2/faq/stop resource ja
  6. ja/v2/faq/time based failback ja

Heartbeatバージョン2に関するよくある質問と回答

crmadminが使用中のリソースをアクティブでないと認識してしまうのはなぜでしょうか?

グループの一部になっているリソースをチェックしようとしている可能性があります。

リソース名の前にグループのidを付けてください。例:crmadmin -W group_id:rsc_id

バージョン2.0.3では、短い名前も使用できます(short_resource_namesオプションが設定されている場合)。

OCF準拠のリソースエージェントを作成するには?

以下の場所に、OCF RAの仕様が掲載されています。
http://www.opencf.org/cgi-bin/viewcvs.cgi/specs/ra/resource-agent-api.txt?rev=HEAD

Heartbeatに、自分で用意したInitスクリプトを対応することはできますか?

InitスクリプトはLSBリソースエージェントとして処理されます。それに関連した問題が発生することがあります。LSBリソースエージェントページでは、スクリプトが使用可能かどうかを判定する手順がご覧になれます。

リソースの障害を監視するには?

最も要求が多かったHeartbeat機能は、(ノード全体だけでなく)リソースに障害が発生したことを検出する機能でした。

これに対応するために、 CRMmonitor操作も認識します。

Heartbeatでリソースの動作を確認するには、リソースのoperationssセクションで1つ、または複数のモニタ操作を指定する必要があります。

モニタ操作ごとに、リソースの状態をチェックする間隔をHeartbeatに指示するintervalを指定します。

詳細については、ja/ClusterInformationBase/Actions_jaのセクション2と注釈付きのDTDの操作セクションをご参照ください。

モニタがリソースの停止を検出すると、どうなるのですか?

ノードがリソースを再起動しようとしますが、失敗すると、相手ノードにフェイルオーバします。

一定期間中にN回の障害が発生した後にフェイルオーバする機能が計画されています。

Heartbeatを再起動せずに、新しいcib.xml構成ファイルをHeartbeatに読み込むことはできますか?

もちろん可能です。cibadminツールのreplaceオプションが必要です。

cib.xmlをほかのノードと同期してもいいですか?

もちろんです。ただ、この操作は、クラスタ情報ベースが自動的に実行しているはずです。2つのアクティブノードの内容が同期されていない状況を発見された際には、バグをご報告ください

各種のタイマ/タイムアウトの違いは何ですか?

  • ha.cfには、以下が含まれています。

    • deadtime:ノードがキープアライブを受信していない場合に、ノードが停止していると判断されるまでの時間
    • deadping: deadtimeと同じ。ただし、クラスタノードではなくpingノードが対象

    • conn_logd_time: 接続が切断された場合に、Heartbeatがログデーモンに再接続するまでの時間
    • initdead: Heartbeatが最初に起動されたときにクラスタノードの停止を宣言するまでの時間
    • warntime: Heartbeatが「ハートビート遅延」警告を発行するまでの時間を指定
  • cib.xmlには、以下が含まれています。

    • transition_timeout: 現在の遷移がタイムアウトして再試行するまでの時間。これは、操作が失敗するか、ほかのタイムアウトが操作に指定されている場合に有効となる。
    • timeout: startstopmonitor操作で、操作が失敗したと判断されるまでの最長期間

Heartbeatが正確にインストールされていることを確認するには?

/usr/lib/heartbeat/BasicSanityCheckを実行して、Heartbeatのインストールをチェックすることができます。

バージョン2ではhb_standbyが動作しないのはなぜですか?

バージョン2では、crm_standbyを使用します。使用可能なコマンドについては、 ja/v2/AdminTools_ja をご参照ください。

障害発生後にリソースを強制的に移行させるには?

2.0.5以前のバージョンでは、これを行う方法はありません。

それ以降のバージョンでは、リソースのresource_failure_stickinessプロパティ(またはグローバルデフォルトのdefault_resource_failure_stickiness)を使用して、フェイルオーバを実行するタイミングを管理します。

以下のクラスタを想定します。

  • default_resource_failure_stickiness-100

  • default_resource_stickiness500

  • スコアが1500nodeAでリソースmy_rscを実行するように設定

  • スコアが1000nodeBでリソースmy_rscを実行するように設定

my_rscについては、nodeBに移動されるまでに、nodeAで障害が発生しても10回まで許容されます。

(nodeA score - nodeB score + stickiness) / abs(failure stickiness)

==> (1500 - 1000 + 500) / abs(-100)

==> 1000 / 100

==> Answer: 10

ただし、default_resource_failure_stickiness-1001以下に設定されている場合は、すぐに移動されます。

(nodeA score - nodeB score + stickiness) / abs(failure stickiness)

==> (1500 - 1000 + 500) / abs(-1001)

==> 1000 / 1001

==> Answer: 0.999

注: 障害許容度は、マイナス値に設定する必要があります。
注: +/-INFINITYのルールが適用されます。

 INFINITY +/- -INFINITY : -INFINITY
 INFINITY +/-  int      :  INFINITY
-INFINITY +/-  int      : -INFINITY

多重障害

ノードのmy_rscの複合スコアがゼロ未満の場合、障害カウンタがリセットされるまで、再実行することはできません

現在の(特定のリソースおよびノードの)障害カウントにリソースの障害許容度をかけて、フェイルオーバスコアが生成されます。フェイルオーバスコアがノードの標準設定を超えると、リソースを再実行する対象からノードが除外されます(障害カウントがリセットされるまで)。

1つ目の例(default_resource_failure_stickiness-100)では、Heartbeatがリソースをそこで再実行しなくなるまでに、my_rscの障害が15回まで許容されます。同様に、nodeBでは、そのノードが同様に判断されるまで、10回の障害が許容されます。

2つ目の例(default_resource_failure_stickinessが-500未満)では、これらの値はそれぞれ、3回と2回の障害に減少します。

障害カウントのリセット

nodeAmy_rscの障害カウントをリセットするには、次のコマンドを使用します。

  • crm_failcount -D -U nodeA -r my_rsc

現在の障害カウントを照会するには、以下のコマンドを使用します。

  • crm_failcount -G -U nodeA -r my_rsc

リソースの移動時に障害カウントが自動的にリセットされないのはなぜですか?

リソースが2つ以上の「不良」ノード間で行き来しないよう、リソースの移動時に障害カウントは自動的にはリセットされません。

リソースを手動で回復するには?

リソースが管理されていないものとして表示されるのはなぜですか?

  • クラスタは、以下の2つの理由によって、リソースを管理されていないものと認識します。
    • 複数のノードでリソースがアクティブとして報告されている
    • クラスタから要求され、STONITHを使用できない場合に、リソースを停止できなかった

アクティブなリソースおよびリソース状態に関する信頼できる情報源は、LRM内にあります。CIBの内容は直接変更することはできないため、これらの変更はLRMからのデータで将来上書きされる可能性があります。

リソースを手動で停止し、クリーンアップしたら、crm_resourceの-Cオプションを使用して、LRMからリソースを削除する必要があります。この使用方法は、crm_resource --helpで表示できます。一般的な形式はcrm_resource -C -r my_resource_nameです。デフォルトでは、-H some_hostも指定しない限り、全てのクラスタノードで実行されます。

2.0.5以降、このコマンドは、クラスタにLRMからの最新の詳細情報を使用してクラスタ自身を更新するよう自動的に指示します。それまで、ユーザーは「少し待って」からcrm_resource -Rを実行します。

2.0.6(このドキュメントの執筆時点では、まだリリースされていません)以前は、ユーザーが適切な値を慎重に選択した上で、-rを付けて使用しなければなりませんでした。これはグループ内のリソースに影響を及ぼしますが、初期のCRMの選択が不適当であったことに加え、後方互換性を確保しなければならなかったことから、デフォルトのままにしていました。

以下のコマンドを実行すると、クラスタがリソースに使用する内部名が表示されます。:
cibadmin -Ql -o status | grep "lrm_resource " | awk '{print $2}' | sort -u

リソースに一致するものを探し、crm_resourceを呼び出す際にその値を使用してください。

バージョン2上での接続性の監視方法

pingd(ipfailに代わるコマンド)

pingdipfailに代わるコマンドです。バージョン2のほかのコマンドと同様に、任意の数のノードを含んだクラスタ内の接続性を確保する機能を提供します(および相対的な接続性に基いたリソースの実装)。

pingdの役割は、ノードの接続性の変更を検出して、同時に、その情報をCIBに更新することです。

管理者は、接続性が最も高いノードのリソースを特定するため、pingdがCIBに入れた情報を使用してください。 これは、pingdによって生成された属性を参照する位置制約を(管理者が)作成することで実行できます。下記の「位置制約でpingd出力を使用する」をご参照ください。

構成方法

pingdの構成には、次の2つのオプションがあります。

  1. 1つ目は、respawn命令をha.cfに追加するオプションです。

    • respawn root /usr/lib/heartbeat/pingd -m 100 -d 5s
      pingdに渡されるオプションの意味については、下記の「pingdの使用方法」を参照してください。

  2. 2つ目は、pingdOCFリソースエージェントを使用してcloneを作成するオプションです。RAはrootとして開始されるので、「apiauth pingd uid=root」などの行をha.cfに追加してください。より適切な方法としては、user=haclusterのパラメータをRA構成に追加し、respawnメソッドと同じようにapiauth命令を使用こともできます。バージョン2.0.6では、指定したユーザーが書き込みパーミッションを持つ場所(/tmp/pingd-defaultなど)を指定するパラメータpidfileも追加する必要があります。

いずれの方法でも、ha.cfファイルにpingノードが含まれていなければなりません。RAのhost_listパラメータでは、ほかのホストではなく、サブセットのみ使用できます。

いずれの方法でも、CIBに最低1つのコロケーション制約を追加してください。下記の「位置制約でpingd出力を使用する」をご参照ください。

リソースエージェントを使用するメリットとして、以下が実行できます。

  • 接続性の情報をノードに制限する
    • 特定のプロパティ(名前、ID、ノード属性)を持つノード
    • 特定のリソースを実行しているノード
  • 入出力オプションを動的に変更する
    • 監視するpingノードのリスト
    • 属性名
    • 乗数
    • 抑制の遅延

以下に、上記のrespawn命令に相当するリソースです。

<clone id="pingd">
  <instance_attributes id="pingd" globally_unique="false">
    <attributes>
      <nvpair id="pingd-clone_node_max" name="clone_node_max" value="1"/>
    </attributes>
  </instance_attributes>
  <primitive id="pingd-child" provider="heartbeat" class="ocf" type="pingd">
    <operations>
      <op id="pingd-child-monitor" name="monitor" interval="20s" timeout="40s" prereq="nothing"/>
      <op id="pingd-child-start" name="start" prereq="nothing"/>
    </operations>
    <instance_attributes id="pingd_inst_attr">
      <attributes>
         <nvpair id="pingd-dampen" name="dampen" value="5s"/>
         <nvpair id="pingd-multiplier" name="multiplier" value="100"/>
      </attributes>
    </instance_attributes>
  </primitive>
</clone>

注: CIBに含まれる属性の場所を変更することは、たとえ可能な場合でも、お勧めはできません。各ノードの属性のコピーが複数作成されてしまうことになり、クラスタが予期せぬ動作をすることがあります。

pingdの使用方法

usage: pingd [-V?p:a:d:s:S:h:Dm:]
        --help (-?)                     This text
        --daemonize (-D)                Run in daemon mode
        --pid-file (-p) <filename>      File in which to store the process' PID
                                        * Default=/tmp/pingd.pid
        --attr-name (-a) <string>       Name of the node attribute to set
                                        * Default=pingd
        --attr-set (-s) <string>        Name of the set in which to set the attribute
                                        * Default=cib-bootstrap-options
        --attr-section (-S) <string>    Which part of the CIB to put the attribute in
                                        * Default=status
        --ping-host (-h) <single_host_name> Monitor a subset of the ping nodes listed in ha.cf
                                            (can be specified multiple times)
        --attr-dampen (-d) <integer>        How long to wait for no further changes to occur before
                                            updating the CIB with a changed attribute
        --value-multiplier (-m) <integer>   For every connected node, add <integer> to the value set in the CIB
                                            * Default=1

位置制約でpingd出力を使用する

pingdの構成例

  • respawn root /usr/lib/heartbeat/pingd -m 100 -d 5s -a default_ping_set

CIBの例

Node

Connected Ping Nodes

default_ping_set Value

c001n01

5

500

c001n02

4

400

c001n03

5

500

  • c001n04

    N/A

    N/A

    c001n05

    0

    0

制約の例

<rsc_location id="my_resource:connected" rsc="my_resource">
    <rule id="my_resource:connected:rule" score_attribute="default_ping_set">
       <expression id="my_resource:connected:expr:defined" attribute="default_ping_set" operation="defined"/>
    </rule>
</rsc_location>

以下は、上記の制約の内容です。

  • default_ping_setに値を設定するよう要求する(c001n04は変更しない)

  • default_ping_setの値を100より大きく設定するよう要求する(c001n05は変更しない)

  • c001n01で実行するmy_resourceの設定を500増加させる

  • c001n02で実行するmy_resourceの設定を400増加させる

  • c001n03で実行するmy_resourceの設定を500増加させる

ノード

接続するPingノード

default_ping_setの値

複合スコア

c001n01

5

500

500

c001n02

4

400

400

c001n03

5

500

500

  • c001n04

    N/A

    N/A

    0

    c001n05

    0

    0

    0

例として、以下の制約があると仮定します。

<rsc_location id="my_resource:preferred" rsc="my_resource">
    <rule id="my_resource:prefer:c001n01" score="100">
       <expression id="my_resource:prefer:c001n01:expr" attribute="#uname" operation="eq" value="c001n01"/>
    </rule>
    <rule id="my_resource:prefer:c001n02" score="200">
       <expression id="my_resource:prefer:c001n02:expr" attribute="#uname" operation="eq" value="c001n02"/>
    </rule>
    <rule id="my_resource:prefer:c001n03" score="300">
       <expression id="my_resource:prefer:c001n03:expr" attribute="#uname" operation="eq" value="c001n03"/>
    </rule>
    <rule id="my_resource:never" score="-INFINITY" boolean_op="or">
       <expression id="my_resource:never:c001n04:expr" attribute="#uname" operation="eq" value="c001n04"/>
       <expression id="my_resource:never:c001n05:expr" attribute="#uname" operation="eq" value="c001n05"/>
    </rule>
</rsc_location>

その場合、リソースを実行するために更新されたスコアは、以下のようになります。

ノード

接続するPingノード

default_ping_setの値

複合スコア

c001n01

5

500

600

c001n02

4

400

600

c001n03

5

500

800

  • c001n04

    N/A

    N/A

    -INFINITY

    c001n05

    0

    0

    -INFINITY

現時点では、リソースが実行されていないか、resource stickinessがゼロに設定されている場合、リソースはc001n01c001n02をともにバックアップとしてc001n03で開始されます。

ただし、リソースがc001n02で実行され、resource_stickiness1000に設定されている場合、更新されたスコアは以下のようになります。

ノード

接続するPingノード

default_ping_setの値

複合スコア

c001n01

5

500

600

c001n02

4

400

1600

c001n03

5

500

800

  • c001n04

    N/A

    N/A

    -INFINITY

    c001n05

    0

    0

    -INFINITY

さらに、リソースは、c001n02で実行されたままになります。

あるいは、resource_stickiness100に設定されている場合、スコアは以下のようになります。

ノード

接続するPingノード

default_ping_setの値

複合スコア

c001n01

5

500

600

c001n02

4

400

700

c001n03

5

500

800

  • c001n04

    N/A

    N/A

    -INFINITY

    c001n05

    0

    0

    -INFINITY

さらに、リソースはc001n03に移動されます。

以下は、正しく設定することの重要性を示したものです。

  • pingdの--value-multiplierオプション

  • default_resource_stickiness / resource_stickiness

  • rsc_location制約のscore

クイックスタート – 最低1つのPingノードにアクセスするノードでのみmy_resourceを実行する

以下の行をha.cfに追加します。

  • respawn root /usr/lib/heartbeat/pingd -m 100 -d 5s -a pingd

この制約をCIBに追加します。

ping接続が失われた際、特定のサービスを終了した方がよい場合もあります。このルールでは、外部へのping接続が確立されない場所からサービスを実行することを禁止しています。ある程度の接続が確立された全てのノードは、pingノードにアクセスできる数には関係なく同様に扱われます。

<rsc_location id="my_resource:connected" rsc="my_resource">
  <rule id="my_resource:connected:rule" score="-INFINITY" boolean_op="or">
    <expression id="my_resource:connected:expr:undefined"
      attribute="pingd" operation="not_defined"/>
    <expression id="my_resource:connected:expr:zero"
      attribute="pingd" operation="lte" value="0"/>
  </rule>
</rsc_location>

もちろん、デフォルト(pingd)以外の属性名を設定するようにpingd デーモンを構成した場合は、attributepingdからpingdデーモンが使用するように構成した名前に変更する必要があります。

注: pingを送信したノードが停止するか、ハートビートがノードへの接続性を失った場合、あらゆるリソースが停止されてしまいます。代わりに、最高の接続性が確立された、ノードを優先するスコア の使用を検討してください。

上記のpingdのrespawnルール、またはゼロ以外の--value-multiplier係数からpingdを開始するほとんどの方法を利用できます。複数のpingノードがある場合は、リソースを実行できますが、ノードが1つの場合は実行できません。

クイックスタート - 最高の接続性が実現されたノードでリソースを実行する

pingdの適切な使用方法の1つをご紹介します。この方法では、pingd属性値がルールのスコアになります。そのため、設定する--value-multiplier は、ほかの条件に割り当てたスコアによって大きく異なります。このルールでは、全てのノードが外部への接続性を失っってしまうと、リソースが完全に停止されます。

  • ほとんどの場合、 が特定のルールのスコアとして直接設定した属性値を許可することが妥当と言えるでしょう。

    例えば、pingdの倍率を100に設定し、1つのノードへのアクセスが100に相当する場合、2つのノードは200に相当します。

    このように、ほかの全ての条件が同等である場合には、最も高いping接続が確立されたノードが選択されるのです。複数のノードのスコアが同じ場合には、次のルールに従えば、同等の重要性が与えられます。

    <rsc_location id="my_resource:connected" rsc="my_resource">
      <rule id="my_resource:connected:rule" score_attribute="pingd" >
        <expression id="my_resource:connected:expr:defined"
          attribute="pingd" operation="defined"/>
      </rule>
    </rsc_location>
    

    もちろん、デフォルト(pingd)以外の属性名を設定するようにpingdデーモンを構成した場合には、score_attributeの名前をpingdから、pingdデーモン用に構成した名前に変更する必要があります。

リソースXが2つのノードでアクティブである(その可能性がある)

Heartbeatは、起動時にマシンでアクティブなリソースを特定します。このため、Heartbeatは、リソースエージェントのモニタ操作を使用するprobeを呼び出します。

このメッセージは、通常、以下の2つの場合で表示されます。

  1. 実際に、複数のノードでリソースがアクティブとして報告されている。
    • 起動時にリソースを開始していないことを確認する。
    • Heartbeatに内部エラーが発生している可能性がある。 この場合は、問題報告のページをチェックして、報告してください。
  2. リソースがモニタ操作を適切に実行していない。
    • リソースエージェントがOCF仕様に準拠していることを確認する。
      • リソースインスタンスがアクティブな場合にのみ0を返す。
      • リソースインスタンスがアクティブでない場合には7を返す。
      • リソースインスタンスに障害がある場合にはそれ以外の数値を返す。

クラスタにリソースXを停止させるには?

バージョン2.0.5では、クラスタにリソースを停止するよう要求し、そのまま停止しておくことができます。

これを行うには、リソースのtarget_roleと呼ばれるインスタンス属性を設定してください。

これを行うには、リソース定義を以下のように設定します。

 <resources>
   <group id="cds_grp">
     <primitive class="ocf" id="cds_res" provider="heartbeat" type="cds">
       <instance_attributes id="cds-defaults">
          <attributes>
             <nvpair id="cds-role" name="target_role" value="Stopped"/>
          </attributes>
       </instance_attributes>
     </primitive>
   </group>
 </resources>

必要な操作を実行し、再度開始する準備が整うと、以下のコマンドでクラスタにリソースを開始するよう命令します。

cibadmin -M -o resources -X '<nvpair id="cds-role" value="Started"/>'

その後に再度リソースを停止させるには、以下のコマンドを実行します。

cibadmin -M -o resources -X '<nvpair id="cds-role" value="Stopped"/>'

ここに、時間ベースのフェイルバックを記載します。

平日にはリソースをフェイルオーバせず、週末にフェイルオーバするには?

date_expressionsを含むルールとともに、複数のinstance_attributessセットを使用します。

以下に、週末のみの移動を許可するIPアドレスの例を挙げます。

<primitive id="my_ip" provider="heartbeat" class="OCF" type="IPaddr">
   <instance_attributes id="my_ip:weekend_override" score="100">
     <rule id="my_ip:failover" boolean_op="and">
       <date_expression id="my_ip:days" operation="date_spec">
         <date_spec id="my_ip:days" weekdays="6-7"/>
       </date_expression>
     </rule>
     <attributes>
       <nvpair id="sat-sun-sticky" name="resource_stickiness" value="0"/>
     </attributes>
   </instance_attributes>
   <instance_attributes id="my_ip" score="10">
      <attributes>
        <nvpair id="mon-fri-sticky" name="resource_stickiness" value="INFINITY"/>
      </attributes>
   </instance_attributes>
</primitive>

scoreを使用して、セットを処理する順序を決定するよう注意してください。スコアの高いセットから先に処理されます。

さらに、週末の午前2時~5時までにフェイルオーバを制限する場合は、以下のようなリソースを構成することができます。

<primitive id="my_ip" provider="heartbeat" class="OCF" type="IPaddr">
   <instance_attributes id="my_ip:weekend_override" score="100">
     <rule id="my_ip:failover" boolean_op="and">
       <date_expression id="my_ip:days" operation="date_spec">
         <date_spec id="my_ip:days" weekdays="6-7"/>
       </date_expression>
       <date_expression id="my_ip:times" operation="date_spec">
         <date_spec id="my_ip:times" hours="2-5"/>
       </date_expression>
     </rule>
     <attributes>
       <nvpair id="sat-sun-sticky" name="resource_stickiness" value="0"/>
     </attributes>
   </instance_attributes>
   <instance_attributes id="my_ip" score="10">
      <attributes>
        <nvpair id="mon-fri-sticky" name="resource_stickiness" value="INFINITY"/>
      </attributes>
   </instance_attributes>
</primitive>

クラスタノードを置き換えるには?

各クラスタノードは、クラスタフレームワークの最初の起動時に作成され、Heartbeatからノードに割り当てられたUUIDを持っています。後継ノードでHeartbeatを起動した場合には(ホスト名とIPアドレスが元のノードと同じであっても)、元のノードとは別のUUIDが割り当てられます。その結果、後継ノードはクラスタには表示されません。以下は有用となりそうなものです。

  • 各ノードの/var/lib/heartbeat/hostcacheには、認識されたクラスタノードのUUIDが記載されたテキストファイルがあります。

  • ノードUUIDのバイナリ版(Heartbeatで使用される)は、hb_uuidに格納されています。

  • これらのファイルは手動では編集せず、hb_addnodehb_delnode、`crm_uuidなどのツールで処理します。

  • delnodecacheは、クラスタに自動的に参加し直すことができない削除済みのマシンの名前を記録するために使用されます。これは、autojoin命令を仕様どおりに動作させるためのものです。

このほかにも方法を示します。

  1. 置き換えるノードのhb_uuidのコピーを用意します。

  2. hb_uuidのコピーがなくても、Heartbeatリリースがあれば、ASCII UUIDからバイナリUUIDを作成できます(crm_uuid -w)。

  3. 置き換えたノードに新しいUUIDを割り当てます。

前提条件:

  • 古いノードは新しいノードに置き換えられる(ケーブル配線など)。
  • 後継ノードは同じホスト名を持つ。
  • 新しいノードは、Heartbeatを展開できるように構成される(/etc/ha.d/ha.cfなどの構成ファイルが配置される)。

  • • 新しいノードの電源をオンにして、Heartbeatがまだ起動していないことを確認(起動してしまうと、新しいノードに新しいUUIDが割り当てられてしまう。さらに autojoin が有効にされている場合には、新しいUUIDを使用してクラスタに参加することになり、事態をややこしくしてしまうことになる)。

以下に、2つのノード(node1node2)を持つクラスタのnode2を置き換える手順をケース別にお知らせします。

  • 古いnode2hb_uuidのコピーを用意します。

  • このファイルを新しいnode2/var/lib/heartbeatにコピーします。

  • node2でHeartbeatを起動すれば完了です。

  • ノードの再起動後にHeartbeatが自動的に起動することを確認します。
  • node2hb_uuidのコピーがなくても、Heartbeatリリースがあれば、ASCII UUIDからバイナリUUIDを作成できます(crm_uuid -w)。

注:: Heartbeatリリース2.0.8のcrm_uuidには、バイナリUUIDを作成する機能(-wオプション)はありません。以下の手順は、リリース2.1.0以降で機能します。

  1. node1で、元のnode2のUUIDをASCII形式で取得します(このUUIDは、CIBの<nodes>セクションまたは上記の/var/lib/heartbeat/hostcacheファイルから取得できます)。以下は、この例の<nodes>セクションです。node2のUUIDがa69b64a2-4de8-4d4a-b4ba-8107136eec4bであったことを示しています。

   <nodes>
       <node id="a0e71041-8cbd-449a-a04b-0da3da3d82a6" uname="node1" type="normal">
         <instance_attributes id="nodes-a0e71041-8cbd-449a-a04b-0da3da3d82a6">
           <attributes>
             <nvpair id="standby-a0e71041-8cbd-449a-a04b-0da3da3d82a6" name="standby" value="off"/>
           </attributes>
         </instance_attributes>
       </node>
       <node id="a69b64a2-4de8-4d4a-b4ba-8107136eec4b" uname="node2" type="normal">
         <instance_attributes id="nodes-a69b64a2-4de8-4d4a-b4ba-8107136eec4b">
           <attributes>
             <nvpair id="standby-a69b64a2-4de8-4d4a-b4ba-8107136eec4b" name="standby" value="on"/>
           </attributes>
         </instance_attributes>
       </node>
   <nodes/>
  1. node2で、crm_uuid -wを使用して、node2のバイナリUUIDを作成します。

注::このコマンドを呼び出したノードのhb_uuidは上書きされますので、必ず正しいノードで実行してください。

node2:/tmp# crm_uuid -w a69b64a2-4de8-4d4a-b4ba-8107136eec4b
  1. node2でHeartbeatを再起動すれば完了です。

  2. システムの再起動後にHeartbeatが自動的に起動することを確認します。

上記の手順を実行する前に、置き換えるnode2でHeartbeatが起動されると、node2に新しいUUIDが割り当てられます。node2は、元のnode2とは別のものとして認識されます。ホスト名とIPアドレスが元のノードと同じであっても、新しいノードはクラスタに統合されません。この状況から回復するには、以下の手順を実行してください。

  1. node2でHeartbeatを停止します。

  2. クラスタからnode2を削除します(以下を参照)。

  3. 上記の方法でnode2hb_uuidを作成します。

  4. 置き換えたノードに新しいUUIDを割り当てます。
  5. クラスタからnode2を削除します(以下を参照)。

  6. クラスタの全てのノードで、/var/lib/heartbeat/delhostcacheを削除します。

  7. クラスタに接続された全てのノードで、 /var/lib/heartbeat/hb_addnode node2を実行します。

  8. node2でHeartbeatを起動すれば完了です。

  9. pingdを停止した場合は起動し、再起動時にHeartbeatが自動的に起動されることを確認します。

  10. クラスタからノードを削除します。

: Heartbeatリリース2.0.8以前のpingdにはバグがあります。hb_delnodeを使用してクラスタノードを削除すると、(削除したクラスタノードが構成したpingグループの一部でなくても)pingdのCIB属性値が0にリセットされます。クラスタ構成によっては、悪影響が生じる恐れがあります。置き換え手順の実行時には、不要なリソース停止/開始を避けるため、クラスタを管理されないモードに設定してください。

  1. pingdが使用されている場合は停止します。

  2. クラスタに接続された全てのノードで、/usr/lib/heartbeat/hb_delnode node2を実行します。node2がすでにクラスタに接続されており、「アクティブなノードは削除できません」という内容のメッセージが表示された場合は、node2でHeartbeatを終了し、手順を再度実行します。

  3. hb_delnodeを実行したノードで、/var/lib/heartbeat/hostacheをチェックして、node2がクラスタから削除されたかどうかを確認します。node2の項目は含まれていないはずです。

    • 項目が残っている場合は、手順2を繰り返します。
  4. pingdが使用されていた場合は再起動します。

  5. 削除したクラスタノードが同じUUIDで再び追加されない場合は、全てのクラスタノードで再度/var/lib/heartbeat/delhostcacheを削除します。

関連情報

Heartbeat FAQ