Le but est de rendre disponible une application web (ici WordPress) dans une infrastructure la plus solide possible.
Principe
Inventaire des Machines
Composition des Clusters
Cluster HaProxy + keepalive(RockyLinux 8 fork RHEL8)
MODOP – PARTIE 5 – Installation WordPress en HA – Cluster HaProxy
3 machines HaProxy
- node01-haw 172.16.186.20
- node02-haw 172.16.186.21
- node03-haw 172.16.186.22
- node-haw 192.168.1.230/24(vIP)
HaProxy va repartir la charge réseau en fonction de la disponibilité des machines du réseau.
Si votre site possède une forte affluence, HaProxy répartira les différentes requêtes SQL, http sur les différents Cluster de machine.
Ici on utilisera 3 machines HaProxy pour gérer la gestion « tiers » panne.
En effet, il y aura un master et deux slaves.
- Si le master est down l’un des deux « slaves » passe en master et répondra aux requêtes.
- Si le deuxième master tombe alors le troisième passera Master.
Statistiquement la panne de 2 serveurs sur 3 est assez rare.
GlusterFS cluster (Centos7)
3 machines GlusterFS
- node01-gfsw 172.16.186.24
- node02-gfsw 172.16.186.25
- node03-gfsw 172.16.186.26
GlusterFS est un service de fichiers distribués. Chaque fichier inscrit sur une machine est automatiquement répliqué sur les autres machines du cluster.
Si une machine du cluster est down, les fichiers restent disponibles sur les deux autres nœuds du Cluster.
Nous allons héberger les fichiers de conf (Apache, haProxy ) et le site de WordPress.
Cela nous permettra de centraliser les fichiers nécessaires au fonctionnement des Clusters.
MySQL cluster (AlmaLinux 8 fork RHEL8)
MODOP – PARTIE 3 – Installation WordPress en HA – Cluster Mysql
3 machines MySQL
- node01-sqlw 172.16.186.27
- node02-sqlw 172.16.186.28
- node03-sqlw 172.16.186.29
Le cluster MySQL est constitué de 3 nœuds MySQL en Master-Master-Master. Toutes données inscrites sur un des nœuds est répliquées automatiquement sur les autres nœuds du cluster.
Si une machine est down, les autres machines répondront aux requêtes via le Cluster HaProxy.
Quand la machine reviendra UP dans le Cluster, elle se resynchronisera automatiquement auprès des autres machines du cluster.
Web cluster apache/PHP
MODOP – PARTIE 4 – Installation WordPress en HA – Cluster Apache
3 machines Apache/php
- node01-webw 172.16.186.30
- node02-webw 172.16.186.31
- node03-webw 172.16.186.32
Le Cluster Apache hébergera uniquement le service Apache/PHP pour le site WordPress, il répondra à toutes les requêtes de HaProxy.
Nous sommes encore sous le mode « tiers ». Si une machine cesse de fonctionner les deux autres répondrons aux sollicitations de HaProxy via le LoadBalancing.
Conclusion
Dans notre infrastructure nous avons 4 clusters de service en mode « tiers » Haute disponibilité
- Cluster HaProxy + KeepAlived
- Cluster GlusterFS
- Cluster MySQL
- Cluster Web
Pour que ce mode soit le plus résilient, il faut impérativement provisionner chacun des services sur des machines hyperviseurs différentes (VMware, Proxmox ,HyperV ,etc) .
Bref si un Hyperviseur est down, les deux autres répondrons aux sollicitations des clients.
Si les hyperviseurs sont gérés par le mode HA, les machines virtuelles hébergées par l’hyperviseur en panne migreront automatiquement sur les autres hyperviseurs UP.
Prérequis
La première étape sera d’inscrire toutes les machines de notre infrastructure « WordPress » sur nos DNS primaire et secondaire afin que les machines se trouvent facilement par leur nom d’host.
[root@dns-pri ~]# vi /var/named/forward.house.cpb ; ### infrastructure WordPress ### ; ; Cluster HAproxy node01-haw IN A 172.16.186.20 node02-haw IN A 172.16.186.21 node03-haw IN A 172.16.186.22 node-haw IN A 192.168.1.230 ; Cluster GlusterFS node01-gfsw IN A 172.16.186.24 node02-gfsw IN A 172.16.186.25 node03-gfsw IN A 172.16.186.26 ; Cluster MySQL node01-sqlw IN A 172.16.186.27 node02-sqlw IN A 172.16.186.28 node03-sqlw IN A 172.16.186.29 ; Cluster Web Httpd/PHP node01-webw IN A 172.16.186.30 node02-webw IN A 172.16.186.31 node03-webw IN A 172.16.186.32
Modifier le numéro de série et redémarrer le service apache.
[root@dns-pri ~]# systemctl reload named
Côté DNS Primaire
Côté DNS Secondaire
Test sur un client
Views: 25