Heartbeat et Pacemaker : la haute-disponibilité

haute disponibilité

L’objectif de cette procédure est de couvrir l’installation et la configuration d’un cluster haute disponibilité avec Pacemaker et Heartbeat.

Le résultat attendu : L’application Web ‘AppliFrais’ fournie par une équipe de développeurs devra être hébergée sur un cluster haute disponibilité. Deux machines veilleront l’une sur l’autre et si une panne survient sur une machine, l’autre prendra le relais du service paramétré (serveur Web apache et SQL).

La première partie de la procédure repose sur un fonctionnement de serveur Web uniquement. La deuxième partie aborde le fonctionnement complet pour héberger ‘AppliFrais’ (Apache2 et SQL)

 

 

PARTIE 1 : HEARTBEAT & PACEMAKER SUR APACHE2

 

Prérequis :

-Deux machines physiques ou virtuelles

TRES IMPORTANT : les deux machines doivent être installées à la main et non clonées pour de meilleurs résultats. Si machines virtuelles, carte réseau en mode pont.

 

-Debian Wheezy 7,9 (net-install ou complète)

Pacemaker n’a pas été inclus à temps lors de la publication de la distro Debian Jessie.

Ici, le terme framework Pacemaker signifie le menu intéractif Pacemaker, c’est la commande crm.

 

-Légende : //hostname//InterfaceRéelle//IpR//MaskR//InterfaceVirtuelle//IpV//MaskV

ha-srv1//eth0//192.168.1.200//255.255.255.0//eth0:0//192.168.1.210//255.255.255.0

ha-srv2//eth0//192.168.1.201//255.255.255.0//eth0:0//192.168.1.210//255.255.255.0

 

L’IP virtuelle sur laquelle le serveur Web proposera le site est 192.168.1.210.

C’est pourquoi il nous faut renseigner cette IP sur une interface virtuelle sur chaque nœud du cluster.

 

Ici, les machines ha-srv1 et ha-srv2 seront les nœuds du cluster

 

 

——————————————————————————————————-

ETAPE I : L’installation du premier serveur ‘ha-srv1’

——————————————————————————————————-

 

On commence par installer la debian à la main sur la première machine.

 

Une fois terminé, on configure les interfaces réseaux comme renseigné ci-dessus pour ha-srv1 :

Le fichier /etc/network/interfaces doit ressembler à ceci :

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.200
netmask 255.255.255.0
auto eth0:0
iface eth0:0 inet static
address 192.168.1.210
netmask 255.255.255.0

 

Une fois terminé, il faut également modifier le fichier /etc/hosts en y ajoutant ceci :

ha-srv2 192.168.1.201

 

Ainsi, ha-srv1 connaît désormais ha-srv2 par son nom en plus de son IP et c’est tant mieux.

 

On installe maintenant les logiciels nécessaires à notre cluster :

apt-get install apache2 apache2-doc libapache2-mod-php5 php5 heartbeat pacemaker

 

Une fois effectué, on se dirige dans /var/www/ et on édite index.html en lui ajoutant ceci :

<h1>SERVEUR HA-SRV1 – 192.168.1.200</h1>

 

On crée le fichier /etc/ha.d/ha.cf et on y ajoute ceci :

logfacility local7
logfile /var/log/ha-log
debugfile /var/log/ha-debug
use_logd no
udpport 694
keepalive 2
deadtime 20
initdead 50
auto_failback off
node ha-srv1
node ha-srv2
ucast eth0 192.168.1.200
ucast eth0 192.168.1.201
crm yes

 

On enregistre puis on crée le fichier /etc/ha.d/authkeys et on ajoute ceci :

auth 1

1 sha1 mysecretkey

On enregistre et on effectue un chmod 600 sur ce fichier sinon le serveur ne démarrera pas (ce qu’on peut facilement voir avec un ‘tail -f /var/log/syslog’)

 

 

——————————————————————————————————-

ETAPE II : L’installation du deuxième serveur ‘ha-srv2’

——————————————————————————————————-

 

Pour ha-srv2, le fichier /etc/network/interfaces doit ressembler à ceci :

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.201
netmask 255.255.255.0
auto eth0:0
iface eth0:0 inet static
address 192.168.1.210
netmask 255.255.255.0

 

Une fois terminé, il faut également modifier le fichier /etc/hosts en y ajoutant ceci :

ha-srv1 192.168.1.200

 

Ainsi, ha-srv2 connaît désormais ha-srv1 par son nom en plus de son IP et c’est tant mieux.

On installe maintenant les logiciels nécessaires à notre cluster :

apt-get install apache2 apache2-doc libapache2-mod-php5 php5 heartbeat pacemaker

 

Une fois effectué, on se dirige dans /var/www/ et on édite index.html en lui ajoutant ceci :

<h1>SERVEUR HA-SRV2 – 192.168.1.201</h1>

 

On pourra ensuite contrôler rapidement la situation lorsque le cluster sera fonctionnel.

 

On copie ensuite les fichiers authkeys et ha.cf depuis has-rv1 vers ha-srv2 avec la commande :

DEPUIS ha-srv1 :

scp /etc/ha.d/{authkeys,ha.cf} root@ha-srv2:/etc/ha.d/

OU DEPUIS ha-srv2

scp root@ha-srv1 :/etc/ha.d/{authkeys,ha.cf} /etc/ha.d/

Heatbeat est prêt au lancement

 

SUR LES DEUX MACHINES : service heartbeat restart

——————————————————————————————————-

ETAPE III : Configuration des ressources Pacemaker

——————————————————————————————————-

 

A partir de ce stade, nous ne toucherons plus à Heartbeat et nous allons nous concentrer sur le framework Pacemaker.

Nous allons utiliser la commande crm pour entrer de le framework :

-Touche Entrée pour valider un choix

-Touche Tab pour l’auto-complétion

-Touche TabX2 pour afficher toutes les commandes dans le menu où vous êtes

–up pour remonter d’un niveau dans les menus

–exit ou quit pour quitter

 

Quelques commandes très utiles… :

#Nettoie les erreurs d’un nœud

crm resource cleanup <ressource>

#Affiche la configuration actuelle

crm configure show

# Modifie la configuration actuelle

crm configure edit

# Change l’éditeur de texte par défaut

crm(options) editor nano

# Sauvegarde les options changées

crm(options) save

# Attribuer une ressource à un node préféré

crm resource move ‘nom_ressource’ ‘nom_d’hôte’

# Eteinds le nœud actuel

crm node standby

# Allume le nœud actuel

crm node online

 

#Repartir à zero sur un node :

service heartbeat stop
rm -rf /var/lib/heartbeat/hostcache
rm -rf /var/lib/heartbeat/hb_uuid
rm -rf /var/lib/heartbeat/cib.xml
service heartbeat restart

Petite note :

# Lorsqu’on entre d’abord dans le framework, puis qu’on modifie à l’aide de ‘configure #edit’, crm vérifiera la syntaxe du fichier de configuration et vous informera des #erreurs contenues dans ce fichier. Une fois votre fichier propre, lorsque vous #retournez dans le crm, exécutez un ‘commit‘ pour appliquer les changements à tous #les nodes du cluster. Cette opération se fait automatiquement si il n’y a pas de #problème.

 

On peut lancer les commandes de deux manières :

on lance crm en premier et on navigue à travers les menus

OU

on tape la commande entière depuis le terminal.

 

 

On va commencer par configurer un éditeur de texte par défaut car vi peut être déroutant pour les novices :

crm options
editor nano

 

Vous pouvez remplacer nano par l’éditeur de votre choix, celui par défaut étant vi.

 

On termine ce paramétrage en effectuant un :

save

 

Puis un up pour remonter dans l’arborescence du menu intéractif :

up

 

Pour commencer, il nous faut la base de la haute disponibilité : le FailOver IP.

 

C’est le coeur du système qui détectera la perte d’un nœud et enclenchera la bascule vers le nœud suivant.

 

Dans Pacemaker, les services sont nommés primitives et constituent les ressources et les propriétés sont nommés property et sont les paramètres globaux du cluster.

 

