Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » MW/CC 2022-02-21

MW/CC 2022-02-21

  • Fach: Middleware / Cloud Computing (5 ECTS)
  • Prüfer: Tobias Distler
  • Beisitzer: Michael Eischer

Angenehme Atmosphäre. Fragen kamen von Tobias, Michael hat nur Ausweiskontrolle und Notizen gemacht. Stift und Papier sollten wegen Corona selber mitgebracht werden. Waren aber nicht notwendig, man sollte selbständig aufmalen, wenn man wollte, wurde aber nicht aufgefordert.

Ich glaube mich an 99% der Fragen zu erinnern, aber keine Gewähr.

Vorbereitung

Während des Semesters immer die Videos angeschaut und dazu/zu den Folien ausführliche Notizen gemacht. Ich war bei nur ca. 50% der Vorlesungen tatsächlich anwesend, aber da ging es sowieso mehr ums Vertiefen des Stoffs.

2 Wochen vor der Prüfung bin ich meine Notizen nochmal durchgegangen, hab diese verdichtet und als Zusammenfassung in wenigen Seiten aufgeschrieben.

1 Woche vor der Prüfung mit Kommilitonen gegenseitig mithilfe der Protokolle und Folien geprüft/herausgefordert. Kann ich sehr empfehlen, da jemand anderem den Stoff zu erklären explizit ist und nicht so implizit wie es sich selbst beim Lernen im Kopf vorzusagen.

Fragen

F: Was ist Cloud Computing und was sind Vor- und Nachteile

A: Verlagerung von Diensten in entfernte Rechenzentren über ein Netz, i.d.R das Internet. Schnell und einfach rauf-/runterskalierbar, Anschein unendlicher Ressourcen für den Kunden.

  • Vorteil: Outsourcing (HW, Strom, Wartung)
  • Nachteil: Datenschutz (Gesundheitsdaten etc.)

F: Nenne 3 Eigenschaften virtualisierter Systeme und erkläre diese.

A:

  • Äquivalenz: gleiche Ergebnisse in VM wie in phys. Rechner
  • Effizienz: So viele Instruktionen wie möglich durch tatsächliche HW ausführen
  • Ressourcenkontrolle: VMM teilt den VMs Ressourcen zu und entzieht sie wieder.

F: Wir hatten uns ja verschiedene Techniken angeschaut. Erkläre den Begriff Binary Translation.

A: Abfangen von Instruktionen aus der VM → Interpreter als Zwischenschicht.

F: Nenne ein Beispiel für eine Instruktion, die abgefangen werden müsste.

A: Systemzeit in VM ändern. Darf eigentliche Systemzeit und andere VMs nicht beeinflussen. Deshalb abfangen und VMM merkt sich Differenz zur eigentlichen Zeit in Cache o.ä.

F: Jetzt klingt es ja so als wäre Binary Translation eigentlich hart ineffizient. Gibt es eine Möglichkeit trotzdem wieder Effizienz rauszuholen?

A: (Hier hing ich ein wenig. Die Antwort war eigentlich so offensichtlich, dass ich nicht draufkam) Es ist nur bei unterschiedlichen Systemen schlimm (z.B. Java als VM, Windows als BS), bei gleichen Systemen (Win als VM, Win als BS) kann der Großteil einfach so ausgeführt werden.

F: Wechseln wir das Thema. Wir haben uns in der Vorlesung verschiedene Cloud Systeme angeschaut. Microsoft Azure Storage behauptet ja stark konsistent zu sein. Wie bewertest du das?

A: Hab gesagt, dass es nicht stark konsistent ist (weiß aber gar nicht, ob das so pauschal stimmt). Mein Punkt war, dass es keine Garantien für die asynchrone Replikation auf den Secondary Stamp gibt. Nach einer Bestätigung des Stamps, ist es möglich den veralteten Zustand vom anderen Stamp zu lesen.

Das hat ihm soweit gepasst, aber einen wichtigen Punkt konnte ich nicht erklären: Man kann sich als Client bei MAS nicht aussuchen mit welchem Stamp man verbunden ist. Um zu dieser Fehlersituation zu kommen muss also der ursprüngliche Stamp abrauchen bzw. nicht erreichbar sein, und der DNS-Server wird dann auf den anderen Stamp switchen.

F: Beschreib doch mal kurz einen Schreibvorgang in MAS.

A: Partition Layer (PL) geht zum Stream Manager (SM) und lässt (falls nötig) einen neuen Extent anlegen. Jetz weiß der PL den Primary Extent-Node (falls nicht, holen) und sendet sein Schreibkommando. Primary schreibt, leitet an Secondaries weiter. Diese schreiben und senden ihre Bestätigung an den Primary. Dieser bestätigt an den PL.

