O que é Socket HA

Este artigo discute as configurações de Alta Disponibilidade (HA) e condições de failover para sites utilizando um par de Sockets físicos da Cato.

Visão Geral da Alta Disponibilidade de Socket para um Site

Para melhorar a resiliência do site, a Cato recomenda fortemente implantar cada site com um par de Sockets que operam em modo de Alta Disponibilidade (HA). Este modo de operação garante a continuidade do serviço para o site em caso de falha de um único Socket. Durante um failover, o Cato Cloud mantém o estado dos fluxos e há um impacto mínimo na experiência do usuário final.

Sites HA de Socket Suportados

A Cato suporta HA de Socket para os seguintes ambientes:

• Site de Socket físico

• Site vSocket AWS

• Site vSocket Azure

Este artigo explica como o HA funciona para um site de Socket físico. Para mais informações sobre a configuração do Socket HA em poucos cliques, veja Using Sockets in an HA Deployment.

• Para mais detalhes sobre AWS vSocket HA, consulte Configuring HA for AWS vSockets

• Para mais detalhes sobre Azure vSocket HA, consulte Configuring High Availability for Azure vSockets

Alta Disponibilidade de Socket e Diferentes Modelos de Socket

Os sites HA podem usar dois Sockets com o mesmo Tipo de Socket X1500, X1600, X1600 LTE, X1600 WiFi ou X1700. No entanto, você não pode usar diferentes Tipos de Socket, então um site com um Socket X1600 e um Socket X1700 não é suportado.

• Você pode usar no mesmo site HA:

  • Qualquer dois modelos de Socket X1500 A/B/C

  • Modelos de Socket X1700A e X1700B

  • Apenas modelos de Socket X1700C

• Você não pode usar um Socket X1600 LTE e um Socket X1600 WiFi no mesmo site HA

Compreendendo a Alta Disponibilidade de Socket e o Failover

Em uma implantação de HA do Socket, dois Sockets da Cato são atribuídos a um site. O primeiro Socket atribuído ao site é identificado como o Socket primário, o segundo é o Socket secundário. Os Sockets operam em modo HÁ Ativo/Standby. Durante a operação normal de um site, o Socket primário tem o status de HA Master, enquanto o Socket secundário tem o status de HA Standby. Apenas o Socket com o status de HA Master lida com o tráfego.

1. O Socket secundário (em espera) monitora continuamente o estado (atividade) do Socket mestre, escutando as mensagens keepalive periódicas que o Socket primário envia. As mensagens keepalive são enviadas pela interface designada com o destino configurado para LAN & VRRP ou VRRP (consulte Conectividade LAN e Socket HA abaixo).

2. Assim que o Socket secundário (Standby) detecta que o Socket primário está offline, ele muda seu estado de HA para Master e começa a lidar com o tráfego. Isso acontece após três segundos sem mensagens keepalive de HA.  

3. O Socket secundário envia uma mensagem GARP para redes LAN para acelerar a convergência de Camada 2.

4. Quando o Socket primário se recupera e é restaurado à funcionalidade regular, ele se torna preventivamente o Master e o Socket secundário retorna ao status de espera.

A imagem a seguir mostra a página de configuração HA para Sockets X1500 no Cato Management Application em Network > Sites > {site name} > Site Configuration > Socket:

Exemplo de Failover de Socket HA

Os diagramas a seguir mostram um exemplo de um problema no Socket primário que causa uma falha para o Socket secundário. Quando o Socket secundário descobre que o Socket primário está inoperante, ele então muda seu status para Master. A Cato Cloud transfere os fluxos de tráfego para os links WAN no Socket secundário.

Socket HA e Condição de Split-Brain

Uma condição de split-brain ocorre quando ambos os Sockets têm a função Master ao mesmo tempo. Isso pode acontecer devido a um problema de conectividade LAN entre os Sockets que cria uma situação em que as mensagens de keepalive do HA não chegam ao Socket secundário.

Você pode identificar uma condição de split-brain verificando a página Socket (mostrada acima) no Cato Management Application.

• Os Sockets primário e secundário serão mostrados como status Master (item 2)

• A condição de Keepalive (no item 4) será mostrada como Falhou e isso faz com que o Status HA (item 3) seja mostrado como NÃO PRONTO

Após a resolução do problema de conectividade da LAN, o Socket secundário identifica que o Socket primário é o Master e o Socket secundário retorna ao status Stand-by.

Tráfego do Site Durante a Condição de Split-Brain

O processo a seguir garante que, durante uma condição de split-brain, apenas o Socket secundário lide com o tráfego do site (mesmo que haja uma condição de split-brain).

• Para tráfego de downstream (do PoP para o site):

  1. O PoP detecta que o Socket secundário agora é o Master.

  2. O PoP define a métrica preferencial para os túneis de Socket secundário.

     O tráfego de downstream agora é roteado apenas para o Socket secundário.

• Para tráfego de upstream (do site para o PoP):

  1. Quando o Socket secundário muda o estado HA de Standby para Master, ele envia uma mensagem GARP para a LAN para atualizar as tabelas ARP e MAC indicando que agora é o Master.

     O tráfego de upstream da LAN agora é roteado apenas para o Socket secundário.

Conectividade HA Socket com a Nuvem Cato

Ambos Sockets, primário e secundário, estabelecem túneis DTLS para o mesmo PoP do Cato Cloud em cada uma das portas WAN. Na direção de upstream, apenas o Master Socket envia o tráfego para o PoP. Na direção de downstream, o PoP usa apenas os túneis do Master Socket para enviar o tráfego para o site. Em caso de um Evento de Failover do Socket HA, o Socket Secundário torna-se o Novo Mestre, e o PoP desvia o Tráfego dos Túneis do Socket Principal Falhado para os Túneis do Socket Secundário. O PoP mantém o estado do fluxo e o estado do NAT para garantir que todas as aplicações de usuário continuem operando durante e após o failover.

O Padrão de implantação usa roteadores entre o Socket e o ISP. No entanto, é possível personalizar a implantação do site para conectar o Socket ao PoP sem um roteador - entre em contato com seu representante oficial Cato para mais informações.

Abaixo estão exemplos de topologias físicas e lógicas para o Socket HA:

Para conectividade WAN, Desempenho e funcionalidade HA ideais, a Cato recomenda um layout de cabeamento simétrico (espelhado) para Ambos os Sockets. Por exemplo, se a porta WAN1 do Socket primário estiver conectada ao ISP1 e a porta WAN2 estiver conectada ao ISP2, o Socket secundário deve ter as mesmas portas conectadas aos mesmos ISPs que o Socket primário.

Essas topologias simétricas podem incluir conexões diretas aos roteadores ISP ou uso de uma pilha de switches.

Nota:

Para configurações padrão de HA, Cato recomenda que você use um layout simétrico para ambos os Sockets Primário e Secundário. Ao usar LTE, existem cenários onde você pode querer usar cartões SIM de diferentes operadoras para garantir melhor cobertura ou utilizar apenas um cartão SIM no Socket secundário.

Conectividade LAN e Socket HA

A Cato requer que ambos os Sockets, primário e secundário, tenham uma disposição de cabeamento simétrico (espelhado) para a conectividade LAN. Por exemplo, a porta LAN 1 para ambos Sockets, primário e secundário, está conectada ao switch LAN (ou portas LAN 1 e 2 para configurações com múltiplas portas LAN).

Esta seção discute as seguintes opções de conectividade LAN para o Socket HA:

1. Único porta LAN

2. Múltiplas portas LAN

3. Agregação de link LAN (opção recomendada)

4. Porta dedicada para mensagens de keepalive HA

Algumas dessas opções requerem configurações adicionais do site no Cato Management Application. Por exemplo, a porta LAN é configurada para LAN & VRRP ou VRRP.

Socket HA com um Único Porta LAN

Há configurações que usam uma única porta LAN para conectar o Socket primário e o secundário ao switch LAN. Com essa configuração, o mesmo número de porta deve ser usado em ambos os Sockets. O tráfego do usuário e as mensagens de keepalive HA são executados em um único link. Esta topologia não fornece redundância de link LAN.

A transferência HA do Socket (onde o Socket secundário se torna o Master) só ocorre quando ambas as condições são atendidas:

1. O Socket secundário para de receber as mensagens de keepalive HA do Socket primário por um período de três segundos.

2. A porta LAN no Socket secundário (que é usada para as mensagens de keepalive HA) está no estado CONECTADO.

Se a porta LAN do Socket Secundário estiver DESCONECTADA, ela não se tornará a Master para evitar uma possível condição de divisão do cérebro.

O diagrama a seguir mostra uma topologia Socket HA de exemplo com uma única porta LAN em cada Socket conectada a um switch:

Socket HA com Múltiplas Portas LAN

Esta seção discute quando ambos os Sockets primário e secundário estão conectados aos switches LAN via duas ou mais portas LAN independentes. Com essa configuração, as mesmas portas devem ser usadas em ambos os Sockets para a conectividade LAN.

Por padrão, a porta LAN com o número mais baixo é usada tanto para o tráfego Keepalive de Alta Disponibilidade quanto para o tráfego de usuários. As portas LAN restantes carregam apenas o tráfego de usuários.

Você pode escolher qualquer porta LAN para o tráfego keepalive de HA alterando o Destino da porta de LAN para LAN & VRRP. A captura de tela a seguir mostra a porta 3 para tráfego de usuário LAN e a porta 4 para o tráfego de keepalive HA e tráfego de usuário.

Para mais informações sobre a alteração da porta LAN para tráfego de keepalive HA, consulte Using Sockets in an HA Deployment. Esta topologia não fornece redundância de link LAN.

A transferência HA do Socket (onde o Socket secundário se torna o Master) só ocorre quando ambas as condições são atendidas:

1. O Socket secundário para de receber as mensagens de keepalive HA do Socket primário por um período de três segundos.

2. A porta LAN & VRRP no Socket secundário está no estado CONECTADO.

Se a porta LAN do Socket Secundário estiver DESCONECTADA, ela não se tornará a Master para evitar uma possível condição de divisão do cérebro.

Socket HA com Agregação de Link LAN (Configuração Recomendada)

Ambos os Sockets primário e secundário estão conectados aos switches LAN através de duas ou mais portas LAN agrupadas em uma agregação de links (LAG). Com essa configuração, as mesmas portas devem ser usadas em ambos os Sockets para a conectividade LAN. Esta topologia fornece redundância para links LAN tanto para o tráfego de usuário quanto para as mensagens de keepalive HA. Se uma das portas membro do LAG falhar, as outras portas membro continuarão a transportar o tráfego do usuário e o tráfego de manutenção de HA.

Esta topologia oferece resiliência de link e resiliência de Socket e é considerada uma melhor prática.

Para saber mais sobre LAN LAG, veja Configuring Link Aggregation for a Socket.

O diagrama a seguir é um exemplo de topologia de conectividade LAN de HA do Socket usando um LAN LAG com uma pilha de switches:

Porta Dedicada para o Tráfego de Keepalive HA

Nesta configuração, você isola o tráfego de manutenção de HA do tráfego LAN. Você pode alocar uma única porta (portas LAN, WAN ou USB) apenas para o tráfego de manutenção de HA enquanto utiliza uma ou mais das portas LAN restantes para o tráfego LAN.

Para definir a porta LAN dedicada para o tráfego de manutenção de HA, defina o Destino da porta para VRRP. Em seguida, defina a opção HA link entre sockets para Directo ou Via Switch.

Estas são as configurações das portas dedicadas:

1. Directo (cabo direto entre os Sockets) – Com esta configuração, se o Socket secundário parar de receber as mensagens de manutenção de HA, ele se torna o Master independentemente do estado da porta VRRP.

2. Via Switch – Com esta configuração, a porta VRRP em ambos os Sockets está conectada a um switch. O comportamento de failover depende do estado da porta VRRP do Socket secundário:

   1. Quando o estado da porta do Socket secundário é Conectado, mas não recebe mensagens de manutenção – o Socket secundário se torna o Master.

      O Socket secundário assume que o estado é causado por falha do Socket primário.

   2. Quando o estado da porta do Socket secundário está Desconectado, o Socket Secundário não se torna o Master (assumindo que é um problema local entre si e o switch.

      O Socket secundário assume que o Socket primário está operando corretamente e não se torna o Master para evitar uma possível condição de cérebro dividido.

Estes são diagramas das configurações de porta dedicada direta e via switch:

Condições de Failover para Alta Disponibilidade de Socket

A seção descreve as condições que causam um failover do Socket primário para o Socket secundário.

Failover devido à Falha do Socket Primário

Este cenário de failover é causado por uma falha no Socket primário. O Socket é considerado estar em um estado desativado baseado em um dos seguintes motivos:

• Falha geral do Socket ou perda de energia

• Conectividade VRRP (sem keepalive por mais de três segundos)
  A perda de conectividade do lado LAN não aciona um failover a menos que anúncios VRRP sejam trocados através do link LAN.

• Sem conectividade com a Internet por mais de dez segundos

Failover devido à Falha do Keepalive

Há também um cenário de failover que é causado quando o Socket secundário não recebe mensagens de manutenção do Socket primário por um período de três segundos.

Quando o Socket secundário descobre que o Socket primário está inoperante, ele então muda seu status para Master. A Cato Cloud transfere os fluxos de tráfego para os links WAN no Socket secundário. O diagrama a seguir mostra esse cenário.

Questões de Conectividade da Internet Causam Failover de Socket?

Os Sockets usam um mecanismo de sondagem para determinar o status de conectividade à Internet. Se o Socket primário determinar que a conectividade à Internet está fora em todos os links de Internet (links Cato) por mais de 10 segundos, então ele para de transmitir as mensagens keepalive HA. Isso causa um failover para o Socket secundário.

Nota:

Nota: É possível que o Socket primário tenha conectividade à Internet, no entanto, todos os túneis DTLS estejam no estado DESCONECTADO. Como os Sockets têm mecanismos de recuperação para Internet e WAN, essa situação não aciona um failover para o Socket secundário. Esses mecanismos de recuperação permitem que o Socket reconecte-se a um PoP diferente na Cato Cloud.

Monitoramento da Alta Disponibilidade de Socket

Esta seção discute diferentes páginas no Cato Management Application que você pode usar para monitorar o status e eventos para Socket HA.

Mostrando o Status do Socket HA

Existem diferentes páginas no Cato Management Application que mostram o status do Socket HA para um site.

Eventos de Failover de Socket HA

Sempre que ocorrer um failover do Socket, quando o Socket secundário estiver ativo por mais de 35 segundos, um evento de Failover do Socket é gerado. Por exemplo, se o Socket primário atualizar para uma nova versão do Socket, e o processo de atualização durar 20 segundos, então um evento de Failover do Socket NÃO é gerado porque o Socket secundário ficou ativo por apenas 20 segundos.

Você pode ver o evento no Cato Management Application na página Home > Eventos. Aqui está um exemplo de evento mostrando um failover do Socket primário para o Socket secundário.

Definindo Notificações para Failover de Alta Disponibilidade do Socket

Você pode usar a página Regra de Saúde de Link (Networking > Políticas de Configuração de Rede) para criar uma Regra de Saúde de Conectividade para enviar notificações para eventos de failover de HA de Socket.

Notificações são enviadas para todos os destinatários definidos no Grupo de Inscrição que você configura no CMA. Um Grupo de Assinatura pode incluir diferentes alvos de notificação, como:  

• Listas de Email com endereços de email (incluindo endereços não associados a usuários ou administradores Cato)

• Integrações Webhook como Slack ou Jira

• Sistemas de notificação de terceiros

Isso permite gerenciar todos os destinos de notificação de um único local e aplicá-los consistentemente em várias Regras.

Este é um exemplo de Regra de Saúde de Conectividade para failover de Socket:

Para mais informações sobre a configuração de uma Regra de Saúde de Conectividade, veja Trabalhando com Regras de Saúde de Links.