Verteilte Syteme. D. Verteilte Dateisysteme

Transkript

1 Verteilte Syteme D. Verteilte Dateisysteme Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.1 Dateien wichtige Abstraktionsform für die dauerhafte Speicherung von Daten, Informationen und Programmen Meist bestehen die Dateien aus einer linearen Aneinanderreihung von Bytes. Für den Zugriff verwendet man einen Dateizeiger, der zu einem Zeitpunkt auf ein bestimmtes Byte verweist. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.2

2 Dateisystem auf Einzelplatzrechnern: Schnittstelle zur Festplatte. ein verteiltes Dateisystem ermöglicht es zusätzlich auf entfernte Dateien zuzugreifen plattenlose Geräte zu unterstützen. Datei- Dienst Client Datei-Server Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.3 Transparenzanforderungen aus Sicht des Clients (nicht alle heute verfügbar) Zugriffstransparenz Der Zugriff auf entfernte Dateien erfolgt für Klienten mit den gleichen Operationen, wie der Zugriff auf lokale Dateien Ortstransparenz Es spielt keine Rolle, an welchem physikalischen Ort eine Datei gespeichert ist. Um den Zugriff identisch zu halten, wird dazu ein uniformer Namensraum benötigt. eine eventuelle Relokierung von Dateien muss ohne Änderung des Namens erfolgen können. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.4

3 Transparenzanforderungen (2) Nebenläufigkeitstransparenz Greifen mehrere Clients gleichzeitig auf eine Datei zu, soll kein Client von den Zugriffen der anderen etwas mitbekommen. Aus Konsistenzgründen sind nebenläufige, schreibende Zugriffe problematisch. (Oft wird dies durch einfache Sperrverfahren verhindert, wodurch dann bei überlappenden Zugriffen keine Nebenläufigkeitstransparenz mehr gilt.) Fehlertransparenz für Klienten, wie für Server, soll ein Fehlverhalten des jeweils anderen nicht zu Inkonsistenzen und Verklemmungen führen. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.5 Transparenzanforderungen (3) Lasttransparenz Die Anfragelast auf Serverseite soll sich nicht auf dessen Antwortzeiten auswirken (wichtige Forderung für verteilte Dateisysteme, die sehr viele Klienten bedienen sollen) Hardware- und Betriebssystem-Transparenz Das verteilte Dateisystem soll die Heterogenität unterschiedlicher Hardware und Betriebssysteme verbergen. Einheitliche Programmierschnittstelle des Dateisystems über verschiedenen Betriebsysteme Replikationstransparenz Der Client darf immer nur eine logische Datei sehen, egal wo und wie häufig diese repliziert vorgehalten wird. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.6

4 Transparenzanforderungen (4) Migrationstransparenz Ändert eine Datei ihren Speicherort, ist dies für den Client unsichtbar. (Dateien werden eventuell dynamisch in der Nähe von den Clients gehalten, die häufig darauf zugreifen). Partitionierungstransparenz Das Dateisystem kann partitioniert werden, Clients können nicht mehr auf bestimmte Dateiserver zugreifen Trotzdem stehen für Klienten noch alle benötigten Dateien zur Verfügung. Eine Vereinigung bisher getrennter Partitionen erzeugt dabei möglichst keine Inkonsistenzen. Speziell für die Anbindung mobiler Rechner interessant. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.7 Aufbau verteilter Dateisysteme Drei wesentliche Komponenten Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.8

5 Dateidienst Ist zuständig für die elementaren Operationen auf Dateien und deren Inhalt. Lesen und Schreiben, Ändern niederwertiger Dateiattribute (z.b.: Längeninformation und Zeitstempel), Allokierung von Plattenblöcken, Plattenein- und ausgabe und Pufferung. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.9 Verzeichnisdienst Abbildung von Dateinamen auf die binären Dateizeiger Verwalten der Dateien im meist hierarchischen Namensraum Test und das Ändern der Zugriffsrechte und anderer höherwertiger Dateiattribute Unterstützung und Umrechnung von symbolischen Verweisen oder Aliasen. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.10

6 Client Modul Für das Anwendungsprogramm ist das Klientenmodul die Schnittstelle, über die Aufrufe an den Verzeichnisund Dateidienst erfolgen. Die lokalen Aufrufe des lokalen Betriebs- oder Dateisystems werden darauf abgebildet. Das Clientmodul kann in unterschiedlich komplexen Ausprägungen vorliegen: vom einfachen RPC-Stub, bis zu einem eigenen Dateisystem mit Cacheeinträgen aus dem verteilten Dateisystem. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.11 Sichtweisen auf verteilte Dateisysteme Die Sichtweise auf ein verteiltes Dateisystem definiert sich durch die Syntax der Dateinamen. Autonome Dateiserver (Server/Rechnername + Pfadname) Remote Mounting Uniformer Namensraum durch Superroot Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.12

7 Autonome Dateiserver Jeder Rechner oder Dateiserver hat seine eigene, von anderen Rechnern unabhängige Verzeichnisstruktur. Bildung des Dateinamens durch Konkatenation aus Rechner/Servernamen und Pfad im Dateiverzeichnis. Die Namengebung ist dadurch orts- oder serverabhängig. Rechnernamen sind beispielsweise die IP-Adresse Servernamen werden z.b. gebildet aus Portnummer und IP- Adresse. z.b. UNC (Universal Naming Convention): \\servername\sys\public\file1 Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.13 Autonome Dateiserver Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.14

8 Remote Mounting eine Verzeichnisstruktur eines entfernten Rechners wird logisch in die lokale Struktur eingebunden. Da diese Einbindung für jeden Rechner individuell erfolgen kann, ist keine Ortstransparenz gegeben. Beispiele: NFS (SUN Network File System) Windows Shares Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.15 Remote Mounting Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.16

9 Uniformer Namensraum durch Superroot Über alle lokalen Dateisysteme wird eine übergeordnete Wurzel gesetzt. Dadurch erreicht man sowohl eine Orts-, als auch Namenstransparenz. Beispiele: Microsoft DFS (Distributed File System), Zusammenfassung aller Freigaben an einem zentralen Punkt im Netz Realisierung z.b. durch geeigneten netzwerkweiten Directory Service (z.b. ADS, NDS) Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.17 Uniformer Namensraum durch Superroot Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.18

10 D.2. Semantik des Datei-Sharing Greifen mehrere Prozesse auf eine Datei gemeinsam zu, entstehen Nebenläufigkeitsprobleme. Einzelrechner: Durch die zentrale Auslegung des Systems können Lese- und Schreibzugriffe stets sequentiell geordnet gehalten werden z.b. durch einen einzelnen Dateipositionszeiger. Verteiltes Dateisystem: Sequentielle Ordnung, wenn auch hier eine zentrale Koordinierung durchgeführt wird. Nicht mehr möglich wenn Caching und Replikation eingesetzt werden Eine Lösung der Sharing-Probleme ist es, generelles Sperren von Dateien durchzuführen. Bei Zugriff eines Clients auf eine Datei zu, wird Zugriff anderer gesperrt Dies verhindert jegliche Parallelität. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.19 D.2.1. Einzelkopie-Semantik oft auch als Unix-Semantik bezeichnet, da im UNIX- Dateisystem implementiert. Ein Lesezugriff auf eine Datei erhält immer das Ergebnis des zeitlich zuvorliegenden letzten Schreibzugriffs. a b write c Æ a b c read abc Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.20

11 Bewertung der Einzelkopie Semantik Zentraler Dateiserver: Semantik leicht zu realisieren. Client Caching: Implementation so, dass Veränderungen einer Cachekopie sofort bei allen anderen Kopien sichtbar werden (write-through). Ausgleich von Netzunzulänglichkeiten: Herstellen einer kausalen Ordnung aller Schreib- und Lesezugriffe durch eine virtuelle globale Zeit. Æ Für verteilte Dateisysteme: sehr ineffizient durch ihre Implementierung bzw. Aufwand zur Konsistenzwahrung Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.21 D.2.2. Sitzungs-Semantik Öffnen einer Datei: Client erhält eine eigene Kopie. Mit der Kopie arbeitet er bis zum Schließen der Datei. Rückschreiben zum Dateiserver nach dem Schließen Dateiänderungen sind für andere Klienten erst nach dem Schließen sichtbar. Server a b Æ a b Client 1 a b write c Æ a b c read abc Client 2 a b Æ a b read abc Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.22

12 Versionenproblem bei Sitzungssemantik Datei wird bei mehreren Klienten gleichzeitig geändert Lösungsmöglichkeiten: Mit dem letzten Schließen werden alle vorherigen Versionen beim Server überschrieben. Die Klienten müssen zwischen den verschiedenen Versionen einen Abstimmungsprozeß durchführen. Unterschiedliche Versionen werden von dem Server geeignet gemischt. Dies kann nur dann sinnvoll erfolgen, wenn der Anwendungskontext bekannt ist (z.b. Gruppeneditoren). Die Versionen werden getrennt voneinander weitergeführt. d.h. spezielle Namengebung für die Versionen. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.23 D.2.3. Unveränderlichkeits-Semantik Dateien sind nicht veränderbar (engl.: immutable file semantics). Dateien können immer nur neu erstellt oder gelesen werden. Änderungen erzwingen ein Neuanlegen der Datei. Versionsproblematik ähnlich wie bei der Sitzungs- Semantik (z.b. Zugriff mehrerer Klienten (lokal) schreibend auf eine gerade mehrfach gelesene Datei) Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.24

13 D.2.4. Transaktions-Semantik Auffassen aller Dateizugriffe als Transaktion Lese- und Schreiboperationen erfolgen in BeginTransaction-, EndTransaction-Klammern. die Dateien bleiben konsistent. Der Verwaltungsaufwand für transaktionsbezogene Dateizugriffe ist sehr hoch und damit das verteilte Dateisystem auch nicht sehr effizient. Zwingend, falls Dateien als Datenbankersatz verwendet werden sollen Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.25 D.3. Implementierungsaspekte Drei wesentliche Aspekte der Implementierung D.3.1. Architekturtyp Zugriffsmodell Dateiservertyp D.3.2. Art des Verzeichnismanagements D.3.3. Replikation und Cachingverfahren Nutzungsprofil eines verteilten Dateisystems die Analyse hängt immer von entsprechender Umgebung ab. In Workstationumgebungen gilt z.b. oft Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.26

14 Nutzungsprofil (Beispiel) Die Mehrheit aller Dateien ist klein Die meisten Dateien sind kleiner als 10 Kilobyte. sie passen evtl. komplett in ein Netzwerk-Paket. d.h. es lohnt sich, die gesamte Datei auf einmal vom Server zum Klienten zu übertragen und nicht Schreib- und Leseanforderungen einzeln über das Netz abzuwickeln. Dateien werden häufiger gelesen als modifiziert Die Effizienz lesender Zugriffe läßt sich gut mit Caching steigern. Im verteilten Dateisystem wird Caching effektiv einsetzbar Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.27 Nutzungsprofil (2) (Beispiel) Viele Dateien haben eine kurze Lebensdauer Der Rücktransfer von Dateien im Klientencache zum Server ist für kurzlebige Dateien unnötig (z.b. für temporäre Dateien, die bei einem Compilerlauf erzeugt wurden) Datei-Sharing ist selten Overhead für die Konsistenzerhaltung des Caching auf Klientenseite kann zugunsten der kürzeren Antwortzeiten aufgegeben werden Der durchschnittliche Prozeß benutzt wenige (kleine) Dateien Caching kann in den Arbeitsspeicher des Klienten verlagert werden. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.28

15 Nutzungsprofil (3) (Beispiel) Es gibt Dateiklassen mit spezifischer Charakteristik Dateien, die ausführbare Programme speichern werden nur gelesen, jedoch von vielen Klienten. Sie können also stark repliziert werden. Temporäre Dateien sind sehr kurzlebig, müssen also gar nicht im verteilten Dateisystem eingetragen werden. Private Dateien, wie Mailboxen werden häufig verändert, aber nicht gemeinsam benutzt Sie können also nahe beim Klienten gehalten werden. Æ Verteilte Dateisysteme könnten die unterschiedlichen Dateitypen mit unterschiedlichen Verfahren behandeln. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.29 Zugriffsmodelle D.3.1. Architekturtypen Das Zugriffsmodell legt fest, in welcher Art die Dateioperationen und -zugriffe (auch auf Verzeichnisse) zwischen Klient und Server abgewickelt werden. Dateiservertyp Zustandsloser Dateiserver Zustandsbehafteter Dateiserver Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.30

16 Upload/Download-Modell Dieses Modell entspricht einem Sitzungsmodell. Beim Öffnen einer Datei durch einen Klienten lädt der Server die Datei vollständig zum Klienten (download), der sie dann lokal bearbeiten kann. Benötigt der Klient die Datei nicht mehr, schließt er sie und sie wird zum Server zurückübertragen (upload). Anwendungsprogramm Server Open, close, read, write,... Clientmodul Upload/ Download Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.31 Bewertung des Upload/Download-Modell: Der Server bietet eine sehr einfache Schnittstelle zum Klientenmodul. Intern kennt der Server Zugriffe, um eine Datei sequentiell vom physikalische Speichermedium zu lesen bzw. darauf zu schreiben. Im Klientenmodul müssen alle Dateioperationen implementiert sein, auch ein Verzeichnismanagement. Der Klient benötigt ausreichend Platz zum lokalen Zwischenspeichern aller benötigten Dateien. Die Netzwerkverbindung wird nur beim Öffnen und Schließen von Dateien belastet, dann aber mit einem großen Volumen. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.32

17 Remote-Access-Modell alle Zugriffe eines Klienten auf eine Datei werden einzeln auf dem entfernten Server ausgeführt. Anwendungsprogramm Server Open, close, read, write,... Clientmodul Funktionsaufrufe Datentransfer Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.33 Bewertung des Remote-Access-Modells Die meiste Funktionalität liegt auf der Serverseite. Das Klientenmodul beschränkt sich meist auf ein reines Kommunikationsmodul. Die Schnittstelle zwischen Klient und Server benötigt viel Funktionalität. Das Netzwerk wird fortwährend belastet, allerdings mit jeweils kleinerem Volumen. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.34

