Middleware Cloud Computing 7.5 ECTS Prüfung 2025-04-16

• Prüfungsform: mündlich
• Prüfer: Tobias Distler
• Beisitzer: Laura
• Note: Sehr gut
• Vorbereitung:
  • Einmal alle Vorlesungen zusammengefasst, Slides sind ja zum Glück nicht so lang.
  • Danach die Themen Google File System (GFS), Microsoft Azure Storage (MAS), Chubby, Zookeeper und das Übungs-HDFS und Amazon Dynamo vertieft. Hier lohnt es sich ggf. auch mal in die Papers reinzulesen, die Folien sind da manchmal etwas dünn.
  • Anschließend Altklausurprotokolle gemacht und versucht die ganzen Beispiele anhand eigener Zeichnungen einmal durchzuexerzieren. Gerade der Punkt ist sehr wichtig, da in der Prüfung viel Wert auf Transfer zwischen GFS ↔ MAS ↔ HDFS sowie Chubby ↔ Zookeeper gelegt wird.
• Evaluation
  • Atmosphäre ist fordernd. Tobias unterbricht einen wenn man seiner Meinung nach alles wichtige gesagt hat. Er hat sich Fragen notiert, die man bestenfalls alle innerhalb der 30 Minuten beantworten können sollte.
  • Man soll selbst Stift und Papier mitbringen um während der Prüfung unaufgefordert Sachen hinzumalen. Lohnt sich insbesondere bei vielen Beispielen von MAS, GFS, usw. Am besten überlegt man sich vorher schonmal wie man das schnell und einfach hinzeichnen kann.
  • Bewertung fand ich alles in allem fair. Im Nachhinein gab es noch ein (sehr angenehmes) Gespräch, bei dem eventuelle Unklarheiten geklärt werden können.

Antworten sind hier teilweise etwas kürzer als in der tatsächlichen Prüfung.

F: Was ist Cloud Computing? Nenne mir außerdem 3 Vor- und Nachteile.

A: Siehe Folien

F: Kommen wir nun zu den Basistechnologien. In der Vorlesung haben wir uns Virtualisierung angeschaut. Was sind denn da die Eigenschaften die man haben will?

A: Äquivalenz, Ressourcenkontrolle, Effizienz. Jeweils noch erklärt.

F: Kann man deiner Meinung nach vollständige Äquivalenz erreichen?

A: Nein, wenn ich jetzt z.B. 10 VMs auf einem Prozessor laufen lasse.

F: Angenommen ich habe nur eine VM, geht das dann?

A: Auch nein, VMM braucht ja noch Rechenzeit.

F: Jetzt hast du die Zeit als nichtfunktionale Eigenschaft genannt. Gibt's da noch andere Aspekte bei denen ich keine Äquivalenz erreichen kann?

A: Ja, Speicherplatz, sowohl RAM als auch auf Platte.

F: Wir haben uns auch mehrere Techniken angeschaut wie man Virtualisierung umsetzen kann. Erkläre doch mal Binary Translation.

A: Siehe Folien

F: Das klingt jetzt so als würde das brutalst gegen das Effizienzkriterium verstoßen. Wann genau ist das denn kein Problem?

A: Wenn man auf die selbe ISA emuliert, muss man nur die sensitiven Instruktionen abfangen.

F: Nenne mir doch mal eine Instruktion, die man emulieren müsste, und wie genau das emuliert werden würde.

A: push cs, damit kann man das Prozessorstatuswort auf den Stack pushen und sieht so dass man sich in Ring 1 befindet.

F: Kommen wir nun zu Datenspeichermodellen. Erkläre doch mal das CAP-Theorem.

A: Siehe Folien

F: In der Vorlesung haben wir uns Microsoft Azure Storage angeschaut. Von welcher Eigenschaft hat man hier Abstriche getätigt?

A: Konsistenz, da man Daten asynchron auf andere Stamps repliziert.

F: Zeige mir anhand eines konkreten Beispiels, wann ich als Nutzer Inkonsistenzen zu spüren bekomme.

A: Zwei Storage Stamps hingemalt und Schritt für Schritt Anfrage durchgegangen. Während Stamp 1 die asynchrone Replikation startet wird schon Erfolgsmeldung an Client gegeben - währenddessen brennt das Rechenzentrum ab und der DNS Eintrag wird geändert, wodurch die Daten verloren gehen.

F. Also ist MAS „AP“, d.h. Available und Partitionstolerant. Wie kann ich erreichen, dass MAS „CP“ wird?

A: Man darf beim Notfall-Failover nicht einfach den DNS Eintrag ändern.

F: Schauen wir uns nun den Stream-Layer etwas genauer an. Angenommen ich habe als Partition-Layer Daten die ich in einen Stream schreiben will, weiß aber weder wohin genau und an welchen Server ich mich wenden muss. Wie funktioniert der Schreibzugriff?

A: Stream Layer hingemalt, Schreibzugriff erklärt

F: Jetzt haben wir also den Fall, bei dem alles gut gegangen ist. In welchen Fällen kann es dazu kommen, dass Daten doppelt geschrieben werden?

A: Wenn der „letzte“ EN nicht mehr erreichbar ist, weder durch SM noch durch andere ENs.

F: Was passiert in MAS, wenn jetzt mein Primary ausfällt?

A: Wird nicht neu vergeben, da ja Extent versiegelt wird.

F: In der Übung haben wir HDFS verwendet. Da gab's gar keinen Primary. Wie haben wir das da gelöst?

