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 conexões físicas entre servidores, consulte requisitos de rede física.

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

Tipos de tráfego de rede

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

  • Tráfego de computação: Tráfego originado de ou destinado a uma VM (máquina virtual).
  • tráfego de Armazenamento: tráfego para Espaços de Armazenamento direto (S2D), usando o protocolo SMB.
  • Tráfego de gerenciamento: tráfego importante para um administrador para 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 atingido a certificação do Windows Server Software-Defined data Center (SDDC) com o padrão ou Premium qualificação adicional (AQ). Esses adaptadores oferecem suporte aos recursos mais avançados da plataforma e passaram na maior parte dos testes por nossos parceiros de hardware. Normalmente, esse nível de investigação leva a uma redução no hardware e nos problemas de qualidade relacionados a drivers. esses adaptadores também atendem aos requisitos de rede estabelecidos para Espaços de Armazenamento direto.

você pode identificar um adaptador que tem o padrão 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:

Screenshot of Windows Certified options, with a Premium AQ option highlighted.

Visão geral dos principais recursos do adaptador de rede

Os principais recursos do adaptador de rede usados pelo Azure Stack HCI incluem:

  • Várias filas de máquinas virtuais dinâmicas (Dynamic VMMQ ou d. VMMQ)
  • Acesso Remoto Direto à Memória (RDMA)
  • RDMA de convidado
  • Alternar equipe inserida (SET)

VMMQ dinâmico

todos os adaptadores de rede com o Premium AQ dão suporte a VMMQ dinâmico. O Dynamic VMMQ requer o uso do switch Embedded Integration.

Tipos de tráfego aplicáveis: computação

Certificações necessárias: Premium

O Dynamic VMMQ é uma tecnologia inteligente e de recebimento. Ele se baseia em seus antecessores de Fila de Máquina Virtual (VMQ), no VMMQ virtual de recepção (vRSS) e no am, 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 assim 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 VMMQ dinâmicos, consulte a postagem de 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: Standardization

todos os adaptadores com AQ Standard ou Premium suportam RDMA. 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 "convidado RDMA" mais adiante neste artigo.

Azure Stack HCI dá suporte a RDMA usando as implementações de protocolo iWARP (Internet Wide Area RDMA) ou RDMA em Ethernet convergidas (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 dão suporte a 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 dão suporte a RDMA. consulte o catálogo do Windows Server para verificar o suporte a RDMA.

Observação

A InfiniBand (IB) não tem suporte com o HCI Azure Stack.

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

iWARP

o iWARP usa o protocolo TCP e pode ser opcionalmente aprimorado com o controle de Flow baseado em prioridade (PFC) e o serviço de transmissão avançada (ETS).

Use iWARP se:

  • Você tem pouca ou nenhuma experiência de rede ou está desconfortável Gerenciando comutadores de rede.
  • Você não controla 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 UDP (User Datagram Protocol) e requer PFC e ETS para fornecer confiabilidade.

Use RoCE se:

  • Você já tem implantações com o RoCE em seu datacenter.
  • Você está familiarizado com o gerenciamento dos requisitos de rede do DCB.

RDMA de convidado

A RDMA convidada permite que as cargas de trabalho SMB tenham os mesmos benefícios de usar o RDMA nos hosts.

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

Certificações necessárias: Premium

Os principais benefícios de usar o convidado RDMA são:

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

SET

o conjunto é uma tecnologia de agrupamento baseada em software que foi incluída no sistema operacional do 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: nenhum (SET é integrado ao 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/Failover de Carga (LBFO) é outra tecnologia de equipe comumente usada com o Windows Server, mas não tem suporte com Azure Stack HCI. Consulte a postagem no blog Teaming in Azure Stack HCI para obter mais informações sobre LBFO em Azure Stack HCI.

SET é importante para Azure Stack HCI porque é a única tecnologia de equipe que permite:

  • Colocação em equipe de adaptadores RDMA (se necessário).
  • RDMA convidado.
  • VMMQ dinâmico.
  • Outros recursos Azure Stack HCI chave (consulte Teaming in Azure Stack HCI).

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

  • make (fornecedor)
  • modelo (versão)
  • velocidade (produtividade)
  • 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 da interface são iguais. Eles podem se desviar somente no numeral listado na descrição. Use o Get-NetAdapterAdvancedProperty cmdlet para garantir que a configuração relatada lista os mesmos valores de propriedade.

Consulte a tabela a seguir para ver um exemplo das descrições da interface que se desviam apenas pelo 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 opção 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 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 GitHub SDN.

As implementações de Azure Stack HCI 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 perda 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)
  • Flow controle (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)

Armazenamento de tráfego

O SMB oferece muitos benefícios como o protocolo de armazenamento para 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 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 difundi 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 as opções ToR (marcadas com Xs). Consulte o diagrama a seguir:

Diagram that shows a four-node cluster on the same subnet.

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 em TOR1 e o tráfego nas portas do lado direito permaneça em TOR2.

Diagram that shows a four-node cluster on different subnets.

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, 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 unidos 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.

  • Armazenamento SBL (camada de barramento), Volume Compartilhado Clusterizado (CSV) e tráfego do 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.
    • 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 são > capazes, 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 redução. Use o seguinte cmdlet para fazer isso:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
        
  • Se você estiver usando o RDMA para tráfego Migração ao Vivo, verifique se o tráfego 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, porque esse cmdlet entra 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 equivalem a 6 Gbps.

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

Velocidade da NIC Largura de banda agrupada Reserva de largura de banda SMB * * SBL/CSV% Largura de banda SBL/CSV Migração ao Vivo% Largura de banda máxima do Migração ao Vivo Batida Largura de banda de 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, pois 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.

Clusters ampliados

Os clusters ampliados fornecem recuperação de desastres que abrange vários data centers. Em sua forma mais simples, uma rede de cluster HCI ampliada Azure Stack tem esta aparência:

Diagram that shows a stretched cluster.

Requisitos de cluster ampliados

Os clusters ampliados 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 de camada 2.

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

  • 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 a 50% de sua capacidade de rede disponível. No entanto, isso não é um requisito, 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 agrupados com o conjunto. 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 um 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. é recomendável que você explicitamente exija que Armazenamento réplica usem interfaces específicas usando o Set-SRNetworkConstraint cmdlet.

    • deve atender a quaisquer requisitos adicionais para Armazenamento réplica.

Exemplo de cluster ampliado

O exemplo a seguir ilustra uma configuração de cluster ampliada. Para garantir que uma NIC virtual específica seja mapeada para um adaptador físico específico, use o cmdlet set-VMNetworkAdapterTeammapping .

Diagram that shows an example of stretched cluster storage.

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

Observação

A configuração exata, incluindo nomes de NIC, endereços IP e VLANs, pode ser diferente da mostrada. 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 roteável entre sites

Nome do nó nome do 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 roteável entre sites

Nome do nó nome do 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, roteável entre sites

Nome do nó nome do 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 ampliada, RDMA desabilitado, roteável entre sites

Nome do nó nome do 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