Azure Local padrões de referência para redes de clusters com reconhecimento de rack

Este artigo contém informações sobre o design de rede e a configuração de um cluster com reconhecimento de rack local do Azure. Essa configuração envolve um único cluster em que os nós são colocados em locais físicos diferentes dentro de um edifício.

A intenção principal é dar suporte a ambientes de fábrica em que o hardware deve ser isolado em salas diferentes devido a requisitos regulatórios, protocolos de segurança ou restrições operacionais. Esse isolamento fornece separação de domínio de falha, mantendo a funcionalidade do cluster para cargas de trabalho industriais críticas.

A configuração do cluster com reconhecimento de rack também pode dar suporte a cenários de recuperação de desastre colocando cargas de trabalho diferentes em um ou em ambos os locais. Essa configuração dá suporte a ambientes com ou sem rede definida por software (SDN) ou redes virtuais de Camada 2.

Principais princípios de rede

A configuração do cluster com reconhecimento de rack destina-se a dar suporte a ambientes com até 4 ou 4 nós, em que o cluster é separado em duas zonas de disponibilidade locais com latência menor ou igual a 1 ms entre salas. Esse requisito de baixa latência garante que, apesar da separação física, o cluster mantenha características de desempenho adequadas para automação de fábrica, monitoramento em tempo real e outros aplicativos industriais sensíveis ao tempo.

• O tráfego RDMA (Acesso remoto à memória direta) não passa para a camada de comutador de coluna.
• O tráfego RDMA é dedicado à camada TOR, ou Topo do Rack, e pode transitar para TORs vizinhos em diferentes zonas.
• VLANs de armazenamento (711, 712) são domínios de difusão de Camada 2 sem configuração de IP.
• A latência sala a sala deve ser menor ou igual a 1 ms para tráfego RDMA.

O ambiente inclui dois dispositivos de coluna que abrangem ambas as salas para dar suporte ao cluster com reconhecimento de rack. Esses dispositivos de coluna hospedam duas intenções de rede primárias: gerenciamento e computação. Os designs mostram uma única intenção de computação, mas várias intenções podem ser suportadas dependendo dos requisitos do cliente. VLANs de armazenamento (711, 712) são hospedados exclusivamente na camada TOR e operam como domínios de difusão de Camada 2 sem configuração de IP.

Importante

Os diagramas de rede usam convenções de nomenclatura simplificadas que diferem das IDs de VLAN referenciadas neste artigo:

• SMB1 em diagramas = VLAN 711 (intenção de armazenamento 1)
• SMB2 em diagramas = VLAN 712 (intenção de armazenamento 2)
• Gerenciamento em diagramas = VLAN 7 (intenção de gerenciamento)
• Computação em diagramas = VLAN 8 (intenção de computação)

Essa convenção de nomenclatura nos diagramas se concentra na finalidade funcional em vez de IDs de VLAN específicas para maior clareza.

Arquitetura de comutador TOR

Os comutadores TOR operam como comutadores de Camada 2 com os seguintes caminhos de conectividade:

• Uplinks de coluna: carregue o gerenciamento e o tráfego de computação.
• Links de armazenamento: suporta comunicação S2D de sala para sala.
• Links de sala a sala: conectividade primária para o tráfego RDMA entre zonas.

Requisitos principais:

• Os links de sala a sala devem dar suporte ao tráfego de intenção de armazenamento entre dispositivos TOR.
• As intenções de rede de computação e gerenciamento exigem extensão de Camada 2 para todos os dispositivos TOR por meio da camada de coluna.
• A latência de link entre salas RDMA deve ser menor ou igual a 1ms.
• Interfaces de no mínimo 10 GbE são necessárias para o tráfego de armazenamento, com 25 GbE recomendado para desempenho ideal.
• Suporte a quadros jumbo (MTU 9216) é necessário para implementações iWARP apenas quando os nós de host suportam quadros jumbo.

Os seguintes recursos de comutador são necessários:

• Suporte ao DCB (Data Center Bridging) para Ethernet sem perdas.
• Controle de Fluxo de Prioridade (PFC - Priority Flow Control) para classes de tráfego RDMA.
• ETS (Seleção de Transmissão Avançada) para alocação de largura de banda.
• LLDP com TLVs DCB para configuração automatizada de host.
• STP (Spanning Tree Protocol) para separação de VLANs de armazenamento e não armazenamento. O MSTP (Multiple Spanning Tree Protocol) foi utilizado nos testes deste ambiente.

Importante

Requisito de QoS rdma: Todas as interfaces que dão suporte ao tráfego RDMA (SMB) são necessárias para implementar políticas de QoS. Isso inclui interfaces de armazenamento voltadas para o host e links entre salas que transportam VLANs de armazenamento (711, 712). A configuração adequada de QoS é essencial para manter o desempenho RDMA de baixa latência e sem perdas em todo o cluster.

Considerações de design:

• Alocação de buffer: assegure uma profundidade de buffer adequada para o tratamento de quadros de pausa do PFC.
• Densidade de portas: planeje no mínimo quatro portas por nó (2x gerenciamento/computação, 2x armazenamento).
• Energia e resfriamento: Considere o maior consumo de energia em switches habilitados para DCB.
• Compatibilidade de firmware: consulte os requisitos de rede física do Azure Local para dispositivos de rede com suporte e níveis de firmware apropriados.
• Considerações sobre o protocolo RDMA: RoCEv2 não requer quadros jumbo; O iWARP requer quadros jumbo somente quando os nós de host dão suporte a eles.

Exemplo de fluxo de tráfego RDMA: Nó 1 RDMA NIC 1 → TOR local → link sala a sala → TOR remoto → nó 3 NIC 1 (latência total ≤ 1ms)

Opção A: links de armazenamento dedicados

Esse design apresenta quatro comutadores TOR (TOR-1 a TOR-4) com as seguintes características:

Configuração do nó:

• Dois cartões de rede físicos por nó (total de quatro interfaces).
• NIC 1: Switch Embedded Teaming (SET) para gerenciamento (VLAN 7) e tráfego de computação (VLAN 8).
• NIC 2: Interfaces de armazenamento dedicadas com marcação VLAN única (711, 712).

Configuração do switch:

• Interfaces de armazenamento: uma marca VLAN por interface.
• Interfaces de gerenciamento/computação: dão suporte a todas as tags de VLAN não associadas a armazenamento.
• MLAG (agregação de link de vários chassis) somente para gerenciamento e tráfego de computação.
• O tráfego de armazenamento ignora o MLAG para minimizar os saltos de sessão RDMA.

Conectividade de sala a sala:

• Dois conjuntos independentes de links agrupados dão suporte ao tráfego entre salas.
• VLAN 711: Link dedicado entre TOR1 e TOR3.
• VLAN 712: Link dedicado entre TOR2 e TOR4.

Observação

As intenções de armazenamento são distribuídas intencionalmente em dispositivos TOR específicos seguindo o princípio de design de rede desagregado. A interface de armazenamento de cada nó dá suporte a apenas uma intenção de armazenamento por interface. Essa configuração foi validada usando o MSTP (Multiple Spanning Tree Protocol) com grupos de árvores separados para VLANs de armazenamento e não de armazenamento.

Opção B: links de armazenamento agregados

A opção B implementa uma configuração desagregada semelhante à Opção A, mas com conectividade de armazenamento agregada:

Configuração de armazenamento:

• O tráfego de armazenamento RDMA usa interfaces SMB1 e SMB2.
• TOR1 e TOR2: dois port-channels (700, 701) fornecem conectividade entre as salas.
• O vPC (Virtual Port Channel) oferece serviços MLAG com mapeamento de Port-Channel para vPC.

Detalhes de conectividade:

• TOR3: O canal de porta único 700 conecta-se ao TOR1/TOR2 (ID do vPC 700).
• TOR4: O canal de porta único 701 conecta-se ao TOR1/TOR2 (ID do vPC 701).

Links MLAG na sala: Conectividade full mesh compatível com VLANs 7, 8, 711 e 712:

• TOR1 ↔ TOR2
• TOR3 ↔ TOR4

Padrões de tráfego: O tráfego entre salas segue dois cenários com base em algoritmos de hash de link:

• Conexão de sala a sala direta (caminho ideal) TOR1 ↔ TOR3 TOR2 ↔ TOR4
• Travessia entre salas com MLAG (potencial aumento de latência) TOR1 ↔ TOR4 ↔ TOR3 TOR2 ↔ TOR3 ↔ TOR4

Opção C: TOR único por sala

A opção C simplifica a arquitetura com um único dispositivo TOR por sala.

Principais características:

• TOR único por zona de disponibilidade.
• SMB1 e SMB2 são hospedados no mesmo dispositivo TOR.
• O link entre salas pode ser redundante (agregado), transportando ambas as VLANs de armazenamento.
• Nenhuma redundância de TOR dentro de zonas.

Configuração de uplink: A conectividade da coluna pode ser links únicos ou agrupados, dependendo do número de comutadores de coluna implantados.

