Data Sharing im Cluster am Beispiel von Adabas Arno Zude, Adabas-Entwicklung Vortrag an der Universität Jena

Transkript

1 Data Sharing im Cluster am Beispiel von Arno Zude, -Entwicklung Vortrag an der Universität Jena 2. Februar 2006

2 Themen Cluster Services Data Sharing im Cluster mit / / 2 Software AG

3 Cluster Services Vortragender Informatik studiert an der TH (heute: TU) Darmstadt mit Diplom abgeschlossen Seit 1989 Software-Entwickler bei der Software AG in Darmstadt im Bereich DBMS Mainframe Software AG 1969 gegründet war das erste Produkt heute: in 60 Ländern vertreten > 2600 Mitarbeiter (> 750 in Deutschland) > 400 Millionen Euro Jahresumsatz spezialisiert auf Mainframes sowie Software-Integrationstechnologien Data Sharing im Cluster mit / / 3 Software AG

4 Ursprung I Cluster Services Entwicklung begann vor der Zeit von SQL Flexible Datenzugriffswege über Feldinhalte Datensatzbasierte Programmierschnittstelle in gewissem Maße auch mengenbasiert SQL-Schnittstelle über Zusatzprodukt oder Dritthersteller z.b. ODBC-, JDBC-Schnittstellen Nicht-SQL-Features Multiple Felder Periodengruppen Dirty Read u.a. Data Sharing im Cluster mit / / 4 Software AG

5 Ursprung II Cluster Services Reputation für hohe Performance hohe Stabilität geringen Administrationsaufwand Eingesetzt hauptsächlich von Banken Behörden Logistikunternehmen Universitäten Versicherungen Verwaltungen u.a. Data Sharing im Cluster mit / / 5 Software AG

6 Terminologie Cluster Services - und SQL-Terminologie im Vergleich: -Term (deutsch) Datenbank Datei (Daten)satz Feld Deskriptor ET BT -Term (englisch) database file record field descriptor ET (end transaction) BT (backout transaction) SQL-Term (englisch) database table row column index commit rollback Data Sharing im Cluster mit / / 6 Software AG

7 Konzepte I Cluster Services Datenbank enthält mehrere Files File wird durch File-Kontrollblock repräsentiert enthält Verwaltungsinformationen Datensätze stehen im Datenspeicher werden durch ISNs identifiziert ISN = Interne Satznummer Datensätze werden über Adresskonverter gefunden Dateninhalte werden über Index und zugeordnete ISNs gefunden File-Kontrollblock Adresskonverter Index Datenspeicher Data Sharing im Cluster mit / / 7 Software AG

8 Konzepte II Cluster Services Daten abspeichern und wiederfinden Transaktionskonzept ACID-Eigenschaften Mehrbenutzerfähigkeit Recovery Administration Data Sharing im Cluster mit / / 8 Software AG

9 Ursprung Cluster Services Cluster-Technologie von IBM für IBM Mainframes mit z/os (früher MVS, OS/390) Hardware und Software Ziele: Höhere Verfügbarkeit Bessere Performance Mittel: Mehrfachauslegung der Komponenten Verteilung der Arbeit Load Balancing Dienste für typische Cluster-Funktionalität (z.b. Cache, Lock) Data Sharing im Cluster mit / / 9 Software AG

10 Architektur Cluster Services z/os Sysplex Timer z/os A Lock List C z/os Cache Coupling Facility z/os B Shared Disks Shared Disks D Data Sharing im Cluster mit / / 10 Software AG

11 Architektur Cluster Services Sysplex Timer synchronisierte Zeitstempel auf allen verbundenen Systemen Schnelle Verbindungen zur Coupling Facility (CF) im Mikrosekundenbereich mal schneller als I/O gegen schnelle Plattenspeicher In vielen Fällen wartet die CPU auf Antwort von der CF Schnelle CF-Anfrage kostet etwa Tausend Instruktionen Das ist ca. ¼ bis ⅓ eines durchschnittlichen -Kommandos! Betrieb von mehreren Coupling Facilities möglich (empfohlen) Duplexing von CF-Strukturen möglich shared everything gemeinsamer Plattenspeicher closely coupled getrennter Hauptspeicher, gemeinsamer CF-Speicher Data Sharing im Cluster mit / / 11 Software AG

12 Services I Cluster Services Cross-System Coupling Facility (XCF) gab es auch schon vor der Coupling Facility Gruppenbildung automatische Benachrichtigung über Zu- und Abgänge zwangsweise Terminierung anderer Gruppenmitglieder Kommunikation Austausch von Nachrichten Broadcast Timeout Statusbeobachtung (in Cluster Services nicht verwendet) regelmäßige Lebenszeichen Data Sharing im Cluster mit / / 12 Software AG

13 Services II Cluster Services Cross-System Extended Services (XES) Strukturen in der Coupling Facility Cache-Struktur für den Betrieb eines gemeinsamen Caches effiziente Benachrichtigung über ungültig gewordene Datenelemente Lock-Struktur für die Synchronisation von Operationen auf gemeinsamen Ressourcen flexible Sperrprotokolle möglich Listen-Struktur (von Cluster Services nicht verwendet) für den Betrieb gemeinsamer Datenstrukturen z.b. Auftragswarteschlange weitere Dienste mehr administrativer Art Data Sharing im Cluster mit / / 13 Software AG

14 Cluster Services Ziele I Cluster Services Erweiterung eines komplexen Systems () in ein verteiltes, auf mehreren separaten Rechnern laufendes [noch komplexeres ] System ( Cluster Services) eine Datenbank mehrere Server, die auf der gemeinsamen Datenbank arbeiten Symmetrisch Jeder Knoten im Cluster kann grundsätzlich alles machen insbesondere auch Updates durchführen Hoch verfügbar Wenn ein Knoten ausfällt geplant oder ungeplant, arbeiten die anderen mit der vollen Funktionalität weiter Data Sharing im Cluster mit / / 14 Software AG

15 Cluster Services Ziele II Cluster Services Bessere Performance angemessener (nur leicht höherer) CPU-Verbrauch höherer Durchsatz gleiche oder kürzere Antwortzeiten gute Skalierbarkeit (bei Vergrößerung des Clusters) geringer Basis-Overhead möglichst lineare Durchsatzsteigerung Kompatibel mit Einzel- Cluster-Einsatz transparent für Anwendungsprogramme Anwendungsprogramme müssen nicht angepasst werden Stabil, robust, für Produktionseinsatz geeignet Data Sharing im Cluster mit / / 15 Software AG

16 Cluster Services Allgemeines Cluster Services Grundlegende Schwierigkeiten bei der Entwicklung von Cluster-Software: konsistenten gemeinsamen Status behalten Operationen auf gemeinsamen Ressourcen korrekt synchronisieren alle gemeinsamen Ressourcen identifizieren alle Operationen auf diesen Ressourcen identifizieren möglichst wenig Aufwand (zur Laufzeit) für Synchronisation Data Sharing möglichst wenig Interaktion zwischen den Knoten Je häufiger ein Knoten auf einen anderen warten muss: desto länger braucht er für seine Arbeit ( Performance) desto höher ist das Risiko, von einem Ausfall des anderen getroffen zu werden ( Verfügbarkeit) Recovery für Knotenausfall Kranken Knoten isolieren, damit nicht der ganze Cluster krank wird Data Sharing im Cluster mit / / 16 Software AG

17 Cluster Services Architektur Cluster Services z/os A CF z/os B Benutzer XES Lock Cache XES Benutzer Nukleus XCF Nukleus DB DB Work PLOG PLOG Work Seq. PLOG Data Sharing im Cluster mit / / 17 Software AG

18 Cluster Services Benutzer Cluster Services Jeder Benutzer wird beim ersten -Kommando an einen der Nuklei im Cluster gebunden normalerweise an einen lokalen Nukleus wenn das nicht geht, an einen entfernten (remote) Nukleus Zugewiesener Nukleus hält den Benutzerkontext z/os A z/os B z/os C Benutzer Benutzer Benutzer Cluster Nukleus A Cluster Nukleus C Data Sharing im Cluster mit / / 18 Software AG

19 Cluster Services Kommunikation Cluster Services Interne Anfragen gezielt an einen oder pauschal an alle anderen Knoten gerichtet Alle internen Anfragen mit Timeout versehen Drastische, aber einfache Fehlerbehandlung: unerwarteter Fehlercode abstürzen! Knoten weg ist erwarteter Fehlercode keine Antwort nicht antwortenden Knoten canceln! danach: Online Recovery Cluster Nukleus B Cluster Nukleus A? Cluster Nukleus C Data Sharing im Cluster mit / / 19 Software AG

20 Cluster Services Synchronisation I Cluster Services XES unterstützt flexible Sperrprotokolle hierarchische Sperren Benachrichtigung bei Sperrkonflikten Entzug gehaltener Sperren (nach Benachrichtigung) Cluster Services braucht aber nur einfache Standardsperren Lesesperre (shared) Schreibsperre (exclusive) shared erlaubt andere shared exclusive schließt alle anderen aus bei Sperrkonflikt: warten bis Sperre frei Abbruch der Sperranforderung Data Sharing im Cluster mit / / 20 Software AG

21 Cluster Services Synchronisation II Cluster Services Einphasige Synchronisation Beispiel: Änderung eines globalen Parameters Nukleus A Nuklei B, C,... PARM-Sperre erwerben (exklusiv, warten) Parameter lokal ändern Anfrage entgegennehmen Anfrage an alle anderen Knoten schicken Parameter lokal ändern Auf Antworten warten Antwort zurückschicken PARM-Sperre freigeben Data Sharing im Cluster mit / / 21 Software AG

22 Cluster Services Synchronisation III Cluster Services Zweiphasige Synchronisation Beispiel: Transaktionssynchronisation am Ende eines Online Save Nukleus A Nuklei B, C,... Phase 1 ETSYNC-Sperre erwerben (exklusiv, nicht warten) Keine neuen Transaktionen starten ET-Sync-Phase-1 Anfrage verschicken Auf Antworten warten Alte Transaktionen auslaufen lassen Anfrage entgegennehmen Keine neuen Transaktionen starten Alte Transaktionen auslaufen lassen Antwort zurückschicken A Data Sharing im Cluster mit / / 22 Software AG

23 Cluster Services Synchronisation III Cluster Services Nukleus A Nuklei B, C,... A Synchronisierter Zustand erreicht! Phase 2 Neue Transaktionen starten ET-Sync-Phase-2 Anfrage verschicken Auf Antworten warten ETSYNC-Sperre freigeben Anfrage entgegennehmen Neue Transaktionen starten Antwort zurückschicken Data Sharing im Cluster mit / / 23 Software AG

24 Cluster Services Cache I Cluster Services Cache in CF sitzt logisch gesehen zwischen Datenbank und lokalem Cache jedes Knoten Verschiedene Cache Policies: directory-only keine Daten im Cache store-through keine geänderten Daten im Cache store-in geänderte Daten im Cache benötigt Cast-out-Prozesse (Schreiben der geänderten Blöcke in die Datenbank) Cluster Services benutzt Store-in Cache schreibt nur geänderte Blöcke in den Cache Cluster Nukleus A Lokaler Cache DB CF Cache DB Cluster Nukleus B Lokaler Cache Data Sharing im Cluster mit / / 24 Software AG

25 Cluster Services Cache II Cluster Services Cache-Kohärenz Wird ein geänderter Block in den Cache geschrieben, werden veraltete Kopien in anderen lokalen Caches invalidiert Cache CF 724 Wenn Nukleus A seine geänderte Kopie von Block 724 in den Cache schreibt, wird die veraltete Kopie von Nukleus C automatisch als ungültig markiert. Nukleus B hat keine Kopie dieses Blocks und ist nicht betroffen. S y s t e m A Cache-Vektor Cache-Vektor Cache-Vektor? 724 Lok. Cache Nukleus A S y s t e m B Lokaler Cache Nukleus B S y s t e m C? Lok. Cache 724 Nukleus C Data Sharing im Cluster mit / / 25 Software AG

26 Cluster Services Cache III Cluster Services Block lesen mit Sperre Lesesperre kann für mehrere Blöcke gelten Kein anderer darf den Block ändern Beim Lesen aus dem Cache wird registriert, dass dieser Knoten eine Kopie des Blocks hat auch wenn der Block gar nicht im Cache ist Wird der Block später geändert, dient die Registrierung zur Invalidierung der veralteten Kopie Lesesperre erwerben (shared, warten) Block lokal finden und validieren OK? J N Block verwenden Lesesperre freigeben Block aus Cache lesen OK? J N Block aus DB lesen Data Sharing im Cluster mit / / 26 Software AG

27 Cluster Services Cache IV Cluster Services Block ändern mit Sperre Schreibsperre kann für mehrere Blöcke gelten Kein anderer darf den Block lesen Oft müssen mehrere logisch zusammengehörende Blöcke geändert werden Beim Design des Sperrprotokolls auf mögliche Deadlocks achten! Schreibsperre erwerben (exklusiv, warten) Block lokal finden und validieren OK? J N Block ändern Block in Cache schreiben Block aus Cache lesen OK? J N Block aus DB lesen Schreibsperre freigeben Data Sharing im Cluster mit / / 27 Software AG

28 Cluster Services Cache V Cluster Services Blocksperren sind teuer Entweder viele Sperren mit kleinem Wirkungsbereich z.b. Blocksperren viele Sperroperationen Oder wenige Sperren mit großem Wirkungsbereich z.b. hierarchische Sperren häufigeres Warten bei parallelen Zugriffen Blocksperren sind pessimistisch erzeugen Aufwand auch ohne parallele Zugriffe Block lokal finden Block validieren OK? N J Fertig Block aus Cache lesen J OK? Fertig N Block aus DB lesen Block lesen ohne Sperre Data Sharing im Cluster mit / / 28 Software AG

29 Cluster Services Cache VI Cluster Services Block lesen ohne Sperre möglich wenn Zielobjekt im Block schon anders gesperrt ist z.b. Sperre auf Datensatzebene Zielobjekt im Block nicht gesperrt zu werden braucht z.b. gewisse Verwaltungsinformationen Dirty Read Inkonsistenzen zwischen logisch zusammengehörenden Blöcken erkannt und kompensiert werden können z.b. Inkonsistenzen zwischen Adresskonverter und Datenspeicher Block lesen ohne Sperre nicht möglich wenn Inkonsistenzen zwischen logisch zusammengehörenden Blöcken nicht erkannt und kompensiert werden können z.b. im Index (wird hier nicht weiter behandelt) Data Sharing im Cluster mit / / 29 Software AG

30 Cluster Services Cache VII Cluster Services Block ändern ohne Sperre Zielobjekt im Block kann gesperrt sein z.b. Datensatz muss aber nicht gesperrt sein z.b. nächste freie Satznummer Das Schreiben des geänderten Blocks in den Cache schlägt fehl, wenn zwischen dem Validieren und dem Schreibversuch ein anderer Knoten den Block geändert und in den Cache geschrieben hat In diesem Fall den Block neu lesen und die Änderung wiederholen Block lesen und validieren Block ändern Block in Cache schreiben N OK? J Fertig Data Sharing im Cluster mit / / 30 Software AG

31 Cluster Services Cache VIII Cluster Services Geänderte Blöcke sofort in den Cache zu schreiben ist teuer für updateintensive Batch-Programme Viele Blöcke können häufig geändert werden z.b. wenn sie viele Datensätze enthalten Schreiben geänderter Blöcke in den Cache bis Transaktionsende verzögern (verzögertes Publizieren) Geänderte Blöcke sind weiterhin nicht gesperrt! Wenn ein geänderter Block von einem anderem Knoten auch geändert wurde, müssen alle Änderungen wiederholt werden Beschreibungen von allen noch nicht publizierten Änderungen merken Beim Wiederholen von Änderungen können auf einmal andere Blöcke betroffen sein z.b. kein Platz für neuen Satz im ursprünglich vorgesehenen Block Dabei können diese auch zu wiederholende Änderungen haben! Das verzögerte Publizieren von Änderungen ist kompliziert! Data Sharing im Cluster mit / / 31 Software AG

32 Cluster Services Cache IX Cluster Services Verzögertes Publizieren geänderter Blöcke kann scheinbare Inkonsistenzen zwischen zusammengehörenden Blöcken hervorrufen Beispiel: Datensatz mit gegebener ISN (Satznummer) lesen Paralleler Update ist möglich (dirty read) 1. Adresskonverter-Block lesen Datensatz ist angeblich in Block Nr Datenspeicherblock 4711 lesen Datensatz ist nicht im Block! 3. Andere Knoten auffordern, etwaige noch nicht publizierte Änderungen dieser beiden Blöcke in den Cache zu schreiben Auf Antworten warten 4. Operation neu versuchen Wenn sich die beteiligten Blöcke nicht geändert haben, sind sie wirklich inkonsistent zueinander Data Sharing im Cluster mit / / 32 Software AG

33 Konzepte Cluster Services Datenbank enthält mehrere Files File wird durch File-Kontrollblock repräsentiert enthält Verwaltungsinformationen Datensätze stehen im Datenspeicher werden durch ISNs identifiziert ISN = Interne Satznummer Datensätze werden über Adresskonverter gefunden Dateninhalte werden über Index und zugeordnete ISNs gefunden File-Kontrollblock Adresskonverter Index Datenspeicher Data Sharing im Cluster mit / / 33 Software AG

34 Cluster Services Recovery I Cluster Services Zurücksetzen von Transaktionen (Backout, Rollback) funktioniert wie im Einzel- Restart Recovery (Offline Recovery) funktioniert im Wesentlichen wie im Einzel- aber die Datensicherungssätze aller Cluster-Nuklei werden dynamisch in chronologische Reihenfolge gemischt Recovery nach Ausfall eines, aber nicht aller Knoten (Online Recovery) wird nach Ruhigstellen der Überlebenden auf Offline Recovery zurückgeführt an dieser Stelle Verbesserungsbedarf Data Sharing im Cluster mit / / 34 Software AG

35 Cluster Services Architektur Cluster Services z/os A CF z/os B Benutzer XES Lock Cache XES Benutzer Nukleus XCF Nukleus DB DB Work PLOG PLOG Work Seq. PLOG Data Sharing im Cluster mit / / 35 Software AG

36 Cluster Services Recovery II Cluster Services Archive Recovery funktioniert nach dem Mischen der Datensicherungssätze wie vorher alt Zwischenspeicher für Sicherungssätze neu PLOG PLOG PLOGs mischen PLOG Alle Sicherungssätze in chronologischer Folge Seq. PLOG Data Sharing im Cluster mit / / 36 Software AG

37 Cluster Services I Cluster Services Die schwierigsten Komponenten sind am Ende nicht unbedingt diejenigen, die die meisten Probleme bereiten Wenn man Dinge sorgfältig macht, kann man sie auch korrekt hinbekommen Pay attention to all details Performance ist wichtig Insbesondere bei Cluster-Software muss sie schon beim Design berücksichtigt werden Der Overhead für Kommunikation, Synchronisation und Data Sharing kann sehr leicht zu Performance-Problemen führen Es ist wichtig, die Architektur des Systems, auf dem man aufbaut, zu kennen und verstehen Auch sehr schnelle Operationen können problematisch sein Kommunikation mit der Coupling Facility im Mikrosekundenbereich ( mal schneller als ein I/O) aber: verbraucht mehr CPU-Zeit als ein I/O! Data Sharing im Cluster mit / / 37 Software AG

38 Cluster Services II Cluster Services Cluster-Software kann trotz des inhärenten Overheads den CPU- Verbrauch verringern, wenn sie Anfragen von entfernten (remote) Knoten in lokale Anfragen umwandelt Allein der Transport von Anfragen verbraucht CPU-Zeit Der erste Cluster-Services-Kunde verteilte seine Cluster-Nuklei auf 14 bzw. 17 Systeme im! Kunden benutzen ihre Software nicht immer so, wie der Hersteller es erwartet Das Ändern von Blöcken ohne Blocksperren und das Sammeln von Änderungen vor dem Publizieren im Cache haben sich bewährt obwohl die dafür notwendige Logik komplex ist obwohl schon einmal durchgeführte Änderungen gelegentlich wiederholt werden müssen Wenn die Knoten nicht miteinander reden können, funktioniert der ganze Cluster nicht passiert, wenn XCF nicht funktioniert (oder extrem langsam ist) Data Sharing im Cluster mit / / 38 Software AG

39 Cluster Services III Cluster Services Am problematischsten für die Verfügbarkeit eines Clusters ist der Fall, dass ein Knoten auf Anfragen nicht reagiert Risiko: Wenn ein Knoten krank ist, wird der ganze Cluster krank Wie kann man wissen, dass ein anscheinend toter Knoten tatsächlich tot ist?? Recovery ist erst dann erlaubt Das zwangsweise Terminieren eines nicht antwortenden Knotens ist im Prinzip richtig Das Wohl aller (des Clusters) geht über das Wohl eines Einzelnen (eines Knotens)... löst aber nicht das ganze Problem Auch zum Abstürzen braucht ein Knoten CPU-Zeit Was, wenn sein System überlastet ist?? Möglichkeiten zur Milderung (aufwendig): Kommunikation zwischen Knoten verringern gezieltes Recovery je nach fehlgeschlagener Operation Data Sharing im Cluster mit / / 39 Software AG

40 Cluster Services IV Cluster Services Lieber schnell abstürzen und dann schnell und zuverlässig Recovery durchführen... als viel Arbeit darin stecken, Abstürze unter günstigen Umständen zu vermeiden Höhere Verfügbarkeit heißt nicht unbedingt, dass ein Benutzer vom Absturz eines (seines) Knotens nichts mitbekommt,... als vielmehr, dass das System gleich danach weiterhin zur Verfügung steht Global synchronisierte Zeitstempel sind sehr nützlich für Cluster Data Sharing im Cluster mit / / 40 Software AG

41 Cluster Services V Cluster Services Die Versprechungen von Clustern, höhere Verfügbarkeit bessere Performance, sind einhaltbar, aber das ist nicht einfach Die höhere Komplexität erhöht auch die Fehleranfälligkeit und wirkt damit gegen das Verfügbarkeitsziel No single point of failure ist ein anspruchsvolles Ziel Man kann Prozessoren, Speicher, Platten, Netzwerkverbindungen, usw. mehrfach auslegen, aber was ist mit der Software?? den verwendeten Protokollen?? Data Sharing im Cluster mit / / 41 Software AG

42 Zum Schluss... Fragen?... Vielen Dank! Data Sharing im Cluster mit / / 42 Software AG

43 Data Sharing im Cluster mit / / 43 Software AG