Configuración de redes InfiniBand y RDMA

Red Hat Enterprise Linux 8

Guía de configuración de redes InfiniBand y RDMA en Red Hat Enterprise Linux 8

Resumen

Este documento describe qué son InfiniBand y el acceso directo a memoria remota (RDMA) y cómo configurar el hardware de InfiniBand. Además, esta documentación explica cómo configurar los servicios relacionados con InfiniBand.

Proporcionar comentarios sobre la documentación de Red Hat

Agradecemos su opinión sobre nuestra documentación. Por favor, díganos cómo podemos mejorarla. Para ello:

  • Para comentarios sencillos sobre pasajes concretos:

    1. Asegúrese de que está viendo la documentación en el formato Multi-page HTML. Además, asegúrese de ver el botón Feedback en la esquina superior derecha del documento.
    2. Utilice el cursor del ratón para resaltar la parte del texto que desea comentar.
    3. Haga clic en la ventana emergente Add Feedback que aparece debajo del texto resaltado.
    4. Siga las instrucciones mostradas.

  • Para enviar comentarios más complejos, cree un ticket de Bugzilla:

    1. Vaya al sitio web de Bugzilla.
    2. Como componente, utilice Documentation.
    3. Rellene el campo Description con su sugerencia de mejora. Incluya un enlace a la(s) parte(s) pertinente(s) de la documentación.
    4. Haga clic en Submit Bug.

Capítulo 1. Comprensión de InfiniBand y RDMA

InfiniBand se refiere a dos cosas distintas:

  • El protocolo de la capa de enlace física para las redes InfiniBand
  • La API InfiniBand Verbs, que es una implementación de la tecnología de acceso directo a memoria remota (RDMA)

RDMA permite acceder a la memoria de un ordenador a la de otro sin que intervenga el sistema operativo de ninguno de los dos. Esta tecnología permite crear redes de alto rendimiento y baja latencia con una baja utilización de la CPU.

En una transferencia de datos IP típica, cuando una aplicación en una máquina envía datos a una aplicación en otra máquina, lo siguiente sucede en el lado receptor:

  1. El núcleo debe recibir los datos.
  2. El núcleo debe determinar que los datos pertenecen a la aplicación.
  3. El núcleo despierta la aplicación.
  4. El kernel espera a que la aplicación realice una llamada al sistema en el kernel.
  5. La aplicación copia los datos del espacio de memoria interna del propio kernel en el buffer proporcionado por la aplicación.

Este proceso implica que la mayor parte del tráfico de red se copie a través de la memoria principal del sistema si el adaptador de host utiliza el acceso directo a la memoria (DMA), o de lo contrario, al menos dos veces. Además, el ordenador ejecuta una serie de cambios de contexto para cambiar entre el contexto del núcleo y el de la aplicación. Ambos cambios de contexto pueden causar una alta carga de la CPU a altas tasas de tráfico y ralentizar otras tareas.

La comunicación RDMA evita la intervención del kernel en el proceso de comunicación, a diferencia de la comunicación IP normal. Esto reduce la sobrecarga de la CPU. El protocolo RDMA permite al adaptador del host saber cuándo llega un paquete desde la red, qué aplicación debe recibirlo y en qué lugar del espacio de memoria de la aplicación debe almacenarse el paquete. En lugar de enviar el paquete al núcleo para que lo procese y luego lo copie en la memoria de la aplicación del usuario, con InfiniBand, el adaptador de host coloca el contenido del paquete directamente en el búfer de la aplicación. Este proceso requiere una API separada, la InfiniBand Verbs API, y las aplicaciones deben soportar esta API antes de poder utilizar RDMA.

Red Hat Enterprise Linux 8 soporta tanto el hardware InfiniBand como la API InfiniBand Verbs. Además, Red Hat Enterprise Linux admite las siguientes tecnologías que permiten utilizar la API Verbs InfiniBand en hardware que no sea InfiniBand:

  • Protocolo RDMA de área amplia de Internet (iWARP): Un protocolo de red que implementa RDMA sobre redes IP.
  • RDMA sobre Ethernet convergente (RoCE), también conocido como InfiniBand sobre Ethernet (IBoE): Un protocolo de red que implementa RDMA sobre redes Ethernet.

Recursos adicionales

Capítulo 2. Configuración de RoCE

En esta sección se explican los antecedentes de RDMA sobre Ethernet convergente (RoCE), así como la forma de cambiar la versión predeterminada de RoCE y de configurar un adaptador RoCE por software.

Tenga en cuenta que hay diferentes proveedores, como Mellanox, Broadcom y QLogic, que proporcionan hardware RoCE.

2.1. Resumen de las versiones del protocolo RoCE

RoCE es un protocolo de red que permite el acceso remoto directo a la memoria (RDMA) a través de Ethernet.

A continuación se detallan las diferentes versiones de RoCE:

RoCE v1

El protocolo RoCE versión 1 es un protocolo de capa de enlace Ethernet con ethertype 0x8915 que permite la comunicación entre dos hosts cualesquiera en el mismo dominio de difusión Ethernet.

