Windows Server 2012は、まったく新しいレベル（ネットワークセグメントレベル）で仮想化を可能にするネットワーク仮想化（NV）テクノロジーを導入しました。 通常のサーバー仮想化とは異なり、NVではIPサブネットを仮想化し、インフラストラクチャで使用される実際のIPアドレスを仮想マシン（VM）およびVM内のアプリケーションから完全に隠すことができます。 同時に、VMは他の物理ホスト、他のサブネット上のホストと相互にやり取りできます。



技術的な観点から見ると、ネットワーク仮想化はかなり複雑なメカニズムであるため、おそらく、1つのポスト内でこの技術の多かれ少なかれ完全な概要は失敗します。 今日は概念とアーキテクチャについて説明し、次の投稿でNVの構成に焦点を当て、仮想化ネットワークで実行されているVMへの外部アクセスの組織について個別に説明します。



基本的な質問から始めましょう。「なぜネットワーク仮想化が必要なのですか？」

ネットワーク仮想化とは何ですか？

いくつかの注意事項があるサーバー仮想化の場合、VM内のOSは、物理サーバーにインストールされ、この機器の唯一のOSであるかのように機能します。 このような抽象化により、1つの物理サーバー上で仮想サーバーの複数の分離されたインスタンスを実行できます。 類推すると、ネットワーク仮想化は、仮想、またはこのコンテキストでは仮想化されたネットワークが物理ネットワークであるかのように機能するという事実につながります。 したがって、このレベルの仮想化により、同じ物理ネットワークインフラストラクチャ上で、IPアドレススペースが重複または完全に一致する可能性がある複数の仮想ネットワークを作成して使用できます。 また、このネットワークインフラストラクチャは、一般的に言えば、任意の数の物理サーバーとネットワーク機器を含むことができます（下図を参照）。







上の図では、異なる部門または組織に属する青いネットワークと赤いネットワークの仮想マシンは同じIPアドレスを使用でき、同じまたは異なる物理ホストで実行できますが、一方で、相互に完全に隔離されている一方で、問題なく、部門または組織の他のネットワークオブジェクト（実際または仮想）と対話します。 これは、NVテクノロジーの目的、そのアプリケーションの利点と主なシナリオを意味します。



データセンター内でのVMのホスティングにおける柔軟性の向上



NVは、データセンター内でVMをホストするときにある程度の自由度を提供します。 特に、VMをホストするには、物理​​ネットワークセグメントに対応するIPアドレスを構成し、VLANを構成して分離を提供する必要があります。 NVは同じVMホスト上で一致するIPアドレスとの共存を許可するため、データセンターで使用されるIPアドレス指定スキームに拘束されなくなり、VLANによって課される制限に制限されなくなります。



クラウドへのVM移行の簡素化



ネットワーク仮想化を使用する場合、VMのIPアドレスと設定は変更されないため、VMを組織の次のデータセンター、ホストのクラウド、またはパブリッククラウドに転送するプロセスが大幅に簡素化されます。 アプリケーションクライアントとIT管理者の両方が、再構成せずにVM /アプリケーションと対話するために引き続きツールを使用します。



サブネットからのライブマイグレーション



動的なVM移行は、IPサブネット（またはVLAN）によって制限されます。 VMを別のサブネットに移行する場合、ゲストOS内のIPを再構成する必要があり、その後の結果はすべて発生します。 ただし、NVをオンにしたWindows Server 2012で2つのホスト間で動的移行を実行する場合、ホストは物理ネットワークの異なるセグメントに配置できますが、ネットワーク仮想化により、移動したVMのネットワーク通信の継続性が保証されます。



物理ホストとネットワークリソースの使用率の増加



IPアドレスとVLANに依存しないため、物理ホストをより均等にロードし、利用可能なリソースをより効率的に利用できます。 NVはVLANをサポートしているため、たとえば、専用のVLANでNVトラフィックを分離するなど、両方の分離方法を組み合わせることができます。

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

