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.

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.

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