Re: Verteilte Filesysteme - OpenAFS
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christian Fröse wrote:
> Hallo!
>
> Ich habe hier 14 Rechner, ein Server und 13 Clients. Momentan ist es so,
> dass die Home-Verzeichnisse per NFS vom Server auf die Clients gezogen
> werden.
>
> Das Problem ist erkennbar: was ist, wenn der Server ausfällt?
>
> Frage nun: Gibt es ein Filesystem, dass es ermöglicht, die Daten
> konsitent auf allen 14 Rechnern zu halten?
> Die Frage kommt daher, dass dieses System circa vier Autostunden von
> meinem Arbeitsplatz weg ist und der Chef der Firma nicht bereit ist,
> weiteres Geld in den "Server" zu investieren.
>
> Eine Anmerkung noch: es werden ACL's verwendet, dies sollte das
> Filesystem unterstützen.
Hi!
AFS wurde schon einmal genannt, ich schreibe etwas mehr dazu:
www.openafs.org
OpenAFS ist ein verteiltes Dateisystem, welches ein weltweit eindeutiges
Verzeichnisschema hat, dadurch kann jeder weltweit ohne Probleme auf die
Daten zugreifen, so er die Berechtigung dazu besitzt.
Technisch gibt es mehrere Zellen (du müsstest z.B. dir eine Zelle
deine.domain.de aufsetzen), diese Zelle wird von einem Database-server
verwaltet. Dieser kümmert sich um die Verwaltung der Daten in deiner
Zelle, die ACLs und co. Dazu kommt noch ein Fileserver, der wie ein NFS
Fileserver die Daten aufnimmt. Zu guter Letzt kommt noch ein
Auth-Server, hier empfehle ich krb5, der den Usern die Berechtigungen
verteilt.
Je nach Ausbau der Server vor Ort kann man alles auf einem Server, der
schon vorhanden ist, halten.
Die Clients bekommen dann den OpenAFS Client verpasst (verfügbar für
AIX, HP-UX, IRIX, Linux, Windows, MacOS X) und können unter dem
einheitlichem Pfad /afs/deine.domain.de/ auf die Daten zugreifen.
Im Dateisystem kann jedes Verzeichnis eigene ACLs bekomme, Gruppen und
Userbasiert. Zum einen existieren spezielle Gruppen (backup, admins,
alle user,..), dann die normalen Gruppen und jeder User kann bis zu 20
eigene Gruppen anlegen. Auf diesen Gruppen und User werden dann die ACLs
zugeteilt.
Aus Sicht des Backups ist es mit OpenAFS ein wenig komplizierter.
Einerseits bekommt man eine einfache Möglichkeit mittels sogenannter RO
Volumes eine Kopie der Daten im FS anzulegen und auf einem anderem
Server zu speichern, allerdings wird diese Kopie bei jedem
"kopiervorgang" neu angelegt, also kein richtiges backup, nur ein
snapshot eines bestimmten Zeitpunktes. Aber gerade für homes nett, da es
schnell angelegt ist und schnell zugreifbar ist.
Da das OpenAFS die Files per Datenbank verwaltet und nicht in clear auf
der HD am Fileserver ablegt, braucht man AFS-aware backup Lösungen. Oder
man macht es sich am Anfang etwas schwerer, erstellt das FS etwas
feingliedriger und kann beim Backup dann die Volumes (kleinste
Verwaltungseinheit beim Verwalten des FS) komplett dumpen und backupen.
Und diese dumps dann auf band/DVDR schreiben.
Dafür existieren auch inkrimentelle Lösungen.
Der Vorteil des Volumes-dumps sind vor allem die Beibehaltung der ACLs
und die schnelle Rekonstruierung beim HD Crash.
Nachteile vom OpenAFS:
1. Speed - max. LineSpeed möglich, also praktisch max. 10-11MB/sec unter
Linux.
=> es existiert ein Cache auf der lokalen HD, aber der nützt nichts beim
Schreiben
2. Speed - man kann die Daten übers Netz verschlüsseln, dann bricht
unter Linux die Geschwindigkeit je anch CPU ein wenig ein. Ich merke das
nicht, mit einem athlon64 hier
3. Windows Samba - Unter Windows ist OpenAFS über smb angebunden, sprich
Windows sieht AFS als Netzlaufwerk. Komfortabel, aber dadurch Nachteile:
<5 MB/sec, keine Files >2GB
4. Offline Mode - so richtig funktioniert OpenAFS nur online. Wenn ein
Client mal offline geht, sollte er aus dem Cache die Files noch lesen
dürfen, aber schreiben ist IMHO nicht machbar.
> MfG
>
> Christian
Für mehr Infos, schreib mir. Ich hab hier eine nette OpenAFS Zelle
laufen und kann sicher 1,2 Tips geben.
MfG,
Lars Schimmer
- --
- -------------------------------------------------------------
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at
Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD/YafmWhuE0qbFyMRAkGDAJ42SlXAGotRGiCFEfVXJbIwT90RjwCeJAWT
hGAqeCvzMTh48Bl5A675Kow=
=V1Df
-----END PGP SIGNATURE-----
Reply to: