Windows Server Technical Details での Hyper-V ネットワーク仮想化の技術的な詳細

  • [アーティクル]

適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、Azure Stack HCI バージョン 21H2 および 20H2

サーバー仮想化を導入すると、複数のサーバー インスタンスを 1 つの物理ホストで同時に実行できます。ただし、サーバー インスタンスは互いに独立しています。 各仮想マシンは基本的に、その仮想マシンだけが物理コンピューター上で実行されているサーバーであるかのように動作します。

ネットワーク仮想化では同様の機能が提供され、複数の仮想ネットワーク (場合によっては重複する IP アドレスで) が同じ物理ネットワーク インフラストラクチャ上で実行されます。各仮想ネットワークは、共有ネットワーク インフラストラクチャ上で実行されている唯一の仮想ネットワークであるかのように動作します。 この関係を示したのが図 1 です。

Server virtualization versus network virtualization

図 1: サーバー仮想化とネットワーク仮想化

Hyper-V ネットワーク仮想化の概念

Hyper-V ネットワーク仮想化 (HNV) では、顧客またはテナントは、企業またはデータセンターに展開されている一連の IP サブネットの "所有者" として定義されます。 顧客は、ネットワークの分離を必要とするプライベート データセンター内に複数の部門または事業単位を持つ企業、またはサービス プロバイダーによってホストされているパブリック データ センター内のテナントであることもあります。 各顧客はデータセンター内に 1 つ以上の VM ネットワークを所有でき、各 VM ネットワークは仮想サブネットを含む 1 つ以上の仮想サブネットで構成されます。

Windows Server 2016 では、HNVv1 と HNVv2 の 2 つの HNV の実装を使用できます。

  • HNVv1

    HNVv1 は、R2 および Windows Server 2012 R2 および System Center 2012 R2 Virtual Machine Manager (VMM) に互換性があります。 HNVv1 の構成は、WMI 管理と Windows PowerShell コマンドレット (System Center VMM を通じて簡素化される) に依存して、分離設定とカスタマー アドレス (CA)、つまり仮想ネットワークから物理アドレス (PA) へのマッピングとルーティングを定義します。 Windows Server 2016 の HNVv1 には機能は追加されておらず、新機能も計画されていません。

    • SET Teaming と HNV V1 は、プラットフォームで互換性がありません。

    o HA NVGRE ゲートウェイを使用するには、ユーザーは LBFO チームまたは No team を使用する必要があります。 または

    o SET Teamed スイッチが搭載された、ネットワーク コントローラーが展開されたゲートウェイを使用します。

  • HNVv2

    Hyper-V スイッチの Azure 仮想フィルタリング プラットフォーム (VFP) 転送拡張を使用して実装される HNVv2 には、多数の新機能が含まれています。 HNVv2 は、ソフトウェア定義ネットワーク (SDN) スタックに新しいネットワーク コントローラーが含まれる Microsoft Azure Stack と完全に統合されています。 仮想ネットワーク ポリシーは、RESTful NorthBound (NB) API を使用して Microsoft ネットワーク コントローラーを介して定義され、OVSDB を含む複数の SouthBound Interface (SBI) を介してホスト エージェントに適用されます。 ホスト エージェントは、それが適用される Hyper-V スイッチの VFP 拡張のポリシーをプログラムします。

    重要

    このトピックでは、HNVv2 について説明します。

仮想ネットワーク

  • 各仮想ネットワークは 1 つ以上の仮想サブネットで構成されます。 仮想ネットワークは、仮想ネットワーク内の仮想マシンが相互にのみ通信できる分離境界を形成します。 従来、この分離は、分離された IP アドレス範囲と 802.1q タグまたは VLAN ID を持つ VLAN を使用して適用されていました。 しかし、HNV では、NVGRE または VXLAN カプセル化を使用して分離が適用され、顧客またはテナント間で IP サブネットが重複する可能性があるオーバーレイ ネットワークが作成されます。

  • 各仮想ネットワークには、ホスト上に一意のルーティング ドメイン ID (RDID) があります。 この RDID は、ネットワーク コントローラー内の仮想ネットワーク REST リソースを識別するために、リソース ID に大まかにマップされます。 仮想ネットワーク REST リソースは、アペンドされたリソース ID を持つ Uniform Resource Identifier (URI) 名前空間を使用して参照されます。