NVを構成する場合、IPアドレスのペアが各仮想ネットワークアダプター（vNIC）に関連付けられます。

• 顧客の住所（CA） VM内で顧客が構成したアドレス。 このアドレスは、VM自体とその内部のOSに表示されます。このアドレスでは、VMは顧客のインフラストラクチャに表示されます。VMがデータセンター内またはそれ以降に移動しても、このアドレスは変更されません。
  
  
• プロバイダーアドレス（PA） 物理ネットワークインフラストラクチャに基づいて、データセンター管理者またはホスティング事業者によって割り当てられたアドレス。 このアドレスは、VMが実行され、NVテクノロジーが構成されているHyper-Vホスト間でネットワークを介してパケットを送信するときに使用されます。 このアドレスは物理ネットワークセグメントでは表示されますが、VMおよびゲストOSでは表示されません。
  
  

ネットワークインタラクションのプロセスでは、VMはCA空間からの送信者と受信者のアドレスでパケットを形成します。 このようなパケットはVMを離れ、Hyper-VホストはPAスペースからの送信者と受信者のアドレスを含むパケットにパックされます。 PAアドレスは、仮想化ポリシーテーブルに基づいて決定されます。 その後、パケットは物理ネットワークを介して送信されます。 同じ仮想化ポリシーテーブルに基づいてパケットを受信したHyper-Vホストは、逆の手順を実行します。ソースパケットを抽出し、宛先VMを決定し、目的のVMのCAアドレスでソースパケットをリダイレクトします。



したがって、ネットワーク仮想化は、最終的には仮想マシンが使用するアドレスの仮想化に帰着します。 次に、Hyper-V Windows Server 2012のアドレス仮想化は、2つのメカニズムを使用して可能になります。汎用ルーティングカプセル化とIP書き換えです。 それぞれについて簡単に考えてみましょう。

汎用ルーティングカプセル化

最初のメカニズムでは、CAアドレスを持つソースパケットはGRE構造にカプセル化され（Generic Routing Encapsulation、 RFC 2890を参照）、必要なPAアドレスを持つIPパケットにパックされます。 送信元パケットが属する一意の仮想サブネット識別子（図の仮想サブネットID、「GREキー」フィールド）、および送信側と受信側のVMの仮想ネットワークアダプターのMACアドレスもGREヘッダーに追加されます。







サブネット識別子を使用すると、異なる顧客のVMのCAアドレスが一致する場合でも、受信ホストはパケットの対象となるVMを正しく判断できます。 このメカニズムの2番目の重要な機能は、ホストで実行されているVMの数に関係なく、1つのPAアドレスで任意のVMからパケットを転送できることです。 これは、GREアドレス仮想化メカニズムを使用する場合のソリューションのスケーラビリティに大きく影響します。 最後に、説明したスキームは既存のネットワーク機器と完全に互換性があり、ネットワークアダプター、スイッチ、またはルーターの更新を必要としないことに注意してください。



ただし、将来的には、スイッチまたはルーターがパケットの仮想サブネットIDフィールドを分析することは不適切ではなく、管理者はこのフィールドに基づいてパケットをスイッチングまたはルーティングするための適切なルールを構成できます。 または、たとえば、ネットワークアダプターであるGREのパッキングとアンパッキングに関連するすべてのタスクを処理します。 この目的のために、マイクロソフトはパートナーとともに、 NVGRE標準（Generic Routing Encapsulationを使用したネットワーク仮想化）を開発しました 。これは現在IETFドラフト段階にあります。 特に、この標準のフレームワーク内では、サブネット識別子、NVGREパケットを示すプロトコルタイプ0x6558、およびその他のニュアンスを格納するための24ビットのテナントネットワーク識別子（TNI）フィールドが規制されています。

IP書き換え