Por defecto, cuando se utiliza un adaptador de red Mellanox ConnectX-3, Red Hat Enterprise Linux utiliza RoCE v1 para el RDMA Connection Manager (RDMA_CM).

RoCE v2

El protocolo RoCE versión 2 existe sobre el protocolo UDP sobre IPv4 o el UDP sobre IPv6. El puerto de destino UDP número 4791 está reservado para RoCE v2.

Por defecto, cuando se utiliza un adaptador de red Mellanox ConnectX-3 Pro, ConnectX-4 Lx o ConnectX-5, Red Hat Enterprise Linux utiliza RoCE v2 para el RDMA_CM, pero el hardware soporta tanto RoCE v1 como RoCE v2.

El RDMA_CM establece una conexión fiable entre un cliente y un servidor para la transferencia de datos. RDMA_CM proporciona una interfaz de transporte neutral RDMA para establecer conexiones. La comunicación utiliza un dispositivo RDMA específico y las transferencias de datos se basan en mensajes.

Importante

No es posible utilizar RoCE v2 en el cliente y RoCE v1 en el servidor. En este caso, configure tanto el servidor como el cliente para comunicarse a través de RoCE v1.

Recursos adicionales

2.2. Cambiar temporalmente la versión RoCE por defecto

No se admite el uso del protocolo RoCE v2 en el cliente y RoCE v1 en el servidor. Si el hardware de su servidor sólo admite RoCE v1, configure sus clientes para que se comuniquen con el servidor utilizando RoCE v1. Esta sección describe cómo aplicar RoCE v1 en el cliente que utiliza el controlador mlx5_0 para el dispositivo Mellanox ConnectX-5 Infiniband. Tenga en cuenta que los cambios descritos en esta sección son sólo temporales hasta que reinicie el host.

Requisitos previos

  • El cliente utiliza un dispositivo InfiniBand que utiliza, por defecto, el protocolo RoCE v2.
  • El dispositivo InfiniBand del servidor sólo es compatible con RoCE v1.

Procedimiento

  1. Crear el /sys/kernel/config/rdma_cm/mlx5_0/ directorio: 

    # mkdir /sys/kernel/config/rdma_cm/mlx5_0/

  2. Muestra el modo RoCE por defecto. Por ejemplo, para mostrar el modo del puerto 1: 

    # cat /sys/kernel/config/rdma_cm/mlx5_0/ports/1/default_roce_mode

    RoCE v2

  3. Cambia el modo RoCE por defecto a la versión 1: 

    # echo \ "IB/RoCE v1" > /sys/kernel/config/rdma_cm/mlx5_0/ports/1/default_roce_mode

2.3. Configuración de Soft-RoCE

Soft-RoCE es una implementación de software de acceso directo a memoria remota (RDMA) sobre Ethernet, que también se denomina RXE. Esta sección describe cómo configurar Soft-RoCE.

Utilizar Soft-RoCE en hosts sin adaptadores de canal de host RoCE (HCA).

Requisitos previos

  • Se ha instalado un adaptador Ethernet en el sistema.

Procedimiento

  1. Instale los paquetes libibverbs, libibverbs-utils, y infiniband-diags: 

    # yum install libibverbs libibverbs-utils infiniband-diags

  2. Carga el módulo del kernel rdma_rxe y muestra la configuración actual: 

    # rxe_cfg start
  Name    Link  Driver      Speed  NMTU  IPv4_addr        RDEV  RMTU
  enp7s0  yes   virtio_net         1500

  3. Añade un nuevo dispositivo RXE. Por ejemplo, para añadir el dispositivo Ethernet enp7s0 como dispositivo RXE, introduzca: 

    # rxe_cfg add enp7s0

  4. Muestra el estado del dispositivo RXE: 

    # rxe_cfg status
  Name    Link  Driver      Speed  NMTU  IPv4_addr        RDEV  RMTU
  enp7s0  yes   virtio_net         1500                   rxe0  1024  (3)

    En la columna RDEV, se ve que el enp7s0 está asignado al dispositivo rxe0.

  5. Opcional: lista los dispositivos RDMA disponibles en el sistema: 

    # ibv_devices
    device          	   node GUID
    ------          	----------------
    rxe0            	505400fffed5e0fb

    Alternativamente, utilice la utilidad ibstat para mostrar un estado detallado: 

    # ibstat rxe0
CA 'rxe0'
	CA type:
	Number of ports: 1
	Firmware version:
	Hardware version:
	Node GUID: 0x505400fffed5e0fb
	System image GUID: 0x0000000000000000
	Port 1:
		State: Active
		Physical state: LinkUp
		Rate: 100
		Base lid: 0
		LMC: 0
		SM lid: 0
		Capability mask: 0x00890000
		Port GUID: 0x505400fffed5e0fb
		Link layer: Ethernet

Capítulo 3. Configuración del subsistema central RDMA

Esta sección describe cómo configurar el servicio rdma y aumentar la cantidad de memoria que los usuarios pueden fijar en el sistema.

3.1. Configuración del servicio rdma

