Veja o padrão de referência de rede de implementação de ligações individuais sem comutador, tor duplo e sem comutador de armazenamento de três nós para o Azure Stack HCI

Artigo
05/17/2024

> 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 padrão de referência de rede de ligação única 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, lojas de retalho, sectores públicos e administração pública.

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 de Rede Definida pelo Software (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 o Quality of Service (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.
Dois NICs RDMA em cada nó numa configuração de ligação única de malha completa para East-West tráfego para o armazenamento.

Nota

Para esta configuração, não existe nenhuma ligação de rede redundante entre os nós.

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	Duas 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 três 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 uma configuração sem comutador de três nós, 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.
StorageAutoIP O parâmetro tem de ser definido como falso, Switchless o 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. As seguintes considerações aplicam-se a cada configuração:

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. equipa pNIC01 e 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.
Três sub-redes necessárias (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

Para obter mais informações, veja Deploy host networking with Network ATC (Implementar redes de anfitriões com o ATC de Rede).

Exemplo de configuração da rede da intenção de armazenamento do modelo arm

Pode utilizar o modelo arm para armazenamento de 3 nós sem comutação, TOR duplo e ligação única.

Eis um fragmento do modelo:

"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.2.1",
                        "subnetMask": "255.255.255.0"
                    }
                ]
            },
            {
                "name": "StorageNetwork2",
                "networkAdapterName": "SMB2",
                "vlanId": "711",
                "storageAdapterIPInfo": [
                    {
                        "physicalNode": "Node1",
                        "ipv4Address": "10.0.2.2",
                        "subnetMask": "255.255.255.0"
                    },
                    {
                        "physicalNode": "Node2",
                        "ipv4Address": "10.0.3.1",
                        "subnetMask": "255.255.255.0"
                    },
                    {
                        "physicalNode": "Node3",
                        "ipv4Address": "10.0.3.2",
                        "subnetMask": "255.255.255.0"
                    }
                ]
            }
        ]
      },

Partilhar via