Requisitos de rede de host para o Azure Stack HCI

  • Artigo
  • 14 minutos para o fim da leitura

Aplica-se a: Azure Stack HCI, versões 21H2 e 20H2

Este tópico aborda considerações e requisitos de rede de host para o Azure Stack HCI. Para obter informações sobre arquiteturas de datacenter e as conexões físicas entre servidores, consulte os 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 computação: Tráfego proveniente ou destinado a uma VM (máquina virtual).
  • Tráfego de armazenamento: Tráfego usando o SMB (Server Message Block), por exemplo, Espaços de Armazenamento Diretos ou migração dinâmica baseada em SMB.
  • Tráfego de gerenciamento: Tráfego usado pelo administrador para gerenciamento do cluster, incluindo Área de Trabalho Remota, Windows Admin Center, Active Directory etc.

Selecionar um adaptador de rede

O Azure Stack HCI requer a escolha de um adaptador de rede que tenha obtido a certificação SDDC (Windows Server Software-Defined Data Center) com a Qualificação Adicional Standard ou Premium (AQ). Esses adaptadores dão suporte aos recursos de plataforma mais avançados e passaram por mais testes por nossos parceiros de hardware. Normalmente, esse nível de escrutínio leva a uma redução nos problemas de qualidade relacionados ao hardware e ao driver. Esses adaptadores também atendem aos requisitos de rede estabelecidos para Espaços de Armazenamento Diretos.

Você pode identificar um adaptador com Standard ou Premium AQ examinando a entrada do Catálogo do Windows Server para o adaptador e a versão do sistema operacional aplicável. Aqui está um exemplo da notação para Premium AQ:

Captura de tela das opções certificadas pelo Windows, com uma opção de Perguntas Frequentes Premium realçada.

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áquinas virtuais dinâmicas (VMMQ dinâmico ou d.VMMQ)
  • Acesso Remoto Direto à Memória (RDMA)
  • RDMA convidado
  • Alterne o Agrupamento Incorporado (SET)

VMMQ dinâmico

Todos os adaptadores de rede com o AQ 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: Premium

O VMMQ dinâmico é uma tecnologia inteligente do lado do recebimento. Ele se baseia em seus antecessores de VMQ (Virtual Machine Queue), 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 assim que as VMs atendam e mantenham a taxa de transferência esperada.
  • Permite que cargas de trabalho "intermitidos" recebam a quantidade esperada de tráfego.

Para obter mais informações sobre o VMMQ dinâmico, consulte a postagem de 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 habilita a rede de alta taxa de transferência e baixa latência, usando recursos mínimos de CPU do host. Esses recursos de CPU de host podem ser usados para executar VMs ou contêineres adicionais.

Tipos de tráfego aplicáveis: armazenamento de host

Certificações necessárias: Padrão

Todos os adaptadores com RDMA de suporte do AQ Standard ou Premium. RDMA é a opção de implantação recomendada para cargas de trabalho de armazenamento no Azure Stack HCI e pode ser opcionalmente habilitada para cargas de trabalho de armazenamento (usando SMB) para VMs. Para obter mais informações, consulte a seção "RDMA convidado" mais adiante neste artigo.

O Azure Stack HCI dá suporte a RDMA usando o Protocolo RDMA (protocolo RDMA) da Área Ampla da Internet (iWARP) ou RDMA em implementações de protocolo RoCE (Converged Ethernet).

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 Premium. 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 verificar o suporte a RDMA.

Observação

Não há suporte para InfiniBand (IB) com o Azure Stack HCI.

Fornecedor nic iWARP RoCE
Broadcom Não Sim
Chelsio Sim Não
Intel Sim Sim (alguns modelos)
Marvell (Qlogic/Cavium) Sim Sim
Nvidia (Mellanox) Não Sim

Para obter mais informações sobre como implantar o RDMA, baixe o documento do 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ê tem pouca ou nenhuma experiência de rede ou está desconfortável ao gerenciar comutadores de rede.
  • Você não controla os comutadores de ToR (topo de 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 (User Datagram Protocol) e exige que o PFC e o ETS forneçam confiabilidade.

Use RoCE se:

  • Você já tem implantações com o 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 RDMA em hosts.

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

Certificações necessárias: 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

SET é uma tecnologia de agrupamento baseada em software que foi incluída no sistema operacional Windows Server desde Windows Server 2016. SET não depende do tipo de adaptadores de rede usados.

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

Certificações necessárias: nenhuma (SET é interno no sistema operacional)

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 as tecnologias de agrupamento LBFO (Balanceamento de Carga/Failover) mais antigas e LACP (Link Aggregation Control Protocol) comumente usadas com o Windows Server. Consulte a postagem de 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 principais recursos do Azure Stack HCI (consulte Agrupamento no Azure Stack HCI).

Observe que SET requer o uso de adaptadores simétricos (idênticos). Não há suporte para o agrupamento de adaptadores assimétricos. Adaptadores de rede simétricos são aqueles que têm o mesmo:

  • make (fornecedor)
  • modelo (versão)
  • velocidade (taxa de transferência)
  • configuração

A maneira mais fácil de identificar se os adaptadores são simétricos é se as velocidades são iguais e as descrições da interface correspondem. 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 que se desviam somente 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

O SET dá suporte apenas à configuração independente de comutador usando algoritmos dinâmicos ou de balanceamento de carga da porta 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.

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 nas classes de tráfego de cluster ou 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 espalhará 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 do 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 interlink (grupo de agregação de vínculo de vários chassis ou MC-LAG) que conecta os comutadores de 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 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 sub-redes diferentes.

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.

  • SBL (Camada do Barramento de Armazenamento), CSV (Volume Compartilhado de Cluster) e Tráfego do 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-SMBBandwidthLimit cmdlet 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 SMB

      • Se a largura de banda disponível para Migração Dinâmica for < de 5 Gbps, use a compactação para reduzir os tempos de apagão. Use o seguinte cmdlet para fazer isso:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

  • Se você estiver usando 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 750MB

    Observação

    Neste exemplo, 750 MBps equivalem a 6 Gbps.

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

Velocidade da NIC Largura de banda em equipe Reserva de largura de banda SMB** % SBL/CSV Largura de banda SBL/CSV % de migração dinâmica Largura de banda de Migração Ao Vivo Máxima 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

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:

Diagrama que mostra um cluster estendido.

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 sites ou sub-redes diferentes.

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

  • A comunicação do host entre sites deve cruzar um limite de Camada 3; Topologias de Camada 2 estendidas não têm suporte.

  • 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 em 50% da capacidade de rede disponível. Isso não é um requisito, no entanto, 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 combinados 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 (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 podem 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.

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 .

Diagrama que mostra um exemplo de armazenamento de cluster estendido.

A seguir, mostra os detalhes do exemplo de configuração de cluster estendido.

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