Plate- forme d'entreprise sécurisée et de haute disponibilité

III.2 MISE EN HAUTE DISPONIBILITE DES SERVICES CAS :

DES SERVICES FTP ET HTTP

Configuration matérielle et logicielle.

Dans le cadre de ce travail notre cluster FailOver possède deux noeuds distincts : un maître de nom haserver0.creolink.lan et l'autre de secours de nom haserver1.creolink.lan ayant presque les mêmes capacités mémoires et fréquences (pas obligatoire),  tournant sous le système Linux Centos 4.6 de noyau 2.4 qui communiqueront entre eux par une liaison Ethernet privée point à point via la carte Ethernet0 et avec les autres hôtes du réseau par une liaison, point à multipoint en conservant la plage d'adresse 172.16.0.0/16. La voie de communication privée peut utiliser un support de connexion série qui paraît plus stable.

.

Figure 1 Architecture de test

Les deux noeuds de notre cluster FailOver auront un support logiciel constitué de: Heartbeat, Mon et drbd pour assurer la haute disponibilité des données et des services http et ftp précédemment configurés et actuellement disponibles sur nos noeuds.

III.2.1 INSTALLATION ET CONFIGURATION DE LA PLATE FORME LOGICIELLE

Nous avons installé successivement les paquetages suivants :

a. Heartbeat-pils :

b. Heartbeat-stonith : Il permet d'assure la possession des ressources par un seul hôte.

c. Heartbeat : Assure la prise de pouls.

d. drbd83 : C'est la bibliothèque des scripts drbd

e. kmod-drbd83 : C'est le module permettant au noyau de gérer le périphérique drbd

f. mon : Il permet de surveiller les ressources et déclenche l'alerte selon leur état.

III.2.1.1 Hertbeat

Heartbeat est situé au coeur du processus de fonctionnement d'une solution de haute disponibilité. Il constitue le lien permettant aux deux serveurs de se prendre mutuellement le pouls. Heartbeat vérifie uniquement la «bonne santé» des serveurs, sans se préoccuper des applications qui tournent dessus. Pour ce faire, il faudra le faire interagir avec un outil de monitoring, comme mon. Nous verrons ci-dessous comment réaliser une synchronisation. On peut télécharger les paquetages pour la: Centos à cette adresse :

http://www.ultramonkey.org/download/heartbeat/

III.2.1.1.1 Installation

Nous avons utilisé l'utilitaire d'installation en ligne yum comme suit:

On peut vérifier son installation comme suit :

III.2.1.1.2 Configuration

Heartbeat a besoin de trois fichiers essentiels pour fonctionner : ha.cf qui définit le moyen de communication et les paramètres de base, haresources pour spécifier le noeud où les services vont être lancés au démarrage et authkeys pour sécuriser le processus de communication.

NB Au cas où Hearbeat ne les a pas crées lors de son installation, on les copie depuis /var/lib/hearbeat vers /etc/ha.d/

Le fichier /etc/ha.d/ha.cf

Ce fichier définit les paramètres généraux de Heartbeat. Par défaut toutes les lignes sont marquées avec le symbole "#", nous allons en décommenter certaines.

# Emplacement des messages de debug

debugfile /var/log/ha-debug

# Autres messages

logfile /var/log/ha-log

# Nombre de secondes entre chaque battement

keepalive 2

# Temps avant qu'un noeud soit déclare mort

deadtime 10

#warntime: intervalle de Temps avant utilisation du dernier message d'avertissement

warntime 10

# Very first dead time (initdead)

initdead 10

# Port utilise pour la communication en UDP

udpport 694

# Interface utilisée

bcast eth0

# Récupération automatique des ressources par le serveur maître si celui-ci est à nouveau opérationnel

auto_failback on

# Les noeuds de notre cluster

node hasever0.creolink.lan

node haserver1.creolink.lan

Voilà, il faut maintenant sauver le fichier de configuration et le copier sur le second serveur grâce à la commande scp /etc/ha.d/ha.cf [e-mail]:/etc/ha.d

Tous les autres paramètres sont optionnels pour la simple redondance que nous cherchons à créer.

Le fichier /etc/ha.d/haresources.s

Le deuxième fichier important est haresources. Son rôle est de définir quel est le noeud qui deviendra maître et les services contrôlés par heartbeat. Pour éviter tous conflits, ce fichier doit être identique de chaque côté de notre installation. Nous reviendrons plus tard sur ce fichier lors de la configuration de DRBD. Pour le moment, nous allons tester heartbeat uniquement avec les services Apache httpd et ftp vsftp bien sûr, précédemment configurés sur les deux serveurs.

La ligne à modifier pour une utilisation minimale d'heartbeat est :

haserver0.creolink.lan indique que c'est ce noeud qui est maître

IPaddr indique le script permettant de récupérer l'adresse du service sous forme d'alias eth0 

Httpd et vsftpd sont respectivement les scripts de démarrages d'apache (service web) et du service FTP et doivent être déplacés du répertoire /etc/rc.d/init.d vers /etc/ha.d/resources afin que heartbeat puisse les trouver et les exécuter.

Le fichier /etc/ha.d/authekeys

Le troisième fichier à configurer est utilisé pour sécuriser la communication entre les deux noeuds. Un échange de clé d'authentification est effectué à chaque fois que la connexion est établie. Trois modes d'authentification sont disponibles : crc, md5 and sha1. Les deux derniers nécessitent un mot de passe qui leur confère une plus grande robustesse.

Considérant les ressources CPU à mettre à disposition pour le sha1, nous avons préféré utiliser le chiffrage crc. Le fichier contient deux lignes, comme suit :

Auth 1

1 crc

Nous allons restreindre les permissions d'accès à ce fichier. En effet L'utilisateur root est le seul à pouvoir le lire et le modifier.

# chmod 600 /etc/had.d/authkeys

Une fois que tout a été configuré et les fichiers copiés sur chacun des noeuds, nous pouvons démarrer le service Heartbeat, d'abord sur la machine haserver0 puis sur haserver1 :

#/etc/init.d/heartbeat start

Test de bon fonctionnement

La ligne de commande /etc/init.d/heartbeat start permet de démarrer le serveur heartbeat, pour vérifier que tout se passe bien nous allons exécuter la commande tail -f /var/log/messages pour écouter en temps réels la conversation entre les 2 noeuds. Voici le résultat obtenu sur le noeud de secours haserver1 :

Si nous déconnectons le serveur ou bien stoppons le service heartbeat, sur le serveur haserver0, nous pouvons observer ceci :

haserver1 ne détecte plus le pouls de haserver0 à partir d'une durée de 10s (deadtime) indiquée dans le fichier ha.cf, le déclare comme mort (dead) et récupère l'IP des services grâces au script IPAddr, acquière les ressources http et vsftp et envoi une alerte mail warn à l'administrateur d'adresse [e-mail] via le serveur de mail lui indiquant comme quoi le noeud haserver0 est mort.

Nous savons faire communiquer nos serveurs, nous devons maintenant synchroniser le contenu de notre site web et de notre répertoire ftp. Pour cela, DRBD est un allié efficace.