【入門】VMware HA（vSphere HA）の仕組みとは？vMotionやFTとの違いも徹底解説

2026年7月22日 2026年7月13日

frenchfly

「VMware HAという言葉を現場でよく聞くけれど、具体的にどんな仕組みでシステムを守っているの？」
「vMotionやFault Tolerance（FT）といった似たような機能と、どう使い分ければいいのか整理できない…」
インフラ環境の構築や運用に関わるエンジニアにとって、こういった疑問は非常に“あるある”です。仮想化基盤（vSphere環境）を設計する際、「システムのダウンタイム（停止時間）をいかに短くし、ビジネスへの影響を最小限に抑えるか」は最も重要なミッションであり、その中核を担うのがVMware HA（High Availability）という技術です。

この記事では、インフラ構築の最前線で培われた知見をもとに、VMware HAが動く裏側の仕組み、必須となる構成要件、そして初心者が最もつまずきやすい「vMotionやDRS、FTとの決定的な違い」を図解と表を交えて徹底解説します。

最後までお読みいただければ、障害発生時にVMware環境の裏側で何が起きているのかを論理的に理解でき、自信を持って仮想環境の運用や設計ができるようになります。

1. VMware HA（High Availability）とは？

まずは、VMware HA（高可用性）の根本的な役割と、なぜ多くの企業で標準的に導入されているのかを明確にしましょう。

1-1. 物理サーバー障害時に仮想マシンを自動復旧する仕組み

VMware HAとは、物理サーバーに突然の電源断やハードウェア故障が発生した際、その上で動いていた仮想マシンを、別の正常な物理サーバー上で「自動的に再起動」させる機能です。

※物理サーバー（ESXiホスト）：仮想マシンを動かす土台となるハードウェア機器のこと。

従来、物理サーバーが壊れた場合、管理者がデータセンターに駆けつけて配線を繋ぎ直し、予備のサーバーを手動で起動する必要がありました。しかし、VMware HAを有効にしておけば、この「障害検知」から「復旧（再起動）」までのプロセスをすべて全自動で行ってくれます。夜間や休日の予期せぬトラブルでも、管理者が即座に対応する必要がなくなります。

1-2. 最大のメリットは「OSレベルの複雑な設定が不要」なこと

システムを高可用性（HA）化する手段は他にもありますが、VMware HAの最大の魅力は「ハイパーバイザー（仮想化基盤）のレイヤーで動作する」点にあります。

通常、WindowsやLinuxのOS側でHAを組む場合、「WSFC」や「Pacemaker」といった複雑なクラスタソフトを各サーバーにインストールし、綿密な設定を行う必要があります。しかしVMware HAなら、仮想マシン内のOSやアプリケーションに特殊な設定を一切することなく、vSphereの管理画面から数クリックで全体の仮想マシンを一括保護できます。この手軽さと確実性が、圧倒的なシェアを誇る理由です。

2. 【図解】VMware HAの仕組みと復旧（フェイルオーバー）プロセス

では、VMware HAはどのようにして「サーバーが壊れた」と判断し、仮想マシンを復旧させているのでしょうか。その内部プロセスを専門用語を交えてわかりやすく解説します。

2-1. FDMエージェントと「ハートビート」による相互監視

VMware HAを有効にすると、各ESXiホストの裏側で「FDM（Fault Domain Manager）」と呼ばれる監視プログラム（エージェント）が自動的に起動します。

このFDMエージェントたちは、同じグループ（クラスタ）に属するホスト間で、1秒に1回「ハートビート（心臓の鼓動）」と呼ばれる小さな通信信号をネットワーク経由で送り合います。

常に「私は正常に動いています」「そちらも問題ないですね」と確認し合い、このハートビートが一定時間途絶えた場合に「障害が発生した」とみなす仕組みです。

2-2. ネットワーク断に備える「データストアハートビート」

ネットワークの不具合で一時的に通信が遅れただけなのに「サーバーが壊れた」と誤検知してしまうと、不必要な再起動が発生してしまいます。

これを防ぐため、VMware HAには「データストアハートビート」という二重の監視機能が備わっています。管理用のネットワーク通信が途絶えた場合でも、仮想マシンのデータが保存されている「共有ストレージ（データストア）」を経由して生存確認を行うことで、誤作動（スプリットブレイン現象）を防止し、極めて高い信頼性を担保しています。

