NTT DATA TECH
💻

VMwareからKVMに移行する人のための機能比較 Vol.7 vSphere HAのアーキテクチャはKVMでどう実現するのか？

Hideaki Nakajima/中嶋 秀成
に公開
VMware
仮想化
RHEL
脱vmware
tech

背景と目的

VMwareがBroadcomに買収されたことを契機に、VMware製品のライセンス体系やコスト構造が大きく変化し、既存の仮想化基盤を継続利用するか、あるいは別の選択肢へ移行するかの検討を迫られるケースが増えています。そのような状況の中で、オープンソースであるKVMは有力な選択肢となります。
　VMwareからKVMへの移行を検討する際、CPU、メモリ、ディスク、ネットワークといったリソース面の違いに加えて、可用性（High Availability：HA）をどのように確保するかは、特に重要な検討事項となります。多くの場合、vSphere HAを標準機能として利用しており、ホスト障害が発生した場合でも、仮想マシンが自動的に別ホストで再起動される仕組みを、強く意識することなく享受してきたと考えられます。
　一方で、KVMにはvSphere HAに相当する機能が製品として一体的に提供されているわけではありません。そのため、VMwareからKVMへ移行する際には、「vSphere HAで実現されていた可用性は、KVMではどのような構成で実現すべきなのか」「同等の可用性を確保するために、どのコンポーネントをどのように組み合わせる必要があるのか」といった点を、改めて整理する必要があります。
　本記事では、VMware vSphereにおける高可用性機能であるvSphere HAに着目し、そのアーキテクチャや動作の考え方を整理したうえで、同等の可用性をKVM環境でどのように実現するのかを解説します。
単なる機能比較に留まらず、「どのレイヤーが、どの責任を担っているのか」というアーキテクチャの観点から両者を比較することで、VMwareからKVMへの移行時に考慮すべきポイントを明らかにすることを目的とします。
　なお、本記事では、仮想化基盤が主体となって仮想マシンを再起動するホストクラスタ（ホストレベルのHA）に焦点を当てて解説します。
　仮想マシン内にクラスタソフトを構成する ゲストクラスタ（OS／アプリケーションレベルのHA）については、次回の記事で改めて取り上げます。

おさらい

前回の記事「VMwareからKVMに移行する人のための機能比較 Vol.6 セキュリティ編」では、VMware vSphereと Red Hat KVMのセキュリティ機能を、機能の有無ではなく、どのレイヤーで、どのようなアーキテクチャによって実現されているかという観点から整理しました。
　VMware vSphereでは、セキュリティ機能が仮想化基盤に統合されており、利用者が細かな構成を意識せずとも一定水準の安全性を確保できる設計となっています。
　一方で Red Hat KVMでは、LinuxカーネルやQEMUなど複数の仕組みを組み合わせて同等の目的を実現しており、設計時に各コンポーネントの役割を明確に意識することが重要であることを確認しました。
　本記事で扱う可用性（HA）についても、この考え方は同様です。vSphere HAが担っている役割をアーキテクチャの観点から整理し、それをKVM環境でどのように置き換えるのかを理解することが、移行検討における重要なポイントとなります。

VMwareとKVMにおけるホストクラスタ（可用性）のアーキテクチャ概要

仮想化基盤における可用性（High Availability：HA）は、主に「どのレイヤーで障害を検知し、どのレイヤーが復旧を担うのか」という観点で整理することができます。
VMware vSphereとRed Hat KVMは、いずれもホスト障害時に仮想マシンを別のホストで再起動する構成を実現できますが、そのアーキテクチャや責任分担には大きな違いがあります。
　vSphere HAは、VMwareの標準機能として提供されており、ESXiホスト間での死活監視や仮想マシンの再起動といった処理が、あらかじめ定義されたアーキテクチャの中で自動的に行われます。
利用者は、クラスタを構成しHAを有効化することで、ホスト障害に対する基本的な可用性を比較的容易に確保できます。
　一方、KVMでは vSphere HAに相当する機能が単体で提供されているわけではありません。ホスト障害の検知や仮想マシンの再起動といった役割は、クラスタソフトウェアや管理インターフェースなど、複数のコンポーネントを組み合わせて実現します。
そのため、可用性を確保するためには、「どのコンポーネントが、どの役割を担うのか」を設計時に明確に意識する必要があります。

