仮想マシンの通信原理

仮想マシンまたはコンテナは、同じホスト内またはホスト外の物理デバイスまたは仮想デバイスとの通信を含め、相互に通信する必要があります. いずれの場合も、通信にはネットワーク カードが必要です.

通信には 2 つの方法があります。1 つは仮想化されたインターフェイスを介する方法で、もう 1 つは仮想マシンの専用の物理インターフェイスを使用する方法です。もちろん、物理インターフェイスはホスト外部のデバイスとの通信にのみ使用されます。ただし、仮想マシンが必要とするインターフェイスの数は、通常、インフラストラクチャで使用できる物理インターフェイスの数よりもはるかに多いため、インターフェイス レベルの仮想化メカニズムは避けられません。NFVI レイヤーは、仮想マシンで使用できる vNIC (仮想ネットワーク インターフェイス カード、仮想ネットワーク カード) を含め、この機能 (およびもちろん他の機能) の実行を担当します。

仮想マシンはこれらの vNIC を実際の物理インターフェイスとして認識し、これらのインターフェイスを使用して仮想マシンの外部でパケットを送受信します。仮想インターフェイスがスケーラビリティと部分的なスイッチング機能を持ち、パフォーマンスを大幅に低下させることなくパケット スイッチング機能を実行できるようにするために、業界ではこれらの機能を実装する複数の方法が提供されています。

1.仮想スイッチ

仮想ブリッジを使用することは、仮想化をインターフェースする単純なソリューションですが、仮想ブリッジには機能、スケーラビリティ、および柔軟性が欠けています。不十分な機能の問題を解決するために、Cisco の Nexus 1000v、VMware の Virtual Switch (仮想スイッチ)、OVS (Open Virtual Switch、オープン仮想交換)。

OVS は、オープン ソース スイッチの中でより一般的な選択肢です. ハイパーバイザーで実行できるだけでなく、豊富な機能セット (sFlow、NetFlow、OpenFlow のサポートなど) もサポートしています. OVS の幅広い人気により、OpenStack のプラットフォームになっています.およびその他の仮想マシン オーケストレーション のデフォルトの選択です。

このアプローチの問題は、より高速なインターフェイスにスケーリングすると、パフォーマンスに影響が出る可能性があることです。ハイパーバイザー ソフトウェアまたはカーネルは、イングレスまたはイーグレス キューからパケットを読み取り、仮想マシンとの間でトラフィックをキューに入れ、分散するという負担を負う必要があるため、これらの操作は多くの CPU サイクルを消費するため、この方法はスケーラビリティの観点から、比較的効率が悪いようです。

特に仮想マシンがデータ トラフィック パスで直接 VNF を使用してネットワーク機能を実行する場合、仮想化の負荷の問題はより深刻になります。仮想化の負荷によるパフォーマンスの低下は、エンドツーエンドのトラフィックに直接影響します。

仮想化の負荷を解決するソリューションは、Hypervisor をバイパスし、vNIC が物理 NIC と 1 対 1 のマッピングで直接通信するパススルー メカニズムです.この方法は、仮想化の負荷の問題を回避できますが、この方法では物理インターフェイスが仮想インターフェイスに割り当てられるため、パフォーマンスの問題が発生します。

通常、サーバーには多くの物理インターフェイスがないため、これを行うと、パススルー モードを使用できる仮想マシンの数が大幅に制限されます。また、パススルー方式は、お客様OSのデバイスドライバのサポートの問題もあります。

2、SR-IOV

SR-IOV (Single Root Input/Output Virtualization、Single Root Input/Output Virtualization) は、単一の NIC がホスト OS で使用できる複数の NIC になるための標準を提供するインターフェイス レベルの仮想化を実現するのに役立ちます。カーネルまたはハイパーバイザーの NIC 仮想化の負担が解消され、NIC のリソースがインターフェイス仮想化の管理に使用されるため、ホスト CPU の負荷が大幅に軽減されます。

正確には、SR-IOV は、PCI (Peripheral Component Interconnect、Peripheral Component Interconnect) 仕様を使用して複数のシステム コンポーネントに接続する入出力 (I/O) デバイスを多重化できます。

SR-IOV は、PCI-SIG (Peripheral Component Interconnect Special Interest Group、Peripheral Component Interconnect Special Interest Group) によって作成および維持されます。

ハイパーバイザーまたはホストにネットワーク インターフェイス仮想化を実装する場合、ホスト CPU は、読み取りと処理が必要な NIC に到着するパケットによって中断されます。ホストが処理を終了した後、これらのデータ パケットはそれぞれの仮想マシンのキューに入れられ、対応する仮想 CPU リソースを占有する必要があります。これは、ホスト CPU に間接的に影響を与えます。これは、ホスト CPU が NIC からの読み取りキューを処理してロードする必要があるためです。これらのパケットに対する要求は、環境内で再度処理されます。

SR-IOV を採用した後、NIC はこれらの割り込みのうち最初の割り込みのみを処理する必要があり、ホスト CPU に対してシールドの役割を果たします。

最初に複数の仮想インターフェイスを作成し、それらの仮想インターフェイスを物理インターフェイスとして上位層 (ホストやハイパーバイザーなど) に提示します。SR-IOV に関しては、これらの仮想インターフェイスは VF (Virtual Function、仮想機能) であり、実際の物理インターフェイス機能を実行して機能している一部の NIC は PF (Physical Function、物理機能) と呼ばれます。VF と VNF (Virtualized Network Function、仮想ネットワーク機能) という用語を混同しないように注意してください。この 2 つには、仮想化技術に関することを除いて共通点はありません。

この時点で、Hypervisor はこれらの VF インターフェイスを pNIC (物理 NIC、物理ネットワーク カード) として仮想マシンに提供できます (ストレート スルー方式で接続されます)。このようにして、データ パケットが物理インターフェイスに到着した後、ホスト CPU は中断されませんが、NIC はリンクからデータ パケットを読み取って処理し、これらのデータ パケットを割り当てられた仮想インターフェイスに送ります。これらのタスクはすべて PF によって実行され、キューは VF のメモリ空間に属します。これらのパケットを正しい VF にキューイングするために、SR-IOV は正しい VF を一意に識別できる MAC アドレスや VLAN タグなどの識別子を使用します。

次の図は、SR-IOV の実装の概略図を示しています。

SR-IOV はホストに仮想インターフェイスを提示しますが、これらのインターフェイスが仮想化されているという事実を隠すわけではありません。VF はホストと PF の間でデータを移動するためにのみ使用され、従来の PCI デバイスとして機能する必要はないため、ホスト、ハイパーバイザー、および仮想マシンはすべて SR-IOV をサポートする必要があります。たとえば、ハイパーバイザーが VM から VF へのパススルー接続を提供する場合、VNF は、リソース構成を必要としないエミュレートされた PCI デバイスと通信していることを認識する必要があります。

SR-IOV の欠点の 1 つは、VF とホスト CPU 間のデータ パケット交換に PCI バスが使用されることです. サービス関数チェーンを使用した後、データ パケットはこのパスを何度も行き来する可能性があり、 PCI バスは制限要因です。 

3.ダイレクトメモリアクセス

仮想マシン間の通信方法の 1 つは、ホスト OS の共有メモリ空間を使用することです.この技術は、この目的のためにホストのメモリの一部を確保し、仮想マシンがアクセスできるようにします. 仮想マシンは、このストレージ スペースを読み書きでき、PCI デバイスとして認識できるため、このメモリ ロケーションは、仮想マシンがパケットを両方向に送信するためのデータ リンクとして機能します。

この方法では、仮想化の分離原則が破られます。これは、現時点で仮想マシンが使用するメモリ空間が、これらの仮想マシンではなくホストに属する共有空間であるためです。

また、このメカニズムが正常に動作するためには、下図に示すように、Hypervisor がこのメカニズムをサポートしている必要があります。

4. vSwitch のパフォーマンスを強化する

前述のインターフェイス仮想化アプローチの背後にある目標は、仮想マシンにスケーラブルなネットワーク インターフェイスと優れた転送パフォーマンスを提供することです。これらのテクノロジーはサーバー仮想化の世界にルーツがあるため、ほとんどのトラフィックがアプリケーションに送られるため、制限されたスイッチング機能と (ネイティブのベアメタル パフォーマンスと比較した) パフォーマンスの低下は許容されます。

しかし、NFV の場合、これらのインターフェイスはデータ パスにあるため、それらのパフォーマンスは NFV ネットワークのパフォーマンスを直接反映します。仮想マシンは特定のネットワーク機能を実行する必要があり、データ パスにも配置されるため、インターフェイスのスループット、遅延、ジッターなどのパフォーマンス要素が非常に重要になります. VNF のインターフェイス パフォーマンスがわずかに低下すると、データ パス全体に影響します.サービス品質の低下を引き起こします。

同様に、NFV は、仮想化レイヤーにインテリジェンスを追加してサービス チェーン機能を有効にすることでメリットを得ることができます。仮想スイッチがサービス チェーン情報を理解できる場合、下図に示すように、SFF として機能し、VNF 間のパケット パスを大幅に簡素化できます。

前述の方法の中で、仮想スイッチ アプローチのスループットは最悪です。これは、すべての負荷がパケット処理用に最適化されていないソフトウェア パスによって実行されるためです。

SR-IOV のスループットは比較的良く、3 つの中では共有メモリ方式で得られるスループットの方が優れています。ただし、共有メモリ技術には前述のセキュリティ上の問題があり、SR-IOV もメモリ共有技術も高度なスイッチング機能を実装するための最良の選択ではなく、仮想スイッチのスループットは低いですが、これらの追加機能を実装するための最良の選択です。 .最良の選択。そのため、通常、必要な機能にバインドされた仮想スイッチを使用する場合、パフォーマンスを向上させる方法は多数あります。

基本的なスイッチング パフォーマンスを向上させる一般的な方法について、以下で説明します。 

1.DPDK

ソフトウェア (仮想) スイッチのパフォーマンスが低い主な理由は、それらが最適化されていないか、パケットを過度に高速に処理およびスイッチングするように設計されていないことです。DPDK (データ プレーン開発キット) はこの問題を解決するように設計されています。DPDK がどのように状況を改善するかを説明する前に、通常の仮想スイッチの制限を確認する価値があります。

仮想スイッチによる高速データ パケットの処理が最適化されていないため、データ パケット処理プロセスの多くのステップで CPU が使用されます。CPU はマルチタスクを処理する必要があるため、その可用性 (特に過負荷の場合) ) パフォーマンスのボトルネックが発生します。また、仮想スイッチはシステム メモリを効率的に使用しません。最初にパケットをメモリ バッファにコピーし、次にクライアント CPU に割り込んでパケットをクライアント メモリにコピーし、最後に vNIC からアプリケーションにデータを読み取ります。純粋なメモリの読み取りと書き込みによって生成されるメモリ割り当て、割り当て解除、CPU 割り込みなどの処理操作は、仮想スイッチのパフォーマンスを低下させます。

DPDK を開発する目的は、ソフトウェアがデータ パケットを処理するための最適化された方法を提供することです。DPDK は、インテル コーポレーションによって作成されたライブラリ関数と NIC ドライバのセットです。最初は 2012 年末にリリースされました。2013 年、Intel は DPDK をオープンソース開発キットとして開発者コミュニティで利用できるようにしました。これにより、開発者は、DPDK が提供する微調整機能を利用するソフトウェア スイッチや同様のアプリケーションでこれらのライブラリ関数を使用できるようになりました。DPDK は、それを使用したいすべてのソフトウェアで同じですが、OVS での使用がより顕著です。DPDK を使用すると、OVS のパフォーマンスを大幅に向上させることができます。この 2 つの組み合わせは、通常、アクセラレーテッド OVS または OVS-DPDK と呼ばれます。

DPDK は、Linux カーネルの組み込みデータ プレーンを独自のライブラリ関数に置き換えます. DPDK の軽量ライブラリ関数は、非常に効果的なメモリ処理メカニズム、つまり、物理ネットワーク カードと DPDK を使用するアプリケーションとの間のリング バッファの使用を使用します ( OVS) データ パケットはパケット間で送受信されるため、システム全体のパフォーマンスが向上します。

データ パケットの読み取りに必要な CPU 割り込みの数を減らすために、DPDK は定期的なポーリング メカニズムを採用し、システム カーネルは新しいデータ パケットを定期的にポーリングします。パケット レートが非常に低い値に低下した場合、定期的なポーリングの代わりに割り込みモードに切り替えることができます。効果的なキャッシュ管理、CPU 割り込みの最適化された最小数、およびその他の拡張機能により、DPDK によって OVS がネイティブに近いパフォーマンスを達成できることが確認されています。

ただし、DPDK には機能的な機能が少なく、独自のネットワーク プロトコル スタックはありません. 主な機能は、データ パケットの処理と転送を完了することです. DPDK は、ネットワーク機能を実装するアプリケーション (OVS-DPDK など) と組み合わせると、豊富な機能を提供できます。 ) 特性と優れた転送パフォーマンス。

2.VPP

DPDK がパケット転送パフォーマンスを向上させる方法について説明しました.CPU とメモリの使用を最適化することにより,DPDK はシリアル ストリームでパケットを処理します.各パケットはネットワーク プロトコル スタック機能を順番に 1 つずつ通過します.パッケージ,この処理方法は通常スカラーと呼ばれます処理 (スカラー処理)。

VPP (ベクター パケット処理、ベクター データ パケット処理) は、DPDK の上に拡張機能を提供し、データ パケットをバッチで処理します (1 つずつではなく)。この並列またはバッチ処理方法は、通常、ベクター処理 (ベクター処理) と呼ばれます。

一般に、同じフローに属するパケットは同じ方法で処理および転送される可能性が高いため、ベクトル処理はこの可能性を利用し、パケットをバッチ処理することでさらにパフォーマンスを向上させます。

VPP で使用されるテクノロジーは、シスコのハイエンド ルーティング プラットフォーム(CRS や ASR9000 シリーズ機器など)で使用されるシスコ独自のテクノロジーです。

2016 年初頭、シスコは VPP テクノロジーを FD.io (Fido) プロジェクトのオープン ソース ソフトウェアとして公開しました。VPP は DPDK と密接に統合され、DPDK を補完し、任意の x86 システムで実行できます。VPP は、主にレイヤー 2 からレイヤー 4 の機能を実現する非常に優れたネットワーク プロトコル スタックを提供するため、高性能な仮想ルーターまたは仮想スイッチと見なして使用することができます。高レベルのアプリケーションと連携して、ファイアウォール、フル機能のルーター (さまざまなルーティング プロトコルをサポート)、およびロード バランサーなどのネットワーク機能を提供できます。

実際、VPP はネットワーク機能を備えた最初のユーザー空間ワイヤスピード パケット転送スイッチを持っていると主張しています。

1) VPP の仕組み

VPP の実装と最適化に関する詳細は、高度な研究作業に非常に役立ちます。データ パケットのスカラー処理中に、データ パケットが転送プロトコル スタックを通過するとき、カプセル化解除、検証、およびセグメンテーションなどの操作が実行される場合があります. データ パケットを転送する必要があるかどうかを判断するには、転送テーブルを照合することが重要です.さらに処理するために上位層に送信されるか、単に破棄されます。

次の図は、2 つの異なるタイプのフローが通過する処理段階を示しています. 処理プロセスが呼び出されるたびに、イーサネット カプセル化、ラベル スイッチング、または転送決定などの処理段階を通過し、パケットを処理するために CPU を呼び出します.

これらの操作は、このプロセスを通過するすべてのパケットに対して実行されます。VPP では、これらの処理段階をパケット処理グラフと呼び、パケットのセット全体に適用されます。

VPP は、パケット処理グラフ機能を簡単に追加し、プラグインを介してフローに統合できる高度にモジュール化されたソフトウェアです。VPP はユーザー空間で動作するため、プラグインを使用したり調整したりするためにカーネル レベルで変更する必要がなく、簡単に実装および追加できます。

2) VPPとFD.io

VPP がオープン ソース ソフトウェアとしてリリースされた後、Linux Foundation は Cisco の独自コードを採用し、それを FD.io または Fido プロジェクトと名付けました。Cisco に加えて、FD.io の他の創設メンバーには、6WIND、Intel、Brocade、Comcast、Ericsson、Huawei、Metaswitch Networks、および Red Hat が含まれます。

FD.io は他のメンバーの貢献も取り入れています.BSD (Berkeley Software Distribution, Berkeley software suite) ライセンスのオープン ソース ソフトウェア DPDK コードに従っていることは特筆に値します。皆様のご協力により、FD.ioには多くの管理ツール、デバッグツール、開発ツールがパッケージ化されており、同時にDPDKやVPPの転送拡張機能と相まって、FD.ioは使用可能な仮想スイッチまたは仮想スイッチになっています。デバッグおよび開発機能 ルーター。

VPP は FD.io コードで非常に重要な役割を果たすため、FD.io は通常、多くの場所で Open-VPP または単に VPP と呼ばれることに注意してください。

3) VPP とやり取りする

VPP のネットワーク プロトコル スタックには、VPP によって公開された基になる API を介してアクセスできます。これらの API は、ネットワーク機能を実行するアプリケーションから呼び出すことができます。アプリケーションはデータ転送操作を実行するために VPP を使用および管理する必要があるため、DPA (データ プレーン管理エージェント、データ プレーン管理エージェント) という用語がアプリケーションを指すために使用されることがあります。

The Honeycomb proxy provided by FD.io can act as a DPA. It also provides RESTCONF and NETCONF northbound interfaces. アプリケーションとコントローラー (特に ODL) は、NETCONF インターフェイスを介して VPP とやり取りします (YANG データ モデルを使用)。

以下の図は、VPP を使用するさまざまな可能性を示しています。

4) VPPの利点と性能

VPP は、フォワーディングとネットワーク プロトコル スタックが組み込まれた最初のユーザー空間の高性能オープン ソース スイッチであるため、サードパーティの独立した組織によって実施されたラボ テストでは、OVS-DPDK と比較して、VPP はパフォーマンスが大幅に改善されていることが示されています。仮想化環境でのネイティブ パフォーマンスに近づきます。

下図はフォワーディングテーブルのサイズとデータパケットのサイズがスループットや遅延に与える影響を示したもので、両者を比較するとVPPのメリットがよくわかります。

VPP は、サービス チェーンとメタデータ ヘッダー フィールドをサポートする 64 ビット アプリケーションであり、NFV 環境にとって理想的なスイッチです。

5. データ パフォーマンスに関する考慮事項

仮想化は、実際のスループットに影響を与えるオーバーヘッドのレイヤーを追加します。前述のように、仮想化レイヤーはハードウェアの CPU、メモリ、および NIC リソースを占有し、VNF 用の仮想プールも作成します。通常はデータ パスに配置される VNF の場合、パケット処理パフォーマンスのために高度に最適化する必要があります。仮想スイッチと vNIC のパケット処理パフォーマンスを向上させる方法が議論されてきましたが、これらは VNF の高いパフォーマンスを達成するには十分ではありません。

仮想化環境では、CPU、ストレージ、およびメモリ リソースの使用効率が、仮想環境内のデータ パスの全体的なパフォーマンスを向上させる上で重要な役割を果たします。

VNF は、パケット パスのボトルネックになることなく、パケットを読み取り、処理し、書き戻すことができる必要があります。ここでは、仮想マシンの CPU とメモリの使用パフォーマンスを最適化するために使用できるいくつかの方法について簡単に紹介します. これらの内容について詳しく知りたい場合、および VNF パフォーマンスを調整する他のパラメーターに興味がある場合は、以下をお勧めします.自分で情報を確認してください。

パフォーマンスの問題に飛び込む前に、仮想化環境はそれに割り当てられたリソースを超えることができないことを強調することが重要です。パフォーマンスを改善する唯一の方法は、仮想マシンにより多くのリソースを割り当てる (弾力性) か、複数の仮想マシン コピーを使用してトラフィックの負荷分散 (弾力性とクラスタリング) を実現することです。実装。

以下で説明する最適化メカニズムは、仮想マシンがより効率的な方法で仮想化環境を使用し、仮想化のオーバーヘッドを削減できるようにすることです. これらの最適化手法は、VNF の全体的なパフォーマンス (スループットと遅延を含む) を改善するために非常に重要です.

1.CPU 使用率を最適化する

CPU 最適化手法について説明するときは、次の CPU 用語を理解する必要があります。

  • マルチソケット: CPU ソケットは、CPU がマザーボードに差し込まれる電気コネクタです. マルチソケット システムでは、複数の物理 CPU を同じ物理ホスト ハードウェアで使用できます.
  • マルチコア: 現在の物理 CPU には、複数の独立した処理エンジンまたは処理ユニットがあります. これらの処理ユニットはコアであり、これらのコアは、CPU によって同時に実行される命令の数を増やすことができます. これらのコアは、1 つ以上のオペレーティング システム プロセスが必要とする CPU 命令を処理する個別のレーンと考えることができます。
  • マルチスレッド (または同時マルチスレッド): このテクノロジにより、CPU コアは異なるアプリケーション スレッドからの命令を同時に処理できます。SMT (Simultaneous Multithreading、同期マルチスレッド) テクノロジを利用して CPU コアの使用率を向上させると、通常、アプリケーションのパフォーマンスを大幅に向上させることができます。IntelはSMTを実装するために独自の独自技術を使用しており、HT(Hyper-Threading、Hyper-Threading)と呼ばれています。

使用可能な CPU、ソケット、およびコアの数を確認するための Linux ユーティリティは lscpu (util-linux パッケージの一部) であり、このユーティリティからの出力例を以下に示します。

Linux:~$ lscpu
Architecture:             x86_64
CPU op-mode(s):           32-bit, 64-bit
Byte Order:               Little Endian
CPU(s):                   32
On-line CPU(s) list:      0-31
Thread(s) per core:       2
Core(s) per socket:       8
Socket(s):                2
NUMA node(s):             2
<snip>

出力からわかるように、システムは 32 CPU システムであり (システムには 2 つの CPU ソケットがあり、各 CPU ソケットには 8 つのコアがあるため)、マルチタスクが可能で、各コアは 2 つのスレッドを実行します。

8 つのコアと 2 つのソケットを備えたシステムは、16 の専用コアを提供でき、ホスト オペレーティング システムまたはハイパーバイザーは、プロセッサのマルチタスク機能を利用して、より多くの仮想 CPU をシステムに提供できます。これらの CPU がデュアルスレッド対応の場合、システムは最大 32 個の仮想 CPU (2 ソケット x 8 コア/ソケット x 2 スレッド/コア) を提供すると見なすことができます。

ほとんどの高性能サーバーは、マルチソケット、マルチコア CPU を使用しています。CPU の仮想化後、理論上はすべてのコアを VNF に割り当てることができ、ホストを使用する別の仮想マシンも同じ数のコアを割り当てることができます.ハイパーバイザーは仮想マシン全体の CPU コアの使用を管理できるため、これは問題ありませんが、これを行うと、特に仮想マシンがほとんどの CPU リソースを瞬時に消費する場合に、予測できない CPU の可用性の問題が発生する可能性があります。

パケット処理など、CPU の可用性に依存する時間に敏感なアプリケーションの場合、この状況は過度のジッターやパケット損失につながる可能性があります。

VNF のパフォーマンスを向上させたい場合は、次の一般的なテクノロジを検討できます。

  • ハイパースレッディングを無効にする

HT または SMT テクノロジを有効にすると、スレッド間で物理コアを論理的に共有する必要があるため、パフォーマンスに一貫性がなくなる場合があります。通常、SMT または HT を無効にすると、CPU が VNF と他のアプリケーションの間を行き来する必要がないため、VNF はよりスムーズなパケット処理パフォーマンスを実現できますが、そうすることでシステムのスケーラビリティが低下します (論理パケット数の減少)。 CPU)。

ただし、この操作はサーバーの BIOS (Basic Input/Output System、Basic Input/Output System) で実行する必要があるため、実際のアプリケーションでは常に HT または SMT を無効にできるとは限りません。つまり、サーバー全体を再起動する必要があります。考えられる解決策の 1 つは、VNF の CPU コアを分離し (名前空間または同様の手法を活用)、VNF が使用している CPU スレッドを他のアプリケーションが使用できないようにすることです。

  • CPU バインディングまたはプロセッサ アフィニティ

プロセスが物理プロセスにバインドされた後、ハイパーバイザー スレッドは CPU 間を行き来しないため、スムーズなパフォーマンスとより優れたメモリ キャッシュ使用率が実現されます。

この手法を使用する場合は、プロセッサの複数のスレッドを同じソケットの CPU にバインドすることに注意する必要があります。

  • 中断のないカーネルを使用する

Linux カーネルは、処理を中断してシステムを遅くすることなく、特定の CPU コアが関連するタスクを実行できるようにするフラグを使用してコンパイルできます。明らかに、これにはカーネルの再コンパイルが必要であり、実行中のシステムでは実行できません。

ただし、上記の操作を実現する場合、Tickless カーネルを使用すると、VNF アプリケーションのパフォーマンスを大幅に向上させることができます。

2.メモリ使用率を最適化する

CPU は、処理中にメモリを頻繁に読み書きする必要があります。高速メモリを使用すると、CPU がメモリからデータを取得したりメモリにデータを格納したりするのに多くのサイクルを費やさないようにすることができます。メモリ アクセス時間は、格納されたデータの検索と照合、および読み取られて処理を待機しているデータのキューイングに重要です。

たとえば、一部の物理ルーターは TCAM (Ternary Content Addressable Memory) などの専用の高性能メモリを使用して、検索可能なデータ (ルーティング情報など) を保存しますが、VNF が汎用ハードウェアで動作し、他のプロセス メモリと共有されている場合、その場合、対応する権限を取得できません。

古いシステムの場合、プロセッサはユニファイド メモリ アクセスと呼ばれる単一のメモリ バンクにアクセスします。大量のメモリを搭載したマルチソケット、マルチプロセッサ サーバーは、メモリをリージョン (ノードとも呼ばれます) に分割し、CPU ソケットとペアになっています. この NUMA (Non-Uniform Memory Access, non-uniform memory access ) テクノロジーでは、それぞれのCPU は、NUMA 境界を越えて共有メモリにアクセスする前に、まず独自のローカル メモリにアクセスします (読み取りと書き込みが高速化されます)。アプリケーションが NUMA 境界内で動作するように制限されている限り、システム パフォーマンスは効果的に向上します。

おすすめ

転載: blog.csdn.net/qq_35029061/article/details/128732972