Pannes d’octobre puis novembre 2017

La panne gigantesque chez OVH qui a fait trembler le web européen le 9 novembre 2017, séisme évalué à 8 sur l’échelle de Richter,  n’a pas été sans incidence sur Piwigo.com. Mais avant cela il y a eu la panne du 7 octobre puis celle du 14. Revenons sur ces pannes avec quelques explications.

Photo by Johannes Plenio on Unsplash

Photo by Johannes Plenio on Unsplash

A) Panne du 7 octobre

Le samedi 7 octobre 2017, notre serveur « reverse-proxy », celui par lequel passe tout le trafic web, a crashé. OVH, noter hébergeur technique, a identifié un problème sur la carte mère et l’a remplacé. Le trafic a été routé sur le serveur de secours le court temps nécessaire au remplacement du matériel défectueux. Une panne sans gravité réelle, sans perte de données, mais qui annonçait le démarrage d’une série douloureuse d’ennuis techniques.

B) Panne du 14 octobre

Une semaine plus tard, le 14 octobre, le même serveur s’emballe jusqu’à être incapable de renvoyer les pages web demandées par les visiteurs… Le trafic est donc à nouveau basculé sur le serveur de secours, en lecture seule pour les comptes hébergés sur ce serveur. Environ 10 heures de recherche plus tard, devant l’impossibilité de déterminer l’origine du problème, nous décidons de basculer le serveur de secours en écriture. Cette décision fut difficile à prendre car elle signifie que les données produites entre la dernière sauvegarde (1h du matin) et le moment de la bascule (environ 8h du matin) sont perdues. Autrement dit, pour les comptes hébergés sur ce serveur, les photos ajoutées dans la nuit ont simplement « disparu » de leur Piwigo.

C’est la première fois dans l’histoire de Piwigo.com que nous basculons un serveur de secours en écriture. Malheureusement, un autre problème est arrivé, lié au premier. Pour vous expliquer ce problème, il faut un peu rentrer dans le détail du fonctionnement des serveurs Piwigo.com.

Sur l’infrastructure Piwigo.com, les serveurs fonctionnent par paire : un serveur principal et son serveur de secours. Il y a actuellement 4 paires en production. Le serveur principal s’occupe de la « gestion courante », tandis que le serveur de secours est synchronisé avec le serveur principal chaque nuit et reçoit le trafic web en lecture seule.

En temps normal, le serveur de secours est configuré pour n’autoriser que la lecture, c’est à dire que l’on peut visiter les albums ou voir les photos, mais pas entrer dans l’administration ou ajouter des photos.

L’un des couples de serveurs constitue ce que l’on appelle le reverse-proxy : tout le trafic web de *.piwigo.com passe par ce serveur et selon le piwigo concerné, le trafic part vers l’un  ou l’autre serveur de l’infrastructure. En temps normal le reverse-proxy est configuré pour pointer vers les serveurs principaux des couples de serveur.

Lorsqu’un problème survient sur l’un des serveurs principaux, nous basculons le trafic sur son serveur de secours. S’il s’agit du serveur reverse-proxy, on bascule l’adresse IP Fail-Over (IPFO) : un mécanisme que l’on gère sur notre console d’administration OVH. Pour les autres serveurs, on modifie la configuration du reverse-proxy.

Voilà pour les explications… revenons au 14 octobre 2017 : nous avons donc basculé l’IPFO pour utiliser le serveur reverse proxy de secours. Malheureusement, 2 problèmes en cascade :

  1. le serveur reverse proxy de secours, pour l’un des couples de serveurs, pointait sur le serveur de secours
  2. le serveur de secours en question était configuré en écriture au lieu d’être en lecture seule

Pourquoi cette configuration anormale ?

Parce que nous utilisons parfois l’infrastructure de secours pour faire des tests « grandeur nature ». En l’occurrence il s’agissait de tests sur l’IPV6.

Quel impact pour les utilisateurs ?

Pendant les trop nombreuses heures où le trafic web passait par le reverse-proxy de secours, les hébergés du serveurs en question sont revenus sur l’état de la nuit précédente (les photos ajoutées dans la nuit/matin) ont apparemment disparu, puis ils ont pu continuer à ajouter des photos. Cet état n’a pas déclencher d’alerte particulière, la situation semblait « normale » pour les utilisateurs concernés. Lorsque le problème a été détecté, nous avons modifié la configuration du reverse proxy pour pointer à nouveau sur le serveur principal. Conséquence : toutes les photos ajoutées pendant « la panne » ont apparemment disparu.

Quelles actions ont été entreprises suite à la panne du 14 octobre ?

1) Vérification de la configuration reverse-proxy

Un nouveau script a été mis en production, qui vérifie très régulièrement que le reverse proxy est configuré pour pointer sur les serveurs principaux.

2) Vérification écriture Vs lecture seule

Un autre script a aussi été mis en production, qui vérifie que les serveurs principaux sont configurés en écriture et les serveurs de secours en lecture seule

3) Compartimentage des applications web tierces

Les applications web « non vitales » et que l’on maîtrise moins, ont été basculées sur un serveurs tiers dédié à cet usage : blog anglophone, blog francophone, wiki interne, forum interne et piwik (analyse des visites). En effet, l’une des hypothèses de la panne en cours, est qu’une application s’est emballée où qu’elle aurait fait l’objet d’une tentative d’attaque. Le fait de déplacer ses applications dans un « compartiment » distinct permet de limiter l’impact d’un dysfonctionnement.

4) Nouveau système de sauvegarde

La décision de basculer un serveur de secours en écriture, c’est à dire le transformer en serveur principal, est particulièrement difficile à prendre. En effet il s’agit d’abandonner l’espoir de revenir sur le serveur principal actuellement en panne. Cette décision est difficile car elle implique d’accepter une perte de données.

Pour faciliter cette décision, 2 mesures ont été prises : d’abord prédéfinir le temps maximum au bout duquel on applique la bascule. Dans notre cas, si la panne dure davantage que 2 heures (hors nuit), il faut basculer. Ensuite, il faut que les sauvegardes soient plus fréquentes que 1 fois par jour : si les sauvegardes avaient seulement 1 ou 2 heures, la décision auraient été bien plus simple à prendre !

En complément de la sauvegarde journalière, nous avons donc ajouté un nouveau système de « sauvegardes glissantes » : toutes les 15 minutes, le script analyse chaque Piwigo sur certains critères (ajout/édition/suppression de photos/utilisateurs/albums/groupes…). Si quelque chose a changé depuis la dernière sauvegarde, le script sauvegarde le Piwigo (fichiers + base de données) en le synchronisant sur le serveur de secours approprié.

C) Et la panne OVH gigantesque des 9 et 10 novembre 2017 ?

Étant hébergés chez OVH, notamment dans le datacentre de Strasbourg, la panne nous a énormément affecté. D’abord parce que notre serveur reverse proxy principal est à Strasbourg. Donc la panne a mis Piwigo.com totalement hors service pendant toute la matinée du 9 novembre. Ensuite parce qu’il nous a été impossible de basculer l’IP Fail Over. Ou plutôt, OVH nous a permis de le faire, mais au lieu de nécessiter 60 secondes, cela a pris 10 heures ! Des heures pendant lesquelles les hébergés du serveur en question étaient en lecture seule.

Contrairement à la situation du 14 octobre, nous n’avons pas pu prendre la décision de basculer le serveur de secours car une demande de bascule IPFO était en cours, et nous n’avions pas la moindre idée de l’heure à laquelle OVH allait appliquer l’action.

L’infrastructure Piwigo.com a retrouvé un état normal le vendredi 10 novembre à 14h46, heure de Paris (France).

OVH prévoit une compensation pour ces pannes. Ce n’est pas grand chose, au regard du préjudice réel, mais nous allons intégralement transférer cette compensions à nos clients. Après des calculs très savants, cela correspond à 3 jours de crédits temps ajoutés sur chaque compte. C’est peu mais c’est pour le symbole !

Nous sommes désolés pour ces désagréments. Comme vous avez pu le lire dans ce billet de blog, nous avons amélioré nos méthodes pour limiter le risque à l’avenir et réduire l’impact d’une panne irréversible d’un serveur.

Ce contenu a été publié dans Général. Vous pouvez le mettre en favoris avec ce permalien.

6 réponses à Pannes d’octobre puis novembre 2017

  1. Pascaud jean-pierre dit :

    il n’y a que ceux qui ne font rien qui ne se trompe pas et moi je rajoute, il n’y à que ceux qui n’entreprennent rien qui n’ont jamais d’ennui.
    Donc tout excusé.
    bonne continuation à l’équipe piwigo.
    ps mon FAI c’est OVH, et je changerais pas à cause de quelques soucis.
    jipe

  2. ERMEL dit :

    vous êtes tout excusés pour ce genre de situation, comme on le dit  » l’erreur est humaine  » et là elle provient aussi d’une machine !!!
    de toute façon , un grand merci à l’équipe de PIWIGO, et bonne continuation

  3. avenet dit :

    no stress, je ne me suis aperçu de rien
    et quelques photos de perdues sur piwigo ? Bah j’ai connu pire avec une carte défectueuse en revenant d’un reportage

  4. Clem dit :

    Merci pour ces explications détaillées, c’est toujours intéressant !

  5. Bonjour Pierrick,

    Merci pour toutes ces explications.
    La loi des séries !!!

    J’étais à Strasbourg le jour du crash d’OVH, mais j’y suis pour rien, je l’jure…
    ;o)

    Bonne continuation à Piwigo et à OVH… et bonnes fêtes de fin d’année à tous.

    ;o)

  6. ALLAIN dit :

    OUI il faut relativiser. certes vous avez une obligation de réussite (OVH aussi) mais franchement, en plus du votre j’ai un hébergement sur OVH et je n’ai rien vue. Bon j’affiche mes photos, je ne vend rien.
    Je suis d’accord avec la personne plus haut qui dit:  » qu’il n’y a que ceux qui ne font rien qui ne se trompe pas » . On pourrait aussi dire qui ne tombe pas en panne.
    Une panne c’est imprévisible et le moins qu’on puisse dire est qu’OVH, y a mis les moyens pour réparer.
    Bonne fin d’année à toute votre équipe et continuez comme cela…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *