Failover simples para site (monitoramento + DNS dinâmico)

Neste artigo quero mostrar como é fácil e gratuito criar um esquema de failover para um site (ou qualquer outro serviço de Internet) usando uma combinação de monitoramento ok e serviço DNS dinâmico. Ou seja, em caso de algum problema com o site principal (desde um problema com um “Erro de PHP” na página, até falta de espaço ou simplesmente um número suspeitamente pequeno de pedidos no caso de uma loja online), novos visitantes irão ser direcionado para o segundo (terceiro e assim por diante) mais adiante) um servidor conhecido em funcionamento, ou na página “Desculpe”, onde explicarão educadamente que “há um problema, já estamos cientes e já estamos resolvendo, nós irá consertar isso em breve” (e neste caso você já estará por dentro e poderá reparar).

Viver com failover ou sem?

Até que algum problema aconteça, não há muita diferença. Mas quando isso acontece, sem failover, muitas vezes acontece o seguinte: você tenta descobrir rapidamente qual é o problema, não funciona (os backups não são implantados, o software, por algum motivo, não funciona como deveria na documentação , etc.), mas não há tempo, nem servidor - os sites estão parados, os clientes estão ligando, todos estão nervosos, você está tentando consertar de alguma forma grosseira e suja “com fita”, então de alguma forma parece inicializar com muletas e vidas. Você acha que no seu tempo livre precisará descobrir com mais detalhes e refazer tudo lindamente, mas não há nada mais permanente do que temporário.

Agora, como isso acontece em uma bela versão com arquivador:

  • Um erro acontece
  • O erro é detectado automaticamente
  • Alerta é enviado
  • A mudança para um dos servidores de backup é transferida
  • Com calma e sem pânico, o problema é resolvido, corrigido e o servidor volta a funcionar.

Este esquema, claro, também pode ter seus próprios problemas, mas ainda assim, o esquema é linear, cada etapa é simples e o principal é que pode ser depurado separadamente, então a chance de falha deste esquema é muito menor, e todas as ações podem ser automatizadas e executadas rapidamente (ao contrário da tarefa de encontrar e consertar porcarias épicas desconhecidas). Seu avião pousou em um país distante, você liga o telefone e vê uma notificação em um telegrama de que o servidor travou, mas está tudo bem, o servidor de backup foi ativado, você pode continuar sua viagem, não precisa voar de volta ou consertá-lo via SSH do café mais próximo com WiFi. Você descobrirá quando for mais conveniente.

O futuro já está aqui!

Anteriormente, o principal problema que tornava o failover muitas vezes uma solução inaceitável era o valor do custo que ele custava. Ou foi necessário comprar hardware caro (e convidar especialistas ainda mais caros). Ou fazenda coletiva algo complicado de acordo com os guias (até me deparei com uma opção onde dois servidores são conectados adicionalmente com um cabo de modem nulo e enviam um batimento cardíaco através dele, para que no momento certo o servidor de backup o reconheça e assuma o controle ao controle). Agora existem maneiras mais fáceis e gratuitas. Se você tem um site com gatos, não há desculpa para não implementar o failover nele ainda!

Bem, além disso, para um esquema de failover você precisa de outro servidor (e talvez mais de um) e antes isso era uma grande despesa, agora você pode obter um VDS por alguns centavos.

O site mais confiável com gatos

Para ilustrar de forma prática a solução com okerr + dns dinâmico, lançamos nosso site com gatos cat.okerr.com. Nós odiamos gatos, então não haverá muitos deles lá. Existem três sites no total, cada um parece aproximadamente o mesmo (todos no mesmo modelo), mas com gatinhos diferentes para facilitar a distinção, e cada um escreve informações técnicas para ver como funciona o failover. A página é atualizada uma vez a cada 1 minuto, mas você sempre pode clicar em recarregar no navegador.

Nas informações técnicas existe uma linha “status=OK”. Às vezes, os servidores fingem problemas e escrevem status=ERR. O servidor principal “parece travar” a cada 20 minutos de cada hora (0:20, 1:20, 2:20,…). Servidor de backup em 40 minutos. O último servidor (servidor “desculpe”) está sempre em execução. Aos 0 minutos de cada hora, os servidores primário e de backup são “restaurados”.

Failover simples para site (monitoramento + DNS dinâmico)

Se você abrir o site e deixá-lo na aba, verá que ele nunca trava (embora cada servidor individual simule periodicamente um problema) e, em caso de problema com o servidor, ele simplesmente “funciona” entre servidores ativos. A imagem, nome e endereço do servidor e sua função serão alterados. Às vezes você pode capturar o momento em que status = ERR (o problema já existe, mas todo o esquema de failover ainda não funcionou), mas a próxima atualização mostrará uma página do site em funcionamento.

Failover em okerr + DNS dinâmico

Vamos ver como funciona nos bastidores. A tarefa do arquivador é garantir que o endereço cat.okerr.com sempre aponte para o endereço IP do servidor em funcionamento.
Atrás de cada um dos servidores que hospedam nosso site cat no okerr existe um indicador que verifica seu status uma vez por minuto.

Failover simples para site (monitoramento + DNS dinâmico)

