PowerScale: La conversión de InfiniBand a Ethernet puede dar lugar a una configuración incorrecta de agregación de enlaces

Summary: En este artículo, se describe cómo resolver un problema que se observa durante la conversión de InfiniBand a Ethernet de backend de un clúster para la versión de OneFS anterior a 9.1.0.0. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

Las versiones de OneFS anteriores a 9.1 y la conversión de un clúster de InfiniBand a back-end Ethernet pueden generar puertos agregados configurados incorrectamente. Reiniciar el nodo crearía el agregado incorrecto y provocaría una división del nodo.

Nota: Este problema se puede evitar mediante la eliminación de todas las interfaces agregadas de todos los pools antes de iniciar la conversión de back-end. Este artículo se debe utilizar en caso de que algo salga mal con la conversión.

Las interfaces de proveedor de Mellanox (mlxen) que están configuradas erróneamente para la agregación y que probablemente pueden provocar que el nodo no se vuelva a unir al clúster. La revisión de ifconfig desde un nodo muestra las interfaces ISIINTERNAL asignadas a lagg0.

Isilon-18# ifconfig 
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 
options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE> 
		ether 00:60:16:cc:bb:aa 
		inet 192.168.60.10 netmask 0xffffff80 broadcast 192.168.60.127 zone 1 
		nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> 
		media: Ethernet autoselect (1000baseT <full-duplex,master>) 
		status: active 
mlxen0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,ISIINTERNAL> metric 0 mtu 1500
options=ed07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> 
		ether 98:03:9b:cc:bb:aa 
		inet 128.221.252.18 netmask 0xffffff00 broadcast 128.221.252.255 zone 1 
		inet 128.221.254.18 netmask 0xffffff00 broadcast 128.221.254.255 zone 1 
		nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> 
		media: Ethernet autoselect (40Gbase-CR4 <full-duplex,rxpause,txpause>) 
		status: active 
mlxen1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,ISIINTERNAL> metric 0 mtu 1500
options=ed07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> 
		ether 98:03:9b:cc:bb:aa 
		inet 128.221.253.18 netmask 0xffffff00 broadcast 128.221.253.255 zone 1 
		inet 128.221.254.18 netmask 0xffffff00 broadcast 128.221.254.255 zone 1 
		nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> 
		media: Ethernet autoselect (40Gbase-CR4 <full-duplex,rxpause,txpause>) 
		status: active 
mlxen2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=ed07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> 
		ether 98:03:9b:cc:bb:fa 
		nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> 
		media: Ethernet autoselect (10Gbase-CX4 <full-duplex,rxpause,txpause>) 
		status: active 
mlxen3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=ed07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> 
		ether 98:03:9b:cc:bb:fb 
		nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> 
		media: Ethernet autoselect (10Gbase-CX4 <full-duplex,rxpause,txpause>) 
		status: active 
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=ed07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> 
		ether 98:03:9b:cc:bb:aa 
		nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> 
		media: Ethernet autoselect 
		status: active 
		groups: lagg laggproto lacp lagghash l2,l3,l4 
		laggport: mlxen0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> 
		laggport: mlxen1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> 
vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
		options=303<RXCSUM,TXCSUM,TSO4,TSO6> 
		ether 98:03:9b:cc:bb:aa 
		inet 10.10.20.11 netmask 0xffffff00 broadcast 10.10.20.255 zone 18 
		nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> 
		media: Ethernet autoselect 
		status: active 
		vlan: 100 
		vlanpcp: 0 parent 
		interface: lagg0 
		groups: vlan

 

Cause

La conversión de Infiniband a Ethernet cambia los nombres de interfaz de ib0 a mlxen0 (int-a) e ib1 a mlxen1 (int-b). El creador del retraso hace referencia a "mlxen0" y "mlxen1" como puertos de interfaz de red externa. Si se produce el problema (lo que significa que no se tomaron medidas preventivas), se necesitan pasos para corregir la asignación dentro de Flexnet (el demonio de administración de redes).

 

Resolution

Antes de la migración:

Este problema se corrigió para OneFS 9.1 y versiones posteriores. Si está en una versión afectada, realice lo siguiente antes de migrar de InfiniBand a Ethernet.

  1. Quite todas las interfaces agregadas de todos los pools de redes.
  2. Complete la migración.
  3. Vuelva a agregar todas las interfaces agregadas a todos los pools de red necesarios.

Después de la migración:

Si se produjo el problema y se dividió un nodo, realice uno de los siguientes pasos (automático o manual) para solucionar el problema.

Resolución automática (solución alternativa)

========================================================

  1. Cree un respaldo del archivo "lni":

    mv /etc/mcp/sys/lni.xml /etc/mcp/sys/lni.xml.bak

  2. Quite la interfaz de nodo afectada del pool de redes.

    isi network pools modify <groupnet.subnet.pool> --remove-ifaces=<interface example: 2:40gige-agg-1>

  3. Ejecute el siguiente comando para reconstruir el archivo de lni.xml del nodo:

    isi_create_lni_xml

  4. Reinicie el nodo.

  5. Verifique que la interfaz sea correcta.

  6. Continúe con el paso final de la configuración de la MTU 9000. Después de esto, vuelva a agregar la interfaz del nodo afectado al pool.

    isi network pools modify <groupnet.subnet.pool> --add-ifaces=<interface example: 2:40gige-agg-1>

Resolución manual (solución alternativa)

========================================================

Para resolver este problema, el laggports Se debe eliminar manualmente mediante las siguientes acciones.

  1. Utilice una conexión en serie en el nodo afectado.

  2. Deshabilite "mcp" en el nodo afectado.

    killall -9 isi_mcp

  3. Deshabilite "isi_flexnet_d" en el nodo afectado.

    killall -9 isi_flexnet_d

  4. Cree un respaldo de ambos archivos "flx_config.xml" en el directorio local.

    1. mv /etc/ifs/flexnet/flx_config.xml /etc/ifs/flexnet/flx_config.xml.bak
    2. mv /etc/ifs/flexnet/flx_config.xml~ /etc/ifs/flexnet/flx_config.xml~.bak

  5. Si hay alguna "VLAN" asociada con el puerto agregado, desactívela.

    ifconfig <vlan interface> down

    EJEMPLO

    ifconfig vlan0 down

  6. Quite los "laggports" de la interfaz de retraso.

    ifconfig <lag interface> -laggport <mlx iface>

    EJEMPLOS

    ifconfig lagg0 -laggport mlxen0
    ifconfig lagg0 -laggport mlxen1

  7. Reduzca la interfaz de retraso.

    ifconfig <lag iface> down

    EJEMPLO

    ifconfig lagg0 down

  8. Ahora que la interfaz de back-end está desasociada del puerto de retraso, pruebe el ping a cualquier otro nodo a través de "int-a" E "int-b".

    ping <back-end IP [int-a]>
    ping <back-end IP [int-b]>

  9. Verifique que el nodo ya no esté inactivo.

    isi status -q

  10. Para actualizar todos los procesos, reinicie el nodo.

 

Products

Isilon A200, Isilon A2000, Isilon F800, Isilon F810, Isilon H400, Isilon H500, Isilon H5600, Isilon H600
Article Properties
Article Number: 000168838
Article Type: Solution
Last Modified: 18 Mar 2025
Version:  9
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.