Skip to content

Commit 6cf1ad2

Browse files
scimbescimbe
committed
new slides
1 parent e7cbe31 commit 6cf1ad2

12 files changed

Lines changed: 1548 additions & 0 deletions

File tree

‎slides/Week-1/week-1.tex‎

Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,81 @@
1+
\documentclass{beamer}
2+
3+
\usetheme{CambridgeUS} % Beispielhaftes ansprechendes Design
4+
\usecolortheme{dolphin}
5+
6+
\title{Verteilte Systeme}
7+
\subtitle{Einleitung und Abgrenzung}
8+
\author{Prof. Dr. Martin Becke}
9+
\date{\today}
10+
11+
\begin{document}
12+
13+
\begin{frame}
14+
\titlepage
15+
\end{frame}
16+
17+
\begin{frame}{Verteilte Systeme in Hamburg}
18+
Hamburg, als bedeutender Wirtschaftsstandort, beherbergt zahlreiche Unternehmen, die auf innovative Technologien angewiesen sind. Verteilte Systeme spielen hier eine Schlüsselrolle, insbesondere in Branchen wie:
19+
20+
\begin{itemize}
21+
\item \textbf{Hafenlogistik:} Der Hamburger Hafen als Smart Port nutzt verteilte Systeme für effizientes Ressourcenmanagement, Echtzeit-Datenanalyse und Automatisierung. Stellen Sie sich den Hafen wie ein komplexes Uhrwerk vor, dessen Zahnräder perfekt ineinandergreifen müssen – jedes Zahnrad ein Knoten im verteilten System.
22+
\item \textbf{Luftfahrt:} Airbus nutzt verteilte Systeme für sichere und effiziente Flugzeugsysteme. Von Navigation bis zur Flugüberwachung kommunizieren verschiedene Komponenten in Echtzeit, ähnlich einem Orchester, das ein komplexes Musikstück spielt.
23+
\item \textbf{Finanzwesen:} Banken und Versicherungen nutzen verteilte Systeme für Echtzeit-Transaktionen und Datenverarbeitung. Stellen Sie sich ein Netzwerk von Bankautomaten vor: jeder Automat ein Knoten, der unabhängig arbeitet, aber Teil eines größeren, synchronisierten Systems ist.
24+
\end{itemize}
25+
26+
\end{frame}
27+
28+
29+
\begin{frame}{Definition}
30+
31+
\begin{block}{Was sind verteilte Systeme?}
32+
Verteilte Systeme sind eine Gruppe von vernetzten, autonomen Computern, die für den Benutzer als ein kohärentes System erscheinen. Sie arbeiten zusammen, um eine gemeinsame Aufgabe zu erfüllen, ohne dass ein zentraler Koordinator vorhanden sein muss. Denken Sie an ein Ameisenvolk: Jede Ameise handelt individuell, aber zusammen erreichen sie komplexe Aufgaben.
33+
\end{block}
34+
35+
\textbf{Kerneigenschaft:} Kein gemeinsamer Speicher. Die Kommunikation erfolgt über das Netzwerk, was Herausforderungen bei der Koordination mit sich bringt.
36+
37+
\end{frame}
38+
39+
40+
\begin{frame}{Abgrenzung}
41+
42+
Verteilte Systeme lassen sich von anderen Architekturen abgrenzen:
43+
44+
\begin{itemize}
45+
\item \textbf{Monolithische Systeme:} Alle Komponenten befinden sich in einer einzigen Codebasis. Wie ein einzelner, großer Kuchen – schwer zu ändern oder zu erweitern, im Gegensatz zu einem Buffet mit verschiedenen, unabhängigen Gerichten (verteiltes System).
46+
\item \textbf{Microservices:} Eine spezielle Form verteilter Systeme, bei der eine Anwendung in kleine, unabhängige Services aufgeteilt ist. Wie ein Baukastensystem: jeder Baustein (Service) hat eine spezifische Funktion und kann unabhängig kombiniert werden.
47+
\item \textbf{Großrechner/Mainframes:} Leistungsstarke, zentralisierte Systeme, die typischerweise in Rechenzentren eingesetzt werden. Wie ein einzelner, mächtiger Dirigent, der ein Orchester leitet – im Gegensatz zu einem selbstorganisierenden Ensemble (verteiltes System).
48+
\end{itemize}
49+
50+
\end{frame}
51+
52+
\begin{frame}{Abstraktionsebenen}
53+
54+
Verteilte Systeme lassen sich auf verschiedenen Abstraktionsebenen betrachten:
55+
56+
\begin{itemize}
57+
\item \textbf{Technologisch:} Fokus auf Hardware, Netzwerke und Protokolle. Wie die einzelnen Instrumente eines Orchesters und wie sie miteinander verbunden sind.
58+
\item \textbf{Anwendungsbezogen:} Fokus auf die Anwendungslogik und die Interaktion zwischen den Komponenten. Wie die Partitur eines Orchesters und wie die verschiedenen Instrumente zusammenspielen, um das Musikstück zu erzeugen.
59+
\end{itemize}
60+
61+
Die gewählte Abstraktionsebene beeinflusst die Art und Weise, wie wir über verteilte Systeme denken und sie entwerfen.
62+
63+
\end{frame}
64+
65+
66+
\begin{frame}{Aspekte und Sichten}
67+
68+
Verschiedene Aspekte sind bei der Entwicklung verteilter Systeme zu berücksichtigen:
69+
70+
\begin{itemize}
71+
\item \textbf{Skalierbarkeit/Ausfallsicherheit:} Wie reagiert das System auf wachsende Last? Wie wird mit Ausfällen umgegangen?
72+
\item \textbf{Datenmanagement:} Wie werden Daten konsistent gehalten und zwischen den Knoten synchronisiert?
73+
\item \textbf{Orchestrierung/Deployment:} Wie werden die verschiedenen Komponenten bereitgestellt und verwaltet?
74+
\item \textbf{Sicherheit:} Wie werden die Daten und Dienste vor unbefugtem Zugriff geschützt?
75+
\end{itemize}
76+
77+
Jeder dieser Aspekte erfordert eine sorgfältige Planung und Umsetzung.
78+
79+
\end{frame}
80+
81+
\end{document}

‎slides/Week-10/week-10.tex‎

Lines changed: 171 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,171 @@
1+
\documentclass{beamer}
2+
3+
\usetheme{CambridgeUS}
4+
\usecolortheme{dolphin}
5+
6+
\title{Verteilte Systeme}
7+
\subtitle{Konsens, Fehlertoleranz und Replikation}
8+
\author{Prof. Dr. Martin Becke}
9+
\date{\today}
10+
11+
\begin{document}
12+
13+
\begin{frame}
14+
\titlepage
15+
\end{frame}
16+
17+
\begin{frame}{Konsensbildung in verteilten Systemen}
18+
Konsensbildung ist der Prozess, bei dem eine Gruppe von Knoten in einem verteilten System eine gemeinsame Vereinbarung über einen Wert oder Zustand trifft. \newline
19+
\textbf{Wesentliche Herausforderungen:}
20+
\begin{itemize}
21+
\item Fehlertoleranz.
22+
\item Kommunikationslatenz.
23+
\item Sicherheit.
24+
\end{itemize}
25+
\textbf{Analogie:} Wie eine Jury, die ein Urteil fällen muss – alle Geschworenen müssen sich einigen, auch wenn einige anderer Meinung sind oder nicht erreichbar sind.
26+
\end{frame}
27+
28+
\begin{frame}{Quorumsabstimmung}
29+
Bei der Quorumsabstimmung muss eine Mindestanzahl von Knoten (das Quorum) zustimmen, um eine Entscheidung zu treffen. \newline
30+
\textbf{Kompromiss:}
31+
\begin{itemize}
32+
\item Kleineres Quorum: Schnellere Entscheidungen, aber höhere Fehlerwahrscheinlichkeit.
33+
\item Größeres Quorum: Höhere Zuverlässigkeit, aber langsamere Entscheidungen.
34+
\end{itemize}
35+
\end{frame}
36+
37+
\begin{frame}{Zentralisierte vs. dezentrale Konsensbildung}
38+
\begin{itemize}
39+
\item \textbf{Zentralisiert:} Ein Knoten (Leader) steuert den Prozess. Einfach, aber anfällig für Ausfälle des Leaders. \newline \textit{Analogie:} Wie eine Monarchie.
40+
\item \textbf{Dezentralisiert:} Alle Knoten sind gleichberechtigt. Robuster und skalierbarer, aber komplexer. \newline \textit{Analogie:} Wie eine Demokratie.
41+
\end{itemize}
42+
Hybride Ansätze kombinieren beide Strategien.
43+
\end{frame}
44+
45+
\begin{frame}{Fallbeispiel Zentral: ZooKeeper Atomic Broadcast (ZAB)}
46+
ZAB ist ein Konsensprotokoll, das von Apache ZooKeeper verwendet wird. \newline
47+
\textbf{Eigenschaften:}
48+
\begin{itemize}
49+
\item Garantiert zuverlässige Replikation von Updates.
50+
\item Ermöglicht geordnete Vereinbarungen über Änderungen am Systemzustand.
51+
\end{itemize}
52+
\textbf{Analogie:} Wie ein Orchesterdirigent, der sicherstellt, dass alle Musiker im gleichen Takt spielen.
53+
\end{frame}
54+
55+
\begin{frame}{Fallbeispiel Dezentral: Blockchain-Mechanismen}
56+
Blockchain-Mechanismen ermöglichen dezentrale Konsensbildung. \newline
57+
\textbf{Beispiele:}
58+
\begin{itemize}
59+
\item \textbf{Proof-of-Work (PoW):} Miner lösen komplexe Rätsel, um Transaktionen zu validieren und neue Blöcke hinzuzufügen.
60+
\item \textbf{Proof-of-Stake (PoS):} Die Wahrscheinlichkeit, einen Block hinzuzufügen, hängt vom Anteil am Netzwerk ab.
61+
\end{itemize}
62+
\end{frame}
63+
64+
\begin{frame}{Blockchain: Vorteile und Nachteile}
65+
\textbf{Vorteile:}
66+
\begin{itemize}
67+
\item Dezentralisierung.
68+
\item Transparenz.
69+
\item Sicherheit.
70+
\end{itemize}
71+
\textbf{Nachteile:}
72+
\begin{itemize}
73+
\item Skalierbarkeit.
74+
\item Hoher Energieverbrauch (bei PoW).
75+
\item Anfälligkeit für 51%-Angriffe.
76+
\item Datenunveränderlichkeit (Problematisch bei Fehlern).
77+
\end{itemize}
78+
\end{frame}
79+
80+
\begin{frame}{Fehlertoleranz}
81+
Fehlertoleranz ist die Fähigkeit eines Systems, trotz Fehlern funktionsfähig zu bleiben. \newline
82+
\textbf{Strategien:}
83+
\begin{itemize}
84+
\item Redundanz.
85+
\item Wiederherstellung.
86+
\item Fehlertolerante Kommunikation.
87+
\item Byzantinische Fehlertoleranz.
88+
\end{itemize}
89+
\end{frame}
90+
91+
\begin{frame}{Fehlerarten}
92+
Fehler in verteilten Systemen können auftreten als:
93+
\begin{itemize}
94+
\item \textbf{Hardwarefehler:} Ausfall von Komponenten.
95+
\item \textbf{Softwarefehler:} Bugs im Code.
96+
\item \textbf{Kommunikationsfehler:} Verlust oder Verzögerung von Nachrichten.
97+
\item \textbf{Byzantinische Fehler:} Fehlerhafte oder böswillige Knoten.
98+
\end{itemize}
99+
\end{frame}
100+
101+
\begin{frame}{Fehlermodell-Terminologie}
102+
Unterschiedliche Begriffe beschreiben verschiedene Aspekte von Fehlern:
103+
\begin{itemize}
104+
\item \textbf{Fault (Fehler):} Ursache des Problems.
105+
\item \textbf{Error (Fehlzustand):} Inkonsistenter Systemzustand.
106+
\item \textbf{Failure (Ausfall):} Beobachtbares Ergebnis.
107+
\end{itemize}
108+
Diese Begriffe sind wichtig für die Analyse und Behebung von Fehlern.
109+
\end{frame}
110+
111+
\begin{frame}{Fehlerarten: Fail-Stop, Fail-Noisy, Fail-Silent}
112+
\begin{itemize}
113+
\item \textbf{Fail-Stop:} Der Knoten hält an und signalisiert den Fehler.
114+
\item \textbf{Fail-Noisy:} Der Knoten liefert falsche Ergebnisse.
115+
\item \textbf{Fail-Silent:} Der Knoten hält an, ohne den Fehler zu signalisieren.
116+
\end{itemize}
117+
\end{frame}
118+
119+
\begin{frame}{Redundanz (1/2)}
120+
Redundanz erhöht die Fehlertoleranz durch zusätzliche Ressourcen:
121+
\begin{itemize}
122+
\item \textbf{Datenredundanz:} Mehrere Kopien der Daten (Replikation, Erasure Coding).
123+
\item \textbf{Rechenredundanz:} Parallele Ausführung von Berechnungen.
124+
\end{itemize}
125+
\end{frame}
126+
127+
\begin{frame}{Redundanz (2/2)}
128+
\begin{itemize}
129+
\item \textbf{Kommunikationsredundanz:} Mehrere Kommunikationspfade.
130+
\item \textbf{Prozess-Resilienz:} System bleibt trotz Prozessausfällen funktionsfähig.
131+
\end{itemize}
132+
\end{frame}
133+
134+
\begin{frame}{Replikation}
135+
Replikation erstellt und verwaltet Kopien von Daten auf mehreren Knoten. \newline
136+
\textbf{Vorteile:}
137+
\begin{itemize}
138+
\item Erhöhte Verfügbarkeit.
139+
\item Bessere Zuverlässigkeit.
140+
\item Verbesserte Skalierbarkeit.
141+
\item Schnellere Wiederherstellung.
142+
\end{itemize}
143+
\end{frame}
144+
145+
\begin{frame}{Replikation: Strategien}
146+
\begin{itemize}
147+
\item \textbf{Passive Replikation (Master-Slave):} Ein Knoten (Master) bearbeitet Anfragen, andere Knoten (Slaves) werden synchronisiert.
148+
\item \textbf{Aktive Replikation (Multi-Master):} Alle Knoten bearbeiten Anfragen, erfordert komplexe Konsistenzverwaltung.
149+
\end{itemize}
150+
\end{frame}
151+
152+
\begin{frame}{Replikation: Cold, Warm, Hot}
153+
\textbf{Unterschiede in der Aktualität der Replikate:}
154+
\begin{itemize}
155+
\item \textbf{Cold:} Seltene Aktualisierung (z. B. Backups).
156+
\item \textbf{Warm:} Regelmäßige Aktualisierung, aber nicht in Echtzeit.
157+
\item \textbf{Hot:} Nahezu Echtzeit-Aktualisierung, hohe Verfügbarkeit.
158+
\end{itemize}
159+
\end{frame}
160+
161+
\begin{frame}{Erasure Coding}
162+
Erasure Coding teilt Daten in Fragmente und erstellt Paritätsinformationen. \newline
163+
\textbf{Vorteile:}
164+
\begin{itemize}
165+
\item Speicherplatzsparender als Replikation.
166+
\item Ermöglicht Datenwiederherstellung bei Teilverlust.
167+
\end{itemize}
168+
\textbf{Analogie:} Wie ein RAID-System, bei dem Daten über mehrere Festplatten verteilt werden.
169+
\end{frame}
170+
171+
\end{document}

‎slides/Week-11/week-11.tex‎

Lines changed: 142 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,142 @@
1+
\documentclass{beamer}
2+
3+
\usetheme{CambridgeUS}
4+
\usecolortheme{dolphin}
5+
6+
\title{Verteilte Systeme}
7+
\subtitle{Algorithmen für Koordination und Konsens}
8+
\author{Prof. Dr. Martin Becke}
9+
\date{\today}
10+
11+
\begin{document}
12+
13+
\begin{frame}
14+
\titlepage
15+
\end{frame}
16+
17+
\begin{frame}{Algorithmen in Verteilten Systemen}
18+
Verteilte Systeme benötigen spezielle Algorithmen, um Herausforderungen wie Konsens, Koordination, Replikation und Fehlertoleranz zu meistern. \newline
19+
\textbf{Herausforderungen:}
20+
\begin{itemize}
21+
\item Knoten können ausfallen.
22+
\item Nachrichten können verloren gehen.
23+
\item Kommunikation ist oft asynchron.
24+
\end{itemize}
25+
\textbf{Analogie:} Wie ein Team von Bergsteigern: Sie müssen zusammenarbeiten und kommunizieren, um das Ziel zu erreichen, selbst wenn einige Mitglieder ausfallen oder der Weg unvorhersehbar wird.
26+
\end{frame}
27+
28+
\begin{frame}{Paralleles Rechnen}
29+
Paralleles Rechnen ermöglicht die gleichzeitige Ausführung von Berechnungen auf mehreren Prozessoren oder Knoten. \newline
30+
\textbf{Eigenschaften:}
31+
\begin{itemize}
32+
\item Ideal für rechenintensive Aufgaben, die in unabhängige Teile zerlegt werden können.
33+
\item Beispiele: Matrixmultiplikation, Bildverarbeitung, Simulationen, Maschinelles Lernen.
34+
\end{itemize}
35+
\textbf{Analogie:} Wie ein Team von Köchen, die gemeinsam ein Menü zubereiten: Jeder Koch arbeitet an einem anderen Gang, wodurch das Menü schneller fertig wird.
36+
\end{frame}
37+
38+
\begin{frame}{MapReduce}
39+
MapReduce ist ein Programmiermodell für die Verarbeitung großer Datenmengen in verteilten Systemen. \newline
40+
\textbf{Phasen:}
41+
\begin{itemize}
42+
\item \textbf{Map:} Die Eingabedaten werden in Schlüssel-Wert-Paare umgewandelt. \newline \textit{Analogie:} Sortieren von Wäsche nach Farben.
43+
\item \textbf{Reduce:} Paare mit gleichem Schlüssel werden zusammengefasst. \newline \textit{Analogie:} Zählen der Socken jeder Farbe.
44+
\end{itemize}
45+
\textbf{Beispiel:} Wortzählung in einem großen Textkorpus.
46+
\end{frame}
47+
48+
\begin{frame}{Resilient Distributed Datasets (RDDs) - Spark}
49+
RDDs sind unveränderliche, verteilte Datensammlungen in Apache Spark, die effiziente Datenverarbeitung und Wiederverwendung ermöglichen. \newline
50+
\textbf{Funktionen:}
51+
\begin{itemize}
52+
\item Unterstützung für Transformationen wie \texttt{map}, \texttt{filter} und \texttt{reduce}.
53+
\item Geeignet für komplexe Operationen wie SQL-Abfragen oder Machine Learning.
54+
\end{itemize}
55+
\textbf{Analogie:} Wie ein gut organisiertes Lager, in dem Materialien (Daten) effizient abgerufen und verarbeitet werden können.
56+
\end{frame}
57+
58+
\begin{frame}{Zentralisierte vs. Dezentralisierte Algorithmen}
59+
\begin{itemize}
60+
\item \textbf{Zentralisiert:} Ein einzelner Knoten steuert den Algorithmus. \newline \textit{Vorteil:} Einfachheit. \newline \textit{Nachteil:} Anfällig für Ausfälle des zentralen Knotens. \newline \textit{Analogie:} Ein Dirigent leitet ein Orchester.
61+
\item \textbf{Dezentralisiert:} Verantwortung verteilt auf alle Knoten. \newline \textit{Vorteil:} Robuster und skalierbarer. \newline \textit{Nachteil:} Komplexer in der Umsetzung. \newline \textit{Analogie:} Ein Jazz-Ensemble improvisiert zusammen.
62+
\end{itemize}
63+
\end{frame}
64+
65+
\begin{frame}{Konsensalgorithmen}
66+
Konsensalgorithmen stellen sicher, dass alle Knoten in einem verteilten System trotz Fehlern denselben Zustand oder Wert annehmen. \newline
67+
\textbf{Beispiele:}
68+
\begin{itemize}
69+
\item Paxos.
70+
\item Raft.
71+
\item ZAB (ZooKeeper Atomic Broadcast).
72+
\end{itemize}
73+
\end{frame}
74+
75+
\begin{frame}{Paxos}
76+
Paxos ist ein bekannter Konsensalgorithmus, der robust und fehlertolerant ist, jedoch als komplex in der Implementierung gilt. \newline
77+
\textbf{Rollen:}
78+
\begin{itemize}
79+
\item Proposer (Antragsteller).
80+
\item Acceptor (Annehmer).
81+
\item Learner (Lerner).
82+
\end{itemize}
83+
\textbf{Phasen:} Vorbereitung, Annahme, Lernen.
84+
\end{frame}
85+
86+
\begin{frame}{Raft}
87+
Raft ist eine modernere und verständlichere Alternative zu Paxos. \newline
88+
\textbf{Kernkonzepte:}
89+
\begin{itemize}
90+
\item \textbf{Leader Election:} Ein Leader wird gewählt.
91+
\item \textbf{Log Replication:} Der Leader repliziert Logs an andere Knoten.
92+
\item \textbf{Safety:} Garantiert Konsistenz.
93+
\end{itemize}
94+
\textbf{Analogie:} Wie ein gut organisiertes Team, das von einem gewählten Anführer koordiniert wird.
95+
\end{frame}
96+
97+
\begin{frame}{ZooKeeper Atomic Broadcast (ZAB)}
98+
ZAB ist ein speziell für Apache ZooKeeper entwickeltes Konsensprotokoll. \newline
99+
\textbf{Eigenschaften:}
100+
\begin{itemize}
101+
\item Garantiert zuverlässige Replikation.
102+
\item Sichert konsistenten Systemzustand.
103+
\end{itemize}
104+
\textbf{Modi:}
105+
\begin{itemize}
106+
\item Recovery (Wiederherstellung).
107+
\item Broadcast (Übertragung).
108+
\end{itemize}
109+
\textbf{Analogie:} Wie ein Nachrichtendienst, der sicherstellt, dass alle Abonnenten dieselben Nachrichten erhalten.
110+
\end{frame}
111+
112+
\begin{frame}{Koordination: Snapshots und Checkpoints}
113+
\begin{itemize}
114+
\item \textbf{Snapshots:} Erfassen den globalen Systemzustand zu einem bestimmten Zeitpunkt. \newline \textit{Analogie:} Wie ein Foto.
115+
\item \textbf{Checkpoints:} Speichern den lokalen Prozesszustand. \newline \textit{Analogie:} Wie ein Speicherpunkt in einem Videospiel.
116+
\end{itemize}
117+
Beide Techniken sind essenziell für Fehlertoleranz und Debugging.
118+
\end{frame}
119+
120+
\begin{frame}{Koordination: Deadlock Detection und Termination Detection}
121+
\begin{itemize}
122+
\item \textbf{Deadlock Detection:} Erkennt Situationen, in denen Prozesse zyklisch aufeinander warten.
123+
\item \textbf{Termination Detection:} Erkennt, wann alle Prozesse ihre Arbeit abgeschlossen haben.
124+
\end{itemize}
125+
Beide Mechanismen sind entscheidend für die korrekte Funktion verteilter Systeme.
126+
\end{frame}
127+
128+
\begin{frame}{Koordination: Mutual Exclusion und Barriers}
129+
\begin{itemize}
130+
\item \textbf{Mutual Exclusion:} Verhindert, dass mehrere Prozesse gleichzeitig auf eine Ressource zugreifen. \newline \textit{Analogie:} Wie ein Schlüssel für ein Badezimmer.
131+
\item \textbf{Barriers:} Synchronisiert Prozesse an bestimmten Punkten im Code. \newline \textit{Analogie:} Wie eine Startlinie bei einem Rennen.
132+
\end{itemize}
133+
\end{frame}
134+
135+
\begin{frame}{Koordination: Self-Stabilization und Smart Contracts}
136+
\begin{itemize}
137+
\item \textbf{Self-Stabilization:} Systeme erholen sich automatisch von Fehlern und erreichen einen korrekten Zustand. \newline \textit{Analogie:} Wie ein Stehaufmännchen.
138+
\item \textbf{Smart Contracts:} Automatisierte Verträge auf Blockchains. \newline \textit{Analogie:} Wie ein digitaler Notar.
139+
\end{itemize}
140+
\end{frame}
141+
142+
\end{document}

0 commit comments

Comments
 (0)