この記事の英語版を表示するには、[英語] のチェック ボックスをオンにしてください。また、テキストにマウス ポインターを合わせると、ポップアップ ウィンドウに英語のテキストを表示することもできます。
翻訳
英語

Hyper-V ネットワーク仮想化ゲートウェイのアーキテクチャ ガイド

 

適用対象: Windows Server 2012 R2,Windows Server 2012

Windows Server 2012 には、Hyper-V ネットワーク仮想化と呼ばれるスケーラブルで安全性に優れたマルチテナント ソリューションが導入されています。 このテクノロジは、クラウド データセンターの構築に使用することができます。これによって、ネットワーク インフラストラクチャをプライベート クラウド、ハイブリッド クラウド、およびパブリック クラウドに、より簡単な方法で段階的に移行できるようになります。

Hyper-V ネットワーク仮想化の概要については、Microsoft TechNet Web サイトに掲載されている「Hyper-V ネットワーク仮想化の概要」、「Hyper-V ネットワーク仮想化の技術的な詳細」、および「Windows Server® 2012 Hyper-V ネットワーク仮想化サバイバル ガイド」を参照してください。

Hyper-V ネットワーク仮想化は、既存のサーバーおよびスイッチ ハードウェアで展開できます。 ただし、プライベート クラウド、クロス プレミス、およびハイブリッド クラウドの展開など、主なシナリオを完了するには、データセンター管理ソリューションに加えて、ゲートウェイ機能が必要です。

この記事では、各種の Hyper-V ネットワーク仮想化ゲートウェイおよびゲートウェイ機能の要件について説明します。 既存のネットワーク アプライアンスには Hyper-V ネットワーク仮想化ゲートウェイ機能が組み込まれている場合があるので、ゲートウェイ機能については明記されます。 Hyper-V ネットワーク仮想化で使用されるパケット カプセル化形式の技術的な詳細については、「NVGRE ドラフト RFC」を参照してください。

お客様のほとんどの展開では、ネットワーク仮想化が行われる環境からネットワーク仮想化が行われない環境への通信を必要とします。 したがって、この 2 つの環境をつなぐには Hyper-V ネットワーク仮想化ゲートウェイが必要です。

ゲートウェイはさまざまなフォーム ファクターで提供されます。Windows Server 2012 上に構築されていたり、トップ オブ ラック (TOR) スイッチに統合されていたり、既存のネットワーク アプライアンスに組み込まれていたりします。あるいは、スタンドアロンのネットワーク アプライアンスで提供されることもあります。 「プライベート クラウド」セクションで説明するプライベート クラウド シナリオには、ルーティング機能が必要です。 ハイブリッド クラウド シナリオ (「ハイブリッド クラウド」セクションで説明) には、ルーティングに加えて VPN 機能も必要です。 3 番目のシナリオでは、ゲートウェイ機能がロード バランサーに組み込まれています (「ロード バランサー」セクションで説明)。

大企業では、一部のサービスやデータをパブリック クラウドのホスト側に移行することを嫌がったり、コンプライアンス上の理由からそれを実施できないことがあります。 ただし、それでも企業は、データセンター リソースをプライベート クラウドに統合することによってクラウドおよびネットワーク仮想化のメリットを享受したいと考えています。 プライベート クラウド展開では、企業はルーティング不可能な内部アドレス空間 (たとえば、10.x.x.x または 192.x.x.x) を十分に備えているため、重複する IP アドレスは必要ない場合があります。 図 1 の例を考えてみます。

図 1:プライベート クラウド展開

図 1: プライベート クラウド展開

この例では、仮想サブネット内のカスタマー アドレスが 10.229.x の IP アドレスであり、一方、ネットワーク仮想化が行われないネットワーク部分 (CorpNet) の IP アドレスが 10.229.1 アドレスであることに注意してください。 この例では、データセンター内の仮想サブネットの PA アドレスは 10.60.x IP アドレスです。 この展開では、企業は、データセンター ファブリック内での仮想マシンの配置とサブネット間のライブ マイグレーションを柔軟に行うことができるという Hyper-V ネットワーク仮想化のメリットを得ることができます。 これにより、データセンターの効率性が向上し、運用経費 (OpEx) と設備経費 (CapEx) の両方が減少します。

図 1 に示すプライベート クラウド シナリオでは、プライベート クラウド ゲートウェイ アプライアンスまたは既存のネットワーク アプライアンスに組み込まれたゲートウェイ機能を必要とします。 プライベート クラウド ゲートウェイの目的は、物理アドレスと仮想アドレスの間のルーティングおよび切り替えを実現することにあります。

Hyper-V ネットワーク仮想化の主な利点は、社内データセンターを Windows Server 2012 ベースのクラウド データセンターにシームレスに拡張できることです。 これは、図 2 に示すように、ハイブリッド クラウド モデルと呼ばれます。

図 2:ハイブリッド クラウド展開

図 2: ハイブリッド クラウド展開

このシナリオでは、Web サーバーなどの内部サーバーがエンタープライズ ネットワークからクラウドのホスト側のデータセンターに移行されます。 企業は、ホスト側によって提供される自社の IP アドレスの持ち込みを活用することで、Web サーバー仮想マシンや、その Web サーバーを参照する他のネットワーク エンドポイントのネットワーク構成を変更する必要がなくなります。 ホスト側では VPN ゲートウェイ アプライアンスを介してセキュリティで保護されたリンクを提供します。 企業の管理者は、社内 VPN を適切な IP アドレスで構成するだけで済みます。 Web サーバー仮想マシンは、クラウドに移動されたことを認識しません。 Active Directory (AD) でドメインに参加したままで、企業の DNS サーバーを使用します。 Web サーバー仮想マシンはまた、SQL Server などの企業内の他のサーバーとも引き続きやり取りします。 この例では、これら 3 つのサービス (AD、DNS、SQL) はすべて社内に残ります。 送信元と送信先の間のネットワーク ホップ数をカウントする tracert などのネットワーク診断ツールでは、Web サーバー仮想マシンと SQL の間のネットワーク トラフィックはもうローカルではなく、インターネット経由でルーティングされると表示されます。

図 2 に示すハイブリッド クラウド シナリオでは、ネットワーク仮想化ゲートウェイ アプライアンスなど、マルチテナント VPN アプライアンスが必要です。 VPN アプライアンス ゲートウェイは、データセンター オーケストレータ (System Center Virtual Machine Manager など) とやり取りして適切なネットワーク仮想化ポリシーを取得する必要があります。

ロード バランサーは、単一の IP アドレス (仮想 IP アドレスまたは VIP) のイメージを、サービスを要求するクライアントに提供します。 複数の異なる IP アドレス (ダイレクト IP アドレスまたは DIP) にサービスが実装されます。 従来のロード バランサーは、VIP からのネットワーク トラフィックをネットワーク アドレス変換 (NAT) 経由で DIP にマップします。 ロード バランサーは、着信パケットの宛先 IP アドレス (VIP) を、サービスを実行するロード バランサーの背後の IP アドレス (DIP) のいずれかで書き直します。 ロード バランサーが双方向 NAT として動作している場合、DIP はロード バランサーにリターン パケットを送信します。ロード バランサーは発信元 IP (DIP) を VIP で書き直します。 この場合、クライアントは VIP のみを認識するだけで、DIP には気付きません。

System_CAPS_noteメモ

Windows Server 2012 R2 および Windows Server 2012 では、ネットワーク負荷分散が Hyper-V ネットワーク仮想化と完全には統合されていません。 ただし、サード パーティ パートナーのロード バランサー ソリューションが用意されており、Hyper-V ネットワーク仮想化ゲートウェイ機能と組み合わせて、Hyper-V ネットワーク仮想化ベースの仮想ネットワーク内で負荷分散を有効にするために使用できます。 ロード バランサーを Hyper-V ネットワーク仮想化ゲートウェイとして使用するには、System Center Virtual Machine Manager (VMM) の修正プログラムが必要です。 ネットワーク負荷分散の詳細については、「ネットワーク負荷分散の概要」を参照してください。

次のシナリオについて検討します。このシナリオでは、Blue 社と Red 社が、テナントの間で負荷分散を行う同じマルチテナント データセンター内にそれぞれの仮想マシンを備えています。 Blue 社は、ロード バランサーの内側でサービスを提供する 4 つの仮想マシンを備えています。 Red 社は、負荷分散の必要がある異なるサービスを提供する 2 つの仮想マシンを備えています。

図 3:ロード バランサーとポリシー

図 3: 複数テナントのロード バランサーの例

図 3 に、パブリックにルーティング可能な IP アドレスが複数の接続先の仮想マシン間で負荷分散される仮想トポロジを示します。 たとえば、インターネットからのクライアントはトラフィックを Blue 社のパブリック IP (VIP) に送信します。 ネットワーク仮想化ポリシーに基づいて動作するロード バランサーは、NVGRE パケットを出力し、そのパケットを適切な Hyper-V ホストに届けます。 Hyper-V ホストは、そのパケットをカプセル化解除し、接続先の仮想マシンに配信します。

図 4:階層間の負荷分散

図 4: 複数テナントのロード バランサーの展開

図 4 に、図 3 について可能な展開を示します。 この場合、負荷分散される仮想マシンの PA 空間は 192.168.6.x です。 Blue 社の顧客は、3 台の物理的なホストを実行する 4 つの仮想マシンを備えています。 Red 社の顧客は、2 つの仮想マシンを 2 台の異なるホスト上で実行しています。 Blue 社も Red 社も Web サービスをホストしています。 外部環境からこれらのサービスには、パブリックにルーティングできる適切な VIP (Blue 社の VIP と Red 社の VIP) を介してアクセスします。 ネットワーク仮想化ポリシーを使用しているロード バランサーは、適切な NVGRE パケットを生成します。

ClientIP から開始され、Blue 社の VIP に送信される接続を Blue 社の VM2 に負荷分散する場合について検討します。 ロード バランサーは、VSID が BlueVSID1、CA が 10.1.6.21、PA が 192.168.6.4 である Blue 社の VM2 にパケットを送信する必要があります。 ロード バランサーの PA は 192.168.6.2 です。 したがって、ロード バランサーは次の NVGRE パケット ヘッダーを生成します。

MACLB --> MACH1

192.168.6.2 --> 192.168.6.4

BlueVSID1

MACext --> MACVM2

ClientIP --> 10.1.6.21

次に、図 5 に示すシナリオについて検討します。このシナリオでは、Blue 社と Red 社の顧客が負荷分散を必要とする多層アプリケーションを備えています。 仮想マシンの観点から、それらは VIP1 を介して次の階層との通信を行います。 たとえば、Tier B1 内の仮想マシンは、Blue VIP1 を介して Tier B2 内の仮想マシンと通信します。 Blue 社の VIP1 は Blue 社の CA IP アドレスです。これには、ロード バランサー上の対応する PA アドレスも含められます。 可能な展開トポロジを図 6 に示します。

図 5:内部に配置されたロード バランサー

図 5: 階層間の負荷分散 (論理的な観点)

図 6:内部に配置されたロード バランサー

図 6: データセンター内部に配置されたロード バランサー

ロード バランサー上の Blue 社の CA VIP と Red 社の CA VIP の PA は 192.168.6.2 です。 ロード バランサーは NVGRE パケット内の VSID を調べて、VIP と DIP との適切なマッピングを決定する必要があります。 たとえば、Blue 社の仮想マシン 11 は Blue 社の CA VIP にパケットを送信します。 NVGRE パケット ヘッダーには、送信元 IP: 192.168.6.7、宛先 IP: 192.168.6.2、GRE キー フィールド Blue VSID1、内部送信元 IP: 10.1.5.20、内部宛先 IP: Blue CA VIP、および元のパケットの残りの部分が含まれます。 重複する CA IP アドレスを使用すると VIP 自体が一意でない場合があるので、VSID と VIP の両方でロード バランサーのポリシーが一致する必要があります。

ゲートウェイは Hyper-V ネットワーク仮想化ポリシーを含み、Windows Server 2012 ホストと同様のアクションを実行する必要があります。 通常の展開では、Windows Server 2012 ホストは、ホスト内に配置されているすべての仮想マシンのどのルーティング ドメインについてもポリシー情報をすべて認識します。 たとえば、ホストが、ルーティング ドメイン X の仮想マシンと、ルーティング ドメイン Y からの別の仮想マシンを有している場合、そのホストは、ルーティング ドメイン X とルーティング ドメイン Y の両方に含まれるすべての仮想サブネットに関するすべてのポリシー情報を有します。単一のルーティング ドメインの場合でも、大量のポリシーをすべての Hyper-V ホストに含めることが必要になると考えられます。

図 1 に示すプライベート クラウドの場合について検討します。 このシナリオで、企業は単一のルーティング ドメインを使用する内部クラウドを備えています。 この場合は、どの Hyper-V ホストも、ネットワーク仮想化が行われる仮想マシンすべてに対するポリシーを有する必要があります。 これにより、すべてのホストでこのポリシーを管理するデータセンター オーケストレータに負担がかかる可能性があります。 仮想マシンが企業内の他のどの仮想サブネットとも実際に通信することはまれであるため、当該ホスト上にあるこのポリシーの大部分は実際には不要です。

各ホスト上で必要なポリシーを削減するために、Windows Server 2012 ホストを特殊モードにすることができます。このモードでは、ホストは、独自のホスト ポリシーに基づいて指定された仮想サブネット内でトラフィックをルーティングします。 クロス仮想サブネット トラフィックは、外部ルーターに送信されて、ネットワーク仮想化ポリシーの確認が行われ、パケットがパスに沿って最終的な宛先に転送されます。 このような展開では、ホストは、ホスト上で実行されている仮想マシンのルーティング ドメインのすべての仮想サブネットについてポリシーを認識するのでなく、ホスト上で実行されている仮想マシンの仮想サブネットについてポリシーを認識するだけで済みます。 このシナリオでは、Hyper-V ネットワーク仮想化ゲートウェイがすべてのクロスサブネット ルーティングに関する決定を下します。 Hyper-V ネットワーク仮想化ゲートウェイは、パケットをルーティングする先の仮想サブネットにあるすべての仮想マシンのすべてのポリシー情報を保持する必要があります。

Hyper-V ネットワーク仮想化の展開では、データセンター オーケストレータが必要です。 そのようなデータセンター オーケストレータの 1 つとして、System Center Virtual Machine Manager (VMM) があります。 データセンター オーケストレータは、Hyper-V ネットワーク仮想化ポリシーを適切なゲートウェイ アプライアンスに届けるメカニズムを提供する役割を果たします。 なお、PA IP ルーティングは、データセンター オーケストレータで管理されません。

Hyper-V ネットワーク仮想化ゲートウェイ パートナーは、ゲートウェイ アプライアンスまたはアプライアンス機能の基本的な構成を行うための管理コンソールを提供する必要があります。 この管理コンソールでは、PA 割り当て、高可用性、モニタリング、認証などの操作を処理します。 管理コンソールは、VMM などのデータセンター オーケストレータによって管理されないゲートウェイの側面を構成する役割を果たします。

複数の物理的な Hyper-V ネットワーク仮想化ゲートウェイを使用して実現する高可用性については、ここでは取り上げません。 データセンター オーケストレータ (VMM など) では、ゲートウェイを構成および管理することが必要になります。 データセンターで複数のゲートウェイを展開するシナリオには、スケーラビリティと回復性が含まれます。 スケーラビリティについては、単一の物理ゲートウェイでは、データセンターに必要な負荷を処理できない場合があります。 さらに、単一のゲートウェイでは単一障害点が発生します。 パートナーの管理コンソールでは、複数のゲートウェイから成る展開を処理する必要があります。

VMM モジュールでは、Hyper-V ネットワーク仮想化ゲートウェイが PowerShell プラグイン モジュールを介して管理されます。 Hyper-V ネットワーク仮想化ゲートウェイを構築するパートナーは、VMM サーバーで物理的に実行される PowerShell プラグイン モジュールを作成する必要があります。 このプラグイン モジュールは、ポリシーをゲートウェイに伝達します。 図 7 に、Hyper-V ネットワーク仮想化の展開を管理する VMM のブロック図を示します。 パートナーのプラグインは VMM サーバー内で実行されることに注意してください。 このプラグインはゲートウェイ アプライアンスと通信します。 この通信に使用されるプロトコルは、ここで指定していません。 パートナーは適切なプロトコルを決定できます。 VMM は、Windows リモート管理 (WinRM) および Windows Management Instrumentation (WMI) と呼ばれる WS-Management プロトコルの Microsoft 実装を使用して、Windows Server 2012 ホストを管理し、ネットワーク仮想化ポリシーを更新します。

図 7:System Center を使用して管理する

図 7: System Center を使用した Hyper-V ネットワーク仮想化の管理

Windows Server 2012 は、Hyper-V ネットワーク仮想化ゲートウェイ アプライアンスのベース プラットフォームとして使用できます。

図 8 に、Windows Server 2012 をベース プラットフォームとして使用するプライベート クラウド ルーターのアーキテクチャを示します。 このシナリオでは、すべての仮想マシンが同じルーティング ドメイン内に入っています。 赤、青、紫の仮想マシンの CA IP プレフィックスはそれぞれ 157.4、157.3、157.2 です。 CorpNet 上のサービスの IP アドレスにはプレフィックス 157.1 が付いています。

図 8:プライベート クラウド ゲートウェイ

図 8: Windows Server 2012 を使用したプライベート クラウド ゲートウェイ

ゲートウェイ内の WNV フィルターは、赤、青、紫の仮想サブネットからトラフィックを受信し、それを親 (管理) オペレーティング システム スタックを介して CorpNet に送信します。 仮想スイッチは、ネットワーク仮想化が行われる環境からホスト オペレーティング システム スタックへの通信に必要な親 (ホスト) VNIC を備えています。 他のネットワーク インターフェイスは、CorpNet に接続される物理ネットワーク インターフェイス (pnic2) にバインドされます。 図 8 に示す Hyper-V ネットワーク仮想化ゲートウェイでは、物理ネットワーク インターフェイスが 2 つ存在する必要はありません。 単一の物理ネットワーク インターフェイスを、2 つの親仮想ネットワーク インターフェイスと一緒に使用することが可能です。 ただし、データセンターの管理者はトラフィックを物理的に分離することを好む場合があります。 ゲートウェイ内に 2 つの物理ネットワーク インターフェイスがあれば、データセンターと CorpNet の統合されたトラフィックは、さまざまな物理スイッチを介してゲートウェイとやり取りすることができます。 2 つの物理ネットワーク インターフェイス (ネットワーク仮想化が行われる環境に 1 つ、ネットワーク仮想化が行われない環境に 1 つ) を使用すれば、お客様の展開の柔軟性を高めることができます。

