Azure Local 2506に新しいSDN（プレビュー）がやって来た（1）：今までのMicrosoft SDNとの違い

みなさん、こんにちは。ネットワールドでSA（ソリューションアーキテクト）として活動している後藤です。

MicrosoftのAzure Localですが、常に更新をし続けるソリューションであり、7月もセキュリティ更新を含んだソリューションアップデートが配信されました。

ソリューションアップデートの内容についてはMicrosoftの公式ページをご確認ください。

learn.microsoft.com

※ 執筆時点で日本語ドキュメントで情報更新がなかったので、英語版になります。

Azure Local 2506というソリューションバージョンになり、2025/06のセキュリティアップデート（Build 25398はKB5060118、Build 26100系はKB5060842）のほか、機能追加が実施されています。

機能追加内容については、以下「Features and improvements in 2506」に詳細が書いてありますが、追加されたプレビュー機能こそが、今回の記事の本題である新しいSDN「Software-Defined Networking (SDN) enabled by Azure Arc (Preview)」になります。

learn.microsoft.com

今回の記事では、Windows Server Hyper-Vに搭載されていたMicrosoft SDN（Hyper-V Network Virtualization）との違いやできること／できないことを解説したいと思います。

1：最初に注意事項と免責事項
2：そもそもMicrosoftのSDN機能って？
3：SDN enabled by Azure Arcとは
4：最後に

1：最初に注意事項と免責事項

本記事で取り扱っている新しいSDN「SDN enabled by Azure Arc」は、執筆時点（2025/07初旬）でパブリックプレビューの機能になります。

執筆時点の情報になりますので、もしかしたら明日には仕様が変更されているかもしれません。最新の情報はMicrosoftの公式ドキュメントをご参照ください。

また、本記事に従って作業を行って発生した問題について、弊社は責任を負いかねますので、自己責任でお願いします。

2：そもそもMicrosoftのSDN機能って？

VMware環境のVMware NSXが圧倒的ネームバリューを誇るSDN（Software Defined Network）ですが、SDNとはなんぞや、となると「ネットワークの構成をソフトウェア的に定義して実装する」ネットワーク仮想化技術の総称といえます。

SDNに日本語訳として「ソフトウェア定義ネットワーク」とあてていることもおおいですね。

物理ネットワークの世界では、L2ネットワーク分離、L3ルーティング、アクセス制御、ロードバランシングなどのネットワーク機能単位で、もしくは複数の機能を実装したハードウェアを用意して物理的にネットワークを組み上げていく手法が主でしたが、コンピューティングの仮想化が進んでいく中、仮想化されたサーバーを接続するネットワークが物理の世界のスピード感では間に合わない、それであればネットワークも仮想化してスピード感を合わせよう！　という流れのなかで生まれ、成長してきた技術だと筆者は考えています。

指数関数的に増えていく仮想マシンに、物理のネットワークが追い付かなくなった、と言い換えてもよいかもしれませんね。

2-1：Microsoft SDNの初期実装：Microsoft SDN v1（HNV v1）

SDN全体の歴史の話はさておき、MicrosoftのSDN機能だけに絞ってお話ししますと、MicrosoftのSDNの歴史もそこそこ長く、MicrosoftのSDNの初めての実装はWindows Server 2012になります。

オーバーレイ型のSDNとなっており、オーバーレイプロトコルはNVGRE（Network Virtualization using Generic Routing Encapsulation）で、ネットワークを定義するコントローラーはMicrosoftが提供する仮想化基盤管理ツールであるSystem Center Virtual Machine Management（SCVMM）でした。

この初めてWindows Serverに実装されたSDNを指して、Microsoft SDN v1なんて表現をすることもありますね。現在確認したところ、公式ドキュメントではHNV v1（Hyper-V Network Virtualization v1）と表記されていました。

この時の実装は結構力業なところがあり、実はコントローラーは不要で、仮想ネットワークの設定や接続する仮想マシンなど、ネットワークの構成をすべてPowerShellでSDNに参加する全Hyper-Vホストに設定を叩き込むという、今となっては「なんという……」といった実装でした。

そうなると、仮想マシンがLive Migrationしたらどうするの？　Hyper-Vホストが再起動したらどうなるの？　という疑問もあると思いますが、すべて手作業で設定を書き換えないといけない、それだと大変なので、仮想ネットワークの設定や仮想マシンの位置を把握して、都度状況に合わせて設定を変更しますよ、という「設定上のコントローラー」としてSCVMMが存在する、という形でした。

2-2：Microsoft SDNの大幅アップデート：Microsoft SDN v2（HNV v2）