Nesta captura de tela vemos como o site cat.okerr.com é verificado no servidor alpha.okerr.com. A página deve conter status=OK e, como vemos acima, o status do nosso indicador está OK agora. Quando o servidor “quebrar”, haverá um ERR. (Este é apenas um exemplo de indicador, okerr está monitorando, então você pode anexar qualquer tipo de indicador, por exemplo, verificar o espaço livre no disco, a quantidade de novos pedidos no banco de dados, e até indicadores lógicos, por exemplo , à noite haverá alguns critérios de erro e durante o dia outros).

Nas configurações do projeto criamos um esquema de failover com estes indicadores:

Failover simples para site (monitoramento + DNS dinâmico)

O esquema possui três indicadores (três servidores), com prioridades diferentes. O servidor principal do site é charlie, se não funcionar (não terá “status = OK” ou simplesmente não está disponível), então bravo e no último caso - alfa. O lado direito da página mostra o status do registro DNS em diferentes servidores.

Para quem notou que o nome cat.he.okerr.com é usado: Usamos um esquema um pouco mais complexo. Em vez de apenas alterar o registro DNS de cat.okerr.com, alteramos cat.he.okerr.com (no provedor DNS dinâmico Furacão Elétrico), e cat.okerr.com é um CNAME (alias), que não muda, sempre aponta para cat.he.okerr.com. Gostamos mais do Hurricane como um DNS dinâmico e tem chaves para gerenciar uma única entrada (em vez de uma zona inteira), achamos que é mais seguro. Você também não precisa especificar senhas de chave no okerr para gerenciar todo o domínio, mas apenas para um subdomínio ou registro.

Da queda à ascensão

Passo a passo de como funciona esse esquema:

  1. Ocorre um problema (simulado) no servidor
  2. O sensor okerr verifica o status de cada servidor uma vez por minuto e reporta ao servidor principal do projeto no okerr
  3. O indicador do servidor correspondente muda de OK para ERR
  4. Quando o status do indicador muda, o failover é recalculado e é calculado qual endereço precisa ser definido (se necessário. Por exemplo, se o servidor principal estiver funcionando e ao mesmo tempo o servidor de backup morreu, nenhuma alteração será feito)
  5. Este endereço é reportado ao serviço DNS dinâmico. Após a conclusão desta etapa, você verá o status “sincronizado” à direita.
  6. Muito em breve (segundos) o registro chegará aos servidores DNS do seu domínio (para o site cat é ns1-ns5.he.net).
  7. A partir deste momento, alguns usuários já estarão no novo servidor ativo. Mas nem todos os servidores DNS do mundo atualizaram os registros ainda, e o registro antigo ainda pode estar armazenado em cache em algum lugar. Você pode ver como os dados nos servidores DNS públicos “dançam”, mostrando um valor novo ou antigo. Se você atualizar a página de configuração de failover, a própria operadora solicitará novos dados dos servidores DNS.
  8. Depois que os dados se estabilizam, o antigo registro em cache fica podre em todos os lugares - todos os 100% das solicitações vão para o novo servidor.

Para acelerar o estágio 7 (geralmente o mais longo), o TTL do registro DNS dinâmico deve ser definido o mais baixo possível. Normalmente os serviços permitem intervalos de 90 a 120 segundos. Este é um compromisso completamente razoável.

adicionalmente

Tudo isso pode ser configurado à noite (caso você já tenha um servidor de backup). Os serviços okerr e DNS dinâmico são gratuitos. Para obter mais verificações no okerr e um período de verificação mais curto, você precisa concluir o treinamento (na página do seu perfil). Após a conclusão, o nível aumenta imediatamente (20 indicadores por hora + 1 rápido, 10 minutos). E se forem poucos, escreva para [email protegido], muito provavelmente será possível aumentar (até agora sempre houve uma oportunidade, nunca recusei, pelo contrário, eu mesmo a ofereci). Só que inicialmente não quero prometer tudo a todos, não tenho certeza se tenho capacidade suficiente para cumprir minha palavra. Mas até agora existem poucos usuários, então não há problemas em aumentar os limites.

O que o okerr pode fazer em geral - veja o site apresentação. Em geral, isso é monitoramento (zabbix da nuvem), e o arquivador é uma função adicional interessante. Você também pode acessar a demonstração no site sem registro.

Quando o status do indicador muda, uma notificação é enviada por e-mail ou Telegram. (Olhamos o que estava acontecendo e percebemos que o telegrama parece ser o mensageiro mais confiável. Obrigado ao RKN pelo teste de estresse!) Com o okerr configurado corretamente, qualquer notificação é um sinal “largue tudo, precisamos consertar!” ou “luzes apagadas!” Não deve haver alertas extras do okerra (se houver, eles precisam ser configurados de forma diferente). Por exemplo, para nosso site cat, o servidor alfa é o último e nunca simula um erro. Se ele se deitar, precisamos saber. Mas outros servidores fingem erros constantemente, portanto, para não receber alertas várias vezes por hora, esses indicadores ficam com status “silencioso”.

Também faz sentido criar um servidor de desculpas (em qualquer hospedagem mais barata), que terá sua página de desculpas (caso todos os servidores principal e de backup estejam inativos) ou o redirecionará para a página de status no okerr (por exemplo, o nosso cp.okerr.com/status/okerr) ou statuspage.io.

Fonte: habr.com

Adicionar um comentário