FreeBSD agregación de enlaces no más rápido que un enlace

Ponemos una NIC Intel I340-T4 de 4 puertos en un servidor FreeBSD 9.3 ¹ y lo configuramos para la agregación de enlaces en modo LACP en un intento de disminuir el tiempo que se necesita para duplicar 8 a 16 TiB de datos de un servidor de archivos maestro a 2- 4 clones en paralelo. Esperábamos obtener un ancho de banda agregado de hasta 4 Gbit / s, pero no importa lo que hayamos intentado, nunca sale más rápido que el agregado de 1 Gbit / s. ²

Estamos usando iperf3para probar esto en una LAN inactiva. ³ La primera instancia casi alcanza un gigabit, como se esperaba, pero cuando comenzamos una segunda en paralelo, los dos clientes bajan de velocidad a aproximadamente ½ Gbit / seg. Agregar un tercer cliente reduce las velocidades de los tres clientes a ~ ⅓ Gbit / seg, y así sucesivamente.

Hemos tenido cuidado al configurar las iperf3pruebas de que el tráfico de los cuatro clientes de prueba ingresa al conmutador central en diferentes puertos:

Hemos verificado que cada máquina de prueba tiene una ruta independiente de regreso al conmutador de bastidor y que el servidor de archivos, su NIC y el conmutador tienen el ancho de banda para lograrlo separando el lagg0grupo y asignando una dirección IP separada a cada uno de las cuatro interfaces en esta tarjeta de red Intel. En esa configuración, logramos un ancho de banda agregado de ~ 4 Gbit / seg.

Cuando comenzamos por este camino, estábamos haciendo esto con un viejo conmutador administrado SMC8024L2 . (Hoja de datos en PDF, 1.3 MB.) No era el conmutador más avanzado de su época, pero se supone que puede hacerlo. Pensamos que el interruptor podría tener la culpa, debido a su antigüedad, pero la actualización a una HP 2530-24G mucho más capaz no cambió el síntoma.

El conmutador HP 2530-24G afirma que los cuatro puertos en cuestión están configurados como una troncal LACP dinámica:

# show trunks
Load Balancing Method:  L3-based (default)

  Port | Name                             Type      | Group Type    
  ---- + -------------------------------- --------- + ----- --------
  1    | Bart trunk 1                     100/1000T | Dyn1  LACP    
  3    | Bart trunk 2                     100/1000T | Dyn1  LACP    
  5    | Bart trunk 3                     100/1000T | Dyn1  LACP    
  7    | Bart trunk 4                     100/1000T | Dyn1  LACP    

Hemos probado LACP pasivo y activo.

Hemos verificado que los cuatro puertos NIC reciben tráfico en el lado de FreeBSD con:

$ sudo tshark -n -i igb$n

Curiosamente, tsharkmuestra que en el caso de un solo cliente, el conmutador divide la transmisión de 1 Gbit / seg en dos puertos, aparentemente haciendo ping-pong entre ellos. (Tanto los conmutadores SMC como HP mostraron este comportamiento).

Dado que el ancho de banda agregado de los clientes solo se une en un solo lugar, en el conmutador en el bastidor del servidor, solo ese conmutador está configurado para LACP.

No importa en qué cliente comenzamos primero, ni en qué orden los iniciamos.

ifconfig lagg0 en el lado de FreeBSD dice:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
    ether 90:e2:ba:7b:0b:38
    inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
    inet6 fe80::92e2:baff:fe7b:b38%lagg0 prefixlen 64 scopeid 0xa 
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    laggproto lacp lagghash l2,l3,l4
    laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

Hemos aplicado tantos consejos en la guía de ajuste de red de FreeBSD como tiene sentido para nuestra situación. (Gran parte de esto es irrelevante, como las cosas sobre el aumento de los FD máximos).

Intentamos desactivar la descarga de segmentación TCP , sin cambios en los resultados.

No tenemos una segunda NIC de servidor de 4 puertos para configurar una segunda prueba. Debido a la prueba exitosa con 4 interfaces separadas, asumimos que ninguno de los hardware está dañado. ³

Vemos estos caminos hacia adelante, ninguno de ellos atractivo:

1. Compre un conmutador más grande y defectuoso, con la esperanza de que la implementación de LACP de SMC sea una mierda, y que el nuevo conmutador sea mejor. (Actualizar a una HP 2530-24G no ayudó).

2. Mire la laggconfiguración de FreeBSD un poco más, con la esperanza de que nos hayamos perdido algo. ^{4 4}

3. Olvídese de la agregación de enlaces y use DNS round-robin para efectuar el equilibrio de carga.

4. Reemplace la NIC del servidor y cambie nuevamente, esta vez con 10 cosas GigE , a aproximadamente 4 veces el costo de hardware de este experimento LACP.

Notas al pie

1. ¿Por qué no pasar a FreeBSD 10, preguntas? Debido a que FreeBSD 10.0-RELEASE todavía usa la versión 28 del grupo de ZFS, y este servidor se ha actualizado al grupo de ZFS 5000, una nueva característica en FreeBSD 9.3. La línea 10. x no obtendrá eso hasta que FreeBSD 10.1 se envíe aproximadamente dentro de un mes . Y no, no es una opción reconstruir desde la fuente para llegar al borde de sangría 10.0-ESTABLE, ya que este es un servidor de producción.

2. Por favor, no saltes a conclusiones. Los resultados de nuestra prueba más adelante en la pregunta le dicen por qué esto no es un duplicado de esta pregunta .

3. iperf3Es una prueba de red pura. Si bien el objetivo final es tratar de llenar esa tubería agregada de 4 Gbit / seg desde el disco, todavía no estamos involucrando el subsistema de disco.

4. Con errores o mal diseñado, tal vez, pero no más roto que cuando salió de la fábrica.

5. Ya me he vuelto bizco por hacer eso.

¿Cuál es el algoritmo de equilibrio de carga en uso tanto en el sistema como en el conmutador?

Toda mi experiencia con esto está en Linux y Cisco, no en FreeBSD y SMC, pero la misma teoría todavía se aplica.

El modo de equilibrio de carga predeterminado en el modo LACP del controlador de vinculación de Linux y en los conmutadores Cisco más antiguos, como el 2950, ​​es el equilibrio basado solo en la dirección MAC.

Esto significa que si todo su tráfico va de un sistema (servidor de archivos) a otro MAC (ya sea una puerta de enlace predeterminada o una interfaz virtual conmutada en el conmutador), el MAC de origen y destino será el mismo, por lo que solo un esclavo alguna vez ser usado.

Desde su diagrama, no parece que esté enviando tráfico a una puerta de enlace predeterminada, pero no estoy seguro de si los servidores de prueba están en 10.0.0.0/24, o si los sistemas de prueba están en otras subredes y se enrutan a través de una interfaz de capa 3 en el conmutador.

Si está enrutando en el interruptor, ahí está su respuesta.

La solución a esto es usar un algoritmo de equilibrio de carga diferente.

Una vez más, no tengo experiencia con BSD o SMC, pero Linux y Cisco pueden equilibrar en función de la información L3 (dirección IP) o la información L4 (número de puerto).

Como cada uno de sus sistemas de prueba debe tener una IP diferente, intente el equilibrio basado en la información L3. Si eso todavía no funciona, cambie algunas direcciones IP y vea si cambia el patrón de equilibrio de carga.