MW/CC 2018-02-22

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

Sehr gute Atmosphäre. Fragen kamen von Tobias, Michael hat nur Ausweiskontrolle gemacht und sonst nichts gesagt. Stift und Papier liegen bereit. Zur Auflockerung wurde sich über sich über ihren kaputten Wecker belustigt.

Ich hab jetzt nicht mehr alle Fragen zusammen bekommen, aber das waren so die Wichtigsten:

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

A: Verlagerung von Diensten, wie Datenspeicher, Rechenkapazität in die „Cloud“, d.h. in große Rechenzentren einer Firma, die das dann für viele Kunden im großen Stil anbietet.

- Vorteile: Skalierbarer, Effizienter, Know How / Aufwand / Risiken Outsourcen - Nachteile: Rechtliches (Datenschutz bei ausländischen Anbietern) und Vendor Lock-In (Nutzen spezieller Dienste, fehlende Standards)

F: (zum Datenschutz) Kann man sich wirklich nicht sicher sein, dass die Daten ein einem Bestimmten Land liegen?

A: Naja meistens kann man die Region angeben, wo die Daten landen sollen (zumindest bei Amazon).

F: Ja. Aber auf dem Weg können sie ja z.B. erst über die ganze Welt gehen.

F: Wir haben uns 2 Datenspeicherlösungen angeschaut. Windows Azure Storage verwendet ja ein Frontend Layer, ein Stream Layer (SL) und Partition Layer (PL). Erkläre, wie ein Schreibzugriff vom PL auf das SL ausschaut.

A: Bild mit PL, Stream Manager (SM), einem Primary und 2 Secondaries hin gemalt und Pfeile (Datenfluss und ACKs) dazu.

F: Wenn ich Daten gespeichert hab und ein OK bekommen hab, sind die Daten dann sicher?

A: Sie sind dann bereits auf 3 Fehlerdomänen verteilt (gegen einzelne Hardware- (/Festplatten-) ausfälle etc. geschützt). Allerdings erfolgt die Replikation auf anderes Stamp erst asynchron zum Schreibvorgang und ACK kommt schon vorher. D.h. nicht gegen Feuer- / Tornado (ganze Rechenzentrumsausfälle) geschützt.

Ich war mir hier mit der Defnition „Fehlerdomäne“ nicht ganz sicher und deswegen ging es hier ein wenig durcheinander und Tobias war verwirrt, was ich meine: Fehlerdomäne bedeutet hier ein Rack mit eigener Rackstromanbindung und Racknetzwerkanbindung. Deshalb kann man sagen, dass nach einem Schreibzugang und ohne Stampreplikation die Daten trotzdem schon auf 3 Fehlerdomänen verteilt sind. Ich dachte, dass ein Stamp (=Teil eines Rechenzentrums) eine komplett eigene Strom- und Netzanbindung von außen bekommt und das eine Fehlerdomäne ist.

F: Was passiert jetzt, wenn ein Fehler beim Schreiben passiert, also z.B. ein Netzsplit und der 2. Secondary kann nicht erreicht werden? (Annahme Stream Manager kann aber noch mit dem reden)

A: Kein ACK an PL, PL meldet Vorfall an SM, SM fragt Replikate nach Ende des Extents, Wegwerfen des gerade geschriebenen Blocks, Versiegeln des Extents.

F: Jetzt haben wir Daten weg geschmissen. Ist das ein Problem?

A: Nein, denn die sind noch nichts ans PL als geschrieben bestätigt worden. PL muss/kann Anfrage wiederholen und in ein neues Extent die Daten schreiben.

F: Es kann vorkommen, dass gleiche Blöcke in einem Stream öfters vorkommen. Wie?

A: Wenn Rückantwort (ACK) eines Replikats beim Schreiben verloren geht, muss PL wegen fehlendem ACK davon ausgehen, dass das nicht funktioniert hat und muss selben Block nochmal schreiben.

Da bin ich nicht gleich drauf gekommen. Bei GFS hätte ich es erklären können, aber Tobias hat mir geholfen in dem er den Tipp gegeben hat: „Überlege mal, welche Nachricht verloren gehen müsste.“ Außerdem hat er danach ergänzt, dass es auch passieren kann, wenn die Aufforderung des SM verloren geht, die Extents zu versiegeln.

F: Bei GFS was so eine zentrale Instanz, wie der SM ein Problem. Warum?

A: GFS wurde für Gmail missbraucht. Die wollten viele kleine E-Mails speicher. GFS ist dafür nicht ausgelegt. Es muss 1. oft beim Master nach neuen Blöcken gefragt werden und 2. muss der Master viele Metadaten speichern.

F: Ist das beim SM im SL im Azure Storage auch so?

A: Nein, denn SM wird vom PL bedient. Dieses fasst kleine Daten zu größeren Blöcken zusammen und macht nur append.

Da hat's ein bisschen geholpert. Ich dachte außerdem noch, dass man den SM nur für neue Extents befragen muss, aber wenn man Blöcke schreibt, ist das ja unabhängig. Aber das ist nicht relevant, da die Blöcke echt klein sind und Extents eher dem entsprechen, was Blöcke im GFS sind.

F: Wir haben uns außerdem Koordinierungsdienste (Chubby, ZooKeeper) angeschaut. Warum braucht man denn da 2f+1 Replikate zum Tolerieren von f Fehlern, während man bei GFS und Azure nur f+1 braucht?

A: Bild mit 5 Replikaten und Netzwerksplit hin gemalt. Bei z.B. ZooKeeper braucht man für Schreibanfragen immer die Gewissheit, dass die Mehrheit der Replikate folgt und die Transaktion auch anwenden werden.

F: Und bei Chubby?

A: Da laufen alle Schreibanfragen über den Master und der braucht die Mehrheit bei der Anführerwahl.

F: Und warum die Mehrheit?

A: Damit bei einem Netzwerksplit die Mehrheit weiß, dass sie weiter machen kann und die Minderheit weiß, dass sie nichts mehr tun darf (bei ZooKeeper zumindest keine Schreibanfragen).

F: Genau. Um Split Brain zu vermeiden. Warum kann ZooKeeper nur schwache Konsistenz bieten?

A: Bild mit 2 Clients an 2 unterschiedlichen Replikaten hin gemalt und Beispiel erklärt, dass, obwohl die Mehrheit der Replikate die Transaktion bestätigt haben, sich die Nachricht zu dem Replikat, an dem Client 2 hängt verzögern könnte. Client 1 bekommt ACK und benachrichtigt Client 2. Der liest und bekommt alte Daten.

F: Wie lange muss ich warten, bis ich mir sicher sein kann, dass Daten, die ich lese aktuell sind?

A: Keine Garantie.

F: Genau. Genauso wie es bei Azure keine Angabe gibt, bis Daten auf 2. Stamp repliziert sind. Warum kann das bei Chubby nicht passieren?

A: Da antwortet nur der Master auf Lese- und Schreibanfragen. Nur wenn der Ausfällt, springt einer der Replikate ein.

F: Tobias markiert einen meiner ZooKeeper Replikate als Leader und trennt ihn vom Rest. Was darf/muss dieser Leader tun?

A: Schreibanfragen mit Fehlermeldung quittieren. Leseanfragen dürfen aber weiterhin beantwortet werden, denn es gibt keine Garantie, dass Daten aktuell sind.

F: Gut. Zeit ist um.

Echt gute Prüfungsbedingungen. Faire Fragen. Sehr gute Folien (auf das Wesentliche zusammengefasst, ohne dass was Wichtiges weggelassen wurde). Man konnte sich gut auf die Prüfung vorbereiten (ok ich hatte auch fast eine ganze Woche dafür Zeit).

Note war super. Eigentlich dachte ich, dass ich manchmal zu unsicher war und zu oft Hilfe gebraucht habe, aber Tobias fand es gut, dass die allermeisten Fragen sehr zielstrebig und korrekt beantwortet wurden.