Hébergement web : pourquoi avons-nous décidé de migrer 3 millions de sites web ?

Temps de lecture estimé : 15 minute(s)

Avez-vous déjà migré un site web ? Ceux qui l’ont déjà fait, ou qui doivent le faire régulièrement, connaissent les difficultés de ce type d’opération.

Pour vulgariser à l’extrême, cette opération nécessite généralement six étapes :

  • achat et configuration de l’infrastructure de destination ;
  • test de cette nouvelle infrastructure en important les données et le code du site web ;
  • fermeture ou mise en lecture seule du site web pour éviter que des données soient enregistrées sur l’ancienne infrastructure durant la migration ;
  • déploiement du code sur la nouvelle infrastructure, import des données dans les nouvelles bases de données ;
  • modification du code source afin de l’adapter à la nouvelle infrastructure (identifiants de base de données, connexion aux API externes, etc.) ;
  • une fois le site web fonctionnel sur la nouvelle infrastructure, redirection du trafic pour rendre le site de nouveau disponible (modification des zones DNS, mise à jour des back end des load balancer…).

En fonction du code source du site web et de la complexité de l’infrastructure, ces différentes étapes peuvent varier et être plus ou moins complexes. Elles dépendent en réalité des accès en écriture de données effectués par votre site. Faut-il stocker des données dans une base de données ? Votre site comporte-t-il un cache basé sur des fichiers locaux ? Tout ceci est défini dans le code source de vos pages web.

Web hosting: migrating 3 million websites

Il y a tout juste un an, en mars 2018, OVH a lancé un projet d’ampleur : migrer l’ensemble de ses clients webhosting et e-mails hébergés dans son datacenter historique de Paris vers un autre centre de données. Pour organiser le travail, la migration a été décomposée en deux parties gérées par deux équipes distinctes : les hébergements web pour la première équipe, et les e-mails pour la seconde. Aujourd’hui, nous nous focalisons sur la migration des hébergements web, mais l’équipe en charge des e-mails aura aussi de quoi alimenter notre blog technique.

Coté webhosting, ce projet concerne trois millions de sites web différents, hébergés sur nos 7 000 serveurs de Paris. Certains de ces sites sont en fonctionnement depuis 1999 ! C’est l’une des activités les plus anciennes d’OVH. Mais pourquoi les migrer alors qu’ils fonctionnent parfaitement à Paris depuis près de 20 ans ? Pour comprendre tous les enjeux, il faut revenir en quelques lignes sur l’historique de ce service.

Histoire de notre plateforme d’hébergement web

Quand Octave a créé OVH en 1999, alors que l’accès à Internet était encore confidentiel, la première activité de l’entreprise a été l’hébergement des sites Internet. Ce qui nous semble simple aujourd’hui ne l’était pas autant à l’époque. Il fallait bénéficier d’une bonne connexion au réseau, maintenir en fonctionnement des serveurs web, et bien les configurer. Peu de personnes possédaient alors les connaissances et les moyens techniques pour réaliser cela.

Construction et croissance de P19

Au début des années 2000, une opportunité permet à OVH d’acquérir un bâtiment dans le 19ème arrondissement de Paris. Bénéficiant de bons accès aux réseaux électriques et Internet, ce bâtiment, nommé P19, permet aux hébergements web et e-mails d’accueillir de très nombreux clients. Il restera quelque temps le seul datacenter d’OVH.

L’hébergement web n’était pas la seule activité d’OVH à P19. Le datacenter accueillait aussi de l’hébergement de serveurs dédiés. Ces deux activités ont connu une forte croissance et à la fin des années 2000, OVH a entrepris la construction de nombreux nouveaux datacenters : Roubaix, puis Strasbourg, Beauharnois (Canada), Gravelines…

L’expérience acquise dans la construction de chaque nouveau datacenter nous a permis d’améliorer la logistique et la maintenance des suivants. Ces nouveaux espaces, bien plus grands que nos locaux parisiens, nous ont permis d’accélérer de nombreuses innovations : watercooling, chaîne de production de nos propres serveurs et baies, refroidissement de nos salles serveurs sans climatisation…

Évolution du web de 1999 à nos jours

Le Web a énormément évolué depuis 1999. De notre point de vue d’hébergeur, nous avons observé trois évolutions au cours du temps.

  • 1999 -> 2005 : naissance du Web. Mise en place de sites statiques en HTML. C’était le temps de l’émergence des blogs. Cette technologie restait cependant réservée aux initiés sachant manier le HTML et les clients FTP, bien que FrontPage ait aidé de nombreuses personnes à se lancer.
    Pour fonctionner, ces sites incluent les données directement dans le code. Leur hébergement est assez simple : un espace de stockage et un serveur web dont la seule action est d’envoyer la page web qu’il va chercher dans l’espace de stockage.
  • 2006 -> 2013 : le web 2.0, la révolution des réseaux sociaux et des bases de données. Les sites deviennent dynamiques et permettent d’afficher des pages personnalisées en fonction des utilisateurs. C’est d’abord l’heure des forums de discussion, des plateformes de blogs, puis arrive l’émergence des réseaux sociaux toujours très présent aujourd’hui.
    Les sites dynamiques ont été une révolution pour les hébergeurs web : le code et les données sont désormais stockés dans deux endroits distincts. Ce qui signifie qu’il faut générer la page avant de l’envoyer à l’internaute. Le rôle du serveur web change pour générer ces pages à la volée, principalement avec le langage PHP. Pour ces sites, il faut donc ajouter des serveurs de bases de données, ainsi que de la puissance de calcul pour les serveurs web.
  •  2014 à nos jours : la montée en puissance du JavaScript a permis aux développeurs de construire de véritables applications web dans les navigateurs, améliorant sensiblement l’expérience des utilisateurs de sites web. Ce changement a été rendu possible avec le déploiement d’Internet sur nos smartphones. De très nombreux services, nécessitant un accès au Web, ont donc pu être lancés.
    Techniquement, cela signifie que les usages changent et que les utilisateurs visitent plus souvent les sites web, augmentant de fait la quantité de données créées et la complexité de leur traitement. La consommation d’espace disque et de ressources pour générer les pages web a continué d’augmenter.

Nos offres se sont adaptées très rapidement à tous ces changements. Nous avons proposé de nouvelles bases de données, augmenté nos espaces de stockage, fourni des services de CDN, etc.

Mais la forte croissance en nombre d’utilisateurs, et en ressources de nos hébergements web, allaient remplir notre datacenter. Entre la croissance naturelle du service et les besoins plus importants des sites web que nous hébergeons, nous avons observé en 2015 que Paris serait plein au début de l’année 2017.

Déploiement des hébergements web à Gravelines

Ce constat engage une seule conclusion : pour éviter d’être en pénurie d’hébergements web, nous devons héberger nos sites web dans un autre datacenter. Nous avons bâti une industrialisation de nos services à Paris afin de livrer 24h/24 des hébergements, de gérer nos 7 000 serveurs et de les maintenir en condition opérationnelle, basés sur les premières technologies d’OVH.

Nous aurions pu choisir de reprendre cette industrialisation et l’appliquer à Gravelines. Cependant, nous avons fait un autre choix ! Reconstruire une nouvelle architecture technique, permettant de supporter de plus grands besoins en performance, et surtout, de réutiliser nos autres produits OVH. Le fameux « Eat your own dog food » porté à l’échelle de nos hébergements web.

Nous avons challengé les équipes afin que la gestion des serveurs dédiés, du vRack (réseau privé), des adresses IP, des load balancers (IPLB) soient en capacité de tenir l’infrastructure et le trafic de nos clients. En devenant nous-même l’un de nos plus gros clients, nous avons été en capacité d’identifier de très nombreuses limites et de les surmonter : amélioration de la vitesse de réponse de nos API, optimisation de nos bases de données…

Pour minimiser les latences, et pour des besoins de répartition géographique, nous proposons à nos clients un vaste choix de datacentres tout autour du monde. Tous ces datacentres étaient des cibles potentielles pour la croissance de notre plateforme. Pour des raisons logistiques, nous avons fait le choix de lancer un seul nouveau datacentre en Europe. Et cela n’a pas d’impact pour nos sites web :les différences de latences entre nos datacentres sont si faibles qu’elles ne se ressentent pas sur les sites web hébergés (le gain est de l’ordre de quelques millisecondes et il en faut quelques centaines pour générer des pages web).

Pour choisir notre nouveau datacentre, nous avons analysé notre croissance naturelle pour obtenir nos besoins d’infrastructure. Dans les faits, notre infrastructure s’agrandit chaque semaine avec de nouvelles livraisons de matériel et nous avions un risque de privatiser certains datacentres en les remplissant rapidement, empêchant nos clients d’y louer des serveurs dédiés ou d’autres services de OVH. Sur ces critères, seulement deux datacentres répondaient à nos besoins d’infrastructure en 2016 : Gravelines, dans le Nord de la France, et Beauharnois au Canada. Notre plateforme n’étant déployée qu’en Europe actuellement, nous avons lancé notre chantier sur Gravelines.

Dans le même temps, nous avons revu et optimisé le matériel utilisé pour construire nos clusters afin de fournir de meilleures performances. Les innovations introduites à Gravelines nous ont simplement permis d’améliorer encore plus la disponibilité de notre plateforme.

La plus grosse difficulté fut de ne pas changer l’expérience du service : nous avons gardé l’ensemble des fonctionnalités ! Gardé l’ensemble des interfaces graphique et des API ! L’objectif était simplement de renouveler l’infrastructure, et non les offres commerciales.

Ce datacenter, pour l’hébergement de sites web, nous l’avons inauguré en juillet 2016. Et depuis le mois de novembre de cette même année, tous les nouveaux hébergements y sont livrés.

Tous les ans, des clients résilient leurs hébergement web car ils ne les utilisent plus ou migrent vers d’autres produits, les VPS par exemple. Ainsi, depuis trois ans, le nombre de sites web hébergés diminue progressivement à Paris. Ce qui nous a permis de faire face à l’augmentation de puissance nécessaire pour les sites web restants, sans augmenter la capacité de nos infrastructures parisiennes.

Vu la décroissance naturelle du datacenter, nous pourrions très bien attendre qu’une majorité de clients résilient au fil du temps avant de le migrer. Pourquoi le faire alors qu’il y reste trois millions de sites web ?

Pourquoi diable avons-nous choisi de migrer notre datacenter ?

Rajeunir Paris ?

Il y a plusieurs raisons d’initier ce chantier titanesque. Mais la principale raison est la gestion de l’obsolescence.

Notre infrastructure repose sur des ressources physiques, hébergées dans ce datacenter : des serveurs dédiés et virtualisés (eux-mêmes reposant sur des machines physiques), des éléments du réseau, un circuit de refroidissement (watercooling et climatisation). Et pour que l’infrastructure reste disponible 24 h/24 et 7 j/7, nous devons renouveler ce matériel périodiquement.

Concernant les serveurs dédiés, c’est assez simple. Si un serveur tombe en panne, il suffit de le remplacer par un nouveau. Les serveurs construits pour Paris ne bénéficient pas des améliorations techniques et logistiques de nos autres datacenters et deviennent de plus en plus difficiles à assembler alors que l’obsolescence de notre centre de données nous impose d’en renouveler de plus en plus.

Nous avons envisagé de remplacer ces serveurs par des modèles de dernière génération, mais ils nécessitent de modifier l’architecture de salles entières. Et pour le réaliser sans impact sur la disponibilité de notre plateforme, nous devons avoir à disposition de la place pour construire de nouvelles salles avant de basculer les serveurs un par un. Dans un bâtiment qui arrive presque à ses limites, cela nécessite de vider des salles.

Les serveurs dédiés ont également besoin d’électricité, de réseau et de systèmes de refroidissement pour fonctionner. Tous ces éléments sont aussi gérés par du matériel physique : climatisation et refroidissement liquide pour le froid, routeurs et switchs pour le réseau, transformateurs électriques, onduleurs et batteries pour l’électricité.

Ces infrastructures physiques redondées doivent aussi être remplacées régulièrement afin d’éviter toute panne. Si une voie d’accès tombe en panne, la seconde prend le relais. C’est d’ailleurs une opération courante afin de procéder à de petites maintenances sur ces matériels.

Le remplacement pur et simple de ces infrastructures par des neuves est une opération complexe et longue. Il n’est pas envisageable de ne tourner que sur l’une des voies d’accès durant autant de temps. Leur remplacement nécessite alors d’installer une troisième voie, puis de basculer dessus lorsque tout est prêt. Cependant, cela signifie aussi qu’il faut de la place dans le datacenter pour toutes ces opérations.

Au bout de vingt ans, notre centre de données parisien est arrivé à la fin d’un cycle. Il faut donc engager de gros travaux à tous les niveaux, ces derniers nécessitant de la place. C’est la principale raison ayant déclenché cette migration.

Augmenter la performance des sites web

La nouvelle infrastructure de Gravelines nous permet de fournir de meilleures performances aux sites web de nos clients. En outre, ces nouvelles technologies nous ont permis de déployer quelques fonctionnalité supplémentaires que nous ne pouvons pas déployer à Paris sans le renouvellement de nos infrastructures : HTTP/2, MySQL 5.6…

Nos clients peuvent bien entendu migrer par eux-mêmes, mais cela nécessite de réaliser une opération difficile et délicate de migration d’hébergement web. De nombreux clients y ont renoncé.

Lorsque la migration sera terminée, nous serons aussi en capacité de simplifier notre maintenance opérationnelle en n’utilisant que des standards d’OVH. Cela permettra d’éviter de réaliser des opérations spécifiques à Paris, réduisant le temps des maintenances et les risques de certaines opérations manuelles récurrentes au datacenter parisien.

Comment migrer autant de sites web ?

Notre métier d’hébergeur web se résume principalement à deux choses : héberger des données et exécuter du code.

L’hébergement des données est une opération complexe afin de conserver leur intégrité dans le temps, mais c’est un secteur relativement normé. Les données sont stockées sur un système de fichiers (c’est une norme) ou bien dans une base de données respectant un langage précis de requête (MySQL 5.5 ou MySQL 5.6). Il suffit donc de reproduire une architecture respectant la même norme sur l’infrastructure de destination et d’y migrer les données.

L’exécution de code est plus complexe. En effet, il est très difficile d’inférer le comportement d’un code source dans son environnement sans l’interpréter au minimum. Il peut tomber en erreur sur une version précise d’une extension de PHP, vérifier l’existence d’un dossier local… Nous avons par exemple de nombreux clients qui stockent dans le code le chemin absolu menant à leurs fichiers. Cependant, cela implique que nous ne pouvons pas modifier l’emplacement de stockage des fichiers sans affecter leur service.

Lorsqu’on héberge quelques clients, on peut facilement les accompagner en détectant les codes qui ne fonctionneront plus après migration. Mais cela passe difficilement à l’échelle. Imaginez-nous, face aux codes de plus de trois millions de sites web !

Demander à nos clients de modifier leur code source n’était pas une solution acceptable. En imaginant que l’ensemble de nos clients aient lu leurs e-mails, un certain nombre n’aurait pas effectué les changements par manque de temps, de connaissance, ou simplement par oubli. Nous aurions mis nos clients en difficulté face à leur site web, et nous ne pouvons pas l’imaginer.

Durant près d’un an, nous avons imaginé plusieurs scénarios de migrations. Nous les avons extrapolés dans tous les sens avec deux objectifs :

  • que les sites web soient toujours fonctionnels après la migration, sans aucun changement à réaliser dans le code de nos clients ;
  • en réduisant au maximum l’impact sur la disponibilité du service durant la migration.

Nous avons implémenté et testé certains de ces scénarios entre mars et juin 2018. Ces travaux initiaux nous ont permis de choisir le meilleur plan de migration. Pour réaliser cette migration sans affecter les services, nous avons dû adapter une partie de notre infrastructure et de notre système d’information : création d’un tunnel réseau inter-datacenters, modifications des load balancers, de notre plateforme de bases de données, ajout de serveurs proxy SQL…

Nous avons beaucoup testé le scénario retenu. Pour nous assurer que cette procédure est effectuée avec le moins d’impacts possibles, nous l’avons répétée à de très nombreuses reprises, en conditions réelles sur des clusters internes, en utilisant des jeux de données inspirés des plateformes de production.

Vous rêvez de connaître les détails de notre plan de migration ? Ils ne rentrent pas tous dans cet article de blog et nous avons décidé de vous parler de notre migration dans une série d’articles, car le sujet est vaste.

À bientôt pour les prochains articles décrivant les coulisses de la plus grosse migration de sites web du plus gros hébergeur européen !

Engineering manager on webhosting