El servicio rdma gestiona la pila RDMA en el kernel. Si Red Hat Enterprise Linux detecta dispositivos InfiniBand, iWARP o RoCE, el gestor de dispositivos udev indica a systemd que inicie el servicio rdma.

Procedimiento

  1. Edite el archivo /etc/rdma/rdma.conf y establezca las variables de los módulos que desea habilitar en yes. Lo siguiente es el valor por defecto /etc/rdma/rdma.conf en Red Hat Enterprise Linux 8: 

    # Load IPoIB
IPOIB_LOAD=yes
# Load SRP (SCSI Remote Protocol initiator support) module
SRP_LOAD=yes
# Load SRPT (SCSI Remote Protocol target support) module
SRPT_LOAD=yes
# Load iSER (iSCSI over RDMA initiator support) module
ISER_LOAD=yes
# Load iSERT (iSCSI over RDMA target support) module
ISERT_LOAD=yes
# Load RDS (Reliable Datagram Service) network protocol
RDS_LOAD=no
# Load NFSoRDMA client transport module
XPRTRDMA_LOAD=yes
# Load NFSoRDMA server transport module
SVCRDMA_LOAD=no
# Load Tech Preview device driver modules
TECH_PREVIEW_LOAD=no

  2. Reinicie el servicio rdma: 

    # systemctl restart rdma

3.2. Renombrar dispositivos IPoIB

Por defecto, el kernel nombra los dispositivos IP sobre InfiniBand (IPoIB), por ejemplo, ib0, ib1, y así sucesivamente. Para evitar conflictos, Red Hat recomienda crear una regla en el gestor de dispositivos udev para crear nombres persistentes y significativos, como mlx4_ib0.

Requisitos previos

  • Se instala un dispositivo InfiniBand en el host.

Procedimiento

  1. Muestra la dirección de hardware del dispositivo. Por ejemplo, para mostrar la dirección del dispositivo llamado ib0, introduzca: 

    # ip link show ib0
8: ib0: >BROADCAST,MULTICAST,UP,LOWER_UP< mtu 65520 qdisc pfifo_fast state UP mode DEFAULT qlen 256
    link/infiniband 80:00:02:00:fe:80:00:00:00:00:00:00:00:02:c9:03:00:31:78:f2 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff

    Los últimos ocho bytes de la dirección, marcados en negrita en el ejemplo, son necesarios para crear una regla udev en el siguiente paso.

  2. Edite el archivo /etc/udev/rules.d/70-persistent-ipoib.rules y añada una regla ACTION. Por ejemplo, para configurar una regla que cambie el nombre del dispositivo con la dirección de hardware 00:02:c9:03:00:31:78:f2 a mlx4_ib0, añada la siguiente línea: 

    ACTION=="add", SUBSYSTEM=="net", DRIVERS=="?*", ATTR{type}=="32", ATTR{address}=="?*00:02:c9:03:00:31:78:f2", NAME="mlx4_ib0"

  3. Reinicia el host: 

    # rebote

Recursos adicionales

3.3. Aumentar la cantidad de memoria que los usuarios pueden fijar en el sistema

Las operaciones RDMA requieren la fijación de la memoria física. Esto significa que el kernel no puede escribir memoria en el espacio de intercambio. Si un usuario fija demasiada memoria, el sistema puede quedarse sin memoria, y el núcleo termina los procesos para liberar más memoria. Por esta razón, la asignación de memoria es una operación privilegiada.

Si los usuarios que no son root ejecutan grandes aplicaciones RDMA, puede ser necesario aumentar la cantidad de memoria que estos usuarios pueden fijar en el sistema. Esta sección describe cómo configurar una cantidad ilimitada de memoria para el grupo rdma.

Procedimiento

  • Como usuario de root, cree el archivo /etc/security/limits.d/rdma.conf con el siguiente contenido: 

    @rdma    soft    memlock     unlimited
@rdma    hard    memlock     unlimited

Pasos de verificación

  1. Inicie sesión como miembro del grupo rdma después de haber editado el archivo /etc/security/limits.d/rdma.conf.

    Tenga en cuenta que Red Hat Enterprise Linux aplica la configuración actualizada de ulimit cuando el usuario se conecta.

  2. Utilice el comando ulimit -l para mostrar el límite: 

    $ ulimit -l
unlimited

    Si el comando devuelve unlimited, el usuario puede fijar una cantidad ilimitada de memoria.

Recursos adicionales

  • Para más detalles sobre la limitación de los recursos del sistema, consulte la página man limits.conf(5).

Capítulo 4. Configuración de un gestor de subred InfiniBand

Todas las redes InfiniBand deben tener un gestor de subred en funcionamiento para que la red funcione. Esto es cierto incluso si dos máquinas están conectadas directamente sin ningún conmutador.

Es posible tener más de un gestor de subred. En ese caso uno actúa como maestro y otro gestor de subred actúa como esclavo que tomará el relevo en caso de que el gestor de subred maestro falle.

