Studiengang Informatik FHDW Vorlesung Betriebssysteme IV 2 Quartal

Studiengang Informatik FHDW Vorlesung: Betriebssysteme IV 2. Quartal 2003 Vorlesung: 1 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Gliederung Wiederholung Kommunikation in verteilten Systemen Einstieg: Problemstellung Rechte Berechtigungen anhand einer praktischen Implementation ISO/OSI-Referenzmodell Vergleich diverser Protokollstacks (TCP/IP. . . ) Einführung Netzwerkkomponenten und -technologien (globale) Verzeichnisdienste (NDS, AD, i. Planet) Synchronisation in verteilten Systemen Deadlocks in verteilten Systemen Prozesse und Prozessoren in verteilten Systemmodelle (das Workstation-Modell) Scheduling in verteilten Systemen Einführung in Netzwerkdienste Ausblick Vorlesung: 2 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

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. Vorlesung: 3 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Dateisystem Ist auf Einzelplatzrechnern die Schnittstelle zur Festplatte. Ein verteiltes Dateisystem ermöglicht es zusätzlich, auf entfernte Dateien zuzugreifen. Ein verteiltes Dateisystem ermöglicht es, plattenlose Geräte zu unterstützen. Verteilte Dateisysteme sind als Client/Server. System aufgebaut. Das Dateisystem bietet einem Klienten einen Dateidienst (engl. : file service) und wird von einem oder mehreren Dateiservern (engl. : file server) implementiert. Vorlesung: 4 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Transparenzanforderungen 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. Vorlesung: 5 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Transparenzanforderungen (2) Nebenläufigkeitstransparenz Greifen mehrere Klienten gleichzeitig auf eine Datei zu, soll kein Klient vom Zugriff anderer Klienten beeinflusst werden. 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. Vorlesung: 6 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Transparenzanforderungen (3) Lasttransparenz Die Anfragelast auf Serverseite soll sich nicht auf dessen Antwortzeiten auswirken. Lasttransparenz ist eine 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. Die Programmierschnittstelle des Dateisystems muß dazu vereinheitlicht über verschiedenen Betriebsystemen implementiert sein. Vorlesung: 7 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Transparenzanforderungen (4) Replikationstransparenz Der Klient darf immer nur eine logische Datei sehen, egal wie häufig und wo diese repliziert vorgehalten wird. Migrationstransparenz Verändert eine Datei ihren Speicherungsort, dann ist dies für den Klienten nicht sichtbar. Dateien werden eventuell dynamisch „in der Nähe“ von den Klienten gehalten, die häufig darauf zugreifen. Vorlesung: 8 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Transparenzanforderungen (5) Partitionierungstransparenz Das Dateisystem kann partitioniert werden, d. h. bestimmte Dateiserver sind nicht mehr zugreifbar für bestimmte Klienten. Trotzdem stehen für alle Klienten noch alle benötigten Dateien zur Verfügung. Eine Vereinigung bisher getrennter Partitionen erzeugt dabei möglichst keine Inkonsistenzen. Partitionierungstransparenz ist speziell für die Anbindung mobiler Rechner interessant. Nicht alle diese Anforderungen werden jedoch von den verfügbaren Systemen erfüllt. Vorlesung: 9 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Aufbau verteilter Dateisysteme Ein verteiltes Dateisystem ist konzeptionell in drei Komponenten gegliedert. Dateidienst Ist zuständig für die elementaren Operationen auf Dateien und deren Inhalt. Dies sind Funktionen, wie Lesen und Schreiben, Ändern niederwertiger Dateiattribute (z. B. : Längeninformation und Zeitstempel), Allokierung von Plattenblöcken, Plattenein- und ausgabe und Pufferung. Vorlesung: 10 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Aufbau verteilter Dateisysteme (2) Verzeichnisdienst Hier erfolgt die Abbildung von Dateinamen auf die binären Dateizeiger, das Verwalten der Dateien im meist hierarchischen Namensraum, der Test und das Ändern der Zugriffsrechte und anderer höherwertiger Dateiattribute, die Unterstützung und Umrechnung von symbolischen Verweisen oder Aliasen. Vorlesung: 11 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Aufbau verteilter Dateisysteme (3) Klientenmodul 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 Klientmodul kann in unterschiedlich komplexen Ausprägungen vorliegen: vom einfachen RPC-Stub, bis zu einem eigenen Dateisystem mit Cacheeinträgen aus dem verteilten Dateisystem. Vorlesung: 12 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Komponenten eines vert. Dateisystems Vorlesung: 13 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Sichtweisen auf verteilte Dateisysteme Die Sichtweise auf ein verteiltes Dateisystem definiert sich auch durch die Syntax der Dateinamen. Rechnername + Pfadname bzw. Servername + Pfadname Jeder Rechner oder Dateiserver hat seine eigene, von anderen Rechnern unabhängige Verzeichnisstruktur. Ein Dateiname wird durch Konkatenation aus Rechneroder Servernamen und dem Pfad im Dateiverzeichnis gebildet. Die Namengebung ist dadurch orts- oder serverabhängig. Rechnernamen sind beispielsweise die IP-Adresse Servernamen werden bspw. gebildet aus Portnummer und IP-Adresse. Vorlesung: 14 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Sichtweisen auf verteilte Dateisysteme (2) Gegeben seien drei autonome Dateiserver: Vorlesung: 15 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Sichtweisen auf verteilte Dateisysteme (3) 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 Namenstransparenz gegeben. Vorlesung: 16 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Sichtweisen auf verteilte Dateisysteme (4 a) Vorlesung: 17 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Sichtweisen auf verteilte Dateisysteme (4 b) Vorlesung: 18 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Sichtweisen auf verteilte Dateisysteme (5) Uniformer Namensraum durch Superroot Über alle lokalen Dateisysteme wird eine übergeordnete Wurzel gesetzt. Dadurch erreicht man sowohl eine Orts-, als auch Namenstransparenz. Vorlesung: 19 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Semantik des Dateisharing Greifen mehrere Prozesse auf eine Datei gemeinsam zu, entstehen Nebenläufigkeitsprobleme. Auf einem Einzelrechner ist es durch die zentrale Auslegung des Systems leicht möglich Lese- und Schreibzugriffe stets sequentiell geordnet zu halten z. B. durch einen einzelnen Dateipositionszeiger. Dies kann auf ein verteiltes Dateisystem übertragen werden, wenn auch hier eine zentrale Koordinierung durchgeführt wird. Wenn jedoch Caching und Replikation eingesetzt werden, versagt das Funktionsprinzip. Vorlesung: 20 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Semantik des Dateisharing (2) Eine Lösung der Sharing-Probleme ist es, generelles Sperren von Dateien durchzuführen. Greift ein Klient auf eine Datei zu, so sperrt er sie für den Zugriff anderer. Dies verhindert jedoch jegliche Parallelität. Vorlesung: 21 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Einzelkopie-Semantik Die Einzelkopie-Semantik wird oft auch als Unix. Semantik bezeichnet, da sie im UNIX-Dateisystem implementiert ist. Ein Lesezugriff auf eine Datei erhält immer das Ergebnis des zeitlich zuvorliegenden letzten Schreibzugriffs. Vorlesung: 22 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Einzelkopie-Semantik (2) Implementiert man einen zentralen Dateiserver, ist die Einzelkopie-Semantik leicht zu realisieren. Wenn die Klienten Dateien cachen, dann muss das Caching so implementiert werden, dass Verände-rungen einer Cachekopie sofort bei allen anderen Kopien sichtbar werden (write-through). Um die Netzunzulänglichkeiten auszugleichen, wird dazu z. B. eine virtuelle globale Zeit benötigt, durch die alle Schreib- und Lesezugriffe in eine kausale Ordnung gebracht werden. Die Einzelkopie-Semantik für verteilte Dateisysteme ist durch ihre zentrale Implementierung bzw. durch den Aufwand zur Konsistenzwahrung sehr ineffizient. Vorlesung: 23 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Sitzungs-Semantik Beim Öffnen einer Datei erhält der Klient eine eigene Kopie. Mit dieser Kopie arbeitet er bis zum Schließen der Datei. Dann wird diese zum Dateiserver zurückgeschrieben. Dateiänderungen sind für andere Klienten erst nach dem Schließen sichtbar. Probleme entstehen, wenn eine Datei bei mehreren Klienten gleichzeitig geändert wird. Vorlesung: 24 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Sitzungs-Semantik (2) Vorlesung: 25 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Sitzungs-Semantik (3) Versionenbehandlung: 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, es wird dann eine spezielle Namengebung für die Versionen benötigt. Vorlesung: 26 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

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. Greifen mehrere Klienten (lokal) schreibend auf eine gerade mehrfach gelesene Datei zu, entstehen mehrere Versionen. Es ergibt sich eine ähnliche Versionsproblematik wie bei der Sitzungs-Semantik. Vorlesung: 27 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Transaktions-Semantik Alle Zugriffe auf eine Datei werden als Transaktion aufgefaßt. Lese- und Schreiboperationen erfolgen in Begin. Transaction- und End. Transaction-Klammern. Die Dateien bleiben konsistent. Der Verwaltungsaufwand für transaktionsbezogene Dateizugriffe ist sehr hoch und damit das verteilte Dateisystem auch nicht sehr effizient. Falls Dateien als Datenbankersatz verwendet werden sollen, ist diese Semantik zwingend. Vorlesung: 28 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Implementierungsaspekte Nutzungsprofil eines verteilten Dateisystems Zu beachten: die Analyse hängt immer von der entsprechenden Umgebung ab. In Workstationumgebungen: Die Mehrheit aller Dateien ist klein. Die meisten Dateien sind kleiner als 10 Kilobyte, sie passen 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. Vorlesung: 29 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Implementierungsaspekte (2) Dateien werden häufiger gelesen als modifiziert: Die Effizienz lesender Zugriffe läßt sich gut mit Caching steigern. Im verteilten Dateisystem wird Caching effektiv eingesetzt werden können. 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: Der zusätzliche Overhead für die Konsistenzerhaltung des Caching auf Klientenseite kann zugunsten der kürzeren Antwortzeiten aufgegeben werden. Vorlesung: 30 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Implementierungsaspekte (3) Der durchschnittliche Prozeß benutzt wenige (und kleine) Dateien: Das Caching kann in den Arbeitsspeicher des Klienten verlagert werden. 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. Es gibt private Dateien, wie Mailboxen, die häufig verändert, aber nicht gemeinsam benutzt werden, sie können also nahe beim Klienten gehalten werden. Verteilte Dateisysteme könnten die unterschiedlichen Dateitypen mit unterschiedlichen Verfahren behandeln. Vorlesung: 31 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Architekturtypen Zugriffsmodelle Das Zugriffsmodell legt fest, in welcher Art die Dateioperationen und -zugriffe (auch auf Verzeichnisse) zwischen Klient und Server abgewickelt werden. 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). Vorlesung: 32 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Architekturtypen (2) Uplaod-/Download-Modell Vorlesung: 33 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Architekturtypen (3) Bewertung des Upload/Download-Modell: Der Server bietet eine sehr einfache Schnittstelle zum Kliententenmodul. 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. Vorlesung: 34 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Architekturtypen (4) Remote-Access-Modell: alle Zugriffe eines Klienten auf eine Datei werden einzeln auf dem entfernten Server ausgeführt. Vorlesung: 35 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Architekturtypen (5) Bewertung des Remote-Access-Modell: 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. Vorlesung: 36 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Architekturtypen (6) Zustandslose und zustandsbehaftete Dateiserver Durch den Zugriff eines Klienten auf eine Datei ergeben sich dynamische Zustandsinformationen: 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 auf Serverseite oder vom Klienten verwaltet werden. Bezeichnung: zustandsbehafteter bzw. zustandsloser Server. Vorlesung: 37 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Architekturtypen (7) Vorteile eines zustandslosen Dateiservers Benötigt keinen Speicher für Klienteninformation. Operationen zum Öffnen oder Schließen von Dateien sind unnötig, da sich diese Information nicht gemerkt werden kann. Das System kann leichter fehlertolerant realisiert werden, da sich ohne Austausch von Zustandsinformationen Replikations- und Backupserver einfacher realisieren lassen. Beim Absturz eines Klienten entstehen für den Server keine Probleme, da keine verwaiste Information vorhanden ist. Vorlesung: 38 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Architekturtypen (8) Vorteile eines zustandsbehafteten Dateiservers Kürzere Nachrichten genügen, um Zugriffe auf Dateien durchzuführen, da nicht mehr in jedem Zugriff alle benötigten Klienteninformationen übertragen werden müssen. Schreib- und Lesezugriffe sind effizienter, da z. B. die Positionszeiger einer im Zugriff befindlichen Datei bereits am richtigen Platz stehen. Es ist Precaching möglich, da alle Dateien bekannt sind, die sich im Zugriff befinden. Durch Precaching holt der Server bereits Daten der zugegriffenen Datei von seiner Platte, die der Klient noch gar nicht angefordert hat. Durch Kenntnis des Benutzungsprofils ist intelligentes Precaching realisierbar. Der Compiler benötigt beispielsweise immer seine Bibliotheksdateien. Dateisperren können vom Server unterstützt werden. Vorlesung: 39 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

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, muß man den zugehörigen Pfadnamen, der auch über mehrere Rechner verteilt sein kann, durchlaufen. Vorlesung: 40 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Verzeichnisdienst (2) Iteratives Durchlaufen: Der Klient fragt beim Server, für den der erste Teil des Pfades passt, nach der Datei. Kann dieser nicht den Zeiger auf die eigentliche Datei liefern, weil er nicht den gesamten benötigten Verzeichnisbaum bei sich hält, gibt er dem Klienten den Pfad und Server zurück, bei dem der Klient weiter nachfragen kann. Dieses Vorgehen wiederholt der Klient, bis er den Zeiger auf die Datei erhält. Dann kann der Klient direkt über den verwaltenden Server auf die Datei zugreifen. Vorlesung: 41 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Verzeichnisdienst (3) Der Navigationsalgorithmus ist vollständig auf Klientenseite implementiert. Als Kommunikationsmodell lassen sich entfernte Prozeduraufrufe (RPC) einsetzen. Vorlesung: 42 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Verzeichnisdienst (4) Rekursives Durchlaufen Der Klient stellt an den Server die Anfrage bezüglich einer Datei. Kann der Server die Anfrage nicht beantworten, so gibt er sie mit der Information, welcher Klient die Anfrage gestellt hat, an den nächsten Server weiter. 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. Vorlesung: 43 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Verzeichnisdienst (5) Wegen der Asymmetrie des Verfahrens kann die Kommunikation in diesem Fall nicht mehr über RPCs stattfinden. Es wird ein asynchrones Kommunikationsmodell benötigt. Vorlesung: 44 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Caching und Konsistenz 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. Der Zugriff über das Netz durch die Klienten bleibt jedoch erhalten. Da sich die Datei nach wie vor auf der Serverseite befindet, ist die Erhaltung der Konsistenz einfach zu gewährleisten. Das Caching verläuft gegenüber dem Klienten transparent. Vorlesung: 45 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Caching und Konsistenz (2) 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. Vorlesung: 46 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Caching und Konsistenz (3) Caching im Arbeitsspeicher des Klienten Untervarianten je nach Zuordnung des Cachespeichers: 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. Vorlesung: 47 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Caching und Konsistenz (4) 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. 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 seine Cacheseiten gegenüber der Auslagerung sperren können. Vorlesung: 48 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Caching und Konsistenz (5) Caching im Speicher des Klienten Vorlesung: 49 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Cachekohärenz-Algorithmen Um den Inhalt des Caches und das Dateisystem auf dem Server in einem konsistenten Zustand zu halten, sind Cachekohärenz-Algorithmen notwendig. Vorlesung: 50 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Cachekohärenz-Algorithmen (2) Write-Through Findet ein Schreibzugriff auf eine Datei statt, die im 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. Deswegen muß der Klient beim Server die Aktualität überprüfen, oder Server teilt jeweils seinen Klienten mit, dass eine Datei woanders geändert wurde. Je nach Sharingsemantik tritt dieses Problem auch beim Schreiben auf. Die Write-through-Strategie ist eher ungeeignet für verteilte Dateisysteme. Vorlesung: 51 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Cachekohärenz-Algorithmen (3) Delayed-Write Um häufige Server- und Netzwerkzugriffe zu sparen, werden Änderungen gesammelt und in Bursts zurückgeschrieben. Dadurch erhält man eine unklare, zeitabhängige Semantik. 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. Vorlesung: 52 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Cachekohärenz-Algorithmen (4) 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. Diese Strategie ist weder robust gegen Ausfälle, noch gut skalierbar. Vorlesung: 53 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

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. (Weitere Ausführungen siehe Kapitel "Replikation") Vorlesung: 54 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

SUN Network File System SUN NFS ist ein de facto Standard bei verteilten Dateisystemen. Ursprüngliches Ziel: verteiltes Dateisystem für heterogene Hardwareplattformen und Betriebssysteme. Die größte Verbreitung liegt in Unix-Umgebungen. Vorlesung: 55 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

NFS Architektur Die NFS-Klienten- und -Serversoftware ist jeweils in den Betriebssystemkern eingebunden. In den Unix-Implementierungen ist die Client/Server Relation symmetrisch, • d. h. Klienten können gleichzeitig Server sein und umgekehrt. Server und Klient kommunizieren über das NFSProtokoll. Als Abstraktionsschicht über den lokalen Dateisystemen und NFS liegt ein virtuelles Dateisystem VFS. Alle Dateioperationen eines Anwendungsprozesses werden durch das virtuelle Dateisystem ausgeführt Vorlesung: 56 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

NFS Architektur (2) VFS entscheidet, ob sich die Datei lokal oder entfernt befindet. Lokale Anforderungen werden an das lokale Dateisystem weitergereicht und von dort bedient. Bei entfernten Dateien wird der Aufruf an den NFSKlienten gegeben. Dieser kommuniziert dann über das Netzwerk mit dem NFS-Server, der den Aufruf entfernt bedient. NFS erlaubt es, plattenlose Klienten zu betreiben, die über kein eigenes lokales Dateisystem verfügen. Vorlesung: 57 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

NFS Architektur (3) Vorlesung: 58 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Virtuelles Dateisystem VFS enthält v-nodes (virtual nodes) als Datei. Handles, die auf i-nodes (Datei-Handles des lokalen Dateisystems) oder auf r-nodes (remote nodes) zeigen. Die r-nodes liegen im NFS-Klienten. r-nodes beinhalten die eigentlichen Datei-Handles, die vom entfernten Server geliefert wurden. Der Anwendungsprozeß erhält beim Öffnen einer Datei einen Dateideskriptor, der einem v-node im VFS zugeordnet ist. Um eine Datei physikalisch zu lokalisieren, muß das virtuelle Dateisystem eine mehrfach verzeigerte Struktur durchlaufen. Vorlesung: 59 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

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 Mount-Dienst versorgt das virtuelle Dateisystem mit den entsprechenden Informationen. Vorlesung: 60 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Remote Mounting Das Mounting eines entfernten Verzeichnisses erfolgt beim Klienten entweder interaktiv durch den Benutzer, der dazu jedoch Supervisor-Rechte haben muß, oder alle gewünschten Mountaufrufe sind in der Startupscript. Datei /etc/rc gespeichert. Dann wird das Mounting beim Hochfahren des Systems durchgeführt. Syntax: mount (server, directoryname, mountpoint) Der Server schickt den Datei-Handle des Verzeichnisses zum Klienten. Der Datei-Handle beinhaltet den Dateisystemtyp, die angesprochene Platte, die i-node Nummer der Datei bzw. des Verzeichnisses und die Schutzbits. Die Verwaltung dieser Datei-Handles liegt bei VFS. Vorlesung: 61 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Remote Mounting Hard-Mounting blockiert im Fehlerfall. Deshalb gibt es Soft-Mounting: Ein gewünschtes Verzeichnis wird von mehreren Servern als Export angeboten (Toleranz bei einem Serverausfall). Der Mountvorgang auf ein Verzeichnis geschieht erst zur Laufzeit. Beim Öffnen einer entfernten Datei werden vom NFSKlienten alle Server angerufen. Der erste Server, der sich zurückmeldet, wird für den entfernten Zugriff verwendet. Der dafür zuständige Dienst nennt sich Automounter. Die Konsistenz der Replikation auf den verschiedenen Servern muß vom Systemverwalter geregelt werden. Dieser Dienst ist z. B. für Binärdateien ausführbarer Programme sinnvoll. Vorlesung: 62 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

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. Vorlesung: 63 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