2-3. 障害検知から再起動（フェイルオーバー）までの4ステップ

実際に障害が起きた際のプロセスは以下の通りです。

[図解：VMware HAによるフェイルオーバープロセス]

（図解内容：ホストAに雷マーク（障害発生） → ホストBがハートビート途絶を検知 → 共有ストレージ内のVMデータをホストBが引き継ぎ → ホストB上でVMが再起動するフロー図）

障害発生: 物理サーバーA（ESXiホスト）にハードウェア障害が発生し、停止する。
障害検知: クラスタ内のリーダー役である「マスターホスト」が、サーバーAからのハートビート途絶を検知する。
所有権の移行: マスターホストが、サーバーAで稼働していた仮想マシンを「どの正常なホストで起動させるか」を決定し、権限を引き継ぐ。
再起動（フェイルオーバー）: 物理サーバーBなどの上で、仮想マシンの電源が「オン」になり、業務システムが再開する。

※重要：HAはあくまで「別の場所での再起動」です。そのため、OSの起動時間分（数分程度）のダウンタイム（通信断）が必ず発生し、メモリ上で保存していなかった作業中データは失われる点に注意が必要です。

2-4. ホスト障害の3つのパターン

VMware HAは単なる電源断だけでなく、以下の3種類の状態を識別して、管理者が事前定義したルールに従い対処します。

① 障害（Failure）: サーバー本体の電源が落ちたり、マザーボード等が完全にクラッシュしたりした状態。
② 分離（Isolation）: サーバー本体は生きているが、ネットワークケーブルの断線等により、他のホストと一切通信できなくなった状態（アイソレーション状態）。
③ パーティション: ネットワークスイッチの不具合などにより、クラスタが2つ以上のグループに分裂してしまった状態。

3. 【重要】混同しがちな「vMotion」「Fault Tolerance」「DRS」との違い

初心者が最も混乱しやすいのが、vSphere環境における他の主要機能との違いです。「HAを使えばシステムを無停止で移動できる」というのは、初心者が陥りがちな致命的な勘違いです。各機能の違いを表で明確に整理しましょう。

機能名	目的・用途	ダウンタイム（停止時間）	主な利用シーンの例
VMware HA	突発的な障害対応	あり（数分・再起動）	夜間の予期せぬ物理サーバーの故障時
vMotion	計画的な移動	なし（無停止）	業務時間中のサーバーパッチ適用やメンテ時
Fault Tolerance (FT)	完全無停止の保護	なし（無停止）	1秒の停止も許されない金融・決済システム
vSphere DRS	負荷分散	なし（自動無停止移動）	特定のサーバーにアクセスが集中した時

3-1. 【HA vs vMotion】ダウンタイムの有無と目的の違い

vMotion（ブイモーション）は、稼働中の仮想マシンを「電源を入れたまま（無停止で）」別のサーバーへ移動させる機能です。これは、管理者が手動で「今から移動させます」と指示する計画的な移行（メンテナンス時など）に使われます。

対してHAは、事前予告なしの突発的な障害からの「自動復旧（再起動）」の仕組みです。ここが最も根本的な違いです。

3-2. 【HA vs Fault Tolerance】無停止要件への対応

「再起動による数分間のダウンタイムも絶対に許容できない」という厳しい要件の場合は、Fault Tolerance（FT：フォールトトレランス）を使用します。

FTは、仮想マシンの「全く同じ動きをするコピー（セカンダリ）」を別のホスト上に常に同期・待機させておき、障害時に0秒で切り替える機能です。極めて強力ですが、CPUやメモリのリソースを2倍消費し、構成の制約も厳しいため、本当に重要な一部のシステムに限定して使われます。

3-3. 【HA vs vSphere DRS】負荷分散機能との相乗効果

vSphere DRS（Distributed Resource Scheduler）は、各サーバーのCPUやメモリの負荷を常に監視し、負荷が高くなった際にvMotionを使って「自動的に仮想マシンをすいているサーバーへ移動（負荷分散）させる」機能です。

