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

Se aplica a: Azure Stack HCI, versión 23H2

En este artículo se describe cómo diseñar y planear una red del sistema de Azure Stack HCI, versión 23H2 para la implementación en la nube. Antes de continuar, familiarícese con los distintos patrones de red de Azure Stack HCI 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 el sistema de Azure Stack HCI: tamaño del clúster, conectividad de almacenamiento del clúster, 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 pasos posteriores:

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

Para ayudar a determinar el tamaño del sistema de Azure Stack HCI, use la herramienta sizer de Azure Stack HCI, 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 del servidor del sistema de Azure Stack HCI, el número máximo de servidores admitidos en el sistema de Azure Stack HCI 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 servidor necesarios para ejecutar cargas de trabajo en la infraestructura.

• Si las cargas de trabajo requieren cuatro o más nodos: no 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 del clúster de Azure Stack HCI, 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 Stack HCI.

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 conmutador a través de las plantillas de Azure Portal o ARM solo está disponible para clústeres de 1, 2 o 3 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 tiene previsto 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 Stack HCI 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 cruzados 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 la administración de 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 de 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 conmutador a través de Azure Portal o la implementación de plantillas de ARM 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 las plantillas de arm o Azure Portal. 3 clústeres sin conmutadores de almacenamiento de nodos solo se pueden implementar mediante plantillas de ARM. Las operaciones de escalado horizontal no se admiten con las implementaciones sin conmutador. 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 tiene previsto 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 Stack HCI, todas las implementaciones se basan en Network ATC para la configuración de red host. Las intenciones de red se configuran automáticamente al implementar Azure Stack HCI a través del Azure Portal. Para obtener más información sobre las intenciones de red y cómo solucionarlos, consulte Comandos comunes de ATC de red.

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 conmutadores, 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 necesitan 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.

• Si usa el conmutador de red para el almacenamiento, se usa un conmutador físico para RDMA.

• Se necesitan al menos 10 Gbps interfaces de red para admitir el tráfico RDMA para el almacenamiento.

Intención de red: Agrupación del 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, 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. Entre los escenarios de este segundo requisito de intención de proceso se 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 demás 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: Determinar la conectividad de red de 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 poder anticipar cualquier requisito de enrutamiento, firewall o subred.

Controladores de adaptador de red

Una vez que instale 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 del sistema de Azure Stack HCI, 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.
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.

Identificador de VLAN de administración

Se recomienda que la subred de administración del clúster de Azure HCI use la VLAN predeterminada, que en la mayoría de los casos se declara como id. 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 se debe hacer como parte de la configuración de arranque de los servidores 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 las VLAN del conmutador físico no se enrutan correctamente.

Identificador de VLAN de administración con un conmutador virtual

En algunos escenarios, hay un requisito para 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 necesario de Windows.

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 convención de nomenclatura recomendada

Las implementaciones de Azure Stack HCI 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.

Aunque no es necesario, se recomienda asignar un nombre a los conmutadores virtuales con la misma convención de nomenclatura. El nombre recomendado para los conmutadores virtuales es el siguiente:

• Nombre del conmutador virtual: "ConvergedSwitch($IntentName)", donde $IntentName puede ser cualquier cadena. Esta cadena debe coincidir con el nombre del adaptador de red virtual para la administración, tal y 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 descripción del propósito del conmutador virtual. La lista de nombres de adaptador de red es una lista de los adaptadores de red físicos que planea usar para la administración y el tráfico de red de proceso:

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

2. Configuración del adaptador de red virtual de administración mediante la convención de nomenclatura atC de red necesaria para todos los nodos

Una vez configurado el conmutador virtual, es necesario crear el adaptador de red virtual de administración. El nombre del adaptador de red virtual usado para el tráfico de administración debe usar la siguiente convención de nomenclatura:

• Nombre del adaptador de red y el adaptador de red virtual: vManagement($intentname).
• El 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.

Para actualizar el nombre del adaptador de red virtual de administración, use el siguiente comando:

$IntentName = "MgmtCompute"
Add-VMNetworkAdapter -ManagementOS -SwitchName "ConvergedSwitch($IntentName)" -Name "vManagement($IntentName)"

#NetAdapter needs to be renamed because during creation, Hyper-V adds the string “vEthernet “ to the beginning of the name

Rename-NetAdapter -Name "vEthernet (vManagement($IntentName))" -NewName "vManagement($IntentName)"

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

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

4. Referencia de 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 usados 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 (ARM). 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 los servidores con Azure Arc.
2	Use pasos específicos cuando se requiera un conmutador virtual antes de registrar los servidores 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 id. de VLAN para Azure Portal implementación o para la implementación de plantillas de ARM.

Asignación de IP de nodo y clúster

Para el sistema Azure Stack HCI, tiene dos opciones para asignar direcciones IP para los nodos de servidor 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 dirección 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 a la dirección IP del clúster automáticamente 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 servidor 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é 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 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 necesitando direcciones IP estáticas, lo que implica que el intervalo de direcciones del grupo de DIRECCIONES 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 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 definición de 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 dirección IP de administración. Por lo tanto, es importante crear una reserva DHCP para la dirección IP del nodo.

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 las direcciones IP del 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.

Requisitos de proxy

Es más probable que se requiera un proxy para acceder a Internet dentro de la infraestructura local. Azure Stack HCI solo admite configuraciones de proxy no autenticadas. Dado que se requiere acceso a Internet para registrar los nodos en Azure Arc, la configuración de proxy debe establecerse como parte de la configuración del sistema operativo antes de que se registren los nodos del servidor. Para obtener más información, consulte Configuración de los valores 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 garantizar que todos los componentes del sistema operativo puedan 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 WinINET, WinHTTP y variables de entorno.
3	El Comprobador de entorno garantiza que la configuración del proxy sea coherente en todos los componentes de proxy.
4	El orquestador realiza automáticamente la configuración del 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, debe abrir varios puntos de conexión de Internet en los firewalls para asegurarse de que Azure Stack HCI 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 del entorno de Azure Stack HCI para evaluar la preparación de la implementación para Azure Stack HCI.

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: Determinación de 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 un servidor para Azure Stack HCI, 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 Stack HCI. 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 ARM 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 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 RoCEv2 en 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 Stack HCI.
3	Asegúrese de que los adaptadores de red son compatibles con Azure Stack HCI 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 ARM.

Pasos siguientes

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