18 Zustandslose und zustandsbehaftete Dateiserver Durch den Zugriff eines Klienten auf eine Datei ergeben sich dynamische Zustandsinformationen. z.b. welche Dateien sind durch welche Klienten geöffnet an welcher Stelle befindet sich der Positionszeiger einer Datei welche Sperren sind gesetzt Die Zustandsinformationen können wie folgt verwaltet werden auf Serverseite (zustandsbehafteter Dateiserver) Auf Clientseite (zustandsloser Server) Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.35 Vorteile eines zustandslosen Dateiservers Benötigt keinen Speicher für Klienteninformation Keine Operationen zum Öffnen/Schließen von Dateien da Server sich diese Information nicht merkt Realisierung eines fehlertoleranten Systems leichter ohne Austausch von Zustandsinformationen können Replikations- und Backupserver einfacher realisieren werden Absturz eines Klienten ist problemlos für den Server da keine verwaiste Information vorhanden ist. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.36

19 Vorteile eines zustandsbehafteten Dateiservers Bei Dateizugriff genügen kürzere Nachrichten keine Neuübertragung aller benötigten Klienteninformationen nötig Schreib- und Lesezugriffe sind effizienter Positionszeiger einer im Zugriff befindlichen Datei stehen z.b. bereits am richtigen Platz Precaching ist möglich, alle Dateien, die sich im Zugriff befinden, sind bekannt Server holt bereits Daten von seiner Platte, die der Klient noch gar nicht angefordert hat Intelligentes Precaching durch Kenntnis des Benutzungsprofils (z.b. benötigt ein Compiler immer seine Bibliotheksdateien) Dateisperren können vom Server unterstützt werden Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.37 D.3.2. Verzeichnisdienst Hauptaufgabe des Verzeichnisdienstes ist das Auflösen von Dateinamen. Der Dateiname ist auf einen Zeiger, der auf den physikalischen Speicherungsort der Datei auf der Festplatte zeigt, abzubilden. Um einen Dateinamen aufzulösen, muss man den zugehörigen Pfadnamen, der auch über mehrere Rechner verteilt sein kann, durchlaufen. Æ siehe Navigation in Namensräumen Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.38

20 Iteratives Durchlaufen von Pfadnamen Klient fragt beim Server, für den der erste Teil des Pfades passt, nach der Datei. Rückgabe Dateizeiger, oder, wenn nicht Teil des Verzeichnisbaums, Verweis auf weiteren Server. Dieses Vorgehen wiederholt der Klient, bis er den Zeiger auf die Datei erhält. Dann direkter Zugriff über den verwaltenden Server auf die Datei Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.39 Rekursives Durchlaufen von Pfadnamen Klientanfrage an den Server bezüglich einer Datei. Weitergabe der Anfrage an den nächsten Server mit der Information, welcher Klient die Anfrage gestellt hat Ist der gesamte Pfadname aufgelöst, schickt der letzte Server den gewünschten Dateizeiger zum Klienten zurück. Die Dateizugriffe können dann zwischen Klient und Server erfolgen. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.40

21 Integration mit netzwerkweitem Namensdienst Bei netzwerkweitem attributbasiertem Namensservice (Directory Service) findet die Auflösung des Wurzelverzeichnisses wie eine normale Namensauflösung statt, die Auflösung des Dateinamens erfolgt dann im lokalen Dateisystem Beispiele Novell NDS: Volumes (Partitionen) von Dateiservern sind in der NDS als Objekte sichtbar. Dateizugriff erfolgt über NDS Namen (z.b..cn=server_sys.ou=abteilung.o=firma:\directory\file) oder Zeiger auf Verzeichnisse (z.b..cn=zeigerobjekt.ou=abteilung.o=firma:file) Microsoft DFS mit Active Directory: Freigaben lokaler Rechner werden über Active Directory sichtbar gemacht Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.41 Caching und Konsistenz Caching im Arbeitsspeicher des Servers Caching auf der Festplatte des Clients Caching im Arbeitsspeicher des Clients Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.42

22 Caching im Arbeitsspeicher des Servers Befindet sich eine Datei bereits im Arbeitsspeicher des Servers, so wird bei erneutem Zugriff auf diese Datei der langsame Plattenzugriff eingespart. Clients müssen bei erneutem Zugriff wieder über das Netz auf den Server zugreifen Erhaltung der Konsistenz einfach zu gewährleisten, da sich die Datei nach wie vor auf der Serverseite befindet, Das Caching verläuft gegenüber dem Client transparent. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.43 Caching auf der Klientenplatte Der Klient legt benutzte Dateien als Cachekopie auf seiner lokalen Platte ab. Dies erspart bei erneutem Zugriff den Weg über das Netz. Die Erhaltung der Konsistenz von mehreren Cachekopien auf Klientenseite ist je nach Konsistenzmodell aufwendig. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.44

23 Caching im Arbeitsspeicher des Klienten Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.45 Caching im Klientenprozeß Jeder Klientenprozeß verwaltet seinen eigenen Cache. Die Caches anderer Prozesse sind dabei nicht sichtbar. Dieses Verfahren benötigt nur einen geringen Verwaltungsaufwand. Es ist speziell für Anwendungen geeignet, in denen eine Datei vom gleichen Prozeß mehrmals geöffnet und geschlossen wird oder lange in Benutzung ist. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.46

24 Caching im Betriebssystemkern Alle Prozesse teilen sich einen Cache, der vom Betriebssystem verwaltet wird. Der Cachespeicher kann größer dimensioniert werden, als bei den einzelnen Caches für jeden Prozeß. Mehrere Prozesse können von den Cacheinhalten profitieren, was eine höhere Trefferrate nach sich zieht. Jeder Dateizugriff ist ein Systemaufruf, auch bei einem Cachetreffer. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.47 Caching in einem Cachemanager Das Caching wird von einem speziellen Anwendungsprozess übernommen. Dadurch wird der Betriebssystemkern von spezifischem Dateisystem-Code freigehalten. Damit die Effizienz des Caches nicht durch Paging des Betriebssystems zunichte gemacht wird, sollte der Cachemanager das Auslagern seiner Cacheseiten sperren können. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.48

25 Cachekohärenz-Algorithmen Um den Inhalt eines lokalen Client-Caches und das Dateisystem auf dem Server in einem konsistenten Zustand zu halten, sind Cachekohärenz-Algorithmen notwendig Man unterscheidet Write Through Delayed Write Write-on-Close Unter Umständen wird hierbei eine Zentrale Koordinierung aller Client Caches benötigt Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.49 Write-Through Findet ein Schreibzugriff auf eine Datei statt, die im lokalen Cache steht, wird immer sowohl in den Cache, als auch in die Datei beim Server geschrieben. (Schreibzugriffe laufen quasi wie bei cachelosen Systemen ab) Beim Öffnen einer Datei aus dem Cache besteht die Möglichkeit, dass diese nicht mehr aktuell ist. Lösung: Klient überprüft beim beim Server die Aktualität oder der Server teilt seinen Klienten jeweils mit, wenn eine Datei woanders geändert wurde (Callback). Problematik besteht beim Lesen und evtl auch beim Schreiben Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.50

26 Delayed-Write Um häufige Server- und Netzwerkzugriffe zu sparen, werden Änderungen gesammelt und in Bursts zurückgeschrieben. Dadurch erhält man aber eine unklare, zeitabhängige Semantik. Write-on-Close Write-on-Close entspricht einer Sitzungs-Semantik. Durch verzögertes Write-on-Close kann ein nachfolgendes Löschen der Datei noch berücksichtigt und ein unnötiges Zurückschreiben verhindert werden. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.51 Zentrale Koordinierung Eine zentrale Koordinierungsstelle kennt alle Cacheeinträge aller Klienten. Dieser Koordinator wird von jedem Schreibzugriff in Kenntnis gesetzt und kann damit alle Klienten informieren, die eine betreffende Datei im Cache halten. (Callback) Diese Strategie ist weder robust gegen Ausfälle, noch gut skalierbar. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.52

27 Replikation Eine weitere Möglichkeit, die Leistung eines verteilten Dateisystems zu erhöhen, ist die Replikation von Daten auf verschiedenen Servern. Dadurch wird zudem eine bessere Zuverlässigkeit und Verfügbarkeit erreicht. Aufwändigere Cachekohärenzkontrolle für Client Caches Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.53 D.4. Beispiele für verteilte Dateisysteme NFS (Network File System) AFS (Andrew File System) Coda Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.54

28 Coda Entwickelt als experimentelles Filesystem an der Carnegie Mellon University (CMU), Pittsburg Basiert auf NFS (Network Filing System) von SUN Weiterentwicklung zu AFS (Andrew File System) Weiterentwicklung zu Coda Verfügbar unter Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.55 NFS Überblick Zugang zum NFS ist auf Programmebene transparent: Virtuelles Dateisystem schafft identische Aufrufschnittstelle zu NFS und zum lokalen Dateisystem. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.56

29 NFS Remote Mounting Ein Server bietet in der Datei /etc/exports eine Exporttabelle aller Verzeichnisse an, die er für NFS zur Verfügung stellt. Ein Klient hängt die gewünschten Verzeichnisse in seine eigene Verzeichnisstruktur durch den Aufruf eines Mount-Dienstes, der das VFS mit den entsprechenden Informationen versorgt Hard-Mounting eines entfernten Verzeichnisses: interaktiv durch den Benutzer (muss Supervisor-Rechte haben) Startupscript-Datei /etc/rc (autom. Mounting beim Hochfahren) Æ Ortstransparenz ist möglich, falls bei allen Klienten eine global eindeutige Verzeichnisstruktur angelegt ist. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.57 Soft Mounting über Automounter Replikation des Exports Verzeichnisses: Gewünschtes Verzeichnis von mehreren Servern als Export angeboten. Der Mountvorgang auf ein Verzeichnis geschieht erst zur Laufzeit. Beim Öffnen einer entfernten Datei werden vom NFS-Klienten alle Server angerufen. Zugriff erfolgt auf ersten Server, der sich zurückmeldet Konsistenzwahrung: Muss vom Systemverwalter geregelt werden. z.b. für Binärdateien ausführbarer Programme sinnvoll. Æ Durch Soft-Mounting läßt sich eine gewisse Toleranz gegenüber Serverausfällen erreichen. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.58

30 NFS Protokoll Das NFS-Protokoll ist für eine zustandslose Implementierung der NFS-Server ausgelegt. Jeder Auftrag an einen Server enthält sämtliche für die Bearbeitung notwendigen Informationen des Klienten und der Datei, welche der Klient bearbeitet. Im Protokoll ist kein Öffnen und Schließen von Dateien vorgesehen. Da die Server zustandslos arbeiten, ist also ein Absturz eines Klienten unkritisch. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.59 NFS Grundoperationen Neben Verwaltungsoperationen des Verzeichnisdienstes gibt es drei Grundoperationen: lookup (dirfilehandle, filename) Im angegebenen Verzeichnis wird die entsprechende Datei gesucht. Der Datei-Handle und die Attribute der Datei wer-den zurückgeliefert. read (filehandle, offset, count) In der angegebenen Datei werden ab der Position offset count Bytes geliefert. write (filehandle, offset, count, data) In der angegebenen Datei werden ab der Position offset count Bytes mit dem Inhalt von data beschrieben. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.60

31 Implementierungsaspekte Kommunikationssystem ist UDP mit Sun-RPC At-Most-Once-Semantik durch RPC sonstiger Protokolloverhead möglichst klein (UDP) Transfer zwischen Klient und Server in 8 KB Blöcken kleine und damit häufiger Pakete zu schicken ist ineffizienter der NFS-Klient liest zusätzlich den darauffolgenden Block Read-ahead-Caching hat eine hohe Trefferwahrscheinlichkeit. Delayed-Write: Schreibzugriffe werden verzögert, bis ein 8 KB großer Block zusammengekommen ist. Wird eine Datei geschlossen, werden sofort alle Änderungen zum Server geschickt. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.61 Caching Leistungssteigerung durch Caching Serverseite: Caching bereits gelesener Dateien im Speicher (transparent für den Client) write-through Semantik läßt keine Konsistenzprobleme auftreten. Clientseite: Cache für Datei-Handles und Cache für Dateien. keine Konsistenzwahrung, d.h die Inhalte werden nicht unter den Klienten abgeglichen Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.62

32 Öffnen einer Datei im Cache Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.63 Workarounds für Cache-Inkonsistenzen Öffnen einer Datei aus dem Klienten-Cache: Vergleich des lokalen Zeitstempels mit dem Modifikations- Zeitstempel beim Server Ist die Kopie älter, wird sie invalidiert und erneut geladen. Regelmäßige Aktualisierung des Klienten-Cacheinhalts: Jeder Cacheblock besitzt eine Uhr, die für Dateiblöcke nach 3 Sek. und für Verzeichnisse nach 30 Sek. ablaufen. Bei jedem Ablaufen wird beim Server auf Aktualität geprüft. Schreibzugriff: Entsprechender Block im Cache wird als dirty markiert. Markierte Blöcke werden alle 30 Sek. zum Server propagiert (sync) Æ Folgerung: der NFS-Klient kann erst nach 3 Sekunden bemerken, dass auf eine Datei gemeinsam schreibend zugegriffen wird. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.64

33 Bewertung Die Sharing-Semantik will sich an die Einzelkopie- Semantik anlehnen ist jedoch durch das periodische Aktualisieren unscharf. Daher sollte gemeinsamer Zugriff über eine externe Synchronisation geregelt werden z.b. durch Dateisperren. NFS ist ursprünglich für fünf bis zehn Stationen ausgelegt, die den gleichen Dateibaum benutzen. Skalierung auf größere Umgebungen nur bedingt sinnvoll. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.65 Ziele von AFS sehr hohe Skalierbarkeit (> Rechner) hohe Autonomie der Einzelstationen, Erzielung einer möglichst großen Fehlertoleranz AFS verwendet die Unix-Dateioperationen Sicherung der Kompatibilität zu bestehenden Anwendungen AFS ist zu NFS kompatibel AFS-Server verwenden das NFS-Protokoll für den Dateitransfer untereinander Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.66

34 Wichtige Konzepte bei AFS/Coda Whole-file Serving Nach dem Upload/Download-Prinzip werden Dateien komplett vom Server zum Klienten und zurück übertragen. Whole-file Caching Caching auf der Klientenplatte nach dem Least-Recently- Used-Verfahren. Die Cachegröße liegt bei mindestens 100 Megabyte, um hohe Trefferraten zu erzielen. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.67 Architektur von Coda (bzw. AFS) Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.68

