De Paris à Toulouse

La semaine dernière, le site i-Run est passé en maintenance pour la première fois depuis 2012. Une maintenance programmée de longue date, étape importante de notre projet de modernisation des applications et des infrastructures.

On vous explique ça…

Contexte

Jusqu’à la semaine dernière, les serveurs de tous les sites i-Run se trouvaient à Paris dans une baie chez OVH. De bons et loyaux serveurs qui depuis 12 ans vous servent sans faillir les pages de nos sites. Mais voilà, vous êtes de plus en plus nombreux et aujourd’hui nos vielles machines peinent de plus en plus à vous répondre comme il se doit. Il est temps pour elles de céder la place à une nouvelle génération de serveurs frais et hautement disponibles.

C’est pourquoi depuis plusieurs mois, notre équipe d’infra travaille à la mise en place d’une nouvelle infrastructure sur Toulouse. Plus de serveurs, plus de capacité, plus de nœuds, plus de résilience, … bref des serveurs #RUNSTOPPABLE !

Les dessous de l’opération

La préparation

Cette opération, c’est tout d’abord des mois de préparation. Avec la mise au point d’une architecture crédible pour supporter notre trafic d’aujourd’hui mais aussi celui de demain. De nombreux tests de composants et de possibilités pour déterminer la meilleure solution. Une documentation claire avec des schémas lisibles qui nous permet de communiquer simplement et de faire valider les besoins et les solutions sans risque d’incompréhension.

Une fois le projet défini et validé, un découpage en tâches de tailles raisonnables (2~3 jours de travail) va permettre d’attaquer un projet immense avec une visibilité sur l’avancement semaine par semaine.

Mise en place

Durant la phase de mise en place, chacun des Administrateurs & Devops de l’équipe s’est attaqué aux tâches, une par une. Bien sur comme les problèmes n’attendent pas la fin du projet, il a fallu s’organiser pour avancer sur le projet tout en continuant de traiter les problématiques de maintenance courantes : Matériels à remplacer, imprimantes à configurer, évolutions et mises à jours, …

Chaque participant alterne entre les tâches du projet de migration et les tâches courantes afin de toujours avancer sans accumuler de la dette par ailleurs. La stratégie fut compliquée tant que Maxence était seul administrateur, mais dès que Nicolas nous a rejoint, il a été plus simple d’alterner.

Tests de montées en charge

Pendant deux semaines l’équipe d’infra a tenu les serveurs fraîchement installés sous de multiples sièges en continu. Plusieurs scénarios de test avaient été décrits :

• Des sieges intensifs avec une grande quantité de clients
• Des sièges moins soutenus mais sur des durées très longues
• Des restarts de serveur pendant la charge
• Des déploiements d’applications sous charge
• …

Pour chaque test, les conditions d’acceptances sont clairement définies.

Viennent ensuite les tests fonctionnels. Ici le but n’est pas de tester les applications car le code ne changera pas durant la migration mais plutôt les interactions entre les applications et l’extérieur du système.

• Vérifier les ouvertures de flux
• Vérifier les modes de paiements
• Déclarer les nouvelles IP aux prestataires
• …

Plusieurs jours de tests qui ont occupé les développeurs et les fonctionnels. Pendant ce temps les tests d’infra ont continué, afin de valider que les opérations de maintenance n’avaient pas d’impact sur l’utilisation des applications.

Transfert

Une fois les préparatifs terminés et testés, l’équipe est sereine pour cette opération de maintenance particulière qu’est le déplacement des serveurs de Paris vers Toulouse.

Vers 10h le lundi matin, une première synchro des données est réalisée à chaud afin de gagner un peu de temps durant la phase critique prévue pour 23h00. La bande passante est limitée pour ne pas impacter la production.

A 23h le site est passé en maintenance pour la première fois depuis 2012 et toutes les applications, ainsi que la BDD sont stoppées. On lance ensuite une nouvelle synchronisation à froid des données afin de rattraper le retard de la journée.

Vers 3h mardi matin, les données sont enfin disponibles sur les nouveaux serveurs à Toulouse. On peut maintenant relancer la BDD et les applications. Une fois les applications relancées et avant de rouvrir le site, on prend le temps de tester les applications et les tâches planifiées la nuit.

Quelques paramétrages et corrections de dernière minute plus tard, on est prêt à remettre le site en route et à rediriger le trafic vers les IPs de notre nouveau cluster de production.

Vers 6h (oui, c’était des grosses corrections) on commence par mettre à jour les DNS pour qu’ils pointent vers les nouvelles IPs. On avait pris soin la semaine précédente de baisser les TTL sur nos domaines pour que le changement se propage plus rapidement.

On configure aussi les anciens serveurs pour servir de reverse proxy vers les nouveaux, ainsi les gens qui utilisent les DNS de FAI lents sur les mises à jour DNS, ne seront pas obligés d’attendre une semaine pour accéder à nouveau au site.

En parallèle les slaves de la BDD ont été synchronisés et reconfigurés pour suivre la nouvelle BDD.

Enfin, vers 7h les sites ont quitté la maintenance et sont redevenus pleinement fonctionnels.

Post-migration

Bien sûr, et malgré beaucoup de préparation, tout ne se passe jamais sans accros, et le lendemain, en dépit de la fatigue, il a fallu faire face à quelques imprévus.

Le plus marquant fut un timeout mal placé sur les proxys qui, le temps que l’on comprenne, nous a obligé à relancer ces derniers plusieurs fois. Heureusement, comme la nouvelle infra est résiliente, aucune coupure n’a été remarquée et une fois le timeout fautif repéré, tout est rapidement rentré dans l’ordre.

D’autres soucis moins gênants ont été remontés par les autres équipes i-Run durant les jours qui suivirent :

• Des flux sortant qui sont passés à travers les mailles du filet
• Des réglages de HTTPS et de CORS
• Des CRON qui se lancent plus de fois qu’ils ne devraient à cause du nombre d’instances des applications
• …

Tous ces problèmes se sont rapidement réglés au cours de la semaine grâce à la réactivité des devs, du devops et des admins.

Retour à la normale

Au final, cette migration représente pour nous, le service info et pour i-Run, la première étape concrète d’un projet plus vaste de restructuration globale de notre Système d’Information.

Pour le service info, ce projet représente :

• 2 mois d’architecture et de recherche
• 5 mois de préparation et d’installation des serveurs
• 1 mois de test d’infrastructure
• 15 tâches dans notre board
• 66 points de charge réalisés (572 réalisés en 2020)
• 12 heures de migration et de suivi

Le tout en parallèle des tâches de maintenance quotidiennes.

Mais au final le challenge est relevé et la tâche accomplie !

Mais ça n’est que la première pierre de l’édifice.