Windows Server 2012、Windows Server 2012 R2とこの実装でのSDN機能が続き、Windows Server 2016で大幅に変更が加わったSDNが登場しました。

それが「ネットワークコントローラー」というコントロールプレーンを持ち、オーバーレイプロトコルとしてVXLANを使用した新しいSDN機能です。

前バージョンと対比して、Microsoft SDN v2という表現をされることもあります。現在確認したところ、公式ドキュメントではHNV v2（Hyper-V Network Virtualization v2）と表記されていました。

learn.microsoft.com

このWindows Server 2016の実装をベースに機能拡張が続けられ、現在のWindows Server 2025ならびにAzure LocalのSDN機能となっています。

主要機能をしてはほかのSDNプロダクトと同じように、ざっと以下のような機能を持っており、またマルチテナントで使用できます。

仮想ネットワーク機能
- 仮想ネットワーク（L2/L3）
- 分散DHCP
- インターネルDNS（iDNS）
- 仮想ネットワークピアリング
- SDN QoS
ロードバランサー機能／ゲートウェイ機能
- ネットワークアドレス変換（NAT）
- ソフトウェアロードバランサー（5タプルによる負荷分散）
- RASゲートウェイ（IPSec/GRE/L3接続）
セキュリティ機能
- データセンターファイアウォール
- ファイアウォール監査
- ポートモニタリング
- ユーザー定義ルーティング（UDR）
- 仮想サブネット暗号化

詳しい技術実装については割愛しますので、以下のドキュメントを参照してください。

learn.microsoft.com

Hyper-Vのように公式ドキュメントに記載があるわけではないのですが、Microsoftのセミナー等でMicrosoft Azureの仮想ネットワークもほぼ同じ実装である、との解説を聞いたことがあります。

構成要素としては以下のとおりであり、本記事の主題である新しいSDNとの違いもありますので、この辺りは押さえておいてください。

Hyper-Vホストと仮想スイッチ、およびMicrosoft Azure VFP Switch Extention
仮想マシンとして実装されたネットワークコントローラー
仮想マシンとして実装されたソフトウェアロードバランサー（SLBMUX）
仮想マシンとして実装されたRASゲートウェイ

ネットワークコントローラーは仮想マシンとして実装され、1台構成のシングル構成から、3台実装の冗長化構成もとることができます。

ネットワークコントローラーはAzure Service Fabric（以下Service Fabric）で実装されており、SDNコントローラーとしての各機能はService Fabricのアプリケーション基盤上で実装されています。したがってService Fabricを複数台構成とすることで高可用性は担保されており、仮想マシンにはフェールオーバークラスターなどの冗長化の仕組みは実装されていません。

SLBMUX、RASゲートウェイも複数台構成による冗長化が可能です。

ネットワークコントローラーがSDN機能の要になっており、ネットワークコントローラーのAPI経由でSDNの設定が可能で、設定はSDNを構成するすべてのHyper-Vホストに設定が自動配布されます。このあたりがMicrosoft SDN v1（HNV v1）と大きな違いですね。

ネットワークコントローラーの操作はREST APIを直接触ることも可能ですし、当然のことながらPowerShellでの操作も可能です。また、SCVMMも使用できます。

JSONファイルを書いて、ネットワークコントローラーのREST APIにPUTすることもできるので、自動化も比較的簡単に実装できる点がいいですね。

前述のように、Azure LocalにおいてもMicrosoft SDN v2（HNV v2）は使用可能であり、筆者もAzure Stack HCI（当時）22H2の検証の過程でAzure Stack HCI（当時）上に展開したことがあります。Windows Server 2019と同じ実装であり、同じ機能が使用できました。

ただし、Azure Stack HCI OSの仮想マシンを作成する必要があるなど、なかなかに準備が大変だったのも事実でした。

2-3：Microsoft SDNの実装方式追加：フェールオーバークラスターを使用したネットワークコントローラー

Azure Local 23H2やWindows Server 2025でこまごまとした機能追加が行われましたが、一連の機能追加の中でも衝撃的だったのが、タイトルの通り「ネットワークコントローラーのフェールオーバークラスターのサービス実装」です。

learn.microsoft.com

これまでのネットワークコントローラーは仮想マシンで実装され、Service Fabricでのアプリケーション基盤上での実装であったため、冗長化を考えた場合は3台のHyper-Vホストでホストごとにネットワークコントローラーの仮想マシンを配置する方式でした。

このやり方のメリットは、「ネットワークコントローラーをホストするHyper-Vホストはクラスターを組む必要がない」点でした。すなわち、スタンドアロンのHyper-Vホストを3台用意すれば、SDN環境を構築することができる、ということになります。

Hyper-Vクラスターのために共有ディスクを用意する必要がない、ということですね。

