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>