ホスティングにおけるSmartNIC：ネットワーク高速化を正しく評価する

ホスティングにおけるSmartNICの適切な位置づけ

用語 SmartNIC これは統一された標準的な製品名ではありません。したがって、ホスティングの計画において重要なのはラベルではなく、データパスにおける実証可能な機能です。つまり、そのカードがどのパケット、ルール、トンネルを処理できるか、ホスト側で処理されるタスクは何か、そしてどのソフトウェアがそれらの機能を制御するか、ということです。 ポート速度が高いからといって、これらの疑問は解決されません。

従来のネットワークカードは、主にイーサネット接続を提供し、チェックサムやセグメンテーションなど、一般的な基本オフロード機能をサポートしています。ある SmartNIC この枠組みを、特殊なデータパス機能やプログラム可能なデータパス機能によって拡張します。これには、フロー制御、仮想スイッチング機能、SR-IOV、トンネル処理、あるいは暗号関連のサブタスクなどが含まれます。ただし、これらの機能が利用可能かどうかは、モデル、ファームウェア、ドライバ、およびプラットフォームとの統合状況によって決まります。

A DPU 通常、より高度な構成となっています。ネットワークASICに加え、独自の演算リソースを備えており、独立したインフラストラクチャ・データパスを運用することができます。 NVIDIAは、BlueFieldについて、統合されたArmシステムがNICリソースとデータパスを制御する「DPUモード」と、カードが外部ホストに対してアダプターのように振る舞う「NICモード」を説明しています。これにより、動作モードに応じて、独自の管理領域および信頼領域も形成されます。

この分類は、調達や運用において実用的な影響を及ぼします。 単純な基本オフロードのみが必要な場合、独自の演算ロジックを備えたカードが必ずしも最適な選択肢とは限りません。逆に、テナント分離やセキュリティ機能のためにインフラストラクチャパスを外部化することは有効な場合もありますが、その場合は追加コンポーネントに対するファームウェアのメンテナンス、アクセス制御、監視、およびリカバリプロセスが必要となります。

100 GbE 以上のポートであっても、ファイアウォールルール、オーバーレイ、または暗号化の処理速度が向上するわけではありません。 決定的な要因となるのは、パケットサイズ、並列フロー数、ルールの範囲、そして必要な処理が実際にハードウェア上で実行可能かどうかという点です。サーバーのCPUがネットワークデータパスにおいて明らかにボトルネックとなっている場合にのみ、機能リストが処理能力の向上につながる可能性があります。

ハードウェアオフロードがデータパスに与える影響

これ以上のオフロードが行われない場合、パケットはまず物理NICに到達し、その後ホストによって処理されます。 アーキテクチャに応じて、パケットはカーネルネットワークスタック、ファイアウォール、ブリッジまたは仮想スイッチ、ルーティング、そして場合によってはオーバーレイ用のカプセル化を経由します。その後に初めて、VM、コンテナ、または他の物理ポートに到達します。各ステップでCPU時間やキューが発生する可能性があります。

このパスは、小さなパケットが多数ある場合、短命な接続が多数ある場合、あるいは大規模なクライアントポリシーがある場合に特に重要になります。ホストへの負荷となるのは、転送されるデータ量だけでなく、個々のパケットやフローの繰り返し処理も原因となります。そのため、 ネットワーク高速化 サーバーの一般的な特性ではなく、具体的に特定されたデータパスに対する意図的な負荷軽減である。

時点では ハードウェアオフロード 制御コンポーネントは、許可された転送ルールおよびフィルタリングルールをハードウェアデータパスに転送することができます。 この点について、Linuxのswitchdevモデルは、転送データパスをカーネルからスイッチデバイスへと移行させる仕組みを規定しています。実際にどのルールが引き継がれるかは、具体的なカード、そのドライバ、および上位のネットワーク統合の特性によって決まります。

開発ブランチ 4.0.90 の OVS ドキュメントでは、フローのハードウェアオフロードに関する個別のセクションについて、明示的に「実験的」であると記載されています。 まさにこの OVS と DPDK を組み合わせた構成について、ドキュメントでは、マッチとアクションの完全なオフロードと、マッチのみをオフロードする部分的なオフロードを区別しています。 この記述は、他のOVSバージョン、NIC、またはプラットフォームに対する、安定した普遍的な互換性の保証ではありません。

したがって、実際には、オフロードに関するあらゆる記述において、具体的なデータパス（使用されているソフトウェアのバージョン、ドライバ、ファームウェア、マッチフィールド、およびアクション）を明記する必要があります。スイッチが有効化されているからといって、関連するフローがオフロードされていること、あるいはセキュリティおよびネットワークのセマンティクスが変更なく満たされていることを証明するものではありません。 たとえば、VLANフィルタリングにおいて、switchdevは、ハードウェアがブリッジVLANルールを遵守し、許可されていないVLAN IDを破棄することを要求します。したがって、オフロードとは既存のルールを技術的に実装するものであり、それらを迂回する手段ではありません。

ホスティングにおいてSmartNICが有効な場面

SmartNICは、特に多数のVMが存在し、繰り返し転送決定が行われる仮想化プラットフォームにおいて有効です。SR-IOVは、VMに仮想機能を割り当てることができます。switchdevアーキテクチャでは、レプレゼンター・インターフェースがオペレーティングシステム内で物理機能または仮想機能をマッピングします。 これにより、これらのポート間のトラフィックに関するルールをハードウェアに実装することが可能になります。 とはいえ、その有用性は必要なVMの機能によって異なります。

マルチテナント対応のオーバーレイネットワークおよび マイクロセグメンテーション これもまた、検討すべき点の一つです。多くの顧客ネットワークで、VLAN やオーバーレイの割り当て、アクセス制御ルール、および同様のフロー決定が繰り返し行われる場合、適切なハードウェアデータパスを利用することで、ホスト CPU の負荷を軽減できます。 ただし、前提条件として、選択したカードおよびドライバにおいて、ルールの数、マッチフィールド、アクションが利用可能であり、ポリシーのセマンティクスが完全に維持されている必要があります。

Red Hat は、OpenShift Container Platform 4.22 において、互換性のある SmartNIC を搭載し、SR-IOV Network Operator が有効になっているベアメタルノード向けのハードウェアオフロードについて文書化しています。 ここでサポートされているのは、通常のポッド間でのポッド間通信およびポッドとClusterIPサービス間の通信のみであり、DPDKアプリケーションはこの機能では互換性がありません。また、このメリットは、関与するノードが互換性のあるSmartNICを使用している通信セグメントに限定されます。

暗号化されたホストネットワークやサイトネットワークにおいて、IPsecオフロードは、カプセル化、デカプセル化、暗号化、およびリプレイ保護のプロセスの一部または全体を処理することができます。 NVIDIAは、Cryptoオフロードやフルオフロードなど、さまざまなオフロード方式について文書化しています。ただし、これらがすべてのケースに普遍的に適用できるわけではありません。サポート状況や性能の限界は、モデル、ファームウェア、および暗号方式によって異なります。

単純なウェブホスティングサーバーは、あえて逆の例として挙げたものです。もしそのサーバーが主に少数の大きなHTTPレスポンスを返し、パケットパス上でCPU負荷が見られないのであれば、より専門化された サーバーハードウェア かえって運用負担を増やすだけだ。まず、ボトルネックの原因がアプリケーション、データベース、ストレージ、ネットワークのいずれにあるのかを特定すべきである。SmartNICは、こうした診断の代わりとして導入する価値はない。

運用事例を技術的に比較する

SmartNICの導入が妥当かどうかは、公称ポート速度ではなく、具体的なデータパスによって決まります。特に、繰り返し実行されるルールが多く、フロー数が膨大である場合や、オーバーレイ機能やセキュリティ機能が恒常的にホストCPUの処理時間を消費している場合には、その導入が理にかなっています。そのメリットは 経路依存性: 高速化されたセクションは、実際に互換性のあるハードウェアとサポートされているルールを通じて実行される接続にのみ役立ちます。

VMプラットフォームにおいては、 SR-IOV 典型的なアプローチ：仮想関数はVMに割り当てられ、一方、オペレーティングシステム内のRepresentorインターフェースは、そうした関数のポートをマッピングします。これにより、switchdev指向のアーキテクチャにおいて、仮想ポートと物理ポート間の転送ルールをハードウェア上で実装することが可能になります。 しかし、これだけでは、望ましいテナント分離や運用モデルが維持されているかどうかを確認する作業の代わりにはなりません。

Kubernetesは、一律の高速化を保証するものではない。文書化されているOpenShift 4.22との統合については、特定のサポート対象トラフィックパス、互換性のあるSmartNICノード、およびワークロードの要件が適用される。 オフロード対応ノードが通常のノードと通信する場合、その通常のノードはカーネル内で自身の処理部分を処理し、それによって全体的な通信経路を制限します。したがって、ロールアウトの際には、まず限定されたノードプールと実際の通信経路を考慮する必要があります。

暗号化されたホストネットワークやサイトネットワークにおいては、これらの用語を特に厳密に使用する必要があります。プラットフォームに応じて、カプセル化、デカプセル化、暗号化、およびリプレイ保護に関して、Crypto-OffloadからFull Offloadに至るまで、さまざまなIPsecのバリエーションが文書化されています。 したがって、一般的なスループットの保証は行われません。モデル、ファームウェア、採用されているアルゴリズム、および製品固有の制限によって、実際にどの処理がオフロードされるかが決まります。

展開前に互換性を確認する

調達プロセスは、オフロードオプションを有効にするのではなく、現状をありのままに把握することから始まります。 PCI-ID、ファームウェアのバージョン、ドライバ、カーネルを含む、正確なカードモデルを把握してください。さらに、eSwitchモード、およびOpen vSwitch、OVN、ハイパーバイザー、Kubernetesプラットフォームのバージョンと構成も把握しておく必要があります。カード自体の機能だけでは、ソフトウェアとの完全な統合が保証されないからです。

必要なルールセマンティクスは、事前にデータパス記述として用意しておく必要があります。例えば、VLAN割り当て、IPv4またはIPv6、TCPまたはUDP、トンネルタイプ、ヘッダー変更、転送、またはドロップなどです。 実験的なOVS 4.0.90のドキュメントでは、DPDK設定に関して、ハードウェア操作が欠落していると部分的なオフロードにつながる可能性があることが示されています。したがって、他のバージョンやプラットフォームについては、単なる検証依頼にとどまり、その機能範囲を保証するものではありません。

プラットフォームマトリックスとは バージョンに依存する互換性検証、NICファミリー全般に関する一般的な記述ではありません。OpenShift 4.22では、ハードウェアオフロード統合の対象として具体的なNICが挙げられており、その中にはConnectX-6 NICモードのBlueField-2も含まれています。 このことから、他のファームウェアやDPUモード、あるいは異なるディストリビューションへの対応が示唆されることはありません。したがって、ハードウェア、ファームウェア、ドライバ、プラットフォームバージョンの各組み合わせについて、個別に文書化してください。

Linuxのswitchdevにおいては、ハードウェアがソフトウェアネットワークのセマンティクスを維持することも極めて重要です。 たとえば、VLANフィルタリングの場合、オフロードを行うスイッチはブリッジのVLANルールを遵守し、許可されていないVLAN IDを破棄しなければなりません。この要件は、機能リストとセキュリティポリシーを併せて検証する必要がある理由を示しています。すなわち、処理の高速化によって、本来のネットワークセグメンテーションとは異なる構造が生じてはならないからです。

SmartNICとCPUおよびソフトウェアの比較検討

ネットワーク処理に制限がある場合、SmartNICはいくつかの選択肢のうちの1つに過ぎません。まずは、CPU容量の増強、適切なキュー数の設定、RSS、IRQの割り当て、あるいはカーネルのチューニングによって、すでにボトルネックが解消されるかどうかを確認する価値があります。 SoftIRQ、キュー、および割り込み割り当ての分類については、以下の記事が参考になります。 ホスティングにおけるCPUおよびネットワークスループット さらなる基礎知識。ネットワークのボトルネックが確認されない限り、追加の専用ハードウェアの導入はあくまで仮定に過ぎない。

DPDKとAF_XDPは、ホストCPU上のソフトウェアパスを短縮できますが、それぞれ独自のアーキテクチャおよびCPUの設計が必要です。継続的なポーリングに関する記述は、これら両方のアプローチに一律に当てはめることはできません： 記載された構成に関するOVS-DPDKのドキュメントによると、1つのスレッドがDPDKデバイスを継続的にポーリングし、その際にCPUコアを完全に占有します。したがって、NUMAマッピング、コアの分離、および具体的なOVSとDPDKのバージョンは、設計上の考慮事項の一部となります。

従来のサーバー用NICであっても、チェックサム、セグメンテーション、あるいは個別のトンネル機能に対して十分なオフロードを提供できます。この選択肢は、大規模な仮想スイッチルール、テナント分離、あるいはハードウェアによるセキュリティデータパスが不要な場合に適しています。 SmartNICの導入が特に妥当となるのは、求められる機能がこうした基本機能の範囲を超え、かつ長期的に繰り返し発生する場合です。

容量に関する考え方は単純ですが、重要です。あるホスト上でパケット処理によってCPUコアがフル稼働しており、そのパケットの一定割合を完全にオフロードできる場合、CPUに余裕が生まれる可能性があります。 しかし、この余裕は、アプリケーション、メモリ、ストレージ、あるいはソフトウェアによるフォールバックが次のボトルネックとなっていない場合にのみ、利用可能なキャパシティとしてカウントされます。これは、リンクレートやカード価格から直接導き出されるものではありません。

したがって、同じ負荷プロファイルに基づいて代替案を比較してください。比較項目には、パケットサイズ、接続レート、制御数、トンネル、暗号化、および予想されるピーク負荷が含まれます。その際、データパスのCPU使用率をアプリケーション処理とは区別して計測し、実際にハードウェアで処理されているフローを確認してください。 CPUのボトルネック ファイアウォール、オーバーレイ、または仮想転送によるものは、評価を行うに足る確かな根拠となりますが、システム負荷が全般的に高いというだけではその根拠にはなりません。

稼働中のオフロードを可視化する

導入後、オフロードオプションが有効になっていると認識するだけでは不十分です。信頼性の高い運用実績は、 フローの状態 カードのカウンタ値、ドロップ率やエラー率、CPU使用率、そして将来のトラフィックに類似した負荷プロファイルなどです。これらのデータを総合して初めて、関連するフローが実際にハードウェアで処理されているのか、それともホストが依然としてデータパスの大部分を担っているのかが明らかになります。

比較を行う際には、運用担当者は変更の前後で、同じパケットサイズ、プロトコル、接続数、およびポリシーを考慮する必要があります。 純粋なギガビットスループットだけでは、小容量パケットや多数の並列フローによるボトルネックが見過ごされがちです。同様に重要な指標として、レイテンシ、関与するホストごとのCPU時間、Softirq負荷、キュードロップ、およびノードやポートへのトラフィック分散が挙げられます。

以下のコマンドは設定を変更しません。最初のクエリでは、イーサネットコントローラとして表示されるPCIデバイスと、ネットワークコントローラとして表示されるPCIデバイスの両方が対象となります。 ethtool -k 提供されている、あるいはNetdevで有効化されているオフロード機能を示していますが、eSwitch、SmartNIC、またはフローオフロードのいずれについても、完全にオフロードされていることを証明するものではありません。その他の出力も同様に、インベントリおよび設定データであり、特定のルールが完全にオフロードされていることを証明するものではありません。

lspci -nn | grep -Ei 'Ethernet controller|Network controller'
ethtool -k <interface>
ethtool -i <interface>
devlink dev show
ovs-vsctl get Open_vSwitch . other_config

Open vSwitch では、特に、設定されたハードウェアアクセラレーションと実際に観測された結果とを区別する必要があります。 OVS 4.0.90の開発ドキュメントでは、フローのハードウェアオフロードを「実験的」と位置付けており、完全または部分的なオフロードについては、このOVSとDPDKを組み合わせた構成についてのみ説明しています。 したがって、本番環境では、フロー情報とハードウェアカウンタを、ホストソフトウェアのカウンタと併せて評価する必要があります。

また、モニタリングには時間的な視点が必要です。短時間のテストではルールが正しいことが確認できる一方で、本番環境に近いプロファイルでは、後でテーブルの容量問題、まれなログパス、あるいは再構成が必要になる場合があります。 したがって、カードモデル、ファームウェア、ドライバ、プラットフォームのバージョンごとに、正常値と異常値を記録しておくことが有効です。そうすることで、アップデート後に、 データパス あるいは、単に観測された負荷が変化しただけである。

OpenShift 4.22 との統合においては、可視化範囲が通信経路全体を網羅している必要があります。文書化されているハードウェアオフロードのサポートは、特定のワークロードおよび通信タイプにのみ適用されます。 互換性のあるノードが、対応するSmartNICを持たないノードと通信する場合、後者はその区間をカーネル内で処理します。その結果、1台のホスト上の測定ポイントだけでは、エンドツーエンドのパスを完全に把握できない可能性があります。

典型的なエラーパターンと再発経路

最もよく見られる不具合のパターンは 不完全なオフロード. フローは、ハードウェア上の単純な特徴に基づいて識別できますが、サポートされていないアクションの場合、部分的または完全にソフトウェアパスに戻らなければなりません。 実験的なOVS 4.0.90のドキュメントでは、DPDK構成におけるこの部分的なオフロードについて説明されています。これはすべてのOVSインストールに当てはまる一般的な記述ではありませんが、具体的な統合を行う際に確認すべき重要なポイントを明らかにしています。

診断は、実際のパスに沿って開始されます。具体的には、入力ポート、仮想関数またはレプレゼンター、スイッチルール、トンネル処理またはポリシー処理、そしてターゲットワークロードです。ある段階の前後のカウンター値に整合性が認められない場合、それはマッチ、アクション、およびフォールバックを確認すべき理由となります。 有効化された機能であっても、この割り当てに取って代わるものではありません。なぜなら、カードの機能には、望まれるすべてのルールの組み合わせが含まれているわけではないからです。

異種クラスターでは、比較が難しくなります。OpenShift 4.22 では、ハードウェアオフロードは、関連するポッドおよびサービスが互換性のある SmartNIC を搭載したノードに割り当てられている場合にのみ行われます。 そのようなパスが通常のノードに到達した場合、その処理はカーネル内で行われ、通信量全体が制限されます。したがって、単一のアクセラレーション対応ノードだけでは、クラスターパス全体が完全にアクセラレーションされるわけではありません。

また、ポッドやネットワークの設定が適切でない場合も、期待される効果が得られない原因となります。Red Hat は、OpenShift 4.22 の機能に関して、適切に構成されたポッドがない状態でハードウェアオフロードを有効にすると、ポッドのスループットが低下する可能性があることを明確に指摘しています。 したがって、運用担当者は、問題が発生した場合、オプションをさらに有効化して対処するのではなく、まずワークロードの接続状況、ネットワークモード、および実際に達成されているフローを確認する必要があります。

制御容量とファームウェアの差異は、同じエラー分類に属します。クライアント数が多い場合、接続の持続時間が短い場合、または動的なポリシーが適用される場合、関連するフロー量が予想とは異なるペースで増加する可能性があります。 また、バージョンに依存するドライバや異なるファームウェアは、計画されたプラットフォームの組み合わせとは異なる機能を提供する場合があります。そのため、インベントリデータやカウンターは、常に具体的なルールセットとともにアーカイブする必要があります。

A 制御されたリカバリパス これにより、システムの稼働状況を診断可能に保ちます。これは、ソフトウェア処理が想定された代替手段として維持され、変更が比較ウィンドウと明確な中止基準を設けて段階的に展開されることを意味します。 なお、ソフトウェア・フォールバックは必ずしも不具合というわけではなく、選択されたハードウェア・パスが完全にはサポートしていないアクションに対して、想定された処理として機能する場合もあります。

調達と運用について現実的な判断を下す

調達に関する決定は、ポート速度や製品名ではなく、処理負荷から始まる。繰り返し行われるパケット処理が明らかにCPU時間を消費している場合、つまり多数の仮想ネットワーク、安定したポリシー群、オーバーレイトラフィック、あるいは定義済みの暗号化パスなどが存在する場合に、専用ハードウェアの導入は妥当である。 こうした実証がない場合は、CPUやキューのチューニング、あるいは適切な基本オフロード機能を備えた従来のNICの方が、よりシンプルな解決策となる可能性があります。

次に、 互換性証明書 具体的な組み合わせにおいて、カードモデルと動作モード、ファームウェア、ドライバ、カーネル、仮想スイッチまたはCNI、ならびに必要なマッチおよびアクション機能が適切に機能すること。 例えば、プログラム可能なインフラストラクチャアクセラレータは、ステートベースまたはセッションベースの機能に対するフローオフロードを提供できるが、だからといって、すべてのSmartNICやプラットフォームが同じ機能を提供するとは限らない。

期待されるCPU負荷の軽減は、パケット処理がボトルネックであった場合に限り、解放されたコアを有効に活用できるようになって初めて、容量として利用可能になります。例えば、それらをデータベース、Webワーカー、または予備として割り当てる場合は、それはアーキテクチャ上の決定であり、自動的なパフォーマンス向上ではありません。 したがって、その他のサーバー構成は依然として極めて重要であり、CPU、メモリ、ストレージは、ネットワークと同様に、アプリケーションに適したものでなければなりません。全体的な検討に関するより詳しい情報は、以下の記事をご覧ください。 ウェブホスティングにおけるパフォーマンスに影響するサーバーハードウェア.

IPsec の場合、検証は特に具体的です。文書化されているオフロードのバリエーションは、暗号オフロードから、カプセル化、デカプセル化、暗号化、リプレイ保護の完全なオフロードまで多岐にわたります。どのバリエーションが利用可能かは、モデル、世代、ファームウェア、および暗号設定によって異なります。 また、製品固有の注意事項には、特定の世代や帯域幅に関する制限が含まれている場合があり、これらについては導入前に承認審査の対象とする必要があります。

DPUは、独自の管理および信頼領域を決定に追加します。 BlueField-DPUモードでは、カードが単なるホストアダプタとして動作するのではなく、統合されたArmシステムがNICリソースとデータパスを制御します。これにより、インフラストラクチャタスクをホストから分離できますが、アクセス権、イメージ、アップデート、監視、および復旧に関する堅牢な設計が求められます。

したがって、経済的な観点からは、カード価格だけが重要なのではありません。それに対して、ホストCPUの負荷削減や回避、プラットフォームの予想寿命、さらには認定、交換部品、ファームウェアのメンテナンス、インシデント復旧にかかる追加コストといった要素も考慮する必要があります。 SmartNICの導入が有意義となるのは、この計算が再現可能なデータパスと、長期的に管理可能なライフサイクルに基づいている場合であり、単に専用ハードウェアが原則として高速に見えるからという理由ではありません。