NFS Protokoll (2) 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 werden 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. Vorlesung: 64 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

NFS Protokoll (3) Die Protokolle für das Mounting, sowie für den Verzeichnis- und Dateizugriff werden über Sun. RPC abgewickelt. Die Authentisierung der Klienten kann über öffentliche Schlüssel (aus dem Network Information Service, NIS) zusätzlich stärker geschützt werden, als es die üblichen Zugriffskontrollbits (rwx) zulassen. Vorlesung: 65 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

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 Kilobyte 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. Vorlesung: 66 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Implementierungsaspekte (2) Durch Delayed-Write werden Schreibzugriffe verzögert, bis ein 8 Kilobyte großer Block zusammengekommen ist. Wird eine Datei geschlossen, werden sofort alle Änderungen zum Server geschickt. Vorlesung: 67 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Caching Die Server cachen für die NFS-Klienten transparent schon gelesene Dateien in ihrem Speicher. write-through Semantik läßt keine Konsistenzprobleme auftreten. Die Klienten führen einen Cache für Datei-Handles und einen Cache für Dateien. ohne Konsistenzwahrung, d. h die Inhalte werden nicht unter den Klienten abgeglichen. Vorlesung: 68 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Caching (2) Work-Around Lösungen sollen Inkonsistenzen vermeiden: Ist eine Datei beim Öffnen im Cache des Klienten, wird der lokale Zeitstempel mit dem Modifikations-Zeitstempel beim Server verglichen. Ist die Kopie älter, wird sie invalidiert und erneut geladen. 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. Beim Schreibzugriff wird der entsprechende Block im Cache als „dirty“ markiert. Die markierten Blöcke werden alle 30 Sek. zum Server propagiert (sync). Vorlesung: 69 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Caching (3) Folgerung: Der NFS-Klient kann erst nach 3 Sekunden bemerken, dass eine Datei gemeinsam schreibend zugegriffen wird. Dies kann dem Anwendungsprogramm gemeldet werden (leider nur selten benutzt). Meist werden Dateisperren eingesetzt, falls es potentiell zu gemeinsamen Zugriffen kommen könnte. Dies wird von NFS nicht unterstützt und muß durch einen separaten Dienst erbracht werden. Vorlesung: 70 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Bewertung Der Zugang zum NFS ist auf Programmebene transparent: Die Aufrufschnittstelle ist durch das virtuelle Dateisystem identisch zur Schnittstelle zum lokalen Dateisystem. Ortstransparenz ist möglich, falls bei allen Klienten eine global eindeutige Verzeichnisstruktur angelegt ist. NFS ist nicht tatsächlich fehlertransparent. Die Server arbeiten zustandslos, also ist ein Absturz eines Klienten unkritisch. Durch den Einsatz des Automounters kann der Ausfall eines Servers kompensiert werden. Zur Leistungssteigerung findet Caching auf Klienten - und Serverseite statt. Es gibt keine vom System unterstützte Replikation. Vorlesung: 71 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Bewertung (2) Die Sharing-Semantik will sich an die Einzelkopie. Semantik anlehnen ist jedoch durch das periodische Aktualisieren unscharf. Der gemeinsame Zugriff sollte deshalb ü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. Die Skalierung auf größere Umgebungen ist nur bedingt sinnvoll. Vorlesung: 72 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Andrew File System (AFS) AFS wurde im Rahmen des Andrew Projekts an der Carnegie-Mellon University entwickelt. Ziel des Gesamtprojekts: Den Studenten an allen Rechnern der Universität den Zugang zur gleichen Umgebung ermöglichen. AFS ist hierzu eine wesentliche Basis. AFS-2 hat Produktstandard und ist public domain verfügbar. Ziele von AFS: Sehr hohe Skalierbarkeit (>10. 000 Rechner) Hohe Autonomie der Einzelstationen, um eine möglichst große Fehlertoleranz zu erzielen. Vorlesung: 73 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Andrew File System (2) AFS verwendet die Unix-Dateioperationen um die Kompatibilität zu den bestehenden Anwendungsprogrammen zu sichern. AFS ist zu NFS kompatibel, da die AFS-Server das NFS-Protokoll für den Dateitransfer untereinander verwenden. Vorlesung: 74 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Wichtige Konzepte • Whole-file Serving Nach dem Upload/Download-Prinzip werden Dateien komplett vom Server zum Klienten und zurück übertragen. Whole-file Caching auf der Klientenplatte nach dem Least-Recently. Used-Verfahren. Die Cachegröße liegt bei mindestens 100 Megabyte, um hohe Trefferraten zu erzielen. Vorlesung: 75 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

AFS-Architektur Klientenkomponente Venus, Serverkomponente Vice Beide Komponenten sind als User-level-Prozesse realisiert, in späteren Versionen wird ein Teil von Venus auch im Kern geladen. Alle Aufrufe zum Öffnen oder Schliessen einer Datei werden im Kern abgefangen, an Venus weitergeleitet und dort behandelt. Die anderen Aufrufe gehen direkt an das lokale Dateisystem. Um mehrere Anfragen nebenläufig beantworten zu können, sind Venus und Vice multi-threaded implementiert. Vorlesung: 76 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

AFS-Architektur (2) Vorlesung: 77 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

AFS-Architektur (3) Die Kommunikation zwischen Venus und Vice basiert auf einem RPC-System, das direkt über IP aufgesetzt ist. Der Namensraum im AFS entspricht einem Namensraum des Unix-Dateisystems. Bei AFS wird der Namensraum in einen lokalen und einen gemeinsamen Dateibaum aufgeteilt. Vorlesung: 78 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

AFS-Architektur (4) Der gemeinsame Teil, der über den Pfad /afs erreicht wird, liegt in der Verwaltung von AFS. Hier liegen alle Dateien, bis auf wenige spezifische Dateien, die lokal Konfigurationen speichern. Entfernte Verzeichnisse können über symbolische Verweise in den lokalen Dateibaum eingebunden werden. Die Cacheeinträge legt Venus im Verzeichnis /cache ab. Zugriffe auf Dateien, die bereits im Cache liegen, erfolgen transparent, ohne dass der Name entsprechend angepasst werden muss. Vorlesung: 79 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

AFS-Architektur (5) AFS Namensraum und Verzeichnisstruktur Vorlesung: 80 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Semantik und Implementierung Der organisatorische Aufbau des AFS kennt drei Elemente: Cell 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. Vorlesung: 81 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Semantik und Implementierung (2) Die Semantik des gemeinsamen Zugriffs auf eine Datei ist nahe bei der Sitzungs-Semantik. Beim Öffnen einer entfernten Datei wird die Datei komplett in das lokale Verzeichnis /cache kopiert. Alle weiteren Lese- und Schreibzugriffe erfolgen lokal, ohne Venus zu benötigen. Das heißt, dass alle lokalen Prozesse bezüglich dieser Dateizugriffe der Einzelkopie-Semantik unterliegen. Wird die Datei wieder geschlossen, wird die geänderte Version auf den Server zurückgelegt. Vorlesung: 82 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Cache Kohärenz In der ersten Implementierung, AFS-1, wurde bei jedem Öffnen einer Datei aus dem Cache 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’, diese Datei ebenfalls halten. Die notifizierten Venus’ können ihre Cachekopie daraufhin invalidieren. Vorlesung: 83 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

AFS Zugriffsprotokoll Vorlesung: 84 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

AFS Zugriffsprotokoll (2) Vorlesung: 85 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Fehlertoleranz Stürzt ein Klient ab und fährt anschließend wieder hoch, dann ist sein AFS-Dateicache immer noch aktiv, da sich dieser auf einer lokalen Festplatte befindet. Nachdem in der Zwischenzeit Dateien im Cache nicht mehr aktuell sein müssen, muss Venus die Zeitstempel aller gecachten Dateien zu 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. Vorlesung: 86 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Fehlertoleranz (2) Bei Ausfall eines Vice gleichen sich die Vice untereinander ab. Es ist im Fehlerfall keine vollständige Sitzungs. Semantik gegeben, 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. Vorlesung: 87 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Implementierungsaspekte und Bewertung Auf Serverseite wird eine Location Database gehalten. Jeder Vice verwaltet ein Replikat dieser Datenbank, in der gespeichert ist, welche Volumes auf welchem Vice zu finden sind. Die Threads von Venus und Vice sind nicht-präemptiv implementiert, um leichter die Serialisierung bei nebenläufigen Zugriffen zu realisieren. 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. Vorlesung: 88 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Implementierungsaspekte, Bewertung (2) Zwischen Klienten und Servern werden Dateien in 64 Kilobyte Blöcken übertragen. Hierdurch wird der Einfluß der Netzwerkverzögerung minimiert. Es konnte gezeigt werden, dass ein AFS-Server mit 18 Klienten nur 40% der Zeit eines NFS-Servers benötigt, obwohl die AFS Version vollkommen als User-Level Implementierung lief. Vorlesung: 89 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Coda ist eine Weiterentwicklung des Andrew File Systems. Ziel: „konstante Datenverfügbarkeit“: Fehlertoleranz: Bei AFS ist 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. Bei Wiederverbindung sollen unterschiedliche Versionen möglichst automatisch abgeglichen werden. Vorlesung: 90 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Coda (2) Die Architektur besteht aus Venus und Vice wie bei AFS. Die Verfahren zur Replikation und Cachekohärenz sind der möglichen Netzwerkpartitionierung angepasst. Vorlesung: 91 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Verwaltung der Netzpartitionierung Bei Coda stellt die Netzpartitionierung nicht einen Fehlerfall, sondern den Normalfall dar. Portable Rechner sind häufig nicht im Netzwerk integriert, während darauf Dateien bearbeitet werden. Volume Storage Group: Die VSG ist die Gruppe von Servern, die alle ein Replikat eines Volumes halten. Die Replikation erfolgt immer in kompletten Volumes. Ein Klient, der eine Datei öffnen möchte, kann sich an eine beliebige Untermenge der VSG wenden. Available Volume Storage Group: Die AVSG beinhaltet alle momentan erreichbaren Server aus der VSG. Vorlesung: 92 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Verwaltung der Netzpartitionierung (2) Venus verwaltet zu allen Volumes die momentane AVSG. Diese Menge wird immer periodisch aktualisiert. Innerhalb jeder AVSG gibt es einen bevorzugten Server, der für Anfragen angesprochen wird. Ist die AVSG leer, wechselt Venus in die Disconnected Operation und arbeitet vollständig aus dem lokalen Cache. Die periodische Validierung der Cacheinhalte über Callbacks wird auf den Zeitpunkt der Wiederverbindung verschoben. Vorlesung: 93 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Verwaltung der Netzpartitionierung (3) Der Inhalt des Caches kann über das LRUVerfahren hinaus beeinflußt werden: Sticky Files: Dateien, die sich immer im Cache befinden sollen, können als „sticky“ deklariert werden. Venus versucht, immer die aktuelle Version dieser 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. Vorlesung: 94 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Replikation über Versionsvektoren Durch den Einsatz von Replikation, bei gleichzeitiger Möglichkeit der Netzpartitionierung, wird es vorkommen, dass Replikate in disjunkten Partitionen vorhanden sind und dort unabhängig voneinander zugegriffen werden. Zur Konflikterkennung verwaltet Coda zu jeder Datei einen Versionsvektor (engl. : Coda version vector, CVV). Dieser Vektor ist ähnlich der Vektorzeit aufgebaut. Er enthält für jeden Server aus der VSG dieser Datei einen Eintrag. Das heißt, dass für jedes Replikat ein Eintrag im CVV vorgesehen ist. Vorlesung: 95 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Replikation über Versionsvektoren (2) Aktualisiert und schließt ein Klient eine Datei, inkrementiert Venus alle Elemente eines „Test-CVV“, die einen Server aus der AVSG repräsentieren. Danach wird der „Test-CVV“ an alle Server der AVSG geschickt. Treten bei den Servern keine Konflikte mit den CVV von verschiedenen Klienten auf, schickt der bevorzugte Server eine positive Quittung an Venus berechnet daraufhin den neuen „echten“ CVV und propagiert die geänderte Datei und den CVV an alle Server der AVSG. Vorlesung: 96 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Replikation über Versionsvektoren (3) Über den Callback-Mechanismus werden nun 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. Ein Problem kann bei disjunkten AVSG auftreten, da Klienten aus verschiedenen AVSGs unbemerkt voneinander, dieselbe Datei verändern können. Vorlesung: 97 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Beispiel CVV Eine Datei F liegt auf den Servern S 1, S 2 und S 3. CVVF = (Version auf S 1, Version auf S 2, Version auf S 3). Zu Beginn ist CVVF = (0, 0, 0). Die Klienten C 1 und C 2 öffnen F. Dannach wird das Netz partitioniert und es sei AVSGC 1={S 1, S 2} und AVSGC 2={S 3}. Vorlesung: 98 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Beispiel CVV, Fall 1 C 1 verändert F: CVVF=(1, 1, 0), • C 2 nimmt keine Veränderungen vor: CVVF=(0, 0, 0). Später sind wieder alle Server erreichbar. Es muß nun ein Abgleich der verschiedenen CVVs durch elementweisen Vergleich stattfinden. Größere Versionsnummern dominieren kleinere. Da hier kein Konflikt auftritt, müssen nur die Server untereinander die Versionen abgleichen. Dies geschieht für die Klienten transparent. Vorlesung: 99 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Beispiel CVV, Fall 2 C 1 verändert F: CVVF=(1, 1, 0), • C 2 verändert ebenfalls F: CVVF = (0, 0, 1). Es sind zwei verschiedene neue Versionen entstanden. Nachdem wieder alle Server erreichbar sind, werden Konfliktfälle durch den Vektorenvergleich gefunden. 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. Vorlesung: 100 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Cache Kohärenz Die Partitionierung des Netzes oder Ausfall eines Servers sind nicht vorhersehbar. Es muß deswegen eine dynamische Anpassung stattfinden. Venus prüft dazu periodisch die AVSGZusammensetzung und spürt verlorengegangene Callbacks auf. Dies geschieht über einen Probe-Echo. Algorithmus, bei dem Venus Probes an alle VSGs schickt, von denen er Dateien hält. Die Echos enthalten einen Volume CVV, eine Art Checksumme über alle CVV des Volumes. Vorlesung: 101 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Cache Kohärenz (2) 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. Vorlesung: 102 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Cache Kohärenz (3) 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. Vorlesung: 103 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Vorlesung: 104 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Vorlesung: 105 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Vorlesung: 106 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Vorlesung: 107 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Vorlesung: 108 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

Vorlesung: 109 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg

ENDE Fragen? Vorlesung: 110 Betriebssysteme IV 2003 Prof. Dr. G. Hellberg