Le changement d’hébergeur, c’est maintenant

L’été avait bien commencé. C’est une phrase que vous devez souvent entendre quand vous demandez comment furent les vacances d’un administrateur système. Et elles avaient plutôt bien commencé, jusqu’à ce que notre hébergeur de l’époque, chez qui nous avions toute notre infrastructure depuis plus de 2 ans et demi, c’est-à-dire 25 serveurs en production, nous fasse comprendre qu’il était temps de trouver un autre prestataire.

Oui, bien sûr. Migrer une infrastructure de 25 serveurs. Dans l’urgence. Au mois de juillet. L’été avait bien commencé.

Trouver un nouveau prestataire alors que la plupart essaient de prendre quelques jours de vacances en croisant les doigts pour qu’une canicule ne ravage pas les climatisations de leurs datacenters était déjà une bonne première étape. Mon choix s’est tourné vers OVH : serveurs disponibles rapidement, à la location, avec un bon prix sans avoir à négocier avec les commerciaux pendant de précieux jours. Notre location actuelle se terminait au 31 juillet et nous étions déjà le 7. C’est ironique car nous les avions quittés il y a plusieurs années par manque d’options pour les professionnels, et nous les rejoignions à nouveau grâce à la mise en place de ces options ¹.

Après 25 bons de commande (OVH ne permet pas de commander plusieurs serveurs à la fois, j’ai passé deux heures de fun), la migration pouvait commencer. Elle allait se dérouler en trois étapes : la préparation, la migration, et les finitions.

La préparation

J’ai commencé par envoyer les lettres de résiliation. Il n’y avait ainsi plus de marche arrière possible. Un bon moyen pour moi de réussir à temps est de me mettre la pression.

Pour que la migration soit parfaite, il ne fallait pas de coupure de service. Nos sites ne sont pas critiques, et nous n’avions pas d’évènement particulier en juillet, mais il n’est jamais bon pour l’humeur d’un administrateur système de recevoir des tweets « VDM marche pas !! ». Essayons d’éviter ça ².

La migration allait impliquer un changement des adresses IP de tous nos sites. Pour que les clients mettent à jour le plus rapidement possible ces adresses, je mis toutes les chances de mon côté en configurant le TTL à 120 secondes. TTL signifie Time To Live et indique aux machines le délai durant lequel l’information reçue doit être considérée valide. Elle est en général de 24 heures sur une entrée DNS. En la réduisant à 2 minutes, j’étais certain que la grande majorité des serveurs DNS se mettraient à jour dans les 5 minutes une fois mes adresses changées.

Par chance, mon nouveau bloc IP /26 était la même portion que mon ancien bloc : de x.x.x.192 à x.x.x.254. Cela m’a évité un sérieux mal de tête dû à la « traduction » d’une ancienne IP vers une nouvelle IP.

Passons vite sur l’installation de l’infrastructure en elle-même, ce n’est pas vraiment le sujet du jour. J’ai donc installé toute l’infrastructure « vide » chez OVH : 10 serveurs Web, 2 serveurs DNS, 7 serveurs MySQL et divers serveurs de cache et de sauvegarde, le tout devant deux répartiteurs de charge redondés qui me servent aussi d’entrée au réseau local via un VPN.

J’avais maintenant une infrastructure « clone » de celle en production, mais vide. Je mis tout de suite en place une copie des fichiers du NAS production vers le nouveau NAS ³, avec une mise à jour régulière des données qui n’étaient pas versionnées via rsync. Ainsi j’allais pouvoir migrer site par site sans perte de données.

La migration

Pour tester les performances des nouveaux serveurs, je décidai de migrer tout d’abord les sites les plus simples : ceux qui n’avaient pas de bases de données. Il n’y en a pas beaucoup, mais c’était suffisant pour vérifier que la mise à jour DNS se faisait rapidement et que les serveurs Web étaient bien configurés.

Comme tout se passe dans le réseau local, habituellement mes serveurs MySQL n’écoutent pas sur le réseau externe. Mais pour le bien de la migration, je ne les avais pas restreints à l’écoute locale. Je pus ainsi établir ce schéma de migration, qui diminue au maximum le redouté downtime :

1. Migrer la base de données de l’ancien serveur vers le nouveau (sans oublier de créer les utilisateurs et les droits adéquats). ⁴
2. Changer la configuration du site à migrer pour qu’il utilise la nouvelle base de données, écoutant en externe il pourra tourner correctement.
3. Comme le code est synchronisé sur les deux infrastructures, je peux maintenant mettre à jour l’adresse IP sur nos serveurs DNS pour que les clients aillent sur les nouveaux serveurs.
4. Au bout d’une période de 24 à 48 heures, je peux sans trop de crainte changer la configuration de connexion à la base de données vers l’IP interne.

Ce protocole avait bien fonctionné. Il n’y a que pour VDM (et FML) que ce fut un peu plus compliqué puisque les bases étaient conséquentes : plus de 20 Go. L’indisponibilité était inévitable, mais elle n’a pas dépassé deux heures. Pour ces deux sites, j’avais prévu de le faire à des heures de « faible » affluence : au cours du week-end vers 6 h du matin. L’indisponibilité n’a pas été très remarquée. C’était les deux derniers sites à être migrés car ils avaient aussi une configuration spéciale de base de données avec de la réplication maître-esclaves ⁵.

Tous les sites ont ainsi été migrés progressivement sur une période d’une dizaine de jours. En dehors de l’attente de la propagation DNS, il y avait les différentes copies et scripts à adapter en fonction de chaque site, ce qui a représenté une masse horaire non négligeable, sans compter les éventuelles erreurs dues au stress ou à la fatigue.

Il faut aussi se rappeler que nombre de sites avaient des scripts qui tournent à intervalles réguliers (crontabs). Leur migration était souvent délicate : à quel moment couper l’un pour lancer l’autre ? Et vérifier ensuite que tout se passait bien pour eux sur les nouvelles machines. Nous avions environ 250 scripts tournant en permanence…

Concernant la migration des autres services, j’allai un peu plus au cas par cas. Mon deuxième serveur DNS était déjà chez OVH mais le premier serveur a dû être migré. Cela avait été fait en amont en même temps que l’installation pour éviter de mélanger la migration des DNS et la migration des sites. Les dépôts Git avaient eux aussi été migrés en amont ⁶.

Les finitions

Le plus gros du travail était alors terminé. Un énorme sentiment de joie envahissait mon petit cœur d’administrateur système. Pourtant, ma tâche était loin d’être achevée car il faut maintenant s’occuper de la partie détestée de tous : faire la vaisselle, ou dans notre cas, nettoyer notre bazar pour rendre tout cela un peu plus propre.

Il a donc fallu passer sur chaque ancien serveur pour vérifier qu’il n’y avait plus aucune activité notable, avant de couper chaque service et vérifier que tout continuait à bien fonctionner sur les nouveaux serveurs. En général, je n’ai pas eu beaucoup de surprises de ce côté-là. Beaucoup avait déjà été fait pendant la migration en elle-même.

Il a ensuite fallu couper l’écoute externe des serveurs de bases de données et s’assurer qu’aucune ancienne IP (ou IP externe) ne traînait dans le code à coup de find et autres grep. La même chose fut de mise pour les entrées DNS.

En parlant d’entrées DNS, il ne fallait pas oublier que nous avions changé le TTL à 120 secondes. Ce fut aussi l’occasion de le repasser à 24 heures pour décharger un peu nos serveurs et améliorer les performances de résolution DNS ⁷.

Vint ensuite la partie ô combien importante de la sauvegarde et du monitoring. Je ne m’étendrai pas là-dessus car ça peut faire (et a déjà fait) l’objet d’articles sur mon blog et ailleurs. Cette partie est indispensable même si elle reste invisible 99 % du temps.

Pour finir, j’ajouteai de jolis reverse DNS à toutes les IP de notre bloc tel un paillasson « Home sweet home » au pied d’une nouvelle maison.

TL;DR

Eh oui, je l’ai fait. Migrer une infrastructure entièrement en production dans l’urgence et en plein mois de juillet. Même si je ne conseille ces circonstances à personne, j’espère que mon humble expérience à ce sujet pourra vous aider si jamais vous rencontrez un défi similaire. Et si jamais vous vous posez la question : l’été s’est bien terminé.