Depuis maintenant quelques jours, la société OVH a subi un incident critique sur son site de Strasbourg. En effet, dans la nuit du 9 au 10 Mars 2021 un incendie à été déclaré dans le data centre nommé SGB2. Depuis, les vps (Virtual Private Server) son hors ligne.
Plan de reprise d’activité (PRA)
Lorsque des sociétés décident d’héberger leurs applications ou site Web chez un hébergeur, elles se doivent généralement de réfléchir à des solutions de reprise d’activité en cas de panne.
Je vais ainsi vous présenter ce que j’utilise de mon côté. J’ai pris la décision personnellement de ne pas laisser mes sauvegardes à la mains du même prestataire.
Dans un premier temps j’ai choisi de mettre en place un panel d’administration afin de gérer plusieurs sites internet. Ceci n’est généralement pas obligatoire ni peut être bien vue mais Lorsque l’on gère une multitude de serveur, il faut avoir une ligne directive.
Ma solution
De mon côté j’ai choisi la solution hestiacp qui n’ait autre qu’un fork du panel vestacp. Hormis la simplicité de création d’un virtualhost ou même d’une base de données j’aime bien cette solutions pour la facilité à programmer des sauvegardes vers un espace réseau.
Globalement chaque site internet est copié avec sa base de données et transformé en une simple archive .tar. Une fois ce .tar créé il est envoyé sur un espace réseau (en l’occurrence j’ai la chance d’avoir un NAS chez moi).
Du coup, pour en revenir à la coupure des services OVH, j’ai tout simplement pu recommander un nouveau serveur sur lequel j’ai pu redéployer mes sauvegardes d’un claquement de doigts (plus ou moins 15 minutes pour la restauration d’une vingtaine de sites internet).
J’ai ainsi pu répondre à l’ensemble des clients qui ont choisi ma prestation par une reprise de service rapide.
Les plus
Vestacp fonctionne avec plusieurs scripts shell. La commande v-restore-backup [nom du fichier.tar] permet justement de recréer une configuration et de déployer l’ensemble des fichiers au bon endroit.
L’autre côté pratique d’avoir un panel qui fonctionne avec des scripts shell est que c’est derniers son particulièrement facile à altérer, me permettant par exemple d’envoyer les attaques en blackhole au lieu d’utiliser un logiciel supplémentaire comme iptable.
Une solution pouvant ainsi être piloté par d’innombrable solution devOps tel qu’Ansible afin de faire une gestion de serveur de masse sans prise de tête 🙂
Pour conclure
Bref pour résumé la leçon de cette incident est qu’il faut toujours voir un serveur comme un container poubelle. Ne jamais avoir une adhérence forte avec une machine et conserver ainsi une grande flexibilité dans l’exploitation et la résolution d’une interruption de service.