nftlb benchmarks en prestatiesleutels

GEPOST DOOR Zevenet | 28 juni 2018

benchmarks

Latests-benchmarks, gedateerd in juni 2018, tonen een belangrijke verbetering van de prestaties bij het gebruik van nftables als datapad in plaats van iptables.

Gegeven een testomgeving van 2-clients die een HTTP-belastingstressprogramma uitvoeren, 1-load balancer en 3-backends met een HTTP-terminator die een respons van ongeveer 210-bytes levert, verkrijgen we de volgende benchmarks in HTTP-stromen per seconde:

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

De bovenstaande cijfers worden weergegeven in termen van per fysieke CPU, omdat de schaalbaarheidstoevoegingen bijna lineair zijn. Hoewel deze benchmarks zijn uitgevoerd met alleen 3-backends, De prestaties van iptables zullen aanzienlijk afnemen terwijl meer backends worden toegevoegd, omdat ze meer opeenvolgende regels impliceren.

Die benchmarks werden uitgevoerd met retpoline uitgeschakeld (geen Spectre / Meltdown-oplossingen), maar zodra ze zijn ingeschakeld, zijn de prestatieboetes die zijn gedetecteerd in NAT-gevallen met conntrack ingeschakeld voor zowel iptables als nftables-gevallen veel erger voor de eerste:

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

Prestatiesleutels

De boetes van de retpoline worden verklaard vanwege het gebruik van veel meer indirecte aanroepen in iptables dan in nftables. Maar ook zijn er enkele meer prestatietoetsen die hieronder worden uitgelegd.

Regels optimaliseren

De belangrijkste prestatietoets is de optimalisatie van de regels. In iptables was het al bekend dat het gebruik van ipset de prestaties verbetert omdat het de verwerking van sequentiële regels vermindert.

Hoewel in nftlb het kan worden uitgebreid om voor andere doeleinden te worden gebruikt, stellen we een basisregels per virtuele service vast met behulp van de expressieve taal die van nature het gebruik van sets en kaarten ondersteunt. Zie hieronder de gegenereerde regels voor a virtuele tcp-service met de naam vs01 met 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 }
    }
}

Zodra we een nieuwe back-end moeten toevoegen, hoeft u alleen maar de gekoppelde keten opnieuw te genereren naar de virtuele service zonder nieuwe regels toe te voegen en zonder de rest van de andere virtuele services te beïnvloeden.

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

Dan, als een nieuwe virtuele dienst vs02 moet worden gemaakt, dan wordt de regelset zoals hieronder wordt weergegeven, zonder de toevoeging van nieuwe regels of andere virtuele services te beïnvloeden:

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

Vroege haken

nftables staat het gebruik van early toe ingangshaak dat wordt gebruikt in nftlb tijdens DSR-scenario's.

Ook kan deze vroege haak worden gebruikt voor filterdoeleinden die de prestaties verhogen in gevallen van dropping van pakketten. Dit wordt hieronder getoond met de meest vroege fase van iptables en nftables cases in pakketten per seconde:

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

Versnellingstechnieken

Er is nog steeds meer ruimte voor optimalisatie, aangezien nftables al snelle paden en lichtgewichttechnieken ondersteunt die kunnen worden gebruikt voor pakketmangelen. Als voorbeelden daarvan zijn:

Flowtables. Conntrack snel pad om reeds bestaande verbindingen naar de intredefase te delegeren zonder het hele langzame pad te passeren. Meer informatie hier.

Staatloze NAT. Voor sommige load-balancing-gevallen kan stateless NAT worden uitgevoerd zonder verbindingstracering en vanuit de ingangsfase om alle prestaties te verkrijgen die worden toegepast op NAT-scenario's.

Delen op:

Documentatie onder de voorwaarden van de GNU-licentie voor vrije documentatie.

Was dit artikel behulpzaam?

Gerelateerde artikelen