O que é Alta Disponibilidade (HA) do Socket

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.

Alta Disponibilidade de Socket e Diferentes Modelos de Socket

Sites HA de Socket podem usar dois Sockets do mesmo tipo de Socket, X1500, X1600, X1600 LTE ou X1700. No entanto, você não pode usar tipos de Socket diferentes, então um site com um Socket X1600 e um X1700 não é suportado.

Você não pode usar um Socket X1600 e um Socket X1600 LTE 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 (Standby) monitora continuamente o estado (liveliness) do Socket Master ouvindo as mensagens periódicas keepalive que o Socket primário envia. As mensagens keepalive são enviadas através da interface designada com o destino definido para LAN & VRRP ou VRRP (veja abaixo Conectividade LAN e Socket HA).

  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:

image.png

Item

Description

1

Função HA do Socket - Primário ou Secundário

2

Status HA do Socket - Master ou Standby

3

Status de HA Status - Pronto ou Não Pronto

4

Condições específicas para o status geral de HA

  • Conectado - Conectividade WAN do Socket

    • GreenCheck.png- Tanto o Socket primário quanto o secundário têm pelo menos um túnel operacional conectado ao Cato Cloud

    • Red_X.png- O Socket não tem túneis operacionais conectados ao Cato Cloud

  • Keepalive - Estado do canal de keepalive do HA entre os Sockets

    • GreenCheck.png- O Socket secundário recebe mensagens HA de keepalive do Socket primário

    • Red_X.png- O Socket secundário não está recebendo mensagens HA de keepalive do Socket primário

  • Versão compatível - Tanto o Socket primário quanto o secundário estão executando versões compatíveis do OS do Socket

    • GreenCheck.png- Both Sockets are running compatible (the same major) Socket version, for example 14.0.13986 and 14.0.12764

    • Red_X.png- Sockets have different major Socket versions, for example 14.0.13986 and 13.0.48732

    Nota: A falha do HA do Socket ocorre mesmo se os Sockets estiverem executando versões major diferentes. No entanto, o site pode enfrentar problemas de funcionalidade se a versão do Socket secundário não suportar recursos que são suportados para a versão do Socket primário.

    For example, if the primary Socket runs version 18.0 and the secondary Socket is running version 15.0, In the case of a failover, features that were released with versions 16 - 18 will not work while the secondary Socket is active.

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á inativo, ele então muda seu status para Master. O Cato Cloud transfere os fluxos de tráfego para os links WAN no Socket secundário.

Socket_HA_Regular.png
Socket_HA_Failure.png

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 evento de failover do Socket HA, o Socket secundário se torna o novo Master e o PoP transfere o tráfego dos túneis do Socket primário com falha 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.

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

PhysicalLogicalTopology.png

Para conectividade WAN, desempenho e funcionalidade HA otimizados, a Cato requer uma disposição 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.

WAN_Connectivity_Router_Switch.png

Nota

Nota: Usar uma topologia assimétrica pode criar problemas e não é oficialmente suportada pela Cato. Por exemplo, onde a porta WAN1 do Socket primário está conectada ao ISP1, e a porta WAN1 do Socket secundário está conectada ao ISP2.

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.

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

HA_LAN_switch.png

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 menor número é usada tanto para o tráfego keepalive HA quanto para o tráfego do usuário. As portas LAN restantes transportam apenas o tráfego do usuário.

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

LAN_VRRP.png

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)

Tanto o Socket primário quanto o secundário estão conectados aos switches LAN via duas ou mais portas LAN agrupadas em uma agregação de link (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:

SocketHA_LAG.png

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.

Direct_HA_Link.png

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:

Socket_HA_-_Direct_Port_for_HA_Traffic.png
Socket_HA_-_via_Switch_Port_for_HA.png

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 como estando em estado de falha por um dos seguintes motivos:

  • Falha geral do Socket ou perda de energia

  • Conectividade LAN (sem manutenção por mais de três segundos)

  • 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.

Socket_HA_LAN_Failure.png

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.

Nome da Página

Descrição

Caminho

Sites

Mostra todos os sites na conta. A coluna Status de HA mostra o status do Socket HA para cada site.

Red > Sites

Socket

Mostra os detalhes do Socket HA para um site. Veja acima Compreendendo a Alta Disponibilidade de Socket e o Failover.

Rede > Sites > <nome do site> > Configuração do Site > Socket

Network Analytics

Mostra os dados de rede para um site e o Status de HA.

Rede > Sites > <nome do site> > Monitoramento de Site > Network Analytics

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.

Failover.png

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

Você pode usar a página de Regras de Saúde de Conectividade (Rede > Regras de Saúde de Link) para criar uma Regra de Saúde de Conectividade para enviar notificações por email para os eventos de failover de Socket HA. As notificações por email são enviadas a todos os destinatários na Lista de Emails que você configura no Aplicativo de Gerenciamento Cato. A Lista de Emails pode incluir endereços de email que não estão definidos para usuários e administradores no Aplicativo de Gerenciamento Cato.

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

Socket_Failover_Alert.png

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.

Esse artigo foi útil?

Usuários que acharam isso útil: 15 de 17

0 comentário