TU Wien:Verteilte Systeme VO (Göschka)/Prüfung 2011-01-17

Aus VoWi
Zur Navigation springen Zur Suche springen

Modus[Bearbeiten]

5 Fragen, nur 4 davon sind zu beantworten. Zeit: 45 Minuten.

Frage 1[Bearbeiten]

Frage: Was versteht man unter "Openness"?

{{#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*Was versteht man unter "Openness"?\s*/si}}

Ein "Offenes VS" bietet Dienste nach Standardregeln an, die die Syntax und die Semantik dieser Dienste beschreiben.

In VS werden Dienste generell durch Schnittstellen (Interfaces) spezifiziert, die oft in einer Interface Definition Language (IDL) beschrieben sind.

Gute Spezifikationen sind vollständig (alles, was für eine Implementierung erforderlich ist, wurde spezifiziert) und neutral (Spezifikationen schreiben nicht vor, wie eine Implementierung aussehen soll).

Vollständigkeit ist wichtig für Interoperabilität (beschreibt den Grad bis zu dem zwei Implementierungen von Systemen/Komponenten verschiedener Hersteller zusammenarbeiten können, indem sie sich lediglich auf die Dienste der anderen verlassen, die nach einem gemeinsamen Standard spezifiziert sind).

Neutralität ist wichtig für Portabilität (beschreibt, in welchem Ausmaß eine Anwendung, die für VS A entwickelt wurde, ohne Veränderungen auf VS B ausgeführt werden kann, das dieselben Schnittstellen wie A implementiert).

Ein offenes VS sollte auch erweiterbar sein (Hinzufügen/Ersetzen von Komponenten, ohne dass die vorhandenen beeinträchtigt werden) -> Flexibilität

Um in einem offenen VS Flexibilität zu erzielen, sollte es aus kleinen, einfach austauschbaren/anpassbaren Komponenten angeordnet sein -> impliziert, dass nicht nur Definitionen der Schnittstellen der obersten Ebene (die von Benutzern/Anwendungen gesehen werden), sondern auch für Schnittstellen zu den internen Bestandteilen des Systems bereitgestellt werden sollten, und außerdem beschrieben wird, wie diese Bestandteile zusammenarbeiten.


Nötig ist Trennung von Policy (Richtlinie) und Mechanismus!

Eine Definition: Offenheit (Openness): Ein verteiltes System ist ein offenes verteiltes System, wenn neue Dienste zu den bereits existierenden Diensten hinzugefügt werden können, ohne letztere zu Unterbrechen bzw. Dienste zu duplizieren


Frage 2[Bearbeiten]

Frage: Welche Aspekte Verteilter Systeme sind auf Client-Seite zu berücksichtigen? Wie werden User Interfaces in die Architektur Verteilter Systeme eingebunden? Wie können dabei verschiedene Arten der Transparenz unterstützt werden?

{{#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*Verteilte Systeme auf Client-Seite\s*/si}}

TODO: Verschiedene Aspekte? Wie werden sie eingebunden?


Paper über die Entwicklung von User Interface Tools: UI Tools

Clients müssen in Verteilten Systemen mit dem User und dem Remote Server parallel kommunizieren. Dies kann durch Multithreading am besten und einfachsten geschehen. Weiters können dadurch zB Latenzzeiten bei der Kommunikation überbrückt werden. Wenn es die Server unterstützen, so kann auch über Load-Balancing nachgedacht werden, so dass sich ein Client von mehreren Server-Replikas die Daten parallel besorgt. Auch die lokale Abarbeitung von Daten steigert die Performance, da zB der Netzwerktransfer minimiert werden kann (zB durch Formularkontrolle am Client anstatt am Server).

User Interfaces

  • Model
  • Control
  • View

UIs werden (wie auch Verteilte Systeme) oft schon in einem Schicht-Model realisiert (Vertikale Verteilung). Einzelne Schichten können auf verschiedenen Maschinen laufen (Horizontale Verteilung) (Distributed User Interface). z.B.: kann das Rendering und die Interpretation der Usereingaben komplett am Server erfolgen und der Client dient nur noch als "dumme" Konsole (Remote Application ==> Rechner-Last auf Server). Damit wird die Application unabhängig von der Client-Plattform (Location, Migration, Relocation Transparency).

Arten der Transparenz: Neben Benutzeroberfläche und anderer für die Applikation benötigter Software besteht die Client-Software aus Komponenten, mit denen Verteilungstransparenz erzielt werden soll. Im Idealfall sollte ein Client nicht erkennen, dass er mit einem entfernten Prozess kommuniziert.

Die Zugriffstranzparenz wird häufig realisiert, indem aus der vom Server gebotenen Schnittstellendefinition ein Client-Stub erzeugt wird. Der Stub bietet dieselbe Schnittstelle, die auch auf dem Server zur Verfügung steht, verbirgt jedoch die möglichen Unterschiede in Hinblick auf die Maschinenarchitektur, sowie die eigentliche Kommunikation. Es gibt unterschiedliche Möglichkeiten, Orts-, Migrations- und Relokationstransparenz zu realisieren. Die Verwendung eines praktischen Namenssystem ist wesentlich. In vielen Fällen ist auch die Zusammenarbeit mit Client-seitiger Software wichtig. Ist beispielsweise ein Client bereits zu einem Server gebunden, kann der Client direkt informiert werden wenn sich die Position des Servers ändert. In diesem Fall kann die Middleware des Clients die aktuelle Position des Servers vor dem Benutzer verbergen und die erneute Bindung zu dem Server ggf. transparent vornehmen.

Auf ähnliche Weise implementieren viele Verteilte Systeme die Replikationstransparenz mithilfe Client-seitiger Lösungen.

Die Maskierung von Kommunikationsfehlern mit einem Server erfolgt normalerweise über Client-Middleware. Beispielsweise kann eine Client-Middleware so konfiguriert werden, dass sie wiederholt versucht, eine Verbindung mit einem Server aufzunehmen, oder nach mehreren Versuchen einen anderen Server auszuprobieren (Fehlertransparenz).


Frage 3[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 4[Bearbeiten]

Frage: Was versteht man unter "Message-oriented Middleware MoM"? Erläutern Sie Modell und Architektur solcher "Message-Queueing"-Systeme. Erklären Sie die Primitivoperationen Put, Get, Poll und Notify eines Message-Queuing Systems. Diskutieren Sie Einsatzzwecke sowie Vor- und Nachteile - gehen Sie insbesonders auf den Begriff des Message Brokers und dessen Bedeutung für EAI ein.

{{#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*Message-oriented Middleware\s*/si}}


MoM bieten Unterstützung für persistente asynchrone Kommunikation. Anwendungen kommunizieren, indem sie ihre Nachricht in eine Message Queue einstellen. Jede Anwendung hat ihre eigene Queue von der sie liest.

Ein Sender einer Nachricht erhält nur eine Garantie, dass die Nachricht irgendwann in die Queue eingefügt wird.


Vorteil: Empfänger kann passiv sein während Sender sendet und umgekehrt (loosly-coupling).

Für das loosely-coupling gibt es 4 Kombinationen:

  • Sender running - Receiver running
  • Sender running - Receiver passive
  • Sender passive - Receiver running
  • Sender passive - Receiver passive


Nachteil: Übertragung kann sich im Minutenbereich abspielen.


Architektur:

MOM Architektur.png

  • Get: blockt solange die Queue leer ist; gibt ansonsten die erste Nachricht zurück
  • Put: hängt eine Nachricht an eine Queue an
  • Poll: Queue nach Nachrichten durchsuchen, gibt die erste Nachricht zurück. Blockt niemals.
  • Notify: installiert einen Handler, der aufgerufen wird, wenn eine Nachricht in die Queue gestellt wird.


MoM erlaubt es loosly-coupled Systems zusammenzuarbeiten. Unterschiedliche Systeme kommunizieren möglicherweise über unterschiedliche Nachrichtenformate, die von anderen Systemen nicht verstanden werden.

Message-Broker und Einsatz in EAI: Der Hauptzweck eines Message-Brokers (MB) ist es, eingehende Nachrichten so umzuwandeln, dass sie von der Zielanwendung verstanden werden können. Zusätzlich zu seiner Hauptaufgabe kann ein Message-Broker jedoch noch andere Aufgaben erfüllen - so wird ein Message-Broker etwa für EAI (Enterprise Application Integration) verwendet. Hierbei handelt es sich um ein sogenanntes Publish/Suscribe-Modell. Hierbei senden Anwendungen Veröffentlichungen zum Thema X an den Broker, der diese Veröffentlichungen dann an andere Anwendungen, die Thema X abonniert haben, weiterleitet. (lt. Verteilte Systeme - Principles and Paradigms (Tanenbaum) Seite 175 f.).


Frage 5[Bearbeiten]

iwas mit EAI, Techniken u Legacy Systems


Informatik-Forum: [[1]]