Sommario

Parametri di riferimento #

I benchmark di latest, datati 2018 di giugno, mostrano un importante miglioramento delle prestazioni nell'utilizzo di nftables come percorso dati invece di iptables.

Dato un ambiente testbed di client 2 che eseguono uno strumento di load stress HTTP, 1 load balancer e 3 backends con un terminatore HTTP che fornisce una risposta di circa 210 byte, otteniamo i seguenti benchmark in Flussi HTTP al secondo:

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

Le figure sopra sono mostrate in termini di CPU fisica in quanto i core di scalabilità sono quasi lineari. Sebbene questi benchmark siano stati eseguiti solo con backend 3, Le prestazioni di iptables diminuiranno notevolmente aggiungendo più backend, in quanto implicano più regole sequenziali.

Questi benchmark sono stati eseguiti con retpoline disabilitato (nessuna mitigazione Spectre / Meltdown), ma una volta abilitati, le penalità sulle prestazioni rilevate nei casi NAT con conntrack abilitato per i casi iptables e nftables sono molto peggiori per il primo:

iptables: penalità della CPU del 40.77% nftables: penalità della CPU del 17.27%

Chiavi di prestazione #

Le penalità di retpoline sono spiegate a causa dell'uso di molte più chiamate indirette in iptables che in nftables. Ma anche, ci sono altre chiavi di performance che verranno spiegate di seguito.

Ottimizzazione delle regole #

La chiave di prestazione principale è l'ottimizzazione delle regole. Era già noto in iptables che l'uso di ipset aumenta le prestazioni in quanto riduce l'elaborazione sequenziale delle regole.

In nftlb, sebbene possa essere esteso per essere usato per altri scopi, impostiamo una regola base per servizio virtuale usando il linguaggio espressivo che supporta nativamente l'uso di insiemi e mappe. Si prega di vedere sotto le regole generate per a servizio tcp virtuale denominato vs01 con i backend 2:

tabella ip nftlb { mappa servizi-tcp { tipo ipv4_addr . inet_service: verdetto
        elementi = { 192.168.0.100 . http: vai a vs01}
    } catena preinstradamento { tipo nat hook preinstradamento priorità 0; la politica accetta;
        ip papà. tcp dport vmap @tcp-services
    } catena postrouting { tipo nat hook postrouting priorità 100; la politica accetta; }

    catena vs01 { da dnat a jhash ip saddr mod 2 mappa { 0: 192.168.1.10, 1: 192.168.1.11 } }
}

Una volta che abbiamo bisogno di aggiungere un nuovo back-end, rigenerare semplicemente la catena associata al servizio virtuale senza l'inclusione di nuove regole e senza influenzare il resto degli altri servizi virtuali.

    catena vs01 {
        dnat a jhash ip saddr mod 3 mappa {0: 192.168.1.10, 1: 192.168.1.11, 2: 192.168.1.12}
    }

Quindi, se un nuovo servizio virtuale vs02 deve essere creato, quindi il set di regole diventa come mostrato di seguito, senza l'aggiunta di nuove regole o che influisca su altri servizi virtuali:

tabella ip nftlb { mappa servizi-tcp { tipo ipv4_addr . inet_service: elementi del verdetto = { 192.168.0.100 . http: vai a vs01,
                     192.168.0.102 . https: vai a vs02 } } catena preinstradamento { tipo nat hook preinstradamento priorità 0; la politica accetta; ip papà. tcp dport vmap @tcp-services } catena postrouting { tipo nat hook postrouting priorità 100; la politica accetta; } catena vs01 { da dnat a jhash ip saddr mod 3 mappa { 0: 192.168.1.10, 1: 192.168.1.11, 2: 192.168.1.12 } }

    catena vs02 { da dnat a jhash ip saddr mod 2 mappa { 0: 192.168.2.10, 1: 192.168.2.11 } }
}

Primi ganci #

nftables consente l'uso di early gancio di ingresso che viene utilizzato in nftlb durante gli scenari DSR.

Inoltre, questo hook iniziale può essere utilizzato per scopi di filtraggio che aumentano le prestazioni in caso di caduta di pacchetti. Di seguito viene mostrato lo stadio più iniziale dei casi di iptables e nftables in pacchetti al secondo:

Drop raw prerouting iptables: 38.949.054,35 PPS/core Drop ingresso nftables: 45.743.628,64 PPS/core

Tecniche di accelerazione #

C'è ancora più spazio per l'ottimizzazione, infatti, poiché nftables supporta già percorsi veloci e tecniche leggere che possono essere utilizzate per il mangling dei pacchetti. Come esempi di ciò sono:

Flowtables. Conntrack percorso veloce per delegare connessioni già stabilite allo stadio di ingresso senza passare attraverso l'intero percorso lento. Maggiori informazioni qui.

NAT stateless. Per alcuni casi di bilanciamento del carico, NAT stateless può essere eseguito senza il tracciamento della connessione e dalla fase di ingresso per ottenere tutte le prestazioni applicate agli scenari NAT.

benchmark nftlb e chiavi di performance