15 Kohärenzkontrolle

15.6 Zusammenfassende Bewertung

Die Beschreibung der Verfahren zur Kohärenzkontrolle zeigte das Zusammenspiel zwischen Erkennung/Vermeidung von Pufferinvalidierungen, Propagierung von Änderungen sowie der Synchronisation. Eine enge Abstimmung dieser Teilaufgaben im Rahmen eines integrierten Ansatzes erlaubt zudem erhebliche Einsparungen im Kommunikationsumfang. Zur Illustration des Lösungsspektrums sind in Abb. 15-13 noch einmal die wichtigsten Alternativen für die drei Teilprobleme aufgeführt. Da die meisten der Verfahren miteinander kombiniert werden können, ergeben sich über 100 verschiedene Realisierungsansätze. Die Anzahl erhöht sich weiter, wenn man bei den einzelnen Verfahrensklassen noch genauere Unterscheidungen vornimmt (z.B. Verwendung von Lese- und/oder Schreibautorisierungen, Art der Validierung, synchrone/asynchrone Broadcast-Invalidierung etc.). Die Aufstellung kann auch dazu dienen, bestehende Implementierungen bzw. Realisierungsvorschläge einzuordnen und somit besser zu bewerten. Dabei ist zur vollständigen Charakterisierung die Spezifikation aller drei Teilstrategien wesentlich. IMS Data Sharing verwendet z.B. die Verfahren S5/P1/U1 (Token-Ring-Sperrverfahren / Broadcast-Invalidierung / Force), während Oracle die Kombination S2/P4/U4 verfolgt.

Die Vielzahl an Kombinationsmöglichkeiten verlangt eine vergleichende Bewertung, um zu den vielversprechendsten Ansätzen zu kommen. Diese wurde in den zurückliegenden Kapiteln zum Teil bereits vorgenommen, soll jedoch hier noch einmal zusammengefaßt werden. Die Einschätzungen basieren zum Teil auf quantitativen Leistungsanalysen, die in großer Zahl für Shared-Disk-Systeme durchgeführt wurden (u.a. [HR85, YCDI87, Yu87, Bh88, Ra88a, DIRY89, DDY91, DY92, DY93, Ra93c, Ra93d, YD94]).

Abb. 15-13: Verfahrensspektrum zur Synchronisation und Kohärenzkontrolle in Shared-Disk-Systemen

Die erste Festlegung betrifft die Wahl zwischen optimistischer Synchronisation und Sperrverfahren. Optimistische Verfahren (Kap. 14.6) erlauben eine Synchronisation mit geringem Kommunikationsaufwand, insbesondere bei zentraler Validierung, der zudem weitgehend unabhängig von den Lastmerkmalen und der Strategie zur Lastverteilung ist. Die Kohärenzkontrolle dagegen ist weniger effektiv lösbar als für Sperrverfahren, da zur Erkennung von Pufferinvalidierungen nur eine (asynchrone) Broadcast-Invalidierung anwendbar ist. Diese führt jedoch einen sehr hohen Aufwand ein und eignet sich nicht für Konfigurationen mit großer Rechneranzahl. Nachteilig ist ferner die hohe Anzahl von Transaktionsrücksetzungen, auch wenn ein Verhungern von Transaktionen durch Kombination mit Sperrverfahren i.a. verhindert werden kann. Sperrverfahren eignen sich schließlich besser zur Unterstützung feiner Synchronisationsgranulate (Satzsperren) und werden in kommerziellen DBS nahezu ausschließlich verwendet.

Von den Sperrverfahren können Token-Ring-Ansätze ausgeschlossen werden, da sie nur für wenige Rechner in Betracht kommen. Damit bleiben zur Synchronisation im wesentlichen die Alternativen S1 bis S4, wobei S1 noch als Spezialfall von S2 aufgefaßt werden kann. Diese Sperrverfahren basieren alle auf der Nutzung Globaler Lock-Manager (GLM), was eine effiziente Integration der Kohärenzkontrolle erlaubt. Dabei sind die Ansätze der Broadcast- und Multicast-Invalidierung aufgrund ihres hohen Kommunikationsbedarfs sowie starker Antwortzeitverschlechterung für Änderungstransaktionen als nicht empfehlenswert einzustufen (ebenso ein Buffer-Purge-Ansatz). Zur Behandlung von Pufferinvalidierungen eignen sich somit primär die Ansätze der On-Request-Invalidierung sowie der Haltesperren. Bezüglich der Update-Propagierung sind Noforce-Ansätze mit direkten Seitentransfers am effizientesten, wobei jedoch dedizierte Page-Owner oft eine hohe Anzahl von Seitenübertragungen verursachen. Am aussichtsreichsten erscheinen daher die Alternativen U3 und U5. Der Austausch geänderter Seiten über Externspeicher (sowie Force) vereinfachen dagegen die Crash-Recovery. Ihr Leistungsverhalten läßt sich zudem durch nicht-flüchtige Platten-Caches stark verbessern.

Der Einsatz von Haltesperren kommt vor allem für Sperrverfahren in Betracht, die Lese- und Schreibautorisierungen verwenden. Weil der Einsatz von Schreibautorisierungen der Nutzung einer lokalen GLA entgegenläuft (Kap. 14.3), sind Haltesperren dabei vor allem für dedizierte Sperrverfahren von Interesse (S1/S2). In diesem Fall kommt vor allem eine dynamische Page-Owner-Zuordnung in Frage, da sich die dedizierten GLM-Rechner weniger als Page-Owner eignen. Bei fester GLA-Zuordnung unter den Verarbeitungsrechnern (Primary-Copy-Sperrverfahren) ist eine sehr effiziente Kohärenzkontrolle möglich mit einer On-Request-Invalidierung sowie mit einer festen Page-Owner-Zuordnung, die mit der GLA-Verteilung übereinstimmt (Kap. 15.3.3). Bei dynamischer GLA-Zuordnung kann der Einsatz von Schreibautorisierungen die Nutzung einer lokalen GLA ebenfalls beschränken, so daß auch hier eine On-Request-Invalidierung Vorteile gegenüber Haltesperren verspricht. Eine feste Page-Owner-Zuordnung ist hierbei weniger interessant, da sie sich nicht mit der dynamischen GLA-Zuordnung kombinieren läßt. Insgesamt erscheinen somit folgende Kombinationen zur Synchronisation/Kohärenzkontrolle am aussichtsreichsten:

Von diesen Alternativen sprechen wesentliche Vorteile für den zweiten Ansatz, einem Primary-Copy-Sperrverfahren mit übereinstimmender GLA- und Page-Owner-Zuordnung. Die stabile Zuordnung der Verantwortlichkeiten erleichtert ein affinitätsbasiertes Transaktions-Routing zur Unterstützung von rechnerspezifischer Lokalität, welche für alle Sperrverfahren wesentlich zur Einsparung von Kommunikationsvorgängen ist. Zudem entfällt der hohe Aufwand für Migrationsvorgänge von Schreibautorisierungen/Haltesperren bzw. zur Lokalisierung des GLM. Die Kohärenzkontrolle kann ohne jegliche Zusatznachrichten gelöst werden, wobei auch Seitentransfers stets mit Sperrnachrichten kombinierbar sind. Bei dynamischer Page-Owner-Zuordnung verursachen Seitenanforderungen dagegen zusätzliche Verzögerungen. Die On-Request-Invalidierung erfordert einen geringeren Verwaltungsaufwand als Haltesperren, da für jede im System gepufferte Seite eine Haltesperre (oder Transaktionssperre) bestehen muß und somit ein zu wartender Eintrag in der globalen Sperrtabelle des GLM. Auf der anderen Seite verspricht die Vermeidung von Pufferinvalidierungen durch Haltesperren eine bessere Puffernutzung und somit bessere Trefferraten. Ein spezifisches Problem des Primary-Copy-Sperrverfahrens liegt in der Notwendigkeit, eine logische DB-Partitionierung zur GLA/Page-Owner-Zuordnung bestimmen zu müssen.

Wie bereits in Kap. 13.4 ausgeführt, kann das Leistungsverhalten eines Shared-Disk-Systems durch eine nahe Rechnerkopplung signifikant verbessert werden. Wenn z.B. die Synchronisation über eine spezielle Lock-Engine oder eine globale Sperrtabelle in einem synchron zugreifbaren Halbleiterspeicher erfolgt, kann diese Aufgabe oft mit vernachlässigbarer Verzögerung erledigt werden. Ferner können Seitentransfers schnell über einen globalen, nicht-flüchtigen Puffer abgewikkelt werden, der auch zur Verbesserung des E/A-Verhaltens genutzt werden kann. Das Leistungsverhalten wird somit wesentlich unabhängiger vom Referenzverhalten der Last sowie der Lastverteilung. Dennoch bleibt auch hier eine affinitätsbasierte Lastverteilung wesentlich, da sie zumindest das E/A-Verhalten beeinflußt (lokale Trefferraten, Ausmaß an Pufferreplikation und Invalidierungen). Nachteile der nahen Kopplung sind jedoch hohe Hardware-Kosten sowie eine potentiell beeinträchtigte Erweiterbarkeit auf zahlreiche Rechner.