Verteilte Dateisysteme 10.1 Transparenter Zugriff auf nicht-lokale Dateien
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
10. Verteilte Dateisysteme
10.1 Transparenter Zugriff auf nicht-lokale Dateien
• Beispiel: Windows Dateifreigabe:
- Client für Microsoft Netzwerke:
o Remote Volumes werden sichtbar,
o Rechner im Netz werden sichtbar,
o integriert im Explorer.
- Dateiangebot über Servermodul:
o Zugriffstransparenz für Programme,
o Redirector im Betriebssystem,
o keine Namenstransparenz,
o byteweiser Zugriff ...
- Explizite Freigabe:
o Zugriffsrechte definierbar,
o Lesen, Schreiben, ...
267 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner• Im Idealfall besitzen verteilte Dateisysteme nachfolgende Eigenschaften.
• Zugriffstransparenz:
- Zugriff auf entfernte Dateien erfolgt mit gleichen Operationen, wie Zugriff auf lokale Dateien.
- Somit bleibt die Verteilung den Klienten verborgen.
Open/Close
• Ortstransparenz: Read/Write
- Es spielt keine Rolle, an welchem physikalischen
Ort eine Datei gespeichert ist.
- Dateien können beliebig verlagert werden
ohne dass der Benutzer davon betroffen ist.
• Nebenläufigkeitstransparenz:
- Keine Inkonsistenzen durch simultane Zugriffe.
- Schreibzugriffe sind hierbei aber problematisch.
- I.d.R. werden Sperren verwendet, wodurch die
Nebenläufigkeitstransparenz verloren geht.
• Fehlertransparenz:
- Es sollte sichergestellt sein, dass nach Ausfall eines Klienten
oder Servers der Dateibetrieb wieder korrekt weiterlaufen kann.
• Leistungstransparenz:
- Verzögerungen infolge entfernten Zugriffs sollten gering und unabh. von der akt. Last sein.
268 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.2 Kopplung von Namensräumen
• Zugriff auf Dateien mit: Servername + Dateiname Æ ortsabhängig.
• "Mounting" von entfernten Verzeichnissen unter Unix:
- i.d.R. individuell pro Knoten Æ keine Namenstransparenz.
Station A Station B
mount
point
• Namens- und Ortstransparenz mithilfe einer Superroot ("\"), aufgesetzt
über alle lokale Dateisysteme (Æ M. Weber).
269 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.3 Semantik verteilter Dateizugriffe
• One Copy Semantik (Unix):
- alle Änderungen werden sofort sichtbar,
- es existieren keine Kopien der Datei,
- eventuell sehr grosse Latenzzeiten,
- entspricht strikter Konsistenz.
• Sitzungs-Semantik:
- Klient meldet Dateizugriff an und erhält
Kopie,
- Modifikationen werden erst beim Close sichtbar,
- Versionsproblem, falls mehrere Klienten gleichzeitig Datei schreiben,
- Lösung: letzte Version gewinnt, Abstimmungsverfahren zw. Klienten, Server mischt geeignet.
• Read-Only Semantik:
- Idee: Datei wird einmal geschrieben und bleibt dann unveränderlich,
- Schreibzugriffe eines Klienten erfolgen atomar u. erzeugen eine neue Datei,
- Erleichtert die Replikation, aber die Versionsproblematik ist wieder gegeben.
• Transaktionssemantik:
- Zugriffe auf eine Datei werden in eine oder mehrere Transaktionen gebündelt,
- ein Transaktionsmonitor garantiert ACID Eigenschaft,
- erfordert Verwaltungsaufwand.
270 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.4 Nutzungsprofil
• Achtung: Analyse hängt immer von der entsprechenden Umgebung ab.
• Hier für Workstationumgebungen (M. Weber).
• Mehrheit aller Dateien ist klein:
- Die meisten Dateien sind kleiner als 10 Kilobyte.
- Sie passen komplett in ein einzelnes Netzwerk-Paket.
- Es ist besser gesamte Datei zum Klienten übertragen, als
Schreib- und Leseoperationen einzeln über das Netz abzuwickeln.
• Dateien werden häufiger gelesen als modifiziert:
- Im verteilten Dateisystem ist Caching effektiv möglich.
• Viele Dateien haben eine kurze Lebensdauer:
- 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.
• Der durchschnittliche Prozeß benutzt wenige (und kleine) Dateien:
- Das Caching kann in den Arbeitsspeicher des Klienten verlagert werden.
271 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner• Es gibt Dateiklassen mit spezifischer Charakteristik:
- Dateien, die ausführbare Programme speichern, werden nur gelesen, jedoch von vielen
Klienten. Æ Sie können also einfach 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önnen unterschiedliche Dateitypen mit
unterschiedlichen Verfahren behandeln.
272 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.5 Zustandslose und zustandsbehaftete Dateiserver
• Dynamische Zustandsinformationen:
- resultieren aus Zugriff eines Klienten auf eine Datei,
- z.B. welche Dateien sind durch welche Klienten geöffnet,
an welcher Stelle ist der Positionszeiger einer Datei,
welche Sperren sind gesetzt, ...
- Frage: Wo werden diese Zustandsinformationen verwaltet (Server oder Klient)?
• Vorteile eines zustandslosen Dateiservers:
- Benötigt keinen Speicher für Klienteninformation.
- Operationen zum Öffnen oder Schließen von Dateien überflüssig.
- Fehlertoleranz einfacher realisierbar, da keine Zustandsinformation
zwischen den (Backup-)Servern synchronisiert werden muss.
- Beim Absturz eines Klienten entstehen für den Server keine Probleme,
da keine verwaiste Information vorhanden ist.
• Vorteile eines zustandsbehafteten Dateiservers:
- Nachrichten kleiner, da keine Klienteninfo. mit jedem Zugriff übertragen werden muss.
- Schreib- und Lesezugriffe sind effizienter, da z.B. die Positionszeiger
einer im Zugriff befindlichen Datei bereits am richtigen Platz stehen.
- Precaching auf Server möglich, da alle Dateien bekannt sind, die sich im Zugriff befinden.
- Dateisperren können vom Server unterstützt werden.
273 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.6 Caching und Replikation 10.6.1 Server caching: • Pufferung nur im Hauptspeicher des Servers, • Eliminiert nur die Disktransferzeiten, • Aus Klientensicht nur eine Kopie, • Klient schreibt immer "durch", • Keine Konsistenzprobleme, • Probl. Latenz des Netzes. 274 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
10.6.2 Replikation von Dateien
• Zielsetzung:
- Verteilung der Last auf mehrere Server,
- Absicherung gegenüber Datenverlust,
- Absicherung gegen Serverausfälle.
• Strikte Replikationskontrolle:
- "Lock/unlock" entsprechend der Dateioperation,
- "Invalidate" für ungültig gewordene Kopien,
- "Update" zur sofortigen Aktualisierung,
• Schwache Replikationskontrolle:
- Schreiboperationen auf die primäre Kopie,
- Verzögerte Ausbreitung der Änderung,.
• Abstimmungsverfahren (Voting):
- zwischen den Servern bzgl. verschied. Versionen.
K
Koonnssiisstteennzzpprroottookkoollll,,
R
Reepplliikkaattiioonnsskkoonnttrroollllee
275 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.6.3 Client caching
KKoonnssiisstteennzz--
• Eliminiert Plattenzugriffe und Nachrichtentransport. pprroottookkoollll
• Verschiedene Konsistenzprotokolle möglich:
- zentrale Vergabe der Zugriffsrechte beim Server,
- verschiedene Durchschreibestrategien:
o sofortiges Durchschreiben auf den Server,
o verzögertes Durchschreiben auf Server,
o zurückschreiben beim Close der Datei,
- eventuell Dateityp berücksichtigen.
• Unterbringung des Puffers:
- im Benutzeradressraum,
- im Betriebssystemkern,
- in separatem Prozess,
- auf Festplatte?
276 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.7 Network File System
10.7.1 Eigenschaften
• NFS = Network File System von SUN, 1985.
- zum Export lokaler Verzeichnisse.
- verwendet intern RPC.
- Klienten für Unix, MacOS und Windows.
• Zugriffstransparenz:
- Programme können Zugriffe auf lokale und entfernte Dateien in gleicher Weise durchführen.
• Ortstransparenz:
- Dateisysteme oder Teile davon werden zum Export angeboten,
- Klient gibt an, an welcher Stelle im lokalen Verzeichnis das
importierte Dateisystem eingehängt wird (mount point).
- Falls bei allen Klienten gleiche Verzeichnisstruktur
realisiert wird ist die Ortstransparenz gegeben.
• Nebenlfg.transparenz: rudimentäre Sperrmechanismen Æ nicht gegeben.
• Fehlertransparenz: gegeben, NFS-Server (V3) sind zustandslos.
• Leistungstransparenz: hängt von der aktuellen Last ab.
277 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.7.2 Virtuelles Dateisystem in Unix
• = VFS, dient als allgemeine Schnittstelle.
- Verdeckt verschied. lokale Dateisysteme und Zugriff auf entfernte Verzeichnisse & Dateien.
- VFS unterhält für jede geöffnete Datei einen Eintrag (v-node) Æ enthält entweder den
lokalen Dateideskriptor (i-node) oder einen globalen NFS-Deskriptor (r-node), ...
• Das dynamische Einhängen (und Abhängen) von importierten Verz.
wird von einem spez. Programm, dem Automounter, durchgeführt.
278 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.7.3 NFS-Protokoll
• Protokoll (V3) zw. Klient und Server ist zustandslos
Æ Server merkt sich nichts über Klient.
• NFS-Server bietet 15 Operationen an, die vom Client aufgerufen werden
können, darunter:
- lookup(dirfh, name) → fh, attr
liefert Dateideskriptor und Dateiattribute 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, Start bei offset
- write(fh, offset, count, data) → attr
schreibt count Zeichen in Datei fh, Start bei offset.
• Nicht vorgesehen sind Dateioperationen wie open, close oder lock, da
sie der Zustandslosigkeit des NFS-Dienstes widersprechen.
• Bem: Die Zustandslosigkeit erleichtert die Fehlererholung.
279 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. SchöttnerSperren
• Notwendig, um gemeinsame Nutzung (insbesondere Schreibzugriffe)
von Dateien zu koordinieren.
• Sperren für ganze Datei oder nur Teilbereiche.
• Implementierung von Sperren in NFS Version 3:
- eigener Dienst verwaltet gesperrte Dateien.
- Klienten müssen über Sperrdienst zugreifen.
• Implementierung von Sperren in NFS Version 4:
- integriert in NFS-Operationen
- zusätzlich: Reservierungsoperationen,
• NFS V4 ist damit nicht mehr zustandslos.
- Problem: Absturz, während Sperre gehalten wird.
- Fehlererholung aufwendiger Æ Lösg.: Sperren mit Leases (laufen nach gewisser Zeit ab).
280 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. SchöttnerCaching
• Sitzungssemantik.
• Server cachen für die NFS-Klienten transparent schon
gelesene Dateien in ihrem Speicher.
• Klienten verwenden Cache, wobei dieser nicht mit
anderen Klienten abgeglichen wird:
- Ist eine Datei beim Öffnen im Cache des Klienten, wird der lokale
Zeitstempel mit dem Modifikations-Zeitstempel beim Server verglichen.
- Ist 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.
- Dann wird beim Server auf Aktualität geprüft.
- Beim Schreibzugriff wird der entsprechende Block im Cache als „dirty“ markiert.
- Markierte Blöcke werden alle 30 Sek. zum Server propagiert (sync).
281 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.7.4 Konfiguration
• Freigabe durch zentrale Konfigurationsdatei /etc/exports:
- steuert, welche Rechner auf welche Verzeichnisse wie zugreifen dürfen.
- Beispiel:
/usr/local 192.168.0.2(ro) *.sol(ro)
/usr/share saturn.sol(rw)
• Abfrage welche Clients Verzeichnisse verwenden mit Befehl
showmount –a.
• Einbinden eines NFS-Verzeichnisses:
mount –t nfs uranus:/usr/local /test
• Dateizugriff wird wie gewohnt geprüft:
- also per UID und GID,
- globale Benutzerverwaltung sinnvoll Æ NIS oder besser LDAP verwenden.
282 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.8 Coda File System
10.8.1 Entwicklung und Ziele
• Entwicklung von Coda:
- Coda ist ein verteiltes Dateisystem,
- wird seit 1990 an der CMU entwickelt,
- Weiterentwicklung von Andrew File System (AFS),
- funktioniert unter vielen Unix Betriebssystemen, z.B. Linux.
• Unterschiede zu NFS:
- hohe Verfügbarkeit, auch wenn kein Dateiserver erreichbar ist,
- ausgereifte Caching Verfahren.
• Ziele von Coda:
- soll für den Anwender wie ein lokales Dateisystem erscheinen,
- Ausfallstransparenz durch hohe Verfügbarkeit,
- Orts- und Namenstransparenz.
• Beteiligte Rechner werden in zwei Gruppen unterteilt:
wenige Vice Server und viele Virtue Workstations.
283 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.8.2 Klienten: Virtue Workstations
• Virtue Workstations haben transparenten Zugriff auf Vice-Dateiserver:
- Hierfür hat jede Workstation einen speziellen Prozess Venus:
o regelt den Zugriff auf die Dateien des Vice Servers,
o kann kurzfristige Serverausfälle überbrücken,
o ähnlich zu einem NFS Klienten.
• Prozesse kommunizieren mit dem virtuellen Dateisystem:
- dieses leitet Anfragen an das lokale Dateisystem weiter,
oder wendet sich an den Venus Prozess (/coda bzw. /afs)
- Venus fordert ggf. Dateien von Vice Dateiserver via RPC an.
Virtue client machine
User space User User Venus
Process Process Process
RPC client stub
Local file system interface
Virtual file system layer
Local OS
Network
284 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.8.3 Vice Dateiserver
• Dienste des Vice Dateiservers:
- bietet Dateien an, die von Venus Prozessen angefordert werden können.
- Trusted Vice bieten zusätzlichen Authentifikations – Dienst,
- Update Prozesse halten die Daten auf den Servern konsistent.
• Coda erscheint für den Anwender wie ein bekanntes UNIX Dateisystem.
- Die meisten Virtual File System Operationen werden unterstützt.
- Es gibt einen globalen Namensraum (/afs bzw. /coda).
o Venus lädt den notwendigen Teil des Namensraums.
o Alle Dateien sind in Unterverzeichnissen der global einheitlichen Wurzel zu finden.
• Kommunikation zwischen Venus und Vice über RPC2:
- RPC2 verwendet Multicast Kommunikation (UDP) zwischen den Knoten,
- Multicast erlaubt effiziente Invalidierung von Replikaten,
- Auf alle Antworten der Multicast-Gruppe wird gewartet.
- Multicast RPC wird mit MultiRPC bezeichnet.
285 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.8.4 Namen in Coda
• Globaler Dateinamensraum für gesamtes System:
- im Gegensatz zu NFS,
- typisch unter /code bzw. /afs.
• Volumes (Partitionen oder Teilbäume):
- Gruppe von Dateien und Verzeichnissen,
- eingehängt an bestimmter Stelle im Namensraum:
- zentrale Zuordnung der Namen auf dem Server (mounting),
- Bem.: Volumes sind die Basis für die Replikation.
286 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.8.5 Dateibezeichner
• Problem: Auffinden von Dateien, die auf mehreren Server verteilt &
repliziert sind, trotz Replikationstranparenz und Ortstransparenz.
• Lösung: 32 Bit RVID (Replicated Volume ID) + 64 Bit File Handle.
- Volume Replication DB liefert Liste VIDs zu einer RVID.
- Volume Location DB. liefert IP-Adresse zu einer VID.
• Bem.: Mehrere VIDs pro RVID für replizierte Volumes.
287 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.8.6 Normalbetrieb
• Sitzungssemantik:
- Klient muss beim Öffnen Modus angeben: lesend oder schreibend öffnen,
- Transfer der vollständigen Datei vom Server zum Klienten,
- Server merkt sich, dass der Klient eine Kopie hat,
- Eine Session wird als Transaktion betrachtet.
• Zugriffssemantik: exklusiver Schreibzugriff, nebenläufiger Lesezugriff
(Leser-Schreiber-Koordinierung).
• Klient hat lokalen Datei-Cache:
- vor Zugriff (bei open) wird Datei in Cache geladen
- Server gibt Callback-Promise aus, d.h. Server verspricht Invalidierungsnachricht zu senden,
- Server verschickt Callback-Break, falls lokale Kopie invalidiert werden muss.
• Beispiel:
- A liest auf veralteten Kopie,
- zulässig, da TAA vor TAB
gestartet wurde,
- neue Session fordert
jedoch neue Kopie an.
288 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.8.7 Fehlertoleranz
Serverredundanz
• Die Einheit der Replikation in den Servern ist ein Volume.
• Eine Volume Storage Group (VSG) ist eine Anzahl von
Servern, die alle ein Replikat eines Volumes haben.
• Die von einem Klienten erreichbaren Server bzgl. eines Volumes
werden mit Available Volume Storage Group (AVSG) bezeichnet.
• Wenn AVSG = ∅ dann ist der Klient von allen Servern getrennt.
Server Server
S1 S3
Broken network
Client Server Client
A S2 B
• Konsistenz der Replikate durch Replicated Write Protocol:
289 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner- Read one / write all:
o Ein Klient kann von einem Server aus der AVSG lesen.
o Klient schreibt auf alle Server Æ MultiRPC.
o fkt. gut solange es keine Fehler gibt.
• Im Fehlerfall hilft ein Versionsvektor bei der Erkennung von Konflikten.
- Jede Datei eines Volumes hat einen Coda Version Vector (CVV),
- #Vektorelemente = #Server in Volume Storage Group,
• CVV im Normalbetrieb:
- Beim Öffnen einer Datei zum Schreiben erhält Klient Datei f und zugehörigen CVVf,
- Beim Schließen wird die Datei f mit CVVf an AVSG gesendet,
- Jeder Server in AVSG inkrementiert sein Element in CVVf
und schickt den Vektor wieder zurück an den Klienten.
- Klient berechnet aus allen Antworten den neuen CVVf
und schickt diesen per Multicast an die AVSG.
• Konflikterkennung mit Hilfe des CVVs:
- Konflikterkennung per elementweisen Vektorvergleich,
- kein Konflikt, falls: CVV1 < CVV2: CVV1[i] ≤ CVV2[i] oder CVV1 = CVV2.
290 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner• Beispiel: Eine Datei f liegt auf den Servern S1, S2 und S3.
- CVVf = (Version auf S1, Version auf S2, Version auf S3); zu Beginn sei CVVf = (0,0,0).
- Die Klienten C1 und C2 öffnen f und dannach wird das Netz partitioniert.
- Es sei AVSGC1 = {S1, S2} und AVSG C2 = {S3}.
- Fall 1:keine Konflikte
o C1 verändert f: CVVf = (1,1,0),
o C2 nimmt keine Veränderungen vor: CVVf = (0,0,0).
o später sind wieder alle Server erreichbar.
o Abgleich der verschiedenen CVVs durch elementweisen Vergleich.
o (1,1,0) > (0,0,0) Æ kein Konflikt
o Server müssen Versionen untereinander abgleichen.
o geschieht transparent für die Klienten.
- Fall 2: Konflikt
o C1 verändert f: CVVf = (1,1,0),
o C2 verändert ebenfalls f: CVVf = (0,0,1).
o Es sind zwei verschiedene neue Versionen entstanden.
o Nachdem wieder alle Server erreichbar sind, werden Konfliktfälle
durch den Vektorenvergleich gefunden (1,1,0) (0,0,1)
o Alle neuen Versionen werden in einem Covolume abgelegt und
die Benutzer darüber informiert.
o Konflikte müssen nun interaktiv durch Benutzer aufgelöst werden.
o Bem.: Diese Fälle treten selten auf, da eine Datei meistens nicht
von mehreren Benutzern konkurrierend aktualisiert wird.
291 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. SchöttnerFehlertoleranz falls kein Server erreichbar ist
• Hat ein Klient keine Verbindung zu einem Server, kann er dennoch
weiterarbeiten Æ Caching beim Klient.
• Venus füllt den Cache des Klienten mit „wichtigen“ Daten:
- Falls benötigte Daten im Cache blockiert Klient nicht.
- Hierfür gibt es eine Caching-Strategie mit Prioritäten für Daten.
- Daten mit hoher Priorität (z.B. definiert durch User) müssen sich ständig im Cache befinden.
• Zustandsautomat des Klienten für jedes Volume:
Disconnection
Hoarding Reintegration complete
Disconnection
Emulation Reintegration
Reconnection
- Hoarding: Daten mit hoher Priorität zuerst im Cache erneuern (wenn Verbindung z. Server).
- Emulation: Klient arbeitet auf „gecachten“ Daten, wenn keine Verbindung zum Server.
- Reintegration: Abgleich modifizierter Daten mit dem Server, bei erneuter Verbindung.
• Bem.: Bei Konflikten ist die Anwendung, bzw. der Anwender gefordert.
- Aber Konflikte unwahrscheinlich, da Dateien selten gemeinsam geschrieben werden.
292 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner10.8.8 Sicherheit • Verschlüsselte Übertragung zwischen Vice und Virtue möglich. • Verwendet wird hierbei eine symmetrische Verschlüsselung. • Zentraler Authentisierungsdienst (ähnlich Key Distribution Center). • Einsatz einer Variante des Needham-Schröder-Protokolls. 293 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
10.9 Zusammenfassung
• Ziel: Soll wie ein lokales Dateisystem erscheinen.
- Nutzungsprofil: Dateien i.d.R. klein, Datei-Sharing ist selten, ...
- i.d.R. Sitzungssemantik Æ gesamte Änderungen werden beim "Close" sichtbar.
• Network File System:
- Ortstransparenz, falls einheitlicher Namensraum auf jedem Klienten,
- eingebunden über VFS; Sitzungssemantik; Caching beim Klient,
- Sperren zur Steuerung konkurrierender Schreibzugriffe.
• Coda:
- Ziele: hohe Verfügbarkeit, auch falls keine Verbindung zu einem Server besteht,
- Sitzungssemantik:
o parallel dürfen N-Leser und max. ein Schreiber pro Datei arbeiten,
o Server sendet Nachricht an Leser, falls die Datei geändert wurde.
- replizierte Volumes (Partition oder Verzeichnisbaum),
- Weiterarbeiten bei Partitionierung des Netzes möglich:
o Konflikte können anhand eines Versionsvektors erkannt werden,
o ggf. muss Benutzer Konflikt auflösen.
- Weiterarbeiten möglich, falls kein Server erreichbar ist:
o falls benötigte Dateien im Cache des Klienten vorhanden sind,
o Cache wird gefüllt mit Hilfe von Heuristiken & Hinweisen von Benutzer,
o Reintegration der Daten im Cache mit dem Server, wenn Verbindung wieder besteht.
294 Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. SchöttnerSie können auch lesen
