Requisitos de red físicos para Azure Local

Se aplica a: Implementaciones hiperconvergidas de Azure Local

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

Conmutadores de red para Azure Local

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

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 Local para los tipos de rol especificados. Los siguientes proveedores (en orden alfabético) confirman que sus conmutadores admiten los requisitos locales de Azure.

Conmutadores de red validados según proveedor

Para ver los conmutadores validados para cada uno de los tipos de tráfico local de Azure, seleccione y expanda un proveedor en la lista siguiente. Puede encontrar estas clasificaciones de red aquí.

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 usados en las implementaciones de Azure Local. Estos estándares ayudan a garantizar comunicaciones confiables entre nodos en implementaciones de Azure Local.

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

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 más a conceptos de la topología de Spine-Leaf que se usa habitualmente con cargas de trabajo en infraestructura hiperconvergida, como Azure Local.

Modelos de red

Puede clasificar el tráfico de red 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).

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 administración (PowerShell, Windows Admin Center) y tráfico de proceso (VM).
• 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.
• Puede usar un conmutador Ethernet (conmutado) o una conexión directa (sin conmutador), como se describe en las dos secciones siguientes.

Directiva de QoS para Azure Local

Para asegurar una priorización constante del tráfico en las implementaciones locales de Azure, las políticas de QoS deben estar alineadas con las configuraciones de host que gestionan el tráfico de almacenamiento a través de la infraestructura de conmutación admitida. Esta directiva se aplica a los entornos ROCEv2 e iWARP y es necesario para las configuraciones de Azure Local conmutadas. Las configuraciones sin conmutador, que no enrutan el tráfico de almacenamiento a través de un conmutador, no requieren esta directiva.

Para obtener más información, consulte Azure Local - QoS Policy.

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.

Debe comprender el ancho de banda de conmutación interna "sin bloqueo" que pueden admitir sus conmutadores Ethernet y minimizar (o, preferiblemente, eliminar) la sobresuscripción de la red.

Puede eliminar los puntos habituales de congestión y la sobresuscripción, como el grupo de agregación de enlaces multichasis utilizado para la redundancia de rutas, mediante un uso adecuado de subredes y VLAN. Para obtener más información, consulte Requisitos de red de host.

Trabaje con el proveedor de red o 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 pretende ejecutar.

Sin conmutadores

Azure Local admite conexiones sin conmutador (directas) para el tráfico Este-Oeste en todos los tamaños del sistema, siempre y cuando cada nodo del sistema tenga una conexión redundante con cada otro nodo del sistema. Esta configuración se denomina conexión de "malla completa".

Ventajas de las conexiones sin conmutador

• No es necesario comprar un conmutador para el tráfico este-oeste. Necesita un conmutador para el tráfico norte-sur. Esto puede dar lugar a menores gastos de capital (CAPEX), pero depende del número de nodos del sistema.
• Como no hay ningún conmutador, solo configuras el host, lo que puede reducir el número de pasos de configuración. Este valor disminuye a medida que aumenta el tamaño del sistema.

Desventajas de las conexiones sin conmutador

• Debe planificar mejor los esquemas de direccionamiento IP y de subredes.
• Estos adaptadores solo proporcionan acceso de almacenamiento local. El tráfico de administración, el tráfico de máquina virtual y otro tráfico que requiere acceso Norte-Sur no puede usar estos adaptadores.
• A medida que crece el número de nodos del sistema, el costo de los adaptadores de red puede superar el costo de usar conmutadores de red.
• No se escalan mucho más allá de los sistemas de tres nodos. Más nodos incurren en cableado y configuración adicionales que pueden superar la complejidad de usar un conmutador.
• La expansión del sistema es compleja y requiere cambios de configuración de hardware y software.

Pasos siguientes

• Consulte Implementar mediante el portal de Azure.
• Consulte Implementar usando plantilla de Azure Resource Manager.