| Anwendung | AFS-Dateiservice | AFS-Volserver | VLDB | PTDB | BDB |
| UBIK | |||||
| Sitzung | Rx | ||||
| Transport | UDP | ||||
| Netzwerk | IP | ||||
| Netzzugang | Ethernet | Token Ring | FDDI | … | |
DasAndrew File System (AFS) ist einNetzwerkprotokoll für verteilte Netzwerkdateisysteme. Es ermöglicht die horizontaleSkalierbarkeit von Sekundärspeichern und integriert client-seitigesCaching. Klassischen Netzwerkdateisystemen wieNFS hat es voraus, dassSekundärspeicher-Erweiterungen und Servertausche aus Nutzersicht vollkommentransparent möglich sind. Dies wird durch eine zusätzliche Abstraktionsebene zwischen dem Dateinamensraum und den Datenobjekten des AFS realisiert.
Das AFS-Protokoll umfasst neben Filesharing auch zwangsweise Protokolle und Datenbanken zur Namensauflösung von Nutzern und Gruppen. Die Verwendung der betriebssystemeigenen Nutzer- und Gruppennamensräume ist weder auf AFS-Client- noch auf der Serverseite vorgesehen. In der Regel synchronisiert ein Administrator die AFS-Nutzer und Gruppen gegen ein zentrales Verzeichnis. DieAuthentifizierung erfolgt mittels ausKerberos-Tickets abgeleitetenTokens.
Die verschiedenen für AFS nötigen Funktionen (Client, Dateiserver, Datenbankserver) laufen arbeitsteilig in separaten Prozessen, i. d. R. auf separaten Maschinen.
Ein lokalerCache auf AFS-Clients samt garantierter Integrität sorgt für eine Lastreduktion auf Dateiservern und eine Latenzreduktion bei den Clients. AFS ist für denLAN- undWAN-Betrieb geeignet. Eine netzweite Cache-Konsistenz-Garantie ist in das Protokoll integriert. Die Authentifikation geschieht in diesem Fall serverseitig. Des Weiteren ist der AFS-Dateinamensraum auf Client-Seite „mehrnutzertauglich“. Dies bedeutet, dass alle Nutzer (wie beiNFS) dieselben Pfade verwenden können und serverseitig mit den korrekten Rechten agieren.Zugriffsrechte werden perACLs nur pro Verzeichnis definiert. AFS ermöglicht mit wenig Aufwand, auf allen Clients einer Zelle einen zentral administrierten, einheitlichen Dateinamensraum aufzubauen. AFS-Server arbeiten üblicherweise unterLinux,Solaris oderAIX, jedoch werden weitereUnix-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 andereUnix-Betriebssysteme verfügbar. AFS-Server mit speziellen Funktionen sind kommerziell verfügbar.
Das AFS beherrscht manuell auszulösendeDatenreplikation. Es ist im AFS unwirtschaftlich, Daten häufig (z. B. einmal pro Minute) zu replizieren.
Unabhängige Verwaltungseinheiten im AFS heißenZellen. Eine Zelle umfasst einen oder mehrereDatenbankserver und einen oder mehrereDateiserver. AFS-Clients sind lose einer „Heimatzelle“ zugeordnet – nicht jedoch (wie z. B. bei einerWindows-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 (üblicherweiseroot.afs) wird vom AFS-Client an eine definierte Stelle (/afs unterUnix) 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. Dabei zeichnen sich Öffentliche Zellen durch folgende Eigenschaften aus:
Die Zellen können sich auch gegenseitig das Vertrauen aussprechen, wodurch Benutzer einer Zelle inACLs 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:
Volumes und Volumeinstanzen werden ausschließlich vom Administrator verwaltet. Sie besitzen eine änderbare Maximalgröße, welche ähnlich einerQuota benutzt wird und ausschließlich für das Volume und nicht für einzelne Benutzer gilt. Es existieren vier Arten von Volumeinstanzen:
Für alle Volumeinstanzen wird jeweils eine Statistik von einem Dateiserver 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, damit umfangreiche Protokollierungsinformationen über Zugriffe auf Instanzen ausgegeben werden können – wahlweise direkt an andere Programme (perPipe).
AFS-Dateiserver enthalten eine oder mehrere Datenpartitionen, die wiederum Volume-Instanzen beinhalten. 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 – der 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 heutzutage am meisten benutzten AFS-Implementierung (OpenAFS) besteht der Dateiserver aus mehreren Prozessen (die teilweise aus mehrerenThreads bestehen):
Da AFS nur ein Protokoll ist, kann sich hinter einem Dateiserver jedoch auch z. B. ein Bandroboter verbergen, der AFS-Dateien auftertiären Speichermedien ablegt (z. B. MR-AFS).
Dateiserver können mehrere IP-Adressen haben. Beim Ausfall eines Datenserver-Netzwerkinterfaces wechseln AFS-Clients automatisch auf ein anderes. Clients testen aus diesem Grund regelmäßig die Erreichbarkeit aller Dateiserver-Netzwerkinterfaces, mit denen sie in Kontakt stehen.
Die Datenbankserver sind untereinander vernetzt und verwalten zwei oder mehr Datenbanken. Obligatorisch sind dabei:
Folgende Datenbanken sind außerdem noch gängig:
Alle Datenbanken werden pro Datenbankserver von jeweils einemProzess verwaltet. Dabei kommt das ProtokollUBIK zum Einsatz. Dieses ermöglicht den Lese- und Schreibzugriff auf die AFS-Datenbanken, solange sich mehr als die Hälfte der Datenbankserver über das Netzwerk erreichen. Für den Lesezugriff muss nur ein Datenbankserver erreichbar sein. Existieren also 5 Datenbankserver, könnte beispielsweise einer dieser Server auf eine neue Maschine migriert werden und der Ausfall eines weiteren Servers würde nicht den Schreibzugriff kosten. Wenn die ausgefallenen Datenbankserver wieder online sind, gleichen sie automatisch den Datenbestand untereinander ab.
Der aufwendige Synchronisationsmechanismus erfordert einen 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 perDomain Name System (überAFSDBResource Record) geschehen.
DerBosserver kommt auf allen AFS-Servern zum Einsatz. Ähnlich demInit-Prozess auf Unix-Systemen verwaltet er eine Liste mit Prozessen, die auf einem Server laufen. Diese Prozesse weisen einen AFS-Server dann als Datenbankserver oder Dateiserver aus. Auch eine gleichzeitige Zuweisung ist möglich, allerdings häufig mit Problemen verbunden. Diese Liste und weitere Prozesse 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 Festplatte zu speichern.
AFS arbeitet heutzutage ausschließlich perUDP, allerdings existiert mitRX eine Abstraktionsschicht, die prinzipiell auch andere Protokolle wieTCP zulässt – es gibt Pläne, genau das für OpenAFS zu realisieren.
Das Rx-Protokoll arbeitet im authentifizierten Modus (sprich: wenn ein Benutzer sich vor der Arbeit anmeldet) 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:
Abgesehen von derzeit nicht bekannten Sicherheitsschwachstellen werden alle diese Ports als sicher angesehen, können also auch über das Internet erreicht werden.
AFS arbeitet mit festen Portnummern und hat deshalb keine Probleme mit üblichenNAT-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 eingesetzt werden, um Benutzer zuverlässig zu authentifizieren. Der Schlüssel ist 56 bit breit und entspricht damit nicht mehr den aktuellen Standards.
Datenübertragungen werden ebenfalls mit einem 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 diese auch zu verändern.DFS, der „ehemalige Nachfolger“ von AFS, räumt mit diesem Problem auf, für AFS gibt es aktuell keine Lösung.
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. vonWEP.
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 heruntergeladene 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:
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 reduziert das Risiko 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. Dies ist nur bei 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. AuchCronjobs 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 mehr 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:
Der Administrator einer Zelle definiert den Namensraum, indem er Volumes strukturiert ineinanderhängt. Beginnend mit dem Standardvolumeroot.cell greift man dann z. B. auf Volumes wiehome-Verzeichnisse,software,projekte undtemp zu und hängt z. B. in dashome-Verzeichnis-Volume weitere mit dem Namenhome.ernie,home.bert, … ein. Der Pfad zu Bert sieht dann z. B. so aus:
/afs/meine.zelle/home/bert
Hinweise:
Unter Betriebssystemen, denen das Konzept dersymbolischen Verknüpfungen fremd ist (z. B.Windows), erscheinen diese als Verzeichnisse im Dateinamensraum des AFS. Neuere Windows-Clients verfügen über entsprechende Erweiterungen, um solche Verknüpfungen als Junction Points darzustellen, sowie über Shell-Erweiterungen, um diese zu verwalten.
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. UnterUnix-Betriebssystemen ist dazu eine Kernelerweiterung nötig. Dies geschieht entweder über einen generischen Dateisystemtreiber wieFUSE (Arla-AFS-Client) oder über ein umfassenderes AFS-spezifisches Kernel-Modul (OpenAFS). In beiden Fällen sind zusätzlicheUserspace-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 (auchCache-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 mehrere Gigabyte groß sein.
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ürUnixpersistent. 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 inlokalen Netzen die Nutzung von riesigen Caches zur Geschwindigkeitssteigerung sinnvoll.
Unter Windows besteht der Cache aus einer einzigen Datei, die perMemory 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ürUnix-Systemen besteht der Cache aus vielen Dateien in einem Verzeichnis. An das Dateisystem, in dem dieses Verzeichnis liegt, werden erhöhte Ansprüche gestellt:
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 eventuell unvollständige Liste:
| Plattform/Implementierung | OpenAFS | Arla (Client) | MR-AFS (Server) | Hostafs (Server) | kAFS (Client) | ||
|---|---|---|---|---|---|---|---|
| Client | Server | ||||||
| Linux | Kernel 2.4 | 1.2.11 | V | ? | ? | E | |
| Kernel 2.6 | V | V | V | V (*) | E | V (*) | |
| 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 | ? | ||||
| macOS | 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-Implementierung 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 Implementierung lesen! |
Für AFS-Server sollte auf die empfohlenen Plattformen zurückgegriffen werden. Es existieren zwar z. B. experimentelle AFS-Server-Versionen für Windows oder alte AFS-Server-Versionen fürIRIX, 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 dies noch unterstützt. Prinzipiell kann jedoch jeder im Userspace laufende Serverprozess (z. B. Samba, Userspace-NFS-Server, Webdav, …) problemlos Dateien aus dem AFS freigeben. Ohne spezielle Anpassungen an der Serversoftware sind so allerdings nur anonyme Zugriffe möglich.
AFS war ursprünglich ein universitäres Projekt derCarnegie Mellon University und umfasste eine Client- sowie eine Server-Implementierung. Es wurde von der Firma Transarc später unter dem NamenTransarc AFS vermarktet. In der Folge kaufteIBM Transarc und vermarktete AFS anschließend unter dem Namen IBM-AFS. IBM gab AFS im Jahre 2000 unter einerOpen-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
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:
Clients für ältere Plattformen – z. B. für ältereWindowsversionen findet man aufOpenAFS durch etwas suchen in den alten OpenAFS-Releases.
Im Rahmen desDCE-Standards wurde das verteilte Dateisystem DFS als Nachfolger von AFS entwickelt. Dieses bietet u. a. folgende Vorteile:
Dem DFS war trotz Abwärtskompatibilität zu AFS 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 derKTH alsOpen-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 können. Die Dateiserver schreiben dazu in einHSM-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. Des Weiteren gibt es MR-AFS-spezifische Funktionen, die z. B. in die Kommandozeilentools von OpenAFS eingebaut sind. 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 jeden 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 alles im AFS vorhalten will. Es besitzt keine Möglichkeit, authentifiziert auf das AFS zuzugreifen. Außerdem unterstützt es ausschließlich 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 kommerziellenFork von OpenAFS mit dem NamenYFS. Diese Abspaltung kann sowohl mit dem AFS- als auch mit dem maßgeblich verbesserten YFS-Protokoll umgehen. Es gibt derzeit keine offizielle Veröffentlichung (Stand Januar 2013).
AmRechenzentrum 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 direkt kommunizieren kann. 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 den Ruhestand ging und der Server nicht hinreichend stabil lief, wurde der Betrieb dieses Servers ca. 2015 wieder eingestellt.
Diverse Programme stören sich daran, wenn sie im AFS laufen.[2]
Das Aufsetzen einer AFS-Zelle ist deutlich schwerer, als z. B. das Anlegen einerSMB-Freigabe oder einesNFS-Exports.Die kryptografische Absicherung der Authentifikation mittelsKerberos 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 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 derUnix-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 verschiedener Backup-Lösungen nicht unterstützt. Die Gründe dafür sind vielschichtig. Eine eigene Backup-Lösung ist jedoch vergleichsweise schnell in Form einigerShell-Skripts programmiert.
