Chez Citymobil, nous utilisons une base de données MySQL comme principal stockage de données persistantes. Nous disposons de plusieurs clusters de bases de données pour divers services et objectifs.

La disponibilité constante du maître est un indicateur critique des performances de l'ensemble du système et de ses différentes parties. La récupération automatique du cluster en cas de panne du maître réduit considérablement le temps de réponse aux incidents et les temps d'arrêt du système. Dans cet article, j'examinerai une conception haute disponibilité (HA) pour un cluster MySQL basé sur Orchestrateur MySQL et adresses IP virtuelles (VIP).

Solution HA basée sur VIP

Tout d’abord, je vais vous expliquer brièvement quel est notre système de stockage de données.

Nous utilisons un schéma de réplication classique avec un maître accessible en écriture et plusieurs répliques en lecture seule. Un cluster peut contenir un maître intermédiaire, un nœud qui est à la fois une réplique et un maître pour les autres. Les clients accèdent aux réplicas via HAProxy, ce qui permet une répartition uniforme de la charge et une mise à l'échelle facile. L'utilisation de HAProxy est due à des raisons historiques et nous sommes actuellement en train de migrer vers ProxySQL.

La réplication est effectuée en mode semi-synchrone basé sur GTID. Cela signifie qu'au moins un réplica doit enregistrer une transaction avant qu'elle soit considérée comme réussie. Ce mode de réplication offre un équilibre optimal entre performances et sécurité des données en cas de panne du nœud maître. Fondamentalement, toutes les modifications sont transférées du maître vers les répliques à l'aide de Row Based Replication (RBR), mais certains nœuds peuvent avoir mixed binlog format.

L'orchestrateur met périodiquement à jour l'état de la topologie du cluster, analyse les informations reçues et, si des problèmes surviennent, il peut lancer une procédure de récupération automatique. Le développeur est responsable de la procédure elle-même, puisqu'elle peut être mise en œuvre de différentes manières : sur la base de VIP, DNS, en utilisant des services de découverte de services ou des mécanismes auto-écrits.

Un moyen simple de restaurer un maître en cas d'échec consiste à utiliser des adresses VIP flottantes.

Ce qu’il faut savoir sur cette solution avant d’aller de l’avant :

• Une VIP est une adresse IP qui n'est pas associée à une interface réseau physique spécifique. En cas de panne d'un nœud ou lors d'une maintenance planifiée, nous pouvons basculer le VIP vers une autre ressource avec un temps d'arrêt minimal.
• Libérer et émettre une adresse IP virtuelle est une opération rapide et peu coûteuse.
• Pour travailler avec VIP, vous devez accéder au serveur via SSH ou utiliser des utilitaires spéciaux, par exemple, keepalived.

Examinons les problèmes possibles avec notre assistant et imaginons comment devrait fonctionner le mécanisme de récupération automatique.

La connectivité réseau au maître a disparu ou un problème est survenu au niveau matériel et le serveur est indisponible

1. L'orchestrateur met à jour la topologie du cluster, chaque réplica signale que le maître est indisponible. L'orchestrateur démarre le processus de sélection d'une réplique adaptée au rôle du nouveau maître et commence la récupération.
2. Nous essayons de supprimer le VIP de l'ancien maître - sans succès.
3. La réplique passe au rôle de maître. La topologie est en cours de reconstruction.
4. Ajout d'une nouvelle interface réseau avec VIP. Comme il n'a pas été possible de supprimer le VIP, nous commençons périodiquement à envoyer une demande en arrière-plan ARP gratuit. Ce type de requête/réponse vous permet de mettre à jour la table de mappage des adresses IP et MAC sur les commutateurs connectés, vous avertissant ainsi du déplacement de notre VIP. Cela minimise la probabilité split brain au retour du vieux maître.
5. Toutes les nouvelles connexions sont immédiatement redirigées vers le nouveau maître. Les anciennes connexions échouent et des appels répétés à la base de données sont effectués au niveau de l'application.

Le serveur fonctionne en mode normal, une panne est survenue au niveau du SGBD

L'algorithme est similaire au cas précédent : mise à jour de la topologie et démarrage du processus de récupération. Puisque le serveur est disponible, nous libérons avec succès le VIP sur l'ancien maître, le transférons vers le nouveau et envoyons plusieurs requêtes ARP. Le retour éventuel de l'ancien maître ne devrait pas affecter le cluster reconstruit et le fonctionnement de l'application.

D'autres problèmes

Défaillance des répliques ou des maîtres intermédiaires ne mène pas à des actions automatiques et nécessite une intervention manuelle.

Une interface réseau virtuelle est toujours ajoutée temporairement, c'est-à-dire qu'après un redémarrage du serveur, le VIP n'est pas automatiquement attribué. Chaque instance de base de données démarre en mode lecture seule par défaut, l'orchestrateur bascule automatiquement le nouveau maître en écriture et tente de l'installer. read only sur le vieux maître. Ces actions visent à réduire la probabilité split brain.

Des problèmes peuvent survenir pendant le processus de récupération, qui doivent également être notifiés via l'interface utilisateur de l'orchestrateur en plus des outils de surveillance standard. Nous avons étendu l'API REST en ajoutant cette fonctionnalité (PR actuellement en cours de révision).

Le schéma général de la solution HA est présenté ci-dessous.

Choisir un nouveau maître

L'orchestrateur est assez intelligent et essaie de choisir la réplique la plus adaptée en tant que nouveau master selon les critères suivants :

• la réplique est en retard sur le maître ;
• Version MySQL du maître et de la réplique ;
• type de réplication (RBR, SBR ou mixte) ;
• emplacement dans le même centre de données ou dans des centres de données différents ;
• disponibilité errant GTID — les transactions qui ont été exécutées sur la réplique et ne sont pas sur le maître ;
• des règles de sélection personnalisées sont également prises en compte.

Tous les indices ne sont pas des candidats idéaux pour un maître. Par exemple, une réplique peut être utilisée pour sauvegarder des données ou le serveur a une configuration matérielle plus faible. Orchestrateur soutient le des règles manuelles avec lesquelles vous pouvez personnaliser vos préférences de sélection de candidats, du plus préféré au plus ignoré.

Temps de réponse et de récupération

En cas d'incident, il est important de minimiser les temps d'arrêt du système, considérons donc les paramètres MySQL qui affectent la création et la mise à jour de la topologie du cluster par l'orchestrateur :

• slave_net_timeout — le nombre de secondes pendant lesquelles la réplique attend que de nouvelles données ou un signal de battement de cœur arrivent du maître avant que la connexion ne soit reconnue comme perdue et reconnectée. Plus la valeur est faible, plus le réplica peut déterminer rapidement que la communication avec le maître est interrompue. Nous fixons cette valeur à 5 secondes.
• MASTER_CONNECT_RETRY — nombre de secondes entre les tentatives de reconnexion. En cas de problèmes de réseau, une valeur faible pour ce paramètre permettra une reconnexion rapide et empêchera le démarrage du processus de récupération du cluster. La valeur recommandée est de 1 seconde.
• MASTER_RETRY_COUNT — nombre maximum de tentatives de reconnexion.
• MASTER_HEARTBEAT_PERIOD — intervalle en secondes après lequel le maître envoie un signal de battement de cœur. La valeur par défaut est la moitié de la valeur slave_net_timeout.

Options de l'orchestrateur :

• DelayMasterPromotionIfSQLThreadNotUpToDate - si égal true, le rôle de maître ne sera pas appliqué sur le réplica candidat tant que le thread SQL du réplica n'aura pas terminé toutes les transactions non appliquées du journal de relais. Nous utilisons cette option pour éviter de perdre des transactions lorsque toutes les répliques candidates prennent du retard.
• InstancePollSeconds — fréquence de construction et de mise à jour de la topologie.
• RecoveryPollSeconds — fréquence de l'analyse topologique. Si un problème est détecté, la récupération de la topologie est lancée. Ce constant, égal à 1 seconde.

Chaque nœud de cluster est interrogé par l'orchestrateur une fois par mois. InstancePollSeconds secondes Lorsqu'un problème est détecté, l'état du cluster est forcé mis à jour, puis la décision finale est prise d'effectuer une récupération. En expérimentant différents paramètres de base de données et d'orchestrateur, nous avons pu réduire le temps de réponse et de récupération à 30 secondes.

banc d'essai

Nous avons commencé à tester le système HA avec le développement d'un système local banc d'essai et une mise en œuvre ultérieure dans des environnements de test et de production. Le stand local est entièrement automatisé basé sur Docker et vous permet d'expérimenter la configuration de l'orchestrateur et du réseau, de faire passer le cluster de 2-3 serveurs à plusieurs dizaines et de réaliser des exercices dans un environnement sécurisé.

Pendant les exercices, nous choisissons l'une des méthodes d'émulation du problème : tirez instantanément sur le maître en utilisant kill -9, terminez doucement le processus et arrêtez le serveur (docker-compose stop), simulez des problèmes de réseau à l'aide iptables -j REJECT ou iptables -j DROP. Nous attendons les résultats suivants :

• l'orchestrateur détectera les problèmes avec le maître et mettra à jour la topologie en 10 secondes maximum ;
• la procédure de récupération démarrera automatiquement : la configuration du réseau changera, le rôle du maître passera au réplica, la topologie sera reconstruite ;
• le nouveau maître deviendra accessible en écriture, les répliques actives ne seront pas perdues pendant le processus de reconstruction ;
• les données commenceront à être écrites sur le nouveau maître et répliquées ;
• Le temps total de récupération ne dépassera pas 30 secondes.

Comme vous le savez, le système peut se comporter différemment dans les environnements de test et de production en raison de différentes configurations matérielles et réseau, des différences de charge synthétique et réelle, etc. C'est pourquoi nous effectuons périodiquement des exercices en conditions réelles, vérifiant le comportement du système en cas de perte de connectivité du réseau ou de dégradation de ses différentes parties. À l’avenir, nous souhaitons construire une infrastructure complètement identique pour les deux environnements et automatiser ses tests.

résultats

La santé du nœud principal du système de stockage est l’une des tâches principales de l’équipe SRE et des opérations. La mise en place de l'orchestrateur et de la solution HA basée sur VIP nous a permis d'atteindre les résultats suivants :

• détection fiable des problèmes avec la topologie du cluster de bases de données ;
• réponse automatique et rapide aux incidents liés au maître, réduisant ainsi les temps d'arrêt du système.

Cependant, la solution a ses limites et ses inconvénients :

• l'extension du système HA à plusieurs centres de données nécessitera un seul réseau L2 entre eux ;
• Avant d'attribuer VIP sur le nouveau maître, nous devons le libérer sur l'ancien. Le processus est séquentiel, ce qui augmente le temps de récupération ;
• la libération du VIP nécessite un accès SSH au serveur ou toute autre méthode d'appel de procédures distantes. Étant donné que le serveur ou la base de données rencontre des problèmes qui ont provoqué le processus de récupération, nous ne pouvons pas être sûrs que la suppression du VIP se terminera avec succès. Et cela peut conduire à l'apparition de deux serveurs avec la même adresse IP virtuelle et à un problème split brain.

Éviter split brain, vous pouvez utiliser la méthode STONITH (« Shoot The Other Node In The Head »), qui isole ou désactive complètement le nœud problématique. Il existe d'autres moyens de mettre en œuvre la haute disponibilité d'un cluster : une combinaison de VIP et DNS, de services de découverte de services et de proxy, de réplication synchrone et d'autres méthodes qui ont leurs propres inconvénients et avantages.

J'ai parlé de notre approche pour créer un cluster de basculement MySQL. Il est facile à mettre en œuvre et offre un niveau de fiabilité acceptable dans les conditions actuelles. À mesure que l’ensemble du système en général et les infrastructures en particulier se développeront, cette approche évoluera sans aucun doute.

Source: habr.com