35 Namensraum Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.69 Cell Organisatorischer Aufbau des AFS eine administrative Einheit, z.b. Abteilung oder Firma. Zellen können über Mounting mit anderen Zellen verbunden werden. Eine Zelle beinhaltet eine Ansammlung von Volumes. Volume Kollektion von zusammengehörenden Verzeichnissen, z.b. ein User Volume. Auf der Ebene von Volumes werden Zugriffsrechte verwaltet Verzeichnis, Datei Verzeichnisse und Dateien in den Volumes werden durch einen 96-bit Dateibezeichner eindeutig identifiziert. Der Identifikator besteht aus einer 32-bit Volumenummer, einem 32-bit v-node (entspricht NFS-Datei-Handle) und einem 32-bit Uniquifier. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.70

36 Dateizugriff Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.71 Semantik des gemeinsamen Dateizugriffs Öffnen einer entfernten Datei: Datei wird komplett in das lokale Verzeichnis /cache kopiert entspricht etwa einer Sitzungs-Semantik Weitere Lese- und Schreibzugriffe: erfolgen lokal, ohne Venus (lokaler Cachemanager) zu benötigen. Das heißt, dass alle lokalen Prozesse bezüglich dieser Dateizugriffe der Einzelkopie-Semantik unterliegen. Schließen der Datei: Geänderte Version wird auf den Server zurückgelegt. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.72

37 Cache Kohärenz AFS-1: Bei jedem Öffnen einer Datei aus dem Cache wurde anhand des Zeitstempels beim Server auf Aktualität geprüft. War die Datei geöffnet, wurde periodisch nachgefragt. Diese Lösung skaliert nur schlecht. seit AFS-2: Nicht nur Venus, sondern auch Vice, arbeiten zustandsbehaftet. Vice protokolliert alle Dateien mit, die ein Venus in seinem Cache hält. Wird eine Datei geändert, schickt Vice einen Callback an alle weiteren Venus, die diese Datei ebenfalls halten. Die notifizierten Venus können ihre Cachekopie daraufhin invalidieren. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.73 Fehlertoleranz Absturz und Neustart eines Klienten: Dateicache auf lokaler Festplatte ist immer noch aktiv Dateien im Cache evtl. nicht mehr aktuell: Venus muss die Zeitstempel aller gecachten Dateien zum Server(Vice) schicken, um die Aktualität prüfen zu lassen. Vice kann daraufhin seine Callback Promise aktualisieren und für die Dateien zu Venus valid oder cancelled schicken. Ausfall eines Vice: Vice gleichen sich untereinander ab. Im Fehlerfall keine vollständige Sitzungs-Semantik, da möglicherweise Callbacks im Netz verloren gehen. AFS unterstützt Dateisperren. Um wegen eines Fehlers Dateien nicht dauerhaft zu sperren, werden Sperren nach 30 Minuten wieder aufgehoben. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.74

38 Implementierungsaspekte und Bewertung Location Database auf Serverseite speichert, welche Volumes auf welchem Vice zu finden sind Jeder Vice verwaltet ein Replikat dieser Datenbank Implemtierung der Threads von Venus und Vice nicht-präemptiv Serialisierung bei nebenläufigen Zugriffen leichter zu realisieren Replikation Für Dateien oder Verzeichnisse, die vorwiegend nur gelesen werden, können mehrere Nur-Lese-Replikate angelegt werden. Es existiert aber serverseitig immer nur eine schreibbare Kopie. Dateiübertragung zwischen Klient und Server in 64 KB Blöcken Einfluß der Netzwerkverzögerung minimiert Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.75 Unterschied Coda / AFS Quelle: CMU Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.76

39 Konstante Datenverfügbarkeit in Coda Fehlertoleranz Bei AFS war durch einen Serverausfall der Dateizugriff blockiert. Dies soll verhindert werden. Replikation Auch schreibbare Dateien sollen replizierbar sein. Unterstützung portabler Geräte Möglichst alle benötigten Dateien sollen sich auf dem lokalen Rechner befinden und somit eine Abkopplung vom Netz erlauben (Partitionierung). Bei Wiederverbindung sollen unterschiedliche Versionen möglichst automatisch abgeglichen werden. Die Verfahren zur Replikation und Cachekohärenz sind der möglichen Netzwerkpartitionierung angepasst. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.77 Verwaltung der Netzpartitionierung Volume Storage Group (VSG) Gruppe von Servern, die ein Replikat eines Volumes halten. Die Replikation erfolgt immer in kompletten Volumes. Klient wendet sich zum Öffnen einer Datei an eine beliebige Untermenge der VSG. Available Volume Storage Group (AVSG) Die AVSG beinhaltet alle momentan erreichbaren Server aus der VSG. Quelle: CMU Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.78

40 Beeinflussen des Cacheeinhalts Sticky Files Venus versucht, immer die aktuelle Version bestimmter Dateien im lokalen Cache zu halten. Interaktives Kopieren Der Benutzer kopiert selbst Dateien in den Cache. Nutzungsprofil Ein Hilfsprogramm stellt das Nutzungsprofil eines Benutzers fest und kopiert selbständig die voraussichtlich benötigten Dateien in den Cache. Quelle CMU Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.79 Optimistische Replikation über Versionsvektoren Einsatz von Replikation bei gleichzeitiger Netzpartitionierung: Auf Replikate in disjunkten Partitionen wird unabhängig voneinander zugegriffen Konflikterkennung über Versionsvektor zu jeder Datei (engl.: Coda version vector, CVV). Aufbau dieses Vektors ähnlich der Vektorzeit Eintrag für jedes Replikat auf jedem Server aus der VSG Beispiel: Datei F liegt auf 3 Servern S1, S2, S3 Æ CVV F =(Version auf S1, Version auf S2, Version auf S3) Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.80

41 Update des CVV Klient aktualisiert und schließt eine Datei: Venus inkrementiert alle Elemente eines Test-CVV und schickt diesen an alle Server der AVSG Treten bei den Servern keine Konflikte mit den CVV von verschiedenen Klienten auf, schickt der bevorzugte Server eine positive Quittung an Venus. Venus berechnet daraufhin den neuen echten CVV und propagiert die geänderte Datei und den CVV an alle Server der AVSG. Über den Callback-Mechanismus werden dann alle erreichbaren Klienten über die neue Version informiert. Æ Bei Coda ist also der Klient für die Aktualisierung der CVV und der erreichbaren Replikate zuständig! Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.81 Problematik: Disjunkte AVSG Klienten aus verschiedenen AVSGs können unbemerkt voneinander dieselbe Datei verändern: Auffinden von Konfliktfällen durch Vektorenvergleich, wenn Server wieder alle erreichbar sind elementweiser Vergleich der CVVs größere Versionsnummern dominieren kleinere. Alle neuen Versionen werden in einem Covolume abgelegt und die Benutzer darüber informiert. Das Auflösen der Konflikte muß dann interaktiv durch die Benutzer erfolgen. Diese Fälle treten nur selten auf, da eine Datei eher selten von mehreren Benutzern aktualisiert wird Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.82

42 Cache Kohärenz Partitionierung des Netzes oder Serverausfall sind nicht vorhersehbar. Daher dynamische Anpassung notwendig Venus prüft dazu periodisch die AVSG-Zusammensetzung und spürt verlorengegangene Callbacks auf. Dies geschieht über einen Probe-Echo-Algorithmus: Venus sendet Probes an alle VSGs, von denen er Dateien hält. Die Echos enthalten einen Volume CVV (VCVV: eine Art Checksumme über alle CVV des Volumes) Anhand der VCVVs kann Venus feststellen, ob neu hinzugekommene Server neue Dateiversionen bei sich halten. Venus verhält sich dann pessimistisch und verwirft alle Dateien des gesamten Volumes. Die periodische Überprüfung findet ca. alle 10 Minuten statt. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.83 Besondere Maßnahmen bei der Veränderung der AVSG Erweiterung der AVSG Kommt ein neuer Server in die AVSG hinzu, werden alle Callbacks betroffener Volumes fallengelassen. Alle Dateien werden invalidiert, denn es könnte sich eine neue Version auf dem neuen Server befinden. Verkleinerung der AVSG Falls ein bevorzugter Server verloren geht, werden alle Dateien dieses Servers invalidiert. Bei erneuter Anforderung einer Datei wird ein anderer Server aus der AVSG als bevorzugter Server ausgewählt und dieser in Zukunft kontaktiert. Verlorener Callback Ging ein Callback verloren, wird die entsprechende Datei invalidiert. Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.84

43 Übungen / Verständnisfragen Priorisieren Sie die genannten Transparenzanforderungen an verteilte Dateisysteme. Begründen Sie Ihre Entscheidungen. Welche Vorteile/Nachteile aus Anwendersicht hat Remote Mounting gegenüber einer Superroot? Welche Informationen muß das Client-Modul halten, wenn der Server zustandslos implementiert wird (wie z.b. bei NFS)? Wodurch unterscheidet sich ein Servercache bei einem zustandslosen und zustandsbehafteten Fileserver? Welche Cacheverfahren sind jeweils bei den verschiedenen Semantiken des verteilten Dateizugriffs sinnvoll einsetzbar? Beschreiben schematisch die Funktionsweise eines verteilten Dateisystems mit Einzelkopie-Semantik. Betrachten Sie das System mit und ohne Client-Cache und überlegen Sie, welche Mechanismen jeweils im System vorhanden sein müssen, um Dateisharing zu ermöglichen und Konsistenz zu gewährleisten. Vergleichen Sie Coda Versionsvektoren (CVV) mit der Vektorzeit Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite D.85