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 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 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 2.

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 3, 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). 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 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 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 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 6.

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

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

  1. Il existe désormais un supplément « Utilisation professionnelle » qui donne 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 à 86 400 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.

12 commentaires sur cet article

  1. Naouak, le lundi 10 décembre 2012 à 07:30

    J’ai fait une migration d’un serveur il y a peu de temps et j’ai utilisé casiment la même technique. Le seul problème que tu n’abordes pas ici et qui est assez important c’est gérer la création de contenus en fichier en production.
    Selon les cas, ça peut se régler en montant cas par cas certains dossiers en NFS mais c’est pas toujours le cas et j’avoue que j’ai pas de solutions efficace sinon.

  2. Maxime VALETTE, le lundi 10 décembre 2012 à 08:37

    Naouak : C’est une partie délicate oui. J’en parle dans mon article en évoquant le rsync pour les fichiers qui ne sont pas versionnés. Il faut s’assurer qu’aucun fichier n’écrasera l’autre et peut-être coder des scripts pour tester la présence de fichiers sur l’ancienne et/ou la nouvelle infrastructure.

    Mais pas de solution miracle en effet :)

  3. Léo, le lundi 10 décembre 2012 à 10:25

    Merci pour cet article Maxime. C’est toujours intéréssant de savoir comment tourne un site à fort trafic comme le tiens.

    Sinon petite question concernant OVH, on leur reproche souvent d’être un hébergeur low cost et que ce low cost se ressent, entre autres sur la bande passante et le peering au rabais. Tu as un avis là dessus ?

  4. Godefroy, le lundi 10 décembre 2012 à 10:27

    Salut Maxime, merci de partager cette expérience avec nous. Tu as choisi quelle solution pour le load balancing chez OVH ?
    Tu as combien de pages vues par mois au total sur tous les sites hébergés sur ton infra ? (le rapport nombre de pages vues / nombre de serveurs m’intéresse)

  5. Maxime VALETTE, le lundi 10 décembre 2012 à 10:38

    Léo : Pas de soucis de mon côté, peut-être parce que je suis sur l’option Pro.

    Godefroy : Plus de 60M de pages vues par mois, sans trop compter les requêtes API qui occupent une bonne partie via les applis mobiles. Je détaillerai tout ça dans d’autres articles sur mon blog, au mois de Janvier :)

  6. Godefroy, le lundi 10 décembre 2012 à 11:03

    Ah oui l’API, dur de faire des comparaisons du coup, ça doit pomper beaucoup de ressources.

    Et le load balancing tu le gères comment ? Avec ça ? : http://www.ovh.com/fr/serveurs_dedies/ace_load_balancing.xml

  7. Maxime VALETTE, le lundi 10 décembre 2012 à 11:42

    Godefroy : Pardon j’avais zappé la question :) Non je fais du LVS redondé sur deux machines, je faisais déjà ça avant. Comme j’ai mon propre VLAN pas de soucis pour avoir des IP qui se baladent entre machines.

  8. Godefroy, le lundi 10 décembre 2012 à 14:30

    Un article sur le load balancing redondé avec LVS m’intéresserait beaucoup :-) Tu as des bonnes sources ?

  9. fensoft, le lundi 10 décembre 2012 à 22:55

    Quel était ton ancien prestataire ? Pour quelle raisons t’as-t-il mis « dehors » ?

  10. Maxime VALETTE, le mardi 11 décembre 2012 à 10:17

    Godefroy : Cette partie technique fera partie de mon article, je ne voulais pas « polluer » 24joursdeweb avec ces détails :)

    fensoft : Je n’ai pas envie de m’étendre sur la question en public mais les relations s’étaient dégradées depuis 6 mois.

  11. fensoft, le mercredi 12 décembre 2012 à 23:48

    Ok dommage, c’était pour éviter de reproduire la même erreur, pas pour remuer le couteau dans la plaie.

  12. Aurélien PONCINI, le jeudi 13 décembre 2012 à 10:45

    Bonjour,
    merci pour cet article Maxime. Très sympa :)

    @Godefroy : la solution HAproxy + Heartbeat fonctionne très bien également si jamais tu ne trouve pas de tuto pour LVS (mais j’en doute^^) .