TU Wien:Verteilte Systeme VO (Göschka)/Prüfung 2008-07-04

Aus VoWi
Zur Navigation springen Zur Suche springen

« Prüfung 2008-05-29 | Prüfung 2008-10-17 »

Frage 1[Bearbeiten]

Frage: Was ist horizontale Verteilung? Mit welchen grundlegenden Design-Fragen müssen Sie sich beim Entwurf der horizontalen Verteilung eines Systems beschäftigen? Gibt es einen Zusammenhang zur vertikalen Verteilung?

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Horizontale Verteilung\s*/si}}

Bei der horizontalen Verteilung können ein Client oder ein Server physisch in logisch äquivalente Teile unterteilt werden, aber jeder Teil arbeitet mit einem eigenen Anteil der vollständigen Datenmenge, sodass die Gesamtlast ausgeglichen ist.

=> "Anteil der vollständigen Datenmenge" => wirkt hier etwas verwirrend. Jeder Teil operiert auf der gleichen, vollständigen Datenmenge und nicht nur auf einem Teil davon. by thex

Wie sicher ist das? Zitat Buch Seite 44 "[..] but each part is operating on its own share of the complete dataset [..]" Ich hätte das wie im ursprünglichen Satz hier interpretiert --emptyvi

Ich denke hier darf nicht von einer Datenbank die repliziert wird ausgegangen werden, sondern z.B. eher von einer Gruppe (Cluster) von Webservern. Dabei arbeitet jeder von ihnen mit einem Anteil (die vom LoadBalancer ihm zugeteilten HTTP Requests) der vollständigen Datenmenge (alle HTTP Requests) --Mannaz 19:08, 9. Mär. 2011 (CET)


Die horizontale Verteilung von Anwendungskomponenten lässt also auch eine Zerlegung der Anwendungskomponenten auf physisch getrennte Rechner zu. Während bei der vertikalen Verteilung Anwendungskomponente genau einem Rechner zugeordnet werden. Wichtiger Bestandteil solcher Systeme ist eine geeignete Middleware,um verteilte Komponenten bzw. Objekte zu einem kohärenten Ganzen zusammen zu führen (z.B. CORBA, Enterprise JavaBeans, etc.) (???)

Beim Entwurf einer horizontalen Verteilung sollte man sich auch Gedanken machen welches Konsistenzmodell gewählt wird um sicherzustellen, dass die Server alle mit den gleichen Datenelementen arbeiten.

Datenzentrierte Konsistenzmodelle (strenge-, sequezielle-, kausale-, FIFO-Konsistenz) versus Clientzentrierte Konsistenzmodelle (Eventuelle Konsistenz, Monotones Lesen, etc)

(mein gedanke dazu)

Designfrage:

  • Werden Replikate erst bei Bedarf erstellt oder schon am Anfang
  • Weitergabe der Aufgaben vom Handler durch Round-Robin oder durch Aufgabenspezifische Unterteilung (aufgabenspez. Verteilung würde man doch bei vertikaler Verteilung nehmen oder? Wenn ich mich an die Laborübung erinnere war eine Round-Robin Alternative, dass mehrere Replikas nach Zufallsprinzip ausgewählt wurden,

Mit den Designfragen könnte auch das gemeint sein(deckt sich ungefähr mit den Folien S.62):

  • Komponenten die oft kommunizieren sollten nahe beieinander liegen
  • Physische Einschränkungen: einige Komponenten können nur auf spezifischen Rechnern oder an speziellen Orten laufen
  • Granularität: Kleinere Komponenten erhoehen die Flexibilitaet, aber ebenso den Netzwerkverkehr. Umgekehrt reduzieren größere Komponenten die Netzwerkbelastung, aber ebenso wird die Flexibilitaet und Wiederverwendbarkeit reduziert.
  • Wahl der Protokolle: entscheidend für Interoperabilität und Last
  • End to End Eigenschaften: CAP - Consistency, Availability, Performance
  • Full distribution -> distributed architecture


Was ich weis kann man das eben wählen ob Round Robin oder Aufgaben spezifisch, ist eben eine Design-Frage)


Horizontale Verteilung kann mit der vertikalen Verteilung kombiniert werden.


Ein Beispiel für einen Webserver mit horizontaler Verteilung

Beispiel zur horizontalen Verteilung (Webserver): Jeder Server verwaltet dieselbe Menge an Webseiten, und immer wenn eine Webseite aktualisiert wird, wird eine Kopie davon auf jeden Server platziert (je nach Konsistenzmodell verschieden schnell). Trifft eine Anforderung ein, wird sie unter Verwendung einer Round-Robin-Strategie an einen Server weitergegeben. Genügend Bandbreite vorausgesetzt, ist diese Form der horizontalen Verteilung sehr effektiv.

TODO: Zusammenhang mit der vertikalen Verteilung


Frage 2[Bearbeiten]

Frage: Erklären Sie "stream-oriented communication". Was ist "QoS" und inwiefern ist es für stream-oriented communication von Bedeutung?

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Stream-orientierte Kommunikation\s*/si}}

Ein Datenstream ist nichts weiter als eine Folge von Dateneinheiten. Sie können sowohl auf kontinuierliche (Audio, Video), als auch auf diskrete Medien angewendet werden. Die zeitliche Abfolge ist für das Streaming von größter Bedeutung, damit die Daten rechtzeitig beim Client eintreffen.

  • asynchron: keine zeitliche Beschränkung (Dateidownload)
  • synchron: maximale End-to-End Verzögerung (Sensorenbeispiel: ein Sensor liefert in einer bestimmten Rate Signale. Diese müssen an den Empfänger übertragen werden. Wenn die Übertragung schneller ist als die Erfassungsrate, ist es ok, wenn sie langsamer ist als die Erfassungsrate, dann gibts Probleme)
  • isochron: minimale und maximale End-to-End Verzögerung (Audio / Video Stream): hier muss die Übertragung zeitgerecht erfolgen. Siehe Audio + Video Stream - beide sollten die gleiche Verzögerung haben, sonst stimmt das Endergebnis nicht zusammen.


Ein einfacher Stream besteht aus einer Datenfolge (z.b. Mono Audio).

Ein komplexer Stream beinhaltet mehrere Substreams die in zeitlicher Abhängigkeit zueinander stehen (Stereo-Audio, Video mit Tonspuren).


QoS (Quality of Service)= Anforderung an zeitliche Steuerung. Solche Anforderungen beschreiben zB was von einem darunterliegenden VS und Netzwerk erwartet wird um sicherzustellen, dass bestimmte Dienste noch korrekt ausgeführt werden können.

  • Erforderliche Bit-Rate
  • max. Verzögerung bei Session beginn
  • max. End-to-End Verzögerung
  • max. Jitter (Verzögerungsvarianz)
  • max. Umlaufverzögerung


Um Jitter zu vermeiden, wird ein Buffer verwendet. Somit können kleine Unregelmäßigkeiten im Datenstrom ausgeglichen werden.


Wenn ein Packet mehrere (Audio und/oder Video) Frames enthält und verloren geht, dann kann eine große Lücke beim Abspielen entstehen. Durch verschachtelte Rahmen (interleaved transmission) kann dieser Effekt reduziert werden. Dafür muss aber eine größere Start Verzögerung in Kauf genommen werden.

Stream lost packet.png


Frage 3[Bearbeiten]

Frage: Geben Sie grundlegende Design-Entscheidungen für Server an und bewerten Sie diese. Gehen Sie auf den Unterschied zwischen stateful und stateless Servern genauer ein und geben Sie Beispiele an. Erläutern Sie anhand einer Skizze Architektur und Funktionsweise eines multi-threaded Servers (zB File- oder Web-Server). Was ist beim Einsatz von Multi-Threading vom Entwickler besonders zu beachten?

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Serverdesign\s*/si}}

TU Wien-Verteilte Systeme VO (Göschka) - distsys tanenbaum S77.gif

