HAProxy – Configuration d’un load balancer pour un cluster Cassandra


En utilisation d’un langage tel que Java et avec les drivers corrects, la répartition de charge est gérée au niveau du driver Java. L’article qui suit est destiné à des connexions qui ne prendraient pas en charge de load balancing.

Tout l’intérêt d’un cluster est de ne pas en voir l’architecture, ni le nombre de machines physiques le constituant, ni d’avoir besoin de savoir chez qui on se connecte dans le cluster.

Un autre intérêt du cluster est de pouvoir répartir les connexions clientes de façon équitable afin que tous les serveurs aient une charge équilibrée.

Le rôle d’un équilibreur de charge (load balancer) est justement celui-ci et doit permettre cette équité dans la charge répartie sur l’ensemble des membres du cluster.

HAProxy est un load balancer permettant l’équilibrage de charge sur à peu près n’importe quel protocole. Dans le cas qui nous intéresse, nous voulons qu’il répartisse les demandes de connexion au port 9042 vers l’un des membres du cluster Cassandra que nous avons créé.

Par contre, HAProxy ne permet pas de connaître la charge réelle d’un membre de cluster à l’instant de décider vers quel serveur envoyer une connexion. La méthode qui sera employée sera donc un équilibrage du nombre de connexions par serveur du cluster.

Serveur dédié à HAProxy

Dans la suite de l’article, un serveur dédié à HAProxy est configuré avec HAProxy installé. Dans ma configuration, il se nomme lbalancer et a pour adresse IP 192.168.1.100 .

Les clients viendront à partir de là se connecter à ce serveur pour profiter du load balancing.

Configuration de HAProxy

Je me suis référée à ces deux sites pour savoir configurer HAProxy pour mes besoins : How to Setup High-Availability Load Balancer with ‘HAProxy’ to Control Web Server Traffic (Techmint.com) et Load balance anything with HAProxy (LiNicKx.com)

Vous trouverez ci-dessous la configuration de HAProxy pour mon cluster Cassandra à 6 nœuds (ajout d’un nœud supplémentaire après configuration des 5 premiers nœuds, en fin de mon article sur le sujet).

Modification de /etc/haproxy/haproxy.cfg, 1e partie

Editer le fichier et vérifier que la ligne suivante existe :

log         127.0.0.1 local2

Modification de /etc/rsyslog.conf

Décommenter les deux lignes suivantes (enlever le # ) :

$ModLoad imudp
$UDPServerRun 514

Création d’un fichier /etc/rsyslog.d/haproxy.conf

Editer le fichier /etc/rsyslog.d/haproxy.conf et créer cette ligne :

local2.* /var/log/haproxy.log

Redémarrer rsyslog

Exécuter la commande suivante :

systemctl restart rsyslog

Modification de /etc/haproxy/haproxy.cfg, 2e partie

Editer le fichier et ajouter les lignes suivantes après la section (defaults) :

#---------------------------------------------------------------------
# Cassandra
#---------------------------------------------------------------------

listen cassandra :9042
    mode                    tcp
    log                     global
    option                  tcplog
    balance                 leastconn
    server casscqlsh01 192.168.1.101
    server casscqlsh02 192.168.1.102
    server casscqlsh03 192.168.1.103
    server casscqlsh04 192.168.1.104
    server casscqlsh05 192.168.1.105
    server casscqlsh06 192.168.1.106

La méthode de répartition de charge utilisée, leastconn, permet de répartir de manière équitable les connexions aux membre de cluster en fonction du nombre de connexions détenues par chacun d’eux.

Commenter toutes les autres lignes pour tous les autres protocoles en-dessous (sauf si vraiment ceux-ci peuvent par ailleurs vous servir pour autre chose)

Configurer HAProxy pour démarrage au boot système

Exécuter les instructions suivantes :

systemctl enable haproxy
systemctl start haproxy

Test de connexion à partir d’un client

Le test suivant permet de vérifier qu’on se connecte bien au cluster :

[achampav@micado ~]$ cqlsh lbalancer -u admcass
Password: 
Connected to CassandraRAC at lbalancer:9042.
[cqlsh 5.0.1 | Cassandra 3.9 | CQL spec 3.4.2 | Native protocol v4]
Use HELP for help.
admcass@cqlsh>