33
183 Bevor Sie mit einer SAP-HANA-Implementierung beginnen können, müssen Sie zunächst einmal die Hintergründe und Zusammenhänge verstehen lernen. In diesem Kapitel werden Sie daher alle dafür erfor- derlichen Informationen erhalten. 6 Planung einer SAP-HANA- Implementierung In diesem Kapitel werden Sie mehr über die Planung einer SAP-HANA- Implementierung erfahren. Zunächst erhalten Sie einen Überblick über die SAP-HANA-Umgebung und die von der Implementierung unabhängigen Optionen. Anschließend erfahren Sie, wie SAP-HANA-Implementierungen für ein Data Warehouse, SAP Business Suite auf SAP HANA und SAP BW auf SAP HANA umgesetzt werden. 6.1 Von der Implementierung unabhängige Überlegungen Bevor Sie eine bestimmte SAP-HANA-Implementierung planen, sollten Sie einige allgemeine Informationen in Betracht ziehen. In diesem Abschnitt erläutern wir die unterschiedlichen SAP-HANA-Editionen sowie einige Optionen zur Auswahl der Hardware für SAP HANA. 6.1.1 SAP-HANA-Editionen SAP hat drei unterschiedliche Editionen von SAP HANA entwickelt, die Sie allerdings nicht mit den drei unterschiedlichen Implementierungsoptionen verwechseln sollten, die in Kapitel 2 erörtert wurden: SAP HANA Appliance Software Platform Edition SAP HANA Appliance Software Enterprise Edition SAP HANA Appliance Software Enterprise Extended Edition

6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Embed Size (px)

Citation preview

Page 1: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

183

Bevor Sie mit einer SAP-HANA-Implementierung beginnen können,müssen Sie zunächst einmal die Hintergründe und Zusammenhängeverstehen lernen. In diesem Kapitel werden Sie daher alle dafür erfor-derlichen Informationen erhalten.

6 Planung einer SAP-HANA-Implementierung

In diesem Kapitel werden Sie mehr über die Planung einer SAP-HANA-Implementierung erfahren. Zunächst erhalten Sie einen Überblick über dieSAP-HANA-Umgebung und die von der Implementierung unabhängigenOptionen. Anschließend erfahren Sie, wie SAP-HANA-Implementierungenfür ein Data Warehouse, SAP Business Suite auf SAP HANA und SAP BW aufSAP HANA umgesetzt werden.

6.1 Von der Implementierung unabhängigeÜberlegungen

Bevor Sie eine bestimmte SAP-HANA-Implementierung planen, sollten Sieeinige allgemeine Informationen in Betracht ziehen. In diesem Abschnitterläutern wir die unterschiedlichen SAP-HANA-Editionen sowie einigeOptionen zur Auswahl der Hardware für SAP HANA.

6.1.1 SAP-HANA-Editionen

SAP hat drei unterschiedliche Editionen von SAP HANA entwickelt, die Sieallerdings nicht mit den drei unterschiedlichen Implementierungsoptionenverwechseln sollten, die in Kapitel 2 erörtert wurden:

� SAP HANA Appliance Software Platform Edition

� SAP HANA Appliance Software Enterprise Edition

� SAP HANA Appliance Software Enterprise Extended Edition

Page 2: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

184

Die Editionen bestimmen ausschließlich, welche Komponenten in der Soft-warelizenzierung enthalten sind und wie Sie Daten extrahieren, bewegenund replizieren können. Bei jeder Implementierung von SAP HANA – sei esals Data Warehouse oder als Datenbank für SAP BW bzw. die SAP BusinessSuite – können Sie zusätzlich unter den zur Verfügung stehenden Editionenwählen.

Hinweis

Die Editionen stehen ebenfalls für die SAP HANA Rapid Deployment Solutions zurVerfügung. Wie bereits erwähnt, gehen wir in diesem Buch nicht detailliert auf dieSAP HANA Rapid Deployment Solutions ein.

Falls Sie SAP HANA für klassische Extraktions-, Transformations- und La-dungsverfahren (ETL) verwenden möchten und Ihnen bereits die SAP DataServices zur Verfügung stehen, sollten Sie sich für die SAP HANA ApplianceSoftware Platform Edition entscheiden. Diese Edition stellt eine großartigeLösung für Nicht-SAP-Unternehmen und Kunden dar, die jegliche Quellen,wie z.B. maßgeschneiderte Data-Warehouse-Anwendungen, Data Martsoder Daten aus Nicht-SAP-ERP-Systemen, beschleunigen möchten.

Die SAP HANA Appliance Software Enterprise Edition wurde für Unterneh-men entwickelt, die ihr SAP-HANA-System mit einer triggerbasierten Repli-kation verwenden möchten. Die Enterprise Edition beinhaltet zudem dieSAP Data Services, sodass Sie sowohl ETL- als auch Trigger-Verfahren durch-führen können. In Kapitel 12, »Datenbereitstellung«, werden wir noch de-tailliert auf eine triggerbasierte Replikation eingehen.

Die SAP HANA Appliance Software Enterprise Extended Edition ist für diejeni-gen geeignet, die »alles« wollen. Im Vergleich zu den anderen Editionenwurde diese Edition zusätzlich mit der logbasierten Replikation ausgestattet.Die meisten Großunternehmen, die bereits SAP ERP oder BI-Software (Busi-ness Intelligence) in ihre Systemlandschaft integriert haben, werden sicher-lich diese Edition in Betracht ziehen.

In jeder dieser Editionen haben Power-User mit dem Information Composerdie Möglichkeit, eigene Daten hochzuladen oder über eine eigene Ansichtauf In-Memory-Daten zuzugreifen. Dieses Werkzeug wird von den Kompo-nenten in den verschiedenen SAP-HANA-Editionen getrennt installiert. Wirwerden uns in Kapitel 9, »Datenmodellierung mit dem Information Compo-ser«, noch eingehend mit dem Information Composer auseinandersetzen.

Von der Implementierung unabhängige Überlegungen 6.1

185

Die in den jeweiligen Editionen enthaltenen Komponenten sind in Ta-belle 6.1 in einer Übersicht zusammengefasst.

Neben diesen drei Haupteditionen werden auch spezielle Softwareeditionenfür spezifische Zwecke angeboten. Diese bestehen aus der Datenbankeditionfür SAP BW, einer Edition für Kunden, die über einen EDGE-Lizenztyp (eineLizenz, die üblicherweise von kleinen Unternehmen erworben wird) verfü-gen, und einer limitierten Edition für Anwendungen und Beschleuniger.Diese Editionen sind zieloptimierte Lösungen, die auf der SAP-HANA-Platt-form basieren. Mithilfe dieser Angebote können kleinere Unternehmen oder

Softwarekomponente Platform Edition

Enterprise Edition

Enterprise Extended Edition

SAP HANA Studio

SAP HANA Information Composer

SAP HANA Client

SAP HANA Client for Excel

SAP HANA UI for Information Access (INA)

SAP-HANA-Datenbank

SAP Host Agent

Software Update Manager (SUM)

SAP HANA Advanced Functions Library (AFL)

Diagnostics Agent

SAP Data Services

SAP HANA Direct Extractor Connection (DXC)

SAP Landscape Transformation Tool (SLT)

Landscape Transformation Replica-tion Server

SAP HANA Load Controller (LC)

SAP (Sybase) Replication Server and Agent

SAP (Sybase) Adaptive Service Enterprise (ASE)

Tabelle 6.1 Die verschiedenen Editionen von SAP HANA

Page 3: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

186

solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine Edi-tion erwerben, die ihren Bedürfnissen entspricht.

Als Betriebssystem wird ein SUSE Linux Enterprise Server (SLES) oder Red HatLinux verwendet. Auf dem SAP Service Marketplace finden Sie Informationenzu weiteren technischen Unterkomponenten. Diese können am bestenanhand ihrer technischen Referenzen, wie in Tabelle 6.2 aufgezeigt wird,ermittelt werden.

Bereich Komponenten-ID Komponentenname

Lifecycle Management BC-HAN-SL-STP SAP HANA Unified Installer

BC-HAN-UPD Software Update Manager (SUM)

BC-DB-HDB-INS SAP-HANA-Datenbankinstallation

BC-DB-HDB-UPG SAP-HANA-Datenbank-Upgrade

Enterprise Edition

(enthält auch Kompo-nenten der Platform Edition)

BC-HAN-DXC SAP HANA Direct Extractor Connection (DXC)

EIM-DS SAP Data Services (ETL-basiert)

BC-HAN-LOA SAP HANA Load Controller (LC) (logbasiert)

BC-HAN-LTR SAP Landscape Transformation (SLT) (triggerbasiert)

BC-HAN-REP SAP (Sybase) Replication Server (logbasiert)

Enterprise Extended Edition

BC-DB-HDB SAP-HANA-Datenbank

BC-DB-HDB-ENG SAP-HANA-Datenbank-Engine

BC-DB-HDB-PER SAP-HANA-Datenbankpersistenz

BC-DB-HDB-SYS SAP-HANA-Datenbankschnittstelle

BC-DB-HDB-DBA SAP-HANA-Datenbank/DBA Cockpit

BC-DB-HDB-POR SAP-HANA-DB-Portierung

BC-DB-HDB-BAC SAP HANA Backup and Recovery

BC-CCM-HAG SAP Host Agent

BC-DB-HDB-CCM SAP HANA Computing Center Management System (CCMS)

BC-DB-HDB-CLI SAP HANA Clients (JDBC/ODBC)

BC-DB-HDB-R SAP-HANA-Integration mit R

BC-DB-HDB-SCR SAP HANA SQLScript

Tabelle 6.2 Interne Softwarekomponenten und -referenzen

Von der Implementierung unabhängige Überlegungen 6.1

187

Um Sie stets auf den neuesten Stand bringen zu können, hat SAP eine Reihevon SAP-HANA-Hinweisen erstellt, die den verschiedenen Releases und Ser-vice Packs angefügt und jeweils entsprechend abgewandelt werden. Partnerund Hardwareanbieter sollten diese Schlüsselinformationen wegen der darinenthaltenen Aktualisierungen sorgfältig und regelmäßig lesen. Die wichtigs-

BC-DB-HDB-MDX MDX-Engine (Microsoft-Excel-Client)

BC-HAN-MOD SAP HANA Studio: Information Modeler

BC-HAN-3DM Information Composer

BC-HAN-SRC SAP HANA UI Toolkit

BC-DB-HDB-TXT SAP-HANA-Text- und Suchfunktionen

BC-DB-HDB-DXC SAP HANA Direct Extractor Connection (DXC)

BC-DB-HDB-SEC SAP-HANA-Sicherheits- und Benutzerverwaltung

BC-DB-HDB-XS SAP-HANA-Anwendungsdienste

BC-DB-HDB-AFL SAP HANA Advanced Functions Library (AFL)

BC-DB-HDB-AFL-PAL SAP HANA Predictive Analysis Library

BC-DB-HDB-AFL-SOP SAP-HANA-Absatz- und Produktionsgrobplanung (SOP)

BC-DB-HDB-PLE SAP-HANA-Planungs-Engine

Endbenutzer-Clients BI-BIP-CMC, BI-BIP BI-Plattform

BI-RA-WBI SAP BusinessObjects Web Intelligence

BI-RA-XL SAP BusinessObjects Dashboards

BI-RA-CR, BI-BIP-CRS SAP Crystal Reports

BI-RA-EXP SAP BusinessObjects Explorer

BI-BIP-IDT Information Design Tool (für Zählbestände)

BI-RA-AO-XLA Microsoft-Excel-Add-In

Bereich Komponenten-ID Komponentenname

Tabelle 6.2 Interne Softwarekomponenten und -referenzen (Forts.)

Page 4: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

188

ten SAP-Hinweise in Bezug auf SAP HANA stehen registrierten SAP-Kundenauf der SAP-Service-Marketplace-Webseite zur Verfügung. Einen Auszug ausdiesen allgemeinen SAP-Hinweisen zu SAP HANA finden Sie in Tabelle 6.3.

Weitere für die Installation der SAP-HANA-Box erforderliche Komponentensind u.a. folgende:

� Java Runtime Environment (JRE)Die JRE wird durch Java-Komponenten in SAP HANA Studio verwendet.Für das System ist mindestens die Version JRE 1.6 erforderlich.

� XULRunnerHierbei handelt es sich um eine Laufzeitumgebung für ein gängiges Back-end für XUL-basierte Anwendungen. Für das System ist mindestens dieVersion 1.9.2 erforderlich.

� LibicuHierbei handelt es sich um einen Satz internationaler Komponenten fürUnicode.

� Network Time Protocol (NTP)Obwohl aus technischer Sicht nicht erforderlich, sollte eine Installationdurchgeführt werden, um Trace-Dateien zwischen SAP-HANA-Knoten zuunterstützen.

� SyslogdHierbei handelt es sich um ein Protokollierungswerkzeug für Systemnach-richten.

� GTK2Hierbei handelt es sich um eine Softwarekomponente für grafische Benut-zeroberflächen (GUIs).

SAP-Hinweis SAP-Hinweisname (englischer Originaltitel)

1514967 SAP HANA: Central Note

1018839 Admin (HANA)

1514966 Sizing SAP HANA Database

1523337 SAP HANA Database: Central Note

1598623 Security

1599888 SAP HANA: Operational Concept

1637145 SAP BW on HANA: Sizing SAP HANA Database

1729988 SAP BW Check for HANA Migration

Tabelle 6.3 SAP-Schlüsselhinweise für die SAP-HANA-Installation

Von der Implementierung unabhängige Überlegungen 6.1

189

Die Netzwerkverbindungen zwischen den Quellsystemen und dem SAP-HANA-Server sollten 10 GB/s betragen, damit die Effizienz der Datenreplika-tion gewährleistet werden kann. Da eine beträchtliche Datenmenge zwi-schen diesen Servern bewegt wird, ist es ebenfalls wichtig, dass die Verbin-dung nicht mit anderen Komponenten über gemeinsam genutzte Routeroder Switches geteilt wird. SAP empfiehlt, diese Verbindungen ausschließ-lich den Servern zuzuordnen und dabei darauf zu achten, dass die Entfernun-gen nicht zu groß werden. Eine Verbindung zwischen einem Server inEuropa und Amerika mit einem SAP-HANA-System in Asien ist beispiels-weise nicht ideal. Obwohl diese Empfehlung kein Muss ist und eine solcheArchitektur dennoch implementiert werden kann, sollte trotzdem nichtaußer Acht gelassen werden, dass jede langsame Netzwerkverbindunggleichzeitig auch die Replikation von Daten verlangsamt.

Softwareinstallation

Nachdem Sie sich für eine Version entschieden haben, kann Ihr Hardwarepartnermit der Installation beginnen. Um die Installation zu vereinfachen, stellt SAP denPartnern die Software SAP HANA Unified Installer zur Verfügung. Zusammen mitder Installation erhalten Sie auch das Software Logistics Toolset (SL), das den Soft-ware Update Manager (SUM) enthält. Dieses Werkzeug wird dazu verwendet, Soft-ware-Updates der SAP-HANA-Komponenten durchzuführen, um eine langfristigeKompatibilität sicherzustellen. Weitere Einzelheiten zum automatischen Software-Updateprozess erfahren Sie in Kapitel 13, »Administration von SAP HANA«.

Bitte beachten Sie, dass ausschließlich Hardwareanbieter und Installationspartnerdie SAP-HANA-SL-Software und SAP-HANA-Komponenten installieren sollten. Daes sich bei SAP HANA um eine sich gerade neu entwickelnde Technologie handelt,ist es sehr unwahrscheinlich, dass Basis-Mitarbeiter aus Unternehmen bereits überdie erforderlichen Kenntnisse für eine solche Installation verfügen. Trotz des vonSAP online bereitgestellten und detaillierten Leitfadens für SAP HANA UnifiedInstaller empfehlen wir allen Kunden ausdrücklich, die Softwareinstallation vonHardwareanbietern und zertifizierten Partnern durchführen zu lassen.

6.1.2 Hardwarespezifikationen und -optionen

SAP HANA wird als In-Memory-Appliance verkauft. Das bedeutet, dasssowohl Software als auch Hardware von den einzelnen Anbietern bereitge-stellt werden. Seit Juli 2014 können SAP-HANA-Hardwarelösungen beiCisco/EMC, Dell, Fujitsu, Hitachi, Huawei, IBM, NEC und Hewlett-Packarderworben werden.

Die Verfügbarkeit der neuen Xeon-E7-CPUs von Intel, die auch als Ivy Bridgebekannt sind, ist besonders beachtenswert. Die Schnelligkeit dieser neuen

Page 5: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

190

Chips beruht auf den 15 Cores. In den bisherigen E7-Versionen waren nurzehn Cores verfügbar. Außerdem weisen sie eine höhere Taktrate auf; vor-läufige Testergebnisse von SAP ergaben, dass die Performance von SAPHANA mehr als doppelt so hoch ist. Wenngleich es unterschiedliche Modellegibt – 2880/90, 4880/90 und 8880/90 –, werden nur die letzten beiden der-zeit in zertifizierten SAP-HANA- Appliances eingesetzt. Die Prozessoren un-terscheiden sich im Allgemeinen in ihren Taktraten, die zwischen 2,5 und2,8 GHz liegen. Einige Prozessoren sind also schneller als andere.