F: Du hast jetzt den Primary hier beim Schreibvorgang hervorgehoben. Warum haben wir im Übungs-HDFS keinen Node mit Primary-Rolle gebraucht?

A: Der Client holt sich die Adressen der DataNodes beim NameNode und sendet selber seine Anfrage an diese. Sequentialiserung durch Leases.

F: Okay, zurück zu MAS. Gehen wir mal davon aus, dass das Schreibkommando den ersten Secondary erreicht, aber nie beim zweiten Secondary ankommt. Was passiert nun?

A: Bestätigung von Secondary bleibt aus, dadurch auch die Bestätigung des Primary an den PL. Nach Timeout ohne Bestätigung wird der PL den Extent vom SM versiegeln lassen. Der SM bestimmt dazu den minimalen gemeinsamen Offset aller Extent-Nodes.

Hier hab ich gemeint, es wird noch vor dem unbestätigten Block versiegelt, das stimmte aber nicht ganz. Wenn der SM nur den Primary und den ersten Secondary erreicht, ist der minimal gemeinsame Offset hinter dem eben geschriebenen aber unbestätigten Block. Dadurch bleibt dieser Block dann tatsächlich lesbar.

F: Und was wenn der Primary ausfällt?

A: Auch Versiegelung des Extents, ein neuer wird angelegt, Primary wird ersetzt. Sein Fokus lag auf dem Node, der den Primary ersetzt, da wusste ich aber nicht so recht was er wollte und hab dann ein wenig was mit GFS vermischt.

Was er wollte: Rolle eines Primarys in MAS wird nur statisch einmal vergeben. Wenn ein Extent-Node der Primary war abraucht, wird er zwar ersetzt, der neue Node ist aber kein Primary. Das geht deshalb, weil vom nun versiegelten Extent nur noch gelesen wird, und keine Schreibkommandos mehr verteilt werden müssen. Bei GFS ist das nicht der Fall, da Chunks immer schreibbar sind.

F: Zum Schluss von MAS wollte er, dass ich von diesen zwei Fehlerfällen auf alle Fehler generalisiere und begründe warum, einmal bestätigte Daten nie verloren gehen werden. Ich hatte keine Ahnung worauf er hinauswollte und weil die Zeit schon so weit war, ist er zum nächsten Thema gewechselt.

F: Wir hatten uns auch Koordinierunsdienste - ZooKeeper und Chubby - angeschaut. ZooKeeper hat schwache Konsistenz, konstruier ein Beispiel wo man das sieht.

A: Replikate A, B, C. B ist Leader, A und C sind Follower. Client 1 schickt Schreibkommando an A, wird verteilt und erhält Bestätigung. Client 2 fragt bei C entsprechende Datei an. Da Zab aber nur garantiert, dass die Mehrheit der Replikate die Transaktion gesehen hat, aber nicht alle, kann C hier einen veralteten Zustand zurückliefern.

F: Und wenn Client 2 seine Anfrage auch an Replikat A stellt?

A: Dann wird immer der aktuelle Zustand geliefert. (gilt immer für das Kontaktreplikat mit der ursprünglichen Schreibanfrage)

F: Und wenn Client 2 seine Anfrage an das Leader-Replikat B sendet?

A: Hier meinte ich leider, der Leader schreibt selber, nachdem er die Transaktion an alle anderen Replikate gesendet hat und würde eine Leseanfrage solange blockieren (zu diesem Zeitpunkt ist aber nur der unbestätigte Zustand gelockt, nicht der bestätigte von dem gelesen wird). Beim Leader kann also tatsächlich auch der veraltete Zustand gelesen werden.

Mein Missverständnis war, dass die Meldung von Zab nur bedeutet, dass die Mehrheit der Replikate die Transaktion gesehen haben, aber nicht, dass sie sie auch geschrieben haben. Deshalb ist es theoretisch möglich, dass nach einer Bestätigung durch das Kontaktreplikat an den Client, kein einziges Replikat (außer dem Kontaktreplikat) den Schreibvorgang tatsächlich umgesetzt hat.

Bewertung

Ich fühlte mich gut vorbereit, aber als ich bei Binary Translation und dann bei Microsoft Azure Schwierigkeiten hatte, dachte das wird mal wieder nicht besser als ne 3,0 (hatte in der Vergangenheit schlechte Erfahrungen mit mündl. Prüfungen). Aber dass wir häufig gemeinsam zu Antworten hingearbeitet haben, war offenbar gar nicht so schlimm.

Sie haben lange diskutiert als ich draußen gewartet hatte, haben sich dann aber aufgrund meiner guten Übungsleistung (habe jede Woche mit Tobias in der Übungssprechstunde gelabert und hab wohl auch guten Code geschrieben) für die bessere Note (1,7) entschieden.