Wie sich Organisationen auf die SAP-HANA-Installation vorbereiten

Die Implementierung von SAP HANA erfordert ausreichend Vorbereitung und die richtige Planung der Hardware-, Backup- und Support-Anforderungen.

Kunden, die von einer Proof-of-Concept-HANA-Anwendung zu einer produktiven On-Premises-Installation wechseln, müssen eine Vielzahl von Punkten berücksichtigen. Dazu zählen unter anderem, dass sie ihre Systemlandschaft auf die In-Memory-Datenbankplattform vorbereiten, sie einen Hardwareanbieter sowie Backup- und Recovery-Pläne auswählen und die Security verwalten müssen. Doch wo beginnt man?

Als erstes muss man verstehen, dass SAP HANA keine Black Box ist. HANA läuft auf Basis eines Linux-Betriebssystems auf einem Stück Hardware mit viel Arbeitsspeicher. Und es ist mehr als eine SQL-92-kompatible In-Memory-Datenbank. SAP HANA wird von SUSE Linux Enterprise Server (ab SLES 11) und Red Hat Enterprise Linux (ab RHEL 6.5) unterstützt. SAP-Kunden können sich unter anderem über den SAP HANA Reference Guide über aktuell unterstützte Versionen und Betriebssysteme informieren.

SAP HANA ist außerdem ein Applikationsserver, allerdings kein SAP NetWeaver Application Server wie traditionelle ABAP- oder Java-Stacks, die SAP-Anwender bereits kennen. Es ist ein schlanker Web-Applikationsserver, der in der Lage ist, leistungsstarke Web-Apps in SAPUI5 oder einfachen JavaScript zu betreiben. Der Name des Web-Applikationsservers ist XS Engine.

Auf Hardwareseite gibt es die Möglichkeit, aus einer Reihe von Anbietern auszuwählen. Seit einigen Jahren ermöglicht SAP seinen Kunden, eigene Hardware für den Einsatz mit HANA-Lizenzen einzusetzen. Dabei müssen Kunden die richtige Mischung an Hardwarespezifikationen haben (unter anderem Arbeitsspeicher, Solid-State Drives für Protokolldateien, schnelle Laufwerke für Daten sowie ein korrektes Verhältnis von Arbeitsspeicher und CPU-Kernen), allerdings hat SAP die strikten Hardwarevorgaben für HANA mittlerweile aufgeweicht. Das SAP HANA Hardware Directory listet unterstützte Hardware auf.

SAP erlaubt seinen Kunden außerdem, eigene HANA-Installationen auszuführen. Zusätzlich ist VMware vSphere (ab vSphere 5.5 oder höher) für SAP HANA 1.0 (ab SPS 07 oder höher) und 2.0 zertifiziert. Unterstützt werden hierbei maximal vier TB RAM pro virtuelle Maschine. Die Kombination aus Virtualisierungsoptionen und unterstützten Hardwaremix stellt Kunden verschiedene Backup- und Recovery-Optionen zur Verfügung.

Plant man eine HANA-Landschaft, lässt sich eine traditionelle Dreisystemlandschaft einsetzen, in der jede Instanz von den Aktivitäten der anderen isoliert ist: Zum Beispiel kann man für jede Softwareentwicklungskomponente einen Hardwareteil verwenden – jeweils einen für Entwicklung, Qualitätssicherung und Produktion.

HANA bietet die Möglichkeit, mehr als eine HANA-Datenbank pro Server zu unterstützen. Zum Beispiel lässt sich ein Hardwareteil für Sandbox und Entwicklung verwenden, während man einen anderen Teil für Qualitätssicherung und Training einsetzt.

SAP HANA ermöglicht außerdem verteilte Installationen, in denen es Master- und Arbeitsknoten gibt. So lässt sich einfach eine Umgebung in der Qualitätssicherung einrichten, um verschiedene Szenarien zu vergleichen, in denen mehrere Knoten im produktiven Einsatz sind. Zum Beispiel können zwei Knoten eine einzige HANA-Entwicklungsinstanz und eine verteilte Instanz der Qualitätssicherung unterstützen.

Bei der Hardwareplanung für eine Produktionsumgebung müssen ebenfalls Backup-Strategien und Disaster-Recovery-Anforderungen berücksichtigt werden. Ein Beispiel sind „aktiv-aktiv“ Umgebungen, bei denen beide Hosts Anfragen akzeptieren. Fällt ein Host aus, lassen sich Client-Verbindungen sofort wiederherstellen. Innerhalb einer HANA-Umgebung stellt SAP diese Cluster-Konfiguration aber nicht zur Verfügung. SAP bietet ein automatisches Host-Failover, das DNS-Änderungen erfordert, die auch automatisiert werden können. Dies findet zwar nicht sofort statt, ist aber sehr schnell.

Anwenderunternehmen können ein repliziertes Standby-System verwenden, welches ein Failover innerhalb von Minuten ermöglicht – dies ist allerdings nicht die Hochverfügbarkeit, wie sie von NetWeaver bekannt ist. In einem replizierten Standby-Datenbankszenario sollte man sich zwei wichtige Punkte in Erinnerung rufen: Zum einen müssen Client-Datenbank-Abfragen über DNS-Änderungen im Falle eines Failovers neu übermittelt werden. Zum anderen kann man die Standby-Datenbank als nicht-produktive Datenbank für eine andere Instanz verwenden, zum Beispiel für die Qualitätssicherung und Tests.

SAP bietet viel Flexibilität mit seinem Standby-Datenbankszenario. Dabei hat der Softwareanbieter darauf Wert gelegt, dass Kunden die Hardware optimal verwenden können, so dass man keine Leerlaufmaschinen im Rechenzentrum stehen hat.

Die Arbeit mit HANA-Backups sollte jedem Data-Center- oder IT-Leiter vertraut sein. Die Datenbank und Protokolldateien müssen regelmäßig gesichert werden, um eine unmittelbare Wiederherstellung zu ermöglichen. Backups lassen sich standardmäßig über SAP HANA Studio oder auf Kommandozeilenebene im Betriebssystem ausführen.

Daneben setzen Kunden auf verschiedene zertifizierte Backup-Partner, zum Beispiel Symantec, IBM und HP. Die spezifische Zertifizierung, die Partner für die Sicherung von SAP HANA erreichen müssen, heißt HANA-BRINT 1.1. Bei der Suche nach HANA-BRINT 1.1 findet man innerhalb des SAP-Angebots zahlreiche Backup-Produkte.

Die Systemlandschaft für HANA strukturieren

Nachdem die Grundzüge von HANA bekannt sind, lauten die nächsten Fragen: Wie muss man seine Systemlandschaft strukturieren und wie sichert man diese ab? Die Implementierung von HANA wirkt sich auf interne Ressourcen aus.

Aus Administrationsperspektive sollten sich SAP-Basis-Administratoren relativ einfach auf die HANA-Administration umstellen können, wenn diese bereits Erfahrung mit UNIX-Plattformen haben.

Das Look and Feel des Installationsprozesses erinnert an SAP. Man muss HANA mit dem SAP Solution Manager für den Enterprise Support verbinden, was eine übliche Basis-Aufgabe ist, die man in einer SAP-NetWeaver-Installation ebenfalls erledigt. SAP-Basis-Administratoren werden die Technologie daher begrüßen, da es keine fundamentale Umstellung für sie bedeutet. Der Einsatz einer In-Memory-Datenbank fügt allerdings der Systemüberwachung eine weitere Dimension hinzu, wobei SAP Tools für die Echtzeit- und historische Leistungsanalyse bereitstellt.

Das Security Management von SAP HANA stellt für Kunden, die derzeit ein Team für die Anwendungssicherheit der SAP Business Suite oder einer anderen NetWeaver-Anwendungen haben, eine der größten Veränderungen dar. Verwendet man NetWeaver BW oder die SAP Business Suite on HANA, wird sich das Security-Team kaum umstellen müssen. Entscheidet man sich hingegen dafür, HANA als eigenständiges Data Warehouse oder als Applikationsserver einzusetzen, wird das Sicherheitsteam einige Zeit für die Umstellung benötigen.

Die Frage, wer für die HANA-Sicherheit verantwortlich ist und diese managt, ist weiterhin umstritten. In der traditionellen Welt der Datenbank-Management-Systeme (DBMS) ist der Datenbank-Administrator neben der Datenbankverwaltung für die Sicherheit zuständig. In SAP-NetWeaver-Umgebungen ist das Sicherheits-Management auf Datenbankebene nur eine Randaufgabe, da SAP die Sicherheit auf Anwendungsebene verwaltet.

In einem eigenständigen Data-Warehouse-Szenario muss man sich allerdings durch das Unternehmen oder die Vertriebsorganisation autorisieren lassen. Basis-Admins sind gut in ihrer eigentlichen Arbeit, aber sie sind selten gut in der Sicherheitsadministration. Wenn ein Kunde mit dem produktiven Einsatz von HANA konfrontiert ist, muss er interne Erfahrungen und Anforderungen genau studieren, um bestimmen zu können, wer die HANA-Security-Administration übernimmt.

Ein letzter Punkt, den Kunden vergessen oder falsch verstehen könnten, ist die Verwendung des SAP Solution Managers im Zusammenhang mit HANA. Der Solution Manager ist nach wie vor der einzige Mechanismus für HANA Early Watch Reports und Mittel für SAP Continuous Quality Checks, die Teil jedes Standard oder Enterprise SAP-Wartungsvertrags sind.

Kunden, die erheblich in eine HANA-Implementierung investieren, sollten die Vorteile des Verifizierungsdienstes SAP GoingLive Check ausnutzen, bevor sie in den Live-Betrieb gehen. Der Solution Manager ist immer noch das Tor zum SAP-Support. Gekoppelt mit seinen proaktiven Monitoring-Funktionen – im Rahmen der Solution Manager Technical Operations – sollte der Solution Manager Teil jedes HANA-Deployment-Plans sein.

Die Implementierung von HANA ist spannend, und es müssen offensichtlich einige Herausforderungen gemeistert werden. Doch mit gemeinsamer Arbeit und dem Austausch von Wissen hat eine neue Implementierung gute Chancen, die vorhandene SAP-Landschaft zu ergänzen.

Über den Autor:
Michael Pytel ist Chief Innovation Officer und Mitbegründer des Beratungshauses NIMBL. Pytel ist außerdem Autor verschiedener SAP-Publikationen, die im Rheinwerk Verlag erschienen sind.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!

Artikel wurde zuletzt im August 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Essential Guide

In-Memory Analytics mit SAP HANA: Die Power von Echtzeitanalysen

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close