Comment optimiser les performances de ClusterControl et de ses composants

La surveillance et la gestion sont essentielles à tout environnement de production car les performances sont importantes. Des interfaces utilisateur lentes qui sont en retard ou qui ne répondent pas, des alertes retardées et des délais d'expiration des tâches de cluster lorsque le serveur manque de ressources sont autant de facteurs qui peuvent causer des problèmes. Il existe des moyens d'améliorer les performances de ClusterControl, en particulier si vous gérez plusieurs clusters et que chaque cluster contient plusieurs nœuds. Ce blog fournit quelques conseils de réglage. Les points élaborés ici sont organisés en fonction de notre expérience en matière de problèmes de performances signalés par nos utilisateurs et clients.

En guise d'introduction, ClusterControl se compose de plusieurs composants principaux - une application Web (frontend) basée sur PHP et un certain nombre de processus démonisés (backend). Ceux-ci exploitent une base de données MySQL/MariaDB pour le stockage persistant. Vous contrôlez efficacement votre cluster à partir de l'application Web, qui sera traduite en une série d'appels de processus exécutés par les processus backend pour gérer et surveiller vos clusters de bases de données.

Base de données MySQL

Les composants de ClusterControl s'appuient sur une base de données MySQL ou MariaDB comme magasin persistant pour surveiller les données collectées à partir des nœuds gérés et de toutes les métadonnées de ClusterControl (par exemple, quels travaux il y a dans la file d'attente, les planifications de sauvegarde, les statuts de sauvegarde, etc.). Par défaut, le script d'installation installera la version fournie par le référentiel standard du système d'exploitation. Voici la version de MySQL/MariaDB en cours d'installation par le programme d'installation :

• CentOS/Redhat 6 - MySQL 5.1

• CentOS/Redhat 7 - MariaDB 5.5

• Ubuntu 18.04 (Bionic) - MySQL 5.7

• Ubuntu 16.04 (Xenial) - MySQL 5.7

• Ubuntu 14.04 (Trusty) - MySQL 5.5

• Debian 9 (Stretch) - MySQL 5.5

• Debian 8 (Jessie) - MySQL 5.5

• Debian 7 (Wheezy) - MySQL 5.5

Le script d'installation effectuerait des réglages de base comme la configuration de l'emplacement du répertoire de données, du port MySQL, de l'utilisateur et de la taille du pool de mémoire tampon InnoDB au début de l'étape d'installation. Cependant, le réglage peut ne pas convenir une fois que vous avez importé ou créé plus de clusters/nœuds. Avec un nombre accru de nœuds à surveiller et à gérer, ClusterControl utiliserait plus de ressources, et la couche de base de données est généralement le premier goulot d'étranglement rencontré par les utilisateurs. Des ajustements supplémentaires peuvent être nécessaires pour contenir la charge entrante.