仮想サブネット

  • 仮想サブネットでは、同じサブネット内の仮想マシンにレイヤー 3 IP サブネット セマンティクスが実装されます。 仮想サブネットはブロードキャスト ドメイン (VLAN に似ています) を形成し、NVGRE テナント ネットワーク ID (TNI) または VXLAN ネットワーク識別子 (VNI) フィールドのいずれかを使用して分離が適用されます。

  • 各仮想サブネットは 1 つの仮想ネットワーク (RDID) に属し、カプセル化されたパケット ヘッダーの TNI キーまたは VNI キーを使用して一意の仮想サブネット ID (VSID) が割り当てられます。 VSID はデータセンター内で一意であり、4096 ～ 2^24-2 の範囲にある必要があります。

仮想ネットワークとルーティング ドメインの主な利点は、顧客が自社のネットワーク トポロジ (IP サブネットなど) をクラウドに持ち込むことができることです。 図 2 の例では、Contoso Corp は R&D Net と Sales Net の 2 つの独立したネットワークを所有しています。 これらのネットワークはルーティング ドメイン ID が異なるため、干渉し合うことはありません。 つまり、Contoso R&D Net は Contoso Sales Net と共に Contoso Corp によって所有されていますが、Contoso Sales Net から切り離されています。Contoso R&D Net には 3 つの仮想サブネットが含まれています。 RDID と VSID の両方がデータセンター内で一意であることに注意してください。

Customer networks and virtual subnets

図 2: カスタマー ネットワークと仮想サブネット

レイヤー 2 転送

図 2 では、VSID 5001 の仮想マシンは、Hyper-V スイッチを介して VSID 5001 内の仮想マシンにもパケットを転送できます。 VSID 5001 の仮想マシンからの受信パケットは、Hyper-V スイッチ上の特定の VPort に送信されます。 イングレス規則 (encap など) とマッピング (カプセル化ヘッダーなど) は、これらのパケットに対して Hyper-V スイッチによって適用されます。 その後、パケットは、Hyper-V スイッチ上の別の VPort (宛先仮想マシンが同じホストに接続されている場合) または別のホスト上の別の Hyper-V スイッチ (宛先仮想マシンが別のホスト上にある場合) に転送されます。

レイヤー 3 ルーティング

同様に、VSID 5001 の仮想マシンは、各 Hyper-V ホストの VSwitch に存在する HNV 分散ルーターによって、VSID 5002 または VSID 5003 の仮想マシンにパケットをルーティングできます。 HNV は、パケットを Hyper-V スイッチに送信する前に、着信パケットの VSID を宛先仮想マシンの VSID に更新します。 これは両方の VSID が同じ RDID 内にある場合にだけ行われます。 したがって、RDID1 の仮想ネットワーク アダプターは、ゲートウェイをスキャンすることなく RDID2 の仮想ネットワーク アダプターにパケットを送信できません。

注意

上記のパケット フローでは、"仮想マシン" という用語は実際には仮想マシン上の "仮想ネットワーク アダプター" を意味します。 通常、仮想マシン上には仮想ネットワーク アダプターが 1 つしかありません。 この場合、"仮想マシン" と "仮想ネットワーク アダプター" は概念的には同じ意味です。

各仮想サブネットでは、レイヤー 3 IP サブネットと VLAN に似たレイヤー 2 (L2) ブロードキャスト ドメイン境界が定義されます。 仮想マシンがパケットをブロードキャストすると、HNV はユニキャスト レプリケーション (UR) を使用して元のパケットのコピーを作成し、宛先 IP と MAC を同じ VSID 内の各 VM のアドレスに置き換えます。

注意

Windows Server 2016 が出荷されると、ブロードキャストおよびサブネット マルチキャストはユニキャスト レプリケーションを使用して実装されます。 サブネット間マルチキャスト ルーティングと IGMP はサポートされていません。

VSID は、ブロードキャスト ドメインであるだけでなく、分離も提供します。 HNV の仮想ネットワーク アダプターは、ポート (virtualNetworkInterface REST リソース) に直接適用されるか、その一部を成す仮想サブネット (VSID) に ACL 規則が適用される Hyper-V スイッチ ポートに接続されます。

Hyper-V スイッチ ポートには、ACL 規則が適用されている必要があります。 この ACL は、ALLOW ALL、DENY ALL、または 5 タプル (送信元 IP、宛先 IP、送信元ポート、宛先ポート、プロトコル) 照合に基づいて特定の種類のトラフィックのみを許可するために、より具体的である場合があります。

注意

Hyper-V スイッチ拡張は、新しいソフトウェア定義ネットワーク (SDN) スタックの HNVv2 では機能しません。 HNVv2 は、他のサードパーティ製スイッチ拡張と組み合わせて使用できない Azure 仮想フィルタリング プラットフォーム (VFP) スイッチ拡張を使用して実装されます。

Hyper-V ネットワーク仮想化の切り替えとルーティング

HNVv2 では、物理スイッチまたはルーターと同じように動作するために、正しいレイヤー 2 (L2) の切り替えとレイヤー 3 (L3) ルーティング セマンティクスが実装されています。 HNV 仮想ネットワークに接続されている仮想マシンが、同じ仮想サブネット (VSID) 内の別の仮想マシンとの接続を確立しようとする場合、最初にリモート仮想マシンの CA MAC アドレスを学習する必要があります。 ソース仮想マシンの ARP テーブルに宛先仮想マシンの IP アドレスの ARP エントリがある場合は、このエントリの MAC アドレスが使用されます。 エントリが存在しない場合、送信元仮想マシンは、返される宛先仮想マシンの IP アドレスに対応する MAC アドレスの要求を含む ARP ブロードキャストを送信します。 Hyper-V スイッチでは、この要求をインターセプトしてホスト エージェントに送信します。 ホスト エージェントでは、ローカル データベースで、要求された宛先仮想マシンの IP アドレスに対応する MAC アドレスを探します。

注意

OVSDB サーバーとして機能するホスト エージェントは、VTEP スキーマのバリアントを使用して、CA-PA マッピング、MAC テーブルなどの格納を行います。

MAC アドレスが使用可能な場合、ホスト エージェントでは ARP 応答を挿入し、これを仮想マシンに返します。 仮想マシンのネットワーク スタックに必要なすべての L2 ヘッダー情報が含まれると、V スイッチ上の対応する Hyper-V ポートにフレームが送信されます。 内部的には、Hyper-V スイッチは、V ポートに割り当てられた N タプル照合規則に対してこのフレームをテストし、これらの規則に基づいてフレームに特定の変換を適用します。 最も重要なのは、ネットワーク コントローラーで定義されているポリシーに応じて、NVGRE または VXLAN を使用してカプセル化ヘッダーを構築するために、一連のカプセル化変換が適用される点です。 ホスト エージェントによってプログラミングされたポリシーに基づいて、CA-PA マッピングを使用して、宛先仮想マシンが存在する Hyper-V ホストの IP アドレスが決定されます。 Hyper-V スイッチを使用すると、正しいルーティング規則と VLAN タグが外部パケットに適用され、リモート PA アドレスに到達します。

HNV 仮想ネットワークに接続されている仮想マシンが、別の仮想サブネット (VSID) 内の仮想マシンとの接続を作成する場合は、パケットを必要に応じてルーティングする必要があります。 HNV では、すべての IP プレフィックスに到達するために次ホップとして使用される CA 空間に 1 つの IP アドレスしか含めないスター トポロジが想定されています (つまり、1 つの既定のルート/ゲートウェイ)。 現時点では、1 つの既定のルートに制限が適用され、既定以外のルートはサポートされていません。

仮想サブネット間のルーティング

物理ネットワークでは、サブネットは、コンピューター (仮想および物理) が相互に直接通信できるレイヤー 2 の (L2) ドメインです。 L2 ドメインはブロードキャスト ドメインであり、ARP エントリ (IP:MAC アドレス マップ) は、すべてのインターフェイスでブロードキャストされる ARP 要求を介して学習され、ARP 応答が要求ホストに返されます。 コンピューターは、ARP 応答から学習した MAC 情報を使用して、イーサネット ヘッダーを含む L2 フレームを完全に構築します。 ただし、IP アドレスが別の L3 サブネットにある場合、ARP 要求はこの L3 境界を越えません。 代わりに、送信元サブネット内の IP アドレスを持つ L3 ルーター インターフェイス (次ホップまたは既定のゲートウェイ) が、独自の MAC アドレスを使用してこれらの ARP 要求に応答する必要があります。

