Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » MW/CC 2015-02-25 (Übersicht)
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Beide Seiten, vorherige ÜberarbeitungVorherige ÜberarbeitungNächste Überarbeitung | Vorherige Überarbeitung | ||
pruefungen:hauptstudium:ls4:mwcc-2015-02-25 [25.02.2015 11:47] – Erste Fragen F30 | pruefungen:hauptstudium:ls4:mwcc-2015-02-25 [25.02.2015 23:12] (aktuell) – Weitere Fragen F30 | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== | + | ====== |
**Fach:** Middleware / Cloud Computing (5 ECTS) | **Fach:** Middleware / Cloud Computing (5 ECTS) | ||
Zeile 19: | Zeile 19: | ||
**F:** Was ist mit Wechseln des Anbieters? | **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. | + | **A:** Starker |
- | **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? | + | **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 |
- | **A: | + | **A: |
- | ... | + | **F:** Skizzier mal die Speicherung von Daten im //Stream Layer//. |
+ | |||
+ | **A:** [Beginn einer Zeichnung von //Stream Manager//, //Stream//, // | ||
+ | |||
+ | **F:** Das interessiert mich gar nicht so sehr. Nehmen wir mal an, der //Stream Manager// hat die richtigen //Extents// ausgewählt; | ||
+ | |||
+ | **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// | ||
+ | |||
+ | **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, | ||
+ | |||
+ | **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 '' | ||
+ | |||
+ | **F:** Und wie kann man sich diese Wiederherstellung im einfachsten Fall vorstellen? | ||
+ | |||
+ | **A:** So ähnlich wie ein Polynom vom Grad '' | ||
+ | |||
+ | **F:** Viel einfacher. Denk mal an den Fall, dass '' | ||
+ | |||
+ | **A:** Ein Xor. | ||
+ | |||
+ | **F:** Dann haben wir uns ja noch Koordinierungsdienste angeschaut, welche waren das? | ||
+ | |||
+ | **A:** //Chubby// und // | ||
+ | |||
+ | **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 // | ||
+ | |||
+ | **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, | ||
+ | |||
+ | **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 '' | ||
===== Bewertung ===== | ===== Bewertung ===== | ||
Zeile 31: | Zeile 181: | ||
===== Vorbereitung ===== | ===== Vorbereitung ===== | ||
- | Effektiv zwei Tage intensiver Vorbereitung, | + | Effektiv zwei Tage intensiver Vorbereitung, |
Die Prüfung orientiert sich eher am Vorlesungsstoff als an den Übungen (mit Ausnahme von // | Die Prüfung orientiert sich eher am Vorlesungsstoff als an den Übungen (mit Ausnahme von // |