オンプレミスの仮想化された顧客機器のNFVパフォーマンスを最適化する

実際のネットワーク機能の仮想化を目的としたソリューションの主な要因は、予測可能で保証されたパフォーマンスとスループットを顧客のトラフィックに提供する能力です。 概念をテストするために設計された多くのプロジェクトは、ネットワーク帯域幅の増加にかなりの注意を払っていますが、遅延の量はネットワークパフォーマンスの等しく重要な指標です（場合によってはもっと重要です）。 この記事では、Intel Open Network Platformアーキテクチャに基づいたBT Adastral Parkラボのテスト環境について説明します。 このテスト環境は、仮想化された顧客のオンプレミス機器のパフォーマンスを評価するように設計されています。







テスト結果は、Data Plane Development Kitを使用した最適化中に、レイテンシーとジッターが減少するという点でパフォーマンスが大幅に向上することを示しています。 たとえば、平均遅延は38〜74％減少し（パケットプロファイルによって異なります）、最大遅延は6倍減少しました。 このようなパフォーマンス最適化の分析は、既存のネットワークと有望な5Gネットワ​​ークの両方で、負荷とリソースのインテリジェントな管理にとって特に重要になります。

I.はじめに

ネットワーク機能仮想化（NFV）テクノロジーは、ラボ条件から実稼働環境および実際の顧客との試運転^1に急速に移行しています。 標準化の作業が進行中です。 欧州通信規格協会（ETSI）の業界技術仕様（ISG）の適切なグループに参加しています。 標準化の主な領域は、パフォーマンス測定とベストプラクティス²です。 最も重要なパフォーマンスメトリックはネットワーク帯域幅ですが、この記事ではパフォーマンスの問題に別の角度から取り組んでいます。レイテンシの感度について説明しています。 特に、特定の仮想ネットワーク機能（VNF）が通常顧客のローカルIT環境にある場合、企業の仮想化（vCPE）を使用して顧客のローカル機器を使用する場合を検討しています。 ETSI ³文書では、そのようなモデルはVE-CPEと呼ばれています（図1）。



標準のx86ハイパーバイザーサーバー上でVNFとして実行できる顧客のローカル環境のネットワーク機能の例には、ルーター、ファイアウォール、セッションボーダーコントローラー、WANアクセラレーターが含まれますが、これらに限定されません。 アフィリエイトには通常、それほど強力ではないWANアクセスチャネルが必要です（セントラルオフィスと比較して）：多くの場合、WANへの接続のスループットは1秒あたり数十または数百メガビットになる可能性があります。毎秒1ギガビットに到達して超過します。 したがって、パフォーマンスの観点からは、ブランチでのvCPE実装の最大スループットではなく、遅延と変動（ジッタ）を最小限に抑える能力が重要です。









図1.支社のローカル顧客環境（VE-CPE）で仮想企業設備を使用する例。



ブランチがグローバルネットワークのインフラストラクチャに接続されているほとんどの企業ネットワークでは、トラフィックの一部がVoice over IP（VoIP）によって処理されます。 このトラフィックは、予測可能で保証されたパフォーマンスを提供するために必要な、遅延とジッタの点でより厳密なフレームワークによって特徴付けられます。 音声送信に関連するネットワーク機能（セッション境界コントローラー-SBCなど）が仮想化なしで物理デバイスを使用して実装されている場合でも、エンドユーザートラフィックを送信するローカルカスタマー環境の他の機能は仮想化できます：サイドのルーターは明らかな例です顧客（CE）。 したがって、NFVインフラストラクチャのパフォーマンスを調整して、レイテンシとジッタの予測レベルを同じレベルにすることが重要です。 これにより、遅延の影響を受けやすいアプリケーションの全体的なパフォーマンス状況に対するNFVインフラストラクチャコンポーネントの影響をより明確に把握できます。



2番目の部分では、 Intel Open Networking Platform（Intel ONP）およびData Plane Development Kit（DPDK）について説明し、3番目の部分では、レイテンシとジッタの評価に関するvCPE環境のテストについて説明します。 実際のテストの結果は、第4部に記載されています。 5番目の部分には結論があり、6番目の部分にはさらなる研究のための推奨資料が含まれています。

II。 オープンネットワークプラットフォームおよびデータプレーン開発キット

vCPEなどのさまざまな使用シナリオに対して通信事業者がNFVソリューションを定義および実装する方法は、コスト、技術的条件、他のサプライヤーのソリューションとの相互作用など、多くの要因に依存します。 その結果、たとえば、 Open vSwitch *（OVS）でのカーネルベースの仮想マシンハイパーバイザー（KVM）テクノロジー、およびOpenStack *などのオープンソースコントロールを使用して、オープンソースNFVソリューションが作成されます。 Intel ONPは、NFV ⁴向けのモジュラーアーキテクチャプラットフォームにこのようなオープンソースコンポーネントを統合しています。



Intel ONPアーキテクチャの（パフォーマンスの点で）最も重要なコンポーネントの1つはDPDKです。DPDKは、KVMハイパーバイザーのVNFパフォーマンスを改善するために使用できます。 図 図2（a）は、典型的なOpen vSwitchの図を示しています。 2（b）-DPDKでvSwitchを開きます。 標準のOVS実装では、ネットワークアダプター間のパケット転送は、仮想スイッチのカーネルスペースにあるパスに沿って行われます。 これは、着信パケットの処理方法を示す単純なストリームテーブルです。 カーネルデータパスの単純なテーブルのエントリのいずれとも一致しないため、最初のフローパケットのみが（「低速パス」に沿って）仮想スイッチのユーザー空間に入る必要があります。 OVSユーザー空間は、ストリームの最初のパケットを処理した後、カーネル空間のテーブルを更新し、以降のすべてのパケットがユーザー空間に分類されなくなります。 これにより、カーネルスペーススレッドテーブルのエントリ数と、ユーザースペースに入る必要のあるパケット数の両方が削減され、その処理にはかなりの計算リソースが必要になります。





図2.（a）Open vSwitch *および（b）Data Plane Development Kit vSwitchの図。



DPDKを使用したOpen vSwitchモデル（図2（b））では、メイン転送プレーン（「高速パス」と呼ばれることもあります）はOVSユーザー空間にあり、DPDKを使用します。 このアーキテクチャの主な違いの1つは、ここでのネットワークアダプターがポーリングモードドライバー（PMD）であることです。これは、着信パケットが継続的にポーリングされ、割り込みで非同期に制御されないためです。 初期ストリームパケットは、カーネルの「高速パス」の場合のパケットと同じパスに沿って、ユーザー空間の別のモジュールに送信されます。



図 図3は、OVSからゲスト仮想マシン（VM）への実際のトラフィックフローを示しています。この記事のコンテキストでは、仮想ルーターとして機能します。 標準のOVS実装では、OVS転送はカーネル空間で終了し（図3（a））、DPDKを使用したOVSモデルでは、OVS転送はユーザー空間で終了します（図3（b））。 ゲスト仮想マシンのvirtioキューはOVS DPDKにマップされるため、OVSはそれらに直接データを読み書きできます。 「ユーザーからユーザーへの空間」のトラフィックパスは、通常、カーネル空間を通るパスよりもパフォーマンスが優れています。 どちらのアーキテクチャでも、ゲストVMはDPDKまたは標準のLinux *ドライバーのいずれかであることに注意してください。 以下で説明するテストでは、高性能シナリオでDPDKドライバーを使用したVNFを使用しています。





図3.トラフィックフロー：（a）Open vSwitch *および（b）Data Plane Development Kit vSwitch。



理論的には、DPDKを使用したOpen vSwitchのパフォーマンスは、標準のOVSモデルのパフォーマンスよりも高いはずです。 ただし、特定のテストを使用して実際にこれをテストすることが重要です。 次のセクションでは、テストシステムと実際の結果について説明します。

III。 テストシステムの説明

テストシステムの主要なコンポーネントを図に示します。 3。





図4.基本レベルおよび高性能のテストシステム（表示されているハードウェア情報は、テスト中のシステムを表すコンピューティングノードに関連しています）。



