Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » MW/CC 2015-04-09
Inhaltsverzeichnis
MW/CC 2015-04-09
Fach: Middleware / Cloud Computing (7,5 ECTS)
Prüfer: Jürgen Kleinöder
Beisitzer: Tobias Distler
Lockere Atmosphäre, wie üblich beim LS 4. Tobias stellt die Fragen, außerdem liegen Stift und Papier bereit, die man durchaus nutzen sollte.
Fragen
F: Zum Einstieg: Was ist Cloud Computing. Worin liegen die Vor- und Nachteile?
A: Auslagerung von Diensten in die Cloud; Nutzung von Infrastruktur auf „Mietbasis“; Wichtiges Merkmal ist vor Allem die dynamische Skalierbarkeit bis ins „Unendliche“. Vorteil für den Nutzer ist vor Allem die schnelle Skalierbarkeit und das feingranulare Bezahlmodell („Pay-as-you-go“). Vorteil für den Anbieter ist die Nutzung der sonst brachliegenden Ressourcen. Nachteile ist der höhere Preis im Vergleich zu gut ausgelasteter eigener Hardware und das Vendor Lock-In Problem.
F: Erklär das Vendor Lock-In Problem genauer.
A: Hauptsächlich aufgrund von fehlenden Standards ist ein Umzug zu einem anderen Anbieter aufwändig.
F: Wenn man also Standards hätte, wäre alles gut?
A: Sie würden definitiv helfen, aber man muss immer noch die Daten aus der alten Cloud herunter- und in die neue hinaufladen.
F: Wir haben zwei Basistechnologien für Cloud Computing kennen gelernt, welche sind das und warum?
A: Web Services, um eine sprachunabhängige Schnittstelle zu den Cloud Diensten zu ermöglichen und Virtualisierung, um Rechenleistung sehr schnell dynamisch zur Verfügung stellen zu können bzw. auf Anbieterseite zur Server-Konsolidierung.
F: Such dir eins davon aus und erzähl mir ein wenig mehr darüber.
A: Dann nehm ich Virtualisierung.
F: Welche drei Eigenschaften sind für eine VM maßgeblich?
A: Äquivalenz, welche auch Isolation impliziert. Ein Nutzer sollte im Bestfall keine Chance haben herauszufinden, ob er auf einer VM arbeitet oder auf einer echten Maschine.
F: Kann man das in der Realität schaffen?
A: Nein, nicht wirklich. Wenn man mehrere VMs hat dann teilt man sich die Ressourcen durch Multiplexing. Und selbst wenn nur eine VM läuft, benötigt der VMM auch ein paar Ressourcen.
F: Gut, was sind weitere Eigenschaften?
A: Effizienz, das heißt, der Großteil der Instruktionen sollte direkt auf dem Host ausgeführt werden. Bei Binary Translation ist das ein wenig abgeschwächt. [Bevor ich zur Ressourcenkontrolle gekommen bin, waren wir schon beim nächsten Thema]
F: Bleiben wir mal bei Binary Translation. Wie funktioniert das?
A: Code der VM wird blockweise in die Ziel-ISA übersetzt, das heißt die VM ist vollständig von der Hardware entkoppelt. Das ist auch eine beliebte Implementierungsmöglichkeit für Emulatoren.
F: Das beißt sich ja mit der Effizienz, oder?
A: Ja, außer wenn man gleiche Architekturen hat, dann reicht eine 1:1 Übersetzung. Bei x86 würde man beispielsweise alle senstiven Instruktionen abfangen und emulieren und alle anderen nativ ausführen.
F: Ok, dann kommen wir mal zu Cloud Datenspeichern. Da hatten wir ja GFS zum Beispiel. Erklär mal die Komponenten und wie eine Schreibanfrage funktioniert.
A: [Skizze: Master, Chunk-Nodes] Wir haben einen Master und mehrere Chunk-Nodes. Gespeichert werden Chunks, die 64 MB groß sind. Beim Schreiben wird zunächst der Master nach den Chunk-Nodes für einen Chunk gefragt, anschließend werden die Daten an den nächstgelegenen Chunk-Node gesendet und dieser piped sie an die anderen weiter. Wenn das erfolgreich war, dann macht man einen Schreibaufruf beim Primary, der sie an die Secondaries weiterleitet.
F: Muss man bei jeder Anfrage den Master fragen?
A: Nein, der Client cached die Metadaten. Dadurch sind diese zwar eventuell leicht veraltet, aber die eigentliche Nutzdaten sind es nicht (außer im Falle von Stale Replicas).
F: Wozu braucht man konkret einen Primary?
A: Wenn man Record Append nutzt, dann legt der Primary den Offset fest und bestimmt damit, wo geschrieben wird.
F: Und bei normalen Schreibanfragen? Braucht man da einen Primary?
A: [Da hing ich etwas und hab überlegt, Tobias hat dann einen zweiten Client auf das Blatt gemalt] Ach ja, wenn man einen zweiten Client hat, dann dient der Primary zur Sequentialisierung der Anfragen.
F: Genau. Der Master wählt ja die Chunk-Nodes aus, nach welchen Kriterien geschieht das?
A: Nach Lokalität, Auslastung und Fehlerdomänen hauptsächlich.
F: Erklär mal, was eine Fehlerdomäne ist.
A: Beispielsweise ein Rack, mit einer eigenen Netzwerk- und Stromversorgung. Man würde Chunks in verschiedene Racks replizieren, damit beim Ausfall von einem Rack der andere Chunk noch verfügbar ist.
F: Warum ist der Master so ein Bottleneck für Google geworden mit der Zeit?
A: Das Hauptproblem sind ist die Anzahl an Chunks. Wenn man sehr viele kleine Dateien hat, dann verbraucht jede einen eigenen Chunk und das führt zu vielen Metadaten, die der Master verwalten muss.
F: Microsoft hat sich beim WAS auch für einen zentralen Master im Stream Layer entschieden. Wieso? Laufen die nicht auch irgendwann in die gleichen Probleme?
A: Großer Unterschied ist, dass der einzige Client des Stream Layer der Partition Layer ist, der sich „brav“ verhält und keine kleinen Dateien anlegt, sondern kleine Objekte zu großen zusammenfasst.
F: Wir hatten auch noch ein System ganz ohne Master, welches denn?
A: Amazon Dynamo, das einen völlig dezentralen Peer-to-Peer Ansatz hat.
F: Was sind denn die Folgen bei so einem System?
A: Der Tradeoff ist, dass man geringere Konsistenz hat, das heißt man kann veraltete oder in Konflikt stehende Daten lesen. Dafür brauchts dann teilweise eine manuelle semantic reconciliation.
F: Wie funktioniert die Erkennung von verschiedenen Versionen?
A: Durch Vektoruhren, bestehend aus dem jeweiligen Knoten und einem Zähler. Dadurch kann man verschiedene Versionen in Beziehung zueinander setzen und Mergekonflikte erkennen, die nur der Client lösen kann.
F: Könnte man in GFS nicht etwas ähnliches machen?
A: Naja das Hauptproblem ist ja, dass man dem Client alle problematischen Versionen geben muss. Bei 64 MB Chunks ist das eher unlustig.
F: Das heißt, was ist bei Dynamo anders?
A: Dynamo ist nur für die Speicherung von vielen kleinen Daten ausgelegt, also kleiner als 1 MB.
F: Genau. Zum Schluss hatten wir noch virtualisierungsbasierte Fehlertoleranz, also Maßnahmen, die helfen, wenn eine VM abschmiert.
A: Ja, dafür haben wir Remus kennen gelernt.
F: Wie funktioniert das?
A: Bei Remus gibt es einen Primär- und einen Backup-Host. Die aktive VM läuft auf dem Primärhost und schickt hochfrequent alle 25 ms Checkpoints an den Backuphost.
F: Okay, wir hatten außerdem noch ZooKeeper, das ja einen bestätigten Zustand und einen aktuellen, aber unbestätigten Zustand verwaltet. Siehst du irgendwelche Parallelen zu Remus?
A: Naja, Remus hat ja praktisch gesehen auch einen unbestätigten Zustand im Primärhost und einen bestätigten in Backuphost.
F: Okay, trotzdem gibts einen kleinen Unterschied.
A: Bei ZooKeeper hat der Master sowohl den bestätigten, als auch den unbestätigten Zustand. Bei Remus hat der Primärhost nur den unbestätigten Zustand.
F: Exakt! Was bedeutet das für Anfragen?
A: Wenn man eine ZooKeeper-Alternative auf dem Konzept von Remus bauen würde, dann dürfte der Master keine Read-Anfragen bearbeiten.
F: Joa naja, wie macht es denn Remus?
A: Remus würde Read-Anfragen unbeantwortet lassen, bis der zugehörige unbestätigte Zustand zum bestätigten Zustand wird. Dazu puffert es die ausgehenden Pakete.
F: So ist es. Warum haben wir bei ZooKeeper - sagen wir - 3 Replikate, um 1 Fehler zu tolerieren?
A: Um ein Split Brain zu vermeiden. [Skizze mit 5 Knoten gemalt] Wenn eine Netzwerk-Partitionierung hat, dann dürfen die beiden Teilsysteme nicht divergieren.
F: Und warum haben wir bei Remus nur 2 Hosts für 1 Fehler?
A: [Hier habe ich etwas um den heißen Brei herum geredet und bin nicht direkt auf die Antwort gekommen.]
F: Also die Antwort ist einfach, dass Remus nicht Partitions-tolerant ist :)
Bewertung
Wurde fix wieder rein gebeten und bin mit der Note sehr zufrieden :) Es wird durchaus positiv bewertet, wenn man viel eigenständig erklärt. Ein paar kleinere Hänger hier und da spielen keine Rolle und es wird immer versucht, einem auf die Sprünge zu helfen und doch noch selbst auf die Lösung zu kommen.