Requisitos de red de host para Azure Stack HCI

Se aplica a: Azure Stack HCI versiones 21H2 y 20H2

En este tema se describen las consideraciones y los requisitos de redes de host para Azure Stack HCI. Para información sobre las arquitecturas de los centros de datos y las conexiones físicas entre servidores, consulte Requisitos de red física.

Para obtener información sobre cómo simplificar las redes de host mediante Network ATC, consulte Simplificación de las redes de host con Network ATC.

Tipos de tráfico de red

El tráfico de red de Azure Stack HCI se puede clasificar por su finalidad prevista:

  • Tráfico de proceso: tráfico que se origina en una máquina virtual o se destina a esta.
  • Tráfico de almacenamiento: Tráfico mediante Bloque de mensajes del servidor (SMB); por ejemplo, Espacios de almacenamiento directo o migración en vivo basada en SMB.
  • Tráfico de administración: Tráfico usado por el administrador para la administración del clúster, incluidos Escritorio remoto, Windows Admin Center, Active Directory, etc.

Selección de un adaptador de red

Azure Stack HCI necesita que se elija un adaptador de red que haya logrado la certificación de centro de datos definido por software (SDDC) de Windows Server con la calificación adicional (AQ) Estándar o Premium. Estos adaptadores admiten las características más avanzadas de la plataforma y han experimentado la mayor parte de las pruebas de nuestros asociados de hardware. Normalmente, este nivel de escrutinio conduce a una reducción en los problemas de calidad relacionados con el hardware y los controladores. Estos adaptadores también cumplen los requisitos de red establecidos para Espacios de almacenamiento directo.

Puede identificar un adaptador que tenga AQ Estándar o Premium; para ello, revise la entrada de Catálogo de Windows Server correspondiente al adaptador y la versión del sistema operativo aplicable. A continuación se muestra un ejemplo de la notación de AQ prémium:

Captura de pantalla de las opciones de certificado para Windows, con AQ prémium resaltada.

Introducción a las funcionalidades principales del adaptador de red

Las principales funcionalidades del adaptador de red que aprovecha Azure Stack HCI incluyen:

  • Varias colas dinámicas de máquinas virtuales (VMMQ dinámico o d.VMMQ)
  • Acceso directo a memoria remota (RDMA)
  • RDMA de invitado
  • Formación de equipos insertada en el conmutador (SET)

VMMQ dinámico

Todos los adaptadores de red con AQ Premium admiten VMMQ dinámico. VMMQ dinámico requiere el uso de la funcionalidad Formación de equipos insertada en el conmutador.

Tipos de tráfico aplicables: proceso

Certificaciones necesarias: Premium

VMMQ dinámico es una tecnología inteligente de la recepción. Se basa en sus predecesores Virtual machine Queue (VMQ), Ajuste de escala de recepción virtual (vRSS) y VMMQ, para ofrecer tres mejoras principales:

  • Optimiza la eficiencia del host con menos núcleos de CPU.
  • Ajusta automáticamente el procesamiento del tráfico de red a los núcleos de CPU, lo que permite a las máquinas virtuales cumplir y mantener el rendimiento esperado.
  • Permite que las cargas de trabajo "en ráfagas" reciban la cantidad esperada de tráfico.

Para más información sobre VMMQ dinámico, consulte la entrada de blog Aceleraciones sintéticas.

RDMA

RDMA es una descarga de la pila de red en el adaptador de red. Permite que el tráfico de almacenamiento del bloque de mensajes del servidor omita el sistema operativo en el procesamiento.

RDMA habilita redes de alto rendimiento y baja latencia al tiempo que usa el mínimo de recursos de CPU del host. Estos recursos de CPU del host se pueden usar para ejecutar máquinas virtuales o contenedores adicionales.

Tipos de tráfico aplicables: almacenamiento del host

Certificaciones necesarias: Estándar

Todos los adaptadores con AQ estándar o prémium admiten RDMA. RDMA es la opción de implementación recomendada para las cargas de trabajo de almacenamiento en Azure Stack HCI y se puede habilitar opcionalmente para las cargas de trabajo de almacenamiento (mediante el bloque de mensajes del servidor) de las máquinas virtuales. Para más información, consulte la sección "RDMA de invitado" más adelante en este artículo.

Azure Stack HCI admite RDMA mediante implementaciones del protocolo RDMA de área extensa de Internet (iWARP) o RDMA a través de implementaciones del protocolo Ethernet convergente (RoCE).

