Verteilte Systeme

  Prüfer: Tobias Distler
  Beisitzer: Jürgen Kleinöder
  
  Alle Fragen kamen von Tobias. Sehr angenehme Prüfungsatmosphäre. Es ging bei
  allen Fragen um die Konzepte und es kam nicht darauf an irgendwelche
  Definitionen genau vorsagen zu können. Es kamen keine Algorithmen wie
  Lamport-Locks, Wellenverfahren oder Maekawa dran.
  
  - Was ist ein verteiltes System und was für Probleme gibt es?
    - Definition aus der Vorlesung
    - Konsistenz
    - Rechnerausfälle
    - Latenz
    - ...
    - wie findet der Client die Server (Registry)
    - wie kann man neue Replikate hinzufügen (Zustandstransfer), konsistent und
      ohne andere Replikate zu stark zu behindern (Last)
    - ...
    - hier hat er mich reden lassen und ich hab alle möglichen allgemeinen Dinge
      genannt
  
  - Wie funktioniert RPC?
    - Stub, Skeletion, Netzwerkschicht genannt und erklärt
  - Wie weiß der Client wohin er die Nachricht schicken soll?
    - Stub für exportiertes Objekt per Registry anfordern
    - im Stub steht Port vom Server + Client-ID damit der Server den Client
      erkennt
  
  - Marshalling, worauf muss man achten?
    - Endianess muss konvertiert werden, Begriffe genannt + kurz erklärt
      - Netzwerkformat, in das immer konvertiert wird, aber potentiell unnötige
        Konvertierung
      - sender-makes-it-right, geht nicht bei Multicast
      - receiver-makes-it-right, am generellsten, muss aber alle Formate
        unterstützen?
  - Andere Probleme?
    - sollte möglichst wenig Speicher brauchen
  
  - Was für Transparenzen gibt es?
    - Migrationstransparenz: Client kann umziehen
    - Ortstransparenz: Client muss Server nicht explizit kennen
    - ich kam nicht auf den Namen Zugriffstransparenz und hab etwas drum-rum erklärt
  
  - Ist eine völlige Zugrifsstransparenz möglich?
    - nein, weil es immer noch zu Netzwerk- oder Replikatausfällen kommen kann
      (hab in dem Kontext vorher auch mal RemoteException erwähnt)
    - dann kam ich nicht drauf worauf er raus wollte: die Methodensignatur ist
      bis auf "RemoteException" identisch ist
  
  - Ist völlige Transparenz immer sinnvoll?
    - nein, kann nützlich sein wenn der Client mehr über das System weiß um z.B.
      Konsistenzanforderungen unterschiedlich zu behandeln
  
  - Bei RPC können Netzwerkfehler auftreten, was tut man?
    - jeweils Begriff + kurze Erklärung
      - Maybe
      - At-Most-Once (hier hab ich kurz gesagt, dass At-Most-Once schwer in der
        RPC-Schicht alleine zu handhaben ist)
      - At-Least-Once
      - Last-of-Many
  - Du hast gesagt, At-Most-Once ist problematisch (siehe oben)?
    - RPC-System kann zwar Logs vor- und nach dem Methodenaufruf machen, aber es
      ist unklar was passiert wenn die Anwendung abstürzt. Ggf. wurde der
      Zustand der Anwendung schon beschädigt.
    - maximal einmal ist damit also leicht sicherzustellen (Log davor), aber
      es nicht sicher dass der dann auch ausgeführt wurde
  - Wie steht es mit dem Antwortspeicher von At-Most-Once, was muss man da tun?
    - Garbage-Collection
      - bei einfädigem Client (oder bei ID pro Thread) kann alte Antwort bei
        nächstem Request verworfen werden
      - Timeout wenn man weiß wie oft der Client es erneut probiert und wie
        lange er jeweils warten
      - zusätzliche Methoden + kurze Erklärung
        - Client sagt nach Absturz dem Server Bescheid
        - Generationenzähler
        - Leases
  
  - Wie kann man mit Server-Ausfällen umgehen?
    - Replikation: aktive und passive
  - Wie funktioniert aktive Replikation?
    - Anfragen werden von allen Replikaten verarbeitet
    - Einigungsprotokoll
    - deterministische Ausführung
    - Antwort
  - Was sind Probleme für die deterministische Ausführung?
    - Mehrfädigkeit: keine Race-Condition und Anwendung muss deterministische
      Ausführung sicherstellen
    - z.B. Zufallszahlen
    - externe Ereignisse: z.B. Requests
  - Wie geht man mit Zufallszahlen oder externen Ereignissen um?
    - nur einer macht diese Ausführung und verteilt das Ergebnis dann weiter
  - Was passiert bei einem Ausfall von diesem Replikat?
    - nach Timeout muss ein anderer übernehmen
    - es muss sichergestellt sein, dass er danach auch dieses Ergebnis nimmt und
      nicht selbst neu berechnet
  - Passive Replikation?
    - Anfragen werden nur von einem Replikat beantwortet
    - Zustand muss an andere Replikate übertragen werden
    - warm passive: regelmäßige Zustandsupdates die angewandt werden
    - cold passive: erst bei Replikatausfall werden die Updates angewandt
  
  - Gibt es sichere Fehlererkennung?
    - Nein, nicht über ein asynchrones Netzwerk.
  - Reicht ein synchrones Netz aus?
    - Nach etwas Nachdenken: Nur um Verluste über das Netzwerk zu erkennen, aber
      das System kann immer noch länger als erwartet brauchen (z.B. Swapping).
      (Er meinte dann noch, dass man dazu synchrone System bräuchte).
    - damit also meist keine sichere Fehlererkennung möglich
  
  - Wie geht man nun damit um, wenn ein anderen Knoten potentiell fehlerhaft
    ist? (Er sagte, das ging etwas über die Vorlesung heraus, aber es kam kurz
    mal in der Vorlesung dran.)
    - Fencing, "Shoot The Other Node In The Head" (STONITH)
    - um sicherzustellen, dass es kein Split-Brain gibt
    - ist aber generell etwas problematisch und man muss sicherstellen, dass
      sich die Knoten nicht gegenseitig abschießen
  - Was macht man, wenn man das Abschießen nicht tun will?
    - Anführerwahl
    - bei f tolerierten Ausfällen, braucht man f+1 Knoten
    - auch bei Netzwerkpartition ist sichergestellt, dass nur ein Anführer
      gewählt werden kann, da nur eine Partition die Mehrzahl der Knoten hat
  
  - Pileus, wie funktioniert es?
    - synchron replizierter Systemkern für Anfragen mit starken
      Konsistenzanforderungen und alle Writes
    - asynchron replizierte Knoten für Leseanfragen mit schwächeren
      Anforderungen
    - Alter der Daten in Antworten
  - Wer entscheidet wie mit alten Daten umgegangen wird?
    - Server schreibt alter der Daten in die Nachrichten
    - Client entscheidet wie konsistente und wie alte Daten er haben will
  
  - Was ist besser, aktiv oder passiv?
    - aktiv kann besser mit Replikatusfällen umgehen, dafür teurer da alle
      Knoten immer Rechnen müssen
    - passiv braucht länger für Wiederherstellung
    - kommt darauf an
  
  - Georeplikation, was für neue Probleme treten da auf?
    - Latenzen werden höher
    - Starke Konsistenz teurer herzustellen
    - man muss ggf. andere Konsistenzen hernehmen (jeweils Begriff und
      Erklärung)
      - Eventual Consistenzy
      - Monotonic Reads
      - Read-My-Writes
      - Consistent Prefix
      - Bounded Staleness (denn Begriff wusste ich nicht, hab's einfach erklärt)
  
  - Zeit, was ist das Problem?
    - Man kann Uhren in einem verteilten System nicht genau synchronisieren.
  - Wie genau geht das?
    - 10ms im Internet, 1ms in LAN
    - kommt auf die Uhren an
  - Was macht man wenn man doch genaue Zeitstempel will?
    - Logische Uhren
    - kurz Lamport-Clocks erklärt (Counter, bei Aktion + 1, bei Empfang max() + 1)
  
  Ergebnis: 1.0
  
  (Mindestens eine weitere Prüfung an diesem Tag lief sehr ähnlich ab.)