Requisitos de rede de anfitrião para o Azure Stack HCI
Aplica-se a: Azure Stack HCI, versões 23H2 e 22H2
Este tópico aborda as considerações e os requisitos de rede do anfitrião para o Azure Stack HCI. Para obter informações sobre as arquiteturas do datacenter e as ligações físicas entre servidores, veja Requisitos de rede física.
Para obter informações sobre como simplificar a rede de anfitriões com o ATC de Rede, veja Simplificar a rede de anfitriões com o ATC de Rede.
Tipos de tráfego de rede
O tráfego de rede do Azure Stack HCI pode ser classificado pela finalidade pretendida:
- Tráfego de gestão: Tráfego de ou para fora do cluster local. Por exemplo, tráfego ou tráfego de réplica de armazenamento utilizado pelo administrador para gestão do cluster, como Ambiente de Trabalho Remoto, Windows Admin Center, Active Directory, etc.
- Tráfego de computação: Tráfego com origem ou destinado a uma máquina virtual (VM).
- Tráfego de armazenamento: Tráfego com o Bloco de Mensagens do Servidor (SMB), por exemplo, Espaços de Armazenamento Direto ou migração em direto baseada em SMB. Este tráfego é de camada 2 e não é encaminhável.
Importante
A réplica de armazenamento utiliza tráfego SMB não baseado em RDMA. Esta e a natureza direcional do tráfego (Norte-Sul) torna-o estreitamente alinhado com o tráfego de "gestão" listado acima, semelhante ao de uma partilha de ficheiros tradicional.
Selecionar uma placa de rede
Os adaptadores de rede são qualificados pelos tipos de tráfego de rede (veja acima) com os quais são suportados para utilização. À medida que revê o Catálogo do Windows Server, a certificação do Windows Server 2022 indica agora uma ou mais das seguintes funções. Antes de comprar um servidor para o Azure Stack HCI, tem de ter , pelo menos , um adaptador qualificado para gestão, computação e armazenamento, uma vez que os três tipos de tráfego são necessários no Azure Stack HCI. Em seguida, pode utilizar o ATC de Rede para configurar os adaptadores para os tipos de tráfego adequados.
Para obter mais informações sobre esta qualificação de NIC baseada em funções, veja esta ligação.
Importante
A utilização de um adaptador fora do tipo de tráfego qualificado não é suportada.
| Level | Função de Gestão | Função de Computação | Função de Armazenamento |
|---|---|---|---|
| Distinção baseada em funções | Gestão | Computação Padrão | Norma de Armazenamento |
| Prémio Máximo | Não Aplicável | Computação Premium | Armazenamento Premium |
Nota
A qualificação mais elevada para qualquer adaptador no nosso ecossistema irá conter as qualificações de Gestão, Computação Premium e Armazenamento Premium .
Requisitos do Controlador
Os controladores de caixa de entrada não são suportados para utilização com o Azure Stack HCI. Para identificar se o adaptador está a utilizar um controlador de caixa de entrada, execute o seguinte cmdlet. Um adaptador está a utilizar um controlador de caixa de entrada se a propriedade DriverProvider for Microsoft.
Get-NetAdapter -Name <AdapterName> | Select *Driver*
Descrição geral das principais capacidades da placa de rede
As funcionalidades importantes da placa de rede utilizadas pelo Azure Stack HCI incluem:
- Multi-Fila da Máquina Virtual Dinâmica (VMMQ Dinâmico ou d.VMMQ)
- Acesso Remoto Direto à Memória (RDMA)
- RDMA convidado
- Agrupamento Incorporado do Comutador (SET)
VMMQ Dinâmico
Todos os adaptadores de rede com a qualificação de Computação (Premium) suportam o VMMQ Dinâmico. O VMMQ dinâmico requer a utilização do Agrupamento Incorporado do Comutador.
Tipos de tráfego aplicáveis: computação
Certificações necessárias: Computação (Premium)
O VMMQ dinâmico é uma tecnologia inteligente do lado da receção. Baseia-se nos seus antecessores de Fila de Máquina Virtual (VMQ), Dimensionamento Do Lado da Receção Virtual (vRSS) e VMMQ, para fornecer três melhorias principais:
- Otimiza a eficiência do anfitrião com menos núcleos de CPU.
- Ajuste automático do processamento de tráfego de rede para núcleos de CPU, permitindo assim que as VMs cumpram e mantenham o débito esperado.
- Permite que as cargas de trabalho "rajada" recebam a quantidade esperada de tráfego.
Para obter mais informações sobre o VMMQ Dinâmico, veja a publicação de blogue Acelerações sintéticas.
RDMA
O RDMA é uma descarga de pilha de rede para o adaptador de rede. Permite que o tráfego de armazenamento SMB ignore o sistema operativo para processamento.
O RDMA permite redes de débito elevado e de baixa latência, utilizando recursos mínimos de CPU do anfitrião. Estes recursos de CPU do anfitrião podem ser utilizados para executar VMs ou contentores adicionais.
Tipos de tráfego aplicáveis: armazenamento de anfitriões
Certificações necessárias: Armazenamento (Standard)
Todos os adaptadores com qualificação de Armazenamento (Standard) ou Armazenamento (Premium) suportam RDMA do lado do anfitrião. Para obter mais informações sobre como utilizar o RDMA com cargas de trabalho de convidado, consulte a secção "RDMA Convidado" mais à frente neste artigo.
O Azure Stack HCI suporta RDMA com as implementações do protocolo IWARP (Internet Wide Area RDMA Protocol) ou RDMA através de Ethernet Convergida (RoCE).
Importante
Os adaptadores RDMA só funcionam com outros adaptadores RDMA que implementam o mesmo protocolo RDMA (iWARP ou RoCE).
Nem todos os adaptadores de rede dos fornecedores suportam RDMA. A tabela seguinte lista os fornecedores (por ordem alfabética) que oferecem adaptadores RDMA certificados. No entanto, existem fornecedores de hardware não incluídos nesta lista que também suportam RDMA. Consulte o Catálogo do Windows Server para localizar adaptadores com a qualificação de Armazenamento (Standard) ou Armazenamento (Premium) que requerem suporte RDMA.
Nota
O InfiniBand (IB) não é suportado com o Azure Stack HCI.
| Fornecedor nic | iWARP | RoCE |
|---|---|---|
| Broadcom | No | Yes |
| Intel | Yes | Sim (alguns modelos) |
| Marvell (Qlogic) | Yes | Yes |
| Nvidia | No | Yes |
Para obter mais informações sobre como implementar o RDMA para o anfitrião, recomendamos vivamente que utilize o ATC de Rede. Para obter informações sobre a implementação manual, veja o repositório do GitHub do SDN.
iWARP
O iWARP utiliza o Protocolo de Controlo de Transmissão (TCP) e pode ser opcionalmente melhorado com o Controlo de Fluxo Baseado em Prioridade (PFC) e o Serviço de Transmissão Avançado (ETS).
Utilize iWARP se:
- Não tem experiência na gestão de redes RDMA.
- Não gere ou não se sente à vontade para gerir os seus comutadores top-of-rack (ToR).
- Não irá gerir a solução após a implementação.
- Já tem implementações que utilizam iWARP.
- Não tem a certeza de qual a opção a escolher.
RoCE
O RoCE utiliza o User Datagram Protocol (UDP) e requer PFC e ETS para fornecer fiabilidade.
Utilize o RoCE se:
- Já tem implementações com o RoCE no seu datacenter.
- Está confortável em gerir os requisitos de rede do DCB.
RDMA convidado
O RDMA convidado permite que as cargas de trabalho SMB para VMs obtenham as mesmas vantagens de utilizar o RDMA nos anfitriões.
Tipos de tráfego aplicáveis: Armazenamento baseado em convidados
Certificações necessárias: Computação (Premium)
As principais vantagens da utilização do RDMA Convidado são:
- Descarga da CPU para o NIC para processamento de tráfego de rede.
- Latência extremamente baixa.
- Débito elevado.
Para obter mais informações, transfira o documento a partir do repositório do GitHub do SDN.
Alternar Agrupamento Incorporado (SET)
A SET é uma tecnologia de agrupamento baseada em software que está incluída no sistema operativo Windows Server desde Windows Server 2016. A solução SET é a única tecnologia de agrupamento suportada pelo Azure Stack HCI. O SET funciona bem com tráfego de computação, armazenamento e gestão e é suportado com até oito adaptadores na mesma equipa.
Tipos de tráfego aplicáveis: computação, armazenamento e gestão
Certificações necessárias: Computação (Standard) ou Computação (Premium)
A solução SET é a única tecnologia de agrupamento suportada pelo Azure Stack HCI. O SET funciona bem com tráfego de computação, armazenamento e gestão.
Importante
O Azure Stack HCI não suporta o agrupamento NIC com o Balanceamento de Carga/Ativação Pós-falha (LBFO) mais antigo. Veja a mensagem de blogue Agrupamento no Azure Stack HCI para obter mais informações sobre o LBFO no Azure Stack HCI.
O SET é importante para o Azure Stack HCI porque é a única tecnologia de agrupamento que permite:
- Agrupamento de adaptadores RDMA (se necessário).
- RDMA convidado.
- VMMQ dinâmico.
- Outras funcionalidades principais do Azure Stack HCI (veja Agrupamento no Azure Stack HCI).
O SET exige a utilização de adaptadores simétricos (idênticos). Os adaptadores de rede simétricos são aqueles que têm:
- a mesma marca (fornecedor)
- o mesmo modelo (versão)
- a mesma velocidade (débito)
- configuração
Em 22H2, o ATC de Rede irá detetar e informá-lo automaticamente se os adaptadores que escolheu são assimétricos. A forma mais fácil de identificar manualmente se os adaptadores são simétricos é se as velocidades e as descrições da interface são correspondências exatas . Só podem desviar-se no numeral listado na descrição. Utilize o Get-NetAdapterAdvancedProperty cmdlet para garantir que a configuração comunicada lista os mesmos valores de propriedade.
Veja a seguinte tabela para obter um exemplo das descrições da interface que se desviam apenas por numeral (#):
| Name | Descrição da interface | Velocidade da ligação |
|---|---|---|
| NIC1 | Placa de Rede n.º 1 | 25 Gbps |
| NIC2 | Placa de Rede n.º 2 | 25 Gbps |
| NIC3 | Placa de Rede n.º 3 | 25 Gbps |
| NIC4 | Placa de Rede n.º 4 | 25 Gbps |
Nota
O SET suporta apenas a configuração independente do comutador através de algoritmos de balanceamento de carga de Porta Dinâmica ou Hyper-V. Para um melhor desempenho, recomenda-se a utilização da Porta do Hyper-V em todos os NICs que funcionem a 10 Gbps ou superior. O ATC de Rede efetua todas as configurações necessárias para SET.
Considerações sobre o tráfego RDMA
Se implementar o DCB, tem de garantir que a configuração do PFC e do ETS é implementada corretamente em todas as portas de rede, incluindo comutadores de rede. O DCB é necessário para o RoCE e opcional para iWARP.
Para obter informações detalhadas sobre como implementar o RDMA, transfira o documento a partir do repositório do GitHub do SDN.
As implementações do Azure Stack HCI baseadas no RoCE requerem a configuração de três classes de tráfego PFC, incluindo a classe de tráfego predefinida, nos recursos de infraestrutura e em todos os anfitriões.
Classe de tráfego de cluster
Esta classe de tráfego garante que existe largura de banda suficiente reservada para heartbeats de cluster:
- Obrigatório: sim
- Ativado para PFC: Não
- Prioridade de tráfego recomendada: Prioridade 7
- Reserva de largura de banda recomendada:
- 10 GbE ou redes RDMA inferiores = 2 por cento
- 25 GbE ou redes RDMA superiores = 1 por cento
Classe de tráfego RDMA
Esta classe de tráfego garante que existe largura de banda suficiente reservada para comunicações RDMA sem perda através do SMB Direct:
- Obrigatório: sim
- Ativado para PFC: Sim
- Prioridade de tráfego recomendada: Prioridade 3 ou 4
- Reserva de largura de banda recomendada: 50 por cento
Classe de tráfego predefinida
Esta classe de tráfego transporta todo o tráfego não definido nas classes de tráfego de cluster ou RDMA, incluindo tráfego de VM e tráfego de gestão:
- Obrigatório: por predefinição (nenhuma configuração necessária no anfitrião)
- Controlo de fluxo (PFC)ativado: Não
- Classe de tráfego recomendada: por predefinição (Prioridade 0)
- Reserva de largura de banda recomendada: por predefinição (não é necessária nenhuma configuração de anfitrião)
Modelos de tráfego de armazenamento
O SMB proporciona muitas vantagens como o protocolo de armazenamento para o Azure Stack HCI, incluindo o SMB Multicanal. O SMB Multicanal não está abrangido neste artigo, mas é importante compreender que o tráfego está multiplexed em todas as ligações possíveis que o SMB Multicanal pode utilizar.
Nota
Recomendamos a utilização de várias sub-redes e VLANs para separar o tráfego de armazenamento no Azure Stack HCI.
Considere o exemplo seguinte de um cluster de quatro nós. Cada servidor tem duas portas de armazenamento (lado esquerdo e direito). Uma vez que cada adaptador está na mesma sub-rede e VLAN, o SMB Multicanal irá distribuir ligações por todas as ligações disponíveis. Por conseguinte, a porta do lado esquerdo do primeiro servidor (192.168.1.1) fará uma ligação à porta do lado esquerdo no segundo servidor (192.168.1.2). A porta do lado direito do primeiro servidor (192.168.1.12) ligar-se-á à porta do lado direito no segundo servidor. São estabelecidas ligações semelhantes para o terceiro e quarto servidores.
No entanto, isto cria ligações desnecessárias e causa congestionamento na interligação (grupo de agregação de ligações multi chassis ou MC-LAG) que liga os comutadores ToR (marcados com Xs). Veja o seguinte diagrama:
A abordagem recomendada é utilizar sub-redes e VLANs separadas para cada conjunto de adaptadores. No diagrama seguinte, as portas da direita utilizam agora a sub-rede 192.168.2.x /24 e a VLAN2. Isto permite que o tráfego nas portas do lado esquerdo permaneça no TOR1 e o tráfego nas portas do lado direito permaneça no TOR2.
Alocação de largura de banda de tráfego
A tabela seguinte mostra alocações de largura de banda de exemplo de vários tipos de tráfego, utilizando velocidades comuns de adaptadores, no Azure Stack HCI. Tenha em atenção que este é um exemplo de uma solução convergida, em que todos os tipos de tráfego (computação, armazenamento e gestão) são executados nos mesmos adaptadores físicos e são acompanhados pela utilização de SET.
Uma vez que este caso de utilização representa o maior número de restrições, representa uma boa linha de base. No entanto, tendo em conta as permutações para o número de adaptadores e velocidades, este deve ser considerado um exemplo e não um requisito de suporte.
Os seguintes pressupostos são feitos para este exemplo:
Existem dois adaptadores por equipa.
Storage Bus Layer (SBL), Cluster Shared Volume (CSV) e Hyper-V (Live Migration) traffic:
- Utilize os mesmos adaptadores físicos.
- Utilize o SMB.
O SMB recebe uma alocação de largura de banda de 50 por cento através do DCB.
- SBL/CSV é o tráfego de prioridade mais alta e recebe 70 por cento da reserva de largura de banda SMB.
- A Migração em Direto (LM) é limitada através do
Set-SMBBandwidthLimitcmdlet e recebe 29 por cento da largura de banda restante.Se a largura de banda disponível para Migração em Direto for >= 5 Gbps e os adaptadores de rede forem capazes, utilize RDMA. Utilize o seguinte cmdlet para o fazer:
Set-VMHost -VirtualMachineMigrationPerformanceOption SMBSe a largura de banda disponível para Migração em Direto for < de 5 Gbps, utilize a compressão para reduzir os tempos de apagão. Utilize o seguinte cmdlet para o fazer:
Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
Se estiver a utilizar o RDMA para tráfego de Migração em Direto, certifique-se de que o tráfego de Migração em Direto não pode consumir toda a largura de banda alocada à classe de tráfego RDMA através de um limite de largura de banda SMB. Tenha cuidado, porque este cmdlet entra em bytes por segundo (Bps), enquanto os adaptadores de rede são listados em bits por segundo (bps). Utilize o seguinte cmdlet para definir um limite de largura de banda de 6 Gbps, por exemplo:
Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MBNota
750 MBps neste exemplo equivale a 6 Gbps.
Eis a tabela de alocação de largura de banda de exemplo:
| Velocidade nic | Largura de banda em equipa | Reserva de largura de banda SMB** | SBL/CSV % | Largura de banda SBL/CSV | % da Migração em Direto | Largura de banda max live migration | % do heartbeat | Largura de banda do heartbeat |
|---|---|---|---|---|---|---|---|---|
| 10 Gbps | 20 Gbps | 10 Gbps | 70% | 7 Gbps | ** | 200 Mbps | ||
| 25 Gbps | 50 Gbps | 25 Gbps | 70% | 17,5 Gbps | 29% | 7,25 Gbps | 1% | 250 Mbps |
| 40 Gbps | 80 Gbps | 40 Gbps | 70% | 28 Gbps | 29% | 11,6 Gbps | 1% | 400 Mbps |
| 50 Gbps | 100 Gbps | 50 Gbps | 70% | 35 Gbps | 29% | 14,5 Gbps | 1% | 500 Mbps |
| 100 Gbps | 200 Gbps | 100 Gbps | 70% | 70 Gbps | 29% | 29 Gbps | 1% | 1 Gbps |
| 200 Gbps | 400 Gbps | 200 Gbps | 70% | 140 Gbps | 29% | 58 Gbps | 1% | 2 Gbps |
* Utilize compressão em vez de RDMA, porque a alocação de largura de banda para tráfego de Migração em Direto é <de 5 Gbps.
** 50 por cento é uma reserva de largura de banda de exemplo.
Clusters dispersos
Os clusters dispersos proporcionam uma recuperação após desastre que abrange vários datacenters. Na sua forma mais simples, uma rede de clusters do Azure Stack HCI esticada tem o seguinte aspeto:
Requisitos de cluster dispersos
Os clusters dispersos têm os seguintes requisitos e características:
O RDMA está limitado a um único site e não é suportado em diferentes sites ou sub-redes.
Os servidores no mesmo site têm de residir no mesmo rack e limite camada 2.
A comunicação do anfitrião entre sites tem de atravessar um limite de Camada 3; as topologias de Camada 2 esticadas não são suportadas.
Tenha largura de banda suficiente para executar as cargas de trabalho no outro site. Em caso de ativação pós-falha, o site alternativo terá de executar todo o tráfego. Recomendamos que aprovisione sites em 50% da capacidade de rede disponível. No entanto, este não é um requisito se conseguir tolerar um desempenho mais baixo durante uma ativação pós-falha.
A replicação entre sites (tráfego norte/sul) pode utilizar os mesmos NICs físicos que o armazenamento local (tráfego leste/oeste). Se estiver a utilizar os mesmos adaptadores físicos, estes adaptadores têm de estar em equipa com SET. Os adaptadores também têm de ter NICs virtuais adicionais aprovisionadas para tráfego encaminhável entre sites.
Adaptadores utilizados para comunicação entre sites:
Pode ser físico ou virtual (anfitrião vNIC). Se os adaptadores forem virtuais, tem de aprovisionar um vNIC na sua própria sub-rede e VLAN por NIC física.
Tem de estar na sua própria sub-rede e VLAN que possa encaminhar entre sites.
O RDMA tem de ser desativado com o
Disable-NetAdapterRDMAcmdlet. Recomendamos que exija explicitamente que a Réplica de Armazenamento utilize interfaces específicas com oSet-SRNetworkConstraintcmdlet.Tem de cumprir quaisquer requisitos adicionais para a Réplica de Armazenamento.
Exemplo de cluster disperso
O exemplo seguinte ilustra uma configuração de cluster dispersa. Para garantir que uma NIC virtual específica é mapeada para um adaptador físico específico, utilize o cmdlet Set-VMNetworkAdapterTeammapping .
O seguinte mostra os detalhes da configuração do cluster disperso de exemplo.
Nota
A configuração exata, incluindo nomes nic, endereços IP e VLANs, pode ser diferente do que é mostrado. Isto é utilizado apenas como uma configuração de referência que pode ser adaptada ao seu ambiente.
SiteA – Replicação local, RDMA ativada, não encaminhável entre sites
| Nome do nó | nome do vNIC | NIC Físico (mapeado) | VLAN | IP e sub-rede | Âmbito do tráfego |
|---|---|---|---|---|---|
| NodeA1 | vSMB01 | pNIC01 | 711 | 192.168.1.1/24 | Apenas Site Local |
| NodeA2 | vSMB01 | pNIC01 | 711 | 192.168.1.2/24 | Apenas Site Local |
| NodeA1 | vSMB02 | pNIC02 | 712 | 192.168.2.1/24 | Apenas Site Local |
| NodeA2 | vSMB02 | pNIC02 | 712 | 192.168.2.2/24 | Apenas Site Local |
SiteB – Replicação local, RDMA ativado, não encaminhável entre sites
| Nome do nó | nome do vNIC | NIC Físico (mapeado) | VLAN | IP e sub-rede | Âmbito do tráfego |
|---|---|---|---|---|---|
| NodeB1 | vSMB01 | pNIC01 | 711 | 192.168.1.1/24 | Apenas Site Local |
| NodeB2 | vSMB01 | pNIC01 | 711 | 192.168.1.2/24 | Apenas Site Local |
| NodeB1 | vSMB02 | pNIC02 | 712 | 192.168.2.1/24 | Apenas Site Local |
| NodeB2 | vSMB02 | pNIC02 | 712 | 192.168.2.2/24 | Apenas Site Local |
SiteA – Replicação dispersa, RDMA desativado, encaminhável entre sites
| Nome do nó | nome do vNIC | NIC Físico (mapeado) | IP e sub-rede | Âmbito do tráfego |
|---|---|---|---|---|
| NodeA1 | Stretch1 | pNIC01 | 173.0.0.1/8 | Encaminhável entre Sites |
| NodeA2 | Stretch1 | pNIC01 | 173.0.0.2/8 | Encaminhável entre Sites |
| NodeA1 | Stretch2 | pNIC02 | 174.0.0.1/8 | Encaminhável entre Sites |
| NodeA2 | Stretch2 | pNIC02 | 174.0.0.2/8 | Encaminhável entre Sites |
SiteB – Replicação dispersa, RDMA desativado, encaminhável entre sites
| Nome do nó | nome do vNIC | NIC Físico (mapeado) | IP e sub-rede | Âmbito do tráfego |
|---|---|---|---|---|
| NodeB1 | Stretch1 | pNIC01 | 175.0.0.1/8 | Encaminhável entre Sites |
| NodeB2 | Stretch1 | pNIC01 | 175.0.0.2/8 | Encaminhável entre Sites |
| NodeB1 | Stretch2 | pNIC02 | 176.0.0.1/8 | Encaminhável entre Sites |
| NodeB2 | Stretch2 | pNIC02 | 176.0.0.2/8 | Encaminhável entre Sites |
Passos seguintes
- Saiba mais sobre o comutador de rede e os requisitos de rede física. Veja Requisitos de rede física.
- Saiba como simplificar a rede de anfitriões com o ATC de Rede. Veja Simplificar a rede de anfitriões com o ATC de Rede.
- Reveja as noções básicas de rede de clustering de ativação pós-falha.
- Veja Implementar com portal do Azure.
- Veja Implementar com o modelo do ARM.
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