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.
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 sobre AWS vSocket HA, consulte Configuring HA for AWS vSockets
-
Para mais sobre Azure vSocket HA, consulte Configuring High Availability for Azure vSockets
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.
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.
-
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).
-
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.
-
O Socket secundário envia uma mensagem GARP para redes LAN para acelerar a convergência de Camada 2.
-
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:
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.
|
|
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.
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):
-
O PoP detecta que o Socket secundário agora é o Master.
-
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):
-
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.
-
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:
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.
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.
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:
-
Único porta LAN
-
Múltiplas portas LAN
-
Agregação de link LAN (opção recomendada)
-
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.
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:
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.
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:
-
O Socket secundário para de receber as mensagens de keepalive HA do Socket primário por um período de três segundos.
-
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.
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:
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:
-
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.
-
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:
-
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.
-
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:
|
|
A seção descreve as condições que causam um failover do Socket primário para o Socket secundá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
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.
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.
Esta seção discute diferentes páginas no Cato Management Application que você pode usar para monitorar o status e eventos para 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 |
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.
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:
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.
0 comentário
Por favor, entre para comentar.