technique:incidents:incident-10-01-18

2018/01/10 : coupure électrique et catastrophe

Résumé

Le 10 janvier 2018 vers 8h30, une coupure électrique (planifiée mais que l’on a pas vu venir) chez notre hébergeur Tetaneutral a éteint brutalement nos machines. Les hyperviseurs ont mal redémarré et un soucis d’accès à distance a étendu la panne pendant 58h.

Début: mercredi 10 janvier 2018 à 08H25
Fin: vendredi 12 janvier 2018 à 18h25
Services impactés: Tous

Timeline

Heure Événement
mercredi 10 janvier 2018
8h25 Coupure électrique des deux hyperviseurs Alice et Bob. Début de l’incident.
10h17 Kyâne constate que les services sont down. Les VMs sont down mais les hyperviseurs ping. Notification au reste du bureau, la piste d’un soucis de routage est envisagée.
12h09 Jérôme constate que les hyperviseurs ne sont pas accessibles en SSH (via clef), il est bloqué.
12h53 Après contact avec Tetaneutral, Stéphane signale que la cause initiale est la coupure électrique du matin.
13h09 Antoine est mis au courant, il ne parvient pas non plus à ce connecter.
14h35 Kyâne (depuis une connexion instable, expliquant la latence dans les opérations qui suivent) essaye à son tour de se connecter, sans succès via clef SSH. Il parvient cependant à se connecter sur Alice via mot de passe avec l’utilisateur pica puis à passer root, toujours via mot de passe.
14h50 Le dossier /etc/pve de Alice est vide. Le fichier .ssh/authorizedkeys étant un lien symbolique de /etc/pve/priv/authorizedkeys ceci explique le soucis d’accès SSH impossible. Un reboot de Alice est fait, un peu “dans le doute”.
14h57 Tentative d’upgrade de Proxmox, en espérant repeupler le dossier /etc/pve. apt-get ne parvient pas à contacter le repository de Proxmox car il utilise ftp au lieu de http. Le fichier de configuration est modifié pour fixer cela.
15h11 apt-get update && apt-get dist-upgrade sur Alice. L’upgrade de Promox échoue sur un soucis de dépendances.
dpkg: des problèmes de dépendances empêchent la configuration de proxmox-ve :
 proxmox-ve dépend de pve-manager ; cependant :
 Le paquet pve-manager n'est pas encore configuré.
 proxmox-ve dépend de qemu-server ; cependant :
 Le paquet qemu-server n'est pas encore configuré.
Des erreurs ont été rencontrées pendant l'exécution :
 pve-cluster
 qemu-server
 pve-ha-manager
 pve-container
 pve-manager
 proxmox-ve
E: Sub-process /usr/bin/dpkg returned an error code (1)
15h21 Étant bloqué, la décision de supprimer et réinstaller complètement Proxmox est prise (apt-get purge pve* proxmox*).
15h30 Profitant du downtime, l’upgrade vers Debian Stretch est faites, pour installer Proxmox 5.
15h57 Reboot de Alice après passage à Debian Stretch, mais sans Proxmox. La machine ne répondra plus au ping après le reboot.
17h10 Après quelques ennuis sur l’accès vPro, Alice finit par être rebootée physiquement. Puis l’accès se fait via VNC puisque de la machine ne remonte pas sur le réseau.
17h30 Après avoir obtenu un accès root via VNC, on constate que Alice n’a pas configurée son IP publique correctement au démarrage. En effet le script /etc/rc.local configure l’IP publique sur l’interface vmbr0, qui est l’interface que l’on utilise avec Proxmox. Suite à la désinstallation (temporaire) de Proxmox avant le reboot, la configuration réseau n’a pas fonctionné. Pour continuer à avancer, on configure à la main l’IP publique sur l’interface eth1.
17h49 Antoine prend en main le dépannage de Bob, tandis que celui de Alice est laissé en attente (difficulté de trouver du réseau pour Kyâne + indisponibilité).
18h09 L’hyperviseur Bob n’a pas redémarré après reboot à cause d’une erreur de configuration du fichier /etc/hosts.
janv. 10 18:07:10 bob systemd[1]: Starting The Proxmox VE cluster filesystem...
janv. 10 18:07:10 bob pmxcfs[8088]: [main] crit: Unable to get local IP address
janv. 10 18:07:10 bob systemd[1]: pve-cluster.service: control process exited, code=exited status=255

En effet pve-cluster n’arrive pas à trouver l’adresse IP de la machine car 2 adresses sont retournées: 

root@bob:~# hostname -i
127.0.1.1 192.168.128.154

Après correction du fichier, un restart du service pve-cluster remet la machine sur pied.

18h12 Une fois que les VMs et services sur Bob sont remontés, Antoine prend en main Alice.
18h17 Changement du /etc/hosts de Alice afin de ne pas rencontrer le même problème que sur Bob une fois remise en route.
18h19 Tentative de réinstallation de Proxmox 5, suppression des repos Proxmox non opensource et réinstallation. Même problème de dépendances circulaires rencontrées par Kyâne précédemment.
18h25 Suppression des packages posant des problèmes (pve-firewall, qemu-server). Avant de relancer une installation de Proxmox, Antoine a voulu vérifier que la machine rebootait bien et semblait fonctionnelle. À ce moment, hormis le clavier qwerty au niveau du VNC, rien ne laissait présager que cette manipulation aller nous couper de la machine.
18h26   Reboot lancé sur Alice. La console VNC se coupe puis plus rien. Antoine n’a pas de moyen de suivre la séquence de boot. Décision est prise de redémarrer Alice à partir de l’interface Intel vPro. La commande de reboot est bien prise en compte par la machine mais le VNC est toujours inopérant.
18h30 Seconde tentative de reboot à partir de l’interface vPro. Message d’erreur dans la page web. Il n’est plus possible de lancer de commande à distance sur Alice. Les logs nous indiquent bien qu’une séquence de boot a été lancée sans nous donner plus d’informations. La console VNC ne répond toujours pas. La machine ne ping pas sur ses IP (publiques ou privées. Même problème que précédemment, l’IP publique n’est pas configurée).
18h44 Impossible de reprendre la main à distance. Tetaneutral propose de redémarrer physiquement la machine, au mieux le vendredi 12.
vendredi 12 janvier 2018
14h11 Alice est redémarrée physiquement par Tetaneutral.
17h03 Kyâne (toujours sur une connexion précaire) accède en VNC à Alice, configure manuellement l’IP publique, et tente une installation de Proxmox. Même erreur, mais un message d’erreur permet d’identifier une potentiellement cause à ce problème.
insserv: Service pve-cluster has to be enabled to start service pvefw-logger
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
17h45 Après des recherches, il semblerait que Proxmox ne supporte plus ''innserv'' dans sa version 5. Étant sur Debian Stretch avec systemd, on peut supprimer sans soucis avec apt-get purge insserv. Cependant ceci supprime aussi le paquet systemd-sysv, que l’on réinstalle aussitôt avec apt-get install systemd-sysv.
17h55 L’installation de Proxmox passe ensuite sans soucis, Alice est redémarrée.
17h58 Alice redémarre sans problème. Les VMs remontent toutes seules (à l’exception de pica01-test qui était mal configurée). On s’assure que tout les services remontent correctement.
18h25 Toute l’infrastructure est de retour à la normale. Fin de l’incident.

Bilan

Ce qui s'est bien passé

  • On a réussi à avoir un accès SSH à la machine en passant par un double mot de passe (utilisateur pica puis root) en backup de l’accès par clef qui était cassé.
  • Malgré une extinction brutale, il n’y a pas eu de pertes ou de corruption de données. En cas de problèmes, les backups étaient de toute manière accessibles.

Ce qui s'est mal passé

  • On a pas anticipé la panne car on n’était pas au courant de la coupure.
  • Picasoft n’ayant pas actuellement un système d’alerting, la panne a été constatée plus de 1H30 après son début.
  • La communication interne ne s’est pas mise en place convenablement (d’abord par mails, mais toutes les personnes susceptibles d’aider n’étaient pas au courant).
  • L’accès vPro et VNC de Tetaneutral qui a planté, nécessitant un redémarrage manuel.
  • Le choix de profiter du downtime pour mettre à jour la version de Proxmox sur Alice était clairement une mauvaise idée. Ce n’était pas le moment pour cela.

Amélioration

Suite à l’incident, un certain nombre de corrections ou de mesures doivent être mises en place.

  • Se tenir au courant des maintenances et pannes du côté de Tetaneutral. Ils ont une mailing technique, mais il y a beaucoup de mails qui passent dessus.
  • Préparer et utiliser Framateam systématiquement comme moyen de communication interne en cas de panne.
  • Même dans le rush de l’incident, toujours documenter les actions effectuées et les problèmes rencontrés (reprise plus facile pour un autre membre de l’asso)
  • Avoir une mailing list avec les personnes qui peuvent intervenir sur l’infrastructure (et sur laquelle envoyer les alertes).
  • Faire une documentation pour la gestion des incidents (quels outils, quels moyen d’accès, quelles procédures, etc.)
  • Mettre à jour Bob sur Proxmox 5, comme Alice.
  • Faire une page web avec des informations publiques pour la communication extérieur en cas d’incidents.
  • Réfléchir et documenter une procédure pour restaurer les VMs d’un hyperviseur sur l’autre.
  • technique/incidents/incident-10-01-18.txt
  • de qduchemi