Améliorations de l'équilibrage de charge PostgreSQL et de ProxySQL - ClusterControl 1.5

Les équilibreurs de charge sont un composant essentiel de la haute disponibilité des bases de données ; en particulier lors de la transparence des changements de topologie pour les applications et de la mise en œuvre de la fonctionnalité de fractionnement en lecture-écriture. ClusterControl fournit un éventail de fonctionnalités pour déployer, surveiller et configurer en toute sécurité les principales technologies d'équilibrage de charge open source du secteur.

Au cours de l'année écoulée, nous avons ajouté la prise en charge de ProxySQL et ajouté plusieurs améliorations pour HAProxy et Maxscale de MariaDB. Nous poursuivons cette tradition avec la dernière version de ClusterControl 1.5.

Sur la base des commentaires que nous avons reçus de nos utilisateurs, nous avons amélioré la gestion de ProxySQL. Nous avons également ajouté la prise en charge de HAProxy et Keepalived pour qu'ils s'exécutent sur les clusters PostgreSQL.

Dans cet article de blog, nous examinerons ces améliorations...

ProxySQL - Améliorations de la gestion des utilisateurs

Auparavant, l'interface utilisateur vous permettait uniquement de créer un nouvel utilisateur ou d'en ajouter un existant, un par un. L'un des commentaires que nous avons reçus de nos utilisateurs était qu'il est assez difficile de gérer un grand nombre d'utilisateurs. Nous avons écouté et dans ClusterControl 1.5, il est désormais possible d'importer de gros lots d'utilisateurs. Voyons comment vous pouvez le faire. Tout d'abord, vous devez avoir déployé votre ProxySQL. Ensuite, allez dans le nœud ProxySQL, et dans l'onglet Utilisateurs, vous devriez voir un bouton "Importer des utilisateurs".

Une fois que vous aurez cliqué dessus, une nouvelle boîte de dialogue s'ouvrira :

Ici, vous pouvez voir tous les utilisateurs que ClusterControl a détectés sur votre cluster. Vous pouvez les faire défiler et choisir ceux que vous souhaitez importer. Vous pouvez également sélectionner ou désélectionner tous les utilisateurs d'une vue actuelle.

Une fois que vous commencez à taper dans la zone de recherche, ClusterControl filtrera les résultats non correspondants, réduisant la liste uniquement aux utilisateurs pertinents pour votre recherche.

Vous pouvez utiliser le bouton "Sélectionner tout" pour sélectionner tous les utilisateurs qui correspondent à votre recherche. Bien sûr, après avoir sélectionné les utilisateurs que vous souhaitez importer, vous pouvez effacer le champ de recherche et lancer une autre recherche :

Veuillez noter "(7 sélectionnés)" - il vous indique combien d'utilisateurs, au total (pas seulement à partir de cette recherche), vous avez sélectionné pour importer. Vous pouvez également cliquer dessus pour voir uniquement les utilisateurs que vous avez sélectionnés pour l'importation.

Une fois que vous êtes satisfait de votre choix, vous pouvez cliquer sur "Suivant" pour passer à l'écran suivant.

Ici, vous devez décider quel devrait être le groupe d'hôtes par défaut pour chaque utilisateur. Vous pouvez le faire par utilisateur ou globalement, pour l'ensemble ou un sous-ensemble d'utilisateurs résultant d'une recherche.

Une fois que vous aurez cliqué sur le bouton "Importer des utilisateurs", les utilisateurs seront importés et apparaîtront dans l'onglet Utilisateurs.

ProxySQL - Gestion du planificateur

Le planificateur de ProxySQL est un module de type cron qui permet à ProxySQL de démarrer des scripts externes à intervalles réguliers. Le calendrier peut être assez granulaire - jusqu'à une exécution toutes les millisecondes. En règle générale, le planificateur est utilisé pour exécuter des scripts de vérificateur Galera (comme proxysql_galera_checker.sh), mais il peut également être utilisé pour exécuter tout autre script que vous aimez. Dans le passé, ClusterControl utilisait le planificateur pour déployer le script de vérificateur Galera, mais cela n'était pas exposé dans l'interface utilisateur. À partir de ClusterControl 1.5, vous avez maintenant un contrôle total.

