![[Photo of the Author]](../../common/images/Atif-Ghaffar.jpg)
original in en Atif Ghaffar
en to de Katja Socher
Atif ist ein Chamäleon. Er ändert seine Rollen von Systemadministrator zu
Programmierer, Lehrer, Projektmanager, zu was auch immer erforderlich ist, um
die Arbeit getan zu kriegen.
Atif denkt, daß er Linux, der Open Source Gemeinde und Projekten, die seine
Lehrer waren, viel schuldet.
Mehr über ihn kann auf seiner Homepage gefunden werden
![[Illustration]](../../common/images/tuxmirror.gif)
Sollten Fileserver nicht Daten für die Kunden verfügbar machen?
Ja, das sollten sie.
Wenn wir einen Fileserver benutzen, der Dateien über NFS oder SMB etc. teilt,
dann haben wir einen Flaschenhals und einen Single Point Of Failure
(Einzelpunkt des Versagens).
Wenn wir Daten über GFS teilen mit geteilter Speicherung
(SAN oder MultiChannel SCSI) haben wir einen Speicherkasten als einen
Einzelpunkt des Versagens und es ist sehr teuer, so ein System mit dieser
Konfiguration aufzusetzen.
Wir können NBD (Network Block Devices) benutzen, um einen Netzwerkspiegel
aufzusetzen, aber ich fühle mich nicht sehr wohl dabei. NBDs haben ihre Grenzen,
sind schwierig aufzusetzen und zu verwalten und sind einfach zu viel Aufwand,
wenn alles, was man braucht, ein paar replizierte Webserverdaten über einige
wenige Webserver sind.
Okay, laßt uns versuchen, Daten zu replizieren.
Hier ist ein Szenario
Du hast zwei Webserver, einen als Hauptserver und den anderen als Backup.
Du machst alle Änderungen auf dem Masterrechner und rsync-st die Änderungen zum
zweiten Rechner.
Einfach?
Aber wie automatisiert man das? Deine Benutzer werden FTP zum Masterrechner
mehrere Male am Tag benutzen. Was passiert, wenn der Masterrechner versagt und
der Backserver übernimmt? Einfach. Ich habe die Antwort dafür. Sie sehen die
Änderungen nicht, die sie gemacht haben und sind darüber sehr verärgert. :)
Nun, du kannst "rsync -av --delete source destination" von CRON alle 5 Sekunden
laufen lassen, aber dann ist dein Rechner nicht mehr wirklich zu etwas anderem
zu gebrauchen, oder?
Hier ist ein weiteres Szenario
Du hast einen FTPserver, um die Daten darauf zu laden und
sechs Webserver, die nach dem round robin Algorithmus darauf antworten.
Deshalb sollten die Daten auf jedem Rechner diesselben sein. Du kannst mit NFS
für einige Zeit davon kommen, wenn du Glück hast, aber nicht für lange.
Nun, was sollte getan werden?
Ich denke, die Antwort ist "kopiere die Daten zu den Webservern nur dann, wenn
es Änderungen an den Dateien gegeben hat", und wenn es keine Änderungen
an den Daten gibt, mache nichts.
Das ist genau das, was wir durch Benutzen von "fam" tun werden.
So, wie wissen wir, daß es eine Änderung an den Dateien gibt?
Hier ist eine Antwort, die ich von einem M$ Windows Entwickler erwarten würde.
Wir können das Verzeichnis durchsuchen, das wir alle paar Sekunden beobachten
und die Zeitstempel und Größe mit der Version, die wir im Cache haben,
vergleichen.
Ja, richtig
Umfrage: Suchen nach Dateizeitstempeln/Größe und Vergleichen mit der
älteren Version ist teuer.
Stell dir vor, daß dein Rechner alle 5 Sekunden "ls -lR /somedirectory" auf
deinem Webserver laufen läßt :)
Der elegante Weg wäre, daß die Datei uns mitteilt, wenn sie sich geändert hat,
so daß wir dann daraufhin handeln können.
Dies ist genau das, was "IMON" für uns macht.
source: http://oss.sgi.com/projects/fam/faq.html
fam, der File Alteration Monitor, liefert ein API, das Applikationen benutzen
können, um benachrichtigt zu werden, wenn bestimmte Dateien oder Verzeichnisse
geändert wurden.
FAM besteht aus zwei Teilen: fam, der Daemon, der auf Anfragen hört und
Benachrichtigungen liefert und libfam, eine Bibliothek, die
Clientapplikationen benutzen können, um mit FAM zu kommunizieren.
Wenn die beobachteten Dateien von einem remote host gemountet werden, wird der
lokale fam versuchen, fam auf dem remote host zu kontaktieren und die Anfragen
an den remote fam weiterzuleiten.
fam kann auch seine Clients benachrichtigen, wenn eine Datei eine Ausführung
beginnt und stoppt. (Der IRIX Interactive Desktop z.B. benutzt dies, um ein
Programmicon zu ändern, während es läuft.)
fam wurde ursprünglich 1989 von Bruce Karsh für IRIX geschrieben und 1995
von Bob Miller umgeschrieben. Dieser Open-Source Release von fam baut und läuft
sowohl auf Linux als auch auf IRIX, und ist derselbe fam, der mit
IRIX 6.5.8. dabei ist.
source: http://oss.sgi.com/projects/fam/faq.html
imon, der Inode Monitor, ist der Teil des Kernels, der fam sagt, wenn Dateien
sich geändert haben. Wenn Applikationen fam erzählen, daß sie an Dateien oder
Verzeichnissen interessiert sind, leitet fam dieses Interesse an imon weiter.
Wenn Dateioperationen auf Dateien, die von imon beobachtet werden, ausgeführt
werden, erzählt es der Kernel imon; imon erzählt es fam und fam benachrichtigt
die Anwendungen, die an den Dateien interessiert sind.
imon wurde ursprünglich 1989 von Wiltse Carpenter für den IRIX Kernel
geschrieben; die Linuxportierung wurde von Roger Chickering gemacht. Die
Linuximplementation im
imon Kernelpatch ist überwiegend ähnlich zur IRIXimplementation, aber sie hakt
sich anders im Kerneldateisystem fest.
FAM und IMON sind beide auf der SGI Webseite verfügbar. Sieh die Ressourcen
unten.
IMON ist ein Patch, den du auf deinen Kernel anwenden kannst. Dies fügt
Möglichkeiten für deinen Kernel hinzu, Inodes zu beobachten.
Um den Kernel zu patchen, cd zu deinem Kernelquellverzeichnis und wende den
Patch an
cd /usr/src/linux
patch -pi < patchfile
dann laß make config oder make menuconfig laufen und wähle, wenn du danach
gefragt wirst
Inode Monitor (imon) support (EXPERIMENTAL)
Im Dateisystemabschnitt
kompilierst du den Kernel ganz normal und rebootest
(tut mir leid).
FAM selbst zu kompilieren ist ganz einfach.
cd zum fam Quellenverzeichnis und laß
./configure && make all install
laufen
Voila, es ist installiert.
Als nächstes installieren wir ein Perlmodul namens SGI::FAM, damit wir unseren
event handler in Perl schreiben können.
Du dachtest nicht wirklich, daß ich dich fragen würde, in C/C++ zu
programmieren. Oder?
Nun, ich weiß nichts über dich, aber ich bin zu faul und ungeduldig, deshalb
schreibe ich meinen Datenreplizierer in Perl.
Lade es herunter und installiere
SGI::FAM von Jesse N. Glick
Um diese Module zu installieren, laß einfach das CPAN Modul laufen
perl -MCPAN -e shell
install SGI::FAM
dies sollte SGI::FAM installieren und alle nötigen Module.
fam_mirror ist ein Skript, das ich geschrieben habe, um die
Replizierung zu automatisieren.
Du kannst es hier anschauen
oder herunterladen.
Du kannst es editieren und
$replicaHosts verändern, so daß es zu deinen hosts paßt,
$rsh ändern, mit was auch immer für einem Befehl, den du von einer
Maschine zur anderen laufen lassen kannst und dasselbe gilt für $rsync.
So, zurück zu Szenario 1
2 Rechner laufen als Webserver (web1, web2). 1 von ihnen als Master
(web1) und der andere als Slave (web2).
Primärer FTPserver ist (web1).
web2 hat überhaupt keinen FTPdienst laufen. (sonst würden die Benutzer
vielleicht versuchen, auf Daten zu schreiben, sogar, wenn das System im
Backupmode ist)
Das web-dokument root ist auf beiden Rechnern /var/www
setup rsh oder ssh. web2 sollte web1
erlauben, remote Befehle laufen zu lassen, ohne Paßwortabfrage.
Ich füge normalerweise meinen ssh_key zu den autorisierten Schlüsseln
des replica Hosts hinzu.
rsync alle Daten von web1 nach web2
rsync -avz /var/www/ web2:/var/www/
Editiere fam_mirror und ändere @replicaHosts in
@replicaHosts=qw(web2)
Laß fam_mirror auf web1 laufen.
fam_mirror /var/www &
und verändere dann die Dateien auf web1. Alle
Änderungen werden auch auf web2 geschrieben.
Jetzt zu Szenario 2 (Eine Farm von Webservern)
Hosts "linuxweb1", "linuxweb2", "linuxweb3" und "linuxweb4" laufen als
Webserver
Host "linuxftp1" läuft als ftp server (Hauptfileserver)
Webhosts erlauben den Benutzern kein FTP.
Installiere fam, imon, SGI::FAM und fam_mirror auf
host "linuxftp1"
Setze rsh oder ssh zwischen den Rechnern auf.
hosts linuxweb[1-4] sollte linuxftp1 remote Befehle ohne
sofortige Nachfrage nach dem Paßwort erlauben.
Editiere fam_mirror und setze @replicaHosts zu
@replicaHosts=qw(linuxweb1 linuxweb2 linuxweb3 linuxweb4);
Ändere $rsh und $rsync, wenn nötig.
Angenommen, daß das webdokument root auf allen Rechnern /var/www ist.
Laß auf linuxftp1
INIT_MIRROR=1 fam_mirror /var/www &
laufen
Jetzt sollten alle Änderungen auf linuxftp1 auch auf
linuxweb[1-4]sichtbar sein.