Verteilte Systeme. Verteilte Dateisysteme und Replikation
|
|
- Hede Hertz
- vor 6 Jahren
- Abrufe
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 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
MehrVerteilte 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
MehrZiele 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
MehrVerteilte 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
MehrVerteilte 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
MehrVerteilte 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
MehrVerteilte 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
MehrVorlesung "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
MehrVerteilte 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
Mehr6.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
MehrLehrveranstaltung 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
MehrVerteilte 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
MehrLehrveranstaltung 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
MehrProf. 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
Mehr138 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
MehrKlausur 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:
MehrServer: 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
MehrSoftware-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,
MehrUniversitä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
MehrWas 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
MehrGrundlagen 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
MehrVerteilte 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
Mehrstattdessen: 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
MehrMultiuser 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
MehrEnterprise 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.
MehrKlausur 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:
MehrAFS / 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
MehrPrü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
MehrWie 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
MehrUnterrichtseinheit 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
MehrKonsistenzproblematik 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
MehrJavaSpaces. 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
MehrKonzepte 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
MehrSysteme 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
MehrUniversitä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
MehrTransaktionen. 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.
MehrVS7 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
MehrClient-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..................................................
MehrClient/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
MehrR 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
MehrPVFS (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
MehrGrundlagen der Rechnerarchitektur
Grundlagen der Rechnerarchitektur Speicher Übersicht Speicherhierarchie Cache Grundlagen Verbessern der Cache Performance Virtueller Speicher SS 2012 Grundlagen der Rechnerarchitektur Speicher 2 Speicherhierarchie
MehrVerteilte 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 -
MehrOFS: 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
MehrIn 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?
MehrVerteilte 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
Mehr2. 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.
MehrVS2 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
Mehrdpa-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
MehrTAV Ü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.
MehrVirtueller 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
MehrVerteilte 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
MehrWhite 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
Mehrein 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
MehrS.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
Mehr8.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
MehrGrundlagen 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)
MehrIUG 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
MehrI/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
MehrVerteiltes 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
Mehr10. 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
Mehr2 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
MehrBetriebssysteme 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
MehrBetriebssysteme 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
MehrSODA. 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
MehrAufgaben: (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
MehrPeg-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
Mehr8. 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,
MehrVerteilte 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
MehrDatenbanken 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!
MehrSysteme 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
MehrRechnerarchitektur 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
MehrDateisystem: 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
MehrDateisystem: 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
MehrBreakerVisu 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
MehrTyp : void* aktuelle Parameter Pointer von beliebigem Typ
2. Funktionen - Prototypvereinbarung typangabe funktionsname(parameterliste); - Funktionsdefinition typ funktionsname(parameterliste){ Anweisung - Funktionstyp -> Typ der Funktionswertes zulaessige Typangaben
MehrGrundlagen 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
MehrDatenbanksystem. 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
Mehr1 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
MehrVerschlü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
MehrGrundlagen 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:
Mehr3 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
MehrReplikation 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
MehrBedeutung 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
MehrInstallation 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
MehrNetwork-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
MehrErsetzbarkeit 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
MehrLehrveranstaltung 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
MehrGerä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
MehrDie 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 2 Behandelter Bereich: Virtualisierung Syscall-Schnittstelle Ports Server Apps Server Apps Betriebssystem Protokolle Betriebssystem
MehrSTRATO 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
MehrVerteilte 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,
MehrGrid-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
Mehr6 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
MehrVS3 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
MehrProgrammierung 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
MehrVerteilte 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
MehrDynamisches 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