Importante

Los adaptadores RDMA solo funcionan con otros adaptadores RDMA que implementan el mismo protocolo RDMA (iWARP o RoCE).

No todos los adaptadores de red de los proveedores admiten RDMA. En la tabla siguiente se enumeran los proveedores (en orden alfabético) que ofrecen adaptadores RDMA certificados como Premium. Sin embargo, hay proveedores de hardware no incluidos en esta lista que también admiten RDMA. Consulte Catálogo de Windows Server para comprobar la compatibilidad con RDMA.

Nota

InfiniBand (IB) no es compatible con Azure Stack HCI.

Proveedor de NIC iWARP RoCE
Broadcom No
Chelsio No
Intel Sí (algunos modelos)
Marvell (QLogic/Cavium)
Nvidia (Mellanox) No

Para más información sobre la implementación de RDMA, descargue el documento del repositorio de GitHub de SDN.

iWARP

iWARP usa el Protocolo de control de transmisión (TCP) y se puede mejorar opcionalmente con el Control de flujo basado en prioridades (PFC) y el Servicio de transmisión mejorada (ETS).

Use iWARP si:

  • Tiene poca o ninguna experiencia con redes o no está familiarizado con la administración de conmutadores de red.
  • No controla los conmutadores de la parte superior del bastidor (ToR).
  • No va a administrar la solución después de la implementación.
  • Ya tiene implementaciones con iWARP.
  • No está seguro de qué opción elegir.

RoCE

RoCE usa el Protocolo de datagramas de usuario (UDP) y requiere PFC y ETS para proporcionar confiabilidad.

Use RoCE si:

  • Ya tiene implementaciones con RoCE en el centro de datos.
  • Está familiarizado con la administración de los requisitos de red de DCB.

RDMA de invitado

RDMA de invitado permite que las cargas de trabajo de SMB de las máquinas virtuales disfruten de las mismas ventajas que con el uso de RDMA en los hosts.

Tipos de tráfico aplicables: almacenamiento basado en invitado

Certificaciones necesarias: Premium

Las principales ventajas de usar RDMA de invitado son:

  • Descarga del procesamiento del tráfico de red de la CPU a la NIC.
  • Latencia extremadamente baja.
  • Capacidad de proceso elevada.

Para más información, descargue el documento del repositorio de GitHub de SDN.

SET

SET es una tecnología de formación de equipos basada en software que se ha incluido en el sistema operativo Windows Server desde Windows Server 2016. SET no depende del tipo de adaptadores de red utilizados.

Tipos de tráfico aplicables: proceso, almacenamiento y administración

Certificaciones necesarias: ninguna (SET está integrado en el sistema operativo)

SET es la única tecnología de formación de equipos admitida por Azure Stack HCI. SET funciona bien con el tráfico de proceso, almacenamiento y administración.

Importante

Azure Stack HCI no admite la formación de equipos de NIC con las tecnologías de formación de equipos anteriores de equilibrio de carga y conmutación por error (LBFO) y el protocolo de control de agregación de vínculos (LACP) que se usan habitualmente con Windows Server. Consulte la entrada de blog Formación de equipos en Azure Stack HCI para más información sobre LBFO en Azure Stack HCI.

SET es importante para Azure Stack HCI, ya que es la única tecnología de formación de equipos que permite:

  • La formación de equipos de adaptadores RDMA (si es necesario).
  • RDMA de invitado.
  • VMMQ dinámico.
  • Otras características principales de Azure Stack HCI (consulte Formación de equipos en Azure Stack HCI).

Tenga en cuenta que SET requiere el uso de adaptadores simétricos (idénticos). No se admite la formación de equipos con adaptadores asimétricos. Los adaptadores de red simétricos son los que tienen los mismos valores de:

  • marca (proveedor)
  • modelo (versión)
  • velocidad (rendimiento)
  • configuración

La manera más sencilla de identificar si los adaptadores son simétricos es comprobar si las velocidades son las mismas y las descripciones de la interfaz coinciden. Solo se admite una diferencia en el número que aparece en la descripción. Use el cmdlet Get-NetAdapterAdvancedProperty para asegurarse de que la configuración que se indica muestra los mismos valores de propiedad.

Consulte la tabla siguiente para obtener un ejemplo de las descripciones de interfaz que solo se diferencian el número (#):

Nombre Descripción de la interfaz Velocidad del vínculo
NIC1 Network Adapter #1 25 Gbps
NIC2 Network Adapter #2 25 Gbps
NIC3 Network Adapter #3 25 Gbps
NIC4 Network Adapter #4 25 Gbps

Nota

SET solo admite la configuración independiente del conmutador mediante algoritmos de equilibrio de carga de puerto dinámico o de Hyper-V. Para el mejor rendimiento, se recomienda usar el puerto de Hyper-V en todas las NIC que funcionan a 10 Gbps o más.

Consideraciones sobre el tráfico RDMA

Si implementa DCB, debe asegurarse de que la configuración de PFC y ETS se implementa correctamente en todos los puertos de red, incluidos los conmutadores de red. DCB es obligatorio para RoCE y opcional para iWARP.

Para información detallada sobre cómo implementar RDMA, descargue el documento del repositorio de GitHub de SDN.

Las implementaciones de Azure Stack HCI basadas en RoCE requieren la configuración de tres clases de tráfico PFC, incluida la clase de tráfico predeterminada, en el tejido y en todos los hosts.

Clase de tráfico del clúster

Esta clase de tráfico garantiza que haya suficiente ancho de banda reservado para los latidos de clúster:

  • Requerido: sí
  • PFC habilitado: no
  • Prioridad de tráfico recomendada: Prioridad 7
  • Reserva de ancho de banda recomendada:
    • Redes RDMA de 10 GbE o menos = 2 %
    • Redes RDMA de 25 GbE o más = 1 %

Clase de tráfico RDMA

Esta clase de tráfico garantiza que haya suficiente ancho de banda reservado para las comunicaciones de RDA sin pérdida mediante el bloque de mensajes del servidor directo:

  • Requerido: sí
  • PFC habilitado: sí
  • Prioridad de tráfico recomendada: Prioridad 3 o 4
  • Reserva de ancho de banda recomendada: 50 %

Clase de tráfico predeterminada

Esta clase de tráfico incluye el resto del tráfico no definido en el clúster o las clases de tráfico RDMA, incluido el tráfico de las máquinas virtuales y el tráfico de administración:

  • Requerido: predeterminado (no se necesita ninguna configuración en el host)
  • Control de flujo (PFC) habilitado: no
  • Clase de tráfico recomendada: predeterminada (Prioridad 0)
  • Reserva de ancho de banda recomendada: predeterminada (no se requiere configuración del host)

Modelos de tráfico de almacenamiento

El bloque de mensajes del servidor ofrece muchas ventajas como protocolo de almacenamiento para Azure Stack HCI, incluido SMB multicanal. SMB multicanal no se abarca en este artículo, pero es importante comprender que el tráfico se multiplexa en cada vínculo posible que pueda usar SMB multicanal.

Nota

Se recomienda usar varias subredes y VLAN para separar el tráfico de almacenamiento en Azure Stack HCI.

Considere el ejemplo siguiente de un clúster de cuatro nodos. Cada servidor tiene dos puertos de almacenamiento (lado izquierdo y derecho). Dado que cada adaptador se encuentra en la misma subred y VLAN, SMB multicanal distribuirá las conexiones entre todos los vínculos disponibles. Por lo tanto, el puerto del lado izquierdo del primer servidor (192.168.1.1) establecerá una conexión con el puerto del lado izquierdo del segundo servidor (192.168.1.2). El puerto del lado derecho del primer servidor (192.168.1.12) se conectará al puerto del lado derecho del segundo servidor. Se establecen conexiones similares para el tercer y cuarto servidor.

Sin embargo, esto crea conexiones innecesarias y produce congestión en el vínculo interno (grupo de agregación de vínculos de varios chasis o MC-LAG) que conecta los conmutadores ToR (marcados con X). Observe el diagrama siguiente:

Diagrama que muestra un clúster de cuatro nodos en la misma subred.

El enfoque recomendado es usar subredes y VLAN independientes para cada conjunto de adaptadores. En el diagrama siguiente, los puertos de la derecha ahora usan la subred 192.168.2.x/24 y la VLAN2. Esto permite que el tráfico de los puertos de la izquierda permanezca en TOR1 y que el tráfico de los puertos del lado derecho permanezca en TOR2.

Diagrama que muestra un clúster de cuatro nodos en subredes diferentes.

Asignación de ancho de banda para el tráfico

En la tabla siguiente se muestran asignaciones de ancho de banda de ejemplo de varios tipos de tráfico, con velocidades de adaptador comunes, en Azure Stack HCI. Tenga en cuenta que se trata de un ejemplo de una solución convergente en la que todos los tipos de tráfico (proceso, almacenamiento y administración) se ejecutan en los mismos adaptadores físicos y la formación de equipos se realiza mediante SET.

Dado que este caso de uso supone la mayoría de las restricciones, representa una buena base de referencia. Sin embargo, si se tienen en cuenta las permutaciones de número de adaptadores y velocidades, se debe considerar un ejemplo y no un requisito auxiliar.

En este ejemplo se realizan las suposiciones siguientes:

  • Hay dos adaptadores por equipo.

  • Tráfico de Capa de bus de almacenamiento (SBL), Volumen compartido de clúster (CSV) e Hyper-V (Migración en vivo):

    • Se usan los mismos adaptadores físicos.
    • Se usa el bloque de mensajes del servidor.
  • El bloque de mensajes del servidor tiene una asignación de ancho de banda del 50 % mediante DCB.

    • El tráfico de SBL y CSV es el tráfico de prioridad más alta y recibe el 70 % de la reserva de ancho de banda de SMB.
    • La migración en vivo (LM) está limitada mediante el cmdlet Set-SMBBandwidthLimit y recibe el 29 % del ancho de banda restante.
      • Si el ancho de banda disponible para la migración en vivo es mayor o igual a 5 Gbps y los adaptadores de red son compatibles, use RDMA. Para ello, use el siguiente cmdlet:

        Set-VMHost VirtualMachineMigrationPerformanceOption SMB
        
      • Si el ancho de banda disponible para la migración en vivo es menor que 5 Gbps, use la compresión para reducir los tiempos sin disponibilidad. Para ello, use el siguiente cmdlet:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
        
  • Si usa RDMA con tráfico de migración en vivo, asegúrese de que este tráfico no consume todo el ancho de banda asignado a la clase de tráfico RDMA mediante un límite de ancho de banda de bloque de mensajes del servidor. Preste atención, ya que este cmdlet toma la entrada en bytes por segundo (Bps), mientras que los adaptadores de red se muestran en bits por segundo (bps). Por ejemplo, use el siguiente cmdlet para establecer un límite de ancho de banda de 6 Gbps:

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
    

    Nota

    En este ejemplo, 750 MBps equivalen a 6 Gbps.

Esta es la tabla de asignación de ancho de banda de ejemplo:

Velocidad de NIC Ancho de banda agrupado Reserva de ancho de banda para SMB** SBL/CSV % Ancho de banda de SBL/CSV % para Migración en vivo Ancho de banda máximo para la migración en vivo % para latidos Ancho de banda para latidos
10 Gbps 20 Gbps 10 Gbps 70% 7 Gbps ** 200 Mbps
25 Gbps 50 Gbps 25 Gbps 70% 17,5 Gbps 29% 7,25 Gbps 1 % 250 MBps
40 Gbps 80 Gbps 40 Gbps 70% 28 Gbps 29% 11,6 Gbps 1 % 400 MBps
50 Gbps 100 Gbps 50 Gbps 70% 35 Gbps 29% 14,5 Gbps 1 % 500 Mbps
100 Gbps 200 Gbps 100 Gbps 70% 70 Gbps 29% 29 Gbps 1 % 1 Gbps
200 Gbps 400 Gbps 200 Gbps 70% 140 Gbps 29% 58 Gbps 1 % 2 Gbps

* Se debe usar compresión en lugar de RDMA, ya que la asignación de ancho de banda para el tráfico de migración en vivo es menor que 5 Gbps.

** El 50 % es una reserva de ancho de banda de ejemplo.

Clústeres extendidos

Los clústeres extendidos proporcionan recuperación ante desastres que abarca varios centros de datos. En su forma más sencilla, una red de clústeres extendidos de Azure Stack HCI tiene el siguiente aspecto:

Diagrama que muestra un clúster extendido.

Requisitos de clúster extendido

Los clústeres extendidos tienen los siguientes requisitos y características:

  • RDMA está limitado a un único sitio y no se admite entre diferentes sitios o subredes.

  • Los servidores del mismo sitio deben residir en el mismo bastidor y en el mismo límite de capa 2.

  • La comunicación de host entre sitios tiene que atravesar un límite de capa 3; no se admiten las topologías de capa 2 extendidas.

  • Tener suficiente ancho de banda para ejecutar las cargas de trabajo en el otro sitio. En caso de conmutación por error, el sitio alternativo tendrá que ejecutar todo el tráfico. Se recomienda aprovisionar los sitios al 50 % de su capacidad de red disponible. Esto no es un requisito si se puede tolerar un rendimiento menor durante una conmutación por error.

  • La replicación entre sitios (tráfico vertical de arriba abajo) puede usar las mismas NIC físicas que el almacenamiento local (tráfico horizontal de derecha a izquierda). Si se usan los mismos adaptadores físicos, estos adaptadores deben estar en equipo con SET. Los adaptadores también deben tener NIC virtuales adicionales aprovisionadas para el tráfico enrutable entre sitios.

  • Los adaptadores usados para la comunicación entre sitios:

    • Pueden ser físicos o virtuales (vNIC de host). Si los adaptadores son virtuales, debe aprovisionar una NIC virtual en su propia subred y VLAN por cada NIC física.

    • Deben estar en su propia subred y VLAN, que pueden enrutar entre sitios.

    • Se debe deshabilitar RDMA mediante el cmdlet Disable-NetAdapterRDMA. Se recomienda requerir explícitamente que la réplica de almacenamiento use interfaces específicas con el cmdlet Set-SRNetworkConstraint.

    • Debe cumplir los requisitos adicionales para la réplica de almacenamiento.

Ejemplo de clúster extendido

En el ejemplo siguiente se muestra una configuración de clúster extendido. Para asegurarse de que una NIC virtual específica esté asignada a un adaptador físico específico, use el cmdlet Set-VMNetworkAdapterTeammapping.

Diagrama que muestra un ejemplo de almacenamiento de clúster extendido.

A continuación se muestran los detalles de la configuración de clúster extendido de ejemplo.

Nota

La configuración exacta, incluidos los nombres de NIC, las direcciones IP y VLAN, puede diferir de lo que se muestra. Esto se usa solo como configuración de referencia y se adapta al entorno.

SitioA: replicación local, RDMA habilitado, no enrutable entre sitios.

nombre del nodo Nombre de NIC virtual NIC física (asignada) VLAN IP y subred Ámbito del tráfico
NodeA1 vSMB01 pNIC01 711 192.168.1.1/24 Solo sitio local
NodeA2 vSMB01 pNIC01 711 192.168.1.2/24 Solo sitio local
NodeA1 vSMB02 pNIC02 712 192.168.2.1/24 Solo sitio local
NodeA2 vSMB02 pNIC02 712 192.168.2.2/24 Solo sitio local

SitioB: replicación local, RDMA habilitado, no enrutable entre sitios.

nombre del nodo Nombre de NIC virtual NIC física (asignada) VLAN IP y subred Ámbito del tráfico
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 Solo sitio local
NodeB2 vSMB01 pNIC01 711 192.168.1.2/24 Solo sitio local
NodeB1 vSMB02 pNIC02 712 192.168.2.1/24 Solo sitio local
NodeB2 vSMB02 pNIC02 712 192.168.2.2/24 Solo sitio local

SitioA: replicación extendida, RDMA deshabilitado, enrutable entre sitios.

nombre del nodo Nombre de NIC virtual NIC física (asignada) IP y subred Ámbito del tráfico
NodeA1 Stretch1 pNIC01 173.0.0.1/8 Enrutable entre sitios
NodeA2 Stretch1 pNIC01 173.0.0.2/8 Enrutable entre sitios
NodeA1 Stretch2 pNIC02 174.0.0.1/8 Enrutable entre sitios
NodeA2 Stretch2 pNIC02 174.0.0.2/8 Enrutable entre sitios

SitioB: replicación extendida, RDMA deshabilitado, enrutable entre sitios

nombre del nodo Nombre de NIC virtual NIC física (asignada) IP y subred Ámbito del tráfico
NodeB1 Stretch1 pNIC01 175.0.0.1/8 Enrutable entre sitios
NodeB2 Stretch1 pNIC01 175.0.0.2/8 Enrutable entre sitios
NodeB1 Stretch2 pNIC02 176.0.0.1/8 Enrutable entre sitios
NodeB2 Stretch2 pNIC02 176.0.0.2/8 Enrutable entre sitios

Pasos siguientes