ハマネージャ(1)

名前

ha-manager - Proxmox VE HA マネージャ

SYNOPSIS

ha-manager <COMMAND> [ARGS] [OPTIONS].

ha-manager add <sid> [OPTIONS]を追加します。

新しいHAリソースを作成します。

<sid >：<type>：<name>。: HAリソースID。これは、リソースの種類と、コロンで区切られたリソース固有の名前で構成されます（例：vm:100 / ct:100）。仮想マシンとコンテナの場合は、VMまたはCT IDをショートカットとして使用できます（例：100）。
--コメント <文字列: 説明
--グループ <文字列: HAグループの識別子。
--max_relocate <integer> (0 - N)(デフォルト = 1): サービスの起動に失敗した場合のサービス再配置の最大試行回数。
--max_restart <integer> (0 - N)(デフォルト = 1): 起動に失敗したノードでサービスを再起動する最大回数。
--状態 <無効 | 有効 | 無視 | 開始 | 停止>(デフォルト = 開始): 要求されたリソースの状態。
--タイプ <ct | vm>: リソースの種類

ha-manager config [OPTIONS］

HAリソースのリスト。

--タイプ <ct | vm>: 特定のタイプのリソースのみをリストアップ

ha-manager crm-command migrate <sid> <node>

別のノードへのリソース移行（オンライン）を要求します。

<sid >：<type>：<name>。: HAリソースID。これは、リソースの種類と、コロンで区切られたリソース固有の名前で構成されます（例：vm:100 / ct:100）。仮想マシンとコンテナの場合は、VMまたはCT IDをショートカットとして使用できます（例：100）。
<ノード>: <文字列: 対象ノード

ha-manager crm-command ノードメンテナンス無効化 <ノード

ノード保守要求の状態を変更します。

<ノード>: <文字列: クラスタ・ノード名。

ha-manager crm-commandノードメンテナンスイネーブル <ノード

ノード保守要求の状態を変更します。

<ノード>: <文字列: クラスタ・ノード名。

ha-manager crm-コマンド relocate <sid> <node

別のノードへのリソース再配置を要求します。これにより、古いノードでサービスが停止し、ターゲット・ノードでサービスが再起動します。

<sid >：<type>：<name>。: HAリソースID。これは、リソースの種類と、コロンで区切られたリソース固有の名前で構成されます（例：vm:100 / ct:100）。仮想マシンとコンテナの場合は、VMまたはCT IDをショートカットとして使用できます（例：100）。
<ノード>: <文字列: 対象ノード

ha-manager crm-コマンド停止 <sid> <タイムアウト

サービスの停止を要求します。

<sid >：<type>：<name>。: HAリソースID。これは、リソースの種類と、コロンで区切られたリソース固有の名前で構成されます（例：vm:100 / ct:100）。仮想マシンとコンテナの場合は、VMまたはCT IDをショートカットとして使用できます（例：100）。
<タイムアウト>: <整数> (0 - N): 秒単位のタイムアウト。0 に設定するとハードストップが実行されます。

ha-manager groupadd <group> --nodes <string> [OPTIONS].

新しいHAグループを作成します。

<グループ>: <文字列: HAグループの識別子。
--コメント <文字列: 説明
--nodes <node>[:<pri>]{,<node>[:<pri>]}*.: 任意の優先度を持つクラスタ・ノード名のリスト。
--nofailback <boolean>(デフォルト = 0): CRM は最も優先度の高いノードでサービスを実行しようとします。より優先度の高いノードがオンラインになると、CRM はサービスをそのノードに移行します。nofailback を有効にすると、この動作が防止されます。
--restricted <boolean>(デフォルト = 0): 制限付きグループにバインドされたリソースは、グループによって定義されたノード上でのみ実行できます。
--タイプ <グループ: グループタイプ。

ha-manager groupconfig

HAグループを取得します。

ha-manager groupremove <グループ削除

haグループの設定を削除します。

<グループ>: <文字列: HAグループの識別子。

ha-manager groupset <group> [OPTIONS].

ha グループの設定を更新します。

<グループ>: <文字列: HAグループの識別子。
--コメント <文字列: 説明
--削除 <文字列: 削除したい設定のリスト。
-ダイジェスト <文字列: 現在のコンフィギュレーション・ファイルのダイジェストが異なる場合、変更を防止します。これは同時修正を防ぐために使用できます。
--nodes <node>[:<pri>]{,<node>[:<pri>]}*.: 任意の優先度を持つクラスタ・ノード名のリスト。
--nofailback <boolean>(デフォルト = 0): CRM は最も優先度の高いノードでサービスを実行しようとします。より優先度の高いノードがオンラインになると、CRM はサービスをそのノードに移行します。nofailback を有効にすると、この動作が防止されます。
--restricted <boolean>(デフォルト = 0): 制限付きグループにバインドされたリソースは、グループによって定義されたノード上でのみ実行できます。

ha-manager help [OPTIONS］

指定したコマンドに関するヘルプを表示します。

--extra-args <array> です。: 特定のコマンドのヘルプを表示します。
--verbose <ブール値: 冗長出力フォーマット。

ha-manager migrate

ha-manager crm-command migrate のエイリアス。

HAマネージャー移転

ha-manager crm-command relocateのエイリアス。

ha-manager remove <sid>

リソース構成を削除します。

<sid >：<type>：<name>。: HAリソースID。これは、リソースの種類と、コロンで区切られたリソース固有の名前で構成されます（例：vm:100 / ct:100）。仮想マシンとコンテナの場合は、VMまたはCT IDをショートカットとして使用できます（例：100）。

ha-manager set <sid> [OPTIONS].

リソース構成を更新します。

<sid >：<type>：<name>。: HAリソースID。これは、リソースの種類と、コロンで区切られたリソース固有の名前で構成されます（例：vm:100 / ct:100）。仮想マシンとコンテナの場合は、VMまたはCT IDをショートカットとして使用できます（例：100）。
--コメント <文字列: 説明
--削除 <文字列: 削除したい設定のリスト。
-ダイジェスト <文字列: 現在のコンフィギュレーション・ファイルのダイジェストが異なる場合、変更を防止します。これは同時修正を防ぐために使用できます。
--グループ <文字列: HAグループの識別子。
--max_relocate <integer> (0 - N)(デフォルト = 1): サービスの起動に失敗した場合のサービス再配置の最大試行回数。
--max_restart <integer> (0 - N)(デフォルト = 1): 起動に失敗したノードでサービスを再起動する最大回数。
--状態 <無効 | 有効 | 無視 | 開始 | 停止>(デフォルト = 開始): 要求されたリソースの状態。

ha-manager status [OPTIONS］

HA 管理者のステータスを表示します。

--verbose <boolean>(デフォルト = 0): 詳細出力。完全なCRMとLRMステータス（JSON）を含みます。

説明

私たちの現代社会は、ネットワークを通じてコンピューターから提供される情報に大きく依存しています。モバイル機器は、人々がいつでもどこからでもネットワークにアクセスできるため、その依存度を高めています。このようなサービスを提供する場合、常に利用可能であることが非常に重要です。

可用性を数学的に定義すると、(A)、ある間隔の間にサービスが使用可能な合計時間と、(B)、間隔の長さの比率となります。これは通常、ある年の稼働時間のパーセンテージで表されます。

表1.可用性 - 年間ダウンタイム
空室率	年間ダウンタイム
99	3.65日
99.9	8.76時間
99.99	52分56秒
99.999	5.26分
99.9999	31.5秒
99.99999	3.15秒

可用性を高める方法はいくつかあります。最もエレガントな解決策は、ソフトウェアを書き換えて、複数のホストで同時に実行できるようにすることです。ソフトウェア自体がエラーを検出し、フェイルオーバーを行う方法が必要です。読み取り専用のウェブページを提供するだけなら、これは比較的簡単です。しかし、これは一般的に複雑で、ソフトウェアを自分で修正することができないため、不可能な場合もあります。以下の解決策は、ソフトウェアを修正することなく動作します：

信頼性の高い「サーバー」コンポーネントの使用

同じ機能を持つコンピュータ・コンポーネントでも、コンポーネントの品質によって信頼性の数値は異なります。ほとんどのベンダーは、信頼性の高いコンポーネントを「サーバー」コンポーネントとして販売しています。

単一障害点の排除（冗長コンポーネント）
- 無停電電源装置（UPS）の使用
- サーバーに冗長電源を使用
- ECC-RAMを使用
- 冗長ネットワークハードウェアの使用
- ローカルストレージにRAIDを使用
- VMデータに分散冗長ストレージを使用
ダウンタイムの削減
- 迅速にアクセス可能な管理者（24時間365日）
- スペアパーツの入手可能性 (Proxmox VEクラスタの他のノード)
- 自動エラー検出(ha-managerによって提供されます)
- 自動フェイルオーバー(ha-managerにより提供)

Proxmox VEのような仮想化環境では、「ハードウェア」への依存がなくなるため、高可用性の実現が非常に容易になります。また、冗長ストレージやネットワークデバイスのセットアップと使用もサポートされているため、1台のホストに障害が発生しても、クラスタ内の別のホストでそれらのサービスを開始するだけです。

さらに良いことに、Proxmox VEはha-managerと呼ばれるソフトウェアスタックを提供しています。エラーを自動的に検出し、自動フェイルオーバーを行うことができます。

Proxmox VEha-managerは"自動化された "管理者のように動作します。まず、管理すべきリソース（VM、コンテナなど）を設定します。次に、ha- managerは正しい機能を監視し、エラーが発生した場合に別のノードへのサービスフェイルオーバーを処理します。

しかし、高い可用性には代償が伴います。高品質の部品は高価であり、冗長化することでコストは少なくとも2倍になります。スペアパーツを追加すれば、コストはさらに増加します。そのため、利点を慎重に計算し、追加コストと比較する必要があります。

可用性を99%から99.9%に高めるのは比較的簡単です。しかし、99.9999%から99.99999%に可用性を高めるのは非常に難しく、コストがかかります。ha-managerの典型的なエラー検出とフェイルオーバーの時間は約2分なので、99.999%以上の可用性を得ることはできません。

要件

HAを始める前に、以下の条件を満たしている必要があります：

少なくとも3つのクラスタノード（信頼できるクォーラムを取得するため）
VMとコンテナ用の共有ストレージ
ハードウェアの冗長性
信頼性の高い「サーバー」コンポーネントを使用
ハードウェア・ウォッチドッグ - 利用できない場合は、Linuxカーネル・ソフトウェア・ウォッチドッグ（ソフトドッグ）にフォールバックします。
オプションのハードウェア・フェンス装置

リソース

ha-managerが扱う主要な管理単位をリソースと呼びます。リソース(「サービス」とも呼ばれます)はサービスID(SID)によって一意に識別されます。SIDはリソースのタイプとタイプ固有のIDで構成され、例えばvm:100のようになります。例えば、vm:100のような場合、vm(仮想マシン)タイプでIDが100のリソースとなります。

仮想マシンとコンテナです。ここでの基本的な考え方の1つは、関連するソフトウェアをこのような仮想マシンやコンテナにバンドルすることができるということで、rgmanagerのように他のサービスから1つの大きなサービスを構成する必要はありません。一般的に、HAが管理するリソースは他のリソースに依存すべきではありません。

マネジメント・タスク

このセクションでは、一般的な管理タスクの簡単な概要を説明します。最初のステップは、リソースのHAを有効にすることです。これは、リソースをHAリソース設定に追加することで行います。これはGUIを使用して行うこともできますし、単にコマンドラインツールなどを使用することもできます：

# ha-manager add vm:100

HAスタックはリソースを起動し、実行し続けようとします。要求された」リソースの状態を設定できることに注意してください。例えば、HAスタックにリソースを停止させたい場合があります：

# ha-manager set vm:100 --state stopped

また後でやり直します：

# ha-manager set vm:100 --state started

通常のVMやコンテナ管理コマンドも使用できます。コマンドは自動的にHAスタックに転送されるので

# qm start 100

は単に要求された状態をstarted に設定します。qm stop も同様で、要求された状態をstopped に設定します。

HAスタックは完全に非同期で動作し、他のクラスタメンバーと通信する必要があります。そのため、このようなアクションの結果が表示されるまで数秒かかります。

現在のHAリソース設定を表示するには

# ha-manager config vm:100 state stopped

そして、実際のHAマネージャーとリソースの状態を見ることができます：

# ha-manager status quorum OK master node1 (active, Wed Nov 23 11:07:23 2016) lrm elsa (active, Wed Nov 23 11:07:19 2016) service vm:100 (node1, started)

他のノードへのリソース移行を開始することもできます：

# ha-manager migrate vm:100 node2

これはオンラインマイグレーションを使用し、VMを実行し続けようとします。オンライン・マイグレーションでは使用済みメモリをすべてネットワーク経由で転送する必要があるため、VMを停止してから新しいノードで再起動した方が速い場合があります。これはrelocateコマンドで実行できます：

# ha-manager relocate vm:100 node2

最後に、以下のコマンドを使用して、HA構成からリソースを削除できます：

# ha-manager remove vm:100

これはリソースを開始したり停止したりするものではありません。

しかし、HA関連のタスクはすべてGUIで行えるので、コマンドラインを使う必要はまったくありません。

仕組み

このセクションでは、Proxmox VE HAマネージャの内部について詳しく説明します。関係するすべてのデーモンとその連携方法について説明します。HAを提供するために、各ノードで2つのデーモンが実行されます：

プベ・ハ・ルム: ローカル・リソース・マネージャ（LRM）は、ローカル・ノード上で実行されているサービスを制御します。現在のマネージャステータスファイルからサービスの要求状態を読み取り、それぞれのコマンドを実行します。
PVE-HA-CRM: クラスタ全体の意思決定を行うクラスタ・リソース・マネージャ（CRM）。LRMにコマンドを送信し、その結果を処理し、何か障害が発生した場合はリソースを他のノードに移動します。CRMはノードのフェンシングも行います。

LRM と CRM のロック

ロックは分散コンフィギュレーション・ファイル・システム(pmxcfs)によって提供され、各LRMが一度だけアクティブになって動作することを保証するために使用されます。LRMはロックを保持しているときのみアクションを実行するため、ロックを取得することができれば、障害が発生したノードをフェンスされたノードとしてマークすることができます。これは、現在未知の障害ノードからの干渉を受けることなく、障害となったHAサービスを安全に復旧させることができます。これはすべて、現在マネージャ・マスター・ロックを保持しているCRMによって監視されます。

サービスステート

CRM はサービス状態の列挙を使用して現在のサービス状態を記録します。この状態はGUIに表示され、ha-managerコマンドラインツールを使用して照会できます：

# ha-manager status quorum OK master elsa (active, Mon Nov 21 07:23:29 2016) lrm elsa (active, Mon Nov 21 07:23:22 2016) service ct:100 (elsa, stopped) service ct:102 (elsa, started) service vm:501 (elsa, started)

以下は可能な状態のリストです：

停止: サービスが停止しました（LRM で確認）。LRM は、停止したサービスがまだ実行中であることを検出すると、そのサービスを再度停止します。
リクエストストップ: サービスを停止してください。CRM は LRM からの確認を待ちます。
へいせん: 停止要求の保留。しかし、CRMは今のところリクエストを受け取っていません。
開始: サービスがアクティブな場合、LRM は、まだ実行中でなければ、早急にサービスを開始する必要があります。サービスが失敗し、実行中でないことが検出された場合、LRM はサービスを再起動します（「開始失敗ポリシー」を参照）。
スタート: 開始要求を保留中です。しかし、CRMはLRMからサービスが実行されていることを確認していません。
フェンス: サービス・ノードがクォーレート・クラスター・パーティション内にないため、ノードのフェンシングを待ちます（フェンシングを参照）。ノードのフェンシングが成功すると、サービスはリカバリ状態になります。
回復: サービスの復旧を待ちます。HAマネージャは、サービスが実行可能な新しいノードを見つけようとします。この検索は、オンラインノードとクォーレートノードのリストだけでなく、サービスがグループメンバーかどうか、そのようなグループがどのように制限されているかにも依存します。新しい利用可能なノードが見つかり次第、サービスはそこに移動され、最初は停止状態になります。実行するように設定されている場合は、新しいノードが実行します。
凍る: サービス状態には触れないでください。この状態はノードのリブート時やLRMデーモンの再起動時に使用します(パッケージの更新を参照)。
無視: 一時的にサービスを完全に管理したい場合に便利です．
マイグレート: 他のノードにサービス（ライブ）を移行します。
エラー: LRM エラーが原因でサービスが無効になっています。手動操作が必要です（エラー回復を参照）。
キューに入れられた: サービスは新しく追加されたもので、CRMは今のところ見ていません。
使用禁止: サービスが停止し、無効とマークされました。

ローカル・リソース・マネージャー

ローカルリソースマネージャ（pve-ha-lrm）は起動時にデーモンとして起動され、HAクラスタがクォーレートされ、クラスタ全体のロックが機能するまで待機します。

それは3つの状態です：

エージェントロック待ち: LRMは排他的ロックを待ちます。これは、サービスが設定されていない場合、アイドル状態としても使用されます。
アクティブ: LRMは排他的ロックを保持し、サービスが設定されています。
エージェントロックの紛失: LRMがロックを失いました。これは障害が発生し、クォーラムが失われたことを意味します。

LRMはアクティブな状態になると、/etc/pve/ha/manager_statusにあるマネージャ・ステータス・ファイルを読み込んで、所有するサービスに対して実行するコマンドを決定します。各コマンドに対してワーカーが起動され、これらのワーカーは並列に実行され、デフォルトでは最大4つまでに制限されています。このデフォルト設定は、データセンター設定キーmax_worker で変更することができます。ワーカープロセスは終了すると収集され、その結果は CRM のために保存されます。

最大同時作業者数調整のヒント

デフォルトの最大同時ワーカー数 4 は、特定の設定には適さない場合があります。例えば、4つのライブマイグレーションが同時に発生すると、低速なネットワークや大きな（メモリの）サービスではネットワークが混雑する可能性があります。また、最悪の場合、max_workerの値を下げてでも、輻輳が最小になるようにしてください。逆に、特にパワフルでハイエンドなセットアップを使用している場合は、max_workerの値を大きくすることもできます。

CRM が要求する各コマンドは UID で一意に識別できます。ワーカーが終了すると、その結果は処理され、LRM ステータスファイル/etc/pve/nodes/<nodename>/lrm_status に書き込まれます。そこで CRM はそれを収集し、コマンドの出力に応じたステートマシンを動作させることができます。

通常、CRM と LRM 間の各サービスのアクションは常に同期しています。これは、CRM が UID で一意にマークされた状態を要求し、LRM がそのアクションを1 回実行し、同じ UID で識別可能な結果を書き戻すことを意味します。この動作は、LRM が古いコマンドを実行しないようにするために必要です。この動作の唯一の例外は、停止コマンドとエラーコマンドです。

ログを読む

HA Stackはすべての動作をログに記録します。これはクラスタ内で何が、そしてなぜ何かが起こるのかを理解するのに役立ちます。ここでは、LRMとCRMの両方のデーモンが何を行ったかを確認することが重要です。サービスが存在するノードでjournalctl -u pve-ha-lrm を、現在のマスタであるノードで pve-ha-crm に対して同じコマンドを使用することができます。

クラスタリソースマネージャ

クラスタリソースマネージャ(pve-ha-crm)は各ノード上で起動し、一度に1つのノードのみが保持できるマネージャロックを待ちます。マネージャーロックの取得に成功したノードはCRMマスターに昇格します。

それは3つの状態です：

エージェントロック待ち: CRMは排他的ロックを待ちます。サービスが設定されていない場合、これはアイドル状態としても使用されます。
アクティブ: CRMは排他的なロックを保持し、サービスが設定されています。
エージェントロックの紛失: CRMのロックが失われました。これは障害が発生し、クォーラムが失われたことを意味します。

その主なタスクは、高可用性に設定されたサービスを管理し、常に要求された状態を強制しようとすることです。例えば、要求された状態のサービスが開始されている場合、そのサービスがまだ実行されていなければ開始されます。このように、CRM は LRM が実行する必要のあるアクションを指示します。

ノードがクラスタ・クォーラムから離脱すると、そのノードの状態は不明（unknown）に変更されます。その後、現在のCRMが故障したノードのロックを確保できれば、サービスは盗まれて別のノードで再起動されます。

クラスタ・メンバがクラスタ・クォーラムから外れたと判断すると、LRMは新しいクォーラムが形成されるのを待ちます。クォーラムがない限り、ノードはウォッチドッグをリセットできません。これにより、ウォッチドッグがタイムアウトした後（これは60秒後に発生します）、再起動がトリガされます。

HAシミュレータ

HAシミュレータを使用すると、Proxmox VE HAソリューションのすべての機能をテストし、学習することができます。

デフォルトでは、シミュレータは6つのVMを持つ実際の3ノードクラスタの動作を監視し、テストすることができます。また、VMやコンテナを追加したり削除したりすることもできます。

実際のクラスタをセットアップしたり設定したりする必要はありません。

aptでインストールします：

apt install pve-ha-simulator

他のProxmox VEパッケージがないDebianベースのシステムにもインストールできます。その場合、パッケージをダウンロードし、インストールするシステムにコピーする必要があります。ローカルファイルシステムから apt を使ってパッケージをインストールすると、必要な依存関係も解決されます。

リモートマシンでシミュレータを起動するには、現在のシステムへの X11 リダイレクトが必要です。

Linuxマシンであれば、これを使うことができます：

ssh root@<IPofPVE>-Y。

Windowsではmobaxtermで動作します。

シミュレータがインストールされた既存の Proxmox VE に接続するか、ローカルの Debian ベースのシステムに手動でインストールした後、以下のようにして試すことができます。

まず、シミュレータが現在の状態を保存し、デフォルトの設定を書き込む作業ディレクトリを作成する必要があります：

mkdir 作業中

そして、作成したディレクトリをpve-ha-simulatorにパラメータとして渡すだけです：

pve-ha-シミュレータ作業/

その後、シミュレーションしたHAサービスを開始、停止、移行したり、ノード障害時に何が起こるかをチェックすることもできます。

コンフィギュレーション

HAスタックはProxmox VE APIにうまく統合されています。例えば、ha-managerコマンドラインインタフェースや Proxmox VE ウェブインタフェースで HA を設定することができます。自動化ツールはAPIを直接使用できます。

すべてのHA設定ファイルは/etc/pve/ha/内にあるため、クラスタノードに自動的に配布され、すべてのノードが同じHA設定を共有します。

リソース

リソース設定ファイル/etc/pve/ha/resources.cfgは、ha-managerによって管理されるリソースのリストを格納します。そのリスト内のリソース設定は以下のようになります：

<type>: <name> <property> <value> ...

リソースIDは、リソースの種類から始まり、コロンで区切られたリソース固有の名前が続きます。これはすべてのha-managerコマンドでリソースを一意に識別するために使用されます(例:vm:100またはct:101)。次の行は追加のプロパティです：

コメント:<文字列

説明

group:<文字列

HAグループの識別子。

max_relocate:<整数> (0 - N)(デフォルト = 1)

サービスの起動に失敗した場合のサービス再配置の最大試行回数。

max_restart:<整数> (0 - N)(デフォルト = 1)

起動に失敗したノードでサービスを再起動する最大回数。

state:<無効 | 有効 | 無視 | 開始 | 停止>(デフォルト = 開始)

要求されたリソースの状態。CRMはこの状態を読み取り、それに従って動作します。enabledは単にstartedの別名であることに注意してください。

開始: CRM がリソースの起動を試みます．起動に成功すると，サービス状態はstartedに設定されます．ノードに障害が発生した場合，または起動に失敗した場合，リソースの復旧を試みます．すべて失敗した場合，サービス状態はエラーに設定されます．
停止: CRMはリソースを停止状態に維持しようとしますが、ノード障害時にはリソースの再配置を試みます。
使用禁止: CRMはリソースを停止状態にしようとしますが、ノードの障害時にリソースを再配置しようとはしません。この状態の主な目的はエラーリカバリーで、リソースをエラー状態から移動させる唯一の方法だからです。
無視: リソースはマネージャーステータスから削除されるため、CRMとLRMはリソースに触れなくなります。このリソースに影響する全ての{pve}APIコールが実行されます。このリソースに影響を与えるAPIコールは、HAスタックを直接バイパスして実行されます。ソースがこの状態にある間、CRMコマンドは破棄されます。リソースはノード障害時に再配置されません。

以下は、1つのVMと1つのコンテナを使った実際の例です。ご覧の通り、これらのファイルの構文は実にシンプルなので、お気に入りのエディタを使ってファイルを読んだり編集したりすることも可能です：

設定例(/etc/pve/ha/resources.cfg)

vm: 501 state started max_relocate 2 ct: 102 # 注意: 全てデフォルト設定を使用してください。

screenshot/gui-ha-manager-add-resource.png

上記のコンフィグはha-managerコマンドラインツールを使って生成されました：

# ha-manager add vm:501 --state started --max_relocate 2 # ha-manager add ct:102

グループ

screenshot/gui-ha-manager-groups-view.png

クラスタノードのグループを定義するには、HAグループ設定ファイル/etc/pve/ha/groups.cfgを使用します。リソースの実行を制限することができます。グループ設定は以下のようになります：

group: <group> nodes <node_list> <property> <value> ...

コメント:<文字列: 説明
nodes:<node>[:<pri>]{,<node>[:<pri>]}*.: クラスタ・ノード・メンバーのリストで、各ノードに優先順位を与えることができます。グループにバインドされたリソースは、最も高い優先度を持つ利用可能なノード上で実行されます。最も優先度の高いクラスのノードが多ければ、サービスはそれらのノードに分散されます。優先順位は相対的な意味しか持ちません。
nofailback:<boolean>(デフォルト = 0): CRM は最も優先度の高いノードでサービスを実行しようとします。より優先度の高いノードがオンラインになると、CRM はサービスをそのノードに移行します。nofailback を有効にすると、この動作が防止されます。
restricted:<ブール値>(デフォルト = 0): 制限付きグループにバインドされたリソースは、グループによって定義されたノード上でのみ実行できます。グループ・ノード・メンバがオンラインでない場合、リソースは停止状態になります。非制限グループのリソースは、グループ・メンバがすべてオフラインの場合、どのクラスタ・ノードでも実行できますが、グループ・メンバがオンラインになるとすぐに元に戻ります。メンバが1人だけの制限なしグループを使用して、優先ノードの動作を実装できます。

一般的な要件として、リソースは特定のノードで実行する必要があります。通常、リソースは他のノードでも実行できるので、単一のメンバーで制限のないグループを定義できます：

# ha-manager groupadd prefer_node1 --nodes node1

大規模なクラスタでは、より詳細なフェイルオーバー動作を定義することが理にかなっています。例えば、可能であればnode1で一連のサービスを実行したいとします。node1が利用できない場合は、node2とnode3で均等にサービスを実行します。これらのノードにも障害が発生した場合は、node4でサービスを実行する必要があります。これを実現するには、ノードリストを次のように設定します：

# ha-manager groupadd mygroup1 -nodes "node1:2,node2:1,node3:1,node4"

もう1つのユースケースは、リソースが特定のノード（例えばnode1とnode2）でのみ利用可能な他のリソースを使用する場合です。HAマネージャが他のノードを使用しないようにする必要があるため、当該ノードで制限グループを作成する必要があります：

# ha-manager groupadd mygroup2 -nodes "node1,node2" -restricted

上記のコマンドにより、以下のグループ設定ファイルが作成されました：

設定例(/etc/pve/ha/groups.cfg)

group: prefer_node1 nodes node1 group: mygroup1 nodes node2:1,node4,node1:2,node3:1 group: mygroup2 nodes node2,node1 restricted 1

nofailbackオプションは、管理タスク中に不要なリソースの移動を回避するのに便利です。例えば、あるサービスをグループ内で最も高い優先度を持たないノードに移行する必要がある場合、nofailbackオプションを設定することで、このサービスを即座に戻さないようにHAマネージャに指示する必要があります。

もう一つのシナリオは、あるサービスがフェンスにかけられ、別のノードにリカバリされた場合です。管理者はフェンスで保護されたノードを修復して再びオンラインにし、障害の原因を調査して再び安定して動作するかどうかを確認しようとします。nofailbackフラグを設定することで、復旧したサービスがそのままフェンスで保護されたノードに戻ることを防ぎます。

フェンシング

ノードの障害時には、フェンシングによって、誤ったノードがオフラインであることが保証されます。これは、リソースが別のノードで復旧したときに2回実行されないようにするために必要です。これがないと、別のノードでリソースを回復できないため、これは本当に重要なタスクです。

もしノードがフェンスされなければ、共有リソースにアクセスできる可能性がある未知の状態になります。これは本当に危険です！ストレージ以外の全てのネットワークが壊れたとします。パブリック・ネットワークからはアクセスできませんが、VMはまだ稼働しており、共有ストレージに書き込んでいます。

このVMを別のノードで起動すると、両方のノードから書き込みを行うため、危険な競合状態が発生します。このような状態になると、VMのデータがすべて破壊され、VM全体が使用不能になる可能性があります。また、ストレージが複数マウントから保護されている場合、リカバリに失敗する可能性もあります。

Proxmox VEフェンスの仕組み

例えば、ノードからの電力を遮断したり、通信を完全に無効にするフェンス・デバイスなどです。これらは非常に高価であることが多く、システムにさらに重要なコンポーネントを追加することになります。

そのため、外部ハードウェアを追加する必要のない、よりシンプルなフェンシング方法を統合したいと考えました。これにはウォッチドッグ・タイマーを使用します。

可能なフェンスの方法

外部電源スイッチ
スイッチ上のネットワーク・トラフィックを完全に無効にすることで、ノードを隔離します。
ウォッチドッグタイマーを使用したセルフフェンシング

ウォッチドッグ・タイマーは、マイクロコントローラーが登場した当初から、重要で信頼性の高いシステムで広く使用されてきました。ウォッチドッグ・タイマは、多くの場合、コンピュータの誤動作を検出して回復するために使用される、シンプルで独立した集積回路です。

通常動作中、ha-managerは定期的にウォッチドッグ・タイマーをリセットし、タイマーが経過しないようにします。ハードウェア障害またはプログラムエラーにより、コンピューターがウォッチドッグのリセットに失敗した場合、タイマーは経過し、サーバー全体のリセット（再起動）がトリガーされます。

最近のサーバー・マザーボードには、このようなハードウェア・ウォッチドッグが搭載されていることがよくありますが、これらを設定する必要があります。ウォッチドッグが利用できない、または設定されていない場合、Linuxカーネルのソフトドッグにフォールバックします。それでも信頼性はありますが、サーバーのハードウェアから独立していないため、ハードウェア・ウォッチドッグよりも信頼性は低くなります。

ハードウェア・ウォッチドッグの設定

デフォルトでは、すべてのハードウェア・ウォッチドッグ・モジュールはセキュリティ上の理由でブロックされています。正しく初期化されないと、装填された銃のようになります。ハードウェア・ウォッチドッグを有効にするには、例えば/etc/default/pve-ha-manager でロードするモジュールを指定する必要があります：

# ウォッチドッグモジュールの選択（デフォルトはソフトドッグ） WATCHDOG_MODULE=iTCO_wdt

このコンフィギュレーションはwatchdog-muxサービスによって読み取られ、起動時に指定されたモジュールがロードされます。

リカバー・フェンス・サービス

ノードに障害が発生し、そのフェンシングが成功した後、CRMは障害が発生したノードからオンライン状態のノードにサービスを移動しようとします。

サービスが回復されるノードの選択は、リソースグループの設定、現在アクティブなノードのリスト、およびそれぞれのアクティブなサービス数に影響されます。

CRMはまず、（グループ設定から）ユーザーが選択したノードと利用可能なノードの交点からセットを構築します。次に、最も優先順位の高いノードのサブセットを選択し、最後に最もアクティブなサービス数が少ないノードを選択します。これにより、ノードが過負荷になる可能性を最小限に抑えます。

ノード障害が発生すると、CRMは残りのノードにサービスを分散します。これにより、これらのノードのサービス数が増加し、特に小規模なクラスタでは高負荷になる可能性があります。このような最悪のケースに対応できるようにクラスタを設計してください。

スタート失敗ポリシー

起動失敗ポリシーは、あるノードでサービスが1回以上起動に失敗した場合に有効になります。このポリシーの目的は、特定のノードで共有リソースが一時的に利用できなくなるのを回避することです。例えば、共有ストレージがネットワークの問題などで利用できないが、他のノードではまだ利用できる場合、リロケート・ポリシーによってサービスを開始することができます。

各リソースに固有の設定を行うことができる2つのサービス開始回復ポリシー設定があります。

最大再起動: 実際のノードで障害が発生したサービスの再起動を試行する最大回数。デフォルトは1回です。
max_relocate: サービスを別のノードに再配置する最大試行回数。実際のノードでmax_restart値を超えた場合にのみ再配置が行われます。デフォルトは1です。

再配置カウントの状態は、サービスの起動が少なくとも1回成功した場合にのみゼロにリセットされます。つまり、エラーが修正されずにサービスが再スタートした場合、再スタートポリシーだけが繰り返されます。

エラーリカバリー

すべての試行の後、サービスの状態を回復できなかった場合、エラー状態になります。この状態では、サービスはもうHAスタックに接続されません。唯一の方法は、サービスを無効にすることです：

# ha-manager set vm:100 --state disabled

これはウェブ・インターフェイスでも可能です。

エラー状態から回復するには、次のようにしてください：

リソースを安全で一貫性のある状態に戻す（例：サービスを停止できなかった場合、そのプロセスを終了させる
リソースを無効にしてエラーフラグを外します。
不具合の原因となったエラーを修正
すべてのエラーを修正した後、サービスの再開をリクエストすることができます。

パッケージ・アップデート

ha-managerをアップデートする際は、様々な理由から一度に行わず、1ノードずつ行ってください。第一に、私たちはソフトウェアを徹底的にテストしていますが、あなたの特定のセットアップに影響するバグを完全に排除することはできません。ノードを1つずつアップデートし、アップデートを終えた後に各ノードの機能をチェックすることは、最終的な問題から回復するのに役立ちます。

また、Proxmox VE HAスタックは、クラスタとローカルリソースマネージャの間でアクションを実行するためにリクエストアクノリッジプロトコルを使用します。再起動のために、LRMはCRMにすべてのサービスをフリーズする要求を行います。これにより、LRMが再起動する短時間の間、クラスタがこれらのサービスに触れることを防ぎます。その後、LRMは再起動中にウォッチドッグを安全に閉じることができます。このような再起動は通常パッケージの更新中に発生し、すでに述べたように、LRMからの要求を確認するためにアクティブなマスターCRMが必要です。そうでない場合、更新処理に時間がかかり過ぎ、最悪の場合、ウォッチドッグがリセットされる可能性があります。

ノードメンテナンス

ハードウェアの交換や新しいカーネルイメージのインストールなど、ノードのメンテナンスが必要になることがあります。これはHAスタックが使用されている間にも当てはまります。

HAスタックは主に2種類のメンテナンスをサポートします：

一般的なシャットダウンまたはリブートについては、シャットダウンポリシーを参照してください。
シャットダウンや再起動を必要としないメンテナンス、または1回の再起動だけで自動的にオフにならないメンテナンスの場合、手動メンテナンスモードを有効にすることができます。

メンテナンス・モード

手動メンテナンスモードを使用すると、ノードをHA動作不可としてマークし、HAによって管理されるすべてのサービスが他のノードに移行するように促すことができます。

これらの移行のターゲットノードは、現在利用可能な他のノードから選択され、HAグループ構成と設定されたクラスタリソーススケジューラ（CRS）モードによって決定されます。各移行の間、元のノードはHAマネージャの状態に記録されるため、メンテナンスモードが無効になってノードがオンラインに戻ると、サービスは再び自動的に移行されます。

現在、ha-manager CLIツールを使用してメンテナンスモードを有効または無効にすることができます。

ノードのメンテナンスモードの有効化

# ha-manager crm-command node-maintenance enable NODENAME

これはCRMコマンドをキューに入れ、マネージャがこのコマンドを処理すると、マネージャのステータスにメンテナンスモードのリクエストが記録されます。これにより、メンテナンスモードにしたいノードだけでなく、どのノードでもコマンドを送信することができます。

各ノードの LRM がコマンドを拾うと、それ自身を利用不可としてマークしますが、すべてのマイグレーションコマンドを処理します。つまり、LRM のセルフフェンシング・ウォッチドッグは、すべてのアクティブなサービスが移動し、すべての実行中のワーカーが終了するまでアクティブなままです。

LRMのステータスがメンテナンスモードと表示されるのは、LRMが要求されたステータスを選択した時点であり、すべてのサービスが移動した時点ではありません。今のところ、ノード上にアクティブなHAサービスが残っていないか確認するか、次のようなログ行を監視することができます：pve-ha-lrm[PID]: watchdog closed (disabled)ノードがいつメンテナンスモードへの移行を完了したかを知るには、次のようなログ行を監視します。

手動メンテナンスモードはノードのリブート時には自動的に削除されませんが、ha-managerCLIを使用して手動で解除するか、manager-statusを手動でクリアした場合にのみ削除されます。

ノードのメンテナンスモードの無効化

# ha-manager crm-command node-maintenance disable NODENAME

上記のha-managerCLI コマンドを使用すると、CRM コマンドがキューに入れられ、それが処理されると、それぞれの LRM ノードが再び使用可能になります。

メンテナンスモードを解除すると、メンテナンスモードを有効にしたときにノード上にあったサービスはすべて元に戻ります。

シャットダウン・ポリシー

以下に、ノードのシャットダウンに関するさまざまなHAポリシーの説明を示します。現在のところ、後方互換性のために条件付きがデフォルトになっています。ユーザによっては、Migrateの方がより期待通りの動作をすると感じるかもしれません。

シャットダウン・ポリシーは、WebUI（Datacenter→Options→HA Settings）で設定するか、datacenter.cfgで直接設定することができます：

ha: shutdown_policy=<値>です。

移行

ローカルリソースマネージャ(LRM)がシャットダウン要求を受け取り、このポリシーが有効になると、現在のHAマネージャが利用できないようにマークします。これにより、現在このノードに配置されているすべてのHAサービスがマイグレーションされます。 LRMは、実行中のサービスがすべて移動されるまで、シャットダウン処理を遅らせようとします。しかし、これは実行中のサービスが別のノードに移行できることを想定しています。つまり、ハードウェア・パススルーを使用するなどして、サービスがローカルにバインドされていない必要があります。グループメンバーでないノードは、グループメンバーが利用できない場合、実行可能なターゲットとみなされるため、一部のノードだけを選択してHAグループを利用する場合でも、このポリシーを使用することができます。しかし，グループを制限ノードとしてマークすることで，HAマネージャは選択されたノードセット以外ではサービスを実行できないことを伝えます．これらのノードがすべて利用できない場合、手動で介入するまでシャットダウンは停止します。シャットダウンされたノードが再びオンラインに戻ると、その間にまだ手動で移行されていない場合、以前に置き換えられたサービスは元に戻ります。

ウォッチドッグは、シャットダウン時の移行プロセス中もアクティブです。ノードがクォーラムを失った場合、フェンスされ、サービスは回復します。

現在メンテナンス中のノードで（以前に停止した）サービスを開始する場合、サービスを移動して別の利用可能なノードで開始できるように、そのノードをフェンスで囲む必要があります。

フェイルオーバー

このモードでは、現在のノードがすぐにオンラインにならない場合、すべてのサービスが停止されますが、リカバリも行われます。一度に多くのノードがパワーオフされるとVMのライブマイグレーションが不可能になる可能性がありますが、それでもHAサービスを確実にリカバリしてできるだけ早く再スタートさせたい場合など、クラスタ規模でメンテナンスを行う場合に便利です。

フリーズ

このモードでは、すべてのサービスが停止してフリーズし、現在のノードが再びオンラインになるまで復旧しないようにします。

条件付き

条件付きシャットダウンポリシーは、シャットダウンまたは再起動が要求されたかどうかを自動的に検出し、それに応じて動作を変更します。

シャットダウン

シャットダウン（電源オフ）は通常、ノードがしばらくの間停止する予定がある場合に実行されます。この場合、LRMはすべての管理サービスを停止します。これは、その後、他のノードがこれらのサービスを引き継ぐことを意味します。

最近のハードウェアは大量のメモリ（RAM）を搭載しています。そのため、すべてのリソースを停止してから再起動し、すべてのRAMのオンラインマイグレーションを回避します。オンライン・マイグレーションを使用したい場合は、ノードをシャットダウンする前に手動でそれを起動する必要があります。

再起動

ノードの再起動はrebootコマンドで行います。これは通常、新しいカーネルをインストールした後に行われます。これは「シャットダウン」とは異なることに注意してください。

LRM は CRM に再起動を指示し、CRM がすべてのリソースをフリーズ状態にするまで待ちます（Package Updates と同じメカニズム）。これにより、これらのリソースが他のノードに移動することを防ぎます。代わりに、CRM は同じノード上で再起動後にリソースを起動します。

手動リソース移動

最後になりますが、ノードをシャットダウンまたは再起動する前に、手動でリソースを他のノードに移動することもできます。オンラインマイグレーションを使うかどうかは自分で決めることができます。

pve-ha-crm、pve-ha-lrm、watchdog-muxのようなサービスを停止しないでください。これらはウォッチドッグを管理・使用しているため、ノードのリブートやリセットを引き起こす可能性があります。

クラスタ・リソース・スケジューリング

クラスタリソーススケジューラ（CRS）モードは、シャットダウンポリシーによってトリガされる移行と同様に、サービスの復旧のためにHAがノードを選択する方法を制御します。デフォルトのモードはbasicですが、Web UI(Datacenter→Options)、またはdatacenter.cfgで直接変更できます：

crs: ha=静的

screenshot/gui-datacenter-options-crs.png

変更は次の監督ラウンドから有効になります（数秒後）。

復旧や移行が必要な各サービスに対して、スケジューラはそのサービスのグループ内で最も優先順位の高いノードの中から最適なノードを繰り返し選択します。

将来的には、（静的および動的な）負荷分散のモードを追加する予定です。

基本的なスケジューラー

各ノードのアクティブなHAサービスの数は、リカバリノードを選択するために使用されます。現在、HA管理されていないサービスはカウントされません。

静的負荷スケジューラ

静的モードはまだ技術プレビューです。

各ノードのHAサービスからの静的な利用情報は、回復ノードを選択するために使用されます。HAで管理されていないサービスの利用は現在のところ考慮されていません。

この選択のために、各ノードは、関連するゲスト構成からのCPUとメモリ使用量を使用して、そのノード上でサービスがすでに実行されているかのように順番に検討されます。次に、そのような各選択肢について、すべてのノードの CPU とメモリの使用量が考慮されます。CPUとメモリの両方について、ノードの中で最も高い使用量（理想的にはどのノードもオーバーコミットされるべきではないため、より重み付けされます）と、すべてのノードの平均使用量（よりコミット率の高いノードがすでにある場合に区別できるようにするため）が考慮されます。

サービスの数が多ければ多いほど、可能な組み合わせも増えるため、数千ものHAマネージドサービスをお持ちの場合は、現在のところ使用することはお勧めできません。

CRS スケジューリングポイント

CRSアルゴリズムはラウンドごとにすべてのサービスに適用されるわけではありません。そのため、Proxmox VE HAマネージャはサービスを現在のノードに維持することを推奨しています。

CRSは現在、次のようなスケジューリングポイントで使用されています：

サービス復旧（常時アクティブ）。アクティブなHAサービスを持つノードが故障した場合、そのノードの全てのサービスを他のノードに復旧させる必要があります。CRSアルゴリズムは、残りのノードにバランスよく復旧させるために使用されます。
HAグループ設定の変更（常にアクティブ）あるノードがグループから削除されたり、そのノードの優先度が下がったりすると、HAスタックはCRSアルゴリズムを使って、適応された優先度制約に合う、そのグループ内のHAサービスの新しいターゲットノードを見つけます。
HAサービス停止→開始移行（オプトイン）。停止しているサービスを開始するように要求することは、CRSアルゴリズムに従って最適なノードをチェックする良い機会です。これは、データセンター設定でha-rebalance-on-startCRS オプションを設定することで有効にできます。このオプションはWeb UIのDatacenter→Options→Cluster Resource Schedulingでも変更できます。

著作権および免責事項

このプログラムはフリー・ソフトウェアです。あなたは、Free Software Foundationによって発行されたGNU Affero General Public Licenseのバージョン3、またはそれ以降のバージョンのいずれかに従って、このプログラムを再配布したり、変更したりすることができます。

このプログラムは有用であることを期待して配布されていますが、商品性や特定の目的への適合性についての暗黙の保証もなく、いかなる保証もありません。詳細はGNU Affero General Public Licenseをご覧ください。

あなたはこのプログラムとともにGNU Affero General Public Licenseのコピーを受け取っているはずです。そうでない場合は、https://www.gnu.org/licenses/をご覧ください。