Gostaríamos de compartilhar um episódio que ocorreu este fim de semana com um cliente. Ele  sofreu uma pane no servidor do seu site e depois nos contou a estória.

A Amazon costuma enviar emails quando vai realizar uma manutenção em uma instância. Este email chega com um título como:

“Amazon EC2 Instance scheduled for retirement [AWS Account: xxxxxxxx]”

Geralmente é um pedido para desligar e ligar o servidor (não é reboot) dado que o ‘host’ em que ele se encontra vai ser aposentado. Este reinício faz com ele seja iniciado em outro ‘host’ físico e novo.

“Recebemos este email para realizar este procedimento em nosso site e para nossa surpresa, mesmo após diversos comandos de ‘desligar’ e ‘desligar forçado’, o servidor não parou. Esperamos 10 minutos e o servidor continuou com o status ‘desligando’.”

O que fazer numa situação em que o servidor não está mais acessível?

• se tiver o suporte técnico contratado pode abrir um ticket pedindo para analisar por que o servidor não foi desligado. Se for o suporte ‘Developer’, o melhor tempo de resposta são 12 horas (se bem que todas as vezes que precisamos de suporte, este tempo foi bem menor);
• se não tiver o suporte, o jeito é postar nos foruns. Em inglês ou português.
• mas sendo o site crítico e não podíamos perder tempo, resolvemos restaurar o backup.

Temos nossos backups realizados pelo agendador do Cloud8. Como já visto em outro post, o Cloud8 organiza os backups por data e guarda as configurações.

Ao se restaurar o backup, bastou selecionar o IP Elástico original e pedir a criação do novo servidor. O Cloud8 criou o servidor com as mesmas configurações anteriores e depois associou o IP. O servidor voltou ao ar em poucos minutos.

Depois de mais de 45 minutos, o antigo servidor finalmente parou e poderia então ter sido reiniciado.

Lições aprendidas

• tenha backup sempre. Não importa se é uma cópia de servidor como a Amazon faz ou então um script ou agente interno que copie os dados para outro local;
• guarde as configurações dos servidores. Em uma situação de crise e urgência, a última coisa que quer fazer é ficar procurando quais são as configurações do servidor (IP, Grupo de Segurança, Chave de Acesso, VPC). A urgência é colocá-lo de volta no ar e da maneira CERTA;
• tenha uma cópia independente e externa ao servidor. Isto é, não dependa de um disco extra conectado ao servidor. Se ocorrer um problema e não conseguir acessar o disco ou então da mesma forma que o servidor não parou, o disco poderia ficar em um estado de ‘desconectando…’ por diversos minutos;
• separe sempre servidores web e banco de dados. Neste caso o cliente não tinha dados críticos neste servidor e portanto a criação de um novo não impactou em perda de dados. Mesmo assim, ainda é possível iniciar o servidor que sofreu a pane, depois que ela for resolvida e resincronizar os dados desde o último backup;
• mundo ideal: tenha seu site/sistema de forma redundante e resiliente. Existem diversos artigos de como fazer (veja o Web Application Hosting: Best Practices)

Conheça o Cloud8! Acesse nossa calculadora e simule o seu cenário, ou crie sua conta para um teste de 15 dias sem compromisso clicando aqui.