Soccer team in a huddle

SAP HANA SPS10: Die wichtigsten Neuerungen

Feature | 5. Oktober 2015 von Andreas Schmitz 0

Parallel zu strategischen Überlegungen zu SAP HANA geht die technische Entwicklung kontinuierlich weiter. Die aktuelle Innovation des SAP HANA Support Package Stacks 10 (SAP HANA SPS10) in der Kurzvorstellung.

Alle halbe Jahre: Das ist der Innovationszyklus der SAP für SAP HANA. Das aktuelle Release des Support Package Stacks ist nun einige Monate auf dem Markt. Und es enthält wichtige Neuerungen:

1. Support für die IBM-Power-Plattform

2. Erweiterungen im Bereich Workloadmanagement

3. Erweiterungen des Multitenant Database Containers

4. Databackup verbessert

5. SAP HANA Dynamic Tiering

6. Mission Critical-Funktionalitäten

Vorschau: Was als Nächstes geplant ist


1. Support für die IBM-Power-Plattform

Bisher lief SAP HANA ausschließlich auf Intel-CPUs, also Prozessoren von Intel. SAP unterstützt nun erstmals auch die IBM-Power-CPUs. Damit „bedient“ SAP neben der Intel-Plattform jetzt auch die zweite große Hardware-Plattform im Bereich der Datenbankserver. SAP erschließt so einerseits eine für SAP wichtige Kundengruppe, die ihre Server auf Basis der IBM-Prozessoren betreiben. Andererseits erleichtert diese Unterstützung den Kunden der IBM-Power-Plattform die Entscheidung für SAP HANA. „Es geht hier um eingeschworene loyale Kunden“, erläutert Ralf Czekalla, Experte aus dem SAP HANA-Produktmanagement, „deshalb war es wichtig, diese Plattform zu aktivieren.“ Im ersten Schritt wird zunächst das SAP Business Warehouse (SAP BW) auf der IBM-Power-Plattform zur Verfügung stehen. Die Freigabe weiterer Produkte und Szenarien ist für die nächsten Monate geplant. Ziel sei es, so Czekalla, auch von Seiten der SAP HANA-Plattform Feature-äquivalent mit der schon länger unterstützten CPU-Plattform von Intel zu sein.

2. Erweiterungen im Bereich Workload-Management 

Es lassen sich erstmals „Workload-Profile“ anlegen, um bestimmte Typen von Prozessen gegenüber anderen zu bevorzugen. In einem SAP Business Suite-System lässt sich so für transaktionale Prozesse eine höhere Priorität als für analytische einräumen. Für ERP- und andere transaktionale Systeme ist es besonders wichtig, dass die Antwortzeiten transaktionaler Vorgänge nicht durch gleichzeitige OLAP-Queries beeinträchtigt werden. Entsprechende Prioritäten lassen sich im System konfigurieren.

3. Erweiterungen des Multitenant Database Containers 

Damit bietet SAP HANA in einem Datenbanksystem nicht mehr nur eine logische Datenbank sondern mehrere voneinander getrennte Datenbanken an. Das ermöglicht unter anderem eine bessere Aufteilung von Administrationen zwischen Basis- und Anwendungsapplikationen auf der Datenbank. Bereits das Vorgänger-Release hat eine dateibasierte Sicherung (Backup) und Wiederherstellung (Recovery) unterstützt. Mit SAP HANA SPS10 wurde dies auf die „BACKINT-Schnittstelle“ ausgedehnt, über die SAP HANA in externe Backup-Systeme eingebunden werden kann. Weitere Verbesserungen gibt es zudem im Bereich des Cross-Datenbank-Zugriffs von einer Tenant-Datenbank auf die andere. Das hilft Kunden, die zwei Anwendungen in demselben Datenbanksystem betreiben wollen. Mit der Einführung von Multitenant Database Containers lassen sich solche Anwendungen nun in einzelne Tenant-Datenbanken separieren.

4. Databackup verbessert

Sowohl inkrementelles wie differentielles Backup ist mit SAP HANA nun möglich. Man muss also Daten, die sich nicht so oft ändern, nun nicht mehr immer wieder aufs Neue komplett sichern. Klassisch war es nötig, ein komplettes Backup zu machen, in dem hundert Prozent des Datenbestandes gesichert wurde. „Natürlich ohne Freibereiche“, wie Czekalla ergänzt.

5. SAP HANA Dynamic Tiering

Technisch gesehen wird in einem SAP HANA-System ein Disk-Store eingeführt, um niedriger priorisierte Daten nicht mehr im Arbeitsspeicher „in memory“ vorhalten und prozessieren zu müssen. Im SAP HANA-System lässt sich mit einer Differenzierung zwischen wichtigen und weniger wichtigen Daten ein größerer Datenanteil unterbringen als bisher. Heiße Daten werden als hoch priorisierte Daten „in memory“ genutzt, warme Daten hingegen auf Disks gespeichert – verbunden mit einer erhöhten Latenzzeit und einer geringeren Performance. Durch Dynamic Tiering als eine Komponente von SAP HANA bekommt der Kunde somit mehr Flexibilität in der Hardwarenutzung.

In SAP HANA sind alle Prozesse zunächst einmal daraufhin optimiert, dass die Daten bei der Verarbeitung komplett im Arbeitsspeicher vorliegen. Eine Disk-basierte Datenbank setzt auf andere Strategien, etwa Caching-Strategien, um mit einem vergleichsweise kleinen Hauptspeicher immer noch eine vertretbare Performance herauszubekommen. Für Dynamic Tiering liegen ausgewählte Teile der Daten nun auf der Festplatte. Dafür sind dann klassisch disk-basierte Algorithmen im Einsatz. Warme Daten müssen also nicht in den SAP HANA-Hauptspeicher gezogen werden, um sie zu verarbeiten. Ein weiterer Vorteil bei Dynamic Tiering: Die Daten liegen wie auch „in memory“ spaltenbasiert vor.

Wichtiger Treiber des Dynamic Tiering sind die Kosten. Denn es ist günstiger, Daten auf der Festplatte abzulegen, als im Hauptspeicher zu halten. „Bei einer In-Memory-Plattform ist die Investition für Hardware stark an das Wachstum der Daten gekoppelt, bei einem Disk-basierten System weitaus weniger“, erläutert SAP HANA-Spezialist Richard Bremer, „mit SAP HANA Dynamic Tiering kombinieren wir somit die Vorteile der In-Memory-Plattform mit denen plattenbasierter Systeme.“

6. Mission Critical-Funktionalitäten

Bei der Cluster-Failover-Lösung SAP HANA System Replication liegt mit der Hard- und Software das gesamte System in individuellen Installationen doppelt vor, typischerweise im gleichen und/oder in unterschiedlichen Datenzentren in Ketten mit bis zu drei Elementen bzw. Datenzentren (siehe Grafik). Wenn das Primärsystem ausfällt, kann das Sekundär- oder Schattensystem den Betrieb übernehmen.

Bildschirmfoto 2015-10-02 um 14.41.29

Grafik: SAP

System Replication wurde bereits im Release SPS05 vor fast drei Jahren eingeführt und seitdem mit jedem aktuelleren Support Package Stack um Details erweitert. Die optimierten Übernahme- oder Takeoverzeiten des aktuellen Betriebsmodells sind die wichtigste Verbesserung in SAP HANA SPS09 und SPS10. Bei der Systemübernahme werden beispielsweise wichtige Initialisierungsprozesse nun in den Hintergrund gestellt, so dass die Datenbank mit dem Umschalten deutlich schneller verfügbar ist. Nach Aussage eines Kunden sanken die Takeover-Zeiten mit diesen Änderungen von 15 auf zwei Minuten. Diese Übernahmezeit hängt von vielen Faktoren ab und ist immer individuell zu betrachten. „Im Durchschnitt ist eine Senkung der Takeover-Zeit um 50 Prozent realistisch – immer allerdings in Verbindung mit Verbesserungen durch SAP HANA SPS09 und SPS10 zu sehen“, sagt SAP HANA-Experte Czekalla. Die Takeover-Zeiten zu reduzieren, ist nicht nur im Katastrophenfall nötig, sondern etwa auch bei einem „(Near-)Zero-Downtime-Upgrade“. Dabei wird auf dem Schattensystem der Upgrade von Komponenten inklusive Datenbanksoftware vorbereitend durchgeführt. Damit können nicht nur SAP HANA-Revisionen aus der gleichen SPS-Linie installiert, sondern auch SPS-Grenzen übersprungen werden.

Mit einer anschließenden Übernahme der Anwendung beziehungsweise des Geschäftsbetriebs auf die Schattenseite wird nebenbei auch gleich auf ein aktualisiertes System gewechselt. „Eine praktische Angelegenheit“, so Czekalla. Möglich ist dies durch die Option von SAP HANA System Replication hierbei auch die Replikation verschiedener, hin zu neueren Versionen laufende Datenströme zu unterstützen. Der Übernahmeprozess kann dann sogar noch optimiert bzw. für die ABAP-Anwendung verschleiert werden. Die genutzte Technik versteckt sich hinter dem Begriff „Connectivity Suspend“ und ist auch schon seit mehreren SPS von SAP HANA verfügbar, aber deren Tragweite wurde bisher oft nicht erkannt. Der Nutzer merkt im optimalen Fall nichts davon, dass ein Wechsel der Hardware und Softwareversionen stattgefunden hat.

Vorschau: Was als Nächstes geplant ist

  • „Hot Standby für SAP HANA System Replication“: Für den weiteren Ausbau der SAP HANA System Replication ist geplant, den Prozess der Datenfortschreibung ins Sekundärsystem zu ändern, so dass Umschaltzeiten von weit unter einer Minute möglich werden können. Auf der administrativen Seite sind fast keine Änderungen notwendig, außer der Eingabe eines neuen „Einschalters“ (Parameterwerts) für diese Option. Zusätzlich zur schnelleren Übernahme soll dann auch eine weitere Reduktion der zu übertragenden Daten zwischen den gekoppelten Systemen um den Faktor fünf bis zehn erreicht werden. Das hat für viele Kunden eine große Relevanz, gerade wenn sie weit auseinanderliegende Datenzentren haben und in strukturschwachen Regionen operieren. Denn das zu übertragende Datenvolumen (und damit der notwendige Datendurchsatz) wird entscheidend verringert.
  • Active-Active-Betrieb von SAP HANA System Replication: In einem darauf aufbauenden Schritt ist angedacht, auf dem Sekundärsystem der System Replikation Lesezugriffe zu ermöglichen. Mit dem Verbund von gekoppelten SAP HANA-Instanzen werden die Daten der laufenden Anwendungen auf das zweite Datenzentrum repliziert. Die Anwendung könnte dann lesende Anfragen auch an das zweite Datenzentrum schicken. Ändernde Operationen werde weiterhin auf den Daten des ersten Datenzentrums ausgeführt. Aktuell besteht die allgemeine Tendenz, nach der Migration zu SAP HANA das operationale Reporting wieder zurück in das eigentliche SAP Suite-Anwendungssystem zu bringen und die Fähigkeiten von SAP HANA in den Originaldaten voll auszuschöpfen. Die geplante Option Active-Active könnte dann innerhalb einer einzigen logischen Instanz eine einfache automatische Trennung von transaktionalen OLTP– und analytischen OLAP-Funktionen auf primäre und sekundäre SAP HANA-Hardware bieten, die mit „SAP HANA System Replication HotStandby“ gekoppelt sind.
  • Eine Tabelle für warme und heiße Daten: Heute sind die Daten nach Tabellen getrennt. Eine Datenbanktabelle ist heute vollständig eine klassische SAP HANA-In-Memory-Tabelle oder ein „extended table“ von Dynamic Tiering. Innerhalb einer Tabelle sind die Daten immer vollständig „heiß“ oder „warm“. Künftig sollen sich heiße und warme Daten in einer einzigen Tabelle vorhalten lassen. Das Tool Data Lifecycle Manager (DLM) aus der SAP HANA Data Warehousing Foundation hilft zusätzlich, etwa aus SAP HANA-In-Memory-Tabellen die Extended Table zu ziehen, die Datenverschiebung zu organisieren und Strukturen in der Datenbank so anzulegen, dass ohne zusätzlichen Aufwand auf heiße und warme Daten lesend zugegriffen werden kann.

Um noch mehr Details über SAP HANA SPS10 zu erfahren, schauen Sie sich auch das Video der SAP-Academy an.

Im SAP-HANA-Blog finden Sie zudem zusätzliche Informationen über die technischen Innovationen in SAP HANA SPS10.

Generelle Informationen zum Thema SAP HANA finden Sie zudem auf unserer Themenseite.

Tags: , , ,

Leave a Reply