La mayoría de los conmutadores InfiniBand contienen un gestor de subredes integrado. Sin embargo, si necesita un gestor de subredes más actualizado o si requiere más control, utilice el gestor de subredes OpenSM proporcionado por Red Hat Enterprise Linux.

4.1. Instalación del gestor de subredes OpenSM

Esta sección describe cómo instalar el gestor de subredes OpenSM.

Procedimiento

  1. Instale el paquete opensm: 

    # yum install opensm

  2. Configure OpenSM si la instalación por defecto no se ajusta a su entorno.

    Si sólo se instala un puerto InfiniBand, el host debería actuar como gestor de subred maestro, y no se necesitan cambios personalizados. La configuración por defecto funciona sin ninguna modificación.

  3. Habilite e inicie el servicio opensm: 

    # systemctl enable --now opensm

Recursos adicionales

  • Para obtener una lista de opciones de línea de comandos para el servicio opensm, así como descripciones adicionales de las configuraciones de las particiones, la calidad del servicio (QoS) y otros temas avanzados, consulte la página man opensm(8).

4.2. Configuración de OpenSM mediante el método simple

Esta sección describe cómo configurar OpenSM si no necesita ninguna configuración personalizada.

Requisitos previos

  • Uno o más puertos InfiniBand están instalados en el servidor.

Procedimiento

  1. Obtenga los GUIDs de los puertos utilizando la utilidad ibstat: 

    # ibstat -d device_name
CA 'mlx4_0'
   CA type: MT4099
   Number of ports: 2
   Firmware version: 2.42.5000
   Hardware version: 1
   Node GUID: 0xf4521403007be130
   System image GUID: 0xf4521403007be133
   Port 1:
      State: Active
      Physical state: LinkUp
      Rate: 56
      Base lid: 3
      LMC: 0
      SM lid: 1
      Capability mask: 0x02594868
      Port GUID: 0xf4521403007be131
      Link layer: InfiniBand
   Port 2:
      State: Down
      Physical state: Disabled
      Rate: 10
      Base lid: 0
      LMC: 0
      SM lid: 0
      Capability mask: 0x04010000
      Port GUID: 0xf65214fffe7be132
      Link layer: Ethernet
    Nota

    Algunos adaptadores InfiniBand utilizan el mismo GUID para el nodo, el sistema y el puerto.

  2. Edite el archivo /etc/sysconfig/opensm y establezca los GUID en el parámetro GUIDS: 

    GUIDS="GUID_1 GUID_2 "

  3. Opcionalmente, establezca el parámetro PRIORITY si hay varios gestores de subred disponibles en su subred. Por ejemplo: 

    PRIORIDAD=15

Recursos adicionales

  • Para obtener información adicional sobre los parámetros que puede establecer en /etc/sysconfig/opensm, consulte la documentación de ese archivo.

4.3. Configurar OpenSM editando el archivo opensm.conf

Esta sección describe cómo configurar OpenSM editando el archivo /etc/rdma/opensm.conf. Utilice este método para personalizar la configuración de OpenSM si solo hay un puerto InfiniBand disponible.

Requisitos previos

  • Sólo hay un puerto InfiniBand instalado en el servidor.

Procedimiento

  1. Edite el archivo /etc/rdma/opensm.conf y personalice la configuración para que se ajuste a su entorno.

  2. Reinicie el servicio opensm: 

    # systemctl restart opensm

Recursos adicionales

  • Cuando se instala un paquete opensm actualizado, la utilidad yum almacena el nuevo archivo de configuración de OpenSM como /etc/rdma/opensm.conf.rpmnew. Compare este archivo con su archivo personalizado /etc/rdma/opensm.conf e incorpore manualmente los cambios.

4.4. Configuración de múltiples instancias de OpenSM

Esta sección describe cómo configurar varias instancias de OpenSM.

Requisitos previos

  • Uno o más puertos InfiniBand están instalados en el servidor.

Procedimiento

  1. Opcionalmente, copie el archivo /etc/rdma/opensm.conf en el archivo /etc/rdma/opensm.conf.orig: 

    # cp /etc/rdma/opensm.conf /etc/rdma/opensm.conf.orig

    Cuando se instala un paquete opensm actualizado, la utilidad yum anula el /etc/rdma/opensm.conf. Con la copia creada en este paso, puede comparar el archivo anterior y el nuevo para identificar los cambios e incorporarlos manualmente en los archivos opensm.conf específicos de la instancia.

  2. Cree una copia del archivo /etc/rdma/opensm.conf: 

    # cp /etc/rdma/opensm.conf /etc/rdma/opensm.conf.1

    Para cada instancia que cree, añada un número único y continuo a la copia del archivo de configuración.

  3. Edite la copia que creó en el paso anterior y personalice la configuración de la instancia para que se ajuste a su entorno. Por ejemplo, establezca los parámetros guid, subnet_prefix, y logdir.
  4. Opcionalmente, cree un archivo partitions.conf con un nombre único específicamente para esta subred y haga referencia a ese archivo en el parámetro partition_config_file en la copia correspondiente del archivo opensm.conf.
  5. Repita los pasos anteriores para cada instancia que desee crear.

  6. Inicie el servicio opensm: 

    # systemctl start opensm

    El servicio opensm inicia automáticamente una instancia única para cada archivo opensm.conf.* en el directorio /etc/rdma/. Si existen varios archivos opensm.conf.*, el servicio ignora la configuración del archivo /etc/sysconfig/opensm así como la del archivo base /etc/rdma/opensm.conf.