標準の Windows ネットワークでは、管理者は静的ルートを作成し、ネットワーク インターフェイスに割り当てできます。 さらに、通常、"既定のゲートウェイ" は、既定のルート (0.0.0.0/0) 宛てのパケットが送信されるインターフェイスの次ホップ IP アドレスとして構成されます。 特定のルートが存在しない場合、パケットはこの既定のゲートウェイに送信されます。 これは通常、物理ネットワークのルーターです。 HNV は、すべてのホストの一部であり、すべての VSID にインターフェイスを備えた組み込みルーターを使用して、仮想ネットワークの分散ルーターを作成します。

HNV はスター トポロジを前提としているため、HNV 分散ルーターは、同じ VSID ネットワークの一部である仮想サブネット間のすべてのトラフィックに対して 1 つの既定のゲートウェイとして機能します。 既定のゲートウェイとして使用されるアドレスは、既定で VSID 内の最も低い IP アドレスに設定され、HNV 分散ルーターに割り当てられます。 この分散ルーターによって、各ホストが仲介を必要とすることなく適切なホストにトラフィックを直接ルーティングできるために、VSID ネットワーク内のすべてのトラフィックについて非常に効率的な方法で適切にルーティングできます。 これは特に、同じ VM ネットワーク内の異なる仮想サブネットで、2 つの仮想マシンが同じ物理ホスト上にある場合に当てはまります。 このセクションで後ほど説明するように、この場合にパケットは物理ホストを離れる必要はありません。

PA サブネット間のルーティング

各仮想サブネット (VSID) に 1 つの PA IP アドレスが割り当てられる HNVv1 とは対照的に、HNVv2 では、Switch-Embedded Teaming (SET) NIC チーム メンバーごとに 1 つの PA IP アドレスを使用するようになりました。 既定の展開では、2 つの NIC からなるチームが想定され、ホストごとに 2 つの PA IP アドレスが割り当てられます。 1 つのホストで、同じ VLAN 上の同一プロバイダー (PA) 論理サブネットから PA IP が割り当てられます。 同じ仮想サブネット内の 2 つのテナント VM は、2 つの異なるプロバイダーの論理サブネットに接続されている 2 つの異なるホスト上に存在することがあります。 HNV は、CA-PA マッピングに基づいて、カプセル化されたパケットの外部 IP ヘッダーを構築します。 ただし、既定の PA ゲートウェイに対してはホストの TCP/IP スタックに依存し、ARP 応答に基づいて外部イーサネット ヘッダーを作成します。 通常、この ARP 応答は、ホストが接続されている物理スイッチまたは L3 ルーターの SVI インターフェイスから取得されます。 このため、HNV は、プロバイダーの論理サブネットや VLAN 間でカプセル化されたパケットをルーティングするために、L3 ルーターに依存しています。

仮想ネットワークの外側のルーティング

ほとんどの顧客展開では、HNV 環境から HNV 環境の一部ではないリソースへの通信が必要になります。 2 つの環境間の通信を実現するためには、ネットワーク仮想化ゲートウェイが必要です。 HNV ゲートウェイを必要とするインフラストラクチャとして、プライベート クラウドやハイブリッド クラウドなどがあります。 基本的に、HNV ゲートウェイは、内部および外部 (物理) ネットワーク (NAT を含む) 間、または IPSec VPN または GRE トンネルを使用する異なるサイトやクラウド (プライベートまたはパブリック) 間のレイヤー 3 ルーティングに必要です。

ゲートウェイはさまざまな物理フォーム ファクターで提供されます。 これらは Windows Server 2016 上に構築でき、VXLAN ゲートウェイとして機能する Top of Rack (TOR) スイッチに組み込まれており、ロードバランサーによってアドバタイズされる仮想 IP (VIP) を介してアクセスしたり、他の既存のネットワーク アプライアンスに配置したり、新しいスタンドアロン ネットワーク アプライアンスにすることができます。

Windows RAS ゲートウェイ オプションについては「RAS ゲートウェイ」を参照してください。

パケット カプセル化

HNV の各仮想ネットワーク アダプターは、次の 2 つの IP アドレスに関連付けられます。

  • カスタマー アドレス (CA) 顧客がイントラネット インフラストラクチャに基づいて割り当てる IP アドレス。 このアドレスの存在によって、顧客は、パブリック クラウドまたはプライベート クラウドに移行されたことを意識せずに、仮想マシンとの間でネットワーク トラフィックをやり取りすることができます。 CA は、仮想マシンから見える、顧客が到達可能なアドレスです。

  • プロバイダー アドレス (PA) ホスト側プロバイダーまたはデータセンターの管理者が、物理ネットワーク インフラストラクチャに基づいて割り当てる IP アドレス。 PA は、仮想マシンをホストしている Hyper-V を実行するサーバーとの間で交換されるネットワーク上のパケットに格納されます。 PA は、物理ネットワーク上では見えますが、仮想マシンからは見えません。

