Partilhar via

Requisitos de rede física para o Azure Local

  • Artigo

Aplica-se a: Azure Local 2311.2 e posterior

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

Nota

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

Comutadores de rede para o Azure Local

A Microsoft testa o Azure Local de acordo com os padrões e protocolos identificados na seção de 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 locais do Azure.

Importante

Embora outros comutadores de rede que utilizam tecnologias e protocolos não listados aqui possam funcionar, a Microsoft não pode garantir que irão trabalhar com o Azure Local e poderá não conseguir ajudar na resolução de problemas que ocorram.

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

Clique num separador de fornecedor para ver comutadores validados para cada um dos tipos de tráfego local do Azure. 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 do Azure Local. Esses padrões ajudam a garantir comunicações confiáveis entre os nós em implementações locais do Azure.

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

Requisito Gestão Armazenamento Computação (Padrão) Computação (SDN)
LANS virtuais ✓ ✓ ✓ ✓
Controle de fluxo prioritário ✓
Seleção de Transmissão Melhorada ✓
ID da VLAN da porta LLDP ✓
Nome da VLAN LLDP ✓ ✓ ✓
Agregação de links LLDP ✓ ✓ ✓ ✓
Configuração do LLDP ETS ✓
Recomendação do LLDP ETS ✓
Configuração do LLDP PFC ✓
Tamanho máximo do quadro LLDP ✓ ✓ ✓ ✓
Unidade de transmissão máxima ✓
Protocolo de Passagem de Fronteira (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 Local 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 local do Azure 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 diminuir as capacidades do comutador ou as velocidades das portas. 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 local do Azure devem estar em conformidade com a especificação IEEE 802.1Qaz que define o ETS (Enhanced Transmission Select). ETS é necessário onde é utilizado DCB. Como o DCB pode ser utilizado tanto em contextos de RoCE como de iWARP RDMA, o 802.1Qaz é necessário em todas as situações.

É necessário um mínimo de três prioridades CoS sem reduzir as funcionalidades do switch ou a velocidade da porta. Além disso, se o teu dispositivo permitir definir as taxas de QoS de entrada, recomendamos que não configures as taxas de entrada ou que as configures 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 Local 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 Local 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 dinamicamente habilitada. Os switches não devem exigir configuração adicional além da ativação de um TLV específico. Por exemplo, ativar o 802.1 Subtipo 3 deve divulgar 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.

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 ETS (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 Local do Azure devem dar 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 local do Azure 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 Local pode funcionar em várias arquiteturas de data center, incluindo 2 níveis (Spinha-Folha) e 3 níveis (Núcleo-Aggregação-Acesso). 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 Local.

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 orientada para Leste-Oeste, com uma parte substancial do tráfego a permanecer dentro de um limite de Camada 2 (VLAN).

Importante

É altamente recomendável que todas as máquinas locais do Azure em um site estejam fisicamente localizadas no mesmo rack e conectadas aos mesmos switches top-of-rack (ToR).

Nota

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

Tráfego Norte-Sul do Azure Local

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 Local

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 sistema 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 interruptores

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 Local, 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 sobresubscrição, 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

Azure Local dá suporte a ligações diretas (sem comutador) para o tráfego Este-Oeste para todos os tamanhos de sistema, desde que cada nó do sistema tenha uma ligação redundante com todos os nós do sistema. Isso é chamado de conexão de "malha completa".

Diagrama mostrando conectividade full-mesh sem switch

Par de interfaces Sub-rede VLAN
Host de Gestão 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 sistemas 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 menores custos de despesas de capital (CAPEX), mas depende do número de nós no sistema.
  • 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 sistema 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 sistema cresce, o custo dos adaptadores de rede pode exceder o custo do uso de switches de rede.
  • Não escala bem além de sistemas de três nós. Adicionar mais nós requer cablagem e configuração adicionais, o que pode ultrapassar a complexidade associada ao uso de um switch.
  • A expansão do sistema é complexa, exigindo alterações na configuração de hardware e software.

Próximos passos