Grundlegende Design-Entscheidungen sind zB:

  • benötigt man einen iterativen Server (Server handled alles selbst)
  • oder einen concurrent server (nebenläufig, gibt alle Aufgaben an eigene Worker-Threads oder andere Prozesse weiter)
  • wie werden Interrupts behandelt(zB. wenn man ein File via FTP auf den Server lädt und währenddessen bemerkt, dass es das falsche ist )
    • Server Interrupt: Eine Möglichkeit für den User ist es den Client zu beenden und neu zu starten -> Server wird Verbindung aufgeben und das File verwerfen, da er denkt der Client ist abgestürzt.
    • out of band control: Client und Server so entwickeln dass sie in der Lage sind out of band daten zu senden. Der Server behandelt diese Daten mit höchster Priorität vor allen Anderen. Eine Möglichkeit: Server hört auf einem getrennten Control End Point, ob out of band Daten vom Client kommen.
  • ist der Server / besitzt der Server
    • stateless Server hat keine Information über den Status des Clients und kann eigenen Status ändern ohne den Client darüber zu informieren. (z.b. Webserver). Zustandslose Server enthalten in Wirklichkeit zwar dennoch Informationen über die Clients, aber entscheidend ist dass der Verlust dieser Informationen zu keinen Unterbrechungen führt.
    • stateful Server enthält beständige Information über Clients. Diese werden so lange behalten bis sie ausdrücklich gelöscht werden. (z.B. Fileserver: Tabelle mit Clients und Berechtigungen). Sind aus Clientsicht schneller als stateless Server. Nachteil: Stürzt der Server ab, muss der Status vor dem Absturz wieder hergestellt werden. Gelingt das nicht kommt es zu Problemen.
    • soft state (der Server kennt den Client nur für eine bestimmte Zeit und verwirft danach alles wieder)
    • session state (hier werden Aktionen immer in einer Session ausgeführt, in der sich ein Client authentifiziert hat - zB WebServer mit Session à la Cookies)
  • wie/wo kann man den Server finden?
    • Name oder Directory Server
    • Well known Port addresses(0-1023)

Arten von Servern:

  • multithreaded server: bestehend aus einem dispatcher und mehreren worker threads. Der dispatcher thread wartet auf eingehende anfragen, und startet pro anfrage einen worker thread, an welchen die anfrage weitergereicht wird. Somit ist es möglich, dass während eine Anfrage bearbeitet wird, der dispachter thread wieder auf neue Anfragen warten kann.
  • single-threaded server: Bestehend aus nur einem einzigen Thread, welcher die Anfragen entgegennimmt, bearbeitet und das Ergebnis an den Client sendet. Die Implementierung ist recht einfach, jedoch kann immer nur ein Client zur selben Zeit bearbeitet werden.
  • finite-state machine: Ebenfalls nur ein Thread. Die finite state machine hält eine Tabelle mit Ergebnissen bereit, sodass eine Anfrage, wo das Ergebnis bekannt ist, sofort beantwortet werden kann. Falls das Ergebnis nicht in der Tabelle enthalten ist, wird eine Anfrage an die Festplatte geschickt, jedoch sofort weitergearbeitet. Wenn das Ergebnis dieser Anfrage eintrifft, wird es in die Tabelle eingetragen und an den Client geschickt.

Beim Einsatz von Multi-Threaded Servern ist zu beachten:

  • Wer erzeugt den Thread?
  • Wann wird der Thread erzeugt?
  • Fixe Anzahl an Threads?
  • Verschiedene Architekturen sind möglich(Thread-per-request, Thread-per-connection, Thread-per-object)
  • Synchronisation

Die Thread-Erzeugung ist sehr teuer. Die Kosten der Thread-Erzeugung können verringert werden, wenn man einen Thread für mehrere Anfragen verwendet. Eine fixe Anzahl an Threads können schon beim Starten erzeugt and und den einkommenden Anfragen zugewiesen werden.


Frage 4[Bearbeiten]

Frage: Was sind die Besonderheiten von Objekt-Servern? Welche Arten gibt es dabei für die "Invocation", also den Aufruf (evtl. auch die Aktivierung/Activation) eines Objektes auf Server-Seite (Policies hinsichtlich thread, code sharing, und object creation)? Was ist in diesem Zusammenhang ein Objekt-Adapter?

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Objektserver\s*/si}}

Ein Objektserver dient zum Bereitstellen von Objekten in einem Verteilten System. Im Gegensatz zu herkömmlichen Servern, stellt der Objektserver keine spezifischen Dienste zur Verfügung, dafür sind die Objekte des Servers zuständig. Der Objektserver stellt lediglich die Mittel, um lokale Objekte remote zugreifbar zu machen. Bevor ein Objekt aufgerufen kann, muss es in den Adressraum des Servers gebracht werden. Es gibt verschiedene Arten der Aktivierung von Objekten: Sie können beim Start des Servers (alle zugleich) erstellt werden, oder beim ersten Aufruf (können nach dem ersten Aufruf bestehen bleiben bis zur Beendigung des Servers, oder gleich nach Beendigung der Anfrage zerstört werden)

