Requisitos de rede física para o Azure Stack HCI
Aplica-se a: Azure Stack HCI, versões 23H2 e 22H2
Este artigo discute considerações e requisitos de rede físicas (malha) para o Azure Stack HCI, especialmente para comutadores de rede.
Observação
Os requisitos para versões futuras do Azure Stack HCI podem ser alterados.
Comutadores de rede para o Azure Stack HCI
A Microsoft testa o Azure Stack HCI para os padrões e protocolos identificados na seção Requisitos de comutador de rede abaixo. Embora a Microsoft não certifique as opções de rede, trabalhamos com fornecedores para identificar dispositivos que dão suporte aos requisitos do Azure Stack HCI.
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 Stack HCI e talvez não consigam ajudar na solução de problemas que ocorrem.
Ao comprar comutadores de rede, entre em contato com o fornecedor de comutador e verifique se os dispositivos atendem aos requisitos do Azure Stack HCI para seus tipos de função especificados. Os seguintes fornecedores (em ordem alfabética) confirmaram que suas opções dão 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 do Azure Stack HCI. Essas classificações de rede podem ser encontradas aqui.
Importante
Atualizamos essas listas conforme somos informados de alterações por fornecedores de comutador de rede.
Se a opção não estiver incluída, entre em contato com o fornecedor de comutador para garantir que o modelo de comutador e a versão do sistema operacional do comutador sejam compatíveis com os requisitos na próxima seção.
Requisitos de comutador de rede
Esta seção lista os padrões do setor obrigatórios para as funções específicas de comutadores de rede usadas 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 do Azure Stack HCI.
Observação
Os adaptadores de rede usados para computação, armazenamento e tráfego de gerenciamento exigem Ethernet. Para obter mais informações, consulte Requisitos de rede de host.
Aqui estão os padrões e especificações obrigatórios do IEEE:
Requisitos de função 23H2
| Requisito | Gerenciamento | Armazenamento | Computação (Standard) | Computação (SDN) |
|---|---|---|---|---|
| LANS Virtuais | ✓ | ✓ | ✓ | ✓ |
| Controle de fluxo de prioridade | ✓ | |||
| Seleção de transmissão aprimorada | ✓ | |||
| ID da VLAN da porta LLDP | ✓ | |||
| Nome da VLAN do LLDP | ✓ | ✓ | ✓ | |
| Agregação de link do LLDP | ✓ | ✓ | ✓ | ✓ |
| Configuração de ETS do LLDP | ✓ | |||
| Recomendação de ETS do LLDP | ✓ | |||
| Configuração do LLDP PFC | ✓ | |||
| Tamanho máximo do quadro LLDP | ✓ | ✓ | ✓ | ✓ |
| Unidade de Transmissão Máxima | ✓ | |||
| Border Gateway Protocol | ✓ | |||
| Agente de Retransmissão DHCP | ✓ |
Observação
O RDMA convidado requer Computação (Standard) e Armazenamento.
Padrão: IEEE 802.1Q
Os comutadores 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 comutadores Ethernet usados para o tráfego de armazenamento do Azure Stack HCI 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 a DCB (Ponte do Data Center) é usada. Como o DCB pode ser usado em cenários de RDMA roCE e iWARP, 802.1Qbb é necessário em todos os cenários. Um mínimo de três prioridades de CoS (Classe de Serviço) são necessárias sem fazer downgrade dos recursos de comutador 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 do Azure Stack HCI devem estar em conformidade com a especificação IEEE 802.1Qaz que define ETS (Seleção de Transmissão Aprimorada). O ETS é necessário onde o DCB é usado. Como o DCB pode ser usado em cenários de RDMA roCE e iWARP, 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 de comutador 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 East-West Camada 2 dentro do mesmo rack e, portanto, requer ETS. A Microsoft não testa o Azure Stack HCI com o DSCP (Ponto de Código de Serviços Diferenciados).
Padrão: IEEE 802.1AB
Os comutadores Ethernet devem estar em conformidade com a especificação IEEE 802.1AB que define o PROTOCOLO LLDP (Protocolo de Descoberta de Camada de Link). 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 das TLVs (Type-Length-Values) do LLDP deve ser habilitada dinamicamente. As opções não devem exigir configuração adicional além da habilitação de um TLV específico. Por exemplo, habilitar o Subtipo 802.1 3 deve anunciar automaticamente todos os VLANs disponíveis nas portas de comutador.
Requisitos de TLV personalizados
O LLDP permite que as organizações definam e codifiquem suas próprias TLVs personalizadas. Elas são chamadas de TLVs específicas da organização. Todas as TLVs específicas da organização começam com um valor de Tipo TLV do LLDP de 127. A tabela a seguir mostra quais subtipos TLV personalizados específicos da organização (tipo TLV 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 de 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 MTU (unidade de transmissão máxima) é o quadro ou pacote de maior tamanho que pode ser transmitido por um link de dados. Um intervalo de 1514 a 9174 é necessário para encapsulamento de SDN.
Border Gateway Protocol
Os comutadores Ethernet usados para o tráfego de computação do SDN do Azure Stack HCI 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: Border Gateway Protocol 4
Agente de Retransmissão DHCP
Os comutadores Ethernet usados para o tráfego de gerenciamento do Azure Stack HCI devem dar suporte ao agente de retransmissão DHCP. O agente de retransmissão DHCP é qualquer host TCP/IP que é 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 de rede e arquitetura
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 a conceitos da topologia Spine-Leaf que normalmente é 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 san (rede de área de armazenamento) tradicionais são muito North-South em que o tráfego flui de uma camada de computação para uma camada de armazenamento em um limite de Camada 3 (IP). A infraestrutura hiperconvergente é mais fortemente East-West em que 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 comutadores ToR (topo de rack).
North-South tráfego para o Azure Stack HCI
North-South tráfego tem as seguintes características:
- O tráfego flui de uma opção tor para a coluna vertebral ou para dentro da coluna vertebral para um comutador ToR.
- O tráfego deixa o rack físico ou cruza um IP (limite de Camada 3).
- 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.
East-West tráfego para o Azure Stack HCI
East-West tráfego tem as seguintes características:
- O tráfego permanece dentro dos comutadores ToR e do limite de Camada 2 (VLAN).
- Inclui o tráfego de armazenamento ou o tráfego de Migração Dinâmica entre nós no mesmo cluster e (se estiver usando um cluster estendido) no mesmo site.
- Pode usar um comutador Ethernet (alternado) ou uma conexão direta (sem comutador), conforme descrito nas próximas duas seções.
Usando comutadores
North-South tráfego requer o uso de comutadores. Além de usar um comutador Ethernet que dá suporte aos protocolos necessários para o Azure Stack HCI, o aspecto mais importante é o dimensionamento adequado da malha de rede.
É imperativo entender a largura de banda de malha "sem bloqueio" que as opções Ethernet podem dar suporte e que você minimize (ou, preferencialmente, elimine) a sobrescrição da rede.
Pontos de congestionamento comuns e sobrescritação, como o Grupo de Agregação de Link de Vários 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 de 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 alternância
O Azure Stack HCI dá suporte a conexões sem alternância (diretas) para East-West tráfego 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".
| Par de interfaces | Sub-rede | VLAN |
|---|---|---|
| Mgmt host vNIC | Específico do cliente | Específico do 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 alternância diminuem com clusters maiores que três nós devido ao número de adaptadores de rede necessários.
Vantagens das conexões sem alternância
- Nenhuma compra de comutador é necessária para East-West tráfego. Uma opção é necessária para North-South tráfego. Isso pode resultar em custos de CAPEX (despesas de capital mais baixas), mas depende do número de nós no cluster.
- Como não há opção, 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 alternância
- É necessário mais planejamento para esquemas de endereçamento de IP e sub-rede.
- Fornece apenas acesso de armazenamento local. O tráfego de gerenciamento, o tráfego de VM e outros tráfegos que exigem acesso North-South 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 de usar comutadores 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 de usar um comutador.
- A expansão do cluster é complexa, exigindo alterações de configuração de hardware e software.
Próximas etapas
- Consulte Implantar usando portal do Azure.
- Confira Implantar usando o modelo do ARM.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de