Transactional Memory for Distributed Systems

Transkript

1 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 1 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 1/26

2 Vorschau 1. Transaktionaler Speicher 2. Verteilter Transaktionaler Speicher 3. Ergebnisse 4. Fazit & Ausblick 2 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 2/26

3 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 3 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 3/26

4 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 4 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 4/26

5 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 5 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 5/26

6 1. Transaktionaler Speicher Validierung Aufzeichnen spekulativer Lese- und Schreibzugriffe --> Read- und Write-Set Schreibzugriffe werden erst beim Commit sichtbar Validierung: Vergleiche überlappende noch laufende TAs T1 T2 W(x)=1 R(x)=0 Zeit Serialisierung Abbruch & Rücksetzung im Konfliktfall T1 W(x)=1 Zeit T2 R(x)=1 6 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 6/26

7 2. Transaktionaler Speicher Rücksetzbarkeit Speicherzugriffe müssen erkannt werden beim ersten Lese-/Schreibzugriff innerhalb einer Transaktion Bei Schreibzugriffen Schattenkopien anlegen, notwendig für Rücksetzbarkeit Reset Write-Set Shadowcopies Read-Set Betriebssystem- bzw. I/O-Aufrufe sind kritisch 7 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 7/26

8 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 8 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 8/26

9 2. Verteilter Transaktionaler Speicher 9 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 9/26

10 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 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

11 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

12 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

13 2. Verteilter Transaktionaler Speicher OSS-Architektur 13 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 13/26

14 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

15 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

16 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

17 2. Verteilter Transaktionaler Speicher Programmiermodell Beispiel: int i=5; Obj obj = oss_malloc(sizeof(obj),tm TM); bot(); printf( Number %d lives\n,i); obj.setpos(12,12); i = 8; eot(); 17 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 17/26

18 3. Experiemente & Leistungsdaten 18 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 18/26

19 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 ) Switched Gigabit Ethernet network Zusätzlich Grid' Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 19/26

20 3. Experimente und Leistungsdaten Raytracer 20 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 20/26

21 3. Experimente und Leistungsdaten Raytracer 140s 120s 100s time in s 80s 60s 4 Kbytes 16 Kbytes 64 Kbytes 40s 20s 0s Nodes 21 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 21/26

22 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

23 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

24 4. Fazit & Ausblick 24 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 24/26

25 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: 25 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 25/26

26 4. Fazit & Ausblick Ausblick Weitere: Anwendungen aus dem Bereich Geo- und BioInformatik Skalierbare Validierungstechniken Adaptives Cache-Management Tests auf Grid' Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 26/26

27 Backup-Folien 27 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 27/26

28 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 0 0x Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 28/26

29 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

30 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

31 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

32 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

33 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

34 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

35 4. Experimente und Leistungsdaten Synthetisches Zugriffsmuster global commit 35 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 35/26

36 4. Experimente und Leistungsdaten Synthetisches Zugriffsmuster global/local commit 36 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 36/26

37 4. Experimente und Leistungsdaten Kosten der Zugriffserkennung 2.5 x clock cycles CPUs 37 Michael Schöttner, Heinrich-Heine Universität Düsseldorf, Abteilung Betriebssysteme 37/26

38 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