benchmark nftlb e chiavi di performance

PUBBLICATO DA Zevenet | 28 giugno, 2018

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

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:

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

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.

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

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:

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

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:

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

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.

Condividere su:

Documentazione sotto i termini della GNU Free Documentation License.

questo articolo è stato utile?

Articoli Correlati