Web hosting : Comment migrer 3 Millions de sites web ?

Temps de lecture estimé : 14 minute(s)

Dans les articles précédents, nous avons vu quelles sont les contraintes opérationnelles et techniques du projet de migration de notre datacentre de Paris.

Si vous n’avez pas tout suivi sur nos contraintes techniques, je vous invite à relire l’article présentant l’infrastructure de nos hébergements web. Nous avons bâti nos scénarios de migration en prenant fortement en compte ces contraintes.

Pour venir à bout de ce projet à haut risque, nous avons envisagé plusieurs scénarios. Chacun comportant leur lot de difficultés et de risques opérationnels. Prenons le temps de voir quels projets de migration ont été étudiés, avant d’expliquer comment nous avons sélectionné le meilleur.

Un scénario, des scénarii

Dans les scénarios de migration, nous parlerons de notre principal problème qui est d’éviter le « split brain ». Ce problème a lieu lorsque l’on reçoit des écritures de données à deux endroits : la source de la migration et sa destination, au même moment.

Le plus simple reste de prendre un exemple : imaginez un site e-commerce en cours de migration et disponible à la source et à la destination en même temps. Si un client de ce site passe une commande, que cette information arrive sur l’infrastructure de destination, et que lorsqu’il paie sa commande, la requête arrive sur l’infrastructure source, le site web ne pourra pas faire le lien entre le paiement et la commande. C’est ce que l’on nomme un « split brain ».

Pour résoudre ce type de problème, il faudra reprendre les deux bases de données pour les harmoniser, ce qui est possible lorsque l’on maîtrise le modèle de données, et donc généralement le code source du site.

En tant qu’hébergeur web, nous n’avons pas la main sur le code source de nos clients. Et à notre échelle, nous ne pouvons même pas imaginer régler les soucis que nous pourrions rencontrer. Ainsi, nous ne pouvons pas envisager de scénario entraînant du split brain.

Migrer les sites unitairement

Migrer les sites web indépendamment les uns des autres est la première idée que nous avons eue. C’est d’ailleurs la solution que nous préconisions pour les clients souhaitant bénéficier rapidement des avantages de Gravelines avant d’entamer cette migration globale.

Voici ce que devaient généralement effectuer nos clients :

  • Identifier toutes les bases de données utilisées par leur code source
  • Configurer le compte de destination
  • Mettre en maintenance le site web dans le datacentre de Paris pour éviter le split brain
  • Migrer toutes les données : fichiers du code source, ainsi que les bases de données
  • Modifier le code source avec les nouveaux identifiants de bases de données
  • Vérifier le bon fonctionnement de leur site web
  • Modifier leur zone DNS afin de rediriger leur site web vers la nouvelle adresse IP du nouveau cluster de Gravelines
  • Ré-ouvrir le site et attendre la fin du délai de propagation DNS.

Nous avons envisagé d’industrialiser cette technique pour le faire au nom du client. Mais nous avons été confrontés à plusieurs soucis techniques :

  • L’identification fiable de toutes les bases de données utilisées est complexe. Il est possible de rechercher tous les noms des bases de données dans le code source de nos clients. Mais cette opération est très longue, et n’est fiable que si le code source ne change pas pendant ce temps.
    Elle nécessite aussi de traiter de nombreux cas particuliers : fichiers binaires exécutés en CGI, obfuscation du code source, voire stockage du nom des bases de données dans… des bases de données. Cette technique ne nous permet pas d’envisager une fiabilité à 100% de notre migration.
  • La migration des fichiers peut se faire suivant deux techniques :
    1. En mode « fichier », le script de migration parcourt l’arborescence des fichiers et les copie un par un.
    2. En mode « bloc », le script de migration prend les données du disque dur et les transfère bit à bit sur le disque dur de destination sans prendre en compte l’arborescence.

Les deux méthodes permettent de copier les données de manière fiable.

Seulement, la copie en mode « bloc » ne peut se faire que sur un disque entier ou une partition de ce disque. Les données de plusieurs sites web se trouvant sur un même filerz, seul le mode « fichier » permet de migrer les données d’un seul site web.
Le déplacement des données en mode « fichier » est très lent si le nombre de fichiers à parcourir est important. Ce qui est le cas de nombreux frameworks PHP effectuant du cache. Nous avions donc le risque d’être dans l’impossibilité de migrer certains sites.

  • Modifier le code source est une opération périlleuse que nous ne nous permettons pas de réaliser car l’impact sur le site web peut être important. De plus, elle nécessite d’avoir identifié de manière exhaustive toutes les utilisations des bases de données…
  • Un certain nombre de nos clients n’hébergent pas leur zone DNS chez nous. Nous sommes alors dans l’incapacité de modifier l’adresse IP de leur site web sans leur intervention, ce qui nous oblige à conserver cette adresse IP si nous souhaitons atteindre un bon niveau de fiabilité pour la migration.

Nous avons donc décliné ce scénario. Bien que fonctionnel pour une très grande majorité des sites web, le faible pourcentage de sites qui aurait été impacté représente en réalité un volume trop important de sites web. Nous aurions dû les réparer manuellement et notre équipe y aurait consacré tout son temps.

IP over Truck Carriers

Internet se base sur le protocole IP pour l’adressage des machines au travers du réseau. Il n’est  pas dépendant du matériel physique sur lequel s’échange le message, il est possible d’en utiliser de nombreux : liens optiques, électriques, sans fil ; voire pigeons voyageur s, comme décrit par une norme humoristique définie le 1er avril 1990 !

Cette RFC humoristique nous a inspirésn bien que nous ne sommes pas experts en pigeons. En effet, bien que la latence (durée pour qu’un message aille du point A au point B) soit importante, la bande passante (quantité d’information envoyée / temps de trajet) est potentiellement énorme : une clé USB contient beaucoup de données ! Dans certains transferts volumineux, il n’est pas idiot de réfléchir à déplacer physiquement les données afin d’augmenter la bande passante d’un transfert.

Nous avons donc réfléchi à l’option de déplacer simplement l’infrastructure de Paris à Gravelines. Celle-ci comporte des avantages :

  • aucun impact sur les sites web. Nous devons simplement rallumer l’infrastructure dans un autre centre de données et rediriger le trafic dessus ;
  • elle permet de vider très rapidement le centre de données.

Nais elle pose aussi quelques défis :

  • Comment réduire le temps de coupure des sites web entre l’arrêt des machines à Paris, leur chargement, leur transport, leur déchargement et leur ré-allumage ? Le temps de coupure serait de l’ordre de plusieurs jours.
  • Que faire en cas d’accident sur le trajet ? Serveur qui tombe, accident de la route…
  • Comment s’assurer que les données ne seront pas altérées durant le transport à cause des vibrations des camions ?
  • Comment intégrer cette infrastructure ne respectant pas les normes d’industrialisation en vigueur à Gravelines ?

Aucun point absolument bloquant mais des défis intéressants. Nous avons donc conservé ce scénario, bien que n’étant pas notre premier choix en raison des risques physiques et du fort temps d’indisponibilité des sites web durant l’opération.

Migrations échelonnées

Ne pouvant pas migrer tout le datacentre d’un seul coup, ni les sites web de manière indépendante, nous avons recherché comment permettre la migration de nos éléments d’infrastructure au fur et à mesure.

Nous avons donc pris un peu de recul et recherché les niveaux de granularité de notre infrastructure, c’est-à-dire les éléments qui lient les sites web entre eux et qui empêchent une migration site par site :

  • Les adresses IP : n’ayant pas la main sur l’intégralité des zones DNS, nous avons considéré que les adresses IP des sites web de nos clients ne pouvaient pas être modifiées. Cela signifie que nous devons migrer tous les sites web utilisant une même adresse IP d’un coup.
  • Les filerz : la migration en mode « fichier » des données sur les filerz n’étant pas envisageable à cause du nombre trop important de fichiers, nous devons effectuer une migration en mode « bloc » et donc migrer tous les clients d’un même filerz simultanément.
  • Les bases de données : toutes les bases de données d’un même site web doivent être migrées au même moment pour que le site continue de fonctionner, et les identifiants de bases de données ne doivent pas changer. Ces bases de données peuvent potentiellement être utilisées par deux hébergements différents, y compris sur des clusters différents ; ces hébergements doivent être migrés en même temps.

Si l’on considère l’ensemble de ces postulats, une seule conclusion s’impose : pour les respecter, nous devons migrer tous les sites d’un coup à cause des interdépendances.

Nous étions dans une situation de blocage. Pour avancer, il a fallu que l’on revoi chaque postulat, et que l’on envisage des solutions afin de passer outre ces problèmes.

Casser les dépendances aux bases de données

L’une des contraintes les plus complexes est de migrer les bases de données en même temps que les sites web, de manière fiable.

Pouvons-nous imaginer une migration fiable à 95%, en prenant en compte uniquement les bases de données fournies avec l’hébergement ? C’est-à-dire en laissant de côté les cas atypiques qui ne se trouvent qu’en analysant le code source des sites web.

Bien sûr, ce n’est pas possible, car les sites web seraient impactés, puisque les bases de données ne seraient plus disponibles.

C’est donc sur la disponibilité des bases de données que nous devons jouer : si nous arrivons à conserver une base de données accessible bien qu’elle ne soit pas migrée, nous pouvons supprimer cette contrainte. Les cas atypique continueront de fonctionner.

C’est techniquement possible si nous ouvrons un tunnel réseau entre notre datacentre de Gravelines et celui de Paris. Avec ce tunnel, un site web utilisant une base de données qui n’est pas référencée dans son hébergement continuerait de fonctionner en allant chercher les données à Paris.

Ce n’est pas la solution idéale : ajouter un tunnel réseau signifie que l’on ajoute une latence de 10ms. Et sur certains CMS du marché effectuant des dizaines de requêtes SQL de manière séquentielle, cela se ressent vite. Mais en limitant cet effet aux seules bases de données non-référencées, nous réduisons une contrainte forte. 100% des sites continueront de fonctionner. Certains pourrons ressentir quelques lenteurs, mais dans les cas d’usage usuel de nos hébergements, pas de répercutions.

