Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
vCenter上の「vSphere HA用に再構成」がグレーアウトして操作不可になる原因は、ほぼ例外なくホストの現在の状態とvCenterが当該操作を許可するための要件が不整合であることです。vCenterはこのメニュー項目を表示する前に厳格な条件を設けており、いずれかの条件を満たしていない場合、該当項目は無効化されたままとなります。
本ガイドでは、このグレーアウト現象を引き起こす既知のすべての要因と各要因に対する正確な解決策を解説しており、vSphere 6、7、8すべてのバージョンに対応しています。
vSphere HA用に再構成はvCenterのホスト単位の操作で、対象のESXiホスト上にFault Domain Manager(FDM)エージェントを再インストール・再初期化する機能です。FDMエージェントはホスト状態の通知やHAクラスタ内の仮想マシン再起動の調整を担うコンポーネントです。
本機能は通常、HAエージェントのエラー発生時、古いエージェント情報が残った状態でホストをメンテナンスモードから解除した場合、またはFDM VIBのインストールに失敗した際に使用します。
vCenterは特定のホスト状態条件をすべて満たした場合のみこの機能を有効化します。以下のセクションで各条件と対応策を記載します。
この項目が無効化されるのは、vCenterがホストまたはクラスタがHA操作を実行可能な状態ではないと検知しているためです。代表的な8つの原因と解決手順を記載します。
クラスタレベルでHAが無効になっている場合、ホスト単位の再構成オプション自体が非表示となります。クラスタ側でHAを有効化しない限り、ホスト側で実行する操作は存在しません。
解決策:

ホストがメンテナンスモードに移行すると、vCenterは同ホスト上のFDMエージェントを無効化します。ホストが通常稼働状態に戻るまで再構成オプションは利用できません。
解決策:
vCenterと通信できないホストに対して管理コマンドを送信することはできません。「切断」「応答なし」のいずれの状態でも当該オプションはブロックされます。
解決策:

すべてのvCenterロールにホスト単位のHAタスク実行に必要な権限が付与されているわけではありません。ログインアカウントが読み取り専用または制限付きアクセスの場合、ホストの状態に関わらずオプションが常にグレーアウトします。
解決策:
こちらは障害ではありません。FDMエージェントが正しくインストール・稼働している場合、修正すべき事項が存在しないためvCenterは再構成オプションを無効化します。
解決策:
vCenterはホスト構成タスクを順次処理します。コンプライアンスチェック、ストレージ再スキャン、修復ジョブなどが実行中の場合、当該タスク完了までHA再構成がブロックされます。
解決策:
vim-cmd vimsvc/task_listを実行し、ホストに登録されているすべてのタスクを確認します。vim-cmd vimsvc/task_info <taskID>を実行して現在の状態を確認します。vim-cmd vimsvc/task_cancel <taskID>でキャンセル後、HA再構成を再試行します。vSphere Lifecycle Manager(vLCM)で管理するvSphere 8環境では、FDMエージェントはクラスタイメージに含まれるコンポーネントとして配布されます。ホストがイメージコンプライアンスチェックに不合格となるとFDM VIBをインストールできず、HA再構成がブロックされます。
解決策:
/var/log/esxupdate.logを確認し、VIBインストールエラーの有無を調査します。settingsd再起動手順は特定の特殊ケースに限った対処法であり、標準的な修復手順ではありません。vSphere Essentialsエディションには高可用性(HA)機能が搭載されていません。ESXiホストにEssentialsライセンスを割り当てている場合、クラスタ設定に関わらずすべてのHA制御項目が常に無効化されます。
解決策:
グレーアウトの問題を解決し再構成を実行すると、別の課題が発生する場合があります。タスク実行直後にvCenterに誤った仮想マシンフェイルオーバーアラートが出力される現象です。
この現象はHAマスターホストに対して再構成を実行した際に発生します。マスターホストのFDMエージェントが再起動のため停止すると、スレーブホストは通信断を検知し、新たなマスターの選出を開始します。この切り替え期間中、スレーブ側はマスター配下の仮想マシンが障害停止したと誤判定し、「vSphere HA仮想マシンフェイルオーバー失敗」の誤アラートを出力します。
再構成を実行する前に検知タイムアウト値を延長し、他のホストが実際の障害ではなくマスター切り替え中であると認識する猶予を確保します。
das.config.fdm.unknownStateMonitorPeriodを追加し、値を30に設定します。
この設定によりデフォルトのタイムアウトが10秒から30秒に延長され、クラスタが再構成処理を完了する時間的余裕が生まれ、誤アラートの発生を抑制できます。
再構成オプションが正常に利用可能になった後は、2つの作業を実施します。修正が正しく反映されたことの確認と、同様のトラブルの再発を防ぐ運用ルールの導入です。
FDMエージェントが正常な状態に復旧したことを確認するため、以下の項目を点検します。
/var/log/fdm.logを確認し、FDMエージェントがクラスタに参加した正常な初期化ログが出力されていること。定常的な運用ルールを設けることで、HA再構成関連のトラブルを大幅に抑制できます。
vSphere HAは基本的な障害対策として有効ですが、FDMエージェントに依存するという根本的な課題が存在します。本ガイドで紹介した通り、古いエージェント情報、VIBインストール失敗、ホスト設定不備などが発生すると、手動で障害を解消するまでクラスタの保護機能が失われ、その間仮想マシンが無防備な状態となります。
Info2Softのi2AvailabilityはVMware標準のHA機構と独立した保護レイヤーを追加します。バイト単位のリアルタイムレプリケーションにより本番環境と災害復旧環境のデータを常時同期するため、ハイパーバイザー側に障害が発生した場合でも正常な待機環境が常時利用可能です。
リアルタイムレプリケーションに加え、定時バックアップと特定時点復元機能を必要とする環境向けにはi2Backupが用意されており、単一コンソールから物理サーバー、仮想マシン、データベースのバックアップを統合管理できます。i2Availabilityとi2Backupを組み合わせることで、単一プラットフォーム標準HAに依存しない多層的なデータ保護体制を構築できます。
下記デモ動画でi2Availabilityの動作を確認できます。60日間の無料トライアルで自身の環境にて動作検証を実施可能です。
Q1:「vSphere HA用に再構成」がクリックできない原因は?
ホストまたは上位クラスタがHA操作を実行可能な状態にないことが原因です。代表的な要因はクラスタのvSphere HA無効化、ホストのメンテナンスモード、vCenterとホスト間の管理ネットワーク切断の3点です。
Q2:vSphere HA再構成を手動で実行する方法は?
vSphere Client上のESXiホストを右クリックし、「vSphere HA用に再構成」を選択します。オプションがグレーアウトしている場合は、クラスタのHA有効化、ホストの完全な接続・通常稼働状態を確認した上で再試行してください。
Q3:HAを一度無効化・有効化すると、グレーアウトした再構成オプションは復活する?
多くのケースで復旧します。クラスタレベルで「vSphere HAをオンにする」の切り替えを実施すると、vCenterがクラスタ内全ホストにFDMエージェントを再配布します。ただし実行中はクラスタ内のすべての仮想マシンが一時的にHA保護対象外となるため、慎重に実施してください。
Q4:vSphere HAのFDMエージェントとは何か?
Fault Domain Manager(FDM)エージェントはホストがvSphere HAクラスタに参加する際に各ESXiホストにインストールされるコンポーネントです。ホスト稼働状態の通知、仮想マシンのハートビート監視、ホスト障害検知時の仮想マシン自動再起動調整を担います。
「vSphere HA用に再構成」がグレーアウトする要因は大きく8種類に分類されます。クラスタのHA無効化、メンテナンスモード、ホスト通信障害、権限不足、エージェント正常稼働、実行中のタスク、vSphere 8のVIBコンプライアンス違反、HA非対応のEssentialsライセンスです。各要因を順番に確認することで、大半の場合簡単に問題を解消できます。
FDMエージェントが正常状態に復旧した後は、ホストの「概要」タブとクラスタの「監視」>「vSphere HA」タブで状態を確認し、問題解決と判断します。またHAマスターホストに対して再構成を実施する場合は事前にdas.config.fdm.unknownStateMonitorPeriodを30秒に設定し、誤ったフェイルオーバーアラートの発生を回避してください。
VMware標準のFDMエージェントへの依存が課題となる環境には、Info2softのi2Availabilityが最適です。ハイパーバイザー側のエージェント状態に左右されない独立したレプリケーション・フェイルオーバーレイヤーにより、仮想マシンの保護を維持します。