Le blog Piwigo.com

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

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.

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.

17 jours après la sortie de Piwigo 2.9.0 et 4 jours après le début des mises à jours, la totalité des comptes Piwigo.com sont maintenant passés en version 2.9.0.

Nouveau design pour les pages d’administration dans Piwigo 2.9

Comme vous l’apprendrez en lisant attentivement les notes de la version 2.9.0, votre historique sera régulièrement et automatiquement purgé pour ne pas dépasser 1 million de lignes. Vous vous dites sans doute que 1 million c’est énorme, mais 176 Piwigo hébergés sur Piwigo.com en comptent davantage, avec un record établi à 27 millions de lignes !

A. La version courte

Le 28 avril 2017, nous avons migré l’un de nos principaux serveurs. L’objectif était d’avoir davantage de puissance et d’espace disque. La migration proprement dite s’est bien passée. Aucune interruption de service et seulement 7 minutes (de 8h00 à 8h07, heure de Paris/France) de passage en lecture seule pour une partie des comptes hébergés sur Piwigo.com.

Nous avons ensuite rencontré quelques difficultés pour communiquer avec les utilisateurs du service de courrier Gmail. La résolution du « problème Gmail » a rendu le site inaccessible pour quelques utilisateurs pendant environ 1 heure. Tout est revenu à la normale en quelques heures. Evidemment, aucune donnée n’a été perdue.

Le nouveau serveur s’acclimate bien à Piwigo et il a hâte de recevoir la version 2.9 dans les prochains jours 🙂

B. Les détails techniques

Un premier message d’information est parti vers 383 hébergés. Nous réalisons alors que les emails destinés à des adresses Gmail reviennent en erreur. En effet, Gmail a récemment mis en place des restrictions très fermes pour lutter contre le spam. Gmail veut ce que l’on appelle un « reverse DNS IPv6 ». C’est un peu barbare mais on l’avait déjà sur l’ancien serveur alors on l’ajoute sur le nouveau. Et là, patatra. Le nouveau serveur ne gère pas du tout l’IPv6 comme l’ancien : quelques utilisateurs, qui sont en IPv6, nous disent tomber sur une page « Apache2 Debian Default Page » au lieu de leur Piwigo. Retour sur le chronologie des faits :

• 8:00 démarrage migration, passage en lecture seule
• 8:07 bascule du trafic web vers le nouveau serveur
• 9:40 tout se passant bien, envoi de l’email d’information
• 9:52 erreurs Gmail, on bloque les envois de l’email
• 10:31 ajout d’une IPv6 sur le serveur
• 12:05 suite au retour de quelques utilisateurs, retrait de l’IPv6

Malheureusement, l’ajout/retrait de l’IPv6 n’est pas une action à effet immédiat. C’est ce que l’on appelle la « propagation des DNS ». Cela peut prendre jusqu’ à 3 heures, selon les utilisateurs.

Nous avons consacré le reste de la journée à faire accepter les emails par Gmail et à garder le site accessible pour tout le monde. Nous avons donc maintenant une IPv6, sur un sous-domaine de pigolabs.com (l’entreprise qui gère Piwigo.com) et cela n’impacte pas les visiteurs web.

Nous avons aussi une solution technique pour que les visiteurs web puissent accéder à vos Piwigo en IPv6. Mais après réflexion, nous ne souhaitons pas utiliser d’IPv6 car elle ne permet pas de faire des bascules instantannées du trafic web alors qu’IPv4 le permet, grâce aux IP FailOver proposées par OVH, notre hébergeur. C’est important car cela permet par exemple de basculer le trafic d’un serveur principal vers un serveur de secours.

Au final, une migration qui ne s’est pas si bien passée et pas mal de transpiration, mais tout est rentré dans l’ordre et le syndrome « Apache2 Debian Default Page » n’a finalement affecté que peu de monde !

Dans l’ombre depuis plusieurs années et pourtant déjà adoptées par plus de 50 organisations, il est temps de présenter officiellement les offres Piwigo.com Entreprise. Ces offres s’adressent aux organisations, privées ou publiques, à la recherche d’un outil simple, abordable et néanmoins complet pour gérer leur collection de photos.

L’objectif de Piwigo.com Entreprise est de démocratiser la photothèque, notamment pour les entreprises de taille modeste. Nous ne visons pas les entreprises du CAC40, même si certaines sont déjà clientes chez nous, mais les millions d’organisations, publiques et privées, qui n’ont pas le budget pour les solutions orientées « entreprise », très complètes fonctionnelement mais souvent chères et difficiles à prendre en main.

Piwigo.com Entreprise, pour un coût raisonnable, pourra venir remplacer des solutions bancales de dossier partagé sur l’intranet de l’entreprise, dans lequel les photos sont parfois dupliquées, parfois supprimées par inadvertance, sans aucune gestion fine des droits d’accès.

Page de présentation des offres Piwigo.com Entreprise

Pourquoi officialiser cette offre aujourd’hui ? Parce que la tendance de fond nous montre clairement que l’offre Entreprise plaît et trouve son public. Bien qu’alors semi-officielle, les offres Entreprise ont représenté près de 40% de notre chiffre d’affaire sur le mois de février 2017 ! Il est donc temps de mettre en valeur ces offres.

En pratique, voici ce qui change avec les offres Entreprise :

• elles sont accessibles aux organisations, contrairement à l’offre standard
• des fonctionnalités supplémentaires, comme le support de fichiers non-photo (PDF, vidéos…)
• niveau de service supérieur (support prioritaire, personnalisation, session de présentation)

Découvrez Piwigo.com Entreprise

Voici une « fonctionnalité », ou plutôt un « service » que les organisations, nombreuses parmi les clients de Piwigo.com, attendaient. Il ne sera plus nécessaire de contacter le support pour obtenir une facture. Sur la page [Administration > Mon compte > Gérer], vous trouverez un nouvel onglet « facturation ».

Nouvel onglet pour vos factures Piwigo.com

Cette page de facturation vous pose quelques questions. Les 2 plus importantes sont votre pays et si vous avez un numéro de TVA. En effet depuis le 1er janvier 2016, l’Union Européenne a décidé de complexifier la compta des entreprises qui ont des clients dans l’UE. C’est évidemment le cas de Piwigo.com. Nous devons maintenant reverser la TVA à chaque pays membre de l’UE, selon son taux de TVA spécifique. Sauf si vous avez un numéro de TVA. Vous comprenez donc pourquoi nous avons absolument besoin de ces 2 informations. Que vous souhaitiez éditer vos factures ou non. Nous allons bientôt devoir exiger de fournir ces informations avant tout paiement.

Le formulaire d’infos de facturation sur votre compte Piwigo.com

Ensuite nous avons besoin de 2 ou 3 informations : votre nom, éventuellement le nom de votre organisation et votre adresse. Ces informations sont uniquement nécessaires pour éditer vos factures. En aucun cas nous n’enverrons la facture par courrier postal. C’est simplement une obligation pour que la facture soit valide.

Lorsque vous affichez une facture, Piwigo.com utilise les infos « en cours » et il ne sera pas possible de générer la même facture avec d’autres informations. Attention donc à bien vérifier que vos informations sont correctes avant d’ouvrir la facture. L’idée est double : ne pas pouvoir générer la même facture pour 2 entités différentes et permettre à un client de changer d’adresse, sans que cela n’affecte ses anciennes factures.

Vous verrez que la facture n’est disponible qu’au format HTML. Vous pouvez obtenir une version PDF en imprimant la page et en choisissant de créer un PDF. C’est une fonctionnalité proposée par tous les navigateurs web modernes.

Nous lançons officiellement un nouveau projet concernant la démo Piwigo. Grosso modo, il s’agit de montrer des belles photos et de fréquentes mises à jour sur la démo, tout en mettant en évidence le contributeur avec un lien vers son Piwigo. Les photos de la démo seront donc « contribuées » par les utilisateurs Piwigo des quatre coins du monde !

Sur la démo, le contributeur est mis en évidence, avec un lien vers son Piwigo.

Ce projet fait suite à la refonte de la démo Piwigo.com en 2015. La récupération des photos des contributeurs enthousiastes avait été manuelle, donc fastidieuse si on voulait étendre la solution. Ce nouveau projet, c’est le même principe, avec une simplification du système grâce à un plugin dans votre Piwigo. Vous pourrez ainsi « suivre » vos contributions, etc.

Pour le moment, il s’agit de contribuer à la démo sur Piwigo.org. Plus tard le plugin Contribute to Demo évoluera pour vous permettre de choisir à quelle démo vous voulez contribuer, y compris les démos sur Piwigo.com.

Nous espérons que vous aimerez l’idée et que vous deviendrez l’un de nos contribeurs ! Lire tous les détails sur l’annonce de Piwigo.org.