[LinuxFocus-icon]
Home  |  Plan  |  Index  |  Suchen

Nachrichten | Archiv | Links | Über uns
Dieses Dokument ist verfübar auf: English  Castellano  Deutsch  Francais  Nederlands  Turkce  

convert to palmConvert to GutenPalm
or to PalmDoc

[Photo of the Author]
von Atif Ghaffar
<atif(at)developer.ch>

Über den Autor:

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



Übersetzt ins Deutsche von:
Katja Socher <katja(at)linuxfocus.org>

Inhalt:

 

Echtzeitdatenspiegelung unter Linux

[Illustration]

Zusammenfassung:

In diesem Artikel zeigen wir eine Möglichkeit zur Echzeitdatenspiegelung unter Linux, ohne teure SANs (Storage Area Network, z.B. GFS) oder andere Netzwerk Block devices.
Wir werden FAM und IMON für unser Datenreplikation benutzen.
FAM (File Alteration Monitor) und IMON (Inode Monitor) wurden von SGI ursprünglich für IRIX entwickelt.

Die Leute von SGI hatte eine sehr gute Idee als sie es nach Linux portierten und Open Source daraus machten.

Wenn Kosten keine Rolle spielen, würde ich GFS (Global File System) benutzen und eine SAN basierte Lösung, aber wenn die Kosten ein Faktor sind und Datenverteilung notwendig ist, bleibt mir nicht viel Auswahl offen
Ich habe einige wenige Möglichkeiten, unter denen ich wählen kann. In diesem Artikel diskutieren wir sie und sehen, was die Vor- und Nachteile sind.



 

Warum Datenreplikation statt Verteilung ?

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.

 

Halte es einfach

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.  

Halte es intelligent

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.

 

Was ist FAM?

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.  

Was ist IMON?

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.

 

Installieren von FAM und IMON

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.

 

Installieren des SGI::FAM Perl Moduls

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.  

Replizieren/Spiegeln mit fam_mirror

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.

 

Ressourcen

 

Bekannte Probleme

Ich fand, daß die Lösung, die ich hier dargestellt habe, ein kleines Problem hat: Sie arbeitet tatsächlich nicht mit großen Verzeichnissen (ein Verzeichnis mit 4000-5000 Unterverzeichnissen). Der Kernel beschwert sich über kmalloc etc.
Ich versuche, es zu lösen. Wenn ich es gelöst habe, werde ich die Information zu dem Artikel hinzufügen.
Laß es mich wissen, wenn du schon eine Lösung für dieses Problem kennst.  

Talkback für diesen Artikel

Jeder Artikel hat seine eigene Seite für Kommentare und Rückmeldungen. Auf dieser Seite kann jeder eigene Kommentare abgeben und die Kommentare anderer Leser sehen:
 Talkback Seite 

Der LinuxFocus Redaktion schreiben
© Atif Ghaffar, FDL
LinuxFocus.org

Einen Fehler melden oder einen Kommentar an LinuxFocus schicken
Autoren und Übersetzer:
en --> -- : Atif Ghaffar <atif(at)developer.ch>
en --> de: Katja Socher <katja(at)linuxfocus.org>

2002-02-24, generated by lfparser version 2.25