+ AFS im OSI-Schichtenmodell Anwendung AFS-Dateiservice AFS-Volserver VLDB PTDB BDB UBIK Sitzung Rx Transport UDP Netzwerk IP Netzzugang Ethernet TokenRing FDDI …
Das Andrew File System (AFS) ist ein Netzwerkprotokoll für verteilte Netzwerkdateisysteme. Es ermöglicht die horizontale Skalierbarkeit von Sekundärspeichern und integriert client-seitiges Caching. Klassischen Netzwerkdateisystemen wie NFS hat es voraus, dass Sekundärspeicher-Erweiterungen und Servertausche aus Nutzersicht vollkommen transparent möglich sind. Dies wird durch eine zusätzliche Abstraktionsebene zwischen dem Dateinamensraum und den Datenobjekten des AFS realisiert.
Konzept 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. Die 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 eine Lastreduktion auf Dateiservern und eine Latenzreduktion bei den Clients. AFS ist für den LAN- und WAN-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 bei NFS) dieselben Pfade verwenden können und serverseitig mit den korrekten Rechten agieren. Zugriffsrechte werden per ACLs 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 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 unwirtschaftlich, Daten häufig (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 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.
Zellen 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: 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).
Die 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.
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, 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, welche ähnlich einer Quota benutzt wird und ausschließlich für das Volume und nicht für einzelne Benutzer gilt. 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 Manuelle erstellte Kopien von RW-Instanzen, welche lediglich lesbar sind. 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 per VLDB selbstständig 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 temporäre 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 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 (per Pipe).
Dateiserver 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 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 geschieht in diesem Fall automatisch, um den Erhalt 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. 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.
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 in einem 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 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 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 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.