Recursos adicionales

  • Cuando se instala un paquete opensm actualizado, la utilidad yum almacena el nuevo archivo de configuración de OpenSM como /etc/rdma/opensm.conf.rpmnew. Compare este archivo con sus archivos personalizados de /etc/rdma/opensm.conf.\* e incorpore manualmente los cambios.

4.5. Creación de una configuración de partición

Esta sección describe cómo crear configuraciones de partición InfiniBand para OpenSM. Las particiones permiten a los administradores crear subredes en InfiniBand similares a las VLAN de Ethernet.

Importante

Si define una partición con una velocidad específica, como 40 Gbps, todos los hosts dentro de esta partición deben soportar al menos esta velocidad. Si un host no cumple con los requisitos de velocidad, no podrá unirse a la partición. Por lo tanto, establezca la velocidad de una partición a la velocidad más baja soportada por cualquier host con permiso para unirse a la partición.

Requisitos previos

  • Uno o más puertos InfiniBand están instalados en el servidor.

Procedimiento

  1. Edite el archivo /etc/rdma/partitions.conf y configure las particiones.

    Nota

    Todos los tejidos deben contener la partición 0x7fff, y todos los switches y todos los hosts deben pertenecer a ese tejido.

    Por ejemplo, añada el siguiente contenido al archivo para crear la partición por defecto 0x7fff a una velocidad reducida de 10 Gbps, y una partición 0x0002 con una velocidad de 40 Gbps: 

    # For reference:
# IPv4 IANA reserved multicast addresses:
#   http://www.iana.org/assignments/multicast-addresses/multicast-addresses.txt
# IPv6 IANA reserved multicast addresses:
#   http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml
#
# mtu =
#   1 = 256
#   2 = 512
#   3 = 1024
#   4 = 2048
#   5 = 4096
#
# rate =
#   2  =   2.5 GBit/s
#   3  =  10   GBit/s
#   4  =  30   GBit/s
#   5  =   5   GBit/s
#   6  =  20   GBit/s
#   7  =  40   GBit/s
#   8  =  60   GBit/s
#   9  =  80   GBit/s
#   10 = 120   GBit/s

Default=0x7fff, rate=3, mtu=4, scope=2, defmember=full:
    ALL, ALL_SWITCHES=full;
Default=0x7fff, ipoib, rate=3, mtu=4, scope=2:
    mgid=ff12:401b::ffff:ffff   # IPv4 Broadcast address
    mgid=ff12:401b::1           # IPv4 All Hosts group
    mgid=ff12:401b::2           # IPv4 All Routers group
    mgid=ff12:401b::16          # IPv4 IGMP group
    mgid=ff12:401b::fb          # IPv4 mDNS group
    mgid=ff12:401b::fc          # IPv4 Multicast Link Local Name Resolution group
    mgid=ff12:401b::101         # IPv4 NTP group
    mgid=ff12:401b::202         # IPv4 Sun RPC
    mgid=ff12:601b::1           # IPv6 All Hosts group
    mgid=ff12:601b::2           # IPv6 All Routers group
    mgid=ff12:601b::16          # IPv6 MLDv2-capable Routers group
    mgid=ff12:601b::fb          # IPv6 mDNS group
    mgid=ff12:601b::101         # IPv6 NTP group
    mgid=ff12:601b::202         # IPv6 Sun RPC group
    mgid=ff12:601b::1:3         # IPv6 Multicast Link Local Name Resolution group
    ALL=full, ALL_SWITCHES=full;

ib0_2=0x0002, rate=7, mtu=4, scope=2, defmember=full:
        ALL, ALL_SWITCHES=full;
ib0_2=0x0002, ipoib, rate=7, mtu=4, scope=2:
    mgid=ff12:401b::ffff:ffff   # IPv4 Broadcast address
    mgid=ff12:401b::1           # IPv4 All Hosts group
    mgid=ff12:401b::2           # IPv4 All Routers group
    mgid=ff12:401b::16          # IPv4 IGMP group
    mgid=ff12:401b::fb          # IPv4 mDNS group
    mgid=ff12:401b::fc          # IPv4 Multicast Link Local Name Resolution group
    mgid=ff12:401b::101         # IPv4 NTP group
    mgid=ff12:401b::202         # IPv4 Sun RPC
    mgid=ff12:601b::1           # IPv6 All Hosts group
    mgid=ff12:601b::2           # IPv6 All Routers group
    mgid=ff12:601b::16          # IPv6 MLDv2-capable Routers group
    mgid=ff12:601b::fb          # IPv6 mDNS group
    mgid=ff12:601b::101         # IPv6 NTP group
    mgid=ff12:601b::202         # IPv6 Sun RPC group
    mgid=ff12:601b::1:3         # IPv6 Multicast Link Local Name Resolution group
    ALL=full, ALL_SWITCHES=full;