Comme vous pouvez le voir, un script a été programmé pour s'exécuter toutes les 2 secondes (2000 millisecondes) - c'est la configuration par défaut pour le cluster Galera.

La capture d'écran ci-dessus nous montre les options pour modifier les entrées existantes. Veuillez noter que ProxySQL prend en charge jusqu'à 5 arguments pour les scripts qu'il exécutera via le planificateur.

Si vous souhaitez qu'un nouveau script soit ajouté au planificateur, vous pouvez cliquer sur le bouton "Ajouter un nouveau script" et vous serez présenté avec un écran comme ci-dessus. Vous pouvez également prévisualiser à quoi ressemblera le script complet une fois exécuté. Après avoir rempli tous les champs "Argument" et défini l'intervalle, vous pouvez cliquer sur le bouton "Ajouter un nouveau script".

En conséquence, un script sera ajouté au planificateur et il sera visible dans la liste des scripts planifiés.

PostgreSQL – Construire la pile haute disponibilité

La configuration de la réplication avec basculement automatique est une bonne chose, mais les applications ont besoin d'un moyen simple de suivre le maître inscriptible. Nous avons donc ajouté la prise en charge de HAProxy et Keepalived en plus des clusters PostgreSQL. Cela permet à nos utilisateurs PostgreSQL de déployer une pile haute disponibilité complète à l'aide de ClusterControl.

À partir du sous-onglet Load Balancer, vous pouvez désormais déployer HAProxy - si vous savez comment ClusterControl déploie la réplication MySQL, il s'agit d'une configuration très similaire. Nous installons HAProxy sur un hôte donné, deux backends, lisons sur le port 3308 et écrivons sur le port 3307. Il utilise tcp-check, s'attendant à ce qu'une chaîne particulière soit renvoyée. Pour produire cette chaîne, les étapes suivantes sont exécutées sur tous les nœuds de la base de données. Tout d'abord, xinet.d est configuré pour exécuter un service sur le port 9201 (pour éviter toute confusion avec la configuration de MySQL, qui utilise le port 9200).

# default: on
# description: postgreschk
service postgreschk
{
        flags           = REUSE
        socket_type     = stream
        port            = 9201
        wait            = no
        user            = root
        server          = /usr/local/sbin/postgreschk
        log_on_failure  += USERID
        disable         = no
        #only_from       = 0.0.0.0/0
        only_from       = 0.0.0.0/0
        per_source      = UNLIMITED

Le service exécute le script /usr/local/sbin/postgreschk, qui valide l'état de PostgreSQL et indique si un hôte donné est disponible et de quel type d'hôte il s'agit (maître ou esclave). Si tout est ok, il renvoie la chaîne attendue par HAProxy.

Tout comme avec MySQL, les nœuds HAProxy dans les clusters PostgreSQL sont visibles dans l'interface utilisateur et la page d'état est accessible :

Ici, vous pouvez voir les deux backends et vérifier que seul le maître est actif pour le backend r/w et que tous les nœuds sont accessibles via le backend en lecture seule. Vous pouvez également obtenir des statistiques sur le trafic et les connexions.

HAProxy contribue à améliorer la haute disponibilité, mais il peut devenir un point de défaillance unique. Nous devons faire un effort supplémentaire et configurer la redondance avec l'aide de Keepalived.

Sous Gérer -> Équilibreur de charge -> Keepalived, vous choisissez les hôtes HAProxy que vous souhaitez utiliser et Keepalived sera déployé dessus avec une adresse IP virtuelle attachée à l'interface de votre choix.

Désormais, toute la connectivité devrait aller au VIP, qui sera attaché à l'un des nœuds HAProxy. Si ce nœud tombe en panne, Keepalived supprimera le VIP sur ce nœud et le remontera sur un autre nœud HAProxy.

C'est tout pour les fonctionnalités d'équilibrage de charge introduites dans ClusterControl 1.5. Essayez-les et dites-nous comment vous