Adabas Cluster Services
Werbung
Data Sharing im Cluster am Beispiel von Adabas Arno Zude, Adabas-Entwicklung Vortrag an der Universität Jena 2. Februar 2006 Themen Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Data Sharing im Cluster mit Adabas / 2.2.06 / 2 Software AG Vorstellung Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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 Adabas Mainframe Software AG 1969 gegründet Adabas 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 Adabas / 2.2.06 / 3 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Adabas Ursprung I 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 Adabas / 2.2.06 / 4 Software AG Adabas Ursprung II Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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 Adabas / 2.2.06 / 5 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Adabas Terminologie Adabas- und SQL-Terminologie im Vergleich: Adabas-Term (deutsch) Adabas-Term (englisch) SQL-Term (englisch) Datenbank database database Datei file table (Daten)satz record row Feld field column Deskriptor descriptor index ET ET (end transaction) commit BT BT (backout transaction) rollback Data Sharing im Cluster mit Adabas / 2.2.06 / 6 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Adabas Konzepte I 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 Index Adresskonverter Datenspeicher Data Sharing im Cluster mit Adabas / 2.2.06 / 7 Software AG Adabas Konzepte II Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Daten abspeichern und wiederfinden Transaktionskonzept ACID-Eigenschaften Mehrbenutzerfähigkeit Recovery Administration Data Sharing im Cluster mit Adabas / 2.2.06 / 8 Software AG Parallel Sysplex Ursprung Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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 Adabas / 2.2.06 / 9 Software AG Parallel Sysplex Architektur z/OS Sysplex Timer Lock A Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen z/OS C List Cache z/OS B Coupling Facility Shared Disks Shared Disks z/OS D Data Sharing im Cluster mit Adabas / 2.2.06 / 10 Software AG Parallel Sysplex Architektur Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Sysplex Timer synchronisierte Zeitstempel auf allen verbundenen Systemen Schnelle Verbindungen zur Coupling Facility (CF) im Mikrosekundenbereich • 10-100 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 10-15 Tausend Instruktionen • Das ist ca. ¼ bis ⅓ eines durchschnittlichen Adabas-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 Adabas / 2.2.06 / 11 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Parallel Sysplex Services I 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 Adabas Cluster Services nicht verwendet) • regelmäßige Lebenszeichen Data Sharing im Cluster mit Adabas / 2.2.06 / 12 Software AG Parallel Sysplex Services II Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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 Adabas Cluster Services nicht verwendet) • für den Betrieb gemeinsamer Datenstrukturen • z.B. Auftragswarteschlange weitere Dienste mehr administrativer Art Data Sharing im Cluster mit Adabas / 2.2.06 / 13 Software AG Adabas Cluster Services Ziele I Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Erweiterung eines komplexen Systems (Adabas) in ein verteiltes, auf mehreren separaten Rechnern laufendes [noch komplexeres ☺] System (Adabas 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 Adabas / 2.2.06 / 14 Software AG Adabas Cluster Services Ziele II Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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-Adabas Cluster-Einsatz transparent für Anwendungsprogramme Anwendungsprogramme müssen nicht angepasst werden Stabil, robust, für Produktionseinsatz geeignet Data Sharing im Cluster mit Adabas / 2.2.06 / 15 Software AG Cluster Services Allgemeines Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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 Adabas / 2.2.06 / 16 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Architektur z/OS A Lock Benutzer XE Adabas Nukleus S XES Cache XCF Benutzer Adabas Nukleus DB Work z/OS B CF DB PLOG PLOG Work Seq. PLOG Data Sharing im Cluster mit Adabas / 2.2.06 / 17 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Benutzer Jeder Benutzer wird beim ersten Adabas-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 Benutzer Cluster Nukleus A z/OS B z/OS C Benutzer Benutzer Cluster Nukleus C Data Sharing im Cluster mit Adabas / 2.2.06 / 18 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Kommunikation 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 Adabas / 2.2.06 / 19 Software AG Cluster Services Synchronisation I Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen XES unterstützt flexible Sperrprotokolle hierarchische Sperren Benachrichtigung bei Sperrkonflikten Entzug gehaltener Sperren (nach Benachrichtigung) Adabas 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 Adabas / 2.2.06 / 20 Software AG Cluster Services Synchronisation II Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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 Adabas / 2.2.06 / 21 Software AG Cluster Services Synchronisation III Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Zweiphasige Synchronisation Beispiel: Transaktionssynchronisation am Ende eines Online Save Nukleus A ETSYNC-Sperre erwerben (exklusiv, nicht warten) Keine neuen Transaktionen starten Phase 1 ET-Sync-Phase-1 Anfrage verschicken Nuklei B, C, ... Anfrage entgegennehmen Keine neuen Transaktionen starten Alte Transaktionen auslaufen lassen Auf Antworten warten Antwort zurückschicken Alte Transaktionen auslaufen lassen A Data Sharing im Cluster mit Adabas / 2.2.06 / 22 Software AG Cluster Services Synchronisation III Nukleus A Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Nuklei B, C, ... A Synchronisierter Zustand erreicht! Phase 2 Neue Transaktionen starten ET-Sync-Phase-2 Anfrage verschicken Anfrage entgegennehmen Neue Transaktionen starten Auf Antworten warten Antwort zurückschicken ETSYNC-Sperre freigeben Data Sharing im Cluster mit Adabas / 2.2.06 / 23 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Cache I 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) Adabas Cluster Services benutzt Store-in Cache schreibt nur geänderte Blöcke in den Cache Cluster Nukleus A Cluster Nukleus B Lokaler Cache Lokaler Cache CF Cache DB DB Data Sharing im Cluster mit Adabas / 2.2.06 / 24 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Cache II Cache-Kohärenz S y s t e m A CF Wird ein geänderter Block in den Cache geschrieben, werden veraltete Kopien in anderen lokalen Caches invalidiert Cache-Vektor ? 724 Lok. Cache Adabas Nukleus A Cache 724 S y s t e m B Cache-Vektor Lokaler Cache Adabas Nukleus B 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 C Cache-Vektor ? Lok. Cache 724 Adabas Nukleus C Data Sharing im Cluster mit Adabas / 2.2.06 / 25 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Cache III 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 Block aus Cache lesen OK? N J J Block verwenden OK? N Block aus DB lesen Lesesperre freigeben Data Sharing im Cluster mit Adabas / 2.2.06 / 26 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Cache IV 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 Block aus Cache lesen OK? N J J Block ändern OK? N Block aus DB lesen Block in Cache schreiben Schreibsperre freigeben Data Sharing im Cluster mit Adabas / 2.2.06 / 27 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Cache V 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? J Fertig N Block aus Cache lesen OK? J Fertig N Block aus DB lesen Block lesen ohne Sperre Data Sharing im Cluster mit Adabas / 2.2.06 / 28 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Cache VI 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 Adabas / 2.2.06 / 29 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Cache VII 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 Adabas / 2.2.06 / 30 Software AG Cluster Services Cache VIII Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Geänderte Blöcke sofort in den Cache zu schreiben ist teuer für update- intensive 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 Adabas / 2.2.06 / 31 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Cache IX 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. 4711 2. 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 Adabas / 2.2.06 / 32 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Adabas Konzepte 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 Index Adresskonverter Datenspeicher Data Sharing im Cluster mit Adabas / 2.2.06 / 33 Software AG Cluster Services Recovery I Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Zurücksetzen von Transaktionen (Backout, Rollback) funktioniert wie im Einzel-Adabas Restart Recovery (Offline Recovery) funktioniert im Wesentlichen wie im Einzel-Adabas 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 Adabas / 2.2.06 / 34 Software AG Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Cluster Services Architektur z/OS A Lock Benutzer XE Adabas Nukleus S XES Cache XCF Benutzer Adabas Nukleus DB Work z/OS B CF DB PLOG PLOG Work Seq. PLOG Data Sharing im Cluster mit Adabas / 2.2.06 / 35 Software AG Cluster Services Recovery II Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen Archive Recovery funktioniert nach dem Mischen der Datensicherungs- sätze wie vorher alt Zwischenspeicher für Sicherungssätze neu PLOG PLOG PLOG PLOGs mischen Alle Sicherungssätze in chronologischer Folge Seq. PLOG Data Sharing im Cluster mit Adabas / 2.2.06 / 36 Software AG Cluster Services Erfahrungen I Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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 (10-100 mal schneller als ein I/O) • aber: verbraucht mehr CPU-Zeit als ein I/O! Data Sharing im Cluster mit Adabas / 2.2.06 / 37 Software AG Cluster Services Erfahrungen II Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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 Parallel Sysplex! 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 Adabas / 2.2.06 / 38 Software AG Cluster Services Erfahrungen III Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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 Adabas / 2.2.06 / 39 Software AG Cluster Services Erfahrungen IV Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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 Adabas / 2.2.06 / 40 Software AG Cluster Services Erfahrungen V Vorstellung Adabas Parallel Sysplex Adabas Cluster Services Erfahrungen 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 Adabas / 2.2.06 / 41 Software AG Zum Schluss ... Fragen? ... Vielen Dank! Data Sharing im Cluster mit Adabas / 2.2.06 / 42 Software AG Data Sharing im Cluster mit Adabas / 2.2.06 / 43 Software AG
