Ce lundi 7 février, entre 15h48 et 21h, les mails, les accès FTP, WebDAV et notre propre site ont été largement indisponibles. L’ensemble des autres services n’a pas été impacté, notamment les sites Web et bases de données de nos clients, les serveurs DNS, l’accès SSH. Aucune donnée n’a été perdue.

Le déroulement précis de cette panne exceptionnelle – la plus longue de notre histoire – est détaillé dans la suite de ce billet. Nous reviendrons également sur les mesures qui seront prises pour éviter que cela ne se produise à nouveau.

Ce qui s’est passé

Vers 15h45, j’entreprends de mettre à jour les outils PostgreSQL (comprenant notamment pg_dump) en version 9.0 sur le serveur hébergeant les sites *.alwaysdata.com (nos propres sites, donc, pas les sites de nos clients) et notre base de données de production.

Pour ce faire, je dois préalablement supprimer les outils de la version 8.4 ; or la suppression de ces outils entraîne la suppression de PostgreSQL lui-même (le serveur). Malgré la demande de confirmation, je valide, croyant à tort qu’il s’agit de fichiers communs et non de la partie serveur de PostgreSQL. De cette terrible erreur humaine découleront 5h de panne.

MISE À JOUR : Plusieurs personnes nous ont fait remarquer qu’il serait préférable d’effectuer les mises à jour sensibles la nuit, et de les tester auparavant. Je me suis donc mal exprimé : il ne s’agissait pas d’une mise à jour de PostgreSQL, mais simplement d’un paquet annexe et totalement secondaire. Ce genre d’opération est effectuée quotidiennement et ne pose aucun risque. Sans cette erreur humaine, j’aurais simplement annulé la commande au moment de confirmer. Les mises à jour présentant le moindre risque sont, elles, bien testées sur un serveur de test puis effectuées la nuit.

Hélas, la suppression de PostgreSQL entraîne – sous Debian – la suppression des données elles-mêmes, et non simplement du logiciel (ce qui est à mon sens une très mauvaise idée). Malgré une CTRL+C quasiment immédiat, une partie des fichiers de notre base de données de production a été supprimée. Pour maximiser les chances de restauration, j’arrête tout ce qui tourne sur le serveur et démonte la partition.

À cet instant – 15h48 – notre base de données de production est inaccessible. Or cette base, en plus d’être utilisée par nos sites et notre interface d’administration – est également utilisée pour l’authentification SMTP, IMAP/POP, FTP et WebDAV. C’est pourquoi il est désormais impossible de se connecter à une boîte mail, d’envoyer/recevoir un mail, ou de se connecter en FTP/WebDAV. Les utilisateurs déjà connectés (en IMAP ou en FTP par exemple) ne sont pas concernés.

Je réalise rapidement que le contenu de notre base de production est intact, mais que les fichiers de la base système de PostgreSQL sont touchés. Dans ce cas de figure, il n’y a malheureusement pas de méthode systématique pour pouvoir réaccéder aux données ; il faut mettre les mains dans le cambouis. Il est impossible de donner une estimation d’heure pour le retour à la normale : cela peut prendre 15 minutes, ou beaucoup plus.

Après presque deux heures sans succès, et voyant que la situation risque de perdurer, nous décidons de remettre une sauvegarde en ligne, accessible en lecture seule uniquement, et servant au FTP, WebDAV et POP/IMAP. À 17h38, donc, ces services sont de nouveau opérationnels, sauf pour les comptes récemment créés (ne se trouvant pas dans la dernière sauvegarde). Le SMTP est exclu pour éviter de refuser (et donc perdre) des emails entrants pour les nouveaux comptes.

Il nous faudra encore près de 3h avant de parvenir à restaurer intégralement la base de production, sans aucune perte de données.

Éviter que cela ne se reproduise

À chaque panne que nous rencontrons, de la plus petite à la plus importante, nous nous interrogeons systématiquement sur les moyens à mettre en place pour éliminer – ou du moins largement atténuer – les risques qu’elle ne se reproduise.

Commençons par évoquer l’origine du problème : l’erreur humaine. Il est possible, dans certains cas, de minimiser les chances de faire une erreur. Nous avions ainsi instauré l’année dernière certains changements : distinction des machines de développement et de production en rajoutant de la couleur au prompt, installation d’un outil empêchant de supprimer (via rm) des données vitales. Dans le cas présent, malgré la demande de confirmation, ma confusion m’a fait prendre une décision désastreuse. À ce niveau-là, je ne vois pas de moyen miracle d’empêcher que cela ne se reproduise.

La solution est donc d’ordre technique. Notre base de production, cruciale pour le fonctionnement de plusieurs de nos services, représente un évident SPOF (Single Point of Failure). La solution, tout aussi évidente, est donc de la dupliquer. Triste ironie, nous avions déjà prévu cette amélioration qui devait intervenir très prochainement…

Depuis PostgreSQL 9.0, un mécanisme de synchronisation des données en temps réel est inclus en standard. C’est ce que nous allons utiliser pour avoir une base miroir, accessible en lecture seule, sur un second serveur indépendant (situé dans un datacenter différent du premier). Ainsi, en cas de suppression sauvage de la base – ou de tout autre problème sur le serveur primaire – le serveur secondaire prendra immédiatement le relai, et aucun des services cruciaux ne sera perturbé.

Cette synchronisation en temps réel ne résout toutefois pas un autre problème potentiel : celui d’une suppression des données au niveau SQL (via un DELETE ou un DROP). Toute modification de la base sur le serveur primaire se fait instantanément sur le serveur secondaire, donc les données seraient définitivement perdues.

Pour pallier ce problème potentiel, nous allons renforcer notre fréquence des sauvegardes de cette base. Aujourd’hui quotidienne, nous allons la passer à une fréquence plus élevée – probablement chaque heure. Notre serveur secondaire sera basé sur EC2, où le système de snapshot permettra de gérer ces sauvegardes automatiques de manière très simple.

En conclusion

Nous présentons naturellement nos plus sincères excuses à tous nos clients pour cette panne exceptionnelle. Sachez qu’à aucun moment vos données n’ont été menacées.

Nous travaillons maintenant depuis plusieurs semaines exclusivement sur le renforcement de notre stabilité générale, concernant tous les services – c’est la raison pour laquelle les nouveautés sont peu nombreuses en ce moment. Le déploiement de notre nouvelle architecture, première source d’indisponibilité en 2010, est désormais bien derrière nous, et 2011 s’annonce sous les meilleurs auspices, à tous points de vue.

À très bientôt pour des nouvelles plus agréables :)