Donc, suivant notre utilisation et le nombre de nœuds disponibles, certaintes propriétés seront configurées spécifiquement. C’est pourquoi il y a deux parties dans cette procédure.

 

note : vous pouvez ouvrir un deuxième terminal et y taper crm_mon pour visualiser l’état de votre cluster (etats des nœuds, ressources attribuées, dernière commande lancée).

 

On crée les paramètres globaux, spécifiques à l’utilisation avec apache2 seul :

crm configure property stonith-enabled=false
crm configure property no-quorum-policy=’ignore’

 

Le STONITH est une technique utilisée pour la haute disponibilité avec un serveur de base de données, ce que nous verrons dans la partie deux de cette procédure.

 

Le QUORUM est une valeur qui correspond aux nombres de nœuds actifs nécessaires au minimum pour la prise de décision lors de la migration d’une ressource.

 

Vu que nous utilisons deux machines, il faut désactiver cette option, sinon elles ne sauront pas qui doit prendre la main. Pour utiliser le quorum, il faut trois machines au minimum.

 

On crée ensuite les ressources dont on a besoin, à savoir :

-une ressource IPFailover (bascule au niveau IP)

-une ressource serviceWeb (bascule au niveau du service apache2)

 

Ressource IPFailover :

crm configure primitive IPFailover ocf:heartbeat:IPaddr2 params ip="192.168.1.210″ cidr_netmask="255.255.255.0″ nic="eth0″ iflabel="VIP" op monitor interval="30s" timeout="20s"

 

Vous devriez voir de l’activité dans votre terminal ‘crm_mon‘.

service heartbeat restart

 

Ressource serviceWeb :

crm configure primitive serviceWeb ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf" op monitor interval="60s" op start interval="0″ timeout="40s" op stop interval="0″ timeout="60s"

 

Petit rappel : Si la communication entre les nœuds fonctionnent, les changements opérés depuis crm sur un nœud seront répliqués sur tous les autres nœuds.

Ainsi, on peut modifier la configuration depuis ha-srv1 ou ha-srv2.

 

On continue en établissant une préférence pour le nœud ha-srv1 avec la commande :

crm resource move IPFailover ha-srv1

 

On groupe les ressources pour qu’elles migrent ensembles et pas réparties selon la charge :

crm configure group cluster-ha IPFailover serviceWeb meta migration-threshold=’5′

 

On redémarre le service sur chaque nœud.

 

On teste dans un navigateur http://192.168.1.210/index.html

Vous devriez voir le nom d’hôte et l’IP du serveur 1 ha-srv1.

 

On continue en lançant un crm_mon dans un autre terminal et en éteignant un nœud avec la commande :

crm node standby

L’autre nœud doit prendre le relais. En allant sur http://192.168.1.210/index.html, vous devriez voir le nom d’hôte et l’IP du serveur 2 ha-srv2.

NOTE: Si vous obtenez les messages suivants dans les ha-logs :

SIOCSIFADDR: No such device
SIOCSIFFLAGS: No such device
SIOCSIFNETMASK: No such device
SIOCSIFBRDADDR: No such device
SIOCSIFFLAGS: No such device
SIOCADDRT: No such device

It may mean that you need to enable IP aliasing in your kernel build.  Check /usr/src/linux/.config for « CONFIG_IP_ALIAS=y ». Rebuildez votre noyau avec l’option IP Aliasing.

 

On redémarre avec :

crm node online

 

Un exemple de crm_mon avant l’extinction du nœud ha-srv1 :

Online: [ ha-srv2 ha-srv1 ]
Resource Group: cluster-hasrv
IPFailover (ocf::heartbeat:IPaddr2): Started ha-srv1
serviceWeb (ocf::heartbeat:apache): Started ha-srv1

 

Et après :

Online: [ ha-srv2 ]
OFFLINE: [ ha-srv1 ]
Resource Group: cluster-hasrv
IPFailover (ocf::heartbeat:IPaddr2): Started ha-srv2
serviceWeb (ocf::heartbeat:apache): Started ha-srv2

 

Une fois ha-srv1 de retour, le paramètre auto_failback renvoie le service au préféré.

 

Pacemaker doit fonctionner maintenant. Il peut faire la bascule au niveau IP et au niveau du service web mais il préfère le nœud ha-srv1, et lui attribuera les deux ressources si il est actif.

 

Mon fichier de configuration Pacemaker pour Heartbeat /var/lib/heartbeat/cib.xml :

node $id= »039eb734-93f8-4634-b390-35721c325ee9″ ha-srv1 \
attributes standby= »off »
node $id= »a9125c53-c6b0-494a-8dde-5d172fd200c2″ ha-srv2 \
attributes standby= »off »
primitive IPFailover ocf:heartbeat:IPaddr2 \
params ip= »192.168.1.210″ cidr_netmask= »255.255.255.0″ nic= »eth0″ iflabel= »VIP » \
op monitor interval= »30s » timeout= »20s »
primitive serviceWeb ocf:heartbeat:apache \
params configfile= »/etc/apache2/apache2.conf » \
op monitor interval= »60s » \
op start interval= »0″ timeout= »40s » \
op stop interval= »0″ timeout= »60s »
group cluster-hasrv IPFailover serviceWeb \
meta migration-threshold= »5″
location cli-prefer-IPFailover cluster-hasrv \
rule $id= »cli-prefer-rule-IPFailover » inf: #uname eq ha-srv1
property $id= »cib-bootstrap-options » \
dc-version= »1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff » \
cluster-infrastructure= »Heartbeat » \
stonith-enabled= »false » \
no-quorum-policy= »ignore »

 

Un commentaire rapide sur VirtualBox headless mode :

Si vous préférez Virtualbox à Vmware, Docker, Lxc et compagnie :

Lorsque vous avez paramétré les interfaces de vos machines virtuelles ainsi que leur serveur ssh respectif, vous n’avez techniquement plus besoin de l’interface graphique de vos machines virtuelles.

Eteignez proprement vos VMs puis, dans l’interface de gestion de Virtualbox, Maintenez Ctrl et cliquez sur vos deux VMs pour les sélectionner.

Maintenez Maj et appuyez sur Entrée et ne relachez Maj que lorsque vous aurez vu vos deux VMs démarrer. Vous venez de lancer vos machines virtuelles en mode headless, ce qui signifie qu’elles sont visibles dans le manager Virtualbox uniquement et ne vous encombrent plus la vue. Faites péter deux terminaux et vous voilà bien.

 

——————————————————————————————————-

ETAPE IV : Configuration des serveurs MySQL en mode réplication – maître/esclave

——————————————————————————————————-

 

PARTIE 2 : HEARTBEAT ET PACEMAKER SUR MYSQL

 

Cette deuxième partie est la suite de la première, il est donc très important d’avoir réussi toutes les étapes de la partie 1 avant de lire cette partie. Elle se base sur les ressources IPFailover et serviceWeb, car l’application Web que nous ont fournis les développeurs doit utiliser une base de données pour fournir un environnement à l’utilisateur.

 

TRES IMPORTANT : l’imports des données dans le SGBG ne se fait qu’à la fin. Cette partie pouvant s’avérer complexe, il vaut mieux vérifier la connectivité et le fonctionnement du cluster ainsi que de la haute disponibilité avant de modifier la base de données.

 

On va ajouter le logiciel mysql-server à nos nœuds, configurer les serveurs mysql en mode réplication, reconfigurer les paramètres globaux de Pacemaker et créer une nouvelle ressource pour nos SGBD MySQL.

 

Ici, nous allons voir le fonctionnement en ‘maître/esclave’.

 

On installe mysql-server sur les deux nœuds avec la commande :

apt-get install mysql-server

 

On paramètre le super-utilisateur lors de l’installation sur les deux machines :

root/motdepasse_root_SQL

 

Pour modifier le mdp super-utilisateur de SQL :

dpkg-reconfigure mysql-server

 

Pour créer une base de données :

mysql -u utilisateur -p

CREATE DATABASE nom_bdd

 

Pour importer une base de données (sous format SQL) :

mysql -u utilisateur -p base_exportee < base_exportee.sql

 

Pour exporter une base de données (sous format SQL) :

mysqldump –all-databases -u root -p > serveur.sql

 

Sur ha-srv1, le serveur maître :

On bloque l’écriture de cette base de données jusqu’à nouvel ordre pour pouvoir synchroniser les deux serveurs MySQL.

On lance mysql :

mysql -u root -p

 

On affiche les bases :

mysql> show databases;
+——————–+
| Database |
+——————–+
| information_schema |
| mysql |
| performance_schema |
+——————–+
3 rows in set (0.00 sec)

 

Créez un base de données sur chaque nœud si vous n’en avez pas :

mysql -u root -p CREATE DATABASE nom_bdd

 

On peut maintenant sauvegarder le fichier /etc/mysql/my.cnf en /etc/mysql/my.cnf.bak

mv /etc/mysql/my{.cnf,.cnf.bak}

 

On crée un nouveau /etc/mysql/my.cnf et on y ajoute ceci :

[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld ]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
query_cache_limit = 1M
query_cache_size = 16M
#bind-address = 127.0.0.1
log-error = /var/log/mysql.err
server-id = 100
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
binlog_do_db = nom_bdd
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[isamchk]
key_buffer = 16M
!includedir /etc/mysql/conf.d/

 

Sur ha-srv2, le serveur esclave :

On peut sauvegarder le fichier /etc/mysql/my.cnf en /etc/mysql/my.cnf.bak, mv /etc/mysql/my{.cnf,.cnf.bak}, on crée un nouveau /etc/mysql/my.cnf et on y ajoute ceci :

[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld ]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
query_cache_limit = 1M
query_cache_size = 16M
#bind-address = 127.0.0.1
log-error = /var/log/mysql.err
server-id = 104
log_bin = /var/log/mysql/mysql-bin.log
log-slave-updates
expire_logs_days = 10
max_binlog_size = 100M
master-retry-count = 20
replicate-do-db = nom_bdd

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[isamchk]
key_buffer = 16M
!includedir /etc/mysql/conf.d/

 

Redémarrez le serveur SQL sur les deux machines afin de prendre en compte la nouvelle configuration.

Le service vous dira surement :

[ ok ] Starting MySQL database server: mysqld ..

[info] Checking for tables which need an upgrade, are corrupt or were not closed cleanly..

Pas de soucis, c’est juste un [info]. Un [Warning] ou [Error], là c’est le drame.

 

On retourne sur ha-srv1, le maître :

On lance mysql -u root -p

Et on accorde tous les droits sur root pour lui permettre de répliquer :

GRANT ALL PRIVILEGES ON *.* TO ‘root’@’%’ IDENTIFIED BY ‘tonmotdepasseroot’ WITH GRANT OPTION;

FLUSH PRIVILEGES ;

 

et on vérouille la base de données pour éviter les écritures intempestives pendant notre synchronisation :

FLUSH TABLES WITH READ LOCK ;

 

Le point-virgule est important pour terminer une commande. Ce mode de syntaxe est utile pour effectuer des requêtes imbriquées indentées depuis mysql>.

 

Le vérrouillage de la base de données maître va nous permettre de récupérer le marqueur de position de la bdd sur ha-srv1 et d’indiquer le même marqueur de position sur ha-srv2, permettant une synchronisation entre les deux instances de mysql-server.

 

Dans mysql>

 

show master status ;

Qui retourne :

+——————+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000005 | 107 | nom_bdd | |
+——————+———-+————–+——————+
1 row in set (0.00 sec)

On va maintenant synchroniser le serveur SQL de ha-srv2 avec celui du ha-srv1.

Dans l’optique :

ha-srv1 : maître

ha-srv2 : esclave

(ne pas oublier les virgules en fin de ligne, pour spécifier que la commande continue)

Les paramètres suivants sont spécifiques, à vous d’adapter :

Sur ha-srv2 :

mysql -u root -p
stop slave ;
change master to
master_host=’192.168.1.200′,
master_user=’root’,
master_password=’mdp-super-user-sql’,
master_log_file=’mysql-bin.000005′,
master_log_pos=107 ;
start slave ;

 

Puis, on dévérouille les tables sur ha-srv1 :

mysql -u root -p
UNLOCK TABLES ;

Enfin, on vérifie que les valeurs File et Position de la commande show master status ; sur ha-srv1 correspondent aux valeurs de Master-Log-File et Read_Master_Log_Pos de la
commande show slave status \G ; sur ha-srv2.

Sur votre esclave, dans mysql -u root -p, la commande show slave status \G ; doit retourner les paramètres Slave_IO_Running et Slave_SQL_Running sur YES.

Sinon, si il y a la moindre erreur, vérifiez /var/log/mysql.err et cherchez le code d’erreur sur le Net.

Pour les sauvegardes, il est important de sauvegarder sur l’esclave, les fichiers /var/lib/mysql/master.info et /var/lib/mysql/relay-log.info.

Ils permettrons de reprendre une réplication après une restauration de base.

 

 

——————————————————————————————————-

ETAPE V : Configuration des serveurs MySQL en mode réplication – maître/maître

——————————————————————————————————-

 

MySQL doit être dans le cluster de haute-disponibilité.

On va choisir la solution la plus simple : passer les deux nœuds en maître.

 

Ainsi, si un nœud tombe, l’autre prendra le relais et guidera le premier nœud pour retrouver le bon curseur afin de reprendre la synchronisation.

Il va donc nous falloir :

-Ajouter les données esclave sur le maître

-Ajouter les données maître sur l’esclave

-Redémarrer MySQL

-Donner tous les droits à root sur l’esclave

-Bloquer l’écriture sur les deux serveurs

-Repérer le log-bin et la position du curseur sur chaque noeud

-Configurer l’esclave en maître sur le serveur maître avec change master to et les paramètres File et Position de l’esclave

-Configurer le maître en maître sur le serveur esclave avec change master to et les paramètres File et Position du maître

-Déverrouiller les tables et contrôler avec show slave status \G ;

Et pour la répartition de charge :

-Ajouter sur chaque nœud :

auto_increment_increment = 2

auto_increment_offset = [1-N] (unique sur chaque nœud ,c’est un pas de décalage)

 

On ajoute les données eslave sur le maitre :

Dans /etc/mysql/my.cnf sur ha-srv1, on ajoute :

log-slave-updates
master-retry-count = 20
replicate-do-db = nom_bdd
relay-log = mysqld-relay-bin
auto_increment_increment = 2
auto_increment_offset = 1

 

Et les données maître sur l’esclave :

Dans /etc/mysql/my.cnf sur ha-srv2, on ajoute :

binlog-do-db = nom_bdd
auto_increment_increment = 2
auto_increment_offset = 2

On redémarre MySQL sur les deux nœuds.

On va maintenant effectuer les modifications sur les deux bases de données pour indiquer à chaque nœud que l’autre est son maître.

 

Sur ha-srv2 :

mysql>grant all privileges on *.* to ‘root’@’%’ IDENTIFIED BY ‘mdp_super_user_sql’ WITH GRANT OPTION;
mysql>flush privileges;
mysql>flush tables with read lock ;
mysql> show master status ;
+——————+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000004 | 267 | nom_bdd | |
+——————+———-+————–+——————+
1 row in set (0.00 sec)

 

sur ha-srv1 :

mysql>stop slave ;
mysql>change master to
master_host=’192.168.1.201′,
master_user=’root’,
master_password=’mdp_super_user_sql’,
master_log_file=’mysql-bin.000004′,
master_log_pos=267 ;
mysql>show master status
+——————+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000007 | 107 | nom_bdd | |
+——————+———-+————–+——————+
1 row in set (0.00 sec)

 

sur ha-srv2 :

mysql>stop slave ;
mysql>change master to
master_host=’192.168.1.200′,
master_user=’root’,
master_password=’mdp_super_user_sql’,
master_log_file=’mysql-bin.000007′,
master_log_pos=107 ;

Et un start slave sur les deux nœuds pour finir:D

 

On vérifie :

On peut constater en lançant sur chaque machine :

Sur ha-srv1 :

mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.201
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 267
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: nom_bdd

 

et sur ha-srv2 :

mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.200
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000007
Read_Master_Log_Pos: 107
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000007
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: nom_bdd

 

C’est parfait : ha-srv1 a bien le Master-Log-File et Read_Master_Log_Pos de ha-srv2 et inversement et les paramètres Slave_IO_Running et Slave_SQL_Running sont sur YES. C’est le
résultat attendu pour passer à l’étape finale.

 

Sur ha-srv1

mysql>create table test (colonne1 int) ; doit apparaître sur ha-srv2 mysql>show tables ;

 

 

——————————————————————————————————-

ETAPE VI : Configuration de la ressource MySQL pour Pacemaker

——————————————————————————————————-

Grâce à notre configuration spéciale sur MySQL, il ne nous reste plus qu’à créer la ressource sur Pacemaker.

Pour utiliser une infrastructure maître/maître, il nous faut utiliser l’un des modes de clonage de ressources dans Pacemaker.

Les modes :

-anonymous : ressources identiques sur chaque nœud

-globally-unique=true : ressources differentes sur chaque nœud

-multi-state : ressources qui peuvent être dans deux états différents

Ici, nous allons utiliser le mode anonymous, car nos bases de données doivent rester identiques quoiqu’il arrive.

 

On crée la ressource dans Pacemaker :

crm configure primitive serviceSQL ocf:heartbeat:mysql \
params socket= »/var/lib/mysqld/mysqld.sock » \
op monitor depth= »0″ timeout= »30″ interval= »20″ \
op monitor role= »Master » depth= »0″ timeout= »30″ interval= »10″ \
op monitor role= »Slave » depth= »0″ timeout= »30″ interval= »30″ \
op start timeout= »120″ \
op stop timeout= »120″

Une fois la ressource crée, on la clone :

crm configure clone

Un crm_mon va rapidement confirmer notre succès :

Les serveurs sont actifs tous les deux :

crm_mon
============
Last updated: Mon Jan 4 05:03:01 2016
Last change: Mon Jan 4 05:02:57 2016 via crm_attribute on ha-srv1
Stack: Heartbeat
Current DC: ha-srv1 (039eb734-93f8-4634-b390-35721c325ee9) – partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, unknown expected votes
4 Resources configured.
============
Online: [ ha-srv2 ha-srv1 ]
Resource Group: cluster-hasrv
IPFailover (ocf::heartbeat:IPaddr2): Started ha-srv1
serviceWeb (ocf::heartbeat:apache): Started ha-srv1
Clone Set: serviceSQL2 [serviceSQL]
Started: [ ha-srv2 ha-srv1 ]

On désactive ha-srv1 crm node standby et sur ha-srv2, le crm_mon donne ceci :

============

Node ha-srv1 (039eb734-93f8-4634-b390-35721c325ee9): standby
Online: [ ha-srv2 ]
Resource Group: cluster-hasrv
IPFailover (ocf::heartbeat:IPaddr2): Started ha-srv2
serviceWeb (ocf::heartbeat:apache): Started ha-srv2
Clone Set: serviceSQL2 [serviceSQL]
Started: [ ha-srv2 ]
Stopped: [ serviceSQL:1 ]

 

 

——————————————————————————————————-

ETAPE VII : Les derniers préparatifs

——————————————————————————————————-

Voilà, il ne reste plus qu’à importer vos tables dans l’un des serveurs SQL, et d’importer l’application Web ‘AppliFrais’ des développeurs sur vos deux serveurs WEB.

Une bascule peut être effectuée au niveau IP et serveur WEB, mais les deux serveurs SQL écrivent en continu l’un sur l’autre toutes les modifications. Si un serveur SQL tombe,
les fichier de log du deuxième lui permettrons de se resynchroniser et de rattraper le retart qu’il à pris lorsqu’il était inactif.