Verteilte Systeme. Verteilte Dateisysteme und Replikation

Größe: px
Ab Seite anzeigen:

Download "Verteilte Systeme. Verteilte Dateisysteme und Replikation"

Transkript

1 1 Verteilte Systeme Verteilte Dateisysteme und Replikation

2 Verteilte Dateisysteme 2

3 Was ist ein Dateisystem? Persistenter Speicher für Datensätze Hierarchischer Namensraum, für alle Prozesse sichtbar (bis auf Zugriffsrechte) API mit folgenden Merkmalen: Zugriff und Aktualisierungsoperationen auf die persistent gespeicherten Datensätze Sequentielles Zugriffsmodell (mit zusätzlichem beliebigen Zugriff) Prozesse können gemeinsam auf die Datensätze zugreifen. Dateisysteme können gemountet werden Wichtig: Transparenz, für den Client soll die Illusion eines lokalen Dateisystems bestehen 3

4 Was ist ein Dateisystem? Komponenten: Verzeichnismodul: Ordnet Dateinamen Datei-ID s zu Dateimodul: Ordnet Datei-ID s bestimmten Dateien zu Zugriffskontrollmodul: Überprüft die Berechtigung für die angeforderte Operation Dateizugriffsmodul: Blockmodul: Gerätemodul: Liest oder schreibt Dateidaten oder Attribute Greift auf Festplattenblöcke zu bzw. reserviert sie Festplatten-I/O und Puffer Verteiltes Dateisystem zusätzlich: Client-Server-Kommunikation Verteilte Namensgebung und Auffinden von Dateien 4

5 UNIX Dateisystem-Operationen Was ist ein Dateisystem? filedes = open(name, mode) filedes = creat(name, mode) status = close(filedes) count = read(filedes, buffer, n) count = write(filedes, buffer, n) Öffnet eine existierende Datei mit einem bestimmten Namen Erzeugt eine neue Datei mit dem angegebenen Namen Beide Operationen geben einen Dateideskriptor zurück, der auf die geöffnete Datei verweist. Der Modus ist read, write oder beides. Schließt die geöffnete Datei filedes Überträgt n Bytes von der Datei, auf die filedes verweist, in buffer Überträgt n Bytes aus buffer in die Datei, auf die filedes verweist Beide Operationen geben die Anzahl der übertragenen Bytes zurück und schieben den Schreib/Lese-Zeiger weiter pos = lseek(filedes, offset, whence) Verschiebt den Schreib/Lese-Zeiger auf den Offset (abhängig von whence relativ oder absolut) status = unlink(name) status = link(name1, name2) status = stat(name, buffer) Entfernt die Datei name aus der Verzeichnisstruktur. Wenn die Datei keine anderen Namen hat, wird sie gelöscht Fügt einen neuen Namen (name2) für eine Datei (name1) ein Ermittelt die Dateiattribute für die Datei name in buffer 5

6 Ein Copy-Programm in C /* Write a simple C program to copy a file using the UNIX file system operations */ #define BUFSIZE 1024 #define READ 0 #define FILEMODE 0644 void copyfile(char* oldfile, char* newfile) { char buf[bufsize]; int i,n=1, fdold, fdnew; if((fdold = open(oldfile, READ))>=0) { fdnew = creat(newfile, FILEMODE); while (n>0) { n = read(fdold, buf, BUFSIZE); if(write(fdnew, buf, n) < 0) break; } close(fdold); close(fdnew); } else printf("copyfile: couldn't open file: %s \n", oldfile);} main(int argc, char **argv) { copyfile(argv[1], argv[2]); } 6

7 Was ist ein Dateisystem? Datei-Attribute Record Struktur Vom System aktualisiert Vom Besitzer aktualisiert: File length Creation timestamp Read timestamp Write timestamp Attribute timestamp Reference count Owner File type Access control list E.g. for UNIX: rw-rw-r-- 7

8 Allgemeine Dateidienst-Anforderungen Tranzparenz Transparenz Nebenläufigkeits-Eigenschaften Replikations-Eigenschaften Zugrifft: Heterogenitäts-Eigenschaften dieselben Operationen (wie lokal) Isolation Fehlertoleranz Konsistenz Sicherheit Effizienz Nebenläufigkeit Deiteidienst Ort: Dienst unterhält mehrere identische Kopien Derselbe Namensraum nach Sperren Dienst Unix der Zugriffskontrolle kann benutzt werden von Clients, die auf Ziel Dateien bietet auf für muß verteilte Datei-Level one-copy weiterlaufen, und Dateisysteme oder Schutz update wenn Record-Level muss Semantik die ist Clients meist wie bei für eine Fehler lokalem beliebigen Einbindung Betriebssysteme des Dateisystems bzw. Hardware Replikation machen Operationen Dateisystem Performanz, oder abstürzen. mit gewährleistet die lokalen vergleichbar Dateien sein. mit Caching der eines ist Mobilität: Anderen Lastverteilung Plattformen Formen Automatische laufen. von zwischen Nebenläufigkeitskontrolle Relokation Servern der macht Dateien, den um Design Dienst at-most-once vollständig lokalen Basierend Dateisystems transparent. muß skalierbarer wenn Konflikte Semantik auf dem Benutzer, ist. der den Zugriff Heterogenität kompatibel möglich zu minimieren sein mit dem lokalen Performanz: Schwierig durchführt Lokaler Dateisystem at-least-once bei verteilten Zugriff Ausreichende der ist SemantikDateisystemen zu Fehlertoleranz erreichen, Identität wenn des performanter verschiedenen eine entfernten Performanz gute Performanz Benutzers (kleiner Betriebssysteme bei Latenz) muß und Volle Dienst-Interface Dienst Skalierbarkeit Replikation muß niedriger authentifiziert neusarten, ist muß gewährleistet und schwierig offen hoher nachdem werden sein Last zusein implentieren. der präzise sollen. Server Konsistenz Skalierung: Caching Spezifikation abgestürzt ist. Siehe Folien (von Schutz Dienst Dateien über kann erfordert Replikation APIs oder erweitert sichere müssen Blöcken) werden Kommunikation veröffentlicht ist ein bei Sicherheit Leicht Kompromiss sein. zuzusätzlicher realisieren (Verschlüsselung, mit ebenfalls bei Last zustandslosen besserer evtl. Digitale Performanz Signaturen) Servern Wenn Dienstschnittstellen der mehrfach müssen existiert offen für (Replikation), alle Prozesse Effizienz kann sein, er die trotz nicht Absturz durchweiterlaufen. eine Firewall o.ä. ausgeschlossen sind. 8

9 Modell für entfernten Dateidienst Client computer Lookup AddName UnName GetNames Server computer Application program Application program Directory service UFID Flat file service Client module Wichtigstes Ziel: Aufteilung der Aufgaben, Einfachere Implementierung der einzelnen Komponenten Read Write Create Delete GetAttributes SetAttributes 9

10 Server-Operationen für den Dateidienst Flat file service Read(FileId, i, n) -> Data position of first byte position of first byte Write(FileId, i, Data) Create() -> FileId Delete(FileId) GetAttributes(FileId) -> Attr SetAttributes(FileId, Attr) Directory service Lookup(Dir, Name) -> FileId AddName(Dir, Name, File) UnName(Dir, Name) GetNames(Dir, Pattern) -> NameSeq Pfadnamen Pathnamen wie '/usr/bin/tar' werden durch FileId iterative Aufrufe von lookup() aufgelöst, ein Eindeutiger Aufruf für Identifier jede Komponente für eine Dateides irgendwo Pfades, im Netzwerk. angefangen Ähnlich mit der Remote ID des Root- Object References Verzeichnisses '/ die jeder Client kennt. 10

11 /* remote file system */ Client module actions: Kopierprogramm mit dem Dateidienst if((fdold = open(oldfile, READ))>=0) { fdnew = creat(newfile, FILEMODE); while (n>0) { n = read(fdold, buf, BUFSIZE); if(write(fdnew, buf, n) < 0) break; } close(fdold); close(fdnew); server operations for: copyfile("/usr/include/glob.h", "/foo") fdold = open('/usr/include/glob.h", READ) FileId = Lookup(Root, "usr") - remote invocation FileId = Lookup(FileId, "include") - remote invocation FileId = Lookup(FileId, "glob.h") - remote invocation client module makes an entry in an open files table with file = FileId, mode = READ, and RWpointer = 0. It returns the table row number as the value for fdold fdnew = creat("/foo", FILEMODE) Client module actions: FileId = create() - remote invocation AddName(Root, "foo", FileId) - remote invocation SetAttributes(FileId, attributes) - remote invocation client module makes an entry in its openfiles table with file = FileId, mode = WRITE, and RWpointer = 0. It returns the n = table read(fdold, row number buf, BUFSIZE) as the value for fdnew Client module actions: Read(openfiles[fdold].file, openfiles[fdold].rwpointer, BUFSIZE) - remote invocation increment the RWpointer in the openfiles table by BUFSIZE and assign the resulting array of data to buf 11

12 Dateigruppen für den Dateidienst Eine Gruppe von Dateien (Teilbaum) kann auf jeden Server plaziert werden oder zwischen Servern verschoben werden bei Beibehaltung ihres Namens. Wie beim UNIX-Dateisystem Hilft beim Verteilen der Last zwischen den Datei-Servern. Dateigruppen haben IDs, die eindeutig im gesamte System sind (d.h. bei einem offenen System müssen sie global eindeutig sein). Benutzt um auf Gruppen von Dateien oder einzelne Dateien zuzugreifen Um eine global eindeutige ID zu konstruieren, benutzen wir eindeutige Attribute der Maschine, wo die Datengruppe erzeugt wurde,z.b. die IP- Adresse, auch wenn die Dateigruppen später verschoben wird. Dateigruppen - ID: 32 bits 16 bits IP address date 12

13 Beispiel: Sun NFS Ein offener Industrie-Standard für ein Netzwerk-Dateisystem (seit etwa 1985), mit klaren und einfachen Schnittstellen Folgt eng dem bisher gezeigten Dateisystem Public Domain, von jedem implementierbar, Protokoll beschrieben in RFC 1813 Unterstützt viele der Design-Anforderungen : Transparenz Heterogenität Effizienz Fehlertoleranz Mit Einschränkungen: Gleichzeitigkeit Replikation Konsistenz Sicherheit 13

14 NFS Architektur Client computer Client computer Application program NFS Client Server computer UNIX system calls Application program Application program Kernel Application program UNIX kernel Operations on local files Virtual file system UNIX file system Other file system NFS client Operations on remote files Virtual file system NFS server NFS Client UNIX file system NFS protocol (remote operations) 14

15 Zugriffstransparenz erfüllt NFS Bewertung Ortstransparenz: Benutzer bemerken nichts von Ortsverschiebungen Mobilitätstransparenz: bei Verschiebung von Dateien müssen sämtliche Tabellen in den Clients modifiziert werden Skalierung: könnte besser sein mit replizierten Dateisystemen Replikation: nur mit Read, keine Updates Heterogenität Fehlertoleranz Konsistenz: sehr gut im lokalen Bereich, ansonsten kritisch Sicherheit: Integration von Kerberos Effizienz: praktische Erfahrungen zeigen exzellentes Leistungsverhalten 15

16 Verteilung von Prozessen im Andrew File System Workstations User Venus program UNIX kernel Servers Vice UNIX kernel Venus User program UNIX kernel Network Vice Venus User program UNIX kernel UNIX kernel 16 *

17 AFS Bewertung Zugriffstransparenz: AFS benutzt einen leicht modifizierten UNIX-Kern, um nichtlokale Dateizugriffe abzufangen und dem AFS-Clienten zuzuleiten Ortstransparenz: stellt einen globalen Dateinamensraum zur Verfügung. Alle Clients haben dieselbe Sicht auf die Dateien. Dateinamen enthalten keinerlei Hinweis auf den Ort. Nebenläufigkeitstransparenz: ist nicht gegeben. AFS kopiert komplette Dateien zu den Clients (Cache auf der Platte). Es gibt jedoch aufwendige Mechanismen zur Inkonsistenzvermeidung Fehlertransparenz: ist grundsätzlich gegeben, jedoch nicht in dem Maße wie bei NFS, da AFS-Server zustandsbehaftet sind Leistungstransparenz: Durch Puffern ganzer Dateien ist die Zugriffszeit in den meisten Fällen (cache hit) identisch mit der Zugriffszeit auf lokale Dateien. Im direkten Vergleich (Benchmark) mit NFS schnitt AFS bei hoher Last deutlich besser ab. 17

18 Replikation 1

19 Sinn der Replikation Replikation bedeutet das Halten einer oder mehrerer Kopien eines Datums Ein Prozess, der auf dieses Datum zugreifen will, kann auf jede beliebige Replika zugreifen Im Idealfall erhält er immer das gleiche Ergebnis Was also erreicht werden muss, ist die Konsistenz der Kopien wobei unterschiedliche Anwendungen unterschiedliche Anforderungen an die Striktheit der Konsistenz haben. 19

20 Ziele der Replikation Zwei große Ziele Steigerung der Verlässlichkeit eines Dienstes bzw. der Verfügbarkeit eines Datums Wenn ein Replikat nicht mehr verfügbar ist, können andere verwendet werden. (Mobilität oder Absturz) Besserer Schutz gegen zerstörte/gefälschte Daten: bei gleichzeitigem Zugriff auf mehrere Replikate wird das Ergebnis der Mehrheit verwendet Steigerung der Leistungsfähigkeit des Zugriffs auf ein Datum Bei großen Systemen: Verteilung der Replikate in verschiedene Netzregionen oder Einfache Vervielfachung der Server an einem Ort 20

21 Problem der Replikation Die verschiedenen Kopien müssen konsistent gehalten werden. Das ist insbesondere ein Problem Wenn es viele Kopien gibt Wenn die Kopien weit verstreut sind Es gibt eine Reihe von Lösungen zur absoluten Konsistenzhaltung in nicht-verteilten Systemen, die jedoch die Leistung des Gesamtsystems negativ beeinflussen. Dilemma: wir wollen bessere Skalierbarkeit und damit bessere Leistung erreichen, aber die dazu notwendigen Mechanismen verschlechtern die Performance. Einzige Lösung: keine strikte Konsistenz 21

22 Ansicht 1: Ansicht 2: Anwendungsbeispiel Bulletin Bulletin board: board: OS.interesting OS.interesting Item ItemFrom Subject Subject A. A. Hampton Hampton Mach Mach G. G. Joseph Joseph Microkernels Microkernels A. A. Hampton Hampton Re: Re: Microkernels Microkernels T.L. T.L. Heureux Heureux RPC RPC Performance Performance M. M. Walker Walker Re: Re: Mach Mach end end Bulletin Bulletin board: board: OS.interesting OS.interesting Item ItemFrom Subject Subject G. G. Joseph Joseph Microkernels Microkernels A. A. Hampton Hampton Mach Mach A. A. Sahiner Sahiner Re: Re: RPC RPC performance performance M. M. Walker Walker Re: Re: Mach Mach T.L. T.L. Heureux Heureux RPC RPC Performance Performance A. A. Hampton Hampton Re: Re: Microkernels Microkernels end end Probleme: Nachrichten tauchen in unterschiedlicher Reihenfolge auf. Sie kommen überhaupt nicht an. Für News ist das OK, aber andere Anwendungen? 22

23 Systemmodell Daten im System = Sammlung von Objekten (Datei, Java-Objekt, etc.) Jedes logische Objekt wird durch eine Reihe physischer Objekte realisiert, den Replikaten. Die Replikate müssen nicht zu jeder Zeit absolut identisch sein sie können es tatsächlich auch nicht sein. Die Replikations-Intelligenz kann in den Objekten platziert sein oder außerhalb (in einer Middleware). Vorteil hier: Anwendungsprogrammierer ist frei von Überlegungen zur Replikation 23

24 Replikations-Intelligenz Die Objektebene (z.b. Programmierer) ist für das Replikationsmanagement verantwortlich Das Verteilte System (Middleware) ist für das Replikationsmanagement verantwortlich 24

25 Konsistenzmodelle Konsistenzmodell: Im Prinzip ein Vertrag zwischen einem Datenspeicher und den darauf zugreifenden Prozessen Wenn sich die Prozesse an gewisse Regeln halten, arbeitet der Datenspeicher korrekt. Erwartung: der Prozess, der ein Read ausführt, erwartet als Ergebnis den Wert des letzten Write Frage: was ist das letzte Write in Abwesenheit einer globalen Uhr? Lösung: verschiedene Konsistenzmodelle (nicht nur strikt) Daten-zentrierte Konsistenzmodelle: Sicht des Datenspeichers Client-zentrierte Konsistenzmodelle: Sicht des Client, weniger starke Annahmen, insbesondere keine gleichzeitigen Updates 25

26 Daten-zentriertes Konsistenzmodell Prozess Prozess Prozess lokale Kopie Verteilter Datenspeicher - physikalisch verteilt - repliziert für verschiedene Prozesse 26

27 Strikte/Atomare Konsistenz Konsequentestes Konsistenzmodell Modell: Jedes Read liefert als Ergebnis den Wert der letzten Write Operation. Notwendig dazu: absolute globale Zeit Unmöglich in einem verteilten System, daher nicht implementierbar Withdraw $100 Waterloo W(x)a: Write-Operation auf Replikt des Objekts x mit Wert a Die Änderung muss per Nachricht an andere Replikte (direkt oder über Original) verbreitet werden P1: Prozeß 1 Zeit: von links nach rechts Bitte Warten, das Konto wird gerade geändert Paris Strikt Konsistent Nicht strikt Konsistent 27

28 Sequentielle Konsistenz Entspricht der seriellen Äquivalenz bei den Transaktionen, bezogen auf einzelne Etwas schwächeres Modell, aber implementierbar. Operationen! Modell: Wenn mehrere nebenläufige Prozesse auf Daten zugreifen, dann ist jede gültige Kombination von Read- und Write-Operationen akzeptabel, solange alle Prozesse dieselbe Folge sehen. Zeit spielt keine Rolle Jede Permutation der Zugriffe ist zulässig, sofern sie von allen Prozessen so wahrgenommen wird Unter sequentieller Konsistenz können zwei Läufe desselben Programms unterschiedliche Ergebnisse liefern, sofern nicht explizite Synchronisationsoperationen dies verhindern Sequentiell Konsistent Nicht sequentiell Konsistent 28

29 Linearisierbarkeit Liegt in der Striktheit zwischen strikter und sequentieller Konsistenz, d.h. sie genügt der sequentiellen Konsistenz, erreicht aber keine strikte Konsistenz! Idee: verwende eine Menge synchronisierter Uhren, auf deren Basis Zeitstempel für die Operationen vergeben werden Verglichen mit sequentieller Konsistenz ist die Ordnung dann nicht beliebig, sondern auf der Basis dieser Zeitstempel Komplexe Implementierung (durch die Forderung der Zeitstempelreihenfolge), wird hauptsächlich eingesetzt zur formalen Verifikation nebenläufiger Algorithmen 29

30 Kausale Konsistenz Schwächeres Modell als die sequentielle Konsistenz Vergleichbar mit Lamports happened-before -Relation Regel: Write-Operationen, die potentiell in einem kausalen Verhältnis stehen, müssen bei allen Prozessen in derselben Reihenfolge gesehen werden. Für nicht in dieser Beziehung stehende Operationen ist die Reihenfolge gleichgültig. Zwei Write-Operationen sind auch potentiell kausal abhängig, wenn vor der zweiten Operation eine Leseoperation stattgefunden hat, die den Wert der zweiten Schreiboperation beeinflusst haben kann! kausal konsistent Nicht Nicht sequentiell strikt kausal nicht einzuordnen! 30

31 FiFo-Konsistenz Idee: alle Schreiboperationen eines Prozesses werden von allen anderen Prozessen in derselben Reihenfolge wahrgenommen. Schreibzugriffe verschiedener Prozesse können von unterschiedlichen Prozessen in unterschiedlicher Reihenfolge gesehen werden. heißt Pipelined RAM (PRAM) bei DSM s 31

32 Schwache Konsistenz In der Regel benötigen Prozesse nur in bestimmten Situationen eine konsistente Sicht auf den Speicher. Schwache Konsistenz unterscheidet daher normale Variablen von Synchronisationsvariablen, die mit einem Datenspeicher assoziiert sind. Die Synchronisation erzwingt eine Aktualisierung der Werte nur eine Operation: synchronisiere(s); alle lokalen Write-Operationen werden zu allen Kopien übertragen und alle Write-Operationen bei anderen Kopien werden zur lokalen Kopie übertragen. Idee: Konsistenz für eine Gruppe von Operationen, und nicht für einzelne Schreib- und Leseoperationen eine sequenzielle Konsistenz zwischen Gruppen von Operationen Wer seine Schreibzugriffe sichtbar machen möchte für andere Prozesse, muss synchronisieren. Wer auf die aktuellsten Daten zugreifen möchte, muss ebenfalls synchronisieren; Wer vor dem Lesezugriff nicht synchronisiert, kann veraltete Werte sehen 32

33 Schwache Konsistenz P1: W(x)a W(x)c S P2: R(x)b R(x)c P3: W(x)b S R(x)b schwach konsistent P1: W(x)a W(x)b S P2: R(x)b P3: R(x)a P1: W(x)a W(x)b S P2: R(x)a nicht schwach konsistent P3 synchronisiert: alle Replikate kennen alle Änderungen von P3 und P3 kennt alle Änderungen der anderen Replikate! P3 hat nicht synchronisiert: er liest alte Werte! P2 müsste R(x)b lesen, da vorher P1 synchronisiert hat und damit alle Replikate alle Änderungen von P1 kennen! 33

34 Freigabe/Eintritts-Konsistenz Bei der schwachen Konsistenz werden bei Zugriff auf eine Synchronisationsvariable die folgenden Aktionen durchgeführt: 1. alle Änderungen des Prozesses werden an alle anderen Kopien propagiert 2. alle Änderungen von anderen Kopien werden zur Kopie des Prozesses propagiert. Dies ist i.allg. nicht nötig. Idee: Kritische Zugriffe können in kritische Abschnitte geklammert werden. Es gibt zwei Operationen für den kritischen Abschnitt: acquire: nur Aktion 2 release: nur Aktion 1 34

35 Freigabe-Konsistenz Bei einem acquire wird der Prozess verzögert, während ein anderer Prozess ebenfalls auf die gemeinsam genutzten Variablen zuzugreift. Bei einem release werden alle lokalen Änderungen an den geschützten Daten sichtbar gemacht (z.b. an die Kopien verteilt). Verzögert, bis Rel(L) von P1 durchgeführt Legale Freigabe-Konsistenz aktuell, da Acq(L) durchgeführt nicht aktuell, da kein Acq(L) durchgeführt Nicht verzögert 35

36 Eintritts-Konsistenz Alle Daten benötigen eine Synchronisationsvariable! Bei einem acquire müssen alle entfernten Änderungen an den geschützten Daten sichtbar gemacht werden. Bei einem release passiert nichts! Vor der Aktualisierung eines gemeinsam genutzten Datenelements muss ein Prozess im exklusiven Modus in einen kritischen Bereich eintreten, um sicherzustellen, dass keine anderen Prozesse gleichzeitig versuchen, das Datenelement zu aktualisieren! Wenn ein Prozess im nicht-exklusiven Modus in einen kritischen Bereich eintreten will, muss er sich zuerst mit dem Eigentümer der Synchronisierungsvariablen, die den kritischen Bereich schützt, in Verbindung setzen, um die neuesten Kopien der geschützten gemeinsam genutzten Daten zu erhalten. Legale Eintritts-Konsistenz nicht aktuell, da kein Acq(Ly) durchgeführt aktuell, da Acq(Ly) durchgeführt 36

37 Definitionen Ein Replikensystem realisiert strikte/atomare Konsistenz (strict consistency), wenn jeder Lesezugriff auf ein Speicherobjekt den Wert der global zeitlich letzten Schreiboperation liefert. Ein Replikensystem realisiert kausale Konsistenz (causal consistency), wenn alle Schreiboperationen, die potentiell kausal voneinander abhängen, von allen Prozessen in derselben (kausal) korrekten Reihenfolge wahrgenommen werden. Ein Replikensystem realisiert sequentielle Konsistenz (sequential consistency), wenn alle Prozesse dieselbe Reihenfolge der Speicherzugriffe wahrnehmen. Ein Replikensystem realisiert FiFo- Konsistenz, wenn alle Schreiboperationen eines Prozesses von allen anderen Prozessen in derselben Reihenfolge wahrgenommen werden. 37

38 Definitionen Ein Replikensystem realisiert schwache Konsistenz, wenn: Alle Zugriffe auf Synchronisationsvariablen genügen der sequentiellen Konsistenz Alle vorangegangenen Schreiboperationen sind überall abgeschlossen, bevor ein Zugriff auf eine Synchroniationsvariable erlaubt ist (Leeren der Pipeline) Alle vorangegangenen Zugriffe auf Synchroniationsvariablen sind abgeschlossen, bevor ein Zugriff auf eine normale Variable stattfindet (keine Operationen aus der Zukunft erlaubt) Ein Replikensystem realisiert Freigabe- Konsistenz, wenn: Alle Zugriffe auf acquire- und release-synchronisationsvariablen genügen der FIFO-Konsistenz Bevor ein Prozess auf normale Variablen zugreift, müssen alle vorangegangenen acquire- Operationen erfolgreich abgeschlossen sein. Alle Zugriffe eines Prozesses auf normale Variablen müssen abgeschlossen sein, bevor eine release-operation des Prozesses durchgeführt werden kann 38

39 Definitionen Ein Replikensystem realisiert Eintritts-Konsistenz, wenn: Ein acquire-zugriff auf eine Synchronisierungsvariable ist für einen Prozess nicht erlaubt, bis alle Aktualisierungen der geschützten gemeinsam genutzten Daten für diesen Prozess durchgeführt wurden. Damit ein Zugriff auf eine Synchronisierungsvariable im exklusiven Modus durch einen Prozess erlaubt wird, darf kein anderer Prozess die Synchronisierungsvariable halten, nicht einmal im nicht-exklusiven Modus. Nachdem ein Zugriff im exklusivsten Modus auf eine Synchronisierungsvariable erfolgt ist, wird möglicherweise der nächste nicht exklusive Zugriff eines anderen Prozesses auf diese Synchronisierungsvariable nicht durchgeführt, bis er für den Eigentümer dieser Variable durchgeführt wurde. 39

40 Zusammenfassung der Konsistenzmodelle...die keine Synchronisationsvariable nutzen Konsitenz Strikt Linearisierbarkeit Sequenziell Kausal FIFO Beschreibung Absolute Zeitreihenfolge aller gemeinsamen Zugriffe Alle Prozesse sehen alle gemeinsamen Zugriffe in derselben Reihenfolge. Die Zugriffe sind darüber hinaus gemäß einem (nicht eindeutigen) globalen Zeitstempel sortiert. Alle Prozesse sehen alle gemeinsamen Zugriffe in derselben Reihenfolge. Die Zugriffe sind nicht der Zeit nach sortiert Alle Prozesse sehen alle kausal verknüpften gemeinsamen Zugriffe in derselben Reihenfolge. Alle Prozesse sehen Schreiboperationen voneinander in der Reihenfolge, in der sie abgesetzt wurden. Schreiboperationen von anderen Prozessen werden möglicherweise nicht immer in der gleichen Reihenfolge gesehen. 40

41 Zusammenfassung der Konsistenzmodelle...die eine Synchronisationsvariable nutzen Konsitenz Schwach Freigabe Eintritt Beschreibung Gemeinsam genutzte Daten sind nur dann verlässlich konsistent, nachdem eine Synchronisierung vorgenommen wurde Gemeinsam genutzte Daten werden konsistent gemacht, nachdem ein kritischer Bereich verlassen wurde Gemeinsam genutzte Daten, die zu einem kritischen Bereich gehören, werden konsistent gemacht, sobald ein kritischer Bereich betreten wird 41

42 Client-zentriertes Konsistenzmodell Client lokale Kopie Verteilter Datenspeicher 42

43 Eventuelle Konsistenz Idee: über lange Zeitspannen keine Updates, dann werden im Laufe der Zeit alle Replikate konsistent sein, indem sie identische Kopien voneinander werden. Beispiele für typische Anwendungen, bei denen ein solches Modell ausreicht (meist wenig Schreibberechtigte oder/und selten Veränderungen) 1. DNS (Aktualisierung wird langsam weitergegeben) 2. Web Caching (oft akzeptierte Inkonsistenz) Vorteil: meist sehr einfach zu implementieren, Write-Write- Konflikte treten meist nicht auf 43

44 Problem Client wechselt Replika Problem Inkonsistentes Verhalten möglich Lösung Client-zentrierte Modelle Konsistenz für Client garantiert nicht garantiert für nebenläufigen Zugriff 44

45 I: Monotones Lesen Regel: Wenn ein Prozess den Wert einer Variablen x liest, dann wird jede weitere Read-Operation denselben oder einen neueren Wert von x liefern. Beispiel: Zugriff auf -Box von verschiedenen Orten Legende: Li: sind Kopien eines Datenspeichers x i: der i-te Zugriff auf x WS ist Schreibset, R Leseoperation, W Schreiboperation jeweils des selben (!) Prozesses P WS(x 1 x 2 ): es ist WS(x 1 ) Teil von WS(x 2 ) Monotones Lesen garantiert Monotones Lesen nicht garantiert 45

46 II: Monotones Schreiben Regel: Eine Schreiboperationen durch einen Prozess auf einen Datenelement x ist abgeschlossen, bevor eine nachfolgende Schreiboperationen auf x durch denselben Prozess stattfindet Keine Daten-zentrierte FIFO-Konsistenz, da hier Konsistenz nur für einen Prozess berücksichtigt wird! Beispiel: Aktualisierung einer Software-Bibliothek? Monotones Schreiben kein Monotones Schreiben 46

47 III: Read-Your-Writes Regel: Die Wirkung einer Schreiboperation durch einen Prozess auf ein Datenelement x wird immer von einer nachfolgenden Leseoperation auf x durch denselben Prozess gesehen (unabhängig davon, wo diese Leseoperation stattfindet) Beispiel: Aktualisierung von Web-Seiten oder Passwörtern Read-Your-Writes kein Read-Your-Writes 47

48 IV: Writes Follows Read Regel: Eine Schreiboperation durch einen Prozess auf einem Datenelement x, die einer vorhergehenden Leseoperation für x folgt, findet garantiert auf demselben oder einem neueren Wert von x statt, der gelesen wurde Beispiel: Lesen von Newsgroups. Antworten können nur gelesen werden, wenn die Frage gelesen wurde. Write Follows Read kein Write Follows Read 48

49 Verteilungsprotokolle Welche Möglichkeiten gibt es nun, Replikate zu verteilen? Wir betrachten Verteilungsprotokolle und anschließend spezielle Konsistenzerhaltungsprotokolle. Beim Design solcher Protokolle müssen verschiedene Fragen beantwortet werden 1. Wo, wann und von wem werden die Replikate platziert? 2. Wie werden Updates propagiert? 49

50 Platzierung der Replikate Es können drei verschiedene Arten von Kopien unterschieden werden 1. Permanente Replikate 2. Server-initiierte Replikate 3. Client-initiierte Replikate 50

51 Permanente Replikate Grundlegende Menge von Replikaten, die meist beim Design eines Datenspeichers schon angelegt werden Beispiele: replizierte Web-Site (Client merkt nichts von der Replikation), Mirroring (Client sucht bewusst ein Replikat aus) Meist nur sehr wenige Replikate 51

52 Server-initiierte Replikate Kurzfristig initiiert bei hohem Bedarf, meist in der (Netz-) Gegend, in der der Bedarf auftritt Wichtige Grundlage für das Geschäftsmodell von Web Hosting Services (dynamisches replizieren von Daten) Schwierige Entscheidung: wann und wo sollen die Replikate erzeugt werden bzw. wann gelöscht werden? Dieser Ansatz kann permanente Replikas ersetzen, wenn garantiert ist, dass immer mindestens ein Server ein Datum vorrätig hält. 52

53 Client-initiierte Replikation Meist als (Client) Cache bezeichnet Management des Caches bleibt völlig dem Client überlassen, d.h., der Server kümmert sich nicht um Konsistenzerhaltung Einziger Zweck: Verbesserung der Datenzugriffszeiten Daten werden meist für begrenzte Zeit gespeichert (verhindert permanenten Zugriff auf alte Kopie) Der Cache wird meist auf der Client-Maschine platziert, oder zumindest in der Nähe von vielen Clients. 53

54 Propagierung von Updates Die Implementierung des jeweiligen Konsistenzmodells ist z.t. nicht ganz einfach und hängt von der Art und Weise ab, wie die Updates lokaler Kopien durchgeführt wird. Auch die Eigenschaften der Kommunikationsoperationen (FIFO/kausal konsistenter/total geordneter Multicast) beeinflussen das Ergebnis. Updates werden generell von einem Client auf einer Replika durchgeführt. Diese müssen dann an die anderen Replikas weiter gegeben werden. Verschiedene Design-Gesichtspunkte für die entsprechenden Protokolle Was wird zu den anderen Replikaten propagiert? Wird push oder pull eingesetzt? Unicast oder Multicast? 54

55 Was wird propagiert? Spontan würde man sagen, dass derjenige Server, dessen Replikat geändert wurde, diesen neuen Wert an alle anderen schickt. ( gierige Möglichkeit) Das muss aber nicht unbedingt so gemacht werden. Alternativen: Sende nur eine Benachrichtigung, dass ein Update vorliegt (wird von Invalidation Protocols verwendet und benötigt sehr wenig Bandbreite). Updates erfolgen nur bei Bedarf ( faule Möglichkeit) Transferiere die das Update auslösende Operation (z.b. sortiere(daten) ) zu den anderen Servern (aktive Replikation: benötigt ebenfalls minimale Bandbreite, aber auf den Servern wird mehr Rechenleistung erforderlich) 55

56 Push: Push oder Pull? die Updates werden auf Initiative des Servers, bei dem das Update vorgenommen wurde, verteilt. Die anderen Server schicken keine Anforderungen nach Updates Typisch, wenn ein hoher Grad an Konsistenz erforderlich ist Pull: umgekehrtes Vorgehen Server/Clients fragen nach neuen Updates für Daten Oft von Client Caches verwendet Aspekt Status am Sever Gesendete Nachrichten Antwortzeit auf dem Client Push-basiert Liste mit Client-Repliken und -Caches Aktualisierung (und möglicherweise später die Aktualisierung laden) Unmittelbar (oder Aktualisierung- Laden-Zeit) Pull-basiert Keine Anfragen und Aktualisieren Aktualisierung- Laden-Zeit 56

57 Unicast oder Multicast? Unicast: sende eine Nachricht mit demselben Inhalt an jeden Replika-Server Multicast: sende nur eine einzige Nachricht und überlasse dem Netz die Verteilung; Meist wesentlich effizienter, insbesondere in LANs Multicast wird meist mit Push-Protokollen verbunden, die Server sind dann als Multicast-Gruppe organisiert Unicast passt besser zu Pull, wo immer nur ein Server nach einer neuen Version eines Datums fragt. 57

58 Protokolle zur Konsistenzerhaltung Wie lassen sich nun die verschiedenen Konsistenzmodelle implementieren? Dazu benötigt man Protokolle, mit deren Hilfe sich die verschiedenen Replika-Server abstimmen. Im folgenden Beispiele für sequentielle Konsitenz und eventuelle Konsistenz Man unterscheidet zwei grundlegende Ansätze für diese Protokolle: 1. Primary-based Protocols (Write-Operationen gehen immer an dieselbe (primäre) Kopie) 2. Replicated-Write Protocols (Write-Operationen gehen an beliebige Kopien) 58

59 Primary-Based Protocols Wenn alle Write-Operationen immer nur an eine Kopie gehen, kann man noch einmal unterscheiden, Ob diese Kopie immer am selben entfernten Platz bleibt Ob die primäre Kopie zu dem schreibenden Client verlagert wird Dementsprechend werden unterschiedliche Algorithmen und Protokolle verwendet: Remote-Write Protocoll Local-Write Protocoll 59

60 Remote-Write Protocols alle Updates auf einem einzigen entfernten Server Read-Operationen auf lokalen Kopien (auch primary- Backup protocoll genannt) Nach Update der primären Kopie 1. Aktualisierung der Kopien (z.b. Backup-Server), 2. Bestätigung zurück an primäre Kopie, 3. primäre Kopie informiert den Client damit bleiben alle Kopien konsistent Problem: Performance (beim Client), deshalb wird auch nonblocking Update eingesetzt (aber hier wieder Problem mit Fehlertoleranz) Beste Umsetzung für sequentielle Konsistenz 60

61 Ablauf: ohne lokaler Kopie (pull) 61

62 Ablauf: mit lokaler Kopie (push, blocking) 62

63 Local-Write Protocols Jeder Prozess, der ein Update ausführen will, lokalisiert die primäre Kopie und bewegt diese dann an seinen eigenen Platz. Realisiert sequentielle Konsistenz Gutes Modell auch für mobile Benutzer: 1. hole primäre Kopie 2. breche Verbindung ab 3. Arbeite 4. baue später Verbindung wieder auf 5. keine Updates durch andere Prozesse! 63

64 Ablauf: nur genau eine Kopie (pull) 64

65 Ablauf: Migration der primären Kopie (push, nonblocking) 65

66 Replicated-Write Protocols Bei dieser Art von Protokollen können Write-Operationen auf beliebigen Replikaten ausgeführt werden. Es muss dann entschieden werden, welches der richtige Wert eines Datums ist. Realisiert sequentielle Konsistenz Zwei Ansätze: Active Replication: eine Operation wird an alle Replikas weiter gegeben Quorum-based: es wird abgestimmt, die Mehrheit gewinnt 66

67 Aktive Replikation Jede Replika besitzt einen Prozess, der die Updates durchführt Updates werden meist als Operation propagiert Wichtigstes Problem: alle Updates müssen auf allen Replikas in derselben Reihenfolge ausgeführt werden! Es wird Multicast mit totaler Ordnung benötigt(!), implementiert z.b. mittels Lamport-Uhren Lamport-Zeitstempel unterstützen Skalierung nicht gut Alternative: zentraler Prozess (Sequenzer), der die Sequentialisierung übernimmt (aber nicht besser skaliert...) Kombination aus beiden Ansätzen hat sich als brauchbar erwiesen 67

68 Aktive Replikation: Problem Was passiert, wenn ein repliziertes Objekt ein anderes Objekt aufruft? Jede Replika ruft das Objekt auf! Lösung: verwende eine Middleware, die sich der Replikation bewusst ist. Löst auch das Problem der Verarbeitung der Antworten 68

69 Koordination der replizierten Objekte Weiterleitung eines Aufrufs von einem replizierten Objekts an ein anderes: Nur Ein Replikt leitet request weiter Rückgabe der Antwort: Nur Ein Replikt leitet reply weiter 69

70 Quorum-Based Protocols Idee: Clients müssen zur Ausführung einer Read- oder Write-Operation die Erlaubnis mehrerer Server einholen Jedes Objekt besitzt eine Versionsnummer. Wenn der Client ein Read oder Write durchführen will, muss er eine Erlaubnis erhalten. (Bei Read Übereinstimmung der Versionsnummer, bei Write Zustimmung zur Aktualisierung) Regeln: N W N/2 + 1; N W + N R N + 1; N R 1; Beispiele für N = 12 Ist das der Fall, kann kein anderer Client eine entsprechende Operation ausführen. Korrektes Read Quorum: Write-Write Konflikt: Read One Write All: 12/

71 Kausal konsitente lazy-replikation Realisiert eventuelle Konsistenz gleichzeitig kausale Beziehungen zwischen Operationen berücksichtigt Verwendet in kausal konsistentem Datenspeicher Nutzt lazy-form der Replikation, um Aktualisierungen weiterzugeben Implementierung: mit Hilfe von Vektor-Zeitstempeln Clients dürfen miteinander kommunizieren, müssen aber Informationen über Operationen (auf dem Datenspeicher) austauschen In der Praxis: Menge der Clients realisiert als Menge von Frontends des Datenspeichers Frontends tauschen Informationen aus reine Clients wissen überhaupt nichts über Konsitenz und Replikation 71

72 Systemmodell Unter Berücksichtung der implementierten Konsistenz! 72

73 Read-Operation Vektor-Zeitstempel LOCAL(C)[i] aktuellster Stand von L i gesehen von C VAL(i)[i]aktueller Status von Kopie L i ; VAL(i)[j] Aktualisierungen von L j WORK(i)[i]todo in L i ; WORK(i)[j] todo-aktualisierungen von L j DEP(R) Zeitstempel beschreibt die Abhängigkeiten der Operation 1. Zeitstempel DEP(R) der Leseanforderung := LOCAL(C) 2. DEP(R)<= VAL(i): L i kennt Status von C 3. Kopie L i gibt Wert und VAL(i)an Client 4. LOCAL(C):= max{local(c),val(i)} Synchronisation der Vektoruhr 73

74 Write-Operation 1. Zeitstempel DEP(W) der Leseanforderung := LOCAL(C) 2. WORK(i)[i]:=WORK(i)[i]+1: todo-liste erhöhen 3. ts(w): Rückgabe Zeitstempel (ist Zustand wenn Warteschlange abgearbeitet) 4. LOCAL(C):= max{local(c),ts(i)}synchronisation der Vektoruhr 5. DEP(W)<= VAL(i): L i kennt Status von C Konsitenz: 1. ts(w)[i] = VAL(i)[i] + 1:Operationen, die von anderen Clients direkt an L i gesendet wurden und W vorausgehen, wurden verarbeitet 2. ts(w)[j] VAL(i)[j]für allej i: alle Aktualisierungen, von denen W abhängt, wurden von L i verarbeitet 74

75 Weitergabe von Aktualisierungen Kopie L i tritt (von Zeit zu Zeit) in Verbindung mit Kopie L j : L i sendet alle Operationen ihrer Write-Warteschlange und Vektor-Zeitstempel WORK(i) an L j L j synchronisiert eigenen Vektor WORK(j)und L j kombiniert empfangene Write-Operationen mit eigener Write-Warteschlange (nicht vorhandene W s werden eingetragen) L j sendet alle Operationen ihrer Write-Warteschlange und Vektor-Zeitstempel WORK(j) an L i und L i aktualisiert sich L i überprüft Ausführbarkeit von Read- und Write-Operationen U:={W DEP(W)[k] VAL(i)[k]}:L i kennt Status der Auftragegeber Wähle W aus U mit: für alle W aus U gilt: DEP(W')[k] DEP(W)[k], d.h. W ist unabhängig von W (nach Ausführung von W gilt für die anderen W s immer noch DEP(W)[k] VAL(i)[k]) Noch offen: Löschen in Warteschlangen, d.h. wann ist bekannt, das ein W bei allen ausgeführt wurde? 75

Verteilte Systeme. Replikation

Verteilte Systeme. Replikation Verteilte Systeme Replikation 1 Sinn der Replikation Replikation bedeutet das Halten einer oder mehrerer Kopien eines Datums Ein Prozess, der auf dieses Datum zugreifen will, kann auf jede beliebige Replika

Mehr

Verteilte Systeme. Replikation & Konsistenz I. Prof. Dr. Oliver Haase

Verteilte Systeme. Replikation & Konsistenz I. Prof. Dr. Oliver Haase Verteilte Systeme Replikation & Konsistenz I Prof. Dr. Oliver Haase 1 Überblick Replikation & Konsistenz I Ziele von Replikation Replikationsmodelle datenzentriert Client-zentriert Replikation & Konsistenz

Mehr

Ziele der Replikation Unterschiedliche Replikationsanforderungen Replikationsmodelle. Verteilte Systeme. 6. Konsistenz und Replikation

Ziele der Replikation Unterschiedliche Replikationsanforderungen Replikationsmodelle. Verteilte Systeme. 6. Konsistenz und Replikation 6-2 Überblick Verteilte Systeme 6. Konsistenz und Replikation Sommersemester 2011 Institut für Betriebssysteme und Rechnerverbund TU Braunschweig Dr. Christian Werner Bundesamt für Strahlenschutz Ziele

Mehr

Verteilte Systeme Kapitel 8: Replikation und Konsistenz

Verteilte Systeme Kapitel 8: Replikation und Konsistenz Verteilte Systeme Kapitel 8: Replikation und Konsistenz Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Inhaltsüberblick der Vorlesung

Mehr

Verteilte Systeme. 6. Konsistenz und Replikation

Verteilte Systeme. 6. Konsistenz und Replikation Verteilte Systeme 6. Konsistenz und Replikation Sommersemester 2011 Institut für Betriebssysteme und Rechnerverbund TU Braunschweig Dr. Christian Werner Bundesamt für Strahlenschutz 6-2 Überblick Ziele

Mehr

Verteilte Systeme SS Universität Siegen Tel.: 0271/ , Büro: H-B Stand: 8.

Verteilte Systeme SS Universität Siegen Tel.: 0271/ , Büro: H-B Stand: 8. Verteilte Systeme SS 2013 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 8. Juli 2013 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i

Mehr

Verteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7.

Verteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7. Verteilte Systeme SS 2015 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 7. Juli 2015 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i

Mehr

Vorlesung "Verteilte Systeme" Sommersemester 1999. Verteilte Systeme. Adreßraum. Rechner. Verteilte Systeme, Sommersemester 1999 Folie 19.

Vorlesung Verteilte Systeme Sommersemester 1999. Verteilte Systeme. Adreßraum. Rechner. Verteilte Systeme, Sommersemester 1999 Folie 19. Verteilte Systeme 19. Distributed Shared Memory Sharing!! No Sharing! Sharing? Evolution der Berechnungsmodelle Vergangenheit Gemeinsamer Speicher Einzelrechner Gegenwart Nachrichtenkommunikation Verteilte

Mehr

Verteilte Systeme. Verteilte Systeme. 9 Verteilte Dateisysteme SS 2015

Verteilte Systeme. Verteilte Systeme. 9 Verteilte Dateisysteme SS 2015 Verteilte Systeme SS 2015 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 7. Juli 2015 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i

Mehr

6.1.2 Sequentielle Konsistenz (Lamport 1979)

6.1.2 Sequentielle Konsistenz (Lamport 1979) 6.1.2 Sequentielle Konsistenz (Lamport 1979) Def.: Sequentielle Konsistenz (sequential consistenc): Effekt/Ergebnisse einer verteilten Programmausführung auf repliziertem Objekt = Effekt/Ergebnisse einer

Mehr

Lehrveranstaltung Speichersysteme Sommersemester 2009

Lehrveranstaltung Speichersysteme Sommersemester 2009 Lehrveranstaltung Speichersysteme Sommersemester 2009 Kapitel 12: Network File Systems André Brinkmann Beispiel: SUN NFS NFS (Network File System) ist ein offenes Protokoll für den Austausch von Dateien

Mehr

Verteilte Systeme - 5. Übung

Verteilte Systeme - 5. Übung Verteilte Systeme - 5. Übung Dr. Jens Brandt Sommersemester 2011 Transaktionen a) Erläutere was Transaktionen sind und wofür diese benötigt werden. Folge von Operationen mit bestimmten Eigenschaften: Atomicity

Mehr

Lehrveranstaltung Speichersysteme Sommersemester 2009

Lehrveranstaltung Speichersysteme Sommersemester 2009 Lehrveranstaltung Speichersysteme Sommersemester 2009 Kapitel 11: Network File Systems Part 1 André Brinkmann Gliederung Network AFached Storage Speichertechnologien hinter NAS Verteilte Dateisysteme NFS

Mehr

Prof. Dr.-Ing. Dagmar Meyer Architekturen verteilter SW-Systeme 5 SYNCHRONISATION

Prof. Dr.-Ing. Dagmar Meyer Architekturen verteilter SW-Systeme 5 SYNCHRONISATION Prof. Dr.-Ing. Dagmar Meyer 5 SYNCHRONISATION Warum braucht man Synchronisation? Ausgangssituation Prozesse müssen sich koordinieren / synchronisieren, z. B. beim Zugriff auf gemeinsame Ressourcen. Alle

Mehr

138 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

138 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner 6. Replikation und Konsistenz 6.1 Motivation Replikation: redundantes Vorhalten von Daten auf verschied. Knoten. - Code: unproblemantisch, da i.d.r. unveränderlich, - Daten: o für Daten, die nur gelesen

Mehr

Klausur zum Kurs Verteilte Systeme (1678) am 2. März 2013

Klausur zum Kurs Verteilte Systeme (1678) am 2. März 2013 Fakultät für Mathematik und Informatik Lehrgebiet Kooperative Systeme Prof. Dr. Jörg M. Haake Klausur zum Kurs Verteilte Systeme (1678) am 2. März 2013 Klausurort: Vorname Name: Adresse: Matrikelnummer:

Mehr

Server: Vice nach Tanenbaum, van Steen

Server: Vice nach Tanenbaum, van Steen 3 Fallbeispiel: Coda Nachfolger des Andrew File Systems (AFS) Carnegie Mellon University, 1990 (CMU) Zielsetzung hohe Verfügbarkeit bei mehreren 10.000 Client-Rechnern Fehlertoleranz abgesetzter Betrieb

Mehr

Software-gestützte Pufferung: Verteilte Dateisysteme. BP 2 Software-gestützte Pufferung: Verteilte Dateisysteme BP 2 BP 2 BP 2

Software-gestützte Pufferung: Verteilte Dateisysteme. BP 2 Software-gestützte Pufferung: Verteilte Dateisysteme BP 2 BP 2 BP 2 3.3 Verteilte Dateisysteme Architektur Dateidienst-Interface Verlagerungsmodell (upload/download model) Ganze Dateien werden vom zum transferiert lund dort bearbeitet Typisch für Massenspeichersysteme,

Mehr

Universität Karlsruhe (TH)

Universität Karlsruhe (TH) Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Cluster-Praktikum Sommersemester 2007 Transparent Replizierte Objekte in JavaParty Institut für Programmstrukturen und Datenorganisation

Mehr

Was machen wir heute? Betriebssysteme Tutorium 10. Frage 10.1.a. Frage 10.1.a

Was machen wir heute? Betriebssysteme Tutorium 10. Frage 10.1.a. Frage 10.1.a Was machen wir heute? Betriebssysteme Tutorium 10 Philipp Kirchhofer philipp.kirchhofer@student.kit.edu http://www.stud.uni-karlsruhe.de/~uxbtt/ Lehrstuhl Systemarchitektur Universität Karlsruhe (TH) 1

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

Verteilte Systeme Prof. Dr. Stefan Fischer. Überblick. Sinn der Replikation. TU Braunschweig Institut für Betriebssysteme und Rechnerverbund

Verteilte Systeme Prof. Dr. Stefan Fischer. Überblick. Sinn der Replikation. TU Braunschweig Institut für Betriebssysteme und Rechnerverbund TU Braunschweig Institut für Betriebssysteme und Rechnerverbund Kapitel 11: Konsistenz, Replikation und Fehlertoleranz Überblick Motivation: warum Replikation? warum ein Konsistenzproblem? Konsistenzmodelle

Mehr

stattdessen: geräteunabhängiges, abstraktes Format für Speicherung und Transfer von Daten Datei

stattdessen: geräteunabhängiges, abstraktes Format für Speicherung und Transfer von Daten Datei Dateiverwaltung Dateiverwaltung 2002 Prof. Dr. Rainer Manthey Informatik II 1 Dateien weitere zentrale Aufgabe des Betriebssystems: "Verbergen" der Details der Struktur von und der Zugriffe auf Sekundärspeicher-Medien

Mehr

Multiuser Client/Server Systeme

Multiuser Client/Server Systeme Multiuser /Server Systeme Christoph Nießner Seminar: 3D im Web Universität Paderborn Wintersemester 02/03 Übersicht Was sind /Server Systeme Wie sehen Architekturen aus Verteilung der Anwendung Protokolle

Mehr

Enterprise JavaBeans Überblick

Enterprise JavaBeans Überblick Enterprise JavaBeans Überblick 1. Überblick Java EE 5 und Komponententechnologien 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5. Java Persistence: Entity Manager 6.

Mehr

Klausur zu Verteilte Anwendungen SS 2004 (Prof. Dr. J.Schlichter, Dr. W.Wörndl)

Klausur zu Verteilte Anwendungen SS 2004 (Prof. Dr. J.Schlichter, Dr. W.Wörndl) Klausur zu Verteilte Anwendungen SS 2004 (Prof. Dr. J.Schlichter, Dr. W.Wörndl) Name: Matrikelnummer: (bitte deutlich schreiben) Zustimmung zur Veröffentlichung des Ergebnisses im Internet: ja nein Datum:

Mehr

AFS / OpenAFS. Bastian Steinert. Robert Schuppenies. Präsentiert von. Und

AFS / OpenAFS. Bastian Steinert. Robert Schuppenies. Präsentiert von. Und AFS / OpenAFS Präsentiert von Bastian Steinert Und obert Schuppenies Agenda AFS Verteilte Dateisysteme, allg. Aufbau Sicherheit und Zugriffsrechte Installation Demo Vergleich zu anderen DFs Diskussion

Mehr

Prüfungsprotokoll der mündlichen Prüfung Verteilte Systeme 1678 (Bachelor Informatik)

Prüfungsprotokoll der mündlichen Prüfung Verteilte Systeme 1678 (Bachelor Informatik) Prüfungsprotokoll der mündlichen Prüfung Verteilte Systeme 1678 (Bachelor Informatik) Prüfer: Prof. Dr. Haake Semester der Prüfung: WS 10/11 Datum der Prüfung: 02.05.2011 Dauer: ca. 25 min Note: 2.0 Hier

Mehr

Wie groß ist die Page Table?

Wie groß ist die Page Table? Wie groß ist die Page Table? Im vorigen (typischen) Beispiel verwenden wir 20 Bits zum indizieren der Page Table. Typischerweise spendiert man 32 Bits pro Tabellen Zeile (im Vorigen Beispiel brauchten

Mehr

Unterrichtseinheit 7

Unterrichtseinheit 7 Unterrichtseinheit 7 Freigegebene Ordner: Durch freigegebene Ordnern können Benutzer Zugriff auf Dateien und Ordner innerhalb eines Netzwerkes (auch bei verstreut gespeicherten Daten, mit Hilfe des Distributed

Mehr

Konsistenzproblematik bei der Cloud-Datenspeicherung

Konsistenzproblematik bei der Cloud-Datenspeicherung Konsistenzproblematik bei der Cloud-Datenspeicherung ISE Seminar 2012 Adrian Zylla 1 Cloud Bereitstellung von Speicher- und Rechenkapazität Die Cloud ist für den Anwender eine Blackbox Besitzt drei Servicemodelle

Mehr

JavaSpaces. Markus Helbig, Christian Holder, Marco Jilg, Dominik Krautmann, Richard Waschhauser

JavaSpaces. Markus Helbig, Christian Holder, Marco Jilg, Dominik Krautmann, Richard Waschhauser JavaSpaces Markus Helbig, Christian Holder, Marco Jilg, Dominik Krautmann, Richard Waschhauser Agenda JavaSpaces JINI Dokumentenablage- System Probleme Demo Entstehung von JavaSpaces JavaSpaces entstand

Mehr

Konzepte und Methoden der Systemsoftware. Aufgabe 1: Polling vs Interrupts. SoSe bis P

Konzepte und Methoden der Systemsoftware. Aufgabe 1: Polling vs Interrupts. SoSe bis P SoSe 2014 Konzepte und Methoden der Systemsoftware Universität Paderborn Fachgebiet Rechnernetze Präsenzübung 3(Musterlösung) 2014-05-05 bis 2014-05-09 Aufgabe 1: Polling vs Interrupts (a) Erläutern Sie

Mehr

Systeme 1. Kapitel 3 Dateisysteme WS 2009/10 1

Systeme 1. Kapitel 3 Dateisysteme WS 2009/10 1 Systeme 1 Kapitel 3 Dateisysteme WS 2009/10 1 Letzte Vorlesung Dateisysteme Hauptaufgaben Persistente Dateisysteme (FAT, NTFS, ext3, ext4) Dateien Kleinste logische Einheit eines Dateisystems Dateitypen

Mehr

Universität Karlsruhe (TH)

Universität Karlsruhe (TH) Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Das Java-Speichermodell Prof. Dr. Walter F. Tichy Dr. Victor Pankratius Ali Jannesari Geschichte des Speichermodells Kapitel 17 der Java-Sprachdefinition

Mehr

Transaktionen. Michael Löwe 04/15/16. FHDW Hannover, Freundallee 15, Hannover address:

Transaktionen. Michael Löwe 04/15/16. FHDW Hannover, Freundallee 15, Hannover  address: Transaktionen Michael Löwe 04/15/16 FHDW Hannover, Freundallee 15, 30173 Hannover E-mail address: michael.loewe@fhdw.de KAPITEL 1 Isolation 1.1. Formales Modell für Transaktionen und Ablaufpläne Zustand.

Mehr

VS7 Slide 1. Verteilte Systeme. Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel

VS7 Slide 1. Verteilte Systeme. Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel VS7 Slide 1 Verteilte Systeme Vorlesung 7 vom 27.05.2004 Dr. Sebastian Iwanowski FH Wedel Inhaltsverzeichnis für die Vorlesung Zur Motivation: 4 Beispiele aus der Praxis Allgemeine Anforderungen an Verteilte

Mehr

Client-Server mit Socket und API von Berkeley

Client-Server mit Socket und API von Berkeley Client-Server mit Socket und API von Berkeley L A TEX Projektbereich Deutsche Sprache Klasse 3F Schuljahr 2015/2016 Copyleft 3F Inhaltsverzeichnis 1 NETZWERKPROTOKOLLE 3 1.1 TCP/IP..................................................

Mehr

Client/Server-Systeme

Client/Server-Systeme Frühjahrsemester 2011 CS104 Programmieren II / CS108 Programmier-Projekt Java-Projekt Kapitel 3: /Server-Architekturen H. Schuldt /Server-Systeme Ein zweischichtiges /Server-System ist die einfachste Variante

Mehr

R 3 (x)a. R 4 (x)b. vorherige und spätere bezieht sich auf die Sequenz der sequentiellen Konsistenz gesamter Datenspeicher wird synchronisiert

R 3 (x)a. R 4 (x)b. vorherige und spätere bezieht sich auf die Sequenz der sequentiellen Konsistenz gesamter Datenspeicher wird synchronisiert 2.8 Schwache Konsistenz (3) Beispiel P1 W 1 (x)a W 1 (x)b Sync 1 P2 P3 Sync 2 W 2 (x)c R 3 (x)b R 3 (x)a t P4 Sync 4 R 4 (x)b R 4 (x)b Annahme: Sequenz der Synchronisation ist: Sync 1, Sync 4, Sync 2 System

Mehr

PVFS (Parallel Virtual File System)

PVFS (Parallel Virtual File System) Management grosser Datenmengen PVFS (Parallel Virtual File System) Thorsten Schütt thorsten.schuett@zib.de Management grosser Datenmengen p.1/?? Inhalt Einführung in verteilte Dateisysteme Architektur

Mehr

Grundlagen der Rechnerarchitektur

Grundlagen der Rechnerarchitektur Grundlagen der Rechnerarchitektur Speicher Übersicht Speicherhierarchie Cache Grundlagen Verbessern der Cache Performance Virtueller Speicher SS 2012 Grundlagen der Rechnerarchitektur Speicher 2 Speicherhierarchie

Mehr

Verteilte Dateisysteme

Verteilte Dateisysteme Verteilte Dateisysteme Proseminar: Speicher und Dateisysteme Hauke Holstein Gliederung 1/23 - Einleitung - NFS - AFS - SMB Einleitung Was sind Verteilte Dateisysteme? 2/23 - Zugriff über ein Netzwerk -

Mehr

OFS: Ein allgemeines Offline-Dateisystem auf Basis von FUSE

OFS: Ein allgemeines Offline-Dateisystem auf Basis von FUSE OFS: Ein allgemeines Offline-Dateisystem auf Basis von FUSE Tobias Jähnel und Peter Trommler Fakultät Informatik Georg-Simon-Ohm-Hochschule Nürnberg http://offlinefs.sourceforge.net Übersicht Hintergrund

Mehr

In diesem Abschnitt wollen wir uns mit der Architektur von Datenbank Managements Systemen beschäftigen.

In diesem Abschnitt wollen wir uns mit der Architektur von Datenbank Managements Systemen beschäftigen. 1 In diesem Abschnitt wollen wir uns mit der Architektur von Datenbank Managements Systemen beschäftigen. Zunächst stellt sich die Frage: Warum soll ich mich mit der Architektur eines DBMS beschäftigen?

Mehr

Verteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7.

Verteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7. Verteilte Systeme SS 2015 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 7. Juli 2015 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i

Mehr

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST 2. Interaktive Web Seiten GET und POST Die Übertragungsmethoden GET und POST sind im http Protokoll definiert: POST: gibt an, dass sich weitere Daten im Körper der übertragenen Nachricht befinden: z.b.

Mehr

VS2 Slide 1. Verteilte Systeme. Vorlesung 2 vom Dr. Sebastian Iwanowski FH Wedel

VS2 Slide 1. Verteilte Systeme. Vorlesung 2 vom Dr. Sebastian Iwanowski FH Wedel VS2 Slide 1 Verteilte Systeme Vorlesung 2 vom 15.04.2004 Dr. Sebastian Iwanowski FH Wedel VS2 Slide 2 Inhaltlicher Umfang dieser Vorlesung Inhaltliche Voraussetzungen: Programmieren, Grundkenntnisse Java

Mehr

dpa-infocom - Datenlieferung

dpa-infocom - Datenlieferung dpa-infocom - Datenlieferung Copyright 2006 von dpa-infocom GmbH Status des Dokuments: FINAL Inhaltsverzeichnis Inhaltsverzeichnis...1 1. Verzeichnisstrukturen...2 2. Nachrichtenmanagement...2 3. Datenübertragung...3

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

Virtueller Speicher. SS 2012 Grundlagen der Rechnerarchitektur Speicher 44

Virtueller Speicher. SS 2012 Grundlagen der Rechnerarchitektur Speicher 44 Virtueller Speicher SS 2012 Grundlagen der Rechnerarchitektur Speicher 44 Die Idee Virtuelle Adressen Prozess 1 Speicherblock 0 Speicherblock 1 Speicherblock 2 Speicherblock 3 Speicherblock 4 Speicherblock

Mehr

Verteilte Systeme SS 2015. Universität Siegen Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7.

Verteilte Systeme SS 2015. Universität Siegen Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7. Verteilte Systeme SS 2015 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 7. Juli 2015 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i

Mehr

White Paper. MOBIPRO XConnector

White Paper. MOBIPRO XConnector White Paper MOBIPRO XConnector Dieses White Paper beinhaltet eine generelle Beschreibung der Funktionalität und Konfigurationsmöglichkeiten des XConnectors. WHITE PAPER... 1 1 ÜBERSICHT... 3 1.1 Beschreibung...3

Mehr

ein verteiltes und repliziertes Dateisystem XtreemOS IP project is funded by the European Commission under contract IST-FP6-033576

ein verteiltes und repliziertes Dateisystem XtreemOS IP project is funded by the European Commission under contract IST-FP6-033576 ein verteiltes und repliziertes Dateisystem is funded by the European Commission XtreemOS IPunder project contract IST-FP6-033576 1 Das XtreemOS Projekt Europäisches Forschungsprojekt gefördert von der

Mehr

S.M. Hartmann GmbH IT Solutions

S.M. Hartmann GmbH IT Solutions S.M. Hartmann GmbH 82008 Unterhaching Prager Straße 7 www.smhsoftware.de S.M. Hartmann GmbH IT Solutions Software für den modernen Handel SMH-Connect/400 Version V6.0 Beschreibung SMH-Connect: iseries

Mehr

8.4 Das Andrew File System 393 8.5 Ausblicke 404 8.6 Zusammenfassung 410 Übungen 411

8.4 Das Andrew File System 393 8.5 Ausblicke 404 8.6 Zusammenfassung 410 Übungen 411 Inhaltsverzeichnis Vorwort 11 Aufgabenbereiche und Leserschaft 11 Aufbau dieses Buches 12 Literatur 12 Änderungen in dieser Auflage 13 Danksagungen 14 Web-Site 14 Kapitel 1 Charakteristische Eigenschaften

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 3 12.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: a)

Mehr

IUG DRESDEN ERSTELLUNG VON ROBUSTEN NATURAL SERVICES Software AG. All rights reserved. For internal use only

IUG DRESDEN ERSTELLUNG VON ROBUSTEN NATURAL SERVICES Software AG. All rights reserved. For internal use only IUG DRESDEN ERSTELLUNG VON ROBUSTEN NATURAL SERVICES 2016 Software AG. All rights reserved. For internal use only DIGITAL BUSINESS APPLICATIONS DRIVE THE DIGITAL BUSINESS Partner Lieferanten Kunden SaaS

Mehr

I/O: Von der Platte zur Anwendung. Von Igor Engel

I/O: Von der Platte zur Anwendung. Von Igor Engel I/O: Von der Platte zur Anwendung Von Igor Engel 1 Gliederung 1 Einleitung 2 Übersicht 3 Systemaufrufe Beispiel in Unix 4 Dateien 4.1 Dateisysteme 4.2 Transport der Daten 5 Festplattentreiber 6 Festplattenkontroller

Mehr

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer Verteiltes Backup Einleitung Grundlegende Backup Techniken Backup in Netzwerken Client/Server Peer-to-Peer Einleitung Backup: Das teilweise oder gesamte Kopieren der in einem Computersystem vorhandenen

Mehr

10. Verteilte Dateisysteme 10.1 Transparenter Zugriff auf nicht-lokale Dateien

10. Verteilte Dateisysteme 10.1 Transparenter Zugriff auf nicht-lokale Dateien 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

Mehr

2 2. Tag. 2.1 Das Dateisystem. das Dateisystem organisiert die Speicherung von Daten. viele Betriebssysteme haben verschiedene Dateisysteme

2 2. Tag. 2.1 Das Dateisystem. das Dateisystem organisiert die Speicherung von Daten. viele Betriebssysteme haben verschiedene Dateisysteme 2 2. Tag 2.1 Das Dateisystem das Dateisystem organisiert die Speicherung von Daten viele Betriebssysteme haben verschiedene Dateisysteme ein gutes Dateisystem ist wichtig um Daten sicher zu lagern Das

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Zusammenfassung Kapitel 4 Dateiverwaltung 1 Datei logisch zusammengehörende Daten i.d.r. permanent

Mehr

SODA. Die Datenbank als Document Store. Rainer Willems. Master Principal Sales Consultant Oracle Deutschland B.V. & Co. KG

SODA. Die Datenbank als Document Store. Rainer Willems. Master Principal Sales Consultant Oracle Deutschland B.V. & Co. KG SODA Die Datenbank als Document Store Rainer Willems Master Principal Sales Consultant Oracle Deutschland B.V. & Co. KG vs No Anforderungskonflikte Agile Entwicklung Häufige Schema-Änderungen Relationales

Mehr

Aufgaben: (dazugehörige Kapitel / Seitenangaben in Kursiv: Kapitel Seite Seitennummern)

Aufgaben: (dazugehörige Kapitel / Seitenangaben in Kursiv: Kapitel Seite Seitennummern) Klausur Verteilte Systeme 15.6. R120A 8:00-9:30 5 Aufgaben, 50 Punkte (8 12 pro Aufgabe) 45-50 1.0 44 1.1 35 2.0 25 3.0 15 4.0 http://www.bts.fh-mannheim.de Aufgaben: (dazugehörige Kapitel / Seitenangaben

Mehr

Peg-Solitaire. Florian Ehmke. 29. März / 28

Peg-Solitaire. Florian Ehmke. 29. März / 28 Peg-Solitaire Florian Ehmke 29. März 2011 1 / 28 Gliederung Einleitung Aufgabenstellung Design und Implementierung Ergebnisse Probleme / Todo 2 / 28 Einleitung Das Spiel - Fakten Peg-33 33 Löcher, 32 Steine

Mehr

8. Verteilte Dateisysteme 8.1 Transparenter Zugriff auf nicht-lokale Dateien! 8.1.1 Windows Dateifreigabe:

8. Verteilte Dateisysteme 8.1 Transparenter Zugriff auf nicht-lokale Dateien! 8.1.1 Windows Dateifreigabe: 8. Verteilte Dateisysteme 8.1 Transparenter Zugriff auf nicht-lokale Dateien! 8.1.1 Windows Dateifreigabe: Client für Microsoft Netzwerke: - Remote Volumes werden sichtbar, - Rechner im Netz werden sichtbar,

Mehr

Verteilte Systeme. Verteilte Systeme. 5 Prozeß-Management SS 2016

Verteilte Systeme. Verteilte Systeme. 5 Prozeß-Management SS 2016 Verteilte Systeme SS 2016 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 31. Mai 2016 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/14) i

Mehr

Datenbanken Konsistenz und Mehrnutzerbetrieb III

Datenbanken Konsistenz und Mehrnutzerbetrieb III Datenbanken Konsistenz und Mehrnutzerbetrieb III 1. Oracle Architektur! Komponenten des Oracle Servers! Zugriff über Netzwerk 2. Zugriffsrechte! Starten und Schließen der Datenbank! Nutzer und Rollen!

Mehr

Systeme I: Betriebssysteme Kapitel 8 Speicherverwaltung

Systeme I: Betriebssysteme Kapitel 8 Speicherverwaltung Systeme I: Betriebssysteme Kapitel 8 Speicherverwaltung Version 21.12.2016 1 Inhalt Vorlesung Aufbau einfacher Rechner Überblick: Aufgabe, Historische Entwicklung, unterschiedliche Arten von Betriebssystemen

Mehr

Rechnerarchitektur SS 2012

Rechnerarchitektur SS 2012 Rechnerarchitektur SS 2012 Cachekohärenz Michael Engel TU Dortmund, Fakultät für Informatik Teilweise basierend auf Material von Gernot A. Fink und R. Yahyapour 11. Juni 2013 Speicher in MP-Systemen Zentrales

Mehr

Dateisystem: Einführung

Dateisystem: Einführung Dateisystem: Einführung Hauptaufgabe des Dateisystems ist der schnelle und zuverlässige Zugriff auf Dateien Problem: Entweder schneller Zugriff oder viel Redunanz beim speichern! Zusätzlich müssen Unterverzeichnisse

Mehr

Dateisystem: Einführung

Dateisystem: Einführung Dateisystem: Einführung Hauptaufgabe des Dateisystems ist der schnelle und zuverlässige Zugriff auf Dateien Problem: Entweder schneller Zugriff oder viel Redunanz beim speichern! Zusätzlich müssen Unterverzeichnisse

Mehr

BreakerVisu External Profiles Assistant

BreakerVisu External Profiles Assistant Handbuch 03/2016 BV External Profiles Assistant BreakerVisu External Profiles Assistant Wichtigste Steuerungen BreakerVisu External Profiles Assistant Wichtigste Steuerungen Steuerung Profile directory

Mehr

Typ : void* aktuelle Parameter Pointer von beliebigem Typ

Typ : void* aktuelle Parameter Pointer von beliebigem Typ 2. Funktionen - Prototypvereinbarung typangabe funktionsname(parameterliste); - Funktionsdefinition typ funktionsname(parameterliste){ Anweisung - Funktionstyp -> Typ der Funktionswertes zulaessige Typangaben

Mehr

Grundlagen der Dateisysteme. Daniel Lieck

Grundlagen der Dateisysteme. Daniel Lieck Grundlagen der Dateisysteme Daniel Lieck Einführung Dateisysteme wofür r eigentlich? - Ändern, Erstellen, Löschen L von Dateien - Strukturierung der Dateien auf Datenträger - Dateiname und rechnerinterne

Mehr

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1 Datenbanksystem System Global Area Hintergrundprozesse Dr. Frank Haney 1 Komponenten des Datenbanksystems System Global Area Program Global Area Hintergrundprozesse Dr. Frank Haney 2 System Global Area

Mehr

1 Network File System ( NFS )

1 Network File System ( NFS ) Network File System 1 Network File System ( NFS ) 1.1 Motivation für die Entwicklung Mit Hilfe von ftp können komplette reguläre Dateien von einem Rechner über das Netzwerk zu einem anderen Rechner transferiert

Mehr

Verschlüsseln eines Bildes. Visuelle Kryptographie. Verschlüsseln eines Bildes. Verschlüsseln eines Bildes

Verschlüsseln eines Bildes. Visuelle Kryptographie. Verschlüsseln eines Bildes. Verschlüsseln eines Bildes Verschlüsseln eines Bildes Visuelle Kryptographie Anwendung von Zufallszahlen Wir wollen ein Bild an Alice und Bob schicken, so dass Alice allein keine Information über das Bild bekommt Bob allein keine

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Institut für Informatik Prof. Dr. Bernhard Bauer Stephan Roser Viviane Schöbel Wintersemester 07/08 Übungsblatt 4 18.1.07 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1:

Mehr

3 Programmiermodelle für parallele und verteilte Systeme

3 Programmiermodelle für parallele und verteilte Systeme 3 Programmiermodelle für parallele und verteilte Systeme Das vorherrschende Programmiermodell für parallele und verteilte Systeme ist das Client Server Modell. Das Client Server Modell ist unabhängig von

Mehr

Replikation und Synchronisation. in mobilen Datenbanksystemen

Replikation und Synchronisation. in mobilen Datenbanksystemen in mobilen Datenbanksystemen 6. Juni 2002 Von Thomas Hoffmann und Sebastian Seidler E-Mail: {hothomas,bastl14w}@minet.uni-jena.de 1 Inhalt Einleitung Was ist Replikation? Was ist Synchronisation? Replikationsverfahren

Mehr

Bedeutung der Metadateien. Alle Metadaten werden in Dateien gehalten. NTFS ist ein Journal-File-System

Bedeutung der Metadateien. Alle Metadaten werden in Dateien gehalten. NTFS ist ein Journal-File-System 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6.3 Metadaten 6.3 Metadaten (2) Alle Metadaten werden in Dateien gehalten Indexnummer 0 1 2 3 4 5 6 7 8 16 17 MFT

Mehr

Installation von MS SQL-Server 2014 Express

Installation von MS SQL-Server 2014 Express ALGE 2016 SQL Server Installation Inhaltsverzeichnis Installation von MS SQL-Server 2014 Express...1 Datenbank für Remote- Zugriff vorbereiten...6 Windows Firewall Konfiguration...9 Falls Sie ein Englischsprachiges

Mehr

Network-Attached Storage mit FreeNAS

Network-Attached Storage mit FreeNAS Network-Attached Storage mit FreeNAS Diese Anleitung zeigt das Setup eines NAS-Servers mit FreeNAS. FreeNAS basiert auf dem OS FreeBSD und unterstützt CIFS (samba), FTP, NFS, RSYNC, SSH, lokale Benutzer-Authentifizierung

Mehr

Ersetzbarkeit und Verhalten

Ersetzbarkeit und Verhalten Ersetzbarkeit und Verhalten U ist Untertyp von T, wenn eine Instanz von U überall verwendbar ist, wo eine Instanz von T erwartet wird Struktur der Typen für Ersetzbarkeit nicht ausreichend Beispiel: void

Mehr

Lehrveranstaltung Speichersysteme Sommersemester 2009. Kapitel 13: Parallele Dateisysteme. André Brinkmann

Lehrveranstaltung Speichersysteme Sommersemester 2009. Kapitel 13: Parallele Dateisysteme. André Brinkmann Lehrveranstaltung Speichersysteme Sommersemester 2009 Kapitel 13: Parallele Dateisysteme André Brinkmann Gliederung Parallele und Cluster Dateisysteme SemanFk der gemeinsamen Nutzung von Dateien Pufferung

Mehr

Geräteverwaltung: Einführung

Geräteverwaltung: Einführung Geräteverwaltung: Einführung Die Ziele einer Geräteverwaltung sind: Einfache Softwareschnittstelle Gleiche Software Schnittstellen für alle Geräte eines Gerätetyps z.b.: unabhängig vom Soundkartenhersteller

Mehr

Die Sicht eines Sysadmins auf DB systeme

Die Sicht eines Sysadmins auf DB systeme Die Sicht eines Sysadmins auf DB systeme Robert Meyer 21. Oktober 2016 Robert Meyer Die Sicht eines Sysadmins auf DB systeme 21. Oktober 2016 1 / 20 Inhaltsverzeichnis 1 Einleitung 2 IO unter Linux typische

Mehr

Übersicht. Virtuelle Maschinen Erlaubnisse (Permission, Rechte) Ringe. AVS SS Teil 12/Protection

Übersicht. Virtuelle Maschinen Erlaubnisse (Permission, Rechte) Ringe. AVS SS Teil 12/Protection Übersicht Virtuelle Maschinen Erlaubnisse (Permission, Rechte) Ringe 2 Behandelter Bereich: Virtualisierung Syscall-Schnittstelle Ports Server Apps Server Apps Betriebssystem Protokolle Betriebssystem

Mehr

STRATO ProNet VLAN Produktbeschreibung Stand: Mai 2015

STRATO ProNet VLAN Produktbeschreibung Stand: Mai 2015 STRATO ProNet VLAN Produktbeschreibung Stand: Mai 2015 Inhalt 1 STRATO ProNet VLAN... 2 2 Mögliche Einsatzszenarien... 2 2.1 Verbindung zweier Server als Failover-Cluster... 2 2.2 Verbindung zweier Server

Mehr

Verteilte Systeme CS5001

Verteilte Systeme CS5001 Verteilte Systeme CS5001 Th. Letschert TH Mittelhessen Gießen University of Applied Sciences Client-Server-Anwendungen: Vom passiven (shared state) Monitor zum aktiven Monitor Monitor (Hoare, Brinch-Hansen,

Mehr

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1 Grid-Systeme Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit 07.06.2002 Grid Systeme 1 Gliederung Vorstellung verschiedener Plattformen Globus

Mehr

6 Speicherorganisation

6 Speicherorganisation Der Speicher des Programms ist in verschiedene Speicherbereiche untergliedert Speicherbereiche, die den eigentlichen Programmcode und den Code der Laufzeitbibliothek enthalten; einen Speicherbereich für

Mehr

VS3 Slide 1. Verteilte Systeme. Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel

VS3 Slide 1. Verteilte Systeme. Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel VS3 Slide 1 Verteilte Systeme Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel Inhaltsverzeichnis für die Vorlesung Zur Motivation: 4 Beispiele aus der Praxis Allgemeine Anforderungen an Verteilte

Mehr

Programmierung im Grossen

Programmierung im Grossen 1 Letzte Aktualisierung: 16. April 2004 Programmierung im Grossen Bertrand Meyer 2 Vorlesung 4: Abstrakte Daten-Typen Übungen 3 Passe die vorhergehende Spezifikation von Stacks (LIFO, Last-In First-Out

Mehr

Verteilte Systeme Prof. Dr. Stefan Fischer. Überblick. Motivation. TU Braunschweig Institut für Betriebssysteme und Rechnerverbund

Verteilte Systeme Prof. Dr. Stefan Fischer. Überblick. Motivation. TU Braunschweig Institut für Betriebssysteme und Rechnerverbund TU Braunschweig Institut für Betriebssysteme und Rechnerverbund Kapitel 7: Verteilte Verzeichnisund Dateidienste Überblick Namens- und Verzeichnisdienste Motivation Namen/Attribute Generelle Anforderungen

Mehr

Dynamisches Huffman-Verfahren

Dynamisches Huffman-Verfahren Dynamisches Huffman-Verfahren - Adaptive Huffman Coding - von Michael Brückner 1. Einleitung 2. Der Huffman-Algorithmus 3. Übergang zu einem dynamischen Verfahren 4. Der FGK-Algorithmus 5. Überblick über

Mehr