Sie befinden sich hier: Termine » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » mwcc-2019-03-18   (Übersicht)

Prüfer: Dr. Tobias Distler Beisitzer: Michael Eischer

Besonderheiten: Überraschend viele Transferfragen, bei denen man um die Ecke denken muss. Präzise Antworten sind gerne gesehen. Einfach loslabern wird zwar nicht negativ angerechnet, führt aber dazu, dass man weniger schafft und das kann sich u.U. negativ auswirken.

Stimmung: Fordernd, Herr Dr. Distler hat wenig Lust auf Repro, er erfreut sich vielmehr an Transferfragen, das merkt man auch.

Vorbereitung: 2 Wochen intensive Vorbereitung, Folien zusammengefasst, teilweise Paper für Vorbereitung gelesen, mit Lernpartner über Stoff diskutiert; Dieser Vorbereitungsstil ist zu empfehlen.

Ergebnis: Beim Verlassen des Raumes ein doch eher mulmiges Gefühl; Dann aber doch ein sehr erfreuliches Ergebnis ;) Gute Abgaben in den Übungen lohnen sich, da diese bei der Bewertung herangezogen werden.

Prüfungsfragen:

Einstieg

  • Definiere Cloud Computing / Überblick, Vor- / Nachteile: siehe Vorlesungsfolien
  • Basistechnologien von Cloud Computing? Web Services und Virtualisierung
  • Anforderung an virtualisierte Systeme? Äquivalenz, Effizienz, Ressourcenkontrolle
  • Gibt es ein perfekt äquivalentes System? Nein, Zeitverhalten
  • Ekläre Binary Translation: Interpreter für Basic Blocks, 1 zu 1 Abbildung falls Quell- und Zielarchitektur gleich, streng genommen keine Effizienz nach Popek
  • Instruktion / Beispiel angeben für Instruktion, die geändert werden müsste: Uhrzeit in VM und auf dem Hypervisor; Datumsänderungen in der VM sollten sich nicht auf Hypervisor oder andere VMs auswirken

MAS

  • Wenn ich ein Datum hochgeladen habe, kann ich dann mein Datum lokal löschen. Nein, nicht stark Konsistent
  • Wie lange muss man warten, bis Datum sicher auf Backup-Storage-Stamp? Kann man nicht sagen.
  • Stream-Layer: Aufbau des Systems beschreiben, siehe Vorlesungsfolien
  • Wie funktioniert ein Schreibvorgang im SL? siehe Vorlesungsfolien
  • Fehlerfall: Netzwerkpartitionierung nur zwischen zwei Secondaries, Client bekommt Fehler, Client beschwert sich beim SM, dass es nicht funktioniert hat, SM versiegelt den Extent, Client wiederholt Schreiboperation auf neuem Extent
  • Wie kann es sein, dass Daten doppelt geschrieben werden? Netzwerkpartitionierung zwischen zweiten und letztem Extent, außerdem Netzwerkpartitionierung zwischen SM und diesem letzten Extent
  • Wie wird der Primary bestimmt? Einmal initial pro Extent
  • Was ist denn, wenn der Primary abraucht. Dann raucht die Primary-Rolle mit diesem ab
  • Wie wird der Primary im GFS bestimmt? Per Lease
  • Was ist denn das Problem mit einem zentralen Master? Starke Belastung des Masters, single-point-of-failure
  • Jetzt ist das MAS ja nach dem GFS gekommen? Beratungsresistent? Vorteil: Nur ein Client (nämlich PM), außerdem hat man die Größe eines Storage Stamps ja in der Hand

GFS

  • Warum muss ich denn den Primary überhaupt wählen, wenn er abgeraucht wurde? Naja, man will ja wahlfreies Schreiben ermöglichen, das ist beim MAS ja nicht so, da da wahlfreies Schreiben nicht unterstützt wird.

Amazon Dynamo

  • Warum kann man beim Lesen eine Liste von Datenobjekten zurückerhalten? Konflikte können auftreten, Nutzer muss im Rahmen der semantic reconciliation mit richtiger Version weiterarbeiten
  • Wie erkennt man Konflikte? Vektoruhren
  • Erkläre doch Vektoruhren genauer? Siehe Vorlesungsfolien
  • Wie muss N, R, W gewählt werden, dass man einen veraltet Zustand lesen kann? In einem System mit drei Knoten, z.B. N = 3, W = 2, R = 1
  • Nehme an: N = 3, R, W = 2: Bei so gut wie jedem System kann man dann keinenveralteten Zustand lesen, bei Dynamo schon. Warum denn? Hinted Handoff; Wenn ein Knoten ausfällt kann es sein, dass dann das Ersatzreplikat und der Knoten an demman liest ausreichen für R, dann liest man trotzdem veraltete Daten

Koordinierungsdienste

  • ZooKeeper: Warum muss man zwei Zustände verwalten? Siehe Übungsfolien, Schreibanfragen müssen serialisiert werden und jeweils aufeinander aufbauen, da sie sonst invalide Ergebnisse liefern könnten, Leseanfragen sollen nur den bestätigten Zustand zurückgeben
  • Chubby: Netzwerkpartitionierung tritt auf, Master in Minderheit, was passiert?
  • Was passiert in diesem Fall bei ZooKeeper, wie unterscheidet sich das Verhalten von Chubby? Master dankt ab, neuer Master wird gewählt; Bei Chubby kann dann weder Lese- noch Schreibanfrage benatwortet werden, bei ZooKepper können immerhin noch Leseanfragen beantwortet werden.