Suchen

In-Memory-Technik leicht erklärt

Die technischen SAP HANA-Betriebsmodi

Seite: 3/7

Logwriter & Datawriter

In den frühen Revisions von HANA war der Logwriter so konzipiert, dass er alle Änderungen in kleinen Blockgrößen in den Log-Bereich schrieb. Bei umfangreichen Änderungen in der Datenbank führte das zu einer erheblichen Anzahl an IO-Operationen. Deshalb war damals die Anforderung von SAP, dass die Persistenz in der Lage sein musste, mindestens 100.000 IOps (IO-Operationen pro Sekunde) schreiben zu können.

Früher war der Aufwand nur mit lokalen Flash-Devices (PCI-basiert) zu vertreten.
Früher war der Aufwand nur mit lokalen Flash-Devices (PCI-basiert) zu vertreten.
(Bild: Texelart/Fotolia.com)

Das ist mit vertretbarem Aufwand nur mit lokalen Flash-Devices (PCI-basiert) zu realisieren. Deshalb hatten und haben die meisten Single-Node-Installationen von HANA PCIe basierte Flash-Devices. Später wurde HANA um eine Scale-Out-Architektur erweitert für den Fall, dass der maximal mögliche Hauptspeicherausbau innerhalb eines Rechners nicht mehr ausreichte, eine größere Datenbank komplett zu speichern. HANA kann mit dieser Option auf mehrere Rechnerknoten verteilt werden.

Die Rechner können so ausgelegt werden, dass nicht alle aktiv sind, sondern dass auch ein oder mehrere Knoten als Failover konfiguriert werden können für den Fall, dass ein aktiver Knoten ausfällt. Das setzt allerdings eine (externe) Persistenz voraus, die von allen Rechnern gelesen werden kann; denn sonst kann ein Failover-Knoten nicht die Daten eines ausgefallenen Rechners einlesen.

Logwriter versus I/O-Raten

Damit war das Konzept, Log-Daten sehr schnell auf ein lokales Device zu schreiben, nicht mehr haltbar. Dementsprechend wurde der Logwriter dahin gehend optimiert, dass er variable Blockgrößen schreiben konnte. Damit waren die hohen IO-Raten auch nicht mehr erforderlich. In einem Scale-Out-Szenario waren knapp 20.000 IOps pro Rechnerknoten ausreichend. Gleichwohl hielt SAP die 100.000 IOps für Single-Nodes bis in die jüngste Vergangenheit aufrecht.

Neben dem Logwriter gibt es noch, wie schon erwähnt, den Datawriter. Zunächst sollte man wiederum meinen, dass der unkritisch im Hinblick auf Performance ist, da er ja asynchron schreibt. Tatsächlich schreibt HANA in konfigurierbaren Zeitabständen – Default ist fünf Minuten – so genannte Savepoints.

Die Performance des Storage muss so ausgelegt sein, dass zumindest vom Durchsatz das zwischen zwei Savepoints geänderte Volumen im verfügbaren Zeitintervall geschrieben werden kann. Da der Datawriter nach dem Prinzip Copy-on-write verfährt, ist die Schreiblast tendenziell sequenziell, da geänderte Blöcke nicht überschrieben werden, sondern die Änderungen in neu allokierte Blöcke abgelegt werden. Damit vereinfachen sich die Anforderungen an die Persistenz, weil sequenzielle IO wesentlich effizienter realisiert werden kann als Random-IO.

(ID:42593811)