Re: Filesysysemsuche

Autor: Markus Hochholdinger (Markus_at_Hochholdinger.net)
Datum: 14. Mar 2004


Hi,

Am So, 2004-03-14 um 18.08 schrieb Thimo Neubauer:
> On Sun, Mar 14, 2004 at 02:59:38PM +0100, Markus Hochholdinger wrote:
> > OpenAFS würde mich brennend interessieren. Was kannst Du darüber
> > erzählen?
> Nachdem ich mit Coda nicht glücklich geworden bin (ergab
> Dateikollisionen, selbst wenn man nur ein "make" gemacht hat) habe ich
> unsere Arbeitsgruppenrechner auf OpenAFS umgestellt. Die Installation
> ist nicht wirklich einfach (und auch nicht so richtig toll
> dokumentiert), wenn es aber mal läuft ist es ein feines System.
ich dachte Coda ist darauf ausgelegt, offline arbeiten zu können.
OpenAFS ist auf Ausfallsicherheit ausgelegt. Oder ist das mittlerweile
anders?

> > Müssen alle Benutzer sich über Kerberos authentifizieren oder nur die
> > einzelnen OpenAFS-Server?
> Die Grundidee ist, dass man ein AFS-Filesystem immer mounten kann
> (wird ja auch bei Bedarf in einen globalen Filespace eingehängt),
> daher muss man sich dann für den weiteren Dateizugriff per Kerberos
> authentifizieren. Die Server verwenden einen gemeinsamen
> Kerberos-Schlüssel für die gegenseitige Authentifikation.
Also heißt der Umstieg auf OpenAFS ein Umstieg auf Kerberos, wenn man
Kerberos vorher noch nicht im Einsatz hatte. Naja, Vorteile würde das
schon einige bringen.

> Ursprünglich bringt OpenAFS einen eigenen Kerberos-Server mit, den
> "kaserver", um den sich aber wohl nicht mehr gekümmert wird. Ein
> normaler Kerberos 5 (ich benutze den MIT) klappt, allerdings muss man
> den kerb5-nach-4-Umsetz-Dienst anschalten, da OpenAFS die 4er-Tickets
> haben möchte.
> Die starke Authentifikation ist schon schön, hat aber auch hässliche
> Seiteneffekte: nachdem Kerberos(und damit auch AFS)-Tokens nach einer
> Weile ablaufen kann man z.B. Diensten nur schwer dauerhaft
> Schreibrechte im AFS geben. Von der Idee, Mails ins AFS auszuliefern
> kann man nur abraten (im Mathe-Institut sollen die das geschafft
> haben, aber da ist bestimmt 'ne Menge Hexerei dabei). Für
> Langlauf-Jobs bis zu einer Woche kann man "renewable tickets"
> benutzen, da kann ich bei Bedarf ein Skript schicken (normalerweise
> gelten Kerberos-Tickets 12h).
Ahja.

> > Wie "kleinlich" ist OpenAFS bei einem Server-Disconnect? Steht dann das
> > ganze Client-System oder kann man mit dem lokalen Dateisystem-Cache
> > weiter arbeiten (vorausgesetzt, es ist nur ein kurzes Netzwerkproblem)?
> Grundsätzlich ist das System synchron, d.h. bei einem disconnect kann
> man nie schreiben. Allerdings verwendet er dann noch die Daten aus dem
> lokalen Cache. Man kann bestimmte read-only-Volumes (z.B. das
> root-Volume) aber auch auf viele Server replizieren, da schwenkt er
> dann automatisch auf einen laufenden um.
Ich meine hier jetzt Extremsituation wie z.B. ich mache eine Datei zum
schreiben auf und dann zieh ich das Netzwerkkabel. Kann man diese Datei
dann nie wieder schreiben? Erkennt der Server den Disconnect nach einer
Weile? Wie synchronisiert sich der Server danach mit dem Client?

> Um das Gesamtsystem stabiler zu bekommen sollte man sowieso mehrere
> Server einsetzen, da gibt es auch feine Funktionen für: das
> Verschieben einzelner Volumes im Betrieb ist kein Problem, die werden
> dann nur für eine kurze Zeit gelockt. Die globalen Datenbanken
> (Volume-Datenbank, Benutzer-Datenbank) werden nach einem
> Mehrheitssystem synchronisiert: wenn Server ausfallen, eine Mehrheit
> der Server sich aber noch gegenseitig findet, kann man die globalen
> Daten immer noch ändern, die Mindeheit synchronisiert sich später
> automatisch. Dafür braucht man allerdings sinnvollerweise eine
> ungerade Anzahl Datenbankserver :)
Ich glaube gerade hier liegen die Stärken von AFS.

> > Wie performant ist OpenAFS? Durch den lokalen Dateisystem-Cache sollten
> > Server-Zugriffe ja minimiert werden könnnen? Oder geht doch wieder alles
> > zum Server (zu den Servern), nur gepuffert?
> Wenn ich die Doku richtig verstanden habe werden bei offenen Dateien
> callbacks auf dem Server angemeldet, d.h. er bekommt bescheid, wenn
> sich die Daten ändern. Meine Versuche, unser OpenAFS von zu Hause
> durch DSL zu verwenden waren recht erfolgreich: erste Zugriffe auf
> Verzeichnisse haben eine Weile gebraucht, danach ging es dann aber
> deutlich flotter, zum vernünftigen Arbeiten hat es gereicht. Die
> Schreibperformance war natürlich lausig :)
Ahja, also ein Schreiben in den lokalen Cache geht somit nicht? Sprich,
die Anwendung muss beim Speichern warten, bis der Server sagt, es ist
alles da?

> IIRC haben wir im Institut 4M/sec schreiben können, ohne
> Verschlüsselung waren es 10M/sec (kann man auch im Betrieb
> umstellen). Das ist aber eine Weile her und ich mag mich bei den
> Zahlen irren. Ist aber im lokalen Netz auf jeden Fall angenehm
> schnell.
Das ist schön. Somit kann man das gut als Fileserver-Dateisystem
einsetzen.

> > Hast Du Erfahrung mit OpenAFS-Clients für Mac OS X?
> Keine Ahnung, aber der Client wird ja zumindest zusammen mit dem Rest
> entwickelt... unser Mac-Profi in der Arbeitsgruppe liess sich bislang
> nicht zum Testen überreden und wird wahrscheinlich bald weg sein...
Schade.

> Noch Fragen? ;-) Wenn es einer von Euch wirklich einrichten möchte
> kann ich noch ein paar speziellere Tipps geben.
Leider ist das Projekt jetzt erstmal gestorben. Bis vor kurzem war die
Überlegung da auf OpenAFS umzusteigen und ich habe schon ein paar
Versuche unternommen, das ganze einzurichten. Allerdings ist man daran
jetzt nicht mehr interessiert.
Aber mich interessiert es trotzdem.

Gruß
                                                          \|/
        MH (o o)
------------------------------------------------------oOO--U--OOo--
 Markus Hochholdinger
 e-mail mailto:Markus_at_Hochholdinger.net .oooO
 www http://www.hochholdinger.net ( ) Oooo.
------------------------------------------------------\ (----( )-
                                                       \_) ) /
                                                             (_/


Dieses Archiv wurde generiert von hypermail 2.1.7 : 14. Mar 2004 CET