13.3 Neue Realisierungsanforderungen

13.3.3 Lastverteilung

Neben der Lastbalancierung sollte die Lastverteilung jedoch auch eine Transaktionsverarbeitung mit einem Minimum an Kommunikations-, E/A- und Synchronisationsverzögerungen unterstützen. Ein allgemeiner Ansatz hierzu ist ein sogenanntes affinitätsbasiertes Transaktions-Routing [YCDI87, Ra92b]. Dabei wird eine Lastverteilung angestrebt, so daß Transaktionen verschiedener Rechner möglichst unterschiedliche DB-Bereiche referenzieren. Hierzu gilt es, Transaktionstypen mit einer Affinität zu denselben DB-Bereichen möglichst denselben Verarbeitungsrechnern zuzuweisen, wodurch eine hohe rechnerspezifische Lokalität im Referenzverhalten erreicht wird. Das für solche Entscheidungen benötigte Wissen über das Referenzverhalten ist zumindest für häufig ausgeführte Online-Transaktionen bekannt bzw. kann über Monitoring ermittelt werden.

Lastverteilungverfahren wie die wahlfreie Auswahl der Verarbeitungsrechner (random routing), welche das Referenzverhalten nicht berücksichtigen, sind wesentlich einfacher zu realisieren als ein affinitätsbasierter Ansatz. Dafür bringt die Unterstützung rechnerspezifischer Lokalität gewichtige Vorteile für das Leistungsverhalten eines Shared-Disk-Systems, die im Rahmen mehrerer Leistungsanalysen nachgewiesen wurden [YCDI87, Ra93d]:

• Eine hohe Lokalität kann natürlich von der Pufferverwaltung jedes Rechners zur Reduzierung physischer E/A-Vorgänge genutzt werden. Für Shared-Disk bewirkt die rechnerspezifische Lokalität darüber hinaus, daß relativ wenige Seiten repliziert in mehreren Rechnern gepuffert sind, so daß sich die Trefferraten gegenüber wahlfreier Lastverteilung verbessern.

• Das Ausmaß an Pufferinvalidierungen kann stark eingeschränkt werden, wenn Änderungen bestimmter Seiten nur an einem bzw. wenigen Rechnern erfolgen. Gegenüber wahlfreier Lastverteilung verbessert dies die Trefferraten und reduziert die Notwendigkeit, geänderte Seiten im System zu propagieren. Damit wird auch die Skalierbarkeit auf eine große Anzahl von Rechnern nachhaltig verbessert.

• Einige Synchronisationsverfahren für Shared-Disk sind in der Lage, rechnerspezifische Lokalität zur Reduzierung des Kommunikationsaufwandes zu nutzen (Kap. 14). Damit ergibt sich auch für diese kritische Funktion ein besseres Leistungsverhalten als bei wahlfreier Lastverteilung.

• Eine weitere Konsequenz rechnerspezifischer Lokalität ist, daß Synchronisationskonflikte zumeist zwischen Transaktionen desselben Rechners auftreten. Diese können jedoch wesentlich schneller erkannt und behandelt werden (lokale Blockierung/Rücksetzung von Transaktionen, lokale Deadlock-Erkennung, Warten auf Sperrfreigabe einer lokalen Transaktionen u.ä.) als rechnerübergreifende Konflikte, die zusätzliche Kommunikationsverzögerungen bewirken.
  

Vielfach liegen jedoch weniger günstige Verhältnisse vor, wie sie beispielhaft in Abb. 13-4b gezeigt sind. In solchen Fällen existieren Transaktionstypen, die nahezu alle DB-Bereiche referenzieren, sowie DB-Bereiche, die von fast allen (wichtigen) Transaktionstypen referenziert werden. Eine affinitätsbasierte Lastverteilung ist hier zwar auch möglich, jedoch läßt sich nicht verhindern, daß verschiedene Rechner dieselben DB-Bereiche referenzieren. Die Situation verschärft sich noch für dominierende Transaktionstypen, deren Verarbeitung auf nur einem Rechner aufgrund hoher Ausführungsrate bzw. hohen Ressourcen-Bedarfs dessen Überlastung zur Folge hätte. Die notwendige Aufteilung solcher Transaktionstypen auf mehrere Rechner führt jedoch nahezu zwangsweise zu Lokalitätseinbußen. Dies kann höchstens (etwa unter Berücksichtigung von Eingabeparametern) durch eine Aufteilung in mehrere Sub-Transaktionstypen, die unterschiedliche DB-Teile berühren, vermieden werden. In Bankanwendungen könnten so Konto-Transaktionen (Einzahlung, Abhebung etc.) über die Kontonummer aufgeteilt werden, so daß jeder Rechner Transaktionen/Konten eines anderen Wertebereiches für die Kontonummern bearbeitet.

Abb. 13-4: Referenzverteilung von Transaktionslasten

Allerdings zeigten empirische Untersuchungen bereits, daß mit einem tabellengesteuerten Ansatz allein meist keine effektive Lastbalancierung erreicht werden kann [Ra88b]. Denn die Berechnung der Routing-Tabelle basiert auf Erwartungswerten über mittlere Ankunftsraten und Instruktionsbedarf pro Transaktionstyp, während die tatsächliche Lastsituation von den Mittelwerten meist signifikant abweicht. Zudem sind die durch Kommunikations-, E/A-, und Sperrverzögerungen bedingten Auswirkungen i.a. in jedem Rechner verschieden und bei der Berechnung der Routing-Tabelle kaum vorhersehbar. Aus diesen Gründen empfiehlt sich ein gemischter Ansatz zum Transaktions-Routing, bei dem aus einer vorbestimmten Tabelle der unter Lokalitätsaspekten bevorzugte Rechner bestimmt wird, daneben jedoch auch die aktuelle Lastsituation berücksichtigt wird. Ist z.B. der bevorzugte Rechner zum Zuweisungszeitpunkt bereits völlig überlastet, kann eine Zuteilung zu einem weniger belasteten Rechner erfolgen, der auch teilweise Lokalität unterstützt.