Heute erklärt unser Kollege Jürgen Meynert im Detail alles zu den SAP HANA-Betriebskonzepten. Dieser Artikel ist daher etwas technischer und länger als sonst. Aber das sind Schulbücher ja auch und wir haben alle viel draus gelernt. Wir wünschen Ihnen daher viel Spaß beim Entdecken und Verstehen!

—

SAP entwickelt mit HANA seit einigen Jahren eine neue technische Basis für ihre Anwendungen. Die Motivation dafür mag darin begründet sein, dass mit nicht flüchtigem Hauptspeicher (NVRAM – non volatile RAM) ein technologischer Paradigmenwechsel bevorsteht.

Die In-memory-Technologie erfordert grundsätzlich neue Programmiermodelle, die sich nicht durch Anpassungen vorhandener Software realisieren lassen, sondern radikal neue Ansätze erfordern. Damit steht nicht nur in der Hardware-, sondern auch in der Softwaretechnologie ein Paradigmenwechsel bevor. Im Zuge des technischen Fortschritts hat die Zugriffsgeschwindigkeit von Storagesystemen nicht Schritt halten können mit den Zuwächsen bei der Prozessorgeschwindigkeit. Bei CPU-Taktraten von 3 GHz, was Zykluszeiten von 0,3 Nanosekunden entspricht, dauern Verarbeitungsschritte im Prozessor in der Größenordnung von Nanosekunden (ns), während Zugriffe auf externen Storage sich im Bereich von Millisekunden (ms) bewegen. Das ist ein Missverhältnis von 1 zu 1.000.000!

Als Konsequenz warten CPUs bei Anwendungen der Informationsverarbeitung die meiste Zeit auf IO. Nun reicht es nicht, nur den Storage schneller zu machen, etwa mit ultraschnellen Flash-Devices, da auch schon das Licht und damit auch die Daten im ns-Bereich nur eine sehr beschränkte Distanz zurücklegen können (< 30 cm in 1 ns). Somit kann schneller Datenzugriff letztlich nur dadurch erzielt werden, dass die Daten auch nahe beim Prozessor bereitgehalten werden: im RAM, oder besser noch im Cache.

Code to Data

Eine weitere Beschleunigung der Verarbeitungsgeschwindigkeit lässt sich dadurch erzielen, dass Anwendungscode direkt in der Datenbank ausgeführt wird, wodurch vergleichsweise hohe Latenzen bei der Kommunikation zwischen Applikation und Datenbank vermieden werden. Wurden also bislang Daten durch die Datenbank zur Anwendung geschleust, wird zukünftig Anwendungscode zu den Daten gebracht. Damit lässt sich der Paradigmenwechsel am anschaulichsten beschreiben: Statt „Data to Code“ heißt es zukünftig „Code to Data“.

Aktuell ist RAM allerdings noch flüchtig, sodass Schreiboperationen im Hauptspeicher durch eine Persistenzschicht, also letztlich doch wieder Storage, abgesichert werden müssen. Für lesenden Zugriff, auch auf sehr große Datenmengen, ist RAM heute bereits gut gerüstet, da mit immer höherer Packungsdichte der Speicherelemente und gleichzeitigem Preisverfall Rechner mit hohen RAM-Kapazitäten (bis zu mehreren TB) zu vertretbaren Preisen verfügbar sind. Da Lesen aus dem RAM heute also effizient und sinnvoll möglich ist, liegt der Fokus von SAP Hana und anderen In-memory-Technologien schwerpunktmäßig auf lesenden Anwendungen wie Reporting und Business Intelligence (OnLine Analytic Processing, OLAP). Für transaktionale Systeme (OnLine Transaction Processing, OLTP) kann man Vorteile daraus gewinnen, dass einerseits Online-Reporting auf den transaktionalen Daten ohne Performanceeinbußen bei der Transaktionsverarbeitung möglich ist oder dass Codestrecken mit hohem Kommunikationsaufkommen zwischen Datenbank und Applikation von einer Verlagerung in die Datenbank schon jetzt profitieren. Aber gleich ob OLAP oder OLTP, die In-memory-DB (IMDB) benötigt eine Persistenz, denn spätestens, wenn der Rechner ausgeschaltet wird, sind die Daten aus dem RAM verschwunden.

Persistenzschicht und Performance

Da bei einer IMDB die Datenzugriffe überwiegend im RAM geschehen, könnte man erwarten, dass der Storage als Persistenzschicht hinsichtlich Performance eine geringe Rolle spielt und in erster Linie zur Absicherung dient, damit keine Daten verloren gehen. Die Anforderungen der SAP an die Performance der Persistenz waren und sind aber zum Teil höher als für klassische Datenbanken. Allgemein lassen sich bei Datenbanken zwei Schreibmechanismen ausmachen – Logwriter und Datawriter. Der Logwriter dokumentiert zeitnah (synchron) in einem eigenen Bereich jede einzelne Änderung (Insert, Update, Delete), die auf der Datenbank durchgeführt wird. Der Datawriter aktualisiert von Zeit zu Zeit (asynchron) die Änderungen der Tabellen im Storage und sorgt für ein konsistentes, aber meist nicht aktuelles (da asynchrones) Abbild der Datenbank. Kritisch für die Transaktionsverarbeitung und für eine Datenbank-Recovery, wenn sie einmal nötig sein sollte, ist der Logwriter. Eine Transaktion gilt erst dann als abgeschlossen, wenn der Logwriter sie als dokumentiert zurückgemeldet hat. Erst dann kann die Verarbeitung fortgesetzt werden. Damit ist sichergestellt, dass nach einem ungeplanten Abbruch der Datenbank der letzte gültige Zustand wiederhergestellt werden kann, indem das letzte konsistente Datenimage mit den dort noch nicht erfassten Logeinträgen fortgeschrieben wird (Roll Forward).

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. 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 ScaleOut-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. 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 ScaleOut-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 – sogenannte Savepoints. Die Performance des Storage muss so ausgelegt sein, dass zumindest vom Durchsatz das zwischen zwei Save­points 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.

Da die spaltenbasierte interne Architektur von Hana vergleichbar ist mit zu einhundert Prozent indizierten Datenbeständen, fallen im Vergleich zu anderen Datenbanken bei Hana häufiger interne Reorganisationen an, die dann auch auf die Persistenz abgebildet werden. Damit erhöht sich die Anforderung des Data­writers an den Schreibdurchsatz. Dagegen sollte man erwarten, dass die Anforderungen an den IO-Durchsatz beim Lesen von Daten eher gering sind, da Hana Daten eigentlich im RAM lesen sollte. Das mag für den Normalbetrieb richtig sein, stimmt aber nicht für den Fall, dass Hana hochgefahren wird. Nimmt man an, dass 1 TB Daten in den Hauptspeicher gelesen werden müssen, dauert das bei einem Durchsatz von 1 GB/s noch immerhin 20 Minuten. Das wäre kein Problem, wenn Restarts der Datenbank die Ausnahme wären. Da Hana aktuell aber ständig weiterentwickelt wird mit dem Ziel, eines Tages NVRAM optimal zu nutzen, sind in regelmäßigen Abständen Updates einzuspielen, die oft mit einem Restart der Datenbank einhergehen. Daher erklärt sich die Anforderung von SAP, die Persistenz auch mit hohen Durchsatzraten für das Lesen im Datenbereich auszustatten.

OLAP versus OLTP

Auch wenn, wie oben erwähnt, der Haupteinsatzbereich von IMDBs tendenziell im OLAP liegt, geht SAP bereits den Weg, auch OLTP-Anwendungen auf Hana zu propagieren (Suite on Hana). Technisch ist es möglich, für OLTP-Systeme sowohl Single Nodes als auch Scale­Out-Architekturen einzusetzen. Aus Sicht der Performance ergibt sich jedoch ein signifikanter Unterschied. Wie bereits erläutert, kann sich für OLTP-Anwendungen ein Performancevorteil auf Hana ergeben, wenn Codestrecken in die Datenbank verlagert werden, um zeitaufwändige Kommunikation zwischen Applikation und Datenbank zu vermeiden. Wenn Hana aber in einer ScaleOut-Landschaft über mehrere Rechnerknoten verteilt ist, wird es sehr schwierig, Code und Datentabellen so über die Knoten zu verteilen, dass die Codestrecken ihre Tabellen auch auf dem gleichen Rechner finden, auf dem sie gerade ablaufen. Denn wenn der Code sich die Daten von einem Nachbarknoten holen muss, fällt wieder Kommunikationsaufwand zwischen den Knoten an, was mit vergleichsweise hoher Latenz geschieht, wie wenn der Code gleich auf dem Applikationsserver verblieben wäre. Aus diesem Grunde ist eine Single-Node-Implementierung von Hana für OLTP auf jeden Fall gegenüber einer ScaleOut-Architektur vorzuziehen.

Zugleich bestand SAP bislang für Hana als Single Node auf der Anforderung nach schnellen (internen) Log-Devices. Interne Log-Devices sind jedoch für geschäftskritische OLTP-Anwendungen nicht akzeptabel, da ein Verlust des Rechners bzw. des Log-Devices gleichzeitig auch mit Datenverlust einhergeht. Geschäftskritische Daten, insbesondere die Logdaten, sollten immer an eine zweite Lokation geschrieben (gespiegelt) werden, sodass man im Notfall die Datenbank aus einer zweiten Quelle bis zur letzten abgeschlossenen Transaktion recovern kann.

Fujitsu hat schon frühzeitig die Hana-Single-Node-Architektur in das FlexFrame-Betriebskonzept integriert und die Logdaten auf externe, spiegelbare Storage-Einheiten platziert. Dort stehen zwar nicht die bisher geforderten 100.000 IOps zur Verfügung, aber aus technischer Sicht sind sie schon lange nicht mehr notwendig. Damit ist aber für Hana der von FlexFrame bekannte sichere und flexible Betrieb für geschäftskritische Anwendungen mit den dafür typischen hohen SLAs gewährleistet. Zwischenzeitlich rückt auch SAP von den hohen IO-Anforderungen für den Logwriter ab, um Hana für eine flexible Integration in den RZ-Betrieb vorzubereiten.

Effizientes Betriebskonzept und Schattendatenbanken

Die Forderung nach sicherer Datenhaltung und einem effizienten Betriebskonzept ist durch die Integration von Hana in FlexFrame gelöst. Mit gespiegeltem Shared-Storage ist Hochverfügbarkeit sowohl lokal als auch RZ-übergreifend gewährleistet. Ein offener Punkt ist noch das Problem der Wiederanlaufzeiten. In Abhängigkeit von der Größe der Datenbank kann ein vollständiger Restart selbst bei hochperformanten IO-Kanälen übermäßig lang dauern. Im Zuge der Weiterentwicklung von Hana arbeitet SAP am Konzept der Schattendatenbank, das Umschaltzeiten idealerweise minimieren würde, da Schattendatenbanken in der Regel nahezu synchron mit den primären Daten mitlaufen. Nach Ausfall der primären Datenbank würde die Aktivierung und vollständige Recovery der Schattendatenbank nur wenige Minuten beanspruchen, bis der Betrieb wieder aufgenommen werden kann.

Schattendatenbanken sind in Hana heute noch nicht verfügbar, aber als Vorstufe dazu bietet Hana die Option der Systemreplication, die dafür sorgt, dass die Logdaten synchron zu einer zweiten Instanz repliziert werden und dass in regelmäßigen Abständen dort der Columnstore (die Spaltenstruktur) von Hana in den Hauptspeicher vorgeladen und aktualisiert wird. So entfällt bei einem Failover das komplette Nachladen des Column­stores, da der größte Teil schon vorgeladen ist. Damit lassen sich die Wiederanlaufzeiten in kritischen Umgebungen auf ein vernünftiges Maß reduzieren.

Die Empfehlung für Anwendungen, die nur minimale Ausfallzeiten erlauben, wäre, lokal zur produktiven Hana-Instanz eine zweite Instanz mit Sytemreplication zu betreiben und für den Desaster-Fall die produktive Persistenz in ein zweites RZ zu spiegeln. Da die Instanz mit der Systemreplication die Rechnerressourcen nur zu einem kleinen Teil nutzt, könnten parallel dazu auf dem Rechnerknoten noch andere, nicht produktive Systeme gefahren werden.

ScaleOut

Bleibt noch zu diskutieren, wie eine ScaleOut-Architektur gegenüber einem Single Node zu bewerten ist. Im Grunde gilt sowohl für OLTP als auch für OLAP, dass bei gleicher Datenbankgröße der Single Node, sofern von den RAM-Kapazitäten möglich, die bevorzugte Alternative ist. Das hat im Wesentlichen zwei Gründe. Der erste wurde schon bei der Diskussion im Zusammenhang mit OLTP diskutiert. Die Kommunikation zwischen den Datenbankknoten kostet vergleichsweise viel Zeit und beeinflusst die Performance negativ. Speziell bei OLAP-Anwendungen ist das Problem der geschickten Zuordnung von Codestrecken zu den Daten nicht so relevant wie bei OLTP, da Queries sich von ihrer mathematischen Struktur in der Regel gut verteilt abarbeiten lassen. Trotzdem bleibt aber das Problem der Latenz, weil die Teilergebnisse einer Query schließlich auf einem Knoten zusammengeführt und in ein Endergebnis konsolidiert werden müssen.

Ein zweites Problem stellt sich beispielsweise bei Joins, die über Tabellen gehen, die über mehrere Knoten verteilt sind. Bevor der Join ausgeführt werden kann, müssen die Daten der beteiligten Tabellen auf den Knoten übertragen und zwischengespeichert werden, auf dem der Join durchgeführt wird. Das kostet einerseits Zeit und andererseits zusätzlich Hauptspeicher. Bei einem Single Node entfällt die Datenübertragung und Zwischenspeicherung, da ja alle Daten lokal sind. Damit ergibt sich als Empfehlung, dass Anwendungen so lange wie möglich mit einer Single-Node-Instanz bedient werden sollten.

Die aktuellen Entwicklungen in der Hardwaretechnik kommen diesem Ansatz entgegen. Mit der im Februar 2014 offiziell verfügbaren Hardware wird es möglich sein, bis zu 12 TB RAM in einer Maschine zu installieren. SAP lässt inzwischen verlauten, dass sie mit der neuen Hardware für OLTP-Anwendungen bis zu 6 TB auf einem Rechner für produktive Systeme unterstützen wird und für OLAP bis zu 2 TB bei acht bestückten Sockeln gegenüber 1 TB in der Vergangenheit. Das klingt plausibel, da sich die CPU-Leistung der neuen Prozessorgeneration etwa verdoppelt hat. Allerdings hat sich auch die Performance der Hana-Technologie in den vergangenen Jahren ständig und signifikant verbessert, sodass man sich aus technischer Sicht für die Zukunft auch noch größeren RAM-Ausbau als 2 TB für einen Knoten in einer ScaleOut-Architektur vorstellen kann.