Transactional Memory for Distributed Systems Michael Schöttner, Marc-Florian Müller, Kim-Thomas Möller, Michael Sonnenfroh Heinrich-Heine Universität Düsseldorf Abteilung Betriebssysteme Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
1/26
1
Vorschau
1. Transaktionaler Speicher 2. Verteilter Transaktionaler Speicher 3. Ergebnisse 4. Fazit & Ausblick
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
2/26
2
1. Transaktionaler Speicher
Ausgangssituation ●
●
●
Problem: CPU Taktraten wachsen nur noch sehr langsam Lösung: Mehrkern-Prozessoren → simultane Ausführung paralleler Threads eines Prozesses Konsequenz: bevorzugt parallele Programmierung
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
3/26
3
1. Transaktionaler Speicher
Ausgangssituation ●
●
Herausforderung: Synchronisierung von Threads ➢
Beim Zugriff auf gemeinsame Variablen
➢
Sonst entstehen Wettlaufsituationen, lost update etc.
Traditionelle Lösung: Sperren / kritische Abschnitte ➢
Je nach Problem schwierig zu realisieren
➢
Gefahr von Fehlern und Verklemmungen
➢
Maximale Nebenläufigkeit gewünscht
→ Alternative: transaktionaler Speicher
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
4/26
4
1. Transaktionaler Speicher
Programmiermodell ●
Idee: Spekulative Transaktionen statt Sperren (Transaktionen + optimistische Synchronisierung)
●
Transaktionen haben ACId-Eigenschaften
●
Programmierer muss Transaktion definieren: BOT & EOT
●
Oft werden kritische Abschnitte als Transaktion realisiert ➢
Java:
synchronized (obj) { … }
➢
TM:
BOT { … } EOT
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
5/26
5
1. Transaktionaler Speicher
Validierung ●
●
Aufzeichnen spekulativer Lese- und Schreibzugriffe --> Read- und Write-Set Schreibzugriffe werden erst beim Commit sichtbar T1
●
Validierung: Vergleiche überlappende noch laufende TAs
T2
Zeit
W(x)=1 R(x)=0
Serialisierung ●
Abbruch & Rücksetzung im Konfliktfall → T1
W(x)=1
T2
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
Zeit
R(x)=1
6/26
6
2. Transaktionaler Speicher
Rücksetzbarkeit ●
Speicherzugriffe müssen erkannt werden ➢
➢
Reset
beim ersten Lese-/Schreibzugriff innerhalb einer Transaktion Bei Schreibzugriffen Schattenkopien anlegen, notwendig für Rücksetzbarkeit
Shadowcopies Write-Set
Read-Set
●
Betriebssystem- bzw. I/O-Aufrufe sind kritisch …
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
7/26
7
1. Transaktionaler Speicher
Implementierungsaspekte ●
TM-Systeme in der Regel auf Cache-Ebene implementiert
●
Zusätzliche Bits pro Cache-Line zur Verwaltung der Zugriffe
●
Schattenkopien von Cache-Lines → Rücksetzbarkeit
●
TA-Validierung als Cache-Kohärenzprotokoll
●
Großes Interesse in Forschung und Industrie
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
8/26
8
2. Verteilter Transaktionaler Speicher
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
9/26
9
2. Verteilter Transaktionaler Speicher
XtreemOS ●
●
●
Linux-basiertes Grid-Betriebssystem ➢
Für vernetzte Desktop PCs
➢
Und für Cluster
Integriertes Projekt, gefördert von EU ➢
19 Partner, ~120 Personen
➢
http://www.xtreemos.eu
HHU-Beteiligung ➢
Grid Checkpointing Service (Job-Migration / Fehlertoleranz)
➢
Object Sharing Service (Daten-Management)
10
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
10/26
2. Verteilter Transaktionaler Speicher
Zielsetzung ●
Vereinfachung der Entwicklung verteilter und paralleler Anwendungen (im Cluster und Grid-Umgebungen
●
Transparenter Zugriff auf entfernte Speicherobjekte
●
Automatische Replikation
●
Transaktionale Konsistenz ➢
Strenge Konsistenz --> Komfort
➢
Änderungen werden gebündelt propagiert
➢
Optimistische Synchronisierung statt Sperren
11
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
11/26
2. Verteilter Transaktionaler Speicher
Zielanwendungen ●
●
Rechenintensive/datenintensive App. ➢
Simulationen, Data Mining, Ray Tracing, … →
➢
Daten: Skalare, meist wenige grosse Objekte
Interaktive Anwendungen ➢
Mehrbenutzerspiele →
➢
Daten: verzeigerte Strukturen, viele kleine Obj.
12
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
12/26
2. Verteilter Transaktionaler Speicher
OSS-Architektur
13
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
13/26
2. Verteilter Transaktionaler Speicher
Skalierbare Transaktionen ●
Transaktionale Konsistenzdomänen ➢
●
Jede Domäne wird separat validiert
Lokaler Commit ➢
Falls nur gelesen wurde
➢
Oder nur nicht-replizierte Daten verändert wurden
●
Verkettete Transaktionen
●
Super-Peer Overlay-Netzwerk
14
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
14/26
2. Verteilter Transaktionaler Speicher
Super-Peer Overlay-Netzwerk ●
●
Gruppieren geographisch naher Knoten
Konsistenzdomäne-1
Aufgaben von Super-Peers ➢
Validierung von Commits
➢
Suche nach Replikaten
➢
Replikatverwaltung
Konsistenzdomäne-2 15
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
15/26
2. Verteilter Transaktionaler Speicher
Programmiermodell ●
Grundlegend wie bei TM-Systemen
●
Explizite Transaktionen
●
Explizite Allokation transaktionaler Daten
●
Konflikt-Monitor zur Unterstützung des Programmierers
16
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
16/26
2. Verteilter Transaktionaler Speicher
Programmiermodell ●
Beispiel:
int i=5; Obj obj = oss_malloc(sizeof(Obj), TM); oss_malloc TM bot(); bot printf(“Number %d lives\n”,i); obj.setPos(12,12); i = 8; eot(); eot
17
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
17/26
3. Experiemente & Leistungsdaten
18
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
18/26
3. Experimente und Leistungsdaten
Messumgebung ●
Cluster with 16 nodes each with two AMD Opteron CPUs (1,8 GHz), 2 GB RAM Debian Linux 64 (Kernel 2.6.24.3)
●
Switched Gigabit Ethernet network
●
Zusätzlich Grid'5000
19
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
19/26
3. Experimente und Leistungsdaten
Raytracer
20
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
20/26
3. Experimente und Leistungsdaten
Raytracer 140s 120s
time in s
100s 4 Kbytes 16 Kbytes 64 Kbytes
80s 60s 40s 20s 0s 1
2
4
8
16
Nodes 21
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
21/26
3. Experimente und Leistungsdaten
Wissenheim ●
Getestet mit 2 Knoten: ➢
Einer in Rennes, Frankreich
➢
Und einer in Düsseldorf
➢
Jeder steuert einen Avatar
●
WAN-Latenz: ~40ms round trip time
●
Geographische Distanz: ~750km
22
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
22/26
3. Experimente und Leistungsdaten
Wissenheim ●
Szenengraph verwaltet durch OSS
●
Synchronisierung: ➢
➢
Strenge Konsistenz: Änderungen am Szenengraph spekulative Transaktionen Schwache Konsistenz: Avatar-Bewegung nicht-transaktionale Zugriffe
23
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
23/26
4. Fazit & Ausblick
24
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
24/26
4. Fazit & Ausblick
Fazit ●
●
Transaktionaler Speicher (TM) ist nützlich für Thread-Synchronisierung auf Mehrkern-CPUs ➢
Pro:
weniger Sync.fehler, keine Deadlocks (keine Sperren)
➢
Contra: Rücksetzbarkeit nicht immer möglich
Verteilter TM ist interessant für Cluster und Grid-Systeme ➢
Pro:
transparente entfernte Zugriffe, strenge Konsistenz, vergleichsweise effizient
➢
Contra: Commit im Netz, Schattenkopien, Validierung
➢
➢
Open Source Code: http://www.xtreemos.eu
25
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
25/26
4. Fazit & Ausblick
Ausblick ●
Weitere: Anwendungen ➢
aus dem Bereich Geo- und BioInformatik
●
Skalierbare Validierungstechniken
●
Adaptives Cache-Management
●
Tests auf Grid'5000
26
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
26/26
Backup-Folien
27
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
27/26
2. Verteilter Transaktionaler Speicher
Adaptive Konflikteinheitsgröße ●
Millipages zur Vermeidung von False Sharing ●
Objektbasierte Zugriffserkennung per MMU
●
Aber vielen Seitenfehler & Caching-Effekt geht verloren Logischer Adressraum
Physikalischer Adressraum
0x4000 Seite 0x2000
Kachel 0x1000
0
0 28
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
28/26
2. Verteilter Transaktionaler Speicher
Adaptive Konflikteinheitsgröße ●
Bei einem Seitenfehler auf einer Millipage, alle Objekte/Millipages freischalten ➢
●
Entspricht Verhalten bei klassischer Konflikteinheitsgröße von 4 KB
Adaptives Verfahren: ➢
Aufzeichnen von Millipage-Zugriffsmustern
➢
dynamisches bündeln von Millipages in Gruppen
29
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
29/26
2. Verteilter Transaktionaler Speicher
Validierung ●
●
●
●
Nur ein Knoten kann zu einem Zeitpunkt validieren → implementiert durch „zirkulierendes“ Token Token beinhaltet globalen Commit-Zähler (64-Bit) Jeder Knoten speichert zuletzt gesehenen Commit in einem lokalen Commit-Zähler Bei Empfang eines Write-Sets: ●
●
Lokale Replikate invalidieren Prüfen, ob eine Seite aus dem Write-Set gelesen wurde, falls ja, laufende Transaktion abbrechen
30
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
30/26
2. Verteilter Transaktionaler Speicher
Commit ●
●
●
Anfordern des Tokens Nachdem erhalten, Write-Set an alle anderen schicken → First-Wins-Strategie ➢
Sender wartet nicht auf Bestätigungen → Token sofort freigeben
➢
Ggf. warten Knoten auf noch ausstehende Commits (Commit-Zähler)
Bem.: Keine verteilten Transaktionen, daher kein aufwändiger 2-Phasen Commit notwendig
31
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
31/26
2. Verteilter Transaktionaler Speicher
Super-Peer-Commit ●
●
●
●
Nur Super-Peers führen Commits durch → Token „zirkuliert“ nur zwischen wenigen Super-Peers Peers müssen Read- und Write-Set mit Commit-Request an ihren Super-Peer versenden Wartet ein Super-Peer auf das Token ➢
So validiert er anhängige Commit-Anfragen gegeneinander
➢
Allfällige Konflikte handelt er direkt ab
Empfängt er das Token erledigt er mehrere Commits
32
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
32/26
2. Verteilter Transaktionaler Speicher
Ultra-Peer-Commit ●
Ultra-Peer ➢
➢
➢
●
Super-Peers wählen einen Ultra-Peer Dieser übernimmt alle Commits → Versenden von Write-Sets Validiert alle Anfragen
Peers schicken Commit-Request mit Read- und Write-Set direkt an Ultra-Peer oder indirekt über ihren Super-Peer
●
Vorteil: Token wird überflüssig
●
Nachteil: potentieller Flaschenhals
33
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
33/26
4. Experimente und Leistungsdaten
Synthetisches Zugriffsmuster ●
Worst case: all Knoten inkrementieren eine shared Variable
●
Best case: all Knoten inkrementieren private Variablen
34
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
34/26
4. Experimente und Leistungsdaten
Synthetisches Zugriffsmuster global commit
35
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
35/26
4. Experimente und Leistungsdaten
Synthetisches Zugriffsmuster global/local commit
36
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
36/26
4. Experimente und Leistungsdaten
Kosten der Zugriffserkennung 2.5
x104
clock cycles
2
1.5
1
0.5
0 CPUs 37
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
37/26
3. Object Sharing Service
Zuverlässigkeit ●
Fail-Stop Fehlermodell
●
Fehlererkennung durch Commit Number (CNR):
●
●
●
Gespeichert im Token
●
wird mit jedem Commit-Paket inkrementiert,
●
jeder Knoten speichert CNR und verschickt diese mit jedem Paket .
Transaction History Buffer: ●
verpasste Write-Sets können bei Bedarf nachgefordert werden,
●
hierzu speichert jeder Knoten Write-Sets in einem Puffer.
Weitergehende Fehlertoleranz durch Grid Checkpointing Dienst
38
Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme
38/26
