Repères #
Les derniers repères, datés de juin 2018, montrent une amélioration importante des performances en utilisant nftables comme chemin de données au lieu d’iptables.
Étant donné l’environnement de testbed des clients 2 exécutant un outil de contrainte de charge HTTP, l’équilibreur de charge 1 et les backends 3 avec un terminateur HTTP fournissant une réponse d’environ 210, nous obtenons les tests suivants dans Flux HTTP par seconde:
iptables DNAT 256.864,07 RPS / processeur iptables SNAT 262.088,94 RPS / processeur nftables DNAT 560.976,44 RPS / processeur nftables SNAT 608.941,57 RPS / processeur nftables DSR 7.302.517,31 RPS / processeur
Les chiffres ci-dessus sont présentés en termes de CPU physique, car les cœurs d'addition évolutifs sont presque linéaires. Bien que ces tests aient été réalisés avec uniquement des moteurs 3, Les performances d'iptables chuteront considérablement en ajoutant plus de serveurs, car ils impliquent davantage de règles séquentielles.
Ces benchmarks ont été effectués avec la rétpoline désactivée (pas d'atténuation Spectre / Meltdown), mais une fois activées, les pénalités de performance détectées dans les cas NAT avec conntrack activé pour les cas iptables et nftables sont bien pires pour le premier:
iptables : 40.77 % de pénalité CPU nftables : 17.27 % de pénalité CPU
Clés de performance #
Les pénalités de rétine sont expliquées par l’utilisation d’appels beaucoup plus indirectionnels dans iptables que dans nftables. Mais aussi, il y a plus de clés de performance qui seront expliquées ci-dessous.
Optimisation des règles #
La clé de performance principale est l'optimisation des règles. Iptables savait déjà que l’utilisation d’ipset améliorait les performances en réduisant le traitement des règles séquentielles.
Dans nftlb, bien qu'il puisse être étendu pour être utilisé à d'autres fins, nous définissons des règles de base par service virtuel en utilisant le langage expressif qui prend en charge de manière native l'utilisation d'ensembles et de cartes. Veuillez voir ci-dessous les règles générées pour un service tcp virtuel nommé vs01 avec backends 2:
table ip nftlb { carte tcp-services { tapez ipv4_addr . inet_service : verdict
éléments = { 192.168.0.100 . http : aller à vs01 }
} préroutage de chaîne { type priorité de préroutage de crochet nat 0 ; politique acceptée ;
ip papa. tcp dport vmap @tcp-services
} postroutage de chaîne { type nat hook postrouting priorité 100 ; politique acceptée ; }
chaîne vs01 { dnat vers jhash ip saddr mod 2 carte { 0 : 192.168.1.10, 1 : 192.168.1.11 } }
}
Une fois que nous avons besoin d'ajouter un nouveau serveur, il vous suffit de régénérer la chaîne associée au service virtuel sans inclure de nouvelles règles et sans affecter le reste des autres services virtuels.
chaîne vs01 {
dnat à jhash ip saddr mod 3 carte { 0 : 192.168.1.10, 1 : 192.168.1.11, 2 : 192.168.1.12 }
}
Ensuite, si un nouveau service virtuel vs02 doit être créé, puis l'ensemble de règles devient comme indiqué ci-dessous, sans l'ajout de nouvelles règles ni affecter les autres services virtuels:
table ip nftlb { mappe les services TCP { tapez ipv4_addr . inet_service : éléments de verdict = { 192.168.0.100 . http : allez à vs01,
192.168.0.102 . https : aller à vs02 } } préroutage de chaîne { type nat hook préroutage priorité 0 ; politique acceptée ; ip papa. tcp dport vmap @tcp-services } postrouting en chaîne { tapez nat hook postrouting priorité 100 ; politique acceptée ; } chaîne vs01 { dnat vers jhash ip saddr mod 3 carte { 0 : 192.168.1.10, 1 : 192.168.1.11, 2 : 192.168.1.12 } }
chaîne vs02 { dnat vers jhash ip saddr mod 2 carte { 0 : 192.168.2.10, 1 : 192.168.2.11 } }
}
Premiers crochets #
nftables permet l’utilisation de crochet d'entrée qui est utilisé dans nftlb lors de scénarios DSR.
En outre, ce premier raccordement peut être utilisé à des fins de filtrage qui améliorent les performances en cas de perte de paquets. Ceci est montré ci-dessous avec le stade le plus précoce des cas iptables et nftables en paquets par seconde:
Chute brute de préroutage iptables : 38.949.054,35 PPS/cœur Chute d'entrée nftables : 45.743.628,64 PPS/cœur
Techniques d'accélération #
En fait, il reste encore beaucoup à faire pour l'optimisation, car nftables prend déjà en charge les chemins rapides et les techniques légères pouvant être utilisées pour la gestion des paquets. Comme exemples de cela sont:
Flowtables. Conntrack, voie rapide pour déléguer des connexions déjà établies à l’étape d’entrée sans passer par la totalité du chemin lent. Plus d'infos ici.
NAT sans état. Pour certains cas d'équilibrage de charge, le NAT sans état peut être effectué sans suivi de connexion et à partir de l'étape d'entrée pour obtenir toutes les performances appliquées aux scénarios NAT.