時は流れ、Azure Localではクラスター構成が必須であり、すべてのノードがS2Dによる共有ディスクにアクセスできるようになりました。共有ディスクが不要なネットワークコントローラーも共有ディスクに仮想マシンの仮想ディスクを置くことになりますが、フェールオーバークラスターのリソースとしては登録できず「HCI上にいる高可用性がない仮想マシン」という、微妙な立ち位置の仮想マシンでネットワークコントローラーを動かす必要がありました。

これに対して、追加された「フェールオーバークラスターを使用したネットワークコントローラー」では、ネットワークコントローラーを仮想マシンで実装せずにフェールオーバークラスターのリソースグループとして実装することで、仮想マシンを動かすためのCPUやメモリなどのリソースを削減し、Service Fabricでのアプリケーション基盤による高可用性の確保を既存のフェールオーバークラスターで高可用性を確保することによるリソース削減、またService Fabricでは3つのデータミラーを持っていたのに対して単一のデータベースと単一のパーティションでデータを保持することでのストレージリソースの削減など、大幅なリソース削減が図られました。

また、今まではネットワークコントローラーを動かす仮想マシンのOSレベルの運用も必要であり、Windows Updateなどの運用業務が必要でした。これらの運用が不要になったのも非常に大きなポイントといえます。

なお、今回クラスターリソース化されたのはネットワークコントローラーだけであり、他の機能であるSLBMUXやRASゲートウェイなどは、仮想マシン実装のままになっています。

3：SDN enabled by Azure Arcとは

そういった中で登場した「SDN enabled by Azure Arc」ですが、従来までのSDN（公式ドキュメントでは「SDN managed by on-premises tools」と呼んでいますが）との違いは「Azureポータルから操作可能なSDN」である、という点でしょう。

つまり、AzureポータルからAzure Arc経由でAzure LocalのSDNを設定し、従来までのPowerShellやREST APIからの設定を行う必要がない、という感じです。

しかしながらプレビュー実装であり、Azureポータルが関連する関係でしょうか、まだまだ機能が従来のSDNに対して追い付いていないのが実情です。

learn.microsoft.com

SDN enabled by Azure Arcに関するMicrosoftのドキュメントは上記のものになりますが、機能ベースでまとめると以下の表のようになると思います。

項目	SDN managed by on-premises tools	SDN enabled by Azure Arc
仮想ネットワーク機能	・VLANによるネットワーク分離（論理ネットワーク）・VXLANによるネットワーク分離（仮想ネットワーク）	・VLANによるネットワーク分離（論理ネットワーク）
SDNとしてのIP管理サービス（分散DHCPやiDNS）	・機能あり	・機能なし
ロードバランサー機能	・NAT機能・5タプルによる負荷分散	・機能なし
RASゲートウェイ機能	・IPSec接続・GRE接続・L3接続	・機能なし
ネットワークセキュリティグループ（NSG）	・仮想ネットワークアダプター・仮想ネットワーク	・仮想ネットワークアダプター・論理ネットワーク
管理ツール	・Windows Admin Center ・PowerShell ・SCVMM	・Azureポータル・Azure CLI
表1：SDN enabled by Azure Arcと従来のSDNの比較

現時点においては、NSGの機能のみ利用可能との理解で差し支えないと思います。

また、SDN enabled by Azure ArcではSDN管理の仮想ネットワーク上へのAKS（Azure Kubernetes Service）の展開や、マルチサイトSDNはサポートしていません。

そういったフル機能のSDNを必要としている場合や、複数のクラスターにまたがってSDNを実装する場合には、従来のSDNのほうが適しています。

SDN enabled by Azure Arcの基本的な構成は、フェールオーバークラスターのリソースとしてネットワークコントローラーが展開される方式になります。

SDN enabled by Azure Arc展開後のフェールオーバークラスターマネージャーでは、SDN専用のサービスがいくつか登録されます（図1）。

図1：SDN enabled by Azure Arc展開後のフェールオーバークラスターマネージャー

「ApiService」や「FirewallService」といった汎用サービスが追加されています。

追加された汎用サービス名は、実はService Fabricで展開されるネットワークコントローラー用のアプリケーション名と同一であり、Service Fabricアプリケーションがフェールオーバークラスターのサービスとして移植されていることを伺い知ることができます。

こういったリソースが展開された環境に対して、Azureポータルからネットワークセキュリティグループを設定することができます。

作成したネットワークセキュリティグループは、Azure Local VM管理にて管理されている仮想マシンと論理ネットワークに対して適用することができます。
オンプレミスで作成し、Azure ArcによってAzure Local配下の仮想マシンとして管理されていない仮想マシンに対しては適用できません。