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

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% CPU penalty
nftables: 17.27% CPU penalty

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

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.

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

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

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:

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

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.