Embora essa opção simplifica o gerenciamento e reduz a complexidade, ela também cria um único ponto de falha por zona durante a manutenção ou falha do dispositivo.

Opção D: Conectividade de nós entre salas

A opção D representa um design distribuído em que os nós se conectam a dispositivos TOR em ambas as salas.

Padrão de conectividade do nó (por nó):

• SET team NIC 0: Conecta-se ao TOR1 local (sala 1).
• SET team NIC 1: Conecta-se ao TOR2 remoto (sala 2).
• SMB1 NIC 0: Conecta-se ao TOR1 (sala 1).
• SMB2 NIC 1: Conecta-se ao TOR2 (sala 2).

Requisitos de infraestrutura:

• Links de fibra dedicados para cada conexão nó-a-TOR cobrindo múltiplas salas.
• Cabeamento entre salas para cada interface de nó.
• Os links TOR-to-TOR dão suporte ao gerenciamento e ao tráfego relacionado à intenção de computação.

Opções de alta disponibilidade:

• Configuração de vPC/HSRP para links entre TORs.
• Configuração de HSRP apenas para implantações simplificadas.

Requisitos e configurações de link de sala a sala

Para obter informações sobre as configurações de link de sala a sala, consulte Conectividade de sala a sala.

Configuração de host para switch

Opção A e B

As opções A e B têm configurações semelhantes, com dois dispositivos TOR para dar suporte a um ambiente de sala.

A NIC de gerenciamento/computação é configurada como uma equipe Switch Embedded Teaming (SET), que requer apenas a configuração de tronco de comutador padrão com as marcas de VLAN apropriadas para dar suporte ao ambiente.

Configuração da interface de computação/gerenciamento:

interface Ethernet1/1
  description Management-Compute-Host-Connection
  no cdp enable
  switchport
  switchport mode trunk
  switchport trunk native vlan 7
  switchport trunk allowed vlan 8
  spanning-tree port type edge trunk
  mtu 9216
  logging event port link-status
  no shutdown

Configuração da interface de armazenamento:

interface ethernet 1/15
  description Storage-Intent-SMB1-Host-Interface
  switchport
  switchport mode trunk
  switchport trunk native vlan 99
  switchport trunk allowed vlan 711
  spanning-tree port type edge trunk
  mtu 9216
  service-policy type qos input AZS_SERVICES
  priority-flow-control mode on send-tlv
  logging event port link-status
  no shutdown

Parâmetro/configuração	Description
switchport trunk native vlan 99	Atribui uma VLAN de blackhole para capturar qualquer tráfego de rede não etiquetado espúrio.
switchport trunk allowed vlan 711	Restringe o tronco a transportar apenas o tráfego VLAN 711 para essa interface de armazenamento.
service-policy type qos input AZS_SERVICES	Aplica a política de QoS para otimização de tráfego RDMA.
priority-flow-control mode on send-tlv	Habilita o PFC (Controle de Fluxo de Prioridade) com a transmissão TLV do LLDP.
spanning-tree port type edge trunk	Otimiza o STP para portas voltadas para host.
mtu 9216	Habilita quadros jumbo. Necessário apenas para iWARP quando nós de host dão suporte a quadros jumbo.

Opção C

A opção C utiliza um único dispositivo TOR que dá suporte a todas as intenções de rede locais do Azure (gerenciamento, computação, SMB1, SMB2).

Em uma configuração de cluster com reconhecimento de rack típica, as intenções de armazenamento são isoladas para diferentes dispositivos TOR em uma sala. Essa configuração simplificada consolida todas as intenções em um único dispositivo, mantendo a separação lógica por meio de diferentes interfaces e VLANs.

Veja um exemplo de uma configuração completa de único nó a seguir:

Interfaces de gerenciamento/computação (equipe SET):

interface ethernet 1/1
  description Management-Compute-Host-Connection-Primary
  no cdp enable
  switchport
  switchport mode trunk
  switchport trunk native vlan 7
  switchport trunk allowed vlan 8
  spanning-tree port type edge trunk
  mtu 9216
  logging event port link-status
  no shutdown
!
interface ethernet 1/2
  description Management-Compute-Host-Connection-Secondary
  no cdp enable
  switchport
  switchport mode trunk
  switchport trunk native vlan 7
  switchport trunk allowed vlan 8
  spanning-tree port type edge trunk
  mtu 9216
  logging event port link-status
  no shutdown

Interfaces de armazenamento (SMB1 e SMB2):

interface ethernet 1/15
  description Storage-Intent-SMB1-Host-Interface
  switchport
  switchport mode trunk
  switchport trunk native vlan 99
  switchport trunk allowed vlan 711
  spanning-tree port type edge trunk
  mtu 9216
  service-policy type qos input AZS_SERVICES
  priority-flow-control mode on send-tlv
  logging event port link-status
  no shutdown
!
interface ethernet 1/16
  description Storage-Intent-SMB2-Host-Interface
  switchport
  switchport mode trunk
  switchport trunk native vlan 99
  switchport trunk allowed vlan 712
  spanning-tree port type edge trunk
  mtu 9216
  service-policy type qos input AZS_SERVICES
  priority-flow-control mode on send-tlv
  logging event port link-status
  no shutdown

Opção D

A opção D remove o requisito de links sala a sala para suportar o tráfego de armazenamento RDMA. Em vez disso, os nós estabelecem conexão cruzada diretamente com dispositivos TOR em ambas as salas. Cada sala mantém um único TOR, mas esse TOR tem conexões diretas com todos os nós em ambas as salas. Essa configuração requer infraestrutura de fibra adicional, mas fornece alta disponibilidade por meio da conectividade distribuída.

Principais características:

• TOR1 (sala 1): gerenciamento de serviços, computação e tráfego SMB1.
• TOR2 (sala 2): gerenciamento de serviços, computação e tráfego SMB2.
• Conectividade entre salas: cada nó se conecta a ambos os TORs para redundância.

Veja o exemplo a seguir de uma configuração de TOR1:

interface Ethernet1/1
  description Management-Compute-Cross-Room-Connection
  no cdp enable
  switchport
  switchport mode trunk
  switchport trunk native vlan 7
  switchport trunk allowed vlan 8
  spanning-tree port type edge trunk
  mtu 9216
  logging event port link-status
  no shutdown
!
interface ethernet 1/15
  description Storage-Intent-SMB1-Cross-Room-Interface
  switchport
  switchport mode trunk
  switchport trunk native vlan 99
  switchport trunk allowed vlan 711
  spanning-tree port type edge trunk
  mtu 9216
  service-policy type qos input AZS_SERVICES
  priority-flow-control mode on send-tlv
  logging event port link-status
  no shutdown

Política de QoS

A configuração de QoS usa a estrutura DCB (Data Center Bridging) para estabelecer um ambiente sem perdas e de baixa latência para tráfego RDMA, abrangendo as tecnologias RoCEv2 e iWARP.

Importante

Implementação obrigatória de QoS: Aplique políticas de QoS a todas as interfaces que transportam tráfego RDMA (SMB), incluindo:

• Interfaces de armazenamento voltadas para host (VLAN 711, 712).
• Links de sala para sala que dão suporte ao tráfego de armazenamento.
• Canais de porta e links agregados que transportam VLANs de armazenamento.

Sem políticas de QoS adequadas, você pode experimentar perda de pacotes, degradação de desempenho e potencial instabilidade do cluster.

Configuração local padrão do Azure:

• Tráfego RDMA: Atribuído à classe 3 do Controle de Fluxo de Prioridade (PFC).
• Pulsação de cluster: atribuída à classe 7 do PFC (prioridade mais alta).
• Alocação de largura de banda: mínimo de 50% reservados para tráfego RDMA.
• Reserva de tráfego de cluster: 1% para interfaces de 25 GbE, 2% para interfaces de 10 GbE.

Principais tecnologias:

• Controle de Fluxo de Prioridade (PFC): fornece transmissão sem perdas para classes de tráfego críticas.
• ETS (Seleção de Transmissão Aprimorada): aloca reservas de largura de banda para classes de tráfego específicas.
• Detecção Antecipada Aleatória Ponderada (WRED): gerencia o congestionamento da fila descartando o tráfego de prioridade mais baixa.
• ECN (Notificação de Congestionamento Avançado): impede cenários de incast em ambientes RoCEv2.

Para ambientes que dão suporte a RoCEv2, o ECN é implementado a fim de evitar situações de incast. Quando o congestionamento é detectado ao longo do caminho de conexão entre nós, o campo DSCP é marcado e o dispositivo de destino instrui os remetentes a reduzir o fluxo de tráfego.

Para obter mais informações, consulte a política de QoS Local do Azure.

Rede definida pelo software

Os clusters com reconhecimento de rack local do Azure dão suporte a implementações de SDN (Software Defined Networking) para requisitos avançados de virtualização de rede e micro segmentação. A integração do SDN permite o gerenciamento centralizado de políticas de rede e o isolamento de segurança aprimorado entre cargas de trabalho entre zonas de disponibilidade.

Para obter mais informações, consulte o guia de configuração de rede definida pelo software.

Próximas etapas

• Conectividade de sala a sala