Galera Cluster : les limites du Load Balancing et du Load Balancer
22 avril 2022
Dans le cadre d’un audit à venir sur MariaDB, j’ai appris que l’entreprise avait mis en place, au niveau de son cluster Galera composé de 5 machines, comme load balancer, d’abord HAProxy, puis Maxscale. La mise en place de ses solutions ne semble pas avoir donné le résultat escompté. Pourquoi ?
La raison principale est le déport de la charge sur les load balancers et la constitution de goulets d’étranglements. Si vous concentrez toutes les requêtes au niveau de deux machines alors que le cluster en comprend 5, vous augmentez la charge des load balancers de manière conséquente. Le risque est donc d’obtenir le résultat inverse, sauf à installer HAProxy, Pen (recommandé par Galera) ou GLB sur les serveurs d’applications qui, en mode Round-Robin, iront s’accrocher successivement aux différentes instances du cluster. Dans ce mode, le load balancer s’accroche lors de chaque nouvelle session à un serveur différent. Les problématiques de charge se déportent alors sur les serveurs d’application eux-mêmes.
Ce bon vieux Round-Robin au niveau des serveurs DNS
L’autre solution est le Round-Robin utilisé nativement au niveau des serveurs DNS. En associant plusieurs adresses IP au FQDN unique des différents serveurs, il s’agit, que ce soit au niveau des machines composant le cluster ou bien au niveau des serveurs d’applications, de changer de serveur utilisé à chaque nouvelle session. La seule utilité de MaxScale est de mettre en cache, en s’appuyant sur Redis ou MemCached, les données issues des SELECT réalisées sur les différentes instances du cluster. Cela ajoute un autre tampon à la mise en cache déjà opérée au niveau des instances MariaDB par le réglage du paramètre InnoDB Buffer Pool. Et du coup, quel en est son utilité réelle, alors que cette mis en cache peut aussi se réaliser au niveau du serveur d’applications ?