• Aucun résultat trouvé

Haute disponibilité d'un service Web dynamique

N/A
N/A
Protected

Academic year: 2022

Partager "Haute disponibilité d'un service Web dynamique"

Copied!
30
0
0

Texte intégral

(1)

Haute disponibilité d'un service Web dynamique

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 ser- vice

D2.1 - Exploitation des services

A2.1.2 Évaluation et maintien de la qualité de service D3.2 - Installation d’une solution d’infrastructure

D3.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

(2)

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érieur

Serveurs/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.

(3)

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é à 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.

(4)

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 coté 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.

Serveur maître IP : 10.22.100.212

Serveur esclave IP : 10.22.100.215

IP virtuelle 10.22.100.220

Serveur maître

IP : 10.22.100.212 Serveur esclave

IP : 10.22.100.215

IP virtuelle 10.22.100.220

À noter qu'il n'y a pas que l'IP virtuelle qui sera activée sur un serveur et désactivée sur

l'autre mais aussi les services (appelés ressources) que l'on a décidé

de mettre en haute disponibilité (comme HTTP).

Lors de son lancement et après configuration, Heartbeat, via Pacemaker, activera l'IP virtuelle 10.22.100.220 au serveur considéré comme « actif » à un instant donné.

En cas de défaillance du serveur primaire, c'est le serveur secondaire qui sera accessible à l'adresse 10.22.100.220.

(5)

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) :

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 Coté labo, implantées sur le même serveur que le serveur Web mais le principe de réplication est strictement identique.

L'architecture mise en place est la suivante : Serveur maître

Hearbeat + Pacemaker + service Web actif

Serveur esclave Hearbeat + Pacemaker + service Web non actif

IP virtuelle

La base de données est accessible par chaque serveur Web. Les disques sont éventuellement en RAID.

Lien HA

Serveur maître IP : 10.22.100.212

Serveur esclave IP : 10.22.100.215

IP virtuelle 10.22.100.220

Hearbeat + Pacemaker + serveur Web (Apache 2) + serveur de bases de données (MySQL)

Lien HA + Réplication

MySQL Hearbeat + Pacemaker + serveur Web (Apache 2) + serveur de bases de données (MySQL)

(6)

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 Coté 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).

(7)

Déroulement de la séquence

Préalable :

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

1. Préparation des serveurs primaire et secondaire (aide en annexe 1)

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 » « intralabXX » et le serveur secondaire

« hdintralabXX » où XX représente les initiales des prénoms et noms des étudiants).

Vérifiez que l'application Gestion de frais est bien accessible sur le serveur maître.

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

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

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

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

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

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

2. Configuration des ressources « failover IP » et « serviceWeb » (aide en annexe 2) Configuration du Failover IP

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

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

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

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

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

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

Testez le « failover IP » des deux manières présentées en annexe 2. Y a-t-il une différence ? Configuration de la ressource HTTP

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

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

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

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

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

3. Configuration de la réplication des bases de données (aide en annexe 3)

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.

Écrivez la procédure détaillée que vous allez mettre en œuvre pour configurer la réplication de la base de données. Cette procédure fera l'objet d'un échange avec votre professeur avant son implémentation.

Mettez en œuvre la réplication selon le procédure.

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).

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.

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

(8)

Proposez et réalisez des tests permettant de vérifier l'opérationnalité de la solution complète en complétant votre tableau.

(9)

Annexes

Annexe 1 : fonctionnement et configuration de Hearbeat 3 et de Pacemaker

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.

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'activerl'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.

Pour démarrer et/ou stopper le Cluster, il suffit de démarrer et/ou stopper le démon

« heartbeat ».

L'exemple de configuration qui suit est basé sur la configuration IP suivante : intralab : serveur maître

IP réelle : 10.22.100.212 --> c'est celle qui est dans /etc/network/interfaces

IP virtuelle : 10.22.100.220 hdintralab : serveur esclave

IP réelle : 10.22.100.215 --> c'est celle qui est dans /etc/network/interfaces

IP virtuelle : 10.22.100.220

(10)

La configuration s'articule autour des fichiers suivants qui doivent être identiques sur les deux serveurs.

/etc/ha.d/ha.cf : ce fichier contient la configuration générale de Heartbeat

Directives et valeurs Explications

logfacility local7 logfile /var/log/ha-log debugfile /var/log/ha-debug use_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 mort

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

auto_failback off La 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 intralabAR

node 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.212

ucast 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 1

1 sha1 PassPhrase

Par mesure de sécurité, les droits sur ce fichier doivent être réduit à la lecture et écriture seulement à l'utilisateur root (si ce n'est pas fait, Heartbeat ne démarre pas)

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.).

Les commandes utiles

Pour 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 listnodes

Et l'état d’un noeud : cl_status nodestatus ma-machine-esclave.mondomaine.com D'autres méthodes d'authentification sont possibles

(11)

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 2012 Stack: Heartbeat

Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorum Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b

2 Nodes configured, unknown expected votes 0 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 2012 Stack: Heartbeat

Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorum Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b

2 Nodes configured, unknown expected votes 0 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, Heartbeat

Current 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 show

node $id="462d81f0-07d8-4c88-af27-d4ee9254640d" hdintralabar node $id="f21c8f9a-8d38-4e1d-a9c8-96e403cd7596" intralabar property $id="cib-bootstrap-options" \

dc-version="1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b" \ Cluster-infrastructure="Heartbeat" \

stonith-enabled="false"\

no-quorum-policy="ignore"

(12)

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 defined

crm_verify[690]: 2012/11/24_00:31:01 ERROR: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option

crm_verify[690]: 2012/11/24_00:31:01 ERROR: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity

Errors 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=false INFO: 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".

(13)

Note : 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.

(14)

Annexe 2 : création et configuration des ressources

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).

(15)

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 virtuelle

À 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: Heartbeat

Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorum Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff

2 Nodes configured, unknown expected votes 1 Resources configured.

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

Online: [ hdintralabar intralabar ]

IPFailover (ocf::heartbeat:IPaddr2): Started hdintralabar

Et 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).

(16)

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 show 1: 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 forever 4: eth1: ...

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"

« 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.

(17)

Deuxième étape : définir une préférence de nœud primaire pour l'adresse virtuelle

Il 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 intralabar

Et 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'IP

Plusieurs 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 « intralabAR » a pour effet de faire basculer l'adresse IP virtuelle sur le nœud hdintralabAR :

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

Last updated: Sat Jul 27 01:39:54 2013

Last change: Fri Jul 26 15:48:11 2013 via crm_attribute on intralabar Stack: Heartbeat

Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorum Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff

2 Nodes configured, unknown expected votes 1 Resources configured.

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

Node intralabar (f21c8f9a-8d38-4e1d-a9c8-96e403cd7596): standby Online: [ hdintralabar ]

IPFailover (ocf::heartbeat:IPaddr2): Started hdintralabar

Un 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 intralabar Stack: Heartbeat

Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorum Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff

2 Nodes configured, unknown expected votes 1 Resources configured.

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

Online: [ hdintralabar intralabar ]

IPFailover (ocf::heartbeat:IPaddr2): Started intralabar

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

(18)

Rappel : en production, il est parfois préférable de maîtriser le retour au serveur maître.

Configuration de la ressource « serviceWeb »

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 commande possibles ;

la possibilité de configurer plusieurs ressources avec leurs propriétés avant de valider le tout.

root@intralabAR:~# crm configure

crm(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# commit crm(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"

...

À 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: Heartbeat

Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee9254640d) - partition with quorum Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff

2 Nodes configured, unknown expected votes 2 Resources configured.

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

Online: [ hdintralabar intralabar ]

(19)

IPFailover (ocf::heartbeat:IPaddr2): Started intralabar intralab (lsb:intralab): Started hdintralabar

Mais, 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 configure

crm(live)configure# group servIntralab IPFailover serviceWeb meta migration-threshold="5"

crm(live)configure# commit crm(live)configure# quit

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.

Test de la solution

Plusieurs 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>

(20)

Annexe 3 : principes de la réplication sur MySQL

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

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 ;

lui attribuer aussi les droits de connexion depuis tous les esclaves.

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 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; ».

Configuration de la réplication via le fichier /etc/mysql/my.cnf sur chaque serveur : la réplication de bases de donnés 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.

(21)

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 = 10 max_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 server-id = 104

#bind-address = 127.0.0.1

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 = 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 (voir dernière partie de cette annexe).

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...

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 ;

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.

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).

Isolation des logs de démarrage de MySQl dans un fichier (sinon les logs s'écrivent dans /var/log/syslog).

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.

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

(22)

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;

+---+---+---+---+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +---+---+---+---+

| mysql-bin.000001 | 3921 | databasesName | | +---+---+---+---+

1 row in set (0.00 sec)

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.

mysql> stop slave;

mysql> change master to

-> master_host='10.22.100.100', -> master_user='replicateur',

-> master_password='mdpreplicateur', -> master_log_file='mysql-bin.000001', -> master_log_pos=3921;

mysql>start slave ;

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

Les bases à répliquer doivent apparaître, séparées d'une virgule.

Ces informations sont sauvées automatiquement dans le fichier /var/lib/mysql/master.info.

(23)

Pour connaître le statut de l'esclave

Sur l'esclave

mysql> 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.000001 Read_Master_Log_Pos: 3921

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

Replicate_Do_DB: gsb_valide Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0 Last_Error:

Skip_Counter: 0 Exec_Master_Log_Pos: 444808 Relay_Log_Space: 65440 Until_Condition: None Until_Log_File:

Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error:

Last_SQL_Errno: 0 Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 100

Permet d'avoir un affichage ligne par ligne pour pouvoir être lu correctement dans une console

Le résultat retourné est relativement complexe mais il contient notamment les informations à vérifier (master_log_file, read_master_log_pos, fichier journal lu sur le maître, fichier relais, etc), ainsi que l'état du processus esclave (Slave_IO_State)

Références

Documents relatifs

Exercice : trouvez la directive DocumentRoot dans le fichier de configuration et modifiez la racine pour qu’elle pointe vers un répertoire de votre choix (par exemple c:/web )..

Créez un lien ODBC (aller dans le panneau de configuration, outils d'administration, sources de données (ODBC), onglet sources de données utilisateur, et créez une nouvelle source

Placer des images dans un répertoire &#34;pics&#34; du serveur PHP, puis utiliser la fonction glob(’pics/*’) pour les afficher toutes dans une page HTML.. Écrire un tableau PHP de

Après tant d'efforts pour chrooter MySQL, nous pouvons nous demander si cela en vaut la peine. Il est sûr qu'en terme de sécurité, nous diminuons sérieusement la vulnérabilité de

Activités Élèves • Installer le serveur en python et un premier exemple : ”Hello World !” • Structurer le site web • Intégrer des variables ”python” dans un fichier

− Un pré processeur logique de gestion des servlets (sous forme d’un service Internet) destinée à connecter au service HTTPD permettant de générer les documents HTML

La reprise manuelle (configuration par défaut pour Server Recovery Manager) a lieu lorsque le service a été restauré et que le groupe de redondance autorise le bouton de

Langages côté serveur Bases de données Frameworks Aspects pratiques.. Comment se faire héberger un