2014 Haute- disponibilité Serveur WebRedondance serveur web avec heartbeat et peacemaker

Maestre AnthonyCFA ROBERT SCHUMAN

Haute disponibilité d'un service Web dynamique

Page 1/41

Propriétés Description

Type de publication Côté Labo

Intitulé court Haute disponibilité d'un serveur Web dynamique

Intitulé long Haute disponibilité d'un serveur Web avec réplication de la base de données correspondante.

Module BTS SIO2 – SISR3 – Exploitation des services

Date de publication Septembre 2013

Date de modification Septembre 2013

Version V1.0

Transversalité SI7 : Justifier le choix d’une solution de mise en production d’un service Stratégies et techniques associées à la continuité de service Stratégies et techniques de sauvegarde et de restauration de

données Stratégies et techniques de répartition et de réplication

SISR4 : Justifier le choix d’une solution de gestion de la disponibilité d’un

serveur Installer et configurer une solution de disponibilité de serveurs Disponibilité des systèmes, méthodes, technologies, techniques,

normes et standards associés

Présentation L'objectif de ce Coté Labo (mis en œuvre en module) est de mettre en place une solution de haute disponibilité pour l'application de gestion de frais du laboratoire pharmaceutique Galaxy-Swiss Bourdin (GSB)

Il fait suite au Coté Labo « Le service Web sécurisé » : http://www.reseaucerta.org/?q=content/service-web-s%C3%A9curis%C3%A9

Activités D1.3 - Mise en production d'un service A1.3.2 Définition des éléments nécessaires à la continuité d'un

serviceD2.1 - Exploitation des services

A2.1.2 Évaluation et maintien de la qualité de serviceD3.2 - Installation d’une solution d’infrastructureD3.3 - Administration et supervision d'une infrastructure

A3.3.1 Administration sur site ou à distance des éléments d'un réseau, de serveurs, de services et d'équipements terminaux

Pré-requis Avoir quelques notions sur l'installation, la configuration et l'administration d'un serveur Linux (ou Ubuntu).Exploitation des services Web et bases de données (dont sauvegarde et restauration).L'application gestion de frais est installée et opérationnelle.

Savoir-faire principaux

En SISR3 : Caractériser les éléments nécessaires à la qualité, à la continuité et à

la sécurité d'un service Installer et configurer les éléments nécessaires à la qualité et à la

continuité du service Valider et documenter la qualité, la continuité et la sécurité d'un

service

Page 2/41

Prolongements En SI7 : Rédiger, mettre en place et tester un Plan de Continuité D'activité

(PCA)

En SISR3 : Assurer la haute disponibilité des autres services présents sur le

serveur Intégrer la répartition de charges

En SISR5 : Superviser le Cluster

Outils SE : Serveur Linux Debian Wheezy (stable actuelle) ou ultérieurServeurs/services : Apache2, PHP, MySQL-server installé et configuré à l'identique sur deux serveurs, Hearbeat et Pacemaker.Clients : navigateur web sur STA Linux, Windows ou autre système.Outils d'analyse et de tests de bon fonctionnement ainsi que phpMyAdmin.Contexte : organisation/GSB-Organisation.doc.

Site officiel de Pacemaker : http://clusterlabs.org/Documentation : http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html-single/Pacemaker_Explained/index.html

Mots-clés Disponibilité, HA, HD, Cluster, Heartbeat, Pacemaker, réplication.

Durée 12 heures en TP

Auteur(es) Apollonie Raffalli

La haute disponibilité

La « haute disponibilité » (en anglais « high availability ») regroupe de nombreuses techniques et processus permettant de garantir un certain pourcentage de disponibilité d'un service.Par exemple, un taux de 99 % de disponibilité assure une disponibilité d'environ 361 jours sur 364 alors qu'un taux de 99,5 % assure une disponibilité de plus de 363 jours sur 365.

La réalité économique fait que les organisations tendent de plus en plus vers des taux encore plus grands comme 99,9 % ou 99,99 % notamment sur certains services critiques. En effet, les conséquences d'une interruption de service sont innombrables et peuvent coûter très cher à tous points de vue.

Par exemple, sur le site http://www.zdnet.fr, on pouvait lire qu'une interruption de service de 40 mn le 19 août 2013 aurait fait perdre à Amazon près de 5 millions de dollars.(http://www.zdnet.fr/actualites/comme-google-amazon-a-subi-une-panne-informatique-39793254.htm)

Pour améliorer la haute disponibilité, il existe de nombreuses configurations possibles.

Dans une configuration très simple (celle que nous allons découvrir dans ce Côté labo), la haute disponibilité nécessite la présence d'un serveur secondaire, fonctionnant sous le même système d'exploitation et fournissant un accès aux services que l'on souhaite rendre « hautement » disponibles.

Ce second serveur configuré à l'identique, en règle générale services arrêtés, surveillera le premier en permanence. En cas de panne du serveur primaire, il le détectera et prendra la relève, devenant alors le nouveau serveur actif.Préparer votre serveur web (machine physique ou vitruelle)

Page 3/41

Comment ça marche ?

Selon http://www-igm.univ-mlv.fr/~dr/XPOSE2006/JEREMIE_LEGRAND_HAUTE_DOSPO/index.htm

Un des algorithmes utilisés pour ce genre d'opérations est basé sur la tachycardie. Il est appelé « heartbeat », ou battements de cœur. Le serveur actif émet régulièrement des informations sur le réseau pour dire qu'il est vivant, pendant que l'autre écoute passivement.

Si plus aucune information n'arrive au serveur en écoute, celui-ci s'alarme :

Il prend alors le rôle de serveur actif (les services basculent sur ce serveur) et se met à son tour à émettre des battements de cœur. Si l'autre serveur est restauré, il jouera, au moins dans un premier temps, le rôle de serveur en écoute.

N'importe quelle machine pourra ainsi tomber en panne sans que l'ensemble ne soit pénalisé.

Ces techniques seront mises en œuvre via deux outils à installer et configurer : Heartbeat qui permet de détecter la défaillance d'un poste grâce à un système de

communication basé sur un échange de paquets UDP et de gérer le Cluster en lui-même (on aurait pu tout aussi bien utiliser ici un autre outil comme « Corosync »).

Pacemaker qui est un gestionnaire de ressources. Il est chargé de créer, démarrer, arrêter et superviser les ressources du Cluster c'est à dire les services gérés en Cluster et donc inclus dans la continuité de services.

Problématique n°1

La haute disponibilité sous-entend que plusieurs machines seront utilisées pour répondre à un même service. Seulement, chaque machine a normalement une adresse IP différente sur le réseau, ce qui est problématique puisque le client ne connaît qu'une seule adresse IP et/ou le nom d'hôte pleinement qualifié (qui n'est associé qu'à une seule adresse IP).

Comment alors faire en sorte que toutes les machines en haute disponibilité répondent à la même adresse ? 

Il faut mettre en place une adresse IP virtuelle, c'est-à-dire une adresse IP qui ne sera pas toujours reliée à la même machine physique. L'adresse IP virtuelle est en fait attribuée au Cluster c'est à dire au groupe de machines participant à la haute disponibilité. L'utilisateur ne connaîtra que cette adresse, et sera en fait redirigé vers l'un ou l'autre des serveurs par un mécanisme réseau. 

Pour cela, plusieurs solutions sont possibles. Dans notre cas, nous n'utilisons que 2 machines en haute disponibilité (une active et une passive) ; une seule d'entre elles fonctionne pour répondre aux requêtes, on peut lui demander de reconnaître 2 adresses IP au lieu d'une : la sienne et l'adresse virtuelle. Toute requête est adressée à l'adresse IP virtuelle.

Lorsqu'elle tombe en panne, la machine passive prend la main, lance ses services et se met à répondre à son tour aux requêtes à destination de l'IP virtuelle.

Page 4/41

Exemple d'un fonctionnement en cas de serveur maître disponible :

Si le serveur maître n'est plus disponible :

Lorsque la première machine est restaurée, deux options peuvent être envisagées : elle pourra faire à son tour office de secours ; elle pourra forcer l'autre machine à redevenir passive, et prendre sa place actuelle.

Remarque : c'est l'adresse IP virtuelle qui doit « apparaître » dans les fichiers de configuration des services (par exemple, dans la configuration des serveurs Web virtuels et celle du serveur DNS).

Problématique n°2

Cette architecture basée sur un basculement de services nécessite aussi une solution qui va permettre d'accéder à tout moment aux données actuelles.

La plupart des services inclus dans un système de haute disponibilité utilise des données, parmi eux : le service Web utilise quasi systématiquement des données stockées dans des bases de

données SQL (et/ou XML) qu'il est donc nécessaire de répliquer également comme nous allons le faire dans ce côté labo ;

le service d'authentification (parfois lui-même également utilisé par le service Web) stocke des données dans des annuaires (comme LDAP) qu'il faut également répliquer ;

Le service de fichier (comme Active Directory ou Samba sur Linux, un serveur NFS, un serveur FTP, etc.) utilise bien évidemment les données des utilisateurs stockées sur une partition locale ou distante. il est alors nécessaire de disposer d'un programme qui synchronise en temps réel une partition entre deux machines (une sorte de RAID 1 réseau) : la solution la plus utilisée pour créer ce type de serveur est d'utiliser Distributed Replicated Block Device (DRBD) comme nous allons l'étudier dans le Côté labo suivant.

Plusieurs architectures sont possibles.

En règle générale, les données sont stockées sur un serveur « à part » (un serveur de base de données, par exemple) :

Page 5/41

Si le serveur maître n'est plus disponible, tout ce qui est écrit dans la base de données sera retrouvé par le serveur esclave puisqu’il s'agit de la même base de données mais nous introduisons ici un point de faiblesse car en cas de défaillance physique du serveur de bases de données lui-même (et pas seulement d'un disque), les données ne sont plus disponibles.

Il faut donc assurer aussi la haute disponibilité du serveur de bases de données en répliquant les bases contenant les données utiles en temps réel sur une autre machine.

Par mesure de simplification, les bases de données seront, dans ce Côté labo, implantées sur le même serveur que le serveur Web mais le principe de réplication est strictement identique.

Page 6/41

La réplication d'un système de gestion de base de données

L'architecture native de la réplication MySQL est basée sur une architecture maître-esclave ou réplication unidirectionnelle.

Le principe est simple : un seul serveur (le maître) assure les opérations d’écriture (commandes SQL INSERT, UPDATE et DELETE) et éventuellement de lecture (commande SQL SELECT), tandis que les esclaves se contentent d'enregistrer les modifications opérés sur le maître. Dans certains cas (lorsque l'application cliente est développée à cet effet) les esclaves assurent aussi les opérations de lecture. La synchronisation entre le maître et les esclaves est quasi instantanée.

Une solution existe en cas de défaillance du maître : il suffit d’activer les opérations d’écriture sur un esclave pour disposer d’un nouveau maître ; cette solution peut être mise en œuvre manuellement ou automatiquement si l'on s'adjoint d'autres outils comme un outil capable de dire si le serveur est tombé et/ou des scripts pour basculer un serveur d'esclave vers maître et vice-versa.

Le type de réplication idéal lorsque deux nœuds sont en jeu reste quand même la réplication bidirectionnelle : tout ce qui est réalisé sur un serveur est recopié sur l'autre en temps réel et vice-versa : relation maître-maître ou pour être plus précis (maître/esclave et esclave/maître). Ce type de réplication est obligatoire lorsqu'on a pour but d'équilibrer la charge d'une base de données en lecture et écriture. Mais une base de données devant se mettre à jour en écriture simultanément sur plusieurs serveurs pose des problèmes techniques et il est nécessaire d'utiliser des technologies de Clustering comme le fait MySQL Cluster qui est la base de données distribuée de MySQL. Cette dernière solution est, sommes toutes, difficile à mettre en œuvre, aussi des configurations plus simples et fiables permettant de transformer une réplication maitre-esclave en maître-maître (ou multi maître) ont vu le jour et correspondent à la majeure partie des contextes de production.

C'est cette dernière que nous mettrons en œuvre dans ce Côté labo.

Vous trouverez en : annexe 1 : le fonctionnement et la configuration des outils Heartbeat dans sa version 3 et

Pacemaker ; annexe 2 : la configuration des ressources ; annexe 3 : le principe de la réplication sur MySQL ; annexe 4 : un récapitulatif des commandes courantes.

Contexte

Le laboratoire pharmaceutique Galaxy-Swiss Bourdin (GSB) met à disposition des visiteurs médicaux une application Web sécurisée de gestion des frais de remboursement (Cô té labo «   Service Web sécurisé   » ). Cette application nécessite :

un serveur Web sécurisé (HTTPS, SSL/TLS)  ; l'accès à une base de données relationnelle, éventuellement administrable par interface Web.

L'authentification des visiteurs pour l'accès au contenu est gérée par l'application à travers la base de données.

L'entreprise a choisi d'héberger en interne les serveurs exécutant l'application sur un serveur Linux.Par mesure de simplification, les deux serveurs sont sur la même machine physique. À noter aussi que ce Côté labo peut être réalisé même si le protocole HTTPS n'a pas été mis en œuvre.

GSB désire disposer d'un serveur de secours prêt à prendre le relais si le serveur principal venait à ne plus être opérationnel.

Vous disposez, dans la ferme des serveurs, d'une machine virtuelle (et vous êtes en mesure d'en créer d'autres) sur laquelle se trouve l'application Web opérationnelle en HTTP ou HTTPS. Les fichiers de configuration devront être à terme modifiés pour intégrer l'adresse IP virtuelle.

La résolution des noms est prise en charge par un serveur DNS déjà configuré qui a (en interne) autorité sur la zone gsb.coop.Votre serveur fait partie de la zone gsb.coop, il est accessible par son nom pleinement qualifié déclaré sur le serveur DNS (par exemple, pour les tests, servIntralabXX.gsb.coop où XX représente les initiales de vos prénoms et noms).

Page 7/41

Dans un premier temps vous utiliserez un contexte de test avec les enregistrements test1 et teste2 dans le domaine (la zone DNS) sisr.Les applications web sont test1 et test2 utilisant la base de données test sous MYSQL

Page 8/41

Déroulement de la séquence

Préalable :

1. Rédigez une note listant les techniques et processus communément utilisés pour améliorer la disponibilité d'un service.

Éléments de réponse, d’après Wikipédia (http://fr.wikipedia.org/wiki/Haute_disponibilit%C3%A9) :Techniques pour améliorer la haute disponibilité :● redondance des matériels (RAID, double alimentation, double carte réseau, etc) ;● manipulation des serveurs "à chaud" ;● local adapté (onduleur, climatisation, sécurisation contre la malveillance, sécurisa-tion quantau risque d'incendie et de dégât des eaux, etc) ;● sécurisation des sauvegardes (externalisation, centralisation) ;● mise en Cluster (redondance des serveurs et le basculement d’un serveur à l’autre) ;● fonctionnement en mode dégradé.Processus pour améliorer la haute disponibilité :● processus de contrôle qui permettront de réduire le nombre d'incidents (mieux vaut prévenirque guérir) :◦ processus de gestion des changements : 60 % des erreurs sont liées à un change-mentrécent. En mettant en place un processus formalisé, accompagné de tests suffisants (etréalisés dans un environnement de pré-production correct), de nombreux incidentspeuvent être éliminés.◦ Un processus de gestion pro-active des erreurs : les incidents peuvent bien souvent êtredétectés avant de survenir : les temps de réponse augmentent... Un processus dédié àcette tâche, et muni des outils adéquats (système de mesure, de reporting...) pourraintervenir avant même que l'incident n'arrive.● Les processus réduisant la durée des pannes : les pannes finissent toujours par arri-ver. À cemoment-là, le processus de reprise en cas d'erreur est primordial pour que le service soitrestauré au plus vite. Ce processus doit avoir un objectif : permettre à l'utilisateur d'utiliser unservice le plus rapidement possible. La réparation définitive doit donc être évitée car elleprend beaucoup plus de temps. Ce processus devra donc mettre en place une solu-tion decontournement du problème. Il peut aussi inclure deux procédures :◦ procédure pour enclencher la bascule en mode secours ;◦ procédure pour revenir à la situation initiale.

Page 9/41

1. Préparation des serveurs primaire et secondaire

Le travail sera dans un premier temps réalisé sur le serveur qui tiendra lieu de serveur maître que l'on clonera par la suite.Le serveur primaire aura pour nom d'hôte « interne » « intralab »  et le serveur secondaire « hdintralab » .

L'exemple de configuration qui suit est basé sur la configuration IP suivante :

intralab : serveur maître

http://www.debian.org/doc/manuals/debian-reference/ch05.fr.html (fichier /etc/hostname) IP réelle : 10.22.100.212/16 --> c'est celle qui est dans /etc/network/interfaces IP virtuelle : 10.22.100.220 attribuée plus tard

Cependant, afin de tester le serveur, nous lui attribuons l’adresse IP virtuelle, donc 10.22.100.220Nous avons donc ceci :

Page 10/41

Nous attribuerons l’adresse ip fixe une fois le serveur primaire cloné

1. Vérifiez que l'application Gestion de frais (ou test) est bien accessible sur le serveur maître (modifier les fichiers du dns et d’apache avec les nouvelles adresses IP).

L’adresse IP du DNS se trouve dans le fichier /etc/resolv.conf (DNS par défaut)

Configuration de la zone inverse :

J’entre les adresses IP correct pour test1 et test2 ainsi que les serveurs (ip non virtuelle), puis de meme pour la zone inverse

Page 11/41

Puis je redémarre le service et je teste le DNS

Page 12/41

Puis j’ai configuré test1.conf et test2.conf situé dans /etc/apache2/sites-available, en ajoutant l’adresse Ip ou le FQDN (test1.sisr :80)

J’active test1.conf

Puis je desactive le service SSL afin qu’il n’entrave pas le fonctionnement de peacemaker, suite à quoi je redémarre le service web apache2

2. Installez Heartbeat, configurez les deux fichiers principaux et accordez les droits nécessaires.

Je crée les deux fichiers principaux ah.cf et authkeys dans le dossier /etc/ha.d et je les configure :

Dans le fichier ah.cf

Dans le fichier authkeys

Page 13/41

Un Cluster est un groupe d'ordinateurs reliés qui travaillent en étroite collaboration. Un Cluster est donc constitué d'au moins 2 machines (physiques ou virtuelles).Les machines d'un Cluster sont appelées « nœuds » (nodes en anglais). Un nœud est donc une machine qui participe à un Cluster (qui est membre d'un Cluster).

À partir de Hearbeat dans sa version 2, il est possible d'intégrer autant de nœuds que l'on veut dans le Cluster et une gestion en natif du monitoring de services est réalisée.

Les clusters sont basés sur le principe des battements de coeur. Un « heartbeat » (battement de cœur, en anglais), c'est le fait qu'un nœud puisse entendre le « coeur » d'un autre nœud battre. Donc, avec le « heartbeat », un nœud peut savoir si les autres nœuds sont encore vivant ou non. Lorsque le « cœur » d'un autre nœud ne bat plus, on considère qu'il est mort.

Nous installerons la version 3 du service Heartbeat (apt-get install heartbeat)à partir de laquelle, l'équipe de Linux-HA conseille de lui adjoindre un gestionnaire de Cluster tel que Pacemaker (stimulateur cardiaque) qui est d'ailleurs installé automatiquement sous Wheezy à l'installation de Heartbeat.Pacemaker est un gestionnaire de Cluster haute disponibilité. Il est chargé de créer, démarrer, arrêter et superviser les ressources du Cluster c'est à dire les services gérés en Cluster et donc inclus dans la continuité de services. apt-get install heartbeat

Heartbeat permet donc de gérer différents services de haute disponibilité (High Availability : HA) au sein d'un Cluster. Il permet de détecter la défaillance d'un poste grâce à un système de communication basé sur un échange de paquets UDP. Dans son mode le plus simple, cette solution de clustering est basée sur le modèle actif-passif : lorsqu'un serveur considéré comme « primaire » n'est plus considéré comme accessible, Heartbeat démarre sur un serveur secondaire les services qu'on lui indique dans la configuration.

Gérer un service en Cluster (un service étant une ressource au sens de Pacemaker) consiste donc, dans sa forme la plus simple (mode actif/passif), à installer le service sur tous les nœuds participants au Cluster et à n'activer ce service que sur le nœud dit maître (nœud actif). Lorsque ce nœud est défaillant, le service est activé automatiquement sur le nœud dit esclave (nœud passif qui devient actif). Le retour automatique du service (auto failback) sur le nœud maître (lorsque celui-ci est de nouveau en état) n'est pas systématique et doit être géré au niveau de la configuration de chaque ressource.

Heartbeat est lancé en démon (ce qui est visible avec la commande netstat) et il se charge (via Pacemaker) d'activer l'adresse IP virtuelle sur le serveur qui joue le rôle de maître ainsi que le lancement des services (ressources au sens de Pacemaker) mis en haute disponibilité. Ces derniers, lancés par Pacemaker, doivent donc être supprimés du démarrage automatique de Linux. Par exemple, pour Apache2 : update-rc.d -f apache2 remove ou insserv -r -v apache2

Les fichiers de configuration se trouvent dans /etc/ha.d et dans /var/lib/heartbeat/crm/ (mais aucun fichier n'est créé à l'installation). C'est dans le fichier /etc/ha.d/ha.cf qu'on indique à Heartbeat qu'il « travaillera » avec Pacemaker.La configuration de Heartbeat s'articule autour des fichiers suivants qui doivent être identiques sur les deux serveurs.http://www.linux-ha.org/wiki/Configuration

/etc/ha.d/ha.cf : ce fichier contient la configuration générale de HeartbeatDirectives et valeurs Explicationslogfacility local7logfile /var/log/ha-logdebugfile /var/log/ha-debuguse_logd no

Gestion des logs : il serait plus judicieux d'utiliser un système de gestion de log avec démon (avec l'option use_logd yes) mais par mesure de simplification, nous utiliserons la méthode classique.

logfacility local7 indique un fichier de log de niveau debug udpport 694 Port utilisé par les mécanismes de "battements de coeur"keepalive 2 Délai entre 2 battements (en secondes)deadtime 20 Temps nécessaire (en secondes) avant de déclarer un nœud

comme mortinitdead 50 Valeur utilisée pour le démarrage (> 2 fois le deadtime)

Page 14/41

auto_failback offLa gestion du retour automatique d'une ou plusieurs ressources sur le nœud primaire ne sera pas gérée par Heartbeat mais par Pacemaker au cas par cas selon la manière dont nous déciderons de configurer la ressource.

node intralabARnode hdintralabAR

Liste des nœuds participants au Cluster (ne pas oublier de configurer le fichier « hosts » sur chacun des nœuds)

ucast eth0 10.22.100.212ucast eth0 10.22.100.215

Lien réseau utilisé pour les battements de cœur

crm yes

Avec « crm yes » : format de configuration des ressources qui exploite un fichier de configuration XML et la gestion du Cluster est réalisée par un Pacemaker.Avec « crm no », Heartbeat exploite un fichier de configuration /etc/ha.d/haresources comme dans sa première version mais les possibilités sont limitées.

/etc/ha.d/authkeys : ce fichier détermine le niveau de sécurité des échanges entre les différents noeuds du Cluster. Lorsque ces informations passent pas le réseau, il vaut mieux crypter l'échange avec md5 sha (plus gourmand en temps processeur). Dans ce cas, il faut fournir une « passphrase ».

auth 11 sha1 PassPhrase

D'autres méthodes d'authentification sont possiblesPar mesure de sécurité, les droits sur ce fichier doivent être réduits à la lecture et écriture seulement à l'utilisateur root (si ce n'est pas fait, Heartbeat ne démarre pas)chmod 600 /etc/ha.d/authkeys

La configuration du Cluster est contenue dans un Cluster Information Base (CIB) qui est un fichier XML./var/lib/heartbeat/crm/cib.xml : ce fichier est généré (au démarrage de Heartbeat) à partir des deux fichiers vus précédemment et est complété au fur des ajouts de ressources.

Ce dernier fichier ne doit JAMAIS être modifié directement mais via les commandes vues ci-après.

Heartbeat peut être démarré lorsqu'il est configuré sur les deux serveurs. Consultez la note en fin d'annexe 1 pour disposer d'un Cluster « neuf » si le Cluster n'est pas ou plus stable (fichier cib.xml différent, démarrage de Hearbeat avant clonage, etc.).

Pour démarrer et/ou stopper le Cluster, il suffit de démarrer et/ou stopper le démon « heartbeat ».

3. Assurez-vous que les noms d'hôtes présents dans les fichiers de configuration puissent être convertis en adresse IP via /etc/hosts et/ou DNS.

Par mesure de simplification, on peut utiliser /etc/hosts :10.22.100.215 hdintralab.gsb.coop hdintralab10.22.100.212 intralab.gsb.coop localhost intralab localhost.localdomain

4. Clonez le serveur primaire et procédez à la configuration IP du serveur esclave.

hdintralab : serveur esclave clone de interalab avec des adresses ip différentes IP réelle : 10.22.100.215/16 --> c'est celle qui est dans /etc/network/interfaces IP virtuelle : 10.22.100.220Par mesure de simplification, on peut utiliser /etc/hosts :10.22.100.215 hdintralab.sisr hdintralab10.22.100.212 intralab.sisr localhost intralab localhost.localdomain

5. Démarrez les nœuds et vérifiez que Heartbeat s'est correctement lancé sur les deux nœuds.

Les commandes utilesPour vérifier que heartbeat est lancé : /etc/init.d/heartbeat status (ou service heartbeat status ou cl_status hbstatus)Pour voir la liste des noeuds : cl_status listnodesEt l'état d’un noeud : cl_status nodestatus ma-machine-esclave.mondomaine.com

Page 15/41

La commande crm implémentée par pacemaker (qui peut être avantageusement utilisée aussi en interactif) permet de gérer la configuration et les différentes ressources. Elle se propage sur chaque nœud automatiquement : la commande s'effectue donc sur n'importe quel nœud.Avant toute chose, un petit aperçu des commandes importantes pour vérifier l'état du Cluster :

Pour vérifier le status d'Heartbeat :root@intralabAR:~# crm status ============Last updated: Sat Nov 24 01:09:13 2012Stack: HeartbeatCurrent DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorumVersion: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b2 Nodes configured, unknown expected votes0 Resources configured.============

Online: [ hdintralabar intralabar ]

La commande suivante permet de suivre l'évolution de la configuration en direct :root@hdintralabAR:~# crm_mon ============Last updated: Sat Nov 24 15:23:25 2012Stack: HeartbeatCurrent DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorumVersion: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b2 Nodes configured, unknown expected votes0 Resources configured.============

Online: [ hdintralabar intralabar ]

Ces deux précédentes commandes remontent un certain nombre d’informations sur l’état général du Cluster (nœuds ok, hs, offline ou en standby) et sur l’état des ressources (quel nœud gère quelle ressource, les éventuels problèmes rencontrés lors du lancement ou du monitoring des ressources…).

Last updated et stack : la dernière mise à jour des informations du moniteur et le fournisseur (provider) utilisé : ici, HeartbeatCurrent DC : c’est le nœud qui va coordonner les actions sur le Cluster. Les autres nœuds remonteront leurs informations au nœud DC. Ce nœud n’est pas nécessairement le nœud « maître » du Cluster.Nodes & votes : le nombre de nœuds et le nombre de votes disponibles pour le quorum (voir page suivante).Resources configured : le nombre de ressources configurées dans le Cluster.Online : la liste des nœuds online. On pourra aussi trouver ici, la liste des nœuds offline ou en stand-by.

Le contrôle d'un service actif (ou pas) sur un nœud peut aussi s'effectuer via les commandes usuelles ps, netstat et nmap.

Pour afficher la configuration (beaucoup plus lisible que le fichier xml) :root@intralabAR:~# crm configure shownode $id="462d81f0-07d8-4c88-af27-d4ee9254640d" hdintralabarnode $id="f21c8f9a-8d38-4e1d-a9c8-96e403cd7596" intralabarproperty $id="cib-bootstrap-options" \ dc-version="1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b" \ Cluster-infrastructure="Heartbeat" \ stonith-enabled="false"\ no-quorum-policy="ignore"

6. Vérifiez la configuration de Hearbeat sur chaque nœud, désactivez STONITH et le quorum.

Page 16/41

Il existe une commande qui permet de vérifier la validité du fichier de configuration XML alors généré :crm_verify -L -V . À la première exécution de cette commande (après le démarrage correct de Heartbeat), des erreurs sont remontées :

root@intralabAR:~# crm_verify -L -V crm_verify[690]: 2012/11/24_00:31:01 ERROR: unpack_resources: Resource start-up disabled since no STONITH resources have been definedcrm_verify[690]: 2012/11/24_00:31:01 ERROR: unpack_resources: Either configure some or disable STONITH with the stonith-enabled optioncrm_verify[690]: 2012/11/24_00:31:01 ERROR: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrityErrors found during check: config not valid

« Stonith » (shot the other node in the head) permet de tuer proprement les nœuds qui sont morts.C'est en fait un mécanisme pour éteindre complètement le serveur qui vient de flancher en éteignant son onduleur. C'est surtout utilisé avec des disques partagés car il serait dangereux que l'ordinateur qui est supposé être hors d'état vienne écrire sur le disque partagé et corrompre/altérer les données.

Par mesure de simplification, pour ce coté labo, nous allons désactiver STONITH par la commande : crm configure property stonith-enabled=false

root@intralabAR:~# crm configure property stonith-enabled=falseINFO: building help index

La vérification ne renvoie plus d'erreur. Vous pouvez consulter le fichier XML généré : /var/lib/heartbeat/crm/cib.xml :<cib validate-with="pacemaker-1.0" crm_feature_set="3.0.1" have-quorum="1" dc-uuid="462d81f0-07d8-4c88-af27-d4ee9254640d" epoch="8" num_updates="0" admin_epoch="0" cib-last-written="Sat Nov 24 00:49:37 2012"> <configuration> <crm_config> <Cluster_property_set id="cib-bootstrap-options"> <nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value="1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b"/> <nvpair id="cib-bootstrap-options-Cluster-infrastructure" name="Cluster-infrastructure" value="Heartbeat"/> <nvpair id="cib-bootstrap-options-stonith-enabled" name="stonith-enabled" value="false"/> </Cluster_property_set> </crm_config> <nodes> <node id="462d81f0-07d8-4c88-af27-d4ee9254640d" uname="hdintralabar" type="normal"/> <node id="f21c8f9a-8d38-4e1d-a9c8-96e403cd7596" uname="intralabar" type="normal"/> </nodes> <resources/> <constraints/> </configuration></cib>

Persiste encore un petit problème à régler concernant le quorum qui est le nombre minimum de nœuds en ligne pour être capable de valider une décision. Dans le cas d’un Cluster avec Pacemaker, il faut que plus de la moitié des nœuds soit en ligne. Avec un Cluster à deux nœuds, il n’y a plus de quorum dès qu’un nœud est perdu. Il faut donc demander à Pacemaker d’ignorer le quorum dans cette situation car le fonctionnement par défaut, quand le quorum n’est pas atteint, est de couper toutes les ressources.

Pour désactiver le quorum, saisir la commande suivante : crm configure property no-quorum-policy="ignore".

7. Vérifiez de nouveau la configuration ainsi que le fichier xml généré.

crm_verify -L -V ==> ne renvoie plus d'erreurscat /var/lib/heartbeat/crm/cib.xml

Page 17/41

2. Configuration des ressources « failover IP » et « serviceWeb »

Après avoir installé les services sur chaque nœud du Cluster, il est nécessaire de configurer le comportement de ceux que l'on désire mettre en haute disponibilité. Rappel : un service est une ressource au sens de Pacemaker. La commande crm qui va permettre de configurer les ressources dans le Cluster est implémentée par Pacemaker ; quelque soit le nœud sur laquelle la commande est exécutée, la configuration se propage sur chaque nœud automatiquement en modifiant le fichier cib.xml

Pour vérifier votre configuration, utilisez les commandes vues dans l'annexe 1 « crm status », « crm_mon » et « crm configure show » ainsi que celles permettant de contrôler si un service est actif ou non (ps, netstat et nmap).

Comment créer une ressource ?

La création d’une ressource s’effectue avec une entrée nommée « primitive » dans la CIB (voir annexe 1). On trouvera au minimum dans la commande :crm configure primitive <nom de la ressource> <espace de nom:nom du script>. Par exemple :

crm configure primitive serviceWeb ocf:heartbeat:apache2 crm configure primitive serviceWeb lsb:apache

Cette « primitive » fait appel à un script d’application correspondant au service à mettre en haute disponibilité.

