いまさら聞けないHyper-Vネットワークの詳細（5）：Hyper-Vのネットワーク仮想化機能：今だからこそ学び直すHyper-V再入門（12）
本連載第8回から複数回に分けて、「Hyper-V」の仮想ネットワークに関する考え方やポイント、仮想スイッチや仮想ネットワークアダプターの設定といった、ネットワーク周りを学び直しています。今回は、Hyper-Vに実装されたネットワーク仮想化機能「ソフトウェア定義ネットワーク」（SDN）を取り上げ、Hyper-Vにおけるネットワーク仮想化機能の実装や機能の概要についてみていきます。
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
Hyper-Vのネットワーク仮想化機能
本連載「今だからこそ学び直すHyper-V再入門」では第8回から「Hyper-V」が提供するネットワーク機能を見てきましたが、その中で「VLAN」（Virtual LAN）という単語が頻出しました。
VLANはその名の通り、「ネットワークを仮想化する機能」であり、単一の物理ネットワーク上で複数の分離されたネットワークを共存させる技術です。分離されたネットワークは「VLAN ID」で管理され、異なるVLAN間では明示的なルーティングを行わないと相互通信はできません。
Hyper-Vの仮想スイッチはVLAN機能をサポートしており、仮想マシンに対してVLAN通信を提供することは本連載第9回「いまさら聞けないHyper-Vネットワークの詳細（2）：仮想スイッチのVLAN機能」で解説した通りです。
中小規模の仮想化基盤およびネットワークであれば、VLANによるネットワーク仮想化でも十分でした。しかし、「Microsoft Azure」をはじめとするハイパースケーラーのサービスはもとより、オンプレミスの大規模な仮想化基盤において、VLANによるネットワーク分離では分離できるネットワークの数（4094個）やネットワーク機器も含めたシステム構築／運用に限界が見えてきたのが実情でした。
そうした背景において登場した技術が「ソフトウェア定義ネットワーク」（Software Defined Networking：SDN）です。
ハードウェア仮想化技術の文脈におけるSDNは、従来物理ネットワーク機器が担当していたネットワーク機能をハイパーバイザーと仮想スイッチが提供し、それらを個別の設定ではなく仮想化基盤の機能として一括コントロールする、というものになります。
このように、ネットワーク機器という専用ハードウェアではなく、ソフトウェアでコントロール可能となったネットワークは、飛躍的にその自由度を増すことになりました。SDNについては、以下の記事も参考にしてください。
- 【参考】「Windows Server 2019」も搭載、いまさら聞けない「SDN」とは（TechTargetジャパン）
さて、Hyper-VのSDNですが、歴史的には「Windows Server 2012」で実装されたネットワーク仮想化技術までさかのぼれます。
Windows Server 2012のネットワーク仮想化技術は、VLANの代わりに「NVGRE」（Network Virtualization using Generic Routing Encapsulation）と呼ばれるプロトコルでネットワークを分離する、というアプローチが採られました。
VLANは仮想マシンが送出するフレームに「VLANタグ」を付与して論理分割されたネットワークを識別するのに対し、NVGREは仮想マシンが送出するイーサネットフレームを丸ごとカプセル化します。カプセル化したパケットには「GRE」（Generic Routing Encapsulation）ヘッダが付与され、24bitの「仮想サブネットID」（VSID）が付与されます（図1）。IDが24bitで表現されるので、理論上、約1677万の仮想ネットワークを構成可能で、VLANでは考えられない規模まで拡張可能になりました。
イーサネットフレームのカプセル化はHyper-V仮想スイッチで行われるため、物理ネットワーク側から見ると図2のようにHyper-Vホストの物理ネットワーク接続IPアドレスから送出されたGREのパケットしか流れていないようにも見えます。しかし、実際に流れているパケットのペイロードには、仮想マシンから送出されたイーサネットフレームがカプセル化された状態で入って通信されています。物理ネットワーク上に流れているGREパケットの送信元／送信先はHyper-Vホストの物理ネットワーク通信用のIPアドレスになります。
送信先Hyper-Vホストでは、受け取ったGREパケットのヘッダを参照してVSIDを確認し、そのVSIDに属している宛先IPアドレスが設定された仮想マシンにカプセルを解除した後のイーサネットフレームを転送します。このような動きになるため、VLANを使用している場合と同じようにネットワークが分離されていることになります。
NVGREのポイントは、カプセル化のプロトコルとして汎用（はんよう）的なGREを使用し、GREによるカプセル化を仮想スイッチで実施するため、既存ネットワーク機器に影響を及ぼさない、という点でした。既存ネットワークを大きく変えることなくオーバーレイネットワークが構築できる点は、コストの観点からも大きなメリットでした。
NVGREを使用したHyper-Vのネットワーク仮想化技術は、「Hyper-Vネットワーク仮想化」（Hyper-V Network Virtualization：HNV）と呼ばれ、Hyper-V単体でも動作することがポイントの一つでもありました。しかし、ネットワーク分離を実現する機能であるため「どのユーザーがどのVSIDを使い、どのHyper-Vホスト上にいるどの仮想マシンが、どのVSIDの仮想ネットワークに所属しているか」を管理するコントロールプレーンの実装が課題でした。
この課題の解決策の一つが、Hyper-Vを管理するためのMicrosoftの管理ツール「System Center Virtual Machine Manager」（SCVMM）を別途導入する方法、もう一つが「PowerShell」による各ホストでの個別管理でした。
大規模な仮想化基盤を管理するには、効率化するための管理ツールが必要で、その立ち位置にいたのがSCVMMでした。しかし、SCVMMは大規模環境向けの管理製品であったため、導入のハードルは低くはなく、さりとてPowerShellで手動管理した場合には「ライブマイグレーション」に仮想ネットワークの設定が自動追従してくれない、という悩みがあったのは事実です。
2016年9月にリリースされた「Windows Server 2016」では、「HNV」（NVGREベースのHyper-Vネットワーク仮想化）は引き続きサポートされたものの、新しいSDNの仕組みが搭載されました。
それがWindows Serverの標準機能として新たに搭載された「ネットワークコントローラー」をコントロールプレーンとしたネットワーク仮想化技術であり、HNVとの対比で「Microsoft SDN v2」や単に「SDN v2」と呼ばれたり、「HNV v2」（Hyper-V Network Virtualization v2）と呼ばれたりする、新しいSDNの仕組みでした。
Microsoft SDN v2（HNV v2）では、管理を容易にするためにSCVMMを利用することは可能ですが必須ではなく、ネットワークコントローラーをインストールしたWindows Serverが仮想ネットワークをコントロールする構成に変更され、さらにネットワークを操作する手法（マネジメントプレーン）としてPowerShellはもちろんのこと、RESTful APIによる管理をサポートしました。RESTful APIについては、以下記事をご参照ください。
また、Windows Serverの管理ツールとして登場した「Windows Admin Center」（WAC）でもMicrosoft SDN v2は管理可能であり、SCVMMのような大規模環境でなくてもGUI（グラフィカルユーザーインタフェース）ツールでSDNを管理できるようになった点が、大きなポイントといえます（画面1）。
このようなコントロールプレーンの標準機能化やモダンなマネジメントプレーンの実装により、Hyper-V上でより現実的なSDNを実装することが可能になりました。そして、最新の「Windows Server 2025」に至るまで、Microsoft SDN v2は機能強化を続けています。
なお、Windows Server 2016ではサポートされていたHNVですが、「Windows Server 2019」で「削除された機能」となってしまい、Windows Server 2019以降のWindows Serverでは使用できなくなりました。そのため、SDNの機能はMicrosoft SDN v2のみ使用可能になっています。
Microsoft SDN v2の機能概要
Microsoft SDN v2は、Microsoft Azureの「仮想マシン」サービスのネットワークサービスにかなり似たネットワーク機能が利用可能です。
【仮想ネットワーク機能】
仮想ネットワーク（L2/L3）
分散DHCP（Dynamic Host Configuration Protocol）
インターネルDNS（Domain Name System）（iDNS）
仮想ネットワークピアリング
SDN QoS（Quality of Service）
【ロードバランサー機能／ゲートウェイ機能】
ネットワークアドレス変換（NAT）
ソフトウェアロードバランサー（5タプルによる負荷分散）
RAS（Remote Access Server）ゲートウェイ（IPsec/GRE/L3接続）
【セキュリティ機能】
データセンターファイアウォール
ファイアウォール監査
ポートモニタリング
ユーザー定義ルーティング（UDR）
仮想サブネット暗号化
Hyper-Vのネットワーク仮想化において、ネットワーク分離はVLANではなくカプセリングプロトコルが用いられます。Windows Server 2012では前述の通りNVGREが利用されていましたが、Microsoft SDN v2では「VXLAN」Virtual Extensible LAN）が利用されます。もちろん、投資保護のためにカプセリングプロトコルとしてNVGREも引き続き使用可能ですが、デフォルト（既定）はVXLANになります。
VXLANもNVGREと同じく、仮想マシンが送出するイーサネットフレームをカプセル化して物理ネットワーク上の通信を行うオーバーレイプロトコルですが、NVGREはベースがGRE（プロトコル番号47）、VXLANはUDP（プロトコル番号17）となります。プロトコルが違いますが、考え方はほぼ同じと言ってしまってよいでしょう。
VXLANもNVGREと同様に仮想ネットワークを識別するIDとして24bitの「VNI」（VXLAN Network Identifier）を持ちます。24bit長なので、やはり約1677万の仮想ネットワークを理論上設定可能です。
以下の画面2は、仮想ネットワークで接続された仮想マシン間でICMP（Internet Control Message Protocol）による疎通確認（Ping）を行った際のパケットキャプチャー結果になります。VXLANパケットの中に仮想マシンのMAC（Media Access Control）アドレスやIPアドレス、ならびにICMPのパケットが全て収められていることが分かります。
仮想マシン間の通信はVXLANでカプセル化されて物理ネットワーク上で送受信されることが分かりました。では、物理ネットワーク、例えばインターネットとやりとりする場合はどうなるのでしょうか？
当然、Microsoft SDN v2は仮想ネットワーク内の仮想マシンに対して物理ネットワークとの接続を提供しており、物理ネットワークとのゲートウェイ機能や、物理ネットワークからの通信を分散するロードバランサー機能など、一通りの機能を提供しています。ゲートウェイ機能はWindows Serverの標準機能である「ルーティングとリモートアクセス」サービス、ロードバランサー機能は同じく標準機能である「ソフトウェアロードバランサーマルチプレクサー」（Software Load Balancer MUltipleXer：SLBMUX）が担当します。
これらも、コントロールプレーンである「ネットワークコントローラー」からの指示に従って動くソフトウェアで実装されたネットワーク機能となります。
Microsoft SDN v2のアーキテクチャの概要
Microsoft SDN v2は、コントロールプレーンである「ネットワークコントローラー」とHyper-V仮想スイッチの拡張機能である「Microsoft Azure VFP Switch Extension」が連携して動作することでネットワーク仮想化を実現しています。
仮想化されたネットワークと物理ネットワークを接続するゲートウェイやロードバランサーなどもWindows Serverの標準機能で実装されており、Windows ServerがあればMicrosoft Azureでもおなじみの負荷分散機能やネットワークアドレス変換（Network Address Translation：NAT）機能、仮想ネットワークへのIPsec接続などの各種ネットワーク機能を実現することが可能です。
以下の図4はMicrosoft SDN v2のアーキテクチャ概要図になります。
この概要図の通り、マネジメントプレーン、コントロールプレーン、データプレーンでそれぞれ役割が設定されており、データプレーンはコントロールプレーンの指示の下に実際にネットワークを動作させるレイヤーになります。このレイヤーはHyper-Vホストの仮想スイッチおよび仮想スイッチの拡張機能である「Microsoft Azure VFP Switch Extension」が担当し、コントロールプレーンとのインタフェースはHyper-Vホスト上で稼働する「NC Host Agent」と「SLB Host Agent」が担います。
前項でも説明した通り、ネットワーク機能は仮想スイッチだけではなく、ゲートウェイやSLBMUXによっても提供されます。それらの機能はゲートウェイ用サービスないしはSLBMUXのサービスが稼働する仮想マシンが別途動作することになります。
それらの仮想マシンはマルチテナントで稼働するように設計されているため、1台の仮想マシンで複数のユーザーを収容することが可能です。
以下の画面3は、後述する「Service Fabric」方式で3台のHyper-Vホスト上にネットワークコントローラーやSLBMUX、ゲートウェイを展開した際の「Hyper-Vマネージャー」の画面です。各Hyper-Vホストにネットワークコントローラー（名前に「NC」がついている仮想マシン）やSLBMUX（名前に「Mux」がついている仮想マシン）、ゲートウェイ（名前に「GW」が付いている仮想マシン）が仮想マシンとして分散配置されていることが分かります。
これらのデータプレーンを制御するためのコントロールプレーンは、前述の通り、「ネットワークコントローラー」が担います。その展開方法としては、複数の仮想マシン上でマイクロサービスアーキテクチャアプリケーションとしてネットワークコントローラーのサービスが稼働する「Service Fabric」と、「フェールオーバークラスター」（フェールオーバークラスタリング）サービスとしてネットワークコントローラーのアプリケーションが稼働する「ネイティブSDN」の2つのパターンが存在します。
ネットワークコントローラーを展開する際には、どちらの手法で展開するかを決定する必要があります。以下の画面4は、WACを用いてネットワークコントローラーを展開する際の画面となります。「Service Fabric」と「ネイティブSDN」のどちらの手法で展開するかの選択肢が提示されています。
前者のService FabricはWindows Server 2016からサポートされた展開方式で、運用環境利用であれば最低3台の仮想マシン上でマイクロサービスアーキテクチャの分散アプリケーションとして実装されたネットワークコントローラーが動作します。
Service Fabricは、マイクロサービスとコンテナのパッケージ化とデプロイ、管理を簡素化する分散システムプラットフォームです。Service Fabric上で稼働するアプリケーションは、複数の仮想マシン（ノード）から構成される「Service Fabricクラスター」によって冗長性が保証されます。
【参考】Azure Service Fabricの概要（Microsoft Learn）
なお、Service Fabricで展開されたネットワークコントローラーは、仮想マシン上で稼働するアプリケーションとなるため、アプリケーションリソースの他、ゲストOSとしてWindows Server OSのリソースが必要になります。また、ネットワークコントローラーアプリケーションを展開する際には、仮想マシンの展開時間も併せて必要になります。
画面3をもう一度見てみると、右下に表示されているコンソールは仮想マシン「SDN-NC01」になりますが、「SDN-NC01」上で「Get-NetworkController」コマンドレットを実行しています。このコマンドレットはネットワークコントローラーのService Fabricクラスターのノードを取得できるコマンドレットであり、各Hyper-Vホスト上の仮想マシンでネットワークコントローラーが構成されていることが確認でき、ネットワークコントローラーも仮想マシンの形で実装されていることが分かります。
後者のネイティブSDNはWindows Server 2025からサポートされている展開方式です。ネットワークコントローラーのサービスはクラスタアプリケーションとして実装されており、冗長性はWindows Serverの標準機能であるフェールオーバークラスターが保証します。
以下の画面5は「ネイティブSDN」でネットワークコントローラーを展開した際のフェールオーバークラスター管理画面となりますが、ネットワークコントローラーとして稼働するために必要な8つの汎用サービスが動作していることが分かります。
このように、「ネイティブSDN」はフェールオーバークラスターが稼働していればクラスターサービスを追加するだけになるので、展開にはそれほど時間がかかりません。ただし、フェールオーバークラスターを構成する関係上、ネットワークコントローラーアプリケーションのデータを格納するための共有ディスクが必要になります。
画面4にもあるように、Windows Server 2025以降を使用してMicrosoft SDN v2環境を構築する場合には、「ネイティブSDN」、すなわちフェールオーバークラスター構成が推奨とされています。
Hyper-Vの高可用性を保証するための機能としても利用されているフェールオーバークラスターについては、別の回で解説します。
コントロールプレーンに対してさまざまな指示を出すためのマネジメントプレーンとしては、PowerShellやSCVMM、WACの他、RESTful APIがサポートされています。ネットワークコントローラーでサポートされるRESTful APIは、Microsoftのドキュメントとしてまとめられています。
- [MS-NCNBI]: Network Controller Northbound Interface［英語］（Microsoft Learn）
ネットワークコントローラーをRESTful APIで操作する際には必須のドキュメントとなっているので、興味があれば確認してください。
PowerShellで管理する場合は「NetworkController」モジュールや「NetworkControllerDiagnostics」モジュールをインポートします。これらのコマンドレットのレファレンスもMicrosoftのサイトにまとめられているので、参考にしてください。
- NetworkController Module［英語］（Microsoft Learn）
なお、前述したように、WACもマネジメントプレーンとして利用できるため、PowerShellやRESTful APIを必ずしも使用しなくてよい環境にはなっています。しかし、ネットワークをソフトウェアで定義できる環境が提供されているので、PowerShellやRESTful APIを利用した自動化などを通じ、運用工数の削減にチャレンジするのもよいかと考えます。
Microsoft SDN v2のセットアップ
Hyper-Vの仮想化基盤にMicrosoft SDN v2を展開する場合は、以下のような方法があります。
- PowerShellスクリプト（SDNExpress）による展開
- WACによる展開
両手法ともMicrosoftのサイトにてドキュメントが整備されているので、まずはドキュメントを参照することをお勧めします。
両ドキュメントとも、Microsoftのハイブリッドクラウドソリューション「Azure Local」上にMicrosoft SDN v2を展開するためのドキュメントですが、Windows ServerのHyper-Vにおいても手順は同じです。ただし、手順内で使用するVHDXファイル（仮想ディスク）はWindows Server OSのものを準備してください。
- SDN Express for Azure Localを使用してSDNインフラストラクチャをデプロイする（Microsoft Learn）
- Windows Admin Center for Azure Localを使用してSDNをデプロイする（Microsoft Learn）
取りあえず検証したいという場合には、WACによる展開をお勧めしますが、2ノード以上のフェールオーバークラスター構成が必要になりますのでその点だけご了承ください。
Microsoft SDN v2の設定
前述の通り、マネジメントプレーンとしてPowerShellやWACなどが利用可能です。
WACを使用すればGUIによる管理が可能です（画面6）。まずはWACでSDN環境の操作に慣れるとよいでしょう。
自動化などを考える場合は、PowerShellによる操作に慣れるべきです。例えば、仮想ネットワークを作成する場合は、以下の画面7のようなコマンドレットの実行で作成できます。
仮想ネットワークの作成や仮想ネットワークへの仮想マシンの接続、外部ネットワーク接続（NAT接続やIPsec接続など）といった一連の作業をWACやPowerShellを利用して設定していきます。感覚としてはMicrosoft Azureの「仮想マシン」サービスでの操作にかなり近いものがあるので、Microsoft Azureの操作に慣れている方であれば、そこまで迷うこともなく設定できるでしょう。
Microsoft SDN v2の現在地
Windows Server 2016で実装され、バージョンを重ねるごとに機能追加されてきたMicrosoft SDN v2ですが、基本的な機能はWindows Server 2019で充足したと考えてよいかと思います。
「Windows Server 2022」では特筆すべき機能強化はありませんでしたが、Windows Server 2025では、ゲートウェイサービスのパフォーマンスの向上が図られた他、よりMicrosoft Azureライクな「ネットワークセキュリティグループ」（NSG）の実装や、SDN基盤のリソース削減を目的としたフェールオーバークラスターベースのネイティブSDNの実装、という機能強化が図られています。詳細は以下のURLをご確認ください。
- Windows Server 2025の新機能：ソフトウェアによるネットワーク制御（Microsoft Learn）
Microsoft SDN v2の今後を考える場合、まず見るべきポイントはMicrosoft Azureのネットワークサービスだと筆者は考えています。今までのMicrosoft SDN v2は、Microsoft Azureがサポートしている機能を実装してきた流れがあると筆者は感じています。したがって、Microsoft Azureでサポートされている機能を見ていくと、今後のMicrosoft SDN v2の進化の方向性を知るきっかけになるかもしれません。
今回はHyper-Vのネットワーク仮想化機能であるSDNを見てきましたが、今回解説できたのはその全貌のほんの一部にすぎません。Microsoftのドキュメントを参考に、検証環境を作り、実際に触れることで、その豊富な機能を体感してみてください。
- ソフトウェア定義ネットワーク（SDN）（Microsoft Learn）
筆者紹介
後藤 諭史（ごとう さとし）
株式会社ネットワールド所属。Microsoft MVP for Cloud and Datacenter Management（2012-2025）。現業の傍ら、コミュニティーイベントでの登壇や著作にてMicrosoftテクノロジーに関する技術情報の発信、共有を続けている。ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。近著は『詳解! Windows Server仮想ネットワーク』（日経BP社）。
関連記事
Copyright © ITmedia, Inc. All Rights Reserved.
アイティメディアからのお知らせ
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。