Esta secção fornece uma visão geral aprofundada de como funciona o clustering do SD-WAN Edge.

Seguem-se conceitos importantes que descrevem a funcionalidade de clustering do SD-WAN Edge:

  • É possível utilizar o clustering do Edge nos hubs da seguinte forma:
    • Para permitir mais capacidade do túnel para um hub do que um Edge individual que sirva como um hub possa fornecer.
    • Para distribuir os Edges Spoke remotos entre vários hubs e reduzir o impacto de qualquer incidente que possa ocorrer.
  • A pontuação de cluster é um cálculo matemático da utilização global do sistema da seguinte forma:
    Os três fatores de utilização medidos são a utilização da CPU, a utilização da memória e a capacidade do túnel.
    • Cada medida de utilização é tratada em percentagem num máximo de 100%.
    • A capacidade do túnel baseia-se na capacidade nominal de um determinado modelo de hardware ou configuração de Edge virtual.
    • É calculada a média das três percentagens de utilização para chegar a uma pontuação de cluster (1-100).
    • Embora o débito não seja diretamente considerado, a utilização da CPU e memória reflete indiretamente o volume de débito e fluxo num determinado Hub.
    • Por exemplo, num Edge 2000:
      • Utilização da CPU = 20%
      • Utilização da memória = 30%
      • Túneis ligados = 600 (numa capacidade de 6000) = 10%
      • Pontuação do cluster: (20 + 30 + 10)/3 = 20
  • Uma pontuação de cluster superior a 70 é considerada “sobrecapacidade”.
  • Um “ID lógico” é um UUID de 128 bits que identifica um elemento dentro da rede VMware.
    • Por exemplo, cada Edge é representado por um ID lógico e cada cluster é representado por um ID lógico.
    • Enquanto o utilizador fornece os nomes do Edge e do cluster, os IDs lógicos são garantidos como exclusivos e são utilizados para a identificação interna de elementos.
  • Por predefinição, a carga é distribuída uniformemente entre os hubs. Por conseguinte, é necessário que todos os Edges que fazem parte de um cluster tenham o mesmo modelo e capacidade.
Cada membro do cluster terá o seu próprio endereço IP para as interfaces WAN e LAN. Todos os VMware SD-WAN Edges no cluster de hub são necessários para executar um protocolo de routing dinâmico, como o eBGP, com os dispositivos de camada 3 no lado LAN com número do sistema autónomo (ASN) único para cada membro do cluster. O routing dinâmico dos clusters no lado do LAN garante que o tráfego do DC para um determinado site Spoke é encaminhado através do membro correto do cluster Edge.
Importante: Os Edges Hub num cluster não se ligam nem comunicam entre si por meio de túneis ou protocolos de routing. Funcionam como Edges independentes para funções de plano de dados. Dependem do emparelhamento BGP do lado da LAN ao comutador principal para lidar com o tráfego de ramo a ramo quando os Edges do ramo estão ligados a Edges Hub diferentes no cluster.

Como é que os clusters Edge são rastreados pelo VMware SD-WAN Gateway?

Depois de um hub ter sido adicionado a um cluster do VMware SD-WAN, o hub vai remover e reconstruir os túneis para todos os gateways atribuídos e indicar a cada gateway que o hub foi atribuído a um cluster e fornecer um ID lógico de cluster.

Para o cluster, o SD-WAN Gateway rastreia:
  • O ID lógico
  • O nome
  • Se o reequilíbrio automático estiver ativado
  • Uma lista de objetos Hub para membros do cluster

Para cada objeto hub no cluster, o gateway rastreia:

  • O ID lógico
  • O nome
  • Um conjunto de estatísticas, atualizadas a cada 30 segundos através de uma mensagem periódica enviada do hub para cada gateway atribuído, incluindo:
    • Utilização da CPU atual do hub
    • Utilização da memória atual do hub
    • Contagem de túneis atual no hub
    • Contagem de caminhos BGP atual no hub
  • A pontuação de cluster atual calculada com base na fórmula acima fornecida.

Um hub é removido da lista de objetos hub quando o hateway não recebeu nenhum pacote do hub Edge durante mais de sete segundos.

Como é que os Edges são atribuídos a um hub específico num cluster?

Numa topologia tradicional de hub e Spoke, o SASE Orchestrator fornece ao Edge o ID lógico do hub ao qual deve estar ligado. O Edge pede aos gateways atribuídos informações de conectividade para esse ID lógico do hub, isto é, endereços IP e portas, que o Edge utilizará para ligar a esse Hub.

Do ponto de vista do Edge, este comportamento é idêntico quando se liga a um cluster. O Orchestrator informa o Edge de que o ID lógico do hub a que se deve ligar é o ID lógico do cluster em vez do ID lógico do hub individual. O Edge segue o mesmo procedimento de envio de um pedido de ligação do hub aos gateways e espera informações de conectividade em resposta.

Há duas divergências do comportamento básico do hub neste momento:

  • Divergência número um: o gateway deve escolher qual hub atribuir.
  • Divergência número dois: devido à divergência número um, o Edge pode obter diferentes atribuições dos seus diferentes gateways.

A divergência número um foi originalmente tratada utilizando a pontuação de cluster para atribuir o hub menos carregado num cluster a um Edge. Embora na prática isto seja lógico, no mundo real, acabou por ser uma solução menos do que ideal porque um evento típico de reatribuição pode envolver centenas ou mesmo milhares de Edges e a pontuação de cluster só é atualizada a cada 30 segundos. Por outras palavras, se o hub 1 tiver uma pontuação de cluster de 20 e o hub 2 tiver uma pontuação de cluster de 21, durante 30 segundos, todos os Edges escolherão o hub 1, altura em que poderá ficar sobrecarregado e acionar mais reatribuições.

Em vez disso, o gateway tenta pela primeira vez uma distribuição matemática justa ignorando a pontuação de cluster. Os IDs lógicos do Edge, que foram gerados por um gerador de número aleatório seguro no Orchestrator, terão (dado Edges suficientes) uma distribuição de valores uniforme. Isto significa que, utilizando o ID lógico, pode ser calculada uma distribuição de partes justa.

  • ID lógico do Edge módulo número de hubs no Cluster = Índice de hub atribuído
  • Por exemplo:
    • Quatro Edges que têm IDs lógicos que terminam em 1, 2, 3, 4
    • Cluster com 2 hubs
    • 1 % 2 = 1, 2 % 2 = 0, 3 % 2 = 1, 4 % 2 = 0 (Nota: “%” é utilizado para indicar o operador do módulo)
    • Os Edges 2 e 4 têm atribuído um índice 0 do hub
    • Os Edges 1 e 3 têm atribuído um índice 1 do hub

    Isto é mais consistente do que uma atribuição do tipo round-robin porque significa que os Edges tendem a ser atribuídos ao mesmo hub de cada vez, o que torna a atribuição e resolução de problemas mais preditiva.

Nota: Quando um hub recomeçar (por exemplo, devido a manutenção ou falha), este será desligado do gateway e removido do cluster. Isto significa que os Edges serão sempre distribuídos uniformemente após todo o reinício de todos os Edges (devido à lógica acima descrita), mas serão distribuídos de forma desigual após qualquer evento do hub que o faça perder conectividade.

O que acontece quando um hub excede a sua capacidade máxima de túnel permitida?

A lógica de atribuição do Edge tentará distribuir uniformemente os Edges entre todos os hubs disponíveis. No entanto, após um evento (como, um reinício) no hub, a distribuição do Edge deixará de ser uniforme.

Nota: Geralmente, o gateway tenta, na atribuição inicial, distribuir Edges uniformemente entre hubs, uma distribuição desigual não é considerada um estado inválido. Se as atribuições forem desiguais mas nenhum hub individual exceder 70% da capacidade do túnel, a atribuição será considerada válida.

Devido a tal evento no hub (ou ao adicionar Edges adicionais à rede), os clusters podem chegar a um ponto em que um hub individual exceda 70% da sua capacidade permitida para o túnel. Se isso acontecer e, pelo menos, outro hub estiver com menos de 70% de capacidade de túnel, a redistribuição justa das partes será executada automaticamente, independentemente de o reequilíbrio estar ativado no Orchestrator. A maioria dos Edges manterá a sua atribuição existente devido à atribuição matemática preditiva utilizando IDs lógicos e os Edges que foram atribuídos a outros Hubs devido a recuperações automáticas ou ao reequilíbrio de utilização anterior serão reequilibrados para garantir que o cluster seja devolvido para uma distribuição uniforme automaticamente.

O que acontece quando um hub excede a sua pontuação de cluster máxima permitida?

Ao contrário da percentagem de túneis (uma medição direta da capacidade), que pode ser acionada imediatamente, a pontuação de cluster só é atualizada a cada 30 segundos e o gateway não consegue calcular automaticamente qual será a pontuação de cluster ajustada após a reatribuição de Edge. Na configuração do cluster, é fornecido um parâmetro de reequilíbrio automático (Auto Rebalance) para indicar se o gateway deve tentar dinamicamente deslocar a carga do Edge para cada hub, conforme necessário.

Se o reequilíbrio automático estiver desativado e um hub exceder uma pontuação de cluster de 70 (mas não 70% de capacidade do túnel), não será tomada nenhuma medida.

Se o reequilíbrio automático estiver ativado e um ou mais hubs excederem uma pontuação de cluster de 70, o gateway reatribuirá um Edge por minuto ao hub com a pontuação de cluster mais baixa atual até que todos os hubs estejam abaixo dos 70 ou não haja mais reatribuições possíveis.

Nota: Por predefinição, o reequilíbrio automático está desativado.

O que acontece quando dois VMware SD-WAN Gateways apresentam atribuições de hub diferentes?

Como é a natureza de um plano de controlo distribuído, cada gateway faz uma determinação individual da atribuição do cluster. Na maioria dos casos, os gateways utilizarão a mesma fórmula matemática e chegarão assim à mesma atribuição para todos os Edges. No entanto, em casos como o reequilíbrio baseado na pontuação de cluster, isto não pode ser assegurado.

Se um Edge não estiver atualmente ligado a um Hub num Cluster, este aceitará a atribuição de qualquer gateway que responda. Isto garante que os Edges nunca deixem de ser atribuídos num cenário em que alguns gateways estão inativos e outros estão ativos.

Se um Edge estiver ligado a um hub num cluster e receber uma mensagem indicando que deve escolher um hub alternativo, esta mensagem será processada por ordem de “Preferência de gateway”. Por exemplo, se o supergateway estiver ligado, o Edge só aceitará reatribuições a partir do supergateway. As atribuições contraditórias solicitadas por outros gateways serão ignoradas. Da mesma forma, se o supergateway não estiver ligado, o Edge apenas aceitará reatribuições do super gateway alternativo. Para os gateways de parceiro (onde não existem super gateways), a preferência de gateway baseia-se na ordem dos gateways de parceiro configurados para esse Edge específico.
Nota: Ao utilizar gateways de parceiros, os mesmos gateways têm de ser atribuídos tanto aos hubs num cluster como aos Edges Spoke, caso contrário, poderá surgir um cenário em que um Edge Spoke não possa receber atribuições do hub porque está ligado a um gateway que também não está ligado aos Hubs num cluster.

O que acontece quando um VMware SD-WAN Gateway fica inativo?

Quando um SD-WAN Gateway fica inativo, os Edges poderão ser reatribuídos se o gateway preferencial for o que ficou inativo e o segundo gateway preferencial fornecer uma tarefa diferente. Por exemplo, o supergateway atribuiu o hub A a este Edge enquanto o supergateway alternativo atribuiu o hub B ao mesmo Edge.

O supergateway que fica inativo acionará o Edge para efetuar a ativação pós-falha para hub B, uma vez que o supergateway alternativo é agora o gateway mais preferido para informações de conectividade.

Quando o supergateway recuperar, o Edge voltará a solicitar uma atribuição do hub a partir deste gateway. De forma a evitar que o Edge volte a mudar para o hub A no cenário acima, o pedido de atribuição do hub inclui o hub atualmente atribuído (se houver um). Quando o gateway processa o pedido de atribuição, se o Edge estiver atualmente atribuído a um hub no cluster e se o hub tiver uma pontuação de cluster inferior a 70, o gateway atualizará a sua atribuição local para corresponder à atribuição existente sem passar pela sua lógica de atribuição. Isto garante que o supergateway, em recuperação, atribuirá o hub atualmente ligado e evitará uma recuperação automática gratuita para os Edges atribuídos.

O que acontece se um hub num cluster perder os seus caminhos dinâmicos?

Conforme referido acima, os hubs reportam aos SD-WAN Gateways o número de caminhos dinâmicos que programaram via BGP a cada 30 segundos. Se os caminhos forem perdidos para apenas um hub num cluster, quer por terem sido erradamente retraídos ou por o vizinho BGP falhar, o SD-WAN Gateway executará uma recuperação automática dos Edges Spoke para outro hub no cluster que tenha uma tabela de routing intacta.

À medida que as atualizações são enviadas a cada 30 segundos, a contagem de caminhos baseia-se no momento em que a atualização é enviada para o SD-WAN Gateway. A lógica de reequilíbrio do SD-WAN Gateway ocorre a cada 60 segundos, o que significa que os utilizadores podem esperar que a recuperação automática demore entre 30 e 60 segundos no caso improvável de perda total de um vizinho BGP do lado LAN. Para garantir que todos os Hubs tenham a oportunidade de atualizar os gateways novamente após tal evento, o reequilíbrio é limitado a um máximo de uma vez a cada 120 segundos. Isto significa que os utilizadores podem esperar que a recuperação automática demore 120 segundos para uma segunda falha consecutiva.

Como configurar o routing nos hubs do cluster?

Como o gateway pode instruir os spokes a ligarem-se a qualquer hub do cluster do membro, a configuração de routing deve ser espelhada em todos os hubs. Por exemplo, se os spokes tiverem de aceder a um prefixo BGP 192.168.2.1 atrás dos hubs, todos os hubs no cluster deverão anunciar 192.168.2.1 exatamente com os mesmos atributos de caminho.

As etiquetas da comunidade de transmissão BGP devem ser utilizadas na implantação do cluster. Configure os nós do cluster para definir a etiqueta de comunidade de transmissão ao redistribuir os caminhos para os pares BGP.

O que acontece se um hub num cluster falhar?

O SD-WAN Gateway aguardará que os túneis sejam declarados mortos (7 segundos) antes de efetuar ativação pós-falha nos Edges Spoke. Isto significa que os utilizadores podem esperar que a recuperação automática demore entre 7 e 10 segundos (dependendo do RTT) quando um SD-WAN Hub ou todas as suas ligações WAN associadas falharem.