Consideraciones de red para las implementaciones en la nube de Azure Local, versión 23H2

Se aplica a: Azure Local, versión 23H2

En este artículo se describe cómo diseñar y planear una red del sistema local de Azure, versión 23H2 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.

Marco de diseño de red

En el diagrama siguiente se muestran las distintas decisiones y pasos que definen el marco de diseño de red para la instancia local de Azure: tamaño del clúster, conectividad de almacenamiento de clústeres, intenciones de tráfico de red, conectividad de administración y configuración del adaptador de red. Cada decisión de diseño habilita o permite las opciones de diseño disponibles en los pasos siguientes:

Paso 1: Determinar el tamaño del clúster

Para ayudar a determinar el tamaño de la instancia local de Azure, use la herramienta De tamaño local de Azure, donde puede definir el perfil, como el número de máquinas virtuales (VM), el tamaño de las máquinas virtuales y el uso de la carga de trabajo de las máquinas virtuales, como Azure Virtual Desktop, SQL Server o AKS.

Como se describe en el artículo Requisitos de máquina del sistema local de Azure, el número máximo de máquinas admitidas en la instancia local de Azure es 16. 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 la infraestructura.

• Si las cargas de trabajo requieren cuatro o más nodos: no se puede implementar y 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 local de Azure, consulte Introducción a los patrones de referencia de red.

• Si las cargas de trabajo requieren tres o menos nodos: puede elegir configuraciones sin conmutador o conmutadas para la conectividad de almacenamiento.

• Si planea escalar horizontalmente más adelante a más de tres nodos: debe usar un conmutador físico para el tráfico de red de almacenamiento. Cualquier operación de escalado horizontal para implementaciones sin conmutadores requiere la configuración manual del cableado de red entre los nodos que Microsoft no valida activamente como parte de su ciclo de desarrollo de software para Azure Local.

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

Decisión	Consideración
Tamaño del clúster (número de nodos por clúster)	La configuración sin conmutadores a través de Azure Portal o las plantillas de Azure Resource Manager solo está disponible para 1, 2 o 3 clústeres de nodos. Los clústeres con 4 o más nodos requieren un conmutador físico para el tráfico de red de almacenamiento.
Requisitos de escalado horizontal	Si piensa escalar horizontalmente el clúster mediante el orquestador, debe usar un conmutador físico para el tráfico de red de almacenamiento.

Paso 2: Determinación de la conectividad de almacenamiento del clúster

Como se describe en Requisitos de red física, Azure Local admite dos tipos de conectividad para el tráfico de red de almacenamiento:

• Use un conmutador de red físico para controlar el tráfico.
• Conecte directamente los nodos entre ellos con cables de fibra o red cruzado para el tráfico de almacenamiento.

Las ventajas y desventajas de cada opción se documentan en el artículo vinculado anteriormente.

Como se indicó anteriormente, solo puede decidir entre las dos opciones cuando el tamaño del clúster es de tres o menos nodos. Cualquier clúster con cuatro o más nodos se implementa automáticamente mediante un conmutador de red para el almacenamiento.

Si los clústeres tienen menos de tres nodos, la decisión de conectividad de almacenamiento influye en el número y el tipo de intenciones de red que puede definir en el paso siguiente.

Por ejemplo, para configuraciones sin conmutador, debe definir dos intenciones de tráfico de red. El tráfico de almacenamiento para las comunicaciones 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 cada uno, 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 hiperconvergida o totalmente convergente .

Estas son las consideraciones resumidas para la decisión de conectividad de almacenamiento del clúster:

Decisión	Consideración
No hay ningún modificador para el almacenamiento	La configuración sin conmutadores a través de Azure Portal o la implementación de plantillas de Resource Manager solo se admite para clústeres de 1, 2 o 3 nodos. Se pueden implementar clústeres sin conmutadores de almacenamiento de 1 o 2 nodos mediante Azure Portal o plantillas de Resource Manager. 3 clústeres sin conmutadores de almacenamiento de nodos solo se pueden implementar mediante plantillas de Resource Manager. Las operaciones de escalado horizontal no se admiten con las implementaciones sin conmutadores. Cualquier cambio en el número de nodos después de la implementación requiere una configuración manual. Se requieren al menos 2 intenciones de red cuando se usa la configuración sin conmutador de almacenamiento.
Conmutador de red para el almacenamiento	Si piensa escalar horizontalmente el clúster mediante el orquestador, debe usar un conmutador físico para el tráfico de red de almacenamiento. Puede usar esta arquitectura con cualquier número de nodos entre 1 y 16. Aunque no se aplica, puede usar una única intención para todos los tipos de tráfico de red (administración, proceso y almacenamiento).

En el diagrama siguiente se resumen las opciones de conectividad de almacenamiento disponibles para varias implementaciones:

Paso 3: 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 y cómo influyen en el siguiente paso del marco. En el caso de las implementaciones en la nube, puede seleccionar entre cuatro opciones para agrupar el tráfico de red en una o varias intenciones. Las opciones disponibles dependen del número de nodos del clúster y del tipo de conectividad de almacenamiento usado.

Las opciones de intención de red disponibles se describen en las secciones siguientes.

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 modificador, no puede usar este tipo de intención. Azure Portal 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 al menos 10 Gbps interfaces de red para admitir el tráfico RDMA para el almacenamiento.

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 al menos 10 Gbps interfaces de red para admitir el tráfico RDMA para el almacenamiento.

Intención de red: agrupar el tráfico de proceso y almacenamiento

Network ATC configura dos intenciones. La primera intención incluye el tráfico de red de proceso y almacenamiento, y la segunda intención incluye solo el tráfico de red de administración. 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 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. Azure Portal 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 al menos 10 Gbps para la intención de proceso y almacenamiento para admitir el 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 intenciones.

• 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 al menos 10 Gbps para la intención de proceso y almacenamiento para admitir el tráfico RDMA.

En el diagrama siguiente se resumen las opciones de intención de red disponibles para varias implementaciones:

Paso 4: Determinación de la conectividad de red de almacenamiento y administración

En este paso, 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 proxy o id. de VLAN para los nodos para la conectividad saliente a Internet y otros servicios de intranet, como sistema de nombres de dominio (DNS) o Servicios de Active Directory.

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.

Controladores de adaptador de red

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 proporcionado por el proveedor de interfaz de red o OEM. Es posible que las funcionalidades importantes de los adaptadores de red no se muestren al usar los controladores de Microsoft predeterminados.

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 asegurarse de 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 de Azure Resource Bridge 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.

Se deben cumplir las condiciones siguientes al definir el grupo de DIRECCIONES IP para la subred de infraestructura durante la implementación:

#	Condición
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.
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.
3	La puerta de enlace predeterminada definida para el grupo de direcciones IP de administración debe proporcionar conectividad saliente a Internet.
4	Los servidores DNS deben garantizar la resolución de nombres con Active Directory e Internet.
5	Las direcciones IP de administración requieren acceso saliente a Internet.

Id. de VLAN de administració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 de VLAN 0. Sin embargo, si los requisitos de red deben usar una VLAN de administración específica para la red de infraestructura, debe configurarse en los adaptadores de red físicos que planea usar para el tráfico de administración.

Si tiene previsto usar dos adaptadores de red físicos para la administración, debe establecer la VLAN en ambos adaptadores. Esto debe hacerse como parte de la configuración de arranque 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 44 de VLAN en el adaptador NIC1de red físico.

Set-NetAdapter -Name "NIC1" -VlanID 44

Una vez establecido el identificador de VLAN y las direcciones IP de los nodos se configuran en los adaptadores de red físicos, el orquestador lee este valor de identificador 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 Azure Portal, ya que esto conlleva el riesgo de interrumpir la conectividad entre los nodos y Azure si los VLAN del conmutador físico no se enrutan correctamente.

Identificador 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 Hype-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. Creación de un 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 a los nombres de conmutador virtual con la misma convención de nomenclatura. El nombre recomendado para los conmutadores virtuales es el siguiente:

"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, tal como se describe en el paso siguiente.

En el ejemplo siguiente se muestra cómo crear el conmutador virtual con PowerShell mediante 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 calcular el tráfico de red:

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

2. Configurar el adaptador de red virtual de administración mediante la convención de nomenclatura atC de red necesaria para 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 distingue mayúsculas de minúsculas.
• $Intentname puede ser cualquier cadena, pero debe ser el mismo nombre que se usa para el conmutador virtual. Asegúrese de usar esta misma cadena en Azure Portal al definir el nombre de la Mgmt intención.

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)"

3. Configuración del identificador de VLAN para administrar el adaptador de red virtual para 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 Set-VMNetworkAdapterIsolation comando .

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 identificador 8 de VLAN en lugar del valor predeterminado:

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

4. Referencia a 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 de Azure Portal, es importante recordar que la configuración de red se basa en Network ATC. Esto significa que al configurar la administración, o la intención de administración y proceso, todavía es necesario seleccionar los adaptadores de red físicos que se usan para esa intención.

Nota:

No seleccione el adaptador de red virtual para la intención 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:

#	Consideraciones
1	El identificador de VLAN debe especificarse en el adaptador de red físico para la administración antes de registrar las máquinas con Azure Arc.
2	Use pasos específicos cuando se requiera un conmutador virtual antes de registrar las máquinas en Azure Arc.
3	El identificador de VLAN de administración se transfiere desde la configuración del host a las máquinas virtuales de infraestructura durante la implementación.
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.

Direcciones IP personalizadas para el almacenamiento

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

Adaptador de almacenamiento	Dirección IP y subred	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: este parámetro, cuando no se especifica se establece en true. Para habilitar direcciones IP de almacenamiento personalizadas durante la implementación, este parámetro debe establecerse en false.
• storageAdapterIPInfo: este parámetro tiene una dependencia con el parámetro "enableStorageAutoIP" y siempre es necesario cuando el parámetro ip automática de almacenamiento está establecido en false. En el parámetro "storageAdapterIPInfo" de la plantilla de ARM, también deberá especificar los parámetros "ipv4Address" y "subnetMask" para cada nodo y adaptador de red con sus propias direcciones IP y máscara de subred.
• vlanId: como se ha descrito anteriormente en la tabla, este parámetro usará las VLAN predeterminadas de NETWORK ATC 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 local de Azure de dos nodos con conmutador de red para el almacenamiento, donde las direcciones IP de almacenamiento se personalizan 2 nodos con direcciones IP de almacenamiento personalizadas.

Asignación de IP de nodo y clúster

Para la instancia local de Azure, tiene dos opciones para asignar direcciones IP para los nodos de la 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 IP estática

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 del 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 saliente durante el proceso de implementación, incluido durante el registro de Azure Arc.

Para evitar problemas de enrutamiento e identificar qué dirección IP se usará para la conectividad saliente y el registro de Arc, Azure Portal 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 de IP 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 necesitando direcciones IP estáticas, lo que implica que el intervalo de direcciones del grupo de IP de administración debe excluirse del ámbito DHCP usado 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/24 a 192.168.1.30/24 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 de administración. 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 producirá 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.

Consideraciones sobre ip del nodo de clúster

Estas son las consideraciones resumidas para las direcciones IP:

#	Consideraciones
1	Las direcciones IP de nodo deben estar en la misma subred del intervalo de grupos de DIRECCIONES IP de administración definido, independientemente de si son direcciones estáticas o dinámicas.
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 de IP dinámica.
3	Use reservas DHCP para los nodos tanto como sea posible.
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.
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.

Consideraciones sobre servidores DNS

