Requisitos de rede de host para HCI do Azure Stack

Aplica-se a: Azure Stack HCI, versões 23H2 e 22H2

Este tópico discute considerações e requisitos de rede de host para o Azure Stack HCI. Para obter informações sobre arquiteturas de datacenter e conexões físicas entre servidores, consulte Requisitos de rede física.

Para obter informações sobre como simplificar a rede host usando ATC de rede, consulte Simplificar rede de host com ATC de rede.

Tipos de tráfego de rede

O tráfego de rede HCI do Azure Stack pode ser classificado pela finalidade pretendida:

• Tráfego de gerenciamento: tráfego de ou para fora do cluster local. Por exemplo, tráfego de réplica de armazenamento ou tráfego usado pelo administrador para gerenciamento do cluster, como Área de Trabalho Remota, Windows Admin Center, Ative Directory, etc.
• Tráfego de computação: tráfego originado ou destinado a uma máquina virtual (VM).
• Tráfego de armazenamento: tráfego usando o Server Message Block (SMB), por exemplo, Storage Spaces Direct ou migração ao vivo baseada em SMB. Esse tráfego é tráfego de camada 2 e não é roteável.

Selecione um adaptador 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 uso. À medida que você analisa 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 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 o 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 este link.

Requisitos 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:

• Máquina Virtual Dinâmica Multi-Fila (VMMQ Dinâmico ou d.VMMQ)
• Acesso Remoto Direto à Memória (RDMA)
• RDMA convidado
• Agrupamento incorporado de switch (SET)

VMMQ dinâmico

Todos os adaptadores de rede com a qualificação Compute (Premium) suportam VMMQ dinâmico. O VMMQ dinâmico requer o uso do Switch Embedded Teaming.

Tipos de tráfego aplicáveis: calcular

Certificações necessárias: Computação (Premium)

O VMMQ dinâmico é uma tecnologia inteligente do lado da receção. Ele se baseia em seus antecessores 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 do 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 redes de alta taxa de transferência e baixa latência, usando recursos mínimos da 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) suportam 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 a RDMA com as implementações do protocolo iWARP (Internet Wide Area RDMA Protocol) ou RDMA over Converged Ethernet (RoCE).

Nem todos os adaptadores de rede de fornecedores suportam RDMA. A tabela a seguir lista os fornecedores (em 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 encontrar adaptadores com a qualificação Storage (Standard) ou Storage (Premium) que requerem suporte RDMA.

Para obter mais informações sobre como implantar o RDMA para o host, é altamente recomendável usar o ATC de rede. Para obter informações sobre a implantação manual, consulte o repositório SDN GitHub.

URDIDURA

O iWARP usa TCP (Transmission Control Protocol) e pode ser opcionalmente aprimorado com PFC (Priority-based Flow Control) e ETS (Enhanced Transmission Service).

Utilize 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 UDP (User Datagram Protocol) e requer PFC e ETS para fornecer confiabilidade.

Use 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 as cargas de trabalho SMB para VMs obtenham os mesmos benefícios do uso do RDMA em hosts.

Tipos de tráfego aplicáveis: armazenamento baseado em convidado

Certificações necessárias: Computação (Premium)

Os principais benefícios do uso do RDMA convidado são:

• Descarregamento da 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 SDN GitHub.

Agrupamento incorporado de switch (SET)

O SET é uma tecnologia de agrupamento baseada em software incluída no sistema operacional Windows Server desde o 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 gerenciamento e é suportado com até oito adaptadores na mesma equipe.

Tipos de tráfego aplicáveis: computação, armazenamento e gerenciamento

Certificações necessárias: Compute (Standard) ou Compute (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 gerenciamento.

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.
• Outros recursos importantes do Azure Stack HCI (consulte Teaming in 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 Network ATC detetará automaticamente e informará 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 descrições da interface são correspondências exatas . Podem desviar-se apenas no algarismo indicado 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 por numeral (#):

Considerações sobre tráfego RDMA

Se você implementar DCB, deverá garantir que a configuração de PFC e ETS seja implementada corretamente em todas as portas de rede, incluindo switches de rede. 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 SDN GitHub.

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:

• Obrigatório: sim
• Compatível com 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 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:

• Obrigatório: sim
• Compatível com PFC: Sim
• Prioridade de tráfego recomendada: Prioridade 3 ou 4
• Reserva de largura de banda recomendada: 50 por cento

Classe de tráfego padrão

Essa classe de tráfego carrega todo o outro tráfego não definido no cluster ou nas classes de tráfego RDMA, incluindo tráfego VM e tráfego de gerenciamento:

• Obrigatório: Por padrão (nenhuma configuração necessária no host)
• Compatível com 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 (sem necessidade de configuração de host)

Modelos de tráfego de armazenamento

O SMB fornece muitos benefícios como o protocolo de armazenamento para o Azure Stack HCI, 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.

Considere o exemplo a seguir de um cluster de quatro nós. Cada servidor tem duas portas de armazenamento (lado esquerdo e direito). Como cada adaptador está na mesma sub-rede e VLAN, o SMB Multichannel distribuirá as 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 na interligação (grupo de agregação de link de vários chassis ou MC-LAG) que conecta os switches ToR (marcados com Xs). Veja 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 exemplos de alocações de largura de banda de vários tipos de tráfego, usando velocidades de adaptador comuns, no Azure Stack HCI. Observe que este é um exemplo de uma solução convergente, onde 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 equipa.

• Tráfego SBL (Storage Bus Layer), CSV (Volume Compartilhado de Cluster) 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 DCB.

  • SBL/CSV é o tráfego de prioridade mais alta e recebe 70% da reserva de largura de banda SMB.
  • A migração ao vivo (LM) é limitada pelo uso do 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 o Live Migration for < de 5 Gbps, use a compactação para reduzir os tempos de blackout. Use o seguinte cmdlet para fazer isso:

      Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
      

• Se você estiver usando RDMA para tráfego de Migração ao Vivo, certifique-se de que o tráfego de Migração ao Vivo não possa 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 recebe entrada em bytes por segundo (Bps), enquanto os adaptadores de rede são listados em bits por segundo (bps). Use o cmdlet a seguir para definir um limite de largura de banda de 6 Gbps, por exemplo:

  Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
  

  Nota

  750 MBps neste exemplo equivale a 6 Gbps.

Aqui está o exemplo de tabela de alocação de largura de banda:

* Use compactação em vez de RDMA, porque 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.

Aglomerados esticados

Clusters estendidos fornecem recuperação de desastres que abrange vários datacenters. Em sua forma mais simples, uma rede de cluster HCI do Azure Stack estendida tem esta aparência:

Requisitos de cluster estendidos

Os clusters esticados têm os seguintes requisitos e características:

• O RDMA é limitado a um único site e não é suportado em diferentes sites ou sub-redes.

• Os servidores no mesmo site devem residir no mesmo rack e limite de camada 2.

• A comunicação do host entre sites deve cruzar um limite de Camada 3; topologias de Camada 2 esticadas não são suportadas.

• Ter 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 em 50% de sua capacidade de rede disponível. Isso não é um requisito, no entanto, se você for capaz de tolerar um desempenho mais baixo durante um failover.

• Adaptadores usados para comunicação entre sites:

  • Pode ser físico ou virtual (host vNIC). 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 o Set-SRNetworkConstraint cmdlet.

  • Deve atender a quaisquer requisitos adicionais para a réplica de armazenamento.

Próximos passos

• 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 o Network ATC. Consulte Simplificar a rede de host com ATC de rede.
• Aprimore as noções básicas de rede de clustering de failover.
• Consulte Implantar usando o portal do Azure.
• Consulte Implantar usando o modelo do Azure Resource Manager.