Los puntos de referencia

Los últimos puntos de referencia, con fecha de junio de 2018, muestran una mejora importante del rendimiento al utilizar nftables como ruta de datos en lugar de iptables.

Dado un entorno de banco de pruebas de clientes 2 que ejecutan una herramienta de estrés de carga HTTP, un equilibrador de carga 1 y backends 3 con un terminador HTTP que proporciona una respuesta de aproximadamente 210 bytes, obtenemos los siguientes puntos de referencia en Flujos de 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

Las cifras anteriores se muestran en términos de CPU física, ya que los núcleos de adición de escalabilidad son casi lineales. Aunque estos puntos de referencia se han realizado solo con backends 3, El rendimiento de iptables se reducirá sustancialmente al agregar más backends, ya que implican más reglas secuenciales.

Esos puntos de referencia se realizaron con retpoline deshabilitado (sin mitigaciones de Spectre / Meltdown), pero una vez que están habilitados, las penalizaciones de rendimiento detectadas en los casos de NAT con conntrack habilitado para los casos de iptables y nftables son mucho peores para el primero:

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

Claves de rendimiento

Las penalizaciones de retpoline se explican debido al uso de muchas más llamadas indirectas en iptables que en nftables. Pero también, hay algunas claves de rendimiento más que se explicarán a continuación.

Optimización de reglas

La clave de rendimiento principal es la optimización de las reglas. Ya se sabía en iptables que el uso de ipset aumenta el rendimiento, ya que reduce el procesamiento de reglas secuenciales.

En nftlb, aunque podría extenderse para usarse con otros fines, establecemos reglas básicas por servicio virtual utilizando el lenguaje expresivo que admite de forma nativa el uso de conjuntos y mapas. Por favor vea abajo las reglas generadas para un servicio de TCP virtual llamado vs01 con 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 }
    }
}

Una vez que tengamos que agregar un nuevo backend, simplemente regenere la cadena asociada al servicio virtual sin la inclusión de nuevas reglas y sin afectar al resto de los otros servicios virtuales.

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

Entonces, si un nuevo servicio virtual vs02 debe crearse, entonces el conjunto de reglas se vuelve como se muestra a continuación, sin la adición de nuevas reglas o afectar otros servicios virtuales:

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

Primeros ganchos

nftables permite el uso de principios gancho de entrada que se utiliza en nftlb durante los escenarios DSR.

Además, este primer enlace se puede utilizar para fines de filtrado que aumenta el rendimiento en casos de caída de paquetes. Esto se muestra a continuación con la etapa más temprana de los casos de iptables y nftables en paquetes por segundo:

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

Técnicas de aceleración

Aún hay más espacio para la optimización, ya que nftables ya admite rutas rápidas y técnicas ligeras que se pueden usar para la manipulación de paquetes. Como ejemplos de eso son:

Flowtables. La ruta rápida de Conntrack para delegar conexiones ya establecidas a la etapa de ingreso sin pasar por toda la ruta lenta. Más información aquí.

NAT sin estado. Para algunos casos de equilibrio de carga, el NAT sin estado se puede realizar sin seguimiento de conexión y desde la etapa de ingreso para obtener todo el rendimiento aplicado a los escenarios de NAT.