Explication du cadre de haute disponibilité MySQL - Partie I :Introduction

Dans cette série de blogs en trois parties, nous expliquerons les détails et les fonctionnalités d'un cadre de haute disponibilité (HA) pour l'hébergement MySQL utilisant la réplication semi-synchrone MySQL et la pile Corosync plus Pacemaker. Dans la première partie, nous vous expliquerons les bases de la haute disponibilité, les composants d'un framework HA, puis nous vous présenterons le framework HA pour MySQL.

Qu'est-ce que la haute disponibilité ?

La disponibilité d'un système informatique est le pourcentage de temps pendant lequel ses services sont actifs pendant une période de temps. Il est généralement exprimé par une série de 9. Par exemple, le tableau ci-dessous montre la disponibilité et le temps d'arrêt correspondant mesuré sur un an.

La signification de la haute disponibilité varie en fonction des exigences de votre application et de votre entreprise. Par exemple, si vous ne pouvez pas vous permettre un temps d'arrêt de plus de quelques minutes par an dans votre service, nous disons que le service doit avoir une haute disponibilité de 99,999 %.

Composants d'un framework HA

L'essence d'être hautement disponible est la capacité de récupérer instantanément des pannes qui peuvent se produire dans n'importe quelle partie d'un système. Il existe quatre composants essentiels dans tout framework HA qui doivent fonctionner ensemble de manière automatisée pour permettre cette capacité de récupération. Examinons ces composants en détail :

1. Redondance dans l'infrastructure et les données

Pour qu'un service soit hautement disponible, il faut s'assurer qu'il y a une redondance dans l'infrastructure d'hébergement ainsi qu'une redondance à jour copie des données que le service utilise ou fournit. Cela agit comme un service de secours prêt à prendre le relais au cas où le primaire serait impacté par des pannes.

2. Mécanisme de détection et de correction des pannes

Il est extrêmement important de détecter immédiatement toute défaillance dans n'importe quelle partie du système principal qui pourrait avoir un impact sur sa disponibilité. Cela permettra à la structure de prendre des mesures correctives sur le même système principal ou de basculer les services vers un système de secours.

3. Mécanisme de basculement

Ce composant gère la responsabilité de basculer les services vers votre infrastructure de secours. Veuillez noter que dans le cas où plusieurs systèmes redondants sont disponibles, ce composant de mécanisme de basculement doit identifier le système le plus approprié parmi ceux-ci et le promouvoir en tant que service principal.

4. Mécanisme de redirection d'application/d'utilisateur

Une fois que les systèmes de secours ont pris le relais en tant que système principal, ce composant garantit que toutes les connexions d'application et d'utilisateur commencent à se produire sur le nouveau système principal.

Explication du cadre de haute disponibilité MySQL - Partie ICliquez pour tweeter

Le cadre HA pour MySQL

Sur la base du modèle ci-dessus, nous utilisons le framework HA suivant pour notre hébergement MySQL chez ScaleGrid :

• Configuration maître-esclave à 3 nœuds utilisant la réplication semi-synchrone MySQL pour assurer la redondance de l'infrastructure et des données.
• La pile Corosync plus Pacemaker pour fournir un mécanisme de détection, de correction et de basculement des pannes.
• Un mappage DNS ou un composant IP virtuel pour fournir le mécanisme de redirection des applications et des utilisateurs.

Consultez le schéma ci-dessous pour visualiser la pile logicielle de cette architecture :

Passons en revue la fonctionnalité de certains des composants clés de ce framework.

1. Corosync

   Corosync fournit un cadre de communication pour les nœuds avec un passage de messages fiable entre eux. Il forme un anneau de cluster de nœuds et assure le suivi des nœuds qui rejoignent et quittent le cluster via l'appartenance au cluster. Corosync travaille en étroite collaboration avec Pacemaker pour communiquer sur la disponibilité des nœuds afin que Pacemaker puisse prendre les décisions appropriées.

2. Stimulateur cardiaque

   Également connu sous le nom de Cluster Resource Manager (CRM), Pacemaker assure la haute disponibilité de MySQL exécuté sur le cluster et détecte et gère les défaillances au niveau des nœuds en s'interfaçant avec Corosync. Il détecte et gère également les défaillances de MySQL en s'interfaçant avec l'agent de ressources (RA). Pacemaker configure et gère la ressource MySQL via des opérations de démarrage, d'arrêt, de surveillance, de promotion et de rétrogradation.

3. Agent de ressources

   L'agent de ressources agit comme une interface entre MySQL et Pacemaker. Il met en œuvre les opérations de démarrage, d'arrêt, de promotion, de rétrogradation et de surveillance qui sont invoquées par le stimulateur cardiaque. Il existe un agent de ressources entièrement fonctionnel appelé Percona Replication Manager (PRM) pour MySQL mis en œuvre par Percona. Ceci a été amélioré par ScaleGrid et est disponible sur notre page GitHub.

4. Composant de mappage DNS

   L'agent de ressources, une fois le basculement réussi, appelle ce composant qui met à jour les enregistrements DNS du serveur MySQL maître avec l'adresse IP du nouveau maître. Notez que les clients utilisent toujours un nom DNS maître pour se connecter au serveur MySQL, et en gérant le mappage de ce nom DNS à l'adresse IP du maître actuel, nous pouvons nous assurer que les clients n'ont pas à modifier leurs chaînes de connexion ou leurs propriétés lorsque il y a un basculement.

Dans la partie II de cette série de blogs, vous découvrirez le composant critique de redondance des données obtenu à l'aide de la réplication semi-synchrone MySQL. Nous approfondirons également les détails de la réplication semi-synchrone et les configurations que nous utilisons pour atteindre notre support de haute disponibilité, et enfin, examinerons divers scénarios d'échec dans la partie III et la manière dont le framework réagit et récupère de ces conditions.