![[LinuxFocus-icon]](../../common/images/logolftop.gif){kind=small} |
|
|
 |
|
| Cet article est disponible en: English Castellano Deutsch Francais Nederlands Turkce |
![[Photo of the Author]](../../common/images/Atif-Ghaffar.jpg)
par Atif Ghaffar <atif(at)developer.ch> L´auteur: 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. Traduit en Fran�ais par: Cyrille Morineaux <cyrillem(at)free.fr> Sommaire: |
![[Illustration]](../../common/images/tuxmirror.gif)
Résumé:
Dans cet article nous étudierons la réplication de données en temps réel sous Linux
sans utiliser de solution SAN coûteuse (Storage Area Network, Zone de Stockage
Réseau, par exemple GFS) ou d'autres périphériques réseau.
Nous utiliserons FAM et IMON pour notre système de réplication.
FAM (File Alteration Monitor) et IMON (Inode Monitor) ont tous deux été développé par SGI pour IRIX.
Les gens de SGI ont eu ensuite l'excellente idée de les porter sur Linux et de les
rendre libres.
Si le coût n'est pas un facteur déterminant, j'aurais tendance à choisir une
solution basée sur GFS (Global File System) et SAN, mais
si le coût devient un facteur important,
et que le partage des données est nécessaire, il ne reste que peu de possibilités.
Nous en avons néammoins quelques unes. Dans cet article nous les étudierons et
évoquerons les avantages et inconvénients
de ces différentes solutions.
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]
|
|
Site Web maintenu par l´équipe d´édition LinuxFocus
© Atif Ghaffar, FDL LinuxFocus.org Cliquez ici pour signaler une erreur ou envoyer un commentaire � Linuxfocus |
Translation information:
|
2001-11-29, generated by lfparser version 2.21
