Compartilhar via

Requisitos de rede de host para o Azure Stack HCI

  • Artigo

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 o ATC de rede, consulte Simplificar a rede de host com o ATC de rede.

Tipos de tráfego de rede

O tráfego de rede HCI do Azure Stack pode ser classificado de acordo com a 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, Active 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 SMB (Server Message Block), por exemplo, migração ao vivo baseada em SMB ou Storage Spaces Direct. 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 torna intimamente 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 são suportados para uso. Ao examinar 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 os 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.

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 papéis 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 Management, Compute Premium e Storage Premium .

A captura de tela mostra as qualificações

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:

  • Multifila 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 Compute (Premium) oferecem 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: Compute (Premium)

O VMMQ dinâmico é uma tecnologia inteligente de recebimento. Ele se baseia em seus predecessores de VMQ (Virtual Machine Queue), vRSS (Virtual Receive Side Scaling) e VMMQ, para fornecer três aprimoramentos 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 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 da 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 (padrão) ou armazenamento (premium) oferecem suporte a 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 Stack HCI dá suporte ao RDMA com as implementações do protocolo Internet Wide Area RDMA Protocol (iWARP) ou RDMA over Converged Ethernet (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 de fornecedores oferecem 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 localizar adaptadores com a qualificação de Armazenamento (Padrão) 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 Não Sim
Intel Sim Sim (alguns modelos)
Marvell (Qlogic) Sim Sim
Nvidia Não Sim

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

iWARP

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

Use o iWARP se:

  • Você não tem experiência no gerenciamento de redes RDMA.
  • Você não gerencia ou não se sente confortá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 protocolo 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ê está 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: Compute (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.

SET (Agrupamento Incorporado de Comutador)

SET é uma tecnologia de agrupamento baseada em software que foi incluída no sistema operacional Windows Server desde o Windows Server 2016. SET é a única tecnologia de agrupamento com suporte do 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)

SET é a única tecnologia de agrupamento com suporte do Azure Stack HCI. O SET funciona bem com tráfego de computação, armazenamento e gerenciamento.

Importante

O Azure Stack HCI não oferece suporte ao agrupamento de NIC com o LBFO (Balanceamento de Carga/Failover) mais antigo. Consulte a postagem do blog Agrupamento no Azure Stack HCI para obter mais informações sobre 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.
  • 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

Em 22H2, o Network ATC 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 por 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 oferece suporte apenas à configuração independente de switch 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. O ATC de rede faz todas as configurações necessárias para o SET.

Considerações sobre 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 comutadores 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 de HCI do Azure Stack 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
  • Habilitado para PFC: Não
  • Prioridade de tráfego recomendada: Prioridade 7
  • Reserva de largura de banda recomendada:
    • Redes RDMA de 10 GbE ou inferior = 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 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 de VM e 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 fornece 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

Recomendamos o uso de 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 (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 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 switches ToR (marcados com Xs). Confira o seguinte diagrama:

Diagrama que mostra um cluster de quatro nós na mesma sub-rede.

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.

Diagrama que mostra um cluster de quatro nós em diferentes sub-redes.

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 comuns de adaptador, no Azure Stack HCI. 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 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:

  • Há dois adaptadores por equipe.

  • Tráfego SBL (Storage Bus Layer), CSV (Volume Compartilhado de Cluster) e Hyper-V (Live Migration):

    • Use os mesmos adaptadores físicos.
    • Use SMB.

  • O SMB recebe uma alocação de 50% de largura de banda usando DCB.

    • SBL/CSV é o tráfego de maior prioridade e recebe 70% da reserva de largura de banda SMB.
    • A migração ao vivo (LM) é limitada usando o Set-SMBBandwidthLimit cmdlet e recebe 29% da largura de banda restante.

      • Se a largura de banda disponível para 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 o 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 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

    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 NIC 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 Batimento cardíaco % 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, 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

Os 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 a seguinte aparência:

Diagrama que mostra um cluster esticado.

Requisitos de cluster estendidos

Importante

A funcionalidade de cluster estendido só está disponível no Azure Stack HCI, 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.

  • 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; Não há suporte para topologias de Layer-2 esticadas.

  • 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 com 50% da 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 (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óximas etapas