Installation und Administration von SAP HANA

SAP HANA ist eine Data-Warehouse-Appliance für die Verarbeitung großer Mengen operationaler und transaktionaler Daten in Echtzeit. HANA ist eine In-Memory-Lösung, bei der die Daten nicht von einem persistenten Speichermedium, sondern aus dem Hauptspeicher des Systems bearbeitet werden.

CONET verfügt mittlerweile über eine eigene Appliance zur Schulung der eigenen Mitarbeiter, sowie als Referenz und zur Entwicklungsumgebung für Kundenprojekte. In diesem Beitrag geben wir Ihnen einen Einblick, wie diese eigene HANA-Appliance installiert und administriert wird.

Was ist HANA

HANA unterstützt Industriestandards, wie „Structured Query Language“ (SQL) und „Multi-Dimensional eXpressions“ (MDX). Es enthält außerdem eine Entwicklungsumgebung, die es Entwicklern ermöglicht, eigene Anwendungen aus Basis von HANA zu entwickeln und zu nutzen. Nach Angaben von SAP besitzt HANA die Fähigkeit, 500 Milliarden Point-of-Sale- (POS-) Datensätze in Sekunden zu scannen. SAP HANA stand ursprünglich für „SAP High Performance Analytic Appliance“ ist aber heutzutage ein gängiger Produktname.

HANA als Cloud-Lösung
Die SAP HANA Cloud Platform ist eine „Platform-as-a-Service“ (PaaS) und wird sowohl von SAP als auch von unabhängigen Unternehmen wie z.B. Amazon als Cloud-Lösung angeboten. Kunden können SAP HANA verwenden, um HANA-basierte Cloud-Applikationen zu erstellen und zu testen, ohne über ein eigenes System verfügen zu müssen. Auf Cloud-Lösungen wird in diesem Beitrag allerdings nicht weiter eingegangen.

HANA als Appliance
Für die ersten Releases verfolgte SAP einen sehr strengen Ansatz bezüglich der Kontrolle der Erstkonfiguration und der späteren Verwaltung des zugrunde liegenden Betriebssystems und der verwendeten Hardware. Klassischer Weise werden SAP-HANA-Appliance von den zertifizierten SAP-HANA-Hardwareanbietern zusammen mit dem installierten Betriebssystem und der HANA Software vorkonfiguriert ausgeliefert.

Mittlerweile wurden die Voraussetzungen für die Installation und Konfiguration des Betriebssystems erheblich gelockert. Voraussetzung hierfür ist allerdings die SAP Zertifizierung „SAP Certified Technology Specialist (Edition 2013) – SAP HANA Installation“. Gerade im Umfeld nichtproduktiver Systemlandschaften (Sandbox-/Demosysteme) ergeben sich hier erheblich kostengünstigere Möglichkeiten als bei einer SAP-HANA-Appliance von einem zertifizierten SAP-HANA-Hardwareanbieter.

Betriebssysteme
Ursprünglich wurde HANA zusammen mit Novell SuSE auf Linux und einigen Hardwarepartnern entwickelt, so dass es zunächst nur für den SLES 11 verfügbar war. Seit Revision 08 ist der SAP HANA Database Server auch auf RedHat Rel 6.5 verfügbar. Weitere Betriebssystemversionen sind in Vorbereitung.

Für die SAP Anwendungen sind Database-Clients für folgende Betriebssysteme verfügbar:
• AIX
• HP-UX
• Linux (SUSE/RedHat)
• OS/400
• SOLARIS
• Windows

Virtualisierung
VMware hat zusammen mit SAP ein Virtualisierungs-Modul für die In-Memory-Technologie von SAP entwickelt. Dadurch ergeben sich für SAP HANA neue Anwendungsmöglichkeiten, wenn man HANA in eine bereits vorkonfigurierte virtuelle Maschine installiert.

Vorausgesetzt ist VMware vSphere 5.5. sowie entweder eine SAP-Zertifizierte Appliance, die von Hardware-Herstellern für SAP HANA entwickelt worden ist, oder eine Zertifizierung von Hardware, die für HANA-Umgebungen geeignet ist. Außerdem müssen Kunden auf die Einhaltung der SAP-Regeln für virtualisierte HANA-Umgebungen achten. Dazu gehören derzeit unter anderem die Begrenzung auf eine einfache virtuelle Maschine (keine Scale-out-Unterstützung) und die Vermeidung von CPU- und Memory-Over-Provisioning.

Landschaft und Installation bei CONET

Zur Schulung der eigenen Mitarbeiter, als Referenz und zur Entwicklung für Kundenprojekte wurde bei CONET Mitte 2014 eine eigene SAP HANA-Systemlandschaft angeschafft. Sie besteht aus einer Fujitsu Midsize Appliance mit 256GB Memory (basierend auf SLES11 SP3) für ein jeweils verteilt installiertes BW 7.4 bzw. ERP 6.0 EhP7.

Installation
In Produktiven Umgebungen darf nur eine produktive Datenbank auf einer Applicance installiert werden. Für nichtproduktive Systeme besteht die Möglichkeit entweder mehrere Datenbankinstanzen auf einer Appliance oder mehrere Schemas für mehrere Anwendungssysteme innerhalb einer Datenbankinstallation zu betreiben.

Um die beiden Systeme so unabhängig wie möglich zu betreiben, wurden je eine DB-Instanz für das BW und für das ERP-System auf einer gemeinsamen Appliance installiert (Multiple DB on one host).

Die Speicherverwaltung der einzelnen DB-Instanzen ist so konfiguriert, dass jede DB nur einen ihr zugewiesenen Maximalwert belegen darf (BW 100GB, ERP 130GB) .

Die Anwendungsserver wurden als „verteilte Systeme“ (also Systemkomponenten die nicht auf einem einzigen Host installiert sind) auf einer jeweils eigenen virtuellen Maschine auf Basis VMware vSphere 5.5 unter dem Betriebssystem Windows Server 2008R2 installiert.

Bei dem BW-System handelt es sich um eine Neuinstallation auf Basis Netweaver 7.4 . Das ERP-System wurde aus einem bestehenden ERP 6.0 EhP7 basierend auf Oracle migriert.

Nennenswert hier ist, dass durch die Migration von Oracle nach HANA die Datenbankgröße um ca. 30% reduziert werden konnte, obwohl die Oracle Datenbank vor der Migration bereits reorganisiert war. Im Wesentlichen liegt das daran, dass die Datenbankdaten bereits komprimiert in der Datenbank abgelegt sind und erst bei der Verarbeitung durch den Kernel-Prozess in Echtzeit entpackt werden.

Administration
Die Administration von SAP HANA unterscheidet sich nicht wesentlich von anderen Datenbanken. Neben detaillierten Betriebssystemkenntnissen und der grundsätzlichen Funktionsweises einer Datenbank sind hier allerding spezielle Kenntnisse der Speicherverwaltung erforderlich. Diese sind insbesondere bei der Fehler- und Performanceanalyse notwendig.

Die Zentrale Administrations- und Entwicklungskonsole für SAP HANA ist das „SAP HANA Studio“. Hierbei handelt es sich um ein auf Eclipse basierendem Management Werkzeug, welches sowohl für Linux als auch für Windowssysteme verfügbar ist.

Die Routineadministrationsaufgaben für SAP HANA umfassen folgende Bereiche:

• SAP HANA Betrieb
Aktivitäten, die entweder regelmäßig oder nach Bedarf von Systemadministratoren ausgeführt werden, wie Monitoring, Datensicherung und Wiederherstellung oder Datenarchivierung.

• SAP-HANA-Administration
Vorgehensweisen zur Konfiguration, Verwaltung, Pflege und Optimierung Ihrer SAP-HANA-Installation, einschließlich Backup und Wiederherstellung.

• SAP-HANA-Datenbanksicherheit
Sicherheitsaspekte von SAP-HANA-Appliance-Software und der SAP-HANA-Datenbank.

Life Cycle Management
SAP stell Korrekturen und Updates für die SAP-HANA-Plattform und alle dazugehörigen Komponenten als SAP-HANA-Revisionen, SAP-HANA-Wartungsrevisionen und dem SAP HANA Datacenter Service Point zur Verfügung. Darüber hinaus werden „Support Package Stacks“ zwei Mal jährlich ausgeliefert und enthalten neben Fehlerkorrekturen auch neue Funktionen.

Revisionen/Wartungsrevisionen enthalten nun Korrekturen bezogen auf das Basis-Support Package Stack. Ein SAP HANA Datacenter Service Point stellt ein Support Package Stack mit einer konkreten Revision dar, die sich im Rahmen des Qualitätsmanagements als stabil etabliert hat und somit die Empfehlung für Produktivsysteme darstellt.

Das Werkzeug zur Installation, Konfiguration und Upgrade einer SAP-HANA-Plattform ist der HANA Lifecycle Manager. Für Produktivsysteme stellt SAP ein Revision Update mit „SAP HANA Zero Downtime Maintenance“ zur Verfügung, bei der ein Upgrade ohne Produktivunterbrechung möglich ist. Die Aktuelle Revision der HANA-Datenbank bei CONET ist SPS09 Rev 93.

Monitoring
Neben den Monitoringmöglichkeiten des SAP HANA Studios ist es ratsam, eine HANA Datenbank mittels SAP Solutionmanager zu überwachen. Hierbei wird die HANA Datenbank sowohl über das DBA-Cockpit der Anwendung auf HANA, den SAP Standard Diagnostics-/Hostagent, als auch über eine separate DB-Clientverbindung zum Solutionmanager selbst angebunden. Daraus ergeben sich umfangreiche Monitoring- und Analyseszenare wie z.B. Ursachenanalyse, Technisches Monitoring, Business-Process-Monitoring und Early-Watch-Alerting. Mit dem aktuellen Supportpackagelevel (SP13) des SAP Solutionmanagers werden bereits im Standardumfang mehr Templates ausgeliefert, als es für die bisherigen Standard-Datenbanksysteme der Fall war.

Über den Autor

Senior Consultant | Beiträge

Rüdiger Platzek war als Senior Consultant im Bereich „SAP NetWeaver Development & Administration” bei der CONET Business Consultants GmbH tätig.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert