Hier sind 4 Protkolle gelistet, die alle an einem Tag mehr oder weniger hintereinander waren. Prüfer war Tobias Distler, Beisitzer war Jürgen Kleinöder. Vor der Prüfung sollte man eines von 3 Papern auswählen (Eucalyptus, Dynamo, Chubby). Zu den Übungen oder zu dem WAS Paper wurde nichts gefragt.
Zur Atmosphäre: Tobias musste wohl spontan einspringen und war sichtlich unbegeistert noch jemanden über das gleiche Zeug zu prüfen. Kann ich auch voll verstehen, ich war schon nummer 6. oder so -.- Naja, kann keiner was dafür, ich hab versucht ihn mit Geschichten ausm Praxisalltag aufzuheitern^^
Herr Kleinöder hat zwei Mal sehr gute Fragen dazwischengehängt.
Hab erzählt einem Praxisbeispiel eines Web-Services, der im Moment noch klein ist, jedoch später womöglich viel größer wird (mehr Daten, mehr Anfragen, mehr zu rechnen). Dann hab ich das Problem vom 29. Februar 2012 bei Windows Azure erzählt und bin dann bissl in Richtung SLA gegangen, warum es denn doch noch risikoreich ist, seinen Service in einer Cloud zu hosten.
Was bietet einem die Cloud (anspielung auch, welche Cloud-Services es gibt, IaaS, PaaS, SaaS)? → Rechenleistung, Datenspeicherung, Sicherheit durch Redundanz, einfache Erweiterbarkeit im Bedarfsfall
Wie genau läuft das ab, wenn der Benutzer eine neue VM registrieren will? → CLC prüft Anforderungen (Zonen-Wunsch) und benachrichtigt einen CC, der widerrum bei seinen NC nach Ressourcen anfragt. Typische Ressourcen sind dabei RAM, CPU-Kerne, Lokaler Speicher (das VM Image muss auch noch draufpassen).
Die VM wurde übrigens über first-fit ausgesucht. Welche Vor-/Nachteile hat das für wen? → Vorteil für den Cloud-Betreiber, da er einzelne Nodes gut auslasten kann und andere komplett vom Strom nehmen kann um Geld zu sparen. Nachteile haben die Benutzer, die alle auf einer Maschine sitzen. Sollten hier z.B. mehrere Web-Shops sein, kommt es ggf. zu Problemen im Weihnachtsgeschäft. Andererseits gibt es auch Sicherheitsrisiken, wenn alle auf einer Maschine untergebracht sind: Root-Kits, die im Hypervisor sitzen. Welche Anforderung an eine Cloud-Lösung würde hier verletzt? → Isolation
Hmm OK, was hätte ich denn noch bei der Platzierung der neuen VM berücksichtigen können, wenn mein User möchte, dass er weitere Instanzen von VMs sehr schnell starten kann? → Eine Maschine wählen, wo das Image bereits vorhanden ist.
Map/Reduce: Erzählen warum Google das gemacht hat, was so damit verarbeitet wird. Bitte generell skizzieren. → Sehr einfaches Bild gemacht, schon zu viel über “Dateien im GoogleFS” gelabert. Hatte im Bild zwischen Mappern und Reducern “eine Datei” hingemalt, stimmt aber so natürlich nicht. Denn das sind die Ergebnisse der Mapper, die noch lokal bei den Mappern liegen.
Habe nebenbei Optimierungsmöglichkeiten erzählt, wurde aber gebremst und später nochmal genauer gefragt: Datenlokalität: Habe erzählt wo man die Mapper hinsetzt (bei den Daten natürlich, denn der Master weiß vom GoogleFS, auf welchem Server die Daten liegen. Bei den Reducern ist das schwieriger, da sie direkt auf die Daten bei den einzelnen Mappern verwiesen werden.
Dann kam die Frage, welche Ausfallszenarien es gibt. → Es könnte der Master-Server abschmieren. Daher gibt es eine periodische Zustandssicherung des Masters (Tasks, welche davon fertiggestellt, Ressourcenpointer etc.). Beim Ausfall wird dieser ersetzt, doch fängt bei einem alten Stand ein (Mapper liefern ja nur 1x Fertigmeldung, wenn die an den ausgefallenen Master geht, bekommt’s keiner mit und der Ersatz-Master wird den Task neu starten, weil er von einem Ausfall ausgeht.
Was passiert wenn ein Mapper ausfällt? → Dessen Task muss neu gestartet werden. Man legt auch redundant Mapper an, damit diese sehr langsame Tasks ausführen, damit die Gesamtzeit (bis alle Mapper fertig sind) kleiner ausfällt. Aber was ist wenn ein Reducer ausfällt, ist das genauso schlimm oder auch ok? Das ist nicht so schlimm, denn den Reducer kann ich neu starten. Wenn aber ein Mapper ausfällt, von dem ein Reducer die Daten nimmt, muss ich den ganzen Vorgang ja neu starten.
Dummerweise hatte ich nur drei Server gemalt. Wer hält welche Daten? (Hier hatte ich wild Pfeile gemalt, auch nicht vorteilhaft bzgl. “wer hält diesen Key, wenn er neu dazukommt?”. Als ich dann das Szenario des Serverausfalls beschreiben wollte (wer Übernimmt die Daten beim Hinted Hand-Off), hatte ich keinen vierten Server, der sich drum kümmern muss (falls wir 3-Fach redundant sein wollen, müssen die Key/Value-Paare auch auf drei komplett verschiedenen Maschinen liegen.
Ich hab Hinted Hand-Off beschrieben, weil mir der Begriff erstmal nich eingefallen is hab ich kurz gestottert, dann kam’s mir aber wieder^^ Tobi war sehr scharf auf diese Begriffsnennung hatte ich das Gefühl.
Dann kam ich auf Eventual Consistency zu sprechen und musste daraufhin erklären, wer bei einem Schreibzugriff die Daten erhält und wie sie auf Knoten verteilt werden. Wenn ich 3x replizieren möchte, repliziert der angesprochene Knoten die Daten auf zwei weitere, wartet jedoch nicht auf das ACK von beiden (bei Amazon’s Dynamo reicht ein ACK).
Frage von JK: Lösen die Server dann beim Lesen die Inkonsistenzen nicht selber auf? → Doch, die einfachen schon, aber wenn A etwas schreibt, und später B und C gleichzeitg Änderungen drauf aufführen, weiß man nicht, welche Version die richtige ist. Habe dabei beschrieben, dass zum Key/Value-Paar noch ein Context-Objekt existiert, dass die Vektoruhren führt. Der Client muss sich danach entscheiden, was er mit den Key/Value-Paaren macht, denn er bekommt bei Konflikten ja mehrere Einträge mit verschiedenen Vektoruhren zurück. Anwendungsfall Amazon: Dann bleibt das Produkt eben im Warenkorb, wenn wir nicht sicher sind, ob es gelöscht wurde oder nicht.