A: Leases auf Files, DataNodes bauen unter sich Datenpipeline auf.

F: Was ist an dieser Art das so zu machen der Nachteil?

A: Deutlich eingeschränkte Verfügbarkeit, da keine parallelen Schreibzugriffe möglich.

F: Dann gibt es auch das Google File System. Wie funktioniert hier das mit den primaries?

A: Primary sequenzialisiert Schreibzugriffe.

F: Wann genau muss der primary neu vergeben werden? Nenne zwei Gründe.

A: Zum Einen weil man wahlfreies Schreiben ermöglichen will, zum anderen weil man Chunks/Blöcke nicht einfach versiegeln kann.

F. Warum dürfen im GFS anfragen abgelehnt werden?

A: Wenn man bei einem Append über eine Blockgrenze hinausschreiben würde.

F: Was ist die Anforderung an Appends?

A: Müssen atomar sein. Primary befüllt hierbei den Rest des Chunks mit Padding, wodurch Daten im Chunk stehen, die niemals ein Nutzer hineingeschrieben hat.

F: Warum darf der primary nicht trotzdem die Anfrage übernehmen?

A: Weil Chunkserver kein Wissen über Files haben, d.h. der primary wüsste nicht wo der nächste Block liegen würde.

F: Zeige mir doch mal ein beispiel, wo es bei appends kaputt gehen kann, wenn der primary das doch machen dürfte.

A: Zwei zeitgleiche Appends, wobei der erste durch die Blockgrenze in zwei Teile aufgeteilt wird. Dadurch ist der erste Append nicht mehr atomar, und der zweite Append kann dann dazwischen liegen.

F: Genau, und somit haben wir einen inkonsistenten Zustand. In Amazon MemoryDB (Papier der diesjährigen Papieranalyse), wie wird es dort geregelt, dass nebenläufige Zugriffe konsistent bleiben?

A: Hier gibt es eine Komponente, die dafür sorgt dass Lesezugriffe zurückgehalten werden, wenn sich im globalen total geordneten Commit-Log-Stream noch schreibzugriffe davor befinden. Hier war es wichtig, dass die Granularität auf einzelnen Objekten, nicht auf dem gesamten System liegt. Es folgten auch ein paar Zwischenfragen sowie Vergleiche mit Chubby.

F: Kommen wir also zu Koordinationsdiensten. WIr haben uns ZooKeeper angeschaut: *er malt folgendes hin*: [F] [L] [F], unter das erste F ein C was mit einem Pfeil (auf das F) verbunden ist. Wie genau kann es hier vorkommen, dass ein veralteter Zustand gelesen wird?

A: Szenario hingemalt, bei dem eine Netzwerkpartition auftritt und ein Client nie von der Transaktion erfährt. Dabei erklärt, wie ZAB funktioniert.

F: Angenommen der zweite Client tätigt nun seine Anfrage auch an den linkesten Follower, und zwar nachdem Client 1 seine Anfrage bestätigt bekommen hat. Wäre hier der Zustand veraltet?

A: Nein, da der Follower bereits Z_b aktualisiert hat, bevor er Client 1 die Bestätigung schickt.

F: Und was wenn er die Anfrage an den Leader schickt?

A: Hier kann wieder ein veralteter Zustand gelesen werden, falls der Leader die Commit-Nachricht nie erhält. (Info: Man kann in ZooKeeper auf allen Replikas außer dem Kontaktreplika veraltete Zustände lesen.)

F: Was passiert in dem Fall, wenn der Leader seine Mehrheit während der Schreibanfrage verliert?

A: Leader-Election findet statt - wenn das vor dem Commit passiert ist die Schreibanfrage weg.

F: Der Leader verwaltet zwei Zustände, Z_a und Z_b. Was passiert wenn ich eine Leseanfrage mit Z_a beantworten würde?

A: Zu neue Zustände (also auch welche, die nie bestätigt werden) können gelesen werden.

Die Frage war eng mit der vorherigen verknüpft.

F: Was kann passieren, wenn ich Z_a nicht hätte?

A: Es kann sein, dass ein anderer Client eine Schreibanfrage überschreibt (siehe Übungsvideo).

F: Wir haben uns auch Chubby angeschaut, was durch eine totale Ordnung stark konsistent ist. Wie erlaubt Chubby Caching?

A: Client bekommt Cache als Lease, welches er erneuern muss - Invalidierungsnachricht bei modifizierenden Anfragen auf die entsprechenden Daten.

F: Was muss der Server vorhalten, damit Caching funktioniert?

A: Die Info was jeder Client sich aktuell cached.

F: Was passiert wenn ein Client auf eine solche request nicht antwortet?

A: Der Leader wartet bis das Lease abgelaufen ist. Blockiert somit zwar alle anderen Anfragen aber availability ist uns wurscht.

F: Wenn jetzt ein neuer Master gewählt wird. Was passiert dann?

A: Dann brauchen alle Clients eine Invalidierungsnachricht. Neuer Master muss jetzt alle Strukturen wiederherstellen etc. (siehe Vorlesungsfolie)

F: Angenommen ich würde bei der Cache-Invalidierungsnachricht auch das neue Datum mitschicken. Dann wäre das doch alles viel schneller.

A: Ja, aber macht Konsistenz kaputt, weil ja noch nicht sicher ist, ob die neuen Daten überhaupt bestätigt werden.

Damit waren wir mit allen Fragen durch.