ホストとプールの管理（プール参加、ホスト統計、ホストメンテナンス）

各プールを管理するアプライアンスの確認、別のアプライアンスへの管理の移行、古い XO Lite ボタンの片付け、ホスト統計の確認を行います。また、検証用ホストで、プール参加、メンテナンスモード、高可用性（HA）をテストします。XOA-HL アプライアンスに管理者としてログインし、許可されたホストコンソールへのアクセスを用意してください。始める前に、アプライアンスのアドレス、ホストとプールの ID、現在それらを管理しているアプライアンスを控えます。最初の接続については初回ログインとホスト接続を参照してください。

接続とプールの管理担当を確認する

1. 設定 → サーバ一覧（/#/settings/servers）を開きます。
2. 対象の接続が有効で、接続済みであることを確認します。
3. 一覧に、予定したホスト、プール、VM、ストレージが表示されることを確認します。

保存されたサーバーの項目があっても、接続が動作しているとは限りません。接続に失敗した場合は、エラーを読み、接続ガイドでアドレス、資格情報、証明書の扱いを確認します。

Issue #126 に記録されたサポート対象のルールは、あるホストまたはプールを管理する XOA は 1 台だけというものです。複数のアプライアンスが技術的には接続できますが、同じプールを複数台から管理することはサポートされません。1 台のアプライアンスで複数のプールを管理することはできます。接続を追加する前に、どのアプライアンスがプールを管理するかを決めます。同じゲストに対して、重複したバックアップスケジュールを動かさないでください。

別のアプライアンスに管理を移す

この手順では、プールの管理担当を旧アプライアンスから新しいアプライアンスに移します。プールの構成は変わりません。XO の管理を移すために、ホストをプールから外したり、VM を削除したりしないでください。

1. 作業時間を確保します。実行中の管理タスクとバックアップタスクの完了を待ちます。
2. 旧アプライアンスで、接続、スケジュール、バックアップの保存先を控えます。
3. 設定をエクスポートし、ファイルを安全に保管します。エクスポートだけでは、ジョブは移行も無効化もされません。
4. 旧アプライアンスで、このプールを対象とするスケジュールを無効にします。
5. 旧アプライアンスの 設定 → サーバ一覧 で、プールへの接続を削除します。これは新しいアプライアンスを接続する前に行います。
6. 新しいアプライアンスで、ホストまたはプールへの接続を追加します。接続された一覧と、予定した権限を確認します。
7. 設定を再作成または復元する場合は、設定のバックアップガイドにある隔離とインポートの注意事項に従います。
8. 旧アプライアンスが再接続せず、プールに対してジョブを実行していないことを確認します。
9. 新しいアプライアンスで、バックアップの保存先を確認し、隔離した環境で復旧テストを行います。その後、予定したスケジュールだけを有効にします。

確認: 新しいアプライアンスだけがプールに接続され、そのジョブを実行しています。

どちらかのアプライアンスの状態が不明な場合は、移行を中断し、接続とタスクのエラーを保存します。複数のホストを 1 つのプールにまとめる場合は、プール参加をテストするを参照してください。

XO Lite のボタンの仕組み

接続した各アプライアンスは、プールにマーカーを残します。XO Lite は、これらのマーカーから Access XOA ボタンを作ります。

• XO はプールの other-config にキー xo:clientInfo:<appliance-uuid> を書き込みます。初期設定では、接続時と、その後 6 時間ごとに書き込みます。そのたびに、48 時間より古いマーカーも削除します。
• 読み取り専用の XO 接続は、マーカーを書き込みません。
• サーバーの接続を削除すると新しい書き込みは止まりますが、既存のマーカーはすぐには消えません。
• Access XOA は、lastConnected の値が最も新しいマーカーを使います。publicUrl が設定されていればそれを開き、なければ eth0（または最初の利用可能なインターフェース）の最初のアドレスを HTTPS で開きます。
• このボタンは、アプライアンスの VM や Web サービスが動いているかを確認しません。アドレスが見つからない場合、XO Lite は代わりに Deploy XOA を表示します。
• XO Lite 自体は古いマーカーを期限切れにしません。XO が接続しなくなっても、古いボタンが残ることがあります。

古いアドレスが表示されても、2 台目のアプライアンスを展開する理由にはなりません。まず、既知のアプライアンスのアドレスと、どのアプライアンスがプールを管理しているかを確認します。正しいアプライアンスが誤ったアドレスを表示している場合は、マーカーを何度も削除するのではなく、その URL とネットワークの設定を確認します。

古い XO Lite マーカーを削除する

この作業は、旧アプライアンスの接続を削除した後にだけ行います（別のアプライアンスに管理を移すを参照）。変更するのは検出用のデータだけで、プールの構成、VM の電源状態、バックアップデータは変わりません。

1. ハイパーバイザーホストで root として、次の読み取り専用コマンドを実行します。

   xe pool-list params=uuid,name-label
   xe pool-param-get uuid='<pool-uuid>' param-name=other-config

2. プールと、古いキーの正確な名前を、管理担当の記録と照合します。

3. そのマーカーの値を控えます。

4. 必要な場合にだけ、そのキーだけを削除します。両方のプレースホルダーを置き換えてください。other-config 全体は絶対に削除しないでください。

   xe pool-param-remove uuid='<pool-uuid>' param-name=other-config param-key='xo:clientInfo:<obsolete-appliance-uuid>'

5. 読み取り専用コマンドをもう一度実行し、XO Lite を再読み込みします。

確認: キーが表示されなくなっています。キーが戻った場合は、旧アプライアンスがまだ接続しています。旧アプライアンスは、再接続時や次の書き込みのときにマーカーを書き戻します。残っている接続を探してください。

ホスト統計を読む

統計を読んでも、ホスト、その VM、ネットワーク、ストレージは何も変わりません。

始める前に

• 接続済みで実行中の、既知のホストを選びます。その ID、プール、CPU 数、メモリ容量を控えます。
• このタブには 1 台のホストだけが表示されます。プールの概要や、アプライアンス自身のシステムモニターは別のものを表示します。

1. ホストの 状態 タブ（/#/hosts/<id>/stats）を開きます。グラフを読む前に、正しいホストであることを確認します。
2. 既定の期間である 10分前まで表示 から始めます。期間、現在時刻、ブラウザーのタイムゾーン、表示された最新サンプルの時刻、タスクや接続のエラーを控えます。
3. サンプリング間隔の数回分待ち、新しいデータが届くことを確認します。グラフが画面に残っていても、収集が最新であるとは限りません。
4. 比較のために、長い期間を選びます。XO は AVERAGE サンプルを要求するため、長い期間の 1 点では短いピークが平均化されることがあります。直近の変化を調べるときは、短い期間に戻します。
5. 最初は Stacked values スイッチをオフのままにして、各系列を個別に読みます。オンにするのは比較するときだけです。オンにすると CPU とネットワークの合計系列が追加され、縦軸の範囲が変わることがあります。その都度、凡例、単位、縦軸を確認します。
6. 既知の通常の負荷で基準を記録します。次に、同じホスト、期間、設定で、既知の高負荷の時間帯と比較します。対象の系列、時刻、サンプル間隔、実際の症状を控えます。

本番環境で負荷テストを行わないでください。グラフを動かすためだけに、ゲストのサイズ変更、移行、再起動をしないでください。検証環境での負荷には、別途オペレーターの承認が必要です。

期間の名前は XO が要求する履歴の長さを示すもので、ホストがその期間すべての履歴を保持しているとは限りません。長い期間の表示は、5 秒ごとには更新されません。比較するときは、同じ期間とサンプル間隔を使います。表示された時刻を控えてください。最後の点は瞬間の値ではありません。

確認: 短い期間で、最新サンプルの時刻が進み続けています。

グラフだけでは、VM を追加する余裕、HA のフェイルオーバー、安全な移行は判断できません。メトリックの正確さ、全履歴、時計の一致、アラート、ダッシュボードとプールの合計、SR 容量、性能の診断はここでは扱いません。

検証用ホスト 2 台でプール参加をテストする