Le script du service peut être : De type OCF (http://linux-ha.org/wiki/OCF_Resource_Agent) qui est un script développé pour

Pacemaker : ils sont, pour la plupart, dans le répertoire /usr/lib/ocf/resource.d/heartbeat/ ou /usr/lib/ocf/resource.d/pacemaker ; la liste des scripts est obtenue avec les commandes crm ra list ocf heartbeat et crm ra list ocf pacemaker. Dans la commande l'espace de nom est dans de cas ocf:heartbeat ou ocf:pacemaker.

De type LSB : c'est un script de démarrage sur Linux présent dans /etc/init.d ; pour qu'il puisse être utilisé avec Pacemaker, ce script doit être conforme à la spécification LSB :

http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html.Le type lsb:service utilise au minimum les capacités start, stop, status des scripts de démarrage système de /etc/init.d. Pour en vérifier la compatibilité minimum, les scripts doivent répondre à une commande start, stop et status. Le lien http://linux-ha.org/wiki/LSB_Resource_Agents aide à la vérification de la compatibilité totale. Dans la mesure du possible, il est conseillé d'utiliser les scripts OCF ou d'écrire (s'il n'existe pas) un script OCF basé sur le script d'initialisation existant. D'autant plus que pour certains services, les scripts OCF offrent des finesses supplémentaires de configuration.On indique ensuite éventuellement (dans la commande crm configure primitive) des paramètres propres à la ressource et des options de monitoring (voir plus loin les configurations spécifiques).La configuration passe donc par la commande crm que l'on peut utiliser directement en ligne de commande (voir notamment « configuration du failover IP ») ou en interactif (voir notamment « configuration de la ressource « serviceWeb »).

Cette commande se propage sur tous les nœuds (ce qui est très pratique) et modifie bien évidemment le fichier XML sur chaque noeud. Attention, il est très dangereux de modifier ce fichier à la main (surtout quand Hearbeat est lancé) ; il faut utiliser à la place la commande crm configure edit. Si, en dernier recours, vous devez passer par la modification du fichier à la main, il est nécessaire de sauvegarder le fichier, arrêter le service « heartbeat » et opérer la même modification sur les deux nœuds.

Note : vous trouverez en annexe 4 un récapitulatif des commandes utiles (y compris certaines que nous ne verrons pas explicitement dans ce Côté labo mais qui peuvent s'avérer utiles).

1 Créez la ressource permettant le « failover IP ». En option, vous créez un moniteur pour cette ressource avec un test de la ressource de 10 secondes, un timeout de démarrage de 30 secondes et un timeout d'arrêt de 40 secondes.

Configuration du failover d'IP

Le failover d'IP (en anglais, fail-over se traduit par « passer outre la panne ») est le basculement de l'adresse IP (virtuelle) du serveur maître vers le serveur esclave si le premier venait à défaillir.

Première étape : attribution de l'adresse IP virtuellePage 18/41

À minima, on crée une ressource nommée « IPFailover » (le nom est libre) qui va créer une adresse IP virtuelle 10.22.100.220/16 (d'autres options sont disponibles)root@intralabAR:~# crm configure primitive IPFailover ocf:heartbeat:IPaddr2 params ip="10.22.100.220" cidr_netmask="255.255.0.0" nic="eth0" iflabel="VIP"

Primitive : argument pour ajouter une primitive regroupant plusieurs valeurs indiquant au Cluster quels scripts utiliser pour la ressource, où le trouver et à quel standard il correspond.

Ocf : classe de la ressource (ça pourrait donc aussi être lsb) Hearbeat : fournisseur de la ressource IPaddr2 : ressource gérant les adresses IPv4 virtuelles ==> le script appelé Params : déclaration des paramètres nécessaires à la ressource IPFaillover : le nom de la ressource (il est évidemment libre... mais doit être suffisamment

« parlant ») IPaddr2 : le script appelé params : suivent les différents paramètres à appliquer ip= « 10.22.100.220 » : nom et valeurs du paramètre « ip » cidr_netmask= « 255.255.0.0 » : masque de sous-réseau nic= « eth0 » : carte réseau sur laquelle est appliquée l'adresse IP

virtuelle iflabel= « VIP » permet de donner un label à la carte réseau

virtuelle. Sans ce label, la VIP n’est pas visible avec la commande ifconfig mais seulement avec la commande ip addr show.

Remarques : pour connaître tous les paramètres de la primitive IPaddr2 (ainsi que ses options par défaut

comme tout ce qui concerne le monitoring de la ressource) : crm ra info ocf:heartbeat:IPaddr2 ;

pour visualiser en direct l’évolution de la configuration, il est intéressant de réaliser la commande sur un nœud et de laisser tourner un « crm_mon » sur l’autre (attendre un peu que la propagation soit effective) ;

en cas d'erreur de syntaxe dans la commande, le système peut demander s'il va quand même enregistrer en terminant son retour d'erreur par « Do you still want to commit? » : il faut évidemment répondre par « n » ;

chaque script de la classe ocf permet la supervision de la ressource via l'option monitor (voir ci-après) et/ou la promotion d’une ressource dans le cadre d’un Cluster actif/actif (comme nous allons le voir dans le Coté labo suivant).

Avec crm_mon ou crm status, on peut constater qu'une ressource est configurée :============Last updated: Sat Jul 27 01:39:54 2013 Last change: Fri Jul 26 15:48:11 2013 via crm_attribute on intralabar Stack: HeartbeatCurrent DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorumVersion: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, unknown expected votes1 Resources configured.============Online: [ hdintralabar intralabar ]IPFailover (ocf::heartbeat:IPaddr2): Started hdintralabarEt nous pouvons constater aussi que l'adresse virtuelle démarrera sur l'un ou l'autre nœud de manière aléatoire (ici Started hdintralabar).Pour vérifier l'adresse IP attribuée on utilise la commande « ip addr show » (attention, pas ifconfig si le paramètre iflabel n'a pas été défini) :root@hdintralabAR:~# ip addr show1: lo:....2: ...3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 7e:e9:2e:18:13:b7 brd ff:ff:ff:ff:ff:ff inet 10.22.100.215/16 brd 10.22.255.255 scope global eth0 inet 10.22.100.220/16 brd 10.22.255.255 scope global eth0:VIP inet6 fe80::7ce9:2eff:fe18:13b7/64 scope link valid_lft forever preferred_lft forever4: eth1: ...

Page 19/41

Si le paramètre « iflabel » a été défini :root@hdintralabAR:~# ifconfig eth0 Link encap:Ethernet HWaddr 7e:e9:2e:18:13:b7 inet adr: 10.22.100.215 Bcast: 10.22.255.255 Masque:255.255.0.0 adr inet6: fe80::7ce9:2eff:fe18:13b7/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:118122 errors:0 dropped:0 overruns:0 frame:0 TX packets:150621 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:24502882 (23.3 MiB) TX bytes:34901151 (33.2 MiB) eth0:VIP Link encap:Ethernet HWaddr 7e:e9:2e:18:13:b7 inet adr:10.22.100.220 Bcast: 10.22.255.255 Masque:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Pour éditer/modifier une ressource : crm configure edit <id_ressource> ; cela vous placera dans une instance de « vim » pour effectuer une modification. À la sauvegarde, la modification est directement appliquée. Par exemple, si l'on veut ajouter à la ressource configurée précédemment des options de monitoring : crm configure edit IPFailover :primitive IPFailover ocf:heartbeat:IPaddr2 \ params ip="10.22.100.220" cidr_netmask="255.255.0.0" nic="eth0" op monitor interval="30s" timeout="20s"

crm configure primitive IPFailover ocf:heartbeat:IPaddr2 params ip="10.22.100.220" cidr_netmask="255.255.0.0" nic="eth0" iflabel="VIP" op monitor interval="10s" timeout="20s" op start timeout="30s" op stop timeout="40s"

« op » définit des options et « monitor » est l'action de monitoring du pacemaker : toutes les 30 secondes, Pacemaker va appeler le script OCF avec comme paramètre monitor. Avant le timeout de 20 secondes, on devra avoir un code retour à 0 pour que Pacemaker considère la ressource comme fonctionnelle. Sinon, il arrêtera/relancera la ressource ou effectuera une bascule (selon le paramétrage des autres options).Remarque : Pour éditer/modifier l'ensemble d'une configuration : crm configure edit.

Deuxième étape : définir une préférence de nœud primaire pour l'adresse virtuelleIl s'agit en fait de définir une contrainte « locative » qui va définir une préférence d’une ressource sur un nœud : le plus simple est, en fait, de laisser Pacemaker « écrire » lui même cette contrainte.On migre la ressource sur le nœud que l'on veut et Pacemaker comprend qu'on a une préférence pour ce nœud : crm resource move IPFailover intralabEt on constate : crm configure show

location cli-prefer-IPFailover IPFailover \ rule $id="cli-prefer-rule-IPFailover" inf: #uname eq intralabar

Cette situation n'est peut-être pas la situation idéale car il est souvent préférable de revenir à un nœud de manière manuelle après avoir vérifié que toutes les conditions favorables sont réunies et qu'il n'y aura pas de perte de données.Dans ce cas, il faut utiliser le paramètre « resource-stickiness » qui empêche la ressource de retourner sur la machine élue par défaut après que celle-ci est défaillit et soit revenue en ligne. La ressource devra être migrée manuellement.Et dans certains cas, on ne privilégie aucun serveur par rapport à d'autres (par

exemple, quand les machines maître et esclave sont strictement identiques, notamment en terme de capacités).Test du failover d'IPPlusieurs possibilités pour tester la solution mise en place dont :

arrêter le serveur ou le service ; mettre un nœud en maintenance : crm node standby sur le nœud que l'on veut rendre inactif

(crm node online pour le remettre actif).Par exemple cette commande sur le nœud « intralab » a pour effet de faire basculer l'adresse IP virtuelle sur le nœud hdintralab : ============Last updated: Sat Jul 27 01:39:54 2013 Last change: Fri Jul 26 15:48:11 2013 via crm_attribute on intralabarStack: HeartbeatCurrent DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorumVersion: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff

Page 20/41

À partir de ce moment là, dès que le nœud intralab est actif, la ressource migrera vers ce nœud (auto failback).

2 Nodes configured, unknown expected votes1 Resources configured.============Node intralabar (f21c8f9a-8d38-4e1d-a9c8-96e403cd7596): standbyOnline: [ hdintralabar ]IPFailover (ocf::heartbeat:IPaddr2): Started hdintralabarUn crm node online doit permettre de récupérer l'adresse IP sur intralab car nous avons défini la préférence ainsi :============Last updated: Sat Jul 27 01:39:54 2013 Last change: Fri Jul 26 15:48:11 2013 via crm_attribute on intralabarStack: HeartbeatCurrent DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorumVersion: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff2 Nodes configured, unknown expected votes1 Resources configured.============Online: [ hdintralabar intralabar ]IPFailover (ocf::heartbeat:IPaddr2): Started intralabarRappel : en production, il est parfois préférable de maîtriser le retour au serveur maître.

2 Sur quel nœud la ressource a-t-elle été lancée ? Justifiez et vérifiez.

crm status ou crm_mon sur un des deux nœudsPour moi : hdintralabar (donc serveur sensé être l'esclave) : Started hdintralabararPour vérifier : ip addr show sur le serveur esclave pour voir l'adresse IP virtuelle (ou sur le maître pour vérifier que l'adresse IP virtuelle n'existe pas)

3 Migrez éventuellement la ressource (si elle n'y était pas déjà) sur le nœud primaire ; vérifiez que la ressource passe bien sur ce nœud et que la préférence a été donnée à ce nœud.

crm resource move IPFailover intralabarcrm configure show==> location cli-prefer-IPFailover IPFailover \rule $id="cli-prefer-rule-IPFailover" inf: #uname eq intralabar

4 Testez l'accès au service Web à partir de l'adresse IP virtuelle.

http://10.22.100.220

5 Procédez aux modifications nécessaires au niveau des fichiers de configuration d'Apache.

Sur chaque serveur :<VirtualHost 10.22.100.220:80> # ou 443 si HTTPS configuré ServerName servIntralabAR.gsb.coopDocumentRoot /var/www/appliGSB/appliFrais...</Directory></VirtualHost>

6 Quel autre service est obligatoirement impacté par le changement d'adresse IP ?

L'autre service impacté est le service DNS qui fait correspondre le nom DNS à l'adresse IP servIntralabAR.gsb.coop <==> 10.22.100.220

Après modification du serveur DNS, on teste : http://servIntralabAR.gsb.coop/cAccueil.php

7 Testez le failover IP des deux manières présentées en annexe 2. Y a-t-il une différence ?

crm node standby ==> pour tester si l'adresse IP virtuelle passe bien sur l'autre serveurcrm node online ==> pour tester le retour de l'adresse IP virtuelleExtinction du serveur « maître »La seule différence est que le nœud est marqué OFFLINE au lieu de standby============Last updated: Fri Jul 26 13:54:56 2013

Page 21/41

Stack: HeartbeatCurrent DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorumVersion: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff2 Nodes configured, unknown expected votes1 Resources configured.============Online: [ hdintralabar ]OFFLINE: [ intralabar ]IPFailover (ocf::heartbeat:IPaddr2): Started hintralabar

Au redémarrage du serveur maître, l'adresse IP virtuelle bascule de nouveau sur ce dernier.

Configuration de la ressource http

8 Sur les deux nœuds, arrêtez le service HTTP et supprimez ce service du démarrage.

/etc/init.d/apache2 stop [ ok ] Stopping web server: apache2 ... waiting . insserv -r -v apache2 insserv: remove service /etc/init.d/../rc0.d/K01apache2 insserv: remove service /etc/init.d/../rc1.d/K01apache2 insserv: remove service /etc/init.d/../rc2.d/S17apache2 insserv: remove service /etc/init.d/../rc3.d/S17apache2 insserv: remove service /etc/init.d/../rc4.d/S17apache2 insserv: remove service /etc/init.d/../rc5.d/S17apache2 insserv: remove service /etc/init.d/../rc6.d/K01apache2 insserv: creating .depend.boot insserv: creating .depend.start insserv: creating .depend.stop

9 Créez la ressource « serviceWeb » et vérifiez sur quel nœud elle démarre.

Nous allons configurer cette ressource en « interactif » car cela procure plusieurs avantages dont : l'utilisation de la touche tabulation qui peut aider à trouver la « bonne » commande ou le

« bon » argument (la double tabulation listera les possibilités) ; l'utilisation de la commande help qui liste les commandes possibles ; la possibilité de configurer plusieurs ressources avec leurs propriétés avant de valider le tout.

root@intralabAR:~# crm configurecrm(live)configure# primitive serviceWeb ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf" op monitor interval="60s op start timeout="40s" op stop timeout="40s"crm(live)configure# commitcrm(live)configure# quit

On crée une ressource nommée « serviceWeb » avec comme paramètre le chemin du fichier de configuration d'Apache2.Remarque :« configfile » a, pour paramètre par défaut /etc/apache2/http.conf (on peut le constater avec la commande : crm ra info ocf:heartbeat:apache), ce qui n'est pas valable dans notre configuration => il faut donc lui préciser ce paramètre. Les autres paramètres par défaut sont corrects.Chaque option (en règle générale, chaque action à effectuer) est ensuite précédée du mot clé « op ».On crée un moniteur pour cette ressource avec un test de la « vie » de la ressource toutes les 60 secondes (op monitor interval="60s") et on spécifie en plus un timeout de démarrage de 40 secondes ("op start timeout="40s") et un timeout d'arrêt de 40 secondes ("op stop timeout="40s").On valide la ressource par « commit » et on sort de la commande interactive par « quit » ou « exit »N'hésitez pas à utiliser la tabulation et double tabulation...

Remarque : avant de valider la ressource, on peut la consulter :crm(live)configure# show ...primitive serviceWeb ocf:heartbeat:apache \

params configfile="/etc/apache2/apache2.conf" \ op start interval="0" timeout="40s" \ op stop interval="0" timeout="40s" \ op monitor interval="60s"

Page 22/41

...

À la validation, un « Warning » peut apparaître :WARNING: serviceWeb: specified timeout 40s for stop is smaller than the advised 60s Vous pouvez l'ignorer ou... en tenir compte. Les développeurs ont estimé qu'un délai de 60s pour arrêter ce service était raisonnable. Si vous pensez qu'effectivement, l'arrêt du service Web prendra plus de 40 secondes, il vaut mieux augmenter le délai. Sur la console crm_mon, il apparaît bien la nouvelle ressource :============Last updated: Sat Jul 27 01:45:04 2013 Last change: Fri Jul 26 15:48:11 2013 via crm_attribute on intralabar Stack: HeartbeatCurrent DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorumVersion: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff2 Nodes configured, unknown expected votes2 Resources configured.============

Online: [ hdintralabar intralabar ]

IPFailover (ocf::heartbeat:IPaddr2): Started intralabarintralab (lsb:intralab): Started hdintralabarMais, comme on peut le voir, la ressource serviceWeb n'est pas démarré sur le même nœud que celle concernant l'IP virtuelle. Par défaut Pacemaker répartit les ressources entre les membres du Cluster.

Pour que l'adresse IP virtuelle et le service « serviceWeb » soient sur le même nœud, il existe plusieurs possibilités comme le groupement des ressources (solution la plus simple) :root@intralabAR:~# crm configurecrm(live)configure# group servIntralab IPFailover serviceWeb meta migration-threshold="5"crm(live)configure# commitcrm(live)configure# quit

10 Vérifiez que le service HTTP soit bien démarré sur le serveur spécifié et non activé sur l'autre.

root@intralabAR:~# netstat -tpnl | grep apache ==> ne renvoie rienroot@hdintralabAR:~# netstat -tpnl | grep apache tcp6 0 0 :::80 :::* LISTEN 5863/apache2

11 Groupez les ressources de manière à ce qu'elles soient actives sur le même nœud.

On crée un groupe nommé « servIntralab » composé des ressources « IPFailover » et « serviceWeb » qui seront toujours démarrées dans l'ordre des entrées du groupe (arrêtées en sens inverse). On spécifie aussi le nombre d'incidents tolérés avant de migrer la ressource définitivement vers un autre noeud ("meta migration-treshold=5"). Ainsi, au bout de cinq incidents, le groupe de ressources sera définitivement migré vers un autre nœud mais si une ressource échoue au démarrage, l'ensemble des ressources du groupe sera démarré sur un autre nœud.

==> La ressource « serviceWeb » migre immédiatement sur le même nœud que celui de « IPFailover ».Nous étudierons, dans le prochain Coté labo, d'autres possibilités de configuration plus compliquées mais permettant des paramétrages plus fins.

root@intralabAR:~# crm configure crm(live)configure# group servIntralab IPFailover serviceWeb meta migration-threshold="5" crm(live)configure# commit crm(live)configure# quit

Puis crm status pour vérifier

Page 23/41

============ Last updated: Fri Jul 26 15:48:15 2013 Last change: Fri Jul 26 15:48:11 2013 via crm_attribute on intralabar ...Resource Group: servIntralab IPFailover (ocf::heartbeat:IPaddr2): Started intralabar serviceWeb (ocf::heartbeat:apache): Started intralabar ============

12 Quels sont les tests que vous effectuez pour vérifier la solution mise en place ?

crm node standby ==> pour tester si les ressources migrent sur l'autre serveur (crm status pour vérifier et un test de l'accès à l'application Web)crm node online ==> pour tester le retour automatique des ressources (crm status pour vérifier et un test de l'accès à l'application Web)D'autres tests doivent être effectués :

Suppression du processus relatif au serveur Web ==> on vérifie que Pacemaker relance le service et qu'il n'y a aucune migration de ressources.

Suppression du processus relatif au serveur Web et empêchement de redémarrage (en modi-fiant par exemple un élément d'un fichier de configuration qui va empêcher le démarrage du service) ==> on vérifie que l'ensemble des ressources migre.

On permet le démarrage du service (sans le démarrer) ==> on vérifie que le retour automa-tique des ressources se réalisent.

Page 24/41

3. Configuration de la réplication des bases de données

Comment ça marche ?

La réplication MySQL est basée sur le fichier log binaire du serveur maître qui garde une trace de toutes les requêtes SQL (update, delete, etc.) et un fichier d'index des modifications à prendre en compte. L'esclave, au moment de la connexion, informe le maître où il s'est arrêté, rattrape les modifications qui ont eu lieu depuis (lecture du fichier log binaire du serveur maître pour qu'il puisse exécuter les requêtes SQL stockées dans ce fichier), puis se bloque en attente des prochaines modifications.

Le fichier de log binaire (ou binlogs) est simplement un enregistrement des modifications depuis un point fixe dans le temps (le moment où vous activez le log binaire). Tous les esclaves qui seront activés auront besoin de la copie des données qui existaient au moment du démarrage du log. Ainsi, si l'on désire mettre une réplication en place, alors que la base de données, concernée par la réplication, du maître est déjà fournie en données, il faut tout d'abord effectuer une copie complète de celle-ci avant de commencer la réplication.

Ensuite, l'esclave va simplement se connecter au maître et attendre des requêtes de modifications. Il lira le fichier journal binaire du maître, en copiera les requêtes dans un fichier tampon, ou fichier « relais » (relay) en terminologie MySQL, et il les « jouera » sur son serveur.Si le maître est indisponible ou que l'esclave perd la connexion avec le maître, il va essayer de se reconnecter selon une période fixée en secondes par le paramètre « master-retry-count » jusqu'à ce qu'il soit capable d'établir la communication, et de recommencer à appliquer les modifications.

Chaque esclave garde la trace du point où il en était rendu. Le serveur maître n'a pas de notions du nombre d'esclaves qui se connectent, ou qui sont à jour à un moment donné.

Remarque : un esclave peut aussi servir de maître à son tour pour réaliser une chaîne de réplication.

Étapes avant modification des fichiers de configuration

La réplication de la base de données se fera dans un premier temps isolé des problématiques de Heartbeat et de Pacemaker et selon une architecture de type maître-esclave.

1 Écrivez la procédure détaillée que vous allez mettre en œuvre pour configurer la réplication de la base de données.

Procédure : Installation des services de bases de données sur les serveurs ; Réplication de bases de données entre plusieurs serveurs qui présuppose l'existence d'un

utilisateur MySQL ayant des droits suffisants sur chaque serveur maître  ; le serveur esclave doit pouvoir se connecter au maître avec cet utilisateur de manière à ce qu'il puisse consulter l’état du log binaire et répliquer les données si des modifications ont été apportées ; pour cela :◦ le droit spécial « REPLICATION SLAVE » suffit ;

GRANT REPLICATION SLAVE ON * . * TO 'test'@'%' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;◦ lui attribuer aussi les droits de connexion depuis tous les esclaves.

Sur le serveur maître, créer l'utilisateur MySQL ayant des droits suffisants :mysql> GRANT REPLICATION SLAVE ON *.* TO replicateur@'%' IDENTIFIED BY 'mdpreplicateur' ;

S'assurer que la base de données est identique sur les deux serveurs (en cas de doute, faire une sauvegarde sur l'un et restaurer sur l'autre)

Mise en place des bases de données à répliquer qui doivent être identiques sur tous les serveurs avant de commencer la réplication : on va devoir s’assurer qu’aucune nouvelle

Page 25/41

donnée ne soit enregistrée pendant le laps de temps nécessaire à la configuration. À ce moment, il s’agit de bloquer l’écriture sur la (les) base(s) que l’on souhaite répliquer de manière à s’assurer qu’aucune nouvelle donnée ne soit enregistrée : on doit pour cela saisir la commande suivante sur le serveur « maître » « FLUSH TABLES WITH READ LOCK; » : cette dernière va alors fermer toutes les tables ouvertes, et verrouiller en lecture toutes les tables et bases. À ce moment-là, les requêtes qui voudront faire une écriture seront mises en file d'attente, jusqu'au déblocage par la commande « UNLOCK TABLES; ».

Bloquer l’écriture sur les bases du serveur maître de manière à s’assurer qu’aucune nou-velle donnée ne soit enregistrée : mysql>FLUSH TABLES WITH READ LOCK;

Configuration de la réplication via le fichier /etc/mysql/my.cnf sur chaque serveur : la réplication de bases de données implique une configuration différente sur chaque serveur. Cette configuration dépend de leur rôle et nécessite (entre autres) un identifiant unique dans la chaîne de réplication.

Quelques directives utilisées dans /etc/mysql/my.cnf sur des versions de MySQL inférieures à 5.5 ne fonctionnent plus (et empêchent MySQL de démarrer avec une erreur dans les logs « unknown variable »), même si ces directives sont encore présentes dans le fichier exemple !Aussi, il ne faut pas se fier complètement aux configurations proposées sur Internet et TOUJOURS exploiter les logs.

Fichier de configuration : /etc/mysql/my.cnf

Pour simplifier le processus (et pour faciliter l'ajout de nouveaux esclaves à un maître), les versions récentes de MySQL (5.x) permettent (et oblige parfois, à partir de la 5.5) d'effectuer des opérations « à chaud » directement dans la console SQL, à l'aide de la commande SQL CHANGE MASTER TO.Aussi, les fichiers de configuration déterminent uniquement un statut « maître » ou « esclave ». Tous les paramètres permettant d'établir un lien entre le maître et l'esclave (comme l'adresse IP du maître, le nom de l'utilisateur et le mot de passe, etc) seront réalisés avec la commande SQL pré-citée.

Sur le serveur « maître » :[mysqld]#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 = 10max_binlog_size = 100M

binlog_do_db = databaseName

On peut maintenant redémarrer MySQL et on doit bloquer IMMÉDIATEMENT l'écriture (voir «  étapes après modifications des fichiers de configuration »).N'hésitez pas à lire en parallèle le fichier « /var/log/mysql.err » notamment si MySQL ne se lance plus...

Sur le serveur « esclave » :[mysqld]log-error =/var/log/mysql.err

Page 26/41

On commente la ligne pour que mysql écoute sur toutes ses interfaces réseaux et non uniquement sur 127.0.0.1. L'esclave va se connecter au maître pour récupérer les données.

Identificateur du serveur maître (libre mais forcément différent de celui des autres serveurs participant à la réplication).

Spécifie le nom de la base à répliquer (on écrit autant de lignes qu'il y a de bases à répliquer).

Identificateur du serveur esclave différent de celui du maître.

Activation du log binaire nécessaire pour la réplication : un fichier journal binaire des requêtes SQL sera ainsi créé sur le serveur maître et sera utilisé par l'esclave pour « rejouer » les requêtes.

Isolation des logs de démarrage de MySQl dans un

Gestion des fichiers de log binaire qui peuvent devenir très lourds : on gère ici le délai d'expiration et leur taille maximale.

server-id = 104#bind-address = 127.0.0.1log_bin = /var/log/mysql/mysql-bin.loglog-slave-updatesexpire_logs_days = 10max_binlog_size = 100Mmaster-retry-count = 20replicate-do-db = databaseName

Remarque : la gestion des logs binaires sur l'esclave et notamment l'option log-slave-updates (comme le fait de commenter la variable « bind-address ») n'est utile que lors d'une réplication circulaire ou d'une réplication multi maître .

On peut maintenant redémarrer MySQL sur l'esclave.N'hésitez pas à lire en parallèle le fichier « /var/log/mysql.err » notamment si MySQL ne se lance plus...

Configurer le serveur « maître » : fichier /etc/mysql/my.cnf[mysqld]#bind-address = 127.0.0.1 log-error =/var/log/mysql.errserver-id =1log_bin = /var/log/mysql/mysql-bin.logexpire_logs_days = 10max_binlog_size = 100Mbinlog_do_db = gsb_valide

Configurer le serveur « esclave » : fichier /etc/mysql/my.cnf (au minimum)[mysqld]#bind-address = 127.0.0.1 log-error =/var/log/mysql.errserver-id =2log_bin = /var/log/mysql/mysql-bin.loglog-salve-updatesexpire_logs_days = 10max_binlog_size = 100Mmaster-retry-count = 20replicate-do-db = gsb_valide

Redémarrer MySQL pour que les modifications soient prises en compte/etc/init.d/ mysql restart

Lorsque la configuration est terminée, et si on ne l'a pas encore fait, il faut : s'assurer que les bases de données soient bien synchronisées, dans le cas contraire il faut le

faire (voir procédure dans la partie « Dépannages et maintenance » ) ; bloquer au préalable l'écriture sur le maître (si ce n'est déjà fait) ; récupérer des informations sur le maître (voir ci-après) ; indiquer à l'esclave via la commande SQL CHANGE MASTER TO l'ensemble des opérations

à réaliser (voir ci-après) ; permettre l'écriture sur le maître ; lancer l'esclave.

Étapes après modifications des fichiers de configuration

Sur le serveur maître, il est nécessaire, après s'être assuré que les deux bases de données sont identiques (voir comment faire dans la partie « dépannage » si vous avez un doute) :

De bloquer l'écriture :mysql> FLUSH TABLES WITH READ LOCK;Query OK, 0 rows affected (0.09 sec)

De repérer le log binaire et la position du jeu de commandes dans le log :mysql> show master status;

Page 27/41

Spécifie le nom de la base qui sera répliquée (on écrit autant de lignes qu'il y a de bases à répliquer).

Enregistre dans son journal (ses binlogs) les commandes qu’il reçoit de son master

Du résultat de cette requête, ce sont les champs File et Position qu'il faut noter.

C'est à partir de cette position que tout ce qui sera écrit sur le maître sera répliqué sur l'esclave. Un fois que les données ont été répliquées, l'esclave garde la trace du point où il en était rendu (une nouvelle Position, voire un nouveau File). Le serveur maître n'a pas de notions du nombre d'esclaves qui se connectent, ou qui sont à jour à un moment donné.

Il faut donc ensuite indiquer au serveur esclave : à partir de quel serveur maître il doit répliquer ses bases de données (on utilisera l'adresse IP

du serveur maître), en lisant quel fichier journal de requêtes (dans l'exemple, mysql-bin.00001), à partir de quelle position dans ce fichier journal (dans l'exemple, 3921), et enfin, avec quel utilisateur (il s'agit du compte utilisateur créé précédemment – Voir

« Étapes avant modification des fichiers de configuration » ).Tout ceci est effectué en une seule ligne avec la syntaxe spéciale CHANGE MASTER TO.

Le processus esclave, s'il existe (ce que l'on peut voir avec la commande « show slave status; », doit être arrêté auparavant.Pour ce faire, dans la console SQL du serveur esclave, exécutez : STOP SLAVE ;.Ce processus doit être redémarré ensuite.

Il est temps maintenant de déverrouiller les bases de données sur le serveur maître :mysql> UNLOCK TABLES;

Pour connaître le statut de l'esclave

Sur l'esclave

Page 28/41

Bloquer de nouveau l’écriture sur les bases du serveur maître. Sur le serveur maître, repérer le log binaire et la position du jeu de commandes dans le log

(avec show master status) Sur le serveur esclave, déclarer le serveur maître :

mysql> change master to-> master_host='10.22.100.212',-> master_user='replicateur',-> master_password='mdpreplicateur',-> master_log_file='mysql-bin.000001',-> master_log_pos=3921;mysql> start slave ;

Sur le serveur « maître », débloquer l'écriture : mysql> unlock tables;

2 Mettez en œuvre la réplication selon la procédure. 3 Proposez et réalisez des tests permettant de vérifier l'opérationnalité de la solution dans un

tableau à 4 colonnes (actions à effectuer, résultats attendus, résultats obtenus, statut)Le test peut se faire à partir de l'application ou directement en modifiant sur le maître le contenu de la base de données.

Actions à effectuer Résultats attendus Résultats obtenus Statut

Lancer l’application test1.sisr ajouter des info dans la bd test

La saisie est visible dans la base de données test du serveur maitre (SELECT * FROM `test` )

La saisie est visible dans la base de données test du serveur esclave (SELECT * FROM `test` )

OK

Page 29/41

4 Transformez l'architecture maître-esclave en architecture multi maître afin de ne pas perdre de données lorsque le serveur maître sera de nouveau opérationnel après une défaillance. Vous rédigerez au préalable une procédure.

En cas de défaillance du serveur maître

Si le serveur maître n'est plus disponible, Hearbeat bascule ses services sur le serveur esclave sur lequel MySQL est démarré et qui acceptera donc que l'application y accède en écriture... Jusque-là, il n'y a pas de souci.Le problème est que nous sommes, en natif, dans une configuration Maître-Esclave. Le master sera de nouveau fonctionnel à un moment donné et nous lui avons donné une préférence : les services vont basculer automatiquement, or ce dernier n'est pas configuré pour récupérer les données écrites sur le SLAVE...

Deux solutions sont possibles :Premier solution non automatisée avec le service MySQL non géré par PacemakerCette solution peut s'avérer très lourde à mettre en place, d'autant plus qu'il faut considérer deux cas :

cas n°1 : on s'est aperçu immédiatement que le serveur esclave a pris le relais ==> on le transforme en maître en repérant le log binaire et la position du jeu de commandes dans le log de manière à ce que, quand le maître soit de nouveau opérationnel, on le transforme momentanément en esclave pour qu'il puisse récupérer les données utiles ;

cas n°2 : on ne s'est pas aperçu immédiatement que le serveur esclave a pris le relais et des données ont été écrites dans la base de données avant que l'on récupère le log binaire et la position du jeu de commandes dans le log. Il faut récupérer l'intégralité de la base de données contenant les données actuelles et la restaurer sur le maître avant de relancer le service.

Dans les deux cas, en dehors de la lourdeur de la solution, l'interruption de services que celle-ci engendre peut ne pas être acceptable.

Deuxième solution : configurer la réplication MySQL en multi maîtreLe serveur de secours doit aussi être configuré comme étant maître au niveau de MySQL. Et chacun sera aussi l'esclave de l'autre.Cela revient en fait à réaliser deux réplications maître-esclave.Ainsi chaque serveur pourra, à chaque instant, prendre la relève de l'autre avec des données actuelles.

C'est cette solution que nous allons configurer car non seulement elle est simple à mettre en œuvre et fiable mais c'est la seule possible (avec MySQL) pour une répartition de charge (que nous allons effectuer dans un prochain Coté labo).

Le principe est : d'ajouter dans chaque fichier de configuration ce qui lui manque (pour le nœud actuellement

maître tout ce qui concerne la configuration d'un esclave et pour le nœud actuellement esclave tout ce qui concerne la configuration d'un maître) ;

de créer sur le « nouveau maître », l'utilisateur MySQL avec les droits adéquats ; de redémarrer MySQL ; de repérer sur chaque nœud le log binaire et la position du jeu de commandes dans le log ; de saisir sur chaque nœud les commandes change master to... et start slave (dans notre cas,

ces commandes ne sont à saisir que sur le nœud actuellement maître pour le transformer en esclave puisque l'autre nœud est déjà configuré en esclave) ;

Remarque : il ne faut surtout pas oublier d'ajouter l'option log-slave-updates sur chaque serveur. Le serveur « hdintralab » va se baser sur le log-bin du serveur « intralab » pour répliquer les données. Par défaut, le serveur « hdintralab » ne « log » pas dans ses log-bin les données de réplication. Or, ceci est indispensable de manière à ce « hdintralab » sache qu'un événement qu'il a déjà exécuté lui est revenu pour qu'il ne l'exécute pas deux fois (et vice-versa) ; c'est ce que permet cette option.

Pour tester la configuration, sur les 2 serveurs : show slave status \G;Slave_IO_Running et Slave_SQL_Running doivent être à Yes.

Remarque : dans le cas d'une configuration pour réaliser une répartition de charges, deux autres lignes doivent être ajoutées dans chaque fichier de configuration pour éviter les conflits

Page 30/41

d'insertion menant à l'échec la réplication car lors de l'écriture simultanée sur les deux maîtres, il pourrait y avoir des collisions au niveau des clés auto incrémentées.

L'astuce est de configurer chaque serveur pour qu'il génère des clef primaires qui n'entrent pas en conflit. Et cela est possible grâce aux variables auto-increment-increment et auto-increment-offset.

auto_increment_increment contrôle l'incrémentation entre les valeurs successives des clés (le pas d'incrémentation).

auto_increment_offset détermine le point de départ des valeurs des colonnes de type AUTO_INCREMENT.

Ainsi, pour une configuration à N maîtres, mettre : auto_increment_increment = N (sur chaque maître) ; auto_increment_offset = 1,2, ... , N (chaque maître aura une valeur unique)

Modifier des fichiers de configuration : Sur le serveur maître actuel – intralab : ajoute les modifications de manière à ce qu'il devienne

aussi esclave :

[mysqld]#bind-address = 127.0.0.1 log-error =/var/log/mysql.errserver-id =1log_bin = /var/log/mysql/mysql-bin.loglog-slave-updatesexpire_logs_days = 10max_binlog_size = 100Mbinlog_do_db = gsb_validemaster-retry-count = 20replicate-do-db = gsb_valide

Sur le serveur esclave actuel – hdIntralab : ajouter les modifications de manière à ce qu'il de-vienne aussi maître :

[mysqld]#bind-address = 127.0.0.1log-error =/var/log/mysql.errserver-id = 2log_bin = /var/log/mysql/mysql-bin.loglog-slave-updatesexpire_logs_days = 10max_binlog_size = 100Mmaster-retry-count = 20replicate-do-db = gsb_validebinlog_do_db = gsb_valide

Redémarrer MySQL pour que les modifications soient prises en compte/etc/init.d/ mysql restart

Sur le serveur hdIntralab, repérer le log binaire et la position du jeu de commandes dans le log (avec show master status)

Sur le serveur intralab, déclarer le serveur nouvellement maître :mysql> change master to-> master_host='10.22.100.215',-> master_user='replicateur',-> master_password='mdpreplicateur',-> master_log_file='mysql-bin.000003',-> master_log_pos=107;mysql> start slave ;

5 Après l'avoir testée, intégrez cette solution au Cluster.

Intégration de la deuxième solution dans un ClusterPage 31/41

On utilise ici la ressource d'hearbeat ocf:hearbeat:mysql et la possibilité de configurer une ressource en mode actif/actif.

Une ressource configurée en actif/actif est démarrée sur chaque nœud. Pour passer une ressource en mode actif/actif il faut utiliser la fonction “clone”. Il y a 3 types de clones :

Le clone « anonymous » (clone par défaut) : les ressources sont configurées de manière identique sur chaque nœud. Si un nœud est indisponible, il n’y a pas de bascule de cette ressource puisqu’elle est déjà fonctionnelle et identique sur l’autre nœud. Ce type de clone permet d'intégrer la deuxième solution dans le Cluster.

Le clone « globally-unique=true » : contrairement au cas précédent, les ressources ne sont pas identiques d’un nœud à l’autre. Elles peuvent par exemple, avoir des données différentes.

Le “multi-state” : c’est une ressource qui peut être dans 2 états différents : “master” ou “slave”. Ce type de clone aurait pu permettre d'intégrer (et d'automatiser) la première solution dans le Cluster et c'est celui que nous utiliserons dans le prochain Coté labo.

Le principe est de créer une ressource de manière classique (tous les paramètres par défaut de la ressource ocf:hearbeat:mysql conviennent à l'exception du chemin du socket qui doit être positionné à "/var/run/mysqld/mysqld.sock" ) puis de la cloner avec la commande : crm configure clone <nom_clone> <id_resource>

Par défaut, il s'agit d'un clone de type « anonymous », aucune option supplémentaire n'est donc nécessaire.

Après configuration, la commande crm_mon donne :============ Last updated: Tue Jul 30 14:47:59 2013 Last change: Tue Jul 30 14:47:43 2013 via cibadmin on intralabar Stack: Heartbeat Current DC: hdintralabar (d990204c-2de3-40c5-8f8d-4469d01aafb3) - partition with quorum Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, unknown expected votes 4 Resources configured. ============

Online: [ intralabar hdintralabar ]

Resource Group: servIntralab IPFailover (ocf::heartbeat:IPaddr2): Started intralabar serviceWeb (ocf::heartbeat:apache): Started intralabar Clone Set: cServiceMySQL [serviceMySQL] Started: [ hdintralabar intralabar ]

Pacemaker se chargera de démarrer le service MySQL sur les deux nœuds.

Pour tester rapidement, il suffit de modifier une valeur dans la base de données sur un nœud et regarder si cette valeur a été modifiée dans la base sur l'autre nœud et vice-versa.Intégration de la solution au curseur

Sur chaque serveur :insserv -r -v mysql

Sur un des deux nœuds :crm configure primitive serviceMySQL ocf:heartbeat:mysql params socket="/var/run/mysqld/mysqld.sock" crm configure clone cServiceMySQL serviceMySQL

6 Proposez et réalisez des tests permettant de vérifier l'opérationnalité de la solution complète en complétant votre tableau, faire les tests à partir d’un client différent des 2 serveurs.

Actions à effectuer Résultats attendus Résultats obtenus Statut

Page 32/41

Les ressources sont sur le nœud intralab :Modifier la bd test par test1.sisr

La saisie est visible dans la base de données test du serveur hdIntralab (SELECT * FROM `test` )

La saisie est visible dans la base de données test du serveur hdIntralab (SELECT * FROM `test` )

OK

On stoppe le noeud intralab.

Les ressources (mise à part la ressource serviceMySQL) migrent sur le nœud hdIntralab.

Les ressources (mise à part la ressource serviceMySQL) migrent sur le nœud hdIntralab.

OK

Les ressources sont sur le nœud hdIntralab :Modifier la bd test par test1.sisr

La saisie est visible dans la base de données test du serveur intralab (SELECT * FROM `test` )

La saisie est visible dans la base de données test du serveur intralab (SELECT * FROM `test` )

OK

On redémarrage le nœud intralab

Les ressources migrent sur ce noeud et les modifications apportées sur la base de données sont visibles.

Les ressources migrent sur ce noeud et les modifications apportées sur la base de données sont visibles.

OK

Page 33/41

Annexes

Annexe 1 :

comment retrouver un nœud propre ?Plusieurs raisons peuvent être à l'origine de l'instabilité d'un Cluster dont :

la modification « à la main » du fichier de configuration XML ; si on démarre Heartbeat avant clonage sur la première machine pour tester les fichiers de

configuration, il se crée un UUID associé à la machine ; lors du clonage, il maintient cet UUID pour la seconde machine. Heartbeat ne voit donc qu'un nœud et "switche" sans arrêt entre les deux (on le voit parfaitement dans les logs) ;

une erreur dans la configuration qu'il est difficile d'annuler via une commande crm.

Pour repartir sur une configuration de départ « propre »: arrêter le service Heartbeat sur les 2 machines ; supprimer dans /var/lib/heartbeat les fichiers hostcache et hb_uuid (sur les deux machines) ; supprimer dans /var/lib/heartbeat/crm le fichier cib.xml ; redémarrer Heartbeat.

Le fichier « hostcache » contient les UUID valides (à rapprocher des UUID écrits dans le fichier de configuration).

Il est aussi possible d'éditer et de modifier le fichier de configuration via la commande crm configure edit.

Exemple du fichier /etc/ha.d/ha.cf : ce fichier contient la configuration générale de Heartbeat http://www.linux-gatineau.org/book/export/html/18http://www.linux-ha.org/ha.cf- http://www.linux-ha.org/haresources- http://www.linux-ha.org/authkeysLe fichier /etc/ha.d/ha.cf- logfacility local0    # inscription dans journal local- logfile /var/log/ha    # nom du fichier journal- keepalive 1    # intervalle entre les paquets (en sec.)- deadtime 10    # nb de sec. avant de constater la mort- Warntime 2    # ¼ à ½ du nb de sec. de deadtime- baud 19200    # vitesse de comm. entre les ports série- serial /dev/ttyS0    # le port du lien série- bcast eth1    # le lien ethernet (câble croisé entre les 2 serveurs)- auto_failback on    # off=actif/passif on=actif/actif- node clo clo2    # ordi maître, ordi esclave

Le fichier haresources : Doit absolument être le même sur les deux serveurs, avec le nom du maître pour commencer, l'adresse de service et les services gérés par Heartbeat- clo 123.456.2.2/24/eth0 named apache2 postfix courier-imapd courier-pop3d mailman vsftpd mysql L'adresse 123.456.2.2 est un alias transféré d'un serveur à l'autre lorsque le maître n'est plus actif. Le fichier authkeys :- auth 1- 1 sha1 MotdePassePrisauhasardfc970c94efb On aurait également pu utiliser 1 CRC, mais pour des raisons de sécurité, CRC n'est pas recommandé pour des connexions autres qu'un câble série et un câble ethernet croisé. Autrement dit, pour une connexion d'ordi à ordi, ce qui est notre cas, ce n'aurait pas été un problème.

IP virtuelle sans ipfailoverCe texte du fichier /etc/network/interfaces assigne deux adresses IP à eth0.

auto eth0allow-hotplug eth0iface eth0 inet static address 10.22.100.212

Page 34/41

netmask 255.0.0.0

auto eth0:0allow-hotplug eth0:0iface eth0:0 inet static address 10.22.100.220 netmask 255.0.0.0

Page 35/41

Annexe 2 : création et configuration des ressources

Test de la solutionPlusieurs possibilités pour tester la solution mise en place dont :

arrêtez le serveur ou le service (utile pour tester la migration des autres ressources) ; mettre un nœud en maintenance : crm node standby sur le nœud que l'on veut rendre inactif

(crm node online pour le remettre actif).Si le service est arrêté, pacemaker a été configuré pour essayer de le redémarrer dans un premier temps : c'est le premier point à tester.Ensuite, pour tester un arrêt définitif du service de manière à ce que l'ensemble des ressources migrent sur l'autre nœud, il faut s'arranger pour que le service ne puisse pas redémarrer...

Quand le Cluster bascule sur l’autre nœud suite à un certain nombre d'erreurs sur une ressource, le nœud qui a rencontré les erreurs ne pourra plus héberger les ressources tant que toutes les erreurs n'auront pas été effacées par la commande suivante : crm resource cleanup <id_resource>

Page 36/41

Annexe 3 : principes de la réplication sur MySQL

Dépannage et maintenance

Une des erreurs les plus fréquentes est de ne pas démarrer avec les mêmes données dans la base (voire se trouver avec des données en conflit). Vous pourrez alors lire ce genre de choses dans les logs :Slave: Duplicate entry '75267' for key 'PRIMARY' Error_code: 1062121210 9:12:54 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000002' position 501Dans ce cas il est nécessaire de sauvegarder sur le maître la bonne base et de la restaurer sur l'esclave :Cette sauvegarde peut se faire directement à partir de l'esclave si le maître accepte les connexions à partir de l'utilisateur qui va effectuer cette sauvegarde (en production, on crée généralement un utilisateur pour cela).Exemple, à partir du serveur esclave (et après avoir stoppé l'esclave avec la commande mysql « stop slave; » :Stopper l'esclave :mysql> stop slave ;Query OK, 0 rows affected (0.06 sec)Sauvegarder dans un fichier « sauvBases.sql »mysqldump -h 10.22.100.100 -u root --databases nom_base1,nom_basen --add-drop-table -p<motDePasse> sauvBases.sqlL'option -- add-drop-table ajoute une commande « drop table » avant chaque requête de création de table : il n'est ainsi pas nécessaire de supprimer la table avant.Restaurer les bases sur l'esclave :mysql -p<motDePasse < sauvBases.sqlUne fois le dump effectué et avant de restaurer les écritures sur le maître, il faut récupérer la position du maître dans ses binlogs :

mysql> show master status;+------------------+----------+--------------+------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+------------------+----------+--------------+------------------+| mysql-bin.000002 | 48044 | DatabasesName | |+------------------+----------+--------------+------------------+1 row in set (0.00 sec)

Il est nécessaire de :

Lancer la commande « change master to » correspondante (seules les données qui ont changées par rapport à la commande précédente sont utiles) : mysql> change master to master_log_file='mysql-bin.000002', master_log_pos=48044;Query OK, 0 rows affected (0.10 sec)

Démarrer l'esclave :mysql> start slave;Query OK, 0 rows affected (0.00 sec)

Libérer les écritures sur le maître mysql> UNLOCK TABLES;Query OK, 0 rows affected (0.00 sec)La seconde erreur fréquente se produit quand il y a un décalage de la valeur des paramètres donnés par la commande « show master status » : cette erreur survient lorsque, par exemple, il y a eu écriture sur une base de l'esclave.Elle est facilement décelable en comparant :Sur le maître mysql> show master status;+------------------------+-----------+--------------------+------------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+------------------------+-----------+--------------------+------------------------+

Page 37/41

| mysql-bin.000002 | 444808 | DatabasesName| |+------------------------+-----------+--------------------+------------------------+1 row in set (0.00 sec)Sur l'esclavemysql> show slave status \G;*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.22.100.100 Master_User: replicateur Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 444808 Relay_Log_File: mysqld-relay-bin.000008 Relay_Log_Pos: 63459 Relay_Master_Log_File: mysql-bin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes ...

À noter que d'autres problèmes peuvent survenir comme : l'esclave qui ne contacte plus son maître ; l'esclave qui n'a pas pu exécuter une requête ; etc.

La commande précédente indiquera alors la cause de l'erreur et son numéro de référence MySQL pour dépanner.

Gestion des binlogsLes relay-logs de l'esclave (fichiers créés dans /var/lib/mysql et contenant les commandes à exécuter par l'esclave) sont consommés dès que toutes les requêtes de chacun ont été exécutées. Par conséquent, aucune action n'est nécessaire dessus.Par contre, ceci n'est pas vrai pour les binlogs du maître car celui-ci n'a pas conscience de ses esclaves et les binlogs s'empilent (même si nous les avons un petit peu géré dans le fichier de configuration).Afin de supprimer les binlogs qui deviennent consommateurs d'espace disque avec le temps, il convient de faire la requête suivante :mysql>SHOW MASTER LOGS;mysql>PURGE MASTER LOGS TO 'mysql-bin.000027';À la première ligne, le résultat indique le fichier binlog en cours. Il ne faut surtout pas le supprimer.La seconde ligne supprime tous les binlogs disponibles jusqu'à celui indiqué exclus.Il est préférable de ne pas supprimer directement les fichiers au niveau système (avec la commande rm) car dans ce cas MySQL ne gèrera plus ses binlogs correctement et donc la requête PURGE MASTER ne fonctionnera plus.Utilisation des fichiers /var/lib/mysql/master.info et /var/lib/mysql/relay-log.infoUn serveur de réplication esclave crée deux autres petits fichiers dans le dossier de données. Ces fichiers sont appelés master.info et relay-log.info par défaut. Ils contiennent des informations comme celles affichées par la commande SHOW SLAVE STATUS. En tant que fichier disques, ils survivent à l'extinction de l'esclave. Au prochain démarrage de l'esclave, ce dernier pourra lire ces fichiers pour savoir où il en était du traitement des événements du maître et de leur lecture.Lorsque l'on sauvegarde les données de l'esclave, il est nécessaire de sauver ces deux fichiers, ainsi que les logs de relais. Ils sont utiles pour reprendre la réplication après une restauration de la base. En cas de perte des logs de relais, le fichier relay-log.info peut limiter les dégâts, car il est possible de déterminer ce que le thread SQL a traité des logs binaires du maître. Puis, on utilise CHANGE MASTER TO avec les options MASTER_RELAY_LOG et MASTER_RELAY_POS pour dire au thread d'I/O de relire les logs depuis ce point. Cela impose que ces logs soient toujours disponibles sur le serveur.

Page 38/41

Ici, pas d'erreur, les valeurs correspondent bien.

Annexe 4 : récapitulatif des commandes courantes

Vérifier que Heartbeat est lancé :/etc/init.d/heartbeat status

Vérifier que Heartbeat est actif : cl_status hbstatus

Voir la liste des noeuds : cl_status listnodes

Voir l'état d’un noeud : cl_status nodestatus nom_node

Accéder à l'interface de configuration du Cluster :crm

crm(live)# help

This is the CRM command line interface program.

Available commands:

cib manage shadow CIBs resource resources management node nodes management options user preferences configure CRM Cluster configuration ra resource agents information center status show Cluster status quit,bye,exit exit the program help show help end,cd,up go back one level

Si on saisit crm(live)# nom_commande help, on a les différentes possibilités d'arguments après la commande et ainsi de suite...

Éditer/Modifier une configurationcrm configure editcela vous placera dans une instance de « vim » pour effectuer une modification qui sera appliquée à la sauvegarde.

Éditer/Modifier directement une ressourcecrm configure edit <id_ressource>cela vous placera dans une instance de « vim » pour effectuer une modification qui sera appliquée à la sauvegarde.

Modifier la configuration du Cluster en entrant directement dans la mode de configuration :crm configure

Voir la configurationcrm(config)configure# show

Équivalent de crm configure showVérifier sa configurationcrm(config)configure# verify

Page 39/41

Équivalent de crm configure verify

Stopper une ressourcecrm resource stop <id_ressource>

Démarrer une ressourcecrm resource start <id_ressource>

Supprimer une ressourcecrm configure delete <id_ressource>

Si la ressource est en cours d'utilisation, il vaut mieux la stopper avant de la supprimer.

Déplacer une ressourcecrm resource move <id_ressource> <noeud>

Annuler le déplacementcrm resource unmove <id_ressource>

Préférence du noeudcrm configure location <nouvel_id_ressource> <id_ressource> <score>: <nœud>

La ressource <id_ressource> préférera tourner sur le nœud <nœud>.

Liste des ressources OCFcrm ra list ocf heartbeat

Connaître la liste complète des paramètres d’une primitive, crm ra info ocf:heartbeat:nom_primitive.

Vous obtenez la liste des timeout par défaut, des paramètres et de leurs valeurs par défaut, les paramètres obligatoires et facultatifs.

Mettre un poste en maintenancecrm node standby [<nœud>]

Sortir un poste de maintenancecrm node online [<nœud>]

Effacer les erreurs sur une ressourcecrm resource cleanup <id_resource>

Cloner une ressource (de type « anonymous »)crm configure clone <nom_clone> <id_resource>

Sauvegarder une configurationcrm configure save /root/sauveha.confcrm configure save xml /root/sauveha.conf.xml # Version XML

Restaurer une configuration (et remplacer la configuration actuelle)crm configure load replace /root/sauveha.conf

Mettre à jour une configurationcrm configure load update /root/sauveha.conf

Page 40/41