SAP BW auf HANA – Migration und Planung der Systemlandschaft

Viele unserer Kunden beschäftigen sich derzeit mit der Frage, wie eine kostenoptimierte Migration der bestehenden BW Landschaft auf SAP BW on HANA bewerkstelligt werden kann. Eine Antwort darauf zu finden war vor Beginn unseres ersten Kundenprojektes zur Migration von BW auf HANA im letzten Jahr eine der ersten Herausforderungen. So galt es insbesondere zu klären welche Kosten neben den eigentlichen Lizenzkosten zu erwarten sein werden und wie ein Vorgehensmodell aussehen kann. Aus diesem Grund möchte ich in einem ersten Erfahrungsbericht praxisnah auf die Planung der Systemlandschaft, insbesondere im Hinblick auf die Anschaffungskosten eingehen.


Kosten einer BW on HANA Installation

Die Kosten für die Installation von SAP BW on HANA setzen sich wie bei jeder Installation aus Hardware- und Softwarelizenzkosten, den Migrationsaufwand und den laufenden Betriebskosten zusammen. Hat man diese Kosten ermittelt, muss man den Nutzen eines BW on HANA dagegen halten und sich für oder gegen eine Migration entscheiden. Wie ermittelt man nun konkret die zu erwartenden Kosten? – Wie kann man die Kosten optimieren? In diesem Blogbeitrag beschäftige ich mich zunächst mit Anschaffungskosten, d.h. den Hardware und Softwarelizenzkosten.


Bedarfsanalyse

Über eine Bedarfsanalyse muss zunächst ermittelt werden, wie viel Speicherplatz nach der Migration in der SAP HANA Datenbank benötigt wird. Auf dieser Basis kann entschieden werden, welche HANA Appliance angeschafft werden muss und wie viele HANA Lizenzen abgenommen werden müssen.

Grundsätzlich wird SAP HANA als Appliance erworben von zertifizierten Hardware Herstellern. Dies bedeutet SAP HANA ist bereits auf der Hardware vorinstalliert. Deshalb spricht man auch oft von einer HANA Box. Eine aktuelle Übersicht der zertifizierten HANA Appliances kann der Product Availability Matrix (PAM) entnommen werden. Meistens ist der Hardwarelieferant durch Konzernrichtlinien vorgegeben. Wenn dies nicht der Fall ist, dann sollte man auf jeden Fall die Angebote und der darin enthaltenen Services der Hersteller vergleichen.

Die Hardware- und Softwarelizenzkosten stellen den größten Teil der Investition dar. Aus diesem Grund ist es sehr wichtig, dass man hier nicht nur den aktuellen Bedarf ermittelt, sondern auch das Datenwachstum und Optimierungsmöglichkeiten in die Bedarfsanalyse mit einbezieht.


Ermittlung des Datenvolumens

Für die Ermittlung des aktuellen Bedarfs kann als erster Anhaltspunkt die aktuelle Größe der produktiven BW Datenbank herangezogen werden. Das zu erwartende Datenwachstum kann durch die Analyse des bisherigen Datenwachstums ermittelt werden. Gegebenenfalls müssen aktuelle Projekte deren Go-Live geplant ist sowie zukünftig geplante Applikationen und deren zu erwartende Datenvolumen berücksichtigt werden.

Hat man das zukünftig erwartende Datenvolumen in einer traditionellen Datenbank ermittelt, kann man davon ausgehen, dass sich das Datenvolumen des SAP BW on HANA um ca. 40-60% reduziert auf Grund der spaltenbasierte Speicherung der Daten und der daraus resultierenden Komprimierung. Dies bestätigte auch unsere Neuinstallation des BW auf HANA. Üblicherweise muss man ca. 30 GB für eine Neuinstallation mit Basiskonfiguration veranschlagen. Die Installation auf einer HANA Datenbank benötigte dagegen lediglich ca. 15 GB.


SAP BW on HANA Speicherverbrauch


Optimierung des Datenvolumens

Das Datenvolumen hat einen signifikanten Einfluss auf die Kosten, daher ist es naheliegend die Optimierungsmöglichkeiten des Datenvolumens zu analysieren. Zunächst einmal sollte man die Anwendungen im BW überprüfen, ob diese überhaupt noch genutzt werden. Leider stellt man oftmals erst bei dieser Analyse fest, dass es Applikationen im SAP BW gibt, die nicht mehr vom Fachbereich genutzt werden. Diese Anwendungen wurden oftmals nicht abgeschaltet und gelöscht, weil sich niemand dafür verantwortlich fühlt und auch meistens aus Kostensicht nicht die Notwendigkeit vorhanden war diese abzuschalten, da Plattenplatz kein Kostentreiber mehr darstellt.

Zusätzlich ist zu empfehlen die Architektur der Applikationen insbesondere in Bezug auf die Layered Scalable Architecture (LSA) zu analysieren. Vorberechnungen auf Grund langer Query Laufzeiten sind sehr häufig durch den Einsatz von SAP HANA nicht mehr notwendig. Generell sollte man mit dem Wechsel über den Wegfall der Layer nachdenken, die lediglich aus technischen Gründen der bisherigen Datenbanktechnologie realisiert wurden. Dies reduziert die Komplexität als auch das Datenvolumen. Im Rahmen der Analyse sollte auch überprüft werden, ob die täglichen Housekeeping Jobs regelmäßig durchgeführt werden. Unter anderem gehören hier das regelmäßige Löschen der nicht mehr benötigten IDOCs und das Löschen bereits verbuchter Datensätze aus der PSA der Staging Area. Ebenfalls muss überprüft werden, ob die BI Statistiken überhaupt verwendet werden und wenn ja, ob der derzeit eingestellte Wert (Standardwert entspricht 14 Tage) überhaupt benötigt wird.

Ebenfalls muss überprüft werden, ob Daten vorgehalten werden, die nicht mehr oder sehr selten benötigt werden. Auch sollte eine Archivierung der Daten in Betracht gezogen werden solange SAP HANA alle Daten im Arbeitsspeicher hält und dieser zeitgleich Kostentreiber für Hardware und Softwarekosten darstellt. Zukünftig soll SAP HANA die Möglichkeit bieten Daten zu trennen in Cold and Hot Data (voraussichtlich mit SP4 in Q2/2012), d.h. selten benötigte Daten werden bspw. auf Solid State Disks (SSD) und somit kostengünstigeren Speicher vorgehalten und sehr oft benötigte Daten werden im Arbeitsspeicher vorgehalten. Dies wird ganz gut im In-Memory Blog des Hasso-Plattner-Institut beschrieben.


Bisherige BW Landschaft als Fallback System

In der klassischen SAP drei Systemlandschaft kann man davon die Anforderungen für das Entwicklungs- und Qualitätssicherungssystem ableiten, allerdings ist hier auf die Empfehlung der SAP im End-to-end Implementation Roadmap für SAP NetWeaver BW 7.3 powered by SAP HANA zu verweisen. Stand heute empfiehlt die SAP nämlich einen Parallelbetrieb der bestehenden SAP BW Landschaft mit traditioneller Datenbank und SAP HANA in der End-to-end Implementation Roadmap für SAP NetWeaver BW 7.3 powered by SAP HANA .


„SAP strongly recommends you to follow a parallel approach in which you keep your production landscape in place for the time being as a fallback. You can implement SAP NetWeaver BW scenario by scenario, with the assurance that the existing production landscape is still available as a fallback if required. This approach greatly mitigates risk while simultaneously enabling you to familiarize yourself with the administration and capabilities of SAP HANA. SAP strongly recommends that you consider the high availability and backup/recovery procedures of SAP HANA before starting to use it in production systems.”

Dies bedeutet für den Kunden zunächst das zusätzliche Kosten durch den Betrieb und Wartung der zwei BW Systemlandschaften entstehen und ggf. zusätzlicher Entwicklungskosten wenn Projekte auf Basis der traditionellen Datenbank und SAP HANA umgesetzt werden. Vermutlich wird sich dies ändern wenn SAP BW on HANA den GA Status hat, jedoch muss man berücksichtigen, dass derzeit nur der ABAP AS die SAP HANA Datenbank unterstützt, d.h. wenn man den Java AS bspw. für BI Java einsetzt, wird weiterhin eine traditionelle Datenbank benötigt. Dies wird sich sicherlich mittelfristig ändern, da die SAP bis 2015 anstrebt die Nummer 2 im Datenbankmarkt zu werden und auch die Ankündigung, dass das SAP ERP bis Jahresende auf der SAP HANA Datenbank läuft bestärkt diese Vermutung.


Zusammenfassung

Zusammengefasst kann gesagt werden, dass basierend auf dem zu erwartenden Datenvolumen, den möglichen Einsparpotential durch Abschaltung nicht benötigter Applikationen, Housekeeping Jobs, Reduzierung von technisch bedingten Layern, einer Datenarchivierung und der Komprimierung durch HANA die benötigte Hardware und Softwarelizenzen ermittelt werden kann. Nachdem man sich mit den Anschaffungskosten auseinandergesetzt hat, sollte man sich als nächstes mit dem Aufwand für die Migration des bestehenden SAP BW basierend auf einer traditionellen, relationalen Datenbank nach SAP BW on HANA beschäftigen. Dies wird in einem weiteren Blogbeitrag aufgegriffen.

Getagged mit: , , , , , , , , ,

Schreibe einen Kommentar

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

*

*