TU Wien:Verteilte Systeme VO (Dustdar)/Pruefung 2015-01-19
Administrative Scalability erklären anhand eines Beispiels[Bearbeiten | Quelltext bearbeiten]
Administrative Scalability beschreibt die Möglichkeit, ein verteiltes System unter einer wachsenden Anzahl von Benutzern verwalten zu können. Ein Beispiel wäre dafür eine Cloud, die Ressourcen on-demand bereitstellt. Hier ist ein gut funktionierendes Abrechnungssystem eine Grundvoraussetzung für den Betreiber, die Cloud vergrößern zu können.
Beschreiben einer Technik um Scalability zu erreichen[Bearbeiten | Quelltext bearbeiten]
Eine der verbreitetsten Techniken ist die Replikation von Entitäten. Beispiel: Durch das Aufstellen zusätzlicher physikalischer Server mit identischen Services, sowie dem Einsatz eines Load Balancers kann die Performance eines Systems/Services erhöht werden, da die Auslastung der einzelnen Server reduziert wird.
Connection-oriented und Connection-less Kommunikation erklären + jeweils ein Beispiel[Bearbeiten | Quelltext bearbeiten]
Connection-Oriented: Baut auf dem Prinzip von Sockets auf und verlangt einen Verbindungsaufbau, allerdings ist die Kommunikation bei bestehendem Kommunikationskanal dann einfacher (früher bei herkömmlicher Telefonie wurde durch den Verbindungsaufbau zusätzlich auch noch die Leitung reserviert). Beispiel: Socket basierter Chat
Connectionless: Spart sich den Aufbau einer Verbindung, jedoch ist die Adressierung der einzelnen Pakete dafür schwieriger. Beispiel: Normaler HTTP Request
Skizzieren eines Send-Vorgangs mit blockierendem Socket bei dem Client nach dem send Weiterarbeiten will (Auslagerung des send()-Befehls in anderen Proess)[Bearbeiten | Quelltext bearbeiten]
Gründe warum in der heutigen Zeit die Verwendung von Webservices immer weiter verbreitet und wichtiger wird (oder so Ähnlich)[Bearbeiten | Quelltext bearbeiten]
Web Services werden immer wichtiger, da sie von überall aus nutzbar sind und wohldefinierte Schnittstellen bieten, welche keine spezifische Implementierung (z.B. immer genau in C++) voraussetzen. Sie können dadurch relativ leicht durch andere Implementierungen ausgetauscht werden, falls das (irgendwann) notwendig werden sollte (z.B. aus Performancegründen bei starkem Wachstum). Ein weiterer Vorteil ist außerdem die starke Wiederverwendbarkeit.
Attribute-Based Naming erklären + ein Beispiel[Bearbeiten | Quelltext bearbeiten]
Beim Attribute-based Naming wird eine Eigenschaft einer Entität durch ein Key-Value-Paar beschrieben. Eine Entität kann in Folge durch ein Set von solchen Attributen beschrieben werden.
Beispiel: Entität AustriaInfo
Attribute | Value |
---|---|
CountryName | Austria |
Language | German |
MemberofEU | Yes |
Capital | Vienna |
Vorteile von rekursiver Namensauflösung[Bearbeiten | Quelltext bearbeiten]
Vorteile rekursiver Namensauflösung:
- Zwischenspeichern der Ergebnisse auf den Namensservern im Vergleich zur iterativen Namensauflösung effektiver
- mögliche Senkung der Kommunikationskosten (zB. wenn Client in Amerika und Server in den Niederlanden)
Siehe Andrew S. Tanenbaum and Maarten van Steen, Distributed Systems – Principles and Paradigms, 2nd Edition, 2007, Prentice-Hall p 207/dt.: S 235
Für was benötigt man Time-Sync? Einen Grund, + Erklärung[Bearbeiten | Quelltext bearbeiten]
Für Konsistenz und die Korrektheit von Prozessen und deren Logs wird Zeitsynchronisation benötigt, wenn mehrere physikalische Maschinen interagieren sollen. Andernfalls könnten Inkonsistenzen auftreten, die zu Softwarefehlern führen oder die Nachvollziehbarkeit (Logs) beeinträchtigen könnten (Beispiel: Maschine A führt Transaktion mit Maschine B durch; A loggt Startzeitpunkt, B den Endzeitpunkt; Uhr von B geht vor und Endzeitpunkt liegt laut Logs schlussendlich vor Startzeitpunkt).
Beschreiben wie das zentralisierte Model für Mutual Exclusion umgesetzt wird[Bearbeiten | Quelltext bearbeiten]
Beim zentralisierten Modell gibt es eine Koordinatoreinheit (zentraler Server/Prozess), welche die Berechtigungen zum Zugriff auf kritische Ressourcen vergibt und wieder einsammelt.
Drei Nicht-funktionale Anforderungen von VS aufzählen und erklären.[Bearbeiten | Quelltext bearbeiten]
- Integrity: Die ungewollte Modifikation von Ressourcen muss verhindert werden.
- Security: Die Sicherheit in und für ein verteiltes System muss gegeben sein; schwerwiegende Konsequenzen bei Fehlern müssen ausgeschlossen sein.
- Availability: Das System muss die bestmögliche Verfügbarkeit aufweisen.
Nennen und erklären eine Methode zur Failure-Detection in Verteilten Systemem.[Bearbeiten | Quelltext bearbeiten]
Bin mir nicht sicher, ob die Frage so Sinn ergibt (stammt nicht von mir), daher leicht abgeänderte Antwort.
Fehler sind unvermeidbar, deshalb sollte man einen Weg finden, damit umzugehen, ohne dass das komplette System (bzw. der Service) fehlerhaft wird. Ein gängiger Weg ist das verschleiern eines Fehlers bei der Antwort an den aufrufenden Prozess (Exception abfangen und etwas "Normales" zurück geben, aber keinen Stacktrace o.Ä.).
Aufzählen und erklären der drei Konsistenzarten[Bearbeiten | Quelltext bearbeiten]
- Continous Consistency: Es geht um einen Grad von Konsistenz, welcher auf Unterschiede in den Replika zurückzuführen ist. Definiert wird "akzeptables" Verhalten bei bestimmten Operationen, da eine perfekte Konsistenz nicht möglich ist.
- Sequential Consistency: Die Operationen von nebenläufigen Prozessen werden, auch wenn sie eigentlich simultan geschehen, in einer zeitlich geordneten Reihenfolge abgearbeitet - sowohl global gesehen, als auch für jeden Prozess selbst betrachtet. Das bedeutet, jeder Prozess bekommt die gleichen Updates in der gleichen Reihenfolge mitgeteilt.
- Causal Consistency: Änderungen, die kausal zusammenhängend sind, müssen von allen Prozessen in derselben Reihenfolge gesehen werden. Andere Änderungen können auch simultan bearbeitet und nicht in der gleichen Reihenfolge gesehen werden.
- FIFO Consistency: Die Änderungen eines Prozesses sind bei allen anderen Prozessen in derselben Reihenfolge sichtbar; bei mehreren Prozessen und simultanen Änderungen kann dies allerdings nicht mehr garantiert werden. Klassisches First In - First Out Prinzip.
Ein Beispiel zu Continous Integration war skizziert und man musste den Numerical Error angeben[Bearbeiten | Quelltext bearbeiten]
MC-Frage zu wann Push einem Pull-based Protokoll vorzuziehen ist[Bearbeiten | Quelltext bearbeiten]
Bei permanenten bzw. serverseitig initiierten Replikas ist die Push-Variante zu bevorzugen. Pull wird hingegen gerne von Clients mit Cache verwendet.
Beschreiben der zwei Modelle, um ein File System transparent für Remote-Clients verfügbar zu machen + mit welchem lässt sich cientseitiges Cachen gut umsetzen.[Bearbeiten | Quelltext bearbeiten]
- Download/Upload Modell: Die angeforderte Datei wird heruntergeladen (=kopiert), kann dort modifiziert und anschließend wieder hochgeladen werden. Sie wird dann auf dem Server einfach ersetzt. (Beispiel: FTP)
- Remote Access Modell: Die angeforderte Datei wird nicht als solche kopiert, es kann jedoch auf ihr operiert werden, als wäre sie eine normale Datei auf dem lokalen Rechner (open, close, read, write, ...). (Beispiel: NFS)
Zum Cachen ist das Download/Upload Modell besser geeignet, da dort relativ leicht mit Versionierung/Bearbeitungsdatum der Zustand geprüft werden kann.
[Bearbeiten | Quelltext bearbeiten]
Kapitel Security, Folie 16
DDoS Attacke erklären und ein Beispiel angeben.[Bearbeiten | Quelltext bearbeiten]
Ein Angreifer ermächtigt sich der Rechenleistung gekaperter (=gehackter) Geräte eines Netzwerks (muss kein lokales Netzwerk, sondern kann auch das Global Area Network sein), um die Ressourcen eines Ziels zu überladen (durch Senden vieler Anfragen). Ein Beispiel wäre der Angriff auf Spamhaus.
Drei wesentliche Eigenschaften von Peer2Peer Systemen.[Bearbeiten | Quelltext bearbeiten]
- Die Entitäten eines P2P-Systems kommunizieren untereinander durch direkte Verbindungen, nicht über eine zentrale Steuereinheit.
- Alle Entitäten eines P2P-Systems sind gleichgestellt, es gibt keine höherwertigeren Entitäten.
- Jede Entität konsumiert und stellt die gleichen Services bereit (Beispiel: Torrent).
Was bedeutet der Begriff „Rapid elasticity“ im Kontext von Cloud Computing.[Bearbeiten | Quelltext bearbeiten]
Rapid elasticity beschreibt die mehr oder weniger unbeschränkte Kapazität von Ressourcen, also das Abrufen zusätzlicher Ressourcen "on demand". Wird mehr Leistung benötigt, wird einfach mehr Leistung angefordert. Und das Ganze selbstregulierend und ohne Unterbrechungen. In Folge können natürlich auch wieder Ressourcen freigegeben werden, wenn kein Bedarf mehr besteht.