ハイブリッド クラウド シナリオを採用した場合、企業はオンプレミス データセンターをシームレスにクラウドに拡張できます。 これにはサイト間 VPN トンネルが必要です。 これは、ホスト プラットフォームとして機能する Windows Server 2012 と、テナント別 Windows Server 2012 ゲスト仮想マシン (クラウド データセンターをさまざまなオンプレミス データセンターに接続するサイト間 (S2S) VPN トンネルを実行する) とを使用して実現できます。Windows Server 2012 S2S VPN は IKEv2 をサポートしており、リモート ポリシーの構成は PowerShell/WMI を介して実現できます。 さらに、Windows Server 2012 ゲスト仮想マシンでは、ゲートウェイ アプライアンスのパフォーマンスおよびスケーラビリティを強化する新しいネットワーク インターフェイス オフロード機能もサポートしています。 このようなオフロード機能については、後の「ハードウェアに関する考慮事項」セクションで説明します。

図 9:ハイブリッド クラウドと Windows Server 2012

図 9: Windows Server 2012 ベースのゲートウェイを備えるハイブリッド クラウド

図 9 に、Red 社と Blue 社がホスト クラウドの顧客である場合のシナリオを示します。 Red 社と Blue 社はデータセンターをホスト側のクラウドにシームレスに拡張します。このホスト側のクラウドは、Windows Server 2012 ベースのテナント別仮想マシン ゲートウェイを展開済みで、Red 社と Blue 社がシームレスにオンプレミス データセンターを拡張できるようにしています。 図 10 では、Red 社も Blue 社も Windows Server 2012 S2S VPN を実行する必要はありません。ただし、顧客のオンプレミス S2S VPN は IKEv2 をサポートして、HostGW で実行される対応する Windows Server 2012 S2S 仮想マシンとやり取りする必要があります。

図 9 に、HostGW の内部アーキテクチャを示します。 各ルーティング ドメインは、独自の仮想マシンを必要とします。 この技術的な理由として、vmnic は単一の仮想サブネット (VSID) にしか関連付けできず、VSID は単一のルーティング ドメインにしか属せないということが挙げられます。 VSID スイッチ ポート ACL は、VSID のトランキングをサポートしていません。 したがって、テナント別 (ルーティング ドメイン) ゲートウェイ仮想マシンを使用するのが、分離するための最も簡単な方法です。

各仮想マシンはデュアル ホーム型です。すなわち、それぞれが 2 つの仮想ネットワーク インターフェイスを備えているということです。 仮想ネットワーク インターフェイスの 1 つが適切な VSID と関連付けられています。 もう 1 つの仮想ネットワーク インターフェイスの VSID は 0 です。これは、トラフィックが WNV フィルターによって変更されないことを意味します。Windows Server 2012 仮想マシンは、ホスト側クラウドと顧客のオンプレミス ゲートウェイとの間にセキュリティで保護されたトンネルを作成するために、RRAS を実行し IKEv2 を使用しています。

図 10:ハイブリッド クラウドと Windows Server 2012

図 10: Windows Server 2012 ベースのテナント別 VM ゲートウェイを備えるハイブリッド クラウド

図 10 に、VMM で Hyper-V ネットワーク仮想化の展開を管理するアーキテクチャを示します。 パートナーは、VMM サーバー内で実行されるプラグインを備えています。 Windows Server 2012 を Hyper-V ネットワーク仮想化ゲートウェイ アプライアンスとして使用する場合は、VMM サーバーで実行されるプラグインからのこの通信のためのエンド ポイントとして、Windows で実行されるローカル管理プロセスが必要です。 この方法により、プラグインは HostGW で実行される WNV フィルターにネットワーク仮想化ポリシーを伝達できます。

Windows Server 2012 ベースのゲートウェイ アプライアンスのスケーラビリティは、次のようなサーバーのハードウェアによって決定されます。

  • NUMA 機能

  • CPU コアの個数

  • RAM の容量

  • オフロード機能およびネットワーク インターフェイスのパフォーマンス

一般に、主要な OEM によって提供されているデュアル ソケット サーバー クラス プラットフォームで、十分なベース プラットフォームとなります。 サーバー アプライアンス上で効果的に実行できる仮想マシンの個数は、通常、サーバー内の RAM の容量によって決定されます。

ネットワーク インターフェイスの選定も、ゲートウェイ アプライアンスのパフォーマンスとスケーラビリティに大きな影響を及ぼす可能性があります。 図 10 に、2 つのネットワーク インターフェイス構成を示します。 仮想サブネット パスに送出されるトラフィックはすべて NVGRE トラフィックになります。 カプセル化されたパケットの場合、送信パス上の Large Send Offload (LSO) や 受信パス上の Virtual Machine Queues (VMQ) などの従来のオフロードは、外側のパケット ヘッダーで動作するため、期待するほどのメリットはありません。 NVGRE トラフィックの外側のヘッダーにより、すべてのトラフィックが同じ IP アドレスを使用して生成され、その送信先が単一の IP アドレスに設定されるように見えます。 ネットワーク インターフェイス オフロードにより、Hyper-V スイッチ パフォーマンスは大幅に向上します。Windows Server 2012 の新機能は GRE タスク オフロードです。この場合、ネットワーク インターフェイスは、LSO と VMQ が期待されたパフォーマンスを発揮し、優れたスケーラビリティを提供できるよう、標準のオフロードのために内側のパケット ヘッダーに対して動作します。 したがって、図 10 に示す仮想サブネットのパス上にあるネットワーク インターフェイスは GRE タスク オフロードをサポートする必要があります。 そのようなネットワーク インターフェイスは 2012 年の終わりまでに市販される見込みです。

Windows Server 2012 のもう 1 つの新機能は、ゲスト仮想マシン用の IPsec Task Offload です。 IPsec は、サイト間 VPN トンネルをセキュリティで保護するために使用されます。 S2S トンネルの両側で IKEv2 をサポートする必要があります。 クロスプレミス ゲートウェイが NAT の内側にない場合、IPsec Task Offload (IPsecTO) は、図 9 に示す外部ネットワークのネットワーク インターフェイスに、テナント別 RRAS 仮想マシンの代わりにパケット別暗号化オペレーションを実行させることで、パフォーマンスの向上を実現できます。 S2S トンネルの両側では、IPsecTO を利用できるように、AES-GCM128 を使用する必要があります。 したがって、RRAS 仮想マシンで IPsecTO を利用するには、次の条件を満たす必要があります。

  • S2S トンネルの両側で AES-GCM128 を使用する

  • ゲートウェイ アプライアンスが NAT の内側になければならない

IPsec 操作は CPU の使用率を非常に大きくするおそれがあるので、IPsecTO では CPU の使用率を大幅に削減し、ネットワークのスループットを向上させることもできます。

SR-IOV は、物理ネットワーク インターフェイスを仮想マシンに直接公開する、Windows Server 2012 の新機能です。 SR-IOV は仮想スイッチをバイパスします。 残念ながら、市場の現在の IPsecTO ネットワーク インターフェイスは、SR-IOV パス上で IPsecTO をサポートしていません。Windows Server 2012 Hyper-V スイッチでは、ACL や QoS などの新しいポリシーベース機能を導入しています。 これらの Hyper-V スイッチ ポリシーがいずれも仮想ネットワーク インターフェイスに設定されていない場合、仮想ネットワーク インターフェイス トラフィックは、SR-IOV パスを使用しません。その代わり、ポリシー適用のために Hyper-V スイッチ パスを通過する必要があります。 トラフィックが Hyper-V スイッチ パスではなく、SR-IOV パスを使用する場合、CPU の利用率が大幅に軽減します。

プライベート クラウド ゲートウェイの場合、ハードウェア要件に関して類似の考慮事項を評価する必要があります。

Hyper-V ネットワーク仮想化および System Center Virtual Machine Manager に関する追加の情報については、以下の記事を参照してください (リンクが設定されていない記事は、まだ開発段階にあることを示します)。

表示: