Andrew File System

AFS im OSI-Schichtenmodell

Anwendung	AFS-Fileservice	AFS-Volserver	VLDB	PTDB	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 gut. Zehntausende Workstations, zehntausende Benutzer und hunderte Dateiserver 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. Dies geschieht dadurch, dass der Client (Workstation) bei einem Datenzugriff zuerst bei einem Datenbankserver nachfragt, wo die gewünschten Daten liegen und sich erst danach an den eigentlichen Dateiserver wendet. Dies ist also eine zusätzliche Abstraktionsebene zwischen dem Pfad, den Benutzer auf ihren Workstations sehen und der physischen Position der Daten auf Dateiservern.

Das Konzept von AFS ist ganzheitlich. Es umfasst nicht einfach das Freigeben von Dateien, sondern auch Benutzerverwaltung, (Kerberos-basierte) Authentifikation, Datensicherung, 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, Dateiserver, Datenbankserver) sind strikt voneinander getrennt und laufen üblicherweise auf verschiedenen physischen Maschinen. Ein Dateiserver 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 Dateiserver und verbessert die Performance – vor allem beim Betrieb über WANs. Die Authentifikation von Benutzern geschieht auf jedem von einem Client benutzten Dateiserver – nicht wie z. B. bei NFS unsicher auf den Client-Maschinen. Trotzdem erfordert nicht jede Sitzung eines Benutzers eine eigene explizite Verbindung zu einem Dateiserver 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.

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 einen oder mehrere Dateiserver. AFS-Clients sind üblicherweise (unter Windows kann das anders sein) einer „Heimatzelle“ zugeordnet, allerdings existiert in den bestehenden AFS-Implementationen keine zentrale Instanz, die über alle Clients Buch führt. Auf Dateiservern 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.

Zellen

Es gibt weltweit zahlreiche AFS-Zellen – vor allem 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-Dateiserver besitzen öffentliche IP-Adressen
• Die Datenbankserver der Zelle müssen öffentlich bekannt gemacht worden sein (entweder durch Eintrag in eine spezielle Datei auf OpenAFS 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.

Volumes

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

• Einen Eintrag in der VLDB (Volume Database), der auf verschiedene Instanzen eines Volumes auf einem oder mehreren Dateiservern derselben AFS-Zelle zeigt.
• Ein Objekt auf einem Dateiserver, 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 vier 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 Dateiservern 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 Dateiserver 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 desselben Volumes repliziert wird.
• Backup-Instanzen – Dieser Instanz-Typ befindet sich immer auf derselben Datenpartition wie die zugeordnete RW-Instanz – die Speicherung erfolgt differentiell zur RW-Instanz. Das bedeutet, dass eine Backup-Instanz auf dem Dateiserver 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 Dateiservern 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 Dateiserver jeweils eine kleine Statistik geführt, in der Zugriffe unterteilt nach Lesend/Schreibend, Lokales Netz/anderes Netz und einiger anderer Kriterien erfasst werden. OpenAFS-Dateiserver besitzen zusätzlich einen Modus, umfangreiche Logginginformationen über Zugriffe auf Instanzen auszugeben – wahlweise direkt an andere Programme (per Pipe).

Dateiserver

AFS-Dateiserver 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 Dateiserver 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 Dateiservern möglich, ohne Zugriff auf dort gelagerte Daten zu verlieren.

Bei der heute meist-benutzten AFS-Implementation (OpenAFS) besteht der Dateiserver 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 Dateiservers. 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 Dateiserver jedoch auch z. B. ein Bandroboter verbergen, der AFS-Dateien auf tertiären Speichermedien ablegt (z. B. MR-AFS).

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

Datenbankserver

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

• PTDB (Protection DataBase) – verwaltet Benutzer der Zelle und Benutzergruppen. Eine besondere Eigenschaft 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 Dateiservern. Außerdem speichert sie von jedem Dateiserver 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 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 die ausgefallenen 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) geschehen.

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-Server dann als Datenbankserver, Dateiserver 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. Dateiserver-Prozesse) bei Bedarf aktualisiert.

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

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-Dateiserver.

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 und hat deshalb keine Probleme mit üblichen NAT-Routern.

Sicherheit

Die Sicherheit von AFS wird dadurch gewährleistet, dass jeder AFS-Server (Datenbank- wie Fileserver) einen zellenweit einheitlichen symmetrischen Schlüssel (Shared-Secret) erhält. Dieser Schlüssel ist auch dem Kerberos-Server bekannt und kann deshalb dafür eingesetzt werden, um Benutzer zuverlässig zu authentifizieren. Der Schlüssel ist 56 bit breit und damit nicht mehr State-of-the-Art.

Datenübertragungen werden mit einem ebenfalls 56 bit breiten Sitzungsschlüssel signiert und bei Bedarf mit einem AFS-eigenen Algorithmus namens fcrypt verschlüsselt.

Bei anonymen Zugriffen auf das AFS (sprich: wann immer ein Nutzer kein AFS-Token hat) existiert für den Client keine Möglichkeit, den Fileserver sicher zu authentifizieren, womit weder die Integrität noch die Vertraulichkeit von Datenübertragungen sichergestellt werden kann.

Schwächen

Wird ein Fileserver kompromittiert und der Zellenschlüssel fällt in die Hände eines Angreifers, so ist es diesem möglich, mit Superuserrechten auf allen Fileservern zu agieren, Daten sämtlicher Nutzer auszulesen und auch diese zu verändern. Der „ehemalige Nachfolger“ von AFS (DFS) räumt mit diesem Problem auf, für AFS ist noch keine Lösung in Sicht.

Die geringe Schlüsselbreite ist ebenfalls ein Problem und rückt Brute-Force-Angriffe in den Bereich des Möglichen. Durch die Verwendung von Sitzungsschlüsseln ist die Gefahr noch relativ gering und nicht zu vergleichen mit der Schwäche von z. B. WEP.

Die fehlende Integritätsprüfung bei anonymen Zugriffen ist eine relativ kritische Schwachstelle, da bei der verbreitetsten AFS-Client-Variante „OpenAFS“ ein Shared-Cache zum Einsatz kommt. Anonym vom Fileserver geholte Dateien werden deshalb auch eingeloggten AFS-Nutzern zurückgeliefert, wenn diese auf solche zugreifen. Ein Angreifer kann – wenn man keine Gegenmaßnahmen ergreift – mit ein wenig Aufwand die Integritätsprüfung für angemeldete Benutzer aushebeln. Diese Schwachstelle ist unkritisch für Single-User-Maschinen, an denen Benutzer lediglich authentifiziert arbeiten. Mehrbenutzersysteme sind jedoch besonders gefährdet. Es ist derzeitig kein praktisch durchgeführter Angriff bekannt.

Gegenmaßnahmen

Gegen das Problem der zellenweit einheitlichen Schlüssel sind folgende organisatorische Maßnahmen zu treffen:

• AFS-Server paranoid absichern und nur die wichtigsten Dienste darauf aktivieren
• Alle AFS-Server in verschlossen Räumen aufbewahren und den Zutritt auf Serververantwortliche beschränken
• AFS-Schlüssel in einem verschlüsselten Dateisystem aufbewahren. Die Sicherheit dieser Maßnahme hat durch neuere Erkenntnisse über mögliche physische Angriffe auf DRAM-Bausteine stark abgenommen

Gegen die geringe Schlüsselbreite können nur die AFS-Entwickler etwas tun. Hinweis: Es existieren Unternehmen, die AFS-Programmierdienste anbieten und gegen Bezahlung auch solche Probleme angehen. Ein regelmäßiger Schlüsselwechsel vermindert die Gefahr erfolgreicher Brute-Force-Angriffe.

Um die beschriebenen Angriffe gegen die Integrität übertragener Daten auszuschließen, muss man auf dem jeweiligen Client anonyme AFS-Zugriffe unterbinden. Das ist nur auf Maschinen praktikabel, auf die keine normalen Benutzer authentifizierten Zugriff (Shell-Accounts, FTP, Webdav, …) haben. Alle Dienste müssen auf einem solchen Rechner grundsätzlich mit einem Token arbeiten. Auch Cron-Jobs darf man dabei nicht vergessen.

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 drei 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 Verknüpfungen – Diese funktionieren wie man das von Unix gewohnt ist. Verknüpfungen, 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 Bert sieht dann z. B. so aus:

/afs/meine.zelle/home/bert

Hinweise:

• Der Pfad eines Verzeichnisses/einer Datei sagt nichts über den Dateiserver 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 symbolische Verknüpfungen fremd ist (z. B. Windows), erscheinen symbolische Verknüpfungen 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 Dateiserver jedoch über einfache Advisory Locks.^[1]

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.

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 Dateisystemtreiber 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.

Cache

AFS-Clients werden auch manchmal Cache-Manager genannt. Dieser Cache ist in der Lage, auch große Datenmengen von Dateiservern 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 Dateiserver 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 Dateiserver 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 32-Bit-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 Dateisystem, in dem dieses Verzeichnis liegt, werden erhöhte Ansprüche gestellt:

• kein Journal
• hohe POSIX-Kompatibilität
• Unter Linux am besten Ext2

Openafs erlaubt auch die Verwendung des Hauptspeichers (RAM) anstatt einem Verzeichnis auf der Festplatte für den Cache (Option afsd -memcache).

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)
		Client	Server
Linux	Kernel 2.6	V	V	V	V (*)	E	V (*)
	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	V	E
	Windows Vista	V	V	?
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
	10.5 (Leopard)	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 4.8	V	V	V
AIX	AIX 5.1, 5.2, 5.3	V	V
	AIX 6.1
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 hat, 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.

AFS-Implementationen, Historisches

AFS, Transarc-AFS, IBM-AFS

AFS war ursprünglich ein universitäres Projekt der Carnegie Mellon University 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.

OpenAFS

OpenAFS ist die am aktivsten gepflegte AFS-Implementation.

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

• Linux
• AIX
• Solaris

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. ausschließlich im Userspace arbeitet), zu übersetzen und zu betreiben. Ausnahmen sind Serverversionen, die spezielle Modifikationen am Wirtsdateisystem 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 OpenAFS durch etwas suchen in den alten OpenAFS-Releases.

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.

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) an der KTH als Opensource-Software entwickelt. Bis jetzt existiert nur eine Client-Implementation, diese deckt jedoch einige von OpenAFS nicht unterstützte Plattformen ab.

MR-AFS

MR-AFS (Multi-Resident-AFS) entstand als kommerzielle Weiterentwicklung von Transarc-AFS. MR-AFS' Stärke ist, dass die Dateiserver Dateien aus dem AFS-Namensraum auf Tertiärspeicher (Bänder, optische Datenträger, …) auszulagern in der Lage sind. Die Dateiserver schreiben dazu in ein HSM-Dateisystem 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.

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.

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 Dateiservern. Letzteres bedeutet, dass man den zu benutzenden Dateiserver explizit angeben muss – das Modul kann dazu nicht den vlserver befragen.

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.

Google unterstützt im Rahmen des „Google Summer of Code“ die Entwicklung von mehreren Erweiterungen im openAFS-Projekt. Unter anderem werden seit Version 1.5.57 Patches aufgenommen, die es erlauben während einer Unterbrechung der Verbindung zu den openAFS- Servern, mit den Daten im Cache weiterzuarbeiten (disconnected AFS).

Weitere Punkte auf der Roadmap sind beispielsweise:

• bessere Integration in die Microsoft Management Console
• einem nativen Dateisystemtreiber für Windows (arbeitet ohne SMB emulation)

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 Version 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, symbolische Verknüpfung und Volume-Mountpoint (eine Sonderform der symbolischen Verknüpfung) bekannt. Pipes, Gerätedateien oder Sockets werden nicht unterstützt.
• AFS unterstützt ausschließlich IPv4.
• Pro Zelle sind maximal 254 Dateiserver erlaubt.
• Pro Dateiserver 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-Dateiservern 4 Tebibyte (32 Bit * Blockgröße) problemlos nutzbar. Einige AFS-RPCs führen zu ungültigen Rückgabewerten, wenn man diese Grenze überschreitet, jedoch ist das üblicherweise für die regulären Nutzer unproblematisch.
• Volumes können maximal 2^31−1 Blöcke groß werden (etwa 2 Terabyte). 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 möglich.
• 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 15 Zeichen haben.
• Jede ACL (also positive und negative ACLs unabhängig voneinander) eines Verzeichnisse kann maximal 20 Einträge haben.
• AFS beherrscht keine automatische Replikation. Daten werden in eine RW-Instanz geschrieben und evtl. später manuell (oder auch skriptgesteuert) in RO-Instanzen kopiert. Jedoch kann immer nur eine RW-Instanz pro Volume existieren.

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

Andere Beschränkungen

• AFS ist nicht für die Ablage von Datenbanken geeignet.
• AFS ist nicht als Mailserverbackend geeignet. Es gibt zwar Beispiele von AFS-Zellen, bei denen Mails direkt in die Homedirectories von Benutzern gelegt werden, jedoch ist das technisch anspruchsvoll. Außerdem skalieren solche Lösungen bei vielen Nutzern schlecht und der Gewinn ist minimal.

Administrationsaufwand

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.

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, das 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.

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.

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.

Einrichtungen, die AFS einsetzen

• Universität Hohenheim - betreibt die älteste AFS-Zelle im deutschsprachigen Raum
• Max-Planck-Institut für Plasmaphysik
• TU Chemnitz
• Georgius-Agricola-Gymnasium Chemnitz
• Universität Paderborn
• Max-Planck-Institut für Kognitions- und Neurowissenschaften
• CERN
• Institut national de physique nucléaire et de physique des particules
• Stanford Linear Accelerator Center
• Deutsches Elektronen-Synchrotron
• Paul Scherrer Institut
• Ruprecht-Karls-Universität Heidelberg
• Fachschaft Physik an der TU Wien
• Technische Universität Braunschweig
• Technische Universität Berlin
• Friedrich-Schiller-Universität Jena
• Leibniz-Rechenzentrum
• Polizei Niedersachsen
• Wirtschaftsuniversität Wien
• Rheinische Friedrich-Wilhelms-Universität Bonn
• Universität zu Köln
• Humboldt-Universität zu Berlin
• Georg-August-Universität Göttingen
• Hochschule München
• Eberhard Karls Universität Tübingen

Einzelnachweise

1. ↑ OpenAFS-announce OpenAFS 1.5.10 release available

Weblinks

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