カスタマー ネットワークのトポロジは、CA によって保たれていますが、カスタマー ネットワークは仮想化され、その基になる (PA によって実現されている) 実際の物理ネットワークのトポロジとアドレスからは切り離されています。 次の図は、ネットワーク仮想化の結果としての仮想マシンの CA とネットワーク インフラストラクチャの PA の概念上の関係を示しています。

Conceptual diagram of network virtualization over physical infrastructure

図 6: 物理インフラストラクチャ上のネットワーク仮想化の概念図

この図では、顧客の仮想マシンは CA 空間内のデータ パケットを送信しています。このデータ パケットは、それ自体の仮想ネットワーク ("トンネル") を通って物理ネットワーク インフラストラクチャを横断します。 上の例のトンネルは、左側の送信元ホストから右側の送信先ホストに送信される Contoso と Fabrikam のデータ パケットと緑の宛先ラベル (PA アドレス) を包む "封筒" と見なすことができます。 重要なのは、ホストがどのように Contoso と Fabrikam の CA に対応する "宛先アドレス" (PA) を決定し、パケットがどのように "封筒" に包まれ、送信先ホストがどのようにパケットを開封して Contoso と Fabrikam の送信先仮想マシンに正しく送り届けるかです。

この簡単な例では、次のようなネットワーク仮想化の主要な側面に焦点を当てました。

  • 各仮想マシンの CA は物理ホストの PA にマップされます。 同じ PA に関連付けられた複数の CA が存在する場合があります。

  • 仮想マシンは CA 空間内のデータ パケットを送信します。このデータ パケットは、マッピングに基づいて PA の送信元と送信先のペアと一緒に "封筒" に入れられます。

  • CA と PA のマッピングでは、ホストがさまざまなカスタマー仮想マシン宛てのパケットを区別できるようにする必要があります。

そのため、ネットワークを仮想化するメカニズムは、仮想マシンで使用されるネットワーク アドレスを仮想化することになります。 ネットワーク コントローラーはアドレスマッピングを担当し、ホスト エージェントは MS_VTEP スキーマを使用してマッピング データベースを管理します。 次のセクションでは、実際のアドレス仮想化メカニズムについて説明します。

アドレス仮想化によるネットワーク仮想化

HNV は、Network Virtualization Generic Routing Encapsulation (NVGRE) または Virtual eXtensible Local Area Network (VXLAN) のいずれかを使用して、オーバーレイ テナント ネットワークを実装します。 既定では VXLAN です。

Virtual eXtensible Local Area Network (VXLAN)

Virtual eXtensible Local Area Network (VXLAN) (RFC 7348) プロトコルは、Cisco、Brocade、Arista、Dell、HP などのベンダーからのサポートを受け、市場で広く採用されています。 VXLAN プロトコルでは、トランスポートとして UDP が使用されます。 VXLAN の IANA 割り当て UDP 宛先ポートは 4789 であり、UDP 発信元ポートは ECMP 拡散に使用される内部パケットからの情報のハッシュである必要があります。 UDP ヘッダーの後に、VXLAN ヘッダーがパケットに追加されます。これには、予約済みの 4 バイトのフィールドの後に、VXLAN ネットワーク識別子 (VNI) の 3 バイトのフィールドが続き、その後に別の予約済みの 1 バイトのフィールドが続きます。 VXLAN ヘッダーの後に、元の CA L2 フレーム (CA イーサネット フレームの FC を使用しない) が追加されます。

VXLAN packet header

Generic Routing Encapsulation (NVGRE)

このネットワーク仮想化メカニズムでは、Generic Routing Encapsulation (NVGRE) がトンネル ヘッダーの一部として使用されます。 NVGRE では、仮想マシンのパケットは別のパケット内にカプセル化されます。 この新しいパケットのヘッダーには、図 7 に示すように、GRE ヘッダーのキー フィールドに格納される仮想サブネット ID に加えて、該当する送信元と送信先の PA IP アドレスが格納されます。

NVGRE encapsulation

図 7: ネットワーク仮想化 - NVGRE カプセル化

仮想サブネット ID により、ホストは、パケット上の PA と CA が重複する場合でも、すべてのパケットについて顧客の仮想マシンを識別できます。 これにより、図 7 に示すように、同じホスト上のすべての仮想マシンが単一の PA を共有できます。

PA の共有はネットワークのスケーラビリティに大きく影響します。 ネットワーク インフラストラクチャに覚えさせる必要がある IP アドレスと MAC アドレスの数を大幅に削減できます。 たとえば、すべてのエンド ホストに平均 30 個の仮想マシンがある場合、ネットワーク インフラストラクチャに覚えさせる必要がある IP アドレスと MAC アドレスの数は 30 の倍数だけ減少します。また、パケットに埋め込まれた仮想サブネット ID により、パケットを実際の顧客に簡単に関連付けることも可能になります。

Windows Server 2012 R2 の PA 共有スキームは、ホストごとに VSID ごとに 1 つの PA です。 Windows Server 2016 には、NIC チーム メンバーごとに 1 つの PA を設定します。

Windows Server 2016 以降では、HNV はそのままの状態で NVGRE と VXLAN を完全にサポートします。NIC (ネットワーク アダプター)、スイッチ、ルーターなどのネットワーク ハードウェアをアップグレードまたは新規購入する必要はありません。 これは、ネットワーク上のパケットが、現在のネットワーク インフラストラクチャと互換性がある PA 空間内の通常の IP パケットであるためです。 ただし、最適なパフォーマンスを得るには、タスクのオフロードをサポートする最新のドライバーでサポートされている NIC を使用します。

マルチテナント展開の例

次の図は、ネットワーク ポリシーで定義された CA-PA の関係を持つクラウド データセンターにある 2 つの顧客の展開例を示しています。

Multi-tenant deployment example

図 8: マルチテナント展開の例

図 8 の例を考えてみます。 ホスティング プロバイダーの共有 IaaS サービスに移行する前は、次のようになっています。

  • Contoso Corp は、SQL という名前の SQL Server を IP アドレス 10.1.1.11 で運用し、その SQL Server をデータベース トランザクションに使用していた Web という名前の Web サーバーを IP アドレス 10.1.1.12 で運用していました。

  • Fabrikam Corp も、SQL という名前の SQL Server を IP アドレス 10.1.1.11 で運用し、その SQL Server をデータベース トランザクションに使用していた Web という名前の Web サーバーを IP アドレス 10.1.1.12 で運用していました。

ホスティング サービス プロバイダーでは、物理ネットワーク トポロジに対応するために、ネットワーク コントローラーを介してプロバイダー (PA) 論理ネットワークを事前に作成していることを前提としています。 ネットワーク コントローラーでは、ホストが接続されている論理サブネットの IP プレフィックスから 2 つの PA IP アドレスを割り当てます。 ネットワーク コントローラーでは、IP アドレスを適用するための適切な VLAN タグも示します。

Contoso Corp と Fabrikam Corp では、ネットワーク コントローラーを使用して、ホスティング サービス プロバイダーによって指定されたプロバイダー (PA) 論理ネットワークによって支えられている仮想ネットワークとサブネットを作成します。 Contoso Corp と Fabrikam Corp は、それぞれの SQL Server と Web サーバーを、同じホスティング プロバイダーの共有 IaaS サービスに移動し、偶然にも SQL 仮想マシンを Hyper-V ホスト 1 で、Web (IIS7) 仮想マシンを Hyper-V ホスト 2 で運用します。 すべての仮想マシンには、元のイントラネット IP アドレス (各社の CA) が保たれます。

両方の企業には、次に示すように、ネットワーク コントローラーによって次の仮想サブネット ID (VSID) が割り当てられています。 各 Hyper-V ホスト上のホスト エージェントは、割り当てられた PA IP アドレスをネットワーク コントローラーから受け取り、既定以外のネットワーク コンパートメントに 2 つの PA ホスト vNIC を作成します。 次に示すように、PA IP アドレスが割り当てられている各ホスト vNIC には、ネットワーク インターフェイスが割り当てられます。

  • Contoso Corp の仮想マシン VSID と PA: VSID は 5001、SQL PA は 192.168.1.10、Web PA は 192.168.2.20

  • Fabrikam Corp の仮想マシン VSID と PA: VSID は 6001、SQL PA は 192.168.1.10、Web PA は 192.168.2.20

ネットワーク コントローラーは、(CA-PA マッピングを含む) すべてのネットワーク ポリシーを SDN ホストエージェントに対して実行します。これにより、永続的なストア (OVSDB データベース テーブル) にポリシーが保持されます。

