Andrew File System

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten auf deiner Diskussionsseite.

**AFS im OSI-Schichtenmodell**
Anwendung	AFS-Fileservice	AFS-Volserver	VLDB	VLDB	BDB
			UBIK
Sitzung	Rx
Transport	UDP
Netzwerk	IP
Netzzugang	Ethernet		Token Ring	FDDI	...

Das Andrew Filesystem (AFS) ist ein Netzwerkprotokoll für verteilte Netzwerkdateisysteme. AFS skaliert extrem gut. Zehntausende Workstations, zehntausende Benutzer und hunderte Fileserver sind keine Seltenheit und können dazu noch im ganzen Internet verteilt sein. „Herkömmlichen“ Netzwerkdateisystemen wie z. B. NFS hat es voraus, dass es prinzipiell möglich ist, Sekundärspeicher ohne Unterbrechung des Betriebs aufzurüsten. Das geschieht durch eine zusätzliche Abstraktionsebene zwischen dem Pfad, den Benutzer auf ihren Workstations sehen und der physischen Position der Daten auf Fileservern.

Das Konzept von AFS ist ganzheitlich. Es umfasst nicht einfach das Freigeben von Dateien, sondern auch Benutzerverwaltung, bei Bedarf auch die für die kryptografischen Komponenten nötige Synchronisation der Uhrzeit zwischen Clients und Servern.

Die verschiedenen für AFS nötigen Funktionen (Client, Fileserver, Datenbankserver) sind strikt voneinander getrennt und laufen üblicherweise auf verschiedenen physischen Maschinen. Ein Fileserver wird i. d. R. niemals auf einer Workstation zum Einsatz kommen, wie das z. B. bei Windows-SMB-Freigaben üblich ist.

Ein lokaler Cache auf AFS-Clients entlastet die Fileserver und verbessert die Performance - vor allem beim Betrieb über WANs. Die Authentifikation von Benutzern geschieht auf jedem von einem Client benutzen Fileserver - nicht wie z. B. bei NFS unsicher auf den Client-Maschinen. Trotzdem erfordert nicht jede Sitzung eines Benutzers eine eigene explizite Verbindung zu einem Fileserver wie das z. B. bei SMB der Fall ist. Zugriffsrechte werden per ACLs definiert, allerdings nur pro Verzeichnis. AFS ermöglicht, auf allen AFS-Clients einer Zelle einen absolut einheitlichen Namensraum aufzubauen. AFS-Server arbeiten üblicherweise unter Linux, Solaris oder AIX, jedoch werden weitere Unix-Varianten als Serverplattform unterstützt.

Es existieren verschiedene Programme, die AFS als Protokoll implementieren. AFS-Clients sind für eine Vielzahl von Betriebssystemen verfügbar - ausnahmslos lizenzkostenfrei. Leistungsfähige AFS-Server sind lizenzkostenfrei für Linux und andere Unix-Betriebssysteme verfügbar. AFS-Server mit speziellen Funktionen sind kommerziell verfügbar.

Das AFS beherrscht Datenreplikation, jedoch nicht in Echtzeit. Die Replikation muss (was auch automatisierbar ist) ausgelöst werden. Es ist im AFS nicht wirtschaftlich, Daten extrem oft (z. B. einmal pro Minute) zu replizieren.

[Bearbeiten] Struktur des AFS

Unabhängige Verwaltungseinheiten im AFS heißen Zellen. Eine Zelle umfasst einen oder mehrere Datenbankserver (die einzigen Objekte, die ein AFS-Client über eine Zelle am Anfang kennen muss) und ein oder mehrere Fileserver. AFS-Clients sind üblicherweise (unter Windows kann das anders sein) einer „Heimatzelle“ zugeordnet, allerdings existiert in den existierenden AFS-Implementationen keine zentrale Instanz, die über alle Clients Buch führt. Auf Fileservern befinden sich Datenpartitionen, die wiederum Instanzen von Volumes enthalten. Volumeinstanzen können symbolische Verknüpfungen auf andere Volumeinstanzen (auch in anderen AFS-Zellen) enthalten, was benutzt wird, um einen Baum aufzuspannen, der den Dateinamensraum des AFS bildet. Ein definiertes Volume (üblicherweise root.afs) wird von jedem AFS-Client an eine definierte Stelle (/afs unter Unix) im Dateisystem eingehängt und bildet die Wurzel dieses Baumes, wobei jedoch durch die symbolischen Verknüpfungen auch Zyklen in der Verzeichnisstruktur möglich sind.

[Bearbeiten] Zellen

Es gibt weltweit zahlreiche AFS-Zellen - vor allen größere Einrichtungen wie Universitäten zählen dazu. Zellen werden unabhängig voneinander verwaltet und können öffentlich sein. Öffentliche Zellen zeichnen sich durch folgende Eigenschaften aus:

Alle AFS-Datenbankserver und AFS-Fileserver besitzen öffentliche IP-Adressen
Die Datenbankserver der Zelle müssen öffentlich bekannt gemacht worden sein (entweder durch Eintrag in eine spezielle Datei auf [1] oder durch Veröffentlichung im DNS.

Zellen können sich auch gegenseitig das Vertrauen aussprechen, wodurch Benutzer einer Zelle in ACLs von Verzeichnissen in Volumeinstanzen der anderen Zelle auftauchen können.

[Bearbeiten] Volumes

Der Begriff Volume steht im Rahmen von AFS für zwei Dinge:

Einen Eintrag in der VLDB , der auf verschiedene Instanzen eines Volumes auf einem oder mehreren Fileservern der selben AFS-Zelle zeigt.
Ein Objekt auf einem Fileserver, das Verzeichnisse und Dateien enthält. In diesem Artikel wird für ein solches Objekt zur besseren Unterscheidung der Begriff Volumeinstanz bzw. Instanz benutzt.

Volumes und Volumeinstanzen werden ausschließlich vom Administrator verwaltet. Sie besitzen eine änderbare Maximalgröße (ähnlich einer Quota, jedoch gilt diese für das Volume und nicht für Benutzer). Es existieren 4 Arten von Volumeinstanzen:

RW-Instanzen - Volumes, auf die man lesend und schreibend zugreifen kann - z. B. Homedirectories von Benutzern. Eine solche Instanz existiert für jedes Volumes. Andere Instanztypen sind fakultativ.
RO-Instanzen - Nur-lesbare manuell erstellte Kopien von RW-Instanzen. Von jeder RW-Instanz können mehrere RO-Instanzen angelegt und auf verschiedenen Fileservern verteilt werden. Solche Instanzen werden für Verzeichnisse im AFS benutzt, die die meisten Benutzer eher als Readonly ansehen/ansehen sollten - z. B. Softwareverzeichnisse oder auf strukturelle Verzeichnisse, in denen dann z.B. die Benutzerhomedirectories liegen. AFS-Clients suchen sich selbstständig per VLDB eine funktionierende RO-Instanz. Gibt es also mehrere RO-Instanzen zu einem Volume, dann bleiben Dateien und Verzeichnisse in einem entsprechenden Bereich des AFS-Namensraumes erreichbar, wenn Fileserver ausfallen - solange noch min. eine RO-Instanz online ist. Der Administrator kann manuell veranlassen, dass der aktuelle Zustand der entsprechenden RW-Instanz in alle RO-Instanzen des selben Volumes repliziert wird.
Backup-Instanzen - Dieser Instanz-Typ befindet sich immer auf der selben Datenpartition wie die zugeordnete RW-Instanz - die Speicherung erfolgt differentiell zur RW-Instanz. Das bedeutet, dass eine Backup-Instanz auf dem Fileserver immer nur soviel Speicher verbraucht, wie nötig ist, um den Unterschied zwischen der RW-Instanz und der Backup-Instanz auszudrücken. Achtung: Eine solche Instanz ist kein (zumindest kein physisches) Backup wie der Name vielleicht vermuten lässt. Sie wird allerdings vom AFS-Backup-System benutzt um konsistente Images der RW-Instanz zu erzeugen.
temporäre Clones - Solche Instanzen werden angelegt, um z.B. Volumes zwischen Fileservern zu verschieben. Würden solche temporären Clones nicht benutzt, müssten Schreibzugriffe auf die RW-Instanz im Namen der Datenintegrität verhindert werden, solange der entsprechende Vorgang läuft. Weder Benutzer noch Administrator bekommen üblicherweise etwas von diesen Instanzen mit.

Für alle Volumeinstanzen wird von Fileserver jeweils eine kleine Statistik geführt, in der Zugriffe unterteilt nach Lesend/Schreibend, Lokales Netz/anderes Netz und einiger anderer Kriterien erfasst werden. OpenAFS-Fileserver besitzen zusätzlich einen Modus, umfangreiche Logginginformationen über Zugriffe auf Instanzen auszugeben - wahlweise direkt an anderer Programme (per Pipe).

[Bearbeiten] Fileserver

AFS-Fileserver enthalten eine oder mehrere Wirtspartitionen, die wiederum Volume-Instanzen bereithalten. Das AFS-Netzwerkprotokoll kümmert sich prinzipiell nicht darum, in welchem Format die Volumes auf den Datenpartitionen lagern, allerdings ist allen AFS-Implementationen gemein, dass wenn man sich eine Partition auf dem Fileserver ansieht, man die Dateistruktur des AFS-Namensraumes nicht wiedererkennt.

Es ist deshalb auch nicht möglich, bestimmte Daten per SMB oder NFS gleichzeitig freizugeben.

RW-Instanzen (bei anderen ist das nicht nötig) lassen sich im laufenden Produktivbetrieb zwischen Servern verschieben - Lese- und Schreibzugriff auf die Daten der Instanz ist weiterhin möglich. Dadurch ist die Wartung von Fileservern möglich, ohne Zugriff auf dort gelagerte Daten zu verlieren.

Bei der heute meist-benutzten AFS-Implementation (OpenAFS) besteht der Fileserver aus mehreren Prozessen (die teilweise aus mehreren Threads bestehen):

fileserver - dieser bedient die Anfragen von AFS-Clients nach Dateien im AFS-Namensraum.
volserver - dieser Serverprozess wird hauptsächlich von Administratoren benutzt. Er stellt Funktionen bereit, die jeweils ganze Volume-Instanzen betreffen (z. B. Volume clonen, Volume an- oder abschalten, Volume durch's Netzwerk schicken, ...)
salvager - Der Salvager testet und repariert die AFS-eigenen Verwaltungsstrukturen auf den Wirtspartitionen eines Fileservers. Das ist z.B. nach einem Crash nötig (und passiert dann auch automatisch), um die Konsistenz der gespeicherten Daten sicherzustellen.

Da AFS nur ein Protokoll ist, kann sich hinter einem Fileserver jedoch auch z. B. ein Bandroboter verbergen, der AFS-Dateien auf tertiären Speichermedien ablegt (z. B. MR-AFS).

Fileserver können mehrere IP-Adressen haben. AFS-Clients wechseln beim Ausfall eines Fileserver-Netzwerkinterfaces einfach auf das nächste. Clients testen aus diesem Grund regelmäßig die Erreichbarkeit aller Fileserver-Netzwerkinterfaces, mit denen sie zu tun haben.

[Bearbeiten] Datenbankserver

Die Datenbankserver sind untereinander vernetzt und verwalten zwei oder mehr Datenbanken. Obligatorisch sind dabei:

PTDB (Protection DataBase) - verwaltet Benutzer der Zelle und Benutzergruppen. Ein besonderes Feature ist, dass Benutzer im gewissen Rahmen selbst Gruppen anlegen, bearbeiten und in ACLs des AFS benutzen können. Achtung: Diese Datenbank ist kein Verzeichnisdienst für Benutzerdaten wie Homedirectories, E-Mail-Adressen oder Passwörter.
VLDB (Volume DataBase) - führt Buch über Volumes (siehe weiter unten im Artikel) auf Fileservern. Außerdem speichert sie von jedem Fileserver die Liste der zugeordneten IP-Adressen.

Folgende Datenbanken sind außerdem noch gängig:

BDB (Backup DataBase) - verwaltet Bänder, die von speziellen AFS-Serverprozessen im Rahmen von Backups mit Daten beschrieben wurden.
KDB (Kerberos DataBase) - diese Datenbank verwaltet Benutzerpasswörter (eigentlich Kerberos-Schlüssel). Das zwischen AFS-Client und KDB-Server benutzte Protokoll ist jedoch ein Vorläufer des bereits überholten Protokolls Kerberos v4. Neu errichtete Zellen verwenden heute üblicherweise einen auf Kerberos v5 basierenden Server, der unabhängig von den AFS-Datenbanken betrieben wird.

Alle Datenbanken werden pro Datenbankserver von jeweils einem Prozess verwaltet. Dabei kommt das Protokoll UBIK zum Einsatz. Dieses ermöglicht, dass immer dann noch Lese- und Schreibzugriff auf die die AFS-Datenbanken möglich ist, wenn sich mehr als die Hälfte der Datenbankserver noch über das Netzwerk erreichen. Für Lesezugriff ist nur ein erreichbarer Datenbankserver nötig. Existieren also 5 Datenbankserver, kann z. B. einer auf eine neue Maschine migriert werden und der Ausfall eines weiteren würde immer noch nicht den Schreibzugriff kosten. Wenn ausgefallen Datenbankserver wieder online sind, gleichen sie automatisch den Datenbestand untereinander ab.

Der aufwendige Synchronisationsmechanismus erfordert exakten Gleichlauf der internen Uhren der Datenbankserver. Wenn sich die Uhrzeiten zweier beliebiger Datenbankserver um mehr als 10 s unterscheiden, sperrt die Datenbank den Schreibzugriff.

Datenbankserver sind die einzigen Objekte, die ein AFS-Client kennen muss, wenn er auf eine gegebene Zelle zugreifen will. Das kann zum einen über eine lokale Datei (CellServDB) oder auch per Domain Name System (über AFSDB Resource-Record).

[Bearbeiten] Andere Server-Prozesse

Der bosserver kommt auf allen AFS-Servern zum Einsatz. Ähnlich dem Init -Prozess auf Unix-Systemen verwaltet er eine Liste mit Prozessen, die auf einem Server zu laufen haben. Die laufenden Prozesse weisen einen AFS-Servern dann als Datenbankserver, Fileserver oder auch beides (nicht zu empfehlen) aus. Diese Liste und noch einige andere Sachen lassen sich über das Netzwerk verwalten.

In manchen AFS-Zellen kommen sog. Update-Server und Update-Clients zum Einsatz, die andere Serversoftware (z. B. Fileserver-Prozesse bei Bedarf aktualisiert.

Ein sog. *butc* kommt auf AFS-Tapecontrollern (sprich: AFS-Backup-Servern) zum Einsatz, um Daten von Fileservern entgegenzunehmen und auf Band oder auch auf Festplatten zu speichern.

[Bearbeiten] Netzwerkprotokoll

AFS arbeitet heutzutage ausschließlich per UDP, allerdings existiert mit RX eine Abstraktionsschicht, die prinzipiell auch andere Protokolle wie TCP zulässt - es gibt Pläne, genau das für OpenAFS zu realisieren.

Das Rx-Protokoll arbeitet im authentifizierten Modus (sprich: wenn ein Benutzer nicht ohne sich vorher einzuloggen arbeitet) immer signiert - üblicherweise auch verschlüsselt. Das bezieht sich z. B. auch auf Übertragungen zwischen AFS-Client und AFS-Fileserver.

AFS ist sehr empfindlich im Bezug auf Firewalls. Folgende ( UDP- ) Ports müssen zwischen Servern und Clients sowie zwischen den Servern untereinander freigeschaltet sein:

Für AFS allgemein: 7000, 7001, 7002, 7003, 7005, 7007
Wenn das AFS-Backup-System zum Einsatz kommt, dann zusätzlich: 7021, 7025-7032
Wenn Kerberos5 zum Einsatz kommt, dann zusätzlich: 88

Abgesehen von derzeitig nicht bekannten Sicherheitsschwachstellen werden alle diese Ports als sicher angesehen, können also auch per Internet erreichbar sein.

AFS arbeitet mit festen Portnummern, hat deshalb Probleme mit üblichen NAT-Routern. Man sollte niemals einen NAT-Router zwischen zwei beliebigen AFS-Servern oder AFS-Clients seiner Zelle benutzen.

[Bearbeiten] Dateisystem-Semantik

Der Dateinamensraum des AFS ist üblicherweise baumförmig. Da aber u. U. auch normale Benutzer Volume-Mountpoints anlegen können, darf man sich nicht darauf verlassen. Das kann z. B. für Backup-Software ein Problem darstellen.

Das Dateisystem kennt 3 Objekttypen:

Verzeichnisse - diese enthalten Dateien, andere Verzeichnisse und Mountpoints + eine ACL, die die Zugriffsrechte regelt.
Dateien - Dateien können in modernen AFS-Zellen (z. B. ab OpenAFS 1.4) - wenn Client und Server das unterstützen - größer als 2 GB sein. Sie besitzen genau einen Datenstrom, Unix-übliche Metadaten wie Benutzer-ID und Gruppen-ID. Dabei werden die Unix-Permissions jedoch nicht für Autorisationszwecke benutzt. Mehrere harte Links auf Dateien können existieren, jedoch nur, wenn sich diese im selben Verzeichnis befinden.
Symbolische Links - Diese funktionieren wie man das von Unix gewohnt ist. Links, deren Ziel eine besondere Form hat, werden vom AFS-Client als Volume-Mountpoint interpretiert. An deren Stelle wird dann der Inhalt des Basisverzeichnisses eines anderen Volumes eingehängt.

Der Administrator einer Zelle gibt deren Struktur vor, indem er Volumes gut strukturiert ineinanderhängt. Beginnend mit dem Standardvolume root.cell greift man dann z. B. auf Volumes wie homedirectories, software, projekte und temp zu und hängt z. B. in das homedirectories -Volume weitere mit dem Namen home.ernie, home.bert, ... ein. Der Pfad zu Ernie sieht dann z. B. so aus:

/afs/meine.zelle/home/bert

Hinweise:

Der Pfad eines Verzeichnisses/einer Datei sagt nichts über den Fileserver aus, auf den zugegriffen wird. Selbiges gilt für Mountpoints.
Auch die Volumes, die man entlang eines Pfades durchschreitet, gehen aus dem Pfad nicht zwangsläufig hervor, jedoch lassen sich diese z. B. aus den Volume-Mountpoints ermitteln.

Unter Betriebssystemen, denen das Konzept symbolischer Links fremd ist (z. B. Windows), erscheinen symbolische Links als Verzeichnisse im Dateinamensraum des AFS.

Das AFS-Protokoll unterstützt netzwerkweite Dateisperren, jedoch nur sog. Advisory Locks (flock()), keine sog. Byte Range locks (lockf()). Der OpenAFS-Windows-Client ist seit Version 1.5.10 in der Lage, lokal Byte Range Locks zu emulieren. Dabei können lokale Anwendungen auf der Client-Maschine derartige Locks benutzen, der AFS-Client sperrt entsprechende Dateien auf dem Fileserver jedoch über einfache Advisory Locks (siehe[2]).

Die Anzeige des freien bzw. belegten Speichers des gemounteten AFS (Unix) bzw. des dem AFS zugeordneten Laufwerksbuchstaben (Windows) ist eine Fantasiezahl. Prinzipiell kann in einem verteilten Netzwerkdateisystem der freie bzw. belegte Speicher nur pro Verzeichnis ermittelt werden.

[Bearbeiten] AFS-Clients

AFS-Clients sind Computer (z. B. Workstations), die auf den AFS-Dateinamensraum zugreifen können. Unter Unix-Betriebssystemen ist dazu eine Kernelerweiterung nötig. Das geschieht entweder über einen generischen Filesystemtreiber wie FUSE (Arla-AFS-Client) oder über ein umfassenderes AFS-spezifisches Kernel-Modul (OpenAFS). In beiden Fällen sind - im Gegensatz z. B. zu NFS zusätzliche Userspace-Prozesse nötig, die den Kernel-Treibern zuarbeiten.

[Bearbeiten] Cache

AFS-Clients werden auch manchmal Cache-Manager genannt. Dieser Cache ist in der Lage, auch große Datenmengen von Fileservern zwischenzuspeichern, wobei nicht ganze Dateien, sondern Stückchen definierter (und anpassbarer) Größe abgelegt werden. Die optimale Größe eines solches Caches ist abhängig von Nutzungsmuster und kann auch viele Gigabyte betragen.

Die Cache-Integrität wird vom AFS garantiert. Ein Dateifragment, das vom Cachemanager eingelagert wird, ist gültig, bis der entsprechende AFS-Server es aktiv invalidiert. Das geschieht für RW-Instanzen z. B. wenn die entsprechende Datei von einem anderen AFS-Client modifiziert wurde, bei RO-Instanzen z. B. dann, wenn der Administrator die Replikation auslöst.

Aktiv gecacht werden ausschließlich Lesevorgänge. Schreibzugriffe werden zwar auch gepuffert, wenn jedoch eine zum schreibenden Zugriff geöffnete Datei geschlossen wird, blockiert das close()-Kommando solange, bis alle Daten zum Fileserver geschrieben wurden.

Der Cache ist (zumindest bei OpenAFS-Clients für Unix) persistent, in der Hinsicht, dass alle eingelagerten Datenfragmente einen Neustart des Cache-Managers überleben. Allerdings werden beim ersten Zugriff auf Daten einer bestimmten Datei die Zeitstempel der Datei mit denen auf dem Fileserver verglichen und die Datei verworfen, wenn es Änderungen gegeben hat.

Die Persistenz des Caches macht u. U. auch in lokalen Netzen die Nutzung von riesigen Caches zur Geschwindigkeitssteigerung sinnvoll.

Unter Windows besteht der Cache aus einer einzigen Datei, die per Memory Mapping benutzt wird. Die Maximalgröße des virtuellen Speichers (4 GB bei einem 32Bit-System) ist deshalb eine unüberwindbare Hürde für die Cache-Größe.

Unter Unix-Systemen besteht der Cache aus vielen Dateien in einem Verzeichnis. An das Filesystem, in dem dieses Verzeichnis liegt, werden erhöhte Ansprüche gestellt:

kein Journal
hohe Posixkompatibilität
Unter Linux am besten Ext2

[Bearbeiten] Unterstützte Plattformen

AFS wird auf vielen Plattformen unterstützt. Das ist für AFS-Serverprozesse leichter zu realisieren, als für AFS-Clients (weil für Server keine Kernelerweiterungen nötig sind). Es existieren verschiedene Projekte, die das AFS-Protokoll ganz oder teilweise implementieren - hier eine nicht auf Vollständigkeit pochende Liste:

Plattform/Implementation		OpenAFS		Arla (Client)	MR-AFS (Server)	Hostafs (Server)	kAFS (Client)
Plattform/Implementation		Client	Server	Arla (Client)	MR-AFS (Server)	Hostafs (Server)	kAFS (Client)
Linux	Kernel 2.6	V	V	V	V (*)	E	V (*)
Linux	Kernel 2.4	1.2.11	V	?	?	E
Windows	Windows 3.11, 3.1 und 3.0
	Windows 98, ME	1.2.2b
	Windows 2000,XP	V	E	E
	Windows Vista	V (ab 1.5.12)	E
Mac OS X	10.1	1.2.7	1.2.7	0.35.9
	10.2	1.2.10	1.2.10	0.35.10
	10.3 (Panther)	1.4.1	1.4.1	0.37
	10.4 (Tiger)	V	V	V
Solaris	vor 2.0	?	?	?	?
	2.0 - 2.6	V (*)	V	?	V (*)
	ab 2.6	V	V	E	V (*)
BSD	FreeBSD 5.x			V
	FreeBSD 6.x
	NetBSD			V
	OpenBSD 3.9			E
AIX 5.1, 5.2, 5.3		V	V
SGI Irix 6.5		?	?
HPUX 11i		?	?

Legende:

Syntax	Bedeutung
V	Der entsprechende Plattform-Port wird aktiv gepflegt und weiterentwickelt. Der Einsatz der entsprechenden AFS-Implementation auf dieser Plattform ist also grundsätzlich zu empfehlen.
E	Dieser Port ist experimentell und für produktiven Einsatz nicht zu empfehlen.
Version	Dieser Port wurde früher aktiv gepflegt, jedoch gibt es zumindest keine aktuellen Pakete mehr. Die letzte verfügbare Versionsnummer ist angegeben.
?	Dieser Port wird offiziell unterstützt. Wer nähere Informationen zur Qualität des Ports hatm, möge diese bitte eintragen.
(*)	Unbedingt den Abschnitt zur entsprechenden Implementation lesen!

Für AFS-Server sollte man tunlichst auf die jeweils empfohlenen Plattformen zurückgreifen. Es existieren zwar z. B. experimentelle AFS-Server-Versionen für Windows oder alte AFS-Server-Versionen für Irix, jedoch ist es ausgesprochen schwer, für solche Versionen Support oder Bugfixes zu bekommen.

Transarc-AFS und seine Nachfolger verfügen über einen NFS-Server im Client, der andere Plattformen, für die kein Client existiert per NFS Zugriff auf den AFS-Namensraum gewähren kann. Allerdings ist nur von Solaris bekannt, dass ein darauf laufender aktueller OpenAFS-Client das noch unterstützt. Prinzipiell sollte jedoch jeder im Userspace laufende Serverprozess (z. B. Samba, Userspace-NFS-Server, Webdav, ...) problemlos Dateien aus dem AFS freigeben können. Ohne spezielle Anpassungen an der Serversoftware werden so aber nur anonyme Zugriffe möglich sein.

[Bearbeiten] AFS-Implementationen, Historisches

[Bearbeiten] AFS, Transarc-AFS, IBM-AFS

AFS war ursprünglich ein universitäres Projekt der CMU und umfasste eine Client- sowie eine Server-Implementation. Es wurde von der Firma Transarc später unter dem Namen Transarc AFS vermarktet. Transarc wurde von IBM aufgekauft, AFS unter dem Namen IBM-AFS vermarktet. IBM gab AFS im Jahre 2000 unter einer Open Source-Lizenz (IBM Public License) frei - es heißt seitdem OpenAFS und wird aktiv weiterentwickelt. Weiterhin sind jedoch weltweit zahlreiche Transarc- und IBM-AFS-Server im Einsatz.

[Bearbeiten] OpenAFS

OpenAFS ist die am aktivsten gepflegte AFS-Implementation.

Das Hauptaugenmerk der Entwicklung bei OpenAFS liegt derzeitig für Server auf

Grundsätzlich gilt, dass der AFS-Server nur in geringem Maße vom Wirtsbetriebssystem abhängig ist. Es sollte also z. B. auch auf einer älteren Version von Linux möglich sein, den Server (der i. d. R. ausschliesslich im Userspace arbeitet), zu übersetzen und zu betreiben. Ausnahmen sind Serverversionen, die spezielle Modifikationen am Wirtsfilesystem vornehmen (sog. inode-Server). Diese benötigen zusätzliche Kernelmodule und werden auch für neue AFS-Installationen praktisch nicht mehr eingesetzt.

Unterstützte Client-Plattformen sind

Linux. Da das für den Client nötige Kernel-Modul Open Source ist und keine Kernel-Patches benötigt, kann man es für beliebige Linux_Distributionen übersetzen.
Windows 2000 und Windows XP
Mac OS X 10.4 (Tiger)
AIX
Solaris. Achtung: Der OpenAFS-Client-Support für Solaris vor 2.6 wird aus der Entwicklungsversion von OpenAFS entfernt - OpenAFS 1.4 unterstützt jedoch weiterhin Solaris ab 2.0.

Clients für ältere Plattformen - z. B. für ältere Windowsversionen findet man auf [3] durch etwas suchen in den alten OpenAFS-Releases bzw. unter [4] sortiert nach Plattform.

Im Rahmen des DCE-Standards wurde das verteilte Dateisystem DFS als Nachfolger von AFS entwickelt. Dieses bietet u. a. folgende Vorteile:

Ein geheimer Schlüssel pro Server, nicht wie bei AFS pro Zelle
ACLs pro Datei und nicht nur pro Verzeichnis

Dem DFS war trotz Abwärtskompatibilität zu AFS jedoch kein Erfolg beschieden, da dessen Einsatz an hohe Lizenzgebühren gebunden war.

[Bearbeiten] Arla

Das Arla-Projekt entstand zu einer Zeit, als es noch keine freie AFS-Implementation gab und Transarc-AFS mit Lizenzzahlungen verbunden war. Es wurde unabhängig vom "AFS-Mainstream" (AFS ... OpenAFS) and der KTH als Opensource-Software entwickelt. Bis jetzt existiert nur eine Client-Implementation, diese deckt jedoch einige von OpenAFS nicht unterstützte Plattformen ab.

[Bearbeiten] MR-AFS

MR-AFS (Multi-Resident-AFS) entstand als Weiterentwicklung von Transarc-AFS. MR-AFS' Stärke ist, dass die Fileserver Dateien aus dem AFS-Namensraum auf Tertiärspeicher (Bänder, optische Datenträger, ...) auszulagern. Die Fileserver schreiben dazu in ein HSM-Filesystem und überlassen die eigentlichen Migrationsentscheidungen der HSM-Software. Dabei können normale AFS-Clients mit MR-AFS-Servern Daten austauschen. MR-AFS befasst sich ausschließlich mit Serversoftware. MR-AFS-spezifische Funktionen sind z. B. in die Kommandozeilentools von OpenAFS eingebaut. Die Zukunft von MR-AFS ist ungewiss, da der einzige Entwickler im Jahr 2009 in Rente gehen wird.

[Bearbeiten] Hostafs

Hostafs ist eine kleine AFS-Server-Implementation, die zum Ziel hat, normale Verzeichnisse als Volumes zu tarnen und per AFS freizugeben. Auf diese Weise kann man z. B. CDROMs im AFS verfügbar machen. Hostafs stellt jedoch keine Zugriffsschutzmechanismen wie ACLs zur Verfügung - alle Freigaben sind für alle lesbar.

[Bearbeiten] kAFS

Diese AFS-Implementation besteht aus einem Client, der als Linux-Kernelmodul realisiert ist. Er ist Teil des Standard-Linux-Kernels. Der Client ist jedoch nicht für produktiven AFS-Betrieb gedacht, sondern z. B. für das Booten über Netzwerk, wenn der Administrator wirklich alles im AFS vorhalten will. Es besitzt keine Möglichkeit authentifiziert auf das AFS zuzugreifen, unterstützt nur lesenden Zugriff und spricht nur mit Fileservern. Letzteres bedeutet, dass man den zu benutzenden Fileserver explizit angeben muss - das Modul kann dazu nicht den vlserver befragen.

[Bearbeiten] Ein Blick in die Zukunft

Am Rechenzentrum Garching ist ein AFS-Server (mit entsprechenden in den OpenAFS-Client einfließenden Client-Modifikationen) mit OSD (Object Storage) in Entwicklung. Dabei werden die Metadaten (Zugriffsrechte, Timestamps, Verzeichnisstrukturen) weiterhin vom AFS-Server verwaltet, die Daten liegen jedoch auf sog. Object-Storage-Servern, mit denen der Client dann direkt kommuniziert. Auf diese Weise können z. B. Dateien auf mehreren Servern liegen (Striping) und deutlich schneller gelesen und geschrieben werden.

[Bearbeiten] Beschränkungen, Grenzen

AFS kann wegen des Callbacks-Prinzips (=Rechner werden aktiv über Änderungen auf dem Server informiert) nicht zuverlässig mit NAT-Routern zusammenarbeiten. Faustregel: Es ist kein NAT-Router dazwischen muss für jedes mögliche Paar von Rechnern einer AFS-Zelle gelten - Ab 1.4.1 arbeitet OpenAFS besser mit IP-NAT zusammen.
Der AFS-Client ist nicht für extrem große Datenmengen ausgelegt. Das liegt an der Organisation des Cache-Managers, der zwar Dateistückchen exorbitanter Größe, jedoch unabhängig von deren Größe nicht besonders viele davon effizient verwalten kann. Diese Beschränkung gilt nur für OpenAFS-Clients vor Version 1.4.0.
Unter Unix-Betriebssystemen benutzt der verbreitete OpenAFS-Client die GIDs (Unix-Gruppen IDs) 0x7f0 bis 0xbf00. Diese Gruppen zusätzlich für andere Zwecke zu benutzen ist ein Sicherheitsrisiko.
AFS unterstützt keine netzweiten Bytes-Range-Locks. Der OpenAFS-Windows-Client simuliert Byte-Range-Locks lokal. Eine ähnliche Funktion soll es in Kürze auch für den OpenAFS-Linux-Client geben.
Jeder Rechner kann Server und Client für jeweils eine AFS-Zelle sein. Es ist nicht möglich, ähnlich einem WWW-Server mehrere AFS-Zellen über einen AFS-Server zu bedienen. Natürlich spricht nichts dagegen, Server z.B. mit Xen zu virtualisieren, aber man benötigt trotzdem eine IP-Adresse pro Zelle pro Server. Clients können unabhängig von ihrer Heimatzelle mit beliebig vielen Zellen gleichzeitig Daten austauschen.
Im AFS-Namensraum sind ausschließlich die Objekte Verzeichnis, Datei, Symbolischer Link und Volume-Mountpoint (eine Sonderform des Symbolischen Links) bekannt. Pipes, Device-Files oder Sockets werden nicht unterstützt.
AFS unterstützt ausschließlich IPv4.
Pro Zelle sind maximal 254 Fileserver erlaubt.
Pro Fileserver werden 255 Datenpartitionen unterstützt.
Die Blockgröße im AFS beträgt 1 kByte und lässt sich nicht ändern.
Pro Datenpartition sind unter OpenAFS-Fileservern maximal 4 Terabyte möglich (32Bit * Blockgröße) möglich.
Volumes können maximal 2^31 -1 Blöcke groß werden (ca. 2 Gigabyte). Diese Einschränkung ist marginal, da das Ziel immer sein sollte, Volumes leicht verschiebbar - also klein - zu halten - Seit OpenAFS 1.4.0 sind auch größere Volumes kein Problem mehr
Volume-Namen können (Instanz-Erweiterungen wie .readonly und .backup nicht hinzugerechnet) maximal 22 Zeichen lang sein.
AFS-Verzeichnisse sind statische Datenstrukturen mit einer maximalen Kapazität von 64435 Einträgen (dentrys). Die Anzahl der Einträge wird reduziert, wenn eine oder mehrere Einträge Namen länger als 14 Zeichen haben.
Jede ACL (also positive und negative ACLs unabhängig voneinander) eines Verzeichnisse kann maximal 20 Einträge haben.

Diverse Programm stören sich daran, wenn sie im AFS laufen. Eine Liste mit bekannten Problemkindern und Lösungen ist unter hier zu finden.

[Bearbeiten] Administrationsaufwand

[Bearbeiten] Einrichtung vs. Betrieb

Das Aufsetzen einer AFS-Zelle ist deutlich schwerer, als z. B. das Anlegen einer SMB-Share oder eines NFS-Exports. Vor allem die kryptografische Absicherung der Authentifikation mittels Kerberos erfordert einen gewissen Aufwand, der unabhängig von der Größe der Zelle ist.

Seine Vorteile spielt AFS in folgenden Situationen aus:

wenn die Skalierbarkeit wichtig ist (Stichwort: Exponentielles Wachstum des Datenbestandes)
wenn der Datenbestand bereits extrem groß ist. AFS-Zellen mit hunderten Terabytes sind kein Problem.
wenn die Sicherheit eine größere Rolle spielt.
wenn Benutzer hohe Flexibilität bei der Rechtevergabe benötigen
wenn viel automatisiert werden soll. AFS lässt sich komplett über Kommandozeilentools steuern.
wenn plattformübergreifender Zugriff auf Daten obligatorisch ist. AFS deckt die Plattformen Unix, Mac OS X und Windows ab.

Wenn die AFS-Zelle erstmal läuft, beschränkt sich die Arbeit des AFS-Administrators auf das Aufrüsten und ggf. Austauschen von Servern. Der Administrationsaufwand ist dann im Verhältnis zur Nutzeranzahl und Speichergröße extrem niedrig. Zellen mit vielen Terabytes an Daten und mehreren tausend Nutzern kommen dabei u.U. mit einer Administratorstelle aus.

[Bearbeiten] Aufwand für normale Benutzer

Der Aufwand für Nutzer sollte nicht unterschätzt werden - die pro-Verzeichnis-ACLs sind ungewohnt und ACLs allgemein sind ein Konzept, dass vor allem in der Unix-Welt erst langsam Bedeutung gewinnt.

Als sinnvolle Strategie hat sich erwiesen, die AFS-Homedirectories mit gewissen Standardpfaden zu versehen, die das Sicherheitsniveau ausdrücken - z. B. ~/public , ~/secret und den Benutzer so - abgesehen von Ausnahmefällen von ACLs fernzuhalten.

Unter der folgenden URL befindet sich die Anleitung für normale Benutzer eines Max-Planck-Institutes: User-Primer des MPI/CBS

Da eine Benutzer-Anleitung jedoch nicht abstrakt sein sollte, wird ein AFS-Administrator eine solche für die eigene Zelle meist selbst schreiben und lokale Besonderheiten darin berücksichtigen.

[Bearbeiten] Backup

AFS wird von vielen Herstellern von Backup-Lösungen nicht unterstützt. Die Gründe dafür sind vielschichtig. Eine eigene Backup-Lösung ist jedoch vergleichsweise schnell in Form einiger Shell-Skripts programmiert. Fertige Skripte gibt es in großer Zahl im Internet - z. B. im Rahmen des InstantAFS-Projektes.

[Bearbeiten] Einrichtungen, die AFS einsetzen

[Bearbeiten] Weblinks

Homepage von OpenAFS
Homepage des Arla-Projektes
Deutsches Handbuch über AFS-Administration
Unix-Permissions Erklärungen zu Unix-Berechtigungen, Abschnitt AFS-ACLs

Von „http://de.wikipedia.org../../../a/n/d/Andrew_File_System_077a.html“

Kategorie: Dateisystem