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.

Link zu der Vergleichsansicht

Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung
Nächste Überarbeitung		Vorherige Überarbeitung
pruefungen:hauptstudium:ls4:mwcc-2015-02-25 [25.02.2015 12:02] – Mehr Fragen, jetzt aber wirklich essen F30pruefungen:hauptstudium:ls4:mwcc-2015-02-25 [25.02.2015 23:12] (aktuell) – Weitere Fragen F30
Zeile 1: Zeile 1:
-====== Middleware/Cloud Computing 2015-02-25 ======+====== MW/CC 2015-02-25 ======
 **Fach:** Middleware / Cloud Computing (5 ECTS) **Fach:** Middleware / Cloud Computing (5 ECTS)
  
Zeile 29: Zeile 29:
 **A:** [Beginn einer Zeichnung von //Stream Manager//, //Stream//, //Extents//, Blöcken etc.] **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?+**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?
  
-... (TODO)+**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.
  
 ===== Bewertung ===== ===== Bewertung =====