Skip to content

MS_HyperVHighAvailability

Jump to bottom
nishi_74322014 edited this page Aug 31, 2026 · 1 revision

Hyper-V 高可用性オプション

概要

  • 物理サーバの状態を監視し、仮想マシンの動作に関わる障害を検知する。

  • 障害の発生を検知すると、

    • 障害のある物理サーバ上で動作していた仮想マシンを停止し、
    • 他の物理サーバ上のサーバ仮想化環境で再起動する

補足（本ページの構成）: 高可用性は
ゲスト・レベル（仮想マシンの中で冗長化する）と
ホスト・レベル（仮想マシンを載せる基盤で冗長化する）の
2 段階に分けて考える、というのが本ページの主張である。
両者は目的が異なり、
ゲスト・レベルはアプリケーションの継続性、
ホスト・レベルは仮想マシンの継続性を守る。
ホスト・レベルだけでは「仮想マシンは別ホストで再起動されるが、
その間アプリケーションは止まる」という点に注意。

ゲスト・レベル

ゲスト・レベルの高可用性オプションの選択肢（以下のいずれかを選択）。

ゲスト・クラスタ

概要

ゲスト OS 同士のステートフルな Active-Passive フェイル・オーバ・クラスタ

サポート

  • Windows 2003 の MSCS はサポート対象外

  • ゲスト OS 内は、ハードウェアが直接見えないので、
    TCP/IP で見える iSCSI だけが、共有ストレージとしてサポート。

  • 共有ストレージは iSCSI、SAN（2012 から）に対応

補足（現在は共有 VHDX が使える）: 本節が述べている
「ゲスト OS からはハードウェアが見えないので iSCSI しか選べない」という制約は、
Windows Server 2012 R2 の共有 VHDX、
および 2016 以降の VHD セットによって緩和されている。
これらを使うと、ゲスト OS 側にストレージ ネットワークの構成を持ち込まずに
共有ディスクを提供できるため、ゲスト・クラスタの構築が大幅に簡単になる。

考慮点

  • ホスト・クラスタとの併用は可能だが、複雑であるため推奨しない。
  • ゲスト・クラスタの全ノードが異なるホスト上で稼働する配置を維持する必要がある（？）。

補足（この「？」への回答）: 著者が疑問符を付けている点は、
必要であるが、手動で維持する必要はない。
フェイル・オーバー クラスタリングの
非対応 VM（Anti-Affinity）設定（AntiAffinityClassNames）を使うと、
同じクラスに属する仮想マシンを
可能な限り異なるホストへ配置するようクラスタ側が制御してくれる。
これを設定しないと、ゲスト・クラスタの全ノードが同一ホストに集まり、
ホスト 1 台の障害でゲスト・クラスタごと落ちるという、
冗長化した意味がなくなる事態が起こり得る。

参考

ゲストNLB

概要

  • ゲスト OS 同士の NLB による、ステートレスな Active-Active 負荷分散

レプリカ（2012から）

概要

  • ゲスト OS 同士のステートフルな Active-Passive レプリケーション構成クラスタ

    • プライマリ サイトにある Hyper-V ホストからレプリカ サイトにある
      別の Hyper-V ホストに Hyper-V 仮想マシンをレプリケートする。

    • 障害が発生した場合、レプリカ サイトにあるレプリケートされた
      仮想マシンを起動して、業務を元の状態にすばやく戻すことができる。

  • レプリケーション

    • HTTP プロトコルを使用し WAN 経由でレプリカ サーバーにレプリケート可能
    • Kerberos 認証と証明書ベースの認証がサポート（オプションで、暗号化もサポート）

  • フェイル・オーバー クラスタリングと密接に？統合

詳細

Windows Server 8 の Hyper-V Replica Broker

移行メモ: 「Windows Server 8」は Windows Server 2012 の開発コード名。

  • レプリカは SQL Server の DB ミラーリングと似ている。

    1. プライマリからレプリカへ VM 実行中も定期的（最短 5 分）に vhd の差分をコピーする。
    2. プライマリが故障するとレプリカへフェイル・オーバーする。
    3. これにより（大方）最新の状態でレプリカで処理を継続できる。
    4. 故障による切り替え時は、プライマリは捨てられるため新規レプリカの追加・全転送が必要。
    5. 手動の切り替え時は、プライマリとレプリカの役割が入れ替わる。

  • フェイル・オーバ・クラスタとは、以下の点で関連がある。

    • レプリカは、転送が最短 5 分なので、MSFC と併用で、ホストの障害リカバリを迅速にできる。
    • 以下、MSFC + レプリカの構成例。
      • メインサイトに MSFC + プライマリを配置。
      • サブサイト（DR サイト）に MSFC + レプリカを配置。
      • MSFC 化した各サイトのフロントに broker を配置し
        転送先のレプリカ（Active ノード）を追跡する必要がある。
      • このため、片方のサイトだけ MSFC と併用する方式も可能。

補足（レプリカは「HA」ではなく「DR」）: 本ページはレプリカを
ゲスト・レベルの高可用性オプションとして分類しているが、
用途としては**災害対策（DR）**にあたる。理由は、

  • 非同期であり、最短でも 30 秒（2012 R2 以降）〜 5 分のデータ損失が発生し得る
  • フェイル・オーバは自動ではなく手動で行う

ためで、「業務を止めない」高可用性（クラスタ）とは目的が異なる。
本ページが MSFC との併用構成を挙げているのは、
サイト内の可用性は MSFC、サイト間の災害対策はレプリカという
役割分担を示したもので、この整理は現在も有効である。
なお、Windows Server 2012 R2 では転送間隔として
30 秒 / 5 分 / 15 分が選べるようになっている。

サポート

