benchmarks
Seneste benchmarks, dateret juni 2018, viser en vigtig forbedring af ydeevnen ved at bruge nftables som databane i stedet for iptables.
I betragtning af et testbaseret miljø hos 2-klienter, der udfører et HTTP-belastningsspændingsvæ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 strømmer pr. 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
Tallene ovenfor er vist i forhold til per fysisk CPU, da skalerbarheden, der tilføjer kerner, er næsten lineær. Selvom disse benchmarks er blevet udført med kun 3 backends, Iptables ydeevne vil falde væsentligt, mens der tilføjes flere backends, da de indebærer mere sekventielle regler.
Disse benchmarks blev udført med retpoline deaktiveret (ingen Spectre / Meltdown-afbødninger), men når de er aktiveret, er præstationsstrafferne, der er opdaget i NAT-sager, med konntrack aktiveret for både iptables og nftables-sager meget værre for den første:
iptables: 40.77% CPU penalty nftables: 17.27% CPU penalty
Ydelse nøgler
Retpolin straffen forklares på grund af brugen af langt flere indirection opkald i iptables end i nftables. Men også der er nogle flere ydeevne nøgler, der vil blive forklaret nedenfor.
Regler optimering
Hovedydende nøglen er regler optimering. Det var allerede kendt i iptables, at brugen af ipset øger ydeevnen, da den reducerer den sekventielle reglerbehandling.
I nftlb, selvom det kunne udvides til at blive brugt til andre formål, fastsætter vi en grundlæggende regler pr. Virtuel tjeneste ved hjælp af det ekspressive sprog, der støtter indbygget brug af sæt og kort. Se venligst de genererede regler for a virtuel tcp-tjeneste ved navn vs01 med 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 } } }
Når vi først skal tilføje en ny backend, skal du bare genskabe den tilknyttede kæde til den virtuelle tjeneste uden at medtage nye regler og uden at påvirke resten af de andre virtuelle tjenester.
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 } }
Så hvis en ny virtuel tjeneste vs02 skal oprettes, så bliver regelsættet som det er vist nedenfor uden tilføjelse af nye regler eller påvirkning af andre virtuelle tjenester:
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 } } }
Tidlige kroge
nftables tillader brug af tidligt indgangskrog der bruges i nftlb under DSR scenarier.
Også denne tidlige krog kan bruges til filtrering formål, der øger ydeevnen i tilfælde af at tabe pakker. Dette er vist nedenfor med den mest tidlige fase af iptables og nftables tilfælde i pakker per sekund:
iptables prerouting raw drop: 38.949.054,35 PPS nftables ingress drop: 45.743.628,64 PPS
Accelerationsteknikker
Der er stadig mere plads til optimering, da nftables allerede understøtter hurtige stier og lette teknikker, der kan bruges til pakke mangling. Som eksempler på det er:
Flowtables. Konflikt hurtig vej for at delegere allerede etablerede forbindelser til indgangsstadiet uden at passere hele den langsomme sti. Mere info her.
Stateless NAT. For nogle belastningsbalanceringstilfælde kan statsløs NAT udføres uden forbindelsessporing og fra indgangsstadiet for at opnå al den præstation, der anvendes på NAT-scenarier.