Requisitos de red física para Azure Stack HCI
Se aplica a: Azure Stack HCI, versiones 23H2 y 22H2
En este artículo se describen los requisitos y las consideraciones de red física (tejido) para Azure Stack HCI, especialmente para los conmutadores de red.
Nota:
Los requisitos para futuras versiones de Azure Stack HCI pueden cambiar.
Conmutadores de red para Azure Stack HCI
Microsoft prueba Azure Stack HCI con los estándares y protocolos que se identifican en la siguiente sección Requisitos del conmutador de red . Aunque Microsoft no certifica los conmutadores de red, trabajamos con los proveedores para identificar los dispositivos que admiten los requisitos de Azure Stack HCI.
Importante
Aunque los demás conmutadores de red que usan tecnologías y protocolos que no se enumeran aquí pueden funcionar, Microsoft no puede garantizar que funcionarán con Azure Stack HCI y es posible que no pueda ayudar a solucionar los problemas que se produzcan.
Al comprar conmutadores de red, póngase en contacto con el proveedor del conmutador y asegúrese de que los dispositivos cumplen los requisitos de Azure Stack HCI para los tipos de roles especificados. Los siguientes proveedores (en orden alfabético) han confirmado que sus conmutadores admiten los requisitos de Azure Stack HCI:
Haga clic en una pestaña proveedor para ver modificadores validados para cada uno de los tipos de tráfico de Azure Stack HCI. Estas clasificaciones de red se pueden encontrar aquí.
Importante
Actualizamos estas listas a medida que se nos informa de los cambios realizados por los proveedores de conmutadores de red.
Si su conmutador no está incluido, póngase en contacto con el proveedor del conmutador para asegurarse de que el modelo de conmutador y la versión del sistema operativo del conmutador admiten los requisitos que se indican en la sección siguiente.
Requisitos del conmutador de red
En esta sección se enumeran los estándares del sector que son obligatorios para los roles específicos de los conmutadores de red que se usan en las implementaciones de Azure Stack HCI. Estos estándares ayudan a garantizar unas comunicaciones confiables entre los nodos de las implementaciones de clústeres de Azure Stack HCI.
Nota:
Los adaptadores de red que se usan para el tráfico de proceso, almacenamiento y administración requieren Ethernet. Para más información, consulte Requisitos de red de host para Azure Stack HCI.
Estos son los estándares y especificaciones de IEEE obligatorios:
Requisitos de roles de 23H2
| Requisito | Administración | Storage | Proceso (Estándar) | Proceso (SDN) |
|---|---|---|---|---|
| REDES LAN virtuales | ✓ | ✓ | ✓ | ✓ |
| Control de flujo de prioridad | ✓ | |||
| Selección mejorada de transmisión | ✓ | |||
| Id. de VLAN del puerto LLDP | ✓ | |||
| Nombre de VLAN de LLDP | ✓ | ✓ | ✓ | |
| Agregación de vínculos LLDP | ✓ | ✓ | ✓ | ✓ |
| Configuración de ETS de LLDP | ✓ | |||
| Recomendación de ETS de LLDP | ✓ | |||
| Configuración de PFC de LLDP | ✓ | |||
| Tamaño máximo de fotograma llDP | ✓ | ✓ | ✓ | ✓ |
| Unidad de transmisión máxima | ✓ | |||
| Protocolo de puerta de enlace de borde | ✓ | |||
| Agente de retransmisión DHCP | ✓ |
Nota:
RDMA invitado requiere proceso (estándar) y almacenamiento.
Estándar: IEEE 802.1Q
Los conmutadores Ethernet deben cumplir con la especificación IEEE 802.1Q que define las redes VLAN. Las VLAN son necesarias para varios aspectos de Azure Stack HCI y son necesarias en todos los escenarios.
Estándar: IEEE 802.1Qbb
Los conmutadores Ethernet que se usan para el tráfico de almacenamiento de Azure Stack HCI deben cumplir con la especificación IEEE 802.1Qbb que define el control de flujo de prioridad (PFC). Si se usa Data Center Bridging (DCB), se necesita PFC. Como DCB se puede usar en escenarios de RDMA como RoCE e iWARP, se necesita 802.1Qbb en todos los escenarios. Se requiere un mínimo de tres prioridades de clase de servicio (CoS) sin que se degraden las funcionalidades del conmutador o la velocidad del puerto. Al menos una de estas clases de tráfico debe proporcionar comunicación sin pérdida.
Estándar: IEEE 802.1Qaz
Los conmutadores Ethernet que se usan para el tráfico de almacenamiento de Azure Stack HCI deben cumplir con la especificación IEEE 802.1Qaz que define la selección de transmisión mejorada (ETS). Se requiere ETS si se usa DCB. Como DCB se puede usar en escenarios de RDMA como RoCE e iWARP, se necesita 802.1Qaz en todos los escenarios.
Se requiere un mínimo de tres prioridades de clase de servicio (CoS) sin que se degraden las funcionalidades del conmutador o la velocidad del puerto. Además, si el dispositivo permite definir las velocidades de QoS de entrada, se recomienda no configurar las tasas de entrada ni configurarlas en el mismo valor exacto que las tarifas de salida (ETS).
Nota:
La infraestructura hiperconvergida tiene una dependencia elevada de la comunicación de capa 2 horizontal de derecha a izquierda en el mismo bastidor y, por tanto, requiere ETS. Microsoft no prueba Azure Stack HCI con Punto de código de servicios diferenciados (DSCP).
Estándar: IEEE 802.1AB
Los conmutadores Ethernet deben cumplir la especificación IEEE 802.1AB que define el protocolo de detección de niveles de vínculo (LLDP). Se requiere LLDP para Azure Stack HCl y permite solucionar problemas de configuraciones de redes físicas.
La configuración del tipo, longitud y valores (TLVs) de LLDP debe estar habilitada dinámicamente. Los conmutadores no deben requerir configuración adicional más allá de la habilitación de un TLV específico. Por ejemplo, si habilita el subtipo 3 de 802.1, se anunciarán automáticamente todas las redes VLAN disponibles en los puertos del conmutador.
Requisitos de los TLV personalizados
LLDP permite a las organizaciones definir y codificar sus propios TLV personalizados. Estos se denominan TLV específicos de la organización. Todos los TLV específicos de la organización se inician con un valor de tipo TLV de LLDP de 127. En la tabla siguiente se muestran los subtipos TLV personalizados específicos de la organización (tipo TLV 127).
| Organización | Subtipo de TLV |
|---|---|
| IEEE 802.1 | Identificador de VLAN del puerto (subtipo = 1) |
| IEEE 802.1 | Nombre de VLAN (subtipo = 3) Mínimo de 10 VLANS |
| IEEE 802.1 | Agregación de vínculos (subtipo = 7) |
| IEEE 802.1 | Configuración de ETS (subtipo = 9) |
| IEEE 802.1 | Recomendación de ETS (subtipo = A) |
| IEEE 802.1 | Configuración de PFC (subtipo = B) |
| IEEE 802.3 | Tamaño máximo del marco (subtipo = 4) |
Unidad de transmisión máxima
La unidad de transmisión máxima (MTU) es el marco o paquete de mayor tamaño que se puede transmitir a través de un vínculo de datos. Se requiere un intervalo de 1514 - 9174 para la encapsulación de SDN.
Protocolo de puerta de enlace de borde
Los conmutadores Ethernet que se usan para el tráfico de proceso sdN de Azure Stack HCI deben admitir el protocolo de puerta de enlace de borde (BGP). BGP es un protocolo de enrutamiento estándar que se usa para intercambiar información de enrutamiento y accesibilidad entre dos o más redes. Las rutas se agregan automáticamente a la tabla de rutas para todas las subredes que tienen habilitada la propagación de BGP. Esto es necesario para habilitar cargas de trabajo de inquilino con SDN y emparejamiento dinámico. RFC 4271: Protocolo de puerta de enlace de borde 4
Agente de retransmisión DHCP
Los conmutadores Ethernet usados para el tráfico de administración de Azure Stack HCI deben admitir el agente de retransmisión DHCP. El agente de retransmisión DHCP es cualquier host TCP/IP que se usa para reenviar solicitudes y respuestas entre el servidor DHCP y el cliente cuando el servidor está presente en una red diferente. Es necesario para los servicios de arranque del entorno PXE. RFC 3046: DHCPv4 o RFC 6148: DHCPv4
Arquitectura y tráfico de red
Esta sección es principalmente para los administradores de red.
Azure Stack HCI puede funcionar en diversas arquitecturas de centros de datos, entre las que se incluyen las de dos niveles (columna-hoja) y las de tres niveles (principal-agregación-acceso). En esta sección se hace referencia a los conceptos de la topología columna-hoja que se suelen usar con las cargas de trabajo en una infraestructura hiperconvergida, como Azure Stack HCI.
Modelos de red
El tráfico de red se puede clasificar por su dirección. Los entornos de red de área de almacenamiento (SAN) tradicionales son intensivos en tráfico vertical de arriba abajo, donde el tráfico fluye desde una capa de proceso a una capa de almacenamiento a través de un límite de capa 3 (IP). La infraestructura hiperconvergida es más intensa en tráfico horizontal de derecha a izquierda, donde una parte importante del tráfico permanece dentro de un límite de capa 2 (VLAN).
Importante
Se recomienda que todos los nodos de clúster de un sitio se encuentren físicamente en el mismo bastidor y estén conectados a los mismos conmutadores de la parte superior del rack (ToR).
Nota:
La funcionalidad de clúster extendido solo está disponible en Azure Stack HCI, versión 22H2.
Tráfico vertical de arriba abajo para Azure Stack HCI
El tráfico vertical de arriba abajo tiene las siguientes características:
- El tráfico fluye desde un conmutador ToR hacia el tronco o viceversa.
- El tráfico sale del bastidor físico o cruza un límite de capa 3 (IP).
- Incluye la administración (PowerShell, Windows Admin Center), el proceso (VM) y el tráfico de clúster extendido entre sitios.
- Usa un conmutador Ethernet para la conectividad a la red física.
Tráfico horizontal de derecha a izquierda para Azure Stack HCI
El tráfico horizontal de derecha a izquierda tiene las siguientes características:
- El tráfico permanece dentro de los conmutadores ToR y el límite de nivel 2 (VLAN).
- Incluye el tráfico de almacenamiento o el tráfico de migración en vivo entre los nodos del mismo clúster y (si se usa un clúster extendido) dentro del mismo sitio.
- Puede usar un conmutador Ethernet (conmutado) o una conexión directa (sin conmutador), como se describe en las dos secciones siguientes.
Con conmutadores
El tráfico vertical de arriba abajo requiere el uso de conmutadores. Además de usar un conmutador Ethernet que admita los protocolos necesarios para Azure Stack HCI, el aspecto más importante es el tamaño adecuado del tejido de red.
Es imperativo conocer el ancho de banda de tejido "sin bloqueo" que pueden admitir los conmutadores Ethernet y que se minimice (o, preferiblemente, se elimine) la suscripción en exceso de la red.
Los puntos de congestión comunes y la suscripción en exceso, como el grupo de agregación de vínculos de varios chasis que se usan para la redundancia de rutas de acceso, se pueden eliminar mediante el uso correcto de subredes y VLAN. Consulte también Requisitos de red de host para Azure Stack HCI.
Colabore con su proveedor de red o con el equipo de soporte técnico de red para asegurarse de que los conmutadores de red tienen el tamaño adecuado para la carga de trabajo que intenta ejecutar.
Sin conmutadores
Azure Stack HCI admite conexiones sin conmutadores (directas) para el tráfico horizontal de derecha a izquierda para todos los tamaños de clúster, siempre que cada nodo del clúster tenga una conexión redundante a cada nodo del clúster. Esto se llama conexión de "malla completa".
| Par de interfaces | Subnet | VLAN |
|---|---|---|
| NIC virtual del host mgmt | Específico del cliente | Específico del cliente |
| SMB01 | 192.168.71.x/24 | 711 |
| SMB02 | 192.168.72.x/24 | 712 |
| SMB03 | 192.168.73.x/24 | 713 |
Nota:
Las ventajas de las implementaciones sin conmutadores disminuyen con clústeres de más de tres nodos debido al número de adaptadores de red necesarios.
Ventajas de las conexiones sin conmutador
- No es necesaria la adquisición de conmutadores para el tráfico horizontal de derecha a izquierda. Se requiere un conmutador para el tráfico vertical de arriba abajo. Esto puede dar lugar a costos de capital reducidos (gastos de capital), pero depende del número de nodos del clúster.
- Dado que no hay ningún conmutador, la configuración se limita al host, lo que puede reducir el número potencial de pasos de configuración necesarios. Este valor disminuye a medida que aumenta el tamaño del clúster.
Desventajas de las conexiones sin conmutador
- Se requiere más planeación para los esquemas de direcciones IP y de subred.
- Proporciona solo acceso de almacenamiento local. El tráfico de administración, el tráfico de las máquinas virtuales y cualquier otro tráfico que requiera acceso vertical de arriba abajo no pueden usar estos adaptadores.
- A medida que crece el número de nodos del clúster, el costo de los adaptadores de red podría superar el costo del uso de conmutadores de red.
- No se escala bien con clústeres de más de tres nodos. Un mayor número de nodos conlleva cableado y configuración adicionales que pueden superar la complejidad del uso de un conmutador.
- La expansión del clúster es compleja y requiere cambios de configuración de hardware y software.
Pasos siguientes
- Consulte Implementación mediante Azure Portal.
- Consulte Implementación mediante la plantilla de Azure Resource Manager.