ラボの紹介よく知られているように、データ通信の分野では、Huawei、ZTE、Ciscoなどの伝統的なメーカーは、転送用のハードウェアカードと組み合わせて独自のネットワーク転送プラットフォームを使用しており、これは一般的にハードウェア転送と呼ばれています。近年、SDN / NFVなどの新しいネットワーク技術の台頭により、x86プラットフォーム上のCPU転送の需要が絶えず言及され、急速に発展しています。それに応じて、Linuxカーネル転送などのオープンソースネットワークオペレーティングシステムが登場しています。Linuxカーネルは、基本的なネットワークレイヤー2および3転送、NAT、ACLなどの機能を処理できる豊富なネットワークプロトコルスタックを備えています。ただし、Linuxカーネルの最大の問題は、パフォーマンスが十分に高くないため、大規模なユーザー転送に適応するのが難しいことです。 パート01、VPPの紹介VPPはVector Packet Processing（ベクターパケット処理）の略で、2002年にシスコが開発した商用コードと言われています。2016年2月11日、Linux FoundationはFD.ioプロジェクトを立ち上げました。シスコはVPPコードのオープンソース版をこのプロジェクトに追加し、現在ではそれがプロジェクトの中核となっています。VPPはユーザー空間で実行され、様々なパケット送受信方式をサポートしています。最も一般的なのはDPDKです。VPPには2つの重要な機能があります。
VPPは、ネットワークデータプレーンアプリケーションを作成するためのモジュール式でスケーラブルなソフトウェアフレームワークです。さらに重要なのは、VPPコードは最新の汎用プロセッサプラットフォーム（x86、ARM、PowerPCなど）向けに設計されており、リアルタイムネットワークI/O操作とパケット処理のためのソフトウェアおよびハードウェアインターフェースの最適化に重点を置いていることです。 パフォーマンスを向上させるため、VPPデータプレーンは、1回の呼び出しで複数のパケットを処理する転送ノードの有向グラフで構成されています。段階的なモジュール設計フレームワークにより、コア/カーネルコードを変更することなく、誰でも新しいグラフノードを「プラグイン」できます。 パート02 VPPの技術原理VPPのベクトルメッセージ処理は、従来のスカラーメッセージ処理とは対照的です。従来のメッセージ処理は、人間の一般的な論理的思考を反映しており、メッセージが到着した順に処理されます。つまり、最初のメッセージが処理され、次に2番目のメッセージが処理され、というように続きます。AがBを呼び出し、Cが戻り、戻り、戻り、戻り、というように、関数は頻繁にネストされ、最終的に戻ります。Linuxカーネル転送とOpenVswitchのメッセージ処理はどちらもスカラーメッセージ処理です。 したがって、従来のスカラー メッセージ処理には次のような欠点があることは明らかです。 1. I-キャッシュスラッシング（キャッシュ時間とスペース制限の特性） 2. I-キャッシュミス 3. キャッシュの拡張以外に、変更の予定はありません。 比較すると、ベクトル メッセージ処理では複数のメッセージを一度に処理します。これは、次の図に示すように、メッセージ配列 packet[n] を一度に処理することと同じです。 簡単に言えば、スカラーパケット処理、つまり従来のパケット処理では、一度に1つのパケットが転送パイプライン全体を通過します。このパイプラインには、イーサネット処理、IP処理、ARP処理、ポリシー処理、NAT処理など、様々な機能が含まれているため、各モジュールはCPU内で異なる命令を必要とします。そのため、パケットがこれらの処理を順番に完了していくにつれて、CPUキャッシュにキャッシュされた命令は再利用できず、ジッタが発生し、転送効率に必然的に影響を及ぼします。一方、ベクターパケット処理では、ベクターパケットのグループを一度に処理します。単一の処理モジュールが複数のパケットを同時に処理することで、CPUキャッシュにキャッシュされた命令の再利用が最大化され、高い効率が実現されます。 VPPは、基盤となるハードウェアキュー（Rxリング）から受信したパケットをパケットベクター、つまりパケットグループに組み立てます。その後、パケット処理グラフを使用して処理フローを実装します。グラフノードは、プロセス全体を連続的に接続された一連のサービスノードに分解します。このパケットグループ（パケットベクター）は、下図に示すように、最初のグラフノードのタスクによって処理され、次に2番目のグラフノードのタスクによって処理され、というように処理が続きます。 パート03、VPPのスケーラビリティ上の図は新機能の挿入について言及しています。LinuxカーネルプロトコルスタックやOpen VSWitchといった他のソフトウェアから転送するシステムを見ると、転送プロトコルスタックのコード全体は基本的に階層化されています。まず一般的なエントリ関数があり、そこから異なる処理モジュールが異なる階層の処理関数に入ります。特定の部分に新しい処理モジュールが追加されると、メインフレームワークの機能ロジックを修正する必要があります。ビジネスロジックとメインフレームワークは分離されておらず、拡張性に欠けています。 しかし、VPPは異なるアプローチを採用しています。ビジネス機能の処理に斬新な戦略を採用しています。VPPは、グラフノードを接続してデータパスを形成することでパケットを処理します。各機能モジュールは独立したノードとして実装されます。VPPの全体的なスケジューリングフレームワークはこれらのノードを相互にリンクし、ノード間の優先順位と順序関係を指定できます。これらのノードは互いに独立しており、優先順位と順序関係を変更するだけで調整できます。さらに、新しい機能を追加するには、新しいノードを追加し、そのノード内に新しい機能のロジックを実装し、対応するノードの前または後に挿入するだけです。不要になったら無効にできるため、非常に便利です。さらに、新しいノードはプラグインとしてコンパイルできるため、プラグアンドプレイ機能を実現できます。 例えば、通常の処理順序は、DPDKパケット受信ノード ---> Ethernet処理ノード ---> IP入力ノード ---> IPルート検索ノード ---> 出力ノードとなります。新たな要件が追加され、転送をガイドするためにDPIマッチングが必要な場合は、DPI機能を別のノードとして記述し、IP入力ノードとIPルート検索ノードの間に挿入することができます。 パート04、VPPの適用前述の通り、 VPPは高性能なオープンソース転送ソフトウェアであり、SDN、NFV、クラウド化、コンピューティングパワーネットワークの時代において、ますます重要な役割を果たすでしょう。VPPはクラウドシナリオにおいてソフトルーター/スイッチとして活用できます。例えば、SD-WANシナリオでは、クラウドPOPはアクセス、ポリシー転送、ルーティング、NAT、トンネリングなどの機能を備えている必要がありますが、豊富なネットワークプロトコルスタック機能と高性能処理能力を備えたVPPは、これらのタスクに最適です。セキュリティシナリオでは、VPPは企業の出口ポイントでセキュリティゲートウェイとして活用できます。さらに、5GコアネットワークのUPFもVPPを用いて実装できます。つまり、ソフト転送が必要な場所には必ずVPPが存在するということです。 パート05、追記前述の通り、VPPは豊富なレイヤー2およびレイヤー3ネットワークプロトコルスタック、柔軟かつスケーラブルな新サービス開発、高性能な転送など、数々の革新的なメリットを誇ります。しかし、限界がないわけではありません。VPPのコードは、OVSやLinuxカーネルよりも習得が困難です。さらに、他のコントロールプレーンソフトウェアとの連携においても、いくつかの欠点があります。例えば、オープンソースルーティングソフトウェアfrroutingとの統合には独自のルータープラグインが必要ですが、このプラグインは長期間更新されていないため、機能上の欠陥が生じています。さらに、VPPの安定性はまだ商用基準に達しておらず、ユーザーによる継続的な修正と改善が必要です。VPPコミュニティは常にアップデートを行い、機能の追加やバグ修正を行っていますが、オープンソースVPPを成熟し、商業的に実行可能で安定した製品へと進化させるには、まだ多くの作業が必要です。しかしながら、VPPは今後も改善を続けていくと確信しています。 |
