Dans notre blog précédent, nous avons discuté de ClusterControl CMON HA pour la haute disponibilité de la base de données distribuée écrit par Krzysztof Ksiazek dans deux articles distincts. Dans ce blog, nous aborderons la distribution de nœuds sur site et sur un cloud public (à l'aide de Google Cloud Platform (GCP)).
La raison pour laquelle nous avons écrit ce blog est que nous avons reçu des questions sur la façon d'implémenter une instance haute disponibilité de ClusterControl avec un ou plusieurs nœuds CMON exécutés sur site et un ou plusieurs autres nœuds CMON exécutés sur un centre de données différent (comme un cloud public). Dans notre précédent blog ClusterControl CMON HA pour la haute disponibilité des bases de données distribuées, nous utilisions des nœuds Galera Cluster, mais cette fois, nous utiliserons la réplication MySQL à l'aide de Percona Server 5.7. Une configuration idéale pour cela consiste à toujours encapsuler la communication des nœuds de votre site sur site et de vos nœuds résidant dans un cloud public via VPN ou un canal sécurisé.
ClusterControl CMON HA en est aux premiers stades pour lesquels nous pensons qu'il n'est pas encore assez mature. Pourtant, notre CMON HA est capable de vous fournir le sens des fonctionnalités pour déployer un ClusterControl afin de le rendre hautement disponible. Passons maintenant à la manière dont vous pouvez déployer et configurer la distribution des nœuds sur site via le cloud public.
Qu'est-ce qu'un CMON ?
Avant de passer au sujet principal, laissez-nous vous présenter ce qu'est CMON. CMON signifie ClusterControl Controller, qui est le « cerveau principal » de ClusterControl. Un service backend effectuant l'automatisation, la gestion, la surveillance des tâches de planification, ainsi que la disponibilité de la haute disponibilité. Les données collectées sont stockées dans la base de données CMON, pour laquelle nous utilisons des bases de données compatibles MySQL comme magasin de données.
La configuration architecturale
Certains d'entre vous ne connaissaient peut-être pas les capacités de ClusterControl qu'il peut exécuter et être configuré pour la haute disponibilité. Si vous avez plusieurs nœuds ClusterControl (ou CMON) en cours d'exécution, cela est possible sans frais. Vous pourrez peut-être exécuter des tonnes de nœuds ClusterControl chaque fois que vous en aurez besoin.
Pour cette configuration, nous aurons des nœuds ClusterControl au-dessus d'un ClusterControl afin de créer ou de déployer les nœuds de la base de données et de gérer un basculement automatique en cas de panne, par exemple. Bien que vous puissiez utiliser MHA, Orchestrator ou Maxscale pour gérer le basculement automatique, mais pour plus d'efficacité et de rapidité, j'utiliserai ClusterControl pour faire les choses spéciales que les autres outils que j'ai mentionnés n'ont pas.
Regardons donc le schéma de cette configuration :
La configuration basée sur ce diagramme montre qu'en plus de CMON à trois nœuds , un CMON (ClusterControl) en cours d'exécution est au-dessus d'eux qui surveillera le basculement automatique. Ensuite, HAProxy pourra équilibrer la charge entre les trois nœuds CMON surveillés, un nœud étant situé dans une région distincte hébergée dans GCP pour ce blog. Vous remarquerez peut-être que nous n'avons pas inclus Keepalived, car nous ne pouvons pas placer un VIP sous GCP car il se trouve sur un réseau différent.
Comme vous l'avez peut-être remarqué, nous plaçons un total de trois nœuds. CMON HA exige que nous ayons besoin d'au moins 3 nœuds pour procéder à un processus de vote ou quorum. Donc, pour cette configuration, nous vous demandons d'avoir au moins 3 nœuds pour avoir une disponibilité plus élevée.
Déploiement d'un nœud ClusterControl sur site
Dans cette section, nous supposons que vous avez déjà configuré ou installé votre interface utilisateur ClusterControl que nous utiliserons pour déployer un cluster de réplication MySQL à trois nœuds à l'aide de Percona Server.
Commençons par créer le cluster en déployant une nouvelle réplication MySQL comme indiqué ci-dessous.
Notez que j'utilise Percona Server 5.7 ici, pour lequel la valeur par défaut la configuration par ClusterControl fonctionne efficacement.
Définissez ensuite le nom d'hôte ou l'IP de vos nœuds,
À ce stade, nous supposons que vous avez déjà configuré un nœud à deux Réplication maître/esclave hébergée ou exécutée sur site. La capture d'écran ci-dessous devrait montrer à quoi ressembleront vos nœuds :
Configurer et installer ClusterControl et activer CMON HA sur le premier nœud
Dans ce blog précédent ClusterControl CMON HA pour la haute disponibilité de la base de données distribuée, nous avons brièvement expliqué comment procéder. Redescendons et suivons les étapes comme indiqué, mais pour cette configuration de réplication maître/esclave particulière.
Première chose à faire, choisissez un nœud sur lequel vous voulez que ClusterControl soit installé en premier (sur cette configuration, je finis par installer en premier sur le nœud 192.168.70.80) et suivez les étapes ci-dessous.
Première étape
Installer ClusterControl
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootNotez qu'une fois que vous êtes invité à détecter une instance mysql actuelle, vous devez laisser ClusterControl utiliser le mysqld existant en cours d'exécution, car c'est l'un de nos objectifs ici pour CMON HA et pour que cette configuration utilise le déjà configuré MySQL.
Étape 2
Liez CMON non seulement pour autoriser via l'hôte local, mais également sur l'adresse IP spécifique (puisque nous allons activer HA)
## edit /etc/default/CMON and modify the line just like below or add the line if it doesn't exist
RPC_BIND_ADDRESSES="127.0.0.1,192.168.70.80"Étape 3
Puis redémarrez CMON,
service CMON restartÉtape 4
Installer les outils CLI s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shAu cours de cette installation, l'outil s9s configurera un utilisateur administrateur pour lequel vous pourrez utiliser la commande s9s, tout comme l'activation de CMON HA.
Étape 5
Activer le CMON HA
$ s9s controller --enable-CMON-haÉtape 6
Enfin, modifiez le /etc/my.cnf et ajoutez,
slave-skip-errors = 1062sous la section [mysqld]. Une fois ajouté, n'oubliez pas de redémarrer mysql en tant que,
service mysql restartou
systemctl restart mysqlActuellement, c'est la limitation à laquelle nous sommes confrontés avec CMON HA car il essaie d'insérer des entrées de journal dans l'esclave, mais cela peut convenir pour le moment.
Configurer, installer ClusterControl et activer CMON HA sur le deuxième nœud
Simple que pour le premier nœud. Maintenant, sur le 2e nœud (192.168.70.70), nous devons suivre les mêmes étapes, mais à la place, nous devons faire quelques ajustements dans les étapes pour rendre cette haute disponibilité possible.
Première étape
Copiez la configuration sur le 2ème nœud (192.168.70.70) à partir du premier nœud (192.168.70.80)
$ scp -r /etc/CMON* 192.168.70.70:/etc/Étape 2
Dans le 2e nœud, modifiez le fichier /etc/CMON.cnf et assurez-vous que l'hôte est correctement configuré. ex.
vi /etc/CMON.cnfEnsuite, attribuez le paramètre de nom d'hôte en tant que,
hostname=192.168.70.70
Étape 3
Installer ClusterControl,
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootCependant, ignorez l'installation de CMON (ou ClusterControl Controller) une fois que vous rencontrez cette ligne,
=> An existing Controller installation detected!
=> A re-installation of the Controller will overwrite the /etc/CMON.cnf file
=> Install the Controller? (y/N):Le reste, faites comme ce que vous avez fait sur le premier nœud, comme la configuration du nom d'hôte, utilisez l'instance d'exécution mysqld existante, fournissez le mot de passe MySQL et le mot de passe pour votre CMON qui doit être les deux ont le même mot de passe avec le premier nœud.
Étape 4
Installer les outils CLI s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shÉtape 5
Copiez la configuration restante du 1er nœud vers le 2e nœud.
$ scp -r ~/.s9s/ 192.168.70.70:/root/
$ scp /etc/s9s.conf 192.168.70.70:/etc/
$ scp /var/www/html/clustercontrol/bootstrap.php 192.168.70.70:/var/www/html/clustercontrol/Étape 6
Installer le package clustercontrol-controller,
Pour Ubuntu/Debian,
$ apt install -y clustercontrol-controllerPour RHEL/CentOS/Fedora,
$ yum install -y clustercontrol-controllerÉtape 7
Copiez le fichier /etc/default/CMON et modifiez l'adresse IP pour l'adresse de liaison RPC
scp /etc/default/CMON 192.168.70.70:/etc/default
RPC_BIND_ADDRESSES="127.0.0.1,10.0.0.103"Puis redémarrez CMON comme suit,
service CMON restartÉtape huit
Modifier le /etc/my.cnf et ajouter,
slave-skip-errors = 1062sous la section [mysqld]. Une fois ajouté, n'oubliez pas de redémarrer mysql en tant que,
service mysql restartou
systemctl restart mysqlActuellement, c'est la limitation à laquelle nous sommes confrontés avec CMON HA car il essaie d'insérer des entrées de journal dans l'esclave, mais cela peut convenir pour le moment.
Étape 9
Enfin, vérifiez à quoi ressemblent les nœuds CMON HA,
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
Total: 2 controller(s)Déploiement de votre nœud ClusterControl dans le cloud
Comme nous l'avons mentionné précédemment, la configuration idéale pour la communication consiste à encapsuler les paquets via le VPN ou d'autres moyens de canal sécurisé. Si vous avez des inquiétudes sur la façon de procéder, consultez notre précédent blog Multi-DC PostgreSQL :Configuration d'un nœud de secours à une géolocalisation différente sur un VPN pour lequel nous avons abordé la manière de créer une configuration VPN simple à l'aide d'OpenVPN.
Donc, dans cette section, nous supposons que vous avez déjà configuré la connexion VPN. Maintenant, ce que nous allons faire est d'ajouter un esclave que nous sommes censés distribuer la disponibilité de CMON dans Google Cloud Platform. Pour ce faire, accédez simplement à Ajouter un esclave de réplication qui peut être trouvé en cliquant sur l'icône de cluster près du coin droit. Voyez à quoi cela ressemble ci-dessous :
Maintenant, voici comment nous allons finir avec :
Maintenant, puisque nous avons ajouté un nouvel esclave hébergé sous GCP, vous devrez peut-être suivre à nouveau ce que nous avons fait plus tôt sur le 2e nœud. Je vais vous relayer pour suivre ces étapes et suivre les instructions sur la façon dont nous avons fait sur le 2ème nœud.
Une fois que vous l'avez correctement, vous obtiendrez le résultat suivant :
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
f 1.7.5.3735 system admins 10.142.0.39 10.142.0.39 9501 Accepting heartbeats.où dans les nœuds
- 192.168.70.80 - (node8) et réside dans mon sur site
- 192.168.70.70 - (node7) et réside dans mon local
- 10.142.0.39 – (gnode1) est hébergé dans GCP et dans une autre région
CMON HA en action
Mon collègue Krzysztof Ksiazek a déjà fourni la configuration de la haute disponibilité à l'aide de HAProxy ici sur ce blog ClusterControl CMON HA pour la haute disponibilité de la base de données distribuée - Deuxième partie (configuration de l'accès à l'interface graphique).
Pour suivre la procédure indiquée dans le blog, assurez-vous d'avoir les packages xinetd et pathlib. Vous pouvez installer xinetd et pathlib comme suit,
$ sudo yum install -y xinetd python-pathlib.noarchAssurez-vous également que le CMONhachk est défini dans /etc/services comme ci-dessous :
[[email protected] ~]# grep 'CMONhachk' /etc/services
CMONhachk 9201/tcpet assurez-vous des modifications et redémarrez xinetd,
service xinetd restartJe vais ignorer la procédure Keepalived et HAProxy et je suppose que vous avez configuré en conséquence. Une chose que vous devez prendre en compte dans cette configuration est que l'utilisation de Keepalived ne peut pas être applicable si vous dispersez le VIP du réseau local au cloud public, car il s'agit d'un réseau totalement différent.
Maintenant, voyons comment CMON HA réagit si les nœuds sont en panne. Comme indiqué précédemment, le nœud 192.168.70.80 (node8) agissait en tant que leader, comme indiqué ci-dessous :
Où la base de données du nœud maître indique également que le nœud 8 est le maître de la vue de topologie de ClusterControl . Essayons de tuer node8 et voyons comment CMON HA procède,
Comme vous le voyez, gnode1 (nœud GCP) prend le relais en tant que leader lorsque node8 tombe en panne. Vérification des résultats HAProxy comme suit,
et nos nœuds ClusterControl montrent que le nœud8 est en panne, alors que le nœud GCP prend en tant que maître,
Enfin, accéder à mon nœud HAProxy qui s'exécute sur l'hôte 192.168.10.100 à le port 81 affiche l'interface utilisateur suivante,
Conclusion
Notre ClusterControl CMON HA existe depuis la version 1.7.2 mais cela a également été un défi pour nous depuis diverses questions et préférences sur la façon de le déployer, comme l'utilisation de la réplication MySQL sur Galera Cluster.
Notre CMON HA n'est pas encore mature mais il est maintenant prêt à répondre à vos besoins de haute disponibilité. Différentes approches peuvent être applicables tant que vos vérifications détermineront le bon nœud qui est opérationnel.
Nous vous encourageons à configurer et déployer à l'aide de CMON HA et faites-nous savoir si cela répond à vos besoins ou si le problème persiste, veuillez nous faire savoir comment vous aider à répondre à vos besoins de haute disponibilité.
