Indholdsfortegnelse

benchmarks #

De seneste benchmarks, dateret juni 2018, viser en betydelig forbedring af ydeevnen ved at bruge nftables som datasti i stedet for iptables.

Givet et testmiljø med 2 klienter, der udfører et HTTP load stress-værktøj, 1 load balancer og 3 backends med en HTTP-terminator, der leverer et svar på omkring 210 bytes, opnår vi følgende benchmarks i HTTP-flows per sekund:

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

Ovenstående tal er vist pr. fysisk CPU, da skalerbarheden ved tilføjelse af kerner er næsten lineær. Selvom disse benchmarks kun er udført med 3 backends, iptables' ydeevne vil falde betydeligt, når der tilføjes flere backends, da de indebærer mere sekventielle regler.

Disse benchmarks blev udført med retpoline deaktiveret (ingen Spectre/Meltdown-afhjælpninger), men når de først er aktiveret, er de performance-straffe, der registreres i NAT-tilfælde med conntrack aktiveret for både iptables- og nftables-tilfælde, meget værre for den første:

iptables: 40.77% CPU-straf nftables: 17.27% CPU-straf

Ydelsesnøgler #

Retpoline-straffene forklares ved brugen af langt flere indirekte kald i iptables end i nftables. Men der er også nogle flere ydeevnenøgler, som vil blive forklaret nedenfor.

Regeloptimering #

Den primære ydeevnenøgle er regeloptimering. Det var allerede kendt i iptables, at brugen af ipset øger ydeevnen, da det reducerer den sekventielle regelbehandling.

I nftlb, selvom det kunne udvides til at blive brugt til andre formål, sætter vi grundlæggende regler pr. virtuel tjeneste ved hjælp af det udtryksfulde sprog, der native understøtter brugen af sæt og kort. Se nedenfor de genererede regler for en virtuel tcp-tjeneste ved navn vs01 med 2 backends:

tabel ip nftlb { kort tcp-tjenester { type ipv4_addr . inet_service : verdict {
        elementer = { 192.168.0.100 . http: goto vs01 }
    } chain prerouting { type nat hook prerouting prioritet 0; politik accepterer;
        IP-daddr. tcp-port vmap @tcp-services
    } chain postrouting { type nat hook postrouting prioritet 100; politik accepterer; }

    kæde vs01 { dnat til jhash ip saddr mod 2 kort { 0 : 192.168.1.10, 1 : 192.168.1.11 } }
}

Når vi har brug for at tilføje en ny backend, skal vi blot regenerere den tilknyttede kæde til den virtuelle tjeneste uden at inkludere nye regler og uden at påvirke resten af de andre virtuelle tjenester.

    kæde vs01 {
        dnat til jhash ip saddr mod 3 kort { 0 : 192.168.1.10, 1 : 192.168.1.11, 2 : 192.168.1.12 }
    }

Så hvis en ny virtuel tjeneste vs02 skal oprettes, bliver regelsættet som vist nedenfor, uden tilføjelse af nye regler eller påvirkning af andre virtuelle tjenester:

tabel ip nftlb { kort tcp-tjenester { type ipv4_addr . inet_service : verdict elementer = { 192.168.0.100 . http : goto vs01,}  Tag: * ...
                     192.168.0.102. https: gå til 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 til jhash ip saddr mod 3 map { 0 : 192.168.1.10, 1 : 192.168.1.11, 2 : 192.168.1.12 } }   Bemærk: `DNAT to JHASH IP SADDR MOD XNUMX MAP` ...

    kæde vs02 { dnat til jhash ip saddr mod 2 kort { 0 : 192.168.2.10, 1 : 192.168.2.11 } }
}

Tidlige kroge #

nftables tillader brugen af tidlig indgangskrog som bruges i nftlb under DSR-scenarier.

Denne tidlige hook kan også bruges til filtreringsformål, hvilket øger ydeevnen i tilfælde af tab af pakker. Dette er vist nedenfor med de tidligste stadier af iptables og nftables i pakker pr. sekund:

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

Accelerationsteknikker #

Der er stadig mere plads til optimering, da nftables allerede understøtter hurtige veje og letvægtsteknikker, der kan bruges til pakkemanipulation. Eksempler på dette er:

FlowtabellerConntrack fast path til at delegere allerede etablerede forbindelser til indgangsfasen uden at gå gennem hele den langsomme sti. Mere info her.

Statsløs NATI nogle tilfælde af load balancing kan stateless NAT udføres uden forbindelsessporing og fra ingress-fasen for at opnå al den ydeevne, der anvendes i NAT-scenarier.

nftlb-benchmarks og ydeevnenøgler