プール参加は、ホストを別のプールに移します。ホストの所属が変わり、不足しているパッチがインストールされることがあります。再構築できる検証用ホスト 2 台だけで練習してください。

始める前に

• リリースが分かっている検証用ホストを 2 台使います。参加先は、そのホストだけを含むプールのマスターです。参加元は、別のプールの唯一のホストです。単独のホストも、1 ホストのプールです。
• 両ホストへの独立したコンソールアクセス、書面の復旧・再構築計画、両方の接続を管理する XOA-HL 1 台を用意します。
• 本番プール、HA が有効なプール、実行中のゲスト、共有または接続済みのワークロード、独立したバックアップのないデータを持つホストは使わないでください。
• ネットワークとストレージの担当者と、同一ネットワーク上での参加構成、DNS と時刻の同期、別の管理用アクセス、ホストコンソールからの復旧について合意します。各ホストに似た名前のネットワークや SR があっても、共有されているとは限りません。

1. XOA-HL のブラウザーで 設定 → サーバ一覧 を開きます。2 つのプールそれぞれに、動作する接続が 1 つあることを確認します。
2. 両プールの ID、参加先マスターと参加元ホストの ID、製品ブランド、バージョン、ビルド、パッチレベル、管理アドレス、ネットワークとストレージの一覧、VM 数、実行中のジョブを控えます。参加元プールに他のホストがないことを確認します。
3. 作業時間中は、両プールのバックアップスケジュールを止めます。それぞれの独立した復旧ポイントは残します。
4. 参加先プールのページ（/#/pools/<target-pool-id>/general）を開き、マスターを確認して Add hosts を選びます。
5. 予定した参加元ホストだけを選びます。一覧には、複数のホストを含むプールのホストは表示されません。パッチの差分は双方向で表示されます。
6. どちらかのパッチ数がゼロでない、ブランドやバージョンが異なる、HA が有効、参加元の VM や SR を残す必要がある、参加経路が不明、のいずれかに当てはまる場合は キャンセル を選び、このテストの外で原因を解決します。この画面をパッチのインストールやホストの退避に使わないでください。
7. 承認された作業時間内に、画面で参加先プールと参加元ホストを正確に確認してから、OK を 1 回だけ選びます。UI は force: true を送信し、XAPI の pool.join_force を呼び出します。この確定はプールを変更します。無害な互換性チェックではありません。
8. タスクの完了を待ちます。参加に成功すると、参加元の接続は消え、参加先の接続の一覧が更新されるはずです。一時的に切断された表示になることがあります。タスクやページの更新が遅いだけで、もう一度送信しないでください。
9. 参加先の接続を更新します。参加先プールの ID とマスターが変わっていないこと、予定した 2 つのホスト ID だけが所属していること、元の参加元プールとその接続の状態を説明できることを確認します。
10. 各ホストで、ネットワークと PIF、SR の接続（PBD）、管理用アクセスを確認します。テスト用ストレージと隔離したゲストネットワークが、適切なホストから使えることを確認します。想定外の VM、重複した XOA 接続、バックアップジョブ、XO Lite のマーカーがないか調べます。

確認: 参加先プールのマスターは変わらず、予定した 2 台のホストだけが所属し、両ホストにコンソールから到達できます。

操作前後の ID、パッチ差分の数、タスクの結果、コンソールへのアクセス、各確認の結果を控えます。参加後の検証用プールが目的どおりなら、そのまま残します。Detach はホストをプールから外す操作で、別の変更です。自動的に元に戻す操作ではありません。同じプールに所属していても、移行や HA が安全であるとは限りません。

参加に失敗した場合は、タスクとエラー、コンソールの状態、両方の一覧を保存します。サーバー側では、すでにパッチの適用や参加の一部が進んでいる可能性があります。作業を止め、ホスト担当者の復旧計画に従います。もう一度強制的に結合したり、ホストを外したりしないでください。後からのホストの削除、HA、共有ストレージ、ライブマイグレーションはここでは扱いません。

検証用ホストでメンテナンスモードをテストする

メンテナンスモードは、ホストを無効にし、実行中の VM をプール内の他のホストに移します。再構築できる検証用プールだけで練習してください。このテストでは、パッチのインストールやホストの再起動は行わず、アップデート中の可用性も確認しません。アップデートについてはホストのアップデートガイドを参照してください。

始める前に

• リリースが分かっている検証用の 2 ホストプールを使います。そのネットワークと共有ストレージは、別のテストで確認済みである必要があります。本番のワークロードや、参加直後で確認していないプールは使わないでください。
• メンテナンスモードにするホストは、マスター以外にします。
• 両ホストへの独立したコンソールアクセスと管理用アクセス、プールを管理する XOA-HL 1 台、承認された復旧・再構築計画を用意します。
• 独立した復旧ポイントを確認済みのテスト用 VM を 1 台使います。参加元ホスト上の通常の VM は、この VM だけにします。その VM のストレージとゲストネットワークは、もう一方のホストでも使える必要があります。
• この VM で、プール内の移行がすでに動作している必要があります。テストしていない場合は、先にそのテストを行い、参加元ホストの状態をもう一度控えます。前提条件や移行用ネットワークが不明な場合は、作業を止めます。

1. XOA-HL で、プール、マスター、両ホストの ID、バージョンとパッチレベル、有効状態と電源状態、管理アドレス、各 VM が動いているホスト、SR の接続（PBD）、ネットワークと PIF、移行先の空き容量、実行中のタスクを控えます。
2. バックアップと復元のジョブを完了させるか、一時停止します。
3. 承認されたゲストセッションで、テスト用 VM のアプリケーションとネットワークの現在の動作を控えます。これが基準になります。
4. 参加元ホストの 詳細設定 タブ（/#/hosts/<source-host-id>/advanced）を開きます。正しいホストとプールが表示されていることを確認します。
5. Enable maintenance mode を選びます。Maintenance mode の画面には、実行中のすべての VM がプール内の他のホストに移行されると表示されます。承認された作業時間内に、OK を 1 回だけ選びます。XO は host.setMaintenanceMode を呼び出し、XAPI がホストを無効にして host.evacuate を呼び出します。
6. Bypass blocked migrations の画面が表示されたら、キャンセルします。この操作は、VM の移行ブロックを外してしまいます。
7. タスクの結果を待ってから、ホストと VM の一覧を更新します。
8. 参加元ホストが無効であること、テスト用 VM が予定した移行先で動いていること、参加元で通常の VM が動いていないこと、アプリケーションとネットワークが基準と一致することを確認します。タスク、エラー、コンソールへのアクセスを控えます。
9. 同じホストの 詳細設定 タブで、Disable maintenance mode を選びます。XO は host.enable を呼び出します。
10. ホストが有効であること、両方の管理経路と SR・ネットワークの接続が正常であること、VM がまだ移行先にあることを確認します。

確認: ホストは再び有効になり、テスト用 VM は移行先で動いたままです。メンテナンスモードを解除しても、VM は元に戻りません。移行先に残すか、テスト済みの別の移行を計画します。

メンテナンスモードの代わりに、ホストの Disable ボタン、強制再起動、緊急停止、パッチのボタンを使わないでください。バックアップスケジュールは、対象範囲と隔離した復旧ポイントを確認してから再開します。操作前後の ID、時刻、ゲストの確認結果、タスクの出力、実際のホストの状態、各 VM が動いているホストを保存します。メンテナンスモードの切り替えに成功しても、またプールに所属しているだけでも、プールがパッチや HA に対応できるとは限りません。

退避に失敗した場合は、作業を止めます。一部の VM はすでに移動しているかもしれません。退避のエラーの後、XO は通常ホストを再び有効にしますが、その処理より前に失敗すると、ホストは無効のままになることがあります。実際の有効状態と、各 VM が動いているホストを確認し、ホスト担当者の復旧計画に従います。不明な状態を解消するために、切り替えを繰り返したり、ブロックを回避したり、ホストを再起動したりしないでください。

検証用プールで HA の準備を確認する