Capítulo 5. Configuración de IPoIB

Por defecto, InfiniBand no utiliza el protocolo de Internet (IP) para la comunicación. Sin embargo, IP sobre InfiniBand (IPoIB) proporciona una capa de emulación de red IP sobre las redes InfiniBand de acceso directo a memoria remota (RDMA). Esto permite que las aplicaciones existentes no modificadas transmitan datos a través de las redes InfiniBand, pero el rendimiento es menor que si la aplicación utilizara RDMA de forma nativa.

Nota

Las redes Internet Wide Area RDMA Protocol (iWARP) y RoCE ya están basadas en IP. Por lo tanto, no se puede crear un dispositivo IPoIB sobre dispositivos IWARP o RoCE.

5.1. Los modos de comunicación IPoIB

Se puede configurar un dispositivo IPoIB en modo Datagram o Connected. La diferencia estriba en qué tipo de par de colas intenta abrir la capa IPoIB con la máquina del otro extremo de la comunicación:

  • En el modo Datagram, el sistema abre un par de colas desconectado y no fiable.

    Este modo no admite paquetes más grandes que la unidad de transmisión máxima (MTU) de la capa de enlace InfiniBand. La capa IPoIB añade una cabecera IPoIB de 4 bytes sobre el paquete IP que se transmite. Como resultado, la MTU de IPoIB debe ser 4 bytes menos que la MTU de la capa de enlace de InfiniBand. Como 2048 es una MTU común de la capa de enlace InfiniBand, la MTU común del dispositivo IPoIB en el modo Datagram es 2044.

  • En el modo Connected, el sistema abre un par de colas fiable y conectado.

    Este modo permite mensajes más grandes que la MTU de la capa de enlace de InfiniBand, y el adaptador del host se encarga de la segmentación y el reensamblaje de los paquetes. Como resultado, no se impone ningún límite al tamaño de los mensajes IPoIB que pueden enviar los adaptadores InfiniBand en el modo Connected. Sin embargo, los paquetes IP están limitados por el campo size y las cabeceras TCP/IP. Por este motivo, la MTU de IPoIB en el modo Connected es de 65520 bytes como máximo.

    El modo Connected tiene un mayor rendimiento, pero consume más memoria del núcleo.

Si un sistema está configurado para utilizar el modo Connected, sigue enviando tráfico de multidifusión en el modo Datagram, porque los conmutadores InfiniBand y el tejido no pueden pasar tráfico de multidifusión en el modo Connected. Además, el sistema vuelve al modo Datagram cuando se comunica con cualquier host que no esté configurado en el modo Connected.

Mientras se ejecuta una aplicación que envía datos de multidifusión hasta la MTU máxima en la interfaz, debe configurar la interfaz en modo Datagram o configurar la aplicación para limitar el tamaño de envío de paquetes a un tamaño que quepa en paquetes de tamaño datagrama.

5.2. Entender las direcciones de hardware IPoIB

Los dispositivos IPoIB tienen una dirección de hardware de 20 bytes que consta de las siguientes partes:

  • Los primeros 4 bytes son banderas y números de pares de colas.

  • Los siguientes 8 bytes son el prefijo de la subred.

    El prefijo de subred por defecto es 0xfe:80:00:00:00:00:00:00. Después de que el dispositivo se conecte al administrador de subredes, el dispositivo cambia este prefijo para que coincida con el configurado en el administrador de subredes.

  • Los últimos 8 bytes son el identificador único global (GUID) del puerto InfiniBand al que está conectado el dispositivo IPoIB.
Nota

Como los primeros 12 bytes pueden cambiar, no los utilices en las reglas del administrador de dispositivos de udev.

Recursos adicionales

5.3. Configuración de una conexión IPoIB mediante comandos nmcli

Este procedimiento describe cómo configurar una conexión IPoIB utilizando los comandos de nmcli.

Requisitos previos

  • Se instala un dispositivo InfiniBand en el servidor y se carga el módulo del núcleo correspondiente.

Procedimiento

  1. Cree la conexión InfiniBand. Por ejemplo, para crear una conexión que utilice la interfaz mlx4_ib0 en el modo de transporte Connected y la MTU máxima de 65520 bytes, introduzca: 

    # nmcli connection add type infiniband con-name mlx4_ib0 ifname mlx4_ib0 transport-mode Connected mtu 65520

  2. Opcional: establezca una interfaz P_Key. Por ejemplo, para establecer 0x8002 como interfaz P_Key de la conexión mlx4_ib0, introduzca: 

    # nmcli connection modify mlx4_ib0 infiniband.p-key 0x8002

  3. Configure los ajustes de IPv4. Por ejemplo, para establecer una dirección IPv4 estática, una máscara de red, una puerta de enlace predeterminada y un servidor DNS de la conexión mlx4_ib0, introduzca: 

    # nmcli connection modify mlx4_ib0 ipv4.addresses '192.0.2.1/24'
# nmcli connection modify mlx4_ib0 ipv4.gateway '192.0.2.254'
# nmcli connection modify mlx4_ib0 ipv4.dns '192.0.2.253'
# nmcli connection modify mlx4_ib0 ipv4.method manual

  4. Configure los ajustes de IPv6. Por ejemplo, para establecer una dirección IPv6 estática, una máscara de red, una puerta de enlace predeterminada y un servidor DNS de la conexión mlx4_ib0, introduzca: 

    # nmcli connection modify mlx4_ib0 ipv6.addresses '2001:db8:1::1/32'
# nmcli connection modify mlx4_ib0 ipv6.gateway '2001:db8:1::fffe'
# nmcli connection modify mlx4_ib0 ipv6.dns '2001:db8:1::fffd'
# nmcli connection modify mlx4_ib0 ipv6.method manual

  5. Active la conexión. Por ejemplo, para activar la conexión mlx4_ib0: 

    # nmcli connection up mlx4_ib0

5.4. Configuración de una conexión IPoIB mediante nm-connection-editor

Este procedimiento describe cómo configurar una conexión IPoIB utilizando la aplicación nm-connection-editor.

Requisitos previos

  • Se instala un dispositivo InfiniBand en el servidor y se carga el módulo del núcleo correspondiente.
  • El paquete nm-connection-editor está instalado.

Procedimiento

  1. Abre un terminal y entra: 

    $ nm-connection-editor
  2. Pulse el botón para añadir una nueva conexión.
  3. Seleccione el tipo de conexión InfiniBand y haga clic en Crear.

  4. En la pestaña InfiniBand:

    1. Opcionalmente, cambie el nombre de la conexión.
    2. Selecciona el modo de transporte.
    3. Selecciona el dispositivo.
    4. Opcional: establecer una MTU.
  5. En la pestaña IPv4 Settings, configure los ajustes de IPv4. Por ejemplo, configure una dirección IPv4 estática, una máscara de red, una puerta de enlace predeterminada y un servidor DNS infiniband IPv4 settings nm connection editor
  6. En la pestaña IPv6 Settings, configure los ajustes de IPv6. Por ejemplo, configure una dirección IPv6 estática, una máscara de red, una puerta de enlace predeterminada y un servidor DNS infiniband IPv6 settings nm connection editor
  7. Haga clic en Guardar para guardar la conexión del equipo.
  8. Cerrar nm-connection-editor.

  9. Opcional: establecer una interfaz P_Key. Tenga en cuenta que debe establecer este parámetro en la línea de comandos, ya que el ajuste no está disponible en nm-connection-editor.

    Por ejemplo, para establecer 0x8002 como interfaz P_Key de la conexión mlx4_ib0, introduzca: 

    # nmcli connection modify mlx4_ib0 infiniband.p-key 0x8002

Capítulo 6. Prueba de redes InfiniBand

Esta sección proporciona procedimientos sobre cómo probar las redes InfiniBand.

6.1. Prueba de las primeras operaciones RDMA de InfiniBand

Esta sección describe cómo probar las operaciones de acceso remoto directo a memoria (RDMA) de InfiniBand.

Nota

Esta sección sólo se aplica a los dispositivos InfiniBand. Si utiliza dispositivos iWARP o RoCE/IBoE, que están basados en IP, consulte:

Requisitos previos

  • RDMA está configurado.
  • Los paquetes libibverbs-utils y infiniband-diags están instalados.

Procedimiento

  1. Enumera los dispositivos InfiniBand disponibles: 

    # ibv_devices
    device                 node GUID
    ------              ----------------
    mlx4_0              0002c903003178f0
    mlx4_1              f4521403007bcba0

  2. Muestra la información de un dispositivo InfiniBand específico. Por ejemplo, para mostrar la información del dispositivo mlx4_1, introduzca: 

    # ibv_devinfo -d mlx4_1
hca_id: mlx4_1
     transport:                  InfiniBand (0)
     fw_ver:                     2.30.8000
     node_guid:                  f452:1403:007b:cba0
     sys_image_guid:             f452:1403:007b:cba3
     vendor_id:                  0x02c9
     vendor_part_id:             4099
     hw_ver:                     0x0
     board_id:                   MT_1090120019
     phys_port_cnt:              2
          port:   1
                state:              PORT_ACTIVE (4)
                max_mtu:            4096 (5)
                active_mtu:         2048 (4)
                sm_lid:             2
                port_lid:           2
                port_lmc:           0x01
                link_layer:         InfiniBand

          port:   2
                state:              PORT_ACTIVE (4)
                max_mtu:            4096 (5)
                active_mtu:         4096 (5)
                sm_lid:             0
                port_lid:           0
                port_lmc:           0x00
                link_layer:         Ethernet

  3. Muestra el estado básico de un dispositivo InfiniBand. Por ejemplo, para mostrar el estado del dispositivo mlx4_1, introduzca: 

    # ibstat mlx4_1
CA 'mlx4_1'
     CA type: MT4099
     Number of ports: 2
     Firmware version: 2.30.8000
     Hardware version: 0
     Node GUID: 0xf4521403007bcba0
     System image GUID: 0xf4521403007bcba3
     Port 1:
           State: Active
           Physical state: LinkUp
           Rate: 56
           Base lid: 2
           LMC: 1
           SM lid: 2
           Capability mask: 0x0251486a
           Port GUID: 0xf4521403007bcba1
           Link layer: InfiniBand
     Port 2:
           State: Active
           Physical state: LinkUp
           Rate: 40
           Base lid: 0
           LMC: 0
           SM lid: 0
           Capability mask: 0x04010000
           Port GUID: 0xf65214fffe7bcba2
           Link layer: Ethernet

  4. Utilice la utilidad ibping para hacer ping desde un cliente a un servidor utilizando InfiniBand:

    1. En el host que actúa como servidor, inicie ibping en modo servidor: 

      # ibping -S -C mlx4_1 -P 1

      Este comando utiliza los siguientes parámetros:

      • -S: Activa el modo servidor.
      • -C InfiniBand_CA_name: Establece el nombre de la CA a utilizar.
      • -P port_number: Establece el número de puerto a utilizar, si el InfiniBand proporciona múltiples puertos.

    2. En el host que actúa como cliente, utilice ibping de la siguiente manera: 

      # ibping -c 50 -C mlx4_0 -P 1 -L 2
      • -c number: Envía este número de paquetes al servidor.
      • -C InfiniBand_CA_name: Establece el nombre de la CA a utilizar.
      • -P port_number: Establece el número de puerto a utilizar, si el InfiniBand proporciona múltiples puertos.
      • -L port_LID: Establece el identificador local (LID) a utilizar.

Recursos adicionales

  • Para más detalles sobre los parámetros de ibping, consulte la página de manual ibping(8).

6.2. Probando un IPoIB usando la utilidad ping

Después de configurar IPoIB, utilice la utilidad ping para enviar paquetes ICMP para probar la conexión IPoIB.

Requisitos previos

  • Los dos hosts RDMA están conectados en el mismo tejido InfiniBand con puertos RDMA.
  • Las interfaces IPoIB en ambos hosts están configuradas con direcciones IP dentro de la misma subred.

Procedimiento

  1. Utilice la utilidad ping para enviar paquetes ICMP al adaptador InfiniBand del host remoto: 

    # ping -c5 192.0.2.1

    Este comando envía cinco paquetes ICMP a la dirección IP 192.0.2.1.

6.3. Probando una red RDMA usando qperf después de configurar IPoIB

Este procedimiento describe ejemplos de cómo mostrar la configuración del adaptador InfiniBand y medir el ancho de banda y la latencia entre dos hosts utilizando la utilidad qperf.

Requisitos previos

  • El paquete qperf está instalado en ambos hosts.
  • IPoIB está configurado en ambos hosts.

Procedimiento

  1. Inicie qperf en uno de los hosts sin ninguna opción para actuar como servidor: 

    # qperf

  2. Utilice los siguientes comandos en el cliente. Los comandos utilizan el puerto 1 del adaptador de canal de host mlx4_0 en el cliente para conectarse a la dirección IP 192.0.2.1 asignada al adaptador InfiniBand en el servidor.

    1. Para mostrar la configuración, introduzca: 

      qperf -v -i mlx4_0:1 192.0.2.1 conf
-------------------------
conf:
    loc_node   =  rdma-dev-01.lab.bos.redhat.com
    loc_cpu    =  12 Cores: Mixed CPUs
    loc_os     =  Linux 4.18.0-187.el8.x86_64
    loc_qperf  =  0.4.11
    rem_node   =  rdma-dev-00.lab.bos.redhat.com
    rem_cpu    =  12 Cores: Mixed CPUs
    rem_os     =  Linux 4.18.0-187.el8.x86_64
    rem_qperf  =  0.4.11
-------------------------

    2. Para mostrar el ancho de banda bidireccional de Reliable Connection (RC), introduzca: 

      # qperf -v -i mlx4_0:1 192.0.2.1 rc_bi_bw
-------------------------
rc_bi_bw:
    bw             =  10.7 GB/sec
    msg_rate       =   163 K/sec
    loc_id         =  mlx4_0
    rem_id         =  mlx4_0:1
    loc_cpus_used  =    65 % cpus
    rem_cpus_used  =    62 % cpus
-------------------------

    3. Para mostrar el ancho de banda unidireccional de la transmisión RC, introduzca: 

      # qperf -v -i mlx4_0:1 192.0.2.1 rc_bw
-------------------------
rc_bw:
    bw              =  6.19 GB/sec
    msg_rate        =  94.4 K/sec
    loc_id          =  mlx4_0
    rem_id          =  mlx4_0:1
    send_cost       =  63.5 ms/GB
    recv_cost       =    63 ms/GB
    send_cpus_used  =  39.5 % cpus
    recv_cpus_used  =    39 % cpus
-------------------------

Recursos adicionales

  • Para más detalles sobre qperf, consulte la página de manual qperf(1).