En 2018, nous avons lancé l'un des plus grands projets de l'histoire d'OVH: la migration des 3 millions de sites web hébergés dans notre centre de données de Paris. Si vous souhaitez découvrir les raisons qui sous-tendent ce projet titanesque, nous les avons examinées dans cet article.Il est maintenant temps d'expliquer comment nous avons procédé à ce projet. Nous avons déjà parlé de nos contraintes opérationnelles, comme nous assurer de n'avoir aucun impact sur les sites Web, même si nous ne contrôlons pas le code source, et limiter le temps d'arrêt. Nous avions aussi de nombreuses contraintes techniques, liées à l'architecture de nos services. Nous reviendrons sur nos différents scénarios de migration dans le prochain article, mais aujourd'hui, nous allons vous expliquer comment fonctionne l'infrastructure qui héberge vos sites web.L'anatomie de l'hébergement webPour fonctionner, les sites web et les applications web ont généralement besoin de deux choses :
Le code source, responsable de l'exécution du comportement du site webLes données utilisées par le code source pour personnaliser l’expériencePour qu'un site soit opérationnel, le code source est exécuté sur un ou plusieurs serveurs dont l'environnement a été configuré avec les outils associés aux langages de programmation utilisées. Le PHP domine actuellement le marché, mais le choix n'est pas limité à ce langage.Pour rester en état de fonctionnement, ces serveurs doivent être entretenus et mis à jour, et leur fonctionnement doit être surveillé en continu. Ce rôle est généralement différent de celui des développeurs, qui sont responsables de la création du code source du site Web. Si vous êtes intéressé par ces rôles, nous vous recommandons d'en savoir plus sur les administrateurs système et DevOps, et sur leurs compétences spécifiques.Pour un propriétaire de site web, surveiller l'infrastructure et son fonctionnement peut être très coûteux : vous devez disposer d'une équipe suffisamment grande pour maintenir une présence 24 heures sur 24, 365 jours par an. Avec une telle équipe, les développeurs ne peuvent compter que sur les demandes de service ponctuelles lorsque le propriétaire du site Web souhaite apporter des modifications.C'est ce niveau de gestion que nous vous proposons à travers notre solution d'hébergement. Au lieu de recruter une équipe d'administrateurs système pour chaque site web, nous avons recruté une équipe d'experts techniques qui s'occupent de tous les sites web que nous hébergeons. Il en va de même pour les données, stockées sur des serveurs dédiés, et exploitées par ces mêmes équipes d'experts.De cette manière, chaque site web n'a pas besoin d'utiliser les ressources d'un serveur entier. Avec nos solutions, nous mettons en commun les ressources de nos infrastructures, de sorte que des serveurs individuels puissent héberger plusieurs sites Web simultanément.Toutes ces économies d'échelle nous permettent d'offrir une solution d'hébergement web à bas prix (à partir de 1,49 € / mois), tout en maintenant un haut niveau de qualité. Nous expliquerons très prochainement comment nous calculons notre qualité de service, mais si vous ne voulez pas attendre, regardez la conférence que nos développeurs ont organisée au FOSDEM 2019.Pour atteindre le niveau de qualité requis tout en gérant autant de sites web, nous avons adapté notre infrastructure.L'architecture technique de nos solutions d'hébergement webL'approche classique de la construction d'un service d'hébergement web consiste à installer un serveur, à configurer les bases de données et un environnement d'exécution du code source, puis à y placer de nouveaux clients jusqu'à ce que le serveur soit rempli, avant de passer au serveur suivant.C'est très efficace, mais il y a quelques inconvénients avec ce type d'architecture :En cas de panne, le redressement peut être long. À moins d'avoir une réplication du système en temps réel, ce qui est très coûteux, vous devez récupérer vos données à partir de la sauvegarde et les migrer ensuite vers une nouvelle machine avant de rouvrir le service aux clients. Bien que la probabilité d'une panne matérielle ou logicielle soit faible, il s'agit d'une opération courante sur les grandes infrastructures.Pour gérer les nouvelles technologies, il serait préférable de ne les introduire que sur de nouveaux serveurs lors de la première phase, puis de prendre le temps de les déployer progressivement sur les serveurs existants lors des phases ultérieures.Cependant, dans un marché aussi changeant que celui d'Internet, il devient difficile de maintenir une infrastructure hétérogène. Les équipes techniques doivent alors s'adapter et travailler avec de multiples configurations différentes, ce qui augmente le risque de régressions ou de pannes. Et pour les équipes de support, il devient très difficile de mémoriser toutes les différentes configurations et de suivre les changements en cours.Chaque brique logicielle est par nature complexe, de sorte que pour atteindre la meilleure performance et la meilleure qualité de service, nous avons créé des équipes spécialisées dans chaque technologie: base de données, environnement PHP, systèmes de stockage, réseau... Avoir toutes ces équipes interagir sur le même serveur peut être difficile et entraîner des malentendus sur la disponibilité des sites web.Il est difficile d’isoler un client qui consomme plus de ressources que la moyenne. Si vous êtes chanceux, vous ne serez pas sur le même serveur que ce client, mais si c'est le cas, la performance de votre site Web peut souffrir en raison de la consommation de ressources de ce dernier.
Comme vous pouvez le voir, à notre échelle, nous avons choisi d'adopter une approche différente, sous la forme d'un modèle bien connu pour les applications devant gérer la charge: une architecture n-tier.
Architecture N-tierLes sites à forte charge peuvent tirer parti des architectures n-tier pour fournir plus de ressources à chaque brique logicielle en les répartissant sur plusieurs serveurs. Si nous allons plus loin dans notre division code/données, nous avons donc besoin de trois serveurs pour faire fonctionner un site web :
- Un serveur responsable de l’exécution du code source
- Deux serveurs de stockage fréquemment utilisés : un serveur de base de données et un serveur de fichiershe data used by the source code to customise the experience
For a site to be operational, the source code is run on one or more servers whose environment has been configured with the tools related to the programming languages used. PHP currently dominates the market, but the choice is not limited to this language.
To remain in operational condition, these servers must be maintained and updated, and their operation must be continuously monitored. This role is usually different to that of developers, who are responsible for creating the source code of the website. If you're interested in these roles, we'd recommend learning more about system administrators and DevOps, and their specific skills.
For a website owner, monitoring the infrastructure and its operations can be very expensive: you need to have a team large enough to maintain a presence 24 hours a day, 365 days a year. With such a team, developers can only rely on one-off service requests when the website owner wants to make changes.
It is this level of management that we offer through our web hosting solution. Instead of recruiting a system administrator team for each website, we have recruited a team of technical experts who take care of all the websites we host. The same goes for the data, which is stored in specific servers, and operated by those same teams of experts.
This way, each website does not need to utilise the resources of an entire server. With our solutions, we pool resources on our infrastructures, so individual servers can be used to run several websites at once.
All of these economies of scale allow us to offer a low-cost web hosting solution (from €1.49/month), while maintaining a high level of quality. We will explain very shortly how we calculate our quality of service, but if you do not want to wait, watch the conference that our developers hosted at the FOSDEM 2019.
To reach the required level of quality while managing so many websites, we have adapted our infrastructure.
The technical architecture of our web hosting solutions
The classic approach to building a web hosting service is to install a server, configure the databases and a source code execution environment, and then place new clients there until the server is full, before moving on to the next server.
This is very effective, but there are some disadvantages with this type of architecture:
- In the event of breakdown, the recovery can be long. Unless you have real-time system replication, which is very expensive, you have to recover your data from the backup and then migrate it to a new machine before reopening the service to the clients. Although the probability of hardware or software failure is low, this is a common operation on large infrastructures.
- To deal with new technologies, it would be preferable to only introduce them on new servers during the first phase, and then take the time to progressively deploy them on existing servers in future phases.
However, in a market as fast-moving as the internet, it becomes difficult to maintain a heterogeneous infrastructure. Technical teams must then adapt, and work with multiple different configurations, increasing the risk of regression or breakdown. And for support teams, it becomes very difficult to memorise all the different configurations and keep track of the ongoing changes. - Each software brick is inherently complex, so to achieve the best performance and quality of service, we have created teams that specialise in each technology: database, PHP environment, storage systems, network... Having all these teams interact on the same server can be difficult, and lead to misunderstandings regarding the availability of websites.
- It is difficult to isolate a customer who consumes more resources than the average. If you're lucky, you won't be on the same server as this customer, but if you are, the performance of your website may suffer as a result of their resource consumption.
As you can see, at our scale, we chose to take a different approach, in the form of a well-known pattern for applications that must deal with the load: an n-tier architecture.
N-tier architecture
High-load sites can leverage n-tier architectures to provide more resources for each software brick by distributing them across several servers. If we go further with our code/data division, we therefore need three servers for running a website:
- A server responsible for the execution of the source code
- Two frequently-used storage servers: a database server and a file server
Serveurs de fichiers : Filerz
Ce sont les serveurs sur lesquels nous stockons les fichiers qui composent le site web (généralement le code source du site web). Ils sont équipés d’un matériel spécifique pour assurer un accès rapide aux données et une durabilité. Nous utilisons également un système de fichiers spécialisé appelé ZFS, qui nous permet de manipuler facilement les sauvegardes locales et distantes.Ils sont gérés par une équipe Storage dédiée, qui propose également ce type de service à plusieurs autres équipes chez OVH (hébergement web, emails...). Si cela vous intéresse, ils proposent également NAS-HA
, que vous trouverez dans le catalogue public de nos serveurs dédiés.En cas de panne, nous gardons un stock de pièces et de serveurs facilement disponibles, pour restaurer le service aussi rapidement que possible.Serveur de base de donnéesLes serveurs de bases de données sont généralement utilisés par les sites Web pour héberger dynamiquement les données du site. Ils utilisent un système de gestion de base de données (SGBD) (MySQL avec nos solutions) qui structure les données et les rend accessibles via un langage de requête (SQL dans notre cas).Ces serveurs nécessitent également du matériel spécifique pour le stockage des données, notamment une grande quantité de RAM, afin de tirer parti des systèmes de cache SGBD et de répondre plus rapidement aux requêtes de recherche.Ces machines sont gérées par une équipe base de données dédiée, qui est responsable de cette infrastructure. L'équipe Base de données propose ces services au public via l'offre
CloudDB
, et gère également le SQL privé.
À Paris, ces serveurs sont hébergés sur un Private Cloud (SDDC), qui nous permet de basculer des machines virtuelles d'un serveur physique à un autre en cas de problème. Cela permet de réduire les temps d'arrêt pendant la maintenance et les temps de récupération en cas de panne.
Serveurs web
Ce sont les serveurs qui reçoivent les requêtes et exécutent le code source du site web. Ils obtiennent leurs données à partir des fichiers et des bases de données fournies par les serveurs Filerz et de bases de données précédemment décrits. La principale exigence pour ces serveurs est de disposer de bonnes ressources CPU, nécessaires à l'exécution du code source.Ces serveurs web étant sans état (c'est-à-dire qu'ils ne stockent pas de données localement), il est possible d'en ajouter plus et de répartir la charge sur plusieurs machines. Cela nous permet de répartir les sites web sur différents serveurs et d'éviter les distorsions d'utilisation sur l'infrastructure, puisque les utilisations sont réparties dynamiquement sur tous les serveurs de la ferme.Si l'un des serveurs tombe en panne, les autres serveurs de la ferme sont disponibles pour maintenir le trafic. Cela nous permet d'utiliser une large gamme de serveurs disponibles dans notre inventaire, à condition qu'ils aient de bonnes capacités CPU.Répartition de chargeLes requêtes ne parviennent pas au serveur web voulu par magie. Pour cela, vous avez besoin d'un point d'entrée qui envoie les requêtes au bon serveur. Cette technologie s'appelle la "répartition de charge".Notre centre de données de Paris dispose de serveurs dont le matériel est entièrement dédié à la répartition de charge. Dans notre nouvelle infrastructure de Gravelines, cependant, nous utilisons une brique publique: IPLBs.Le trafic des sites Web arrive à
quelques adresses IP ( https://docs.ovh.com/fr/hosting/list-addresses-ip-clusters-and-web-hostings/#cluster-025 ) que nous dédions à notre service d'hébergement web. Ces adresses IP sont gérées par nos équilibrateurs de charge. Ils constituent donc le point d'entrée de nos infrastructures. Nous avons également mis en place la meilleure technologie anti-DDoS pour protéger les sites web de nos clients.Ces équilibrateurs de charge fonctionnent parfaitement pour les volumes élevés de trafic du site Web, répartis sur plusieurs serveurs Web, car les requêtes sont distribuées de manière équitable, via des algorithmes de répartition de charge. Mais nos exigences sont différentes. Nous souhaitons héberger plusieurs sites différents sur un même serveur, et adapter l'allocation en fonction de plusieurs critères : le forfait d'hébergement du client (les offres premium comportant moins de sites par serveur), et les ressources nécessaires pour répartir continuellement la charge.Nous proposons également des solutions avec des ressources garanties, comme Performance Hosting, ou même totalement dédiées, comme Cloud Web.
En fait, la répartition de la charge est très fortement liée à nos clients. Nous avons changé le système de répartition avec une brique dédiée à OVH, nommée
predictor, qui choisit le serveur web en fonction du site web de la requête. Les prédictifs s'adaptent aux métriques de notre infrastructure, et aux informations fournies par notre système.and execute the website source code. They get their data from the files and databases provided by the previously-described Filerz and database servers. The main requirement for these servers is good CPU resources, which are needed for executing the source code.
Since these web servers are stateless (i.e. they do not store any data locally), it is possible to add more of them and distribute the load across several machines. This allows us to distribute websites across different servers and avoid distortions of use across the infrastructure, as uses are dynamically distributed across all the servers of the farm.
If one of the servers goes down, other servers in the farm are available to maintain the traffic. This allows us to use a wide range of the servers available in our inventory, provided they have good CPU capabilities.
Load balancing
Queries don't arrive at the intended web server by magic. For this, you need an entry point that sends the requests to the right server. This technology is called 'load balancing'.
Our Paris datacentre features servers whose hardware is fully dedicated to load balancing. In our new Gravelines infrastructure, however, we use a public brick: IPLBs.
Website traffic arrives at a few IP addresses ( https://docs.ovh.com/en/hosting/list-addresses-ip-clusters-and-web-hostings/#cluster-025 ) that we dedicate to our web hosting service. These IP addresses are managed by our load balancers. They are therefore the entry point of our infrastructures. We have also implemented the very best anti-DDoS technology, to protect our clients' websites.
These load balancers work perfectly for high volumes of website traffic, spread across multiple web servers, as queries are distributed fairly, via load balancing algorithms. But our requirements are different. We wish to have several different sites on a single server, and change the allocation based on several criteria: the customer's hosting package (as more premium offers involve fewer websites per server), and the resources required to continuously distribute the load.
We also offer solutions where resources are guaranteed, such as Performance Hosting, or even fully dedicated, like Cloud Web.
In fact, the load distribution is very strongly tied to our customers. We have changed the distribution system with a brick dedicated to OVH, named predictor, that chooses the web server according to the request's website. The predictors adapt to our infrastructure's metrics, and the information provided by our system.
Tout cela rend notre infrastructure légèrement plus complexe que d'ordinaire, bien que nous n'allions pas entrer beaucoup plus dans les détails afin de maintenir les choses simples et dans le cadre de ce blog post. Cela devrait avoir fourni un aperçu suffisant pour expliquer les scénarios de migration possibles.En ajoutant la répartition de charge, ainsi que plusieurs serveurs de base de données et de stockage de fichiers, cette architecture nous permet d'accueillir un nombre incroyablement grand de sites Web différents. Mais comme tous les administrateurs d'infrastructure le savent, "Shit happens!". Un jour ou l'autre, l'échec arrivera. Il est donc nécessaire de savoir réagir dans de tels cas afin de minimiser l’impact.Domaines de défautL'une des techniques pour réduire l'impact des pannes est de limiter leur périmètre en créant des domaines de pannes. En dehors du monde de l'informatique, nous observons des concepts similaires dans la gestion forestière, avec l'utilisation de parcelles vides comme pare-feu, ou dans l'industrie du bâtiment, avec les portes du même nom.
Dans notre métier, il s'agit de diviser l'infrastructure en morceaux et de répartir les clients entre différents clusters. Nous avons donc divisé l'infrastructure de Paris en 12 clusters identiques. Dans chaque cluster, on retrouve le load balancer, les serveurs web et les Filerz. Si un des clusters tombe, " seulement " 1/12 des clients hébergés sur ce centre de données sont affectés.Les serveurs de bases de données sont traités séparément. Bien que nous ne le mettions pas en avant comme une fonctionnalité, nous permettons à nos clients de partager l'utilisation de leurs bases de données entre leurs solutions d'hébergement lorsqu'ils ont besoin de partager des données. Étant donné que le client n'est pas en mesure de choisir le cluster de ses sites Web, nous avons séparé les bases de données des clusters, afin de les rendre accessibles à l'ensemble du centre de données.
Donc pour la dernière fois, nous devons mettre à jour notre schéma d'infrastructure...
One of the techniques for reducing the impact of failures is to limit their perimeter by creating fault domains. Outside the world of computer science, we see similar concepts in forest management, with the use of empty parcels as firestoppers, or in the building industry, with the the doors of the same name.
In our business, it's about dividing the infrastructure into pieces, and distributing customers across different clusters. We therefore divided the Paris infrastructure into 12 identical clusters. In each cluster, we find the load balancer, the web servers and the Filerz. If one of the clusters goes down, "only" 1/12 of the customers with sites hosted at that datacentre are affected.
Database servers are treated separately. Although don't highlight it as a feature, we allow our customers to share the use of their databases between their hosting solutions when they need to share data. Since the customer isn't able to choose the cluster of their websites, we have separated the databases from the clusters, in order to make them accessible to the entire datacentre.
So for the last time, we need to update our infrastructure schema...
Gestion de l’infrastructure informatique
Toute cette infrastructure est gérée par notre système d’information, en configuration en temps rèel, qui fait le lien entre l’espace client OVH, les API OVH et l’infrastructure elle-même.Le système d’information inclut une représentation exhaustive de l’infrastructure, ce qui permet d’adapter la délivrance des nouveaux comptes, de géré les changements dans nos offres et d’éffectuer des actions techniques sur les comptes.Par exemple, lorsque vous créez une nouvelle base de données sur votre offre d'hébergement, le système d’information s’occupe de sélectionner le serveur sur lequel elle sera logée, pour s’assurer qu’elle est créée sur la même infrastructure, avant de vous notifier de sa disponibilité par e-mail ou via l’API.Félicitations... vous savez un peu plus sur notre architecture ! Pour savoir où tourne votre propre site web, vous pouvez retrouver les noms de vos serveurs de base de données, Filerz et clusters liés à votre hébergement dans l'espace client OVH.Contraintes techniques de migrationCette architecture impose certaines contraintes techniques, si les sites web qui y sont hébergés doivent continuer à fonctionner comme prévu :
Tous les sites d'un même cluster partagent la même adresse IP
Les serveurs de bases de données et les clusters d'hébergement ne sont pas corrélésPour migrer un site web, il faut synchroniser sa migration avec celle de tous ses éléments associés, soit le load balancer, Filerz, et les bases de donnéesLe code source d'un site web peut utiliser une base de données qui n'est pas référencée sur son hébergement
Le code source peut inclure des références à l'infrastructure (lien absolu incluant le numéro de filerz, le nom du cluster, le nom des serveurs de base de données...)Vous connaissez désormais l'ensemble des contraintes opérationnelles et techniques liées au projet de migration vers le centre de données. Dans le prochain article, nous discuterons des différents scénarios de migration que nous avons envisagés et du scénario que nous avons finalement choisi.À bientôt! To find out where your own website is running, you can find the names of your database servers, Filerz and clusters linked to your hosting in the OVH Control Panel.
Technical constraints for migration
This architecture imposes some technical constraints, if the websites hosted on it are to continue working as intended:
- All the websites in the same cluster share the same IP address
- Database servers and hosting clusters are uncorrelated
- In order to migrate a website, you must synchronise its migration with the migration of all its associated elements, i.e. the load balancer, Filerz, and databases
- The source code of a website can use a database that is not referenced on its web hosting
- The source code can include references to the infrastructure (absolute link including the filerz number , the cluster name, the name of the database servers ...)
You now know all the operational and technical constraints related to the datacentre migration project. In the next article, we will discuss the different migration scenarios we considered, and the one we eventually chose.
See you soon!