NFTB-Benchmarks und Leistungsschlüssel

GESCHRIEBEN VON Zevenet | 28. Juni 2018

Benchmarks

Latests-Benchmarks vom Juni 2018 zeigen eine wichtige Verbesserung der Leistung bei der Verwendung von Nftables als Datenpfad anstelle von iptables.

In einer Testumgebung mit 2-Clients, die ein HTTP-Laststress-Tool ausführen, unterstützen 1 Load Balancer und 3 ein HTTP-Terminator, das eine Antwort von etwa 210-Bytes liefert, und erhalten folgende Benchmarks in HTTP-Flüsse pro Sekunde:

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

Die obigen Abbildungen sind in Bezug auf jede physische CPU dargestellt, da die Additionskerne für die Skalierbarkeit nahezu linear sind. Obwohl diese Benchmarks nur mit 3-Backends durchgeführt wurden, Die Leistung von iptables sinkt erheblich, während weitere Backends hinzugefügt werden, da sie mehr sequentielle Regeln impliziert.

Diese Benchmarks wurden mit deaktivierter Retpoline durchgeführt (keine Spectre / Meltdown-Abschwächung), aber sobald sie aktiviert sind, sind die in NAT-Fällen mit aktivierter Conntrack sowohl für iptables- als auch für nftables-Fälle festgestellten Leistungseinbußen für den ersten Fall viel schlechter:

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

Leistungsschlüssel

Die Retpoline-Strafen werden erklärt, weil in iptables viel mehr Umleitungsaufrufe verwendet werden als in Nftables. Es gibt aber auch einige weitere Leistungsschlüssel, die im Folgenden erklärt werden.

Regeloptimierung

Der Hauptleistungsschlüssel ist die Regeloptimierung. In iptables war bereits bekannt, dass die Verwendung von ipset die Leistung erhöht, da die Verarbeitung sequentieller Regeln reduziert wird.

In nftlb können wir, obwohl es für andere Zwecke verwendet werden könnte, grundlegende Regeln für jeden virtuellen Dienst festlegen. Dabei wird die Ausdruckssprache verwendet, die die Verwendung von Mengen und Karten unterstützt. Nachfolgend finden Sie die generierten Regeln für a Virtueller TCP-Service mit dem Namen vs01 mit 2-Backends:

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 }
    }
}

Wenn Sie ein neues Backend hinzufügen müssen, generieren Sie einfach die zugehörige Kette für den virtuellen Dienst neu, ohne dass neue Regeln hinzugefügt werden und der Rest der anderen virtuellen Dienste nicht beeinträchtigt wird.

    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 }
    }

Dann, wenn ein neuer virtueller Dienst vs02 muss erstellt werden, dann wird der Regelsatz wie unten gezeigt, ohne dass neue Regeln hinzugefügt werden oder andere virtuelle Dienste beeinflusst werden:

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 }
    }
}

Frühe Haken

nftables erlaubt die frühzeitige Nutzung Eindringhaken das wird in nftlb während DSR-Szenarien verwendet.

Dieser frühe Hook kann auch zu Filterzwecken verwendet werden, um die Leistung im Fall von Paketen zu erhöhen. Dies wird im Folgenden mit dem frühesten Stadium von iptables und nftables-Fällen in Paketen pro Sekunde gezeigt:

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

Beschleunigungstechniken

In der Tat gibt es noch mehr Raum für die Optimierung, da nftables bereits schnelle Pfade und leichte Techniken unterstützt, die für das Paketmangling verwendet werden können. Beispiele hierfür sind:

Flowtables. Conntrack Fast Path zum Delegieren bereits bestehender Verbindungen in die Ingress-Phase, ohne den gesamten langsamen Pfad zu durchlaufen. Mehr Infos hier.

Zustandsloses NAT. In einigen Fällen des Lastenausgleichs kann zustandsloses NAT ohne Verbindungsüberwachung und ab der Eingangsstufe ausgeführt werden, um die gesamte auf NAT-Szenarien angewendete Leistung zu erhalten.

Teilen:

Dokumentation unter den Bedingungen der GNU Free Documentation License.

War dieser Artikel hilfreich?

Verwandte Artikel