Compartir a través de

Requisitos de red de host para Azure Stack HCI

  • Artículo

Se aplica a: Azure Stack HCI, versiones 23H2 y 22H2

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 administración: Tráfico desde o hacia el clúster local. Por ejemplo, el tráfico de réplicas de almacenamiento o el tráfico usado por el administrador para la administración del clúster, como Escritorio remoto, Windows Admin Center, Active Directory, etc.
  • 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. Este tráfico es el tráfico de nivel 2 y no es enrutable.

Importante

La réplica de almacenamiento usa tráfico SMB no basado en RDMA. Esto y la naturaleza direccional del tráfico (vertical de arriba abajo) lo alinean estrechamente con el de tráfico de "administración" enumerado anteriormente, similar al de un recurso compartido de archivos tradicional.

Selección de un adaptador de red

Los adaptadores de red se clasifican por los tipos de tráfico de red (consulte más arriba) con los que se pueden usar. Al revisar el catálogo de Windows Server, la certificación de Windows Server 2022 ahora indica uno o varios de los siguientes roles. Antes de comprar un servidor para Azure Stack HCI, debe tener al menos un adaptador clasificado para la administración, el proceso y el almacenamiento, ya que los tres tipos de tráfico son necesarios en Azure Stack HCI. Luego, puede usar Network ATC para configurar los adaptadores para los tipos de tráfico adecuados.

Para más información sobre esta clasificación de NIC basada en roles, consulte este vínculo.

Importante

No se admite el uso de un adaptador fuera de su tipo de tráfico clasificado.

Nivel Rol de administración Rol de proceso Rol de almacenamiento
Distinción basada en roles Administración Proceso estándar Storage Standard
Premio máximo No es aplicable Proceso prémium Almacenamiento prémium

Nota:

La clasificación más alta de cualquier adaptador de nuestro ecosistema contendrá las clasificaciones Administración, Proceso prémium y Almacenamiento prémium.

Captura de pantalla que muestra las calificaciones

Requisitos para controladores

Los controladores de bandeja de entrada no se admiten con Azure Stack HCI. Para identificar si el adaptador usa un controlador de bandeja de entrada, ejecute el siguiente cmdlet. Un adaptador usa un controlador de bandeja de entrada si la propiedad DriverProvider es Microsoft.

Get-NetAdapter -Name <AdapterName> | Select *Driver*

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 la calificación Compute (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: Proceso (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 de "ráfaga" 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: Almacenamiento (estándar)

Todos los adaptadores con la calificación storage (Estándar) o Storage (Premium) admiten RDMA del lado host. Para obtener más información sobre el uso de RDMA con cargas de trabajo de invitado, consulte la sección "RDMA invitado" más adelante en este artículo.

Azure Stack HCI admite RDMA con las implementaciones del protocolo RDMA de área extensa de Internet (iWARP) o RDMA a través 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. Sin embargo, hay proveedores de hardware no incluidos en esta lista que también admiten RDMA. Consulte el Catálogo de Windows Server para buscar adaptadores con la calificación Storage (Estándar) o Storage (Premium) que requieren compatibilidad con RDMA.

Nota:

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

Proveedor de NIC iWARP RoCE
Broadcom No Sí
Intel Sí Sí (algunos modelos)
Marvell (Qlogic) Sí Sí
Nvidia No Sí

Para obtener más información sobre la implementación de RDMA para el host, se recomienda encarecidamente usar Network ATC. Para obtener información sobre la implementación manual, consulte el 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:

  • No tiene experiencia en la administración de redes RDMA.
  • No administra o no se siente incómodo administrando 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: Proceso (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.

Formación de equipos insertada en el conmutador (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 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, y se admite con hasta ocho adaptadores en el mismo equipo.

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

Certificaciones necesarias: Proceso (Estándar) o Proceso (Premium)

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 el equilibrio de carga o conmutación por error (LBFO) anterior. 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).

SET requiere el uso de adaptadores simétricos (idénticos). Los adaptadores de red simétricos son los que tienen los mismos valores de:

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

En 22H2, Network ATC detectará e informará automáticamente si los adaptadores que ha elegido son asimétricos. La manera más fácil de identificar manualmente si los adaptadores son simétricos es si las velocidades y las descripciones de la interfaz son coincidencias exactas . 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. Network ATC realiza todas las configuraciones necesarias para SET.

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:

  • Obligatorio: 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:

  • Obligatorio: 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:

  • Obligatorio: de forma predeterminada (sin necesidad de configuración en el host)
  • Control de flujo (PFC) habilitado: no
  • Clase de tráfico recomendada: De forma predeterminada (Prioridad 0)
  • Reserva de ancho de banda recomendada: de forma predeterminada (no se requiere ninguna configuración de 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

Importante

La funcionalidad de clúster extendido solo está disponible en Azure Stack HCI, versión 22H2.

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.

  • 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.

Pasos siguientes