Haute disponibilité d'un serveur FTP
Propriétés Description
Type de publication Côté Labo
Intitulé court Haute disponibilité d'un serveur FTP (File Transfert Protocol)
Intitulé long Haute disponibilité d'un serveur FTP avec synchronisation des données via DRBD
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 Côté Labo (mis en œuvre en module) est de poursuivre la mise en haute disponibilité des services (Coté Labo « Haute disponibilité du service Web avec réplication de la base de données correspondante ») en intégrant le serveur FTP.
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).
Avoir réalisé le Coté Labo « Haute disponibilité du service Web ».
Rôle et principaux concepts du service FTP.
Rôle et principaux concepts d'un système de gestion de fichiers.
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
Prolongements En SI7 :
• Rédiger, mettre en place et tester un Plan de Continuité D'Activité (PCA)
En SISR3 :
• Affiner la configuration de DRBD
• Assurer la haute disponibilité d'autres services aux utilisateurs
• Intégrer un autre nœud dans le Cluster
• Intégrer la répartition de charges
• Authentification LDAP pour le service FTP En SISR4 :
• Assurer la haute disponibilité des services système comme l'authentification
En SISR5 :
• Assurer la haute disponibilité des services réseau (DNS, DHCP, etc)
• Assurer la haute disponibilité du matériel d'interconnexion
• Superviser le Cluster
Outils SE : Serveur Linux Debian Wheezy (stable actuelle) ou ultérieur
Serveurs/services : proftpd installé et configuré à l'identique sur deux serveurs, Hearbeat et Pacemaker.
Clients : client FTP sur STA Linux, Windows ou autre système.
Contexte : organisation/GSB-Organisation.doc.
Documentation : organisation/outils/GSB-DocumentTechnique.doc Site officiel de Pacemaker : http://clusterlabs.org/
Documentation en ligne :
http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html- single/Pacemaker_Explained/index.html
Site officiel de DRBD : /www.drbd.org/ et plus particulièrement http://www.drbd.org/users-guide-8.3/
Mots-clés Disponibilité, HA, HD, Heartbeat, Pacemaker, synchronisation, FTP, DRBD
Durée 8 heures
Auteur(es) Apollonie Raffalli avec la relecture attentive de Rogez Sanchez et Gaëlle Castel
La haute-disponibilité d'un serveur de fichiers
Dans le précédent Côté Labo, nous avons installé un solution de haute disponibilité du service Web pour l'application de gestion de frais avec failback automatique (retour automatique vers le serveur primaire).
Nous proposons ici de compléter les services aux utilisateurs mis en haute disponibilité avec un serveur FTP qui mettra à disposition (en lecture et écriture) certains répertoires du disque.
Comme pour un serveur Web dynamique, la haute disponibilité d'un serveur de fichier nécessite une solution qui va permettre de répliquer les données de manière à ce que si le serveur de secours venait à prendre le relais, il dispose des données actuelles. De même pour le retour vers le serveur d'origine.
Comme pour le service Web avec un système de gestion de bases de données, plusieurs architectures sont possibles.
Les données sont stockées sur un serveur « à part » (un serveur NAS par exemple) :
Tout ce qui est écrit sera retrouvé par l'autre machine, mais nous introduisons ici un point de faiblesse car en cas de défaillance du serveur de fichiers 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 fichier en synchronisant en temps réel les fichiers sur une autre machine. La solution la plus simple pour créer ce type de serveur est d'utiliser DRBD (Distributed Replicated Block Device en anglais, ou périphérique en mode bloc répliqué et distribué) qui est un outil qui synchronise (par réplication) des périphériques de stockage (partition, volume logique, etc.) entre deux nœuds via le réseau (une sorte de RAID 1 réseau).
Pour utiliser DRBD et synchroniser des données, il n'est pas nécessaire d'utiliser un serveur « à part », il suffit d'isoler les données à synchroniser sur une partition ou un volume logique : c'est l'architecture que nous allons utiliser.
Les données sont stockées dans une partition sur chaque serveur :
Le fonctionnement résumé de DRBD est le suivant :
● Une ou plusieurs partitions (déclarée(s) dans un fichier de configuration) contenant les données à répliquer est identique sur chaque serveur ;
● Dans la plupart des cas, un seul serveur (celui qui est actif) est habilité à recevoir des données (sauf à utiliser un système de fichier comme OCFS -Oracle Cluster File System- qui permet la synchronisation de deux partitions montées en lecture et écriture) ;
● La synchronisation est réalisée en temps réel car elle se fait à la volée, pendant que les données sont modifiées : lorsqu'une opération en écriture a lieu sur cette partition, DRBD l'intercepte et envoie les blocs du disque dur qui ont été modifiés vers l'autre serveur ;
● l'utilisation est transparente : les applications (comme dans notre cas, le service FTP), qui enregistrent leurs données sur le périphérique de stockage répliqué, le font sans même savoir qu'il s'agit d'une unité de stockage spéciale.
Serveur maître hearbeat+pacemaker +service FTP
Serveur esclave hearbeat+pacemaker +service FTP
IP virtuelle
Les fichiers sont accessibles par chaque serveur. 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
Partition 1 : syst + appli
Partition 2 : données Partition 1 : syst + appli
Partition 2 : données
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é » ). La haute disponibilité de cette application est assurée via un serveur de secours (Cté Labo « haute disponibilité du service Web »).
GSB dispose ainsi :
● d'un serveur maître intralab ;
● d'un serveur de secours hdintralab.
La mise en œuvre de la haute disponibilité a été simulée sur des machines virtuelles présentes dans la ferme des serveurs et le cluster est accessible par son adresse IP virtuelle correspondant au nom DNS « servIntralabXX.gsb.coop » où XX représente les initiales de vos prénoms et noms.
Il a été décidé de mettre à disposition sur le serveur intralab un service FTP (le paquetage proftpd) utile aux développeurs de GSB pour transférer leurs fichiers. Ce service sera intégré à la solution de haute disponibilité.
Nous supposerons ici que chaque nœud dispose de trois partitions :
● /dev/sda1 : une partition primaire sur laquelle on trouve le système et les applications ;
● /dev/sda5 : une partition logique destinée à accueillir les données des utilisateurs (le répertoire /home) ;
● /dev/sda6 : la partition swap.
Proftpd sera installé sur la première partition du disque dur. Chaque utilisateur du système (dont les développeurs) aura accès, après authentification, en lecture et écriture à son propre FTP dans son répertoire personnel. À terme, l'ensemble des répertoires personnels seront donc déportés sur /dev/sda5.
Par mesure de simplification, l'authentification sera une authentification « classique » via les fichiers système (/etc/passwd, /etc/shadow, /etc/group). C'est le comportement par défaut de proftpd ; ainsi, après l'installation, aucune modification n'est à opérer sur le fichier de configuration.
Le client FTP utilisé sur les STA peut être en ligne de commande et/ou graphique (comme filezilla disponible sur Windows et Linux).
Vous trouverez :
● dans la documentation technique de GSB (organisation/outils/GSB-DocumentTechnique.doc) l'installation et la configuration du serveur proftpd (fiche 5) ;
● en annexe 1, un mode opératoire concernant l'installation et la configuration de DRBD ;
● en annexe 2, la configuration d'une ressource en mode actif/actif
● en annexe 3, un récapitulatif des commandes
Sur chacun des deux serveurs, la partition /dev/sda5 est celle que DRBD duplique.
Comme nous faisons le choix (arbitraire) d'enregistrer les méta-données sur cette partition, elle ne doit pas être formatée (ou si elle l'est, elle devrait être remise à zéro).
Il est possible (et conseillé en production) d'utiliser une autre partition (non formatée ou remise à zéro) pour les méta-données.
Déroulement de la séquence
Préalable :
● Créez sur chaque serveur la ou les partitions en ext3 ou ext4 nécessaires.
● Installez, configurez et testez sur chaque serveur le service FTP.
1. Installation et configuration de DRBD (aide en annexe 1)
L'installation et la configuration de DRBD se fera dans un premier temps isolément des problématiques d'Heartbeat et de Pacemaker.
● Activez le module DRBD et installez les outils de gestion.
● Procédez à la configuration de DRBD sur chacun des serveurs.
● Proposez et réalisez des tests permettant de vérifier que la solution est opérationnelle dans un tableau à 4 colonnes (actions à effectuer, résultats attendus, résultats obtenus, statut).
2. Intégration du service FTP dans le Cluster (aide en annexe 2) Configuration des ressources DRBD et FileSystem
● Sur les deux nœuds, arrêtez le service DRBD et supprimez ce service du démarrage.
● Créez les ressources nécessaires.
● Proposez et réalisez des tests permettant de vérifier que la solution est opérationnelle dans un tableau à 4 colonnes (actions à effectuer, résultats attendus, résultats obtenus, statut).
Configuration de la ressource FTP
● Sur les deux nœuds, arrêtez le service FTP et supprimez ce service du démarrage.
● Créez la ressource « serviceFTP » et procédez aux ajustements nécessaires.
● Proposez et réalisez des tests permettant de vérifier que la solution est opérationnelle dans un tableau à 4 colonnes (actions à effectuer, résultats attendus, résultats obtenus, statut).
3. Sauvegarde de la configuration
● Sauvegardez votre configuration
● Testez une restauration (ou mise à jour)
Lors des différents tests, s'ils portent sur l’arrêt d'une ressource mise en erreur :
● ne pas oublier de supprimer toutes les erreurs via la commande : crm resource cleanup <id_resource> ;
● vérifier l’ensemble des ressources par la commande : crm_resource -P
Annexes
Annexe 1 : installation et configuration de DRBD
Le module DRBD (Distributed Replicated Block Device) est donc un autre composant du High-Availability Linux Project qui a pour rôle de synchroniser les données entre deux postes. DRBD offre une excellente garantie de réplication des données en fonctionnant en RAID-1 par IP : les données sont copiées simultanément sur deux postes via le réseau.
DRBD est constitué d'un module du noyau (le cœur du système), qui se comporte comme un driver de système de fichiers, et d'outils de gestion regroupés dans le paquetage drbd8-utils.
Le noyau installé avec debian Wheezy (version stable) dispose théoriquement du module DRBD dans sa version 8.3.11.
Sur chaque serveur, il est possible de le charger (modprobe drbd) mais il n'est pas nécessaire de gérer le module soi-même car DRBD va le charger et le décharger automatiquement via le service (script /etc/init.d/drbd).
Pour vérifier qu'il soit bien chargé : lsmod | grep drbd
Pour obtenir des informations sur le module installé : modinfo drbd filename: /lib/modules/3.2.0-4-amd64/kernel/drivers/block/drbd/drbd.ko alias: block-major-147-*
license: GPL version: 8.3.11
description: drbd - Distributed Replicated Block Device v8.3.11
author: Philipp Reisner <phil@linbit.com>, Lars Ellenberg <lars@linbit.com>
srcversion: F937DCB2E5D83C6CCE4A6C9
….
Et la commande cat /proc/drbd doit renvoyer (avant configuration) : version: 8.3.11 (api:88/proto:86-96)
srcversion: F937DCB2E5D83C6CCE4A6C9
Il est nécessaire ensuite d'installer les outils de gestion drbd8-utils.
Étape 1 : les fichiers de configuration
La configuration s'articule autour des fichiers suivants qui doivent être identiques sur les deux serveurs.
● /etc/drbd.conf : fichier général qui inclut les autres (nous ne le modifierons pas).
● /etc/drbd.d/global_common.conf : pour les paramètres généraux et communs à toutes les ressources.
● /etc/drbd.d/nom_ress.res : théoriquement, un fichier pour chaque ressource (une ressource correspond à UNE partition (block device) sur laquelle DRBD va agir).
L'exemple de configuration qui suit est basé sur la configuration 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
➔ /dev/sda5 est la partition que DRBD va répliquer. Toutes les données de cette partition seront perdues si les méta-données sont enregistrées sur cette partition.
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
➔ /dev/sda5 est la partition que DRBD va répliquer. Toutes les données de cette partition seront perdues si les méta-données sont enregistrées sur cette partition.
● /etc/drbd.d/global_common.conf : ce fichier contient les directives communes à toutes les ressources. Ces directives peuvent être surchargées lors de la déclaration des ressources.
Ce qui suit est la configuration minimale :
Directives et valeurs Explications
usage-count yes; Statistiques sur l’usage des versions collectées par le projet DRBD. Un serveur web est contacté à chaque fois qu’une nouvelle version de DRBD est installée sur un serveur.
protocol C; C'est le protocole le plus sécurisé : les opérations d'écriture en local sur le nœud principal sont considérées comme achevées lorsque que les écritures sur les 2 partitions ont été confirmées.
syncer { rate 650M; } Débit entre les différends nœuds (650M est le maximum).
Si le réseau n'est pas dédié, le projet DRBD recommande de mettre le débit à 1/3 de la bande passante1.
Le déclaration des ressources : fichier /etc/drbd.d/ftp.res (à créer sur chaque serveur)
Directives et valeurs Explications
resource resftp { device /dev/drbd0*;
disk /dev/sda5;
meta-disk internal**;
on intralabAR {
address 10.22.100.212:7789;
}
on hdintralabAR {
address 10.22.100.215:7789;
} }
Définition de la ressource « resftp » DRBD va créer un disque virtuel...
… Qui sera monté sur le disque physique /dev/sda5
Gestion des méta-données (ici, enregistrés sur le même disque)*
Déclaration du premier nœud (adresse IP et port)
Déclaration du deuxième nœud (adresse IP et port)
* le block device est conventionnellement nommée /dev/drbdX, ou X est le numéro de périphérique mineur. Si une autre ressource (correspondante à une autre partition) est créé, le « device » sera /dev/drbd1.
** : une autre configuration possible (recommandée par DRBD) est d'externaliser les méta-données sur une autre partition ; il faut préciser dans ce cas la partition et l'emplacement des données dans la partition, par exemple meta-disk /dev/sda6[0).
Dans ce cas, la partition qui contient les données peut être formatée normalement ou laissé e telle quelle si elle contient déjà les données utiles.
Étape 2 : initialisation des méta-données sur la partition qui va contenir les données
Initialisation des méta-données sur chaque nœud : drbdadm create-md resftp
Plusieurs cas peuvent se présenter : Cas N°1
La partition vient d'être créée et n'est pas formatée. La commande devrait fonctionner sans problème et renvoyer le résultat suivant :
Writing meta data...
initializing activity log NOT initialized bitmap
1 Il est recommandé d'utiliser une connexion dédié pour DRBD mais, par mesure de simplification, nous n'allons pas le faire dans ce Coté Labo.
New drbd meta data block successfully created.
success Cas N°2
La partition a déjà été formatée (éventuellement des données sont écrites). Dans ce cas, vous devriez avoir le message d'erreur ci-dessous :
you are the 1012th user to install this version md_offset 2600464384
al_offset 2600431616 bm_offset 2600349696 Found ext3 filesystem
2539520 kB data area apparently used
2539404 kB left usable by current configuration Device size would be truncated, which
would corrupt data and result in 'access beyond end of device' errors.
You need to either
* use external meta data (recommended) * shrink that filesystem first
* zero out the device (destroy the filesystem) Operation refused.
Command 'drbdmeta 0 v08 /dev/sda2 internal create-md' terminated with exit code 40 drbdadm create-md r0: exited with code 40
Il est nécessaire de détruire le système de fichier. Pour cela : Sur le nœud maître :
● sauvegarder (dans /root par exemple), droits sur les objets compris, le contenu de la partition s'il s'agit de la partition qui contient les données (et que des données utiles sont déjà dessus).
● démonter la partition : umount /dev/sda2 ;
● détruire le système de fichier : shred -zvf -n 1 /dev/sda2 ;
● exécuter la commande drbdadm create-md resftp qui doit maintenant fonctionner.
Sur le nœud esclave, même s'il s'agit d'une partition qui contient les données, il n'est pas besoin d'une quelconque sauvegarde puisque les données vont être répliquées à partir du maître ; il suffit de :
● Démonter la partition : umount /dev/sda2.
● Détruire le système de fichier : shred -zvf -n 1 /dev/sda2
● Exécuter la commande drbdadm create-md resftp
Étape 3 : première synchronisation
Il faut activer la ressource avec la commande drbdadm up resftp qui regroupe les trois commandes suivantes :
• drbdadm attach resftp (associe la ressource DRBD à son périphérique) ;
• drbdadm syncer resftp (ajuste les paramètres de synchronisation pour cette ressource) ;
• drbdadm connect resftp (connecte la ressource) ;
Le statut de DRBD : root@intralabAR:~# cat /proc/drbd affiche alors : version: 8.3.11 (api:88/proto:86-96)
srcversion: F937DCB2E5D83C6CCE4A6C9
0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r--- ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:2539404
La ressource, « 0 » pour drbd0, est connectée (cs:Connected) et les 2 nœuds ont été trouvés. Aucun des nœuds n'est maître (ro :Secondary/Secondary : le premier Secondary représente le nœud sur lequel la commande est exécutée). ds:Inconsistent/Inconsistent indique le statut des disques et est l'état normal à ce stade (aucune synchronisation n'a encore été réalisée).
Sur le nœud maître, il faut lancer la première synchronisation :
root@intralabAR:~# drbdadm -- --overwrite-data-of-peer primary resftp Le statut a changé :
root@intralabAR:~# cat /proc/drbd ...
0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---
ns:202232 nr:0 dw:0 dr:210976 al:0 bm:12 lo:1 pe:5 ua:64 ap:0 ep:1 wo:f oos:2047360 [>...] sync'ed: 9.3% (2047360/2248960)K
finish: 0:00:30 speed: 67,200 (67,200) K/sec
La ressource est en train de se synchroniser (cs:SyncSource) à partir du nœud sur lequel a été lancé la commande qui est en « Primary ». Le statut du disque du nœud secondaire « Inconsistent » est normal tant que la synchronisation n'est pas terminée.
Remarque : les chiffres indiqués ne sont pas très représentatifs de ce que l'on peut obtenir avec des disques réels (tous ces tests sont fait à partir d’une machine virtuelle).
Une fois la synchronisation terminée, le statut de DRBD doit être le suivant : root@intralabAR:~# cat /proc/drbd
...
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r---
ns:2248960 nr:0 dw:0 dr:2249966 al:0 bm:138 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
La commande /etc/init.d/drbd status (ou service drbd status) affiche en plus le point de montage et le système de fichier (ici, le disque virtuel n'a pas encore été formaté)
drbd driver loaded OK; device status:
...
m:res cs ro ds p mounted fstype 0:resftp Connected Primary/Secondary UpToDate/UpToDate C
Étape 4 : formatage et montage de la partition sur le nœud primaire
Sur le nœud primaire, il est nécessaire de formater le disque virtuel.
Le disque à formater n'est pas /dev/sda5 mais /dev/drbd0 : root@intralabAR:~# mkfs.ext4 /dev/drbd0
mke2fs 1.42.5 (29-Jul-2012) Étiquette de système de fichiers=
Type de système d'exploitation : Linux Taille de bloc=4096 (log=2)
Taille de fragment=4096 (log=2) ...
Écriture des tables d'i-noeuds : complété Création du journal (16384 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de fichiers : complété
Il est nécessaire ensuite de monter la partition (le but ici est de synchroniser les « /home ») : Le montage se fera donc sous /home et doit utiliser /dev/drbd0
root@intralabAR:~# mount /dev/drbd0 /home/
« /home » est peut-être déjà monté automatiquement au démarrage via une ligne dans le fichier /etc/fstab, auquel cas il faut supprimer (ou commenter) cette ligne.
La commande /etc/init.d/drbd status affiche maintenant : drbd driver loaded OK; device status:
... m:res cs ro ds p mounted fstype 0:resftp Connected Primary/Secondary UpToDate/UpToDate C /home ext4
Il ne reste plus qu'à restaurer les données préalablement sauvegardées et le serveur FTP devrait être de nouveau opérationnel.
Tester la synchronisation
Par défaut, DRBD fonctionne en mode Primary/Secondary. Ceci signifie que l'un des disques supporte les lectures et écritures (sur le nœud primaire), mais que le second n'accepte que les opérations en lecture.
Pour pouvoir tester la synchronisation, il est nécessaire sur le nœud primaire de :
● démonter la partition : umount /dev/drdb0 ;
● changer le statut de la ressource pour « secondaire » : drbdadm secondary resftp ; Et sur le nœud secondaire :
● changer le statut de la ressource pour « primaire » : drbdadm primary resftp ;
● monter la partition : mount /dev/drdb0 /home
Vous devriez retrouvez les données restaurées dans /home... et vous pouvez y créer un fichier pour vérifer qu'après l'opération inverse, celui-ci se retrouve bien sur le nœud primaire.
Il est possible d'obtenir des disques répliqués en mode primary/primary. Cela signifie que les 2 disques supportent les écritures en simultanée. Mais il faut pour cela un système de fichiers qui le supporte comme OCFS2 ou GFS.
Le split brain
Un split brain se produit lorsque deux parties d'un cluster d'ordinateurs sont déconnectées, chaque partie croyant que l'autre ne fonctionne plus. Le terme est une analogie médicale du syndrome split- brain (littéralement « dédoublement du cerveau ») (source : http://fr.wikipedia.org/wiki/Split-brain).
Chaque nœud va alors démarrer les services (les deux nœuds se déclarent primary), ce qui va éventuellement provoquer une incohérence des données quand les différents nœuds montent et écrivent sur un système de fichiers de façon concurrente.
DRBD va détecter les deux primary au moment où la connectivité entre les deux nœuds est rétablie : le démon stoppe alors la connexion et arrête la réplication, ce qui est visible dans les logs :
Split-Brain detected, dropping connection!
Il est possible de configurer DRBD pour reprendre la main automatiquement et décider quelles données garder (instructions after-sb-*pri dans la section net) mais il est préférable d'intervenir manuellement afin d'estimer les « dégâts » et décider quel est le nœud dont les données sont les plus actuelles et quel est le nœud dont les données doivent être discréditées.
Comment éviter le split brain
● Assurer au maximum la liaison entre les éléments du cluster : on peut utiliser deux liens réseau différents ou faire du bonding – agrégation de liens.
● S’assurer que l’autre nœud est inactif : le Stonith : « Shoot The Other Node In The Head » est une méthode d’isolation d’un nœud qui ne répond plus. Le nœud jugé hors service sera donc, en général, arrêté électriquement (via IPMI – Interface de Gestion Intelligente du Matériel par exemple). Nous ne le mettrons pas en œuvre dans ce Coté Labo mais ceci est indispensable en production.
Comment résoudre le split brain ?
Il faut supprimer les données sur le nœud le moins actif et resynchroniser. En règle générale les commandes suivantes suffisent :
Sur les deux nœuds : umount /dev/drbd0 et drbdadm disconnect resftp
Sur le nœud le moins actif : drbdadm secondary resftp et drbdadm -- --discard-my-data connect resftp Sur le nœud à partir duquel on réplique les données : drbdadm connect resftp
À la fin de la synchronisation on monte DRBD : mount /dev/drbd0 /home
Annexe 2 : intégration du service FTP dans le cluster
L'intégration du service FTP revient de facto à intégrer aussi le service DRBD. Les principes de l’intégration sont sont les suivants :
● Une ressource pour chacun de ces services doit être créée.
● Ces services doivent être démarrés par Pacemaker ==> il faut les sortir du démarrage du système.
● Le service DRBD doit démarrer sur les deux nœuds mais avec un rôle différent (primary/secondary – voir Rappel ci-dessous) avec une préférence en tant que primaire pour le nœud « intralab » .
● Lorsque le service DRBD démarre sur le nœud qui joue le rôle de maître, ce dernier doit être en primary et monter le disque virtuel sur /home ==> il faut déclarer une nouvelle ressource de type « système de fichier » (ocf:heartbeat:Filesystem).
● Le service DRDB doit démarrer avant celui de FTP.
La ressource DRBD doit donc être configurée en mode actif/actif avec la fonction “clone” qui, rappelons-le, admet 3 types :
• Le clone « anonymous » (clone par défaut) : les ressources sont configurées de manière identique sur chaque nœud. Si un nœud est indisponible, il n’y a pas de bascule de cette ressource puisqu’elle est déjà fonctionnelle et identique sur l’autre nœud.
• Le clone « globally-unique=true » : contrairement au cas précédent, les ressources ne sont pas identiques d’un nœud à l’autre. Elles peuvent par exemple, avoir des données différentes.
• Le « multi-state » : c’est une ressource qui peut être dans 2 états différents : « master » ou
« slave ». C'est ce type de clone que nous allons utiliser.
Création et configuration des ressources DRBD et Système de fichiers
Il est préférable que les commandes qui suivent soient validées/activées en même temps car elles sont étroitement liées. On travaille donc en mode « live »
root@intralabAR:~# crm configure
On crée tout d'abord une ressource appelée drbd0 qui démarrera sur le maître et, sur l'esclave, la ressource resftp (définie dans le fichier /etc/drbd.d/ftp.res) :
crm(live)configure# primitive drbd0 ocf:heartbeat:drbd params drbd_resource=resftp op monitor role=Master interval=60s timeout=30s op monitor role=Slave interval=60s timeout=30s
La primitive ressource nommée drbd0 est intégrée ici dans un objet plus complexe "ms" (pour master- slave) nommé ms-drbd0 :
crm(live)configure# ms ms-drbd0 drbd0 meta clone-max=2 clone-node-max=1 master-max=1 master- node-max=1 globally-unique=false notify=true
Explication :
● clone-max=2 : il ne peut y avoir que 2 ressources démarrées en même temps (= nombre de nœuds) ;
● clone-node-max=1 : une ressource par nœud au maximum ;
● master-max=1 : une seule ressource peut être activée en tant que maître ;
● master-node-max=1 : une seule ressource sur le même nœud ;
● globally-unique=false : les ressources sont identiques d'un nœud à l'autre ;
● notify=true : le cluster informe les nœuds du changement d’état de chacune des ressources.
On configure ensuite une ressource fs0 qui permet de monter le système de fichiers qui contiendra les données partagées :
crm(live)configure# primitive fs0 ocf:heartbeat:Filesystem params fstype=ext4 directory=/home device=/dev/drbd0
Il est nécessaire maintenant de gérer l'exécution des ressources (préférence d'exécution, ordre dans lequel les ressources seront exécutées, etc). En effet, comme nous l'avons déjà observé, si les ressources ne sont pas groupées, elles vont être activées sur des nœuds différents de manière à optimiser le cluster.
Une alternative à la commande group (vue dans le précédent Côté Labo) est l'utilisation les contraintes colocation et order : le principe est le même, on va lier des ressources entre elles et créer un ordre de démarrage mais ces deux commandes permettent une gestion beaucoup plus fine des contraintes.
Trois types de contraintes sont disponibles :
● contrainte locative avec la commande location : définit une préférence ou une obligation d’exécution d’une ressource sur un nœud (c'est ce type de contrainte qui est écrite automatiquement lorsque l'on migre une ressource sur un nœud – voir précédent Côté Labo) ;
● contrainte colocative avec la commande colocation : oblige une ressource à fonctionner (ou pas) sur le même nœud qu'une autre ressource (l’obligation peut être une interdiction suivant la valeur de la pondération – voir ci-après) ;
● contrainte d’ordre avec la commande order : ordonnance le démarrage et arrêt des ressources.
La syntaxe générale des commandes est la suivante :
location <id_contrainte> <id_ressource> [rule role=rôle] <score>: #uname eq <noeud>
colocation <id_contrainte> <score> : <id_ressource_dependante[ :rôle]>
<id_ressource_necessaire[:rôle]>
order <id_contrainte> <score> : <id_ressource1 :action1> <id_ressource2 :action2>
Avec
Rôle : started, slave ou master
action : start, stop, promote, demote (l'action1 est à réaliser sur la ressource 1 avant de réaliser l'action2 sur la ressource2)
Le cluster prend en compte les préférences d’exécution sur un nœud ou l’autre suivant un mécanisme de pondération des ressources (score). Le score peut avoir une valeur positive ou négative :
● + l'infini (ou mandatory) : avec location, obligation d’exécution de la ressource sur le nœud (valeur notée « inf » dans les commandes) et avec colocation, obligation d'exécution des ressources ensemble.
● Valeur comprise entre 0 et + l’infini : préférence d’exécution de la ressource
● Valeur comprise entre - l’infini et 0 : préférence de non-exécution de la ressource
● Valeur = 0 correspond au mot clé advisory
● - l'infinie : avec location, interdiction d’exécution de la ressource sur le nœud (valeur notée « - inf » dans les commandes)
Il est possible de connaître la syntaxe d'une commande via la commande : crm configure help nom_commande (par exemple crm configure help order)
On déclare que ms-drbd0 sera exécutée préférentiellement en tant que maître sur intralabar (avec un score égal à 100) :
crm(live)configure# location ms-drbd0-master-on-intralabar ms-drbd0 rule role=master 100: #uname eq intralabar
Dans un cluster à deux nœuds une valeur de pondération (score) comprise entre 0 et + l’infini (ici « 100 » choisi arbitrairement) est équivalente à la valeur « inf ». La donne change à partir de 3 nœuds car on pourra préférer créer un ordre priorité pour chacun de nœuds (par exemple par rapport aux capacités physiques des serveurs).
Le système de fichiers doit être monté sur le nœud où la ressource ms-drbd0 est lancé en tant que maître, et seulement après que drbd0 ait été promu maître :
crm(live)configure# colocation fs0-on-ms-drbd0 inf: fs0 ms-drbd0:Master
La commande colocation permet donc de forcer deux (ou plus) ressources à cohabiter sur le même nœud : ici, fs0 et ms-drbd0 quand il est lancé en maître.
Contrairement à la commande group, cette dernière contrainte ne définit pas d’ordre de démarrage (et d’arrêt) des ressources. Il faut lui adjoindre la commande order.
Le système de fichiers doit être monté après que ms-drbd0 ait été promu maître : crm(live)configure# order ms-drbd0-before-fs0 mandatory: ms-drbd0:promote fs0:start
La commande order permet donc de définir un ordre dans les ressources. Ici, fs0 n'est démarré qu'une fois que la ressource ms-drbd0 est promue maître.
Les commandes colocation et order peuvent encore être affinées avec l'usage des parenthèses pour les ressources qui n'ont pas de liens entre elles.
Par exemple :
colocation id inf:(A B) C
Les ressources A et B sont indépendantes.
L'arrêt de la ressource A ou celle de la ressource B n’impactera pas la ressource C
Pour que le ressource C s'arrête et migre avec A et/ou B, il est nécessaire que les ressources A et B s'arrêtent simultanément. Par contre, si la ressource C s'arrête, les ressources A et B seront coupées.
order id inf:(A B) C
Les ressources A et B peuvent démarrer en parallèle et C démarrera après le démarrage d'une des deux ressources.
Si aucune ligne n'a renvoyé d'erreurs, on peut valider : crm(live)configure# commit
crm_mon :
============
Last updated: Mon Aug 9 14:07:28 2013
Last change: Mon Aug 9 14:07:25 2013 via crmd on intralabar Stack: Heartbeat
Current DC: hdintralabar (d990204c-2de3-40c5-8f8d-4469d01aafb3) - partition with quorum Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, unknown expected votes 7 Resources configured.
============
Online: [ intralabar hdintralabar ] Resource Group: servIntralab
IPFailover (ocf::heartbeat:IPaddr2): Started intralabar serviceWeb (ocf::heartbeat:apache): Started intralabar Clone Set: cServiceMySQL [serviceMySQL]
Started: [ hdintralabar intralabar ] Master/Slave Set: ms-drbd0 [drbd0]
Masters: [ intralabar ] Slaves: [ hdintralabar ]
fs0 (ocf::heartbeat:Filesystem): Started intralabar
Création de la ressource relative au service FTP
La création de la ressource relative au service FTP ne devrait pas poser de problèmes si l'on prête attention au fait que :
➔ le chemin par défaut prévu dans le script ocf vers le fichier de configuration n'est pas correct (crm ra info ocf:heartbeat:proftpd) ;
➔ Il est préférable de rallonger les timeout à 40 s de démarrage et d'arrêt qui sont, par défaut, courts (20 s) (si on laisse le fichier de configuration par défaut, le démarrage de FTP prend plus de 20 secondes : en laissant le timeout par défaut, le système se met en erreur car il considérera que FTP ne peut être démarré sur aucun des nœuds)
La ressource FTP ne devra être activée que sur le nœud sur lequel DRBD est lancé en tant que maître et après que le système de fichier ne soit monté.
Annexe 3 : récapitulatif des commandes courantes
Vérifier que Heartbeat est lancé : /etc/init.d/heartbeat status
Vérifier que Heartbeat est actif : cl_status hbstatus
Voir la liste des noeuds : cl_status listnodes
Voir l'état d’un noeud : cl_status nodestatus nom_node
Accéder à l'interface de configuration du cluster : crm
crm(live)# help
This is the CRM command line interface program.
Available commands:
cib manage shadow CIBs resource resources management node nodes management options user preferences
configure CRM cluster configuration
ra resource agents information center status show cluster status
quit,bye,exit exit the program help show help
end,cd,up go back one level
Si on saisit crm(live)# nom_commande help, on a les différentes possibilités d'arguments après la commande et ainsi de suite...
Éditer/Modifier une configuration crm configure edit
cela vous placera dans une instance de « vim » pour effectuer une modification qui sera appliquée à la sauvegarde.
Éditer/Modifier directement une ressource crm configure edit <id_ressource>
cela vous placera dans une instance de « vim » pour effectuer une modification qui sera appliquée à la sauvegarde.
Modifier la configuration du cluster en entrant directement dans le mode de configuration : crm configure
Voir la configuration crm(config)configure# show Équivalent de crm configure show Vérifier sa configuration
crm(config)configure# verify Équivalent de crm configure verify
Stopper une ressource
crm resource stop <id_ressource>
Démarrer une ressource
crm resource start <id_ressource>
Supprimer une ressource
crm configure delete <id_ressource>
Si la ressource est en cours d'utilisation, il vaut mieux la stopper avant de la supprimer.
Déplacer une ressource
crm resource move <id_ressource> <noeud>
Annuler le déplacement
crm resource unmove <id_ressource>
Préférence du noeud
crm configure location <nouvel_id_ressource> <id_ressource> <score>: <nœud>
La ressource <id_ressource> préférera tourner sur le nœud <nœud>.
Liste des ressources OCF crm ra list ocf heartbeat
Connaître la liste complète des paramètres d’une primitive, crm ra info ocf:heartbeat:nom_primitive.
Vous obtenez la liste des timeout par défaut, des paramètres et de leurs valeurs par défaut, les paramètres obligatoires et facultatifs.
Mettre un poste en maintenance crm node standby [<noeud>]
Sortir un poste de maintenance crm node online [<noeud>]
Effacer les erreurs sur une ressource crm resource cleanup <id_resource>
Cloner une ressource (de type « anonymous ») crm configure clone <nom_clone> <id_resource>
Sauvegarder une configuration crm configure save /root/sauveha.conf
crm configure save xml /root/sauveha.conf.xml # Version XML Restaurer une configuration (et remplacer la configuration actuelle) crm configure load replace /root/sauveha.conf
Mettre à jour une configuration
crm configure load update /root/sauveha.conf
