Dans le blog précédent de la série, nous avons discuté des avantages et des inconvénients de l'utilisation de Galera Cluster pour créer un cluster géodistribué. Dans cet article, nous allons concevoir un cluster géo-distribué basé sur Galera et nous montrerons comment vous pouvez déployer toutes les pièces requises à l'aide de ClusterControl.
Concevoir un cluster Galera géo-distribué
Nous allons commencer par expliquer l'environnement que nous voulons construire. Nous utiliserons trois centres de données distants, connectés via un réseau étendu (WAN). Chaque centre de données recevra les écritures des serveurs d'applications locaux. Les lectures seront également uniquement locales. Ceci est destiné à éviter le trafic inutile traversant le WAN.
Pour cette configuration, la connectivité est en place et sécurisée, mais nous ne décrirons pas exactement comment cela peut être réalisé. Il existe de nombreuses méthodes pour sécuriser la connectivité en commençant par des solutions matérielles et logicielles propriétaires via OpenVPN et en terminant par des tunnels SSH.
Nous utiliserons ProxySQL comme loadbalancer. ProxySQL sera déployé localement dans chaque datacenter. Il acheminera également le trafic uniquement vers les nœuds locaux. Les nœuds distants peuvent toujours être ajoutés manuellement et nous expliquerons les cas où cela pourrait être une bonne solution. L'application peut être configurée pour se connecter à l'un des nœuds ProxySQL locaux à l'aide de l'algorithme round-robin. Nous pouvons également utiliser Keepalived et Virtual IP pour acheminer le trafic vers le seul nœud ProxySQL, tant qu'un seul nœud ProxySQL serait capable de gérer tout le trafic.
Une autre solution possible consiste à colocaliser ProxySQL avec des nœuds d'application et à configurer l'application pour qu'elle se connecte au proxy sur l'hôte local. Cette approche fonctionne assez bien sous l'hypothèse qu'il est peu probable que ProxySQL ne soit pas disponible alors que l'application fonctionnerait correctement sur le même nœud. Généralement, ce que nous voyons est soit une panne de nœud, soit une panne de réseau, ce qui affecterait à la fois ProxySQL et l'application.
Le diagramme ci-dessus montre la version de l'environnement, où ProxySQL est colocalisé sur le même nœud que l'application. ProxySQL est configuré pour répartir la charge de travail sur tous les nœuds Galera du centre de données local. L'un de ces nœuds serait choisi comme nœud pour envoyer les écritures tandis que les SELECT seraient distribués sur tous les nœuds. Le fait d'avoir un nœud d'écriture dédié dans un centre de données permet de réduire le nombre de conflits de certification possibles, ce qui se traduit généralement par de meilleures performances. Pour réduire encore plus cela, nous devrions commencer à envoyer le trafic via la connexion WAN, ce qui n'est pas idéal car l'utilisation de la bande passante augmenterait considérablement. À l'heure actuelle, avec les segments en place, seules deux copies du jeu d'écriture sont envoyées dans les centres de données :une par DC.
Le principal problème avec les déploiements géo-distribués de Galera Cluster est la latence. C'est quelque chose que vous devez toujours tester avant de lancer l'environnement. Suis-je d'accord avec le temps de commit ? À chaque validation, une certification doit avoir lieu, de sorte que les jeux d'écriture doivent être envoyés et certifiés sur tous les nœuds du cluster, y compris les nœuds distants. Il se peut que la latence élevée rende la configuration inadaptée à votre application. Dans ce cas, vous pouvez trouver plusieurs clusters Galera connectés via une réplication asynchrone plus appropriés. Ce serait un sujet pour un autre article de blog cependant.
Déploiement d'un cluster Galera géo-distribué à l'aide de ClusterControl
Pour clarifier les choses, nous allons montrer ici à quoi peut ressembler un déploiement. Nous n'utiliserons pas de configuration multi-DC réelle, tout sera déployé dans un laboratoire local. Nous supposons que la latence est acceptable et que l'ensemble de la configuration est viable. Ce qui est génial avec ClusterControl, c'est qu'il est indépendant de l'infrastructure. Peu importe si les nœuds sont proches les uns des autres, situés dans le même centre de données ou si les nœuds sont répartis sur plusieurs fournisseurs de cloud. Tant qu'il existe une connectivité SSH de l'instance ClusterControl à tous les nœuds, le processus de déploiement est exactement le même. C'est pourquoi nous pouvons vous le montrer étape par étape en utilisant uniquement un laboratoire local.
Installation de ClusterControl
Tout d'abord, vous devez installer ClusterControl. Vous pouvez le télécharger gratuitement. Après l'enregistrement, vous devez accéder à la page avec un guide pour télécharger et installer ClusterControl. C'est aussi simple que d'exécuter un script shell. Une fois que vous avez installé ClusterControl, un formulaire vous sera présenté pour créer un utilisateur administratif :
Une fois que vous le remplissez, un écran de bienvenue s'affiche et vous accédez aux assistants de déploiement :
Nous allons procéder au déploiement. Cela ouvrira un assistant de déploiement :
Nous choisirons MySQL Galera. Nous devons transmettre les détails de connectivité SSH - l'utilisateur root ou l'utilisateur sudo sont pris en charge. À l'étape suivante, nous devons définir les serveurs dans le cluster.
Nous allons déployer trois nœuds dans l'un des centres de données. Ensuite, nous pourrons étendre le cluster, en configurant de nouveaux nœuds dans différents segments. Pour l'instant, tout ce que nous avons à faire est de cliquer sur "Déployer" et de regarder ClusterControl déployer le cluster Galera.
Nos trois premiers nœuds sont opérationnels, nous pouvons maintenant procéder à l'ajout nœuds supplémentaires dans d'autres centres de données.
Vous pouvez le faire à partir du menu d'action, comme indiqué sur la capture d'écran ci-dessus .
Ici, nous pouvons ajouter des nœuds supplémentaires, un à la fois. Ce qui est important, vous devez changer le segment Galera en non nul (0 est utilisé pour les trois nœuds initiaux).
Après un certain temps, nous nous retrouvons avec les neuf nœuds, répartis sur trois segments.
Maintenant, nous devons déployer la couche proxy. Nous utiliserons ProxySQL pour cela. Vous pouvez le déployer dans ClusterControl via Gérer -> Load Balancer :
Ceci ouvre un champ de déploiement :
Tout d'abord, nous devons décider où déployer ProxySQL. Nous utiliserons les nœuds Galera existants, mais vous pouvez taper n'importe quoi dans le champ, il est donc parfaitement possible de déployer ProxySQL au-dessus des nœuds d'application. De plus, vous devez transmettre les informations d'identification d'accès pour l'utilisateur administratif et de surveillance.
Ensuite, nous devons soit choisir l'un des utilisateurs existants dans MySQL, soit en créer un tout de suite. Nous voulons également nous assurer que ProxySQL est configuré pour utiliser des nœuds Galera situés uniquement dans le même centre de données.
Lorsque vous avez un ProxySQL prêt dans le centre de données, vous pouvez l'utiliser comme source de configuration :
Cela doit être répété pour chaque serveur d'application que vous avez dans tous les centres de données . Ensuite, l'application doit être configurée pour se connecter à l'instance ProxySQL locale, idéalement via le socket Unix. Cela s'accompagne des meilleures performances et de la latence la plus faible.
Une fois le dernier ProxySQL déployé, notre environnement est prêt. Les nœuds d'application se connectent au ProxySQL local. Chaque ProxySQL est configuré pour fonctionner avec les nœuds Galera dans le même centre de données :
Conclusion
Nous espérons que cette série en deux parties vous a aidé à comprendre les forces et les faiblesses des clusters Galera géo-distribués et comment ClusterControl facilite le déploiement et la gestion d'un tel cluster.
