Dans le cadre du déploiement d'un site Drupal d'envergure professionnelle, la tolérance aux pannes est un impératif absolu. Si l'application Drupal peut facilement être répartie sur plusieurs serveurs web configurés derrière un répartiteur de charge, la base de données constitue historiquement le point de défaillance unique le plus critique. C'est ici qu'intervient la technologie Galera Cluster pour MariaDB.
Ce guide complet détaille la mise en œuvre d'une infrastructure de base de données hautement disponible, résiliente et synchrone, spécialement optimisée pour répondre aux exigences transactionnelles de Drupal sous Debian.
Pourquoi choisir Galera Cluster pour la base de données de Drupal ?
Contrairement aux solutions classiques de réplication asynchrone de type maître-esclave, Galera Cluster propose une réplication synchrone de type multi-maître. Cela signifie que chaque nœud du cluster contient exactement les mêmes données en temps réel et peut accepter des requêtes de lecture et d'écriture de la part de l'application.
Voici les avantages majeurs de cette approche pour une infrastructure Drupal :
- Absence totale de perte de données : la réplication synchrone garantit que si un nœud tombe en panne, aucune transaction validée n'est perdue.
- Haute disponibilité réelle : la panne d'un nœud n'interrompt pas le service, les autres nœuds continuent de répondre instantanément aux requêtes de Drupal.
- Évolutivité des lectures : Drupal effectuant une majorité d'opérations de lecture, vous pouvez répartir cette charge sur l'ensemble des nœuds actifs pour optimiser les temps de réponse.
- Cohérence stricte des données : les mécanismes de certification intégrés à Galera préviennent les conflits d'écriture et assurent l'intégrité de vos tables de cache et d'entités Drupal.
Prérequis système et architecture réseau sous Debian
Pour mettre en place un cluster hautement disponible et éviter le phénomène de partitionnement réseau appelé scénario de split-brain, il est impératif de déployer un nombre impair de nœuds. Nous utiliserons ici une architecture composée de trois serveurs Debian distincts.
Avant de commencer, assurez-vous de disposer des éléments suivants :
- Trois instances de serveurs sous Debian installées et à jour.
- Des adresses IP statiques et privées pour chacun des nœuds.
- Une résolution de noms opérationnelle via le fichier d'hôtes ou un DNS interne.
- Un accès root ou des privilèges sudo sur chaque serveur.
Pour notre démonstration, nous utiliserons le plan d'adressage suivant :
- Nœud 1 : 10.0.0.11 (nom d'hôte : db1.local)
- Nœud 2 : 10.0.0.12 (nom d'hôte : db2.local)
- Nœud 3 : 10.0.0.13 (nom d'hôte : db3.local)
Il est essentiel de configurer votre pare-feu pour autoriser le trafic réseau sur les ports spécifiques requis par Galera :
- Port 3306 : pour les connexions standard MariaDB.
- Port 4567 : pour le trafic de communication du cluster Galera.
- Port 4568 : pour le transfert d'état incrémentiel (IST).
- Port 4444 : pour le transfert d'état complet (SST).
Installation de MariaDB sur les nœuds Debian
La première étape consiste à installer le serveur MariaDB ainsi que le module Galera sur chacun des trois serveurs Debian. Exécutez les commandes suivantes sur les trois machines pour garantir une base logicielle homogène.
Mettez d'abord à jour vos dépôts et installez les paquets requis :
sudo apt update
sudo apt install -y mariadb-server mariadb-client galera-4Une fois l'installation terminée, sécurisez vos instances de base de données à l'aide de l'outil interactif officiel :
sudo mysql_secure_installationAu cours de cette étape, veillez à définir un mot de passe administrateur robuste pour le compte root, à désactiver les connexions anonymes, à interdire l'accès root à distance et à supprimer la base de données de test par défaut.
Configuration du cluster Galera pas à pas
L'étape suivante consiste à éditer les fichiers de configuration de MariaDB afin d'activer et de paramétrer le moteur Galera. Sur Debian, la configuration doit être enregistrée dans un fichier dédié.
Créez et éditez le fichier de configuration spécifique sur le premier nœud :
sudo nano /etc/mysql/mariadb.conf.d/60-galera.cnfInsérez la configuration suivante, en prenant soin d'adapter les adresses IP et les noms de nœuds selon votre propre architecture réseau :
[mysqld]
# Configuration de base pour la compatibilité avec Drupal
binlog_format=ROW
default-storage-engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
# Configuration du moteur de réplication Galera
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
# Configuration générale du cluster
wsrep_cluster_name="drupal_galera_cluster"
wsrep_cluster_address="gcomm://10.0.0.11,10.0.0.12,10.0.0.13"
# Configuration spécifique du nœud actuel
wsrep_node_address="10.0.0.11"
wsrep_node_name="node1"
# Méthode de transfert d'état initial
wsrep_sst_method=rsyncCopiez ce fichier de configuration sur le deuxième nœud (10.0.0.12) et modifiez les deux variables spécifiques :
- wsrep_node_address="10.0.0.12"
- wsrep_node_name="node2"
Copiez enfin le fichier sur le troisième nœud (10.0.0.13) et ajustez les variables associées :
- wsrep_node_address="10.0.0.13"
- wsrep_node_name="node3"
Note : la directive innodb_autoinc_lock_mode fixée à la valeur 2 est d'une importance capitale pour Drupal. Elle permet d'éviter les verrous de table lors des insertions massives de données, un comportement fréquent lors de l'exécution des files d'attente (queues) ou de l'indexation de recherche de Drupal.
Amorçage et démarrage du cluster de base de données
Une fois la configuration déployée sur tous les serveurs, vous devez amorcer le cluster. Cette opération ne doit être effectuée que sur le premier nœud pour définir le point de départ de la réplication.
Arrêtez le service MariaDB sur tous les nœuds pour éviter les conflits de démarrage :
sudo systemctl stop mariadbSur le premier nœud (node1), lancez la commande d'amorçage spécifique :
sudo galera_new_clusterVous pouvez vérifier que le cluster est bien initialisé en interrogeant la variable d'état de Galera :
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"La sortie de cette commande doit indiquer que la taille du cluster est actuellement de 1. Vous pouvez maintenant démarrer le service MariaDB normalement sur le deuxième nœud (node2) :
sudo systemctl start mariadbRépétez immédiatement l'opération sur le troisième nœud (node3) :
sudo systemctl start mariadbExécutez à nouveau la commande de contrôle sur n'importe lequel de vos trois serveurs pour valider la bonne intégration de l'ensemble de l'infrastructure :
mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size';"Si l'installation a été réalisée correctement, la valeur retournée doit désormais être de 3. Votre cluster est maintenant entièrement opérationnel et synchronisé.
Configuration de Drupal pour se connecter au cluster haute disponibilité
Pour connecter votre application Drupal à votre nouveau cluster de base de données hautement disponible, vous devez configurer le fichier de paramètres de votre site.
Il existe deux manières principales d'adresser votre cluster depuis Drupal :
- Utilisation d'un proxy ou d'un répartiteur de charge : vous configurez un outil comme HAProxy ou ProxySQL en amont de vos bases de données. Drupal pointe alors vers l'adresse IP unique du proxy.
- Configuration native dans le fichier de configuration de Drupal : vous déclarez les différents nœuds directement dans le fichier de configuration PHP.
Voici comment déclarer vos serveurs de base de données directement dans le fichier de configuration de Drupal pour assurer un basculement automatique élémentaire :
<?php
// Exemple de configuration haute disponibilité dans settings.php
$databases['default']['default'] = [
'database' => 'drupal_prod_db',
'username' => 'drupal_user',
'password' => 'mot_de_passe_ultra_securise',
'prefix' => '',
'host' => '10.0.0.11', // Nœud principal par défaut
'port' => '3306',
'namespace' => 'Drupal\\mysql\\Driver\\Database\\mysql',
'driver' => 'mysql',
'autoload' => 'core/modules/mysql/src/Driver/Database/mysql/',
];
// Nœuds de secours en cas de défaillance du nœud principal
$databases['default']['replica'][] = [
'database' => 'drupal_prod_db',
'username' => 'drupal_user',
'password' => 'mot_de_passe_ultra_securise',
'prefix' => '',
'host' => '10.0.0.12',
'port' => '3306',
'namespace' => 'Drupal\\mysql\\Driver\\Database\\mysql',
'driver' => 'mysql',
'autoload' => 'core/modules/mysql/src/Driver/Database/mysql/',
];
$databases['default']['replica'][] = [
'database' => 'drupal_prod_db',
'username' => 'drupal_user',
'password' => 'mot_de_passe_ultra_securise',
'prefix' => '',
'host' => '10.0.0.13',
'port' => '3306',
'namespace' => 'Drupal\\mysql\\Driver\\Database\\mysql',
'driver' => 'mysql',
'autoload' => 'core/modules/mysql/src/Driver/Database/mysql/',
];Bien que cette configuration native soit utile pour les opérations de lecture, l'intégration d'un outil de répartition de charge comme ProxySQL reste recommandée pour les grands sites de production afin de gérer finement le routage des écritures et d'éviter d'éventuels conflits de verrous applicatifs.
Tests de basculement et validation de la haute disponibilité
La mise en œuvre d'un cluster n'est pas complète tant que son comportement en situation d'échec n'a pas été rigoureusement testé. Nous allons simuler une panne pour valider la tolérance aux pannes du système.
Connectez-vous au premier nœud (node1) et arrêtez brutalement le service de base de données :
sudo systemctl stop mariadbConsultez ensuite l'état du cluster depuis le deuxième nœud (node2) en exécutant la requête SQL suivante :
SHOW STATUS LIKE 'wsrep_cluster_status';
SHOW STATUS LIKE 'wsrep_cluster_size';Le statut doit indiquer Primary, ce qui confirme que la majorité des nœuds reste active, et la taille doit s'ajuster à la valeur de 2. Pendant ce temps, connectez-vous à l'interface d'administration de votre site Drupal. Naviguez sur les différentes pages et effectuez une modification de contenu pour vérifier que l'application reste totalement opérationnelle en écriture comme en lecture.
Une fois le test validé, redémarrez le service sur le premier nœud :
sudo systemctl start mariadbLe nœud va automatiquement se reconnecter au cluster existant, comparer son état grâce au protocole de transfert d'état incrémentiel (IST) et rattraper son retard sans aucune intervention manuelle. La taille du cluster repassera alors à 3 de manière transparente.
FAQ sur la haute disponibilité MariaDB pour Drupal
Puis-je installer Galera Cluster avec seulement deux serveurs ?
Non, il est fortement déconseillé de déployer un cluster Galera avec seulement deux nœuds. En cas de coupure réseau entre les deux serveurs, aucun d'eux ne pourra obtenir la majorité requise pour valider les transactions, provoquant un blocage complet du cluster pour éviter la corruption des données. Si vous manquez de ressources, vous pouvez utiliser un nœud arbitre léger appelé Galera Arbitrator (garbd) comme troisième entité pour assurer le rôle de votant.
Comment Drupal gère-t-il les conflits d'écriture simultanés sur Galera ?
Galera Cluster utilise un système de verrouillage optimiste. Si deux requêtes d'écriture concurrentes entrent en conflit sur la même ligne de données au même moment sur deux nœuds différents, l'une d'elles sera validée et l'autre sera rejetée avec une erreur de transaction. Pour minimiser ce risque avec Drupal, il est conseillé de diriger toutes les requêtes d'écriture vers un seul nœud principal à la fois à l'aide d'un outil d'équilibrage de charge, et d'utiliser les autres nœuds uniquement pour les lectures.
Quel est l'impact de la réplication synchrone sur les performances de mon site Drupal ?
La réplication synchrone introduit une légère latence réseau lors des opérations d'écriture, car chaque transaction doit être approuvée par la majorité des nœuds avant d'être confirmée. Cependant, les performances en lecture sont excellentes et peuvent être parallélisées sur l'ensemble du cluster. Pour compenser l'effet sur les écritures, l'utilisation de liaisons réseau privées à faible latence et de disques SSD rapides est fortement recommandée pour vos serveurs de base de données Debian.