ClusterControl est suffisamment intelligent pour détecter toute anomalie de performances en écrivant les lignes suivantes dans cmon_X.log (où X est l'ID du cluster) :

2018-11-28 01:30:00 : (INFO) CmonSheetManager at 0x3839af0 loaded 70 values for key 'diskstat' between 2018-11-23 01:30:00 - 2018-11-28 01:30:0
0.
2018-11-28 01:30:00 : (INFO) SQL processing: 220.0000ms
2018-11-28 01:30:00 : (INFO) Parsing       : 0.0000ms
2018-11-28 01:30:00 : (INFO) Sum           : 220.0000ms

Ce qui précède signifie simplement qu'il a fallu 220 ms (valeur somme) pour charger 70 valeurs pour le composant "diskstat", où la majeure partie du temps de traitement se produisait à l'étape de traitement SQL et 0 ms pour analyser le jeu de résultats SQL Cela conclut que la couche SQL a pris la majeure partie du temps de traitement lorsque ClusterControl a tenté d'interroger l'ensemble de données.

Nous pensons que la plupart des requêtes SQL exécutées par ClusterControl sont correctement optimisées pour une seule instance MySQL et utilisent une indexation appropriée. En termes simples, si vous voyez apparaître régulièrement quelque chose comme ci-dessus dans le fichier journal, certaines améliorations de la couche de base de données sont nécessaires, comme indiqué dans les sections suivantes.

Réglage de la taille du pool de tampons InnoDB

La taille du pool de tampons est un élément important et doit être configurée à l'avance pour améliorer les performances de MySQL. Cela permet au traitement MySQL de se dérouler dans la mémoire au lieu de toucher le disque. Une règle simple consiste à vérifier le taux de réussite d'InnoDB et à rechercher la ligne suivante dans la section BUFFER POOL AND MEMORY :

Buffer pool hit rate 986 / 1000

Le taux de réussite de 986 / 1 000 indique que sur 1 000 lectures de ligne, il a pu lire la ligne dans la RAM 986 fois. Les 14 fois restantes, il a dû lire la ligne de données du disque. En termes simples, 1000/1000 est la meilleure valeur que nous essayons d'atteindre ici, ce qui signifie que les données fréquemment consultées tiennent entièrement dans la RAM.

Augmenter la valeur innodb_buffer_pool_size aidera beaucoup à laisser plus de place à MySQL pour travailler. Cependant, assurez-vous d'avoir suffisamment de ressources RAM au préalable. Par défaut, ClusterControl alloue 50 % de la RAM au pool de mémoire tampon. Si l'hôte est dédié à ClusterControl, vous pouvez même le pousser à une valeur supérieure comme 70 %, à condition de laisser au moins 2 Go de RAM aux processus et aux caches du système d'exploitation. Si vous ne pouvez pas en allouer autant, augmenter la RAM est la seule solution.

La modification de cette valeur nécessite un redémarrage de MySQL (plus ancien que MySQL 5.7.5), donc l'ordre de redémarrage correct du service sera :

1. Modifier la valeur innodb_buffer_pool_size dans my.cnf.
2. Arrêtez le service CMON.
3. Redémarrez le service MySQL/MariaDB.
4. Démarrez le service CMON.

Ou redémarrez simplement l'hôte si vous pouvez vous permettre un temps d'arrêt plus long.

Régler max_connections

Par défaut, le script d'installation configurera la valeur max_connections jusqu'à 512. C'est plutôt élevé, bien que raisonnable, puisque ClusterControl atteint à peine 200 connexions au total, sauf si le serveur MySQL est partagé avec d'autres applications ou si vous avez des dizaines de nœuds MySQL surveillés par ClusterControl (on parle de 30 nœuds et plus).

Une valeur max_connections élevée gaspille des ressources et l'ajustement de la valeur affectera la mémoire maximale configurée pour MySQL. Si elle est supérieure à la RAM système, il est possible que le processus du serveur MySQL se termine avec une exception OOM, si toutes les connexions sont utilisées.

Pour vérifier cela, recherchez simplement le statut MySQL de max_used_connections. Voici les connexions maximales jamais atteintes par MySQL sur un nœud ClusterControl qui surveille 2 clusters avec 6 nœuds MySQL au total :

mysql> SHOW STATUS like 'max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 43    |
+----------------------+-------+

Une bonne valeur pour commencer est Max_used_connections x 2, et augmentez-la progressivement si la valeur augmente constamment. La modification de la variable max_connections peut être effectuée dynamiquement via l'instruction SET GLOBAL.

Utilisation du fichier socket MySQL

Par défaut, le script d'installation configurera automatiquement la valeur d'hôte suivante dans chaque fichier de configuration de base de données ClusterControl :

Ce qui précède forcera le client MySQL à se connecter via le réseau TCP, tout comme la connexion à un hôte MySQL distant, bien que ClusterControl s'exécute sur le même serveur que le serveur MySQL. Nous l'avons volontairement configuré de cette manière pour simplifier le processus d'installation, car presque chaque plate-forme de système d'exploitation pré-configure différemment le fichier de socket MySQL, ce qui réduit considérablement le taux d'échec de l'installation.

Changer la valeur en "localhost" forcera le client à utiliser le fichier de socket MySQL Unix à la place :

Sur les systèmes basés sur Unix, les programmes MySQL traitent le nom d'hôte localhost spécialement, d'une manière qui est probablement différente de ce que vous attendez par rapport aux autres programmes basés sur le réseau. Pour les connexions à localhost, les programmes MySQL tentent de se connecter au serveur local en utilisant un fichier socket Unix. Cela se produit même si une option --port ou -P est donnée pour spécifier un numéro de port.

L'utilisation du fichier de socket MySQL UNIX est beaucoup plus sécurisée et réduira la surcharge du réseau. Il est toujours recommandé sur TCP. Cependant, vous devez vous assurer que le fichier socket est correctement configuré. Il doit exister sur les directives suivantes dans my.cnf et tous les fichiers d'options MySQL sur le nœud ClusterControl, par exemple :

[mysqld]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

[mysql]
socket=/var/lib/mysql/mysql.sock

[mysqldump]
socket=/var/lib/mysql/mysql.sock

La modification du fichier de socket nécessitera également un redémarrage de MySQL et CMON. Si vous utilisez le "localhost", vous pouvez alors ajouter des options de configuration supplémentaires comme skip-networking=1, pour empêcher l'acceptation des connexions à distance. Notre image ClusterControl Docker utilise cette approche pour surmonter une limitation de docker-proxy lors de la liaison sur les ports.

OpenSSH avec SSSD

ClusterControl utilise le protocole SSH comme canal de communication principal pour gérer et surveiller les nœuds distants. Les configurations OpenSSH par défaut sont assez correctes et devraient fonctionner dans la plupart des cas. Cependant, dans certains environnements où SSH est intégré à d'autres outils d'amélioration de la sécurité tels que SElinux ou System Security Services Daemon (SSSD), cela peut avoir un impact significatif sur les performances de SSH.

Nous avons vu de nombreux cas où un nombre toujours croissant de connexions SSH établies pour chacun des nœuds gérés et finalement, le serveur ClusterControl et tous les nœuds gérés maximisent leur mémoire système avec des connexions SSH. Dans certains cas, seul un redémarrage normal complet du système tous les soirs sur le serveur ClusterControl peut résoudre le problème.

Si vous exécutez votre infrastructure avec System Security Services Daemon (SSSD), il est conseillé de commenter la ligne suivante dans la configuration du client OpenSSH dans /etc/ssh/ssh_config sur le nœud ClusterControl :

#ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Ce qui précède ignorera l'utilisation de SSSD pour gérer la clé d'hôte, qui sera gérée par le client OpenSSH à la place.

À partir de ClusterControl 1.7.0, vous avez la possibilité d'utiliser l'outil de surveillance basé sur agent avec Prometheus. Avec la surveillance basée sur l'agent, ClusterControl n'utilise pas SSH pour échantillonner les métriques de l'hôte, ce qui peut être excessif dans certains environnements.

Système de fichiers et partitionnement

Le contrôleur ClusterControl écrit une nouvelle entrée dans son fichier journal presque toutes les secondes pour chaque cluster. Pour ceux qui souhaitent profiter de ces écritures séquentielles sur disque et souhaitent faire des économies, vous pouvez utiliser un disque à broche à cet effet. Modifiez la ligne suivante dans tout cmon_X.cnf :

logfile=/new/partition/log/cmon_X.log

Remplacez X par l'ID de cluster et redémarrez le service CMON pour appliquer les modifications.

Si vous utilisez ClusterControl comme référentiel de sauvegarde, il est recommandé d'allouer suffisamment d'espace disque sur une partition distincte autre que la partition racine. Cela s'améliore si la partition réside sur un système de fichiers en réseau ou en cluster pour un montage facile avec les nœuds ciblés lors de l'exécution de l'opération de restauration. Nous avons vu des cas où les sauvegardes créées occupaient tout l'espace disque de la partition principale, affectant finalement ClusterControl et ses composants.

Tenir à jour

ClusterControl a un cycle de publication court - au moins une nouvelle version majeure chaque trimestre de l'année plus des correctifs de maintenance hebdomadaires (principalement des corrections de bogues - le cas échéant). La raison en est que ClusterControl prend en charge plusieurs fournisseurs et versions de bases de données, systèmes d'exploitation et plates-formes matérielles. Il y a souvent de nouvelles choses introduites et d'anciennes choses obsolètes par rapport à ce qui est fourni. ClusterControl doit suivre tous les changements introduits par les fournisseurs d'applications et suivre les meilleures pratiques à chaque fois.

Nous recommandons aux utilisateurs de toujours utiliser la dernière version de ClusterControl (la mise à niveau est facile) avec le dernier navigateur Web (construit et testé sur Google Chrome et Mozilla Firefox), car nous profitons très probablement de les nouvelles fonctionnalités disponibles dans la dernière version.

Réflexions finales

Si vous avez des questions ou rencontrez des problèmes ou des problèmes de lenteur lors de l'utilisation de ClusterControl, veuillez nous contacter via notre canal d'assistance. Les suggestions et les commentaires sont les bienvenus.

Bon réglage !