イデオロギーの2番目のメカニズムはやや単純です。 各CAアドレスには、一意のPAアドレスが割り当てられます。 パケットがVMから送信されると、Hyper-VホストはIPパケットヘッダーのCAアドレスをPAアドレスに置き換えて、パケットをネットワークに送信します。 受信ホストは、逆アドレス置換を実行し、VMパケットを配信します。 説明したアルゴリズムからわかるように、Hyper-Vの役割を持つ各物理ホストでは、ネットワーク仮想化を使用するこのホストで実行されているすべての仮想マシンで使用されるCAアドレスと同じ数のPAアドレスを構成する必要があります。







パッケージをGREでカプセル化するには、追加のオーバーヘッドが必要です。 したがって、10Gbpsアダプターを積極的に使用するVMなど、帯域幅の要件が高いシナリオでは、IP Rewriteも推奨されます。 他のほとんどの場合、GREメカニズムが最適です。 NVGREをサポートする機器の出現により、このメカニズムはIPリライトのパフォーマンスに劣ることはありません。

顧客ネットワークと仮想サブネット

Hyper-Vネットワーク仮想化の用語では、顧客はデータセンターに展開されたVMのグループの「所有者」です。 実際には、ホスティングサービスプロバイダーのデータセンターについて話している場合、そのような顧客は会社または組織である可能性があります。 プライベートクラウドについて話している場合、原則として顧客は組織の部門または部門です。 いずれの場合でも、顧客は1つ以上のネットワーク（顧客ネットワーク）を所有でき、そのようなネットワークはそれぞれ1つ以上の仮想サブネット（仮想サブネット）で構成されます。



顧客ネットワーク

• 顧客のネットワークは、仮想マシンの分離境界を定義します。 つまり、同じ顧客ネットワークに属するVMは相互に対話できます。 その結果、同じ顧客ネットワークに属する仮想サブネットは、重複するIPアドレススペースを使用してはなりません。
  
  
• 各顧客のネットワークは、データセンター管理者またはSystem Center 2012 Virtual Machine Managerなどのソフトウェアマネージャーによって割り当てられる特別なルーティングドメインID（RDID）を使用して識別されます。 RDIDには、{11111111-2222-3333-4444-000000000000}などのグローバル識別子（GUID）形式があります。
  
  

仮想サブネット

• 仮想サブネットはIPサブネットのセマンティクスを使用するため、VMのブロードキャストドメインを定義します。 同じ仮想サブネット上の仮想マシンは、同じIPプレフィックスを使用する必要があります。つまり、同じIPサブネットに属します。
  
  
• 各仮想サブネットは、1つの顧客のネットワーク（1つのRDIDに関連付けられている）に属し、既知の一意の仮想サブネットID（VSID）によって識別されます。 VSIDは、4096から2 ^ 24-2までの値を取ることができます。
  
  

これら2つの概念を適用することにより、顧客はネットワークトポロジをクラウドに転送できます。 図 2つのSiniyeネットワーク（R＆Dネットワークと営業部ネットワーク）を以下に示します。 最初は、これらのネットワークは分離されており、相互にやり取りするべきではありません。 Hyper-Vネットワーク仮想化環境への転送中、これらのネットワークには異なるRDIDが割り当てられるため、これらのネットワークのVMはお互いを「見る」ことができません。 同時に、たとえば、R＆Dネットワークの仮想サブネット1、2、および3のVMはパケットを交換できます。

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

NVは、Windows Server 2012でのみ使用可能です。



Hyper-Vネットワーク仮想化を備えたホストは、CAおよびPAスペース、RDIDおよびVSIDに関する情報を実際に設定および保存し、仮想化メカニズムに対処する仮想化ポリシーをサポートする必要があります。 Windows Server 2012には、ソフトウェアがNVのあらゆる側面を管理できるプログラミングインターフェイス（API）のセットが含まれています。 最も単純なケースでは、このような管理ソフトウェアはPowerShellスクリプトである可能性があり、産業シナリオでは、この役割はSystem Center 2012 Virtual Machine Manager SP1（VMM）によって果たされます。 Windows Server 2012のサポートが登場したのはSystem Center 2012のSP1のリリースであったため、NVであることに注目してください。



仮想化ポリシーで指定された設定は、Windows Network Virtualization（WNV）と呼ばれるNetwork Filter Interface Specification（NDIS）ドライバーによって直接適用されます。 WNVフィルターは、Hyper-V拡張可能スイッチの下にあります。 つまり、Hyper-Vスイッチとそのすべての拡張機能（存在する場合）はCAアドレスで機能し、PAアドレスについては何も知りません。 ただし、VSIDはスイッチと拡張機能からアクセスできるため、Hyper-V拡張スイッチは、たとえば、異なる顧客に属する10.0.0.5 CAアドレスを区別できます。







VMでネットワーク仮想化が有効になっている場合、このVMの仮想ネットワークアダプターが接続されているHyper-V拡張スイッチポートでは、ハイパーバイザーにアクセス制御リスト（ACL）が含まれます。 ここで ACLについて詳しく説明しました 。 ACLは、VMが属する仮想サブネットのVSIDを示します。 ACLで指定されたもの以外のVSIDでこのスイッチポートに到着するパケットは無視されます。



このロジックを考慮すると、パケットの移動は次のようになります。 Hyper-V拡張スイッチポートを介したVMからの発信パケットはWNVフィルターに入り、NV仮想化ポリシーを分析し、必要な操作をパケットに適用し（IPアドレスを置き換えるか、GREでパッキング）、その後、パケットがネットワークに送信されます。



受信側では、着信パケットはWNVフィルターに入り、NV仮想化ポリシーを分析します。 着信パケットがGREパケットである場合、フィルターはGREヘッダーからVSIDフィールドを読み取り、元のIPパケットを抽出し、VSIDとともに、仮想マシンのvNICが受信者アドレスに対応するCAアドレスに接続されているHyper-V拡張スイッチポートに送信します送信元IPパケットのヘッダー内。 送信されたVSIDがこのポートのACLのVSIDと一致する場合、スイッチはパケットを仮想マシンに渡します。 使用される仮想化メカニズムがIP書き換えである場合、フィルターは、仮想化ポリシーからの情報に基づいて、パケット内のPAアドレスをCAアドレスに変更し、PAとCAアドレスの同じペアからVSIDを識別し、VSIDとともにCAアドレスを持つパケットを送信します適切なHyper-V拡張スイッチポートに。 送信されたVSIDがこのポートのACLのVSIDと一致する場合、スイッチはパケットを仮想マシンに渡します。



説明されているロジックは、Windows Server 2012と昇格されたHyper-Vの役割を持つ同じホストまたは異なるホストにあるVM間でパケットが転送されるときに適用されます。 たとえば、特定のビジネスアプリケーションが実行されているVMからのパッケージが、このビジネスアプリケーションのクライアント部分でワークステーションに到達する必要がある場合、状況はやや複雑になります。 この場合、Hyper-Vネットワーク仮想化ゲートウェイを構成する必要があります。これについては、別途説明します。



次の投稿では、1）PowerShellスクリプト、2）VMMを使用してNVを構成する方法を説明します。

それまでの間、次のことができます。

• コース「 Windows Server 2012の新機能。パート1.仮想化、ネットワーク、ストレージ 」の最初のモジュールで、ネットワーク仮想化の実際の動作をご覧ください。
  
  
• Windows Server 2012ネットワークインフラストラクチャコースの3番目のモジュールで、Hyper-Vネットワーク仮想化に関する詳細情報を入手してください。
  
  
• 元のプレゼンテーション （英語）、この投稿で使用したスライド、NVでのパケットフロープロセスの詳細な説明をダウンロードします。
  
  

資料が役に立てば幸いです。



よろしくお願いします！