Alta disponibilidade acessível

Venho há algumas semanas organizando uma forma de ter alta disponibilidade para o serviço isaCloud. É claro que o conceito de alta disponibilidade precisa ser de acordo com as demandas do “negócio” (entre aspas porque isaCloud é um serviço sem fins comerciais).

O que eu tenho pensado:

  • Ter um cold site, isto é, um segundo datacenter (ou site secundário) com dados replicados que possa assumir o serviço
  • Não preciso ter failover automático
  • O chaveamento dos sites pode tolerar uma mudança e propagação de DNS (até 1h, digamos)

Comecei configurando um simples lsync entre o datacenter A e o datacenter B. Estou há duas semanas mantendo essa replicação ativa de dados e configurações entre um servidor no Brasil e um na Holanda.

Eu testei a virada de DNS de um dos domínios que tenho no isaCloud e a seguir compartilho o que funcionou e o que não funcionou:

✅ Consistência do histórico de mensagens
✅ Baixa latência para replicação
✅ Configurações do servidor e certificados
✅ Boot do serviço
✅ Reconexão de conversas com usuários de servidores externos
🔴 Reconexão de conversas com usuários de outros domínios também do isaCloud

Como mencionei ali em cima, eu virei apenas 1 domínio dos 5 que tenho no isaCloud e, nesse caso, a comunicação entre o domínio “migrado” pro site secundário e os demais que ficaram no site primário não funcionou bem porque os domínios que ficaram achavam ainda que o domínio em questão ainda era servido pelo site primário.

Outra questão que não ficou clara para mim é sobre deixar previamente configuradas entradas de DNS SRV com menor prioridade para que a escolha pelo site secundário fosse automática. Mas isso tem uns poréns:

  • Pro meu teste não funcionou porque o site primário continuava acessível no target da entrada SRV já que os demais domínios seguiam funcionando lá
  • No caso de um failover automático pro site secundário através dessa entrada SRV com prioridade menor, o failback acabaria acontecendo automaticamente se o site primário voltasse a responder sozinho – porém os dados no site primário estariam desatualizados.

Bem, ainda tô desenhando a melhor forma de fazer isso tudo:

  • Failover automático com faiback manual
  • Failover manual alterando o hostname pra onde os SRV apontam

Num próximo post eu compartilho o que ficou decidido e como ficou implementado.

Com carinho,
Isadora.