Reveja o padrão de referência de rede de implementação de ligações duplas, sem comutadores e sem comutadores de armazenamento de três nós para o Azure Stack HCI
> Aplica-se a: Azure Stack HCI, versão 23H2 e posterior
Neste artigo, saiba mais sobre o armazenamento de três nós sem comutação com dois comutadores TOR L3 e dois padrões de referência de rede de ligações de malha completa que pode utilizar para implementar a sua solução do Azure Stack HCI.
Nota
Os padrões de referência de rede sem comutação de 3 nós descritos neste artigo foram testados e validados pela Microsoft. Para obter informações sobre padrões de rede sem comutadores de dois nós, veja Padrões de implementação de rede do Azure Stack HCI.
Cenários
Os cenários para este padrão de rede incluem laboratórios, fábricas, sucursais e datacenters.
Considere implementar este padrão ao procurar uma solução económica que tenha tolerância a falhas em todos os componentes de rede. Os serviços SDN L3 são totalmente suportados neste padrão. Os serviços de encaminhamento, como o Protocolo BGP (Border Gateway Protocol), podem ser configurados diretamente nos comutadores TOR se suportarem serviços L3. As funcionalidades de segurança de rede, como a micro segmentação ou qoS, não necessitam de configuração adicional do dispositivo de firewall, uma vez que são implementadas na camada de placa de rede virtual.
Componentes de conectividade física
Conforme ilustrado no diagrama acima, este padrão tem os seguintes componentes de rede física:
Para a comunicação para norte e para sul, o cluster do Azure Stack HCI necessita de dois comutadores TOR na configuração do grupo de agregação de ligações multi chassis (MLAG).
Duas placas de rede que utilizam o comutador virtual SET para processar o tráfego de gestão e computação, ligados aos comutadores TOR. Cada NIC está ligada a um TOR diferente.
Quatro NICs RDMA em cada nó numa configuração de ligação dupla de malha completa para East-West tráfego para o armazenamento. Cada nó no cluster tem uma ligação redundante com dois caminhos para o outro nó no cluster.
| Redes | Gestão e computação | Armazenamento |
|---|---|---|
| Velocidade da ligação | Pelo menos 1 GBps. 10 GBps recomendados | Pelo menos 10 GBps |
| Tipo de interface | RJ45, SFP+ ou SFP28 | SFP+ ou SFP28 |
| Portas e agregação | Duas portas em equipa | Quatro portas autónomas |
Logical networks
Conforme ilustrado no diagrama abaixo, este padrão tem os seguintes componentes de rede lógica:
VLAN de redes de interligação de nós para tráfego SMB (Armazenamento e migração em direto)
O tráfego baseado na intenção de Armazenamento consiste em seis sub-redes individuais que suportam o tráfego RDMA. Cada interface é dedicada a uma rede de interligação de nós separada. Este tráfego destina-se apenas a viajar entre os três nós. O tráfego de armazenamento nestas sub-redes é isolado sem conectividade a outros recursos.
Cada par de adaptadores de armazenamento entre os nós funciona em sub-redes IP diferentes. Para ativar uma configuração sem comutação, cada nó ligado suporta a mesma sub-rede correspondente do respetivo vizinho.
Ao implementar três nós numa configuração sem comutadores, o ATC de Rede tem os seguintes requisitos:
Suporta apenas uma VLAN única para todas as sub-redes IP utilizadas para a conectividade de armazenamento.
StorageAutoIPO parâmetro tem de ser definido como falso,Switchlesso parâmetro tem de ser definido como verdadeiro e é responsável por especificar os IPs no modelo do ARM utilizado para implementar o cluster do Azure Stack HCI a partir do Azure.Para o Azure Stack HCI, versão 23H2, implementações na cloud:
Os clusters sem comutadores de armazenamento horizontal não são suportados.
Só é possível implementar este cenário de três nós com modelos arm.
Para obter mais informações, veja Implementar através do modelo de implementação do Azure Resource Manager.
VLAN de Gestão
Todos os anfitriões de computação física têm de aceder à rede lógica de gestão. Para fins de planeamento de endereços IP, cada anfitrião tem de ter, pelo menos, um endereço IP atribuído a partir da rede lógica de gestão.
Um servidor DHCP pode atribuir automaticamente endereços IP para a rede de gestão ou pode atribuir manualmente endereços IP estáticos. Quando DHCP é o método de atribuição de IP preferencial, são recomendadas reservas DHCP sem expiração.
Para obter informações, veja Considerações sobre a Rede DHCP para a implementação na cloud.
A rede de gestão suporta duas configurações de VLAN diferentes para o tráfego – Nativo e Etiquetado:
A VLAN nativa para a rede de gestão não requer que forneça um ID de VLAN.
A VLAN etiquetada para a rede de gestão requer a configuração do ID de VLAN nas placas de rede físicas ou na placa de rede virtual de gestão antes de registar os nós no Azure Arc.
As portas do comutador físico têm de ser configuradas corretamente para aceitar o ID de VLAN nos adaptadores de gestão.
Se a intenção incluir tipos de tráfego de gestão e computação, as portas de comutador físico têm de ser configuradas no modo de ramal para aceitar todas as VLANs necessárias para cargas de trabalho de gestão e computação.
A rede de Gestão suporta o tráfego utilizado pelo administrador para a gestão do cluster, incluindo Ambiente de Trabalho Remoto, Windows Admin Center e Active Directory.
Para obter mais informações, veja Management VLAN network considerations (Considerações de rede da VLAN de Gestão).
VLANs de Computação
Em alguns cenários, não precisa de utilizar Redes Virtuais SDN com encapsulamento VXLAN. Em vez disso, pode utilizar VLANs tradicionais para isolar as respetivas cargas de trabalho de inquilino. Essas VLANs têm de ser configuradas na porta de comutadores TOR no modo de ramal. Ao ligar novas máquinas virtuais a estas VLANs, a etiqueta VLAN correspondente é definida na placa de rede virtual.
Rede de Endereços do Fornecedor (PA) HNV
A rede Endereço do Fornecedor de Virtualização de Rede Hyper-V (HNV PA) serve como a rede física subjacente para o tráfego de inquilino East-West (interno-interno), North-South tráfego de inquilino (externo-interno) e para trocar informações de peering BGP com a rede física. Esta rede só é necessária quando é necessário implementar redes virtuais com o encapsulamento VXLAN para uma camada extra de isolamento e multi-inquilino de rede.
Para obter mais informações, veja Planear uma infraestrutura de Rede Definida pelo Software.
Intenções de ATC de Rede
Para padrões sem comutador de armazenamento de três nós, são criadas duas intenções de ATC de Rede. A primeira intenção é o tráfego de rede de computação e gestão e a segunda intenção é o tráfego de armazenamento.
Intenção de gestão e computação
- Tipo de intenção: Gestão e Computação
- Modo de intenção: modo de cluster
- Agrupamento: Sim. pNIC01 e equipa pNIC02.
- VLAN de gestão predefinida: a VLAN configurada para adaptadores de gestão não é modificada.
- PA e VLANs de computação e vNICs: o ATC de Rede é transparente para vNICs pa e VLAN ou vNICs de VM de computação e VLANs.
Intenção de armazenamento
Tipo de intenção: Armazenamento
Modo de intenção: modo de cluster
Agrupamento: Não. As NICs RDMA utilizam o SMB Multicanal para fornecer resiliência e agregação de largura de banda.
VLANs predefinidas: VLAN única para todas as sub-redes.
IP Automático de Armazenamento: Falso. Este padrão requer a configuração de IP manual ou a definição de IP do modelo arm.
São necessárias seis sub-redes (definidas pelo utilizador):
- Rede de Armazenamento 1: 10.0.1.0/24 –
Node1 -> Node2 - Rede de Armazenamento 2: 10.0.2.0/24 –
Node1 -> Node2 - Rede de Armazenamento 3: 10.0.3.0/24 –
Node2 -> Node3 - Rede de Armazenamento 4: 10.0.4.0/24 –
Node1 -> Node3 - Rede de Armazenamento 5: 10.0.5.0/24 –
Node1 -> Node3 - Rede de Armazenamento 6: 10.0.6.0/24 –
Node2 -> Node3
- Rede de Armazenamento 1: 10.0.1.0/24 –
Para obter mais informações, veja Deploy host networking with Network ATC (Implementar redes de anfitriões com o ATC de Rede).
Modelo arm Exemplo de configuração de redes de intenções de armazenamento
Pode utilizar o modelo arm para armazenamento de 3 nós sem comutador, TOR duplo e ligação dupla.
"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"
}
]
}
]
},
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários