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 e requisitos de rede física (malha) para HCI do Azure Stack, particularmente para comutadores de rede.

Nota

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

Comutadores de rede para 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 suportam os requisitos de HCI do Azure Stack.

Importante

Embora outros switches de rede que usam tecnologias e protocolos não listados aqui possam funcionar, a Microsoft não pode garantir que eles funcionarão com o Azure Stack HCI e pode não conseguir 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 dão suporte aos requisitos do Azure Stack HCI:

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

Importante

Atualizamos estas listas à medida que somos informados das alterações 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 suportem os 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 switches de rede usados em implantações HCI do Azure Stack. Esses padrões ajudam a garantir comunicações confiáveis entre nós em implantações de cluster HCI do Azure Stack.

Nota

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

Aqui estão as normas e especificações IEEE obrigatórias:

Requisitos da função 23H2

Necessidade Gestão 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 do RCLE-Aprendizagem ao longo da vida ✓
Configuração do LLDP PFC ✓
Tamanho máximo do quadro LLDP ✓ ✓ ✓ ✓
Unidade de transmissão máxima ✓
Protocolo BGP ✓
Agente de Retransmissão DHCP ✓

Nota

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

Padrão: IEEE 802.1Qbb

Os comutadores 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 quando 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. É necessário um mínimo de três prioridades de Classe de Serviço (CoS) sem fazer downgrade dos recursos do switch ou das velocidades da porta. Pelo menos uma dessas classes de tráfego deve fornecer comunicação sem perdas.

Padrão: IEEE 802.1Qaz

Os comutadores 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 é utilizado DCB. Como o DCB pode ser usado em cenários RoCE e iWARP RDMA, o 802.1Qaz é necessário em todos os cenários.

É necessário um mínimo de três prioridades CoS sem fazer downgrade dos recursos do switch ou da velocidade da porta. Além disso, se o seu dispositivo permitir que as taxas de QoS de entrada sejam definidas, recomendamos que você não configure as taxas de entrada ou as configure exatamente com o mesmo valor das taxas de saída (ETS).

Nota

A infraestrutura hiperconvergente depende muito 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 Link Layer Discovery Protocol (LLDP). 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) LLDP deve ser habilitada dinamicamente. Os switches não devem exigir configuração adicional além da ativação de um TLV específico. Por exemplo, habilitar o 802.1 Subtipo 3 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 codificem seus próprios TLVs personalizados. Estes são chamados TLVs Organizacionais Específicos. Todos os TLVs específicos da organização começam com um valor de Tipo de TLV LLDP de 127. A tabela abaixo mostra quais subtipos de TLV personalizado específico da organização (TLV Tipo 127) são necessários.

Organization 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 RCLE (Subtipo = A)
IEEE 802,1 Configuração do PFC (Subtipo = B)
IEEE 802,3 Tamanho máximo do quadro (subtipo = 4)

Unidade de transmissão máxima

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

Protocolo BGP

Os comutadores Ethernet usados para o tráfego de computação SDN do Azure Stack HCI 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ários com SDN e emparelhamento dinâmico. RFC 4271: Protocolo 4 do Border Gateway

Agente de Retransmissão DHCP

Os comutadores 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. É necessário para serviços de inicialização PXE. RFC 3046: DHCPv4 ou RFC 6148: DHCPv4

Tráfego e arquitetura 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 se refere mais a 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 pela 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 um nível de computação para um nível 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).

Nota

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

Tráfego Norte-Sul para Azure Stack HCI

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

  • O tráfego flui de um interruptor ToR para a coluna ou da coluna para um interruptor ToR.
  • O tráfego sai do rack físico ou atravessa 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 switch Ethernet para conectividade com a rede física.

Tráfego Leste-Oeste para Azure Stack HCI

O tráfego Este-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 (sem switch), conforme descrito nas próximas duas seções.

Usando switches

O tráfego Norte-Sul exige a utilização de interruptores. Além de usar um switch Ethernet que suporta os protocolos necessários para o Azure Stack HCI, o aspeto mais importante é o dimensionamento adequado da malha de rede.

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

Pontos comuns de congestionamento e excesso de assinatura, 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 sem interruptor

O Azure Stack HCI dá suporte a conexões sem switch (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 completa".

Diagrama mostrando conectividade sem switch full-mesh

Par de interfaces Sub-rede VLAN
Mgmt host vNIC Específico ao cliente Específico ao cliente
SMB01 192.168.71.x/24 711
SMB02 192.168.72.x/24 712
SMB03 192.168.73.x/24 713

Nota

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 ligações sem comutador

  • Não é necessária a compra de interruptores para o tráfego Este-Oeste. É necessário um interruptor 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 ligações sem comutador

  • É necessário mais planeamento para esquemas de endereçamento IP e sub-rede.
  • Fornece apenas acesso ao armazenamento local. O tráfego de gerenciamento, o tráfego de VM e outros tráfegos que exigem acesso Norte-Sul 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 switches de rede.
  • Não é dimensionado 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óximos passos