MW/CC 2015-02-25

Fach: Middleware / Cloud Computing (5 ECTS)

Prüfer: Jürgen Kleinöder

Beisitzer: Tobias Distler

Angenehme Atmosphäre, man kennt sich. Nach einer Runde Smalltalk mangels Beisitzer konnte es auch losgehen. Fragen kamen ausschließlich von Tobi. Papier und Stift liegen bereit; an ein paar Stellen wird man aufgefordert, etwas zu skizzieren.

F: Wir haben uns in der Vorlesung mit Cloud Computing beschäftigt. Kannst du mal eine Definition davon geben?

A: Nutzung von Dienstleistungen statt Anschaffung eigener Soft- oder Hardware. Aus Kundensicht scheinbar unbegrenzte Ressourcen, dadurch einfache Skalierung in beide Richtungen möglich. Auf unterschiedlichen Ebenen möglich: Infrastructure as a Service (virtuelle Festplatten oder VMs), Platform as a Service (Umgebung/Framework für eigenen Applikationen) oder Software as a Service (Webapplikationen).

F: Gibt es auch Nachteile?

A: Abrechnung auf Zeitbasis, dadurch dauerhafter Betrieb relativ teuer. Privatsphäre und Datenschutz sind problematisch, man gibt seine (Kunden-) Daten in die Hände externer (ausländischer) Unternehmen.

F: Was ist mit Wechseln des Anbieters?

A: Starker Vendor Lock-in: Anpassung der Applikation an bestimmten Anbieter, keine standardisierten Schnittstellen. Migration von Daten aufwändig und teuer.

F: Jetzt hast du gesagt, eine möglicher Cloud-Dienst ist die Speicherung von Daten. Dazu haben wir uns in der Vorlesung Windows Azure Storage angeschaut. Wie ist der grundsätzliche Aufbau im Hinblick auf Redundanz?

A: Storage Stamp, eine Reihe von Racks mit 30 Petabyte Kapazität, als zentrales Element. Innerhalb davon dreifach redundante synchrone Speicherung auf unterschiedlichen Racks mit eigener Netzwerk- und Stromanbindung. Asynchrone Replikation auf anderes Rechenzentrum alle 30 Sekunden.

F: Skizzier mal die Speicherung von Daten im Stream Layer.

A: [Beginn einer Zeichnung von Stream Manager, Stream, Extents, Blöcken etc.]

F: Das interessiert mich gar nicht so sehr. Nehmen wir mal an, der Stream Manager hat die richtigen Extents ausgewählt; wie sieht jetzt der Datenfluss aus?

A: [Drei Replikate gezeichnet.] Der Partition Layer schickt die Daten zum jeweiligen Primary. Dieser leitet weiter an beide Secondaries und wartet deren Bestätigungen ab. [Durch Pfeile skizziert.] Erst dann Bestätigung an den Partition Layer.

F: Wer bestimmt den Offset?

A: Der Primary. Da immer auf allen Replikaten geschrieben wird, kann es nicht zu Inkonsistenzen kommen.

F: Was passiert, wenn ein Replikat wegfällt? [In der Skizze durchgestrichen.]

A: Stream Manager muss ein weiteres Replikat erzeugen lassen.

F: Ja, und während des Schreibens, wenn noch nicht alle Replikate bestätigt haben?

A: Schreiben schlägt fehl.

F: Was muss man tun, wenn man dann ein weiteres Replikat erzeugen will?

A: Extent versiegeln. Extents können versiegelt und unversiegelt sein, pro Stream immer nur einer nicht versiegelt.

F: Wo versiegelt man, an welchem Offset?

A: Am kleinsten.

F: Das heißt, am fragt alle Replikate?

A: Das defekte kann man nicht mehr fragen. Ansonsten ja und dann daraus eben den kleinsten Offset nehmen.

F: Gehen dabei keine Daten verloren?

A: Nein, denn Anhängen ist die einzige Schreiboperation. Bei unterschiedlichen Offsets hat ein Teil der Replikate noch keine Bestätigung an den Master geschickt.

F: Was sind diese zusätzlichen Daten also?

A: Unbestätigt.

F: Genau. Wenn ich meine Daten jetzt auf Windows Azure Storage hochgeladen habe, wie sicher sind sie dort?

A: Kommt darauf an, wie sehr ich dem Cloud-System vertraue.

F: Sollte ich sie lokal gleich wegschmeißen?

A: Hängt davon ab, wie paranoid ich bin und ob ich später vielleicht migrieren möchte. Nach bestätigtem Schreiben sind die Daten jedenfalls redundant innerhalb eines Storage Stamp gespeichert. Cloud-System selbst kann natürlich Fehler haben.

F: Und was ist, wenn der Storage Stamp ausfällt?

A: Ja, Replikation zwischen Rechenzentren kann wie gesagt natürlich bis zu 30 Sekunden dauern.

F: Und die 30 Sekunden sind ja auch nur ein Durchschnittswert. Also besser ein bisschen warten mit dem lokalen Löschen. Wir haben auf dem Stream Layer also einen zentralen Master, ähnlich wie beim Google File System, obwohl es dort ja einige Probleme damit gibt. Welche sind das?

A: Master ist Flaschenhals und Single Point of Failure.

F: Konzentrieren wir uns auf den Flaschenhals-Aspekt. Warum ist das so?

A: Jede Operation muss zuerst den Master fragen, welcher Storage Server zuständig ist. Dadurch viele Anfragen am Master.

F: Wirklich? Werden keine Techniken verwendet, um das zu reduzieren?

A: Ich glaub, es gibt Caching.

F: Genau, das Problem ist ein anderes.

A: Trotzdem nehmen die Anfragen am Master zu, wenn eine Google File System-Instanz wächst gibt es weiterhin nur einen Master.

F: Ja, aber denk mal eher an die Verwendung. Wofür wurde das Google File System gebaut, wofür wird es praktisch benutzt?

A: Gebaut für große Daten, Blockgröße ist 64 MB. Verwendet wird es aber unpassenderweise auch für kleinere Daten.

F: Was passiert dann?

A: Starke interne Fragmentierung.

F: Gut, aber im Bezug auf den Master?

A: Anlegen eines neuen Chunks generiert jedes Mal einen Request am Master, dadurch hohe Last.

F: Vor allem wachsen die Metadaten stark an. Trotzdem hat man sich bei Windows Azure Storage auch für einen zentralen Master entschieden. Warum tritt das Problem dort nicht so stark auf?

A: Andere Art der Daten: Blobs, Tabellen und Warteschlangen. Der Partition Layer bildet sie zur eigentlichen Speicherung auf den Stream Layer ab.

F: Wie tut er das, was wird auf dem Stream Layer gespeichert?

A: Persistentes Commit Log und Checkpoints in regelmäßigen Zeitabständen, bei zu großem Commit Log o.ä.

F: Und dadurch hat man keine kleinen Dateien?

A: Als Checkpoints auf jeden Fall nicht; beim Commit Log vielleicht, aber das wird ja regelmäßig neu angelegt.

F: Nein, das ist ja auch nur eine große Datei, an die man anhängt. Was könnte man denn tun, um die Anzahl ein Replikaten zu reduzieren?

A: Erasure Codes verwenden? hingegen immer

F: Genau. Wie funktionieren die grundsätzlich?

A: Zwei Zahlen n und m, wobei m > n. Berechnung von m Blöcken aus der Originaldatei, Wiederherstellung aus n beliebigen davon möglich.

F: Und wie kann man sich diese Wiederherstellung im einfachsten Fall vorstellen?

A: So ähnlich wie ein Polynom vom Grad n durch n + 1 Punkte gegeben ist.

F: Viel einfacher. Denk mal an den Fall, dass m = n + 1. Was ist das dann?

A: Ein Xor.

F: Dann haben wir uns ja noch Koordinierungsdienste angeschaut, welche waren das?

A: Chubby und ZooKeeper.

F: Such dir eines davon aus, skizziere seinen Aufbau und erklär Unterschiede zum jeweils anderen.

A: [Baum gezeichnet.] Beide verwalten die Daten in einem Baum aus Knoten.

F: Das mein ich gar nicht, was sind die Unterschiede bei der internen Struktur?

A: Bei Chubby gehen alle Anfragen an das primäre Replikat, andere sind Schattenreplikate und kommen bloß beim Ausfall des Primary zum Tragen. In ZooKeeper können Anfragen an alle Replikate gestellt werden, Schreibanfragen werden an den Primary weitergeleitet. Dadurch schwächere Konsistenzgarantien.

F: Wie sehen diese Inkonsistenzen aus?

A: Problem ist, dass Primary beim Weiterleiten nur auf die Mehrzahl der Replikate wartet und nicht auf alle. Wenn jetzt ein Client 1 etwas geschrieben hat und dies Client 2 mitteilt, kann es sein, dass Client 2 ein Replikat erwischt, auf dem der Schreibvorgang noch nicht angekommen ist.

F: Wie verhindert Chubby trotzdem eine zu große Last für den Primary?

A: Durch Caching. Server merkt sich, welche Daten die Clients gelesen haben und damit zwischengespeichert haben könnten. Invalidierung aktiv durch Nachricht an die Clients.

F: Wie sieht diese Invalidierung aus?

A: Möchtest du auf den Fernaufruf-Mechanismus hinaus?

F: Nein, weniger. Gibt der Server einfach die Anweisung, den Cache wegzuwerfen?

A: Nur für betroffene Daten, aber im Grunde ja.

F: Man könnte ja auch den Cache gleich aktualisieren, indem man die neuen Daten mit schickt.

A: Dabei wären aber viele Daten zu übertragen.

F: Naja, wenn der Client die Daten gleich wieder liest, sind das noch mehr Daten.

A: Aber liest er sie denn gleich wieder?

F: Das ist ja genau die Frage – offensichtlich ja nicht. Wie viele Replikate gibt es denn üblicherweise?

A: Fünf.

F: Wieso?

A: Um split Brain zu verhindern, braucht man 2f + 1 Replikate. Im Fehlerfall durch kann man sicherstellen, dass man immer noch die Mehrheit sieht.

Wurde schnell wieder rein gebeten und bin sehr zufrieden .

Effektiv zwei Tage intensiver Vorbereitung, etwas mehr könnte nicht schaden. Es sind vergleichsweise wenige Folien, aber sehr dichter Inhalt. Bei Verständnisschwierigkeiten hilft es bisweilen, in den angegebenen Papers nachzulesen.

Die Prüfung orientiert sich eher am Vorlesungsstoff als an den Übungen (mit Ausnahme von ZooKeeper vielleicht). Mein Eindruck war, dass es eher um die grobe Architektur geht und das Verständnis für die Motivation bzw. daraus resultierende Probleme. Allerdings wurde auch ein paar Details abgefragt, also empfiehlt es sich durchaus, alles zu lernen.