高可用性（HA）が有効なとき、ハートビートの通信が途絶えると、HA はホストをフェンシングして再起動することがあります。再構築できる検証用プールだけでテストしてください。ここでは、意図的にホストを障害状態にすることはなく、VM の再起動も測定しません。可用性を主張する前に、保護されたテスト用 VM を使って、承認された別の障害テストを行ってください。

始める前に

• リリースが分かっていて、再構築でき、別途確認済みの検証用の 3 ホストプールを使います。通常のワークロードは置かないでください。
• プールは、プールの外で動く XOA-HL 1 台から管理します。アプライアンスとそのアクセス経路は、障害の影響範囲の外に置きます。
• 各ホストへの独立したコンソールアクセスと電源へのアクセス、承認された復旧計画を用意します。
• XCP-ng の HA 計画ガイドを読みます。このガイドは 3 ホストを推奨し、ネットワークとストレージのハートビート、容量、フェンシングの前提条件を説明しています。実際の XCP-HL ホストのリリースで、これらを確認します。
• 2 ホストの参加、移行の成功、同じ名前の SR だけでは、プールが HA に対応できるとは限りません。

1. XOA-HL で、プール、マスター、3 台のホストの正確な ID、ホストのリリース、管理アドレスと固定の管理 IP、現在の HA の状態、VM、実行中のタスク、プールを管理する唯一の XOA-HL を控えます。
2. ストレージとネットワークの担当者に、共有で書き込み可能なハートビート SR が 3 台すべてのホストに接続され、到達できることを確認してもらいます。また、管理とストレージの経路が正常で冗長であること、ホストを 1 台失った後も保護対象のゲストを動かせる容量があることも確認してもらいます。
3. 表示名だけでなく、SR の ID とその接続（PBD）を控えます。前提条件やコンソールへのアクセスが不明な場合は、ここで作業を止めます。ここまでは読み取りだけです。
4. プールの 詳細設定 タブ（/#/pools/<pool-id>/advanced）を開きます。Heartbeat SR と High Availability を確認します。
5. High Availability のスイッチをオンにして、Enabling high availability の画面を開きます。この画面には、このプールの共有で書き込み可能な SR が表示されます。候補の SR をストレージの記録と照合します。一覧に表示されていても、ホストの接続、ハートビートの信頼性、フェイルオーバーの容量は保証されません。
6. 記録や復旧計画が不十分な場合は、キャンセル を選びます。一覧に表示されているというだけで SR を選ばないでください。
7. すべての前提条件を満たし、承認された検証用の作業時間内に限り、画面をもう一度開いて、控えた SR を選び、OK を 1 回だけ選びます。XO は pool.enableHa を呼び出し、これが XAPI の pool.enable_ha を呼び出します。タスクとエラーを控えます。
8. プールを更新します。High Availability がオンであること、予定した SR が Heartbeat SR に表示されていること、3 台すべてのホストに到達できること、想定外の VM やタスクが現れていないことを確認します。
9. プールが正常で、記録を保存したら、High Availability をオフにします。Disabling high availability の画面で、OK を 1 回だけ選びます。XO は XAPI の pool.disable_ha を呼び出します。
10. HA がオフであること、すべてのホストと SR の経路が正常であること、次の作業に別途承認があることを確認します。

確認: 予定したハートビート SR で HA をそれぞれ 1 回オンとオフにし、3 台すべてのホストに到達できる状態が続いています。

HA が有効な間は、ホストとプールのパッチのボタンはブロックされます。このテスト中に、アップデートや再起動を始めないでください。操作前後のプール、ホスト、SR の ID、接続、容量の前提、タスクの出力、コンソールへのアクセス、HA の状態を保存します。

有効化に失敗した場合や、ホストがフェンシングされた場合は、コンソール、タスク、HA のログを保存し、担当者の復旧計画に従います。プールが劣化している場合は、作業を止めて担当者の障害対応手順に従います。HA のスイッチは、万能の復旧手段ではありません。不明な状態を解消するために、切り替えを繰り返したり、ホストの toolstack を再起動したり、ネットワークやストレージの障害を起こしたりしないでください。