[LinuxFocus-icon]
Sommaire  |  Carte  |  Index  |  Recherche

Nouvelles | Archives | Liens | A propos
Ce document est disponible en: English  Castellano  Deutsch  Francais  Nederlands  Turkce  

convert to palmConvert to GutenPalm
or to PalmDoc

[Photo of the Author]
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.
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



Traduit en Franšais par:
Cyrille Morineaux <cyrillem(at)free.fr>

Sommaire:

 

La réplication de données en temps réel sous Linux

[Illustration]

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.



 

Pourquoi répliquer au lieu de partager ?

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.

 

Faire simple

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".  

Faire élégant

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.

 

Qu'est-ce que FAM?

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.  

Qu'est-ce que IMON?

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.

 

Installation de FAM et IMON

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.

 

Installation du module Perl SGI::FAM

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.  

Réplication avec fam_mirror

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]

 

Ressources

 

Problèmes connus

J'ai découvert que la solution présentée ici possède un petit inconvénient: cela ne fonctionne pas avec de grandes arborescences de répertoires. (répertoires avec 4 à 5000 sous-répertoires). Le noyau se plaint de kmalloc etc.
J'essaie actuellement de comprendre. Dès que tout cela sera résolu, cet article sera mis a jour.
Si vous connaissez une solution à ce problème, n'hésitez pas à me contacter.  

Discussion sur cet article

Chaque article possède sa page de discussion. Vous pouvez y soumettre un commentaire ou lire ceux d´autres lecteurs:
 page de discussion 

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:
en --> -- : Atif Ghaffar <atif(at)developer.ch>
en --> fr: Cyrille Morineaux <cyrillem(at)free.fr>

2001-11-29, generated by lfparser version 2.21