Consideraciones de red para implementaciones en la nube de Azure Local

Se aplica a: Implementaciones hiperconvergidas de Azure Local

En este artículo se describe cómo diseñar y planear una red de sistema local de Azure para la implementación en la nube. Antes de continuar, familiarícese con los distintos patrones de red local de Azure y las configuraciones disponibles.

Por qué un marco de diseño de red

El diseño de la red host para una instancia de Azure Local implica más de 10 decisiones de interbloqueo: modo de conectividad, arquitectura, topología física, tamaño del clúster, conectividad de almacenamiento, puertos de adaptador de red, intenciones de tráfico de red, direccionamiento IP, VLAN, copia de seguridad, conectividad saliente y redes definidas por software. Un marco estructurado le ayuda a:

  • Tome cada decisión una vez, en el orden correcto, para que las opciones anteriores restrinjan y simplifiquen las posteriores.
  • Detecte combinaciones no válidas al principio, como una combinación no admitida de arquitectura, tipo de almacenamiento e intenciones.
  • Establecer un vocabulario compartido entre arquitectos, operaciones y despliegues sobre el terreno.
  • Aplique un proceso repetible desde un clúster de borde de un solo nodo hasta un despliegue multibastidor de 64 nodos.

Marco de diseño de red

El marco de diseño de red es una secuencia de 11 decisiones para la instancia de Azure Local. Primero decide el modo de conectividad y luego elige una arquitectura que bifurca el diseño en una ruta de acceso hiperconvergida (HCI) o una ruta de acceso desagregada (DA). Cada decisión posterior documenta ambas rutas de acceso y se cierra con una lista de consideraciones de diseño:

  1. Determinación del modo de conectividad
  2. Determinación de la arquitectura
  3. Determinación de la topología de clúster
  4. Determinación del tamaño del clúster
  5. Determinación de la conectividad de almacenamiento
  6. Determinación de los puertos y la configuración del adaptador de red
  7. Determinación de intenciones de tráfico de red
  8. Determinación de direcciones IP de administración y red de infraestructura
  9. Determinación de la red de copia de seguridad
  10. Determinación de la conectividad saliente
  11. Determinación de redes definidas por software (SDN)

Decisión 1: Determinar el modo de conectividad

El modo de conectividad determina cómo la instancia de Azure Local alcanza Azure para la administración del registro, la facturación y el ciclo de vida. Lo decide primero, ya que se aplica tanto a las arquitecturas hiperconvergidas como desagregadas, e influye en el diseño de conectividad saliente en la Decisión 10.

  • Conectado: los nodos y los servicios de infraestructura llegan a Azure a través de Internet, directamente a través de un proxy de empresa, a través de la puerta de enlace de Azure Arc o a través de vpn de ExpressRoute/S2S. Este es el modo más común y es necesario para la implementación en la nube estándar. Planea los detalles de la conectividad saliente en la Decisión 10.
  • Desconectado (aislado de la red): para entornos soberanos, regulados o aislados de la red, las operaciones desconectadas de Azure Local proporcionan un extremo local de nube autónoma en lugar de puntos de conexión públicos de Azure. Una implementación desconectada usa un plano de control de Azure Arc local que se ejecuta en un clúster de administración de 3 nodos dedicados.

Estas son las consideraciones resumidas para la decisión del modo de conectividad:

# Consideración Se aplica a
1 Las implementaciones conectadas requieren acceso saliente a Azure para la administración del ciclo de vida, la facturación y el registro de Arc. Planee la topología saliente en la Decisión 10. Ambas
2 Las implementaciones desconectadas usan las operaciones desconectadas de Azure Local con un punto de conexión local de Autonomous Cloud y no requieren puntos de conexión públicos de Azure. Ambas
3 Las implementaciones desconectadas requieren un clúster de administración de tres nodos dedicado más uno o varios clústeres de carga de trabajo. Ambas
4 El modo de conectividad se aplica a las arquitecturas hiperconvergidas y desagregadas que elija en la Decisión 2. Ambas

Decisión 2: Determinar la arquitectura

La decisión arquitectónica divide el diseño en dos posibles vías. Determina la arquitectura de almacenamiento, el tamaño del clúster y las intenciones de red disponibles en el resto de este artículo.

Architecture Arquitectura de almacenamiento Escala típica Cuándo usarlo
Hiperconverged (HCI) NVMe/SSD/HDD local agrupados con Espacios de almacenamiento directo (S2D). Tráfico de almacenamiento a través de RDMA. 1–16 nodos, un solo bastidor o con reconocimiento de bastidor La mayoría de los despliegues. El cómputo y el almacenamiento escalan juntos.
Hiperconverged (HCI): variante de almacenamiento híbrido S2D además de una SAN externa en paralelo. Elija el tipo de almacenamiento por carga de trabajo. 1–16 nodos, bastidor único Un clúster hiperconvergido que también necesita volúmenes respaldados por SAN para cargas de trabajo específicas. Se conecta la SAN tras la implementación inicial; no se admite la función «rack-aware».
Desagregado (DA) SAN externo: Canal de fibra (FC) o SAN basado en IP. Sin S2D. El proceso y el almacenamiento se escalan de forma independiente. De 1 a 8 bastidores, hasta 16 nodos por bastidor y 64 nodos por clúster Ya utiliza almacenamiento SAN o necesita escalar la computación y el almacenamiento de forma independiente.

La arquitectura hiperconvergida también tiene una variante de almacenamiento híbrida opcional que ejecuta una SAN externa en paralelo con S2D para que pueda elegir el tipo de almacenamiento por carga de trabajo. Es una configuración exclusiva de hiperconvergencia que se agrega tras la implementación inicial. La decisión 5 abarca los detalles de diseño y las integraciones de almacenamiento externo admitidas.

Cada decisión de este marco documenta ambas arquitecturas en paralelo, con secciones independientes hiperconvergidas (HCI) y desagregadas (DA). Siga las decisiones de diseño para la arquitectura que ha elegido aquí.

Estas son las consideraciones resumidas para la decisión de arquitectura:

# Consideración Se aplica a
1 La arquitectura que elija determina la conectividad de almacenamiento, los puertos del adaptador de red y las intenciones de tráfico de red disponibles en pasos posteriores. Ambas
2 La hiperconvergida (HCI) admite una variante con reconocimiento de bastidor que extiende el clúster entre dos salas o zonas de disponibilidad, mientras que la desagregada (DA) escala entre varios bastidores. Defina el diseño físico en la Decisión 3. Ambas
3 Hyperconverged (HCI) usa Espacios de almacenamiento directo con unidades locales. Proceso y almacenamiento se escalan conjuntamente, hasta 16 nodos. HCI
4 El almacenamiento híbrido es una variante solo hiperconvergida: el clúster ejecuta S2D con una SAN externa en paralelo. Adjunte la SAN externa después de la implementación inicial (operación del día 2), no durante la primera implementación. HCI
5 Desagregado (DA) usa una SAN externa: Canal de Fibra (FC) o una SAN basada en IP, sin usar Espacios de almacenamiento directo. El proceso y el almacenamiento se escalan de forma independiente entre 1 y 8 bastidores, hasta 16 nodos por bastidor y 64 nodos por clúster. DA

Decisión 3: Determinación de la topología de clúster

La decisión sobre la topología del clúster define la disposición física de sus nodos y conmutadores. Las opciones disponibles dependen de la arquitectura elegida en la Decisión 2.

La forma física estándar para ambas arquitecturas es un único bastidor con un par de conmutadores de la parte superior del bastidor (ToR):

  • Un par de conmutadores ToR configurados con agregación de enlaces multichasis (MLAG), que admiten hasta 16 nodos en el mismo rack.
  • Un conmutador BMC (controlador de gestión de placa base) para la gestión fuera de banda por encima de los ToR.
  • Enlaces ascendentes al conmutador central, router o firewall existentes.

Hiperconverged (HCI)

Un clúster hiperconvergido utiliza un único bastidor o un diseño con reconocimiento de bastidor:

  • Bastidor único: todos los nodos y el par de conmutadores ToR están en un bastidor, admitiendo hasta 16 nodos. En el caso de los patrones modificados, todo el tráfico host (administración, proceso y almacenamiento) se ejecuta en el mismo par de conmutadores.

  • Con conocimiento de rack (dos zonas): un clúster con conocimiento de rack distribuye una implementación de infraestructura hiperconvergente entre dos salas o zonas de disponibilidad:

    • Un número par de nodos repartidos entre dos salas, hasta un máximo de 8 nodos, asignados a dos zonas de disponibilidad del clúster.
    • Se requiere menos de 1 ms de latencia entre salas para la replicación S2D.
    • El tráfico de almacenamiento RDMA permanece en la capa ToR y nunca atraviesa la columna vertebral.

    Hay cuatro opciones de enlace ascendente disponibles para clústeres con reconocimiento de bastidor:

    Option Topology Notas
    1. Vínculos de almacenamiento dedicados 2 ToR por habitación (4 totales) TOR1↔TOR3 en VLAN 711, TOR2↔TOR4 en VLAN 712.
    2. Vínculos de almacenamiento agregados 2 ToR por habitación (4 totales) El almacenamiento usa LAG/vPC entre salas; posible salto de red adicional y latencia de RDMA frente a la opción 1.
    3. Conectividad de nodos por sala 1 ToR por habitación (2 totales) Ambas redes de almacenamiento comparten el mismo ToR por sala; enlace entre salas agrupado.
    4. Conectividad entre nodos de distintas salas 1 ToR por habitación (2 totales) Cada máquina está conectada por cable a los ToR de ambas salas; reduce la dependencia entre ToR, pero aumenta el cableado.

Desagregado (DA)

Un clúster desagregado puede abarcar entre 1 y 8 bastidores:

  • Bastidor único: un par HSRP de dos conmutadores es suficiente hasta 16 nodos. Las redes de clúster se ejecutan en puertos de red independientes y no las administra Network ATC.
  • Varios bastidores: para más de 16 nodos, distribuya el clúster entre hasta 8 bastidores conectados mediante una topología leaf-spine (Clos): cada bastidor tiene dos conmutadores leaf de computación, con dos spines y dos conmutadores leaf de servicio sobre los bastidores. Cada bastidor contiene hasta 16 nodos y el clúster se escala a un máximo de 64 nodos. Solo se admite SDN basado en malla; no se admite SDN de Microsoft.

Para obtener más información sobre la arquitectura del tejido de columna de hoja, el flujo de tráfico y cómo elegir un patrón desagregado, consulte Introducción a los patrones de referencia de red para implementaciones desagregadas y Elegir un patrón de referencia de red para implementaciones desagregadas.

Estas son las consideraciones resumidas para la decisión de topología del clúster:

# Consideración Se aplica a
1 Un solo bastidor con un par de switches ToR puede alojar hasta 16 nodos para ambas arquitecturas. Ambas
2 Los clústeres hiperconvergentes de un solo bastidor canalizan todo el tráfico del host (administración, cómputo y almacenamiento) por el mismo par de switches ToR configurados con MLAG. No use un par de conmutadores de solo almacenamiento independiente. HCI
3 Los clústeres hiperconvergentes con reconocimiento de racks se extienden por dos salas o zonas de disponibilidad, con un número par de nodos, hasta un máximo de 8, y menos de 1 ms de latencia entre salas. Los clústeres con reconocimiento de rack no son compatibles con el almacenamiento SAN externo (híbrido). HCI
4 Para clústeres hiperconvergidos con reconocimiento de bastidor, elija una de las cuatro opciones de conexión ascendente. Los vínculos de almacenamiento dedicados (opción 1) mantienen el tráfico RDMA en la capa de ToR con la latencia más baja. HCI
5 Los clústeres desagregados abarcan entre 1 y 8 bastidores conectados por un tejido de columna de hoja (Clos), con hasta 16 nodos por bastidor y 64 nodos por clúster. DA
6 Para más de 16 nodos desagregados, use un tejido de columna de hoja en varios bastidores. Solo se admite SDN basada en fabric. DA

Decisión 4: Determinar el tamaño del clúster

Para ayudar a determinar el tamaño de su instancia de Azure Local, use la herramienta de dimensionamiento de Azure Local o la herramienta de dimensionamiento de la comunidad incluida en Odin para Azure Local, con la que puede definir su perfil, como el número de máquinas virtuales (VMs), el tamaño de las VMs y el tipo de carga de trabajo que ejecutan, como Azure Virtual Desktop, SQL Server o AKS.

Como se describe en el artículo sobre los requisitos de las máquinas de Azure Local, el número máximo de máquinas admitidas en una única instancia hiperconvergente (HCI) de Azure Local es 16. Las implementaciones desagregadas que usan una SAN externa pueden escalar hasta 64 nodos. Una vez completado el planeamiento de la capacidad de la carga de trabajo, debe tener una buena comprensión del número de nodos de máquina necesarios para ejecutar cargas de trabajo en su infraestructura.

Hiperconverged (HCI)

Un clúster hiperconvergido admite de 1 a 16 nodos. El número de nodos determina las opciones de conectividad de almacenamiento en la Decisión 5:

  • Si las cargas de trabajo requieren cuatro o más nodos con almacenamiento S2D: no puede usar una configuración sin conmutador para el tráfico de red de almacenamiento. Debe incluir un conmutador físico compatible con el acceso directo a memoria remota (RDMA) para controlar el tráfico de almacenamiento. Para más información sobre la arquitectura de red de instancia de Azure Local, consulte Introducción a los patrones de referencia de red.
  • Si las cargas de trabajo requieren cuatro o menos nodos: puede elegir configuraciones sin conmutador o conmutadas para la conectividad de almacenamiento. El almacenamiento sin conmutador es compatible con clústeres de 1 a 4 nodos.
  • Si planea escalar horizontalmente más adelante más allá de una configuración sin conmutadores: debe usar un conmutador físico para el tráfico de red de almacenamiento. Cualquier operación de escalado horizontal para implementaciones sin switches requiere configurar manualmente el cableado de red entre los nodos, cuya validación Microsoft no realiza activamente como parte de su ciclo de desarrollo de software para Azure Local.

Desagregado (DA)

Un clúster desagregado escala el proceso y el almacenamiento de forma independiente entre 1 y 8 bastidores, con hasta 16 nodos por bastidor y un máximo de 64 nodos por clúster. La capacidad de almacenamiento es independiente del número de nodos, ya que la SAN externa proporciona almacenamiento en lugar de por unidades locales.

Formas de implementación admitidas

La combinación de número de nodos y la opción de almacenamiento determina si se admite una forma de implementación y si requiere plantillas Resource Manager:

Nodes No hay conmutador de almacenamiento (S2D sin conmutadores) Conmutador de red para el almacenamiento (conmutado S2D) SAN externo (basado en FC o IP)
1 nodo ✅ (valor predeterminado) ✅ ✅
2 nodos ✅ (Azure Portal o plantillas ARM) ✅ ✅
3 nodos ✅ (solo plantillas de ARM) ✅ ✅
4 nodos ✅ (solo plantillas de ARM) ✅ ✅
5 a 16 nodos ❌ ✅ ✅
Más de 16 nodos (multibastidor) ❌ ❌ ✅

Estas son las consideraciones resumidas para la decisión de tamaño del clúster:

# Consideración Se aplica a
1 Los clústeres hiperconvergidos con más de 4 nodos que usan almacenamiento S2D requieren un conmutador físico para el tráfico de red de almacenamiento. HCI
2 Si tiene la intención de escalar horizontalmente el clúster mediante el orquestador, debe usar un conmutador físico para el tráfico de red de almacenamiento. HCI
3 Los clústeres desagregados escalan el proceso y el almacenamiento de forma independiente entre 1 y 8 bastidores, hasta 16 nodos por bastidor y 64 nodos por clúster. La capacidad de almacenamiento es independiente del recuento de nodos porque lo proporciona la SAN externa. DA

Decisión 5: Determinar la conectividad de almacenamiento

Como se describe en Requisitos de red física, las opciones de conectividad de almacenamiento dependen de la arquitectura elegida en la Decisión 2. A menos que los sobrescriba con plantillas de Resource Manager, todas las configuraciones de Espacios de almacenamiento directo (S2D) usan los siguientes valores predeterminados de Network ATC para el almacenamiento:

Red de almacenamiento VLAN predeterminado Subred predeterminada
Red de almacenamiento 1 711 10.71.1.0/24
Red de almacenamiento 2 712 10.71.2.0/24
Red de almacenamiento 3 (cuando está presente) 713 10.71.3.0/24

Hiperconverged (HCI)

Las implementaciones hiperconvergidas usan Espacios de almacenamiento directo con uno de los dos tipos de conectividad de almacenamiento:

  • Almacenamiento conmutado: Use un conmutador de red físico para gestionar el tráfico de almacenamiento. El almacenamiento conmutado admite de 1 a 16 nodos y admite el escalado horizontal.
  • Almacenamiento sin switches: Conecte directamente los nodos entre sí con cables de red cruzados o de fibra para el tráfico de almacenamiento. Solo se admite el almacenamiento sin conmutadores para clústeres de 1 a 4 nodos (un límite superior estricto) y no admite el escalado horizontal.

Las ventajas y desventajas de las opciones conmutadas y sin conmutador se documentan en el artículo vinculado anteriormente.

Solo puede decidir entre el almacenamiento conmutado y sin conmutador cuando el tamaño del clúster es de cuatro o menos nodos. Cualquier clúster S2D con más de cuatro nodos se implementa automáticamente mediante un conmutador de red para el almacenamiento.

Importante

Para las implementaciones hiperconvergentes conmutadas, haga pasar el tráfico de almacenamiento por el mismo par de conmutadores ToR que transporta el tráfico de administración y de computación. No se admite el uso de un par independiente de conmutadores dedicados exclusivamente al propósito de almacenamiento. Un par de conmutadores dedicados únicamente al almacenamiento, aislado de la red de administración y cómputo, puede dar lugar a una situación de división del clúster, ya que los nodos pueden perder la ruta de almacenamiento (este-oeste) mientras mantienen la ruta de administración, o a la inversa. Mantenga todas las intenciones en un único par de conmutadores ToR configurado por MLAG por bastidor.

Si los clústeres tienen cuatro o menos nodos, la decisión de conectividad de almacenamiento influye en el número y el tipo de intenciones de red que puede definir en la Decisión 7. Por ejemplo, para configuraciones sin conmutador, debe definir dos intenciones de tráfico de red. El tráfico de almacenamiento para la comunicación este-oeste mediante los cables cruzados no tiene conectividad norte-sur y está completamente aislado del resto de la infraestructura de red. Esto significa que debe definir una segunda intención de red para administrar la conectividad saliente y para las cargas de trabajo de proceso.

Aunque es posible definir cada intención de red con un solo puerto de adaptador de red físico, esto no proporciona ninguna tolerancia a errores. Por lo tanto, siempre se recomienda usar al menos dos puertos de red físicos para cada intención de red. Si decide usar un conmutador de red para el almacenamiento, puede agrupar todo el tráfico de red, incluido el almacenamiento en una única intención de red, que también se conoce como una configuración de red host hiperconvergente o totalmente convergente.

Planeación de IP de almacenamiento para clústeres sin conmutadores

Para el almacenamiento sin conmutador, el número de subredes de almacenamiento crece con el número de nodos, ya que cada nodo necesita una conexión directa a cada otro nodo. El número de subredes de almacenamiento es igual a N × (N − 1), donde N es el número de nodos:

Nodos sin conmutador Subredes de almacenamiento IP automática de almacenamiento
2 2 Admitido automáticamente
3 6 Deshabilitar la dirección IP automática de almacenamiento y definir todas las direcciones IP de almacenamiento en la plantilla de Resource Manager
4 12 Deshabilitar la dirección IP automática de almacenamiento y definir todas las direcciones IP de almacenamiento en la plantilla de Resource Manager

Para obtener más información sobre cómo definir direcciones IP de almacenamiento personalizadas, consulte Direcciones IP personalizadas para el almacenamiento.

Almacenamiento híbrido (S2D más SAN externo)

Azure Local admite la conexión de una SAN externa a un clúster hiperconvergido para que el almacenamiento respaldado por SAN funcione en paralelo con Espacios de almacenamiento directo (S2D). La SAN externa siempre se conecta en una operación posterior a la implementación (Day-2): primero se implementa un clúster hiperconvergido estándar con S2D y, a continuación, se conecta la SAN. No puede implementar una configuración híbrida desde el principio, por lo que debe planear el tejido de SAN y los adaptadores por adelantado aunque los conecte después de que se ejecute el clúster. Esto le permite elegir volúmenes S2D o SAN externos por carga de trabajo para máquinas virtuales, clústeres de AKS y Azure Virtual Desktop (AVD). Varios volúmenes SAN se presentan como volúmenes compartidos de clúster (CSV) formateados con NTFS, y cada CSV aparece como una ruta de carpeta que se asigna como ruta de almacenamiento para las máquinas virtuales. Hay dos integraciones disponibles con carácter general:

  • Cabinas SAN de Fibre Channel (FC): cada nodo se conecta a la SAN a través de dos redes Fibre Channel (Fabric A y Fabric B) para garantizar la redundancia, mediante adaptadores de bus de host (HBAs) en cada host. Los volúmenes respaldados por SAN se detectan como CSV NTFS y se comparten entre nodos, y el proceso y el almacenamiento se escalan de forma independiente.
  • SAN basado en IP (Ethernet): cada nodo se conecta a la matriz a través de la red de almacenamiento Ethernet(mediante un iniciador iSCSI estándar o un cliente de almacenamiento proporcionado por el proveedor) y monta volúmenes de bloques remotos en el clúster con E/S de múltiples rutas en tejidos redundantes. Los volúmenes se presentan como CSV NTFS y se comparten entre nodos, y el proceso y el almacenamiento se escalan de forma independiente. Estas soluciones suelen utilizar subredes de almacenamiento dedicadas, tramas jumbo y agrupación de NIC. Si esas subredes de almacenamiento son enrutables dependen de la arquitectura de red de almacenamiento: algunas implementaciones conectan hosts directamente a conmutadores de almacenamiento dedicados en subredes aisladas y no enrutables, mientras que otras enrutan el tráfico de almacenamiento desde la red del centro de datos. El número de nodos admitidos, los límites de escalado y la MTU exacta de la trama jumbo dependen del proveedor de almacenamiento y de la validación de Azure Local.

Desde el punto de vista del diseño de red:

  • La red de almacenamiento S2D no cambia desde la implementación original conmutada o sin conmutador.
  • La conectividad SAN usa redes SAN y adaptadores independientes (HBA de FC o NIC para SAN basadas en IP) y no está administrada por Network ATC. Planee puertos dedicados para la conectividad SAN y para el almacenamiento en bloque basado en IP, subredes de almacenamiento dedicadas con marcos jumbo (enrutables o no enrutables, en función de la arquitectura de red de almacenamiento).
  • Los clústeres con reconocimiento de bastidor no son compatibles con almacenamiento SAN externo para implementaciones hiperconvergentes.

Para obtener más información, consulte External storage support for Azure Local.

Desagregado (DA)

Cuando usa una SAN externa —Fibre Channel o una SAN basada en IP (por ejemplo, iSCSI o PowerFlex SDC)—, no hay Espacios de almacenamiento directo ni ninguna intención de almacenamiento RDMA administrada por Network ATC. En ambos casos:

  • El tráfico de administración y proceso se configura a través de Network ATC mediante un conmutador virtual Switch Embedded Teaming (SET).
  • Redes de clúster: volumen compartido de clúster (CSV) y tráfico de migración en vivo a través de SMB multicanal, se ejecutan en puertos de red independientes que no están administrados por Network ATC. Planee redes VLAN y subredes dedicadas para estas redes. Las VLAN de clúster predeterminadas son 1711 y 1712.
  • Configure la calidad del servicio Ethernet (QoS) para las redes de clúster. La decisión 6 describe la clase recomendada de esquema de prioridad de servicio (CoS) y la asignación de ancho de banda.

El tejido de almacenamiento difiere según el tipo de SAN:

  • Canal de fibra (FC): el almacenamiento se ejecuta completamente en el tejido FC, independiente de la red Ethernet. No se requiere QoS de almacenamiento Ethernet, control de flujo de prioridad (PFC) o Ethernet sin pérdida: todo el tráfico del clúster es TCP a través de SMB multicanal.
  • SAN basado en IP: el almacenamiento se ejecuta a través de adaptadores Ethernet dedicados para acceder a la SAN basada en IP. Reemplaza Espacios de almacenamiento directo y elimina RDMA y, dado que todo el tráfico (tráfico SAN basado en IP, CSV, migración en vivo y heartbeat del clúster) se transmite por TCP, no se requieren Ethernet sin pérdidas ni PFC. Compruebe que el modelo de matriz SAN se admite antes de implementarlo.

Las implementaciones de iSCSI siguen este patrón validado, que se elige en decisión 6:

  • Ruta de acceso dedicada de 6 puertos: los puertos dedicados llevan la ruta de acceso ISCSI A y la ruta de acceso B, independientes de las redes de clúster. Este patrón admite una red de copia de seguridad dedicada opcional.

Para obtener más información sobre cómo conectar una SAN externa, incluida la configuración del lado host y del lado matriz para el canal de fibra e iSCSI, consulte Conexión de una matriz de almacenamiento externa a Azure Local y compatibilidad con almacenamiento externo para Azure Local.

Rutas estáticas de host iSCSI

En el caso de las implementaciones iSCSI, solo la interfaz de administración tiene una puerta de enlace predeterminada. El clúster y las interfaces iSCSI tienen direcciones IP sin una puerta de enlace predeterminada. Para acceder a objetivos iSCSI que estén a uno o varios saltos de capa 3, configure en cada host una ruta estática persistente /32 para la IP de cada objetivo iSCSI, con el siguiente salto establecido en la puerta de enlace del switch leaf (interfaz virtual del switch) en la VLAN de iSCSI y la ruta asociada al adaptador de almacenamiento. Las rutas estáticas fuerzan el tráfico iSCSI fuera del adaptador de almacenamiento y impiden que se filtre en la red de administración. En una configuración de E/S de múltiples rutas (MPIO), cada ruta iSCSI necesita su propia ruta estática hacia los mismos destinos por su VLAN correspondiente. Si una cabina expone muchas direcciones IP de destino en la misma subred, puede enrutar toda la subred de destino a través de la puerta de enlace de la ruta correspondiente en lugar de agregar una ruta para cada destino. Configure el iniciador iSCSI, las rutas estáticas y MPIO durante la instalación del sistema operativo.

Nota

Con el almacenamiento SAN externo, no se usa Espacios de almacenamiento directo, por lo que las opciones de intención de almacenamiento que dependen de RDMA no están disponibles. Utilice la intención de administración y de cómputo, además de las redes del clúster independiente descritas anteriormente.

Direcciones IP personalizadas para el almacenamiento

De forma predeterminada, Network ATC asigna automáticamente las direcciones IP y VLAN para el almacenamiento de la tabla siguiente:

Adaptador de almacenamiento Dirección IP y subred Red de Área Local Virtual (VLAN)
pNIC1 10.71.1.x 711
pNIC2 10.71.2.x 712
pNIC3 10.71.3.x 713

Sin embargo, si los requisitos de implementación no se ajustan a esas direcciones IP y VLAN predeterminadas, puede usar sus propias direcciones IP, subredes y VLAN para el almacenamiento. Esta funcionalidad solo está disponible al implementar clústeres mediante plantillas de ARM y deberá especificar los parámetros siguientes en la plantilla:

  • enableStorageAutoIP: Cuando no se especifica este parámetro, se establece en true. Para habilitar direcciones IP de almacenamiento personalizadas durante la implementación, este parámetro debe establecerse falseen . La función Auto IP de almacenamiento es compatible con clústeres sin conmutador de 2 nodos; para clústeres sin conmutador de 3 y 4 nodos, debe establecer este parámetro en false y definir explícitamente todas las direcciones IP de almacenamiento.
  • storageAdapterIPInfo: Este parámetro tiene una dependencia con el enableStorageAutoIP parámetro y siempre es necesario cuando el parámetro IP automática de almacenamiento se establece en false. Dentro del parámetro storageAdapterIPInfo de la plantilla de ARM, también tendrá que especificar los parámetros ipv4Address y subnetMask para cada nodo y adaptador de red con sus propias direcciones IP y su máscara de subred.
  • vlanId: Como se describe en la tabla anterior, este parámetro usa las VLAN predeterminadas de ATC de red si no es necesario cambiarlas. Sin embargo, si esas VLAN predeterminadas no funcionan en la red, puede especificar sus propios identificadores de VLAN para cada una de las redes de almacenamiento.

La siguiente plantilla de ARM incluye un ejemplo de una instancia de Azure Local de dos nodos con un conmutador de red para el almacenamiento, donde las direcciones IP de almacenamiento se personalizan: 2 nodos implementación con direcciones IP de almacenamiento personalizadas.

Estas son las consideraciones resumidas para la decisión de conectividad de almacenamiento:

# Consideración Se aplica a
1 La configuración sin conmutadores a través del portal de Azure se admite para clústeres de 1 o 2 nodos. Solo se pueden implementar clústeres sin conmutadores de almacenamiento de 3 y 4 nodos mediante plantillas de Resource Manager. HCI
2 Las operaciones de escalado horizontal no son compatibles con implementaciones sin conmutadores. Cualquier cambio en el número de nodos después de la implementación requiere una configuración manual. HCI
3 El conmutador de red para el almacenamiento se puede usar con cualquier número de nodos de 1 a 16, y una única intención puede llevar todos los tipos de tráfico. HCI
4 En las implementaciones hiperconvergidas, la configuración de almacenamiento debe compartir el mismo par de conmutadores ToR que la administración y el cómputo. No se admite un par de conmutadores dedicados únicamente al almacenamiento y puede provocar una situación de split-brain en el clúster. HCI
5 Desagregado (DA) utiliza una SAN externa —Fibre Channel (FC) o SAN basada en IP (por ejemplo, iSCSI o PowerFlex SDC)— para conectar el clúster al almacenamiento externo. No hay Espacios de almacenamiento directo y el proceso y el almacenamiento se escalan de forma independiente hasta 64 nodos. DA
6 Las implementaciones iSCSI usan este patrón: una ruta de acceso dedicada de 6 puertos (puertos iSCSI dedicados, red de copia de seguridad opcional). DA
7 iSCSI requiere rutas estáticas de host /32 para cada destino y MPIO para que el tráfico de almacenamiento se mantenga en el adaptador de almacenamiento. iSCSI se ejecuta a través de TCP, por lo que PFC y Ethernet sin pérdida no son necesarios. DA

Decisión 6: Determinar los puertos y la configuración del adaptador de red

Los adaptadores de red están calificados por el tipo de tráfico de red (administración, proceso y almacenamiento) con los que se usan. Trabaje con el OEM para determinar qué adaptadores están disponibles y calificados para cada intención (administración, proceso y almacenamiento) en el hardware.

Antes de comprar una máquina para Azure Local, debe tener al menos dos adaptadores que estén calificados para la administración, el proceso y el almacenamiento, ya que los tres tipos de tráfico son necesarios en Azure Local. La implementación en la nube se basa en Network ATC para configurar los adaptadores de red para los tipos de tráfico adecuados, por lo que es importante usar adaptadores de red compatibles.

Una vez instalado el sistema operativo y antes de configurar las redes en los nodos, debe asegurarse de que los adaptadores de red tengan el controlador más reciente suministrado por el proveedor de interfaz de red o OEM. Es posible que funciones importantes de los adaptadores de red no estén disponibles al usar los controladores predeterminados de Microsoft.

Los valores predeterminados usados por Network ATC se documentan en Configuración de red del clúster. Se recomienda utilizar los valores predeterminados. Dicho esto, las siguientes opciones se pueden anular mediante el portal de Azure o las plantillas de Resource Manager, si es necesario:

  • VLAN de almacenamiento: defina este valor en las VLAN necesarias para el almacenamiento.
  • Paquetes Jumbo: define el tamaño de los paquetes jumbo. Se recomienda una unidad de transmisión máxima (MTU) de 9216 bytes para el tráfico de almacenamiento RDMA. Configure la misma MTU en los conmutadores físicos. Para los fabrics de almacenamiento SAN externos (híbridos o desagregados), la MTU requerida para tramas jumbo depende del proveedor de almacenamiento y puede diferir del valor de S2D; por ejemplo, 9216 bytes para fabrics de almacenamiento RDMA y un valor especificado por el proveedor (como 9014 bytes) para las redes de almacenamiento por bloques basadas en IP. Use la MTU especificada por el proveedor de almacenamiento y configure el mismo valor de extremo a extremo entre hosts y conmutadores.
  • Red directa: establezca este valor false en si desea deshabilitar RDMA para los adaptadores de red.
  • Tecnología directa de red: defina este valor como RoCEv2 o iWarp.
  • Prioridades de tráfico para el puente del centro de datos (DCB): establezca las prioridades que se ajusten a sus requisitos. Le recomendamos encarecidamente que use los valores predeterminados de DCB, ya que han sido validados por Microsoft y por sus clientes.

Hiperconverged (HCI)

Las implementaciones hiperconvergidas usan 2, 4, 6 o 8 puertos de adaptador de red por nodo, en función de cómo se agrupa el tráfico en intenciones en la Decisión 7. La velocidad de cada puerto y la funcionalidad RDMA deben coincidir con el tráfico que lleva:

  • 2 puertos: una única intención de Agrupar todo el tráfico. SET agrupa los dos primeros adaptadores físicos (por ejemplo, pNIC01 y pNIC02). Todos los tipos de tráfico comparten los mismos puertos. Requiere un mínimo de 10 Gb; Se recomienda 25 GbE o superior.
  • 4 puertos: una intención de administración y proceso en Port1 y Port2 (SET) más una intención de almacenamiento dedicada en Port3 y Port4. La configuración de almacenamiento no usa SET; usa SMB multicanal para ofrecer resiliencia y agregación de ancho de banda.
  • 6 puertos: intenciones independientes de Administración (Puerto1 y Puerto2, SET), Cómputo (Puerto3 y Puerto4, SET) y Almacenamiento (Puerto5 y Puerto6, SMB Multicanal).
  • 8 puertos: agregue una segunda intención de proceso o copia de seguridad en los puertos restantes para la separación de tráfico adicional.

En el caso de los patrones conmutados, los modificadores ToR deben cumplir los requisitos del conmutador físico. En el caso de los patrones sin conmutadores, los adaptadores de almacenamiento forman una malla directa de nodo a nodo, por lo que no se necesitan modificadores de almacenamiento; cada subred de almacenamiento requiere una VLAN única y el recuento de subredes crece según se describe en la Decisión 5.

Desagregado (DA)

Las implementaciones desagregadas usan un diseño de puerto Ethernet que depende del tipo SAN. Defina el diseño por el número de puertos de red y el rol de cada puerto, no por el factor de forma del adaptador físico. En todos los casos, dos puertos de red transportan la intención de administración y cómputo (un equipo de conmutación integrada SET administrado por Network ATC), y otro par independiente de puertos de red transporta las redes del clúster —heartbeat del clúster, Volumen compartido de clúster (CSV) y migración en vivo mediante SMB Multichannel— como puertos independientes no administrados por Network ATC. Cómo se distribuyen estos puertos entre adaptadores físicos es una opción oem: pueden proceder de un único adaptador de varios puertos (como un OCP de cuatro puertos), de dos adaptadores independientes (por ejemplo, un OCP incorporado más un adaptador de complemento) o de dos adaptadores incorporados. Las VLAN de clúster predeterminadas son 1711 y 1712. Cada clúster independiente y puerto de almacenamiento lleva una sola VLAN, por lo que puede establecer esa VLAN como VLAN de acceso (nativa) en el puerto ToR y dejar la interfaz de host sin etiquetar, consulte QoS de clúster y almacenamiento. Para obtener el conmutador completo, el cableado y el diseño del puerto para cada tipo SAN, consulte los patrones de referencia de red desagregados.

Canal de fibra (FC)

Las implementaciones de FC usan un diseño Ethernet de 4 puertos o 6 puertos por nodo. Cada servidor también utiliza adaptadores de bus de host FC (HBA) de doble puerto (puerto A al conmutador FC A, puerto B al conmutador FC B) para la conectividad SAN, separada de los puertos de red Ethernet:

  • 4 puertos: administración y proceso en los puertos de red 1 y 2 (SET) y redes de clúster en puertos de red independientes 3 y 4.
  • 6 puertos (copia de seguridad de invitados): idéntico al diseño de 4 puertos, más una intención de proceso para copia de seguridad de invitados en los puertos de red 5 y 6 (SET) para el tráfico de copia de seguridad de invitados. Para obtener más información, consulte la Decisión 9.

iSCSI

Las implementaciones iSCSI usan este patrón validado. Los adaptadores de almacenamiento deben tener al menos 10 GbE (25 GbE o superior para cargas de trabajo de alto rendimiento):

  • Ruta de acceso dedicada de 6 puertos: dos puertos de red para administración y proceso (SET), dos puertos de red independientes para las redes de clúster (VLAN 1711 y 1712) y dos puertos de red independientes para la ruta de acceso iSCSI dedicada A (VLAN 300) y la ruta de acceso B (VLAN 400). Este patrón admite una red de copia de seguridad opcional, como se describe en la Decisión 9.

QoS de clúster y almacenamiento

Todo el almacenamiento desagregado y el tráfico del clúster circulan por TCP: SMB Multicanal para las redes del clúster (CSV, migración en vivo y latidos) e iSCSI sobre TCP para el tráfico de almacenamiento. TCP gestiona la congestión y se recupera de las pérdidas mediante sus propios mecanismos de retransmisión y control de congestión, por lo que este diseño no necesita Ethernet sin pérdidas ni conformación del tráfico en el host. No configure lo siguiente en el clúster y los puertos de almacenamiento:

  • Control de flujo de prioridad (PFC) o colas sin pérdida. PFC proporciona comunicación sin pérdidas para RDMA/RoCE, que no se utiliza en los despliegues desagregados. En un tejido TCP, PFC añade riesgo operativo —propagación de pausas, bloqueo en cabecera de línea y flujos perjudicados— sin ningún beneficio.
  • Puente del centro de datos del lado host (DCB) o selección de transmisión mejorada (ETS). La ETS del host y la clase de servicio (CoS) 802.1p son mecanismos de salto a salto de capa 2. Influyen solo en el vínculo de host a hoja y sus garantías de ancho de banda no se extienden a través del tejido.

Importante

En una implementación multirrack con arquitectura leaf-spine, el tráfico del clúster y de almacenamiento entre racks se enruta en la capa 3 a través de la superposición VXLAN EVPN. El CoS de 802.1p que un host establece solo reside dentro de la etiqueta VLAN 802.1Q, por lo que se descarta cuando una hoja enruta y encapsula el marco, la programación de conmutadores de columna en el encabezado de paquete externo, no el CoS del host. Por lo tanto, el ETS del host no puede proteger el tráfico de iSCSI o de clúster frente a la congestión de spine o incast, y configurarlo da una falsa sensación de protección.

Para mantener el tráfico de clúster y almacenamiento en buen estado en todo el tejido:

  • Diseñe la infraestructura para la escalabilidad. Cree la arquitectura leaf-spine con poca o ninguna sobresuscripción, dimensione los enlaces ascendentes de la capa spine para los picos de tráfico de almacenamiento y mantenga el tráfico de almacenamiento y el del clúster en puertos dedicados cuando la disposición de puertos lo permita. Combinado con el control de congestión TCP, esta es la protección principal para el tráfico entre racks.

Nota

En un clúster desagregado de un solo bastidor (Capa 2 en un único par de ToR), o en un enlace ascendente convergente del host que transporta varios tipos de tráfico, el ETS del host sigue funcionando en ese enlace local y puede evitar que el tráfico masivo de CSV o de Live Migration deje sin recursos al latido del clúster. Cuando se usan puertos dedicados para el clúster y las redes de almacenamiento, tal como recomiendan las configuraciones de varios bastidores, hay poco que arbitrar en esos enlaces, por lo que omitir ETS en el host tiene un efecto insignificante. Eliminar ETS del host en todo el sistema es una simplificación deliberada para la infraestructura enrutada basada en TCP.

Las tramas jumbo siguen mereciendo la pena y son independientes de la decisión anterior sobre QoS, ya que los puertos del clúster transportan tráfico CSV y de migración en vivo mediante SMB, es decir, transferencias masivas que se benefician de usar menos paquetes y de mayor tamaño. No es necesario configurarlos manualmente: Azure Local aplica a los adaptadores de host la MTU de tramas jumbo que especifique en el portal de Azure o en la plantilla ARM durante la implementación, por lo que no es necesario ejecutar comandos del adaptador en los nodos. Debe configurar la misma MTU en los puertos del conmutador físico usted mismo, ya que Azure Local no configura los conmutadores: un emparejamiento común es MTU 9000 en el host y 9216 en el conmutador.

Dado que no hay ningún QoS de host, el clúster independiente y los puertos de almacenamiento no necesitan conservar ninguna prioridad de 802.1p y cada uno de estos puertos solo tiene una sola VLAN. Por lo tanto, puede establecer esa VLAN como VLAN de acceso (nativa) en el puerto ToR y dejar la interfaz de host sin etiquetar; no se necesita ningún etiquetado de VLAN en los hosts:

  • Redes de clúster: configure los dos puertos de clúster en las VLAN de clúster (por ejemplo, 1711 y 1712).
  • iSCSI, ruta de acceso dedicada de 6 puertos: establezca los dos puertos iSCSI dedicados en sus VLAN de almacenamiento (por ejemplo, 300 y 400).

Los puertos de administración y de proceso son independientes: permanecen en el conjunto SET administrado por Network ATC y se configuran como trunk si transportan más de una VLAN. Siga las instrucciones del proveedor de almacenamiento para conocer los requisitos adicionales.

Requisitos de conmutador físico

En el caso de las implementaciones conmutadas (hiperconvergidas) y desagregadas, los conmutadores físicos de la parte superior del bastidor (ToR) deben admitir las siguientes funcionalidades para llevar el tráfico del clúster de forma confiable:

  • Control de flujo de prioridad (PFC) para el tráfico RDMA sin pérdida (IEEE 802.1Qbb).
  • Selección mejorada de transmisión (ETS) para la asignación de ancho de banda entre clases de tráfico (IEEE 802.1Qaz).
  • Tramas jumbo con una MTU de al menos 9216 bytes.
  • Notificación de congestión explícita (ECN) para implementaciones de RoCEv2.
  • Agregación de enlaces multichasis (MLAG) para pares ToR redundantes.

Nota

Las funcionalidades PFC, ETS y ECN se aplican a las implementaciones hiperconvergidas conmutadas (RDMA). Las implementaciones desagregadas transportan todo el tráfico de almacenamiento y del clúster a través de TCP, por lo que no requieren PFC, Ethernet sin pérdidas ni ETS en hosts y conmutadores. Confíe en una capacidad suficiente de la red y en el control de congestión de TCP. El tejido desagregado todavía necesita marcos jumbo, MLAG o canal de puerto virtual (vPC) y compatibilidad con VLAN compatible con MPIO con enrutamiento estático para iSCSI.

Estas son las consideraciones resumidas para la decisión de configuración del adaptador de red:

# Consideración Se aplica a
1 Use las configuraciones predeterminadas de Network ATC tanto como sea posible. Ambas
2 Los conmutadores físicos deben configurarse según la configuración del adaptador de red. Consulte Requisitos de red física para Azure Local. Ambas
3 Trabaje con el OEM para determinar qué adaptadores de red se admiten y califican para cada intención en Azure Local. La lista admitida está más restringida que el catálogo de Windows Server. Ambas
4 Se requieren al menos interfaces de red de 10 Gbps para admitir el tráfico de almacenamiento RDMA o iSCSI. Se recomienda 25 GbE o superior. Ambas
5 Al aceptar los valores predeterminados, Network ATC configura automáticamente las direcciones IP y VLAN del adaptador de red de almacenamiento (IP automática de almacenamiento). En algunos casos, no se admite la dirección IP automática de almacenamiento y debe declarar cada dirección IP del adaptador de red de almacenamiento mediante plantillas de Resource Manager. HCI
6 El almacenamiento desagregado y el tráfico de clúster se ejecutan a través de TCP, por lo que no es necesario el control de flujo de prioridad (PFC) ni el ETS/DCB del lado host. El ETS del host solo afecta al enlace entre el host y el leaf y no se aplica en toda la malla leaf-spine enrutada; dimensione la capacidad de la malla para proteger el tráfico entre racks. DA
7 Dado que las implementaciones desagregadas no usan QoS de host, cada clúster independiente y puerto de almacenamiento lleva una sola VLAN y puede usar una VLAN de acceso (nativa) en la ToR, por ejemplo, 1711 y 1712 para las redes de clúster y 300 y 400 para iSCSI dedicado, por lo que las interfaces de host no necesitan etiquetas VLAN. DA

Decisión 7: Determinar las intenciones de tráfico de red

Para Azure Local, todas las implementaciones dependen de Network ATC para la configuración de red host. Las intenciones de red se configuran automáticamente al implementar Azure Local a través de Azure Portal. Para obtener más información sobre las intenciones de red y cómo solucionar problemas, consulte Comandos de ATC de red comunes.

En esta sección se explican las implicaciones de la decisión de diseño para las intenciones de tráfico de red. Las opciones disponibles dependen de la arquitectura, el número de nodos del clúster y el tipo de conectividad de almacenamiento usado.

Nota

Network ATC crea conmutadores virtuales SET para la administración y el tráfico de proceso. El tráfico de almacenamiento en implementaciones de S2D usa SMB Multicanal y no se sitúa detrás de un conmutador SET.

Hiperconverged (HCI)

En el caso de las implementaciones hiperconvergidas, puede seleccionar entre cuatro opciones para agrupar el tráfico de red en una o varias intenciones.

Intención de red: agrupar todo el tráfico

Network ATC configura una intención única que incluye el tráfico de red de administración, proceso y almacenamiento. Los adaptadores de red asignados a esta intención comparten ancho de banda y rendimiento para todo el tráfico de red.

  • Esta opción requiere un conmutador físico para el tráfico de almacenamiento. Si necesita una arquitectura sin conmutador, no puede usar este tipo de intención. El portal de Azure filtra automáticamente esta opción si selecciona una configuración sin conmutador para la conectividad de almacenamiento.
  • Se recomienda al menos dos puertos de adaptador de red para garantizar la alta disponibilidad.
  • Se requieren interfaces de red de al menos 10 Gbps para soporte al tráfico RDMA para almacenamiento. Se recomienda 25 GbE o superior.

Intención de red: administración de grupos y tráfico de proceso

Network ATC configura dos intenciones. La primera intención incluye la administración y el tráfico de red de proceso, y la segunda intención incluye solo el tráfico de red de almacenamiento. Cada intención debe tener un conjunto diferente de puertos de adaptador de red.

Puede usar esta opción para la conectividad de almacenamiento conmutada y sin conmutador, si:

  • Hay al menos dos puertos de adaptador de red disponibles para cada intención para garantizar la alta disponibilidad.
  • Se usa un conmutador físico para RDMA si usa el conmutador de red para el almacenamiento.
  • Se requieren interfaces de red de al menos 10 Gbps para soporte al tráfico RDMA para almacenamiento.

Intención de red: administración de grupos y tráfico de proceso

Network ATC configura dos intenciones. La primera intención incluye el proceso y el tráfico de red de almacenamiento, y la segunda intención incluye solo la administración del tráfico de red. Cada intención debe usar un conjunto diferente de puertos de adaptador de red.

  • Esta opción requiere un conmutador físico para el tráfico de almacenamiento, ya que los mismos puertos se comparten con el tráfico de proceso, lo que requiere comunicación norte-sur. Si necesita una configuración sin conmutador, no puede usar este tipo de intención. El portal de Azure filtra automáticamente esta opción si selecciona una configuración sin conmutador para la conectividad de almacenamiento.
  • Esta opción requiere un conmutador físico para RDMA.
  • Se recomienda al menos dos puertos de adaptador de red para garantizar la alta disponibilidad.
  • Se recomiendan interfaces de red de al menos 10 Gbps para la intención de proceso y almacenamiento para soporte al tráfico RDMA.
  • Incluso cuando la intención de administración se declara sin una intención de proceso, Network ATC crea un conmutador virtual Switch Embedded Teaming (SET) para proporcionar alta disponibilidad a la red de administración.

Intención de red: configuración personalizada

Defina hasta tres intenciones con su propia configuración siempre que al menos una de las intenciones incluya tráfico de administración. Se recomienda usar esta opción cuando necesite una segunda intención de proceso. Los escenarios para este segundo requisito de intención de proceso incluyen el tráfico de almacenamiento remoto, el tráfico de copia de seguridad de máquinas virtuales o una intención de proceso independiente para distintos tipos de cargas de trabajo.

  • Use esta opción para la conectividad de almacenamiento conmutada y sin conmutador si la intención de almacenamiento es diferente de las otras.
  • Use esta opción cuando se requiera otra intención de proceso o cuando desee separar completamente los distintos tipos de tráfico a través de diferentes adaptadores de red.
  • Use al menos dos puertos de adaptador de red para cada intención para garantizar la alta disponibilidad.
  • Se recomiendan interfaces de red de al menos 10 Gbps para la intención de proceso y almacenamiento para soporte al tráfico RDMA.

Desagregado (DA)

En el caso de las implementaciones desagregadas, la matriz de almacenamiento se alcanza a través del canal de fibra o iSCSI, por lo que no hay ninguna intención de almacenamiento RDMA. Usa lo siguiente:

  • Una intención de administración y cómputo configurada a través de Network ATC mediante un conmutador virtual SET.
  • Redes de clúster (heartbeat del clúster, CSV y migración en directo a través de SMB Multichannel) que se ejecutan en puertos de red dedicados fuera de Network ATC, como se describe en la Decisión 5.
  • En el caso de iSCSI, las rutas de acceso iSCSI son puertos independientes que network ATC no administra. Están asignados a la configuración de 6 puertos.
  • Una opción opcional de copia de seguridad de invitado cuando se utiliza el diseño de 6 puertos (FC) o el diseño de ruta dedicada de 6 puertos (iSCSI), tal como se describe en la Decisión 9.

Agrupaciones de intenciones admitidas

En la tabla siguiente se resumen las agrupaciones de intenciones que se admiten para cada opción de conectividad de almacenamiento:

Agrupación de intenciones S2D sin conmutador S2D conmutado SAN externo (basado en FC o IP)
Agrupar todo el tráfico (administración, proceso, almacenamiento) ❌ ✅ ❌
Administración y proceso de grupos, almacenamiento independiente ✅ ✅ ❌
Agrupar cómputo y almacenamiento, gestión independiente ❌ ✅ ❌
Configuración personalizada (hasta tres intenciones) ✅ ✅ ❌
Administración y proceso, además de redes de clúster no administradas por Network ATC ❌ ❌ ✅

Estas son las consideraciones resumidas para la decisión de intenciones de tráfico de red:

# Consideración Se aplica a
1 Use al menos dos puertos de adaptador de red por intención para garantizar la alta disponibilidad. Ambas
2 Los clústeres hiperconvergidos sin conmutador requieren al menos dos intenciones (administración y proceso, además de almacenamiento). HCI
3 Las opciones Agrupar todo el tráfico y Agrupar cómputo y almacenamiento requieren un conmutador físico para almacenamiento y no están disponibles para clústeres sin conmutadores. HCI
4 Las implementaciones desagregadas usan una intención de administración y de cómputo, además de redes de clúster que funcionan fuera de Network ATC. DA
5 En el caso de iSCSI, las rutas de acceso iSCSI son puertos independientes y dedicados fuera de Network ATC DA

Decisión 8: Determinar las direcciones IP de administración y la red de infraestructura

En esta decisión, definirá el espacio de direcciones de subred de infraestructura, cómo se asignan estas direcciones al clúster y si hay algún requisito de identificador de VLAN para los nodos. Esta decisión se aplica tanto a las arquitecturas hiperconvergidas como desagregadas.

Los siguientes componentes de subred de infraestructura deben planearse y definirse antes de iniciar la implementación para que pueda prever cualquier requisito de enrutamiento, firewall o subred.

Rangos de IP reservados para evitar

Al implementar Azure Local, la plataforma reserva dos bloques CIDR internos de Kubernetes: 10.96.0.0/12 para los servicios de Kubernetes y 10.244.0.0/16 para la red de pods. El plano de control Azure Resource Bridge (ARB) se ejecuta en esta plataforma interna de Kubernetes y los clústeres de Azure Kubernetes Service (AKS) que implemente usan los mismos intervalos. Si alguna Azure Local configuración se superpone a estos intervalos, la implementación podría producir un error o experimentar problemas de conectividad difíciles de solucionar.

Dado que 10.96.0.0/12 es la red interna de Kubernetes Service de la plataforma, no hay ninguna dirección IP de infraestructura de Azure Local y ninguno de los servicios de infraestructura principales que el clúster debe alcanzar, como DNS y proxy, puede estar dentro de ella. Desde los nodos y las máquinas virtuales de infraestructura, cualquier tráfico enviado a una dirección en 10.96.0.0/12 se controla internamente y nunca llega al destino real. Planee lo siguiente para que se siten fuera 10.96.0.0/12de :

  • Las IP de los nodos del clúster y la IP del clúster.
  • La máquina virtual de Azure Resource Bridge y las direcciones IP de las otras máquinas virtuales de infraestructura, junto con el grupo de direcciones IP de administración del que se obtienen.
  • Los servidores DNS y el servidor proxy que usa la infraestructura.

El 10.244.0.0/16 rango de pods tiene la misma restricción: cualquier IP de infraestructura, IP de nodo o red lógica que coloque en él entra en conflicto con la red de pods.

Si implementa AKS en Azure Local, los mismos intervalos reservados agregan dos requisitos más para las cargas de trabajo de AKS:

  • La red lógica de AKS no puede superponerse a los intervalos reservados. La red lógica (LNET) en la que se implementan clústeres de AKS no debe superponerse 10.96.0.0/12 (servicios de Kubernetes) ni 10.244.0.0/16 (pods).
  • AKS no puede acceder a puntos de conexión privados dentro de 10.96.0.0/12. Cualquier punto de conexión privado en el que se basan las cargas de trabajo de AKS(por ejemplo, Azure Container Registry, Azure Key Vault o puntos de conexión de Azure Storage) no debe tener una dirección IP dentro de 10.96.0.0/12. Desde una máquina virtual del plano de control de AKS o un nodo de trabajo, ese intervalo es la red interna de Kubernetes Service, por lo que el tráfico a cualquier dirección de ella se controla internamente y nunca llega al punto de conexión real. Si el entorno ya coloca puntos de conexión privados u otros servicios a los que AKS debe llegar en ese espacio, muévalos antes de implementar AKS.

Los rangos CIDR de servicio y de pod no se pueden cambiar actualmente, así que planifique la red para evitar estos rangos en lugar de esperar poder cambiarlos. Más allá de la infraestructura de Azure Local, de los puntos de conexión a los que debe llegar y de AKS, estos rangos no reservan ni restringen el resto del espacio de direcciones de su centro de datos; solo los servicios a los que se conecta el propio clúster no deben solaparse con ellos. Para conocer los requisitos completos de planificación de direcciones de AKS, incluidas las implementaciones en varios racks, consulte Planificar direcciones IP para AKS en Azure Local.

Intervalos reservados que se deben evitar

La plataforma de Kubernetes (que usa Arc Resource Bridge y AKS) reserva internamente los siguientes intervalos IP y no se debe usar para ningún componente de infraestructura de Azure Local:

Intervalo reservado Para qué se usa
10.96.0.0/12 Servicios internos de Kubernetes (Cluster IPs)
10.244.0.0/16 Redes de pods de Kubernetes

Qué comprobar antes de la implementación

Asegúrese de que ninguna de las siguientes direcciones IP de infraestructura local de Azure se encuentra dentro de los intervalos reservados anteriores:

Compruebe esto Ejemplo de un problema
Las IPs de gestión de tus nodos. Nodo en 10.244.1.50 conflictúa con la red de pods
Dirección IP del clúster La dirección IP del clúster en 10.96.0.5 no se puede acceder desde los nodos
La máquina virtual de Azure Resource Bridge y el grupo de direcciones IP de infraestructura El conjunto que comienza en 10.100.0.1 se encuentra dentro de 10.96.0.0/12
Direcciones IP del servidor DNS DNS en 10.96.1.10 conflictaría
Dirección IP del servidor proxy El servidor proxy en 10.97.10.25 entraría en conflicto
La puerta de enlace predeterminada La puerta de enlace en 10.96.0.1 podría entrar en conflicto.
Todas las redes lógicas de las máquinas virtuales La subred de VM 10.244.100.0/24 se superpone con la red de pods

Intervalos IP seguros para usar

Estos son ejemplos de intervalos IP privados usados habitualmente que no entran en conflicto:

Rango seguro Notas
192.168.x.x Más común para implementaciones pequeñas
172.16.x.x a 172.31.x.x Bueno para redes medianas
10.0.x.x a 10.95.x.x Seguro: permanece por debajo del límite reservado 10.96.0.0 .
10.112.x.x y versiones posteriores Seguro: por encima del límite reservado 10.111.255.255

Referencias de planeamiento de IP

Grupo de direcciones IP de administración

Al realizar la implementación inicial de la instancia local de Azure, debe definir un intervalo IP de direcciones IP consecutivas para los servicios de infraestructura implementados de forma predeterminada.

Para garantizar que el intervalo tiene suficientes direcciones IP para los servicios de infraestructura actuales y futuros, debe usar un intervalo de al menos seis direcciones IP disponibles consecutivas. Estas direcciones se usan para la dirección IP del clúster, la máquina virtual del puente de recursos de Azure y sus componentes.

Si prevé ejecutar otros servicios en la red de infraestructura, se recomienda asignar un búfer adicional de direcciones IP de infraestructura al grupo. Es posible agregar otros grupos de direcciones IP después de la implementación de la red de infraestructura mediante PowerShell si el tamaño del grupo que planeó se agota originalmente.

Durante el despliegue, el verificador del entorno comprueba la conectividad ICMP desde las direcciones del grupo de direcciones IP de administración hasta la puerta de enlace predeterminada del grupo de direcciones IP de administración. Asegúrese de que la puerta de enlace predeterminada permite el tráfico ICMP desde la subred de administración de Azure Local.

Estas son las consideraciones resumidas para el grupo de direcciones IP de administración:

# Consideración Se aplica a
1 El intervalo IP debe usar direcciones IP consecutivas y todas las direcciones IP deben estar disponibles dentro de ese intervalo. Este intervalo IP no se puede cambiar después de la implementación. Ambas
2 El intervalo de direcciones IP no debe incluir las direcciones IP de administración de nodos de clúster, pero debe estar en la misma subred que los nodos. Ambas
3 La puerta de enlace predeterminada definida para el grupo de direcciones IP de administración debe proporcionar conectividad de salida a Internet. Ambas
4 Los servidores DNS deben garantizar la resolución de nombres con Active Directory e Internet. Ambas
5 Las direcciones IP de administración requieren acceso de salida a Internet. Ambas
6 El comprobador de entorno valida que el tráfico ICMP responde en la puerta de enlace predeterminada desde el rango de direcciones IP de administración local de Azure. Ambas

ID de VLAN de gestión

Se recomienda que la subred de administración de la instancia local de Azure use la VLAN predeterminada, que en la mayoría de los casos se declara como identificador 0 de VLAN. Sin embargo, si los requisitos de su red exigen usar una VLAN de administración específica para su red de infraestructura, esta debe configurarse en los adaptadores de red físicos que tiene previsto usar para el tráfico de administración.

Si tiene previsto usar dos adaptadores de red físicos para la administración, debe definir la VLAN en ambos adaptadores. Esto debe hacerse como parte de la configuración de arranque (bootstrap) de las máquinas y, antes de que se registren en Azure Arc, para asegurarse de registrar correctamente los nodos mediante esta VLAN.

Para establecer el identificador de VLAN en los adaptadores de red físicos, use el siguiente comando de PowerShell. En este ejemplo se configura el identificador de VLAN 44 en el adaptador NIC1de red físico:

Set-NetAdapter -Name "NIC1" -VlanID 44

Una vez establecido el id. de VLAN y las direcciones IP de los nodos se configuran en los adaptadores de red físicos, el orquestador lee este valor de id. de VLAN del adaptador de red físico que se usa para la administración y lo almacena, por lo que se puede usar para la máquina virtual de Azure Resource Bridge o cualquier otra máquina virtual de infraestructura necesaria durante la implementación. No es posible establecer el identificador de VLAN de administración durante la implementación en la nube desde el portal de Azure, ya que esto conlleva el riesgo de interrumpir la conectividad entre los nodos y Azure si las VLAN del conmutador físico no se enrutan correctamente.

Planee cuidadosamente el identificador de VLAN de administración, ya que no se puede cambiar después de la implementación. El identificador de VLAN de administración también lo hereda la máquina virtual del puente de recursos de Azure y las otras máquinas virtuales de infraestructura, por lo que también se aplica a ellas. No se admite cambiar el identificador de VLAN de la red de infraestructura después de la implementación, ya que interrumpiría la conectividad entre los nodos, los servicios de infraestructura y Azure.

Id. de VLAN de administración con un conmutador virtual