VMwareとKVMのホストクラスタ（可用性）におけるアーキテクチャの違い

（1）VMware（vSphere）

vSphere HAは、単一のプロセスで実現されているわけではなく、複数のコンポーネントが役割を分担することで成立しています。
通常時にはホスト間で死活監視を行い、障害発生時には自律的に仮想マシンを別ホストで再起動します。

■通常時

　① FDM（Fault Domain Manager）
　　各ESXiホスト上で動作し、ホスト間のハートビート監視と障害判定、仮想マシン再起動の制御を担うHAの中核コンポーネントです。
　② Hostd
　　ESXi上の管理エージェントであり、FDMからの指示を受けて仮想マシンの起動・停止などの操作を実行します。
　③ VMM（Virtual Machine Monitor）
　　各仮想マシンに対応する実行制御コンポーネントであり、HA による再起動後も仮想マシンの実行状態を管理します。
　④ VM Monitoring
　　vSphere HAの機能の一部であり、VMware Toolsを介してゲストOSのハートビートを監視し、無応答と判断した場合に仮想マシンを自動的にリセットします。
　⑤ VMware Tools
　　ゲストOS内で動作し、VM Monitoringに対してハートビートを送信することで仮想マシンの正常性を通知します。
　⑥ vCenter
　　HAクラスタの構成管理および設定を行う管理コンポーネントであり、通常時の障害検知や再起動処理そのものは担いません。

■フェールオーバー発生時

　ESXi#1でハードウェア障害や停止が発生した場合、クラスタ内の他ホスト上で動作している FDMがハートビートの消失を検知します。
　FDMはネットワークハートビートおよびデータストアハートビートの両方を確認し、当該ホストが復旧不能であると判断すると、影響を受けた仮想マシンを再起動対象として確定します。
　その後、マスターに選出されたFDMが再配置先ホスト（例：ESXi#2）を決定し、対象ホスト上の Hostdに対して仮想マシンの起動を指示します。
　Hostdは共有ストレージ上の仮想マシンファイルにアクセスし、VMMを生成して仮想マシンを再起動します。
　この一連の処理はvCenterに依存せず実行されるため、vCenterが停止していてもHAのフェールオーバーは動作します。
　なお、VM Monitoringが有効化されている場合は、ホスト障害ではなくゲストOSの無応答が検知された際にも、同様にHostdを介して仮想マシンの再起動が実行されます。

（2）Red Hat KVM

Red Hat KVM には、vSphere HAのような統合された高可用性機能は標準では備わっていません。
そのため、ホスト障害時に仮想マシンを別ホストで再起動させるには、別途クラスタソフトウェアをホストOS上に導入し、仮想マシンの起動・停止・監視を制御する構成を設計する必要があります。
このクラスタソフトは、ノード間の死活監視や排他制御（フェンシング）、リソースの配置管理を担い、libvirtを介して仮想マシンを制御します。
どの製品や方式を採用するかは、システムの要件や運用ポリシーに応じて選定することになります。

■通常時

　① クラスタソフト
　　ホストマシン上に導入するクラスタソフトウェアであり、ノード間の死活監視、排他制御、リソース（仮想マシン）の配置管理を担います。KVMにおけるHAの中核はこのクラスタソフトであり、ハイパーバイザー自体が可用性を提供するわけではありません。
　② スクリプト
　　クラスタソフトの仕様に基づき、仮想マシンを制御するためのスクリプトを用意する必要があります。
　　一般的には以下の処理が必要となります。
　　・起動処理（start）
　　・停止処理（stop）
　　・状態監視処理（monitor）
　　何を監視対象とするか（例：プロセス死活、応答性、ストレージ状態など）、どの条件で再起動させるかは利用者が設計する必要があります。
　③ libvirt
　　仮想マシンの起動・停止・状態取得を行う管理インターフェースであり、クラスタソフトから呼び出されることでHA制御を実行します。
　④ QEMUプロセス
　　各仮想マシンに対応して生成される実行プロセスであり、クラスタソフトによる再起動指示時に生成・終了される対象となります。

■フェールオーバー発生時

　ホストマシン#1にハードウェア障害や電源断などが発生すると、他ノード上で動作しているクラスタソフトウェアがハートビートの消失を検知します。
　クラスタソフトは、あらかじめ定義された監視方式（ネットワークハートビートや共有ストレージの状態確認など）に基づいて、当該ホストが停止しているか、あるいは隔離状態であるかを判定します。
　障害と判断された場合、まずスプリットブレインを防止するための排他制御（フェンシング）が実行されます。これは、障害ホストがストレージやリソースへ再接続して不整合を引き起こすことを防ぐための重要な処理です。
　その後、クラスタソフトは再起動対象の仮想マシンをホストマシン#2に再配置します。再配置先ノードでは、あらかじめ定義されたリソース制御ロジック（起動処理）に基づき、libvirtを介して該当仮想マシンの起動が実行されます。libvirtは新たにQEMUプロセスを生成し、そのQEMUがKVMモジュールを利用して仮想マシンを実行します。これにより、ホストマシン#1上で稼働していた仮想マシンは、ホストマシン#2上で再起動されます。
　この一連の処理は、ハイパーバイザーである KVM 自体が自律的に実行するものではなく、外部のクラスタソフトが制御主体となって実現される点が特徴です。

（3）VMwareからKVMに移行する際の主な考慮点

VMwareからKVMへ移行する際、ホストクラスタ（ホストレベルのHA）に関して最も大きな違いは、可用性機能が製品として統合されているか、設計によって構成する必要があるかという点にあります。
　vSphere HAでは、クラスタを構成しHAを有効化することで、ホスト障害時の仮想マシン再起動が自動的に実現されます。障害検知、再配置判断、再起動処理までが一体化されたアーキテクチャとして提供されており、利用者は主に設定を行う立場となります。
　一方、KVM環境では、可用性はクラスタソフトウェアを中心とした複数コンポーネントの組み合わせによって実現されます。そのため、移行時には以下の点を明確に設計する必要があります。
　・障害検知方式の設計
　　どのハートビート方式を用いるのか、ネットワーク断とノード停止をどのように判定するのかを定義する必要があります。
　・フェンシング方式の設計
　　スプリットブレインを防ぐために、どのような排他制御手段を用いるのかを明確にする必要があります。
　・仮想マシン制御方式の選定
　　libvirtを介した制御方法や、起動・停止・監視のロジックをどの粒度で設計するかを決める必要があります。
　・監視対象の定義
　　ホスト障害のみを対象とするのか、仮想マシンの状態まで監視対象に含めるのかを設計する必要があります。
　つまり、VMwareでは暗黙的に提供されていた可用性の機能が、KVMでは利用者側の設計事項として明示化されます。移行にあたっては、「同等の機能があるかどうか」ではなく、「どの機能をどこで担うのか」を整理することが重要です。

まとめ

本記事では、vSphere HAとKVM環境におけるホストクラスタの可用性アーキテクチャを比較しました。
　VMware vSphereでは、FDMを中心とした統合型のHA機能が提供されており、ホスト障害時の仮想マシン再起動が製品機能として完結しています。
　一方、Red Hat KVMでは、可用性はクラスタソフトウェアを中心に構成され、複数コンポーネントの組み合わせによって実現されます。
　両者はいずれも「ホスト障害時に仮想マシンを再起動する」という目的は同じですが、その実現方法や責任分担は大きく異なります。VMwareからKVMへ移行する際には、このアーキテクチャの違いを理解したうえで、可用性設計を明示的に行うことが重要となります。

関連記事

本シリーズ「VMwareからKVMに移行する人のための機能比較」の各回はこちらからご覧いただけます。

参考資料

①仮想化の設定および管理 | Red Hat Enterprise Linux | 9 | Red Hat Documentation
②書籍：平初・森若和雄・鶴野隆一郎・まえだこうへい『KVM徹底入門　Linuxカーネル仮想化基盤　構築ガイド』翔泳社、2013年出版
③書籍：ヴイエムウェア株式会社 Broadcom『VMware vSphere徹底入門』翔泳社、2025年出版
④書籍：ヴイエムウェア株式会社『VMware徹底入門』翔泳社、2016年出版
⑤書籍：今井悟志『VMware vSphere7 インテグレーションガイド』インプレス、2021年出版
⑥VMware vSphere 8.0

NTT DATA TECH
NTT DATA TECH

NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。

設定によりコメント欄が無効化されています