Postmortem 18/05/2020: reboot inesperado, crontab zoado, glusterfs não montado
Métricas
- Tempo fora do ar: 9 minutos
- Serviços afetados: T O D O S
- O quão foi afetado?: Queda total
O que aconteceu
Estávamos felizes e contentes em uma de nossas discussões diárias sobre qual editor de texto serviço de comunicação utilizar, quando de repente recebemos uma mensagem da nossa querida Ada, que é um bot de telegram que monitora os serviços e repositórios do IMEsec:
processo de resolução
0. O que sabíamos
A primeira coisa a ser feita foi verificar se foi só a Ada que caiu ou se houve algum problema no servidor. Uma rápida visita a imesec.ime.usp.br nos disse que nem o servidor de DNS sobreviveu.
Logo que logamos no servidor por SSH ficou claro o problema: ele reiniciou inesperadamente e o GlusterFS não conseguiu auto-montar, e portanto nenhum container conseguiu subir.
1. desescalando o problema
Como foi só uma falha em inicializar, a solução foi simples: iniciar manualmente o GlusterFS e subir nossos serviços.
Isso se resume a dois comandos:
mount -t glusterfs localhost:services /services && docker-compose up -d
E com isso tudo voltou ao normal :)
Analisando o ponto de falha
O GlusterFS não está listado em nossa /etc/fstab pois caso algum problema desse tipo ocorresse, o sistema inicializaria em modo de recuperação sem rodar nenhum serviço, então não conseguiríamos conectar por SSH.
A solução temporária pra isso foi colocar a linha
@reboot sleep 20 && mount -t glusterfs localhost:services /services
na crontab de root, para esperar alguns segundos para a stack de rede inicializar e em seguida montar o GlusterFS. Mas como já dizia Alan Turin: "Não há nada mais permanente do que uma solução temporária" [citation needed], então ela ficou lá. Eventualmente a stack de rede demorou um pouco mais de 20 segundos para subir e deu ruim.
A solução certa seria provavelmente fazer uma unidade do systemd e colocar a stack de rede como dependência.
O que foi feito?
- @reboot sleep 20 && mount -t glusterfs localhost:services /services
+ @reboot sleep 60 && mount -t glusterfs localhost:services /services
Follow-ups
Ainda não sabemos ao certo o motivo do servidor ter reiniciado, mas suspeitamos do hardware pré histórico, pois ao ver o arquivo /var/log/syslog percebemos que ele estava corrompido logo antes da inicialização (depois que reiniciou):
TO BE CONTINUED.... I hope......