Contourner la dépendance aux adresses IP

Derrière une même adresse IP se trouvent plusieurs centaines de milliers de sites web. Migrer l’ensemble des filerz et des bases de données impliquerait donc un temps de coupure très important.

Cependant, la question peut être tournée autrement : comment faire pour que le trafic d’une même adresse IP soit distribué dans le bon datacentre en fonction du site web ? C’est un souci de load balancing et nous avons déjà un load balancer qui s’adapte en fonction du site web demandé : le predictor.

Il est possible de définir au sein du predictor où se situe réellement le site web pour rediriger le trafic. Ajouter un nouveau predictor en amont de nos infrastructures est le plus simple. Mais le chaînage de load balancers n’est pas une bonne idée : il complexifie le chemin pour arriver au site web et ajoute un nouvel élément critique dans l’infrastructure.

Et finalement, rien ne nous empêche d’utiliser le load balancing de Paris ou de Gravelines pour effectuer cette redirection de trafic.

Nous avons sélectionné le predictor de nos nouveaux clusters de Gravelines. Nous y avons ajouté la liste des sites web et leur état : « migré » ou « non migré ». Ainsi, pour les sites migrés, le trafic est distribué localement. Dans le cas contraire, le trafic est redirigé sur  un load balancer du cluster à Paris.

Nous savons migrer une adresse IP entre nos datacenters. Il est donc possible de préparer ces nouveaux predictors puis de migrer les adresses IP de tout un cluster de manière transparente, sans provoquer de coupure client.

Les adresses IP ne sont plus un point bloquant. En cassant cette contrainte, nous pouvons désormais migrer les clients filerz par filerz. Peut-on faire encore mieux ?

Faire bloc avec les filerz

La question logique à la suite de tout cela est comment décorréler les clients de chaque filerz ?

La migration d’un filerz entier prend du temps. Il s’agit de transférer plusieurs To de données au travers de notre réseau et cela prend des dizaines d’heures. Pour éviter le split brain, il faut par ailleurs éviter les écritures à la source durant la copie.

Mais notre équipe « Storage » sait gérer ce type de cas qui est fréquent pour eux. Ils réalisent tout d’abord une première copie de toutes les données, sans fermer le service source. Une fois cette première copie réalisée, ils synchronizent uniquement les différences écrites depuis la première copie. Et ainsi de suite jusqu’à ce que le temps de copie soit très réduit.

Une fois qu’il est suffisamment faible, il est envisageable de couper le service durant quelques heures, de nuit, pour effectuer la migration sans split brain. Tout en migrant les bases associées en même temps.

Nous avons désormais tous les éléments pour réaliser un nouveau scénario de migration !
Allez, on recommence :

Notre scénario final :

En reprenant ce que nous venons de décrire, vous avez probablement déjà une bonne idée de notre manière de migrer les clusters. Voici les principales étapes :

1/ Construction d’un nouveau cluster à Gravelines, aux normes de ce nouveau datacenter mais comprenant autant de filerz et de bases de données que le précédent.

2/ Construction d’un lien réseau entre le nouveau et l’ancien datacenter.

3/ Migration du trafic IP sur le nouveau cluster avec redirection vers Paris pour les sites non migrés.

4/ Copie des données sans coupure des sites web.

5/ De nuit : coupure des sites du premier filerz, migration de ses données et des bases de données associées.

6/ De nuit : coupure des sites, migration du second filerz et des bases de données associées.

7/ Fermeture du cluster source.

 

À la fin de la migration de tous les filerz d’un cluster, nous ne pouvons pas détruire le lien réseau vers Paris tant que toutes les bases de données n’ont pas été migrées. Il le sera à la toute fin de la migration. Il faut donc que ce lien soit pérenne et monitoré durant plusieurs mois.

Ce scénario a été validé en juillet 2018. Pour le rendre opérationnel, il nous a fallu 5 mois d’adaptation de nos systèmes, ainsi que de multiples répétitions à blanc sur un cluster de test spécifiquement déployé pour vérifier le bon fonctionnement de l’ensemble. Car bien que ce scénario soit beau sur le papier, nous avons dû résoudre de nombreux problèmes sur l’ensemble des maillons de la chaîne. Nous rentrerons dans les détails techniques dans d’autres articles dédiés à cette migration.

Pour chaque point de ce scénario, il s’agit en réalité de dizaines d’opérations synchronisées entre les différentes équipes. Nous avons dû mettre en place un suivi très précis de nos opérations afin que tout se déroule au mieux au milieu de la nuit. Nous en parlerons aussi.

Vous connaissez désormais notre scénario de migration. Cet article, bien que long, est nécessaire pour comprendre les choix d’architecture, et les surprises que nous avons rencontrées durant  notre migration.

Dans les prochains articles, nous nous focaliserons sur des points précis de notre migration et des défis techniques que nous avons rencontrés.

À bientôt pour la suite de nos aventures !

Engineering manager on webhosting