製品 サポート
Exchange 無し
SQL Server 有り（設定必要）
AD DC （検証中）

補足: レプリカが苦手なのは、
アプリケーション自身がレプリケーション機構を持つ製品である。
Exchange（DAG）や SQL Server（Always On）は、
アプリ側の仕組みを使う方が整合性と切り替え速度の両面で優れるため、
Hyper-V レプリカと二重に構成する意味が薄い。
AD DC も同様に、AD 自身のマルチマスタ レプリケーションがあるうえ、
巻き戻し（USN ロールバック）の危険があるため、
DC を丸ごとレプリカする構成は避け、DC を複数台立てるのが定石である。

参考

ホスト・レベル

ホスト・クラスタ

概要

ホスト間でクラスタを構成し、ゲスト OS をホスト間で

  • フェイル・オーバー
  • ライブ・マイグレーション
  • クイック・マイグレーション

する。

サポート

FC-SAN, iSCSI（SCSI3 Persistent Reservation 機能に対応）
など、WSFC でサポートされる共有ストレージが使用できます。

考慮点

ホスト・レベルの高可用性オプション（ホスト・クラスタ）は、
ゲスト・レベルの高可用性オプションと併用可能だが、
ゲスト・クラスタとの組み合わせは複雑であるため推奨しない。

ホスト・クラスタのネットワーク種別

NICチーミング、MPIO も参照。

移行メモ: 元ページのリンク MIPO は MPIO の誤記と思われるが、
どちらの名前のページも 3 サイトのダンプに実体が無いため、
リンクを外して用語表記のみとした。
MPIO（Multipath I/O）は、上記のとおり
ストレージへのアクセス経路を複数確保する Windows の機能。

ネットワーク種別の比較

ネットワーク種別 冗長化方法 仮想スイッチ クラスタ・ネットワーク・ロール 補足
ゲスト・サービス用 NIC チーミング必須 ○ － ホストに共有しない。
VLAN を使用する場合は互換性に注意
管理者ネットワーク用 NIC チーミング 3 ホスト・ベースのバックアップに使用する場合、帯域に注意
CSV 用 NIC 複数セグメントの NIC 1 PowerShell にてメトリックを最小に設定（2008R2 まで）※ 1
ライブ・マイグレーション用 NIC 複数セグメントの NIC 1 フェイル・オーバー クラスター マネージャーで設定する。
iSCSI ストレージ用ネットワーク用 NIC（ホスト） MPIO 必須 0 ホストが iSCSI を使用する場合
iSCSI ストレージ用ネットワーク用 NIC（ゲスト） MPIO ○ － ゲストが iSCSI を使用する場合

補足（iSCSI で「チーミングではなく MPIO」である理由）: 上表で
iSCSI だけ冗長化方法が MPIO になっているのは意図的である。
NIC チーミングはリンクの冗長化しか行わないのに対し、
MPIO はストレージへの経路（パス）全体を冗長化し、
負荷分散（ラウンドロビン等）とパス障害時の切り替えを行う。
iSCSI をチーミングで冗長化するのはベンダ側でも非推奨とされることが多い。

クラスタ・ネットワーク・ロール

ホスト・クラスタのストレージ構成

CSVの利用が前提となる

WSFC でサポートされる共有ストレージが使用できる。
パターンが多数あり複雑なので、ここでは推奨される CSV に限定する。

  • 1 LUN に複数の仮想マシンを配置。

  • CSV のデザイン・パターン（1 CSV ≒ 1 LUN）

    • 1 CSV
    • 複数 CSV（I/O 負荷を分散）
      • クラスタ・ノード数の倍数
      • I/O 特性に最適化

  • 仮想マシンの配置
    固定配置、動的配置のどちらにもメリットがある。

    • CSV のオーナーノードに仮想マシンを固定配置（複数 CSV）？
    • 動的配置（CSV は意識しない、VMM の動的最適化を利用）

補足（CSV のオーナーノードを意識する理由）: CSV は全ノードから
同時に読み書きできるが、メタデータの更新はオーナー ノードが集約して行う。
このため、オーナー以外のノードでメタデータ更新が多発すると
リダイレクト I/O が発生して性能が落ちる。
著者が「オーナーノードに仮想マシンを固定配置」を挙げているのはこの対策である。
ただし、Windows Server 2012 以降は CSV の実装が改善され、
通常のワークロードでこれを意識する必要は薄れているため、
動的配置（VMM に任せる）で問題ないことが多い。

ストレージのTips

  • ディスク領域の計算
    仮想マシンのメモリ情報（.BIN ファイル）の容量を考慮します。

  • 残容量の監視
    VHD の領域の残容量が枯渇すると、仮想マシンが停止します。

  • VHDX の利用
    VHD よりもパフォーマンス、耐障害性が増した VHDX の利用を推奨します。

  • VHD のアラインメント

補足（.BIN ファイルは現在は作られない）: 仮想マシンのメモリ内容を
保存するための .BIN ファイル（メモリ サイズと同容量を事前確保する）は、
Windows Server 2016 以降では作成されない（自動停止アクションが
既定で「保存」から「シャットダウン」に変わったため）。
したがって、現在のディスク領域見積もりでは
本節が挙げているメモリ分の上乗せは不要になっている。

仮想マシン・モニタリング

概要

  • ホスト・クラスタ環境下において、仮想マシンの状態を監視。

機能

  • 仮想マシンのハートビート監視
  • 仮想マシンのサービス監視（2012 から）

サポート

  • ゲストとホストが同じドメイン若しくは信頼関係が必要
  • ファイア・ウォールを構成する必要がある。
  • サービスの回復オプションを構成する必要がある。

考慮点

参考

参考

Tags: Windows, Hyper-V, 仮想化

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally