データ プレーン開発キット (DPDK) は、データ プレーン アプリケーションのパケット処理を強化する一連のライブラリで構成されています。

SE データ パスのパケット処理は次のとおりです。

  • サーバ健全性モニター

  • TCP/IP スタック - すべてのフローの TCP

  • SSL の終了

  • プロトコル ヘッダーの解析

  • SIP/L4/L7 アプリケーション プロファイルのサーバ ロード バランシング

  • パケットの送受信

SE システムの論理アーキテクチャ



SE システムの論理アーキテクチャの各コンポーネントの機能は次のとおりです。

作業プロセス

サービス エンジンの 3 つのプロセスは次のとおりです。

  • SE-DP

  • SE-Agent

  • SE-Log-Agent

SE-DP：プロセスのロールは、プロキシのみ、ディスパッチャーのみ、またはプロキシとディスパッチャーの組み合わせにすることができます。

  • プロキシのみ：アプリケーション/仮想サービスごとに定義された完全な TCP/IP、L4/L7 処理、およびポリシー。

  • ディスパッチャーのみ：

    • (v)NIC の Rx を処理し、各プロキシ サービスの現在の負荷に基づいて、プロキシ ロックレス RxQ を介してプロキシ サービス全体にフローを分散します。

    • ディスパッチャーは、NIC を介したパケットの受信と送信を管理します。

    • プロキシ TxQ をポーリングし、NIC に送信します。

  • プロキシ-ディスパッチャー：使用可能な構成とリソースに応じて、プロキシおよびディスパッチャーとして機能します。

SE–Agent：コントローラの構成およびメトリック エージェントとして機能します。これは、使用可能な任意のコアで実行できます。

SE-Log-Agent：ログのキューを保持します。これにより、次のアクションが実行されます。

  • すべての SE プロセスからログをバッチ処理し、コントローラのログ マネージャに送信します。

  • SE-Log-Agent は、使用可能な任意のコアで実行できます。

フロー テーブル

これは、フローに関する情報を格納する表です。プロキシ サービスへのフロー マッピングを維持します。

サービス エンジンは、使用可能なリソースに基づいて、最適な数のディスパッチャーを構成します。これは、サービス エンジン グループのプロパティを使用してオーバーライドできます。ネットワーク インターフェイス カード (NIC) の所有権と使用率に基づいて、次のような複数のディスパッチ スキームがサポートされています。

  • すべての NIC を所有してアクセスする単一のディスパッチャー プロセス。

  • 構成された数のディスパッチャーに分散される NIC の所有権。

  • すべてのディスパッチャー コアが 1 つ以上の NIC キュー ペアをポーリングするが、相互に排他的な se_dp を使用してキュー ペア マッピングを行うマルチキュー構成。

残りのインスタンスはプロキシと見なされます。NIC とディスパッチャーの組み合わせによって、SE が処理できる 1 秒あたりのパケット数 (PPS) が決まります。CPU 速度は、単一コアの最大データ プレーン パフォーマンス (CPS/RPS/TPS/Tput) を決定し、SE のコア数によって直線的に拡張されます。再起動を必要とせずに、SE のプロキシ能力を動的に増やすことができます。se_dp プロセスのサブセットは、トラフィック フローの処理でアクティブになります。残りの se_dp プロセスは、新しいフローを処理するために選択されません。すべてのディスパッチャー コアも、このプロセスのサブセットから選択されます。

SE グループ プロパティ max_num_se_dps を使用して、se_dp プロセスのアクティブ数を指定できます。ランタイム プロパティとして、再起動せずに値を増やすことができます。ただし、この数を減らした場合、SE が再起動されるまで有効になりません。

構成の例は次のとおりです。

[admin:ctr2]: serviceenginegroup> max_num_se_dps

INTEGER 1-128 Configures the maximum number of se_dp processes that handles traffic. If not configured, defaults to the number of CPUs on the SE.
[admin:aziz-tb1-ctr2]: serviceenginegroup> max_num_se_dps

INTEGER 1-128 Configures the maximum number of se_dp processes that handles traffic. If not configured, defaults to the number of CPUs on the SE.
[admin:ctr2]: serviceenginegroup> max_num_se_dps 2
[admin:ctr2]: serviceenginegroup> where | grep max_num
| max_num_se_dps                        | 2                     |
[admin:ctr2]: serviceenginegroup>

CPU 使用率の追跡

CPU に負荷がかかるのは、次の場合です。

  • プロキシ

  • SSL ターミネーション

  • HTTP ポリシー

  • ネットワーク セキュリティ ポリシー

  • WAF

  • ディスパッチャー

  • 高 PPS

  • 高スループット

  • 小さなパケット（DNS など）

ハイパーバイザーからゲスト仮想マシンへのパケット フロー

SR-IOV

Single Root I/O Virtualization (SR-IOV) は、物理ポート（PF（Platform Function：プラットフォーム機能）リソースの一部をゲスト OS に割り当てます。仮想機能 (VF) はゲスト仮想マシンの vNIC として直接マッピングされ、ゲスト仮想マシンは特定の VF のドライバを実装する必要があります。

SR-IOV は、CSP および OpenStack のアクセス権なしの展開でサポートされます。

SR-IOV の詳細については、『VMware NSX Advanced Load Balancer インストール ガイド』の「OpenStack への NSX Advanced Load Balancer のインストール」トピックの「DPDK での VLAN と NSX Advanced Load Balancer (OpenStack No-Access) 統合を使用した SR-IOV の概要」セクションを参照してください。

仮想スイッチ

ハイパーバイザー内の仮想スイッチは、L2 スイッチ機能を実装し、各ゲスト仮想マシンの vNIC にトラフィックを転送します。仮想スイッチは VLAN を vNIC にマッピングするか、オーバーレイ ネットワークを終端し、オーバーレイ セグメント ID を vNIC にマッピングします。

注：

AWS/Azure クラウドは、物理 NIC 内に完全な仮想スイッチとオーバーレイ ターミネーションを実装しており、ネットワーク パケットはハイパーバイザーをバイパスします。

このような場合、VF はゲスト仮想マシンの vNIC に直接マッピングされるため、ゲスト仮想マシンは特定の VF のドライバを実装する必要があります。

VLAN インターフェイスと VRF

VLAN

VLAN は、IP アドレスを使用して構成できる論理インターフェイスです。これは、親 vNIC インターフェイスの子インターフェイスとして機能します。VLAN インターフェイスは、ポート チャネル/ボンディングで作成できます。

VRF コンテキスト

VRF は、仮想ルーティングおよび転送ドメインを識別します。すべての VRF には、SE 内にルーティング テーブルがあります。物理インターフェイスと同様に、VLAN インターフェイスは VRF に移動できます。VLAN インターフェイスの IP サブネットは、VRF とそのルーティング テーブルの一部です。VLAN タグを持つパケットは、VRF コンテキスト内で処理されます。2 つの異なる VRF コンテキストのインターフェイスで IP アドレスが重複している可能性があります。

健全性モニター

健全性モニターは、パケット処理とともに同期操作としてプロキシ内のデータ パスで実行されます。健全性モニターは、すべてのプロキシ コア間で共有されるため、SE のコア数に合わせて直線的に拡張されます。

たとえば、仮想サービスごとにプール内に 5 台のサーバがあり、サーバごとに 1 つの健全性モニターがある 10 個の仮想サービスの場合、仮想サービス全体で 50 個の健全性モニターになります。専用のディスパッチャーを使用する 6 コア SE には、5 つのプロキシがあります。各プロキシは 10 個の健全性モニターを実行し、すべての健全性モニターの状態は、すべてのプロキシにまたがる共有メモリ内に維持されます。

カスタムの外部健全性モニターは SE 内で個別のプロセスとして実行され、スクリプトはプロキシに健全性モニターの状態を提供します。

注：

同じ SE グループに配置された仮想サービスでは、ある仮想サービスを使用して別の仮想サービスの健全性チェックを行うことはできません。

データパス インターフェイスの DHCP

DHCP (Dynamic Host Configuration Protocol) モードは、ベアメタル/LSC Cloud のデータパス インターフェイス（通常のインターフェイス/ボンディング）でサポートされます。ただし、コントローラ GUI から有効にすることもできます。

configure serviceengine <serviceengine-name> コマンドを使用して、コントローラから DHCP を有効にすることができます。

次のコマンドを使用して、目的の data_vnics index ( i ) を確認できます。

data_vnics index <i>
dhcp_enabled
save
save

これにより、目的のインターフェイスで DHCP が有効になります。

特定の data_vnic で DHCP を無効にするには、上記のコマンド シーケンスで dhcp_enabled を no s に置き換えます。

注：

管理対象外または未接続のインターフェイスで DHCP がオンになっていると、SE の停止シーケンスが遅くなり、コントローラによって SE が再起動される可能性があります。