Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » MW/CC 2018-02-22 (Übersicht)

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

--- pruefungen:hauptstudium:ls4:mwcc-2018-02-22 [23.02.2018 13:26] – sedrubal
+++ pruefungen:hauptstudium:ls4:mwcc-2018-02-22 [23.02.2018 16:06] (aktuell) – sedrubal
@@ Zeile 16: / Zeile 16: @@
 - Vorteile: Skalierbarer, Effizienter, Know How / Aufwand / Risiken Outsourcen
-- Nachteile: Rechtliches (Datenschutz) und Vendor Lock-In (Nutzen spezieller Dienste, fehlende Standards)
+- Nachteile: Rechtliches (Datenschutz bei ausländischen Anbietern) und Vendor Lock-In (Nutzen spezieller Dienste, fehlende Standards)
-**F:** Wir haben uns 2 Datenspeicherlösungen angeschaut. Windows Azure Storage verwendet ja ein Frontend Layer, ein Stream Layer und Partition Layer. Erkläre, wie ein Schreibzugriff vom Partition Layer auf das Stream Layer ausschaut.
+**F:** (zum Datenschutz) Kann man sich wirklich nicht sicher sein, dass die Daten ein einem Bestimmten Land liegen?
-**A:** Bild mit PL, Stream Manager, einem Primary und 2 Secondaries hin gemalt und Pfeile (Datenfluss und ACKs) dazu.
+**A:** Naja meistens kann man die Region angeben, wo die Daten landen sollen (zumindest bei Amazon).
-**F:** Wenn ich Daten gespeicher hab und ein OK bekommen hab, sind die Daten dann sicher?
+**F:** Ja. Aber auf dem Weg können sie ja z.B. erst über die ganze Welt gehen.
+**F:** Wir haben uns 2 Datenspeicherlösungen angeschaut. Windows Azure Storage verwendet ja ein Frontend Layer, ein Stream Layer (SL) und Partition Layer (PL). Erkläre, wie ein Schreibzugriff vom PL auf das SL ausschaut.
+**A:** Bild mit PL, Stream Manager (SM), einem Primary und 2 Secondaries hin gemalt und Pfeile (Datenfluss und ACKs) dazu.
+**F:** Wenn ich Daten gespeichert hab und ein OK bekommen hab, sind die Daten dann sicher?
 **A:** Sie sind dann bereits auf 3 Fehlerdomänen verteilt (gegen einzelne Hardware- (/Festplatten-) ausfälle etc. geschützt). Allerdings erfolgt die Replikation auf anderes Stamp erst asynchron zum Schreibvorgang und ACK kommt schon vorher. D.h. nicht gegen Feuer- / Tornado (ganze Rechenzentrumsausfälle) geschützt.
@@ Zeile 30: / Zeile 36: @@
 **F:** Was passiert jetzt, wenn ein Fehler beim Schreiben passiert, also z.B. ein Netzsplit und der 2. Secondary kann nicht erreicht werden? (Annahme Stream Manager kann aber noch mit dem reden)
-**A:** Kein ACK an PL, PL meldet Vorfall an Stream Manager, SM fragt Replikate nach Ende des Extents, Wegwerfen des gerade geschriebenen Blocks, Versiegeln des Extents.
+**A:** Kein ACK an PL, PL meldet Vorfall an SM, SM fragt Replikate nach Ende des Extents, Wegwerfen des gerade geschriebenen Blocks, Versiegeln des Extents.
 **F:** Jetzt haben wir Daten weg geschmissen. Ist das ein Problem?
@@ Zeile 50: / Zeile 56: @@
 **A:** Nein, denn SM wird vom PL bedient. Dieses fasst kleine Daten zu größeren Blöcken zusammen und macht nur append.
-Da hats ein bisschen geholpert. Ich dachte außerdem noch, dass man den SM nur für neue Extents befragen muss, aber wenn man Blöcke schreibt, ist das ja unabhängig. Aber das ist nicht relevant, da die Blöcke echt klein sind und Extents eher dem entsprechen, was Blöcke im GFS sind.
+Da hat's ein bisschen geholpert. Ich dachte außerdem noch, dass man den SM nur für neue Extents befragen muss, aber wenn man Blöcke schreibt, ist das ja unabhängig. Aber das ist nicht relevant, da die Blöcke echt klein sind und Extents eher dem entsprechen, was Blöcke im GFS sind.
 **F:** Wir haben uns außerdem Koordinierungsdienste (Chubby, ZooKeeper) angeschaut. Warum braucht man denn da 2f+1 Replikate zum Tolerieren von f Fehlern, während man bei GFS und Azure nur f+1 braucht?