Hyper-V Host 2 の Contoso Corp Web 仮想マシン (10.1.1.12) が、10.1.1.11 の SQL Server への TCP 接続を作成すると、次のような結果になります。

  • 宛先 MAC アドレス 10.1.1.11 の VM ARP

  • vSwitch の VFP 拡張では、このパケットをインターセプトして SDN ホスト エージェントに送信します

  • SDN ホスト エージェントでは、10.1.1.11 の MAC アドレスのポリシー ストアを検索します

  • MAC が検出された場合、ホスト エージェントでは VM に ARP 応答を挿入します

  • MAC が見つからない場合、応答は送信されず、10.1.1.11 用の VM の ARP エントリは到達不能としてマークされます。

  • VM は、正しい CA イーサネットと IP ヘッダーを使用して TCP パケットを構築し、vSwitch に送信するようになりました。

  • vSwitch の VFP 転送拡張は、パケットが受信された送信元 vSwitch ポートに割り当てられている VFP レイヤー (下記参照) を介してこのパケットを処理し、VFP 統合フロー テーブルに新しいフロー エントリを作成します。

  • VFP エンジンは、IP およびイーサネットのヘッダーに基づいて、各レイヤー (たとえば、仮想ネットワーク レイヤー) に対して規則の一致またはフローテーブル検索を実行します。

  • 仮想ネットワーク レイヤー内の一致する規則は、CA-PA マッピング領域を参照し、カプセル化を実行します。

  • カプセル化の種類 (VXLAN または NVGRE) は、VSID と共に VNet レイヤーで指定されます。

  • VXLAN カプセル化の場合、外部 UDP ヘッダーは、VXLAN ヘッダーの VSID が 5001 で構成されます。 外部 IP ヘッダーは、SDN ホスト エージェントのポリシー ストアに基づいて、それぞれ Hyper-V ホスト 2 (192.168.2.20) と Hyper-V ホスト 1 (192.168.1.10) に割り当てられた送信元と宛先の PA アドレスで構築されます。

  • その後、このパケットは VFP の PA ルーティング層に送信されます。

  • VFP の PA ルーティング層は、PA 空間トラフィックと VLAN ID に使用されるネットワーク コンパートメントを参照し、ホストの TCP/IP スタックを使用して PA パケットを Hyper-V ホスト 1 に正しく転送します。

  • カプセル化されたパケットを受信すると、Hyper-V ホスト 1 は PA ネットワーク コンパートメント内のパケットを受信し、vSwitch に転送します。

  • VFP は、その VFP レイヤーを介してパケットを処理し、VFP 統合フロー テーブルに新しいフロー エントリを作成します。

  • VFP エンジンは、仮想ネットワーク層のイングレス規則と一致し、外側にカプセル化されたパケットのイーサネット、IP、VXLAN ヘッダーを取り除きます。

  • その後、VFP エンジンは、宛先 VM が接続されている vSwitch ポートにパケットを転送します。

同様のプロセスが、Fabrikam Corp の Web 仮想マシンと SQL 仮想マシン間のトラフィックで生じる場合には、Fabrikam Corp の HNV ポリシー設定が使用されます。その結果、Fabrikam Corp の仮想マシンと Contoso Corp の仮想マシンは、HNV により、それぞれの元のイントラネット上に存在するかのように振る舞います。 同じ IP アドレスを使用していても、決して干渉し合うことはありません。

切り分けられたアドレス (CA および PA)、Hyper-V ホストのポリシー設定、仮想マシンの受信方向と送信方向のトラフィックに対して適用される CA と PA 間のアドレス変換では、NVGRE キーまたは VXLAN VNID を使用して、この 2 組のサーバーが分離されます。 さらに、仮想化のマッピングと変換により、仮想ネットワーク アーキテクチャが物理ネットワーク インフラストラクチャから切り離されます。 Contoso の SQL および Web と Fabrikam の SQL および Web は独自の CA IP サブネット (10.1.1/24) 内にありますが、それぞれの物理的な展開は異なる PA サブネット (Contoso は 192.168.1/24、Fabrikam は 192.168.2/24) 内の 2 台のホスト上で行われます。 つまり、HNV では、サブネット間での仮想マシンのプロビジョニングとライブ マイグレーションが可能になります。

Hyper-V ネットワーク仮想化のアーキテクチャ

この Windows Server 2016、HNVv2 は、Hyper-V スイッチ内の NDIS フィルタリング拡張機能である Azure 仮想フィルタリング プラットフォーム (VFP) して実装されます。 VFP の主要な概念とは、プログラミング ネットワーク ポリシーの SDN ホスト エージェントに公開された内部 API を持つ照合アクションのフロー エンジンと同じです。 SDN ホスト エージェント自体は、OVSDB および WCF SouthBound 通信チャネルを通してネットワーク コントローラーからネットワーク ポリシーを受け取ります。 仮想ネットワーク ポリシー (CA-PA マッピングなど) は VFP を使用してプログラミングされているだけでなく、ACL、QoS などの追加のポリシーです。

vSwitch および VFP 転送拡張のオブジェクト階層は次のとおりです。

  • vSwitch

    • 外部 NIC 管理

    • NIC ハードウェア オフロード

    • グローバル転送規則

    • Port

      • ヘアピン用エグレス転送レイヤー

      • マッピングと NAT プールの領域リスト

      • 統合フロー テーブル

      • VFP レイヤー

        • フロー テーブル

        • Group

        • ルール

          • 規則でのスペースの参照

VFP では、ポリシーの種類 (仮想ネットワークなど) ごとにレイヤーが作成されます。これは規則/フロー テーブルの汎用セットです。 そのような機能を実装するために特定の規則がレイヤーに割り当てられるまで、組み込み機能は提供されません。 各レイヤーには優先順位が割り当てられ、レイヤーは昇順でポートに割り当てられます。 規則は、主に方向と IP アドレス ファミリに基づいてグループに分けられます。 また、グループには優先順位も割り当てられます。多くの場合、グループの 1 つの規則が特定のフローと一致する可能性があります。

VFP 拡張を使用した vSwitch の転送ロジックは次のとおりです。

  • イングレス処理 (ポートに入ってくるパケットの観点からのイングレス)

  • 転送

  • エグレス処理 (ポートを離れるパケットの観点からのエグレス)

VFP では、NVGRE および VXLAN カプセル化の種類に対する内部 MAC 転送と、外部 MAC VLAN ベースの転送がサポートされています。

VFP 拡張機能には、パケット トラバーサルの低速パスと高速パスがあります。 フロー内の最初のパケットは、各レイヤー内のすべての規則グループを走査し、コストの高い操作である規則参照を実行する必要があります。 ただし、フローが統合フロー テーブルに登録され、(一致した規則に基づく) アクションの一覧が表示された後、それ以降のすべてのパケットは、統合フロー テーブルのエントリに基づいて処理されます。

HNV ポリシーは、ホスト エージェントによってプログラミングされます。 各仮想マシン ネットワーク アダプターは、IPv4 アドレスで構成されます。 これらは仮想マシンが相互通信に使用する CA で、仮想マシンから IP パケットで伝送されます。 HNV は、ホスト エージェントのデータベースに格納されているネットワーク仮想化ポリシーに基づいて、CA フレームを PA フレームにカプセル化します。

HNV Architecture

図 9: HNV アーキテクチャ

まとめ

クラウド ベースのデータセンターは、スケーラビリティの向上やリソース使用効率の改善など多数のメリットを提供します。 これらの潜在的メリットを実現するには、動的環境におけるマルチテナントのスケーラビリティの問題を根本的に解決するテクノロジが必要です。 HNV は、こうした問題を解決し、また物理ネットワーク トポロジに対して仮想ネットワーク トポロジを分離することによりデータセンターの運用効率を向上させるように設計されました。 既存の標準を基盤として、HNV は現在のデータセンターで実行され、既存の VXLAN インフラストラクチャで動作します。 HNV を導入した顧客は、自社のデータセンターをプライベート クラウドに統合したり、ハイブリッド クラウドを備えたホスト サーバー プロバイダーの環境にシームレスに拡張したりできるようになります。

HNVv2 について詳しくは、次のリンクをご覧ください。

コンテンツ タイプ 参考資料
コミュニティ リソース - プライベート クラウド アーキテクチャのブログ
- 質問の送り先: cloudnetfb@microsoft.com
RFC - NVGRE ドラフト RFC
- VXLAN - RFC 7348
関連テクノロジ - Hyper-V ネットワーク仮想化の技術的な詳細については、Windows Server 2012 R2 の「Hyper-V ネットワーク仮想化の技術的な詳細」を参照してください。
- ネットワーク コントローラー