Planification d'une architecture multi-serveurs pour une infrastructure dédiée

Un seul serveur dédié suffit généralement pour gérer la plupart des applications web en production. À un moment donné, ce n'est plus le cas — soit parce que le trafic a dépassé la capacité d'un seul serveur, soit parce que tu as besoin d'une redondance pour éviter qu'une panne matérielle ne mette l'application hors service, soit parce que ta base de données est devenue suffisamment volumineuse pour nécessiter un matériel dédié…

Table des matières

Quand un serveur unique n'est plus la bonne solution

Les facteurs qui poussent à passer à une architecture multi-serveurs sont bien précis. Le simple argument « on grandit » ne suffit pas : les coûts et la complexité d'une infrastructure multi-serveurs sont bien réels, et l'optimisation d'un serveur unique permet souvent de tenir plus longtemps que ce que les équipes imaginent.

Passe à une architecture multi-serveurs lorsque :

La charge moyenne dépasse systématiquement le nombre de cœurs de ton serveur pendant les heures de trafic normal, et pas seulement lors des pics. Un serveur à 16 cœurs dont la charge moyenne reste supérieure à 20 met les tâches en file d'attente.
Ta base de données et ton application se disputent la même mémoire vive. La mise en cache Redis, le pool de tampons InnoDB de MySQL, les workers PHP-FPM et la mémoire de l'application partagent tous la même mémoire vive physique sur un seul serveur. À un certain moment, les performances de la base de données et celles de la couche web s'opposent directement l'une à l'autre.
Une panne matérielle constituerait un incident opérationnel. Si l'indisponibilité du serveur pendant son remplacement (généralement 2 à 4 heures) t'entraînerait des pertes financières importantes, tu as besoin d'une redondance.
Le déploiement nécessite une interruption de service. Les configurations à plusieurs serveurs permettent des déploiements progressifs ; les déploiements sur un seul serveur nécessitent souvent de mettre l'application hors ligne pendant les mises à jour.

Niveau 1 : Séparation entre le Web et la base de données

La première configuration multi-serveurs vraiment efficace sépare la couche des applications web de la couche de la base de données. Ça résout le problème de contention de la mémoire vive et permet à chaque serveur d'être optimisé pour son rôle.

Serveur web : Nginx, PHP-FPM, code d'application, cache Redis. Configuration optimisée pour le processeur. À ce stade, les formules Essential ou Elite d'InMotion conviennent à la plupart des applications.

Serveur de base de données :PostgreSQL, grand pool de mémoire tampon InnoDB (70 à 80 % de la RAM), configuration optimisée des E/S disque. Configuration optimisée pour la mémoire. Les 192 Go de RAM DDR5 du serveur Extreme en font un excellent serveur de base de données dédié : un pool de mémoire tampon InnoDB de 130 à 150 Go permet de conserver la plupart des bases de données de production entièrement en mémoire.

La connectivité réseau entre les deux serveurs est importante. Les deux serveurs doivent être hébergés dans le même centre de données InMotion pour garantir une communication sur réseau privé à faible latence. La configuration de l'application doit pointer les connexions à la base de données vers l'adresse IP privée du serveur de base de données plutôt que vers localhost :

// WordPress wp-config.php

define('DB_HOST', '10.0.0.2'); // Database server private IP

define('DB_NAME', 'production_db');

define('DB_USER', 'app_user');

define('DB_PASSWORD', 'secure_password');

MySQL on the database server should bind to the private interface and accept connections only from the web server IP:

# /etc/mysql/mysql.conf.d/mysqld.cnf

bind-address = 10.0.0.2

# Grant access only from web server

# GRANT ALL ON production_db.* TO 'app_user'@'10.0.0.1' IDENTIFIED BY 'password';

Niveau 2 : Couche Web à équilibrage de charge

Lorsqu'un seul serveur web ne suffit plus, l'ajout d'un deuxième serveur web derrière un équilibreur de charge permet de répartir le trafic et d'assurer la bascule en cas de défaillance d'un des serveurs.

HAProxy est l'équilibreur de charge open source standard pour cette configuration. Il tourne sur un petit serveur (ou sur le serveur de base de données si les ressources le permettent) et répartit les requêtes au sein de la couche web :

global

    maxconn 50000

    log /dev/log local0

defaults

    mode http

    timeout connect 5s

    timeout client 30s

    timeout server 30s

    option httplog

frontend web_frontend

    bind *:80

    bind *:443 ssl crt /etc/ssl/certs/production.pem

    default_backend web_servers

backend web_servers

    balance roundrobin

    option httpchk GET /health

    server web1 10.0.0.1:80 check inter 2s

    server web2 10.0.0.2:80 check inter 2s

La directive httpchk envoie des requêtes de vérification de l'état à la page /health de chaque serveur web toutes les 2 secondes. Un serveur qui échoue aux vérifications d'état est automatiquement retiré de la rotation. Le guide de configuration d'HAProxy couvre l'ensemble de la configuration des vérifications d'état, y compris la correspondance des codes de réponse et les seuils d'échec.

L'état de session doit être géré en dehors des serveurs web. Lorsque l'équilibrage de charge répartit les requêtes entre plusieurs serveurs web, chaque requête peut aboutir sur un serveur différent. Les données de session stockées dans le gestionnaire de session par défaut de PHP, basé sur des fichiers, ne seront pas disponibles sur l'autre serveur. Stocke les sessions dans Redis sur le serveur de base de données :

# /etc/php/8.x/fpm/php.ini

session.save_handler = redis

session.save_path = "tcp://10.0.0.3:6379"

Tous les serveurs web pointent vers la même instance Redis. N'importe quel serveur web peut traiter n'importe quelle requête, quel que soit le serveur qui a traité les requêtes précédentes du même utilisateur.

Niveau 3 : Haute disponibilité des bases de données

Une redondance au niveau du serveur web sans redondance au niveau de la base de données crée un point de défaillance unique au niveau de la base de données. La réplication ou la mise en cluster de MySQL assure une redondance au niveau de la base de données.

La réplication maître-réplique MySQL est la configuration de haute disponibilité la plus simple. Le serveur maître gère toutes les écritures ; les répliques reçoivent les modifications via la réplication du journal binaire et peuvent traiter les requêtes de lecture.

# Primary server my.cnf

[mysqld]

server-id = 1

log_bin = /var/log/mysql/mysql-bin.log

binlog_format = ROW

sync_binlog = 1

innodb_flush_log_at_trx_commit = 1

# Replica server my.cnf

[mysqld]

server-id = 2

relay-log = /var/log/mysql/relay-bin.log

read_only = 1

Pour le basculement automatique (promotion d'une réplique au statut de serveur principal en cas de défaillance de ce dernier), Orchestrator est l'outil standard pour la gestion de la topologie MySQL. Orchestrator surveille la topologie de réplication et peut effectuer une promotion automatique, grâce à des intégrations avec Consul ou ZooKeeper pour la coordination du basculement via DNS.

MySQL InnoDB Cluster offre une réplication synchrone avec basculement automatique, au prix d'une latence d'écriture plus élevée (les écritures doivent être validées par un quorum de nœuds avant d'être validées). Pour les applications où la perte de données lors d'un basculement est inacceptable, le modèle synchrone d'InnoDB Cluster offre des garanties plus solides que la réplication asynchrone. La documentation sur la réplication en groupe de MySQL aborde la configuration et les aspects opérationnels.

Schéma d'architecture : configuration de production à trois serveurs

[Load Balancer / HAProxy]

                         10.0.0.0:80,443

                        /               \

              [Web Server 1]         [Web Server 2]

               10.0.0.1               10.0.0.2

               Nginx + PHP            Nginx + PHP

                        \               /

                    [Database Server]

                         10.0.0.3

                    MySQL Primary + Redis

                         |

                    [DB Replica]

                         10.0.0.4

                    MySQL Replica

Cette configuration prend en charge :

Panne du niveau Web : HAProxy exclut le serveur Web défaillant ; le serveur restant prend en charge tout le trafic
Échec de la réplique de la base de données : l'application continue d'écrire sur la base principale ; la réplique se reconnecte et rattrape son retard
Panne du serveur principal de la base de données : Orchestrator fait passer la réplique au statut de serveur principal ; le DNS est mis à jour pour rediriger l'application vers le nouveau serveur principal

Ce qu'il ne gère pas : la défaillance du répartiteur de charge. L'ajout d'une redondance HAProxy avec Keepalived (pour le basculement de l'adresse VIP entre deux instances HAProxy) permet d'éliminer ce dernier point de défaillance unique.

Stockage de fichiers partagé entre serveurs Web

Les applications web qui permettent de télécharger des fichiers (images, documents, contenu généré par les utilisateurs) doivent rendre ces fichiers accessibles depuis tous les serveurs web. Les fichiers téléchargés sur web1 doivent pouvoir être lus depuis web2.

Trois approches, par ordre de complexité :

Montage NFS : un serveur exporte un répertoire via NFS ; les autres le montent. C'est simple, mais le serveur NFS devient un point de défaillance unique et un goulot d'étranglement au niveau des E/S à grande échelle.

GlusterFS : un système de fichiers distribué qui réplique les données sur plusieurs serveurs. Plus complexe à configurer, mais il élimine le point de défaillance unique.

Stockage objet avec interface CDN : télécharge tes fichiers directement sur un stockage objet compatible S3 (ou sur le stockage de sauvegarde d'InMotion comme zone de transit), puis diffuse-les via un CDN. L'architecture la plus simple pour les nouvelles applications : pas de système de fichiers partagé à gérer.

Pour les applications existantes, le NFS est souvent la solution la plus rapide pour accéder à des fichiers sur plusieurs serveurs. Pour les applications conçues dès le départ pour fonctionner sur plusieurs serveurs, le stockage objet avec diffusion via un CDN permet d'éviter complètement toute une série de complexités opérationnelles.

Planifier la progression

Il n'est pas nécessaire de mettre en place une architecture multi-serveurs d'un seul coup. Voici comment ça se passe généralement :

Commence par un serveur unique bien configuré (InMotion Essential ou Extreme, selon la charge de travail)
Mettre la base de données sur son propre serveur dès que les conflits de mémoire vive ou d'E/S deviennent perceptibles
Ajoute un deuxième serveur web et un équilibreur de charge lorsque la saturation du processeur est constante
Mets en place la réplication de la base de données lorsque les besoins de l'entreprise exigent de réduire le risque de temps d'arrêt
Ajoute une redondance HAProxy lorsque l'équilibreur de charge lui-même devient le dernier point de défaillance unique

Chaque étape entraîne des coûts supplémentaires et accroît la complexité opérationnelle. Passe à l'étape suivante lorsque les contraintes actuelles sont mesurables, et non en prévision de contraintes que tu n'as pas encore rencontrées.

Partager cet article