====== 2018/01/10 : coupure électrique et catastrophe ====== ===== Résumé ===== Le 10 janvier 2018 vers 8h30, une coupure électrique ([[https://lists.tetaneutral.net/pipermail/technique/2018-January/003070.html|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/authorized_keys'' étant un lien symbolique de ''/etc/pve/priv/authorized_keys'' 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 [[https://www.mail-archive.com/pve-user@pve.proxmox.com/msg08279.html|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 [[https://lists.tetaneutral.net/listinfo/technique|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.