20 janvier 2022

Tuto Virtualisation – Partie IX, Cluster MariaDB Galera et Failover HAproxy

EDIT 2018 : Retrouvez cette série de tuto dans une grosse mise à jour ici : Xen et OpenVswitch sont dans une Debian 9 – V.2018

Neuvième partie du tutoriel sur la virtualisation « Xen et OpenVswitch sont dans une Debian« .
Nous venons de mettre un place un cluster de données avec GlusterFS, passons maintenant à un cluster pour nos bases SQL.
Nous allons utiliser pour cela MariaDB Galera Cluster.

I – Présentation

MariaDB est un fork de MySQL. Crée par le fondateur de ce dernier lors du rachat de MySQL par Oracle. Google a migré dessus, d’autres s’y mettent.
Pour les clients, c’est transparent, rien à modifier et coté serveur, à part le nom des paquets, on est en terrain connu.
Idéalement, il monter un tel cluster sur au moins trois serveurs afin d’éviter les situations de « splitbrain ».
Dans mon cas, je n’ai pas envie d’avoir trois nœuds, le volume de requêtes ne le justifiant pas, et la place en Ram sur mon hyperviseur n’est pas illimitée.
On va donc utiliser seulement deux nœuds et un arbitrateur installé sur une autre VM dont l’unique rôle sera d’être le troisième membre évitant les splitbrains.

II – Création des VMS

Nous avons besoin de trois VMs : Maria1, Maria2, et Marialb (qui servira à Garb et à Haproxy)

dom0# xen-create-image --hostname maria1 --role debugo --size 20G --memory 1G--swap 1G --vcpus=1 --ip=99.99.99.99
dom0# xen-create-image --hostname maria2 --role debugo --size 20G --memory 1G--swap 1G --vcpus=1 --ip=99.99.99.99
dom0# xen-create-image --hostname marialb --role debugo --size 5G --memory 1G--swap 1G --vcpus=1 --ip=99.99.99.99

Puis, la routine, pour les trois vms :
Fichier /etc/xen/mariaX.cfg :

vif         = [ 'vifname=mariaX.0,ip=10.20.1.15X ,mac=00:16:3E:A1:5X:20,bridge=brint.20',
                'vifname=mariaX.1,ip=10.99.1.15X ,mac=00:16:3E:A1:5X:99,bridge=brint.99',
                'vifname=mariaX.2,ip=10.10.1.15X ,mac=00:16:3E:A1:5X:10,bridge=brint.10'
]

Interfaces réseaux  :

dom0# mount /dev/vg0/mariaX-disk /mnt/vm/
dom0# nano /mnt/vm/etc/network/interfaces

Collez cela :

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
 address 10.20.1.15X
 netmask 255.255.255.0
auto eth1
iface eth1 inet static
 address 10.99.1.15X
 netmask 255.255.255.0
auto eth2
iface eth2 inet static
 address 10.10.1.15X
 netmask 255.255.255.0
 gateway 10.10.1.3

Et démontez :

dom0# umount /mnt/vm

Je te détaille pas les trois machines, mais Maria1 > 151, Maria2 -> 152 et Marialb -> 150
Pourquoi ces VMS ont une pâte sur le vlan 10 ? Car pour ajouter le dépôt, je n’ai pas réussi à faire passer le tout par le proxy. Il y a de la doc sur le net, mais rien ne fonctionnait.
Bref, je ne me prend pas la tete plus longtemps, on fait comme ca, on supprimera ces interfaces après.

III – Ajout du dépôt

Sur les trois vms :

# apt-get install -y python-software-properties
# apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db
# echo 'deb http://mirror3.layerjet.com/mariadb/repo/10.0/debian jessie main' > /etc/apt/sources.list.d/mariadb.list
# apt-get update

On peut maintenant couper eth2 sur les trois vms :

# ifdown eth2

Puis supprimer l’interface dans le fichier /etc/network/interfaces de chaque VM, ainsi que dans le fichier de configuration Xen de chaque VM.
Puis, toujours pour les trois vms :

dom0# xen shutdown mariaX
dom0# xen create /etc/xen/mariaX.cfg

Et on se reconnecte sur les trois…

IV – Installation de MariaDB

Sur les deux machines, Maria1 et Maria2

# apt-get install -y mariadb-galera-server mariadb-client galera3

Une fois tout cela installé, toujours sur les deux machines :

# service mysql stop
# rm -f /var/lib/mysql/ib_logfile*

Puis on va créer le fichier de configuration : /etc/mysql/conf.d/galera.cnf (toujours sur Maria1 et Maria2)

[mysqld]
query_cache_size=0
binlog_format=ROW
default_storage_engine=innodb
innodb_autoinc_lock_mode=2
innodb_doublewrite=1
bind-address=0.0.0.0
# Configuration Galera
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_provider_options="gcache.size=4G"
wsrep_cluster_address=gcomm://
wsrep_cluster_name='mon-cluster'
wsrep_sst_method=rsync
# Tunning InnoDB a personnaliser selon ses besoins
#innodb_buffer_pool_size=4G
#innodb_file_per_table
#innodb_flush_log_at_trx_commit=2
innodb_log_file_size=100M

Puis sur sql2, on va copier le fichier de configuration contenant le compte debian-sys (afin d’avoir le même mot de passe sur chaque nœud pour ce compte particulier) et ainsi éviter les erreurs au lancement

maria2# scp -p root@maria1:/etc/mysql/debian.cnf /etc/mysql/

 

III – Lancement du Cluster

On revient sur Maria1 et on lance le cluster :

maria1# service mysql start --wsrep-new-cluster

On vérifie :

maria1# mysql -u root -e 'SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"' -p

Doit retourner un membre.
Sur Maria 2 :
On édite le fichier /etc/mysql/conf.d/galera.cnf pour modifier :

wsrep_cluster_address="gcomm://maria1"

On démarre le serveur :

maria2# service mysql start

On vérifie sur les deux vms :

# mysql -u root -e 'SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"' -p

Doit retourner deux membres.
On peut aussi utiliser :

# mysql -u root -p -e 'SHOW STATUS LIKE "wsrep_%"'

qui affichera alors toutes les informations liées au cluster.

IV – Garb, l’arbitrator

Sur la troisième machine Marialb :

marialb# apt-get install galera-arbitrator-3

Le fichier de configuration se trouve dans /etc/default/garb. Éditez le de la sorte :

GALERA_NODES="sql1:4567 sql2:4567"
GALERA_GROUP="mon-cluster"
LOG_FILE="/var/log/garbd.log"

On lance :

marialb# service garb start

On vérifie sur Maria1 et Maria2 :

# mysql -u root -e 'SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"' -p

Doit retourner trois membres.
Sur Maria1, on modifie le fichier /etc/mysql/conf.d/galera.cnf comme cela :

wsrep_cluster_address="gcomm://maria2,marialb"

Sur Maria2, on modifie le fichier /etc/mysql/conf.d/galera.cnf comme ceci :

wsrep_cluster_address="gcomm://maria1,marialb"

Le Cluster est prêt.

V – Tests de réplication

Pour faire vos tests, c’est simple, créer des bases, tables, vérifiez la réplication. Coupez un des serveurs, créer, modifiez des bases, rallumez le serveur, vérifiez la réplication, bref, vous voyez le principe !
Normalement, tout devrait être transparent sans la moindre perte de données. J’ai fait pas mal de tests et aucune faiblesse à démontrer pour le moment.
Si vous coupez Maria1 et que le cluster est toujours ON (Maria2 Up au moins), pour relancer Maria1 :

maria1# service mysql start

Le flag –wsrep-new-cluster n’est obligatoire que pour le démarrage du cluster (si tous les serveurs sont down).

VI – Failover avec HAproxy

Bon, tout ça, c’est bien joli, mais pour le moment les clients sql doivent encore s’adresser à un serveur en particulier. Si celui ci tombe, on l’a dans l’os.
Il faudrait quelque chose en amont pour faire un point d’entrée unique. Plusieurs solutions techniques sont possibles (heartbeat, etc…).
Connaissant déjà HAproxy, nous allons l’utiliser ici et nous allons le déployer sur marialb. Garb et Haproxy étant léger, pas de soucis pour cette VM.
Simple à installer :

marialb# apt-get install haproxy

Ajoutez ce qui suit dans le fichier de config /etc/haproxy/haproxy.cfg :

frontend sql-front
 bind *:3306
 mode tcp
 default_backend sql-back
backend sql-back
 mode tcp
 balance leastconn
 option mysql-check user haproxy_check
 server maria1 10.20.1.151:3306 check port 3306
 server maria2 10.20.1.152:3306 check port 3306 backup
listen stats 0.0.0.0:8282
 mode http
 balance
 timeout client 5000
 timeout connect 4000
 timeout server 30000
 stats hide-version
 stats uri /
 stats realm HAProxy\ Statistics
 stats auth user:pass
 stats admin if TRUE

On crée un frontend qui écoute sur le port standard MySQL (3306). Haproxy transfère aux deux serveurs derrières. Ici, pas de loadbalancing, tout est envoyé sur Maria1. Maria2 n’est utilisé qu’en cas de down du premier nœud (option backup)
L’interface pour les stats sera accessible avec notre futur reverse proxy.
Pour faire les vérifications, on peut utiliser la vérification du socket toute bête. Le hic, c’est que cela incrémente un compteur de connexion en erreur côté sql (et à un moment, le serveur refuse toute connexion venant du proxy et paf, plus de sites…. Et le fait que le serveur réponde sur le port 3306 ne veut pas dire que le serveur sql tourne correctement. Le mieux est donc de passer par une vérification avec connexion d’un user.
C’est l’option mysql-check.
Mais il faut donc ajouter un utilisateur sur les serveurs sql.
On se connecte à Maria1 :

maria1# mysql -u root -p
mysql > GRANT USAGE ON *.* TO 'haproxy_check'@'10.20.1.150';
mysql > flush privileges;
mysql > quit

On revient sur marialb pour relancer Haproxy :

marialb# service haproxy restart

Dorenavant, nos clients SQL se connecteront à marialb et non plus à maria1 ou maria2.

VII – Test Haproxy

Pour tester cela, on va créer une base test sur maria1 :

maria1# mysql -u root -p
mysql > create database test;
mysql >  GRANT ALL PRIVILEGES ON test.* TO 'test'@'10.20.1.150' IDENTIFIED BY 'test';
mysql > flush privileges;

On peut tester sur la vm Web (10.20.1.30) par exemple :

web# apt-get install mysql-client
web# mysq -h marialb -u test -ptest
myqsl>...

Vous constatez surement que l’hôte de mon user sql n’est pas l’hôte de mon client. En effet, la connexion passant par le proxy, il faut donner les droits avec l’ip du proxy…

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *