ベンチマーク

6月2018日付のLatestsベンチマークは、iptablesの代わりにnftablesをデータパスとして使用する際のパフォーマンスの重要な改善を示しています。

HTTPロードストレスツール、2ロードバランサ、および1バックエンドを実行し、約3バイトの応答を提供する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のパフォーマンスはバックエンドを追加しながら大幅に低下しますというのは、それらはより逐次的な規則を意味するからです。

これらのベンチマークは、レトポリンを無効にして（Spectre / Meltdown緩和策なしで）実行されましたが、有効にすると、iptablesとnftablesの両方のケースでconntrackが有効になっているNATケースで検出されたパフォーマンスのペナルティは、最初のケースでははるかに悪化します。

iptables: 40.77% CPU penalty
nftables: 17.27% CPU penalty

パフォーマンスキー

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

ルールの最適化

パフォーマンスの主なポイントは、ルールの最適化です。 iptablesでは、ipsetを使用すると順次ルールの処理が減るため、パフォーマンスが向上することが既に知られています。

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

table ip nftlb {
    map tcp-services {
        type ipv4_addr . inet_service : verdict
        elements = { 192.168.0.100 . http : goto vs01 }
    }

    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
        ip daddr . tcp dport vmap @tcp-services
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
    }

    chain vs01 {
        dnat to jhash ip saddr mod 2 map { 0 : 192.168.1.10, 1 : 192.168.1.11 }
    }
}

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

    chain 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 作成する必要がある場合、新しいルールを追加したり、他の仮想サービスに影響を与えたりすることなく、ルールセットは次のようになります。

table ip nftlb {
    map tcp-services {
        type ipv4_addr . inet_service : verdict
        elements = { 192.168.0.100 . http : goto vs01,
                     192.168.0.102 . https : goto vs02 }
    }

    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
        ip daddr . tcp dport vmap @tcp-services
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
    }

    chain vs01 {
        dnat to jhash ip saddr mod 3 map { 0 : 192.168.1.10, 1 : 192.168.1.11, 2 : 192.168.1.12 }
    }

    chain vs02 {
        dnat to jhash ip saddr mod 2 map { 0 : 192.168.2.10, 1 : 192.168.2.11 }
    }
}

初期のフック

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

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

iptables prerouting raw drop: 38.949.054,35 PPS
nftables ingress drop: 45.743.628,64 PPS

加速テクニック

nftablesはすでに高速パスとパケットマングリングに使用できる軽量のテクニックをすでにサポートしているので、最適化の余地はまだあります。 その例としては、

フローテーブル。 低速パス全体を通過せずに、すでに確立されている接続を入力ステージに委任するための高速パスをConntrackします。 詳細はこちら.

ステートレスNAT。 一部のロードバランシングのケースでは、ステートレスNATは、NATシナリオに適用されるすべてのパフォーマンスを取得するために、接続追跡なしで、および入力ステージから実行できます。