Requisitos de rede física para Azure Stack HCI

Aplica-se a: Azure Stack HCI, versões 21H2 e 20H2

Este artigo aborda as considerações físicas e os requisitos de rede (malha) para Azure Stack HCI, especialmente para comutadores de rede.

Observação

Os requisitos para versões Azure Stack HCI futuras podem mudar.

Comutadores de rede para Azure Stack HCI

A Microsoft Azure Stack HCI os padrões e protocolos identificados na seção Requisitos de comu switch de rede abaixo. Embora a Microsoft não certifique os comutadores de rede, trabalhamos com fornecedores para identificar dispositivos que suportam Azure Stack HCI requisitos.

Esses requisitos também são publicados Windows especificações e políticas do programa de compatibilidade de hardware. Selecione Baixar Especificações, Windows Server 2022, abra o arquivo ZIP, abra Dispositivos e Componentes Requisitos de WHCP para Windows Server 2022.pdfe consulte a seção Device.Network.Switch.AzureStackHCI.

Importante

Embora outros comutadores de rede que usam tecnologias e protocolos não listados aqui possam funcionar, a Microsoft não pode garantir que eles funcionarão com Azure Stack HCI e podem não ser capazes de ajudar na solução de problemas que ocorrem.

Ao comprar comutadores de rede, entre em contato com o fornecedor do comutadores e verifique se os dispositivos atendem a todos os Azure Stack HCI requisitos. Os fornecedores a seguir (em ordem alfabética) confirmaram que suas opções são Azure Stack HCI requisitos:

Fornecedor 10 GbE 25 GbE 100 GbE 400 GbE
Dell Série S41xx Série S52xx Série S52xx
Lenovo G8272, NE1032 NE2572 NE10032
Juniper Networks

A versão 20.2R3-S2 ou posterior do Junos Software Service é necessária
Série QFX5110,série QFX5120,série QFX5200 Série QFX5120,série QFX5200 Série QFX5120,série QFX5200,série QFX5210, série QFX5220 Série QFX5130,série QFX5220

Importante

Atualizamos essa lista à medida que estamos informados sobre as alterações por fornecedores de com switch de rede.

Se a opção não estiver incluída, entre em contato com o fornecedor da opção para garantir que o modelo de opção e a versão do sistema operacional da opção deem suporte aos requisitos na próxima seção.

Requisitos do com switch de rede

Esta seção lista os padrões do setor que são obrigatórios para comutadores de rede usados em todas as Azure Stack HCI implantações. Esses padrões ajudam a garantir comunicações confiáveis entre nós em implantações Azure Stack HCI cluster.

Observação

Os adaptadores de rede usados para o tráfego de computação, armazenamento e gerenciamento exigem Ethernet. Para obter mais informações, consulte Requisitos de rede de host.

Aqui estão os padrões e especificações obrigatórios do IEEE:

Padrão: IEEE 802.1Q

Os comutadores Ethernet devem estar em conformidade com a especificação IEEE 802.1Q que define VLANs. As VLANs são necessárias para vários aspectos Azure Stack HCI e são necessárias em todos os cenários.

Padrão: IEEE 802.1Qbb

Os comutadores Ethernet devem estar em conformidade com a especificação IEEE 802.1Qbb que define o PFC (Priority Flow Control). PFC é necessário quando Data Center Bridging (DCB) é usado. Como o DCB pode ser usado em cenários RoCE e iWARP RDMA, o 802.1Qbb é necessário em todos os cenários. No mínimo, três prioridades de CoS (Classe de Serviço) são necessárias sem fazer downgrade das funcionalidades do comutador ou das velocidades de porta. Pelo menos uma dessas classes de tráfego deve fornecer comunicação sem perda.

Padrão: IEEE 802.1Qaz

Os comutadores Ethernet devem estar em conformidade com a especificação IEEE 802.1Qaz que define ETS (Seleção de Transmissão Aprimorada). O ETS é necessário no local em que o DCB é usado. Como o DCB pode ser usado em cenários RoCE e iWARP RDMA, 802.1Qaz é necessário em todos os cenários.

No mínimo, três prioridades de CoS são necessárias sem fazer downgrade das funcionalidades de opção ou da velocidade da porta. Além disso, se o dispositivo permitir que as taxas de QoS de entrada sejam definidas, recomendamos que você não configure as taxas de entrada ou configure-as exatamente com o mesmo valor que as taxas de ETS (saída).

Observação

A infraestrutura hiperconvergida tem uma alta dependência East-West comunicação de Camada 2 no mesmo rack e, portanto, requer ETS. A Microsoft não testa o Azure Stack HCI com Serviços Diferenciados code point (DSCP).

Padrão: IEEE 802.1AB

Os comutadores Ethernet devem estar em conformidade com a especificação IEEE 802.1AB que define o PROTOCOLO LLDP. O LLDP é necessário para Azure Stack HCI e permite a solução de problemas de configurações de rede física.

A configuração dos valores de comprimento de tipo LLDP (TLVs) deve ser habilitada dinamicamente. As opções não devem exigir configuração adicional além da habilitação de um TLV específico. Por exemplo, a habilitação do subtipo 3 802.1 deve anunciar automaticamente todas as VLANs disponíveis nas portas de comutação.

Requisitos de TLV personalizados

O LLDP permite que as organizações definam e codiem seus próprios TLVs personalizados. Eles são chamados de TLVs específicas organizacionais. Todos os TLVs específicos organizacionalmente começam com um valor de Tipo TLV LLDP de 127. A tabela a seguir mostra quais subtipos TLV personalizados específicos da organização (tipo TLV 127) são necessários:

Versão necessária Organização Subtipo TLV
20H2 e posterior IEEE 802.1 Nome da VLAN (subtipo = 3)
20H2 e posterior IEEE 802.3 Tamanho máximo do quadro (subtipo = 4)

Arquitetura e tráfego de rede

Esta seção é predominantemente para administradores de rede.

Azure Stack HCI pode funcionar em várias arquiteturas data center, incluindo 2 camadas (Leaf-2) e 3 camadas (Core-Aggregation-Access). Esta seção se refere mais aos conceitos da topologia Spine-Leaf que normalmente é usada com cargas de trabalho em infraestrutura hiperconvergida, como Azure Stack HCI.

Modelos de rede

O tráfego de rede pode ser classificado por sua direção. Ambientes de SAN (Rede de Área de Armazenamento) tradicionais são muito North-South em que o tráfego flui de uma camada de computação para uma camada de armazenamento em um limite de IP (Camada 3). A infraestrutura hiperconvergente é mais East-West em que uma parte substancial do tráfego permanece dentro de um limite de VLAN (Camada 2).

Importante

É altamente recomendável que todos os nós de cluster em um site sejam fisicamente localizados no mesmo rack e conectados aos mesmos comutadores ToR (topo de rack).

North-South tráfego para Azure Stack HCI

North-South tráfego tem as seguintes características:

  • O tráfego flui de uma opção ToR para a cabeça ou para dentro da cabeça para um comador ToR
  • O tráfego sai do rack físico ou cruza um limite de Camada 3 (IP)
  • Inclui gerenciamento (PowerShell, Windows Admin Center), computação (VM) e tráfego de cluster estendido entre sites
  • Usa um com switch Ethernet para conectividade com a rede física

East-West tráfego para Azure Stack HCI

East-West tráfego tem as seguintes características:

  • O tráfego permanece dentro dos comutadores ToR e do limite de camada 2 (VLAN)
  • Inclui tráfego de armazenamento ou Migração ao Vivo tráfego entre nós no mesmo cluster e (se estiver usando um cluster ampliado) dentro do mesmo site
  • Pode usar um comutador Ethernet (comutado) ou uma conexão direta (sem comutação), conforme descrito nas próximas duas seções.

Usando opções

North-South tráfego requer o uso de opções. Além de usar um comutador Ethernet que dá suporte aos protocolos necessários para Azure Stack HCI, o aspecto mais importante é o dimensionamento adequado da malha de rede.

É imperativo entender a largura de banda de malha "sem bloqueio" com a qual os comutadores de Ethernet podem dar suporte e que você minimize (ou, preferencialmente, elimine) a excesso de assinaturas da rede.

Os pontos de congestionamento comuns e a assinatura em excesso, como o grupo de agregação de link de vários chassis usado para a redundância de caminho, podem ser eliminados por meio do uso adequado de sub-redes e VLANs. Consulte também requisitos de rede do host.

Trabalhe com sua equipe de suporte de rede ou fornecedor de rede para garantir que os comutadores de rede tenham sido corretamente dimensionados para a carga de trabalho que você pretende executar.

Usando switching

Azure Stack HCI dá suporte a conexões sem switch (diretas) para tráfego de East-West para todos os tamanhos de cluster, desde que cada nó no cluster tenha uma conexão redundante para cada nó no cluster. Isso é chamado de conexão de "malha completa".

Diagrama mostrando conectividade alternada de malha completa

Par de interface Sub-rede VLAN
VNIC do host de gerenciamento Específico do cliente Específico do cliente
SMB01 192.168.71. x/24 711
SMB02 192.168.72. x/24 712
SMB03 192.168.73. x/24 713

Observação

Os benefícios das implantações sem switches diminuem com clusters maiores que três nós devido ao número de adaptadores de rede necessários.

Vantagens de conexões alternadas

  • Nenhuma compra de comutador é necessária para o tráfego de East-West. Uma opção é necessária para o tráfego de North-South. Isso pode resultar em custos de CAPEX (despesas de capital) menores, mas depende do número de nós no cluster.
  • Como não há nenhuma opção, a configuração é limitada ao host, o que pode reduzir o número potencial de etapas de configuração necessárias. Esse valor diminui à medida que o tamanho do cluster aumenta.

Desvantagens de conexões alternadas

  • Mais planejamento é necessário para esquemas de endereçamento de IP e sub-rede.
  • Fornece somente acesso de armazenamento local. O tráfego de gerenciamento, o tráfego de VM e outros tipos de tráfego que exigem acesso North-South não podem usar esses adaptadores.
  • À medida que o número de nós no cluster cresce, o custo dos adaptadores de rede pode exceder o custo do uso de comutadores de rede.
  • Não dimensiona muito além dos clusters de três nós. Mais nós incorrem em cabos e configurações adicionais que podem ultrapassar a complexidade do uso de um comutador.
  • A expansão do cluster é complexa, exigindo alterações de configuração de hardware e software.

Próximas etapas