Choix de votre topologie HA
Il existe différentes manières de conserver une haute disponibilité avec les bases de données. Vous pouvez utiliser des adresses IP virtuelles (VRRP) pour gérer la disponibilité des hôtes, vous pouvez utiliser des gestionnaires de ressources comme Zookeeper et Etcd pour (re)configurer vos applications ou utiliser des équilibreurs de charge/proxy pour répartir la charge de travail sur tous les hôtes disponibles.
Les adresses IP virtuelles ont besoin d'une application pour les gérer (MHA, Orchestrator), de scripts (Keepalived, Pacemaker/Corosync) ou d'un ingénieur pour basculer manuellement et la prise de décision dans le processus peut devenir complexe. Le basculement IP virtuel est un processus simple et direct en supprimant l'adresse IP d'un hôte, en l'attribuant à un autre et en utilisant l'arping pour envoyer une réponse ARP gratuite. En théorie, une adresse IP virtuelle peut être déplacée en une seconde, mais il faudra quelques secondes avant que l'application de gestion du basculement soit sûre que l'hôte a échoué et agisse en conséquence. En réalité, cela devrait se situer entre 10 et 30 secondes. Une autre limitation des adresses IP virtuelles est que certains fournisseurs de cloud ne vous permettent pas de gérer vos propres adresses IP virtuelles ou de les attribuer du tout. Par exemple, Google ne vous permet pas de faire cela sur leurs nœuds de calcul.
Les gestionnaires de ressources comme Zookeeper et Etcd peuvent surveiller vos bases de données et (re)configurer vos applications une fois qu'un hôte tombe en panne ou qu'un esclave est promu maître. En général, c'est une bonne idée, mais la mise en œuvre de vos contrôles avec Zookeeper et Etcd est une tâche complexe.
Un équilibreur de charge ou un proxy se placera entre l'application et l'hôte de la base de données et fonctionnera de manière transparente comme si le client se connectait directement à l'hôte de la base de données. Tout comme avec l'adresse IP virtuelle et les gestionnaires de ressources, les équilibreurs de charge et les proxys doivent également surveiller les hôtes et rediriger le trafic si un hôte est en panne. ClusterControl prend en charge deux proxys :HAProxy et ProxySQL et les deux sont pris en charge pour la réplication maître-esclave MySQL et le cluster Galera. HAProxy et ProxySQL ont tous deux leurs propres cas d'utilisation, nous les décrirons également dans cet article.
Pourquoi avez-vous besoin d'un équilibreur de charge ?
En théorie, vous n'avez pas besoin d'un équilibreur de charge, mais en pratique, vous en préférerez un. Nous allons vous expliquer pourquoi.
Si vous avez configuré des adresses IP virtuelles, tout ce que vous avez à faire est de pointer votre application vers la bonne adresse IP (virtuelle) et tout devrait bien se passer en termes de connexion. Mais supposons que vous ayez augmenté le nombre de réplicas en lecture, vous souhaiterez peut-être également fournir des adresses IP virtuelles pour chacun de ces réplicas en lecture pour des raisons de maintenance ou de disponibilité. Cela peut devenir un très grand pool d'adresses IP virtuelles que vous devez gérer. Si l'un de ces réplicas en lecture a échoué, vous devez réattribuer l'adresse IP virtuelle à un autre hôte, sinon votre application se connectera à un hôte en panne ou, dans le pire des cas, à un serveur en retard avec des données obsolètes. Il est donc nécessaire de conserver l'état de la réplication vers l'application gérant les IP virtuelles.
Aussi pour Galera, il y a un défi similaire :vous pouvez en théorie ajouter autant d'hôtes que vous le souhaitez à la configuration de votre application et en choisir un au hasard. Le même problème se pose lorsque cet hôte est en panne :vous risquez de vous connecter à un hôte indisponible. L'utilisation de tous les hôtes pour les lectures et les écritures peut également entraîner des retours en arrière en raison du verrouillage optimiste dans Galera. Si deux connexions tentent d'écrire sur la même ligne en même temps, l'une d'entre elles recevra une annulation. Si votre charge de travail comporte de telles mises à jour simultanées, il est conseillé de n'utiliser qu'un seul nœud dans Galera pour écrire. Par conséquent, vous souhaitez un gestionnaire qui assure le suivi de l'état interne de votre cluster de bases de données.
HAProxy et ProxySQL vous offriront tous deux la fonctionnalité de surveiller les hôtes de base de données MySQL/MariaDB et de conserver l'état de votre cluster et sa topologie. Pour les configurations de réplication, si un réplica esclave est en panne, HAProxy et ProxySQL peuvent redistribuer les connexions vers un autre hôte. Mais si un maître de réplication est en panne, HAProxy refusera la connexion et ProxySQL renverra une erreur appropriée au client. Pour les configurations Galera, les deux équilibreurs de charge peuvent choisir un nœud maître du cluster Galera et envoyer uniquement les opérations d'écriture à ce nœud spécifique.
En surface, HAProxy et ProxySQL peuvent sembler être des solutions similaires, mais ils diffèrent beaucoup par leurs fonctionnalités et la manière dont ils distribuent les connexions et les requêtes. HAProxy prend en charge un certain nombre d'algorithmes d'équilibrage tels que moindres connexions, source, aléatoire et round-robin tandis que ProxySQL distribue les connexions à l'aide de l'algorithme round-robin basé sur le poids (un poids égal signifie une distribution égale). Étant donné que ProxySQL est un proxy intelligent, il est conscient de la base de données et est également capable d'analyser vos requêtes. ProxySQL est capable d'effectuer un fractionnement en lecture/écriture basé sur des règles de requête où vous pouvez transmettre les requêtes aux esclaves ou au maître désignés dans votre cluster. ProxySQL inclut des fonctionnalités supplémentaires telles que la réécriture des requêtes, la mise en cache et le pare-feu des requêtes avec génération de statistiques approfondies en temps réel sur la charge de travail.
Cela devrait suffire à fournir des informations générales sur ce sujet. Voyons donc comment vous pouvez déployer à la fois des équilibreurs de charge pour la réplication MySQL et les topologies Galera.
Déployer HAProxy
Utiliser ClusterControl pour déployer HAProxy sur un cluster Galera est simple :accédez au cluster concerné et sélectionnez "Ajouter un équilibreur de charge" :
Et vous pourrez déployer une instance HAProxy en ajoutant l'adresse de l'hôte et en sélectionnant les instances de serveur que vous souhaitez inclure dans la configuration :
Par défaut, l'instance HAProxy sera configurée pour envoyer des connexions aux instances de serveur recevant le moins de connexions, mais vous pouvez modifier cette stratégie en tourniquet ou en source.
Dans les paramètres avancés, vous pouvez définir des délais d'expiration, un nombre maximal de connexions et même sécuriser le proxy en ajoutant une plage d'adresses IP pour les connexions.
Sous l'onglet des nœuds de ce cluster, le nœud HAProxy apparaît :
Désormais, votre cluster Galera est également disponible via le nœud HAProxy nouvellement déployé sur le port 3307. N'oubliez pas d'ACCORDER l'accès à votre application à partir de l'IP HAProxy, car le trafic arrivera désormais du proxy au lieu des hôtes de l'application. N'oubliez pas non plus de faire pointer votre connexion d'application vers le nœud HAProxy.
Supposons maintenant que l'instance de serveur tombe en panne, HAProxy le remarquera en quelques secondes et arrêtera d'envoyer du trafic vers cette instance :
Les deux autres nœuds fonctionnent toujours bien et continueront à recevoir du trafic. Ainsi, le cluster reste hautement disponible sans que le client ne remarque la différence.
Déploiement d'un nœud HAProxy secondaire
Maintenant que nous avons déplacé la responsabilité de maintenir la haute disponibilité sur les connexions de base de données du client vers HAProxy, que se passe-t-il si le nœud proxy meurt ? La réponse est de créer une autre instance HAProxy et d'utiliser une IP virtuelle contrôlée par Keepalived comme indiqué dans ce schéma :
L'avantage par rapport à l'utilisation d'adresses IP virtuelles sur les nœuds de la base de données est que la logique de MySQL se situe au niveau du proxy et que le basculement des proxys est simple.
Déployons donc un nœud HAProxy secondaire :
Après avoir déployé un nœud HAProxy secondaire, nous devons ajouter Keepalived :
Et après l'ajout de Keepalived, l'aperçu de vos nœuds ressemblera à ceci :
Alors maintenant, au lieu de pointer directement vos connexions d'application vers le nœud HAProxy, vous devez les pointer vers l'adresse IP virtuelle à la place.
Dans l'exemple ici, nous avons utilisé des hôtes distincts pour exécuter HAProxy, mais vous pouvez également facilement les ajouter à des instances de serveur existantes. HAProxy n'apporte pas beaucoup de surcharge, même si vous devez garder à l'esprit qu'en cas de panne du serveur, vous perdrez à la fois le nœud de la base de données et le proxy.
Déployer ProxySQL
Le déploiement de ProxySQL sur votre cluster se fait de manière similaire à HAProxy :"Ajouter un équilibreur de charge" dans la liste des clusters sous l'onglet ProxySQL.
Dans l'assistant de déploiement, indiquez où ProxySQL sera installé, l'utilisateur/mot de passe d'administration, l'utilisateur/mot de passe de surveillance pour se connecter aux backends MySQL. À partir de ClusterControl, vous pouvez soit créer un nouvel utilisateur à utiliser par l'application (l'utilisateur sera créé à la fois sur MySQL et ProxySQL) ou utiliser les utilisateurs de la base de données existante (l'utilisateur sera créé sur ProxySQL uniquement). Définissez si vous utilisez ou non des transactions implicites. Fondamentalement, si vous n'utilisez pas SET autocommit=0 pour créer une nouvelle transaction, ClusterControl configurera le fractionnement lecture/écriture.
Une fois ProxySQL déployé, il sera disponible sous l'onglet Nœuds :
L'ouverture de la vue d'ensemble du nœud ProxySQL vous présentera l'interface de surveillance et de gestion de ProxySQL, il n'y a donc plus aucune raison de se connecter à ProxySQL sur le nœud. ClusterControl couvre la plupart des statistiques importantes de ProxySQL telles que l'utilisation de la mémoire, le cache de requêtes, le processeur de requêtes, etc., ainsi que d'autres métriques telles que les groupes d'hôtes, les serveurs principaux, les résultats des règles de requête, les principales requêtes et les variables ProxySQL. Dans l'aspect de gestion ProxySQL, vous pouvez gérer les règles de requête, les serveurs principaux, les utilisateurs, la configuration et le planificateur directement depuis l'interface utilisateur.
Consultez notre page de didacticiel ProxySQL qui explique en détail comment effectuer l'équilibrage de charge de base de données pour MySQL et MariaDB avec ProxySQL.
Déployer Garbd
Galera implémente un algorithme basé sur un quorum pour sélectionner un composant principal à travers lequel il applique la cohérence. Le composant principal doit avoir la majorité des voix (50 % + 1 nœud), donc dans un système à 2 nœuds, il n'y aurait pas de majorité, ce qui entraînerait un cerveau divisé. Heureusement, il est possible d'ajouter un garbd (Galera Arbitrator Daemon), qui est un démon léger sans état qui peut agir comme un nœud impair. L'avantage supplémentaire de l'ajout de Galera Arbitrator est que vous pouvez désormais le faire avec seulement deux nœuds dans votre cluster.
Si ClusterControl détecte que votre cluster Galera se compose d'un nombre pair de nœuds, vous recevrez un avertissement/conseil de ClusterControl pour étendre le cluster à un nombre impair de nœuds :
Choisissez judicieusement l'hôte sur lequel déployer garbd, car il recevra toutes les données répliquées. Assurez-vous que le réseau peut gérer le trafic et qu'il est suffisamment sécurisé. Vous pouvez choisir l'un des hôtes HAProxy ou ProxySQL sur lequel déployer garbd, comme dans l'exemple ci-dessous :
Notez qu'à partir de ClusterControl 1.5.1, garbd ne peut pas être installé sur le même hôte que ClusterControl en raison du risque de conflits de packages.
Après avoir installé garbd, vous le verrez apparaître à côté de vos deux nœuds Galera :
Réflexions finales
Nous vous avons montré comment rendre vos configurations de cluster MySQL maître-esclave et Galera plus robustes et conserver une haute disponibilité à l'aide de HAProxy et ProxySQL. Garbd est également un joli démon qui peut enregistrer le troisième nœud supplémentaire dans votre cluster Galera.
Ceci finalise le côté déploiement de ClusterControl. Dans notre prochain blog, nous vous montrerons comment intégrer ClusterControl au sein de votre organisation en utilisant des groupes et en attribuant certains rôles aux utilisateurs.
