OpenvSwitch オフロードに基づく UCloud の高性能 25G スマート ネットワーク カードの実践

ダブル11やフラッシュセールなどの繁忙期には、電子商取引ユーザーのトラフィックが急増し、仮想マシンネットワークのパフォーマンス向上の要求がますます緊急になり、25Gネットワ​​ークが徐々に標準になりつつあります。従来の純粋なソフトウェア仮想スイッチ ソリューションによってもたらされるパフォーマンスのボトルネックを解決するために、当社は業界で主流のスマート ネットワーク カード ソリューションを調査し、最終的に OpenvSwitch に基づくオープン ソース ソリューションを採用することを決定し、パブリック クラウドに実装することに成功しました。

[[250725]]

従来のソリューションと比較して、新しいスマート ネットワーク カード ソリューションは、スイッチ全体で小さなパケットの転送パフォーマンスが 24Mpps、単一の VF で受信パフォーマンスが 15Mpps であり、ネットワーク カードの全体的なパフォーマンスが 10 倍以上向上します。クラウドホストに適用すると、ネットワーク容量が少なくとも 4 倍増加し、レイテンシが 3 倍短縮されるため、電子商取引やその他のビジネスのピーク時の安定性の問題が効果的に解決されます。この記事では、新しいソリューションの選択から実装までのプロセスで遭遇する落とし穴と解決策を詳しく説明し、参考とインスピレーションを提供することを目指します。

業界主流のスマートネットワークカードソリューションの比較

従来のソフトウェア仮想スイッチのパフォーマンスのボトルネックは、物理ネットワーク カードからメッセージを受信した後、転送ロジックに従って vhost スレッドに送信し、vhost がそれを仮想マシンに渡して実行することです。このように、vhost の処理能力は、仮想マシンのネットワーク パフォーマンスに影響を与える鍵となります。

そのため、ホストマシン上の 25G SmartNIC を介してネットワーク トラフィックをオフロードすることが、業界で認められている主流の方向性となっています。現在、スマート ネットワーク カードの実装は数多く存在します。たとえば、AWS は汎用 ARM ベースのマルチコア ソリューションを採用し、Azure は FPGA ベースのソリューションを採用し、Huawei Cloud は専用のネットワーク プロセッサ (NP) ベースのソリューションを採用し、Alibaba Cloud はプログラム可能な ASIC チップ ベースのソリューションを採用しています。現時点では、それぞれの計画に長所と短所があり、特に優れた天下統一の計画は存在しません。

一般的な ARM および MIPS マルチコア ソリューションに基づいて、ホスト マシン上で元々実行されていた vSwitch をネットワーク カードに移植するだけで、Linux カーネルと DPDK の両方をサポートできるため、ホスト マシンのコンピューティング リソースを解放するという目的を達成できます。 FPGA、NP、およびプログラム可能な ASIC に基づく他のほとんどのソリューションは、ネットワーク カード上で高速転送パス (Fast Path) を維持します。メッセージを受信すると、まず、このタイプのメッセージの処理ルールが Fast Path にキャッシュされているかどうかがチェックされます。見つかった場合は、ルールに従ってアクションを直接実行し、見つからない場合は処理のためにスロー パスに転送します。このスローパスは、DPDK または Linux カーネルになります。

したがって、Fast Path にとって最も重要なことは、十分なアクションとカスタム アクションのスケーラビリティをサポートしているかどうかです。各メーカーの独自インターフェースに加えて、スロー パスおよびファースト パス通信には、DPDK によって提供される標準の TC オフロード インターフェースと RTE フロー インターフェースもあります。

しかし、FPGA は消費電力とコストが高く、研究開発サイクルが長く、迅速に実装できない上、ハードウェアからソフトウェアまで多くのリソースが必要になります。サードパーティのネットワーク カード製造元に基づくその他のソフトウェア カスタマイズ ソリューションは、ネットワーク カード ソフトウェアの安定性に関してサードパーティの製造元に大きく依存しており、問題が発生した場合にすぐに特定してトラブルシューティングを行うことができません。

私たちのおすすめ

業界に完璧な実装ソリューションが存在しなかったため、私たちはオープンソース テクノロジーに注目し始めました。 OpenvSwitch 自体が Linux Tc Flower Offload インターフェイスをサポートしているため、既存の制御プレーンや管理プレーンへの影響はほとんどなく、ユーザーが使用できるように迅速に適用および開発できます。そのため、Tc Flower Offload をベースにした OpenvSwitch オープンソース ソリューションを選択しました。

メッセージ処理は、受信から最終宛先にメッセージを送信するための一連の連続操作として考えることができ、最も一般的な処理は送信または破棄です。この一連の操作は、通常、連続した一致とその後のアクション実行です。 Linux カーネル TC サブシステムの Tc Flower は、フローに基づいてパケットの転送を制御できます。フローは通常、パケットの共通フィールドに基づいて分類されます。これらのフィールドは、フロー キーと呼ばれる一致項目を形成します。フロー キーには、パケットの共通フィールドとオプションのトンネル情報が含まれます。 TC アクションは、パケットの破棄、変更、送信などの操作を実行します。

この方法は、OpenvSwitch の分類方法に似ています。 Tc Flower 分類子によるオフロードは、フローベースのシステムのスループットを向上させ、CPU 使用率を削減する強力な方法を提供します。

OpenvSwitch オフロードに基づくスマート NIC 実装

ソリューションが選択された後、元のアーキテクチャにそれを実装し始めました。このプロセスは順調に進んだわけではありません。実装中に、いくつかの問題も発生しました。

1. 仮想マシンの移行

実装の開始時に最初に行うことは、仮想マシンの移行です。さまざまなメーカーの SmartNIC は VF パススルー ソリューションに基づいており、VF の非移行性により仮想マシンの移行が困難になります。業界では、Azure は主に VF と virtio-net デバイス ソリューションの結合を通じてこの問題を解決していますが、この方法では一定レベルのユーザー介入が必要となり、仮想マシン イメージ管理の問題が発生します。

