• Accueil
  • Billet
  • Développement
    • Développement
    • Java
    • Laravel
    • WordPress
    • Tests
  • Systèmes
    • Linux
    • macOS
    • Windows
  • NAS
  • SysAdmin
getBrain.fr
  • Accueil
  • Billet
  • Développement
    • Développement
    • Java
    • Laravel
    • WordPress
    • Tests
  • Systèmes
    • Linux
    • macOS
    • Windows
  • NAS
  • SysAdmin
Home  /  Linux • SysAdmin  /  Cluster Galera & HAproxy Frontend
06 octobre 2016

Cluster Galera & HAproxy Frontend

Written by Sébastien Champseix
Linux, SysAdmin Backend, centos, centos-7.2, cluster, Cluster Galera, clustercheck, Frontend, Galera, HAproxy, MariaDB, ProofOfConcept 1 Comment
Partagez !

Welcome back sur notre superbe site GetBrain.fr !

Dans ce tutoriel nous allons voir la mise en place d’un cluster Galera avec MariaDB avec un HAproxy en Front.

J’utilise dans mon POC le network suivant :  “Network Galera : 10.10.100.0/24”
Voici l’infra en image :

galera-infra

Nos 4 serveurs seront basés sous centos-7.2, dans un premier tant nous allons ajouter sur chacun des nodes galera différentes entrées dans le fichier “/etc/hosts” :

vi /etc/hosts

10.10.100.201 galera-01

10.10.100.202 galera-02

10.10.100.203 galera-03

Voici un exemple de la configuration de mon interface :

[root@galera-01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens9
BOOTPROTO="static"
NAME="ens9"
UUID="02764b74-5e1e-4357-bbd3-246d2698e9b9"
DEVICE="ens9"
ONBOOT="yes"
IPADDR=10.10.100.201
NETMASK=255.255.255.0
NM_CONTROLLED="no"

On test un ping entre tous les nodes,
galera-01 vers galera-02 & galera-03 :

[root@galera-01 ~]# ping galera-02
PING galera-02 (10.10.100.202) 56(84) bytes of data.
64 bytes from galera-02 (10.10.100.202): icmp_seq=1 ttl=64 time=0.787 ms
64 bytes from galera-02 (10.10.100.202): icmp_seq=2 ttl=64 time=0.978 ms
64 bytes from galera-02 (10.10.100.202): icmp_seq=3 ttl=64 time=0.841 ms
64 bytes from galera-02 (10.10.100.202): icmp_seq=4 ttl=64 time=0.909 ms
^C
--- galera-02 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.787/0.878/0.978/0.080 ms

[root@galera-01 ~]# ping galera-03
PING galera-03 (10.10.100.203) 56(84) bytes of data.
64 bytes from galera-03 (10.10.100.203): icmp_seq=1 ttl=64 time=1.81 ms
64 bytes from galera-03 (10.10.100.203): icmp_seq=2 ttl=64 time=0.980 ms
64 bytes from galera-03 (10.10.100.203): icmp_seq=3 ttl=64 time=0.766 ms
64 bytes from galera-03 (10.10.100.203): icmp_seq=4 ttl=64 time=1.02 ms
^C
--- galera-03 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.766/1.144/1.811/0.398 ms

galera-02 vers galera-01 & galera-03 :

[root@galera-02 ~]# ping galera-01
PING galera-01 (10.10.100.201) 56(84) bytes of data.
64 bytes from galera-01 (10.10.100.201): icmp_seq=1 ttl=64 time=0.848 ms
64 bytes from galera-01 (10.10.100.201): icmp_seq=2 ttl=64 time=0.832 ms
64 bytes from galera-01 (10.10.100.201): icmp_seq=3 ttl=64 time=1.41 ms
64 bytes from galera-01 (10.10.100.201): icmp_seq=4 ttl=64 time=0.968 ms
^C
--- galera-01 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.832/1.014/1.411/0.237 ms

[root@galera-02 ~]# ping galera-03
PING galera-03 (10.10.100.203) 56(84) bytes of data.
64 bytes from galera-03 (10.10.100.203): icmp_seq=1 ttl=64 time=1.36 ms
64 bytes from galera-03 (10.10.100.203): icmp_seq=2 ttl=64 time=0.827 ms
64 bytes from galera-03 (10.10.100.203): icmp_seq=3 ttl=64 time=1.06 ms
64 bytes from galera-03 (10.10.100.203): icmp_seq=4 ttl=64 time=0.874 ms
^C
--- galera-03 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.827/1.033/1.365/0.211 ms

galera-03 vers galera-01 & galera-02 :

[root@galera-03 ~]# ping galera-01
PING galera-01 (10.10.100.201) 56(84) bytes of data.
64 bytes from galera-01 (10.10.100.201): icmp_seq=1 ttl=64 time=0.753 ms
64 bytes from galera-01 (10.10.100.201): icmp_seq=2 ttl=64 time=0.774 ms
64 bytes from galera-01 (10.10.100.201): icmp_seq=3 ttl=64 time=0.795 ms
64 bytes from galera-01 (10.10.100.201): icmp_seq=4 ttl=64 time=0.867 ms
^C
--- galera-01 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.753/0.797/0.867/0.047 ms

[root@galera-03 ~]# ping galera-02
PING galera-02 (10.10.100.202) 56(84) bytes of data.
64 bytes from galera-02 (10.10.100.202): icmp_seq=1 ttl=64 time=0.875 ms
64 bytes from galera-02 (10.10.100.202): icmp_seq=2 ttl=64 time=0.985 ms
64 bytes from galera-02 (10.10.100.202): icmp_seq=3 ttl=64 time=0.882 ms
64 bytes from galera-02 (10.10.100.202): icmp_seq=4 ttl=64 time=0.279 ms
^C
--- galera-02 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.279/0.755/0.985/0.279 ms

On désactive ensuite SElinux :
pour selinux=enforcing :

sed -i -e 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux
sed -i -e 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config

pour selinux=permissive :

sed -i -e 's/SELINUX=permissive/SELINUX=disabled/g' /etc/sysconfig/selinux
sed -i -e 's/SELINUX=permissive/SELINUX=disabled/g' /etc/selinux/config

et un reboot de chaque nodes est nécessaire.

On va ensuite créer une clé ssh sur notre serveur galera-01 pour ne plus avoir à saisir de password pour se connecter vers galera-02 et galera-03.

[root@galera-01 ~]# ssh-keygen -t rsa -b 4096
passphrase empty.

cat .ssh/id_rsa.pub | ssh root@galera-02 'cat >> .ssh/authorized_keys'
ssh root@galera-02 "chmod 700 .ssh; chmod 640 .ssh/authorized_keys"

cat .ssh/id_rsa.pub | ssh root@galera-03 'cat >> .ssh/authorized_keys'
ssh root@galera-03 "chmod 700 .ssh; chmod 640 .ssh/authorized_keys"

On ajoute un nouveau répo pour mariaDB sur chaque serveurs:

vi /etc/yum.repos.d/mariadb.repo

# MariaDB 10.0.27 CentOS repository list - created 2016-08-29 02:00 UTC
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.0.27/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

On installe les paquets nécessaires :

yum -y install MariaDB-Galera-server MariaDB-client galera rsync xinetd xinetd wget

On en profite pour faire ça sur tous les nodes:

systemctl start firewalld

et on ouvre les ports suivant :

ports: 873/tcp 3306/tcp 9200/tcp 4567/tcp 4444/tcp

on configure le fichier /etc/my.cnf.d/server.cnf sur l’ensemble des noeuds du cluster :

wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.10.100.201,10.10.100.202,10.10.100.203"
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
##Cluster NAME
wsrep_cluster_name="openstack_mdb_cluster"

##SERVER IP
wsrep_node_address="10.10.100.201"

#Replication over rsync
wsrep_sst_method=rsync

on modifie server.cnf sur les 2 autres nodes tout en modifiant la value :
pour galera-02 :

##SERVER IP
wsrep_node_address="10.10.100.202"

pour galera-03 :

##SERVER IP
wsrep_node_address="10.10.100.203"

On va ensuite mettre en place un serveur Haproxy,
ajouter le repo mariadb puis :
on installe le client mySQL et on modifie la value ENABLED :

sed -i "s/ENABLED=0/ENABLED=1/" /etc/default/haproxy

Ensuite créer votre propre haproxy.cfg :

mv /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
vi /etc/haproxy/haproxy.cfgw/code>

Vous-pouvez effectuer un wget sur l’url :

wget https://img.champseix.com/Config-clustercheck-Galera/myhaproxy-cfg

On configure ensuite sur chacun de nos nodes galera le clustercheck en créant le fichier :

vi /usr/bin/clustercheck OR (wget https://img.champseix.com/Config-clustercheck-Galera/clustercheck)

puis :

chmod 755 /usr/bin/clustercheck

N’oubliez pas de modifier les crédentials Mariadb présent dans le fichier clustercheck.

On va ensuite modifier les services :

vi /etc/services OR (wget https://img.champseix.com/Config-clustercheck-Galera/services)

Seul les lignes suivantes sont modifiées :

#wap-wsp 9200/tcp # WAP connectionless session service
#wap-wsp 9200/udp # WAP connectionless session service
mysqlchk 9200/tcp

Une fois ceci effectué nous allons créer le fichier suivant :

vi /etc/xinetd.d/mysqlchk OR (wget https://img.champseix.com/Config-clustercheck-Galera/mysqlchk)

puis arrêter xinetd :

systemctl stop xinetd

puis relancer :

systemctl start xinetd

test en local :
galera

galera

galera

Configurer le lancement du service haproxy au boot du système sur le serveur haproxy:

[root@haproxy-gal01 ~]# chkconfig --add haproxy
[root@haproxy-gal01 ~]# chkconfig haproxy on

Maintenant notre adresse 10.10.100.250 fera office de VIP pour notre cluster Galera. Pour cela il faudra créer le user haproxy sur notre cluster galera :

CREATE USER 'haproxy'@'10.10.100.250';
update haproxy set password=PASSWORD("VotreMDP") Where User='haproxy';

Ensuite vérifier en base que le MDP soit le même pour le user haproxy sur chaque node (ainsi on vérifie que la réplication est ok):

select * from mysql.user;

Sur chaque node vous devrez avoir le même hash au niveau du password :
exemple password (toto) :

| 10.10.100.250 | haproxy | *63D85DCA15EAFFC58C908FD2FAE50CCBC60C4EA2 |

Votre interface web haproxy est également disponible à l’adresse : http://10.10.100.250 (pas besoin de préciser de port vu que dans haproxy.cfg on lui indique le port 80)

galera

Comme on peux le constater aucune session n’est ouverte sur le cluster, ni sur le VIP (Frontend).

Nous allons réaliser une session via 10.10.100.250 :
galera

galera

On constate 1 session sur le frontend, et sur le node galera-01 du cluster.

Déconnectons-nous et refaisons un test,
galera

La current session à changer de node → galera-02
galera

aller une dernière déconnexion, galera-03 or not ?

galera

Bingo !

galera

Bon chaque nœud du cluster répond au travers de notre « VIP » 10.10.100.250.

N’oubliez pas d’optimiser votre “my.cnf.d/server.conf” en fonction de votre RAM, pour ce qui est des buffers, log et des commits de mon côté j’utilise cela :

#for my POC each node got 2GB RAM
innodb_buffer_pool_size = 1.6GB
#taille du redo logs
innodb_log_file_size = 100M
#augmentation du nombre de connexion authorized - bypass 'too many connections', parfois les sessions ne sont pas fermées correctement.
max_connections = 200

# all table in same file (because of the number of table) if few table you can use the 'ON' option for .idb file for each tables.
innodb_file_per_table = OFF

# on force la mémoire tampon journal innoDB à écrire dans le fichier une fois par seconde, plutôt qu'a chaque commit.
innodb_flush_log_at_trx_commit = 0

# Pour un cluster Galera on active le Interleaved lock mode
innodb_autoinc_lock_mode=2

Voilà c’est tout pour le moment ! Mon cluster Galera sera utilisé dans un autre tutoriel un peu plus tard .. Be Patient ! aller un indice ça s’appelle OpenStack ..

see-you-soon1

Partager :

  • Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)
  • Cliquez pour partager sur Facebook(ouvre dans une nouvelle fenêtre)
  • Cliquez pour partager sur LinkedIn(ouvre dans une nouvelle fenêtre)
  • Cliquez pour envoyer par e-mail à un ami(ouvre dans une nouvelle fenêtre)
  • Cliquer pour imprimer(ouvre dans une nouvelle fenêtre)

Articles similaires

Sébastien Champseix

Passionné du monde de l'Opensource je ne césse d'enrichir mes connaissances techniques sur les environnements GNU / Linux. L'architecture réseau, firewalling , loadbalancing sont d'un grand intérêt également, dont-il faut se tenir informé. Fan du langage python et de l'utilisation d'api divers me permettant une certaine facilitée d'administration et de déploiement. Je compte me pencher sur l'automatisation via ansible .. je suis donc partant pour de bon tuto/livre/info autour du sujet ;)

 Previous Article Installer Laravel sur Cloud9.io
Next Article   L’astuce de la gestion à 3 doigts sur Mac OS X

1 Comment

  1. Valentin Ouvrard Reply to Valentin
    18 novembre 2016 at 6 h 46 min

    Super article, merci.

    Il faudrait ajouter un second HAProxy avec Keepalived, pour avoir quelque chose de hautement-disponible.

    A bientôt

Leave a Reply

Annuler la réponse

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

fb.png twitter.png google.png youtube.png telegram.png rss.png

Articles récents

  • Think Different
    L’astuce de la gestion à 3 doigts sur Mac OS X 23 novembre 2016 Billet, macOS
  • Cluster Galera & HAproxy Frontend 6 octobre 2016 Linux, SysAdmin
  • Installer Laravel sur Cloud9.io 1 octobre 2016 Développement, Laravel
  • ESXi 6.0 HA – vCenter avec KVM et NAS Asustor 28 septembre 2016 SysAdmin

Commentaires récents

  • Loic Dumay dans Installer une SeedBox simplement sur Debian
  • terry dans Installer une SeedBox simplement sur Debian
  • terry puillet dans Installer une SeedBox simplement sur Debian
  • kris1208 dans Ajouter un utilisateur sur sa SeedBox
  • Loic Dumay dans Installer une SeedBox simplement sur Debian
Confidentialité et cookies : ce site utilise des cookies. En continuant à naviguer sur ce site, vous acceptez que nous en utilisions.
Pour en savoir plus, y compris sur la façon de contrôler les cookies, reportez-vous à ce qui suit : Politique relative aux cookies

© Copyright 2016 | getBrain.fr | Politique de confidentialité | Contact

loading Annuler
L'article n'a pas été envoyé - Vérifiez vos adresses e-mail !
La vérification e-mail a échoué, veuillez réessayer
Impossible de partager les articles de votre blog par e-mail.