Las implementaciones y despliegues locales de Azure que se basan en Active Directory requieren un servidor DNS que pueda resolver el dominio On-Prem 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 usarán esos mismos servidores DNS para la resolución de nombres. Una vez completada la implementación, no se admite cambiar las direcciones IP de los servidores DNS y no será posible actualizar las direcciones en la pila de la plataforma local de Azure.

Estas son las consideraciones resumidas para las direcciones de los servidores DNS.

#	Consideraciones
1	Los servidores DNS en todos los nodos del clúster deben ser los mismos.
2	Los servidores DNS del intervalo de direcciones IP de la infraestructura deben ser los mismos que se usan para los nodos.
3	El plano de control de máquinas virtuales de Azure Resource Bridge y el plano de control de AKS usarán los servidores DNS configurados en el intervalo de direcciones IP de la infraestructura.
4	No se admite cambiar los servidores DNS después de la implementación. Asegúrese de planear la estrategia dns antes de realizar la implementación local de Azure.

Requisitos de proxy

Es más probable que se requiera un proxy para acceder a Internet dentro de la infraestructura local. Azure Local solo admite configuraciones de proxy no autenticadas. Dado que se requiere acceso a Internet para registrar los nodos en Azure Arc, la configuración del proxy debe establecerse como parte de la configuración del sistema operativo antes de que se registren los nodos de la máquina. Para obtener más información, consulte Definición de la configuración de proxy.

El sistema operativo Azure Stack HCI tiene tres servicios diferentes (WinInet, WinHTTP y variables de entorno) que requieren la misma configuración de proxy para asegurarse de que todos los componentes del sistema operativo pueden acceder a Internet. La misma configuración de proxy que se usa para los nodos se transfiere automáticamente a la máquina virtual de Arc Resource Bridge y AKS, lo que garantiza que tienen acceso a Internet durante la implementación.

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

#	Consideración
1	La configuración del proxy debe completarse antes de registrar los nodos en Azure Arc.
2	Se debe aplicar la misma configuración de proxy para las variables de entorno, WinHTTP y WinINET.
3	El Comprobador de entorno garantiza que la configuración del proxy sea coherente en todos los componentes del proxy.
4	El orquestador realiza automáticamente la configuración de proxy de la máquina virtual de Arc Resource Bridge y AKS durante la implementación.
5	Solo se admiten los servidores proxy no autenticados.

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 local de Azure para evaluar la preparación de la implementación para Azure Local.

Estas son las consideraciones resumidas para el firewall:

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

Paso 5: Determinar la configuración del adaptador de red

Los adaptadores de red están calificados por tipo de tráfico de red (administración, proceso y almacenamiento) con los que se usan. Al revisar el catálogo de Windows Server, la certificación de Windows Server 2022 indica para qué tráfico de red están calificados los adaptadores.

Antes de comprar una máquina para Azure Local, debe tener al menos un adaptador calificado 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.

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

• VLAN de almacenamiento: establezca este valor en las VLAN necesarias para el almacenamiento.
• Paquetes de Jumbo: define el tamaño de los paquetes de jumbo.
• Network Direct: establezca este valor en false si desea deshabilitar RDMA para los adaptadores de red.
• Tecnología directa de red: establezca este valor en RoCEv2 o iWarp.
• Prioridades de tráfico Puente del centro de datos (DCB): establezca las prioridades que se ajusten a sus requisitos. Se recomienda encarecidamente usar los valores de DCB predeterminados, ya que Microsoft y los clientes validan estos valores.

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

#	Consideración
1	Use las configuraciones predeterminadas tanto como sea posible.
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.
3	Asegúrese de que los adaptadores de red son compatibles con Azure Local mediante el catálogo de Windows Server.
4	Al aceptar los valores predeterminados, Network ATC configura automáticamente las direcciones IP y VLAN del adaptador de red de almacenamiento. Esto se conoce como configuración de 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.

Pasos siguientes

• Acerca de la implementación de Azure Local, versión 23H2.