ベンチマーク #

2018 年 XNUMX 月の最新ベンチマークでは、iptables の代わりに nftables をデータ パスとして使用すると、パフォーマンスが大幅に向上することが示されています。

HTTP負荷ストレスツールを実行する2つのクライアント、1つのロードバランサ、および約3バイトの応答を送信するHTTPターミネータを備えた210つのバックエンドのテストベッド環境を考えると、次のベンチマークが得られます。 1秒あたりのHTTPフロー:

iptables DNAT 256.864,07 RPS / cpu iptables SNAT 262.088,94 RPS / cpu nftables DNAT 560.976,44 RPS / cpu nftables SNAT 608.941,57 RPS / cpu nftables DSR 7.302.517,31 RPS / cpu

上記の数値は、コアの追加によるスケーラビリティがほぼ線形であるため、物理CPUあたりで示されています。これらのベンチマークは3つのバックエンドのみで実行されていますが、 バックエンドを追加するとiptablesのパフォーマンスが大幅に低下しますより連続的なルールを意味するためです。

これらのベンチマークは、retpoline を無効にした状態で実行されました (Spectre/Meltdown の緩和策なし)。ただし、これらを有効にすると、iptables と nftables の両方のケースで conntrack が有効になっている NAT ケースで検出されたパフォーマンスの低下は、最初のケースで大幅に悪化します。

iptables: 40.77% CPU ペナルティ nftables: 17.27% CPU ペナルティ

パフォーマンスキー #

retpoline ペナルティは、iptables では nftables よりも間接呼び出しがはるかに多く使用されるためであると説明されています。ただし、以下で説明するパフォーマンス キーもいくつかあります。

ルールの最適化 #

パフォーマンスの主な鍵はルールの最適化です。ipset を使用すると、順次ルール処理が削減されるため、パフォーマンスが向上することは、iptables ではすでにわかっていました。

nftlbでは、他の目的にも使用できるように拡張できますが、セットとマップの使用をネイティブにサポートする表現言語を使用して、仮想サービスごとに基本ルールを設定します。生成されたルールについては以下を参照してください。 01 つのバックエンドを持つ vs2 という名前の仮想 TCP サービス:

テーブル ip nftlb { マップ tcp-services { タイプ ipv4_addr . inet_service : 判定
        要素 = { 192.168.0.100 . http : vs01 に移動 }
    } チェーン プレルーティング { タイプ nat フック プレルーティング 優先度 0; ポリシー accept;
        ip daddr . tcp dport vmap @tcp-services
    } チェーン postrouting { type nat hook postrouting priority 100; policy accept; }

    チェーン vs01 { dnat から jhash ip saddr mod 2 マップ { 0 : 192.168.1.10, 1 : 192.168.1.11 } }
}

新しいバックエンドを追加する必要がある場合は、新しいルールを含めず、他の仮想サービスに影響を与えずに、仮想サービスに関連付けられたチェーンを再生成するだけです。

    チェーンvs01 {
        dnat から jhash ip saddr mod 3 マップ { 0 : 192.168.1.10、1 : 192.168.1.11、2 : 192.168.1.12 }
    }

そして、新しい仮想サービスが vs02 作成する必要がある場合、新しいルールが追加されたり、他の仮想サービスに影響を与えたりすることなく、ルールセットは以下に示すようなものになります。

テーブル ip nftlb { マップ tcp-services { タイプ ipv4_addr . inet_service : 判定要素 = { 192.168.0.100 . http : goto vs01,
                     192.168.0.102 . https: vs02 へ移動 } } チェーン プレルーティング { type nat hook prerouting priority 0; policy accept; ip daddr . tcp dport vmap @tcp-services } チェーン ポストルーティング { type nat hook postrouting priority 100; policy accept; } チェーン vs01 { dnat to jhash ip saddr mod 3 map { 0 : 192.168.1.10, 1 : 192.168.1.11, 2 : 192.168.1.12 } }

    チェーン vs02 { dnat から jhash ip saddr mod 2 マップ { 0 : 192.168.2.10, 1 : 192.168.2.11 } }
}

初期のフック #

nftablesは早期の使用を許可します 進入フック DSR シナリオ中に nftlb で使用されます。

また、この初期フックは、パケットがドロップされた場合のパフォーマンスを向上させるフィルタリングの目的にも使用できます。これは、1 秒あたりのパケット数で iptables と nftables の最も初期段階のケースで以下に示されています。

iptables プレルーティング 生ドロップ: 38.949.054,35 PPS / コア nftables イングレス ドロップ: 45.743.628,64 PPS / コア

加速技術 #

実際、nftables はすでにパケット加工に使用できる高速パスと軽量テクニックをサポートしているため、最適化の余地はまだあります。その例を次に示します。

フローテーブル. すでに確立されている接続を、低速パス全体を通過せずにイングレス ステージに委任する Conntrack 高速パス。 詳細はこちら.

ステートレスNAT一部の負荷分散ケースでは、接続追跡なしで、入力段階からステートレス NAT を実行して、NAT シナリオに適用されるすべてのパフォーマンスを得ることができます。