HAとDRSを組み合わせるのがエンタープライズ環境のベストプラクティスです。「障害時にはまずHAで再起動し、再起動直後に特定のサーバーに負荷が偏ったら、DRSが自動で負荷を均等にならしてくれる」という、極めて安定した自律型のインフラが完成します。

4. VMware HAを構成するための必須要件と環境設計

VMware HAを利用するためには、ただ機能をオンにすれば良いわけではなく、以下のコンポーネントと環境設計が必須となります。

4-1. 2台以上のESXiホストとvCenter Server

HAは「クラスタ」と呼ばれるグループ内で仮想マシンを移動させるため、最低でも2台以上の物理サーバー（ESXiホスト）が必要です。また、これらのホスト群を一元管理し、HA機能を有効化するための統合管理サーバー「vCenter Server」が必須となります。

4-2. データを守る「共有ストレージ」

仮想マシンの本体（OSやデータのファイル群）は、各物理サーバーに内蔵されたディスクではなく、すべてのホストから共通してアクセスできる「共有ストレージ（SAN、NAS、またはvSANなど）」に保存されていなければなりません。

物理サーバーAが壊れても、データ自体は共有ストレージに無傷で残っているため、物理サーバーBがそのデータを読み込んで安全に再起動できるのです。

4-3. 予備リソースを確保する「アドミッションコントロール」

インフラ設計において非常に重要な概念が「アドミッションコントロール（フェイルオーバー容量の確保）」です。

※アドミッションコントロール：障害時に備えて、システムが受け入れ可能なリソースの空き容量を強制的に予約する機能。

例えば、3台のサーバーのCPUやメモリを100%ギリギリまで使っていた場合、1台が壊れて残りの2台に仮想マシンを移動させようとしても、リソースがパンクして起動できません。そのため、HAでは「常に1台分のサーバーが壊れても受け入れられる余白（パーセンテージやスロット）」を意図的に確保しておく制御が自動で行われます。

5. ゲストOSやアプリ層の障害にはどう対応する？

VMware HAは「物理サーバーのハードウェア障害」には非常に強力ですが、万能ではありません。ソフトウェアレベルのトラブルにはどう対処すべきか解説します。

5-1. VMware Toolsによる「仮想マシンの監視（VM監視）」

「物理サーバー本体は正常だが、仮想マシン内のWindows OSがブルースクリーンになってフリーズした」という場合、デフォルトのHA設定では異常を検知できません。

これをカバーするために、「仮想マシンの監視（VM監視）」というオプション機能があります。仮想マシン内にインストールした「VMware Tools」からの応答が一定時間途絶えた場合、ゲストOSがハングアップしたとみなし、該当VMだけを強制再起動させることができます。

5-2. アプリケーション監視にはサードパーティ製HAソフトを併用

「OSは動いているが、その中で動いているデータベース（SQL ServerやOracle等）のサービスだけがクラッシュした」といったアプリケーションレベルの障害は、VMware HAでは検知・復旧できません。

このような詳細なソフトウェア監視が必要な場合は、「LifeKeeper」や「WSFC」などのOS内で動作するサードパーティ製のHAクラスタリングソフトを、VMware HAと併用するのが定石です。

6. まとめ：VMware HAで強固なインフラ基盤を構築しよう

この記事では、VMware HAの仕組みと、関連機能との違いについて深く解説しました。重要なポイントは以下の4点です。

VMware HAは、物理ホスト障害時に仮想マシンを別ホストで「自動再起動」する仕組み。
通信の瞬断（ダウンタイム）は必ず発生するため、vMotion（無停止の計画移行）やFault Tolerance（無停止の障害対応）とは目的が根本的に異なる。
動作の裏側では、FDMエージェントがネットワークとデータストア経由で「ハートビート」による相互監視を行っている。
必須要件として、複数台のESXiホスト、vCenter Server、共有ストレージ、そして予備リソースの設計が必要。

VMware HAを正しく設計・運用することで、管理者が夜間に叩き起こされるような突発的なシステムダウンの被害を最小限に抑え、自律的で強固なインフラ基盤を構築できます。まずはテスト環境などで、実際にESXiホストのネットワークを意図的に切断し、HAによるフェイルオーバーの動きを観察してみることを強くお勧めします。