Requisitos de rede do host para o Azure Local
Aplica-se a: Azure Local, versões 23H2 e 22H2
Este tópico discute as considerações de rede do host e os requisitos para o Azure Local. Para obter informações sobre arquiteturas de datacenter e as conexões físicas entre computadores, consulte Requisitos de rede física.
Para obter informações sobre como simplificar a rede de host usando a ATC de Rede, consulte Simplificar a rede de host com a ATC de Rede.
Tipos de tráfego de rede
O tráfego de rede local do Azure pode ser classificado por sua finalidade pretendida:
- Tráfego de gerenciamento: tráfego de ou para fora do sistema local. Por exemplo, o tráfego de réplica de armazenamento ou o tráfego usado pelo administrador para gerenciamento do sistema, como Área de Trabalho Remota, Windows Admin Center, Active Directory etc.
- Tráfego de computação: tráfego originado ou destinado a uma VM (máquina virtual).
- Tráfego de armazenamento: tráfego usando SMB (Server Message Block), por exemplo, Espaços de Armazenamento Diretos ou migração dinâmica baseada em SMB. Esse tráfego é tráfego de camada 2 e não é roteável.
Importante
A réplica de armazenamento usa tráfego SMB não baseado em RDMA. Isso e a natureza direcional do tráfego (Norte-Sul) o tornam estreitamente alinhado ao tráfego de "gerenciamento" listado acima, semelhante ao de um compartilhamento de arquivos tradicional.
Selecione um adaptador de rede
Os adaptadores de rede são qualificados pelos tipos de tráfego de rede (veja acima) com os quais têm suporte para uso. À medida que você examina o Catálogo do Windows Server, a certificação do Windows Server 2022 agora indica uma ou mais das seguintes funções. Antes de comprar um computador para o Azure Local, você deve ter no mínimo um adaptador qualificado para gerenciamento, computação e armazenamento, pois todos os três tipos de tráfego são necessários no Azure Local. Em seguida, você pode usar a ATC de Rede para configurar seus adaptadores para os tipos de tráfego apropriados.
Para obter mais informações sobre essa qualificação de NIC baseada em função, consulte esta postagem no blog do Windows Server.
Importante
Não há suporte para o uso de um adaptador fora de seu tipo de tráfego qualificado.
Nível | Função de gerenciamento | Função de computação | Função de armazenamento |
---|---|---|---|
Distinção baseada em função | Gerenciamento | Computação Padrão | Storage Standard |
Prêmio Máximo | Não Aplicável | Computação premium | Armazenamento Premium |
Observação
A qualificação mais alta para qualquer adaptador em nosso ecossistema conterá as qualificações Management, Compute Premium e Storage Premium .
Exigências do driver
Não há suporte para drivers de caixa de entrada para uso com o Azure Local. Para identificar se o adaptador está usando um driver de caixa de entrada, execute o cmdlet a seguir. Um adaptador está usando um driver de caixa de entrada se a propriedade DriverProvider for Microsoft.
Get-NetAdapter -Name <AdapterName> | Select *Driver*
Visão geral dos principais recursos do adaptador de rede
Os recursos importantes do adaptador de rede usados pelo Azure Local incluem:
- Várias filas de máquina virtual dinâmica (VMMQ dinâmico ou d.VMMQ)
- Acesso Remoto Direto à Memória (RDMA)
- RDMA convidado
- SET (Agrupamento Incorporado de Comutador)
VMMQ dinâmico
Todos os adaptadores de rede com a qualificação de Computação (Premium) dão suporte ao VMMQ dinâmico. O VMMQ dinâmico requer o uso do Switch Embedded Teaming.
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 recepção. Ele se baseia em seus predecessores de Virtual Machine Queue (VMQ), Virtual Receive Side Scaling (vRSS) e VMMQ, para fornecer três melhorias principais:
- Otimiza a eficiência do host usando menos núcleos de CPU.
- Ajuste automático do processamento de tráfego de rede para núcleos de CPU, permitindo que as VMs atendam e mantenham a taxa de transferência esperada.
- Permite que cargas de trabalho "intermitentes" recebam a quantidade esperada de tráfego.
Para obter mais informações sobre o VMMQ dinâmico, consulte a postagem no blog Acelerações sintéticas.
RDMA
RDMA é um descarregamento de pilha de rede para o adaptador de rede. Ele permite que o tráfego de armazenamento do SMB ignore o sistema operacional para processamento.
O RDMA permite redes de alta taxa de transferência e baixa latência, usando recursos mínimos de CPU do host. Esses recursos de CPU do host podem ser usados para executar VMs ou contêineres adicionais.
Tipos de tráfego aplicáveis: armazenamento de host
Certificações necessárias: Armazenamento (Padrão)
Todos os adaptadores com qualificação de Armazenamento (Standard) ou Armazenamento (Premium) dão suporte ao RDMA do lado do host. Para obter mais informações sobre como usar o RDMA com cargas de trabalho de convidado, consulte a seção "RDMA de convidado" mais adiante neste artigo.
O Azure Local dá suporte ao RDMA com as implementações de protocolo iWARP (Internet Wide Area RDMA Protocol) ou RDMA sobre Ethernet Convergente (RoCE).
Importante
Os adaptadores RDMA funcionam apenas com outros adaptadores RDMA que implementam o mesmo protocolo RDMA (iWARP ou RoCE).
Nem todos os adaptadores de rede de fornecedores dão suporte a RDMA. A tabela a seguir lista os fornecedores (em ordem alfabética) que oferecem adaptadores RDMA certificados. No entanto, há fornecedores de hardware não incluídos nesta lista que também oferecem suporte a RDMA. Consulte o Catálogo do Windows Server para encontrar adaptadores com a qualificação de Armazenamento (Standard) ou Armazenamento (Premium) que exigem suporte a RDMA.
Observação
Não há suporte para o InfiniBand (IB) com o Azure Local.
Fornecedor de NIC | iWARP | RoCE |
---|---|---|
Broadcom | Não | Sim |
Intel | Sim | Sim (alguns modelos) |
Marvell (Qlogic) | Sim | Sim |
Nvidia | Não | Sim |
Para obter mais informações sobre como implantar o RDMA para o host, é altamente recomendável que você use a ATC de Rede. Para obter informações sobre a implantação manual, consulte o repositório GitHub do SDN.
iWARP
O iWARP usa o Protocolo de Controle de Transmissão (TCP) e pode ser opcionalmente aprimorado com Controle de Fluxo Baseado em Prioridade (PFC) e Serviço de Transmissão Aprimorado (ETS).
Use o iWARP se:
- Você não tem experiência em gerenciar redes RDMA.
- Você não gerencia ou se sente desconfortável em gerenciar seus switches top-of-rack (ToR).
- Você não gerenciará a solução após a implantação.
- Você já tem implantações que usam iWARP.
- Você não tem certeza de qual opção escolher.
RoCE
O RoCE usa o User Datagram Protocol (UDP) e requer PFC e ETS para fornecer confiabilidade.
Use o RoCE se:
- Você já tem implantações com RoCE em seu datacenter.
- Você se sente confortável em gerenciar os requisitos de rede DCB.
RDMA convidado
O RDMA convidado permite que cargas de trabalho do SMB para VMs obtenham os mesmos benefícios de usar RDMA em hosts.
Tipos de tráfego aplicáveis: armazenamento baseado em convidado
Certificações necessárias: Computação (Premium)
Os principais benefícios de usar o RDMA convidado são:
- Descarregamento de CPU para a NIC para processamento de tráfego de rede.
- Latência extremamente baixa.
- Alto rendimento.
Para obter mais informações, baixe o documento do repositório GitHub do SDN.
SET (Agrupamento Incorporado de Comutador)
SET é uma tecnologia de agrupamento baseada em software que foi incluída no sistema operacional Windows Server desde Windows Server 2016. O SET é a única tecnologia de agrupamento compatível com o Azure Local. O SET funciona bem com tráfego de computação, armazenamento e gerenciamento e é compatível com até oito adaptadores na mesma equipe.
Tipos de tráfego aplicáveis: computação, armazenamento e gerenciamento
Certificações necessárias: Computação (Padrão) ou Computação (Premium)
O SET é a única tecnologia de agrupamento compatível com o Azure Local. O SET funciona bem com tráfego de computação, armazenamento e gerenciamento.
Importante
O Azure Local não dá suporte ao agrupamento de NIC com o LBFO (Balanceamento de Carga/Failover) mais antigo. Consulte a postagem no blog Agrupamento no Azure Local para obter mais informações sobre LBFO no Azure Local.
O SET é importante para o Azure Local porque é a única tecnologia de agrupamento que permite:
- Agrupamento de adaptadores RDMA (se necessário).
- RDMA convidado.
- VMMQ dinâmico.
- Outros recursos importantes do Azure Local (consulte Agrupamento no Azure Local).
O SET requer o uso de adaptadores simétricos (idênticos). Os adaptadores de rede simétricos são aqueles que têm o mesmo:
- marca (fornecedor)
- modelo (versão)
- velocidade (taxa de transferência)
- configuração
No 22H2, o ATC de Rede detectará e informará automaticamente se os adaptadores escolhidos são assimétricos. A maneira mais fácil de identificar manualmente se os adaptadores são simétricos é se as velocidades e as descrições da interface forem correspondências exatas . Eles podem se desviar apenas no numeral listado na descrição. Use o Get-NetAdapterAdvancedProperty
cmdlet para garantir que a configuração relatada liste os mesmos valores de propriedade.
Consulte a tabela a seguir para obter um exemplo das descrições de interface que se desviam apenas pelo numeral (#):
Nome | Descrição da interface | Velocidade do link |
---|---|---|
NIC1 | Adaptador de rede #1 | 25 Gbps |
NIC2 | Adaptador de rede #2 | 25 Gbps |
NIC3 | Adaptador de rede #3 | 25 Gbps |
NIC4 | Adaptador de rede #4 | 25 Gbps |
Observação
O SET dá suporte apenas à configuração independente do comutador usando algoritmos de balanceamento de carga de porta dinâmica ou Hyper-V. Para obter um melhor desempenho, a porta Hyper-V é recomendada para uso em todas as NICs que operam em ou acima de 10 Gbps. A ATC de Rede faz todas as configurações necessárias para SET.
Considerações sobre o tráfego RDMA
Se você implementar o DCB, deverá garantir que a configuração do PFC e do ETS seja implementada corretamente em todas as portas de rede, incluindo switches de rede. O DCB é necessário para RoCE e opcional para iWARP.
Para obter informações detalhadas sobre como implantar o RDMA, baixe o documento do repositório GitHub do SDN.
As implementações locais do Azure baseadas em RoCE exigem a configuração de três classes de tráfego PFC, incluindo a classe de tráfego padrão, na malha e em todos os hosts.
Classe de tráfego do sistema
Essa classe de tráfego garante que haja largura de banda suficiente reservada para pulsações do sistema:
- Obrigatório: Sim
- Habilitado para PFC: Não
- Prioridade de tráfego recomendada: Prioridade 7
- Reserva de largura de banda recomendada:
- Redes RDMA de 10 GbE ou inferiores = 2%
- Redes RDMA de 25 GbE ou superior = 1%
Classe de tráfego RDMA
Essa classe de tráfego garante que haja largura de banda suficiente reservada para comunicações RDMA sem perdas usando o SMB Direct:
- Obrigatório: Sim
- Habilitado para PFC: Sim
- Prioridade de tráfego recomendada: Prioridade 3 ou 4
- Reserva de largura de banda recomendada: 50%
Classe de tráfego padrão
Essa classe de tráfego transporta todos os outros tráfegos não definidos no sistema ou nas classes de tráfego RDMA, incluindo o tráfego de VM e o tráfego de gerenciamento:
- Obrigatório: por padrão (nenhuma configuração necessária no host)
- Habilitado para controle de fluxo (PFC): Não
- Classe de tráfego recomendada: por padrão (prioridade 0)
- Reserva de largura de banda recomendada: por padrão (nenhuma configuração de host necessária)
Modelos de tráfego de armazenamento
O SMB oferece muitos benefícios como o protocolo de armazenamento para o Azure Local, incluindo SMB Multichannel. O SMB Multichannel não é abordado neste artigo, mas é importante entender que o tráfego é multiplexado em todos os links possíveis que o SMB Multichannel pode usar.
Observação
Recomendamos usar várias sub-redes e VLANs para separar o tráfego de armazenamento no Azure Local.
Considere o seguinte exemplo de um sistema de quatro nós. Cada máquina tem duas portas de armazenamento (lado esquerdo e direito). Como cada adaptador está na mesma sub-rede e VLAN, o SMB Multichannel espalhará as conexões por todos os links disponíveis. Portanto, a porta do lado esquerdo da primeira máquina (192.168.1.1) fará uma conexão com a porta do lado esquerdo da segunda máquina (192.168.1.2). A porta do lado direito da primeira máquina (192.168.1.12) se conectará à porta do lado direito da segunda máquina. Conexões semelhantes são estabelecidas para a terceira e quarta máquinas.
No entanto, isso cria conexões desnecessárias e causa congestionamento no interlink (grupo de agregação de enlace de vários chassis ou MC-LAG) que conecta os switches ToR (marcados com Xs). Confira o seguinte diagrama:
A abordagem recomendada é usar sub-redes e VLANs separadas para cada conjunto de adaptadores. No diagrama a seguir, as portas à direita agora usam a sub-rede 192.168.2.x /24 e a VLAN2. Isso 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 a seguir mostra exemplos de alocações de largura de banda de vários tipos de tráfego, usando velocidades de adaptador comuns, no Azure Local. Observe que este é um exemplo de uma solução convergente, em que todos os tipos de tráfego (computação, armazenamento e gerenciamento) são executados nos mesmos adaptadores físicos e são agrupados usando SET.
Como esse caso de uso apresenta a maioria das restrições, ele representa uma boa linha de base. No entanto, considerando as permutações para o número de adaptadores e velocidades, isso deve ser considerado um exemplo e não um requisito de suporte.
As seguintes suposições são feitas para este exemplo:
Existem dois adaptadores por equipe.
Tráfego SBL (Storage Bus Layer), CSV (Volume Compartilhado Clusterizado) e Hyper-V (Migração ao Vivo):
- Use os mesmos adaptadores físicos.
- Use SMB.
O SMB recebe uma alocação de largura de banda de 50% usando o DCB.
- SBL/CSV é o tráfego de prioridade mais alta e recebe 70% da reserva de largura de banda SMB.
- A LM (Migração ao Vivo) é limitada usando o
Set-SMBBandwidthLimit
cmdlet e recebe 29% da largura de banda restante.Se a largura de banda disponível para a Migração ao Vivo for >= 5 Gbps e os adaptadores de rede forem capazes, use RDMA. Use o seguinte cmdlet para fazer isso:
Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
Se a largura de banda disponível para a Migração ao Vivo for < de 5 Gbps, use a compactação para reduzir os tempos de blecaute. Use o seguinte cmdlet para fazer isso:
Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
Se você estiver usando RDMA para tráfego de migração ao vivo, verifique se o tráfego de migração ao vivo não pode consumir toda a largura de banda alocada para a classe de tráfego RDMA usando um limite de largura de banda SMB. Tenha cuidado, pois esse cmdlet usa a entrada em bytes por segundo (Bps), enquanto os adaptadores de rede são listados em bits por segundo (bps). Use o seguinte cmdlet para definir um limite de largura de banda de 6 Gbps, por exemplo:
Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
Observação
750 MBps neste exemplo equivale a 6 Gbps.
Aqui está o exemplo de tabela de alocação de largura de banda:
Velocidade da placa de rede | Largura de banda agrupada | Reserva de largura de banda SMB** | % SBL/CSV | Largura de banda SBL/CSV | % de migração ao vivo | Largura de banda máxima de migração ao vivo | % de pulsação | Largura de banda de pulsação |
---|---|---|---|---|---|---|---|---|
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 |
* Use compactação em vez de RDMA, pois a alocação de largura de banda para o tráfego de migração ao vivo é <de 5 Gbps.
** 50 por cento é um exemplo de reserva de largura de banda.
Clusters estendidos
Os clusters estendidos fornecem recuperação de desastre que abrange vários datacenters. Em sua forma mais simples, um cluster estendido do Azure Local tem esta aparência:
Requisitos de cluster estendido
Importante
A funcionalidade de cluster estendido só está disponível no Azure Local, versão 22H2.
Os clusters estendidos têm os seguintes requisitos e características:
O RDMA é limitado a um único site e não tem suporte em diferentes sites ou sub-redes.
As máquinas no mesmo local devem residir no mesmo rack e no mesmo limite da Camada 2.
A comunicação do host entre os sites deve cruzar um limite de Camada 3; não há suporte para topologias de Camada 2 estendidas.
Tenha largura de banda suficiente para executar as cargas de trabalho no outro site. No caso de um failover, o site alternativo precisará executar todo o tráfego. Recomendamos que você provisione sites com 50% de sua capacidade de rede disponível. No entanto, isso não é um requisito se você puder tolerar um desempenho inferior durante um failover.
Adaptadores usados para comunicação entre sites:
Pode ser físico ou virtual (vNIC do host). Se os adaptadores forem virtuais, você deverá provisionar uma vNIC em sua própria sub-rede e VLAN por NIC física.
Deve estar em sua própria sub-rede e VLAN que pode rotear entre sites.
O RDMA deve ser desabilitado usando o
Disable-NetAdapterRDMA
cmdlet. Recomendamos que você exija explicitamente que a Réplica de Armazenamento use interfaces específicas usando oSet-SRNetworkConstraint
cmdlet.Deve atender a todos os requisitos adicionais para a Réplica de Armazenamento.
Próximas etapas
- Saiba mais sobre os requisitos de switch de rede e rede física. Consulte Requisitos de rede física.
- Saiba como simplificar a rede de host usando a ATC de Rede. Consulte Simplificar a rede de host com a ATC de Rede.
- Aprimore os conceitos básicos de rede de clustering de failover.
- Consulte Implantar usando o portal do Azure.
- Consulte Implantar usando o modelo do Azure Resource Manager.