Architectures haute disponibilité pour les clusters MySQL sur Compute Engine

Last reviewed 2024-02-21 UTC

Ce document décrit plusieurs architectures offrant une haute disponibilité pour les déploiements MySQL sur Google Cloud. La haute disponibilité est la mesure de la résilience du système en réponse à la défaillance d'une infrastructure sous-jacente. Dans ce document, la haute disponibilité est abordée sous l'angle de la disponibilité des clusters MySQL au sein d'une seule région cloud.

Ce document est destiné aux administrateurs de bases de données, aux architectes cloud et aux ingénieurs DevOps qui veulent apprendre comment renforcer la fiabilité au niveau des données MySQL en améliorant le temps d'activité global du système. Ce document vous concerne si vous exécutez MySQL sur Compute Engine. Il ne vous est pas destiné si vous utilisez Cloud SQL pour MySQL.

Pour les systèmes ou applications qui nécessitent un état persistant pour gérer les requêtes ou les transactions, la couche de persistance des données doit être disponible pour un traitement correct des requêtes liées aux interrogations ou aux mutations de données. Si l'application doit interagir au niveau des données pour répondre aux demandes de service, tout temps d'arrêt à ce niveau empêche l'application d'effectuer les tâches nécessaires.

En fonction des objectifs de niveau de service (SLO) du système, vous pouvez avoir besoin d'une topologie d'architecture capable de fournir un niveau de disponibilité plus élevé. Bien qu'il existe plusieurs façons d'obtenir la haute disponibilité, en règle générale, vous provisionnez une infrastructure redondante que vous pouvez rendre accessible rapidement à votre application.

Ce document traite des sujets suivants :

  • Section "Terminologie" pour vous aider à comprendre les concepts liés aux bases de données à haute disponibilité
  • Description des différentes options proposées pour les topologies MySQL à haute disponibilité
  • Informations contextuelles pour vous aider à comprendre ce qu'il faut prendre en compte dans chaque option

Terminologie

Certains termes et concepts standards dans l'industrie sont importants à comprendre, mais leur propos dépasse le cadre de ce document.

Réplication. Processus par lequel les transactions d'écriture (INSERT, UPDATE ou DELETE) sont capturées, journalisées, puis appliquées en série de manière fiable à tous les nœuds de base de données de la topologie.

Nœud source. Toutes les écritures de base de données doivent être dirigées vers un nœud source. Le nœud source fournit un accès en lecture à l'état le plus récent des données persistantes.

Nœud d'instance dupliquée. Copie en ligne du nœud de base de données source. Les modifications sont répliquées de manière quasi synchrone sur les nœuds d'instance dupliquée à partir du nœud source. Il est possible de lire les données des nœuds d'instances dupliquées, sachant que les données peuvent être légèrement retardées en raison du délai avant réplication.

Délai avant réplication. Mesure temporelle qui exprime l'intervalle entre le moment où une transaction est appliquée au nœud source et celui où elle est appliquée à l'instance dupliquée.

Disponibilité. Durée (en pourcentage) pendant laquelle une ressource est opérationnelle et capable de diffuser une réponse à une requête.

Détection des défaillances. Processus permettant d'identifier qu'une défaillance d'infrastructure s'est produite.

Basculement. Processus de promotion de l'infrastructure de sauvegarde ou de secours (dans ce cas, le nœud d'instance dupliquée) au rang d'infrastructure principale. En d'autres termes, lors du basculement, le nœud d'instance dupliquée devient le nœud source.

Objectif de temps de récupération (RTO). Durée d'exécution, en temps réel, acceptable du point de vue métier, du processus de basculement au niveau des données.

Action de remplacement. Processus de rétablissement de l'ancien nœud source après un basculement.

Autoréparation. Capacité d'un système à résoudre les problèmes sans intervention externe d'un opérateur humain.

Partition réseau. Condition dans laquelle deux nœuds d'une topologie, par exemple les nœuds source et d'instance dupliquée, ne peuvent pas communiquer entre eux sur le réseau.

Split-brain. Condition qui se produit lorsque deux nœuds croient simultanément qu'ils sont le nœud source.

Groupe de nœuds. Ensemble de tâches de ressources de calcul qui fournissent un service. Pour ce document, ce service est le niveau de persistance des données.

Nœud témoin ou de quorum. Ressource de calcul distincte permettant à un groupe de nœuds de déterminer ce qu'il doit faire lorsqu'une condition de split-brain se produit.

Élection du responsable ou nœud source. Processus selon lequel un groupe de nœuds en relation avec des nœuds similaires, y compris des nœuds témoins, détermine le nœud à utiliser comme nœud source.

Groupe de nœuds. Ensemble de tâches de ressources de calcul qui fournissent un service. Pour ce document, ce service est le niveau de persistance des données.

Système de secours à chaud. Un nœud qui représente une copie proche d'un autre nœud source et peut devenir le nouveau nœud source avec un temps d'arrêt minimal.

Quand choisir une architecture haute disponibilité ?

Les architectures haute disponibilité offrent une protection renforcée contre les temps d'arrêt au niveau des données. Comprendre la tolérance de vos services aux temps d'arrêt et les compromis liés aux différentes architectures est essentiel pour choisir l'option adaptée à votre cas d'utilisation.

Utilisez une topologie à haute disponibilité lorsque vous souhaitez accroître la disponibilité au niveau des données afin de répondre aux exigences de fiabilité de vos services et charges de travail. Pour les environnements tolérants à un certain nombre de temps d'arrêt, une topologie à haute disponibilité implique un coût et une complexité non justifiés. Par exemple, les environnements de développement ou de test ont rarement besoin de la haute disponibilité au niveau de la base de données.

Évaluer les exigences liées à la haute disponibilité

Si vous envisagez de fournir la haute disponibilité, le coût est un facteur incontournable dont vous devez tenir compte. En effet, vos coûts d'infrastructure et de stockage vont au moins doubler. Lorsque vous évaluez les options MySQL haute disponibilité possibles, posez-vous les questions suivantes :

  • Quels services ou clients dépendent de votre niveau de données ?
  • Quel est votre budget opérationnel ?
  • Quel coût représentent les temps d'arrêt au niveau de la persistance des données pour votre entreprise ?
  • Quel est le degré d'automatisation nécessaire pour le processus ?
  • Quel niveau de disponibilité espérez-vous atteindre, 99,5 %, 99,9 %, 99,99 % ?
  • À quel rythme devez-vous lancer le basculement ? Quel est votre objectif de temps de récupération (RTO) ?

Les éléments suivants contribuent au temps de récupération et doivent être pris en compte dans l'estimation de votre RTO :

  • Détection de la panne
  • Préparation de l'instance de machine virtuelle (VM) secondaire
  • Basculement de l'espace de stockage
  • Temps de récupération de la base de données
  • Temps de récupération de l'application

Architectures MySQL haute disponibilité

Sur le plan le plus élémentaire, la haute disponibilité au niveau des données englobe les éléments suivants :

  • Un mécanisme permettant de déterminer qu'une défaillance du nœud source s'est produite
  • Un processus permettant d'effectuer un basculement où le nœud d'instance dupliquée est promu au rang de nœud source
  • Un processus permettant de modifier le routage des requêtes afin que les requêtes d'application atteignent le nouveau nœud source
  • La possibilité d'employer une méthode permettant de revenir à la topologie d'origine à l'aide des nœuds source et d'instance dupliquée

Ce document traite des trois architectures haute disponibilité suivantes :

En plus de la défaillance de l'infrastructure, chacune de ces architectures peut contribuer à minimiser les temps d'arrêt dans l'éventualité peu probable d'une panne de zone. Afin d'assurer une protection contre les interruptions de service régionales, vous pouvez modifier le système de noms de domaine (DNS) associé à ces architectures pour fournir une haute disponibilité multirégionale. Ce sujet n'entre pas dans le cadre de ce document.

Haute disponibilité avec des disques persistants régionaux

La haute disponibilité au niveau des données repose toujours sur un certain type de réplication des données. La réplication la plus simple est celle que vous n'avez pas à gérer.

L'option de disque persistant régional de Compute Engine vous permet de provisionner un appareil de stockage de blocs qui assure une réplication de données synchrone entre deux zones d'une même région. Les disques persistants régionaux constituent un composant de base essentiel pour la mise en œuvre de services à haute disponibilité dans Compute Engine.

Le schéma suivant illustre l'architecture haute disponibilité avec des disques persistants régionaux.

Architecture faisant appel à des disques persistants régionaux pour fournir la haute disponibilité

Si l'instance de VM de votre nœud source devient indisponible en raison d'une défaillance de l'infrastructure ou d'une panne de zone, vous pouvez forcer l'association du volume Persistent Disk régional à une instance de VM située dans votre zone de sauvegarde de la même région.

Pour ce faire, vous devez effectuer l'une des opérations suivantes :

  • Démarrez une autre instance de VM dans la zone de sauvegarde où l'accès au disque persistant régional partagé est disponible.
  • Gardez une instance de VM de secours à chaud dans la zone de sauvegarde. Une instance de VM de secours à chaud est une instance de VM en cours d'exécution qui est identique à l'instance que vous utilisez. Après avoir associé le disque persistant régional, vous pouvez démarrer le moteur de la base de données.

Si la panne du service de données est rapidement identifiée, l'opération d'association forcée prend généralement moins d'une minute, ce qui permet d'atteindre un RTO de l'ordre de quelques minutes.

Si votre entreprise peut tolérer le temps d'arrêt supplémentaire nécessaire pour détecter une panne, la communiquer et effectuer le basculement manuellement, il n'est pas nécessaire d'automatiser le processus.

Si votre tolérance en termes de RTO est inférieure, vous pouvez automatiser le processus de détection et de basculement. Si vous automatisez cette architecture, le système devient plus complexe, car vous devez prendre en compte plusieurs cas particuliers pour le processus de basculement et de remplacement. Pour plus d'informations sur une mise en œuvre entièrement automatisée de cette architecture, consultez la page qui traite de la configuration de la haute disponibilité pour Cloud SQL.

Avantages

L'utilisation de disques persistants régionaux pour obtenir la haute disponibilité présente plusieurs avantages en raison des caractéristiques suivantes :

  • Cette architecture offre une protection simultanée contre plusieurs modes de défaillance : défaillance de l'infrastructure de serveur de la zone principale, dégradation du stockage de blocs dans une seule zone ou panne d'une zone entière.
  • La réplication de la couche d'application ou de la base de données n'est pas nécessaire, car les disques persistants régionaux offrent une réplication continue et synchrone des données au niveau du bloc, qui est entièrement gérée par Google Cloud. Un disque persistant régional détecte automatiquement les erreurs et les ralentissements, change de mode de réplication et récupère les données répliquées sur une seule zone.
  • En cas de problèmes de stockage dans une zone principale, un disque persistant régional effectue automatiquement des opérations de lecture à partir d'une zone secondaire. Cette opération peut entraîner une augmentation de la latence de lecture, mais votre application peut continuer à fonctionner sans intervention manuelle.

Remarques

Les limites de cette architecture sont liées à la nature même de cette topologie déployée sur une région unique et à certaines des contraintes inhérentes aux disques persistants régionaux :

  • Le disque persistant régional ne peut être installé que sur une seule base de données. Même si l'instance de VM de base de données de secours est en cours d'exécution, cette instance ne peut pas être utilisée pour répondre à des requêtes de lecture de base de données.
  • La technologie à la base de cette architecture ne permet la réplication qu'entre les zones d'une même région. Par conséquent, le basculement régional avec cette seule architecture n'est pas possible.
  • Le débit en écriture du disque persistant régional est réduit de moitié par rapport aux disques persistants zonaux. Assurez-vous que les limites de débit respectent la tolérance requise.
  • La latence d'écriture du disque persistant régional est légèrement supérieure à celle du disque persistant zonal. Nous vous recommandons de tester votre charge de travail pour vérifier que les performances d'écriture sont acceptables pour vos besoins.
  • En cas de défaillance et de basculement, vous devez forcer l'association du disque persistant régional à la VM de secours. L'opération d'association forcée s'exécute généralement en moins d'une minute. Vous devez donc prendre en compte ce délai lorsque vous évaluez votre RTO.
  • L'estimation du RTO doit tenir compte du temps nécessaire à l'association forcée du disque persistant régional et à la détection par le système de fichiers de la VM du disque associé à chaud.

Haute disponibilité avec un nœud témoin et de secours à chaud (hot-standby)

Si vous souhaitez automatiser le basculement, vous avez besoin d'une architecture différente. Une option consiste à déployer un groupe d'au moins deux nœuds de base de données, à configurer la réplication asynchrone de la base de données et à lancer des nœuds témoins pour s'assurer qu'un quorum peut être atteint lors d'une élection de nœud source.

Le nœud de base de données source traite les transactions d'écriture et répond aux requêtes de lecture. Le processus de réplication de la base de données transmet les modifications au nœud d'instance dupliquée de secours à chaud en ligne.

Comme le nœud témoin peut être une petite machine virtuelle, il fournit un mécanisme peu coûteux permettant de s'assurer qu'une majorité dans le groupe est réunie pour une élection du nœud source.

Les nœuds du groupe évaluent en permanence l'état des autres nœuds du groupe. Les signaux que ces vérifications d'état consomment toutes les quelques secondes sont appelés pulsations, car ils sont utilisés pour évaluer l'état des autres nœuds du groupe. L'évaluation rapide de l'état des nœuds de la base de données est importante, car un nœud de base de données source non opérationnel doit être identifié rapidement de sorte que le basculement de l'instance de secours à chaud puisse être lancé.

Le quorum d'un groupe de nœuds est déterminé par le nombre d'éléments votants qui doivent être membre d'un cluster actif pour que ce cluster démarre correctement ou continue de s'exécuter. Pour qu'un groupe de nœuds puisse atteindre un quorum dans une élection de nœud de base de données source, la majorité des nœuds du groupe doit participer. Dans une optique de protection contre une condition de split-brain, l'exigence de majorité garantit que, dans le cas d'une partition de réseau, deux groupes de votants ne puissent pas disposer en même temps d'un nombre suffisant de nœuds pour voter.

Une majorité de groupe est composée de (n+1)/2 nœuds, où n est le nombre total de nœuds dans le groupe. Par exemple, si un groupe comporte trois nœuds, au moins deux nœuds doivent participer à l'élection du nœud source. Si un groupe comporte cinq nœuds, au moins trois nœuds sont nécessaires.

Les groupes sont dimensionnés avec un nombre impair de nœuds au cas où une partition réseau empêcherait la communication entre les sous-groupes du groupe de nœuds. Si le groupe est en nombre pair, il y a plus de chances qu'aucun des sous-groupes n'obtienne la majorité. Si le groupe est en nombre impair, il y a plus de chances que l'un des sous-groupes ait la majorité, ou qu'aucun des deux ne l'obtienne.

Le schéma suivant compare un groupe de nœuds opérationnel avec un groupe de nœuds dégradé.

Architecture comparant un groupe de nœuds opérationnel avec un groupe de nœuds dégradé

Le schéma montre deux groupes de nœuds : un fonctionnel et un dégradé. Le groupe de nœuds entièrement fonctionnel et sain dispose de trois membres. Dans cet état, les nœuds source et d'instance dupliquée de la base de données remplissent leurs objectifs. Le quorum nécessaire pour ce groupe de nœuds est de deux nœuds.

Le groupe de nœuds dégradé affiche l'état indiquant que les pulsations du nœud source ne sont plus envoyées en raison d'une défaillance de l'infrastructure. Cet état peut être le résultat d'une défaillance de l'instance du nœud de base de données source, mais le nœud principal peut très bien être encore en cours d'exécution. Une partition réseau peut également empêcher la communication entre le nœud source et les autres nœuds du groupe.

Quelle que soit la cause, le résultat est que le nœud d'instance dupliquée et le nœud témoin déterminent que le nœud source n'est plus opérationnel. À ce stade, la majorité du groupe effectue une élection du nœud source, détermine que le nœud de secours à chaud doit devenir le nœud source et lance un basculement.

Le schéma suivant montre la transaction de base de données, la réplication et le flux de pulsations dans l'architecture des nœuds témoin.

Architecture d'utilisation de nœuds témoins et de secours à chaud pour obtenir la haute disponibilité

Dans le diagramme précédent, cette architecture haute disponibilité s'appuie sur le nœud d'instance dupliquée de secours à chaud pour lancer rapidement le traitement des écritures de production après un basculement. Les mécanismes de basculement (par exemple, la promotion du nœud source) sont exécutés par les nœuds de base de données du groupe.

Pour mettre en œuvre une telle architecture, prenez en compte les deux projets suivants :

Avantages

L'architecture de secours à chaud présente peu d'éléments mobiles et peut être déployée facilement. Elle offre plusieurs avantages :

  • Avec un seul nœud témoin à faible coût supplémentaire, un basculement entièrement automatisé est possible.
  • Cette architecture permet de résoudre une défaillance d'infrastructure à long terme aussi facilement qu'une défaillance temporaire (consécutive à un redémarrage du système, par exemple).
  • Moyennant une certaine latence de réplication, la haute disponibilité multirégionale est assurée.

Remarques

Le basculement est automatique, mais les tâches opérationnelles suivantes demeurent :

  • Vous devez gérer la réplication entre le nœud source et le nœud d'instance dupliquée.
  • Vous devez gérer les nœuds témoins.
  • Vous devez déployer et gérer le routage de la connexion à l'aide d'un équilibreur de charge.
  • Sans modifications de votre logique d'application, éléments qui n'entrent pas dans le cadre de ce document, vous ne pouvez pas diriger les opérations de lecture vers le nœud d'instance dupliquée.

Haute disponibilité avec Orchestrator et ProxySQL

Si vous combinez les composants Open Source Orchestrator et ProxySQL, vous disposez d'une architecture capable de détecter les pannes et de lancer automatiquement le basculement du trafic à partir d'un nœud source défaillant vers une instance dupliquée saine récemment promue.

De plus, vous pouvez acheminer de manière transparente les requêtes vers les nœuds de lecture ou d'écriture appropriés, afin d'améliorer les performances du niveau des données en état stable.

Orchestrator est un gestionnaire de topologie de réplication MySQL et une solution de basculement Open Source. Ce logiciel vous permet de détecter, d'interroger et de refactoriser des topologies de réplication complexes. Il fournit également une détection fiable des défaillances, une récupération intelligente et un mécanisme de promotion.

ProxySQL est un proxy Open Source hautes performances et à disponibilité élevée compatible avec le protocole de base de données MySQL. ProxySQL peut gérer des millions de connexions sur des centaines de milliers de serveurs backend.

Le schéma suivant illustre l'architecture combinée Orchestrator/ProxySQL.

Architecture combinant Orchestrator et ProxySQL pour obtenir la haute disponibilité

Dans cette architecture, comme illustré par le schéma précédent, le trafic lié à la base de données est acheminé par un équilibreur de charge interne vers des instances ProxySQL redondantes. Ces instances acheminent le trafic vers une instance de base de données accessible en écriture ou en lecture basée sur la configuration ProxySQL.

Orchestrator gère les étapes de détection et de récupération suivantes :

  1. Orchestrator détermine que le nœud de base de données source n'est pas disponible.
  2. Tous les nœuds d'instances dupliquées sont interrogés afin de fournir un deuxième avis sur l'état du nœud source.
  3. Si les nœuds d'instances dupliquées fournissent une évaluation cohérente sur l'indisponibilité du nœud source, le basculement est lancé.
  4. Comme défini par la topologie, le nœud promu devient le nouveau nœud source pendant le basculement.
  5. À la fin du basculement, Orchestrator permet de s'assurer que le nombre correct de nouveaux nœuds de réplication est provisionné conformément à la topologie.

La réplication continue entre la base de données source dans la zone A et les instances dupliquées de la base de données dans les autres zones maintient les instances dupliquées à jour en leur transférant toutes les écritures acheminées vers la base de données source. Orchestrator vérifie l'état des bases de données source et dupliquée en envoyant des pulsations en continu. L'état de l'application Orchestrator est conservé dans une base de données Cloud SQL distincte. Si des modifications de la topologie sont nécessaires, Orchestrator peut également envoyer des commandes aux bases de données.

ProxySQL achemine le trafic de manière appropriée vers les nouveaux nœuds source et d'instance dupliquée une fois le basculement terminé. Les services poursuivent le traitement au niveau des données à l'aide de l'adresse IP de l'équilibreur de charge. L'adresse IP virtuelle est basculée sans interruption de l'ancien nœud source au nouveau nœud source.

Avantages

Les composants de l'architecture et l'automatisation offrent les avantages suivants :

  • Le logiciel utilisé dans cette architecture fournit diverses fonctionnalités d'observabilité, y compris des graphiques de la topologie de réplication, ainsi qu'une visibilité sur le trafic de requêtes.
  • ProxySQL et Orchestrator se coordonnent pour assurer la promotion et le basculement automatiques de l'instance dupliquée.
  • La règle de promotion des instances dupliquées est entièrement configurable. Contrairement à d'autres configurations de haute disponibilité, vous pouvez décider de promouvoir un nœud d'instance dupliquée spécifique en nœud source en cas de basculement.
  • Après un basculement, les nouvelles instances dupliquées sont provisionnées de manière déclarative en fonction de la topologie.
  • ProxySQL présente l'avantage supplémentaire de fournir un équilibrage de charge qui permet d'acheminer de manière transparente les requêtes de lecture et d'écriture vers les nœuds d'instances dupliquées et le nœud source appropriés en fonction des règles configurées.

Points à prendre en compte

Cette architecture accroît la responsabilité opérationnelle et entraîne des coûts d'hébergement supplémentaires pour les raisons suivantes :

  • Orchestrator et ProxySQL doivent être déployés et administrés.
  • Orchestrator nécessite une base de données distincte pour la maintenance de l'état.
  • Orchestrator et ProxySQL doivent être configurés pour la haute disponibilité, ce qui engendre une complexité de configuration et de déploiement accrue.

De plus, Orchestrator n'est pas compatible avec les réplications multisources, n'accepte pas tous les types de réplication parallèle et ne peut pas être associé à des logiciels de clustering tels que Galera ou Percona XtraDB. Pour en savoir plus sur les limites actuelles, consultez les questions fréquentes sur Orchestrator.

Étape suivante