Revise el patrón de referencia de red de implementación de doble vínculo para Azure Stack HCI sin conmutadores de almacenamiento de tres nodos, doble TOR y doble vínculo.
> Se aplica a: Azure Stack HCI, versión 23H2 y posteriores
En este artículo, obtendrá información sobre el almacenamiento de tres nodos sin conmutadores con dos conmutadores TOR L3 y dos patrones de referencia de red de vínculos de malla completa que puede usar para implementar la solución de Azure Stack HCI.
Nota
Microsoft ha probado y validado los patrones de referencia de red sin conmutadores de 3 nodos descritos en este artículo. Para más información sobre los patrones de red sin conmutador de dos nodos, consulte Patrones de implementación de red de Azure Stack HCI.
Escenarios
Entre los escenarios de este patrón de red se incluyen laboratorios, fábricas, sucursales y centros de datos.
Considere la posibilidad de implementar este patrón al buscar una solución rentable que tenga tolerancia a errores en todos los componentes de red. Los servicios L3 de SDN son totalmente compatibles con este patrón. Los servicios de enrutamiento como el Protocolo de puerta de enlace de borde (BGP) se pueden configurar directamente en los conmutadores TOR si admiten servicios L3. Las características de seguridad de red, como la microsegmentación o QoS, no requieren una configuración adicional del dispositivo de firewall, ya que se implementan en la capa del adaptador de red virtual.
Componentes de conectividad física
Como se muestra en el diagrama anterior, este patrón tiene los siguientes componentes de red físicos:
Para la comunicación de entrada norte y sur, el clúster de Azure Stack HCI requiere dos conmutadores TOR en la configuración del grupo de agregación de vínculos de varios chasis (MLAG).
Dos tarjetas de red que usan el conmutador virtual SET para controlar el tráfico de administración y proceso, conectados a los conmutadores TOR. Cada NIC está conectada a un TOR diferente.
Cuatro NIC RDMA en cada nodo de una configuración de vínculo dual de malla completa para East-West tráfico para el almacenamiento. Cada nodo del clúster tiene una conexión redundante con dos rutas de acceso al otro nodo del clúster.
Redes | Administración y proceso | Storage |
---|---|---|
Velocidad del vínculo | Al menos 1 GBps. Se recomiendan 10 GBps | Al menos 10 GBps |
Tipo de interfaz | RJ45, SFP+ o SFP28 | SFP+ o SFP28 |
Puertos y agregación | Dos puertos agrupados | Cuatro puertos independientes |
Redes lógicas
Como se muestra en el diagrama siguiente, este patrón tiene los siguientes componentes de red lógicos:
Redes de interconexión de nodos VLAN para el tráfico SMB (almacenamiento y migración en vivo)
El tráfico basado en intenciones de Storage consta de seis subredes individuales que admiten el tráfico RDMA. Cada interfaz está dedicada a una red de interconexión de nodos independiente. Este tráfico solo está pensado para viajar entre los tres nodos. El tráfico de almacenamiento en estas subredes está aislado sin conectividad con otros recursos.
Cada par de adaptadores de almacenamiento entre los nodos funciona en subredes IP diferentes. Para habilitar una configuración sin conmutador, cada nodo conectado admite la misma subred coincidente de su vecino.
Al implementar tres nodos en una configuración sin conmutadores, Network ATC tiene los siguientes requisitos:
Solo admite una sola VLAN para todas las subredes IP usadas para la conectividad de almacenamiento.
StorageAutoIP
el parámetro debe establecerse en false,Switchless
el parámetro debe establecerse en true y es responsable de especificar las direcciones IP de la plantilla de ARM que se usan para implementar el clúster de Azure Stack HCI desde Azure.Para las implementaciones en la nube de Azure Stack HCI, versión 23H2:
No se admiten clústeres sin conmutadores de almacenamiento horizontal.
Solo es posible implementar este escenario de tres nodos mediante plantillas de ARM.
Para más información, consulte Implementación a través de una plantilla de implementación de Azure Resource Manager.
VLAN de administración
Todos los hosts de proceso físicos deben acceder a la red lógica de administración. Para fines de planeamiento de direcciones IP, cada host debe tener al menos una dirección IP asignada desde la red lógica de administración.
Un servidor DHCP puede asignar automáticamente direcciones IP para la red de administración, o el usuario puede asignar direcciones IP estáticas de forma manual. Cuando DHCP es el método de asignación de IP preferido, se recomiendan las reservas DHCP sin expiración.
Para más información, consulte Consideraciones de red DHCP para la implementación en la nube.
La red de administración admite dos configuraciones de VLAN diferentes para el tráfico: nativo y etiquetado:
La VLAN nativa para la red de administración no requiere que proporcione un identificador de VLAN.
La VLAN etiquetada para la red de administración requiere la configuración del identificador de VLAN en los adaptadores de red físicos o en el adaptador de red virtual de administración antes de registrar los nodos en Azure Arc.
Los puertos de conmutador físico deben configurarse correctamente para aceptar el identificador de VLAN en los adaptadores de administración.
Si la intención incluye tipos de tráfico de administración y proceso, los puertos de conmutador físico deben configurarse en modo tronco para aceptar todas las VLAN necesarias para la administración y las cargas de trabajo de proceso.
La red de administración admite el tráfico utilizado por el administrador para la administración del clúster, incluido Escritorio remoto, Windows Admin Center y Active Directory.
Para más información, consulte Consideraciones sobre la red VLAN de administración.
VLAN de proceso
En algunos escenarios, no es necesario usar redes virtuales de SDN con encapsulación VXLAN. En su lugar, puede usar VLAN tradicionales para aislar sus cargas de trabajo de inquilino. Esas VLAN deben configurarse en el puerto de conmutadores TOR en modo tronco. Al conectar nuevas máquinas virtuales a estas VLAN, la etiqueta VLAN correspondiente se define en el adaptador de red virtual.
Red HNV Provider Address (PA)
La red del proveedor de virtualización de red de Hyper-V (HNV PA) actúa como la red física subyacente para el tráfico de inquilinos de East-West (interno interno), North-South (interno externo) y para intercambiar información de emparejamiento BGP con la red física. Esta red solo es necesaria cuando es necesario implementar redes virtuales mediante la encapsulación de VXLAN para una capa adicional de aislamiento y multiinquilino de red.
Para obtener más información, consulte Planear una infraestructura de red definida por software.
Intenciones de ATC de red
En el caso de los patrones sin conmutadores de almacenamiento de tres nodos, se crean dos intenciones de ATC de red. La primera intención es para la administración y el tráfico de red de proceso, y la segunda intención es para el tráfico de almacenamiento.
Intención de administración y proceso
- Tipo de intención: Administración y proceso
- Modo de intención: modo de clúster
- Formación de equipos: Sí. equipo de pNIC01 y pNIC02.
- VLAN de administración predeterminada: no se modifica la VLAN configurada para adaptadores de administración.
- VLAN y VLAN de proceso y VNIC de proceso: Network ATC es transparente para vNIC pa y VLAN o VNIC de máquina virtual de proceso y VNIC y VLAN.
Intención de almacenamiento
Tipo de intención: Storage
Modo de intención: modo de clúster
Formación de equipos: No. Las NIC RDMA usan SMB multicanal para proporcionar resistencia y agregación de ancho de banda.
VLAN predeterminados: VLAN única para todas las subredes.
IP automática de almacenamiento: False. Este patrón requiere la configuración manual de IP o la definición de IP de plantilla de ARM.
Seis subredes necesarias (definidas por el usuario):
- Red de almacenamiento 1: 10.0.1.0/24 –
Node1 -> Node2
- Red de almacenamiento 2: 10.0.2.0/24 –
Node1 -> Node2
- Red de almacenamiento 3: 10.0.3.0/24 –
Node2 -> Node3
- Red de almacenamiento 4: 10.0.4.0/24 –
Node1 -> Node3
- Red de almacenamiento 5: 10.0.5.0/24 –
Node1 -> Node3
- Red de almacenamiento 6: 10.0.6.0/24 –
Node2 -> Node3
- Red de almacenamiento 1: 10.0.1.0/24 –
Para más información, consulte Implementación de redes de host con Network ATC.
Ejemplo de configuración de redes de intención de almacenamiento de plantillas de ARM
Puede usar la plantilla de ARM para el almacenamiento sin conmutadores de 3 nodos, tor dual y vínculo dual.
"storageNetworkList": {
"value": [
{
"name": "StorageNetwork1",
"networkAdapterName": "SMB1",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.1.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.1.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.5.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork2",
"networkAdapterName": "SMB2",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.2.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.2.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.4.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork3",
"networkAdapterName": "SMB3",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.5.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.3.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.3.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork4",
"networkAdapterName": "SMB4",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.4.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.6.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.6.3",
"subnetMask": "255.255.255.0"
}
]
}
]
},