Haute disponibilité d`un serveur FTP

Transcription

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 :
•
•
•
•
SISR4 :
•
•
•
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
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 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
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
http://www.reseaucerta.org
© CERTA - septembre 2013 – v1.0
Page 1/17
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/htmlsingle/Pacemaker_Explained/index.html
Site officiel de DRBD : /www.drbd.org/ et plus
http://www.drbd.org/users-guide-8.3/
particulièrement
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.
Page 2/17
Les données sont stockées sur un serveur « à part » (un serveur NAS par exemple) :
Les fichiers sont accessibles par
chaque serveur. Les disques sont
éventuellement en RAID.
Serveur maître
Lien HA
Serveur esclave
hearbeat+pacemaker
+service FTP
hearbeat+pacemaker
+service FTP
IP virtuelle
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 :
Serveur maître
IP : 10.22.100.212
Partition 1 : syst + appli
Partition 2 : données
Serveur esclave
IP : 10.22.100.215
Partition 1 : syst + appli
Partition 2 : données
IP virtuelle
10.22.100.220
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.
Page 3/17
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.
Page 4/17
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
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
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
Page 5/17
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 <[email protected]>, Lars Ellenberg <[email protected]>
srcversion: F937DCB2E5D83C6CCE4A6C9
….
Et la commande cat /proc/drbd doit renvoyer (avant configuration) :
version: 8.3.11 (api:88/proto:86-96)
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
Page 6/17
➔ /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
usage-count yes;
Explications
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.
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.
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.
protocol C;
syncer { rate 650M; }
Le déclaration des ressources : fichier /etc/drbd.d/ftp.res (à créer sur chaque serveur)
Directives et valeurs
resource resftp {
device /dev/drbd0*;
disk /dev/sda5;
meta-disk internal**;
on intralabAR {
address 10.22.100.212:7789;
}
Explications
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)
on hdintralabAR {
address 10.22.100.215:7789;
}
}
* 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.
Page 7/17
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)
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).
Page 8/17
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
0:resftp Connected Primary/Secondary UpToDate/UpToDate
mounted
C
/home
fstype
ext4
Page 9/17
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 splitbrain (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
Page 10/17
Page 11/17
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 masterslave) nommé ms-drbd0 :
crm(live)configure# ms ms-drbd0 drbd0 meta clone-max=2 clone-node-max=1 master-max=1 masternode-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
Page 12/17
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>
<id_ressource_necessaire[:rôle]>
<score> :
<id_ressource_dependante[ :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).
Page 13/17
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
Page 14/17
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é.
Page 15/17
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
resource
node
options
configure
ra
status
quit,bye,exit
help
end,cd,up
manage shadow CIBs
resources management
nodes management
user preferences
CRM cluster configuration
resource agents information center
show cluster status
exit the program
show help
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
Page 16/17
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
Page 17/17

Haute disponibilité d`un serveur FTP

Transcription

Documents pareils

Solution Haute Disponibilité pour Linux : Un cluster

Les solutions se multiplient pour les TPE

Comment faire son nœud de ceinture de Kimono de Judo

Monde Informatique (LMI) (L`) N° 1089 - 04/11/05

Prusik Instructions

Chapitre 1

2013_ANNONCE_VIE_Marketing Télémarketing

lire la suite

télécharger - Dauphine Alumni

Lead Nurturing - dirheimer.net

La relation commerciale