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
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
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”.
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.
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:
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
Da queda à ascensão
Passo a passo de como funciona esse esquema:
- Ocorre um problema (simulado) no servidor
- O sensor okerr verifica o status de cada servidor uma vez por minuto e reporta ao servidor principal do projeto no okerr
- O indicador do servidor correspondente muda de OK para ERR
- 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)
- Este endereço é reportado ao serviço DNS dinâmico. Após a conclusão desta etapa, você verá o status “sincronizado” à direita.
- Muito em breve (segundos) o registro chegará aos servidores DNS do seu domínio (para o site cat é ns1-ns5.he.net).
- 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.
- 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
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
Fonte: habr.com