Conteúdo
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.