Les équilibreurs de charge sont un composant essentiel de toute configuration de base de données hautement disponible. Ils sont utilisés pour augmenter la capacité et la fiabilité de vos systèmes et applications critiques en empêchant la surcharge d'un serveur. Nous en parlons beaucoup sur le blog de Manynines, par exemple pourquoi vous en avez besoin et comment ils fonctionnent. L'un des équilibreurs de charge les plus populaires disponibles pour MySQL et MariaDB est HAProxy.
Sur le plan des fonctionnalités, HAProxy n'est pas comparable à ProxySQL ou MaxScale. Cependant, HAProxy est un équilibreur de charge rapide et robuste qui fonctionnera parfaitement dans n'importe quel environnement tant que l'application peut effectuer la séparation lecture/écriture et envoyer des requêtes SELECT à un backend et toutes les écritures et SELECT...FOR UPDATE à un autre backend.
Le suivi de toutes les métriques mises à disposition par HAProxy est très important ; vous devez être en mesure de connaître l'état de votre proxy, notamment pour savoir si vous avez rencontré des problèmes.
ClusterControl a toujours mis à disposition une page d'état HAProxy montrant l'état du proxy en temps réel. Désormais, avec les nouveaux tableaux de bord SCUMM (Severalnines ClusterControl Unified Monitoring &Management) basés sur Prometheus, il est possible de suivre facilement l'évolution de ces métriques au fil du temps.
Ce billet de blog explorera les différentes métriques présentées dans le tableau de bord HAProxy SCUMM.
Exploration du tableau de bord HAProxy dans ClusterControl
Tous les tableaux de bord Prometheus et SCUMM sont désactivés par défaut dans ClusterControl. Cependant, pour les déployer pour un cluster donné, il suffit d'un clic. Si vous surveillez plusieurs clusters avec ClusterControl, vous pouvez réutiliser la même instance Prometheus pour chaque cluster.
Une fois déployé, vous pouvez alors accéder au tableau de bord HAProxy. Examinons les données disponibles dans le tableau de bord :
La première chose que vous verrez lorsque vous accédez au tableau de bord HAProxy est des informations sur l'état de vos backends. Veuillez noter ici que ce que vous voyez peut dépendre du type de cluster et de la manière dont vous avez déployé HAProxy. Dans ce cas, nous avons déployé un cluster Galera et HAProxy a été déployé de manière circulaire. Par conséquent, vous voyez trois backends pour les lectures et trois pour les écritures - six au total. C'est également la raison pour laquelle vous voyez tous les backends marqués comme "Up".
Dans un scénario avec un cluster de réplication, les choses seront différentes car le HAProxy sera déployé dans une division lecture/écriture, et les scripts ne garderont qu'un seul hôte (maître) opérationnel dans le rédacteur. backend.
Remarquez, c'est pourquoi ci-dessous vous voyez deux serveurs backend marqués comme "Hors service" :
Dans le graphique suivant, vous verrez les données envoyées et reçues par les deux backend (de HAProxy aux serveurs de base de données) et frontend (entre HAProxy et les hôtes clients) :
Vous pouvez également vérifier la répartition du trafic entre les backends dans votre configuration HAProxy. Dans ce cas, nous avons deux backends et les requêtes sont envoyées via le port 3308, qui agit comme point d'accès circulaire à notre cluster Galera :
Ensuite, vous pouvez voir comment le trafic a été réparti sur tous les serveurs principaux. Dans ce scénario, en raison du modèle d'accès circulaire, les données étaient plus ou moins uniformément réparties sur les trois serveurs Galera principaux :
Informations sur les sessions, y compris le nombre de sessions ouvertes depuis HAProxy vers le backend serveurs, peuvent également être surveillés, comme le montre le graphique suivant. Vous pouvez également suivre le nombre de fois par seconde qu'une nouvelle session a été ouverte sur le backend et l'apparence de ces métriques par serveur backend.
Les deux graphiques suivants montrent le nombre maximum de sessions par serveur principal et quand des problèmes de connectivité sont apparus. Cela peut être très utile à des fins de débogage lorsque vous rencontrez une erreur de configuration sur votre instance HAProxy et que les connexions commencent à tomber.
Ce graphique suivant est potentiellement plus précieux car il montre diverses mesures liées à l'erreur gestion, telles que les erreurs, les erreurs de requête, les tentatives côté backend, etc. Il existe également un graphique "Sessions" montrant un aperçu des métriques de session.
Ici, vous pouvez voir que ClusterControl suit les erreurs de connexion en temps réel, qui peut aider à identifier le moment précis où les problèmes ont commencé à évoluer.
Enfin, nous examinerons les deux graphiques suivants liés aux requêtes en file d'attente . HAProxy met en file d'attente les requêtes vers le backend si les serveurs backend sont sursaturés. Cela peut indiquer, par exemple, les serveurs de base de données surchargés, qui ne peuvent plus gérer de trafic.
Conclusion
Le déploiement et la surveillance de votre équilibreur de charge HAProxy dans ClusterControl peuvent faciliter la gestion et la surveillance de vos connexions. Avoir une visibilité claire sur les performances de vos backends, la distribution du trafic, les métriques de session, les erreurs de connexion et le nombre de requêtes en file d'attente peut aider à garantir la disponibilité et l'évolutivité de toute configuration de base de données.
ClusterControl facilite la configuration et la surveillance des équilibreurs de charge pour toute configuration de base de données. Vous n'utilisez pas encore ClusterControl ? Si vous souhaitez constater par vous-même à quel point il est facile de déployer et de surveiller votre équilibreur de charge HAProxy avec ClusterControl, nous vous invitons à un essai gratuit de 30 jours de la plateforme, sans aucune condition. Pour une présentation plus détaillée de pourquoi et comment utiliser HAProxy pour l'équilibrage de charge, consultez notre tutoriel sur l'équilibrage de charge MySQL avec HAProxy.