Entweder können die SAP-HANA-Hardwareserver vergrößert (Scale-Up)oder mehrere kleinere Server miteinander verbunden werden (Scale-Out).Die Vorteile einer Scale-Up-Lösung sind, dass Sie weniger Server erwerbenund verwalten müssen. Der Hauptvorteil einer Scale-Out-Lösung ist, dass Siebesonders große SAP-HANA-Systeme erstellen können. Beides wird im Fol-genden kurz erörtert. Am Ende dieses Abschnitts betrachten wir schließlichnoch ein spezifisches Beispiel für ein SAP-HANA-Hardware-Setup.

SAP-HANA-Scale-Up-Systeme

Die beiden Ansätze sollten von den Basis-Mitarbeitern eines Unternehmens,das SAP HANA implementieren möchte, sorgfältig abgewogen werden. DerVorteil eines einzelnen Systems ist offensichtlich. In großen und schnellwachsenden Unternehmen allerdings ist ein Knoten mit »nur« 2 TB Speicherlangfristig gesehen möglicherweise nicht ausreichend. Um zu sehen, obdiese Speicherkapazität für Ihr Unternehmen ausreicht, müssen Sie dasDatenwachstum betrachten. Ein System mit 2 TB kann 6 bis 8 TB unkompri-mierte Daten verarbeiten.

Ebenso müssen Sie die Anzahl der aktiven gleichzeitigen Benutzer berück-sichtigen. Wenn Sie das SAP-HANA-System für Berichte und Analysen nut-zen, benötigen Sie erfahrungsgemäß 0,2 Cores pro aktivem, gleichzeitigemBenutzer. Ein 2-TB-System wie das PQ 2800 von Fujitsu mit acht Ivy-Bridge-Prozessoren mit jeweils 15 Cores könnte entsprechend bis zu 600 aktive,gleichzeitige Benutzer unterstützen (8 × 15 ÷ 0,2). Wenn Sie eine gleichzei-tige Nutzung von 20 % Ihrer Benutzer einplanen, könnte das 3.000 festgeleg-ten Benutzern entsprechen. Dies sind nur einige Grundgedanken zu denMöglichkeiten eines Scale-Up-Systems. Selbstverständlich sollten Sie jedochmit Ihrem Hardwarepartner detailliert auf das Sizing-Vorhaben, Ihr Systemund die tatsächlich genutzten Daten eingehen.

Von der Implementierung unabhängige Überlegungen 6.1

191

Ab Juli 2014 verwenden alle Hardwareanbieter mit zertifizierten, auf Ivy-Bridge-Prozessoren basierenden SAP-HANA-Lösungen den Linux SLES fürSAP Version 11 (siehe Tabelle 6.4).

Es besteht noch die Möglichkeit, die älteren E7-10-Core-Prozessoren einigerAnbieter einzusetzen (siehe Tabelle 6.5). Die einzelnen Knoten in diesen Sys-temen können etwas langsamer sein. Mit entsprechender Konfigurationkann die Rechenleistung für das Gesamtsystem jedoch erhöht werden (d.h.in einer Scale-Out-Konfiguration).

System Speicher (RAM) Protokoll- und Daten-trägergröße

CPUs (Intel Ivy Bridge EX E7)

Geplanter Einsatz

SAP Busi-ness Suite

EDW/Data Mart

EDW/SAP BW

Fujitsu PQ 2400 E/S/L

128–512 GB 896–2.048 GB 2x 8890v2

1.024 GB 3.584 GB 4x 8890v2

PQ 2800 B/E/L

128–512 GB 896–2.048 GB 2x 8890v2

1.024 GB 3.584 GB 4x 8890v2

2.048 GB 6.656 GB 8x 8890v2

HP HP Con-verged System 500

256–512 GB 2.048 GB 2x 4880v2

1.024 GB 6.930 GB 4x 4880v2

2.048 GB 17.600 GB 4x 4880v2

DELL R920 128–1.024 GB 1.204–5.120 GB 4x 4880v2

Huawei RH5885H V3

128–512 GB 4.096–8.800 GB 2x 4890v2

1.024 GB 4.096–8.800 GB 4x 4890v2

IBM x3850 X6 128–512 GB 2.662 GB 2x 8880v2

512–1.024 GB 1.200–18.000 GB 4x 8880v2

x3950 X6 1.024 GB 2.662 GB 8x 8880v2

1.536–2.048 GB Noch nicht definiert

8x 8880v2

4.096 GB Noch nicht definiert

8x 8880v2

6.144 GB Noch nicht definiert

8x 8880v2

Tabelle 6.4 SAP-HANA-Scale-Up-Lösungen mit Intel Ivy-Bridge-15-Core-E7-Prozessoren

Page 6: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

192

SAP-HANA-Scale-Out-Systeme

SAP-HANA-Scale-Out-Systeme sind im Wesentlichen Systeme, die aus meh-reren, über ein Netzwerk miteinander verbundenen Knoten bestehen. Die-ses Netzwerk hat eine Geschwindigkeit von mindestens 10 GB, um Engpässebeim Datentransfer zwischen den Servern zu vermeiden. Die meisten SAP-HANA-Systeme können in ihrer Konfiguration an diesen Aufbau angepasstwerden. Der Vorteil der Scale-Out-Lösung ist die Fähigkeit, sehr große SAP-HANA-Systeme mit Hunderten von CPU-Cores für Zigtausende Benutzer auf-zubauen. Dies ist wirklich die Big-Data-Plattform der Zukunft.

Derzeit gibt es viele interessante Ansätze für Scale-Out-Systeme. Beispiels-weise kann das X6-System mit 2 TB von IBM ab Juli 2014 in einer Scale-Out-Lösung mit bis zu 56 Knoten konfiguriert werden, sodass ein System mit112 TB Speicher und 3360 CPU-Cores entsteht. Das HP Converged System500 ist eine SAP-zertifizierte Plattform mit Scale-Out-Möglichkeiten bis zu16 TB (dieser Wert wird in naher Zukunft möglicherweise noch erhöht).

Ein weiterer Ansatz für ein Scale-Out-System ist der Einsatz von Bladesanstelle von eigenständigen Serverknoten. Für diesen Zweck bieten Cisco/EMC B440-Blade-Server und HP BL680-Blade-Server an. Cisco/EMC hat

System HANA-Speicher

128 GB 256 GB 512 GB 1.024 GB

Cisco C260

C460

B440

Dell R910

Fujitsu RX600 S5

RX900 S2

Hitachi CB2000

HP DL-580 G7

DL-980 G7

BL-680

IBM 3690 X5

3950 X5

NEC Express 5800

Tabelle 6.5 SAP-HANA-Knoten mit Intel-E7-10-Core-Knoten

Von der Implementierung unabhängige Überlegungen 6.1

193

zudem eine gemeinsam genutzte Plattform für ein Scale-Out namens Jupitergeschaffen, in dem SAP HANA, Nearline Storage (NLS) und Hadoop in einemeinzigen System mit über 8 TB Speicher eingebunden werden. Wie Siesehen, gibt es also ausreichend Möglichkeiten für SAP-HANA-Scale-Out-Systeme.

Einige Hardwareanbieter bieten auch einen sogenannten »Investitions-schutz«. Dies bedeutet im Wesentlichen, dass Sie ältere Hardware teilweisein neueren Systemen einsetzen können, während Ihre Umgebung weiterwächst. Wenn Sie beispielsweise vor einigen Jahren ein 10-Core-Prozessor-system wie IBM 3950 erworben haben, können Sie nun neue prozessorba-sierte Ivy-Bridge-Serverknoten mit 15 Cores zu Ihrem System hinzufügen.Diese sind mit den älteren 10-Core-Knoten kompatibel. Erst wenn Ihreneuen Knoten mehr als 50 % Ihres gesamten SAP-HANA-Systems ausma-chen, müssen Sie umsteigen. Mit diesem Ansatz können Sie Tausende vonEuro einsparen und sicherstellen, dass Ihre Hardwareinvestitionen nachhal-tiger sind als bisher.

Da es hier zu Verwirrung kommen kann, empfiehlt es sich, die SAP-HANA-Experten Ihres Beraters einzubeziehen und gemeinsam mit diesen undIhrem Hardwareanbieter eine passende Lösung für Ihr Unternehmen zuermitteln. Allerdings ändern sich die Hardwaremöglichkeiten rapide. Dahersollten Sie sich nur auf Berater erlassen, die darin entsprechende Erfahrun-gen aufweisen können. Falsche Hardware kann sehr kostspielig sein. Inves-tieren Sie also erst ein wenig Zeit, bevor Sie sich für eine Scale-Out-Lösungentscheiden.

Hardwarebeispiel

Die SAP-HANA-Hardware ist in vieler Hinsicht einzigartig und wird von denjeweiligen Anbietern optimiert, um SAP-Lösungen zu unterstützen. DieseAnbieter haben bereits Erfahrungen und Expertenwissen mit der Installationund dem Support von SAP-HANA-Landschaften sammeln können. Aus die-sem Grund sollten Sie von keinem nichtzertifizierten Hardwareanbietererwarten, dass dieser die Anwendung installieren, betreiben und unterstüt-zen kann. Abbildung 6.1 zeigt ein Beispiel für Hardwarelösungen von unter-schiedlichen Anbietern.

Während der Arbeit an diesem Buch haben wir mit IBM bei der Installationund Prüfung seines High-End-x3950-X5-Servers zusammengearbeitet. Dawir hierzu nur ein System mittlerer Größe benötigten, entschieden wir uns

Page 7: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

194

für eine Speicherkapazität von 256 GB und ein mittleres Dateisystem (sieheAbbildung 6.2).

Abbildung 6.1 Einige Hardwarelösungen von verschiedenen Anbietern

Abbildung 6.2 Innenansicht von IBM 3950 X5: das SAP-HANA-System der fünften Generation

Hitachi CB 2000

Fujitsu RX 900 S2

Dell R910

NEC Express 5800

IBM x3950 X6

Cisco C460

HP BL 680

IBM FLEX X6

HP Converge System 500 Huawei RH5885H V3

Rückseite derMaschine

Vorderseite der Maschine

PCI-Karte: Die interne PCI-SSD-Karte verwaltet die SAP-HANA-Logs

auf einem separaten GPFS (Dateisystem).

Festplatten: 1 Hot-Swap-Platte; der Restfungiert als virtuelles Laufwerk. Sie

enthalten den Failover für SAP HANA.

Prozessoren (10 Kerne, Intel-Xeon-E7-Serie)

Hauptspeicher:256 GB installiert,

erweiterbar bis 512 GB.Das ist die SAP-HANA-DB.

Doppelte Strom-versorgung

Von der Implementierung unabhängige Überlegungen 6.1

195

2014 begannen wir mit dem Aufbau des neuen 3850-SAP-HANA-Modular-systems der sechsten Generation (X6) (siehe Abbildung 6.3).

Abbildung 6.3 Innenansicht von IBM 3850 X6: das SAP-HANA-System der sechsten Generation

Die Hardware ist völlig neu angeordnet. Sie umfasst Flash-Speicherbankenund eigenständige Recheneinheiten sowie einen Speicher für die Persistenzder SAP-HANA-Datenprotokolle und die Datendateien. Das neue Systembeinhaltete zudem 15-Core-Prozessoren, die viel schneller waren als das X5-2013-System. Wir haben das System mit 1,222 Milliarden Zeilen getestet.Die Abfragegeschwindigkeit erhöhte sich um mehr als 268 % – mehr als dop-pelt so schnell.

Obwohl sich dieses Hardwarebeispiel speziell auf die High-End-Systeme derx-Serie von IBM bezieht, sind die Komponenten anderer Anbieter damitdurchaus vergleichbar und somit für Sie eine gute Grundlage, um die Zusam-menhänge zu verstehen.

Ein modulares SAP-HANA-IBM-3850-X6-System mit 4 Sockeln und 4 Rechen-

blöcken. Eine Version mit 8 Einheiten war für die 3950-Konfiguration verfügbar.

Jede Recheneinheit hat zweiLüfter zur Kühlung. Es handelt

sich um ein Hot System.

Dies sind die Speicherbanken. Jede Rechen-einheit kann theoretisch über einen Speichermit 6 TB bzw. einen eXFlash-Speicherkanal

mit 12,8 TB verfügen.

Für den internen Speicherder Protokolldateien und

zur persistenten Datenspeicherung.

Bis zu 6,4 TBeXFlash bzw. 12,8 TB

herkömmlicher Speicherwaren möglich.

Wärmeableiterzur Kühlungdes Systems

Jede Recheneinheitumfasst einen Intel-E7-Ivy-Bridge-Prozessor mit

15 Kernen.

Page 8: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

196

6.2 SAP HANA als Data Warehouse

Auch wenn die Implementierung von SAP HANA als Data Warehouse eineder einfachsten Möglichkeiten ist, die Geschwindigkeit dieser Plattform zunutzen, gibt es einige Aspekte, die sorgfältig geplant werden sollten. Die bei-den wichtigsten Aspekte sind die Datenmodellierung und das Sizing, die imfolgenden Abschnitt erörtert werden.

6.2.1 Datenmodellierung

Beim Modellieren von Daten für SAP HANA als Data Warehouse musssichergestellt werden, dass zwei Dinge berücksichtigt werden: Zum einensollte die Geschwindigkeit von SAP HANA ausgenutzt werden. Zum anderensollte die Geschwindigkeit nicht weiter optimiert werden, wenn dies nichterforderlich ist.

Zum besseren Verständnis betrachten wir nun die traditionellen Sternsche-mata und Schneeflockenmodellierungstechniken, die für ein In-Memory-Data-Warehouse möglicherweise nicht geeignet sind. Diese Techniken die-nen primär zur Reduzierung von Tabellen-Joins und Datenmengen im DataWarehouse. Hierbei wurden einfach die dritten Normalformmodelle imTransaktionssystem verwendet und denormalisiert, indem Ereignis- (Fakten)und Dimensionstabellen (Beschreibungen) erzeugt wurden. Dies hatte zweiVorteile. Zum einen erübrigten sich kostenintensive Tabellen-Joins, wennStammdaten, die über Dutzende von Tabellen verteilt waren, abgefragt undmit Transaktionsdaten verbunden wurden. Angepasste Dimensionen erzeug-ten einfach denormalisierte Tabellen für alle Kunden, Anbieter und Pro-dukte, und der Modellierer konnte diese Daten mit Vorgängen wie Verkauf,Lieferung und Fakturierung verknüpfen. Zum anderen entfielen die hohenKosten für die Aufzeichnung aller Ereignisse und Stammdaten in einer einzi-gen Tabelle, wie dies bei Modellen der ersten Normalform oder bei Vor-gangsdateien der Fall ist.

Um das System noch weiter zu beschleunigen, erstellten Dimensionsmodel-lierer Übersichtstabellen. Zudem stellten sie sicher, dass die langsamerenAbfragen, die zusammengefasste Daten benötigten, auf diese Tabellen undnicht auf die Faktentabellen mit detaillierten Vorgängen umgeleitet werdenkonnten. Andere erstellten zusammenfassende Sternschemata mit unter-schiedlicher Granularität (z.B. Gesamtumsatz nach Produkt, Geschäft, proTag). Um noch schnellere Ergebnisse zu erhalten, wurde es schließlich gän-gige Praxis, dass die Abfragen vorab durchgeführt und die Zwischenergeb-

SAP HANA als Data Warehouse 6.2

197

nisse auf den Anwendungsservern in den Speicher-Caches vorgehalten wur-den – es wurde keine Möglichkeit ausgelassen, um mehr Geschwindigkeitaus dem festplattenbasierten Data Warehouse herauszuholen.

Viele dieser Ansätze sind ungeeignet, wenn SAP HANA als Data Warehouseeingesetzt wird. In einem spaltenbasierten Speicher beispielsweise wirddurch die Kompression ein Großteil der Datenredundanzen aus den Model-len der ersten bzw. zweiten Normalform entfernt. Der Aufwand für dieseAnsätze kann also oft minimal sein. In SAP HANA gibt es keine »echten«Tabellen. Stattdessen stehen komprimierte zeilen- und spaltenbasierte Spei-cher auf Indexbasis bereit, die als Tabellen mit einfachem Zugriff und einfa-cher Modellierung angezeigt werden. Im Data Warehouse gibt es hauptsäch-lich Spaltenspeicherdaten und Tabellen-Joins. Es handelt sich lediglich umeine semantische Ansicht dessen, was in der neuen Datenbank stattfindet.Mit anderen Worten, die kostenintensiven Tabellen-Joins, die in den tradi-tionellen Dimensionsmodellen vermieden werden sollten, sind nicht mehrvorhanden.

Außerdem ist der Einsatz von Übersichtstabellen in den meisten Fällen nichtsinnvoll, wenn das System ohnehin schon sehr schnell ist. Das Zwischenspei-chern von Zwischenergebnissen (z.B. durch Übermittelung in den Cache) istnur in äußerst seltenen Fällen sinnvoll.

Sogar die Vorgehensweise zur Extraktion, Transformation und zum Laden(ETL) ändert sich bei SAP HANA. Bei herkömmlichen Data Warehouseserfolgt die Transformation während der Extraktion aus dem Quellsystembzw. auf Ebene des Anwendungsservers, auf dem die ETL-Werkzeuge instal-liert sind. Bei SAP HANA ist es oft sinnvoll, die Daten einfach in der vorlie-genden Form zu laden und die Transformationen innerhalb von SAP HANAüber Berechnungen, Analysesichten bzw. über SQL-Skripte durchzuführen,wenn die Daten zwischen den Staging- und Berichtsebenen in den Modellenbewegt werden. Dies kann die Transformationen deutlich beschleunigen,und Sie müssen sich nicht auf kleinere, langsamere Server auf der ETL- oderAnwendungsebene verlassen.

Kurzum, Sie sollten die Modellierungsansätze für das Data Warehouse noch-mals überdenken, wenn Sie mit SAP HANA arbeiten. Sie sollten sich fragen,ob die älteren Methoden tatsächlich noch sinnvoll sind. Es stehen viele, sehrgute Hilfsquellen im Internet und in Buchhandlungen zur Verfügung, dieerläutern, warum Operational Data Stores (ODS) in dieser neuen Herange-hensweise wichtiger sind als Sternschemata.

Page 9: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

198

Hinweis

Wir empfehlen den Kurs HA-300 der SAP-Schulungen für Neulinge im BereichModellierung bei SAP HANA. Der Titel des Kurses ist »SAP HANA – Implementa-tion and Modeling«.

6.2.2 Sizing

Wenn Sie planen, Daten aus einem Transaktionssystem zu verschieben oderDaten aus einem bestehenden System zu konvertieren, ist ein besonderswichtiges Kriterium beim Sizing eines SAP-HANA-Systems das Komprimie-rungsverhältnis beim Verschieben von Daten in die In-Memory-Plattform.Einige Kunden konnten sehr hohe (8- bis 10-fache) Komprimierungen fest-stellen, während andere »nur« eine 3,8-fache Datenreduktion erzielt haben.Aus diesem Grund empfiehlt SAP, mit einer Planung von einem 3- bis5-fachen Faktor für das Sizing des jeweiligen Systems zu beginnen undanschließend detaillierter auf das Sizing-Vorhaben einzugehen.

Die Unterschiede bei diesen Komprimierungszahlen entstehen dadurch,dass einige Unternehmen bereits relationale Datenbanken mit umfangrei-chen Komprimierungsmethoden (z.B. DB2 v10 oder die native Komprimie-rung in der Oracle-12g-Datenbank) verwenden, während andere über Da-tenbanken mit eingeschränkteren Komprimierungsfähigkeiten verfügen.Natürlich erwarten wir höhere Komprimierungszahlen in Datenbanken, dieohnehin geringe Komprimierungsfähigkeiten aufweisen. Hinzu kommenUnterschiede in der Art und Weise, wie Datentypen komprimiert werden(d.h., Strings sind eigentlich Arrays in den meisten Datenbanken), währendZahlen in den meisten Versionen der Oracle-Datenbanken bereits auf bis zu50 % komprimiert sind. Und schließlich gibt es auch Unterschiede bei denIndexgrößen, die entweder zeilen- oder spaltenbasiert sind. Um eine grobeSchätzung zu erhalten, empfiehlt es sich, als ersten Schritt die Faustregel des3- bis 5-fachen Faktors anzuwenden.

Das Sizing von SAP HANA als Data Warehouse ist darüber hinaus auch einStück Wissenschaft. Es besteht aus dem Sizing des erforderlichen Speichers(spaltenbasierte Speicher, zeilenbasierte Speicher sowie Speicher für Cachesund Komponenten) und der Größeneinteilung des Datenträgers (Log undPersistenz) sowie des CPU-Sizings für die zu erzielende Rechenleistung.Glücklicherweise gibt es einige grundlegende Methoden, um die Größeeines Systems festzulegen:

SAP HANA als Data Warehouse 6.2

199

� SAP QuickSizer Dieses Werkzeug ist für Unternehmen geeignet, die noch kein SAP-ERP-oder SAP-BW-System verwenden oder eine Rapid Deployment Solutionbevorzugen.

� Faustregel beim SizingFür all diejenigen, die eine Sizing-Übung überspringen möchten, gibt esauch die Möglichkeit, das Sizing eines Systems basierend auf einer Reihevon allgemeinen Empfehlungen durchzuführen. Das Ergebnis werden all-gemeine Schätzungen sein, die Ihnen einen vorläufigen Eindruck davonvermitteln können, was beim Sizing eines Systems zu erwarten ist. Den-noch sollten Sie vor der tatsächlichen Implementierung eines Systems eindetaillierteres Sizing durchführen.

� T-Shirt-ModellSAP bietet auch ein T-Shirt-Modell für umfangreiche Schätzungen. Wie dieanderen Methoden sollte auch diese nur für allgemeine Schätzungen ange-wendet werden. Sie ist nicht zuverlässig genug, um sie als einzige Sizing-Methode anzuwenden.

SAP QuickSizer

QuickSizer für SAP HANA steht unter dem Link http://service.sap.com/quick-sizer zur Verfügung (ein SAP-Service-Login ist hierzu erforderlich). Für diedrei verschiedenen Versionen von SAP HANA stehen entsprechend dreiunterschiedliche Versionen dieses Werkzeugs zur Verfügung (siehe Abbil-dung 6.4).

Abbildung 6.4 Arten der SAP-HANA-QuickSizer-Werkzeuge

Wenn Sie mit dem Sizing Ihres Data Warehouses beginnen, geben Sie dieProjektdaten, die Anzahl der Benutzer und den Speicherbedarf für die Daten

Page 10: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

200

ein, die Sie auf SAP HANA übertragen möchten. Es ist wichtig, dass Sie dieseZahl als unkomprimierte Daten angeben. Ist in Ihrem Quellsystem eine Kom-primierung von 30 % aktiviert, sollten Sie 30 % zu der im Quellsystem ange-zeigten Datenmenge hinzufügen. Außerdem definieren Sie den Zeitraum, indem Ihr System aktiv ist (siehe Abbildung 6.5).

Abbildung 6.5 QuickSizer-Eingabe für SAP HANA als Data Warehouse

In diesem Beispiel gehen wir von 350 Benutzern und einer Datenmenge von600 GB aus, die aus einer Oracle-Datenbank geladen werden sollen. Hiermuss berücksichtigt werden, dass beim Sizing die bereits verfügbaren Daten(300 GB) sowie die Daten der nächsten drei Jahre einbezogen werden müs-sen (planmäßig 100 GB pro Jahr). Der Eingabewert ist also 600 GB insge-samt. Die Start- und Endzeiten sind von 9:00 bis 18:00 Uhr.

Sie können neue Quellsysteme hinzufügen, indem Sie eine Zeile markierenund darüber auf die Schaltfläche Insert klicken. So können Sie mehrereQuellsysteme in das Sizing einbeziehen. Wenn Sie Ihre Eingaben abgeschlos-sen haben, klicken Sie einfach auf Calculate result. Sie können nun mit derAnalyse der Sizing-Ergebnisse beginnen (siehe Abbildung 6.6).

In diesem Beispiel benötigen Sie 246 MB RAM in Ihrem System und einSystem, das 70.000 SAPS unterstützen kann. Der Begriff SAPS ist eine ein-heitliche Kennzahl der Systemperformance, die jeder Hardwareanbieter ineinem System-Sizing umsetzen können sollte. Ursprünglich sollte mit dieserKennzahl gemessen werden, ob Bestellungen verarbeitet werden können.100 SAPS wurden als 2.000 vollständig verarbeitete Business-Auftragsposi-tionen pro Stunde festgelegt. Mittlerweile ist es jedoch eine Standardmaß-einheit, mit der Hardwareanbieter die Größe von Anwendungsservern undder SAP-HANA-Datenbankserver ermitteln.

SAP HANA als Data Warehouse 6.2

201

Abbildung 6.6 QuickSizer-SAP-HANA-Sizing-Ergebnisse

Sie können die Sizing-Ergebnisse einfach für die Anbieter ausdrucken undum ein Angebot für die Hardware bitten. Gehen Sie für Sandbox-, Entwick-lungs-, Qualitätssicherungs- und Hochverfügbarkeitssysteme gleichermaßenvor. Die Größe für diese Systeme kann variieren.

Faustregel für das Sizing

Es gibt auch noch andere schnelle Wege, um eine ungefähre Vorstellungdavon zu bekommen, wie groß Ihr System sein wird. Diese Faustregeln las-sen sich sehr gut für vorläufige Schätzungen und Budgetierungen auf hohemNiveau anwenden. Um jedoch genaue Zahlen zu erhalten, sollten Sie, wiebereits erklärt, eine echte Sizing-Methode verwenden. Zunächst müssen Sieden benötigten Speicherplatz abschätzen.

Speicher = 50GB + [Quelldaten + bestehende DB-Komprimierung] ÷ 4 × 2

Die 50 GB stehen SAP-HANA-Services und -Caches zur Verfügung. Der Wert4 ist die durchschnittliche Komprimierung, die für zeilen- und spaltenba-sierte Speichertabellen erwartet wird. Der Faktor 2 bezieht sich auf denerforderlichen Speicherplatz für Laufzeitobjekte und auf temporäre Ergeb-nissätze in SAP HANA. Und abschließend steht der Begriff bestehende DB-Komprimierung für Komprimierungen, die bereits auf Ihrem System durchge-führt wurden (falls zutreffend). Dieser Vorgang ist kompliziert, und wennSie lediglich einige Anhaltspunkte brauchen, können Sie auch einfach dieDatenbankgröße Ihres Systems als Grundlage nehmen und diese durch 4 tei-

Page 11: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

202

len. Aber denken Sie daran, dass es sich hierbei nur um Faustregeln handelt.In einem echten System kann es eine 8- bis 9-fache Komprimierung geben.

Sie können beispielsweise mit einem Data-Warehouse-System anfangen, dieLog-Dateien bereinigen und Aggregate (mit SAP HANA nicht erforderlich)und die temporären Speicherdateien entfernen. Dieses bereinigte Data-Warehouse-System bietet Ihnen eine Ausgangsbasis für das SAP-HANA-Sizing.

In unserem Faustregel-Beispiel erhalten Sie eine Datenbank mit 1,4 TB un-komprimierten Daten, wenn Sie ein altes Data-Warehouse-System mit 1 TBhaben, das System bereits 40 % Komprimierung verwendet und Sie diesenProzentsatz erneut hinzurechnen. Wenn Sie diesen Wert durch 4 teilen, er-halten Sie eine SAP-HANA-Datenbank mit einer Größe von 350 GB. An-schließend multiplizieren Sie das Ergebnis mit 2, um Speicher für interneProzesse, Indizierung, Datenbewegung und Endanwender zu ermöglichen,und fügen zum Schluss 50 GB für den internen Speicher von SAP HANAhinzu. Das ergibt eine grobe Schätzung von 710 GB an erforderlichemSpeicher.

Als Nächstes benötigen Sie Festplattenplatz, der wie folgt abgeschätzt wer-den kann:

Festplatte für die Persistenzschicht = 4 SpeicherFestplatte für den Log = 1 Speicher

In diesem Beispiel benötigen Sie vier 750-GB-Festplatten für die Persistenz-schicht und etwa 750 GB für die Logs. Dies entspricht etwa 3,75 TB (keineSorge, Festplattenspeicher dieser Größe sind heutzutage recht kostengüns-tig). Die Persistenzschicht ist die Festplatte, die das System sichert und fürRedundanz sorgt, falls es zu Speicherfehlern kommt, und sollte daher nichtunterschätzt werden.

Sie können natürlich immer mehr Speicher hinzufügen, während das Systemweiter wächst. Es wird jedoch empfohlen, lieber etwas mehr Platz einzupla-nen, damit der Festplattenplatz nicht zu klein ist. So verhindern Sie, dass Siedirekt nach dem »Go-Live« als Erstes mehr Speicher hinzufügen müssen.Außerdem sollte diese Festplatte nicht auf einem gemeinsam und starkgenutzten Storage Area Network platziert werden. Versuchen Sie, die SAP-HANA-Festplatte so gut wie möglich als spezielle und separate Festplatte ein-zusetzen.

Die CPUs basieren auf der Anzahl der enthaltenen Kerne. Inzwischen existie-ren CPUs mit 15 Kernen. Wenn Sie einen Knoten mit 4 × 15 Kernen haben,

SAP HANA als Data Warehouse 6.2

203

erhalten Sie 60 Kerne und können somit 300 aktive Benutzer auf diesemHardwareknoten arbeiten lassen – sowie eine viel größere Anzahl von festge-legten Benutzern. Beim Sizing durch SAP-Anbieter ist es üblich, Prozessorenbasierend auf der Speichergröße von SAP HANA hinzuzufügen, sodass ihreeigentliche Zahl durchaus unterschiedlich ausfallen kann. Der CPU-Bedarfwird mit der folgenden Formel ermittelt:

CPU = 0,2 CPU-Kerne pro aktivem Benutzer

Je nachdem, wem Sie Zugriff gewähren, kann es schwer sein, die Anzahl deraktiven Benutzer zu bestimmen. In der Vergangenheit waren in Data Ware-houses meist 20 bis 40 % der festgelegten Benutzer aktiv, während in ERP-Systemen eine höhere Zahl üblich ist. Wenn Sie ein älteres System auf SAPHANA verschieben, erhalten Sie die tatsächlichen Nutzungszahlen aus denSystemüberwachungswerkzeugen, die der Administrator wahrscheinlichbereits einsetzt. Sie werden daraus ersehen können, wie viele Ihrer festgeleg-ten Benutzer gegenwärtig Ihr System verwenden, wobei die Aktivitäten die-ser Benutzer in »niedrig«, »mittel« und »hoch« aufgegliedert werden. DieseInformationen können bei der Bestimmung der Anzahl erforderlicher CPU-Kerne sehr hilfreich sein.

Die CPU-Geschwindigkeit kann abhängig vom Kaufdatum Ihres SAP-HANA-Systems variieren. Seit Sommer 2014 ist die neue Intel-E7-Ivy-Bridge-Seriemit einer Taktrate von 2,5 bis 2,8 GHz ausgestattet. Es ist sehr wahrschein-lich, dass in Zukunft noch schnellere Prozessoren eingesetzt werden.

T-Shirt-Sizing

Für eine noch schnellere Referenz können Sie ein T-Shirt-Sizing-Modell ver-wenden. Diese Aufstellung asiert auf ähnlichen Regeln wie den zuvor erläu-terten, kategorisiert jedoch die Größen auf praktische Weise in extra kleinebis extra große SAP-HANA-Umgebungen (siehe Tabelle 6.6). Diese Aufstel-lung lässt sich leicht lesen, sollte aber nicht für die Budgetierung oder Ein-kaufsentscheidungen genutzt werden, da sie nicht absolut verlässlich ist.

Da mehr Kerne zur Verfügung stehen (aktuell zehn pro Prozessor), solltenKunden, die sich eine Speicherkapazität von mehr als 1.024GB wünschen,zusammen mit ihrem Hardwarepartner mehrere Knotensysteme miteinan-der verbinden oder größere Knoten für eine erhöhte Skalierbarkeit verwen-den. Derzeit haben SAP und IBM neue Systeme mit über 100 TB Speichervorgeführt, sodass die allgemeine Skalierbarkeit kein größeres Problem fürdie meisten Unternehmen darstellen sollte.

Page 12: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

204

Ein anderer wichtiger Faktor für viele wird die Geschwindigkeit sein, mit derDaten repliziert werden können. Die kleineren Systeme sind auf ca. 5–10 GBpro Stunde beschränkt, während die größeren Systeme bis zu 30 GB undmehr erreichen können. Da sich diese Zahlen jedoch mit neuen Hardware-versionen und neuen SAP-HANA-Versionen häufig ändern, sollten sie ledig-lich als Orientierungshilfe dienen. Dieser Bereich entwickelt sich schnellweiter. Daher sind die meisten Hardwarebeispiele nur begrenzt gültig.

6.3 SAP Business Suite auf SAP HANA

Seit Januar 2013 bietet SAP Unterstützung für die SAP Business Suite auf SAPHANA. Dies bedeutet, dass Sie ein neues SAP-ERP-System auf SAP HANAinstallieren oder Ihr bestehendes System auf SAP HANA migrieren können,um die einfachere Architektur sowie die signifikanten Performancevorteilevon SAP HANA zu nutzen. Zahlreiche Unternehmen haben ihre SAP-ERP-Systeme bereits auf SAP HANA verschoben oder dieses installiert. DieserTrend setzt sich immer weiter fort. Seit Juli 2014 müssen Sie als Ramp-Up-Kunde registriert sein, um Zugriff auf diese Lösung zu erhalten.

Datenkompri-mierung (Daten-menge vor Komprimierung)

Arbeits-speicher

Prozessoren SAS/SSD (für Daten)

Replikations-geschwindig-keit (pro Stunde)

XXL 7.000–250.000 GB 3.072 GB bis 112+ TB

8 x 15 Cores + Intel E7 2,8 GHz

15+ TB 30+ GB

XL 3.500–7.000 GB 2.048–2.560 GB

8+ Intel E7 2,5+ GHz

5–10 TB 30+ GB

L 2.000–3.500 GB 1.024 GB 4 Intel E7 2,5+ GHz

4–5 TB 10–20 GB

M 1.250–2.000 GB 512 GB 4 Intel E7 2,5+ GHz

2.048 GB 10–20 GB

S 500–1.250 GB 256 GB 2 Intel E7 2,5+ GHz

1.024 GB 5–10 GB

XS 256–500 GB 128 GB 2 Intel E7 2,5+ GHz

1.024 GB 5–10 GB

Tabelle 6.6 SAP-HANA-T-Shirt-Sizing

SAP Business Suite auf SAP HANA 6.3

205

Hinweis

Vor der Migration sollten Sie das optionale Enhancement Package 6 für SAPERP 6.0 mit der SAP-HANA-Version installieren. Wenn Sie allerdings Branchen-lösungen mit Zusatzfunktionen nutzen, werden möglicherweise nicht alle durchdas Enhancement Package unterstützt. Lesen Sie SAP-Hinweis 1774566 sorgfäl-tig, bevor Sie mit diesem Prozess beginnen. Sollten Sie sich für den Prozess ent-scheiden, müssen Sie eine separate Vereinbarung unterzeichnen, in der Ein-schränkungen hinsichtlich der SAP-Lizenz- und Wartungsvereinbarung erläutertwerden. Weitere Informationen hierzu erhalten Sie in SAP-Hinweis 1768031.

Es gibt drei Implementierungsoptionen, um ein SAP-Business-Suite-Systemauf SAP HANA in Ihrem Unternehmen umzusetzen:

� vollständige Neuinstallation

� In-Place-Migration

� kopieren, upgraden und migrieren

Diese Optionen werden im Folgenden erörtert. Anschließend erhalten Sieeinige Tipps für das Sizing (passend zu den verschiedenen Implementie-rungsoptionen).

Zusätzlich zu diesem Abschnitt empfehlen wir die SAP-Hinweise zu SAPBusiness Suite auf SAP HANA (siehe Tabelle 6.7).

Name Beschreibung

SAP-Hinweis 774615 Support Package Levels for SAP ERP /SAP ECC Installa-tion and Upgrades

Liste der erforderlichen Support Packs

SAP-Hinweis 855498 Installation Prerequisite Checker

SAP-Software auf UNIX, Windows und IBM i: Über-prüfen der Abhängigkeiten der Betriebssysteme

SAP-Hinweis 998833 Release Restrictions: SAP ERP 6.0 – Enhancement Packages

Informationen über die Ein-schränkungen bei den SAP Enhancement Packages für SAP ERP 6.0

SAP-Hinweis 1730095 EHP6 for SAP ERP 6.0 on HANA – Release Infor-mation

Releaseinformationen und Äquivalenzebenen der Sup-port Packs

Tabelle 6.7 Wichtige Hinweise für SAP Business Suite auf SAP HANA

Page 13: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

206

6.3.1 Vollständige Neuinstallation

Dies ist die einfachste Option, um die SAP Business Suite auf SAP HANA zuimplementieren. In diesem Szenario erwerben und installieren Sie ein völligneues SAP-HANA-System einschließlich SAP Business Suite. Auch wenn essich nicht für die Migration eines Produktivsystems empfiehlt, können Siehiermit einige Daten in das SAP-HANA-System (d.h. die Stammdaten undoffene Bestellungen) migrieren, um die neuen Funktionen von SAP HANAnutzen zu können.

Dieser Ansatz eignet sich vor allem für jene, die ältere Implementierungenbereinigen und dabei ein Upgrade auf neuere Versionen der SAP BusinessSuite vermeiden möchten. Er eignet sich ebenfalls für Benutzer, die die SAPBusiness Suite zum ersten Mal implementieren. Starten Sie für diese Installa-tion das Installationswerkzeug Software Provisioning Manager 1.0, und folgenSie dem SAP Installation Guide.

SAP-Hinweis 1760306 SAP EHP6 for SAP ERP 6.0, version for SAP HANA 1.0: Add-ons

Zu berücksichtigende Aspekte beim Einsatz von SAP Enhancement Package 6 für SAP ERP 6.0, Version für SAP HANA in Kombina-tion mit einem Add-on im selben System

SAP-Hinweis 1768031 SAP EHP 6 for SAP ERP 6.0, version for SAP HANA

Einschränkungen hinsicht-lich des produktiven Einsat-zes von SAP Enhancement Package 6 für SAP ECC 6.0, Version für SAP HANA

SAP-Hinweis 1774566 SAP Business Suite Powered by SAP HANA – Restrictions

Einschränkungen für SAP ECC auf SAP HANA

SAP-Hinweis 1785057 Preparatory Steps for Database Migration to SAP HANA

Informationen über die vor-bereitenden Schritte für die Datenbankmigration auf SAP HANA

SAP-Hinweis 1789632 EHP6 for SAP ERP 6.0 on HANA – HANA Content Activation

Informationen über manuell zu aktivierende Inhalte

Name Beschreibung

Tabelle 6.7 Wichtige Hinweise für SAP Business Suite auf SAP HANA (Forts.)

SAP Business Suite auf SAP HANA 6.3

207

Vor der Installation sind folgende Schritte notwendig:

1. Deaktivieren Sie die Windows-Server-Firewall.

2. Vergewissern Sie sich, dass das Windows-Dateisystem NTFS ist (nichtFAT).

3. Überprüfen Sie die Windows-Domänenstruktur. Bei Domain-Installatio-nen sollten alle SAP-Systemhosts Teil einer einzigen Domäne sein.

4. Stellen Sie im Windows-Server den Hochleistungs-Energiesparplan ein.

5. Stellen Sie sicher, dass der Benutzer die Berechtigung zur Installation derSoftware in der Domäne hat. (Verwenden Sie nicht den Benutzer <sapsid>adm für die Installation des SAP-Systems.)

6. Erstellen Sie das Verzeichnis \usr\sap\trans auf dem Host, der als Trans-porthost verwendet werden soll, und geben Sie das Verzeichnis usr\sapauf dem Transporthost als SAPMNT frei. Setzen Sie bei dieser Freigabe dieBerechtigung für Everyone auf Full Control. Somit kann das Installati-onsprogramm das Transportverzeichnis im Standard \\SAPTRANSHOST\SAPMNT\trans adressieren. Erteilen Sie schließlich Everyone die Berech-tigung Full Control für das Transportverzeichnis.

7. Beschaffen Sie die physischen Installationsmedien als Teil des Installa-tionspakets. Sie können den Software Provisioning Manager 1.0 ver-wenden.

8. Ermitteln Sie die Komponenten für Ihre Installation, wie z.B. die zentraleServiceinstanz für ABAP (ASCS), die Datenbankinstanz, den Enqueue Rep-lication Server sowie die primäre(n) und zusätzliche(n) Anwendungsser-verinstanz(en).

9. Vergewissern Sie sich, dass die Anwendungsserver und die SAP-HANA-Datenbankserver für dieselbe Zeitzone eingerichtet sind.

Die eigentliche Installation umfasst folgende Schritte:

1. Stellen Sie sicher, dass die Ports für 21200, 4239 und 21212 nicht blo-ckiert sind. Das Installationswerkzeug Software Provisioning Manager 1.0verwendet Port 21200 zur Kommunikation mit dem GUI-Server; der GUI-Server verwendet Port 21212 zur Kommunikation mit dem GUI-Clientund Port 4239 des HTTP-Servers. Daher müssen alle Ports offen sein.

2. Sorgen Sie dafür, dass im Installationsverzeichnis mindestens 300 MBSpeicherplatz für jede Installationsoption sowie 300 MB freier Speicher-platz für die ausführbare Datei des Installationsprogramms zur Verfügung

Page 14: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

208

stehen. Wenden Sie SAP-Hinweis 1697164 an, und vergewissern Sie sich,dass die Datenbank in Betrieb ist, bevor Sie die Installation starten.

3. Doppelklicken Sie auf sapinst.exe in dem Verzeichnis, in das Sie die DateiSWPM10SP<Support Package-Nummer>_<Versionsnummer>.SAR entpackthaben. Der Installationsprozess wird gestartet. Folgen Sie nun den Anwei-sungen auf dem Bildschirm (siehe Abbildung 6.7).

Abbildung 6.7 Installation des SAP-HANA-Anwendungsservers für SAP Business Suite

6.3.2 In-Place-Migration

Eine In-Place-Migration ist die gängigste Methode für Benutzer, die bereitsein funktionierendes SAP-Business-Suite-System haben und auf SAP HANAmigrieren möchten. Bei dieser Methode werden im Wesentlichen Änderun-gen an der Gesamtlandschaft vermieden, indem SID, Hostname, Anwen-

SAP Business Suite auf SAP HANA 6.3

209

dungsserver und Konnektivität beibehalten werden. Folglich wird nur derDatenbankserver während der Installation verändert, und die anderen Teileder Landschaft bleiben weitestgehend intakt. Die Ausfallzeit bei der Migra-tion wird primär zum Verschieben der Datendateien von der alten Daten-bank auf die SAP-HANA-Datenbank genutzt. Daher richtet sich die notwen-dige Ausfallzeit meist nach der Größe des SAP-Business-Suite-Systems. Beiden ersten SAP-Business-Suite-Systemen, die auf SAP HANA migriert wur-den, erfolgte dies im Rahmen eines herkömmlichen Upgrades. Hierzu gehör-ten das Patchen des Systems, ein Upgrade der Anwendung auf die erforder-liche Ebene, die Implementierung von Unicode und schließlich dieMigration zu SAP HANA.

Heute können Sie ein neues Werkzeug mit dem Namen Database MigrationOption (DMO) einsetzen und all diese Aufgaben in einem Schritt erledigen.Die Ausfallzeit des Systems ist hierbei auf ein Minimum reduziert. DMO istkein separates Werkzeug, sondern eine im Software Update Manager (SUM)Version 1 Service Pack 9 verfügbare Option. Wenn Sie eine ältere Versionvon SAP ERP verwenden, ist das DMO-Werkzeug hervorragend für eine pa-rallele Durchführung von Upgrade und Migration geeignet. Dieses Werk-zeug wird auch für alle SAP-In-Place-Migrationen empfohlen. Mit der DMO-Option kann der Systemteil der SAP Business Suite 7.0 auf eine Stufe ent-sprechend zu SAP NetWeaver 7.40 migriert werden. Dieser Vorgang umfasstauch Migrationen von SAP ERP Version 6.0 EHP 7. DMO wird ebenfalls fürdie Migration von SAP BW auf SAP HANA genutzt.

Mithilfe des DMO-Werkzeugs wird innerhalb des SAP-Business-Suite-Sys-tems ein Schattensystem, ein sogenanntes Schatten-Repository, erstellt. Die-ses Schattensystem umfasst eine kleine Menge an Daten und wirkt sich nichtauf das bestehende System aus, wenn ausreichend Systemressourcen vor-handen sind. Sie können gemeinsam mit Ihrem Implementierungspartnervor einem Upgrade ermitteln, ob dies der Fall ist. Im zweiten Schritt derKonfigurationsphase stehen Ihnen drei Optionen für die DMO-Migrationzur Verfügung. Die Standardoption sollte automatisch ausgewählt werden,falls Sie nicht wissen, ob die Systemressourcen in Ihrem bestehenden SAP-ERP-System für eine Datenbankmigration mit geringer Ausfallzeit ausrei-chend sind (siehe Abbildung 6.8).

Wenn Sie die erweiterte Option ausgewählt haben, können Sie nun mit denverbleibenden Konfigurations- und Prüfaufgaben fortfahren. Mit dem DMO-Werkzeug werden Sie durch die einzelnen Schritte geleitet. Wenn Sie beiSchritt 4, der sogenannten Vorverarbeitung, angelangt sind, wird das Schat-

Page 15: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

210

ten-Repository erzeugt. Zu diesem Zeitpunkt sind keine Änderungen an derSystemkonfiguration mehr möglich. Falls Sie dennoch Änderungen vorge-nommen haben, kann es sein, dass die Konfigurationen des Schatten- unddes tatsächlichen Systems nicht mehr übereinstimmen. Benutzer könnenjedoch weiterhin auf das System zugreifen und Transaktionen buchen; neueTransporte in die Umgebung sind allerdings nicht mehr möglich (sieheAbbildung 6.9).

Abbildung 6.8 »Database Migration Option« (DMO) – Reduzierung des Systemausfalls

Abbildung 6.9 »Database Migration Option« (DMO) – Sperrung der Entwicklungsumgebung

Die folgenden Upgradeschritte finden im Schattensystem statt, während dastatsächliche System weiterläuft. Sobald das Upgrade des Schattensystems

SAP Business Suite auf SAP HANA 6.3

211

abgeschlossen ist, wird mit dem DMO-Werkzeug das Schattensystem in dasSAP-HANA-System verschoben. Die eigentlichen Datenverschiebungenerfolgen als Exporte und Importe. Bei großen SAP-Business-Suite-Systemenempfiehlt sich eine Aufteilung der sehr großen Tabellen, bevor diese ver-schoben werden. In einigen Fällen sollten Indizes zur Beschleunigung desProzesses hinzugefügt werden. Die Datenexporte und -importe finden nachder Vorverarbeitung in Schritt 4 statt.

Das System muss nun für weitere Datenaktualisierungen gesperrt werden,bis die Daten auf SAP HANA migriert wurden. Hierzu gehören Datenlade-jobs, Finanzzuordnung, Abschreibungen, Benutzereinträge sowie alle Jobs,mit denen Daten im System geändert, aktualisiert oder neu hinzugefügt wer-den. Sobald alle Vorbereitungen getroffen sind, können Sie das System sper-ren und mit dem Transfer beginnen (siehe Abbildung 6.10). Für gewöhnlichbietet sich dazu ein Wochenende an.

Abbildung 6.10 »Database Migration Option« (DMO) – Sperrung des Quellsystems

Nachdem die Daten auf das neue SAP-HANA-System migriert wurden, stehtIhnen ein funktionierendes System zur Verfügung, und die Benutzer könnenauf die neue Umgebung zugreifen. Im Master Guide des SAP Marketplacegibt es Empfehlungen zu den Nachbereitungsschritten. Sie sollten die aktu-elle Version zurate ziehen und prüfen, ob für Ihr System Änderungen not-wendig sind und welche Nachbereitungsschritte optional sind.

Page 16: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

212

Hinweis

Weitere Informationen zu DMO finden Sie in den SAP-Hinweisen 1875197 und1813548. Für Basis-Mitarbeiter empfiehlt sich die zweitägige DMO-Schulung mitdem Titel »HA-250: Migration to SAP HANA Using DMO«.

6.3.3 Kopieren, upgraden und migrieren

Wenn Sie keinerlei Risiko eingehen möchten, können Sie SAP Business Suiteauf SAP HANA mit der Option zum Kopieren, Upgraden und Migrierenimplementieren. Bei dieser Option wird das SAP-Business-Suite-System mit-hilfe von herkömmlichen Basis-Werkzeugen auf ein anderes System kopiert.Anschließend wird im neuen SAP-HANA-System für die Kopie ein Upgradedurchgeführt. Dabei werden dieselben Schritte wie in Abschnitt 6.3.2 (unterEinsatz von DMO) ausgeführt. Diese Option erfordert mehr Hardware undSchritte als bei der In-Place-Migration. Allerdings sinkt auch das Projektri-siko. Für Benutzer, die vor einer vollständigen Migration einen »Proof ofConcept« durchführen möchten, ist diese Option auch sehr gut geeignet.

6.3.4 Sizing

Selbstverständlich müssen Sie auch die Größe des Systems anpassen, undzwar unabhängig davon, welche Implementierung von SAP Business Suiteauf SAP HANA Sie auswählen. Hierfür stehen Ihnen drei Optionen zur Ver-fügung: SAP QuickSizer (den Sie bereits aus Abschnitt 6.2.2 kennen und derim Folgenden beschrieben wird), ein ABAP-Bericht und Anbieterwerkzeuge.

SAP QuickSizer

Wenn Sie mit dem Sizing in der SAP-HANA-Umgebung beginnen, sollten Siezuerst die SAP-Richtlinien für das Datenbank-Sizing lesen. Diese finden Siein SAP-Hinweis 1514966. Mit diesem Grundwissen können Sie die erstenSizing-Versuche mithilfe des Werkzeugs SAP HANA QuickSizer unterneh-men. Dieses Werkzeug finden Sie unter http://service.sap.com/quicksizer.

Erstellen Sie zunächst ein Projekt, und geben Sie auf dem Bildschirm in denBereichen Project Data, Customer Data, Platform and Communication,System Availability und Network Infrastructure so viele Informationenwie möglich ein (siehe Abbildung 6.11). Die meisten dieser Daten werdennicht für das Sizing verwendet, stellen aber SAP und Ihrem Hardwarepartnerwertvolle Informationen bereit, wenn Sie die Sizing-Ergebnisse mit diesenteilen.

SAP Business Suite auf SAP HANA 6.3

213

Abbildung 6.11 Erstellen eines SAP-HANA-Sizing-Projekts für SAP Business Suite

In diesem Beispielprojekt planen wir die Implementierung eines neuen SAP-ERP-Financials-Systems mit Financial Accounting und Controlling für dieSAP Business Suite auf SAP HANA. Diese Aktivität unterscheidet sich in SAPQuickSizer nicht von einem Sizing eines herkömmlichen festplattenbasiertenSystems. Erst nachdem das Sizing abgeschlossen wurde, können wir mithilfeder SAP-Richtlinien das Ergebnis des klassischen Sizings auf das identischeSAP-HANA-Sizing übertragen. Daher müssen wir die zu implementierendeKomponente auswählen – in unserem Fall also FI-CO.

Es gibt 940 Benutzer, die nach ihren Aktivitäten in »niedrig«, »mittel« und»hoch« aufgegliedert werden. Wie Sie in der ersten Zeile der geplantenDatenmengen sehen können (Abbildung 6.12), planen wir die Verarbeitungvon durchschnittlich 5 Millionen Rechnungsdokumenten mit durchschnitt-lich zwei Auftragspositionen pro Tag. Von diesen Dokumenten werden plan-mäßig ca. 5 % pro Jahr geändert und 25 % angezeigt.

Insgesamt sollen in unserem System Daten aus 48 Monaten vorgehalten wer-den, und die Archivierung ist deaktiviert. Dies ist die durchschnittliche Nor-mallast zwischen 9:00 und 18:00 Uhr. Darunter ist die Spitzenlast zwischen12:00 und 13:00 Uhr eingetragen (Sie können diese Zeiten entsprechendIhren Spitzenlasten ändern). Zudem geben wir in Table 3 die geschätzteAnzahl an Datensätzen für die Datensatztypen ohne Auftragspositionen ein.Nachdem wir alle Informationen eingegeben haben, klicken wir im oberenBereich des Bildschirms auf die Schaltfläche Calculate result und erhaltendie Sizing-Ergebnisse (siehe Abbildung 6.13).

Page 17: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

214

Abbildung 6.12 Eingabe der Sizing-Vorgaben für FI-CO

Abbildung 6.13 Sizing-Ergebnis für FI-CO

SAP Business Suite auf SAP HANA 6.3

215

Aus dem Ergebnis geht hervor, dass es sich um ein sehr großes System mitSystemanforderungen von mindestens 2.080.000 SAPS und über 5 TB Spei-cher handelt. Zur Erinnerung: Dies gilt nur für ein herkömmliches festplat-tenbasiertes System, und die SAP-Richtlinien sind erforderlich, um dies inaussagekräftige und vergleichende SAP-HANA-Systemgrößen umzusetzen.Informationen darüber, wie Sie diesen Sizing-Schätzwert für SAP HANAumwandeln, erhalten Sie im PDF-Anhang von SAP-Hinweis 1779345.

Im Allgemeinen ist es ratsam, das durchsatzbasierte Sizing anstelle einesSizings zu nutzen, das auf der Anzahl der Benutzer beruht. Denn damit kön-nen Sie die Datenhaltungszeiten besser steuern und den benötigten Speicherreduzieren. Selbstverständlich können Sie die Daten auch im Nearline Sto-rage (NLS) vorhalten und auf diese zugreifen, selbst wenn sie nicht physischin SAP HANA gespeichert werden.

ABAP Report

Das Sizing der SAP Business Suite auf SAP HANA mithilfe des SAP-QuickSi-zer-Werkzeugs ist ein sehr guter Ausgangspunkt für eine Neuimplementie-rung. SAP bietet Ihnen aber auch ein auf ABAP basierendes Sizing-Pro-gramm, das für Bestandskunden mit vorhandenem SAP-ERP-Systemeingesetzt werden kann. Dieses Programm erhalten Sie als Anhang zu SAP-Hinweis 1872170 (siehe Abbildung 6.14). Sie können das Werkzeug gemäßden Anweisungen im Hinweis herunterladen und für sehr detaillierte SAP-HANA-Sizing-Schätzungen in Ihrem SAP-Business-Suite-Migrationsprojektnutzen.

Abbildung 6.14 Sizing-Programm für »SAP Business Suite auf SAP HANA« – SAP-Hinweis 1872170

Page 18: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

216

Mit diesem Programm wird ein Ergebnisbericht generiert, der Sie genauüber die Speicheranforderungen für Datenbanktabellen informiert (live-Cache wird derzeit noch nicht unterstützt). Das ABAP-Programm ist sogar inder Lage, Ereignisse während der Migration zu prüfen, wie z.B. Depooling,Indizes, Declustering und LOBs (große Objekte). In diesem Werkzeug kön-nen Sie zudem über Filter bestimmte Bereiche für das Sizing auswählen.Somit können Sie spezifische Tabellen für das SAP-HANA-Sizing oder sogareinzelne Module wie Financial Accounting oder Materials Management ineiner Sidecar-Implementierung Ihres SAP-HANA-Systems auswählen.

Wenn Sie das Programm ausführen, wird Ihnen der Fortschritt in einemBildschirm angezeigt. Dies kann einige Zeit in Anspruch nehmen, abhängigdavon, wie viele parallele Dialogprozesse Sie im ersten Eingabebildschirmangegeben haben. Es ist durchaus möglich, dass das Programm in großenSystemen mehr als eine Stunde benötigt. Bei vielen Unternehmen sollte dasProgramm nach Feierabend ausgeführt werden, wenn mehr Ressourcenzugewiesen werden können und die Auswirkungen auf die Benutzer nurminimal sind.

Wie Sie in diesem Beispiel sehen können (Abbildung 6.15), wird die SAPBusiness Suite auf SAP HANA ungefähr 1,96 TB des Speichers benötigen.Diesen Schätzwert können wir den Anbietern vorlegen und Angebote für dieSAP-HANA-Hardware anfordern.

Abbildung 6.15 Ergebnis des SAP-HANA-Sizing-Programms für SAP Business Suite

SAP Business Suite auf SAP HANA 6.3

217

Hinweis

In SAP-Hinweis 1872170 ist auch ein detailliertes PDF-Dokument mit dem Titel»Frequently Asked Questions« enthalten. Es informiert Sie, wie Sie das Programmherunterladen und ausführen und die Ergebnisse auswerten müssen.

Anbieterwerkzeuge

Neben SAP QuickSizer und den ABAP-Sizing-Werkzeugen haben viele Hard-wareanbieter eigene Tabellenkalkulationen zur Berechnung oder Verifizie-rung der Hardware-Sizing-Vorhaben generiert. Einige Unternehmen, wiez.B. HP, haben zudem Softwareprogramme entwickelt, die Unterstützungbei einem SAP-HANA-Sizing-Vorhaben bieten. Das Sizing-Werkzeug von HPkann von der Webseite des Unternehmens heruntergeladen und in wenigenMinuten auf dem Desktop installiert werden.

Der Vorteil vieler dieser Sizing-Werkzeuge ist, dass sie häufig Preislisten fürdie Hardware bereitstellen, die der Anbieter für Ihre Sizing-Anforderungenvorschlagen könnte. In unserem Sizing-Beispiel, bei dem das Sizing-Werk-zeug von HP zum Einsatz kommt, wird die Entwicklungs- und Sandboxum-gebung zur Kostenersparnis auf derselben Hardware positioniert (sieheAbbildung 6.16).

Abbildung 6.16 HP-Sizing-Werkzeug für »SAP Business Suite auf SAP HANA«

Die Qualitäts- und Testumgebung sowie die Produktivumgebung werdenseparat gehalten. Die drei Umgebungen werden in Abbildung 6.16 darge-

Page 19: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

218

stellt. Das Sizing-Werkzeug von HP gibt an, dass im Produktivsystem dieAnforderungen mit einem einzigen SAP-HANA-System mit 1 TB Speichererfüllt werden können, wobei der interne Festplattenplatz 7 TB beträgt. Wei-terhin empfiehlt das Werkzeug zwei SAP-HANA-Systeme mit 256 GB Spei-cher und 3 TB Festplattenplatz für die anderen Umgebungen. Der Listen-preis für solch eine Konfiguration läge bei insgesamt 270.892 USD vorDienstleistungen, Steuer und Rabatten.

Andere Sizing-Werkzeuge und Tabellenkalkulationen von Unternehmen wieFujitsu, IBM, Dell, Huawei, NEC, Hitachi und Cisco/EMC sind auf Anfrageerhältlich.

6.4 SAP Business Warehouse auf SAP HANA

SAP BW auf SAP HANA ist bis heute die gängigste Form einer SAP-HANA-Implementierung, weil SAP BW die erste für SAP HANA zur Verfügung ste-hende Anwendung war und SAP BW gleichzeitig das am häufigsten ver-wendete Berichtssystem für SAP-Kunden ist. Trotz seines Status als meist-verwendetes Berichtssystem wurde SAP BW mit signifikanten Problemenkonfrontiert und stieß an die Grenzen seiner Leistungsfähigkeit, da sich dieDatenvolumen der meisten Unternehmen stetig vermehrten und zig Tera-byte groß wurden. Herkömmliche relationale Systeme auf Festplattenbasiskonnten mit den erforderlichen Datenlesevorgängen und Tabelleneinfü-gungen nicht Schritt halten.

Release 7.4

Auf SAP HANA können Sie Ihre älteren SAP-BW-Systeme auf SAP BW Version 7.3aktualisieren. Um jedoch die Geschwindigkeit und die Funktionen von SAP HANAvoll nutzen zu können, sollten Sie SAP BW 7.4 einsetzen. Diese Version wurde sogeschrieben und umgestaltet, dass alle neuen Funktionen von SAP HANA in einemeinheitlichen, flexiblen und leistungssteigernden Data Warehouse für Unterneh-men des 21. Jahrhunderts bereitgestellt werden. SAP hat z.B. einige Bereiche desstandardmäßigen Business Content in Content Release 7.47 SP 7 neu geschrieben,um das Laden der Daten und die Datenarchitektur zu vereinfachen und flexibleDatenmodelle zu erzeugen. Der neue, für SAP HANA optimierte Inhalt umfasstBereiche wie Debitoren- und Kreditorenbuchhaltung, Produktkostenprognoseund -simulationen, Profit-Center-Rechnung, Hauptbuch, Vertriebsübersicht, Lie-ferservices, Fakturakonditionen, Auftragsrückstände, Einkaufsübersicht, Rech-nungswesen im Einkauf, Vertragsmanagement, Rechnungsprüfung und Service-Levels. Neue Inhalte für andere Bereiche können in nachfolgenden Releases hinzu-gefügt werden.

SAP Business Warehouse auf SAP HANA 6.4

219

In den folgenden Abschnitten nennen wir Ihnen einige zentrale Aspekte, dieSie bei der Umstellung eines SAP-BW-Systems auf SAP HANA berücksichti-gen sollten. Wir organisieren die Abschnitte in verschiedene Hauptschritte:Sizing, Vorbereitung für eine Migration, Durchführung einer Migration undOptimierung einer Migration. Abschließend präsentieren wir einige neueFunktionen in SAP BW 7.4, die besonders relevant für die Migration vonSAP BW auf SAP HANA sind.

6.4.1 Sizing

Es gibt zwei Optionen für das Sizing eines SAP-BW-Systems auf SAP HANA:SAP QuickSizer (der bereits für das Sizing von SAP HANA als Data Warehouseund SAP Business Suite auf SAP HANA erörtert wurde) und das SAP BWMigration Cockpit für SAP HANA. Im Folgenden werden beide Möglichkeitenbeschrieben.

Sizing von SAP BW mit dem SAP-QuickSizer-Werkzeug

Das erste Sizing-Werkzeug von SAP ist QuickSizer (siehe Abbildung 6.17). Ereignet sich für Unternehmen, die noch kein SAP-ERP- bzw. SAP-BW-Systemeinsetzen oder SAP Rapid Deployment Solutions für SAP HANA nutzenmöchten und deshalb eine brandneue Implementierung planen. QuickSizerist nicht für Unternehmen vorgesehen, die bereits eine SAP-ERP- oder SAP-BW-Lösung einsetzen. Diese Kunden sollten stattdessen die von SAP undanderen Anbietern bereitgestellten Werkzeuge verwenden, die in diesemKapitel vorgestellt wurden.

Die Speicheranforderungen von SAP HANA für SAP-BW-Caches und zusätz-liche Komponenten sind auf ca. 50 GB festgelegt. (Der Rest wird anhand derGröße der spalten- und zeilenbasierten Speicher gesteuert.) Der erste Schrittfür die Anwendung von QuickSizer besteht in der Eingabe der Projektinfor-mationen: Betriebssystem, Hardware und Datenbank. Danach öffnen Sie dieQuickSizer-Menüs.

Im Bereich Table 1 geben Sie die Planungsinformationen ein (wenn Sie Inte-grated Planning [IP] in SAP BW verwenden). Die mit einem roten Sternchenmarkierten Felder sind Pflichtfelder. Für H-PLANN-1 geben Sie im FeldUsers die maximale Anzahl gleichzeitiger Benutzer ein. Die Felder S.t. undE.t. beziehen sich auf die Start- und Endzeiten für die Verarbeitung. DurchEingabe dieser Informationen erhalten Sie am Ende des Sizings zusätzlicheine Schätzung der Lastverteilung auf dem SAP-HANA-System nach Zeitperi-oden.

Page 20: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

220

Abbildung 6.17 SAP QuickSizer für SAP BW auf neuen SAP-HANA-Implementierungen

Geben Sie in Table 2 die voraussichtliche Anzahl von Informationsverbrau-chern (H-BW-INFO), Anwendern (H-BW-BUSI.) und Experten (H-BW-

EXPER) ein. SAP empfiehlt ein Verhältnis von 71 %, 26 % bzw. 3 % für jedeBenutzergruppe. Sie können aber auch Ihre eigenen Berechnungen einge-ben, falls Sie bessere Schätzungen ermittelt haben. Es sollte auf jeden Falldarauf geachtet werden, dass sich die Anzahl von SAP-BW-Nutzern aufgleichzeitige Anwender (und nicht auf festgelegte Anwender) bezieht. Fürdiesen Zweck erhalten Sie sehr gute Schätzungen aus Ihrem EarlyWatch-Bericht im SAP Solution Manager. Ihr Basis-Team sollte in der Lage sein,Ihnen genauere Auskünfte darüber zu geben.

Geben Sie den geschätzten Verteilungsprozentsatz der Benutzer in den Spal-ten Report., OLAP und Explor. ein. In diesem Beispiel haben wir geschätzt,dass von den 438 Informationsverbrauchern 33 % statische vorformatierteBerichte verbrauchen, 56 % OLAP-Werkzeuge, wie z.B. SAP BEx Web Analy-zer oder SAP BusinessObjects Analysis, verwenden und die restlichen 11 %Daten untersuchen und eine große Menge an Navigationsaktivitäten aufwei-sen werden. Diese Schätzungen helfen SAP QuickSizer dabei, die Größe deserforderlichen Speichers zu berechnen.

SAP Business Warehouse auf SAP HANA 6.4

221

In Table 3 schätzen Sie, wie viele Datensätze periodisch in SAP BW geladenwerden. In diesem Beispiel gehen wir davon aus, dass 279.994.355 Daten-sätze täglich zwischen 12:00 und 01:00 Uhr geladen werden.

In Table 4 schätzen Sie einen Speicherplatzbedarf von 2,9 TB im Spaltenda-tenspeicher und einen Speicherplatzbedarf von 500 GB im Zeilendatenspei-cher in SAP HANA. Diese Sizing-Zahl ist datenbankspezifisch, und SAP bieteteinige Programme, die bei der Berechnung realistischer Schätzungen hilf-reich sein können. Im SAP-Hinweis 1637145 finden Sie Programme, die aufSAP BW laufen und bei der Ermittlung realistischer Sizing-Zahlen helfen. DasShell-Skript für jeden Datenbanktyp befindet sich in der Datei get_size.zip,die extrahiert und zusammen mit der Datei load_RowStore_List.sql ausgeführtwerden sollte, um die Größe in Table 4 eingeben zu können. Die einzigeAusnahme stellt die IBM-DB2-Datenbank auf z/OS dar. Für letztere Kombi-nation steht stattdessen ein ABAP-Programm zur Verfügung (siehe SAP-Hin-weis 1736976). Wir sollten ebenfalls erwähnen, dass ausschließlich für DB2die Eigenkomprimierung der Datenbank in der Schätzung des Umfangs ent-halten ist. Bei anderen Datenbanken mit eingeschalteten Komprimierungen(z.B. Oracle) muss die Sizing-Zahl entsprechend angepasst werden. Wirmöchten ebenso darauf hinweisen, dass dieses Programm davon ausgeht,dass Ihr SAP-BW-System Unicode-fähig ist. Sollte dies nicht der Fall sein, istes ratsam, zusätzliche 10 % zu Ihrer Sizing-Ausgabe hinzufügen.

Obwohl tatsächliche Komprimierungsverhältnisse und Beispiele von SAP aufrealen Kundenszenarien beruhen, schätzen wir in diesem Beispiel die Kom-primierungsrate auf 1:5. Dieses Komprimierungsverhältnis wird wahr-scheinlich für Ihr eigentliches System höher oder niedriger sein. Eine fünffa-che Komprimierungsberechnung wird jedoch gewährleisten, dass wir unsereHardware nicht wesentlich unterdimensionieren.

Jetzt haben Sie die Voraussetzungen dafür geschaffen, die Informationen deseigentlichen SAP-BW-Systems hinzuzufügen. Der größte Teil der erforderli-chen Informationen für Table 5 und Table 6 (siehe Abbildung 6.18) steht inder Administrator Workbench (Transaktion RSA1) in SAP BW zur Verfügung(siehe Berichte wie SAP_ANALYZE_ALL_INFOCUBES, ANALYZE_RSZ_TABLES undSAP_INFOCUBE_DESIGNS, die jeweils auch Informationen für die einzelnenInfoProvider bereitstellen).

Geben Sie in Table 5 die InfoCube-Informationen ein. Sie können maximaleine Anzahl von 13 Dimensionen (in das Feld Dim.) eingeben. Die drei fest-gelegten Dimensionen eines InfoCubes sind bereits enthalten. Geben Siealso nur die freien Dimensionen ein. Das Feld KeyF. bezieht sich auf die

Page 21: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

222

Anzahl der Kennzahlen in der Faktentabelle Ihres InfoCubes, und das FeldCom. stellt die geschätzte Komprimierung dar. Wenn Sie über keine besse-ren Schätzungen verfügen, kann ein Verhältnis von 1:5 für ein anfänglichesSizing dienen, bevor Sie die Schätzung mit Ihrem Hardwareanbieter genauerfestlegen.

Abbildung 6.18 QuickSizer für SAP BW auf SAP HANA: BW-Daten

Geben Sie im Feld Initial load die Anzahl der Datensätze im bestehendenInfoCube ein, und im Feld Period. Upld geben Sie die Anzahl der Datensätzeein, die schätzungsweise periodisch geladen werden. Die Informationen zudieser Datensatzzahl stehen in vielfältiger Weise in SAP BW zur Verfügung.Sie können diese Informationen finden, indem Sie in Transaktion RSA1 zujedem InfoCube gehen und anschließend auf der Registerkarte Content miteinem Rechtsklick Manage auswählen. Hier wählen Sie Number of Entries,um die Anzahl der Datensätze aus der Faktentabelle anzuzeigen. Das Pro-gramm ANALYZE_RSZ_TABLES wird alle Einträge auch in der Dimensionsta-belle erfassen. Diese Zahlen können für die anfängliche Schätzung derDatenladungen verwendet werden. Zum Schätzen der Uploads können Sieanhand der Datenpakete abschätzen, wie viele Datensätze täglich geladenwerden. Da diese einen wesentlichen Teil des SAP-HANA-Umfangs ausma-chen, ist es wichtig, genug Zeit für die sorgfältige Ermittlung dieser Zahlenaufzuwenden.

SAP Business Warehouse auf SAP HANA 6.4

223

Bei der letzten Position in Table 5 müssen Sie schätzen, wie viele Datenla-dungen in SAP BW erhalten bzw. behalten werden. In diesem Beispiel schät-zen wir tägliche Ladungen für die meisten InfoCubes und beabsichtigen,Daten von einem Zeitraum von zwei Jahren zu behalten. Dies würde 2 × 365= 730 bedeuten. Wir haben jedoch planmäßige Ausfallzeiten für Upgrades,Patches und geplante Services für nächstes Jahr mit einkalkuliert, sodass dieZahl etwas niedriger ausfallen wird. Da der letzte InfoCube in der Schätzungperiodisch geladen wird, planen wir für diesen nur 208 Perioden ein.

In Table 6 werden die Schätzungen für die DataStores (DSOs) hinzugefügt.Die Logik ist derjenigen, die in Table 5 angewendet wurde, sehr ähnlich. DieFelder NumF., TxtFlds und CharL. beziehen sich jedoch auf die Anzahl dernumerischen Felder im DSO, die Anzahl an Textfeldern bzw. auf die durch-schnittliche Länge der Zeichenfelder. Dies lässt sich nur schwer einschätzenund erfordert von Ihrem SAP-BW-Team gute Designinformationen.

Das Kennzeichen WO ist nicht erforderlich, aber es identifiziert, ob das DSOschreiboptimiert ist und somit nicht so viele Log-Dateieinträge aufweist wieein reguläres DSO. Die restlichen Felder verhalten sich genauso wie für dieInfoCubes in Table 5.

Nachdem Sie die Einträge vollständig abgeschlossen haben, werden Sie vonSAP QuickSizer eine recht gute Erstschätzung der erforderlichen Komponen-ten erhalten. In Abbildung 6.19 sehen Sie ein Beispiel für die Resultate.

Abbildung 6.19 Die SAP-QuickSizer-Ergebnisse

Wie Sie sehen, setzt dieses Beispiel eines SAP-HANA-Sizings einen Speichervon 1,6 TB voraus. Da Sie diese Kapazität kaum mit einem einzigen Server-knoten erreichen können, sollten Sie ein Multiknotensystem verwenden. In

Page 22: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

224

einem solchen Fall wird SAP BW auf SAP HANA die Stammdaten, ABAP-Sys-temtabellen und die Daten der zeilenbasierten Speicher im Master-Knoteneinsetzen. Die anderen verbundenen Serverknoten werden die PersistentStaging Area (PSA), InfoCubes und DSOs enthalten.

Wenn viele Knoten hinzugefügt werden, findet mehr Verarbeitung im Mas-ter-Knoten statt (wie z.B. Stammdatenzugriffe). Aus diesem Grund solltenSie in Abstimmung mit Ihrem Hardwareanbieter den Speicher des Master-Knotens größer bemessen, als von SAP QuickSizer geschätzt wird. Mit diesenInformationen ausgestattet, können Sie Ihren Hardwarepartner um Ange-bote und Kostenvoranschläge bitten.

SAP-BW-Sizing mit dem SAP BW Migration Cockpit für SAP HANA

Kunden, die bereits über ein SAP-BW-System verfügen, haben bessere Alter-nativen zum Bereitstellen detaillierter Sizing-Ergebnisse. Im SAP BW Migra-tion Cockpit für SAP HANA steht Ihnen ein Werkzeug zur Verfügung, mitdem das aktuelle Betriebssystem und die Komprimierungsraten der Quellda-tenbank berücksichtigt werden. Das Werkzeug plant zudem ein, dass in SAPBW 7.4 unnötige Daten, wie z.B. die Tabellen der Persistent Staging Area(PSA), aus dem Speicher auf Datenträger ausgelagert werden, wenn diesenicht benötigt werden (siehe Abbildung 6.20).

Abbildung 6.20 Sizing von SAP BW auf SAP HANA mit dem »SAP BW Migration Cockpit für SAP HANA«

Wird dieses Programm in einem Produktivsystem ausgeführt, erhalten Siesehr genaue Sizing-Informationen. Darin eingeschlossen ist das Sizing für

SAP Business Warehouse auf SAP HANA 6.4

225

RAM sowie für den dynamischen Laufzeitspeicher, Log-Speicher und Fest-plattenspeicher. Es liefert sogar Einzelheiten zu Datengrößen mit entspre-chendem dynamischen Laufzeitspeicher für zeilen- und spaltenbasierte Spei-cher sowie die berechnete und geschätzte Größe im SAP-HANA-Speicher.

Je präziser die Genauigkeit der durchgeführten Schätzung ist (die, wie inAbbildung 6.21 dargestellt, anhand von Optionsfeldern ausgewählt werdenkann), desto länger wird das Programm laufen. Bei 12 parallel laufenden Pro-zessoren und einem 9-TB-Datenlager ist eine Laufzeit von 30 bis 70 Minutennicht unüblich. Um die Geschwindigkeit des Prozesses zu erhöhen, könnenSie Analysetabellen unterdrücken, die kleiner als 1 MB sind.

Abbildung 6.21 Eingabeparameter für das Sizing von SAP BW auf SAP HANA

Da Ausfallzeiten beim Ausführen dieses Sizing-Programms durchaus vor-kommen können, sollten Sie zusätzlich den Parameter in rdisp/max_wprun_time in 0 ändern. Das können Sie in SAP BW mit der Transaktion RZ11durchführen. Abschließend schätzen Sie das Wachstum des Systems in

Page 23: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

226

einem bestimmten Zeitraum als Prozentsatz oder als absolutes Wachstum inGigabyte. Abbildung 6.22 zeigt ein Beispiel für die Ergebnisse eines Sizings.

Abbildung 6.22 Ergebnisse für das Sizing von SAP BW auf SAP HANA

Die Ausgabe wird in der von Ihnen zuvor bestimmten Datei gespeichert, dieSie nun Ihren Hardwareanbietern für Sizing-Vorgaben und Hardwareaus-wahl per E-Mail zukommen lassen können. Weitere Informationen zumSizing finden Sie in den folgenden SAP-Hinweisen:

� SAP-Hinweis 1514966: Sizing SAP HANA Database

� SAP-Hinweis 1637145: SAP BW on HANA: Sizing SAP HANA Database

SAP Business Warehouse auf SAP HANA 6.4

227

Bevor Sie Ihre Hardware bestellen oder Ihre Budgets festsetzen, empfehlenwir Ihnen, dass Sie Ihre Planungen mit Ihrem bevorzugten Anbieter erarbei-ten bzw. besprechen.

6.4.2 Vorbereiten einer Migration

Zur Vorbereitung einer Migration von SAP BW auf SAP HANA sind einigeSchritte notwendig. Diese werden im Folgenden erläutert.

Housekeeping im SAP-BW-System

SAP BW ist ein komplexes System mit vielen Redundanzen und kopiertenDaten in der Datenbank, die bereinigt werden können. Das betrifft Log-Dateien, Ergebnistabellen, das temporäre Staging von Daten und den Zwi-schenspeicher von Daten, in dem sich die Daten befinden, bevor sie inübergeordnete Datenmodelle geschoben werden. Sie können sich eine be-trächtliche Menge an Arbeit sparen, wenn Sie noch vor einer SAP-HANA-Migration oder einem SAP-BW-Upgrade-Projekt eine Bereinigung durch-führen.

Durch eine solche Bereinigung kann die Größe eines SAP-BW-Systems um20 bis 30 % reduziert werden. So konnte beispielsweise das SAP-BW-Systemeines großen Öl- und Gasunternehmens von 108 TB auf unter 36 TB redu-ziert werden, indem vor der SAP-HANA-Migration mehr Daten in den Near-line Storage (NLS) geschoben wurden. Dadurch konnte das UnternehmenMillionen von US-Dollar an Hardware- und Lizenzkosten sparen.

Da SAP HANA viele der Systemtabellen und Stammdaten (zeilenbasierteSpeichertabellen) auf dem Master-Knoten speichert, sollten diese Tabellen soklein wie möglich gehalten werden, um genügend Platz auf diesem Knotenzu schaffen. Die wichtigsten Punkte, auf die dabei geachtet werden sollte,sind die folgenden:

� Bereinigen Sie die PSA von Daten, die bereits auf DSOs geladen wurden.

� Löschen Sie die Aggregate (Ergebnistabellen), da sie nicht mehr gebrauchtwerden.

� Komprimieren Sie die E- und F-Tabellen in allen InfoCubes, um InfoCubeswesentlich zu verkleinern.

� Entfernen Sie Daten aus statistischen Cubes (diese beginnen mit dem tech-nischen Namen 0CTC_xxx). Sie enthalten Leistungsangaben für das auf derrelationalen Datenbank betriebene SAP BW. Das Löschen dieser Daten

Page 24: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

228

kann mithilfe der Transaktion RSDDSTAT oder des Programms RSDDSTAT_DATA_DELETE durchgeführt werden.

� Achten Sie auf Log-Dateien, Lesezeichen und nicht verwendete Abfragenund Vorlagen des SAP Business Explorers (BEx) (Transaktion RSZDELETE).

� Entfernen Sie so viel wie möglich aus dem Zwischenspeicher, den DTP-Fehlerprotokollen und den temporären Datenbankobjekten des Daten-transferprozesses (DTP). Hilfe und Programme zu diesem Thema findenSie in den SAP-Hinweisen 1139396 und 1106393.

� Für schreiboptimierte DSOs, die Daten in meldepflichtige DSOs schieben(LSA++-Ansatz), entfernen Sie die Daten in den schreiboptimierten DSOs.Diese stehen bereits in übergeordneten Objekten zur Verfügung.

� Migrieren Sie alte Daten zu NLS auf einem kleinen Server. Der unregelmä-ßige Zugriff auf diese alten Daten durch einige Benutzer wird weiterhinmöglich sein. Abfragen auf diese Daten können auch weiterhin durchge-führt werden, wenn SAP BW auf SAP HANA liegt, auch wenn In-Memorynicht erforderlich ist.

� Entfernen Sie Daten in nicht verwendeten DSOs, InfoCubes und Dateien,die im SAP-BW-System für das Staging verwendet werden. Dies schließteine mögliche Restrukturierung von Stammdatentext und Attributen mit-hilfe von Prozesstypen in der Transaktion RSPC mit ein.

Sie sollten eventuell auch in der Tabelle RSBATCHDATA gespeicherte Hinter-grundinformationen bereinigen. Diese Tabelle kann sehr groß werden,wenn sie nicht gepflegt und verwaltet wird. Sie sollten außerdem in Erwä-gung ziehen, alle IDocs zu archivieren und die tRFC-Queues zu bereinigen.All diese Schritte werden die Größe des SAP-HANA-Systems reduzieren undSie dabei unterstützen, genügend Platz für die Systemtabellen auf dem Mas-ter-Knoten zu schaffen.

Des Weiteren bietet Ihnen SAP im SAP-Hinweis 706478 einige Vor-schläge, wie Sie in Zukunft ein zu schnelles Wachsen der Basis-Tabellenverhindern können. Falls Sie SAP BW 7.0 SP 23 oder höher verwenden,können Sie unerwünschte Stammdaten auch direkt löschen (siehe SAP-Hinweis 1370848).

Abschließend können Sie das Programm RSDDCVER_DIM_UNUSED anwenden,um alle unbenutzten Dimensionseinträge in Ihren InfoCubes zu löschen undsomit die allgemeine Systemgröße zu verringern.

Sie können diese Aufgaben manuell ausführen. Allerdings bietet SAP hierfürauch einige Bereinigungsprogramme an. Wenn Sie SAP BW 7.0 SP 32 oder

SAP Business Warehouse auf SAP HANA 6.4

229

höher verwenden, können Sie eine Housekeeping-Aufgabenliste erstellenund automatisch Hilfe beim Bereinigen des Systems erhalten (siehe Abbil-dung 6.23). Sie müssen das Programm aus SAP-Hinweis 1829728 zuerstinstallieren, bevor Sie die Aufgabenliste SAP_BW_HOUSEKEEPING mithilfe vonTransaktion STC01 generieren können.

Abbildung 6.23 Die SAP-BW-Housekeeping-Aufgabenliste für die Systembereinigung

SAP bietet auch eine Bereinigungsliste und automatischen Support im SAPBW Migration Cockpit für SAP HANA 3.0 (siehe Abbildung 6.24). Dieseswichtige Cockpit-Werkzeug sollten Sie vor, während und nach der Migrationvon SAP BW auf SAP HANA nutzen. Es bietet Ihnen eine klare Übersichtüber alle wichtigen Aufgaben, die Sie im Rahmen einer Migration von SAPBW auf SAP HANA durchführen müssen.

Abbildung 6.24 »SAP BW Migration Cockpit für SAP HANA«-Housekeeping-Aufgaben

Page 25: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

230

Prüfungen vor einer Migration von SAP BW auf SAP HANA

Nachdem Ihr System nun bereinigt wurde, müssen Sie sich darauf vorberei-ten, das System auf SAP HANA zu migrieren. Die Voraussetzungen hierfürsind, dass Sie mindestens über SAP BW Version 7.3 verfügen, dass Unicodeimplementiert ist und die Sicherheitsumstellung für das SAP-BW-7.0-Systemabgeschlossen ist. Diese Schritte wurden von vielen Unternehmen nicht alsTeil ihres früheren SAP-BW-Upgrades mit durchgeführt.

Wir empfehlen Ihnen, Migrationen von SAP BW auf SAP HANA mit SAP BW7.4 durchzuführen. Aus diesem Grund beginnen viele Migrationsprojektevon SAP BW 7.0 und 3.5 auf SAP HANA zuerst mit einem kurzen techni-schen SAP-BW-Upgrade. Sie können die Unicode- und Sicherheitsumstellungdirekt in Ihrem SAP-BW-7.0-System vornehmen und anschließend zu SAPBW 7.4 übergehen. Diese Aufgaben erledigen Sie am einfachsten mit demDMO-Werkzeug (Database Migration Option). Hiermit lassen sich alle zuvorgenannten Aufgaben in einem einzigen Schritt im Rahmen der Migrationvon SAP BW auf SAP HANA durchführen.

Zur Planung der DMO-Schritte im SAP Software Update Manager (SUM) stelltSAP ein Checklisten-Werkzeug im SAP BW Migration Cockpit für SAP HANA3.0 bereit. Mit diesen Checklisten werden automatische Prüfprogramme fürdie SAP-BW-Versionen 3.5 und 7.x zur Verfügung gestellt. Das Cockpit-Werkzeug erhalten Sie als Anhang zu SAP-Hinweis 1729988 (siehe Abbil-dung 6.25).

In der Version 3.x dieses Werkzeugs werden Hunderte von Prüfungen auto-matisch im SAP-BW-System durchgeführt, einschließlich Plattform-Checksder Datenbank-, Anwendungs- und Systeminformationen. Basis-Prüfungensind ebenfalls für Support Packs, ABAP/Java Stacks, Unicode, SAP-BW-Relea-ses und Add-ons zu Ihrem System enthalten.

Die Idee hinter dem Checklisten-Werkzeug von SAP BW Migration Cockpitfür SAP HANA ist, dass es während des laufenden Projekts mehrmals ausge-führt wird: Einmal, bevor Sie beginnen, dann regelmäßig, während Sie Pro-bleme und Upgrade-Anforderungen lösen, und abschließend, nachdem dasSystem auf SAP HANA migriert wurde. Der letzte Schritt ist äußerst wichtig,weil das Checklisten-Werkzeug auch über spezifische Prüfungen für das SAP-HANA-System verfügt und Ihnen somit helfen kann, sämtliche Probleme zuidentifizieren, bevor Sie das System an Endanwender übergeben. Wenn dasWerkzeug ein rotes Kennzeichen anzeigt, sollten Sie dieses Problem lösen,bevor Sie mit der SAP-HANA-Migration beginnen. Wenn ein neues rotes

SAP Business Warehouse auf SAP HANA 6.4

231

Kennzeichen auftaucht, reparieren Sie den Fehler, bevor Sie mit der Migra-tion fortfahren und diese abschließen.

Abbildung 6.25 SAP BW Migration Cockpit für SAP HANA 3.0: Checkliste

Bei einem Upgrade von SAP BW auf eine höhere Version bietet SAP aucheine Aufgabenliste, die Sie vor dem eigentlichen Upgrade in der DMOdurchführen können (siehe Abbildung 6.26). Wenn Sie Version 7.0 SP 31oder höher nutzen, können Sie selbst eine Liste mit Aufgaben erstellen, dievor dem Upgrade erforderlich sind, und Unterstützung bei der Vorbereitungdes Systems erhalten. Je mehr Aufgaben Sie erledigen, desto schneller wirddas Upgrade sein, da Sie die Größe und Komplexität des Systems bereits vor-her reduzieren.

Um Zugriff auf diese Aufgabenliste zu erhalten, müssen Sie das Programmaus SAP-Hinweis 1734333 installieren und die Aufgabenliste SAP_BW_BE-FORE_UPGRADE mithilfe von Transaktion STC01 erzeugen.

Viele der Aufgaben aus diesen drei Werkzeugen überlappen sich teilweise,und einige sind nicht notwendig. Sie bieten jedoch eine sinnvolle Anleitung,wie Sie Ihr System vor dem SAP-BW-Upgrade und der SAP-HANA-Migrationbestmöglich bereinigen und dessen Größe reduzieren können.

Page 26: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

232

Abbildung 6.26 SAP BW vor der Upgrade-Aufgabenliste

6.4.3 Durchführen der Migration

In Kapitel 2, »SAP-HANA-On-Premise-Implementierungsoptionen«, habenwir Ihnen die drei Optionen für die Implementierung eines SAP-BW-Sys-tems auf dem SAP-HANA-System vorgestellt:

� Migrieren Sie Ihr gesamtes SAP-BW-System auf SAP HANA.

� Richten Sie ein neues SAP-BW-System ein (mit einer SAP-HANA-Daten-bank), das parallel zum vorhandenen SAP-BW-System bereitgestellt wird,und setzen Sie die neue SAP-BW-Umgebung für besonders komplexeoder neue Anforderungen ein. Dies wird als Side-by-Side- oder Sidecar-Installation bezeichnet und erfordert oft eine partielle Migration der SAP-BW-Transaktionsdaten sowie eine vollständige Replikation der meistenStammdaten.

� Implementieren Sie ein neues SAP-BW-System, und führen Sie es vollstän-dig auf SAP HANA aus.

Die ersten beiden dieser drei Optionen beinhalten eine Migration. In derersten Option, der Standardmigration, migrieren Sie Ihr gesamtes SAP-BW-System nach SAP HANA. In der zweiten Option, der partiellen Migration,installieren Sie eine zusätzliche Instanz von SAP BW und migrieren anschlie-ßend einen Teil Ihrer Transaktionsdaten in das neue SAP-BW-System, aufdem Sie dann SAP HANA betreiben.

Jede dieser Optionen hat ihre eigenen Vorteile und Einschränkungen. Siesollten daher frühzeitig entscheiden, wie viel Risiko Sie auf sich nehmen

SAP Business Warehouse auf SAP HANA 6.4

233

möchten, welche Prüfungen dafür erforderlich sind, wie viel Nichtverfügbar-keit des SAP-BW-Systems für Sie akzeptabel ist und welche Ressourcen Siefür das Migrationsprojekt verpflichten können. Wir werden als Nächstes diebeiden erstgenannten Optionen ausführlicher erörtern.

Standardmigration

Mit diesem Ansatz behandeln Sie Ihre SAP-BW-Umstellung auf SAP HANAals Datenbank-Migrationsprojekt. Sie beginnen mit dem SAP-BW-System,führen die zuvor erläuterte Bereinigung und die erforderlichen Vorbereitun-gen durch und migrieren die Datenbank auf SAP HANA, belassen aber dieAnwendungslogik und die Datenmodelle wie gehabt.

In diesem Szenario können Sie erneut das DMO-Werkzeug anwenden (sieheAbschnitt 6.3.2). DMO ist eine wichtige Option im Software Update Mana-ger (SUM) für Kunden mit veralteten SAP-BW-Systemen, die auf SAP HANAmigrieren möchten. Sie können das DMO-Werkzeug nutzen, wenn Sie min-destens SAP BW Version 7.0 mit Service Pack 17 (siehe SAP-Hinweis1799545 und Abbildung 6.27) installiert haben.

Abbildung 6.27 »Database Migration Option« für SAP BW auf SAP HANA

Die beste Herangehensweise bei der Datenbankmigration mit dem DMO ist,mit einem Sandbox-System zu beginnen und ein sogenanntes Runbook zuerstellen, in dem Listen mit Schrittanleitungen zu Problemen und Software-aufgaben geführt werden. Es ist durchaus üblich, dass nach der ersten Migra-tion ein Word-Dokument mit 90 bis 100 Seiten zur Verfügung steht, das

Page 27: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

234

Screenshots und Dokumentation enthält. Dieses Runbook ist der Schlüsselzum Erfolg. Sie sollten darauf aufbauen, wenn Sie auf das Entwicklungs- undanschließend auf das QA- und Produktivsystem migrieren.

Wenn Sie mit einem SAP-BW-System arbeiten, das nicht stark genutzt wirdoder eine hohe Verarbeitungskapazität besitzt, können Sie die Ausfallzeitminimieren, indem Sie das Schattensystem während des Upgrades ausgiebignutzen. Bei Einsatz eines Schattensystems wird das System und nicht dieDaten kopiert. Viele der Upgrade-Aufgaben erfolgen im Schattensystem,während das eigentliche System weiter ausgeführt wird. Das System ist erstin den späteren Schritten nicht für die Benutzer verfügbar, wenn die Konfi-guration und Daten auf SAP HANA verschoben werden. So wird die Ausfall-zeit des Systems auf ein Minimum reduziert.

Durch Auswahl der Standardoption oder der erweiterten Option in Abbil-dung 6.28 können Sie die Ausfallzeit für Ihre Migration reduzieren, da dasUpgrade in der Schatteninstanz stattfindet und das System erst ausfällt, wenndie Daten exportiert und in die SAP-HANA-Instanz importiert werden.

Abbildung 6.28 Minimieren des Systemausfalls für SAP BW über DMO

Partielle Migration

Viele Unternehmen haben sich dafür entschieden, die Migration von SAPBW auf SAP HANA mithilfe des Sidecar-Ansatzes durchzuführen. Dazu ge-hört die Installation eines neuen SAP-BW-Systems auf SAP HANA, das paral-lel zum aktuellen SAP-BW-System auf einer relationalen Datenbank betrie-ben wird. Anschließend werden InfoCubes und DSOs in wichtige Bereicheder SAP-HANA-Box transportiert, und die Datenladungen werden auf dasneue System als Teil kleinerer Projekte transferiert (für Transporte zwischenverschiedenen Softwarereleases siehe SAP-Hinweis 1090842). Unterdessenwerden andere InfoCubes und DSOs auf dem alten SAP-BW-RDBS-Systemeingesetzt. Im Grunde genommen betreiben Sie zwei SAP-BW-RDBS-Sys-teme gleichzeitig, ohne dass die Ladungen für InfoProvider in beiden Syste-men dupliziert werden.

Obwohl dieser Ansatz kostspieliger ist, ermöglicht er Ihnen jedoch, Ihr Alt-system zu behalten und somit die Risiken einer SAP-HANA-Migration mini-mal zu halten. Die Nichtverfügbarkeit des Systems kann ebenfalls minimal

SAP Business Warehouse auf SAP HANA 6.4

235

gehalten werden, da an einem Wochenende ein Funktionsbereich nach demanderen bearbeitet werden kann. Des Weiteren wird es Unternehmenermöglicht, schlecht gestaltete SAP-BW-Systeme mit vielen kundenspezifi-schen Codes, standardabweichenden Objekten und Workarounds, die dieAbfrageleistung verbessern sollen, neu zu implementieren. Viele dieser älte-ren Customizations werden eventuell nach einer Umstellung auf SAP HANAnicht mehr benötigt. Die Migration der InfoProvider kann ebenfalls übereinen längeren Zeitraum hinweg stattfinden.

Der Trick, um diesen Ansatz erfolgreich durchzuziehen, besteht jedoch inder Stilllegung der InfoProvider im Altsystem während des Wechsels zu SAPHANA. Das Laden in beide Systeme ist eine komplexe Angelegenheit undkönnte Stress für das SAP-ERP-System verursachen. Zum Beispiel könnte eserforderlich sein, Stammdaten während der Migrationsphase sowohl imSAP-BW-Altsystem als auch im neuen SAP BW, das auf das SAP-HANA-Sys-tem aufsetzt, zu duplizieren. Folglich sollten Sie diese Jobs stoppen und The-menbereiche mit gemeinsamen Stammdaten so bald wie möglich migrieren.Für weitere Informationen über das Laden von SAP-ERP-Daten auf zwei odermehr SAP-BW-Systeme empfehlen wir Ihnen die SAP-Hinweise 775568 und844222.

Migrieren einer Kopie von SAP BW auf SAP HANA

Sowohl bei einer Standardmigration als auch bei einer partiellen Migration könnenSie zunächst auch nur eine Kopie von SAP BW auf SAP HANA migrieren. DieserAnsatz ist bei Unternehmen mit einer sehr geringen Risikotoleranz beliebt, diezudem sehr viel Zeit für die Migration von SAP BW auf SAP HANA zur Verfügunghaben. In diesem Fall wird ein SAP-BW-System zunächst kopiert, dann werden dieSAP-Hinweise und SAP-BW-Upgrades übernommen, die auf der kopierten Versiondes SAP-BW-Produktionssystems benötigt werden, und abschließend werden dieFunktionen des alten SAP-BW-Systems mit dem neuen System abgeglichen, dasauf SAP HANA aufsetzt. Dies kann Interfaces, Open Hubs, SAP-BusinessObjects-BI-Berichte, Sicherheit, Broadcast-Berichte, Abfragen und Datenabgleich mit ein-schließen.

Nach der Durchführung solcher Tests werden die Prozessketten auf Funktionalitätund Laufzeiten geprüft, und die Daten werden anschließend erneut abgeglichen.Um diese Schritte durchziehen zu können, müssen Sie sorgfältig planen und Ihreduplizierten Prozessketten über das Wochenende laufen lassen, um negative Aus-wirkungen auf das SAP-ERP-System zu vermeiden. Es bedarf auch einer Planungund einiger Verbesserungen bzw. Erweiterungen an Ihren Ladeprogrammen, umdie Daten sowohl auf das SAP-BW- als auch auf das SAP-HANA-System zu laden,ohne dabei die Delta-Datenübernahme zu beeinflussen. Dies ist zwar nicht ein-fach, aber es ist möglich.

Page 28: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

236

Nachdem die Prüfungen abgeschlossen wurden, migrieren Sie einfach die Benutzerauf das neue SAP BW, das auf SAP HANA aufsetzt, und setzen das alte SAP BW aufder relationalen Datenbank außer Betrieb. Sie können es sogar während des Cut-overs als Risikominderungsstrategie einige Wochen lang inaktiv im Hintergrundlaufen lassen. Zusätzliche und hilfreiche Informationen dazu finden Sie im SAP-Hinweis 886102.

Wichtig zu beachten ist hierbei, dass die Datenbankmigrationen von SAP BW aufSAP HANA am besten mit dem in diesem Kapitel beschriebenen DMO-Werkzeugdurchgeführt werden. Obwohl es möglich ist, ist eine schrittweise Migration vonSAP BW auf SAP HANA außerhalb dieses Werkzeugs nicht die beste Methode. DieDMO kann auf dem primären SAP-BW-System oder einer Kopie davon verwendetwerden.

Zusammenfassung der Migrationsansätze

Für die meisten Unternehmen stellt die standardmäßige Migration von SAPBW auf SAP HANA ohne wesentliche Optimierungsaktivitäten die einfachsteund am besten geeignete Lösung dar. Bis jetzt haben die meisten Unterneh-men ihre SAP-BW-Migrationsprojekte auf diese Weise geplant; die anderenAnsätze werden jedoch auch angewendet. Tabelle 6.8 fasst die Implementie-rungsoptionen in einer Übersicht zusammen (einschließlich einer Zeilesowohl für optimierte als auch für nicht optimierte Versionen der Standard-migration; die Optimierung wird im Folgenden erläutert).

Um Ihr Migrationsprojekt von SAP BW auf SAP HANA schneller abzuschlie-ßen, sollten Sie ernsthaft in Erwägung ziehen, die technische Datenbankmi-gration von der SAP-HANA-Optimierung zu trennen. Dies erörtern wiranschließend. Viele Aufgaben können auch zu einem späteren Zeitpunktdurchgeführt werden.

6.4.4 Optimieren einer Migration

Nachdem Sie die Datenbankmigration durchgeführt haben, können Sie IhrSystem optimieren. Wenn Sie sich gegen eine Optimierung entscheiden,wird Ihr Datenbanksystem zwar SAP HANA sein, es werden jedoch keine

Aufwand Risiko Nutzen Gängig

Standardmigration ohne Optimierung niedrig niedrig mittel Ja

Standardmigration mit Optimierung mittel mittel hoch Ja

Tabelle 6.8 Zusammenfassung der Implementierungsoptionen

SAP Business Warehouse auf SAP HANA 6.4

237

Modelländerungen an Ihrem System vorgenommen. Die Migration hat indiesem Fall keine Auswirkungen auf Ihre Abfragen, Links zu NLS, Interfacesoder das Laden von Daten, sondern führt lediglich zu einer wesentlichschnelleren Leistung und einigen internen Änderungen in Bezug auf Pro-zesse von SAP HANA auf Datenbankebene (d.h. Datenaktivierung und Kom-primierung). Funktionell werden Sie das gleiche System haben, daher ist die-ser Ansatz der schnellste und üblichste.

Wenn Sie sich für eine Optimierung entscheiden, werden die Datenstruktu-ren verbessert, um die neuen Fähigkeiten in SAP HANA optimal nutzen zukönnen, die u.a. auch SAP-HANA-optimierte InfoCubes mit einschließen.Auch zusätzliche SAP-HANA-Hinweise zu Ihren Datentransformationenkönnen hier enthalten sein, um Abfragen beim Laden von Daten schnellerausführen zu können. Dieser Migrationsansatz ist im Grunde genommengleichzeitig ein technisches und ein funktionelles Upgrade. Obwohl die Aus-wirkungen auf die Abfragen minimal sind, bietet die Optimierung eine signi-fikante zusätzliche Leistung in Datenladungen und in der Abfragegeschwin-digkeit.

Für sehr große SAP-BW-Systeme kann dieser Ansatz jedoch ziemlich zeitauf-wendig sein und erfordert möglicherweise wesentlich mehr Prüfungen. Umdiesen Nachteil auszugleichen, können Besitzer großer SAP-BW-Systeme dasfunktionelle Upgrade auf langsame Leistungsbereiche limitieren, die diesenExtraschub benötigen. Sie können aber auch zuerst das standardmäßigeUpgrade durchführen und anschließend das System im Zuge zukünftiger undneuer Entwicklungsbemühungen optimieren bzw. dann, wenn Erweiterun-gen oder Verbesserungen an bestehenden InfoCubes vorgenommen werden.

Sie können auch auswählen, ob die Datenarchitektur aus der Layered ScalableArchitecture (LSA) im älteren SAP-BW-System in eine vereinfachte LSA++-Architektur mit weniger Schichten und Partitionen in SAP BW auf SAPHANA migriert werden soll. In der neuen LSA++-Datenarchitektur wird derTatsache Rechnung getragen, dass die Aufteilung von Tabellen und das Sta-ging im alten SAP-BW-System für eine bessere Lade- und Abfrageleistunghäufig nicht benötigt wird, wenn SAP BW auf SAP HANA betrieben wird.Wie viel Aufwand Sie in die Optimierung zu investieren bereit sind, hängtvon den zur Verfügung stehenden Ressourcen sowie von dem Zeitrahmenab, in dem Sie die Migration abschließen möchten.

In diesem Abschnitt werden einige Optimierungsschritte für SAP BW aufSAP HANA erläutert.

Page 29: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

238

Optimierte DataStore-Objekte (DSO)

In früheren Versionen von SAP BW auf SAP HANA wurde empfohlen, die DSOs inSAP BW mithilfe der Transaktion RSMIGRHANADB zu optimieren oder diesemanuell in der Data Warehousing Workbench zu konvertieren. Dies ist nun nichtmehr der Fall. Ab dem Jahr 2014 hat SAP die Funktionsweise von SAP-BW-DSOsauf SAP HANA so verändert, dass die SAP-HANA-optimierten DSOs nicht mehrerforderlich sind. SAP empfiehlt nun, dass die für SAP HANA optimierten DSOswieder zur alten Version rückkonvertiert werden. Neue Kunden sollten ihre DSOsbei einer Migration auf SAP HANA generell nicht konvertieren. Weitere Informa-tionen erhalten Sie in SAP-Hinweis 1849498.

Optimieren von Code

Wenn keine Änderungen vorgenommen werden, laufen möglicherweiseeinige einzelne Datensatzabfragen für Datentransformationen während desLadens der Daten in SAP BW auf SAP HANA langsamer als auf einer relatio-nalen Datenbank. Dies muss nicht im Rahmen einer Migration geändert wer-den. Um jedoch diese Transformationstypen besser identifizieren zu kön-nen, stellt SAP ein Programm namens ABAP Routine Analyzer im SAP BWMigration Cockpit für SAP HANA zur Verfügung (siehe Abbildung 6.29). Mitdiesem Programm können Sie ermitteln, wo der suboptimale Code gespei-chert ist und wie er verbessert werden kann.

Abbildung 6.29 »ABAP Routine Analyzer« und »ABAP Code Inspector« im »SAP BW Migration Cockpit für SAP HANA«

SAP Business Warehouse auf SAP HANA 6.4

239

Dieses Programm kann sowohl SAP-BW-7.x-Transformationen als auch SAP-BW-3.5-Update- und Transferregeln automatisch überprüfen sowie alleABAP-Codes kennzeichnen, die von weiteren SAP-HANA-Optimierungenprofitieren würden (Abbildung 6.30).

Abbildung 6.30 »SAP BW ABAP Routine Analyzer« für SAP-HANA-Migrationen

Arbeiten mit optimierten InfoCubes

Sie können weiterhin bestehende Standard-InfoCubes verwenden, die keineSAP-HANA-optimierte Eigenschaft haben, Sie können sie aber auch umwan-deln. Der Kern des neuen optimierten InfoCubes besteht darin, dass das Sys-tem außer der Paketdimension keine weiteren Dimensionstabellen erstellt,wenn Sie Merkmale und/oder Kennzeichen bestimmten Dimensionenzuordnen. Stattdessen werden einfach die Stammdaten-Identifier (SIDs) indie Faktentabelle geschrieben, und die Dimensionsschlüssel (DIM IDs) wer-den nicht länger verwendet. Das Resultat ist ein schnelleres Lesen und Ladenvon Daten. Kurz gesagt entwickeln sich Dimensionen zu logischen Einheitenanstatt zu physischen Datentabellen. Das logische Konzept von Dimensionenwird ausschließlich zur Vereinfachung der Abfrageentwicklung in BEx QueryDesigner angewendet. Die InfoCubes können in der standardmäßigen SAP-BW-Administrationsoberfläche oder anhand eines von SAP bereitgestelltenProgramms (RSDRI_CONVERT_CUBE_TO_INMEMORY) optimiert werden.

In Abbildung 6.31 sehen Sie ein Beispiel für ein SAP-BW-InfoCube-Modellvor der SAP-HANA-Optimierung. Da die physische Tabelle des Sternschemaswährend der SAP-HANA-Optimierung verändert wird, muss jedes speziellentwickelte Programm, das direkt auf InfoCubes zugreift, anstatt dafür Stan-

Page 30: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

240

dard-Interfaces zu verwenden, neu geschrieben werden. Da sich nur sehrwenige Unternehmen in diesen Bereich gewagt haben, wird die optionaleKonvertierung mit Ausnahme einer schnelleren InfoCube-Leistung nurgeringe Auswirkungen auf die meisten Unternehmen haben.

Abbildung 6.31 SAP-BW-InfoCube-Modell vor der SAP-HANA-Optimierung

In Abbildung 6.32 sehen Sie ein Beispiel für ein SAP-BW-InfoCube-Modellnach der SAP-HANA-Optimierung.

Abbildung 6.32 SAP-BW-InfoCube-Modell nach der SAP-HANA-Optimierung

Faktentabelle

Dimensions-tabelle

Dimensions-tabelle

Merkmale

Merkmale

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Merkmale

Merkmale

Merkmale

Merkmale

Merkmale

Merkmale

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Dimensions-tabelle

Dimensions-tabelle

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Faktentabelle

Merkmale

Merkmale

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Merkmale

Merkmale

Merkmale

Merkmale

Merkmale

Merkmale

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

Attribute &Hierarchien

SAP Business Warehouse auf SAP HANA 6.4

241

Um bestehende InfoCubes zu konvertieren, können Sie diese entweder ein-zeln in der Administrator Workbench bearbeiten (siehe Abbildung 6.33),oder Sie öffnen einfach das Programm RSDRI_CONVERT_CUBE_TO_INMEMORYund wählen die InfoCubes aus, die konvertiert werden sollen. Der Job wirdim Hintergrund als Speichervorgang ausgeführt und ist extrem schnell. ImDurchschnitt können Sie hier mit einer Dauer von 10 bis 20 Minuten rech-nen, selbst bei sehr großen InfoCubes mit mehreren Hundert Millionen Zei-len. Während der Konvertierung können Benutzer sogar die InfoCubesabfragen, Datenladungen müssen jedoch aufgeschoben werden. Aktuell las-sen sich traditionelle InfoCubes mit maximal 233 Kennzahlen und 248Merkmalen in optimierte InfoCubes konvertieren.

Abbildung 6.33 Konvertieren der SAP-BW-InfoCubes in optimierte InfoCubes

Nach der Konvertierung zu SAP HANA werden optimierte InfoCubes ineinem spaltenbasierten Speicher der SAP-HANA-Datenbank gepflegt und miteinem logischen Index gekennzeichnet (CalculationScenario). Falls dieInfoCubes jedoch vor der Konvertierung nur im SAP BW Accelerator (BWA)gespeichert waren, werden die InfoCubes während der Konvertierung deak-tiviert, sodass Sie diese vor einer erneuten Verwendung reaktivieren und dieDaten neu laden müssen.

Obwohl optimierte InfoCubes nicht ummodelliert werden können, ist esdennoch möglich, InfoObjects mithilfe der InfoCube-Pflegeoption zu lö-schen und hinzuzufügen, selbst nachdem bereits Daten in den InfoCube ge-laden wurden.

Page 31: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

242

Da optimierte InfoCubes nur eine Faktentabelle haben, anstatt der zwei Fak-tentabellen, die traditionelle InfoCubes besitzen (eine E-Tabelle mit leseopti-mierter Partitionierung und eine F-Tabelle mit schreib-/löschoptimierter Par-titionierung), ist das Sternschema wesentlich einfacher und ähnelt auchmehr den klassischen logischen Data-Warehouse-Designs, die auf RalphKimballs dimensionalen Modellierungsprinzipien basieren. Diese Vereinfa-chung der Faktentabellen zusammen mit dem Entfernen physischer Dimen-sionstabellen hat zwei- bis dreifach schnelleres Laden von Daten zur Folge.

Bestandskennzahlen sollten auch berücksichtigt werden. Da SAP HANA dieinitialen Bestands-, Delta- und historischen Transaktionen separat lädt, sindzwei DTPs für InfoCubes mit Bestandskennzahlen erforderlich (z.B.Bestands-Cubes). In diesem Fall wird ein DTP benötigt, um die Bestandsda-ten zu initialisieren, und ein weiterer DTP ist erforderlich, um Daten undhistorische Transaktionen zu laden (für weitere Details lesen Sie bitte dieSAP-Hinweise 1548125 und 1558791). Außerdem können traditionelle Info-Cubes mit Bestandskennzahlen nur in optimierte InfoCubes konvertiert wer-den, wenn sie nicht in einen 3.x-Datenfluss eingeschlossen sind.

Aufgrund der erforderlichen manuellen Intervention und der notwendigenDTP-Änderungen sollten Bestands-Cubes und Cubes mit Bestandskennzah-len in einer Sandbox oder einer Entwicklungsbox geprüft werden, bevor siein Produktionssysteme konvertiert werden. Alternativ können diese Info-Cubes in einem nicht konvertierten Status bleiben. In SAP BW 7.4 gibt esneuen Support für Bestandskennzahlen. Daher sollten Kunden auf diese Ver-sion migrieren anstatt auf SAP BW 7.3.

Konvertieren der SAP-BW-3.x-Datenflüsse auf 7.x-DTPs für die SAP-HANA-Migration

Um die Datenflüsse von SAP BW 3.x auf den neuen Datentransformations-prozess (DTP) der SAP-BW-7.x-Systeme konvertieren zu können, hat SAP einKonvertierungswerkzeug im SAP BW Migration Cockpit für SAP HANA inte-griert (siehe Abbildung 6.34).

Mit dem Werkzeug wird der 3.x-Datenfluss einfach kopiert und dieser Ko-pie konvertiert. Somit steht die alte 3.x-Version noch bereit, wenn Sie dieMigration testen. Nach Abschluss des Tests können Sie die ältere Versionlöschen.

SAP Business Warehouse auf SAP HANA 6.4

243

Abbildung 6.34 SAP-BW-Datenflusskonvertierung für 3.x auf SAP-BW-7.x-DTPs

Partitionierung von InfoCube-Faktentabellen und -Komprimierung

Nach der Optimierung von SAP-HANA-InfoCubes können die Faktentabellennicht länger semantisch partitioniert werden – und das ist auch gar nichtmehr erforderlich. Hinter den Kulissen befinden sich jedoch noch vier Parti-tionen. Die erste Partition wird für unkomprimierte Requests verwendet,während die zweite die komprimierten Requests enthält. Eine andere Parti-tion enthält die Referenzpunkte der Bestandsdaten, und noch eine weiterewird für die historischen Bestandsdatenbewegungen verwendet. Die zweiletzten Partitionen sind leer, wenn ihre Bestandskennzahlen nicht verwen-det werden.

Dennoch erfordern die ersten zwei Partitionen eine regelmäßige Kompri-mierung, um den verwendeten physikalischen Speicher zu reduzieren unddie Ladezeiten bei Zusammenführungsprozessen zu erhöhen (ähnlich dertraditionellen SAP-BW-Datenpflege). Dies hat nur geringe Auswirkungen aufkleine InfoCubes (mit weniger als 100 Millionen Datensätzen) sowie aufInfoCubes ohne ein signifikantes Zurückladen von Daten oder vielenRequests. Da die Komprimierung auch als ein gespeicherter Vorgang inner-halb von SAP HANA ausgeführt wird, läuft die Komprimierung sehr schnellund nimmt selbst bei sehr großen InfoCubes nur wenige Minuten inAnspruch.

Page 32: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

244

Die Zukunft der InfoCubes

Derzeit findet in Internet-Blogs und -Foren eine große Debatte darüber statt, obInfoCubes in einem SAP-HANA-System überhaupt erforderlich sind. Vorläufigwerden InfoCubes jedoch aus unterschiedlichen Gründen noch gebraucht.

Sowohl für die Integrierte Planung (IP) als auch für die Write-back-Option werdentransaktionale InfoCubes gebraucht. Außerdem werden InfoCubes zum Speichernund Verwalten von Bestandskennzahlen benötigt, und auch das Interface fürdirektes Schreiben (RSDRI) funktioniert nur für InfoCubes. Zudem wird dieUmstellung von SAP BW auf SAP HANA erleichtert, indem es Kunden ermöglichtwird, zur neuen Plattform zu wechseln, ohne Anwendungslogik, Abfragen, Multi-Provider und Datentransformationen von DSOs zu InfoCubes umschreiben zumüssen.

Nichtsdestotrotz muss infrage gestellt werden, ob InfoCubes weiter verwendetwerden sollen. Die Einführung des Stern- und Schneeflockenschemas und andererTechniken für die dimensionale Datenmodellierung (DDM) in den 1990er-Jahrenreduzierte kostspielige Tabellen-Joins in relationalen Datenbanken, wobei dieDatenredundanz gespeicherter Daten in der ersten Normalform in OperationalData Stores (ODSs) vermieden wurde.

Das Entfernen der relationalen Datenbank aus der In-Memory-Verarbeitung vonSAP HANA stellt die meisten Vorteile der dimensionalen Datenmodellierung zurDiskussion, und eine fortgesetzte Anwendung dieser Strukturen ist fragwürdig. InZukunft werden stattdessen möglicherweise mehrschichtige DSOs mit unter-schiedlicher Datenhaltung und Granularität verwendet werden. Bis es so weit ist,werden InfoCubes in den meisten Unternehmen aber noch als Übergangslösungfür die Datenhaltung eingesetzt.

6.4.5 Neue Funktionen in SAP BW 7.4

In den früheren Versionen von SAP BW auf SAP HANA war es nicht möglich,Daten in nativen SAP-HANA-Schemata mit jenen in SAP BW physisch abzu-fragen. Dies hat sich mit SAP BW 7.4 nun geändert. Diese Version bietetzwei neue Funktionen zur Unterstützung der Modellintegration, unabhängigvon der Quelle:

� erweiterte Composite Provider

� Ansichtsmodelle der Open Operational Data Stores (ODS)

Mithilfe der erweiterten Composite Provider können Sie nun SAP-BW-MultiProvider, SAP-HANA-basierte VirtualProvider, Transient Providerund InfoSets konsolidieren. Dies hat den Vorteil, dass Sie diese über eineeinzige Schnittstelle abfragen können, ohne die Daten zwischen den einzel-nen Quellsystemen oder Modellen verschieben zu müssen (siehe Abbil-dung 6.35).

SAP Business Warehouse auf SAP HANA 6.4

245

Abbildung 6.35 Erweiterte Composite Provider für SAP BW 7.4 auf SAP HANA

Sie können die Composite Provider auch verwenden, um Daten aus anderenSAP HANA Data Marts und -Anwendungen zu verknüpfen. Außerdem gibtes neue Unterstützung für Bestandskennzahlen in SAP BW 7.4 auf SAPHANA. Der Modellierungsbildschirm zum Erstellen von Composite Provi-dern, der auf der Eclipse-Plattform basiert, ist in Abbildung 6.36 dargestellt.

Abbildung 6.36 Eclipse-Modellierung für SAP BW 7.4 auf SAP HANA

Composite Provider zur Kombination von Daten

SAP BW

MDX, OData, BICS, SQL …

Arbeitsplatz

SAP HANA Data Mart

Tabelle

Modell

Sicht

DSOs

SAP ERP SAP BW Oracle

Hadoop DB2

Page 33: 6 Planung einer SAP-HANA- Implementierung - thali.ch · PDF file6 Planung einer SAP-HANA-Implementierung 186 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine

Planung einer SAP-HANA-Implementierung6

246

Die neue Open-ODS-Funktion in SAP BW 7.4 ermöglicht es Ihnen, SAP-BW-basierte DSOs mit Tabellen zusammenzuführen, die während der nativenSAP-HANA-Entwicklung erstellt wurden. Somit können Sie SAP-BW-Datenmit Nicht-SAP-BW-Daten auf vielfältige Weise verknüpfen, wie es in vorhe-rigen Versionen von SAP BW nicht möglich war. Den Open-ODS-Modellie-rungsbildschirm sehen Sie in Abbildung 6.37.

Abbildung 6.37 Sicht der Open-ODS-Modellierung in SAP BW 7.4 auf SAP HANA

Zahlreiche Unternehmen haben Probleme bei der Integration der SAP-BW-basierten Data Warehouses in die traditionellen Data Marts anderer Plattfor-men. Mit diesem neuen Werkzeug allerdings kann die Verschiebung derNicht-SAP-BW-Data Marts auf das native SAP HANA einfacher gerechtfertigtwerden, während weiterhin die Möglichkeit besteht, die Tabellen virtuellzusammenzuführen und diese in einer einheitlichen BI-Schnittstelle abzufra-gen. Nicht-SAP-BW-Entwickler können zudem in SAP HANA arbeiten, ohnesämtliche Daten physisch in SAP BW zusammenführen zu müssen.

6.5 Zusammenfassung

Die Planung einer SAP-HANA-Implementierung erfordert fundierte techni-sche Fähigkeiten sowie ein solides Verständnis der langfristigen Architektur-und Systemeinsatzstrategie eines Unternehmens. Sie stellt einen großenUnterschied zum Upgraden von Servern, Datenbanken und Betriebssys-temen dar. Unternehmen erhalten stattdessen eine Appliance, die brand-

Zusammenfassung 6.5

247

neue Funktionen bietet und die Arbeitsweise von Servern und Datenbankenim Unternehmen grundlegend verändert.

Unternehmen sollten den Aufwand einer solchen Implementierung nichtunterschätzen. Die langfristigen Vorteile einer Vereinfachung von Anwen-dungs- und Datenbankservern bei gleichzeitiger Beseitigung von Leistungs-einschränkungen relationaler Datenbanken sind jedoch so zahlreich, dassUnternehmen sie nicht einfach ignorieren können. Um eine SAP-HANA-Implementierung erfolgreich umsetzen zu können, ist es zudem wichtig,kompetente Partner während der Umstellungsphase mit einzubeziehen undseriöses Personal für das Training der vorhandenen Support-Mitarbeiter ein-zusetzen. Die Wahl des richtigen Plattformanbieters und eines erfahrenenPartners ist daher entscheidend.