Flexibles Infrastrukturkonzept für SAP HANA (Sponsored Content) Innovationspotenziale schnellstmöglich schöpfen

Der Umstieg von einem traditionellen SAP-System auf S/4 HANA verspricht für Anwenderunternehmen große Vorteile: Analysen sind schneller verfügbar und es besteht dabei die Option, auf die Echtzeitdaten der Anwendung zuzugreifen. Doch gleichzeitig stellt er auch große Anforderungen an die IT-Infrastruktur. Daher sind flexible Konzepte wie der Flexpod-Ansatz gefragt, die zum einen mit vielfältigen Vorteilen im Storage-Bereich punkten und zum anderen eine schnelle Inbetriebnahme – kombiniert mit einem „Single Point of Contact“ – mit sich bringen. So gelingt der Umstieg problemlos.

Migration auf SAP HANA

Aktuelle Untersuchungen wie die PAC-Studie „S/4 HANA – Relevanz für SAP-Kunden, Erwartungen und Hindernisse“ zeigen es: Die meisten Unternehmen, die SAP im Einsatz haben, beschäftigen sich aktiv mit dem Umstieg auf S/4 HANA. Dabei wird S/4 HANA nicht nur als Pflichtprogramm wahrgenommen, sondern auch als Problemlöser gesehen. In erster Linie sehen die Anwender in S/4 HANA einen Gewinn in punkto Schnelligkeit. Dabei profitiert vor allem der Bereich Finanzen und Controlling und Logistik von der neuen Lösung. Treiber sind dabei im Wesentlichen Effizienzsteigerung bei SAP-gestützten Prozessen, Innovation in Richtung Realtime und Verfolgung von Trendthemen wie Big Data oder Industrie 4.0.

Für die digitale Transformation der Geschäftsmodelle räumen die Anwenderunternehmen ihren SAP-Systemen eine zentrale Rolle ein. Die meisten SAP-Verantwortlichen sind der Meinung, dass S/4 HANA von SAP-Kunden früher oder später eingeführt werden muss, zumal der Support anderer Datenbanken 2025 auslaufen wird. Die wichtigste Motivation ist für zwei Drittel der Befragten, der SAP-Produktstrategie zu folgen, um an SAPs künftigen Weiterentwicklungen teilhaben zu können. Damit wird eines klar: Die Anwenderunternehmen sehen klare Vorteile und verfolgen auch konkrete Ziele. Allerdings müssen sie den Umstellungsaufwand abschätzen können, denn die Herausforderungen an die IT-Infrastruktur gelten als nicht gering.

Mit dem Umstieg auf S4/HANA wird allerdings die zugrunde liegende Datenbank gewechselt: SAP HANA ist dafür die Plattform und sie wird auf x86-basierenden Servern nur auf SUSE- und Red Hat-Linux unterstützt. Der Betrieb einer In-Memory-Datenbank wie SAP HANA hat ein massives Problem: Die Daten liegen im Arbeitsspeicher der Server und bei einem Stromausfall fällt das komplette System aus. Das stellt weitaus größere Herausforderungen an die Betriebsmodelle als das bei traditionellen Datenbanken der Fall ist. Ab dem Service Pack 10 (SPS10) für die In-Memory-Plattform SAP HANA hat SAP Verbesserungen vorgenommen. Mit dieser Version stehen neuartige Funktionen zur Verfügung, die auch die Anbindung an das Internet der Dinge (IoT) bieten, die eine effektivere Verwaltung von Big Data, eine hohe Datenverfügbarkeit im gesamten Unternehmen sowie die Entwicklung neuer Anwendungen ermöglichen.

Optimierte Backup-Infrastruktur

Speziell aus dem Blickwinkel der Backup-Infrastruktur sind für viele bestehenden SAP-Installationen Optimierungen nötig, wenn sie auf HANA umgestellt werden sollen. Aufgrund der In-Memory-Struktur ist die HANA-Datenbank einfach „weg“, wenn der „flüchtige“ Hauptspeicher, das DRAM, keinen Strom mehr bekommt. Diese Art der Datenbereitstellung für die Applikation – das In-Memory-Konzept von SAP HANA – führt zu Änderungen im Betriebsmodell. Dazu zählen auch die Aufgaben im Bereich von Disaster Recovery oder die üblichen Hochverfügbarkeitsanforderungen, wie sie bei unternehmenskritischen Applikation notwendig sind.

Dazu benötigt Unternehmen auch ein schnelles Storage-Subsystem mit „Enterprise-Funktionalitäten“. Denn es sind größere Datenmengen vom internen Server-Speicher (DRAM) auf Platten- oder Flash-Systeme zu bewegen. Bei HANA werden alle Daten alle fünf Minuten auf persistenten Speicher geschrieben werden („persitancy flash“), wobei dieser Vorgang schnell laufen muss. Auf diese Art werden „Consistency Points“ – mit einem Abstand von fünf Minuten – erstellt.
Hier stoßen traditionelle Backup-Konzepte schnell an ihre Grenzen. In einer HANA-Umgebung mit einem herkömmlichen Backup-Konzept würde man die Daten als Streaming-Backup über den Host auf ein Backup-System sichern. Bei einer Datensicherung im TByte-Bereich kann das Sichern auf Disk und anschließend auf ein Tape-Laufwerk einige Stunden dauern.

Ähnlich zeitaufwändig ist der Wiederherstellungsvorgang: Das Nachladen von Tape oder Disk und das Füllen des Persistenz-Layers und das Laden des Hauptspeichers sind zeitintensiv. Anschließend müssen noch Log-Files der Transaktionen eingespielt werden. Die Zeiten für eine Systemwiederherstellung fallen dementsprechend hoch aus und produktive, unternehmenskritische Systeme sind nicht verfügbar. Somit wäre es wünschenswert, häufiger eine Datensicherung in Form eines Snapshots durchführen zu können, bei dem die produktiven IT-Systeme nicht belastet werden. Dadurch sind weniger Log-Dateien bei einem Wiederherstellungsvorgang abzuarbeiten und die Wiederherstellungszeiten sinken. Generell empfiehlt es sich nur in den seltensten Fällen, die Backup-Problematik mit einer alten Backup-Infrastruktur zu lösen. IT-Verantwortliche sollten auf alle Fälle auf moderne Ansätze – wie etwa eine schnelle Snapshot-Funktionalität – setzen.

Hierzu bieten sich NetApp-Storage-Systeme wie die FAS-Reihe an. Sie erlauben die persistente Datenablage für die In-Memory-Datenbank von HANA. Die Storage-Lösung kann mehrere Versionen der operativen Daten in effizienter Art und ohne Belastung der Produktivsysteme verwalten. Backups werden dadurch mit deutlich geringeren Speicheranforderungen durchgeführt und dauern nur noch wenige Sekunden – anstatt mehrere Stunden. Der Storage-Snapshot erfolgt komplett eigenständig und beeinträchtigt nicht die Leistung der HANA-Server durch Datenhandling oder Transport. Da die NetApp-Storage-Systeme die Veränderungen der Daten gegenüber dem letzten Backup erkennen, müssen zwischen dem primären Server-Standort und dem langfristigen Backup-Speicher nur noch die Deltas verschoben werden. Damit entsteht ein granulares, inkrementelles Konzept für die Datensicherung, das unabhängig von der eingesetzten Anwendungen nutzbar ist.

Mit der Snapshot-Technologie erfolgt das Backup einer HANA-Umgebung in nur wenigen Sekunden. Wie eine von NetApp unter SAP-HANA-Bestandskunden durchgeführte Analyse gezeigt hat, liegt die Zeit für ein Hana-Snapshot-Backup bei durchschnittlich 19 Sekunden. Viele NetApp-Kunden schaffen dies auch in kürzerer Zeit und in maximal einer Minute waren selbst die komplexesten Backups durchgelaufen. Der spürbare Zeitgewinn wird umso deutlicher, je größer die HANA-Datenbank ist, weil die Backup-Zeiten unabhängig von der Datenbankgröße weitgehend identisch sind. Der Grund: Die von NetApp entwickelte Technologie arbeitet mit „Verpointerung“, es werden also keine Daten physikalisch verschoben.

Wer mit einer klassischen Backup-Infrastruktur vergleichbar kurze Zeiten erzielen möchte, der müsste eine Vielzahl von Gigabit-Ethernet-Anbindungen vorsehen – inklusive einer hierfür geeigneten Systemarchitektur. Auch eine Wiederherstellung kann der Datenbank-Administrator entsprechend schnell einspielen. Hierfür muss lediglich SAP HANA gestoppt und das gewünschte Backup ausgewählt werden. Anstatt Daten danach langwierig zurückzuspielen, wird im NetApp-System ein früheres Abbild der SAP-HANA-Daten aktiviert (sogenannter SnapRestore) und HANA kann direkt wieder anlaufen.

SAP HANA-Zertifizierung

Das Thema Zertifizierung ist bei SAP HANA sehr wichtig. Es dürfen nur zertifizierte Systeme eingesetzt werden – ansonsten arbeitet man in einer nicht supporteten Umgebung. Das stellt bei einem Produktivbetrieb eines unternehmenskritischen Systems keine Option dar. In den Labors von SAP wird zusammen mit den Hardware-Herstellern zertifiziert. Dabei sind die Vorgaben seitens SAP recht hoch. Zudem kommt noch ein Aspekt dazu: Wer an einer zertifizierten Konfiguration „zuviel“ ändert, der arbeitet bereits in einer nicht zertifizierten Umgebung.

Generell definiert SAP zwei Ausprägungen bei HANA: Zum einen eine HANA-Appliance und zum anderen die HANA TDI (Tailored Datacenter Integration). Bei der SAP HANA Appliance handelt es sich um eine von SAP zertifizierte Kombination aus Server/Netzwerk und Storage. Dabei werden alle Komponenten (Prozessorgeneration, Anzahl der Cores, Speicherausbau, etc.) genau spezifiziert, und auch die Vorgaben an den Betrieb sind rigoros: Man darf zum Beispiel nur HANA darauf laufen lassen, keine anderen Workloads. Für genau diese Umgebung mit den zertifizierten Komponenten garantiert SAP dann auch die entsprechenden Key Performance Indicators (KPI). In der SAP HANA PAM (Product Availability Matrix) sind die Produkte aufgeführt. Hier gelten die Vorgaben/KPI der SAP, Abweichungen sind nicht erlaubt. Zum Beispiel haben Cisco und NetApp auch eine dedizierte SAP HANA-Appliance vorgestellt.

Als zweites gibt es die TDI-Version, die „Tailored Datacenter Integration“. Damit kann man prinzipiell mehrere Kombinationen fahren. Sie ist gedacht, damit Unternehmen unter Umständen andere Hardware-Konfigurationen nutzen können. Man benötigt zwar zertifizierten Storage und einen zertifizierten Server-Anteil, ist ansonsten aber flexibler. Allerdings muss SAP dann auch diese Konfiguration zertifiziert haben. Da diese Variante im IT-Betrieb flexibler zu handhaben ist, nutzt der Großteil aller Anwenderunternehmen, die HANA bislang einsetzen, diese Variante.

Neben der größeren Flexibilität bei der Hardware-Auswahl können Unternehmen auch bestehende Hardware und Anwendungen kombiniert nutzen. Als Virtualisierungsschicht wird allerdings nur der VMware-Hypervisor unterstützt. Man darf aber auch mehrere HANA-Instanzen mit TDI betreiben. Üblicherweise wird „HANA TDI“ beim Anwender vor Ort installiert, basierend auf einem Abnahmetest der SAP oder eines entsprechend zertifizierten SAP-Partners. Verantwortlich für den Support der HANA TDI ist das Anwenderunternehmen selbst. Nach erfolgreicher Abnahme der Konfiguration übernimmt SAP auf Wunsch den Support. Mit TDI ist das Verteilen von verschiedenen Workloads auf die Systemressourcen erlaubt, jedoch müssen entsprechend die SAP KPI für das HANA-System erfüllt sein.

Flexpod und SAP HANA

Beim Flexpod-Ansatz handelt es sich um eine konvergente Infrastruktur. Alle Komponenten – Server, Storage, Netzwerk und Verwaltungs-Werkzeuge – sind aufeinander abgestimmt und entsprechen den Vorgaben an ein „Cisco Validated Design“. Damit steht eine ideale Basis für den Betrieb von SAP HANA zur Verfügung. Um die Inbetriebnahme des Systems schnell ablaufen zu lassen, gibt es einen Installation Guide für alle Aufgaben. Zudem haben die Anwender ein Support-Modell für den kompletten Hardware-Stack und die Hypervisor-Ebene: Entweder NetApp, Cisco oder VMware sind der „Single Point of Contact“.

Da im Flexpod-Stack die Storage-Schicht von NetApp stammt, sind auch alle NetApp-Spezialitäten nutzbar. Als wesentliche Pluspunkte sind hier das extrem schnelle Backup und die sehr kurzen Wiederherstellungszeiten zu nennen. Dazu gehören aber auch die asynchrone und synchrone Spiegelung von HANA. Stand heute ist nur NetApp in der Lage, einen Storage-basierten asynchronen Spiegel zu unterstützen.

Zudem gibt es bei NetApp den in das HANA-Studio integrierten Storage-basierten Snapshot. Knopf im HANA-Backup-Tool wird gedrückt und nach 19 Sekunden (im Durchschnitt) ist ein komplettes Backup der HANA-Datenbank erstellt. Die Größe der Datenbank ist dabei nicht ausschlaggebend. Entsprechende Vorteile ergeben sich auch beim Restore. Für die Anwender hat das zur Folge, dass sie öfter ein Backup machen können und somit werden beim Recovery die wiederherzustellenden Datenmengen geringer sind. Zudem läuft die Wiederherstellung schneller ab.

Anwender im SAP-Umfeld profitieren aber auch beim Aufbau von Test/Dev-Umgebungen von den NetApp-Spezialitäten: Basierend auf den Read-Only-Snapshot, den man dann über die Cloning-Funktionalitäten beschreibbar macht, können sie aus einem bestehenden Backup des Produktivsystems ein  Qualitätssicherungs- Test- oder Sandbox-System in Minutenschnelle erzeugen. (rhh)