アップストリーム (https://patchwork.ozlabs.org/cover/920005/ ) の「virtio_net をパススルー デバイスのスタンバイとして動作させる」ソリューションを調査したところ、この環境ではユーザーが手動でボンディング操作を設定したり、特定のイメージを作成したりする必要がなく、ユーザー介入の問題を完全に解決できることがわかりました。最終的に、仮想マシンの移行には VF + スタンバイ virtio-net 方式を採用しました。具体的な移行プロセスは次のとおりです。

l virtio-net ネットワーク カードを使用して仮想マシンを作成し、ホスト上の VF を hostdev ネットワーク カードとして選択し、virtio-net ネットワーク カードと同じ MAC アドレスを設定して、仮想マシンに接続します。このようにして、仮想マシンは virtio-net および VF ネットワーク カードに対して同様のボンディング機能を自動的に形成します。現時点では、ホスト上の仮想マシンには 2 つのネットワーク データ プレーンが存在します。

仮想マシンの起動時に、virtio-net バックエンド タップ デバイスがホストの OpenvSwitch ブリッジに自動的に追加されます。仮想マシンのネットワーク カードを切り替える場合は、データパスも切り替える必要があります。 VF が仮想マシンに接続された後、OpenvSwitch ブリッジ上のタップ デバイスを VF_repr に置き換えます。

2. VXLANのencap/decapはオフロードできない

次に、SmartNIC 側を調整する必要があります。 Mellanox CX5 ネットワーク カードを例にとると、ソフトウェア環境には OpenvSwitch-2.10.0、ukernel-4.14、MLNX_OFED-4.4-1.0.0.0 が含まれます。 mlx5_core ドライバーの最新バージョンは Ethernet over GRE トンネル オフロードをサポートしていないため、最初に VXLAN 経由でテストしました。

下図の通り、eth2はPF、mlx_0はVF0の代表であり、以下のコマンドで初期化されます。まず、VF デバイスを有効にし、ドライバー mlx5_core から VF デバイスのバインドを解除し、PF デバイスの IP アドレスを設定し、PF ネットワーク カードのスイッチ モードを設定し、PF ネットワーク カードの encap 機能を有効にします。

OpenvSwitch の構成は次のとおりです。仮想マシン VF は、代表者 mlx_0 を使用して br0 に接続し、vxlan0 を介してもう一方の端に送信します。 VXLAN トンネルのローカル アドレスは 172.168.152.75、リモート アドレスは 172.168.152.208 です。

カプセル化/カプセル化解除メッセージは効果的に送受信できますが、ネットワーク カードにオフロードされません。

まず、dmesgにエラーが表示されていることに気付きました

原因を調べたところ、OpenvSwitch が vxlan デバイスを作成するときに、vxlan dport 情報をネットワーク カードに登録していなかったことが判明しました。 OpenvSwitch は通常、vxlan デバイスの netdev_ops->ndo_add_vxlan_port インターフェイスを介してこの機能を完了しますが、ukernel-4.14 などの新しいカーネルでは、netdev_ops->ndo_udp_tunnel_add インターフェイスを介して完了します。

その後、この問題を解決するために、OpenvSwitch にパッチ「datapath: support upstream ndo_udp_tunnel_add in net_device_ops」https://patchwork.ozlabs.org/patch/953417/ を提出しました。

3. デキャップメッセージをオフロードできない

上記の問題を解決した後、出力方向の encap メッセージは効果的にオフロードできますが、入力 decap メッセージは依然としてオフロードできません。

ケース 2 の vxlan decap プリントアウトは mlx_0 VF 上にあるため、decap ルールも VF ポートに送信される可能性があると推測されます。 tc ルールは vxlan_sys の仮想デバイス上に設定されるため、設定用の物理ネットワーク カードを見つける際に問題が発生している可能性があります。

コード分​​析により、仮想デバイスの物理ネットワーク カードがアクション デバイス、つまり mlx_0 VF を通じて検出され、OpenvSwitch から mlx_0 VF に送信された tc_flower が egress_dev のフラグを true として伝送していることがわかります。 VFに対応するPFにTCルールが設定されていることが推測できます。

この推論に従って、mlx5ドライバコードbackports/0060-BACKPORT-drivers-net-ethernet-mellanox-mlx5-core-en_.patchを調べました。

ukernel-4.14 は cls_flower->egress_dev フラグをサポートできますが、HAVE_TC_TO_NETDEV_EGRESS_DEV はサポートしていないことがわかりました。したがって、mlx5_core ドライバーにはカーネルの互換性を判断する上で問題があると結論付けられます。その後、この問題を解決するために、Mellanox に対応するパッチを提出しました。

4. バックエンドタップデバイスのencapメッセージが破棄される

ライブマイグレーションを行う場合は、バックエンドのタップデバイスが必要です。パケットを送信する際、OpenvSwitch はタップ デバイスに tc ルールを設定し、tc in_sw メソッドを使用して tunnel_key を設定し、それを gre_sys デバイスに転送して送信します。しかし、gre_sys デバイスはパケットを直接破棄するため、私たちは驚きました。

理由を分析した結果、tc オフロードの in_sw の場合、パケットは OpenvSwitch の転送ロジックをバイパスし、gre_sys デバイスを介して直接送信されることがわかりました。 OpenvSwitch-2.10.0 のカーネル モジュール コードを使用しています。カーネル モジュールの互換性をコンパイルすると、ukernel-4.14 は USE_UPSTREAM_TUNNEL をサポートしていないことが判明しました。したがって、gre_sys デバイスはカーネルに付属する gre デバイスではなく、nodo_start_xmit 関数を持たない OpenvSwitch 自体によって作成されたデバイスです。 OpenvSwitch カーネル状態 gre トンネルの転送は、実際には gre_sys デバイスを介して送信されません。

ukernel-4.14 は USE_UPSTREAM_TUNNEL をサポートしていませんが、カーネルの組み込み gre デバイスは ip_tunnel_key を介して nodo_start_xmit 送信をサポートできます。したがって、USE_UPSTREAM_TUNNEL フラグはカーネルの組み込み gre デバイスに対して有効です。

したがって、OpenvSwitchはacinclude.m4ファイルを判別できる。

OpenvSwitch は gre と erspan に基づいてこの機能を決定しますが、ukernel-4.14 では erspan に対して USE_UPSTREAM_TUNNEL フラグが無効です。

その後、アップストリーム https://patchwork.ozlabs.org/cover/848329/ パッチ シリーズ「ERSPAN バージョン 2 (タイプ III) サポート」を導入し、OpenvSwitch が USE_UPSTREAM_TUNNEL のカーネル サポートを認識できるようにして、gre_sys デバイス ドロップ メッセージの問題を解決しました。

5. イーサネットオーバーGREトンネルはオフロードできない

Mellanox が提供する ethernet over gre に基づくパッチをインストールした後、入力の decap 方向をオフロードできないことがわかりました。

これは、gre_sys デバイス上で tc ingress qdisc が生成されないからです。 OpenvSwitch は、tc ルールを設定するために vport の get_ifinex を通じてデバイスの ifindex を取得しますが、gre トンネル タイプの vport には、enable get_ifindex 関数がありません。

私たちはアップストリームの OpenvSwitch を検索し、「netdev-vport: TC ルールを使用するように gre netdev タイプを作成する」にパッチを適用することでこの問題を解決しました。

また、出力カプセル化オフロード メッセージは相手側では受信できません。パケットをキャプチャすると、gre ヘッダーに csum フィールドが含まれていることがわかりますが、OpenvSwitch 上の gre トンネルでは csum オプションが設定されていません。

リサーチ コード cls_tunne_key の設定アクションにはデフォルトで csum フィールドがあり、明示的に TCA_TUNNEL_KEY_NO_CSUM を設定して csum フィールドをオフにする必要があります。ただし、OpenvSwicth-2.10.0 ではこの適応は行われません。

私たちはアップストリームの OpenvSwitch を探し、最終的にパッチ「netdev-tc-offloads: TC csum オプションがトンネル構成と一致しない」で問題を解決しました。

要約すると、UCloud 25G SmartNIC の選択スキームと、実践の過程で遭遇したさまざまな技術的問題とその解決策について詳細に紹介しました。 ukernel、OpenvSwitch、mlx5_core ドライバーの機能を完成させ、バグを修正することで、最終的にこのオープン ソース ソリューションを正常に実装できました。

パフォーマンス比較

アプリケーションが実際に導入された後、OpenvSwitch によってアンロードされた高性能 25G スマート ネットワーク カード ソリューションに基づいて、vSwitch パフォーマンスと仮想ネットワーク カード パフォーマンスの観点から一連のパフォーマンス テストを実施しました。ご覧のように、

単一 VF の受信性能は 15Mpps に達します。

vSwitch 全体の転送パフォーマンスは、小さなパケットの場合 24Mpps です。

一般的に、従来の純粋なソフトウェア環境では、vSwitch の転送パフォーマンスは 2Mpps であり、仮想ネットワーク カードの受信パフォーマンスは 1.5Mpps 程度しかありません。元のソリューションと比較して、ネットワーク カードの全体的なパフォーマンスが 10 倍以上向上しました。

クラウド ホストに適用する場合、同じ 8 コア ホストで、UDP の小さなパケット (1 バイト) を受信するシナリオを例にとると、新しいソリューションの PPS 値は 469w に達する可能性がありますが、元の値は 108w です。

次のステップ

現在、このソリューションはパブリック クラウドにうまく適用されており、ネットワーク強化 2.0 クラウド ホストとしてリリースされる予定です。これにより、クラウド ホストのネットワーク機能が現在のネットワーク強化 1.0 バージョンの 4 倍以上に向上します。今後は、このソリューションをベアメタル物理クラウドホスト製品に移植し、パブリッククラウドと物理クラウドホストの機能とトポロジの一貫性を確保し、ステートフルファイアウォール/NATオフロードを検討する予定です。