![[Photo of the Author]](../../common/images/Atif-Ghaffar.jpg)
original in en Atif Ghaffar
en to fr Cyrille Morineaux
Atif est un caméléon. Il change de rôle, passant d'Administrateur Système,
à programmeur, professeur, chef de projet, ou quoi que ce soit d'autre
permettant l'aboutissement d'un travail.
Atif pense qu'il doit beaucoup à Linux, à la communauté du logiciel libre et à ses
projets pour lui avoir servi de professeur.
Pour en savoir plus, consultez sa page personnelle
![[Illustration]](../../common/images/tuxmirror.gif)
Les serveurs de fichiers ne sont-ils pas là pour rendre les données accessibles aux clients ?
Bien sûr que oui.
Si nous utilisons un serveur de fichier qui partage les fichiers par NFS ou SMB
etc, alors nous avons un goulot d'étranglement et un Unique Point de Défaillance.
Si nous partageons les données par GFS avec un stockage partagé (SAN ou SCSI
multi-canaux), la zone de stockage devient Unique Point de Défaillance mais
il est tres coûteux d'installer une telle configuration.
Nous pouvons utiliser NBD (Network Block Devices) pour créer un réseau en miroir,
mais je ne suis pas très à l'aise avec ce genre de configuration. Les NBD ont
leurs limites, sont difficiles a paramétrer et à gérer et un peu trop lourds quand
votre seul besoin est la réplication de données de quelques serveurs web sur
d'autres serveurs web.
Bon, essayons la réplication.
Voici un premier scénario
Vous disposez de 2 serveurs web: un serveur principal et un autre de secours.
Vous faites toutes vos modifications sur la machine principale puis les appliquez sur la deuxième machine via rsync.
Simple ?
Mais comment l'automatiser? Vos utilisateurs accèderont plusieurs fois par jours à
la machine maître par FTP. Que se passera t-il si celle-ci tombe en panne et que le
serveur de secours prenne le relais ?
Facile: j'ai la réponse. Ils ne verront pas les modifications qu'ils ont faites précédemment,
et seront très fâchés. :)
Bon, vous pouvez exécuter "rsync -av --delete source destination" via CRON toutes
les 5 secondes, mais alors votre machine ne sera plus vraiment utilisable pour
quoi que ce soit d'autre , n'est-il pas ?
Voici un autre scénario
Vous avez un serveur FTP pour charger les données et
six serveurs web qui répondent alternativement, à la mode round robin.
Ainsi les données de chaque machine devraient être identiques. Vous pouvez
toujours utiliser NFS pendant quelques temps...si vous êtes chanceux , mais cela ne durera pas.
Alors que faire?
Je pense que la réponse est de "copier les données sur les serveurs uniquement s'il y a
une modification des fichiers", et s'il n'y a aucune modification alors ne rien faire.
C'est exactement ce que nous ferons avec "fam".
Alors comment savoir qu'il y a eu des modifications sur des fichiers?
Voici une réponse que je pourrais obtenir d'un développeur M$ Windows.
Nous pouvons rechercher les fichiers toutes les x secondes dans le répertoire
concerné et comparer la taille et l'heure de ces fichiers avec la version que nous avons dans le cache.
Bravo
Sondage: analyser les tailles/heures des fichiers et comparer le résultat
avec l'ancienne version est très coûteux.
Imaginez si vous devez exécuter un "ls -lR /unrépertoire" toutes les 5 secondes sur votre serveur web :)
La manière élégante serait que le fichier nous informe de sa modification, nous
permettant ainsi d'agir.
C'est exactement ce que fera "IMON" pour nous.
source: http://oss.sgi.com/projects/fam/faq.html
fam, le Moniteur d'Altération de Fichier, fournit une API que les applications
peuvent utiliser pour être informées de chaque modification de fichiers ou de répertoires.
FAM se décompose en deux parties: fam, le démon qui est à l'écoute des requêtes
et fournit les informations, et libfam, une bibliothèque que les applications clientes
utilisent pour dialoguer avec FAM.
Si les fichiers analysés sont situés sur un hôte distant, le fam local essaiera
de contacter le fam distant, et lui communiquera les requêtes qui lui ont été adressées.
fam peut également informer ses clients du début et de la fin de l'exécution d'un fichier.
(Le bureau interactif d'IRIX utilise cette fonctionnalité pour modifier l'icône d'un programme lorsqu'il
s'exécute par exemple.)
fam a été développé à l'origine pour IRIX en 1989 par Bruce Karsh, et a été réécrit
en 1995 par Bob Miller. Cette version open-source de fam fonctionne aussi bien sous
Linux que sous IRIX, et sera d'ailleurs livrée avec IRIX 6.5.8.
source: http://oss.sgi.com/projects/fam/faq.html
imon, le Moniteur Inode, est la partie du noyau qui informe fam lorsque
des fichiers ont été modifiés. Quand des applications informent fam qu'elles sont intéressées par des fichiers
ou des répertoires, fam le signale à imon. Lors de modifications des fichiers
surveillés par imon, le noyau en informe imon, qui informe fam et qui remonte à son tour l'information aux applications qui lui en ont
fait la demande.
imon a été développé pour le noyau d'IRIX en 1989 par Wiltse Carpenter;
le portage Linux a été réalisé par Roger Chickering. L'implémentation Linux dans
le correctif du noyau pour imon, est semblable à celle
d'IRIX sauf pour ce qui concerne la manière dont elle s'intègre dans le code du
système de fichiers.
FAM et IMON sont accessibles sur le site web de SGI. Voir la section Ressources ci-dessous.
IMON est un correctif applicable à votre noyau. Cela ajoutera a votre noyau la
possibilite de surveiller les Inodes.
Pour modifier le noyau, placez-vous dans le répertoire contenant les sources du
noyau.
et appliquez le correctif
cd /usr/src/linux
patch -pi < patchfile
puis exécutez make config ou make menuconfig et
quand on vous le demandera sélectionnez
Inode Monitor (imon) support (EXPERIMENTAL)
dans la section FileSystems
compilez le kernel comme d'habitude et redémarrez (désolé).
La compilation de FAM est très simple.
se positionner dans le répertoire contenant les sources de fam et exécuter
./configure && make all install
Voilà, c'est terminé.
Ensuite nous installerons un module Perl nommé SGI::FAM, ainsi pourrons-nous
écrire notre propre gestionnaire d'évènement en Perl.
Vous n'avez pas vraiment cru que je vous demanderais de programmer en C/C++.
N'est-ce pas ?
Bon je ne sais pas pour vous, mais je suis un peu paresseux et impatient, alors j'écrirai le gestionnaire en Perl
Téléchargez et installez SGI::FAM de Jesse N. Glick
Pour installer ces modules, exécutez simplement le module CPAN
perl -MCPAN -e shell
install SGI::FAM
cela devrait installer SGI::FAM et tous les modules pré-requis.
fam_mirror est un script que j'ai écrit pour automatiser la réplication.
Pour le visualiser
ou le télécharger.
Vous pouvez l'éditer et
modifier $replicaHosts en fonction de vos besoins,
modifiez $rsh par la commande qui vous convient
et faites de même avec $rsync.
Revenons au scenario 1
2 machines fonctionnent comme serveurs web (web1, web2). L'une étant le
maître (web1) et l'autre l'esclave (web2).
Le serveur FTP primaire est (web1).
web2 ne fait fonctionner aucun service FTP. (sinon les utilisateurs
pourraient essayer d'écrire dans des fichiers même quand la machine est en
mode sauvegarde)
La racine des documents web est /var/www sur les deux machines
configurez rsh ou ssh sur les deux machines. web2 doit permettre à web1
d'exécuter des commandes à distance sans lui demander de mot de passe.
Habituellement, j'ajoute ma clé ssh_key au fichier authorized_keys des
hôtes de réplication.
rsync toutes les données de web1 a web2
rsync -avz /var/www/ web2:/var/www/
Editez fam_mirror et remplacez @replicaHosts par
@replicaHosts=qw(web2)
exécutez fam_mirror sur web1.
fam_mirror /var/www &
puis modifiez quelques fichiers sur web1. Tous les changements doivent
maintenant figurer sur web2.
Maintenant au tour du scenario 2 (Une ferme de serveurs web)
Les machines "linuxweb1", "linuxweb2", "linuxweb3" et "linuxweb4" sont des serveurs web
L'hôte "linuxftp1" fonctionne comme serveur ftp (serveur de fichier principal)
Les hôtes web ne permettent pas le FTP aux utilisateurs.
Installez fam, imon, SGI::FAM et fam_mirror sur l'hôte "linuxftp1"
Configurez rsh ou ssh entre les machines.
Les hôtes linuxweb[1-4] doivent permettre à linuxftp1 d'exécuter des
commandes distantes sans réclamer de mot de passe.
Editez fam_mirror et définissez le champ @replicaHosts comme suit
@replicaHosts=qw(linuxweb1 linuxweb2 linuxweb3 linuxweb4);
Modifiez $rsh et $rsync si nécessaire.
Si la racine des documents web est /var/www sur toutes les machines.
exécutez sur linuxftp1
INIT_MIRROR=1 fam_mirror /var/www &
Maintenant toutes les modifications sur linuxftp1 doivent être visibles sur linuxweb[1-4]