Compartilhar via

Requisitos de rede física para o Azure Stack HCI

  • Artigo

Aplica-se a: Azure Stack HCI, versões 23H2 e 22H2

Este artigo discute considerações de rede física (malha) e requisitos para o Azure Stack HCI, especialmente para comutadores de rede.

Observação

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

Switches de rede para o Azure Stack HCI

A Microsoft testa o Azure Stack HCI de acordo com os padrões e protocolos identificados na seção Requisitos de comutador de rede abaixo. Embora a Microsoft não certifique comutadores de rede, trabalhamos com fornecedores para identificar dispositivos que oferecem suporte aos requisitos de HCI do Azure Stack.

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 funcionem com o Azure Stack HCI e talvez não consiga ajudar na solução de problemas que ocorrem.

Ao comprar comutadores de rede, entre em contato com o fornecedor do switch e verifique se os dispositivos atendem aos requisitos de HCI do Azure Stack para seus tipos de função especificados. Os seguintes fornecedores (em ordem alfabética) confirmaram que seus switches oferecem suporte aos requisitos do Azure Stack HCI:

Clique em uma guia do fornecedor para ver as opções validadas para cada um dos tipos de tráfego HCI do Azure Stack. Essas classificações de rede podem ser encontradas aqui.

Importante

Atualizamos essas listas à medida que somos informados sobre as alterações feitas pelos fornecedores de comutadores de rede.

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

Requisitos do comutador de rede

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

Observação

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

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

Requisitos de função 23H2

Requisito Gerenciamento Armazenamento Computação (Standard) Computação (SDN)
LANS virtuais ✓ ✓ ✓ ✓
Controle de Fluxo Prioritário ✓
Seleção de transmissão aprimorada ✓
ID da VLAN da porta LLDP ✓
Nome da VLAN LLDP ✓ ✓ ✓
Agregação de links LLDP ✓ ✓ ✓ ✓
Configuração do LLDP ETS ✓
Recomendação LLDP ETS ✓
Configuração do LLDP PFC ✓
Tamanho máximo do quadro LLDP ✓ ✓ ✓ ✓
Unidade Máxima de Transmissão ✓
Border Gateway Protocol ✓
Agente de Retransmissão DHCP ✓

Observação

O RDMA convidado requer computação (padrão) e armazenamento.

Padrão IEEE 802.1Q

Os switches 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 do Azure Stack HCI e são necessárias em todos os cenários.

Padrão: IEEE 802.1Qbb

Os switches Ethernet usados para o tráfego de armazenamento HCI do Azure Stack devem estar em conformidade com a especificação IEEE 802.1Qbb que define o PFC (Controle de Fluxo de Prioridade). O PFC é necessário onde o 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. Um mínimo de três prioridades de Classe de Serviço (CoS) são necessárias sem fazer downgrade dos recursos do switch ou das velocidades das portas. Pelo menos uma dessas classes de tráfego deve fornecer comunicação sem perdas.

Padrão: IEEE 802.1Qaz

Os switches Ethernet usados para o tráfego de armazenamento HCI do Azure Stack devem estar em conformidade com a especificação IEEE 802.1Qaz que define o ETS (Enhanced Transmission Select). O RCLE é necessário quando o DCB é usado. Como o DCB pode ser usado em cenários RoCE e iWARP RDMA, o 802.1Qaz é necessário em todos os cenários.

Um mínimo de três prioridades de CoS são necessárias sem fazer downgrade dos recursos do switch 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 saída (ETS).

Observação

A infraestrutura hiperconvergente tem uma alta dependência da comunicação Camada 2 Leste-Oeste dentro do mesmo rack e, portanto, requer ETS. A Microsoft não testa o Azure Stack HCI com DSCP (Ponto de Código de Serviços Diferenciados).

Padrão: IEEE 802.1AB

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

A configuração dos TLVs (Type-Length-Values) do LLDP deve ser habilitada dinamicamente. Os switches 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 do switch.

Requisitos de TLV personalizados

O LLDP permite que as organizações definam e codifiquem seus próprios TLVs personalizados. Eles são chamados de TLVs Específicos da Organização. Todos os TLVs específicos da organização começam com um valor LLDP TLV Type de 127. A tabela abaixo mostra quais subtipos de TLV personalizado específico da organização (TLV tipo 127) são necessários.

Organização Subtipo TLV
IEEE 802.1 ID da VLAN da porta (Subtipo = 1)
IEEE 802.1 Nome da VLAN (Subtipo = 3)
Mínimo de 10 VLANS
IEEE 802.1 Agregação de link (subtipo = 7)
IEEE 802.1 Configuração do ETS (Subtipo = 9)
IEEE 802.1 Recomendação do RCLE (Subtipo = A)
IEEE 802.1 Configuração do PFC (Subtipo = B)
IEEE 802,3 Tamanho máximo do quadro (subtipo = 4)

Unidade Máxima de Transmissão

A unidade de transmissão máxima (MTU) é o maior quadro ou pacote de tamanho que pode ser transmitido através de um link de dados. Um intervalo de 1514 - 9174 é necessário para o encapsulamento SDN.

Border Gateway Protocol

Os switches Ethernet usados para o tráfego de computação SDN HCI HCI do Azure devem oferecer suporte ao BGP (Border Gateway Protocol). BGP é um protocolo de roteamento padrão usado para trocar informações de roteamento e acessibilidade entre duas ou mais redes. As rotas são adicionadas automaticamente à tabela de rotas de todas as sub-redes com a propagação BGP habilitada. Isso é necessário para habilitar cargas de trabalho de locatário com SDN e emparelhamento dinâmico. RFC 4271: Protocolo de gateway de borda 4

Agente de Retransmissão DHCP

Os switches Ethernet usados para o tráfego de gerenciamento HCI do Azure Stack devem oferecer suporte ao agente de retransmissão DHCP. O agente de retransmissão DHCP é qualquer host TCP/IP usado para encaminhar solicitações e respostas entre o servidor DHCP e o cliente quando o servidor está presente em uma rede diferente. Ele é necessário para serviços de inicialização PXE. RFC 3046: DHCPv4 ou RFC 6148: DHCPv4

Arquitetura e tráfego de rede

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

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

Modelos de rede

O tráfego de rede pode ser classificado por sua direção. Os ambientes tradicionais de SAN (Storage Area Network, rede de armazenamento de dados) são fortemente norte-sul, onde o tráfego flui de uma camada de computação para uma camada de armazenamento através de um limite de Camada 3 (IP). A infraestrutura hiperconvergente é mais fortemente leste-oeste, onde uma parte substancial do tráfego permanece dentro de um limite de Camada 2 (VLAN).

Importante

É altamente recomendável que todos os nós de cluster em um site estejam fisicamente localizados no mesmo rack e conectados aos mesmos switches top-of-rack (ToR).

Observação

A funcionalidade de cluster estendido só está disponível no Azure Stack HCI, versão 22H2.

Tráfego Norte-Sul para o Azure Stack HCI

O tráfego Norte-Sul tem as seguintes características:

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

Tráfego Leste-Oeste para o Azure Stack HCI

O tráfego Leste-Oeste tem as seguintes características:

  • O tráfego permanece dentro dos switches ToR e do limite de Camada 2 (VLAN).
  • Inclui tráfego de armazenamento ou tráfego de migração ao vivo entre nós no mesmo cluster e (se estiver usando um cluster estendido) dentro do mesmo site.
  • Pode usar um switch Ethernet (comutado) ou uma conexão direta (switchless), conforme descrito nas próximas duas seções.

Uso de opções

O tráfego Norte-Sul requer o uso de switches. Além de usar um comutador Ethernet que ofereça suporte aos protocolos necessários para o Azure Stack HCI, o aspecto mais importante é o dimensionamento adequado da malha de rede.

É imprescindível entender a largura de banda de malha "sem bloqueio" que seus switches Ethernet podem suportar e que você minimize (ou, de preferência, elimine) o excesso de assinatura da rede.

Pontos comuns de congestionamento e sobreassinatura, como o Multi-Chassis Link Aggregation Group usado para 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 seu fornecedor de rede ou equipe de suporte de rede para garantir que seus switches de rede tenham sido dimensionados corretamente para a carga de trabalho que você pretende executar.

Usando switchless

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

Diagrama mostrando conectividade sem comutador de malha completa

Par de interfaces Sub-rede VLAN
Gerenciar vNIC do host Específico para o cliente Específico para o 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 switch diminuem com clusters maiores que três nós devido ao número de adaptadores de rede necessários.

Vantagens das conexões sem comutador

  • Nenhuma compra de switch é necessária para o tráfego Leste-Oeste. Um interruptor é necessário para o tráfego Norte-Sul. Isso pode resultar em custos de despesas de capital (CAPEX) mais baixos, mas depende do número de nós no cluster.
  • Como não há switch, 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 das conexões sem comutador

  • É necessário mais planejamento para esquemas de endereçamento IP e de sub-rede.
  • Fornece apenas acesso ao armazenamento local. O tráfego de gerenciamento, o tráfego de VM e outro tráfego que requer acesso Norte-Sul não podem usar esses adaptadores.
  • À medida que o número de nós no cluster aumenta, o custo dos adaptadores de rede pode exceder o custo do uso de comutadores de rede.
  • Não escala muito além de clusters de três nós. Mais nós incorrem em cabeamento e configuração adicionais que podem superar a complexidade do uso de um switch.
  • A expansão do cluster é complexa, exigindo alterações na configuração de hardware e software.

Próximas etapas