Cluster de serveurs de base de données

Un cluster est un groupe de deux ou plusieurs serveurs indépendants fonctionnant comme un système unique. Un cluster de serveurs de base de données peut permettre l’obtention d’une solution avec haute disponibilité ou encore augmenter la performance I/O de votre service de base de données. Dans cet article, nous discutons des différentes approches pour la mise en cluster des bases de données MySQL et MSSQL.

MySQL DRBD

Le service de base de données MySQL peut être transformé en un service hautement disponible à l’aide de DRBD. Cette technologie logicielle, seulement disponible sous Linux, effectue la mise en miroir des données d’un service entre le nœud actif et le nœud passif d’un cluster hautement disponible. DRBD fonctionne avec des périphériques en mode bloc (ex.: partitions d’un disque dur, volumes logiques LVM). Chaque bloc de données écrit sur le nœud actif l’est également sur le nœud passif.
La mise en miroir de données peut être effectuée de façon étroitement couplée selon le protocole C (mise en miroir synchrone). Dans ce mode, le système de fichier du nœud actif est averti que l’écriture du bloc est terminée uniquement lorsque le bloc a été écrit autant sur le nœud actif que le nœud passif. Il s’agit d’un bon choix pour une solution hautement disponible tout particulièrement si le fait de perdre ou de corrompre une transaction doit être évité à tout prix. L’autre mode possible est la mise en miroir asynchrone. Dans ce mode, le système de fichier du nœud actif est averti que l’écriture du bloc est terminée dès que le bloc a été écrit sur le nœud actif. Il s’agit d’un bon choix lors de la mise en place de nœuds séparés par une longue distance physique.
Le diagramme ci-dessous présente une solution web formée d’un cluster de serveurs web ainsi que d’un cluster DRBD de serveurs MySQL connectés via un réseau local. Les deux serveurs MySQL sont interconnectés par un lien réseau DRBD. Ce lien réseau est utilisé pour synchroniser les blocs de données entre les deux serveurs tout en évitant de congestionner le réseau local.

Une conséquence de la mise en miroir des données au niveau du périphérique en mode bloc est que les données ne peuvent être accédées que sur le nœud actif. Cela est dû aux spécifications de la plupart des systèmes de fichiers Linux (ext3, ext4, XFS, JFS, etc). Ces systèmes de fichiers ne supportent pas l’accès simultané par plusieurs serveurs à un même disque partagé pour des opérations en lecture et en écriture. Leur conception ne permet qu’à un seul serveur l’accès à un disque donné. Par conséquent, la performance d’un cluster DRBD MySQL est sensiblement égale à celle d’un seul serveur MySQL. DRBD fournit de la haute disponibilité pour votre service de base de données MySQL mais ne lui procure aucun gain de performance.

Réplication MySQL

Un cluster formé de deux serveurs MySQL ou plus peut également être créé à l’aide d’une solution redondante de répartiteurs de charge et des fonctionnalités de réplication du service MySQL.

Réplication MySQL master/master

Un cluster MySQL avec réplication master/master est formé de deux serveurs MySQL en mode actif/actif. L’application de répartition de charge doit définir deux adresses IP distinctes :

• Adresse IP pour les opérations d’écriture
• Adresse IP pour les opérations de lecture

Les opérations d’écriture doivent être effectuées sur un seul serveur afin d’éviter la corruption de données. Alors qu’un serveur est défini en tant que serveur primaire dans l’application de répartition de charge, le second serveur est défini en tant que serveur de relève. Si le serveur primaire a une défaillance, les opérations en écriture seront redirigées automatiquement sur le second serveur. Les données reliées au service de base de données sont synchronisées entre les deux serveurs à l’aide d’une tâche de réplication configurée dans MySQL. Les opérations en lecture peuvent être effectuées sur les deux serveurs MySQL.
Dans une telle configuration de réplication master/master, les deux serveurs sont sur un pied d’égalité. Si un serveur a une défaillance, le second prend le relai sans qu’il y ait besoin de modifier la configuration des serveurs web. Pour les opérations en écriture, une telle configuration fournit un niveau de performance égal à celui d’un seul serveur. Pour les opérations en lecture, la performance théorique d’une telle configuration est deux fois plus élevée que celle d’un seul serveur. Toutefois, pour obtenir des performances plus élevées lors des opérations de lecture, l’application web doit être codée de façon à distinguer les opérations en écriture des opérations en lecture.

Réplication MySQL master/slave

Un cluster MySQL avec réplication master/slave est formé de deux serveurs MySQL en mode actif/actif. L’application de répartition de charge doit définir deux adresses IP distinctes :

• Adresse IP pour les opérations d’écriture
• Adresse IP pour les opérations de lecture

Les opérations d’écriture vers la base de données doivent être réalisées uniquement sur le serveur master. Les données contenues dans le serveur slave sont synchronisées avec le serveur master. Les opérations de lecture peuvent être réalisées sur l’un ou l’autre des serveurs MySQL.
Dans une configuration de réplication master/slave, seul le serveur master est en mesure de gérer les opérations d’écriture. En cas de défaillance du serveur master, l’application web cessera de fonctionner normalement. Pour les opérations en lecture, une telle configuration offre un niveau de performance égal à celui d’un seul serveur. Pour les opérations en lecture, la performance théorique d’une telle configuration est deux fois plus élevée que celle d’un seul serveur. Toutefois, pour obtenir des performances plus élevées lors des opérations de lecture, l’application web doit être codée de façon à distinguer les opérations en écriture des opérations en lecture.
Jusqu’à présent, la comparaison des réplications master/master et master/slave indique qu’il n’y a aucun réel avantage à utiliser une réplication master/slave. Cependant, tandis que la réplication master/master s’effectue uniquement entre deux serveurs, la réplication master/slave peut être réalisée avec plusieurs serveurs dont un master et les autres en configuration slave. Par conséquent, une configuration master/slave devient intéressante lorsque le nombre de serveurs slave est supérieur à un.

Cluster MSSQL pour haute disponibilité

Un cluster Microsoft Windows est composé de deux serveurs en mode actif/passif, au moins un contrôleur de domaine et une solution de stockage de données. Le diagramme ci-dessous présente un cluster MSSQL formé de deux serveurs de base de données, deux contrôleurs de domaine redondants et d’une solution de stockage SAN iSCSI. Le SAN iSCSI est connecté aux serveurs de base de données avec des connexions multi-trajet afin de fournir des liens de communication redondants.

Cette configuration recommandée par Microsoft Windows fournit un service de base de données hautement redondant pour cette solution web. Si le serveur actif cesse de fonctionner, le serveur actif prendra le relai. La performance du cluster de base de données dépend principalement des éléments suivants :

• Processeur des serveurs de base de données
• Type et configuration RAID des disques du SAN
• Mécanisme de mise en cache des données du SAN
• Liens de communication entre les serveurs de base de données et le SAN

Réplication MSSQL

Un cluster formé de deux serveurs MSSQL ou plus peut également être réalisé en utilisant une solution de répartition de charge redondante et les fonctionnalités de réplication de MSSQL.

Réplication MSSQL master/master

Un cluster utilisant la réplication MSSQL master/master consiste en deux serveurs MSSQL opérant en mode actif/actif. L’appareil de répartition de charge doit définir deux adresses IP distinctes :

• Adresse IP pour les opérations d’écriture
• Adresse IP pour les opérations de lecture

Les opérations d’écriture doivent être effectuées sur un seul serveur MSSQL afin d’éviter la corruption de données. Alors qu’un serveur est défini en tant que serveur primaire dans l’application de répartition de charge, le second serveur est défini en tant que serveur de relève. Si le serveur primaire a une défaillance, les opérations en écriture seront redirigées automatiquement sur le second serveur. Les données reliées au service de base de données sont synchronisées entre les deux serveurs à l’aide du mécanisme de publication transactionnelle avec des abonnements qui peuvent être mis à jour (« transactional publication with updatable subscriptions ») intégré à MSSQL. Les opérations en lecture peuvent être effectuées sur les deux serveurs MySQL.
Le mécanisme publication transactionnelle avec des abonnements qui peuvent être mis à jour ajoute une colonne nommée msrepl_tran_version sur chaque table publiée afin de suivre les transactions. Toutes les commandes SQL INSERT de votre application doivent potentiellement être adaptées à cette contrainte.
Dans une telle configuration de réplication master/master, les deux serveurs sont sur un pied d’égalité. Si un serveur a une défaillance, le second prend le relai sans qu’il y ait besoin de modifier la configuration des serveurs web. Pour les opérations en écriture, une telle configuration fournit un niveau de performance égal à celui d’un seul serveur. Pour les opérations en lecture, la performance théorique d’une telle configuration est deux fois plus élevée que celle d’un seul serveur. Toutefois, pour obtenir des performances plus élevées lors des opérations de lecture, l’application web doit être codée de façon à distinguer les opérations en écriture des opérations en lecture.

Réplication MSSQL master/slave

Un cluster MSSQL avec réplication master/slave est formé de deux serveurs MSSQL en mode actif/actif. L’application de répartition de charge doit définir deux adresses IP distinctes :

• Adresse IP pour les opérations d’écriture
• Adresse IP pour les opérations de lecture

Les opérations d’écriture vers la base de données doivent être réalisées uniquement sur le serveur master. Les données contenues dans le serveur slave sont synchronisées avec le serveur master à l’aide du mécanisme de publication transactionnelle (« transactional publication ») intégré à MSSQL. Les opérations de lecture peuvent être réalisées sur l’un ou l’autre des serveurs MySQL.
Dans une configuration de réplication master/slave, seul le serveur master est en mesure de gérer les opérations d’écriture. En cas de défaillance du serveur master, l’application web cessera de fonctionner normalement. Pour les opérations en lecture, une telle configuration offre un niveau de performance égal à celui d’un seul serveur. Pour les opérations en lecture, la performance théorique d’une telle configuration est deux fois plus élevée que celle d’un seul serveur. Toutefois, pour obtenir des performances plus élevées lors des opérations de lecture, l’application web doit être codée de façon à distinguer les opérations en écriture des opérations en lecture.
Jusqu’à présent, la comparaison des réplications master/master et master/slave indique qu’il n’y a aucun réel avantage à utiliser une réplication master/slave à l’exception de la nécessité d’utiliser des requêtes SQL INSERT modifiées en mode master/master. Cependant, tandis que la réplication master/master s’effectue uniquement entre deux serveurs, la réplication master/slave peut être réalisée avec plusieurs serveurs dont un master et les autres en configuration slave. Par conséquent, une configuration master/slave devient intéressante lorsque le nombre de serveurs slave est supérieur à un.