Benchmarks

Os benchmarks mais recentes, datados de junho 2018, mostram uma melhoria importante do desempenho no uso de nftables como caminho de dados em vez de iptables.

Dado um ambiente de teste de clientes 2 executando uma ferramenta de carga de carga HTTP, balanceador de carga 1 e backends 3 com um terminador HTTP fornecendo uma resposta de cerca de 210 bytes, obtemos os seguintes benchmarks em Fluxos HTTP por segundo:

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

As figuras acima são mostradas em termos de CPU física, pois os núcleos de adição de escalabilidade são quase lineares. Embora esses benchmarks tenham sido realizados apenas com backends 3, O desempenho do iptables cairá substancialmente ao adicionar mais back-ends, como eles implicam regras mais seqüenciais.

Esses benchmarks foram realizados com retpoline desabilitado (sem mitigações Spectre / Meltdown), mas uma vez que eles são habilitados, as penalidades de desempenho detectadas em casos NAT com conntrack habilitado para casos iptables e nftables são muito piores para o primeiro:

iptables: 40.77% CPU penalty
nftables: 17.27% CPU penalty

Chaves de desempenho

As penalidades de retpolina são explicadas devido ao uso de muito mais chamadas indiretas em iptables do que em nftables. Mas também há mais algumas chaves de desempenho que serão explicadas abaixo.

Otimização de regras

A principal chave de desempenho é a otimização de regras. Já era conhecido no iptables que o uso de ipset aumenta o desempenho, pois reduz o processamento de regras sequenciais.

Em nftlb, embora possa ser estendido para ser usado para outros propósitos, definimos regras básicas por serviço virtual usando a linguagem expressiva que suporta nativamente o uso de conjuntos e mapas. Por favor, veja abaixo as regras geradas para um serviço tcp virtual chamado vs01 com 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 }
    }
}

Depois que precisarmos adicionar um novo back-end, basta regenerar a cadeia associada para o serviço virtual sem a inclusão de novas regras e sem afetar o restante dos outros serviços virtuais.

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

Então, se um novo serviço virtual vs02 precisa ser criado, então o conjunto de regras se torna como mostrado abaixo, sem a adição de novas regras ou afetar outros serviços virtuais:

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

Ganchos

nftables permite o uso precoce de gancho de ingresso que é usado em nftlb durante cenários de DSR.

Além disso, esse gancho inicial pode ser usado para fins de filtragem que aumenta o desempenho em casos de descarte de pacotes. Isso é mostrado abaixo com o estágio mais inicial dos casos de iptables e nftables em pacotes por segundo:

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

Técnicas de aceleração

Ainda há mais espaço para otimização, já que os nftables já oferecem suporte a caminhos rápidos e técnicas leves que podem ser usadas para a manipulação de pacotes. Como exemplos disso são:

Flowtables. O caminho rápido do Conntrack para delegar conexões já estabelecidas ao estágio de ingresso sem passar por todo o caminho lento. Mais informações aqui.

NAT sem estado. Para alguns casos de balanceamento de carga, o NAT sem estado pode ser executado sem rastreamento de conexão e do estágio de ingresso para obter todo o desempenho aplicado aos cenários NAT.