====== MW/CC 2015-04-09 ======
**Fach:** Middleware / Cloud Computing (5 ECTS)

**Prüfer:** Jürgen Kleinöder

**Beisitzer:** Tobias Distler

Wie immer sehr gute Atmosphäre bei der Prüfung. Tobias stellt die Fragen, Jürgen hat nur ein einziges Mal eine Anmerkungen gemacht.

Stift und Papier liegen bereit für Skizzen.

===== Fragen =====
**F:** Wir haben uns mit Cloud Computing beschäftigt, geb doch mal eine Definition

**A:** - Verlagerung von Diensten/Berechnungen/Daten an externe Anbieter

- Verschiedene Ebenen: {Software, Platform, Infrastructure} as a Service + Erklärung

- Skalierbarkeit in beide Richtungen

- Scheinbar unendliche Ressourcen

**F:** Nachteile von Cloud Computing?

**A:** - Rechtliche Probleme (ausländ. Anbieter)

- Probleme bei Ausfall/Pleite des Anbieters (Keine Kontrolle über Daten)

- Keine techn. Standards für versch. Cloud-Anbieter

**F:** Wäre das Problem des Anbieterwechsels mit techn. Standards gelöst?

**A:** - Immerhin müsste man seine Software nicht mehr anpassen

- Daten transferieren ist immer noch zeit- & kostenintensiv

**F:** Wir haben uns Datenspeichersysteme angeschaut, beschreibe doch mal das GFS. Vor allem der Schreibvorgang interessiert mich.

**A:** - Skizze mit Master und drei Chunk-Server

- Typische Eigenschaften von GFS beschrieben (große Dateien, Aufteilung in Chunks, Master- und Chunkserver, ...)

- Angefangen den Schreibvorgang zu erklären

**F:** Welche Kriterien spielen eine Rolle bei der Auswahl der Chunkserver?

**A:** Latenz, Auslastung, Energie

**F:** Eine wichtige fehlt mir noch, was ist denn der Grund mehrere Replikate zu erstellen?

**A:** - Achja, Fehlerdomänen. --> eigene Strom-/Netzwerkanbindung

- Schreibvorgang weiter erklärt

**F:** Warum gehen alle Schreiboperationen über den Primary, könnten das nicht auch die Secondaries machen?

**A:** Gibt Konsistenzprobleme: die Reihenfolge der Datensätze könnte vertauscht sein.

**F:** Gibt es Systeme die das zulassen? 

**A:** Amazon Dynamo

**F:** Wie geht Dynamo mit der schwachen Konsistenz um?

**A:** - Kurz erklärt wie die Architektur von Dynamo funktioniert

- Mehrere versch. Versionen im System möglich

**F:** Und wie erkennt Dynamo jetzt wann er die Version parallel speichern muss oder überschreiben kann

**A:** Vektoruhren

**F:** Wie kann dann die Konsistenz wiederhergestellt werden?

**A:** Das muss der Client übernehmen, indem er eine neue Version erstellt und mit kombinierter Vektoruhr speichert

**F:** Warum macht man das im GFS nicht so?

**A:** Es ist nichttrivial aus mehreren Versionen eine aktuelle zu basteln. Bei einem "normalen" Dateisystem erwarte ich dass die Dateien so gespeichert werden, wie ich sie speichere.

**F:** Ich sehe noch ein anderes Problem

**A:** Bei mehreren Versionen muss ich Chunks mehrfach speichern. Dadurch dass Chunks relativ groß sind, brauche ich viel Speicher dafür.

**F:** Nicht nur speichern, sondern v.a. auch übertragen. Das grad hat sich so angehört als hat das GFS starke Konsistenz?

**A**: - Nein --> kurz den Fehlerfall beschrieben, wie es zu unterschiedl. Inhalten kommen kann

- Kurz auf selbstidentifizierende & -verifizierende Datensätze eingegangen

**F:** Beim GFS wurde auf einen zentralen Master gesetzt, welche Probleme bringt die Entscheidung mit sich?

**A:** - Single Point of Failure

- Flaschenhals bei vielen Anfragen

**F:** Jaja, lösen wir durch Caching und Replikation. Aber für was wurde das GFS in der Praxis genutzt

**A:** zB Gmail --> viele kleine Dateien --> Master hat zuviele Metadaten zu verwalten und Hauptspeicher wird zu klein

**F:** Neben GFS haben wir uns noch AWS angeschaut. Gib mir doch mal einen Überblick.

**A:** Kurz Storage Stamp und Stream Layer beschrieben

**F:** Auch hier hat man in der Stream Layer auf einen zentralen Master gesetzt, ergeben sich die selben Probleme wie beim GFS?

**A:** Das Metadatenproblem ist nicht so schlimm, weil der einzige Client die Partition Layer ist und die nur sehr große Object Tables hat.

**F:** Und damit hat man dann weniger Dateien?

**A:** Ja, nämlich nur 2 pro Object Table: Eine für die Daten und ein Commit-Log. (Ich habe vergessen, dass das natürlich pro Partition gilt. Die Begründung bleibt aber gleich, die Anzahl der Partitionen ist relativ überschaubar).

**F:** Gut, wir haben uns noch mit Virtualisierung beschäftigt.

**A:** Genau wir haben uns zwei Systeme angeschaut: Remus und Spare

**F:** Bleiben wir bei Remus.

**A:** Leicht holprige Erklärung: Passives Backup, hochfrequentes Sichern von veränderten Seiten, Puffern von Netzwerkverkehr, Hochfahren des Backups bei Ausbleiben von Sicherungspunkten

**F:** Warum muss man den ausgehenden Netzwerkverkehr puffern bzw. warum darf man ihn im Fehlerfall nicht rausgeben?

**A:** Naja dann könnte der Client ja Nachrichten doppelt erhalten

**F:** Doppelt ist gar nicht so sehr das Problem. Kann man sich denn sicher sein, dass es derselbe Verkehr ist, der nochmal erzeugt wird?

**A:** Naja die VM könnte auch Zufallszahlen oder so verwenden, also nein.

**F:** Genau man weiß nicht ob die VMs deterministisch sind und darf deswegen auch kein deterministisches Verhalten voraussetzen.


===== Bewertung =====
Die Wartezeit war nur sehr kurz und ich wurde schnell wieder reingebeten, die Note war sehr zufriedenstellend.