Este artigo discute as considerações e os requisitos de rede física (malha) para o Azure Local, especialmente para comutadores de rede.
Observação
Os requisitos para versões futuras do Azure Local podem mudar.
Comutadores de rede para o Azure Local
A Microsoft testa o Azure Local para os padrões e protocolos identificados na seção Requisitos do comutador de rede abaixo. Embora a Microsoft não certifique comutadores de rede, trabalhamos com fornecedores para identificar dispositivos que dão suporte aos requisitos locais do Azure.
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 o Azure Local e pode não ser capaz de ajudar na solução de problemas que ocorrem.
Ao comprar comutadores de rede, entre em contato com o fornecedor do comutador e verifique se os dispositivos atendem aos requisitos locais do Azure para os tipos de função especificados. Os seguintes fornecedores (em ordem alfabética) confirmaram que seus comutadores dão suporte aos requisitos locais do Azure:
Clique em uma guia de fornecedor para ver os comutadores validados para cada um dos tipos de tráfego local do Azure. Essas classificações de rede podem ser encontradas aqui.
Importante
Atualizamos essas listas à medida que somos informados sobre as alterações dos fornecedores de switches 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 sejam compatíveis com os requisitos da próxima seção.
Broadcom Advanced Enterprise SONiC OS 4.2.1 ou posterior
✓
✓
✓
✓
Observação
O RDMA convidado requer computação (padrão) e armazenamento.
Requisitos do switch de rede
Esta seção lista os padrões do setor que são obrigatórios para as funções específicas dos comutadores de rede usados em implantações locais do Azure. Esses padrões ajudam a garantir comunicações confiáveis entre nós em implantações locais do Azure.
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 obrigatórios do IEEE:
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 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 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 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 ETS é 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 seu dispositivo permitir que as taxas de QoS de entrada sejam definidas, recomendamos que você não configure as taxas de entrada ou configure-as com exatamente o mesmo valor que as taxas de saída (ETS).
Observação
A infraestrutura hiperconvergente tem uma alta dependência da comunicação Leste-Oeste Camada 2 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 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 subtipo 802.1 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 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 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 de 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 links (subtipo = 7)
IEEE 802.1
Configuração ETS (subtipo = 9)
IEEE 802.1
Recomendação do CELE (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 máxima de transmissão (MTU) é o maior tamanho de quadro ou pacote que pode ser transmitido por um link de dados. Um intervalo de 1514 a 9174 é necessário para o encapsulamento SDN.
Border Gateway Protocol
Os comutadores Ethernet usados para o tráfego de computação SDN Local do Azure devem dar suporte ao BGP (Border Gateway Protocol). O 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 comutadores Ethernet usados para o tráfego de gerenciamento local do Azure devem dar 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
Requisitos de função 22H2
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 link LLDP
✓
✓
✓
✓
Configuração do ETS LLDP
✓
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 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 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 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 ETS é 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 seu dispositivo permitir que as taxas de QoS de entrada sejam definidas, recomendamos que você não configure as taxas de entrada ou configure-as com exatamente o mesmo valor que as taxas de saída (ETS).
Observação
A infraestrutura hiperconvergente tem uma alta dependência da comunicação Leste-Oeste Camada 2 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 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 subtipo 802.1 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 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 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 de 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 links (subtipo = 7)
IEEE 802.1
Configuração ETS (subtipo = 9)
IEEE 802.1
Recomendação do CELE (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
Novo requisito no 22H2
A unidade máxima de transmissão (MTU) é o maior tamanho de quadro ou pacote que pode ser transmitido por um link de dados. Um intervalo de 1514 a 9174 é necessário para o encapsulamento SDN.
Border Gateway Protocol
Novo requisito no 22H2
Os comutadores Ethernet usados para o tráfego de computação SDN Local do Azure devem dar suporte ao BGP (Border Gateway Protocol). O 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
Novo requisito no 22H2
Os comutadores Ethernet usados para o tráfego de gerenciamento local do Azure devem dar 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
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 aos 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 por sua direção. Os ambientes tradicionais de SAN (Storage Area Network, rede de área de armazenamento) 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 computadores locais do Azure em um site estejam fisicamente localizados no mesmo rack e conectados aos mesmos comutadores ToR (topo de rack).
Observação
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 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 Local
O tráfego Este-Oeste tem as seguintes características:
O tráfego permanece dentro dos switches ToR e do limite da Camada 2 (VLAN).
Inclui tráfego de armazenamento ou tráfego de migração dinâmica 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.
Uso de opções
O tráfego Norte-Sul requer o uso de interruptores. Além de usar um comutador Ethernet que dá suporte aos protocolos necessários para o Azure Local, o aspecto 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) o excesso de assinaturas da rede.
Pontos de congestionamento comuns e excesso de assinaturas, como o Grupo de Agregação de Enlace Multi-Chassis 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 comutadores de rede tenham sido dimensionados corretamente para a carga de trabalho que você pretende executar.
Usando sem comutador
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ó no sistema. Isso é chamado de conexão de "malha completa".
Par de interface
Sub-rede
VLAN
vNIC do host de gerenciamento
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 comutador diminuem com sistemas maiores que três nós devido ao número de adaptadores de rede necessários.
Vantagens das conexões sem switch
Nenhuma compra de switch é necessária para o tráfego leste-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 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 conexões sem switch
É necessário mais planejamento para esquemas de endereçamento de 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 aumenta, o custo dos adaptadores de rede pode exceder o custo do uso de comutadores de rede.
Não é dimensionado muito além dos 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 de configuração de hardware e software.
