Dieser Artikel oder Abschnitt bedarf einer grundsätzlichen Überarbeitung. Näheres sollte auf der Diskussionsseite angegeben sein. Bitte hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

Das Andrew File System (AFS) ist ein Netzwerkprotokoll für verteilte Netzwerkdateisysteme. Es ermöglicht horizontale Skalierbarkeit von Sekundärspeicher und integriert client-seitiges Caching. Klassischen Netzwerkdateisystemen wie NFS hat es voraus, dass Sekundärspeicher-Erweiterungen und Servertausch aus Nutzersicht vollkommen transparent möglich sind. Das wird durch eine zusätzliche Abstraktionsebene zwischen den Dateinamensraum und den Datenobjekten des AFS realisiert.

Das AFS-Protokoll umfasst zwingend neben Filesharing auch Protokolle und Datenbanken zur Namensauflösung von Nutzern und Gruppen. Nutzung der betriebssystemeigenen Nutzer- und Gruppennamensräume ist weder auf AFS-Client noch -Serverseite vorgesehen. In der Regel wird ein Administrator die AFS-Nutzer und Gruppen gegen ein zentrales Verzeichnis synchronisieren. Authentifizierung erfolgt mittels aus Kerberos-Tickets abgeleiteten Tokens.

Die verschiedenen für AFS nötigen Funktionen (Client, Dateiserver, Datenbankserver) laufen arbeitsteilig in separaten Prozessen, i. d. R. auf separaten Maschinen.

Ein lokaler Cache auf AFS-Clients samt garantierter Integrität sorgt für Lastreduktion auf Dateiservern und Latenzreduktion auf Clients. AFS ist für LAN- und WAN-Betrieb geeignet. Eine netzweite Cache-Konsistenz-Garantie ist ins Protokoll integriert. Authentifikation geschieht serverseitig. Der AFS-Dateinamensraum ist auf Client-Seite „mehrnutzertauglich“: alle Nutzer können (wie bei NFS) dieselben Pfade verwenden, agieren aber serverseitig jeweils mit korrekten Rechten. Zugriffsrechte werden per ACLs definiert, allerdings nur pro Verzeichnis. AFS ermöglicht mit wenig Aufwand, auf allen Clients einer Zelle einen zentral administrierten, einheitlichen Dateinamensraum aufzubauen. AFS-Server arbeiten üblicherweise unter Linux, Solaris oder AIX, jedoch werden weitere Unix-Varianten als Serverplattform unterstützt. Alle aktuell verfügbaren AFS-Server-Prozesse arbeiten im Userspace.

Es existieren verschiedene Programme, die AFS als Protokoll umsetzen. AFS-Clients sind für eine Vielzahl von Betriebssystemen verfügbar – i. d. R. 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 manuell auszulösende Datenreplikation. Es ist im AFS nicht wirtschaftlich, Daten oft (z. B. einmal pro Minute) zu replizieren.

Unabhängige Verwaltungseinheiten im AFS heißen Zellen. Eine Zelle umfasst einen oder mehrere Datenbankserver und einen oder mehrere Dateiserver. AFS-Clients sind lose einer „Heimatzelle“ zugeordnet – nicht jedoch (wie z. B. bei einer Windows-Domainmitgliedschaft) per Shared-Secret mit ihr verbunden. Auf Dateiservern befinden sich Datenpartitionen, die Instanzen von Volumes enthalten. Volume-Instanzen können symbolische Verknüpfungen auf andere Volumeinstanzen (auch in anderen AFS-Zellen) enthalten. Diese „Volume-Mountpoints“ sind die Übergangspunkt zwischen Volumes im Dateinamensraum. Ein Volume (üblicherweise root.afs) wird vom AFS-Client an eine definierte Stelle (/afs unter Unix) im Dateisystem eingehängt und bildet die Wurzel dieses AFS-Namensraumes, wobei jedoch durch die symbolischen Verknüpfungen auch Zyklen in der Verzeichnisstruktur möglich sind.

Weltweit existieren zahlreiche AFS-Zellen – vor allem in größeren Einrichtungen wie Universitäten. Zellen werden unabhängig voneinander verwaltet und können auch ö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 AFS-Verzeichnissen Rechte erhalten können. Dieses Vertrauen wird durch entsprechende Kerberos-Mechanismen realisiert.

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, Dateien und Verweise zu anderen Volumes 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. Diese wird ähnlich einer Quota benutzt, gilt jedoch für das Volume und nicht einzelne Benutzer. Es existieren vier Arten von Volumeinstanzen:

RW-Instanzen

Instanzen, auf die man lesend und schreibend zugreifen kann – z. B. Home-Verzeichnisse von Benutzern. Eine solche Instanz existiert i. d. R. für jedes Volume. 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 Daten benutzt, die nur selten verändert werden – z. B. Softwareverzeichnisse oder strukturelle Verzeichnisse, in denen dann z. B. die Benutzer-Home-Verzeichnisse liegen. AFS-Clients suchen sich selbstständig per VLDB eine funktionierende RO-Instanz. Die Existenz mehrerer RO-Instanzen macht die Daten eines Volumes redundant. AFS-Clients machen diese Redundanz für Nutzer transparent. 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 (Copy-On-Write), weshalb eine solche Instanz kein physisches Backup ersetzen kann.

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. Diese Instanzen werden vom AFS ausschließlich intern verwendet.

Für alle Volumeinstanzen wird von Dateiserver jeweils eine Statistik geführt, in der Zugriffe unterteilt nach lesend/schreibend, lokales Netz/anderes Netz und einigen anderen Kriterien erfasst werden. OpenAFS-Dateiserver besitzen zusätzlich einen Modus, umfangreiche Protokollierungsinformationen über Zugriffe auf Instanzen auszugeben – wahlweise direkt an andere Programme (per Pipe).

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

Es ist deshalb auch nicht möglich, die Datenpartitionen mittels eines anderen Filesharing-Protokolls zusätzlich freizugeben.

RW-Instanzen 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-Implementierung (OpenAFS) besteht der Dateiserver aus mehreren Prozessen (die teilweise aus mehreren Threads bestehen):

• Dateiserver – 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 klonen, Volume an- oder abschalten, Volume durchs 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.

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 Home-Verzeichnisse, 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.

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.

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 anzumelden 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 in 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 derzeit 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.

Die Sicherheit von AFS wird dadurch gewährleistet, dass jeder AFS-Server (Datenbank- wie Dateiserver) 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, 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 Dateiserver sicher zu authentifizieren, womit weder die Integrität noch die Vertraulichkeit von Datenübertragungen sichergestellt werden kann.

Wird ein Dateiserver kompromittiert und der Zellenschlüssel fällt in die Hände eines Angreifers, so ist es diesem möglich, mit Superuser-Rechten auf allen Dateiservern zu agieren, Daten sämtlicher Nutzer auszulesen und auch diese zu verändern. DFS, der „ehemalige Nachfolger“ von AFS, 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 z. B. von WEP.

Die fehlende Integritätsprüfung bei anonymen Zugriffen ist eine kritische Schwachstelle, da bei der verbreitetsten AFS-Client-Variante „OpenAFS“ ein Shared-Cache zum Einsatz kommt. Anonym vom Dateiserver geholte Dateien werden deshalb auch angemeldeten 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 derzeit kein praktisch durchgeführter Angriff bekannt.

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 verschlossenen 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 hilft nur eine Neuimplementierung der Sicherheitsschicht des verwendeten RPC-Protokolls (Rx). 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 Cronjobs dürfen dabei nicht vergessen werden.

Zur Vereinfachung wird der Dateinamensraum im AFS vom Administrator i. d. R. zyklenfrei aufgebaut. Eine Garantie dafür kann es jedoch nicht geben, sobald Nutzer das Recht bekommen, Volume-Mountpoints anzulegen oder Rechte zu verändern. 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 definiert den Namensraum, indem er Volumes gut strukturiert ineinanderhängt. Beginnend mit dem Standardvolume root.cell greift man dann z. B. auf Volumes wie home-Verzeichnisse, software, projekte und temp zu und hängt z. B. in das home-Verzeichnis-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 der symbolischen Verknüpfungen fremd ist (z. B. Windows), erscheinen diese als Verzeichnisse im Dateinamensraum des AFS. Neuere Windows-Clients enthalten entsprechende Erweiterungen, um solche Verknüpfungen als Junction Points auszudrücken sowie Shell-Erweiterungen, um damit umzugehen.

Das AFS-Protokoll unterstützt netzwerkweite Dateisperren, jedoch nur sog. Advisory Locks (flock()), keine Byte Range locks (lockf()). Der OpenAFS-Windows-Client ist ab 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) ist eine Fantasiezahl. Prinzipiell kann in einem verteilten Netzwerkdateisystem der freie bzw. belegte Speicher nur pro Verzeichnis ermittelt werden. Der Windows-Client ist in der Lage, den freien Speicher pro Verzeichnis an Anwendungen zurückzumelden.

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 zusätzliche Userspace-Prozesse nötig, die den Kernel-Treibern zuarbeiten. Der OpenAFS-Windows-Clients basiert auf einem für AFS entwickelten Redirektor, der mit einem Windows-Dienst kooperiert.

AFS-Clients (auch Cache-Manager) sind in der Lage, große Datenmengen von Dateiservern zwischenzuspeichern, wobei nicht ganze Dateien, sondern Stückchen anpassbarer Größe abgelegt werden. Die optimale Größe eines solchen Caches ist abhängig von Nutzungsmuster und kann auch viele Gigabytes 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 bei OpenAFS für Unix persistent. Die Cache-Integrität wird nach Neustart durch den Abgleich der Änderungszeitstempel von Dateien mit dem Dateiserver realisiert. 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 OpenAFS für 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 eines Verzeichnisses auf der Festplatte für den Cache (Option afsd -memcache).

AFS wird auf vielen Plattformen unterstützt. Das ist für AFS-Serverprozesse leichter zu realisieren, als für AFS-Clients da 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:

Legende:

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 werden diese nicht offiziell unterstützt bzw. von Fehlern befreit.

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 war ursprünglich ein universitäres Projekt der Carnegie Mellon University und umfasste eine Client- sowie eine Server-Implementierung. 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 ist die am aktivsten gepflegte AFS-Implementierung.

Das Hauptaugenmerk der Entwicklung bei OpenAFS liegt derzeit 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
• macOS 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.

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

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 bereits in Rente ist.

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

Diese AFS-Implementierung 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.

Wegen Unzufriedenheit mit den organisatorischen Mechanismen der Weiterentwicklung des AFS-Protokolls arbeiten einige OpenAFS-Entwickler an einem kommerziellen Fork von OpenAFS mit dem Namen YFS. Diese Abspaltung kann sowohl mit dem AFS- als auch mit dem massiv verbesserten YFS-Protokoll umgehen. Es gibt derzeit keine offizielle Veröffentlichung (Stand Januar 2013).

Am Rechenzentrum Garching wurde ein AFS-Server (mit entsprechenden in den OpenAFS-Client einfließenden Client-Modifikationen) mit OSD (Object Storage) entwickelt. 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. Da der Entwickler des OSD-AFS in Ruhestand ging und der Server nicht hinreichend stabil lief, wurde der Betrieb dieses Servers ca. 2015 wieder eingestellt.

• 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.
• AFS arbeitet ausschließlich mit IPv4. Die Unterstützung von IPv6 würde Änderungen an den Schemata der AFS-Datenbank sowie an den RPCs der Datenbankserver erfordern.
• 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 gegen Servervirtualisierung. 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.
• 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 RPCs des Dateiservers führen zu ungültigen Rückgabewerten, wenn man diese Grenze überschreitet. Ab der Dateiserverversion 1.6.2 ist das jedoch ist das für die regulären Nutzer unproblematisch.
• Volumes können maximal 2^31−1 Blöcke groß werden (etwa 2 Tebibyte). 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, jedoch beträgt die maximal einstellbare Quota immer noch 4 TiB.
• 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.^[2]

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

Das Aufsetzen einer AFS-Zelle ist deutlich schwerer, als z. B. das Anlegen einer SMB-Freigabe oder eines NFS-Exports. Die kryptografische Absicherung der Authentifikation mittels Kerberos erfordert einen gewissen Aufwand, der unabhängig von der Größe der Zelle ist. Zusätzlich kostet das Design der Zelle Zeit.

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

Die Verwendung von AFS ist mit einem Mehraufwand für Nutzer verbunden – die pro-Verzeichnis-ACLs sind ungewohnt und ACLs allgemein ein Konzept, das vor allem in der Unix-Welt erst langsam an Bedeutung gewinnt.

Als sinnvolle Strategie hat sich erwiesen, die AFS-Home-Verzeichnisse 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.

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.

• Max-Planck-Institut für Kognitions- und Neurowissenschaften
• Universität Hohenheim – betreibt die älteste AFS-Zelle im deutschsprachigen Raum
• Max-Planck-Institut für Plasmaphysik (hat AFS im Februar 2024 abgeschaltet)
• TU Chemnitz
• Georgius-Agricola-Gymnasium Chemnitz
• Universität Paderborn
• 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
• Technische Universität Graz – SPSC
• Friedrich-Schiller-Universität Jena
• Polizei Niedersachsen
• Wirtschaftsuniversität Wien
• Rheinische Friedrich-Wilhelms-Universität Bonn (bis 1. Dezember 2013)^[3]
• Universität zu Köln
• Humboldt-Universität zu Berlin
• Georg-August-Universität Göttingen, am Institut für Informatik
• Hochschule für angewandte Wissenschaften München
• Eberhard Karls Universität Tübingen

• Liste von Dateisystemen

• Website von OpenAFS
• Website des Arla-Projektes

1. ↑ OpenAFS-announce OpenAFS 1.5.10 release available
2. ↑ Eine Liste mit bekannten Problemkindern und Lösungen ist hier (Memento des Originals vom 7. Januar 2007 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/fbo.no-ip.org zu finden.
3. ↑ Einstellung des AFS zum 1. Dezember 2013 (Memento vom 22. August 2015 im Internet Archive)