Requisitos de rede de host para Azure Stack HCI

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

Este tópico discute as considerações e os requisitos de rede do host para 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

Azure Stack HCI tráfego de rede pode ser classificado por sua finalidade pretendida:

  • Tráfego de computação: Tráfego proveniente ou destinado a uma VM (máquina virtual).
  • Armazenamento tráfego: tráfego para Espaços de Armazenamento Direct (S2D), usando o SMB (Bloco de Mensagens do Servidor).
  • Tráfego de gerenciamento: Tráfego importante para um administrador de gerenciamento de cluster, como Active Directory, Área de Trabalho Remota, Windows Admin Center e Windows PowerShell.

Selecionar um adaptador de rede

Azure Stack HCI requer a escolha de um adaptador de rede que tenha obtido a certificação do SDDC (Data Center do Windows Server Software-Defined) com a AQ (Qualificação Adicional) standard ou Premium. Esses adaptadores suportam os recursos de plataforma mais avançados e passaram por mais testes por nossos parceiros de hardware. Normalmente, esse nível de investigação 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 Direct.

Você pode identificar um adaptador que tenha o Standard ou Premium AQ, revendo 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 Windows Opções certificadas, com uma Premium AQ realçada.

Visão geral dos principais recursos do adaptador de rede

As funcionalidades importantes do adaptador de rede usadas Azure Stack HCI incluem:

  • Multifila de Máquinas Virtuais Dinâmicas (VMMQ dinâmico ou d.VMMQ)
  • Acesso Remoto Direto à Memória (RDMA)
  • RDMA convidado
  • Set (Switch Embedded Teaming)

VMMQ dinâmico

Todos os adaptadores de rede com o Premium AQ são suportados pelo 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 e do lado do recebimento. Ele se baseia em seus antecessores de Fila de Máquina Virtual (VMQ), 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 atendem e mantenham a produtividade esperada.
  • Permite que cargas de trabalho "estouradas" 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

O 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 uma 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: Padrão

Todos os adaptadores com Standard ou Premium AQ são suportados por RDMA. O RDMA é a opção de implantação recomendada para cargas de trabalho de armazenamento no Azure Stack HCI e pode ser opcionalmente habilitado 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.

Azure Stack HCI dá suporte a RDMA usando as implementações de protocolo 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 são suportados por RDMA. A tabela a seguir lista os fornecedores (em ordem alfabética) que oferecem Premium adaptadores RDMA certificados. No entanto, há fornecedores de hardware não incluídos nesta lista que também são suportados por RDMA. Consulte o catálogo Windows servidor para verificar o suporte a RDMA.

Observação

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

Fornecedor da NIC iWARP RoCE
Broadcom Não Sim
Gregsio Sim Não
Intel Sim Sim (alguns modelos)
Marvell (Qlogic/Ium) Sim Sim
Nvidia (Mellanox) Não Sim

Para obter mais informações sobre como implantar o RDMA, baixe o documento do GitHub SDN.

iWARP

O iWARP usa o protocolo TCP e, opcionalmente, pode ser aprimorado com PFC (Priority-based Flow Control) e ETS (Serviço de Transmissão Aprimorado).

Use iWARP se:

  • Você tem pouca ou nenhuma experiência de rede ou não está gerenciando comutadores de rede.
  • Você não controla seus comutadores 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 protocolo UDP 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 ao 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 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 GitHub SDN.

SET

SET é uma tecnologia de equipe 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 (o conjunto é compilado no sistema operacional)

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

Importante

o balanceamento de carga/Failover (LBFO) é outra tecnologia de agrupamento comumente usada com o Windows Server, mas não tem suporte com o Azure Stack HCI. Confira a equipe de postagem no blog em Azure Stack HCI para saber mais sobre LBFO no Azure Stack HCI.

O conjunto é importante para 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 principais 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 Agrupamento de adaptadores assimétricos. Os 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 as mesmas e as descrições de interface correspondem. Eles podem se desviar apenas do numerador 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 deviating somente por Numeral (#):

Name Descrição da interface Velocidade do link
NIC1 #1 de adaptador de rede 25 Gbps
NIC2 #2 de adaptador de rede 25 Gbps
NIC3 #3 de adaptador de rede 25 Gbps
NIC4 #4 de adaptador de rede 25 Gbps

Observação

SET oferece 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.

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 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 de GitHub SDN.

As implementações de HCI Azure Stack baseadas em RoCE exigem a configuração de três classes de tráfego de 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 reservada suficiente para pulsações de cluster:

  • Exigida: Sim
  • PFC – habilitado: não
  • Prioridade de tráfego recomendada: prioridade 7
  • Reserva de largura de banda recomendada:
    • redes RDMA de 10 GbE ou inferiores = 2%
    • 25 GbE ou mais de redes RDMA = 1 por cento

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 SMB Direct:

  • Exigida: 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 transporta 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 Flow (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 fornece muitos benefícios como o protocolo de armazenamento para Azure Stack HCI, incluindo SMB multicanal. 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 multicanal 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 (lado esquerdo e direito). Como cada adaptador está na mesma sub-rede e VLAN, o SMB multicanal espalhará conexões entre 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 o 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). Consulte o diagrama a seguir:

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

A abordagem recomendada é usar sub-redes separadas e VLANs 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 em 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 as alocações de largura de banda de exemplo de vários tipos de tráfego, usando velocidades de adaptador comuns, em Azure Stack HCI. Observe que este é 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 apresenta a maioria das restrições, ele representa uma boa linha de base. No entanto, considerando as permutas 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 neste exemplo:

  • Há dois adaptadores por equipe.

  • tráfego de camada de barramento de Armazenamento (SBL), Volume Compartilhado Clusterizado (CSV) 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.

    • O SBL/CSV é o tráfego de prioridade mais alta e recebe 70% da reserva de largura de banda SMB.
    • Migração ao Vivo (LM) é limitado 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 compatíveis, use RDMA. Use o seguinte cmdlet para fazer isso:

        Set-VMHost VirtualMachineMigrationPerformanceOption SMB
        
      • Se a largura de banda disponível para 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 Migração ao Vivo, verifique se Migração ao Vivo tráfego 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, porque 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

    750 MBps neste exemplo equivale 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** % de SBL/CSV Largura de banda SBL/CSV Migração ao Vivo % Largura de banda Migração ao Vivo máx. % de pulsação Largura de banda da pulsação
10 Gbps 20 Gbps 10 Gbps 70% 7 Gbps * * 2% 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 a compactação em vez de RDMA, porque a alocação de largura de banda Migração ao Vivo tráfego é < 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 Azure Stack HCI cluster 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 diferentes sites ou sub-redes.

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

  • A comunicação de host entre sites deve cruzar um limite de Camada 3; Não há suporte para topologias de Camada 2 estendidas.

  • 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% da capacidade de rede disponível. Isso não é um requisito, no entanto, se você for capaz de tolerar um desempenho inferior 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 unidos com SET. Os adaptadores também devem ter NICs virtuais adicionais provisionadas para tráfego de tabela entre sites.

  • Adaptadores usados para comunicação entre sites:

    • Pode ser físico ou virtual (host vNIC). Se os adaptadores são virtuais, você deve provisionamento de 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 roteá-los entre sites.

    • O RDMA deve ser desabilitado usando o Disable-NetAdapterRDMA cmdlet . Recomendamos que você explicitamente Armazenamento Replica para usar interfaces específicas usando o Set-SRNetworkConstraint cmdlet .

    • Deve atender a quaisquer requisitos adicionais para Armazenamento Replica.

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.

Veja a seguir os detalhes da configuração de cluster estendido de exemplo.

Observação

Sua configuração exata, incluindo nomes de 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 habilitado, não é habilitada 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 habilitado, não é habilitada 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 ampliada, RDMA desabilitado, tabela de rdmas 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 Tabelas entre sites
NodeA2 Stretch1 pNIC01 173.0.0.2/8 Tabelas entre sites
NodeA1 Stretch2 pNIC02 174.0.0.1/8 Tabelas entre sites
NodeA2 Stretch2 pNIC02 174.0.0.2/8 Tabelas entre sites

SiteB – replicação ampliada, RDMA desabilitado, tabela de rdmas 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 Tabelas 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