Haute disponibilité d'un service Web dynamique

Transcription

1 Haute disponibilité d'un service Web dynamique Propriétés Type de publication Intitulé court Intitulé long Module Côté Labo Date de publication Septembre 2013 Date de modification Septembre 2013 Version V1.0 Description Haute disponibilité d'un serveur Web dynamique Haute disponibilité d'un serveur Web avec réplication de la base de données correspondante. BTS SIO2 SISR3 Exploitation des services 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 Présentation Activités Pré-requis Savoir-faire principaux 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 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é» : D1.3 - Mise en production d'un service A1.3.2 Définition des éléments nécessaires à la continuité d'un service 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 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. 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 CERTA - septembre 2013 v1.0 Page 1/30

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 Mots-clés Durée Auteur(es) 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 : Documentation : Disponibilité, HA, HD, Cluster, Heartbeat, Pacemaker, réplication. 12 heures en TP 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 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. ( 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. CERTA - septembre 2013 v1.0 Page 2/30

3 Comment ça marche? Selon 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. CERTA - septembre 2013 v1.0 Page 3/30

4 Exemple d'un fonctionnement en cas de serveur maître disponible : Serveur maître IP : Serveur esclave IP : IP virtuelle Lors de son lancement et après configuration, Heartbeat, via Pacemaker, activera l'ip virtuelle au serveur considéré comme «actif» à un instant donné. Si le serveur maître n'est plus disponible : À 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). Serveur maître IP : Serveur esclave IP : IP virtuelle En cas de défaillance du serveur primaire, c'est le serveur secondaire qui sera accessible à l'adresse 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. CERTA - septembre 2013 v1.0 Page 4/30

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) : La base de données est accessible par chaque serveur Web. Les disques sont éventuellement en RAID. Serveur maître Hearbeat + Pacemaker + service Web actif Lien HA Serveur esclave Hearbeat + Pacemaker + service Web non actif IP virtuelle 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 IP : Hearbeat + Pacemaker + serveur Web (Apache 2) + serveur de bases de données (MySQL) IP virtuelle Lien HA + Réplication MySQL Serveur esclave IP : Hearbeat + Pacemaker + serveur Web (Apache 2) + serveur de bases de données (MySQL) CERTA - septembre 2013 v1.0 Page 5/30

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 viceversa : 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). CERTA - septembre 2013 v1.0 Page 6/30

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. CERTA - septembre 2013 v1.0 Page 7/30

8 Proposez et réalisez des tests permettant de vérifier l'opérationnalité de la solution complète en complétant votre tableau. CERTA - septembre 2013 v1.0 Page 8/30

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 : > c'est celle qui est dans /etc/network/interfaces IP virtuelle : hdintralab : serveur esclave IP réelle : > c'est celle qui est dans /etc/network/interfaces IP virtuelle : CERTA - septembre 2013 v1.0 Page 9/30

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 logfacility local7 logfile /var/log/ha-log debugfile /var/log/ha-debug use_logd no udpport 694 keepalive 2 deadtime 20 initdead 50 auto_failback off node intralabar node hdintralabar ucast eth ucast eth crm yes Explications 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 Port utilisé par les mécanismes de "battements de coeur" Délai entre 2 battements (en secondes) Temps nécessaire (en secondes) avant de déclarer un nœud comme mort Valeur utilisée pour le démarrage (> 2 fois le deadtime) 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. Liste des nœuds participants au Cluster (ne pas oublier de configurer le fichier «hosts» sur chacun des nœuds) Lien réseau utilisé pour les battements de cœur 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 D'autres méthodes d'authentification sont possibles 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 CERTA - septembre 2013 v1.0 Page 10/30

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: Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: a28b7f31d7ddc bd23114f58978b 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: Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: a28b7f31d7ddc bd23114f58978b 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-d4ee d" hdintralabar node $id="f21c8f9a-8d38-4e1d-a9c8-96e403cd7596" intralabar property $id="cib-bootstrap-options" \ dc-version=" a28b7f31d7ddc bd23114f58978b" \ Cluster-infrastructure="Heartbeat" \ stonith-enabled="false"\ no-quorum-policy="ignore" CERTA - septembre 2013 v1.0 Page 11/30

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-d4ee d" epoch="8" num_updates="0" admin_epoch="0" cib-last-written="sat Nov 24 00:49: "> <configuration> <crm_config> <Cluster_property_set id="cib-bootstrap-options"> <nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value=" a28b7f31d7ddc bd23114f58978b"/> <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-d4ee d" 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-quorumpolicy="ignore". CERTA - septembre 2013 v1.0 Page 12/30

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. CERTA - septembre 2013 v1.0 Page 13/30

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 ( 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 : 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 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). CERTA - septembre 2013 v1.0 Page 14/30

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 /16 (d'autres options sont disponibles) root@intralabar:~# crm configure primitive IPFailover ocf:heartbeat:ipaddr2 params ip=" " cidr_netmask=" " 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= « » : nom et valeurs du paramètre «ip» cidr_netmask= « » : 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: Last change: Fri Jul 26 15:48: via crm_attribute on intralabar Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: 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). CERTA - septembre 2013 v1.0 Page 15/30

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 /16 brd scope global eth0 inet /16 brd 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: Bcast: Masque: adr inet6: fe80::7ce9:2eff:fe18:13b7/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets: errors:0 dropped:0 overruns:0 frame:0 TX packets: errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes: (23.3 MiB) TX bytes: (33.2 MiB) eth0:vip Link encap:ethernet HWaddr 7e:e9:2e:18:13:b7 inet adr: Bcast: Masque: 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=" " cidr_netmask=" " 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. CERTA - septembre 2013 v1.0 Page 16/30

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... À partir de ce moment là, dès que le location cli-prefer-ipfailover IPFailover \ nœud intralabar est actif, la ressource rule $id="cli-prefer-rule-ipfailover" inf: #uname eq intralabar migrera vers ce nœud (auto failback).... 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: Last change: Fri Jul 26 15:48: via crm_attribute on intralabar Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: 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: Last change: Fri Jul 26 15:48: via crm_attribute on intralabar Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, unknown expected votes 1 Resources configured. ============ Online: [ hdintralabar intralabar ] IPFailover (ocf::heartbeat:ipaddr2): Started intralabar CERTA - septembre 2013 v1.0 Page 17/30

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: Last change: Fri Jul 26 15:48: via crm_attribute on intralabar Stack: Heartbeat Current DC: hdintralabar (462d81f0-07d8-4c88-af27-d4ee d) - partition with quorum Version: ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, unknown expected votes 2 Resources configured. ============ Online: [ hdintralabar intralabar ] CERTA - septembre 2013 v1.0 Page 18/30

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> CERTA - septembre 2013 v1.0 Page 19/30

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. CERTA - septembre 2013 v1.0 Page 20/30