par 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…
