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 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 em uma guia de fornecedor para ver opções validadas 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.
Broadcom Advanced Enterprise SONiC OS 4.2.1 ou posterior
✓
✓
✓
✓
Nota
O RDMA convidado requer computação (padrão) e armazenamento.
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 nós em implantações do Azure Local.
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:
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 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 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 local do Azure 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 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) 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 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
Requisitos de função 22H2
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 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 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 local do Azure 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 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) 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
Novo requisito em 22H2
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
Novo requisito em 22H2
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
Novo requisito em 22H2
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 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 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 fortemente Leste-Oeste, onde uma parte substancial do tráfego permanece 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 para o 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 o 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 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 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 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 Local dá suporte a conexões sem comutador (diretas) para tráfego Leste-Oeste para todos os tamanhos de sistema, desde que cada nó no sistema tenha uma conexão redundante com cada nó do sistema. Isso é chamado de conexão de "malha completa".
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 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 se dimensiona muito além de sistemas 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 sistema é complexa, exigindo alterações na configuração de hardware e software.
