Requisitos de rede física para o Azure Stack HCI
Aplica-se a: Azure Stack HCI, versões 23H2 e 22H2
Este artigo aborda considerações e requisitos de rede físicos (recursos de infraestrutura) para o Azure Stack HCI, especialmente para comutadores de rede.
Nota
Os requisitos para futuras versões do Azure Stack HCI podem ser alterados.
Comutadores de rede para o Azure Stack HCI
A Microsoft testa o Azure Stack HCI para as normas e protocolos identificados na secçã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 do Azure Stack HCI.
Importante
Embora outros comutadores de rede que utilizem tecnologias e protocolos não listados aqui possam funcionar, a Microsoft não pode garantir que irá trabalhar com o Azure Stack HCI e poderá não conseguir ajudar na resolução de problemas que ocorrem.
Ao comprar comutadores de rede, contacte o fornecedor do comutador e certifique-se de que os dispositivos cumprem os requisitos do Azure Stack HCI para os tipos de função especificados. Os seguintes fornecedores (por ordem alfabética) confirmaram que os respetivos comutadores suportam os requisitos do Azure Stack HCI:
Clique num separador de fornecedor para ver comutadores validados para cada um dos tipos de tráfego do Azure Stack HCI. Estas classificações de rede podem ser encontradas aqui.
Importante
Atualizamos estas listas à medida que somos informados das alterações feitas pelos fornecedores de comutadores de rede.
Se o comutador não estiver incluído, contacte o fornecedor de comutadores para garantir que o modelo de comutador e a versão do sistema operativo do comutador suportam os requisitos na secção seguinte.
Requisitos de comutador de rede
Esta secção lista as normas do setor que são obrigatórias para as funções específicas dos comutadores de rede utilizados nas implementações do Azure Stack HCI. Estas normas ajudam a garantir comunicações fiáveis entre nós nas implementações de clusters do Azure Stack HCI.
Nota
Os adaptadores de rede utilizados para tráfego de computação, armazenamento e gestão necessitam de Ethernet. Para obter mais informações, veja Requisitos de rede de anfitrião.
Seguem-se as normas e especificações IEEE obrigatórias:
Requisitos de Função 23H2
| Requisito | Gestão | Armazenamento | Computação (Standard) | Computação (SDN) |
|---|---|---|---|---|
| LANS Virtuais | ✓ | ✓ | ✓ | ✓ |
| Controlo de Fluxo de Prioridade | ✓ | |||
| Seleção de Transmissão Avançada | ✓ | |||
| ID de VLAN de Porta LLDP | ✓ | |||
| Nome da VLAN LLDP | ✓ | ✓ | ✓ | |
| Agregação de Ligações LLDP | ✓ | ✓ | ✓ | ✓ |
| Configuração do LLDP ETS | ✓ | |||
| Recomendação do LLDP ETS | ✓ | |||
| Configuração do LLDP PFC | ✓ | |||
| Tamanho Máximo da Moldura LLDP | ✓ | ✓ | ✓ | ✓ |
| Unidade de Transmissão Máxima | ✓ | |||
| Border Gateway Protocol | ✓ | |||
| Agente de Reencaminhamento DHCP | ✓ |
Nota
O RDMA convidado requer Computação (Standard) e Armazenamento.
Standard: IEEE 802.1Q
Os comutadores Ethernet têm de estar em conformidade com a especificação IEEE 802.1Q que define as 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.
Standard: IEEE 802.1Qbb
Os comutadores Ethernet utilizados para o tráfego de armazenamento do Azure Stack HCI têm de estar em conformidade com a especificação IEEE 802.1Qbb que define o Controlo de Fluxo Prioritário (PFC). O PFC é necessário onde o Data Center Bridging (DCB) é utilizado. Uma vez que o DCB pode ser utilizado 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 mudar para uma versão inferior das capacidades de comutador ou velocidades de porta. Pelo menos uma destas classes de tráfego tem de fornecer comunicação sem perdas.
Standard: IEEE 802.1Qaz
Os comutadores Ethernet utilizados para o tráfego de armazenamento do Azure Stack HCI têm de estar em conformidade com a especificação IEEE 802.1Qaz que define a Seleção de Transmissão Avançada (ETS). O ETS é necessário onde o DCB é utilizado. Uma vez que o DCB pode ser utilizado em cenários DE RDMA RoCE e iWARP, é necessário 802.1Qaz em todos os cenários.
É necessário um mínimo de três prioridades de CoS sem mudar para uma versão inferior das capacidades de comutador ou da velocidade da porta. Além disso, se o seu dispositivo permitir que as taxas de QoS de entrada sejam definidas, recomendamos que não configure as taxas de entrada nem as configure exatamente para o mesmo valor que as taxas de saída (ETS).
Nota
A infraestrutura hiperconvergida depende de East-West comunicação de Camada 2 no mesmo rack e, por conseguinte, requer ETS. A Microsoft não testa o Azure Stack HCI com o Ponto de Código dos Serviços Diferenciados (DSCP).
Standard: IEEE 802.1AB
Os comutadores Ethernet têm de estar em conformidade com a especificação IEEE 802.1AB que define o Protocolo LLDP (Link Layer Discovery Protocol). O LLDP é necessário para o Azure Stack HCI e permite a resolução de problemas de configurações de rede física.
A configuração dos Valores de Comprimento de Tipo (TLVs) LLDP tem de estar ativada dinamicamente. Os comutadores não podem exigir configuração adicional para além da ativação de um TLV específico. Por exemplo, ativar o Subtipo 3 802.1 deve anunciar automaticamente todas as VLANs disponíveis nas portas do comutador.
Requisitos de TLV personalizados
O LLDP permite às organizações definir e codificar as suas próprias TLVs personalizadas. Estes são denominados TLVs Específicos organizacionalmente. Todas as TLVs Específicas da Organização começam com um valor de Tipo TLV LLDP de 127. A tabela abaixo mostra quais os subtipos TLV Personalizados Específicos da Organização (Tipo TLV 127) necessários.
| Organização | Subtipo TLV |
|---|---|
| IEEE 802.1 | ID de VLAN de Porta (Subtipo = 1) |
| IEEE 802.1 | Nome da VLAN (Subtipo = 3) Mínimo de 10 VLANS |
| IEEE 802.1 | Agregação de Ligações (Subtipo = 7) |
| IEEE 802.1 | Configuração 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 da Moldura (Subtipo = 4) |
Unidade de Transmissão Máxima
A unidade de transmissão máxima (MTU) é o pacote ou pacote de maior tamanho que pode ser transmitido através de uma ligação de dados. É necessário um intervalo de 1514 a 9174 para encapsulamento da SDN.
Border Gateway Protocol
Os comutadores Ethernet utilizados para o tráfego de computação SDN do Azure Stack HCI têm de suportar o Protocolo BGP (Border Gateway Protocol). O BGP é um protocolo de encaminhamento padrão utilizado para trocar informações de encaminhamento e alcance entre duas ou mais redes. As rotas são adicionadas automaticamente à tabela de rotas de todas as sub-redes com a propagação de BGP ativada. Isto é necessário para ativar cargas de trabalho de inquilinos com SDN e peering dinâmico. RFC 4271: Protocolo 4 do Gateway de Limite
Agente de Reencaminhamento DHCP
Os comutadores Ethernet utilizados para o tráfego de gestão do Azure Stack HCI têm de suportar o agente de reencaminhamento DHCP. O agente de reencaminhamento DHCP é qualquer anfitrião TCP/IP que é utilizado para reencaminhar pedidos e respostas entre o servidor DHCP e o cliente quando o servidor está presente numa rede diferente. É necessário para os serviços de arranque PXE. RFC 3046: DHCPv4 ou RFC 6148: DHCPv4
Tráfego de rede e arquitetura
Esta secção é predominantemente para administradores de rede.
O Azure Stack HCI pode funcionar em várias arquiteturas de datacenters, incluindo 2 camadas (Folha de Coluna) e 3 camadas (Core-Aggregation-Access). Esta secção refere-se mais a conceitos da topologia de Spine-Leaf que é frequentemente utilizada com cargas de trabalho em infraestruturas hiperconvergidas, como o Azure Stack HCI.
Modelos de rede
O tráfego de rede pode ser classificado pela respetiva direção. Os ambientes tradicionais da Rede de Área de Armazenamento (SAN) são fortemente North-South em que 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 hiperconvergida é mais fortemente East-West onde uma parte substancial do tráfego permanece dentro de um limite de Camada 2 (VLAN).
Importante
Recomendamos vivamente que todos os nós de cluster num site estejam fisicamente localizados no mesmo rack e ligados aos mesmos comutadores top-of-rack (ToR).
North-South tráfego para o Azure Stack HCI
North-South tráfego tem as seguintes características:
- O tráfego flui de um comutador 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 limite de Camada 3 (IP).
- Inclui gestão (PowerShell, Windows Admin Center), computação (VM) e tráfego de cluster disperso entre sites.
- Utiliza um comutador Ethernet para conectividade à 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 tráfego de armazenamento ou tráfego de Migração em Direto entre nós no mesmo cluster e (se utilizar um cluster disperso) no mesmo site.
- Pode utilizar um comutador Ethernet (comutado) ou uma ligação direta (sem comutadores), conforme descrito nas duas secções seguintes.
Utilizar comutadores
North-South tráfego requer a utilização de comutadores. Além de utilizar um comutador Ethernet que suporte os protocolos necessários para o Azure Stack HCI, o aspeto mais importante é o dimensionamento adequado dos recursos de infraestrutura de rede.
É imperativo compreender a largura de banda dos recursos de infraestrutura "sem bloqueio" que os comutadores Ethernet podem suportar e minimizar (ou, de preferência, eliminar) a subscrição excedida da rede.
Os pontos de congestionamento comuns e a subscrição excedida, como o Grupo de Agregação de Ligações Multi-Chassis utilizado para redundância de caminhos, podem ser eliminados através da utilização adequada de sub-redes e VLANs. Veja também Requisitos de rede de anfitrião.
Trabalhe com o fornecedor de rede ou a equipa de suporte de rede para garantir que os comutadores de rede foram devidamente dimensionados para a carga de trabalho que pretende executar.
Utilizar sem comutador
O Azure Stack HCI suporta ligações sem comutadores (diretas) para East-West tráfego para todos os tamanhos de cluster, desde que cada nó no cluster tenha uma ligação redundante a todos os nós do cluster. Esta ligação é denominada "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 |
Nota
Os benefícios das implementações sem comutadores diminuem com clusters maiores do que três nós devido ao número de adaptadores de rede necessários.
Vantagens das ligações sem comutadores
- Não é necessária nenhuma compra comutador para East-West tráfego. É necessário um comutador para North-South tráfego. Isto pode resultar em custos de despesas de capital mais baixos (CAPEX), mas depende do número de nós no cluster.
- Como não existe nenhum comutador, a configuração está limitada ao anfitrião, o que pode reduzir o número potencial de passos de configuração necessários. Este valor diminui à medida que o tamanho do cluster aumenta.
Desvantagens das ligações sem comutadores
- É necessário mais planeamento para esquemas de endereçamento IP e sub-rede.
- Fornece apenas acesso de armazenamento local. O tráfego de gestão, o tráfego da VM e outro tráfego que exija North-South acesso não podem utilizar estes adaptadores.
- À medida que o número de nós no cluster aumenta, o custo dos adaptadores de rede pode exceder o custo da utilização de comutadores de rede.
- Não dimensiona muito além dos clusters de três nós. Mais nós incorrem em cablagem e configuração adicionais que podem ultrapassar a complexidade de utilizar um comutador.
- A expansão do cluster é complexa, requerendo alterações de configuração de hardware e software.
Passos seguintes
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários