Mon infrastructure 2013, partie 1 : Migration

Le 30 janvier 2013 — par

Après plusieurs articles sur l’infrastructure VDM il y a quelques années (les liens sont ici) et une migration cet été chez OVH, j’ai décidé de faire une petite mise à jour sur l’état de mon infrastructure Web qui héberge entre autres VDM et FML.

À l’occasion de l’opération 24 jours de Web en décembre dernier, j’ai écrit la première partie qui concerne cette migration. La voici ci-dessous en préambule des articles à venir, un peu plus techniques.

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 à un administrateur système. Et ça avait 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 essaie de prendre quelques jours de vacances en croisant les doigts pour qu’une canicule ne ravage 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 rejoignons à nouveau grâce à la mise en place de ces options 1.

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 passer en trois étapes : La préparation, la migration, les finitions.

La préparation

J’ai commencé par envoyer les lettres de résiliation, ainsi il n’y avait 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 2.

La migration va impliquer un changement d’adresses IP de tous nos sites. Pour que les clients mettent à jour le plus rapidement possible ces adresses, je mets 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 pour lequel l’information reçue doit être considérée valide. Elle est en général à 24 heures sur une entrée DNS. En la réduisant à 2 minutes je suis sûr que la grande majorité des serveurs DNS se mettront à 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. Ça a pu m’enlever un bon mal de tête dans 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’ai maintenant une infrastructure « clone » de celle en production, mais vide. Je mets tout de suite en place une copie des fichiers du NAS production vers le nouveau NAS 3, avec une mise à jour régulière des données qui ne sont pas versionnées via rsync. Ainsi je pourrai migrer site par site sans perte de données.

La migration

Pour tester les performances des nouveaux serveurs, je décide de migrer tout d’abord les sites les plus simples : Ceux qui n’ont pas de bases de données. Il n’y en a pas beaucoup mais ça suffit pour vérifier que la mise à jour DNS se fait rapidement et que les serveurs Web sont 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 ai pas restreints à l’écoute locale. Je pourrai 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). 4
  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 a bien fonctionné. Il n’y a que pour VDM (et FML) que c’était un peu plus compliqué puisque les bases sont 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 : Le week-end vers 6h du matin. L’indisponibilité n’a pas été très remarquée. C’était les deux derniers à être migrés car ils avaient aussi une configuration spéciale de base de données avec de la réplication maître-esclaves 5.

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 représente 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 ont des scripts qui tournent à intervalle régulier (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 avons environ 250 scripts qui tournent en permanence…

Concernant la migration des autres services, c’est 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 à la migration des sites. Les dépôts Git ont eux aussi été migrés en amont 6.

Les finitions

Le plus gros du travail est maintenant fait, et c’est un énorme sentiment de joie qui envahit mon petit cœur d’administrateur système. Et pourtant c’est loin d’être fini car il faut maintenant s’occuper de la partie que l’on déteste 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 pas beaucoup de surprises de ce côté-là car 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 d’autres grep. La même chose pour les entrées DNS.

En parlant d’entrées DNS, il ne faut pas oublier qu’on avait changé le TTL à 120 secondes. C’est aussi l’occasion de les repasser à 24 heures pour décharger un peu nos serveurs et améliorer les performances de résolution DNS 7.

Vient 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 ou ailleurs. Elle est indispensable même si invisible 99% du temps.

Pour finir, ajoutons de jolis reverses DNS à toutes les IP de notre bloc tel un paillasson « Home sweet home » au pied de sa nouvelle maison.

TL;DR

Hé 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é.


  1. Il existe désormais un supplément « Utilisation professionnelle » qui donnent le droit d’utiliser le KVM, d’avoir son bloc RIPE, du stockage NAS ou encore de mettre ses serveurs dans une baie virtuelle pour faire un VLAN. 

  2. Même si parfois cela peut m’être d’une grande aide, comme pour mon problème d’adresses IP

  3. Je vous invite à lire l’excellent article sur la copie efficace d’une source vers de multiples destinations, chez Tumblr

  4. MySQL permet de créer les utilisateurs avec des droits correspondant à des tables qui n’existent pas. Ça m’a permis de créer les utilisateurs une fois pour toutes avant la migration des données. 

  5. Mes 7 serveurs MySQL sont répartis comme ceci : 1 serveur maître pour VDM avec 2 esclaves, 1 serveur maître pour FML avec 2 esclaves, le dernier serveur MySQL suffit à supporter la charge de tous nos autres sites. 

  6. Nous sommes depuis passés sur GitHub, ce qui faciliterait grandement cette partie pour une éventuelle prochaine migration. 

  7. Cet effet sur les performances est probablement inexistant mais le TTL à 86400 secondes fait toujours partie des bonnes pratiques du métier. Si vous souhaitez en savoir plus, il y a un excellent papier du MIT à ce sujet

S'abonner au flux RSS du blog
Recevoir les nouveaux articles par e-mail :