====== 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.)