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 modificadores admiten los requisitos locales de Azure:
Haga clic en una pestaña proveedor para ver modificadores validados para cada uno de los tipos de tráfico local de Azure. 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.
Broadcom Advanced Enterprise SONiC OS 4.2.1 o posterior
✓
✓
✓
✓
Nota:
RDMA invitado requiere proceso (estándar) y almacenamiento.
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 más información, consulte Requisitos de red de host para Azure Stack HCI.
Estos son los estándares y especificaciones de IEEE obligatorios:
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 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 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 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 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 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 de borde 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
Requisitos de roles de 22H2
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 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 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 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 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
Nuevo requisito en 22H2
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
Nuevo requisito en 22H2
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 de borde 4
Agente de retransmisión DHCP
Nuevo requisito en 22H2
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 del centro de datos, como 2 niveles (hoja de columna) y 3 niveles (Core-Aggregation-Access). En esta sección se hace referencia más a los conceptos de la topología de hoja de columna que se usa habitualmente con cargas de trabajo en infraestructura hiperconvergida, como Azure Local.
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 encarecidamente que todas las máquinas locales de Azure de un sitio se encuentren físicamente en el mismo bastidor y estén 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 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 este-oeste para Azure Local
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 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.
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 Local, el aspecto más importante es el ajuste de 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.
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".
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 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 vertical de arriba abajo. 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.