En algunos escenarios, es necesario crear un conmutador virtual antes de que se inicie la implementación.

Nota

Antes de crear un conmutador virtual, asegúrese de habilitar el rol de Hyper-V. Para obtener más información, consulte Instalación del rol de Windows necesario.

Si se requiere una configuración de conmutador virtual y debe usar un identificador de VLAN específico, siga estos pasos.

  1. Cree el conmutador virtual con la convención de nomenclatura recomendada.

    Las implementaciones locales de Azure dependen de Network ATC para crear y configurar los conmutadores virtuales y los adaptadores de red virtual para las intenciones de administración, proceso y almacenamiento. De forma predeterminada, cuando Network ATC crea el conmutador virtual para las intenciones, usa un nombre específico para el conmutador virtual.

    Se recomienda asignar un nombre al conmutador virtual con la misma convención de nomenclatura. El nombre recomendado para los conmutadores virtuales es ConvergedSwitch($IntentName), donde $IntentName debe coincidir con el nombre de la intención tipada en el portal durante la implementación. Esta cadena también debe coincidir con el nombre del adaptador de red virtual que se usa para la administración, como se describe en el paso siguiente.

    En el ejemplo siguiente se muestra cómo crear el conmutador virtual con PowerShell usando la convención de nomenclatura recomendada con $IntentName. La lista de nombres de adaptador de red es una lista de los adaptadores de red físicos que planea usar para administrar y procesar el tráfico de red:

    $IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true

    Nota

    Una vez implementada una instancia local de Azure, no se admite el cambio del nombre de la intención de administración o el nombre del conmutador virtual. Debe usar el mismo nombre de intención y nombre del conmutador virtual si necesita actualizar o volver a crear la intención después de la implementación.

  2. Configure el adaptador de red virtual de administración con la convención de nomenclatura requerida de Network ATC en todos los nodos.

    Una vez creado el conmutador virtual y el adaptador de red virtual de administración asociado, asegúrese de que el nombre del adaptador de red es compatible con los estándares de nomenclatura de Network ATC.

    En concreto, el nombre del adaptador de red virtual que se usa para el tráfico de administración debe usar las convenciones siguientes:

    • El nombre del adaptador de red y el adaptador de red virtual deben usar vManagement($intentname).
    • Este nombre no distingue mayúsculas de minúsculas.
    • $Intentname puede ser cualquier cadena, pero debe ser el mismo nombre usado para el conmutador virtual. Asegúrese de utilizar esta misma cadena en el portal de Azure al definir el nombre de intención Mgmt.

    Para actualizar el nombre del adaptador de red virtual de administración, use los siguientes comandos:

    $IntentName = "MgmtCompute"

# Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

# Rename NetAdapter because during creation, Hyper-V adds the string "vEthernet" to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

    Nota

    Durante la validación de la implementación, todos los vSwitches en los nodos deben tener las VNIC correspondientes. Si hay vSwitches presentes pero no hay VNIC coincidentes, la operación produce el siguiente error:

    "No se pudo completar la operación. 200: Existen vSwitches en los nodos, pero no hay vnics, este escenario no está soportado.

    Asegúrese de que los nombres de los adaptadores coinciden entre las salidas de Get-NetAdapter y Get-VMNetworkAdapter -ManagementOS. Si no coinciden, cambie el nombre de las NIC antes de reintentar la implementación.

  3. Configure el identificador de VLAN en el adaptador de red virtual de administración en todos los nodos.

    Una vez creado el conmutador virtual y el adaptador de red virtual de administración, puede especificar el identificador de VLAN necesario para este adaptador. Aunque hay diferentes opciones para asignar un identificador de VLAN a un adaptador de red virtual, la única opción admitida es usar el comando Set-VMNetworkAdapterIsolation.

    Una vez configurado el identificador de VLAN necesario, puede asignar la dirección IP y las puertas de enlace al adaptador de red virtual de administración para validar que tiene conectividad con otros nodos, DNS, Active Directory e Internet.

    En el ejemplo siguiente se muestra cómo configurar el adaptador de red virtual de administración para usar el id. de VLAN 8 en lugar del valor predeterminado:

    Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID "8"

  4. Haga referencia a los adaptadores de red físicos para la intención de administración durante la implementación.

    Aunque el adaptador de red virtual recién creado se muestra como disponible al implementar a través del portal de Azure, es importante recordar que la configuración de red se basa en Network ATC. Esto significa que, al configurar la intención de administración o la intención de administración y cómputo, aún debe seleccionar los adaptadores de red físicos que se usan para esa intención.

    Nota

    No seleccione el adaptador de red virtual para el objetivo de red.

    La misma lógica se aplica a las plantillas de Azure Resource Manager. Debe especificar los adaptadores de red físicos que desea usar para las intenciones de red y nunca los adaptadores de red virtual.

Estas son las consideraciones resumidas para el identificador de VLAN:

# Consideración Se aplica a
1 El id. de VLAN debe especificarse en el adaptador de red físico para la administración antes de registrar las máquinas con Azure Arc. Ambas
2 Use pasos específicos cuando se requiera un conmutador virtual antes de registrar las máquinas en Azure Arc. Ambas
3 El id. de VLAN de administración se transfiere desde la configuración del host a las máquinas virtuales de infraestructura durante la implementación. Ambas
4 No hay ningún parámetro de entrada de identificador de VLAN para la implementación de Azure Portal ni para la implementación de plantillas de Resource Manager. Ambas
5 Todos los adaptadores que quiera usar para la administración deben tener configurado el mismo identificador de VLAN. Ambas
6 El identificador de VLAN de administración (red de infraestructura) no se puede cambiar después de la implementación. También lo heredan la máquina virtual de Azure Resource Bridge y las demás máquinas virtuales de infraestructura, por lo que debe planificarlo antes de registrar las máquinas con Azure Arc. Ambas

Asignación de IP de nodo y clúster

Para una instancia de Azure Local, tiene dos opciones para asignar direcciones IP para los nodos de máquina y para la dirección IP del clúster:

  • Se admiten los protocolos estáticos y dinámicos del Protocolo de configuración de host (DHCP).
  • La asignación de IP de nodo adecuada es clave para la administración del ciclo de vida del clúster. Decida entre las opciones estáticas y DHCP antes de registrar los nodos en Azure Arc.
  • Las máquinas virtuales y servicios de infraestructura, como Arc Resource Bridge y Network Controller, siguen usando direcciones IP estáticas del grupo de direcciones IP de administración. Esto implica que incluso si decide usar DHCP para asignar las direcciones IP a los nodos y la dirección IP del clúster, el grupo de direcciones IP de administración sigue siendo necesario.

En las secciones siguientes se describen las implicaciones de cada opción.

Asignación de direcciones IP estáticas

Si se usan direcciones IP estáticas para los nodos, el grupo de direcciones IP de administración se usa para obtener una dirección IP disponible y asignarla automáticamente a la dirección IP del clúster durante la implementación.

Es importante usar direcciones IP de administración para los nodos que no forman parte del intervalo IP definido para el grupo de direcciones IP de administración. Las direcciones IP del nodo de máquina deben estar en la misma subred que el intervalo IP definido.

Se recomienda asignar solo una dirección IP de administración para la puerta de enlace predeterminada y para los servidores DNS configurados para todos los adaptadores de red físicos del nodo. Esto garantiza que la dirección IP no cambie una vez creada la intención de red de administración. Esto también garantiza que los nodos mantengan su conectividad de salida durante el proceso de implementación, incluido durante el registro de Azure Arc.

Para evitar problemas de enrutamiento e identificar la dirección IP que se usa para la conectividad saliente y el registro de Arc, el portal de Azure valida si hay más de una puerta de enlace predeterminada configurada.

Si se creó un conmutador virtual y un adaptador de red virtual de administración durante la configuración del sistema operativo, la dirección IP de administración del nodo debe asignarse a ese adaptador de red virtual.

Asignación IP de DHCP

Si las direcciones IP de los nodos se adquieren desde un servidor DHCP, también se usa una dirección IP dinámica para la dirección IP del clúster. Las máquinas virtuales y los servicios de infraestructura siguen requiriendo direcciones IP estáticas, lo que implica que el intervalo de direcciones del grupo de direcciones IP de administración debe excluirse del ámbito de DHCP utilizado para los nodos y la dirección IP del clúster.

Por ejemplo, si el intervalo ip de administración se define como 192.168.1.20 a 192.168.1.30 para las direcciones IP estáticas de la infraestructura, el ámbito DHCP definido para la subred 192.168.1.0/24 debe tener una exclusión equivalente al grupo de direcciones IP de administración para evitar conflictos de IP con los servicios de infraestructura. También se recomienda usar reservas DHCP para direcciones IP de nodo.

El proceso de definir la dirección IP de administración después de crear la intención de administración implica el uso de la dirección MAC del primer adaptador de red físico seleccionado para la intención de red. A continuación, esta dirección MAC se asigna al adaptador de red virtual que se crea con fines administrativos. Esto significa que la dirección IP que obtiene el primer adaptador de red físico del servidor DHCP es la misma dirección IP que usa el adaptador de red virtual como IP de administración. Por lo tanto, es importante crear una reserva DHCP para la dirección IP del nodo.

Se produce un error en la lógica de validación de red usada durante la implementación en la nube si detecta varias interfaces de red físicas que tienen una puerta de enlace predeterminada en su configuración. Si necesita usar DHCP para las asignaciones IP de host, debe crear previamente el conmutador virtual SET (switch embedded teaming) y el adaptador de red virtual de administración como se ha descrito anteriormente, por lo que solo el adaptador de red virtual de administración adquiere una dirección IP del servidor DHCP.

Estas son las consideraciones resumidas para las direcciones IP:

# Consideración Se aplica a
1 Las direcciones IP de nodo deben estar en la misma subred que el intervalo definido del grupo de direcciones IP de administración, independientemente de si son direcciones estáticas o dinámicas. Ambas
2 El grupo de direcciones IP de administración no debe incluir direcciones IP de nodo. Use exclusiones DHCP cuando se use la asignación dinámica de IP. Ambas
3 Use reservas DHCP para los nodos tanto como sea posible. Ambas
4 Las direcciones DHCP solo se admiten para direcciones IP de nodo y la dirección IP del clúster. Los servicios de infraestructura usan direcciones IP estáticas del grupo de administración. Ambas
5 La dirección MAC del primer adaptador de red físico se asigna al adaptador de red virtual de administración una vez creada la intención de red de administración. Ambas

Consideraciones sobre el servidor DNS

Las implementaciones locales de Azure basadas en Active Directory requieren un servidor DNS que pueda resolver el dominio local y los puntos de conexión públicos de Internet. Como parte de la implementación, es necesario definir los mismos servidores DNS para el intervalo de direcciones IP de infraestructura configurado en los nodos. La máquina virtual del plano de control de Azure Resource Bridge y el plano de control de AKS utilizan esos mismos servidores DNS para la resolución de nombres. Una vez completada la implementación, no se admite cambiar las direcciones IP del servidor DNS y no es posible actualizar las direcciones en la pila de plataformas de Azure Local.

Los servidores DNS usados para Azure Local deben ser externos y operativos antes de la implementación. No se admite la ejecución de todos los servidores DNS configurados como máquinas virtuales en la misma instancia de Azure Local que depende de ellos. Dado que los nodos del clúster, Azure Resource Bridge y AKS necesitan resolución de nombres durante el arranque y antes de que se ejecuten las máquinas virtuales de carga de trabajo, al menos uno de los servidores DNS configurados debe ejecutarse fuera de la instancia de Azure Local. Un clúster que se basa únicamente en máquinas virtuales DNS hospedadas en sí mismo no puede resolver nombres durante un apagado completo, reinicio o recuperación, cuando esas máquinas virtuales aún no están disponibles. Si ejecuta DNS como vm en el clúster para la resolución local, mantenga al menos un servidor DNS externo independiente en la lista configurada.

Estas son las consideraciones resumidas para las direcciones de servidor DNS:

# Consideración Se aplica a
1 Los servidores DNS en todos los nodos del clúster deben ser los mismos. Ambas
2 Los servidores DNS del intervalo de direcciones IP de la infraestructura deben ser los mismos que se usan para los nodos. Ambas
3 El plano de control de máquinas virtuales de Azure Resource Bridge y el plano de control de AKS usan los servidores DNS configurados en el intervalo de direcciones IP de la infraestructura. Ambas
4 No se admite cambiar los servidores DNS después de la implementación. Asegúrese de planificar la estrategia de DNS antes de realizar la implementación de Azure Local. Ambas
5 Al definir una matriz de varios servidores DNS en una plantilla de ARM para la red de infraestructura, asegúrese de que cada valor está entre comillas "" y separadas por comas, como en el ejemplo siguiente. Ambas
6 No se admite la ejecución de todos los servidores DNS configurados como máquinas virtuales en la misma instancia de Azure Local. Al menos un servidor DNS configurado debe ejecutarse fuera del clúster para que la resolución de nombres funcione durante el arranque, el apagado, el reinicio y la recuperación, cuando las máquinas virtuales hospedadas en clúster no estén disponibles. Ambas
7 Todos los servidores DNS configurados deben resolver los dominios locales necesarios para la infraestructura. No se admiten servidores DNS públicos como 8.8.8.8. Ambas
8 Todos los servidores DNS configurados no deben superponerse con los intervalos de subredes reservadas de ARB (10.96.0.0/12 y 10.244.0.0/16). Ambas 
"dnsServers": [
    "10.250.16.124",
    "10.250.17.232",
    "10.250.18.107"
]

Decisión 9: Determinación de la red de copia de seguridad

Decida si su despliegue requiere una red de copia de seguridad dedicada para el tráfico de copia de seguridad de las máquinas virtuales invitadas (VM). Esta decisión se aplica tanto a las arquitecturas hiperconvergidas como desagregadas.

  • Sin red de copia de seguridad: el tráfico de copia de seguridad de invitado comparte la intención de proceso existente. Esto es suficiente para implementaciones más pequeñas o donde el volumen de tráfico de copia de seguridad es bajo.
  • Habilitar red de copia de seguridad: agregue una red de copia de seguridad dedicada con dos puertos de adaptador de red adicionales por nodo. Una red de copia de seguridad dedicada aísla el tráfico de copia de seguridad del tráfico de almacenamiento y proceso de producción, que protege el rendimiento de la carga de trabajo durante las ventanas de copia de seguridad.

Hiperconverged (HCI)

En el caso de las implementaciones hiperconvergidas, agregue una red de copia de seguridad dedicada como segunda intención de proceso mediante el modelo de intención de configuración personalizada descrito en decisión 7. Asigne dos puertos de adaptador de red adicionales a la intención de copia de seguridad para lograr alta disponibilidad.

Desagregado (DA)

La compatibilidad con la red de copia de seguridad depende del tipo san y del diseño del adaptador elegido en la Decisión 6:

  • Fibre Channel: Use el diseño de 6 puertos, que agrega una intención de proceso Copia de seguridad de invitado en los puertos de red 5 y 6 (SET), además de la intención de administración y proceso, y de las redes del clúster.
  • iSCSI 6-port (dedicated-path): admite una red de copia de seguridad opcional. Al habilitar la copia de seguridad, los puertos de administración y cómputo (puertos de red 1 y 2) se agrupan en un conmutador SET administrado por NetworkATC que aloja la vNIC del host de administración y transporta en troncal la VLAN de copia de seguridad del cliente. El clúster dedicado y los puertos iSCSI (puertos de red 3, 4, 5 y 6) no se ven afectados. El cliente creará manualmente la vNIC de copia de seguridad de invitado en el host en el conmutador virtual administrado por Network ATC.

Para conocer los patrones de referencia de copia de seguridad de canal de fibra y sin copia de seguridad, consulte Patrón desagregado de canal de fibra con red de copia de seguridad y patrón desagregado de canal de fibra sin red de copia de seguridad.

Estas son las consideraciones resumidas para la decisión de red de copia de seguridad:

# Consideración Se aplica a
1 En implementaciones hiperconvergidas, agregue la red de copia de seguridad como segunda intención de proceso mediante el modelo de intención de configuración personalizada o cree manualmente una vNIC adicional sobre el conmutador virtual Management & Compute. HCI
2 En las implementaciones desagregadas, use el diseño de 6 puertos (Fibre Channel) o el de 6 puertos con ruta dedicada (iSCSI) para agregar una red de copia de seguridad para invitados. DA

Decisión 10: Determinar la conectividad saliente

Planee cómo los nodos de Azure Local y los servicios de infraestructura llegan a Azure para la administración del registro, la facturación y el ciclo de vida. Esta decisión se aplica a las arquitecturas y se basa en el modo de conectividad elegido en la Decisión 1. Azure Local admite cinco topologías de conectividad salientes: cuatro variantes de ruta de acceso pública y una ruta de acceso totalmente privada.

# Topology Proxy empresarial Puerta de enlace de Arc Resumen
1 Salida directa No configurado No configurado Los nodos llegan Azure directamente a través de Internet. Requiere más de 100 FQDN en el firewall perimetral. Ideal para laboratorios o entornos aislados pequeños.
2 Proxy empresarial Configurado No configurado Todo el tráfico HTTP/HTTPS del host se redirige a través del proxy corporativo. Sigue requiriendo que se permitan más de 100 FQDN y que la inspección de SSL esté deshabilitada para los puntos de conexión de Azure Local.
3 Puerta de enlace de Arc No configurado Configurado Los túneles de puerta de enlace de Arc admiten el tráfico HTTPS para Azure, dejando menos de 30 puntos de conexión en la lista de permitidos del firewall.
4 Proxy empresarial y puerta de enlace de Arc Configurado Configurado Se recomienda para nuevas implementaciones de producción. Política de proxy centralizada más una lista mínima de elementos permitidos.
5 Ruta de acceso privada Configurado (proxy explícito de Azure Firewall) Configurado Los nodos se conectan a Azure a través de Azure ExpressRoute o una VPN de sitio a sitio. El proxy es siempre Azure Firewall Explicit Proxy, y se requiere la puerta de enlace de Arc.

Para entornos aislados de la red, use las operaciones desconectadas de Azure Local, que proporcionan un punto de conexión local de Autonomous Cloud en lugar de puntos de conexión públicos de Azure. Para obtener más información, consulte la Decisión 1.

Importante

Actualmente no se admite la implementación del registro de infraestructura de Azure Local a través de una ruta de acceso totalmente privada (Azure ExpressRoute o VPN de sitio a sitio). Use una topología de ruta de acceso pública para la implementación. Todavía puede usar la conectividad privada para cargas de trabajo y puntos de conexión privados.

puerta de enlace de Azure Arc

La puerta de enlace de Azure Arc reduce el número de puntos de conexión públicos necesarios para implementar y operar Azure Local de más de 100 a menos de 30. Una implementación con puerta de enlace de Arc se basa en cuatro componentes:

  • Agente de Arc: se ejecuta en cada nodo y lo conecta al plano de control de Azure Arc.
  • Proxy de Arc: un servicio proxy de reenvío local que forma parte del agente de Arc y se ejecuta en cada nodo. Cuando la puerta de enlace de Arc está habilitada en Azure Local, el proxy de Arc redirige el tráfico HTTPS admitido a través del túnel de puerta de enlace de Arc. Los nodos acceden localmente a su propio proxy de Arc en localhost:40343, mientras que la máquina virtual de Azure Resource Bridge, el plano de control de AKS y las máquinas virtuales de nodo de trabajo acceden a él mediante la IP del clúster en el puerto 40343.
  • IP de clúster: un único reenviador usado por Azure Resource Bridge y AKS. Flota entre nodos para lograr una alta disponibilidad, por lo que el tráfico HTTPS de la máquina virtual del puente de recursos redirigido Azure y la máquina virtual de AKS siempre fluye a través del proxy de Arc en el nodo que posee la dirección IP del clúster en ese momento. Al solucionar problemas de este tráfico, analice los registros del proxy de Arc en el nodo que posee actualmente la dirección IP del clúster, no en los demás nodos.
  • Recurso de puerta de enlace de Arc: El punto de entrada administrado por Azure, al que se accede como <gatewayId>.gw.arc.azure.com.

Cuando la puerta de enlace de Arc está habilitada, cada componente enruta su tráfico saliente a través de un proxy específico. El tráfico HTTPS del sistema operativo del nodo usa el proxy local de Arc del nodo (http://localhost:40343), mientras que la VM de Azure Resource Bridge, el plano de control de AKS y las VM de trabajo usan la IP del clúster a través del puerto 40343. Las máquinas virtuales de Azure Local habilitadas para Arc utilizan su propio proxy dedicado de Arc. En todos los casos, el proxy de Arc solo reenvía los extremos HTTPS compatibles administrados por Microsoft a través del túnel de la puerta de enlace de Arc.

El tráfico HTTPS a los puntos de conexión que la puerta de enlace de Arc no permite(incluidos servicios de terceros y OEM, como servicios de actualización de proveedores de hardware u otros agentes instalados en los nodos) se redirige al proxy o firewall de la empresa. Debe permitir esos endpoints de forma explícita según sus requisitos. El tráfico HTTP nunca se tunelizará y siempre irá al proxy de empresa o al firewall.

Para obtener más información sobre cómo funciona la puerta de enlace de Arc y cómo crear el recurso de puerta de enlace, consulte Acerca de Azure Arc puerta de enlace para Azure Local. Para registrar las máquinas a través de la puerta de enlace, consulte Registro de máquinas Azure Local con Azure Arc mediante la puerta de enlace de Arc. Para ver un desglose detallado de cada flujo de tráfico saliente (SO del nodo, Azure Resource Bridge, AKS y máquinas virtuales de Azure Local), con diagramas, consulte Análisis detallado de la conectividad saliente de Arc gateway.

Complete estos requisitos previos antes de registrar los nodos:

  • Cree el recurso de puerta de enlace de Arc en la suscripción donde planea implementar Azure Local.
  • Configure el firewall para permitir el acceso a los puntos de conexión de la puerta de enlace de Arc y deshabilite la inspección SSL en estos.
  • Si usa un proxy empresarial, agregue las subredes necesarias, los nombres de nodo, el nombre del clúster y los FQDN de cualquier extremo privado a la lista de exclusión del proxy antes del registro de Arc.

Incluso con la puerta de enlace de Arc, aproximadamente 23 FQDN siguen estando en la lista de permitidos del firewall perimetral o del proxy, entre los que se incluyen:

  • Dos FQDN de bootstrap y seis FQDN de registro de Arc.
  • El extremo de la puerta de enlace de Arc (<gatewayId>.gw.arc.azure.com).
  • Los extremos de la lista de revocación de certificados (CRL) solo pueden usar HTTP, ya que la puerta de enlace de Arc solo admite HTTPS.
  • Azure Key Vault (vault.azure.net) y la cuenta de almacenamiento testigo (blob.core.windows.net) para la implementación.

Para obtener la lista completa y actual del punto de conexión, consulte Requisitos de firewall.

Nota

Cuando se implementa AKS, la subred de AKS requiere línea de visión en la subred de infraestructura en los puertos TCP 22, 6443, 40343, 55000 y 65000.

Estas son las principales consideraciones sobre el gateway de Arc:

# Consideración Se aplica a
1 Planifique la lista de exclusión del proxy antes del despliegue. Incluya los extremos de Private Link admitidos y los nombres y las direcciones IP de los nodos que tiene previsto agregar durante una ampliación horizontal. Ambas
2 La inspección de SSL no es compatible con los puntos de conexión de gateway de Arc. Al usar un proxy terminador, no se puede omitir la inspección TLS para el extremo de puerta de enlace de Arc, ya que el proxy no puede interceptar el túnel TLS anidado. Ambas
3 No configure el proxy manualmente. El script de registro de Arc automatiza la configuración de proxy para WinINET, WinHTTP y las variables de entorno. Ambas
4 No se puede actualizar la lista de exclusión del proxy tras la implementación para añadir nuevos puntos de conexión o máquinas. Ambas
5 Use la misma configuración de proxy en todas las máquinas Azure Local. Ambas
6 El tráfico HTTPS a los puntos de conexión que la puerta de enlace de Arc no permite, incluidos los servicios de terceros y OEM, se redirige al proxy de empresa o al firewall. Permita explícitamente esos extremos. Ambas
7 El tráfico redirigido de la VM de Azure Resource Bridge y de la VM de AKS siempre fluye a través del nodo que tiene asignada la IP del clúster. Analice los registros de proxy de Arc para este tráfico en el nodo que posee actualmente la dirección IP del clúster. Ambas

Requisitos de proxy

Es probable que se requiera un proxy para acceder a Internet desde la infraestructura local. A partir de Azure Local 2506, ya no se configura manualmente el proxy del host. En su lugar, durante el registro de Arc solo se proporcionan una vez el servidor proxy empresarial y la lista de exclusión del proxy, y el script de registro de Arc configura automáticamente el proxy en los tres componentes del sistema operativo (WinINET, WinHTTP y las variables de entorno) de cada nodo. Puede proporcionar los detalles del proxy a través del script de registro de Arc o interactivamente a través de la aplicación Configurator. Para obtener más información, consulte Definición de la configuración de proxy.

La misma configuración de proxy se lleva automáticamente a la máquina virtual de Arc Resource Bridge y AKS durante la implementación, por lo que esos componentes tienen acceso a Internet sin pasos manuales adicionales. Cuando usa la puerta de enlace Arc, el script de registro establece el proxy HTTPS del host en el proxy local de Arc (http://localhost:40343), enruta el tráfico HTTP al proxy empresarial y agrega automáticamente los puntos de conexión internos necesarios a la lista de omisión de cada componente.

Solo se admiten servidores proxy no autenticados. Los archivos de configuración automática de proxy (PAC) y los puntos de conexión de proxy que usan un .local dominio (por ejemplo, http://proxy.contoso.local) no se admiten.

Al definir la lista de omisión de proxy, siga estas reglas de formato para que el tráfico interno omita el proxy correctamente:

  • Incluya, como mínimo, la dirección IP de cada máquina Azure Local, la dirección IP del clúster y las direcciones IP de red de infraestructura. Arc Resource Bridge, AKS y futuros servicios de infraestructura usan estas direcciones IP. Como alternativa, puede omitir toda la subred de infraestructura.
  • Incluya el nombre NetBIOS de cada máquina y del clúster.
  • En el caso de los dominios internos, puede usar un nombre de dominio con un carácter comodín de asterisco inicial (*), como *.contoso.com. En el caso de las subredes, use la notación comodín, como 192.168.1.*.
  • Separe las entradas con comas. No se admite la notación CIDR para omitir subredes.

Estas son las consideraciones resumidas para la configuración del proxy:

# Consideración Se aplica a
1 A partir de Azure Local 2506, ya no se configura manualmente el proxy del host. El script de registro de Arc lo configura automáticamente en winINET, WinHTTP y variables de entorno. Ambas
2 Proporcione el servidor proxy empresarial y la lista de excepciones del proxy una sola vez, durante el registro en Arc, antes de que los nodos se registren en Azure Arc. Ambas
3 Puede proporcionar los detalles del proxy a través del script de registro de Arc o interactivamente a través de la aplicación Configurator. Ambas
4 El script de registro de Arc lleva la configuración del proxy a la máquina virtual de Arc Resource Bridge y AKS durante la implementación. Ambas
5 Solo se admiten servidores proxy no autenticados. No se admiten archivos PAC ni puntos de conexión proxy con un .local dominio. Ambas
6 El servidor proxy configurado para los nodos de Azure Local no debe superponerse con los intervalos de subredes de ARB reservados (10.96.0.0/12 y 10.244.0.0/16). Ambas
7 En la lista de excepciones del proxy, incluya la IP de cada equipo, la IP del clúster y la subred de infraestructura, así como los nombres NetBIOS del equipo y del clúster. Separe las entradas con comas y use la notación comodín (por ejemplo, 192.168.1.*), porque no se admite la notación CIDR. Ambas

Puntos de conexión privados

Puede usar puntos de conexión privados de Azure Private Link para mantener el tráfico hacia los servicios de plataforma como servicio (PaaS) de Azure compatibles en una ruta de red privada a través de Azure ExpressRoute o una VPN de sitio a sitio. Los puntos de conexión privados se admiten en las cinco topologías salientes para servicios como Azure Storage (blob), Azure SQL, Azure Key Vault, Azure Container Registry (ACR) y Azure Site Recovery. Para obtener más información sobre los escenarios admitidos y la configuración de cada escenario, consulte Acerca de los puntos de conexión privados de Azure en Azure Local.

Importante

Azure Arc Private Link no se admite para la infraestructura de Azure Local (nodos y Azure Resource Bridge), máquinas virtuales Azure Local ni AKS. El registro de Arc debe usar los puntos de conexión públicos de Arc. El DNS de infraestructura debe resolver los FQDN de Arc (por ejemplo, gbl.his.arc.azure.com) en direcciones IP públicas. Si el DNS corporativo devuelve direcciones IP privadas para estos FQDN, use un servidor DNS independiente para Azure Local. Si DNS devuelve una dirección IP privada (por ejemplo, en 10.x, 172.16.xo 192.168.x) para un punto de conexión de Arc en un host, la configuración no es compatible.

Al planear puntos de conexión privados, siga estas reglas:

  • Evite la superposición de intervalos reservados: las direcciones IP del extremo privado no deben estar comprendidas en 10.244.0.0/16 (pods de AKS) ni en 10.96.0.0/12 (servicios de Kubernetes). Un punto de conexión superpuesto se trata como tráfico interno del clúster y nunca deja la red virtual. Por ejemplo, un punto de conexión en 10.244.1.4 falla, mientras que 10.245.0.5 se enruta correctamente.
  • Mantener los servicios críticos públicos durante la implementación: mantenga habilitado el acceso público en Azure Key Vault y la cuenta de almacenamiento testigo hasta que se complete la implementación y restrinja a las redes privadas.
  • Agregar puntos de conexión privados a la lista de omisión: cuando use un proxy empresarial, agregue los FQDN de los puntos de conexión privados a la lista de omisión del proxy durante el registro de Arc. En el caso de las cargas de trabajo de AKS, agréguelas a la lista de omisión de variables de entorno después del registro de Arc.
  • No use caracteres comodín: las entradas comodín, como *.azurecr.io , por ejemplo, no se admiten en la lista de omisión. Agregue los FQDN exactos del registro antes de implementar, porque Azure Resource Bridge y AKS los usan para extraer imágenes.
  • Enrutamiento de puntos de conexión privados fuera de la puerta de enlace de Arc: los puntos de conexión privados no se enrutan a través de la puerta de enlace de Arc. Para servicios como Azure Site Recovery, deshabilite la inspección SSL en el proxy empresarial o, preferiblemente, agregue el punto de conexión a la lista de exclusión del proxy.

En la tabla siguiente se proporcionan instrucciones de punto de conexión privado por servicio:

Service FQDN Orientación
Azure Key Vault vault.azure.net Necesario para la implementación (configuración de secretos). Mantener el acceso público habilitado durante la implementación; restringir después.
Azure Storage blob.core.windows.net Necesario para implementaciones de dos nodos (testigo en la nube). Mantenga el acceso público habilitado hasta que finalice la instalación.
Azure Container Registry (Registro de Contenedores de Azure) azurecr.io Fundamental para la descarga de imágenes en AKS. No se permiten comodines en la lista de exclusión; agregue los FQDN específicos del registro antes del despliegue.
Recuperación del Sitio de Azure privatelink.siterecovery.* No permitido a través de la puerta de enlace de Arc. Deshabilite la inspección SSL en el proxy o agregue el extremo a la lista de exclusión del proxy.

Requisitos de firewall

Actualmente, es necesario abrir varios puntos de conexión de Internet en los firewalls para asegurarse de que Azure Local y sus componentes puedan conectarse correctamente a ellos. Para obtener una lista detallada de los puntos de conexión necesarios, consulte Requisitos de firewall.

La configuración del firewall debe realizarse antes de registrar los nodos en Azure Arc. Puede usar la versión independiente del comprobador de entorno para validar que los firewalls no bloquean el tráfico enviado a estos puntos de conexión. Para más información, consulte Comprobador de entorno de Azure Local para evaluar la preparación de la implementación para Azure Local.

Estas son las consideraciones resumidas para el firewall:

# Consideración Se aplica a
1 La configuración del firewall debe realizarse antes de registrar los nodos en Azure Arc. Ambas
2 El Comprobador de entorno en modo independiente se puede usar para validar la configuración del firewall. Ambas

Decisión 11: Determinar las redes definidas por software (SDN)

Las redes definidas por software (SDN) constituyen una capa de red opcional para cargas de trabajo que se aplica después de haber implementado la red de host (decisiones de la 1 a la 10). En Azure Local, SDN está habilitado por Azure Arc y tiene como ámbito dos funcionalidades: redes lógicas SDN (LNET) que proporcionan segmentos de red definidos por software para las cargas de trabajo y están respaldados por VLAN en el tejido físico y la microsegmentación a través de grupos de seguridad de red (NSG). Decida si las cargas de trabajo necesitan segmentación de red programable y directiva de seguridad distribuida y confirme que la arquitectura admite el modelo sdn que necesita.

Importante

La SDN administrada por Arc en Azure Local no admite redes virtuales (VNETs), equilibradores de carga de software (SLB) ni puertas de enlace RAS/GRE. Solo se admiten LNETs y NSGs. Si sus cargas de trabajo requieren VNETs, SLB, GRE o toda la pila de puerta de enlace SDN de Microsoft, Azure Local no es la plataforma recomendada. En su lugar, use una implementación de SDN de Windows Server en la que es compatible la pila completa de Network Controller, incluidas las VNET, el SLB y las puertas de enlace.

Hiperconverged (HCI)

Las implementaciones hiperconvergidas admiten Microsoft SDN habilitados por Azure Arc para 1 a 16 nodos:

  • El plano de control SDN solo proporciona LNET y NSG. Al habilitarla, se activa la extensión Azure Virtual Filtering en el conmutador virtual de la carga de trabajo.
  • Las LNET se sustentan en VLAN de la fabric, por lo que configure y habilite los enlaces troncales de las VLAN correspondientes en los conmutadores ToR para cada red lógica.
  • La controladora de red se ejecuta como un conjunto de servicios de clúster en la instancia de Azure Local, no como máquinas virtuales de infraestructura independientes.

SDN solo es compatible con los siguientes patrones de intención de Network ATC de Decision 7:

Patrón de intención Descripción Compatible con SDN
Agrupar todo el tráfico Una única intención que integra administración, cómputo y almacenamiento. Solo se admite con el almacenamiento conmutado. ✅
Gestión de grupos y cómputo, con un propósito de almacenamiento independiente Una intención para la gestión y el cómputo, y una segunda intención dedicada al almacenamiento. ✅
Grupo de cómputo y almacenamiento, con un propósito de administración independiente El proceso y el almacenamiento comparten una intención y la administración usa una intención independiente. ❌
Configuración personalizada Cualquier agrupación personalizada que separa el cómputo de la gestión en las distintas intenciones. ❌

Desagregado (DA)

Las implementaciones desagregadas no usan la Microsoft controladora de red SDN. Las redes lógicas de SDN se aprovisionan en el tejido de columna de hoja externa mediante una superposición VXLAN EVPN, coherente con la topología de varios bastidores de la Decisión 3:

  • Diseñe el tejido VRF y la superposición para llevar las redes lógicas necesarias.
  • Las redes lógicas de AKS necesitan capacidad de acceso de nivel 3 a la red lógica de administración.
  • Los clústeres desagregados de un solo bastidor que no necesitan SDN a escala pueden permanecer en la topología de dos conmutadores más sencilla.

Para obtener más información sobre el diseño de superposición de VRF y VXLAN en la arquitectura leaf-spine, consulte Descripción general de los patrones de referencia de red para despliegues desagregados.

Estas son las consideraciones resumidas para la decisión de SDN:

# Consideración Se aplica a
1 SDN es opcional y se superpone a la red host después de la implementación. Decida si las cargas de trabajo necesitan redes lógicas de SDN (LNET) o microsegmentación (NSG). Ambas
2 SDN administrado por Arc en Azure Local solo admite LNET y NSG. Las VNET, las puertas de enlace SLB y RAS/GRE no son compatibles. HCI
3 Las máquinas virtuales no administradas que se ejecutan en Azure Local y usan SDN administrada por herramientas locales no se pueden convertir en máquinas virtuales de Azure Local. HCI
4 Los LNET están respaldados por VLAN en el tejido. Configure las VLAN correspondientes y configúrelas como troncales en los conmutadores físicos para cada red lógica. HCI
5 Si las cargas de trabajo requieren VNET, SLB, GRE o la pila completa de puertas de enlace SDN de Microsoft, use una implementación de SDN de Windows Server en lugar de Azure Local. HCI
6 Desagregado (DA) usa SDN externo basado en tejido (VXLAN EVPN) en el tejido de la columna de hoja. No se usa la controladora de red de SDN de Microsoft. DA

Pasos siguientes

  • Last updated on