Compartir a través de

Requisitos de red física para Azure Local

Se aplica a: Azure Local 2311.2 y versiones posteriores

En este artículo se describen las consideraciones y los requisitos de red físicos (fabric) para Azure Local, especialmente para los conmutadores de red.

Nota:

Los requisitos para futuras versiones locales de Azure pueden cambiar.

Conmutadores de red para Azure Local

Microsoft prueba Azure Local con los estándares y protocolos identificados en la sección Requisitos del conmutador de red a continuación. Aunque Microsoft no certifica los conmutadores de red, trabajamos con proveedores para identificar los dispositivos que admiten los requisitos locales de Azure.

Importante

Aunque otros conmutadores de red que usan tecnologías y protocolos que no aparecen aquí pueden funcionar, Microsoft no puede garantizar que funcionen con Azure Local y es posible que no puedan ayudar a solucionar problemas que se producen.

Al comprar conmutadores de red, póngase en contacto con el proveedor del conmutador y asegúrese de que los dispositivos cumplen los requisitos locales de Azure para los tipos de roles especificados. Los siguientes proveedores (en orden alfabético) han confirmado que sus conmutadores admiten los requisitos locales de Azure.

Haga clic en una pestaña de proveedor para ver interruptores validados para cada uno de los tipos de tráfico de Azure Local. 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 locales de Azure. Estos estándares ayudan a garantizar comunicaciones confiables entre nodos en implementaciones locales de Azure.

Nota:

Los adaptadores de red que se usan para el tráfico de proceso, almacenamiento y administración requieren Ethernet. Para obtener más información, consulte Requisitos de red de host.

Estos son los estándares y especificaciones de IEEE obligatorios:

Requisitos de la función 23H2

Requisito Administración Almacenamiento Calcular (Estándar) Computación (SDN)
REDES LAN virtuales ✓ ✓ ✓ ✓
Control de flujo prioritario ✓
Selección de transmisión mejorada ✓
Id. de VLAN del puerto LLDP ✓
Nombre de VLAN de LLDP ✓ ✓ ✓
Agregación de enlaces LLDP ✓ ✓ ✓ ✓
Configuración de ETS de LLDP ✓
Recomendación LLDP ETS ✓
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 Frontera ✓
Agente de retransmisión DHCP ✓

Nota:

El RDMA invitado requiere tanto Cómputo (estándar) como 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 Local y son necesarios en todos los escenarios.

Estándar: IEEE 802.1Qbb

Los conmutadores Ethernet usados para el tráfico de almacenamiento local de Azure 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 local de Azure 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 alta dependencia de la comunicación de capa 2 de este a oeste dentro del mismo rack y, por tanto, requiere ETS. Microsoft no prueba Azure Local 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). LLDP es necesario para Azure Local y permite la solución de problemas de configuraciones de red físicas.

La configuración de los valores de tipo y longitud de LLDP (TLVs) debe habilitarse de forma dinámica. 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 de TLV personalizados específicos de la organización (tipo TLV 127) necesarios.

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 VLANes
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 necesita un rango de 1514 - 9174 para la encapsulación SDN.

Protocolo de Puerta de Enlace de Frontera

Los conmutadores Ethernet que se usan para el tráfico de proceso de SDN local de Azure 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 Fronterizo 4

Agente de retransmisión DHCP

Los conmutadores Ethernet usados para el tráfico de administración local de Azure 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 Local puede funcionar en varias arquitecturas de centros de datos, incluidas las de 2 niveles (Spine-Leaf) y 3 niveles (Core-Aggregation-Access). En esta sección se hace referencia principalmente a los conceptos de la topología Spine-Leaf que se utiliza habitualmente con cargas de trabajo de procesamiento en infraestructuras hiperconvergidas, como Azure Local.

Modelos de red

El tráfico de red se puede clasificar por su dirección. Los entornos tradicionales de red de área de almacenamiento (SAN) se caracterizan por un tráfico norte-sur, donde el tráfico fluye desde un nivel de computación hacia un nivel de almacenamiento a través de una frontera de capa 3 (IP). La infraestructura hiperconvergida tiene un tráfico predominantemente Este-Oeste, donde una parte importante del tráfico permanece dentro de un límite de capa 2 (VLAN).

Importante

Es necesario que todas las máquinas locales de Azure de un sitio estén físicamente ubicadas en el mismo bastidor y conectadas a los mismos conmutadores de la parte superior del bastidor (ToR).

Nota:

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

Tráfico Norte-Sur para Azure Local

El tráfico de norte a sur 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 Este-Oeste para Azure Local

El tráfico de Este-Oeste tiene las siguientes características:

  • El tráfico permanece dentro de los conmutadores ToR y el límite de nivel 2 (VLAN).
  • Incluye tráfico de almacenamiento o tráfico de migración en vivo entre nodos del mismo sistema 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.

Usando 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 Local, el aspecto más importante es el ajuste de tamaño adecuado del tejido de red.

Es imperativo comprender el ancho de banda de malla "sin bloqueo" que pueden admitir sus conmutadores Ethernet y minimizar (o, preferiblemente, eliminar) la sobresuscripción 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.

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 Local admite conexiones sin conmutadores (directas) para el tráfico Este-Oeste para todos los tamaños del sistema, siempre y cuando cada nodo del sistema tenga una conexión redundante a todos los nodos del sistema. Esto se llama conexión de "malla completa".

Diagrama que muestra la conectividad sin conmutadores de malla completa

Par de interfaces Subred Red de Área Local Virtual (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 conmutador disminuye con sistemas mayores que 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 de Norte a Sur. Esto puede dar lugar a menores gastos de capital (CAPEX), pero depende del número de nodos del sistema.
  • 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 sistema.

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 sistema, el costo de los adaptadores de red podría superar el costo de usar conmutadores de red.
  • No se escala mucho más allá de los sistemas 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 sistema es compleja y requiere cambios de configuración de hardware y software.

Pasos siguientes