Überblick 5. Verteilte Dateisysteme 5.1 Anforderungen an Verteilte Dateisysteme 5.2 Dateidienst-Architektur 5.3 Fallstudie NFS 5.4 Fallstudie AFS O. Kao Systemaspekte Verteilter Systeme 5-1 5.1 Anforderungen an Verteilte Dateisysteme Verteilte Dateisysteme unterstützen die gemeinsame Nutzung von Dateien im Intranet Zugriff auf Dateien unabhängig von der tatsächlichen Position Grundlage für die effiziente Umsetzung zahlreicher Dienste wie Namens-, Druck-, Authentifizierungsdienste, Webserver, Beispiele: NFS (Network File System), AFS (Andrew File System) Dateisystem ist üblicherweise am höchsten ausgelasteter Dienst im Intranet Funktionalität und Leistung kritisch für Gesamtsystem Anforderungen an verteilte Dateisysteme Transparenz Offenheit Nebenläufige Dateiaktualisierung Dateireplikation: Fehlertoleranz (Ersetzung korrupter Daten, Serverausfall, ) und Lastbalancierung (Vermeidung von Hot-Spots) Leistung, Umfang, Funktionalität und Zuverlässigkeit mit einem lokalen Dateisystem vergleichbar oder besser O. Kao Systemaspekte Verteilter Systeme 5-2
Transparenz Anforderungen an verteilte Dateisysteme Zugriffstransparenz: keine Unterscheidung zwischen lokalen und entfernten Daten Ortstransparenz: Clients sehen einen einheitlichen Dateinamensraum Dateien und Dateigruppen können an eine andere Position verschoben werden, ohne dass sich ihre Pfadnamen ändern Mobilitätstransparenz: Weder Client-Programme noch Systemadministrationstabellen in Clients werden bei Datenverschiebung modifiziert Leistungstransparenz: Mindestverfügbarkeit auch bei sehr hoher Auslastung Skalierungstransparenz: Einfache inkrementelle Erweiterung des Dateidienstes möglich Offenheit: Heterogene HW und BS werden unterstützt O. Kao Systemaspekte Verteilter Systeme 5-3 Anforderungen an verteilte Dateisysteme (2) Nebenläufige Dateiaktualisierung Dateiänderungen sollen keine Operationen der anderen Clients stören Bedarf an Nebenläufigkeitskontrolle für schreibende Zugriffe Techniken bekannt, allerdings sehr aufwendig I.d.R. Verwendung von zwingenden oder freiwilligen Sperren (UNIX-Standard lock) Dateireplikation Eine Datei wird durch mehrere Kopien ihres Inhalts an unterschiedlichen Positionen dargestellt Redundanz erhöht Effizienz Fehlertoleranz: Ersetzung korrupter Daten, Serverausfall, Lastbalancierung: Zugriffe werden auf mehrere Server verteilt und beschleunigt Vermeidung von Hot-Spots Funktionen eines verteilten Dateidienstes sollen bezüglich Leistung, Umfang, Funktionalität und Zuverlässigkeit mit einem lokalen Dateisystem vergleichbar oder besser sein O. Kao Systemaspekte Verteilter Systeme 5-4
Sicherheit Anforderungen an verteilte Dateisysteme (3) Zugriffskontrollmechanismen wie in lokalen Dateisystemen mit zusätzlichen Forderungen nach Verschlüsselung und Signierung von Anforderungs- und Antwortnachrichten Zuverlässige Abbildung der Benutzer-ID auf lokale IDs Fehlertoleranz Der Dienst wird weitergeführt, auch wenn einzelne Clients oder Server ausfallen Konsistenz Konventionelle Dateisysteme unterstützen eine Eine-Kopie- Aktualisierungssemantik Modell für nebenläufigen Dateizugriff so, dass alle Prozesse, die auf eine Datei zugreifen, den gleichen Inhalt sehen als gäbe es nur eine einzige Datei Bei replizierten oder in Cache gehaltenen Dateien entstehen Verzögerungen, die zu Inkonsistenzen führen könnten O. Kao Systemaspekte Verteilter Systeme 5-5 5.2 Dateidienst-Architektur Abstraktes Architekturmodell als Grundlage für NFS und AFS Aufteilung der Verantwortung zwischen drei Modulen Clientmodul emuliert eine konventionelle Dateisystemschnittstelle Servermodul realisiert Operationen auf Dateien (Flacher Dateidienst) Servermodul realisiert Operationen auf Verzeichnissen (Verzeichnisdienst) Zustandslose Implementierung der Servermodule Client Server Anwendung Anwendung Verzeichnisdienst Clientmodul Flacher Dateidienst O. Kao Systemaspekte Verteilter Systeme 5-6
Dateidienst-Architektur: Module Flacher Dateidienst: Operationen zur Dateimanipulation UFIDs (Unique File Identifiers) zur Identifikation von Dateien UFID = Lange Bitfolge pro Datei, die im gesamten VS eindeutig ist Erhält der flache Dateidienst eine Anforderung zur Dateierzeugung, so wird ein UFID generiert und als Identifikator zurückgegeben Verzeichnisdienst: Verwaltet Verzeichnisbezeichner in Dateien Client des flachen Dateidienste Erzeugung von Verzeichnissen, Hinzufügen neuer Dateinamen, Zuordnung von alphanumerischen Dateinamen und UFIDs: Clients liefern Textnamen und bekommen UFID zurück Clientmodul Erweitert die Operationen der beiden Dienste in Form einer API Abbildung der Befehle auf die Operationsmenge der Dienste Informationen über die Netzwerkposition der Prozesse für die Dienste Caching zuletzt verwendeter Dateiblöcke O. Kao Systemaspekte Verteilter Systeme 5-7 Dateidienst-Architektur: Schnittstelle zum flachen Dateidienst Stellt eine Menge von RPC-Funktionen zur Verfügung, die aber nicht direkt von den Anwendungen benutzt wird UFID ist ungültig, wenn die entsprechende Datei nicht auf dem Server gespeichert ist bzw. Zugriffsrechte nicht vorhanden sind Operationen für den flachen Dateidienst Read(FileId, i, n) -> Data throwsbadposition Write(FileId, i, Data) throwsbadposition Create() -> FileId Delete(FileId) If 1 i Length(File): Reads a sequence of up to n items from a file starting at item i and returns it in Data. If 1 i Length(File)+1: Writes a sequence of Data to a file, starting at item i, extending the file if necessary. Creates a new file of length 0 and delivers a UFID for it. Removes the file from the file store. GetAttributes(FileId) -> Attr Returns the file attributes for the file. SetAttributes(FileId, Attr) Sets the file attributes O. Kao Systemaspekte Verteilter Systeme 5-8
Schnittstelle zum flachen Dateidienst und UNIX Dargestellte Schnittstelle und die elementaren Funktionen von UNIX sind funktional gleich Clientmodul zur Umsetzung der UNIX-Systemaufrufe in Befehle des flachen Dateidienstes Besonderheit beim abstrakten Modell Keine open und close Befehle, da zustandsloser Server Zugriff erfolgt unmittelbar durch Angabe der UFID Bei jedem Dateizugriff wird die aktuelle Cursorposition angegeben Unterschiede in der Fehlertoleranz Wiederholbare Operationen: Mit Ausnahme von create sind alle Operationen idempotent at-least-once Semantik Bei UNIX wird bei jedem Lese/Schreibzugriff der Cursor weitergesetzt Nach Absturz wird der Server neu gestartet und setzt den Betrieb fort, ohne dass die Clients/Server einen Zustand wiederherstellen müssen Bei UNIX muss der Server die aktuelle Cursorposition notieren und ggf. wiederherstellen O. Kao Systemaspekte Verteilter Systeme 5-9 Zugriffskontrollen bei UNIX Zugriffskontrolle Überprüfung der Benutzeridentität bei Anmeldung Überprüfung des geforderten Zugriffs bei Aufruf von open Verteilte Zugriffskontrolle Überprüfung der Zugriffsrechte auf dem Server Login/Passwort müssen zusammen mit der Anforderung übergeben werden Gefahr durch gefälschte Benutzer-IDs Zugangsdaten dürfen nicht auf dem Server gespeichert werden Zustandslose Implementierung erwünscht Realisierungsmöglichkeiten Umwandlung des Dateinamens in UFID und Kodierung der Ergebnisse in einer Capability, die bei nachfolgenden Anfragen benutzt wird Die Überprüfung findet bei jeder Clientanforderung statt Client muss Zugangsinformationen immer mitsenden O. Kao Systemaspekte Verteilter Systeme 5-10
Verschlüsselung der Capabilities Vorgehensweise Client sendet Nachricht an einen entfernten Serverprozess, mit der die Erstellung eines Objekts angewiesen wird Server erzeugt das Objekt und eine lange Zufallszahl (Prüfwert) und speichert Objektidentifikation, Rechte, Server sendet Objektnummer, Bitmap mit Rechten und kryptografisch gesicherte Konkatenation ObjektRechtePrüfwert Beim Zugriff sendet der Client die Capability als Teil der Anfrage Server extrahiert die Objektnummer und verwendet sie als Index zur Auffindung des Objekts Anschließend werden die gesendeten Objekt/Rechte mit dem lokalen Prüfwert kombiniert und verschlüsselt Stimmt das Ergebnis mit dem gespeicherten Wert überein, so wird der Zugriff gestattet. Zugriff auf fremde Objekte kann nicht gelingen, da die Zufallszahl und somit das vierte Feld nicht berechnet werden kann Server Objekt Rechte f(objekt, Rechte, Prüfwert) O. Kao Systemaspekte Verteilter Systeme 5-11 Dateigruppierungen Dateigruppe = Menge von Dateien auf einem bestimmten Server UNIX hat einzelne Dateisysteme Bei AFS existieren Volumes Ursprünglich eingeführt für Integration austauschbarer Festplatten Verteilte Dateidienste unterstützen die Zuordnung von Dateien zu Dateiservern in größeren logischen Einheiten Dateien können mehrfach gespeichert werden Lastverteilung und Fehlertoleranz verbessert Eindeutige Kennzeichnung notwendig, da Dateigruppen verschoben und mit anderen Gruppen zusammengeführt werden können Üblicherweise Konkatenation aus IP-Adresse (32 Bit) und lokal eindeutiger, vom aktuellen Datum abgeleiteter ID (16 Bit) IP-Adresse ist ungeeignet für die Dateisuche, da die Dateigruppe verschoben werden kann Dateidienst verwaltet die Zuordnung Gruppen-IDs Server O. Kao Systemaspekte Verteilter Systeme 5-12
5.3 Fallstudie NFS NFS (Network File System) wurde 1985 von Sun entwickelt, NFS- Protokoll ist ein Internetstandard definiert in RFC 1813 Definitionen der wichtigsten Schnittstellen als Public Domain und Quellcode für Referenzimplementierung unter Lizenz bereitgestellt (www.opensource.org) Ziele bei NFS-Entwicklung Bestmögliche Unterstützung für heterogene HW und BS Transparenten Zugriff auf entfernte Dateien für Clients Symmetrische Client/Server-Beziehung: Ein Rechner kann gleichzeitig Client (Dateien importieren) und Server (Dateien exportieren) sein Intranet: aus Leistungsgründen oft dedizierte NFS-Server vorhanden Keine Einschränkung der Anzahl importierter/exportierter Dateisysteme Zustandsloser NFS-Server Übertragung der Zugangsdaten und Sicherheitsüberprüfung bei jedem Zugriff erforderlich (Group-ID/User-ID) Verifikation durch Zusatzdienste wie NIS (Network Information Service) O. Kao Systemaspekte Verteilter Systeme 5-13 NFS-Architektur NFS-Server-Module im Kern eines jeden NFS-Servers NFS-Client-Modul wandelt Zugriffsbefehle auf entfernte Dateien in Befehle gemäß NFS-Protokoll und übergibt sie dem relevanten Server RPC-Schnittstelle zum NFS-Server ist offen jeder Rechner kann Anforderungen senden, die aber erst bei gelungener Authentifizierung ausgeführt werden Anwend ung 1 Anwend ung n NFS- Protokoll Virtuelles Dateisystem Lokal Extern Kern UNIX- Dateisystem Anderes Datei- System NFS- Client Netz Virtuelles Dateisystem Lokal UNIX- Dateisystem NFS- Server Kern Client Server O. Kao Systemaspekte Verteilter Systeme 5-14
Virtuelles Dateisystem Verbirgt die räumliche Trennung Integration durch Modul VFS (Virtual File System) Unterscheidung zwischen lokalen/entfernten Dateisystemen Ggf. Konvertierung der Datei-IDs (Unter NFS Dateihandles) Aufbau der Dateihandles Abgeleitet aus I-Node-Nummern von UNIX durch Erweiterung um 2 Felder: Dateisystem-ID I-Node-Nummer I-Node-Erstellungsnummer Dateisystem-ID: Eindeutige Nummer im Superblock des Dateisystems I-Node-Erstellungsnummer: I-Nodes von gelöschten Dateien werden wieder vergeben Durch Inkrementieren dieser Nummer wird Zugriff auf neue Dateien verhindert I-Node-Nummer: aktuelle Datei-ID im lokalen Dateisystem Client erhält Dateisystem-ID beim Mounten, Dateihandles bei lookup, create, Für jedes integrierte Dateisystem gibt ein v-node die Art jeder enthaltenen Datei (lokal oder entfernt) O. Kao Systemaspekte Verteilter Systeme 5-15 Mount-Dienst Einbindung eines (Teil-)Dateisystems wird als Mounting bezeichnet Zuständigkeit bei einem Mount-Dienst-Prozess im Benutzerraum Datei /etc/exports gibt bei jedem NFS-Server an, welche lokale Dateisystem exportiert werden dürfen Jedem Namen ist eine Liste berechtigter Clients hinzugefügt Integrationsmöglichkeiten Hard mount: Ständige Einbindung eines NFS-Verzeichnisses (/etc/fstab) Manuelle Integration mit dem Befehl mount Automounter: Verzeichnisse werden bei erstem Zugriff und für die Nutzungsdauer eingebunden Tabelle enthält mögliche Mountpunkte für den Automounter Bei Auflösung dieser Mountpunkte bekommt der Automounter eine Meldung, der das angeforderte Dateisystem in seiner Tabelle sucht und Testanforderung an den/die gelisteten Server sendet Der zuerst antwortende Server wird mit symbolischem (in späteren Versionen mit realem) Link gekoppelt O. Kao Systemaspekte Verteilter Systeme 5-16
NFS-Protokoll Das NFS-Protokoll verwendet XDR und UDP Ein NFS-Server bietet insgesamt 15 Operationen (Prozeduren) an, die vom Client aufgerufen werden können, darunter lookup(dirfh, name) fh, attr liefert Dateideskriptor und -attribute für die Datei name aus dem durch dirfh spezifizierten Verzeichnis read(fh, offset, count) data, attr liest bis zu count Zeichen aus Datei fh beginnend bei offset write(fh, offset, count, data) attr schreibt count Zeichen in Datei fh beginnend bei offset Nicht vorgesehen sind Dateioperationen wie open, close oder lock, da sie der Zustandslosigkeit des NFS Dienstes widersprechen Sperren trotz Zustandslosigkeit durch Verwendung eines getrennten Protokolls mit lockd-daemon Im Fehlerfall kompliziertes Freigeben/Weiterverwenden der Sperren O. Kao Systemaspekte Verteilter Systeme 5-17 5.4 Fallstudie AFS Andrew = verteilte Programmierumgebung entwickelt an Carnegie Mellon University Entwurf von Andrew File System (AFS) zur gemeinsamen Nutzung von Informationen bei Minimierung der Client/Server-Kommunikation Erstmalige Übertragung großer Dateien bzw. Ausschnitte davon (64KB) zum Client und cachen, bis der Server eine neue Version bereitstellt Der Cache basiert auf permanentem Speicher, enthält mehrere Hundert Dateien, die zuletzt auf dem Client verwendet wurden und ist bei Systemneustart wieder hergestellt Skalierbarkeitsaspekte im Vordergrund AFS wurde als kommerzielle und Public Domain Version zur Verfügung gestellt Kompatibel zu NFS Zugriff über die gewohnten UNIX-Befehle keine Anpassung der Programme notwendig O. Kao Systemaspekte Verteilter Systeme 5-18
Eigenschaften AFS Während NFS eher für bescheidene Knotenanzahlen (innerhalb eines lokalen Netzes) ausgelegt ist, unterstützt AFS größere Anzahlen (WANs) Entsprechend muss AFS bezüglich Sicherheit und Skalierbarkeit mehr leisten als NFS AFS unterscheidet streng zwischen Server und Client: Server sind vertrauenswürdig Nicht jede beliebige Maschine darf Server sein Im Gegensatz zu NFS ist AFS nicht für plattenlose Rechner geeignet, und setzt die Existenz lokaler Platten beim Client voraus O. Kao Systemaspekte Verteilter Systeme 5-19 Bearbeitung einer Datei Szenario AFS 1. Nach Absetzen von open wird nach der Datei im lokalen Cache gesucht. Falls nicht vorhanden, wird der zuständige AFS-Server ermittelt und eine Anforderung für diese Datei abgeschickt 2. Kopie wird im lokalen UNIX-Dateisystem des Clients gespeichert, geöffnet und der resultierende Dateideskriptor weitergereicht 3. Nachfolgende read/writes nutzen den Dateideskriptor 4. Beim Schließen wird die lokale Kopie aktualisiert und der neue Inhalt an den Server gesendet 5. AFS-Server aktualisiert Inhalt und Zeitstempel der zentralen Datei Selten aktualisierte Dateien (UNIX-Befehle, Bibliotheken, ) bzw. spezifische Benutzerdateien bleiben lange Zeit gültig und ermöglichen Leistungszuwachs Der Cache wird auf der lokalen Festplatte (100 MByte bis 1 GByte) eingerichtet Working-Set für weitere Leistungssteigerung O. Kao Systemaspekte Verteilter Systeme 5-20
Entwurfsstrategie von AFS Annahmen für die durchschnittliche und maximale Dateigröße dienen als Grundlage für die Optimierung von AFS Dateien sind klein, die meisten davon kleiner als 10 KByte Leseoperationen viel gebräuchlicher als Schreiboperationen (bis zu Faktor 6) Sequentieller Zugriff ist üblich, wahlfreier Zugriff eher selten Die meisten Dateien werden von nur einem Benutzer gelesen und verändert Zeitliches Lokalitätsprinzip: Wurde auf eine Datei vor kurzer Zeit zugegriffen, so ist ein nächster Zugriff in kurzer Zeit sehr wahrscheinlich Diese Annahmen treffen auf Datenbanksysteme nicht zu Viele Benutzer, häufige Aktualisierung, fein strukturierter Datenzugriff Separate Bereitstellung von Funktionen für verteilte Datenbanksysteme O. Kao Systemaspekte Verteilter Systeme 5-21 Implementierung von AFS: Softwarekomponenten 1. Vice: Serverprozess im Benutzerraum auf jedem AFS-Server 2. Venus: Vergleichbar mit dem Clientmodul des abstrakten Modells Benutzerprogramm Ausführung auf jedem Clientrechner als Benutzerprozess Verwaltet eine Festplattenpartition als Cachespeicher und modifiziert den Inhalt nach der Strategie LRU Workstations Servers UNIX kernel Venus Vice Benutzerprogramm UNIX kernel Venus Network UNIX kernel Vice Benutzerprogramm UNIX kernel Venus UNIX kernel O. Kao Systemaspekte Verteilter Systeme 5-22
Implementierung von AFS: Datenaufteilung und Namensraum Benutzerprozesse auf den Clients sehen lokale und entfernte Dateien Lokale Dateien: Behandelt wie normale UNIX-Dateien, stehen nur lokalen Benutzern zur Verfügung Gemeinsam genutzte Dateien: Abgelegt auf Servern, Kopien davon in Caches der Clients Integration im speziellen Verzeichnis (cmu), Kopplung durch symbolische Links Verlust der Ortstransparenz fällt nur Sysadmins auf Benutzerdaten liegen im gemeinsamen Bereich Lokale Dateien / (root) Gemeinsame Dateien tmp bin... vmunix cmu bin Symbolic links O. Kao Systemaspekte Verteilter Systeme 5-23 Implementierung von AFS: Modifikation des UNIX-Kerns Ähnlichkeiten zum abstrakten Modell Vice-Prozesse implementieren flachen Dateidienst Venus-Prozesse implementieren hierarchische Verzeichnisstruktur Eindeutige Identifizierung der Dateien/Verzeichnisse durch 96 Bit Datei- ID (fid) Venus-Prozesse übersetzen die lokalen Pfadnamen in fids Modifikation des UNIX-Kerns, um die Dateisystemaufrufe open, close, aufzufangen und an den venus Prozess weiterzuleiten Workstation Benutzerprogramm UNIX Systemaufrufe für Dateien Aufrufe für nichtlokale Dateien Venus UNIX kernel UNIX Dateisystem Lokale Festplatten O. Kao Systemaspekte Verteilter Systeme 5-24
Implementierung von AFS: Dateigruppierung Volume Zusammenfassung der Daten in Gruppen genannt Volumes, so dass die Daten einfacher gesucht und verschoben werden können Kleiner als Dateisysteme unter NFS Übliche Beispiele für separate Volumes sind persönliche Daten eines Benutzers, Systembinär-Dateien, Dokumentationen, Bibliothekscodes, Aufbau der fids im Zusammenhang mit Volumes Volume-Nummer zur Identifikation des Volumes, das die Datei enthält NFS-Datei-Handle zur Identifikation der Datei innerhalb des Volumes (vergleichbar mit Datei-IDs bei UFIDs) Eindeutiger Bezeichner, um Wiederverwendung von Datei-ID zu verhindern Venusserver übersetzt die gewöhnlichen Pfadnamen in fids, da Vice- Server Anforderungen unter Angabe der fids akzeptieren 32 Bit Volume-Nummer 32 Bit Datei-Handle 32 Bit Eindeutiger Bezeichner O. Kao Systemaspekte Verteilter Systeme 5-25 Mechanismus callback Vorgehensweise bei Weitergabe einer Datei von Vice an Venus Gleichzeitig mit Versand: Erstellung eines Tokens callback promise Token stellt sicher, dass Venus von Vice benachrichtigt wird, wenn ein anderer Client seine lokale Kopie der Datei ändert Token wird zusammen mit den gecachten Daten abgelegt und hat zwei mögliche Zustände valid und cancelled Valid: Datei wurde von keinem anderen Prozess zwischenzeitlich geändert gecachte Kopie ist aktuell Cancelled: Ein anderer Venus-Prozess hat eine Aktualisierung des Dateiinhalts angefordert zuständiger Vice-Prozess sendet ein Callback (Entfernter Prozeduraufruf) an alle Venus-Prozesse, die ein Token callback promise haben. Empfangende Venus-Prozesse ändern den Zustand ihres Tokens auf cancelled Beim Öffnen einer Datei überprüft Venus das Token Falls valid verwende gecachte Version, da aktuell Falls cancelled fordere aktuelle Version von Vice-Server an O. Kao Systemaspekte Verteilter Systeme 5-26
Cachekonsistenz beim Absturz? Beim Neustart eines Clients kann nicht davon ausgegangen werden, dass die lokalen Tokens mit callback promise aktuell sind Venus erzeugt für jeden Server eine Cache-Auswertungsanforderung mit Änderungszeitstempel der Dateien, die auf einem Server abgelegt sind Ist der Zeitstempel aktuell, so antwortet der Server mit valid, andernfalls wird das Token auf cancelled gesetzt O. Kao Systemaspekte Verteilter Systeme 5-27 Implementierung von AFS: Dateisystemaufrufe User process UNIX kernel Venus Vice Falls die zu öffnende Datei Durchsucht die Liste der im gemeinsamen Datenraum ist => Weiterleitung Gibt es die Datei dort nicht Dateien im lokalen Cache. Netz open(filename,mode) der Anforderung an Venus oder nicht mit gültigem, callback promise => sende Anforderung an Vice- Server mit dem Volume read(filedescriptor, Buffer, length) write(filedescriptor, Buffer, length) close(filedescriptor) Lokale Datei öffnen, Dateideskriptor an Anwendung leiten Normale UNIX Lese- Operation Normale UNIX Schreib- Operation Schließt lokale Kopie, benachrichtigt Venus Kopie der Datei im lokalen Dateisystem speichern, Namen in lokale Cache- Liste eintragen, lokalen Namen an UNIX leiten Falls Änderung der lokalen Kopie, sende neuen Inhalt an Vice-Server mit zugehörigem Volume Übertragung einer Kopie der Datei und eines callback promise, Protokollierung des callback promise Ersetze Dateiinhalt, sende callback an alle Clients, die ein callback promise für diese Datei besitzen O. Kao Systemaspekte Verteilter Systeme 5-28
Weitere AFS Aspekte Positionsdatenbank Jeder Server enthält eine Kopie einer vollständig replizierten Datenbank mit der Zuordnung Volume-Name zu Server Verschiebungen werden verzögert vermerkt, Weiterleitungsinformationen auf dem alten Server existieren Schreibgeschützte Repliken Volumes mit sich selten ändernden Dateien werden als schreibgeschützte Repliken auf mehreren Servern abgelegt 1:n Eintrag in Positionsdatenbank Änderungen nur auf einem Volume erlaubt und werden dann an alle Repliken weitergeleitet Optimierung der Netzwerknutzung durch große Pakete und Caching von Dateiabschnitten WAN-Unterstützung Mehrere autonome, administrative Zellen können zusammengefasst und dem Benutzer einheitlichen, nahtlosen Dateinamensraum präsentieren O. Kao Systemaspekte Verteilter Systeme 5-29 Sicherheit in AFS Sicherheitskritische Software läuft ausschließlich auf den Servern, die als vertrauenswürdig betrachtet werden Zugriffsrechte werden an einzelne Benutzer oder an Gruppen von Benutzern vergeben Ist ein Benutzer Mitglied in mehreren Gruppen, so besitzt er die akkumulierten Rechte aller dieser Gruppen Die Rechte werden in Zugriffskontrolllisten gespeichert. Um den Umfang der Listen handhabbar zu machen, beziehen sich Rechte nicht auf individuelle Dateien, sondern auf Verzeichnisse Rechte für read, write, lookup, insert, administer, lock, delete Aus Kompatibilitätsgründen zu Unix werden von den AFS-Clients noch Unixmodebits (rwx) verwaltet, die angeben, welche Zugriffe grundsätzlich erlaubt sind Mittlerweile wird AFS standardmäßig mit Kerberos gesichert O. Kao Systemaspekte Verteilter Systeme 5-30