Failover avec Hearbeat, rsync et réplication mysql
Pour mieux expliquer ce TP, j'ai pris un exemple concret: une installation de Wordpress, qui nous permettra de tester la réplication des fichiers et de la BDD !
Prérequis :
- Installer Debian 10 et ses mises à jour
- Cloner la VM pour en créer une autre, identique
- Renommer le clone /etc/hostname
- Configurer les IP statiques sur les 2 VM
- Choisir une IP virtuelle pour le cluster
Installation d'Heartbeat
(a faire sur chaque node)
apt install heartbeat
Création du fichier de configuration:
nano /etc/heartbeat/ha.cf
Ajoutez les paramètres suivants:
# Indication du fichier de log
logfile /var/log/heartbeat.log
# Les logs heartbeat ne seront pas gérés par syslog
logfacility none
# On liste tous les membres de notre cluster heartbeat (par les noms de préférences)
node NOM_DU_NODE1
node NOM_DU_NODE2
# On défini la périodicité de controle des noeuds entre eux (en seconde)
keepalive 1
# Au bout de combien de seconde un noeud sera considéré comme "mort"
deadtime 10
# Quelle carte résau utiliser pour les broadcasts Heartbeat (ens33 dans mon cas)
bcast ens18
# Adresse du routeur pour vérifier la connexion au net
ping 10.10.1.254
# Rebascule-t-on automatiquement sur le primaire si celui-ci redevient vivant ? oui*
auto_failback yes
Création du fichier de clé:
nano /etc/heartbeat/authkeys
Ajoutez les paramètres suivants:
auth 1
1 sha1 UneCle
Édition des droits sur le fichier:
chmod 600 /etc/heartbeat/authkeys
Création du fichier haressources:
nano /etc/heartbeat/haresources
On indique le nom du node primaire et son IP
NODE1 10.10.1.127
Démarrage d'Heartbeat:
systemctl start heartbeat
Si tout se passe bien, sur le premier node l'IP virtuel apparaît
Installation de Wordpress
(Vous pouvez passer cette étape si vous avez votre propre site)
Idem, à faire sur les deux nodes
Installation du serveur LAMP:
apt install apache2 mariadb-server php libapache2-mod-php php-cli php-common php-curl php-gd php-json php-mbstring php-mysql php-xml php-xmlrpc php-soap php-intl php-zip
Création de la base de donnée:
mysql -u root -p
CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
GRANT ALL ON wordpress.* TO 'wordpress_user'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
EXIT;
Téléchargement et décompression de WordPress:
cd /tmp
wget https://wordpress.org/latest.tar.gz
tar xzvf latest.tar.gz
Création du fichier .htaccess
touch /tmp/wordpress/.htaccess
Copie du fichier config exemple en fichier config :
cp /tmp/wordpress/wp-config-sample.php /tmp/wordpress/wp-config.php
Copie du dossier temporaire vers le dossier définitif :
cp -a /tmp/wordpress/. /var/www/html/wordpress
Donner les permissions au dossier /wordpress :
chown -R www-data:www-data /var/www/html/wordpress
Configurer le fichier de config Wordpress :
nano /var/www/html/wordpress/wp-config.php
Remplacer :
- database_name_here
- user_name_here
- password_here
- régler la collation de la base de donnée comme configurée plus tôt
Redémarrer Apache, se connecter via navigateur, vérifier que le site wordpress est accessible. (Sur les deux Nodes)
Ne finissez pas la configuration de WordPress !
Réplication du dossier de l’application avec Rsync
Synchronisation des dossiers wordpress avec Rsync
Installation de Rsync (par defaut il y est deja, au cas ou)
apt install rsync
Test de Rsync à partir du Node secondaire :
rsync --delete -avzhe ssh root@10.10.1.167:/var/www/html/wordpress/ /var/www/html/wordpress/
Mise en place du login SSH sans mot de passe, par certificat, sur le node secondaire :
ssh-keygen -t rsa -b 2048
ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.10.1.158
Test de la connexion sans mot de passe
ssh root@10.10.1.158
Vous avez accès directement au shell sans rentrer de mot de passe
Automatisation de la synchro entre les deux Nodes :
Créer un script /scripts/rsync.sh
Y coller la commande rsync précédente
Si besoin on ajoute les droits d’exécution:
chmod +x rsync.sh
On ajoute la cron:
crontab -e
On teste en créant un fichier dans le dossier wordpress sur le Node principal, il devrait être créé sur le Node secondaire moins d’une miute après.
On le supprime et on vérifie qu’il soit bien supprimé.
Réplication des bases de donnée :
Sur le Node principal (base Master) :
On active les binary logs
mysql -u root -p
SET sql_log_bin = 1;
exit
A la fin du fichier /etc/mysql/my.cnf
an ajoute les paramètres suivants :
[mariadb]
log-bin
server_id=1
log-basename=master1
On redémarre le service MySQL
systemctl restart mysql
On crée un utilisateur pour la réplication :
CREATE USER 'replication_user'@'%' IDENTIFIED BY 'repli_password';
GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'%';
Sur le Node secondaire :
Même principe, a la fin du fichier /etc/mysql/my.cnf
an ajoute les paramètres suivants (pensez à changer l'ID):
[mariadb]
log-bin
server_id=2
log-basename=master1
On redémarre le service MySQL
systemctl restart mysql
On configure la base en esclave :
mysql -u root -p
CHANGE MASTER TO
MASTER_HOST='10.10.1.158',
MASTER_USER='replication_user',
MASTER_PASSWORD='repli_password',
MASTER_PORT=3306,
MASTER_CONNECT_RETRY=10;
On démarre le mode esclave :
START SLAVE;
On vérifie l’état de la synchronisation :
SHOW SLAVE STATUS;
Si la synchronisation est fonctionnelle, on peut tester en terminant la configuration sur le Node primaire. Celle ci devrait s’appliquer automatiquement sur le Node secondaire.
On crée un article Wordpress, il devrait être dupliqué sur le second serveur.
Voila, votre site web est répliqué !
No Comments