Équilibrage de charge MariaDB MaxScale sur Docker :gestion :deuxième partie

Cet article de blog est la suite de MariaDB MaxScale Load Balancing  on Docker :Deployment - Part1. Dans cette partie, nous allons nous concentrer davantage sur les opérations de gestion avec des cas d'utilisation avancés comme le contrôle des services, la gestion de la configuration, le traitement des requêtes, la sécurité et la réconciliation des clusters. Les exemples d'étapes et d'instructions présentés dans cet article sont basés sur les environnements d'exécution que nous avons configurés dans la première partie de cette série de blogs.

Contrôle des services

Pour MaxScale, démarrer et arrêter le conteneur est le seul moyen de contrôler le service. Si le conteneur a été créé, nous pouvons utiliser la commande suivante pour gérer le service :

$ docker start maxscale
$ docker stop maxscale
$ docker restart maxscale

Exécution sans privilèges root

Les conteneurs Docker s'exécutent par défaut avec le privilège root, tout comme l'application qui s'exécute à l'intérieur du conteneur. Il s'agit d'une autre préoccupation majeure du point de vue de la sécurité, car les pirates peuvent obtenir un accès root à l'hôte Docker en piratant l'application exécutée à l'intérieur du conteneur.

Pour exécuter Docker en tant qu'utilisateur non root, vous devez ajouter votre utilisateur au groupe docker. Tout d'abord, créez un groupe docker s'il n'y en a pas :

$ sudo groupadd docker

Ensuite, ajoutez votre utilisateur au groupe docker. Dans cet exemple, notre utilisateur est "vagabond":

$ sudo usermod -aG docker vagrant

Déconnectez-vous et reconnectez-vous afin que votre appartenance au groupe soit réévaluée (ou redémarrez si cela ne fonctionne pas). À ce stade, vous pouvez exécuter le conteneur MaxScale avec la commande d'exécution standard (aucun sudo requis) en tant qu'utilisateur "vagrant" :

$ docker run -d \
--name maxscale-unprivileged \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale

Le processus MaxScale est exécuté par l'utilisateur "maxscale" et ne nécessite aucun privilège spécial jusqu'au niveau racine. Ainsi, exécuter le conteneur en mode non privilégié est toujours le meilleur moyen si vous êtes préoccupé par la sécurité.

Gestion des configurations

Pour le conteneur MaxScale autonome, la gestion de la configuration nécessite la modification du fichier de configuration mappé, suivie du redémarrage du conteneur MaxScale. Cependant, si vous exécutez en tant que service Docker Swarm, la nouvelle configuration doit être chargée dans les configurations Swarm en tant que nouvelle version, par exemple :

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

Ensuite, mettez à jour le service en supprimant les anciennes configurations (maxscale_config) et ajoutez la nouvelle (maxscale_config_v2) à la même cible :

$ docker service update \
--config-rm maxscale_config \
--config-add source=maxscale_config_v2,target=/etc/maxscale.cnf \
maxscale-cluster

Docker Swarm planifiera ensuite le retrait et le remplacement des conteneurs un conteneur à la fois jusqu'à ce que l'exigence de répliques soit satisfaite.

Mise à niveau et rétrogradation

L'un des avantages de l'exécution de vos applications dans Docker est la procédure de mise à niveau et de rétrogradation triviale. Chaque conteneur en cours d'exécution est basé sur une image, et cette image peut être changée facilement avec la balise image. Pour obtenir la liste des images disponibles pour MaxScale, consultez la section Balises dans le Docker Hub. Les exemples suivants montrent le processus de rétrogradation d'un MaxScale 2.3 vers une version mineure antérieure, 2.2 :

$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.3
$ docker rm -f maxscale
$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.2

Assurez-vous que les options de configuration sont compatibles avec la version que vous souhaitez exécuter. Par exemple, la rétrogradation ci-dessus échouerait lors de la première exécution en raison des erreurs suivantes :

2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'master_reconnection' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'master_reconnection'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'delayed_retry' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'delayed_retry'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'transaction_replay_max_size' for object 'rw-service' of type 'service', or '1Mi' is an invalid value for parameter 'transaction_replay_max_size'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'transaction_replay' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'transaction_replay'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads_timeout' for object 'rw-service' of type 'service', or '10' is an invalid value for parameter 'causal_reads_timeout'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'causal_reads'.

Ce que nous devons faire est de supprimer les options de configuration non prises en charge comme indiqué ci-dessus dans le fichier de configuration avant de rétrograder l'image du conteneur :

• master_reconnection
• delayed_retry
• transaction_replay
• causal_reads_timeout
• causal_reads

Enfin, redémarrez le conteneur et vous devriez être bon. La mise à niveau de version pour MaxScale fonctionne de manière similaire. Changez simplement la balise que vous souhaitez utiliser et c'est parti.

Filtres MaxScale

MaxScale utilise un composant appelé filtre pour manipuler ou traiter les requêtes lorsqu'elles le traversent. Il existe un tas de filtres que vous pouvez utiliser, comme indiqué dans cette page, les filtres MaxScale 2.3. Par exemple, une requête spécifique peut être enregistrée dans un fichier si elle correspond à un critère ou vous pouvez réécrire la requête entrante avant qu'elle n'atteigne les serveurs principaux.

Pour activer un filtre, vous devez définir une section et inclure le nom de la définition dans la définition de service correspondante, comme indiqué dans les exemples plus bas.

Journalisation de toutes les requêtes (QLA)

Comme son nom l'indique, le filtre QLA enregistre toutes les requêtes correspondant à l'ensemble de règles par session client. Toutes les requêtes seront enregistrées en suivant le format de base de fichier.

Tout d'abord, définissez le composant avec type=filter et module=qlafilter :

## Query Log All (QLA) filter
## Filter module for MaxScale to log all query content on a per client session basis
[qla-sbtest-no-pk]
type		= filter
module		= qlafilter
filebase	= /tmp/sbtest
match		= select.*from.*
exclude		= where.*id.*
user		= sbtest

Ajoutez ensuite le composant de filtrage dans nos services :

[rw-service]
...
filters        = qla-sbtest-no-pk
[rr-service]
...
filters        = qla-sbtest-no-pk

C'est également une bonne idée de mapper /tmp du conteneur avec le répertoire réel sur l'hôte Docker, afin que nous n'ayons pas à accéder au conteneur pour récupérer les fichiers journaux générés. Tout d'abord, créez un répertoire et accordez une autorisation globale en écriture :

$ mkdir qla
$ chmod 777 qla

Puisque nous devons lier le répertoire ci-dessus dans le conteneur, nous devons arrêter et supprimer le conteneur en cours d'exécution et le relancer avec la commande suivante :

$ docker stop maxscale
$ docker run -d \
--name maxscale \
--restart always \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
-v $PWD/qla:/tmp \
mariadb/maxscale

Vous pouvez ensuite récupérer le contenu des requêtes journalisées dans le répertoire qla :

$ cat qla/*
Date,[email protected],Query
2019-06-18 08:25:13,[email protected]::ffff:192.168.0.19,select * from sbtest.sbtest1

Réécriture de requête

La réécriture de requête est une fonctionnalité qui, en fonction des requêtes exécutées sur le serveur de base de données, permet rapidement d'isoler et de corriger les requêtes problématiques et d'améliorer les performances.

La réécriture des requêtes peut être effectuée via regexfilter. Ce filtre peut faire correspondre ou exclure les instructions entrantes à l'aide d'expressions régulières et les remplacer par une autre instruction. Chaque règle est définie dans sa propre section et inclut le nom de la section dans le service correspondant pour l'activer.

Le filtre suivant correspondra à un certain nombre de commandes SHOW que nous ne voulons pas exposer aux clients en lecture seule :

## Rewrite query based on regex match and replace
[block-show-commands]
type            = filter
module          = regexfilter
options         = ignorecase
match           = ^show (variables|global variables|global status|status|processlist|full processlist).*
replace         = SELECT 'Not allowed'

Ensuite, nous pouvons ajouter le filtre au service que nous voulons appliquer. Par exemple, toutes les connexions en lecture seule doivent être filtrées pour ce qui précède :

[rr-service]
...
filters        = qla-sbtest-no-pk | block-show-commands

Gardez à l'esprit que plusieurs filtres peuvent être définis à l'aide d'une syntaxe semblable au tube shell Linux "|" syntaxe. Redémarrez le conteneur pour appliquer les modifications de configuration :

$ docker restart maxscale

Nous pouvons alors vérifier avec la requête suivante :

$ mysql -usbtest -p -h192.168.0.200 -P4006 -e 'SHOW VARIABLES LIKE "max_connections"'
+-------------+
| Not allowed |
+-------------+
| Not allowed |
+-------------+

Vous obtiendrez le résultat attendu.

Récupération de cluster

MaxScale 2.2.2 et versions ultérieures prennent en charge la réplication automatique ou manuelle de MariaDB ou la récupération de cluster pour les événements suivants :

• basculement
• basculement
• rejoindre
• réinitialiser la réplication

Le basculement du cluster maître-esclave peut et doit souvent être configuré pour s'activer automatiquement. Le basculement doit être activé manuellement via MaxAdmin, MaxCtrl ou l'interface REST. Rejoindre peut être réglé sur automatique ou activé manuellement. Ces fonctionnalités sont implémentées dans le module "mariadbmon".

Les événements de basculement automatique suivants se sont produits si nous avons délibérément arrêté le maître actif, 192.168.0.91 :

$ docker logs -f maxscale
...
2019-06-19 03:53:02.348   error  : (mon_log_connect_error): Monitor was unable to connect to server mariadb1[192.168.0.91:3306] : 'Can't connect to MySQL server on '192.168.0.91' (115)'
2019-06-19 03:53:02.351   notice : (mon_log_state_change): Server changed state: mariadb1[192.168.0.91:3306]: master_down. [Master, Running] -> [Down]
2019-06-19 03:53:02.351   warning: (handle_auto_failover): Master has failed. If master status does not change in 4 monitor passes, failover begins.
2019-06-19 03:53:16.710   notice : (select_promotion_target): Selecting a server to promote and replace 'mariadb1'. Candidates are: 'mariadb2', 'mariadb3'.
2019-06-19 03:53:16.710   warning: (warn_replication_settings): Slave 'mariadb2' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   warning: (warn_replication_settings): Slave 'mariadb3' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   notice : (select_promotion_target): Selected 'mariadb2'.
2019-06-19 03:53:16.711   notice : (handle_auto_failover): Performing automatic failover to replace failed master 'mariadb1'.
2019-06-19 03:53:16.723   notice : (redirect_slaves_ex): Redirecting 'mariadb3' to replicate from 'mariadb2' instead of 'mariadb1'.
2019-06-19 03:53:16.742   notice : (redirect_slaves_ex): All redirects successful.
2019-06-19 03:53:17.249   notice : (wait_cluster_stabilization): All redirected slaves successfully started replication from 'mariadb2'.
2019-06-19 03:53:17.249   notice : (handle_auto_failover): Failover 'mariadb1' -> 'mariadb2' performed.
2019-06-19 03:53:20.363   notice : (mon_log_state_change): Server changed state: mariadb2[192.168.0.92:3306]: new_master. [Slave, Running] -> [Master, Running]

Une fois le basculement terminé, notre topologie ressemble maintenant à ceci :

Pour l'opération de basculement, cela nécessite une intervention humaine et une façon de le faire via la console MaxCtrl. Supposons que l'ancien maître soit de nouveau opérationnel et prêt à être promu en tant que maître, nous pouvons effectuer l'opération de basculement en envoyant la commande suivante :

$ docker exec -it maxscale maxctrl
maxctrl: call command mariadbmon switchover monitor mariadb1 mariadb2
OK

Où, le formatage est :

$ call command <monitoring module> <operation> <monitoring section name> <new master> <current master>

Ensuite, vérifiez la nouvelle topologie en répertoriant les serveurs :

 maxctrl: list servers
┌──────────┬──────────────┬──────┬─────────────┬─────────────────┬──────────────┐
│ Server   │ Address      │ Port │ Connections │ State           │ GTID         │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb1 │ 192.168.0.91 │ 3306 │ 0           │ Master, Running │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb2 │ 192.168.0.92 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb3 │ 192.168.0.93 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
└──────────┴──────────────┴──────┴─────────────┴─────────────────┴──────────────┘

Nous venons de promouvoir notre ancien maître à son emplacement d'origine. Fait amusant, la fonction de récupération automatique de ClusterControl fait exactement la même chose si elle est activée.

Réflexions finales

L'exécution de MariaDB MaxScale sur Docker apporte des avantages supplémentaires tels que le clustering MaxScale, la facilité de mise à niveau et de rétrogradation, ainsi que des fonctionnalités avancées de proxy pour les clusters MySQL et MariaDB.