Sysplex-Cluster-Technologien für Hochleistungs-Datenbanken

Sysplex-Cluster-Technologien für Hochleistungs-Datenbanken

16 Datenbank-Spektrum 3/2002

Wir stellen die Cluster-Architektur IBMParallel Sysplex und ihren Einsatz zurDatenbank- und Transaktionsverarbei-tung vor. Die Sysplex-Architektur ermög-licht die Nutzung von bis zu 32 Mehrpro-zessor-Großrechnern auf einem gemein-samen Datenbestand, ohne Modifikationbestehender Anwendungen. Eine wesent-liche Komponente ist die so genannteCoupling Facility (CF), in der allenRechnern zugängliche globale Daten-strukturen und globale Pufferbereicheverwaltet werden. Wir diskutieren, wiemit einer solchen »nahen« Rechnerkopp-lung leistungskritische Cluster-Aufgabenzur Synchronisation und Kohärenzkon-trolle gelöst werden können. Leistungsun-tersuchungen zeigen eine hohe Skalierbar-keit der Sysplex-Performance in prakti-schen Einsatzfällen.

1 Einführung

Transaktions- und Datenbankanwendun-gen in modernen Großunternehmen er-fordern Rechenleistungen, die von einemeinzelnen Rechner nicht mehr erbrachtwerden können. Kommerzielle Groß-rechner werden deshalb seit einiger Zeitim Rahmen von Clustern eingesetzt. In-ternetanwendungen und Web-Servicesverstärken diesen Trend, weil der Ab-stand zwischen Durchschnitts- und Spit-zenbelastung ständig größer wird.

Cluster leiden allgemein unter Skalie-rungsschwierigkeiten, insbesondere auf-grund von Synchronisationsproblemenbeim Zugriff auf gemeinsam genutzteDaten. Der IBM OS/390- bzw. z/OS-Sys-plex verfügt über eine Reihe neuartigertechnologischer Ansätze, die eine pro-blemlose Skalierung bis zu über einhun-dert CPUs ermöglichen. In dem vorlie-genden Beitrag werden einige dieserTechnologien erläutert.

Großrechner, besonders auch solcheder S/390-Architektur, sind schon immerführend beim Einsatz neuer Technologiengewesen. Eigenschaften wie z.B. SCSI,Caches, Direct Memory Access (DMA),Pipelining, Branch Prediction, virtuelleSpeicher, Speicherschutz, Multitasking,

Multithreading, Netzwerkfähigkeit undMultiprozessorfähigkeit (SMP) warenlange Großrechnern vorbehalten und dif-fundierten nur langsam in die PC-Welt.Welche technologischen Eigenschaftenwird ein PC, ein PDA oder ein Mobiltele-fon von übermorgen haben? Mit hoherWahrscheinlichkeit werden es wiederumEigenschaften sein, die wir schon heute inGroßrechnern vorfinden, wie Cluster-Technologien und die Eigenschaften desSysplex.

Im nächsten Abschnitt führen wir zu-nächst wesentliche Architekturmerkmalevon Clustern ein und diskutieren Alterna-tiven bezüglich der Interprozessor-Kom-munikation und Externspeicheranbin-dung. Abschnitt 3 gibt einen Überblick zuIBM Parallel Sysplex sowie den darin ent-haltenen spezifischen Cluster-Komponen-ten wie der so genannten Coupling Facility(CF). Abschnitt 4 diskutiert den Einsatzder CF zur globalen Sperrvergabe sowiezur Kohärenzkontrolle, zwei leistungskri-tischen Funktionen für Cluster. Abschlie-ßend werden einige Messergebnisse vor-gestellt, welche eine hohe Skalierbarkeitdes Parallel Sysplex ausweisen.

2 Cluster-Architekturen

2.1 Taxonomie

Die meisten kommerziellen Großrech-ner-Installationen basieren auf Mehrpro-zessorsystemen / Parallelrechnern bzw.Clustern. Kennzeichnend ist der Einsatzmehrerer Prozessoren in unmittelbarerräumlicher Nachbarschaft (typischerwei-se ein Maschinenraum) mit sehr schnel-len Interprozessor-Verbindungen. DieEinteilung der wichtigsten Cluster-Artenerfolgt aufgrund von zwei Kriterien: dieArt der Prozessor/Rechner-Kopplung so-wie der Externspeicherzuordnung.

Bezüglich der Prozessor/Rechner-Kopplung unterscheiden wir die drei inAbbildung 2.1 gezeigten Varianten, näm-lich enge, lose und nahe Kopplung. Beieng gekoppelten Parallelrechnern – auchals Symmetrischer Multiprozessor (SMP)bezeichnet – greifen mehrere CPUs aufeinen gemeinsamen Hauptspeicher zu,

der eine einzige Kopie (Instanz) des Be-triebssystems enthält. Bei einem lose ge-koppelten Parallelrechner verfügt jedeCPU über ihren eigenen Hauptspeicherund eine eigene Kopie des Betriebssys-tems. Eine Mischform ist die nahe Kopp-lung ( »closely coupled system«). Dies istim Wesentlichen ein lose gekoppelter Pa-rallelrechner, bei dem allen CPUs ein zu-sätzlicher, gemeinsam genutzter Speicher(Globaler Speicher) zur Verfügung steht,der in der Regel von einem eigenen Rech-ner verwaltet wird. Auf den globalenSpeicher und die dort verwalteten Datenbzw. globalen Datenstrukturen wird einsehr schneller Zugriff unterstützt (z.B.über eigene Maschinenbefehle), wodurchsich gegenüber der losen Kopplung auf-wendige Kommunikationsvorgänge überallgemeine nachrichtenbasierte Protokol-le einsparen lassen.

Die Verbindung der Rechner unterei-nander erfolgt durch ein Hochgeschwin-digkeitsnetzwerk. Dieses wird in der Re-gel als Crossbar Switch implementiert.Die Datenübertragungsrate derartigerSwitches liegt typischerweise im Bereichzwischen zehn und 100 GByte/s. Die Pa-rallelschaltung mehrerer Switches istmöglich.

Basierend auf den vorgestellten Artender Prozessorkopplung unterscheidet

Wilhelm G. Spruth, Erhard Rahm


Abb. 2.1: Arten der Prozessorkopplung


Datenbank-Spektrum 3/2002 17

man unter Berücksichtigung der Art desPlattenspeicherzugriffs im Wesentlichendrei Arten von Cluster-Architekturen:Shared Everything, Shared Nothing,Shared Disk [RAHM94]. Der einfachsteAnsatz ist das Shared-Everything-Mo-dell. Es wird durch einen symmetrischenMultiprocessor (SMP) implementiert, ba-siert also auf der engen Kopplung. Da allePlattenspeicherdaten im einzigen Haupt-speicher des SMP zwischengespeichertwerden, erfolgt ein gemeinsamer Platten-/Datenzugriff für alle Prozessoren. Syn-chronisationsaufgaben können über dengemeinsamen Hauptspeicher und das vonallen Prozessoren gemeinsam genutzteBetriebssystem und Datenbanksystemeinfach gelöst werden. Das Hauptprob-lem ist, dass SMPs selbst nur bis zu einerbegrenzten maximalen Anzahl von CPUsskalieren. Diese Grenze liegt für normaleDatenbankanwendungen beim derzeiti-gen Stand der Technik bei 16 CPUs.

Von Clustern im engeren Sinnespricht man daher nur bei lose oder nahgekoppelten Ansätzen nach dem Shared-Nothing- oder Shared-Disk-Modell. Üb-licherweise nutzen diese Cluster als Kno-ten (»nodes«) SMPs, so dass sie genaugenommen hybride Architekturen reprä-sentieren. In Abbildung 2.2 ist ein solchesCluster mit 4 Knoten und loser Kopplungdargestellt.

Beim Shared-Nothing-Modell besitztjeder Knoten einen Teil der Daten(bank),der auf Plattenspeichern untergebrachtist, auf die nur der betreffende Knoten zu-greifen kann, siehe Abbildung 2.3. DieArbeitslast wird den einzelnen Rechnernhäufig statisch zugeordnet. Durch die Da-ten-Partitionierung ist jedes System in derLage, auf seine Daten direkt zuzugreifen,ohne Synchronisation mit anderen Kno-ten. Ein derartiges Modell kann eine guteSkalierbarkeit liefern, solange eine sau-bere Aufteilung der gesamten Datenbankauf die einzelnen Knoten und deren Plat-tenspeicher möglich ist. Echtzeit-Work-load-Schwankungen können die Prozes-sor-Ressourcen über- oder unterfordern.Letzteres führt zu einer Leistungsver-schlechterung des Clusters.

Das Shared-Disk-Modell sieht vor,dass jedes System auf die vollständigeDatenmenge, die über die Plattenspeicherdes Clusters verteilt ist, zugreifen kann,siehe Abbildung 2.4. Der Vorteil diesesModells liegt in der Möglichkeit, die Ar-

beitslast dynamisch über alle Knoten desClusters zu verteilen. Als Hauptnachteilergibt sich eine potenziell schlechte Ska-lierbarkeit aufgrund des zur globalenSynchronisierung des Datenzugriffs er-forderlichen Aufwands. Hinzu kommtdie Notwendigkeit einer Kohärenzkon-trolle, da dieselben Daten in jedem Kno-ten im Hauptspeicher gepuffert und mo-difiziert werden können, wodurch Kopiender betreffenden Daten in anderen Kno-ten ungültig werden.

Bei naher Kopplung lassen sich dieAufgaben der Synchronisation und derKohärenzkontrolle über den globalenSpeicher sehr effizient lösen und somit dieSkalierbarkeit entscheidend verbessern.Dies ist der wesentliche Schlüssel zum Er-folg der Sysplex-Architektur. Zur Ab-grenzung von lose gekoppelten Shared-

Disk-Konfigurationen spricht man bei dernahen Kopplung auch gelegentlich von ei-ner Shared-Data-Architektur, da der ge-meinsame Datenzugriff nicht nur über diePlatten, sondern auch über den globalenSpeicher unterstützt werden kann (z.B.durch die dortige Pufferung von Daten-bankseiten).

2.2 Cluster-Implementierungen

Eine ganze Reihe von Herstellern liefernCluster für die Transaktionsverarbeitungund als Datenbankrechner. Bevor wir abdem nächsten Abschnitt näher auf dieSysplex-Architektur eingehen, sollennoch kurz zwei andere wichtige Hard-wareplattformen angesprochen werden,nämlich Sun Fire 15K Cluster und HP Su-perdome Cluster.

Abb. 2.2: Cluster mit 4 Knoten

Abb. 2.3: Shared-Nothing-Modell (partitionierte Daten)

Abb. 2.4: Shared-Disk-Modell (gemeinsame Daten)

speicher



Der Sun Fire 15K Cluster (Abb. 2.5)besteht aus bis zu 72 CPUs auf 18 als»System Boards« bezeichneten SMP-Knoten mit je 4 UltraSPARC III 900-MHz-Prozessoren (komplexere Anord-nungen sind möglich, z.B. für wissen-schaftliche Zwecke). Auf jedem SystemBoard befinden sich Hauptspeichermo-dule sowie Anschlüsse für den zentralenSwitch. Weiterhin enthält das SystemBoard E/A-Controller, welche eine Ver-bindung zu getrennten E/A-Boards her-stellen. Auf den E/A-Boards ist ein PCI-Bus implementiert, der SCSI-Adapter-karten für den Anschluss von Plattenspei-chern aufnehmen kann. Für Glasfaserver-bindungen kann dies der serielle Fibre-Channel-SCSI-Anschluss sein.

Vom Prinzip her verwirklicht dieseKonfiguration zunächst ein Shared-Nothing-Modell. Die Datenbank wirdpartitioniert und auf Gruppen von Plat-tenspeichern aufgeteilt, die den einzelnenKnoten fest zugeordnet sind. Wenn einKnoten auf einen Plattenspeicher zugrei-fen will, der an einen anderen Knoten an-geschlossen ist, muss dies über eine (auf-wendige) Kommunikation zwischen denbetroffenen Knoten abgewickelt werden.Um dies zu vermeiden, kann man allePlattenspeicher über einen weiterenSwitch mit allen Knoten verbinden, wievom HP Superdome Cluster unterstützt.

Der HP Superdome Cluster (Abb.2.6) besteht aus 16 als »Cell Boards« be-zeichneten SMP-Knoten mit je 4 CPUs,also insgesamt 64 CPUs. Ähnlich wiebeim Sun Fire 15K Cluster befinden sichHauptspeicher, E/A-Controller und An-schlüsse für den zentralen Switch auf je-dem Cell Board. Der zusätzliche FibreChannel Switch ermöglicht es jedemKnoten, auf jeden Plattenspeicher zuzu-greifen (Shared-Disk-Funktionalität).

Der in Abbildung 2.6 gezeigte FibreChannel Switch wird entweder durch dieangeschlossenen Knoten gesteuert oderer wird als Teil eines Storage Servers undeines Storage Area Networks (SAN) im-plementiert. Der Storage Server enthälteinen eigenen Rechner und realisiert z.B.einen dynamischen Plattenspeicher-Ca-che, Plattensteuerung sowie RAID- undNetzwerk-Optimierungen. Beispiele fürderartige Storage-Server-Produkte sindSymmetrix von EMC, Lightning vonHitachi und Shark von IBM.

3 Parallel Sysplex

Der Sysplex (System Complex) wurdevon IBM 1990 eingeführt; die hier disku-tierte Cluster-Variante Parallel Sysplexkam 1994 als Bestandteil der S/390- bzw.zSeries-Architektur auf den Markt. IBMbezeichnet die Hardware als S/390 oderzSeries und das Betriebssystem als OS/390 oder z/OS. zSeries und z/OS weisengegenüber S/390 und OS/390 eine zusätz-liche 64-Bit-Unterstützung auf; davonabgesehen sind die Unterschiede nicht so

groß. Die derzeitige zSeries-Implemen-tierung wird als z900 bezeichnet, einekleinere Variante z800 wurde kürzlich an-gekündigt.

Abbildung 3.1 zeigt den Aufbau derParallel-Sysplex-Architektur. Währenddie in Abschnitt 2.2 vorgestellten Clustervon Sun und HP eine lose Kopplung ver-wenden, handelt es sich beim ParallelSysplex um eine nah gekoppelte Cluster-Architektur nach dem Shared-Disk- bzw.Shared-Data-Modell. Der Sysplex be-steht aus den Prozessorknoten (»Syste-

Abb. 2.5: Sun Fire 15K Cluster

Abb. 2.6: HP Superdome Cluster

4fach SMP



me« genannt), gemeinsamen Plattenspei-chern (Shared Storage Devices), Netz-werk-Controllern und den Kern-Cluster-Technologie-Komponenten. Letztere um-fassen den (die) als »FICON Director«bezeichneten Switch(es), den Sysplex Ti-mer und die »Coupling Facility« (CF).Die Coupling Facility enthält den für dienahe Kopplung charakteristischen globa-len Speicher zur Realisierung globalerKontrollaufgaben und ist von allen Kno-ten schnell zugreifbar. Es werden bis zu32 Knoten unterstützt. Jeder Knoten stellteinen SMP dar und enthält maximal 16CPUs, insgesamt also maximal 512CPUs. Hinzu kommen noch 3 Ein-/Aus-gabeprozessoren (I/O-Off-Load-Prozes-soren, IOPs) pro Knoten. Derzeitige In-stallationen haben bis zu 100 CPUs. DieKnoten müssen nicht homogen sein, d.h.,ein Knoten kann aus einem z900-Rechnerund ein anderer aus einem älteren S/390-Rechner bestehen.

Zu den Sysplex-Komponenten wer-den spezifische Maschinenbefehle sowieBetriebssystemdienste zur Verfügung ge-stellt, mit denen eine effiziente Durchfüh-rung der Cluster-Aufgaben für alle Kno-ten erreicht wird, insbesondere zu Kom-munikation, E/A sowie für globale Steue-rungsaufgaben wie Synchronisation,Kohärenzkontrolle und Lastbalancie-rung. Diese Dienste werden in allgemei-ner Form realisiert und von unterschiedli-chen Software-Subsystemen, vor allemDatenbanksystemen, für den Cluster-Ein-satz verwendet. IBM hat dazu die wich-tigsten Subsysteme an das Arbeiten in-nerhalb eines Sysplex angepasst. EineAnpassung der Anwendungen an denSysplex ist in der Regel nicht erforderlichund i.Allg. auch nicht möglich. Sysplex-Unterstützung ist für folgende OS/390-Subsysteme verfügbar:

• Datenbanksystem IMS• Datenbanksystem DB2• Dateisystem VSAM • Transaktionsmonitor CICS

(CICSplex)• Transaktionsmonitor IMS TM• Web-Applikationsserver WebSphere • Communication Server• SAP System R/3

Wir stellen im Folgenden die wesent-lichen Cluster-Komponenten FICON-Switch, Sysplex Timer und die CouplingFacility näher vor.

3.1 FICON-Architektur für Kommunikation und E/A

Jeder Knoten kann mit bis zu 256 »Kanä-len« mit der Außenwelt verbunden wer-den, mit bis zu 100 Mbyte/s pro Verbin-dung. Die Verbindung der Systemesowohl untereinander als auch zu denPlattengeräten erfolgt über ein oder mehre-re FICON (FIbre CONnection)-Switches.Da jedes System 256 Ein-/Ausgabekanäleanbinden kann, hat diese Verbindungsstruk-tur die Aufgabe, bei 32 Systemen maximal256 * 32 = 2 13 Kanäle zu verwalten. Damitist jeder Knoten in der Lage, auf alle Plat-tenspeicher und alle anderen Knoten desSysplex direkt zuzugreifen (Shared-Disk-Modell). Die Steuereinheiten der Platten-speicher (Control Units) implementiereneine Storage-Server- und SAN-Funktiona-lität.

Die von IBM entwickelte FICON-E/A-Architektur basiert auf dem Kanal-Sub-system (channel subsystem) der ES/9000-E/A-Architektur. Diese integriertE/A-Prozessoren (IOPs), Kanäle sowiedie »Staging Hardware«. Die IOPs sor-gen für die Kommunikation zwischen denKnoten und den Kanälen. Diese führenzur Datenübertragung ein Kanalpro-gramm aus, wobei über die Steuereinhei-ten (Control Units) auf die Plattenspei-

cher zugegriffen wird. Die Staging-Hard-ware stellt die Kommunikationspfadezwischen den IOPs, den Kanälen unddem Rest des Systems zur Verfügung.

In der FICON-Architektur bildet derFICON-Switch (FICON Director) dieKerneinheit. Er implementiert eine Swit-ched-Point-to-Point-Topologie für S/390-E/A-Kanäle und Steuereinheiten. Ein FI-CON-Switch kann bis zu 60 Kanäle undSteuereinheiten dynamisch und nicht blo-ckierend (Crossbar Switch) über ihrePorts miteinander verschalten. Normaler-weise werden eine Reihe von FICON-Switches parallel genutzt. Entfernungenvon bis zu 3 km für optische Übertragun-gen sind möglich. Die zulässigen Entfer-nungen erhöhen sich beim Einsatz einerso genannten Extended-Distance-Laser-Link-Einrichtung auf 20, 40 oder 60 km.Dies ist für Unternehmen wichtig, die ausKatastrophenschutzgründen zwei ge-trennte Rechenzentren betreiben.

Die Kommunikation zwischen denKnoten und den Plattenspeichern erfolgtüber das FICON-Protokoll, der seriellenVersion des S/390-Kanalprotokolls. ZurKommunikation der Knoten untereinan-der wird das so genannte »Channel-to-Channel« (CTC)-Protokoll eingesetzt,normalerweise in einer Full-Duplex-An-

Abb. 3.1: Parallel Sysplex



ordnung. Hierbei betrachtet jeder senden-de Knoten den Empfänger als eine Ein-/Ausgabeeinheit. Der Empfänger simu-liert für diesen Zweck einen eigenen Typeiner S/390-Steuereinheit (Abb. 3.2). DasOS/390-Betriebssystem stellt einen Ba-sisdienst, die »Cross System CouplingFacility« (XCF) zur Verfügung, um übereine CTC-Verbindung eine Kommunika-tion mit einer anderen OS/390-Instanz in-nerhalb eines Sysplex zu bewerkstelligen.Dieser Dienst wird wiederum von Sub-systemen wie den DatenbanksystemenDB2 und IMS für den Nachrichtenaus-tausch eingesetzt.

3.2 Sysplex Timer

Die Anforderungen an einen Cluster be-züglich Genauigkeit und Konsistenz desTaktes in den einzelnen Teilsystemen(Knoten) werden durch einen Sysplex Ti-mer erfüllt. Dieser stellt eine externe Zeit-referenz (ETR, External Time Reference)dar. Der Timer generiert die synchroni-sierte Tageszeit (Time Of Day, TOD) füralle Knoten. Von der ETR werden 3 Sig-nale (oscillator signal, on-time signal,data signal) für die Clock-Synchronisati-on erzeugt und an die Knoten des Sysplexgesendet. Der Sysplex Timer kann umge-kehrt auch Informationen aus einer exter-nen Quelle erhalten (z.B. Time Code Re-ceiver). Im Falle eines Sysplex-Timer-Ausfalls arbeiten die Knoten weiter undverwenden ETR aus einem lokalen Mo-dul. Beim Wiederanschluss des Timersbesteht je nach ETR-Parameter die Mög-lichkeit der Resynchronisation.

Datenbanksysteme wie DB2 und IMSnutzen den Sysplex Timer u.a. für dieKennzeichnung ihrer Log-Einträge, mitdenen Änderungen an Datenbankobjek-ten für Recovery-Zwecke protokolliertwerden. Die Log-Sätze werden zunächstin jedem System in eine separate Log-Da-tei geschrieben; über die synchronisiertenZeitstempel lässt sich nun ein Mischendieser Dateien zu einer globalen Log-Da-tei vornehmen, in der alle Änderungen inder Cluster-weit chronologischen Rei-henfolge angeführt sind. Damit könnenim Fehlerfall die an verschiedenen Rech-nern erfolgten Änderungen eines Daten-bankobjektes oder einer ganzen DB-Platte vollständig rekonstruiert werden[RAHM94].

3.3 Coupling Facility (CF)

Die wichtigste Komponente des Sysplexist die Coupling Facility (CF). Sie setztsich physisch aus S/390-Hardware mit ei-genem Prozessor (SMP) mit einem relativgroßen Hauptspeicher (mehrere Giga-bytes) sowie speziellem Mikrocode (Con-trol Code) zusammen. Die Kopplung mitanderen S/390-Prozessoren erfolgt überserielle Glasfaserverbindungen mit einerÜbertragungsrate von 100 MByte/s (HighSpeed Coupling Links). Auf der CF läuftkein Standard-S/390-Betriebssystem, unddie vielfältigen Steuerfunktionen der CFsind für den Systemprogrammierer auchnicht direkt verfügbar. Aus Leistungs- undVerfügbarkeitsgründen können innerhalbeines Sysplex zwei oder mehrere Coup-ling Facilities eingesetzt werden.

Jeder Knoten sowie die CF selbst ent-halten eine »Coupling Support Facility«.Diese bewerkstelligt die Kommunikationund den Datenaustausch zwischen Knotenund CF. Die Coupling Support Facility be-steht aus je einer Glasfaserverbindung (100MByte/s), einem dedizierten Link-Prozes-sor für die Verarbeitung des (proprietären)Übertragungsprotokolls und einer Erweite-rung des S/390-Maschinenbefehlssatzes.Die zusätzlichen Maschinenbefehle reali-sieren die nahe Kopplung zwischen Knotenund CF und ermöglichen allen Knoten denZugriff auf Inhalte in CF-Datenstruktu-ren. Das Kommunikationsprotokoll wurdefür eine besonders geringe Latenzzeit op-timiert, welches synchrone Zugriffe einesjeden Knotens auf die CF ermöglicht.Synchron bedeutet, dass ein auf einemKnoten laufender Prozess während einesZugriffs auf die Coupling Facility blo-ckiert; es findet kein Prozesswechsel undkein Übergang »User-Status – Kernel-Status« statt. Die Zugriffsgeschwindig-keit liegt im Mikrosekundenbereich undist somit weitaus effizienter als die Kom-munikation über allgemeine Protokollebei loser Rechnerkopplung.

Die nahe Kopplung über die CF wirdfür die leistungskritischen Kontrollaufga-ben in Shared-Disk-Clustern genutzt, umdurch die effiziente Realisierung einehohe Skalierbarkeit zu erreichen. Diesbetrifft die globale Synchronisation überSperrverfahren (Locking), die Kohärenz-kontrolle der Pufferinhalte mit schnellemAustausch geänderter Daten zwischenden Knoten sowie die flexible Lastvertei-lung. Entsprechend werden spezifischeFunktionen (Maschinenbefehle) für Lo-cking, Caching und Queuing sowie zuge-schnittene Datenstrukturen im Haupt-speicher der CF bereitgestellt. Die CF-Hauptspeicher-Ressourcen können dyna-misch partitioniert und einer der CF-Strukturen zugewiesen werden. Innerhalbderselben CF sind mehrere CF-Struktu-ren desselben oder unterschiedlichenTyps möglich. Die auf diesen Strukturenbereitgestellten Funktionen bzw. Cluster-Protokolle repräsentieren drei Verhal-tensmodelle:

• Lock-Modell: Es unterstützt feingra-nulares, globales Locking für hohePerformance und eine Signalisierungvon Zugriffskonflikten.

• Cache-Modell: Es liefert eine globaleKohärenz-Steuerung für die verteil-ten Pufferinhalte der einzelnen Kno-ten sowie einen globalen Puffer in derCF (Shared Data Cache).

• Queue-Modell: Es implementiert ei-nen umfangreichen Satz an Queuing-Konstrukten für die Verteilung vonArbeitslasten, zur Realisierung einerschnellen Nachrichtenübertragung(Message Passing) sowie für die Ver-waltung globaler Status-Informa-tionen. Ein Beispiel für Letzteres istdie Verwaltung globaler Sicherheits-rechte.

Abbildung 3.3 zeigt die Anbindung derKnoten an die CF und die dort verwalte-ten globalen Datenstrukturen. Der Zugriff

Abb. 3.2: Channel-to-Channel-Verbindung



erfolgt dabei nicht nur von den Systemenauf die CF, sondern die CF kann auch di-rekt (ohne Involvierung des Betriebs-systems) auf bestimmte Hauptspeicher-inhalte der Systeme mit Bit-Vektorenzugreifen und ändern. Solche Bit-Vekto-ren existieren für jede logische Verbin-dung zu einer CF-Datenstruktur und er-lauben z.B. die schnelle Signalisierungvon Zugriffskonflikten (s.u.).

Im nächsten Abschnitt betrachten wirdie Nutzung der CF-Lock- und Cache-Strukturen zur Realisierung der Cluster-weiten Synchronisation (Locking) undKohärenzkontrolle.

4 Locking und Kohärenzkontrolle mit der CF

Die Datenbankverarbeitung in Shared-Disk-Konfigurationen erfordert die glo-bale Synchronisation der Transaktionenbeim Zugriff auf die allen Rechnern zu-gänglichen Datenbankobjekte. Hierzuwird ein globales Sperrprotokoll unterBeteiligung der DBS-Subsysteme allerRechner benötigt. Das zweite wesentli-che Shared-Disk-Problem ist die Kohä-renzkontrolle, da jedes DBS-SubsystemKopien derselben DB-Seiten in seinemHauptspeicher puffern und ändern kann.Hierzu ist es erforderlich, veraltete Kopi-en zu erkennen und Transaktionen jedesKnotens stets die aktuellsten Daten zurVerfügung zu stellen. Diese Problemewerden durch Änderungstransaktionenverursacht; bei reinen Leselasten (z.B.Data-Warehouse-Analysen) gibt es we-der ein Synchronisations- noch ein Kohä-renzproblem.

Für die Lösung dieser Aufgaben wur-de für lose und nah gekoppelte Shared-Disk-DBS eine Reihe von leistungsfähi-gen Protokollen entwickelt [RAHM94].Insbesondere kann die Kohärenzkontrolleweitgehend mit der globalen Synchroni-sation zur Reduzierung zusätzlicherKommunikationsvorgänge kombiniertgelöst werden. Zur Einsparung von Nach-richten zur globalen Sperrbehandlungwurden ebenfalls Techniken entwickelt,um möglichst viele Sperren rechnerlokalentscheiden zu können. Dennoch zeigtsich für viele Anwendungslasten, dass beiloser Kopplung eine hohe Kommunikati-onsbelastung durch die Nachrichten ver-ursacht wird und dieser Aufwand typi-scherweise mit der Knotenanzahl an-

steigt, so dass die Skalierbarkeit entspre-chend begrenzt wird. Im Sysplex wirddurch die Coupling Facility sowohl dieglobale Sperrbehandlung als auch die Ko-härenzkontrolle durch die zentralen CF-Strukturen wesentlich unterstützt, wo-durch die Voraussetzung für hohe Ska-lierbarkeit und Performance des Shared-Disk-Clusters geschaffen wird.

4.1 Locking mit der CF

Die globale Sperrbehandlung im Sysplexerfolgt in Zusammenarbeit der CF, des OS/390-Betriebssystems sowie der auf jedemSystem laufenden DBS-Instanzen (bzw. an-deren Subsystemen, die eine globale Syn-chronisation benötigen). Wie in Abbildung4.1 für das Datenbanksystem DB2 gezeigt,läuft auf jedem Rechner ein lokaler Lock-Manager (LLM), der für die Sperrbehand-lung aller Transaktionen und Prozesse desjeweiligen Rechners zuständig ist. In derCF-Lock-Struktur wird eine zentrale Sperr-tabelle verwaltet, auf die alle LLMs zugrei-fen, um eine schnelle systemweite Synchro-nisation konkurrierender Datenzugriffe zuerreichen. Diese Zugriffe erfolgen synchronüber eine als »Cross System ExtensionServices” (XES) bezeichnete OS/390-Komponente, die u.a. spezielle Maschi-nenbefehle zum Setzen und Freigeben

von globalen Sperren in der CF-Sperrta-belle verwendet. Der wesentliche Vorteildieser Konfiguration liegt darin, dass allekonfliktfreien Sperranforderungen, dietypischerweise über 99% aller Sperrenbetreffen, über die zentrale Sperrtabellemit minimaler Verzögerung behandeltwerden können. Nur solche Sperranfor-derungen, für die zwischen verschiede-nen Rechnern ein Konflikt auftritt, erfor-dern die Synchronisierung zwischen denbetroffenen Rechnern. Hierzu erfolgt einNachrichtenaustausch über das erwähnteCTC-Protokoll sowie die OS/390-Kompo-nente XCF.

Die CF verwaltet in der zentralenSperrtabelle eine reduzierte Sperrinfor-mation mit einer festen maximalen An-zahl n von Sperreinträgen. Jeder Eintragder CF-Sperrtabelle bezieht sich nichtnotwendigerweise auf ein einzelnes Ob-jekt, sondern auf eine Hashklasse, d.h.,jedes zu sperrende Objekt ist über eineHashfunktion auf einer der n Hashklassenabzubilden. Zum Beispiel haben Sperrenin IMS-Datenbanken bis zu 19 Bytes(152 Bits) lange Bezeichner. Da eineSperrtabelle mit 2152 Einträgen für denHauptspeicher viel zu groß (und sehrdünn belegt) wäre, erfolgt eine Abbil-dung in eine Hashklassen-Bezeichnungvon 18 Bit. Der Adressraum für die Lock-

Abb. 3.3: Anbindung der Systeme an die Coupling Facility



Einträge kann somit über eine CF-Sperr-tabelle von 218 = 262.144 Einträge abge-deckt werden. Dabei wird unterstellt,dass jeder Knoten den gleichen Hashing-Algorithmus benutzt. Da die n EinträgeHashklassen repräsentieren, können »un-echte Konflikte« auftreten, wenn zweiSperrbezeichner in dieselbe Hashklasseabgebildet werden. Die Häufigkeit sol-cher Kollisionen ist eine Funktion derSperrtabellengröße. Diese kann vom Sys-temprogrammierer dynamisch verändertwerden, um die Menge der falschen Kon-flikte zu minimieren. Eine Faustregel be-sagt, dass nicht mehr als 1% der Sperran-forderungen zu Konflikten führen sollte.

Abbildung 4.2 verdeutlicht für eineBeispielkonfiguration mit drei Systemenden Aufbau der globalen Sperrtabelle inder CF sowie der lokalen Sperrtabellender LLMs. Die zentrale Sperrinformationwird nicht auf Ebene einzelner Transakti-onen, sondern nur für ganze Systeme ge-führt. Das Sperrprotokoll unterscheidetdabei wie üblich Lesesperren, welche proObjekt gleichzeitig an mehrere Systemegewährt werden können, und exklusiveSchreibsperren. Die CF-Sperrtabelle(oberer Teil in Abb. 4.2) verwendet hierzupro Sperreintag (Hashklasse) zwei Fel-der: Für den Fall einer exklusiv gesetztenSperre (EXC) enthält das erste Feld dieKnotenadresse des Besitzers. Ein Bit-Vektor mit 32 Bit Länge nimmt das zwei-te Feld ein. Jedes Bit dieses Vektors zeigtan, welcher der (maximal möglichen) 32Rechner eine Lesesperre erworben hat(Shared, SHR=1) bzw. ob keine solcheSperre vorliegt (SHR=0). Das Beispielweist somit aus, dass System 1 exklusiverBesitzer von allen Objekten der Hash-klasse i ist und dass Systeme 2 und 3 Le-seberechtigungen für alle Objekte derHashklasse k besitzen.

Wie im unteren Teil von Abbildung4.2 gezeigt, bestehen die lokalen Sperrta-bellen der LLMs aus drei Teilen: lokaleSperrzustände (Local Lock State), ob-jektspezifische Sperranforderungen loka-ler Transaktionen (Local Queue) und glo-bale Warteschlangen mit objektspezifi-schen Sperranforderungen mehrererRechner (Global Queue). Im lokalenSperrstatus führt der LLM seine Kenntnisvom Zustand der CF-Sperreinträge be-züglich der Hashklassen: »0« bedeutetkeine Kenntnis (Eintrag wird möglicher-weise von keinem anderen Knoten be-

nutzt), »S« (Shared-Kenntnis, LLM hatLeserecht), »E« (exklusive Nutzungdurch den eigenen Knoten) oder »Gx«(ein anderer Knoten x besitzt exklusiveRechte und kontrolliert die Sperrvergabeim Sysplex). Im Beispiel weisen die loka-len Einträge entsprechend der CF-Sperr-einträge System 1 als exklusiven Besitzer

der Hashklasse i und Systeme 2 und 3 alsleseberechtigt für Hashklasse k aus. Derzweite Bereich der lokalen Sperrtabellenenthält Informationen zu den spezifi-schen Objekten und lokal laufendenTransaktionen bzw. Prozessen, welcheSperren besitzen oder darauf warten. Sobedeutet der Eintrag »(A, i, P1, E)« in

Abb. 4.1: Kommunikationsstruktur zur globalen Sperrbearbeitung im Sysplex

Abb. 4.2: Zentrale CF-Sperrtabelle und lokale Sperrtabellen der LLM



System 1, dass der lokale Prozess P1 dieSperre zu Objekt A, welche zur Hashklas-se i gehört, im exklusivem Modus besitzt.Der dritte Bereich (Global Queue) ist nurrelevant für Objekte, an denen ein system-übergreifender Sperrkonflikt in der CF er-kannt wurde und der LLM zur Konflikt-auflösung mit anderen LLMs zusammen-arbeiten muss. Hierzu werden in demSperrbereich die Sperranforderungen deranderen Rechner abgelegt, um diese globalsynchronisiert abzuarbeiten.

Mit diesen Datenstrukturen läuft dieSperrbehandlung für Objekt O folgender-maßen ab:

• Hat der LLM für die O zugeordneteHashklasse j kein Besitzrecht (Ein-trag »0« im lokalen Sperrstatus), wirdein Sperraufruf für j mit dem ge-wünschten Zugriffsmodus (E oder S)an die CF gerichtet. Liegt kein Kon-flikt vor, was in der Mehrzahl der Fäl-le zu erwarten ist, wird die Sperre anden LLM gewährt und der globaleSperreintrag für j entsprechend ange-passt. Diese globale Sperrgewährungerfolgt aufgrund der nahen Kopplungsehr schnell (Mikrosekunden). DerLLM passt den lokalen Sperrstatus anund gewährt der Transaktion die an-geforderte Sperre.

• Sperranforderungen, zu deren Hash-klasse der LLM ein exklusives Be-sitzrecht hat, können lokal – ohne Zu-griff auf die zentrale CF-Sperrtabelle– behandelt werden. Dies ermöglichteine noch schnellere Sperrbearbei-tung und reduziert die Auslastung derCF. Im Beispiel von Abbildung 4.2kann so System 1 alle Lese- undSchreibsperranforderungen zu Ob-jekten der Hashklasse i (also nicht nurfür Objekt A) lokal behandeln.

• Analog können lesende Sperranfor-derungen, zu deren Hashklasse derLLM ein S-Besitzrecht hat, ohne Ver-zögerung lokal bewilligt werden. ImBeispiel von Abbildung 4.2 könnendie Systeme 2 und 3 alle Leseanfor-derungen bezüglich Hashklasse k ohneerneuten CF-Zugriff behandeln.

• Bei globalen Sperrkonflikten stelltdie Coupling Facility sicher, dass nurdiejenigen Knoten von dem Auflö-sungsprozess betroffen sind, die vor-her ein Interesse angemeldet haben

(in der zentralen Sperrtabelle ver-merkt). Dabei erhält einer der betei-ligten LLMs die Verantwortung zurAuflösung des globalen Konflikts(i.Allg. der Knoten, welcher das ex-klusive Besitzrecht zur Hashklassehat bzw. möchte). Über ein nachrich-tenbasiertes Protokoll erfolgt einAustausch der spezifischen Sperran-forderungen sowie deren schrittweiseAbarbeitung durch die beteiligtenRechner.

Eine detaillierte Beschreibung der Sperr-behandlung ist in [ISJ97] zu finden.Wichtig ist, dass typischerweise mehr als99% der Sperranforderungen rechner-lokal oder sehr schnell über die CF be-handelt werden können und nur in denwenigen Fällen eines gleichzeitigen rech-nerübergreifenden Sperrkonflikts ein auf-wendigeres nachrichtenbasiertes Proto-koll abläuft.

Das skizzierte Basisprotokoll steht al-len Subsystemen der Knoten zur Verfü-gung, lässt sich jedoch auf spezifische Er-fordernisse anpassen, z.B. bezüglich derObjektnamen und Sperrgranularitäten. Sowird im relationalen DatenbanksystemDB2 ein hierarchisches Sperrverfahren(Explicit Hierarchical Locking, EHL)eingesetzt, bei dem einerseits feingranu-lare Sperren auf Satz- und Seitenebenezur Reduzierung von Sperrkonflikten un-terstützt werden, andererseits grobe Gra-nulate wie Tabellen oder Segmente, umwenig Sperranforderungen stellen zumüssen. Dabei erfolgt die Sperrbehand-lung mit der Coupling Facility mit mög-lichst grober Granularität. Der lokaleLock-Manager (LLM) verwaltet alleSperren auf der feinsten Granularitätsstu-fe, wobei die gröberen Granulate mit An-wartschaftssperren (intention locks) be-legt werden. Damit können einerseits vie-le Sperren lokal behandelt werden, wennder betreffende LLM das exklusive oderLeserecht für ein großes Granulat besitzt.Kommt es zu einem Konflikt, kann durchdynamische Verfeinerung der Sperrgra-nularität dennoch erreicht werden, dassnur im Falle tatsächlicher Konflikte aufder feinsten Ebene Sperranforderungenlängere Zeit blockiert werden.

Im Beispiel von Abbildung 4.3 hatTransaktion 1 auf Knoten 1 auf einemganzen Segment eine explizite Sperre, diein der CF-Sperrtabelle vermerkt ist (nicht

gezeigt). Damit sind in Knoten 1 alle Sei-ten und Sätze dieses Segmentes implizitgesperrt und Zugriffe darauf innerhalbvon Knoten 1 können ohne Kommunika-tion mit der CF (also lokal) behandeltwerden. Die entsprechenden Zugriffewerden dennoch vom LLM vermerkt,z.B. dass Transaktion 1 die Sätze 3 und 4in den Seiten 1 bzw. 2 referenzierte. Imunteren Teil von Abbildung 4.3 ist die Si-tuation gezeigt, nachdem eine neueTransaktion 2 auf Knoten 2 eine Sperrefür Datensatz 5 angefordert hat. DieSperranforderung geht an die CF, welcheKnoten 2 daraufhin vom Konflikt mitKnoten 1 informiert. Da kein tatsächli-cher Konflikt zwischen den beiden Trans-aktionen besteht, kann der Konflikt durcheine Herabstufung und Verfeinerung derGranularität behoben werden. Dies han-deln die beiden Knoten über einen Nach-richtenaustausch (CTC-Kommunikati-on) untereinander aus. Transaktion 1 er-hält eine explizite Sperre mittlerer Granu-larität für Seite 1 und eine expliziteSperre feiner Granularität für Datensatz4. Transaktion 2 erhält eine expliziteSperre für Datensatz 5. Das Segment unddie Seite 2 werden mit einer Anwart-schaftssperre belegt, welche anzeigt, dassmehrere unterschiedliche Knoten explizi-te Sperren des Segments bzw. der Seitebesitzen.

4.2 Kohärenzkontrolle

Die Cache-Funktion der Coupling Facili-ty wird zur Kohärenz-Steuerung der Da-tenbankpuffer in den Hauptspeichern derSysplex-Knoten verwendet. Wir erläuterndie Vorgehensweise am Beispiel vonDB2; die CF-Funktionalität zur Kohä-renzkontrolle wird jedoch auch von ande-ren Subsystemen genutzt.

Eine allgemeine, wenngleich ineffizi-ente Lösungsmöglichkeit zur Kohärenz-kontrolle bei loser Kopplung (also ohneCF) ist ein so genannter Broadcast-Inva-lidierungsansatz, der in Abbildung 4.4 il-lustriert ist. Dabei wird die Änderung ei-ner Seite in einem Knoten (im Beispiel A)am Ende der ändernden Transaktion übereine Broadcast-Nachricht allen Knotenmitgeteilt. Diese können daraufhin ältereVersionen der betreffenden Seite in ihremPuffer invalidieren und somit den Zugriffdarauf umgehen. Der ändernde RechnerA schreibt vor Freigabe der exklusivenSperre die geänderte Seite auf Extern-



speicher (»cast-out«), so dass danach alleKnoten auf die aktuelle Version der Seitezugreifen können. Nachteile der Vorge-hensweise sind hoher Nachrichtenauf-wand durch die Broadcast-Invalidierung,der mit der Knotenanzahl zunimmt (ge-ringe Skalierbarkeit), sowie hoher I/O-Aufwand für das Cast-out auf die langsa-men Plattenspeicher. Die Nachteile wer-den abgemildert in einer Variante des An-satzes, bei der die Sperre für eine geän-derte Seite über Transaktionsgrenzen hin-weg gehalten wird und die Freigabe derSperre und das Cast-out erst erfolgen,wenn ein Konflikt durch einen anderenKnoten vorliegt.

Eine effiziente Lösung zur Kohärenz-kontrolle wird jedoch erst durch Einsatzder CF erreicht. Hierbei werden die CF-Cache-Strukturen verwendet, die auszwei Teilen bestehen: Directory-Einträgeund optional globale Pufferbereiche zurAufnahme von Datenseiten bzw. -blöcken.Ein Directory-Eintrag existiert für jedenDatenblock, der sich entweder in dem loka-len Puffer irgendeines Knotens oder in ei-nem globalen Puffer der CF befindet. JederDirectory-Eintrag enthält einen Hinweisdarauf, welche Knoten momentan Kopiendes entsprechenden Datenblocks besitzen.In dem geschützten Bereich des Hauptspei-chers eines jeden Knotens ist daneben einBit-Vektor definiert, wobei ein Bit zu jedemlokalen Pufferrahmen existiert.

Beim Lesen einer noch nicht lokal ge-pufferten Datenseite durch eine DB2-In-stanz an Knoten B wird der Aufruf zu-nächst an die CF gerichtet, um den Blockggf. sehr schnell vom globalen Puffer ein-zulesen. Falls die Seite nicht im globalenPuffer vorliegt, wird sie vom Plattenspei-cher gelesen. In beiden Fällen wird imCF-Directory die Datenseite registriertund die Position vermerkt, an der sie indem lokalen Puffer in B abgelegt wird.Außerdem wird im Bit-Vektor von B dasentsprechende Bit gesetzt, um eine gülti-ge Datenseite anzuzeigen. Am Ende einerUpdate-Transaktion werden geänderteSeiten in den globalen Puffer in derCF durchgeschrieben, was wesentlichschneller als das Schreiben auf Platte er-folgt. Die CF übernimmt die Seiten undermittelt über die Directory-Einträge,welche Knoten Kopien von den betroffe-nen Seiten haben, und schickt nur an die-se Invalidierungssignale. Das Invalidie-rungssignal bewirkt ein Umschalten das

der Datenseite entsprechende lokale Bitdes Bit-Vektors zur Anzeige eines ungül-tigen Zustands. Dies geschieht ohne Un-terbrechung der in dem Knoten laufendenProzesse. Immer, wenn das Datenbank-system eine lokal gepufferte Datenseitebenutzen möchte, zeigt ein einfacher Bit-

Test die Gültigkeit an. In dem Fall, dassdieser Test einen ungültigen Zustand fest-stellt, erfolgt ein Refresh der lokalen Ko-pie dieser Datenseite. Dies kann meistsehr schnell aus dem globalen Puffer derCF erfolgen, also wesentlich schneller alsdas Einlesen der Seite vom Plattenspei-

Abb. 4.3: Explizites hierarchisches Locking

Abb. 4.4: Broadcast-Invalidierung zur Kohärenzkontrolle

Daten-satz

Daten-satz



cher. Die CF ermöglicht somit eine sehreffiziente Invalidierung von Seiten alsauch einen schnellen Austausch geänder-ter Seiten zwischen Knoten.

Der Aufwand zur Kohärenzkontrollekann weiter begrenzt werden, indem die-se nur auf solchen Datenbankpartitionen(Segmenten) erfolgt, bei denen Invalidie-rungen nicht schon von vorneherein aus-geschlossen sind. Dies ermöglicht Perfor-mance-Vorteile für Partitionen, die exklu-siv von einem Knoten genutzt bzw. dieSysplex-weit nur gelesen werden. DB2ermöglicht ferner, auch ungeänderte Sei-ten, die aus einem lokalen Puffer ver-drängt werden sollen, in den globalen CF-Puffer zu schreiben. Dies kann eine bes-sere E/A-Leistung ermöglichen, da jederTreffer auf eine Seite des globalen Pufferseinen langsamen Plattenzugriff einspart.Da die CF nicht direkt mit den Platten-speichern verbunden ist (Abb. 3.1), mussdas Ausschreiben (Cast-out) geänderterSeiten vom globalen Puffer auf Platten-speicher über die Hauptspeicher der Kno-ten erfolgen. Diese Aufgabe wird durchHintergrundprozesse auf den Knoten er-ledigt, die aktiviert werden, sobald dieAnzahl geänderter Seiten im globalenPuffer einen bestimmten Schwellwertübersteigt. Die Seitenersetzung für unge-änderte Seiten im globalen CF-Puffer er-folgt gemäß LRU (Least Recently Used).

5 Leistungsverhalten

Zur Leistungsbewertung von Sysplex-Konfigurationen wurden seitens IBM undAnwendern umfangreiche Analysen undMessungen vorgenommen, welche einesehr gute Skalierbarkeit zeigten. Hier sol-len nur einige wenige Ergebnisse ange-führt werden; nähere Angaben zu den Ex-perimenten und weitere Ergebnissefinden sich in [ISJ97, RED98].

Beim Vergleich von Konfigurationenohne und mit Sysplex-Unterstützungzeigt sich, dass die Softwareunterstüt-zung für den Sysplex – selbst bei nur ei-nem Knoten – einen gewissen Overheadverursacht. Abbildung 5.1 stellt den typi-schen Verlauf für das Ausmaß diesesOverheads dar, wobei die obere Kurvedem linearen Wachstum und die unteredem realen Sysplex-Verhalten entspricht.

Eine entsprechende Aufstellung desprozentualen Sysplex-Overheads alsFunktion der Systemanzahl in verschie-

denen Installationen zeigt Abbildung 5.2.Dargestellt sind Messungen aus 5 konkre-ten Transaktions-Produktionsumgebun-gen A, B, C, D, E sowie das Ergebnis ei-ner Simulation einer relationalen Anwen-dung. Die Anzahl der Knoten (Systeme)lag bei 2 bis 11. Der zusätzliche Overheadaufgrund des Einsatzes der Sysplex-Soft-ware lag zwischen 7 und 13,3 %. Um diesenBetrag liegt der Durchsatz beim Einsatz derSysplex-Software unter dem theoretischenMaximum eines linearen Durchsatzwachs-tums ohne Kontroll-Overhead.

Abbildung 5.3 zeigt die Ergebnisseeiner Simulation mit dem CICS-Transak-tionsmanager, CICSplex System-Mana-ger und IMS-Datenbank für eine Mi-schung aus OLTP- und Analyseanwen-dungen. Beim Scaleup mit 8 Systemenstieg die Leistung auf das 3,89fache, bei16 Systemen auf das 7,40fache der Leis-tung einer Installation mit 2 Systemen.Dies ist ein fast linearer Scaleup. Ähnli-che Ergebnisse wurden aus der Praxis be-richtet, darunter auch mit SAP R/3-An-wendungen.

Von Bedeutung ist, dass die Anwen-dungen selbst nicht angepasst wurden. InAnbetracht der Skalierungsprobleme, dienormalerweise bei der Portierung vonEinzelprozessoranwendungen auf einenCluster auftreten, ist dies ein sehr gutesErgebnis.

Abb. 5.1: Sysplex-Overhead: typischer Verlauf

Abb. 5.2: Sysplex-Overhead: Beispielwerte

Abb. 5.3: Sysplex-Durchsatzverhalten (Beispiel)



6 Zusammenfassung

Der vorgestellte Sysplex-Ansatz realisierteine innovative Großrechner-Cluster-Ar-chitektur, die in zahlreichen Datenbank-und Transaktionsanwendungen eine sehrhohe Leistungsfähigkeit und Skalierbar-keit unter Beweis gestellt hat. Die we-sentlichen Cluster-Komponenten sind derFICON-Hochleistungs-Switch zur Kopp-lung der Rechner und Plattenspeicher(Shared Disk), der Sysplex Timer sowiedie Coupling Facility (CF). Die CF unter-stützt eine nahe Kopplung (close coup-ling), bei der die Rechner synchron undsehr schnell auf globale CF-Datenstruk-turen und Datenseiten in globalen Puffer-bereichen zugreifen. Damit werden leis-tungskritische Cluster-Aufgaben zurSynchronisation, Kohärenzkontrolle undLastbalancierung wesentlich effizienterlösbar als bei loser Kopplung über allge-meine nachrichtenbasierte Kommunika-tionsprotokolle. Die Kontrollaufgabenwerden durch eigene Maschinenbefehleund Betriebssystemfunktionen unter-stützt, welche von Subsystemen wie Da-tenbanksystemen (DB2, IMS), Transak-tions- und Applikationsservern (CICS,WebSphere) genutzt werden.

Literatur[HKS02 ] Herrmann, P.; Kebschull, U.; Spruth,

W. G.: Einführung in z/OS und OS/390. Ol-denbourg-Verlag, erscheint 2002.

[HORS00] Horswill, J.: Designing & Program-ming CICS Applications. O´Reilly, 2000. ISBN1-56592-676-5.

[ISJ97] Sonderheft des IBM Systems Journalzum Thema Sysplex, Vol. 36, No.2, 1997.http://www.research.ibm.com/journal/sj36-2.html

[JEDI02] http://jedi.informatik.uni-leipzig.de,2002.

[JRD92] Sonderheft des IBM Journal of Re-search and Development zum Thema Sys-plex, Vol. 36, No.4, 1992.

[RAHM94] Rahm, E.: Mehrrechner Datenbank-systeme. Addison-Wesley (Oldenbourg),1994. ISBN 3-89319-702-8.

[RED98] System/390 Parallel Sysplex Perfor-mance. SG 24-4356.-03, 4th edition, Dec.1998. IBM Red Book. http://www.red-books.ibm.com/redbooks/SG244356.html

[RED02] IBM Red Books. http://www.red-books.ibm.com, 2002.

[SHS01] Sloan, S.; Hernandez, A. K.; Sloan, S.G.: DB2 Universal Database for OS/390: AnIntroduction to DB2 for OS/390 Version 7.Prentice Hall, 2001. ISBN 013019848X.

[ZACK99] Zack, W. H.: Windows 2000 and Main-frame Integration. Macmillan Technical Publi-shing, 1999. ISBN 1-57870-200-3.

Bibliographische Hinweise: Zum The-ma Sysplex existiert ein Sonderheft desIBM Journal of Research and Develop-ment [JRD92] sowie ein weiteres Sonder-heft des IBM System Journal [ISJ 97].

Eine Einführung in z/OS und OS/390ist in [HKS02] nachzulesen. [ZACK99]enthält einen Vergleich OS/390 mit Win-dows 2000. Anleitungen für Übungen zumThema OS/390 sind auf der Leipziger Web-site [JEDI02 ] zu finden. [HORS00] enthälteinen sehr guten Überblick über die In-formationsverarbeitung mit CICS;[SHS01] zu dem Einsatz von DB2 unterOS/390. Umfangreiche technische Infor-mationen zu allen IBM-Produkten sindauf der IBM Redbook-Site verfügbar[RED02]. [RAHM94] behandelt u.a. diewichtigsten Arten von Cluster-Datenbank-systemen (Parallelen DBS), insbesondereLösungsansätze für Synchronisation undKohärenzkontrolle in Shared-Disk-Syste-men.

Prof. Dr.-Ing. Wilhelm G. Spruth war langjäh-riger Mitarbeiter in den IBM Laboratorien inBöblingen und dort u.a. für die Entwicklung desersten S/370 Mikroprozessors in CMOS Techno-logie verantwortlich. Er übernahm vertretungs-weise von 1993–1998 die beiden LehrstühleRechnerarchitektur und Verteilte Systeme an derUniversität Leipzig. Derzeitig ist er als Honorar-professor in Leipzig und ebenso an der Univer-sität Tübingen tätig.

Prof. Dr. Erhard Rahm ist Lehrstuhlinhaber fürDatenbanken am Institut für Informatik der Uni-versität Leipzig. Er promovierte und habilitiertean der Univ. Kaiserslautern und verbrachte For-schungsaufenthalte bei IBM und MicrosoftResearch. Er ist derzeit Sprecher des GI-Arbeits-kreises »Web und Datenbanken« und leitet dieBTW2003-Tagung in Leipzig.

Prof. Dr.-Ing. Wilhelm G. SpruthFakultät für Informatik, Universität TübingenFakultät für Mathematik und Informatik, Universität LeipzigInstitut für InformatikAugustusplatz 10–1104109 [email protected]

Prof. Dr. Erhard RahmUniversität LeipzigInstitut für InformatikAugustusplatz 10-1104109 [email protected]://dbs.uni-leipzig.de

Sysplex-Cluster-Technologien für Hochleistungs-Datenbanken

Documents

Transcript of Sysplex-Cluster-Technologien für Hochleistungs-Datenbanken