Requisitos de rede de host para o Azure Stack HCI
Aplica-se a: Azure Stack HCI, versões 23H2 e 22H2
Este tópico discute as considerações e os requisitos de rede do host para o Azure Stack HCI. Para obter informações sobre arquiteturas de datacenter e as conexões físicas entre servidores, 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 do Azure Stack HCI pode ser classificado por sua finalidade pretendida:
- Tráfego de gerenciamento: Tráfego de ou para fora do cluster local. Por exemplo, o armazenamento réplica tráfego ou tráfego usado pelo administrador para gerenciamento do cluster, como Área de Trabalho Remota, Windows Admin Center, Active Directory etc.
- Tráfego de computação: Tráfego proveniente ou destinado a uma VM (máquina virtual).
- Tráfego de armazenamento: Tráfego usando o protocolo SMB, por exemplo, Espaços de Armazenamento Diretos ou migração dinâmica baseada em SMB. Esse 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. Essa 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.
Selecionar um adaptador de rede
Os adaptadores de rede são qualificados pelos tipos de tráfego de rede (veja acima) com os quais eles 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 funções a seguir. Antes de comprar um servidor para o Azure Stack HCI, você deve ter minimamente pelo menos um adaptador qualificado para gerenciamento, computação e armazenamento, pois todos os três tipos de tráfego são necessários no Azure Stack HCI. 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 nic baseada em função, consulte este link.
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 | Padrão de Computação | Padrão de Armazenamento |
| 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 de Gerenciamento, Computação Premium e Armazenamento Premium .
Exigências do driver
Não há suporte para drivers de caixa de entrada para uso com o Azure Stack HCI. 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 Stack HCI 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 Agrupamento Inserido com 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 do recebimento. Ele se baseia em seus antecessores de VMQ (Fila de Máquina Virtual), vRSS (Virtual Receive Side Scaling) 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 "com intermitência" 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 SMB ignore o sistema operacional para processamento.
O RDMA permite a rede 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 (Standard)
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 convidado" mais adiante neste artigo.
O Azure Stack HCI dá suporte ao RDMA com as implementações de protocolo iWARP (Protocolo RDMA de Área Ampla da Internet) ou RDMA sobre Implementações de protocolo RoCE (Ethernet Converged).
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 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 dão suporte a RDMA. Consulte o Catálogo do Windows Server para localizar adaptadores com a qualificação de Armazenamento (Standard) ou Armazenamento (Premium) que exigem suporte a RDMA.
Observação
Não há suporte para InfiniBand (IB) com o Azure Stack HCI.
| Fornecedor de NIC | iWARP | RoCE |
|---|---|---|
| Broadcom | No | Yes |
| Intel | Sim | Sim (alguns modelos) |
| Marvell (Qlogic) | Yes | Yes |
| Nvidia | No | Yes |
Para obter mais informações sobre como implantar o RDMA para o host, é altamente recomendável usar 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, opcionalmente, pode ser aprimorado com o PFC (Controle de Fluxo Baseado em Prioridade) e o ETS (Serviço de Transmissão Avançada).
Use iWARP se:
- Você não tem experiência no gerenciamento de redes RDMA.
- Você não gerencia ou se sente desconfortável ao gerenciar seus comutadores tor (top-of-rack).
- 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 UDP (Protocolo de Datagrama de Usuário) e exige que o PFC e o ETS forneçam confiabilidade.
Use RoCE se:
- Você já tem implantações com RoCE em seu datacenter.
- Você está confortável em gerenciar os requisitos de rede do DCB.
RDMA convidado
O RDMA convidado permite que cargas de trabalho SMB para VMs obtenham os mesmos benefícios de usar o 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.
- Alta taxa de transferência.
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. SET é a única tecnologia de agrupamento com suporte do Azure Stack HCI. SET funciona bem com tráfego de computação, armazenamento e gerenciamento e tem suporte com até oito adaptadores na mesma equipe.
Tipos de tráfego aplicáveis: computação, armazenamento e gerenciamento
Certificações necessárias: Computação (Standard) ou Computação (Premium)
SET é a única tecnologia de agrupamento com suporte do Azure Stack HCI. SET funciona bem com computação, armazenamento e tráfego de gerenciamento.
Importante
O Azure Stack HCI não dá suporte ao agrupamento NIC com o LBFO (Balanceamento de Carga/Failover) mais antigo. Confira a postagem no blog Agrupamento no Azure Stack HCI para obter mais informações sobre LBFO no Azure Stack HCI.
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.
- Outros recursos importantes do Azure Stack HCI (consulte Agrupamento no Azure Stack HCI).
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 são correspondências exatas . Eles só podem se desviar 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 da interface desviando apenas por numeral (#):
| Nome | Descrição da interface | Velocidade do link |
|---|---|---|
| NIC1 | Adaptador de rede nº 1 | 25 Gbps |
| NIC2 | Adaptador de rede nº 2 | 25 Gbps |
| NIC3 | Adaptador de rede nº 3 | 25 Gbps |
| NIC4 | Adaptador de rede nº 4 | 25 Gbps |
Observação
SET dá suporte apenas à configuração independente de 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 de tráfego RDMA
Se você implementar o DCB, deverá garantir que a configuração de PFC e ETS seja implementada corretamente em todas as portas de rede, incluindo comutadores 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 do Azure Stack HCI 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 de cluster
Essa classe de tráfego garante que haja largura de banda suficiente reservada para pulsações de cluster:
- Exigida: Sim
- Habilitado para PFC: Não
- Prioridade de tráfego recomendada: Prioridade 7
- Reserva de largura de banda recomendada:
- 10 GbE ou redes RDMA inferiores = 2%
- 25 GbE ou redes RDMA superiores = 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:
- Exigida: 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 carrega todo o tráfego não definido no cluster ou nas classes de tráfego RDMA, incluindo tráfego de VM e tráfego de gerenciamento:
- Obrigatório: por padrão (nenhuma configuração necessária no host)
- Controle de fluxo (PFC)habilitado: 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 Stack HCI, incluindo o 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
É recomendável usar várias sub-redes e VLANs para separar o tráfego de armazenamento no Azure Stack HCI.
Considere o exemplo a seguir de um cluster de quatro nós. Cada servidor tem duas portas de armazenamento (esquerda e direita). Como cada adaptador está na mesma sub-rede e VLAN, o SMB Multichannel distribuirá conexões em todos os links disponíveis. Portanto, a porta do lado esquerdo no primeiro servidor (192.168.1.1) fará uma conexão com a porta do lado esquerdo no segundo servidor (192.168.1.2). A porta do lado direito no primeiro servidor (192.168.1.12) se conectará à porta do lado direito no segundo servidor. Conexões semelhantes são estabelecidas para o terceiro e quarto servidores.
No entanto, isso cria conexões desnecessárias e causa congestionamento no interlink (grupo de agregação de link de vários chassis ou MC-LAG) que conecta os comutadores ToR (marcados com Xs). Confira o diagrama a seguir:
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 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 alocações de largura de banda de exemplo de vários tipos de tráfego, usando velocidades comuns do adaptador, no Azure Stack HCI. Observe que esse é um exemplo de uma solução convergida, 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 representa 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:
Há dois adaptadores por equipe.
Tráfego de SBL (Camada de Barramento de Armazenamento), CSV (Volume Compartilhado Clusterizado) e Hyper-V (Migração Dinâmica):
- Use os mesmos adaptadores físicos.
- Use SMB.
O SMB recebe uma alocação de largura de banda de 50% usando DCB.
- SBL/CSV é o tráfego de prioridade mais alta e recebe 70% da reserva de largura de banda SMB.
- A LM (Migração Dinâmica) é limitada usando o
Set-SMBBandwidthLimitcmdlet e recebe 29% da largura de banda restante.Se a largura de banda disponível para Migração Dinâmica for >= 5 Gbps e os adaptadores de rede forem capazes, use RDMA. Use o seguinte cmdlet para fazer isso:
Set-VMHost -VirtualMachineMigrationPerformanceOption SMBSe a largura de banda disponível para Migração Dinâmica for < de 5 Gbps, use compactação para reduzir os tempos de apagão. Use o seguinte cmdlet para fazer isso:
Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
Se você estiver usando o RDMA para tráfego de Migração Dinâmica, verifique se o tráfego de Migração Dinâmica 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 entra 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 750MBObservação
Neste exemplo, 750 MBps equivalem a 6 Gbps.
Aqui está o exemplo de tabela de alocação de largura de banda:
| Velocidade nic | Largura de banda agrupada | Reserva de largura de banda do SMB** | % de SBL/CSV | Largura de banda SBL/CSV | % de migração dinâmica | 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 Dinâmica é <de 5 Gbps.
** 50% é uma reserva de largura de banda de exemplo.
Clusters estendidos
Os clusters estendidos fornecem recuperação de desastre que abrange vários datacenters. Em sua forma mais simples, uma rede de cluster do Azure Stack HCI estendida tem esta aparência:
Requisitos de cluster estendido
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.
Os servidores no mesmo site devem residir no mesmo rack e no limite da Camada 2.
A comunicação de host entre sites deve cruzar um limite de Camada 3; Não há suporte para topologias estendidas de Camada 2.
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% da capacidade de rede disponível. No entanto, isso não é um requisito se você for capaz de tolerar um desempenho menor durante um failover.
A replicação entre sites (tráfego norte/sul) pode usar as mesmas NICs físicas que o armazenamento local (tráfego leste/oeste). Se você estiver usando os mesmos adaptadores físicos, esses adaptadores deverão ser agrupados com SET. Os adaptadores também devem ter NICs virtuais adicionais provisionadas para tráfego roteável entre sites.
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 possa rotear entre sites.
O RDMA deve ser desabilitado usando o
Disable-NetAdapterRDMAcmdlet . Recomendamos que você exija explicitamente que a Réplica de Armazenamento use interfaces específicas usando oSet-SRNetworkConstraintcmdlet .Deve atender a quaisquer requisitos adicionais para a Réplica de Armazenamento.
Exemplo de cluster estendido
O exemplo a seguir ilustra uma configuração de cluster estendido. Para garantir que uma NIC virtual específica seja mapeada para um adaptador físico específico, use o cmdlet Set-VMNetworkAdapterTeammapping .
O exemplo a seguir mostra os detalhes da configuração de cluster estendido de exemplo.
Observação
Sua configuração exata, incluindo nomes NIC, endereços IP e VLANs, pode ser diferente do que é mostrado. Isso é usado apenas como uma configuração de referência que pode ser adaptada ao seu ambiente.
SiteA – Replicação local, RDMA habilitada, não roteável entre sites
| Nome do nó | Nome da vNIC | NIC física (mapeada) | VLAN | IP e sub-rede | Escopo do tráfego |
|---|---|---|---|---|---|
| NodeA1 | vSMB01 | pNIC01 | 711 | 192.168.1.1/24 | Somente site local |
| NodeA2 | vSMB01 | pNIC01 | 711 | 192.168.1.2/24 | Somente site local |
| NodeA1 | vSMB02 | pNIC02 | 712 | 192.168.2.1/24 | Somente site local |
| NodeA2 | vSMB02 | pNIC02 | 712 | 192.168.2.2/24 | Somente site local |
SiteB – Replicação local, RDMA habilitada, não roteável entre sites
| Nome do nó | Nome da vNIC | NIC física (mapeada) | VLAN | IP e sub-rede | Escopo do tráfego |
|---|---|---|---|---|---|
| NodeB1 | vSMB01 | pNIC01 | 711 | 192.168.1.1/24 | Somente site local |
| NodeB2 | vSMB01 | pNIC01 | 711 | 192.168.1.2/24 | Somente site local |
| NodeB1 | vSMB02 | pNIC02 | 712 | 192.168.2.1/24 | Somente site local |
| NodeB2 | vSMB02 | pNIC02 | 712 | 192.168.2.2/24 | Somente site local |
SiteA – Replicação estendida, RDMA desabilitada, roteável entre sites
| Nome do nó | Nome da vNIC | NIC física (mapeada) | IP e sub-rede | Escopo do tráfego |
|---|---|---|---|---|
| NodeA1 | Stretch1 | pNIC01 | 173.0.0.1/8 | Roteável entre Sites |
| NodeA2 | Stretch1 | pNIC01 | 173.0.0.2/8 | Roteável entre Sites |
| NodeA1 | Stretch2 | pNIC02 | 174.0.0.1/8 | Roteável entre Sites |
| NodeA2 | Stretch2 | pNIC02 | 174.0.0.2/8 | Roteável entre Sites |
SiteB – Replicação estendida, RDMA desabilitada, roteável entre sites
| Nome do nó | Nome da vNIC | NIC física (mapeada) | IP e sub-rede | Escopo do tráfego |
|---|---|---|---|---|
| NodeB1 | Stretch1 | pNIC01 | 175.0.0.1/8 | Roteável entre Sites |
| NodeB2 | Stretch1 | pNIC01 | 175.0.0.2/8 | Roteável entre Sites |
| NodeB1 | Stretch2 | pNIC02 | 176.0.0.1/8 | Roteável entre Sites |
| NodeB2 | Stretch2 | pNIC02 | 176.0.0.2/8 | Roteável entre Sites |
Próximas etapas
- Saiba mais sobre o comutador de rede e os requisitos de rede física. Confira Requisitos de rede física.
- Saiba como simplificar a rede de host usando a ATC de Rede. Confira Simplificar a rede de host com a ATC de Rede.
- Ative o failover clustering noções básicas de rede.
- 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