Des weiteren kann die activation policy eines Objektes festlegen, ob es in einem gemeinsamen Speicherbereich mit anderen Objekten, oder in einem eigenen Speicherbereich untergebracht wird (aus Sicherheitsgründen).

Durch Codesharing können sich Objekte den Code teilen, sodass dieser nur einmal am Server geladen werden muss (z.B.: Ein Objekt zum Zugriff auf eine Datenbank, welches von allen Anfragen benutzt werden kann). Es kann vom Objektserver für jedes Objekt ein Thread erzeugt werden, oder ein Thread für alle Objekte (Warteschlange falls Anfragen während der Bearbeitung eintreffen). Alle diese Entscheidungen werden in der activation policy festgelegt.

Der Object Adapter dient als Hülle um ein Objekt und stellt den Mechanismus bereit, um ein Objekt nach einer gewissen Strategie (activation policy) zu aktivieren.

Ein Objekt Server kann mehrere Object Adapter beinhalten, ein Object Adapter mehrere Objekte.

Wichtig ist noch, dass ein Object Adapter generisch ist, er weiß nicht von den Schnittstellen eines Objektes, nur so kann er für beliebige Objekte verwendet werden.


Die Skizze ist im englischen Buch (Second Edition) auf der Seite 77 zu finden. (--> glaub ich nicht) Hier wird wohl eher die Grafik von Seite 453 gemeint sein.

  • Seite 491 in der Deutschen ausgabe (2.auflage)

Bild: TU Wien-Verteilte Systeme VO (Göschka) - TU Wien-Verteilte Systeme Object Adapter.png


Frage 5[Bearbeiten]

Frage: Erläutern Sie das Domain Name System DNS, sowie den Ablauf bei der Namens-Auflösung anhand der DNS Database (Resource Records). Was ist reverse lookup? Was ist ein zone-transfer?

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Domain Name System\s*/si}}


DNS ist das NS für das Internet. Es wird verwendet um Domainnamen auf IP-Adressen zu mappen. Eine Domain kann man sich als „Unterbaum“ eines hierarchischen Graphen vorstellen. Pfadnamen nennt man „Domainname“.


Knoten speichern ihre Daten in Resource Records. Resource Record ist die kleinste Informationseinheit im DNS.

ausgewaehlte Resource Record Typen:

  • SOA ? Start of Authority: Informationen zur dargestellten Zone
  • A ? IP eines Hosts
  • MX ? Mailserver
  • NS ? Name eines NS der die dargestellte Domain implementiert
  • CNAME ? Alias-Implementierung von DNS: speichert den cannonical name (= primary name) des hosts (--> soft link)
  • PTR ? wird für reverse DNS verwendet: hat host mit cannonical name soling.cs.vu.nl die IP 130.37.20.20, dann wird ein PTR eintrag für soling.cs.vu.nl mit wert 20.20.37.130.in-addr.arpa angelegt
  • (etc.)

Caching und Replikation werden zur Steigerung der Effektivität verwendet.


Zone-Transfer = Zonenübertragung (Übertragung von Resource Records) auf einen anderen NS also z.b. von Primary NS auf Secondary NS. Dies dient der Ausfallsicherheit und Performance.


(Ein Secondary NS kann ein Primary NS einer anderen Zone sein. Beide sind authorative).


Reverse-lookup: wird benötigt um von einer IP auf einen Domainname zu schließen. Dazu wurde eine eigene Domain (mit 3 (Ebenen von) Subdomains) begründet: in-addr.arpa-Domäne.

Somit lassen sich z.B. alle IP Adressen die mit 193 beginnen in der 193.in-addr.arpa Domäne finden.

Ablauf bei der Namens-Auflösung anhand der DNS Database (Resource Records):

Wenn man eine Verbindung zu einer Domain aufbauen will, braucht man zunächst einmal dessen IP-Adresse. Angenommen, ein Rechner X will eine Verbindung zu „de.wikipedia.org.“ (Rechner Y) aufbauen. Dazu braucht er dessen IP-Adresse. In den folgenden Schritten wird beschrieben, wie dies ablaufen könnte.

  1. Der Rechner X sucht in seiner Hosts-Datei, ob die IP-Adresse für „de.wikipedia.org“ dort hinterlegt ist. Falls dem nicht so ist, fragt er beim DNS-Server nach.
  2. Hat der DNS-Server von Rechner X eine IP-Adresse für den angefragten Namen zwischengespeichert, antwortet er damit und die Anfrage kommt zum Ende (siehe letzter Punkt). Andernfalls fragt er einen der 13 Root-Nameserver nach „de.wikipedia.org.“.
  3. Der Root-Nameserver findet heraus, dass die Auflösung dieses Namens in der „org.“-Zone weitergeht und sendet die Namen und die IP-Adressen der „org.“-Nameserver zum DNS-Server von Rechner X.
  4. Nun fragt der DNS-Server von Rechner X einen der Nameserver für „org.“-Domains nach „de.wikipedia.org.“.
  5. Der „org.“-Nameserver sendet ihm die Namen der Nameserver für die Zone „wikipedia.org.“.
  6. Anschließend fragt der DNS-Server von Rechner X einen „wikipedia.org.“-Nameserver wie die IP-Adresse des Namens "de.wikipedia.org." ist.
  7. Mit dieser Adresse wird an den DNS-Server von Rechner X geantwortet und der …
  8. … sendet sie an den Rechner X, welcher nun zum Beispiel seine HTTP-Anfragen an die IP-Adresse von „de.wikipedia.org.“ senden kann.


Frage 6[Bearbeiten]

Frage: Wozu braucht man Uhrensynchronisation? Erläutern Sie das NTP und den Berkeley Algorithmus. Was ist die Problematik bei der Synchronisation von Physical Clocks?

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Uhrensynchronisation\s*/si}}

Uhrensynchronisation braucht man für die Festlegung der Reihenfolge von Operationen in Verteilten Systemen (Korrektheit verteilter und zeitabhängiger Informationsverarbeitung). Es muss nicht immer eine "wirkliche" Uhr verwendet werden. Es kann auch nur eine logische Uhr verwendet werden.

NTP (Network Timing Protocol): Es handelt sich dabei um eine Synchronisation mit einem externen Zeitgeber. Die Genauigkeit von Zeitgebern wird durch das sogenannte Stratum definiert. Je niedriger es ist, desto genauer ist eine Zeitquelle. Beim NTP wird ein höheres Stratum mit einem niedrigeren synchronisiert. Ein Rechner sendet eine Nachricht an den Zeitserver und merkt sich den Sendezeitpunkt t1. Der Server zeichnet sich den Empfangszeitpunkt t2 sowie den Sendezeitpunkt der Antwort (kurz davor) t3 und schickt die Antwort. Der Rechner zeichnet den Empfangszeitpunkt t4 auf. (t1 und t4: lokale Zeit; t2 und t3: Serverzeit)

Berechnung der Abweichung und des Delays:

Abweichung = ((t2 - t1) + (t3 - t4)) / 2

Delay = ((t2 - t1) + (t4 - t3)) / 2


Die Abweichung mit zugehörigem Delay wird acht mal ermittelt und die Abweichung mit dem kleinsten delay effektiv verwendet. Korrektur: beschleunigen oder bremsen der lokalen Uhr.

Delay über einem Grenzwert --> Zeitquelle nicht vertrauenswürdig (citation needed!).

Timing delay.png

Berkley Algorithmus: Es handelt sich dabei um eine interne Synchronisation. Es gibt einen Koordinator, welcher seine lokale Zeit an alle sendet (auch an sich selbst). Jeder antwortet mit seiner Abweichung von dieser Referenzzeit. Danach berechnet der Koordinator die durchschnittliche Abweichung und schickt jedem zurück, um wie viel er seine Zeit vor- oder zurückstellen muss. Korrektur: beschleunigen oder bremsen der lokalen Uhr.

  • Problematik: Uhren dürfen nie zurück gestellt werden, nur über längere Zeit verlangsamt. Antwortzeiten über Netzwerk unterschiedlich.

Clock Problem.png

weiß nicht, ob man sich dabei nur physische Uhren konzentrieren soll oder nicht (bitte diesen Punkt überarbeiten). Bei physischen Uhren kann es durch den Kristall-Oszillator zu einer Uhr-Asymmetrie kommen.

Edit: Ich glaub das Problem von "Physical Clocks" ist auf den Folien (WS2012/13) Seite 6 beschrieben. TAI seconds are of constant length, unlike solar seconds. Leap seconds are introduced when necessary to keep UTC in phase with the sun. Weiterer Punkt: ZeitZonenProblematik


Frage 7[Bearbeiten]

Frage: Welche Besonderheiten sind bei der Replikation von Objekten zu beachten? Erläutern Sie (inkl. genauer Skizze) wie man "Replication transparency" in Objektsystemen umsetzen könnte ("replicated invocation").

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Replikation von Objekten\s*/si}}

folgender Absatz ist meiner Meinung nach zu wenig

Eine Menge von Replikaten wird zu einer Gruppe zusammengefasst, wobei ein Replikat der Koordinator dieser Gruppe ist. Aufgerufen wird eine Methode immer bei allen Replikaten um sicherzustellen, dass alle den aktuellen Status haben (etwa über Reliable Multicast). Falls dieses replizierte Objekt jedoch selbst wieder eine Methode eines anderen distributes Objects aufruft, dann wird das nur vom Koordinator der Gruppe gemacht. Andernfalls würde die Methode zu oft aufgerufen werden. Auch die Antwort eines Aufrufs wird nur vom Koordinator zurückgeschickt.


Schon eher trifft es das hier:

Problem: Wenn Objekte in verteilten Systeme verwendet werden und ebenfalls verteilt sind, dann müssen auch die Zugriffe auf Objekte konsistent gehalten werden, da es sonst zu inkonsitenten Zuständen innerhalb des Systems führen kann (entry consistency). Wir müssen also eine gleichzeitige Ausführung von Methoden am Objekt verhindern (durch Locking relativ einfach zu lösen) und wir müssen Änderungen (Methodenaufrufe) auf ALLE Replikate des Objektes verteilen um sicherzustellen, dass nicht 2 unterschiedliche Aufrufe auf ein verteiltes System zur gleichen Zeit geschehen.

Dies kann folgendermaßen geschehen:

  • primary-based approach: ein "Koordinator" übernimmt die Kontrolle und delegiert die Aufrufe. Problem: Overhead, Skalierbarkeit geht verloren, "Koordinator" muss andere verteilte Objekte kennen.
  • totally-ordered-multicasts: Methodenaufrufe werden zB durch Lamport clocks durchnummeriert und dann in der Reihenfolge auf jedes Objekt ausgeführt. Problem dabei: sehr aufwändig, viel Overhead

Folgendes Bild beschreibt ein weiteres Problem:

Repl meth invoc problem.png

Methodenaufrufe auf ein vielleicht nicht verteiltes Objekt werden mehrmals ausgeführt. Um dies zu verhindern, gibt es zB folgenden Ansatz:

Repl meth invoc solutions.png

Falls von A aus ein Aufruf in B erfolgt, so ruft A alle Replikate in B (B1, B2, B3) auf. Wenn B nun seinerseits wieder eine Methode von C aufruft, so wird das nur vom Koordinator von B (z.B. B1) gemacht (und zwar bei C1 und C2). Andernfalls (wenn alle 3 Replikate von B den Aufruf durchführen würden) wäre die Methode von C zu oft aufgerufen worden. Die Antworten werden nur vom Koordinator zurückgegeben, also von z.B. C2 zu allen 3 Replikaten von B, und von B1 zu A.

Wird hier ausreichend auf das "Replication transparency" eingegangen? Wie wird die Replikationstranpsarenz hier konkret umgesetzt?


Frage 8[Bearbeiten]

Frage: Wozu benötigt man Fehlermodelle ganz allgemein? Geben Sie verschiedene Fehlermodelle für "fail-controlled systems" an und diskutieren Sie diese v.a. hinsichtlich des benötigten Aufwandes für die Maskierung. Inwiefern ist es u.U. heikel zu spezifizieren, daß ein System "k-fault-tolerant" sein soll?

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Fehlermodelle und k-fault-tolerance\s*/si}}

Achtung: Diese Fehlermodelle sind falsch, wie wir in der Prüfung vom 17.01.2011 leider feststellen mussten. Siehe http://www.informatik-forum.at/showthread.php?85245-After-test-17.01.2011&p=690539&viewfull=1#post690539


Fehler werden in Klassen unterteilt, um die Auswirkungen besser einschätzen zu können.

  • crash failure: ein server stürtzt ab und gibt keine Rückmeldungen mehr, bis er neugestartet wird. Bis der crash eingetroffen ist, arbeitet der Server korrekt
  • omission failure: Ein Server antwortet nicht auf Anfragen. Das kann verschiedene Gründe haben, beispielsweise, dass er nie die Anfrage erhalten hat (receive omission). Oder der Server hat die Anfrage erhalten, beantwortet, ist aber nicht in der Lage die Antwort zu versenden (send omission)
  • timing failure: Wenn eine Antwort länger als eine definierte Response-Time benötigt, spricht man von einem Timing failure
  • response failure: wenn die Antwort eines Servers inkorrekt ist. Es gibt 2 Arten von response Fehlern: value failure der Server liefert eine falsche Antwort (Suchmaschine liefert webseiten, nach welchen nicht gesucht wurde); state transition failure: passieren, wenn der Server unerwartet auf eine Anfrage reagiert (z.B: ein Server erhält eine Anfrage, welche er nicht erkennen kann und daraus Aktionen startet, welche niemals passieren dürften)
  • arbitrary failure/bizantine failure: ist eine sehr schwerwiegende klasse von fehlern, wenn z.b. ein Server eine Antwort liefert, welche niemals erstellt werden dürfte (die aber nicht als fehlerhaft erkannt werden kann)


Richtige Antworten für Fehlermodelle:


  • fail-halt (fail-stop) system: Halting failures only. Often: halting can be detected; d.h. der Server stürzt ab und teilt das entweder vorher mit oder es ist für andere, von ihm abhängige Prozesse ersichtlich, dass er abgestürzt ist.
  • fail-passive (fail-silent) system: Stuck output instead of erratic output (Silence as opposed to babbling). Often crash failures. Other processes may incorrectly conclude that a server has halted whereby the server is only unexpectedly slow!; Server crashed, aber teilt dies nicht mit (häufig!), hier ist es schwierig festzustellen, ob der Server tatsächlich down oder nur langsam ist (oder das Problem ganz woanders liegt, etwa in der Netzwerkverbindung).
  • fail-consistent system: No byzantine failures.
  • fail-inconsistent system: Any type of failure.
  • fail-safe system: All minor failures, no catastrophic consequences expected.; Output des Systems ist falsch, kann aber von anderen Prozessen als solcher erkannt werden.

Ein System ist k-Fehler-tolerant, wenn es k Fehler verkraften, aushalten kann. Zum Beispiel ist ein Server mit 3 Netzteilen in Bezug auf diese 2-fault tolerant: 2 Netzeile können ausfallen, aber die Stromversorgung ist immer noch gewährleistet!

Hauptproblem in der Spezifikation von k-fault-tolerant liegt v.a. darin, dass man nicht ohne weiteres sagen kann, was k tatsächlich für eine Zahl ist. Kann man zB über Erfahrungswerte festlegen, aber auch das ist natürlich keine Garantie.

Aufwand für die Maskierung:

  • fail-stop or fail-silent: k+1: Wenn man 3 Systeme hat und 1 fällt aus, braucht man genau 1 weiteres um es zu ersetzen, wenn man weiß, dass es down ist.
  • fail-passive (fail-consistent) with or w/o distributed agreement: 2k+1: Wenn man 3 Systeme hat, eines abstürzt dies aber nicht mitteilt, braucht man 2 Systeme, die eine Mehrheit liefern.
  • arbitrary (malicious, two-faced, byzantine) without distributed agreement: 2k+1: Wie fail-passive - wenn man 3 Systeme hat, eines davon lügt, und man schaut sich die Ergebnisse der drei nachher an, braucht man mindestens 2 um zu sagen, was das korrekte Ergebnis ist
  • byzantine (arbitrary failures, malicious, two-faced) with distributed agreement: 3k+1: Hat man 3 Systeme, bei denen das Ergebnis von einem oder mehreren Systemen davon abhängt, wie die anderen entscheiden, kann man mit 3 kein garantiert korrektes Ergebnis finden -> man braucht min. 4 (siehe hierzu #"Byzantinische Generäle" )
  • It is therefore wise to provide enough errordetection logic inside a component to guarantee failsilent behaviour at the system level!


Frage 9[Bearbeiten]

Frage: Wodurch unterscheidet sich Sicherheitspolitik (security policy) von Sicherheitsmechanismen (security mechanisms)? Zählen Sie auch die wichtigsten Mechanismen auf.

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Sicherheitspolitik vs. Sicherheitsmechanismen\s*/si}}

Security policies sind eine Beschreibung der geforderten Schutzmaßnahmen. Darin steht etwa, wer auf welche Services zugreifen darf.

Security mechanisms sind eine Menge von technischen Maßnahmen zur Realisierung der Security policies, z.B. Encryption, Authentification, Authorization und Auditing.



Frage 10[Bearbeiten]

Frage: Erläutern Sie das Grundprinzip von publish/subscribe als Kommunikations-/Koordinationsmechanismus. Worin bestehen die Möglichkeiten aber auch die Probleme dieses Mechanismus (v.a. dessen Implementierung). Erläutern Sie weiters JINI und JavaSpaces als konkrete Technologien.

{{#dpl:resultsheader=Diese Frage wurde bereits in folgenden Prüfungen gestellt: |oneresultheader=Diese Frage wurde bereits in der folgenden Prüfung gestellt: |noresultsheader=* Diese Frage wurde noch nie gestellt! |skipthispage=no |shownamespace=false |uses=Vorlage:Kapitel |replaceintitle=/Verteilte Systeme VO \(Göschka\)\/Prüfung/, |include={Kapitel}.dpl |includematch=/\|\s*TU Wien:Verteilte Systeme VO \(Göschka\)\/Fragenkatalog Wiki\s*\|\s*Publish\/Subscribe\s*/si}}

Publish/Subscribe-Systeme, bei denen Nachrichten mit einem gewissen Typ versehen werden. Diese werden an alle Prozesse zugestellt, die sich dafür interessieren (indem sie sich vorher dafür registriert haben). Funktioniert nur wenn beide Prozesse aktive sind. Dieser Ansatz wird als Meeting-based bezeichnet. Publish/Subscribe systeme sind referentiell ungekoppelt, und können temporal ungekoppelt (Message wird gespeichert und zugestellt, sobald Subscriber online) oder gekoppelt (Subscriber muss online sein um Message zu empfangen)

Vorteile: Der Publisher muss sich keine Gedanken um die Systemtopologie machen und um die Zustellung, sondern kann einfach eine Nachricht in das System schicken. Besser Skalierbar als ein traditionelles Client-Server Modell.

Nachteile: Der Publisher weiß nicht, wer die Nachrichten empfangen soll und kann nicht feststellen, ob alle, die die Nachricht erhalten sollen sie auch erhalten haben. Wenn es viele Publisher, aber nur einen Subscriber gibt, und der Subscriber crasht, gehen die Nachrichten verloren.

(Anm. koDiacc: Hab jetzt kein Buch zur Hand, aber müsste es nicht heißen: Wenn es viele Subscriber (=Abbonnementen) gibt, aber nur einen Publisher (Veröffentlicher), und der Publisher "baden" geht, stehen die Subscriber mit leeren händen da?)


Anm.: ich glaube, dass hier außerdem ("v.a. dessen Implementierung") das Broker-Konzept erklärt werden soll. Hier ein Versuch (hauptsächlich aus dem deutschen Buch (2008, S.176) kopiert):

Ein Broker verwaltet einen Vorrat aus Regeln und Programmen, die eine Nachricht des Typs T1 in eine Nachricht des Typs T2 umwandeln können. Das Problem besteht in der Regeldefinition und Programmentwicklung. Als kommerzielles Produkt werden Broker oftmals irreführend als "intelligent" bezeichnet. Broker werden jedoch mit umfangreichen Entwicklungswerkzeugen mitgeliefert, und der Vorrat an Regeln und Programmen muss weiterhin von Experten gefüllt werden. Die "Intelligenz" des Systems liegt also in Wirklichkeit in den Köpfen von Experten/Entwicklern.


Jini setzt Generative Communication um. Es speichert Tupel von Java-Objekten in einem Shared Dataspace (JavaSpace), aus dem sie von interessierten Prozessen durch Matching mit einem Template (ebenfalls ein Tupel aus Objekten, das aber nicht vollständig ausgefüllt sein muss) wieder abgefragt werden können. Das Abfragen kann dabei auch das gelesene Tupel auch gleich aus dem Datastore entfernen (take-Operation). Neben dem Zugriff auf JavaSpaces unterstützt Jini auch noch Naming und Security (Authentification, so dass nur berechtigte Prozesse auf den Datastore zugreifen können).. [ausreichend??]


Quelle[Bearbeiten]

Ein Prüfungsbericht ist hier im Informatik-Forum zu finden.