2つのベンチマークテストシステムを使用して、DPDKなどの高性能アーキテクチャが遅延およびジッタの結果に与える影響を評価および比較します。 各テストシステムには、1つのOpenStackコントローラーノードと、Kiloバージョンシステムを使用して構築された対応するコンピューティングノードが含まれます。 ハイパーバイザーで実行されているコンピューティングノードとそれに関連付けられたゲストVNFは、テスト対象のシステムを表します。



基本レベルのテストシステムは、BIOS設定を最適化せずにIntel Xeon E5-2680プロセッサ（Sandy Bridgeアーキテクチャ）を使用します。 高性能テストシステムはIntel Xeon E5-2697 v3プロセッサ（Haswellアーキテクチャ）を使用し、BIOSチューニングを行ってパフォーマンスを向上させながら、電力消費を抑え、CステートとPステートを無効にしました。 基本システムはカーネル空間の標準データパスを使用し、高性能システムはOVS DPDKデータパスを使用します。 どちらの場合でも、Fedora * 21がベースOSとして使用されますが、ベースレベルシステムは標準の非リアルタイムカーネル（3.18）を使用しますが、高性能システムは適切な構成設定（vSwitchとVMコアの分離）でLinuxリアルタイムカーネル（3.14）を使用しますメインシステムのOSから、Linux拡張セキュリティを無効にし、アイドル時にポーリングを使用し、タイムスタンプに最適なタイマーを選択します）。 基本システムは、VMのインストールとネットワークリソースの割り当てに関する標準OpenStack設定を使用します。 高性能システムでは、チューニングがより正確になります。vSwitchとVNFに専用CPUを割り当てることができます。 さらに、高性能システムは、同じ物理システムにインストールされたVNF用の中央処理装置とメモリの使用、およびサーバー上の物理ネットワークアダプターのインターフェイスに直接接続するための特定のCPUの使用を保証します。



両方のテストシステムで、Brocade 5600 * R3.5仮想ルーターがすべてのテストで実際のVNFとして使用され、Spirent Test Center C1 *負荷テストデバイスが長時間のトラフィックテストに使用されました。 高性能システムでは、仮想ルーターはDPDKドライバーを使用します。 図に示すように。 5、シングルVNFおよびデュアルVNFサービスチェーンシステムがテストされました。





図5.テスト対象のシステム：（a）単一の仮想ルーター、（b）シリアルサービスチェーン内の2つの仮想ルーター。



テストシステムは、遅延とジッタの測定精度を損なうことなく、ブランチオフィスが動作するのに十分な帯域幅（100 Mbit / s以下）を確保するように構成されました。 次のパッケージプロファイルがすべてのテストに使用されました。

• 64バイトフレーム（双方向負荷25 Mbps）
• 256バイトフレーム（双方向負荷25 Mbps）
• リアルタイムiMixフレームブレンディング（50 Mbps双方向負荷）
• 1,500バイトフレーム（100 Mbps双方向負荷）

テスト機器は、タイムスタンプ付きの署名を使用して、フレーム間の遅延を決定します。 署名は、フレームチェックシーケンス（FCS）の隣のペイロードの最後にあり、タイムスタンプ、シーケンス番号、およびストリーム識別子が含まれています。 「ジッター」とは、1つのストリーム内の2つの着信フレーム間の時間差を意味します。 したがって、パケット遅延の差はこの方法で測定されます。 1つのトラフィックストリームで構成される、各方向のテスト対象システムへの同じトラフィック負荷が作成されました。 次のセクションで示される結果は、特定の方向の最悪のメトリックを示しています（つまり、遅延、ジッターなどの指定された値は、双方向伝送ではなく、単方向トラフィックに対してのみ与えられます）。 表示される結果はネットワークの定常状態の動作に関連していることに注意してください。初期結果は約20秒後にリセットされ、割り当てられた時間内にテストが実行されます。 このソリューションを使用すると、最初のフローパケットが「低速パス」を通過しても影響を受けない信頼性の高い結果を得ることができます。

IV。 試験結果

A.混合テスト

4つの異なるパケットプロファイルについて5分間の間隔で測定された平均片方向トラフィック遅延を、単一のVNFについて図1に示します。 6および図2のデュアルVNF 7。





図6.仮想化を使用した1つのネットワークの平均遅延（マイクロ秒単位）（小さいほど良い）。



異なるパケットプロファイルの平均遅延の結果は、基本レベルのシステムと比較して、高性能システムのパフォーマンスが大幅に向上していること（平均遅延が低いこと）を明確に示しています。 単一のVNFを使用したテストでは、遅延は38〜74％減少し、二重のVNFを使用したテストでは、遅延は34〜66％減少しました。 予想どおり、デュアルVNFの場合の全体的な遅延は、2つのVNFインスタンス間のパケットスイッチングとハイパーバイザーの仮想スイッチにより、両方のテストシステムでわずかに高くなりました。 これらのテストでは、パケット損失ゼロが記録されたことに注意してください。





図7.仮想化を使用した2つのネットワークの平均遅延（マイクロ秒単位）（小さいほど良い）。

B. 256バイトのパケットテスト

特定のパッケージプロファイルを使用してテスト結果をより詳細に調べることは理にかなっています。 たとえば、256バイトのモックアップを使用したテストでは、G.711エンコード^5の RTPプロトコルによって生成されたVoIPフレームをより正確に再現します。 図 図8は、256バイトのパケットを使用したシングルおよびデュアルVNFの最小、平均、および最大片方向トラフィック遅延を示しています。





図8. 256バイトのパケットの詳細な遅延結果（マイクロ秒単位）。





図9. 256バイトパケットの詳細なジッター結果（マイクロ秒単位）。



図 図9は、片方向トラフィックジッタの対応する平均値と最大値を示しています。 最大レイテンシとジッター値は、両方のテストシステムの最悪のパフォーマンス特性を評価するために重要です。 高性能システムでは、単一VNFで最大遅延が6倍、デュアルVNFで7.4倍に遅延が減少しました。 最大ジッタは、それぞれ24倍および8.5倍減少しました。 これらのテストでは、パケット損失ゼロが記録されたことに注意してください。



短い間隔でパフォーマンスを評価するだけでなく、時間とともにパフォーマンスが変動する可能性を調査することも重要です。 図 図10は、256バイトのパケットと単一のVNFで16時間続くテストと比較した、5分間続くテストの最大遅延テストの結果を示しています。 一般に、結果は、最適化されたシステムの生産性が基本レベルのシステムとほぼ同じであることを示しています。最大遅延は、16時間テストで5倍、5分間テストで6倍減少しました。 16時間のテストでは、最大遅延が大幅に高くなることに注意することが重要です。 これは、非常に少数のテストパケットに影響を与える非常にまれなシステム中断イベント（つまり、メンテナンスタスク）によって説明できます。 それにもかかわらず、256バイトのパケットを使用した16時間のテストでの片方向トラフィックの最大遅延の値はわずか2ミリ秒でした。 これは非常に適切な結果であり、一方向音声トラフィック伝送の遅延しきい値は、ITU-T G.114 ⁶仕様に従って150ミリ秒です。 つまり、vCPTの追加による遅延の増加は、最悪の場合、許容される遅延の合計の1.3％に過ぎません。 基本レベルのシステムでも、一方向のトラフィックの最大遅延は9.95ミリ秒であり、これは総許容値のわずか6.6％です。





図10.ミリ秒単位の長い遅延テストの結果（16時間と5分のテストの比較）。

V.結論と結論

この記事では、KVMハイパーバイザーに基づいて仮想CPEインフラストラクチャプラットフォームを微調整する方法について説明します。 特に、DPDKなどのIntel ONPアーキテクチャの一部のコンポーネントを使用すると、基本構成（最適化なし）と比較してパフォーマンスが大幅に向上します。 単一のVNFを使用したテストでは、一方向のトラフィック遅延が38〜74％減少しましたが、デュアルVNFを使用したテストでは、遅延は34〜66％減少しました。 256バイトのパケットが使用されたVoIPトラフィックに近いテストでは、最大遅延がそれぞれ6倍（単一VNFの場合）および7.4倍（デュアルVNFの場合）、最大ジッターがそれぞれ24倍および8倍減少しました。 、5回。



実験結果に基づいて、VoIPなどの遅延の影響を受けやすいアプリケーション向けにNFVインフラストラクチャのパフォーマンスを調整すると、基本構成（最適化なし）と比較して、遅延とジッターの観点から全体的なパフォーマンスのより具体的な指標が提供されると結論付けることができます ネットワークオペレーターによる最適化を適用するかどうかの決定は、vCPEインフラストラクチャでサポートされるVNF機能の必要なセットと、サービスレベル契約で指定されたパフォーマンスメトリック（遅延やジッタレベルなど）がサービスにどのように関連するかに大きく依存しますこれらのVNF機能に。 実際には、ネットワーク事業者が使用する実際のサービスレベル契約には、事業者自身のバックボーンおよびトランジットネットワーク内のパフォーマンス目標が含まれ、地域によって異なります。 ヨーロッパでは30〜40ミリ秒、北米では40〜50ミリ秒、大西洋横断チャネルでは最大90ミリ秒の双方向IPパケット送信時間が、平均遅延の典型的な例と標準です。



ネットワーク事業者が、工場設定の事前構築済みソリューションの代わりにDPDKなどのコンポーネントでNFV最適化を使用する場合、高レベルの管理ソリューションに対する最適化の潜在的な影響を評価する必要があります。指定されたパフォーマンス要件に従って。 この記事で説明する実験は、パフォーマンスを最適化する方法、既存のネットワークおよび有望な5Gインフラストラクチャへの適用の可能性をより詳細に理解するための基礎と見なすことができます。

VI。 今後の課題

さらなる研究のための可能なトピックは次のとおりです。

• 「最適化レベル」と全体的な最適化に対するそれぞれの効果の調査：機器の選択（特に、遅延時間の違いに対するIntel Xeon E5-2680およびIntel Xeon E5-2697 v3プロセッサの影響）、BIOS設定（たとえば、P- Intel SpeedStepテクノロジーを使用して電力負荷の効率を高めることができる状態）、リアルタイムカーネル設定（たとえば、「ヘルツカーネルなし」、読み取り、コピー、更新操作のポーリング）、ハイパーバイザー設定、VNF設定-これらはすべて、アーキテクチャの特性を決定します。 したがって、可能な最適化対策と各レベルへの影響のより明確な画像を取得する必要があります。
• VoIPに特化したVNFを含む、さまざまな種類のVNFに対して同様のパフォーマンス評価テストを実施することを検討する必要があります。
• テスト分析を改善して、プロファイルと頻度に応じてパケット遅延とジッターの分布を評価できます。
• 高レベル制御の観点からのNFV最適化のさらなる分析：制御モジュールが、DPDKなどの機能を使用してNFVインフラストラクチャの特定の設定を使用する基本的なリソースと機能を「知っている」場合、管理ソリューションはより複雑になりますが、遅延に敏感な配信の構成が可能になります最も適切なNFVインフラストラクチャ上のVNF。

明らかに、この分野にはまだ多くの興味深い問題や検討が必要な問題があります。

参照資料

1. J.ストラドリング。 「グローバルWANアップデート：主要プレーヤーと主要トレンド」、2015年9月の現在の分析からの推奨事項を含むレポート
2. 「ネットワーク機能の仮想化のパフォーマンスと最高の移植性技術」、仕様ETSI ISG GS NFV-PER001、V1.1.1。 2014年6月
3. 「ネットワーク機能の仮想化の使用例」、仕様ETSI ISG GS NFV001、V1.1.1。 2013年10月
4. Intel Open Network Platform Server（バージョン1.5）リリースノート2015年11月
5. 「vCPEのNFVパフォーマンスの測定」ネットワークテストレポート、Overture Networks、2015年5月
6. 「ITU-T仕様G114-一方向送信時間」、2003年5月