Wissen aus erster Hand. Leseprobe Bevor Sie mit einer SAP-HANA-Implementierung beginnen können, müssen Sie zunächst einmal die Hintergründe und Zusammenhänge verstehen. In dieser Leseprobe werden Sie alle dafür erforderlichen Informationen erhalten.»«(kapitel 6) Inhalt Index Die Autoren Leseprobe weiterempfehlen Bjarne Berg, Penny Silvia Einführung in SAP HANA 605 Seiten, gebunden, 2. Auflage 2015 69,90 Euro, ISBN 978-3-8362-3459-7 www.sap-press.de/3748
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 erforderlichen Informationen erhalten. 6 Planung einer SAP-HANAImplementierung In diesem Kapitel werden Sie mehr über die Planung einer SAP-HANAImplementierung 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 183
Von der Implementierung unabhängige Überlegungen 6.1 Die Editionen bestimmen ausschließlich, welche Komponenten in der Softwarelizenzierung enthalten sind und wie Sie Daten extrahieren, bewegen und replizieren können. Bei jeder Implementierung von SAP HANA sei es als Data Warehouse oder als Datenbank für SAP BW bzw. die SAP Business Suite können Sie zusätzlich unter den zur Verfügung stehenden Editionen wählen. Hinweis Die Editionen stehen ebenfalls für die SAP HANA Rapid Deployment Solutions zur Verfügung. Wie bereits erwähnt, gehen wir in diesem Buch nicht detailliert auf die SAP HANA Rapid Deployment Solutions ein. Falls Sie SAP HANA für klassische Extraktions-, Transformations- und Ladungsverfahren (ETL) verwenden möchten und Ihnen bereits die SAP Data Services zur Verfügung stehen, sollten Sie sich für die SAP HANA Appliance Software Platform Edition entscheiden. Diese Edition stellt eine großartige Lösung für Nicht-SAP-Unternehmen und Kunden dar, die jegliche Quellen, wie z.b. maßgeschneiderte Data-Warehouse-Anwendungen, Data Marts oder Daten aus Nicht-SAP-ERP-Systemen, beschleunigen möchten. Die SAP HANA Appliance Software Enterprise Edition wurde für Unternehmen entwickelt, die ihr SAP-HANA-System mit einer triggerbasierten Replikation verwenden möchten. Die Enterprise Edition beinhaltet zudem die SAP Data Services, sodass Sie sowohl ETL- als auch Trigger-Verfahren durchführen können. In Kapitel 12,»Datenbereitstellung«, werden wir noch detailliert auf eine triggerbasierte Replikation eingehen. Die SAP HANA Appliance Software Enterprise Extended Edition ist für diejenigen geeignet, die»alles«wollen. Im Vergleich zu den anderen Editionen wurde diese Edition zusätzlich mit der logbasierten Replikation ausgestattet. Die meisten Großunternehmen, die bereits SAP ERP oder BI-Software (Business Intelligence) in ihre Systemlandschaft integriert haben, werden sicherlich diese Edition in Betracht ziehen. In jeder dieser Editionen haben Power-User mit dem Information Composer die Möglichkeit, eigene Daten hochzuladen oder über eine eigene Ansicht auf In-Memory-Daten zuzugreifen. Dieses Werkzeug wird von den Komponenten in den verschiedenen SAP-HANA-Editionen getrennt installiert. Wir werden uns in Kapitel 9,»Datenmodellierung mit dem Information Composer«, noch eingehend mit dem Information Composer auseinandersetzen. Die in den jeweiligen Editionen enthaltenen Komponenten sind in Tabelle 6.1 in einer Übersicht zusammengefasst. 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 Replication 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 Neben diesen drei Haupteditionen werden auch spezielle Softwareeditionen für spezifische Zwecke angeboten. Diese bestehen aus der Datenbankedition für SAP BW, einer Edition für Kunden, die über einen EDGE-Lizenztyp (eine Lizenz, 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-Plattform basieren. Mithilfe dieser Angebote können kleinere Unternehmen oder 184 185
Von der Implementierung unabhängige Überlegungen 6.1 solche, die nicht alle Fähigkeiten von SAP HANA nutzen möchten, eine Edition erwerben, die ihren Bedürfnissen entspricht. Als Betriebssystem wird ein SUSE Linux Enterprise Server (SLES) oder Red Hat Linux verwendet. Auf dem SAP Service Marketplace finden Sie Informationen zu weiteren technischen Unterkomponenten. Diese können am besten anhand 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 Enterprise Edition (enthält auch Komponenten der Platform Edition) Enterprise Extended Edition BC-HAN-UPD BC-DB-HDB-INS BC-DB-HDB-UPG BC-HAN-DXC EIM-DS BC-HAN-LOA BC-HAN-LTR BC-HAN-REP BC-DB-HDB BC-DB-HDB-ENG BC-DB-HDB-PER BC-DB-HDB-SYS BC-DB-HDB-DBA BC-DB-HDB-POR BC-DB-HDB-BAC BC-CCM-HAG BC-DB-HDB-CCM BC-DB-HDB-CLI BC-DB-HDB-R BC-DB-HDB-SCR Tabelle 6.2 Interne Softwarekomponenten und -referenzen Software Update Manager (SUM) SAP-HANA-Datenbankinstallation SAP-HANA-Datenbank-Upgrade SAP HANA Direct Extractor Connection (DXC) SAP Data Services (ETL-basiert) SAP HANA Load Controller (LC) (logbasiert) SAP Landscape Transformation (SLT) (triggerbasiert) SAP (Sybase) Replication Server (logbasiert) SAP-HANA-Datenbank SAP-HANA-Datenbank-Engine SAP-HANA-Datenbankpersistenz SAP-HANA-Datenbankschnittstelle SAP-HANA-Datenbank/ DBA Cockpit SAP-HANA-DB-Portierung SAP HANA Backup and Recovery SAP Host Agent SAP HANA Computing Center Management System (CCMS) SAP HANA Clients (JDBC/ODBC) SAP-HANA-Integration mit R SAP HANA SQLScript Bereich Komponenten-ID Komponentenname BC-DB-HDB-MDX MDX-Engine (Microsoft-Excel- Client) BC-HAN-MOD BC-HAN-3DM BC-HAN-SRC BC-DB-HDB-TXT BC-DB-HDB-DXC BC-DB-HDB-SEC BC-DB-HDB-XS BC-DB-HDB-AFL BC-DB-HDB-AFL-PAL BC-DB-HDB-AFL-SOP BC-DB-HDB-PLE SAP HANA Studio: Information Modeler Information Composer SAP HANA UI Toolkit SAP-HANA-Text- und Suchfunktionen Endbenutzer-Clients BI-BIP-CMC, BI-BIP BI-Plattform BI-RA-WBI BI-RA-XL BI-RA-CR, BI-BIP-CRS BI-RA-EXP BI-BIP-IDT BI-RA-AO-XLA SAP HANA Direct Extractor Connection (DXC) SAP-HANA-Sicherheits- und Benutzerverwaltung SAP-HANA-Anwendungsdienste SAP HANA Advanced Functions Library (AFL) SAP HANA Predictive Analysis Library SAP-HANA-Absatz- und Produktionsgrobplanung (SOP) SAP-HANA-Planungs-Engine SAP BusinessObjects Web Intelligence SAP BusinessObjects Dashboards SAP Crystal Reports SAP BusinessObjects Explorer Information Design Tool (für Zählbestände) Microsoft-Excel-Add-In Tabelle 6.2 Interne Softwarekomponenten und -referenzen (Forts.) Um Sie stets auf den neuesten Stand bringen zu können, hat SAP eine Reihe von SAP-HANA-Hinweisen erstellt, die den verschiedenen Releases und Service Packs angefügt und jeweils entsprechend abgewandelt werden. Partner und Hardwareanbieter sollten diese Schlüsselinformationen wegen der darin enthaltenen Aktualisierungen sorgfältig und regelmäßig lesen. Die wichtigs- 186 187
Von der Implementierung unabhängige Überlegungen 6.1 ten SAP-Hinweise in Bezug auf SAP HANA stehen registrierten SAP-Kunden auf der SAP-Service-Marketplace-Webseite zur Verfügung. Einen Auszug aus diesen allgemeinen SAP-Hinweisen zu SAP HANA finden Sie in Tabelle 6.3. 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 Weitere für die Installation der SAP-HANA-Box erforderliche Komponenten sind 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. XULRunner Hierbei handelt es sich um eine Laufzeitumgebung für ein gängiges Backend für XUL-basierte Anwendungen. Für das System ist mindestens die Version 1.9.2 erforderlich. Libicu Hierbei handelt es sich um einen Satz internationaler Komponenten für Unicode. Network Time Protocol (NTP) Obwohl aus technischer Sicht nicht erforderlich, sollte eine Installation durchgeführt werden, um Trace-Dateien zwischen SAP-HANA-Knoten zu unterstützen. Syslogd Hierbei handelt es sich um ein Protokollierungswerkzeug für Systemnachrichten. GTK2 Hierbei handelt es sich um eine Softwarekomponente für grafische Benutzeroberflächen (GUIs). Die Netzwerkverbindungen zwischen den Quellsystemen und dem SAP- HANA-Server sollten 10 GB/s betragen, damit die Effizienz der Datenreplikation gewährleistet werden kann. Da eine beträchtliche Datenmenge zwischen diesen Servern bewegt wird, ist es ebenfalls wichtig, dass die Verbindung nicht mit anderen Komponenten über gemeinsam genutzte Router oder Switches geteilt wird. SAP empfiehlt, diese Verbindungen ausschließlich den Servern zuzuordnen und dabei darauf zu achten, dass die Entfernungen nicht zu groß werden. Eine Verbindung zwischen einem Server in Europa und Amerika mit einem SAP-HANA-System in Asien ist beispielsweise nicht ideal. Obwohl diese Empfehlung kein Muss ist und eine solche Architektur dennoch implementiert werden kann, sollte trotzdem nicht außer Acht gelassen werden, dass jede langsame Netzwerkverbindung gleichzeitig auch die Replikation von Daten verlangsamt. Softwareinstallation Nachdem Sie sich für eine Version entschieden haben, kann Ihr Hardwarepartner mit der Installation beginnen. Um die Installation zu vereinfachen, stellt SAP den Partnern die Software SAP HANA Unified Installer zur Verfügung. Zusammen mit der Installation erhalten Sie auch das Software Logistics Toolset (SL), das den Software Update Manager (SUM) enthält. Dieses Werkzeug wird dazu verwendet, Software-Updates der SAP-HANA-Komponenten durchzuführen, um eine langfristige Kompatibilitä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 Installationspartner die SAP-HANA-SL-Software und SAP-HANA-Komponenten installieren sollten. Da es sich bei SAP HANA um eine sich gerade neu entwickelnde Technologie handelt, ist es sehr unwahrscheinlich, dass Basis-Mitarbeiter aus Unternehmen bereits über die erforderlichen Kenntnisse für eine solche Installation verfügen. Trotz des von SAP online bereitgestellten und detaillierten Leitfadens für SAP HANA Unified Installer empfehlen wir allen Kunden ausdrücklich, die Softwareinstallation von Hardwareanbietern und zertifizierten Partnern durchführen zu lassen. 6.1.2 Hardwarespezifikationen und -optionen SAP HANA wird als In-Memory-Appliance verkauft. Das bedeutet, dass sowohl Software als auch Hardware von den einzelnen Anbietern bereitgestellt werden. Seit Juli 2014 können SAP-HANA-Hardwarelösungen bei Cisco/EMC, Dell, Fujitsu, Hitachi, Huawei, IBM, NEC und Hewlett-Packard erworben werden. Die Verfügbarkeit der neuen Xeon-E7-CPUs von Intel, die auch als Ivy Bridge bekannt sind, ist besonders beachtenswert. Die Schnelligkeit dieser neuen 188 189
Von der Implementierung unabhängige Überlegungen 6.1 Chips beruht auf den 15 Cores. In den bisherigen E7-Versionen waren nur zehn Cores verfügbar. Außerdem weisen sie eine höhere Taktrate auf; vorläufige Testergebnisse von SAP ergaben, dass die Performance von SAP HANA mehr als doppelt so hoch ist. Wenngleich es unterschiedliche Modelle gibt 2880/90, 4880/90 und 8880/90, werden nur die letzten beiden derzeit in zertifizierten SAP-HANA- Appliances eingesetzt. Die Prozessoren unterscheiden sich im Allgemeinen in ihren Taktraten, die zwischen 2,5 und 2,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 erwerben und verwalten müssen. Der Hauptvorteil einer Scale-Out-Lösung ist, dass Sie besonders große SAP-HANA-Systeme erstellen können. Beides wird im Folgenden kurz erörtert. Am Ende dieses Abschnitts betrachten wir schließlich noch 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. Der Vorteil eines einzelnen Systems ist offensichtlich. In großen und schnell wachsenden Unternehmen allerdings ist ein Knoten mit»nur«2 TB Speicher langfristig gesehen möglicherweise nicht ausreichend. Um zu sehen, ob diese Speicherkapazität für Ihr Unternehmen ausreicht, müssen Sie das Datenwachstum betrachten. Ein System mit 2 TB kann 6 bis 8 TB unkomprimierte Daten verarbeiten. Ebenso müssen Sie die Anzahl der aktiven gleichzeitigen Benutzer berücksichtigen. Wenn Sie das SAP-HANA-System für Berichte und Analysen nutzen, benötigen Sie erfahrungsgemäß 0,2 Cores pro aktivem, gleichzeitigem Benutzer. 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 gleichzeitige Nutzung von 20 % Ihrer Benutzer einplanen, könnte das 3.000 festgelegten Benutzern entsprechen. Dies sind nur einige Grundgedanken zu den Möglichkeiten eines Scale-Up-Systems. Selbstverständlich sollten Sie jedoch mit Ihrem Hardwarepartner detailliert auf das Sizing-Vorhaben, Ihr System und die tatsächlich genutzten Daten eingehen. Ab Juli 2014 verwenden alle Hardwareanbieter mit zertifizierten, auf Ivy- Bridge-Prozessoren basierenden SAP-HANA-Lösungen den Linux SLES für SAP Version 11 (siehe Tabelle 6.4). Fujitsu PQ 2400 E/S/L HP System Speicher (RAM) Protokollund Datenträgergröße PQ 2800 B/E/L HP Converged System 500 CPUs (Intel Ivy Bridge EX E7) Geplanter Einsatz SAP Business Suite EDW/ Data Mart Es besteht noch die Möglichkeit, die älteren E7-10-Core-Prozessoren einiger Anbieter einzusetzen (siehe Tabelle 6.5). Die einzelnen Knoten in diesen Systemen können etwas langsamer sein. Mit entsprechender Konfiguration kann die Rechenleistung für das Gesamtsystem jedoch erhöht werden (d.h. in einer Scale-Out-Konfiguration). EDW/ SAP BW 128 512 GB 896 2.048 GB 2x 8890v2 1.024 GB 3.584 GB 4x 8890v2 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 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 128 512 GB 4.096 8.800 GB 2x 4890v2 V3 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 8x 8880v2 definiert 4.096 GB Noch nicht 8x 8880v2 definiert 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 190 191
Von der Implementierung unabhängige Überlegungen 6.1 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 SAP-HANA-Scale-Out-Systeme SAP-HANA-Scale-Out-Systeme sind im Wesentlichen Systeme, die aus mehreren, über ein Netzwerk miteinander verbundenen Knoten bestehen. Dieses Netzwerk hat eine Geschwindigkeit von mindestens 10 GB, um Engpässe beim Datentransfer zwischen den Servern zu vermeiden. Die meisten SAP- HANA-Systeme können in ihrer Konfiguration an diesen Aufbau angepasst werden. 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 aufzubauen. Dies ist wirklich die Big-Data-Plattform der Zukunft. Derzeit gibt es viele interessante Ansätze für Scale-Out-Systeme. Beispielsweise 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 mit 112 TB Speicher und 3360 CPU-Cores entsteht. Das HP Converged System 500 ist eine SAP-zertifizierte Plattform mit Scale-Out-Möglichkeiten bis zu 16 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 Blades anstelle von eigenständigen Serverknoten. Für diesen Zweck bieten Cisco/ EMC B440-Blade-Server und HP BL680-Blade-Server an. Cisco/EMC hat zudem eine gemeinsam genutzte Plattform für ein Scale-Out namens Jupiter geschaffen, in dem SAP HANA, Nearline Storage (NLS) und Hadoop in einem einzigen System mit über 8 TB Speicher eingebunden werden. Wie Sie sehen, gibt es also ausreichend Möglichkeiten für SAP-HANA-Scale-Out- Systeme. Einige Hardwareanbieter bieten auch einen sogenannten»investitionsschutz«. Dies bedeutet im Wesentlichen, dass Sie ältere Hardware teilweise in neueren Systemen einsetzen können, während Ihre Umgebung weiter wächst. Wenn Sie beispielsweise vor einigen Jahren ein 10-Core-Prozessorsystem wie IBM 3950 erworben haben, können Sie nun neue prozessorbasierte Ivy-Bridge-Serverknoten mit 15 Cores zu Ihrem System hinzufügen. Diese sind mit den älteren 10-Core-Knoten kompatibel. Erst wenn Ihre neuen Knoten mehr als 50 % Ihres gesamten SAP-HANA-Systems ausmachen, müssen Sie umsteigen. Mit diesem Ansatz können Sie Tausende von Euro einsparen und sicherstellen, dass Ihre Hardwareinvestitionen nachhaltiger sind als bisher. Da es hier zu Verwirrung kommen kann, empfiehlt es sich, die SAP-HANA- Experten Ihres Beraters einzubeziehen und gemeinsam mit diesen und Ihrem Hardwareanbieter eine passende Lösung für Ihr Unternehmen zu ermitteln. Allerdings ändern sich die Hardwaremöglichkeiten rapide. Daher sollten Sie sich nur auf Berater erlassen, die darin entsprechende Erfahrungen aufweisen können. Falsche Hardware kann sehr kostspielig sein. Investieren Sie also erst ein wenig Zeit, bevor Sie sich für eine Scale-Out-Lösung entscheiden. Hardwarebeispiel Die SAP-HANA-Hardware ist in vieler Hinsicht einzigartig und wird von den jeweiligen Anbietern optimiert, um SAP-Lösungen zu unterstützen. Diese Anbieter haben bereits Erfahrungen und Expertenwissen mit der Installation und dem Support von SAP-HANA-Landschaften sammeln können. Aus diesem Grund sollten Sie von keinem nichtzertifizierten Hardwareanbieter erwarten, dass dieser die Anwendung installieren, betreiben und unterstützen kann. Abbildung 6.1 zeigt ein Beispiel für Hardwarelösungen von unterschiedlichen Anbietern. Während der Arbeit an diesem Buch haben wir mit IBM bei der Installation und Prüfung seines High-End-x3950-X5-Servers zusammengearbeitet. Da wir hierzu nur ein System mittlerer Größe benötigten, entschieden wir uns 192 193
Von der Implementierung unabhängige Überlegungen 6.1 für eine Speicherkapazität von 256 GB und ein mittleres Dateisystem (siehe Abbildung 6.2). 2014 begannen wir mit dem Aufbau des neuen 3850-SAP-HANA-Modularsystems der sechsten Generation (X6) (siehe Abbildung 6.3). Ein modulares SAP-HANA-IBM-3850-X6- System mit 4 Sockeln und 4 Rechenblöcken. Eine Version mit 8 Einheiten war für die 3950-Konfiguration verfügbar. IBM x3950 X6 Fujitsu RX 900 S2 NEC Express 5800 Jede Recheneinheit umfasst einen Intel-E7- Ivy-Bridge-Prozessor mit 15 Kernen. Cisco C460 Hitachi CB 2000 HP BL 680 Für den internen Speicher der Protokolldateien und zur persistenten Datenspeicherung. Bis zu 6,4 TB exflash bzw. 12,8 TB herkömmlicher Speicher waren möglich. Jede Recheneinheit hat zwei Lüfter zur Kühlung. Es handelt sich um ein Hot System. Dell R910 IBM FLEX X6 HP Converge System 500 Huawei RH5885H V3 Abbildung 6.1 Einige Hardwarelösungen von verschiedenen Anbietern Wärmeableiter zur Kühlung des Systems Dies sind die Speicherbanken. Jede Recheneinheit kann theoretisch über einen Speicher mit 6 TB bzw. einen exflash-speicherkanal mit 12,8 TB verfügen. PCI-Karte: Die interne PCI-SSD- Karte verwaltet die SAP-HANA-Logs auf einem separaten GPFS (Dateisystem). Doppelte Stromversorgung Festplatten: 1 Hot-Swap-Platte; der Rest fungiert als virtuelles Laufwerk. Sie enthalten den Failover für SAP HANA. Hauptspeicher: 256 GB installiert, erweiterbar bis 512 GB. Das ist die SAP-HANA-DB. 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-Speicherbanken und eigenständige Recheneinheiten sowie einen Speicher für die Persistenz der SAP-HANA-Datenprotokolle und die Datendateien. Das neue System beinhaltete 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 doppelt so schnell. Rückseite der Maschine Prozessoren (10 Kerne, Intel-Xeon-E7-Serie) Vorderseite der Maschine Abbildung 6.2 Innenansicht von IBM 3950 X5: das SAP-HANA-System der fünften Generation Obwohl sich dieses Hardwarebeispiel speziell auf die High-End-Systeme der x-serie von IBM bezieht, sind die Komponenten anderer Anbieter damit durchaus vergleichbar und somit für Sie eine gute Grundlage, um die Zusammenhänge zu verstehen. 194 195
SAP HANA als Data Warehouse 6.2 6.2 SAP HANA als Data Warehouse Auch wenn die Implementierung von SAP HANA als Data Warehouse eine der einfachsten Möglichkeiten ist, die Geschwindigkeit dieser Plattform zu nutzen, gibt es einige Aspekte, die sorgfältig geplant werden sollten. Die beiden wichtigsten Aspekte sind die Datenmodellierung und das Sizing, die im folgenden Abschnitt erörtert werden. 6.2.1 Datenmodellierung Beim Modellieren von Daten für SAP HANA als Data Warehouse muss sichergestellt werden, dass zwei Dinge berücksichtigt werden: Zum einen sollte die Geschwindigkeit von SAP HANA ausgenutzt werden. Zum anderen sollte die Geschwindigkeit nicht weiter optimiert werden, wenn dies nicht erforderlich ist. Zum besseren Verständnis betrachten wir nun die traditionellen Sternschemata und Schneeflockenmodellierungstechniken, die für ein In-Memory- Data-Warehouse möglicherweise nicht geeignet sind. Diese Techniken dienen primär zur Reduzierung von Tabellen-Joins und Datenmengen im Data Warehouse. Hierbei wurden einfach die dritten Normalformmodelle im Transaktionssystem verwendet und denormalisiert, indem Ereignis- (Fakten) und Dimensionstabellen (Beschreibungen) erzeugt wurden. Dies hatte zwei Vorteile. Zum einen erübrigten sich kostenintensive Tabellen-Joins, wenn Stammdaten, die über Dutzende von Tabellen verteilt waren, abgefragt und mit Transaktionsdaten verbunden wurden. Angepasste Dimensionen erzeugten einfach denormalisierte Tabellen für alle Kunden, Anbieter und Produkte, und der Modellierer konnte diese Daten mit Vorgängen wie Verkauf, Lieferung und Fakturierung verknüpfen. Zum anderen entfielen die hohen Kosten für die Aufzeichnung aller Ereignisse und Stammdaten in einer einzigen Tabelle, wie dies bei Modellen der ersten Normalform oder bei Vorgangsdateien der Fall ist. Um das System noch weiter zu beschleunigen, erstellten Dimensionsmodellierer Übersichtstabellen. Zudem stellten sie sicher, dass die langsameren Abfragen, die zusammengefasste Daten benötigten, auf diese Tabellen und nicht auf die Faktentabellen mit detaillierten Vorgängen umgeleitet werden konnten. Andere erstellten zusammenfassende Sternschemata mit unterschiedlicher Granularität (z.b. Gesamtumsatz nach Produkt, Geschäft, pro Tag). Um noch schnellere Ergebnisse zu erhalten, wurde es schließlich gängige Praxis, dass die Abfragen vorab durchgeführt und die Zwischenergeb- nisse auf den Anwendungsservern in den Speicher-Caches vorgehalten wurden es wurde keine Möglichkeit ausgelassen, um mehr Geschwindigkeit aus dem festplattenbasierten Data Warehouse herauszuholen. Viele dieser Ansätze sind ungeeignet, wenn SAP HANA als Data Warehouse eingesetzt wird. In einem spaltenbasierten Speicher beispielsweise wird durch die Kompression ein Großteil der Datenredundanzen aus den Modellen der ersten bzw. zweiten Normalform entfernt. Der Aufwand für diese Ansätze kann also oft minimal sein. In SAP HANA gibt es keine»echten«tabellen. Stattdessen stehen komprimierte zeilen- und spaltenbasierte Speicher auf Indexbasis bereit, die als Tabellen mit einfachem Zugriff und einfacher Modellierung angezeigt werden. Im Data Warehouse gibt es hauptsächlich Spaltenspeicherdaten und Tabellen-Joins. Es handelt sich lediglich um eine semantische Ansicht dessen, was in der neuen Datenbank stattfindet. Mit anderen Worten, die kostenintensiven Tabellen-Joins, die in den traditionellen Dimensionsmodellen vermieden werden sollten, sind nicht mehr vorhanden. Außerdem ist der Einsatz von Übersichtstabellen in den meisten Fällen nicht sinnvoll, wenn das System ohnehin schon sehr schnell ist. Das Zwischenspeichern von Zwischenergebnissen (z.b. durch Übermittelung in den Cache) ist nur 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 Warehouses erfolgt die Transformation während der Extraktion aus dem Quellsystem bzw. auf Ebene des Anwendungsservers, auf dem die ETL-Werkzeuge installiert sind. Bei SAP HANA ist es oft sinnvoll, die Daten einfach in der vorliegenden 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 Modellen bewegt werden. Dies kann die Transformationen deutlich beschleunigen, und Sie müssen sich nicht auf kleinere, langsamere Server auf der ETL- oder Anwendungsebene verlassen. Kurzum, Sie sollten die Modellierungsansätze für das Data Warehouse nochmals überdenken, wenn Sie mit SAP HANA arbeiten. Sie sollten sich fragen, ob die älteren Methoden tatsächlich noch sinnvoll sind. Es stehen viele, sehr gute Hilfsquellen im Internet und in Buchhandlungen zur Verfügung, die erläutern, warum Operational Data Stores (ODS) in dieser neuen Herangehensweise wichtiger sind als Sternschemata. 196 197
SAP HANA als Data Warehouse 6.2 Hinweis Wir empfehlen den Kurs HA-300 der SAP-Schulungen für Neulinge im Bereich Modellierung bei SAP HANA. Der Titel des Kurses ist»sap HANA Implementation and Modeling«. 6.2.2 Sizing Wenn Sie planen, Daten aus einem Transaktionssystem zu verschieben oder Daten aus einem bestehenden System zu konvertieren, ist ein besonders wichtiges Kriterium beim Sizing eines SAP-HANA-Systems das Komprimierungsverhältnis beim Verschieben von Daten in die In-Memory-Plattform. Einige Kunden konnten sehr hohe (8- bis 10-fache) Komprimierungen feststellen, während andere»nur«eine 3,8-fache Datenreduktion erzielt haben. Aus diesem Grund empfiehlt SAP, mit einer Planung von einem 3- bis 5-fachen Faktor für das Sizing des jeweiligen Systems zu beginnen und anschließend detaillierter auf das Sizing-Vorhaben einzugehen. Die Unterschiede bei diesen Komprimierungszahlen entstehen dadurch, dass einige Unternehmen bereits relationale Datenbanken mit umfangreichen Komprimierungsmethoden (z.b. DB2 v10 oder die native Komprimierung in der Oracle-12g-Datenbank) verwenden, während andere über Datenbanken mit eingeschränkteren Komprimierungsfähigkeiten verfügen. Natürlich erwarten wir höhere Komprimierungszahlen in Datenbanken, die ohnehin geringe Komprimierungsfähigkeiten aufweisen. Hinzu kommen Unterschiede in der Art und Weise, wie Datentypen komprimiert werden (d.h., Strings sind eigentlich Arrays in den meisten Datenbanken), während Zahlen in den meisten Versionen der Oracle-Datenbanken bereits auf bis zu 50 % komprimiert sind. Und schließlich gibt es auch Unterschiede bei den Indexgrößen, die entweder zeilen- oder spaltenbasiert sind. Um eine grobe Schätzung zu erhalten, empfiehlt es sich, als ersten Schritt die Faustregel des 3- bis 5-fachen Faktors anzuwenden. Das Sizing von SAP HANA als Data Warehouse ist darüber hinaus auch ein Stück Wissenschaft. Es besteht aus dem Sizing des erforderlichen Speichers (spaltenbasierte Speicher, zeilenbasierte Speicher sowie Speicher für Caches und Komponenten) und der Größeneinteilung des Datenträgers (Log und Persistenz) sowie des CPU-Sizings für die zu erzielende Rechenleistung. Glücklicherweise gibt es einige grundlegende Methoden, um die Größe eines Systems festzulegen: SAP QuickSizer Dieses Werkzeug ist für Unternehmen geeignet, die noch kein SAP-ERPoder SAP-BW-System verwenden oder eine Rapid Deployment Solution bevorzugen. Faustregel beim Sizing Für all diejenigen, die eine Sizing-Übung überspringen möchten, gibt es auch die Möglichkeit, das Sizing eines Systems basierend auf einer Reihe von allgemeinen Empfehlungen durchzuführen. Das Ergebnis werden allgemeine Schätzungen sein, die Ihnen einen vorläufigen Eindruck davon vermitteln können, was beim Sizing eines Systems zu erwarten ist. Dennoch sollten Sie vor der tatsächlichen Implementierung eines Systems ein detaillierteres Sizing durchführen. T-Shirt-Modell SAP bietet auch ein T-Shirt-Modell für umfangreiche Schätzungen. Wie die anderen Methoden sollte auch diese nur für allgemeine Schätzungen angewendet 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/quicksizer zur Verfügung (ein SAP-Service-Login ist hierzu erforderlich). Für die drei verschiedenen Versionen von SAP HANA stehen entsprechend drei unterschiedliche Versionen dieses Werkzeugs zur Verfügung (siehe Abbildung 6.4). Abbildung 6.4 Arten der SAP-HANA-QuickSizer-Werkzeuge Wenn Sie mit dem Sizing Ihres Data Warehouses beginnen, geben Sie die Projektdaten, die Anzahl der Benutzer und den Speicherbedarf für die Daten 198 199
SAP HANA als Data Warehouse 6.2 ein, die Sie auf SAP HANA übertragen möchten. Es ist wichtig, dass Sie diese Zahl als unkomprimierte Daten angeben. Ist in Ihrem Quellsystem eine Komprimierung von 30 % aktiviert, sollten Sie 30 % zu der im Quellsystem angezeigten Datenmenge hinzufügen. Außerdem definieren Sie den Zeitraum, in dem Ihr System aktiv ist (siehe Abbildung 6.5). Abbildung 6.6 QuickSizer-SAP-HANA-Sizing-Ergebnisse Abbildung 6.5 QuickSizer-Eingabe für SAP HANA als Data Warehouse In diesem Beispiel gehen wir von 350 Benutzern und einer Datenmenge von 600 GB aus, die aus einer Oracle-Datenbank geladen werden sollen. Hier muss berücksichtigt werden, dass beim Sizing die bereits verfügbaren Daten (300 GB) sowie die Daten der nächsten drei Jahre einbezogen werden müssen (planmäßig 100 GB pro Jahr). Der Eingabewert ist also 600 GB insgesamt. Die Start- und Endzeiten sind von 9:00 bis 18:00 Uhr. Sie können neue Quellsysteme hinzufügen, indem Sie eine Zeile markieren und darüber auf die Schaltfläche Insert klicken. So können Sie mehrere Quellsysteme in das Sizing einbeziehen. Wenn Sie Ihre Eingaben abgeschlossen haben, klicken Sie einfach auf Calculate result. Sie können nun mit der Analyse der Sizing-Ergebnisse beginnen (siehe Abbildung 6.6). In diesem Beispiel benötigen Sie 246 MB RAM in Ihrem System und ein System, das 70.000 SAPS unterstützen kann. Der Begriff SAPS ist eine einheitliche Kennzahl der Systemperformance, die jeder Hardwareanbieter in einem System-Sizing umsetzen können sollte. Ursprünglich sollte mit dieser Kennzahl gemessen werden, ob Bestellungen verarbeitet werden können. 100 SAPS wurden als 2.000 vollständig verarbeitete Business-Auftragspositionen pro Stunde festgelegt. Mittlerweile ist es jedoch eine Standardmaßeinheit, mit der Hardwareanbieter die Größe von Anwendungsservern und der SAP-HANA-Datenbankserver ermitteln. Sie können die Sizing-Ergebnisse einfach für die Anbieter ausdrucken und um ein Angebot für die Hardware bitten. Gehen Sie für Sandbox-, Entwicklungs-, Qualitätssicherungs- und Hochverfügbarkeitssysteme gleichermaßen vor. 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 Vorstellung davon zu bekommen, wie groß Ihr System sein wird. Diese Faustregeln lassen sich sehr gut für vorläufige Schätzungen und Budgetierungen auf hohem Niveau anwenden. Um jedoch genaue Zahlen zu erhalten, sollten Sie, wie bereits erklärt, eine echte Sizing-Methode verwenden. Zunächst müssen Sie den 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 Wert 4 ist die durchschnittliche Komprimierung, die für zeilen- und spaltenbasierte Speichertabellen erwartet wird. Der Faktor 2 bezieht sich auf den erforderlichen Speicherplatz für Laufzeitobjekte und auf temporäre Ergebnissätze in SAP HANA. Und abschließend steht der Begriff bestehende DB- Komprimierung für Komprimierungen, die bereits auf Ihrem System durchgeführt wurden (falls zutreffend). Dieser Vorgang ist kompliziert, und wenn Sie lediglich einige Anhaltspunkte brauchen, können Sie auch einfach die Datenbankgröße Ihres Systems als Grundlage nehmen und diese durch 4 tei- 200 201
SAP HANA als Data Warehouse 6.2 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, die Log-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 unkomprimierten Daten, wenn Sie ein altes Data-Warehouse-System mit 1 TB haben, das System bereits 40 % Komprimierung verwendet und Sie diesen Prozentsatz erneut hinzurechnen. Wenn Sie diesen Wert durch 4 teilen, erhalten Sie eine SAP-HANA-Datenbank mit einer Größe von 350 GB. Anschließend multiplizieren Sie das Ergebnis mit 2, um Speicher für interne Prozesse, Indizierung, Datenbewegung und Endanwender zu ermöglichen, und fügen zum Schluss 50 GB für den internen Speicher von SAP HANA hinzu. Das ergibt eine grobe Schätzung von 710 GB an erforderlichem Speicher. Als Nächstes benötigen Sie Festplattenplatz, der wie folgt abgeschätzt werden kann: Festplatte für die Persistenzschicht = 4 Speicher Festplatte für den Log = 1 Speicher In diesem Beispiel benötigen Sie vier 750-GB-Festplatten für die Persistenzschicht und etwa 750 GB für die Logs. Dies entspricht etwa 3,75 TB (keine Sorge, Festplattenspeicher dieser Größe sind heutzutage recht kostengünstig). Die Persistenzschicht ist die Festplatte, die das System sichert und für Redundanz sorgt, falls es zu Speicherfehlern kommt, und sollte daher nicht unterschätzt werden. Sie können natürlich immer mehr Speicher hinzufügen, während das System weiter wächst. Es wird jedoch empfohlen, lieber etwas mehr Platz einzuplanen, damit der Festplattenplatz nicht zu klein ist. So verhindern Sie, dass Sie direkt nach dem»go-live«als Erstes mehr Speicher hinzufügen müssen. Außerdem sollte diese Festplatte nicht auf einem gemeinsam und stark genutzten Storage Area Network platziert werden. Versuchen Sie, die SAP- HANA-Festplatte so gut wie möglich als spezielle und separate Festplatte einzusetzen. Die CPUs basieren auf der Anzahl der enthaltenen Kerne. Inzwischen existieren CPUs mit 15 Kernen. Wenn Sie einen Knoten mit 4 15 Kernen haben, erhalten Sie 60 Kerne und können somit 300 aktive Benutzer auf diesem Hardwareknoten arbeiten lassen sowie eine viel größere Anzahl von festgelegten Benutzern. Beim Sizing durch SAP-Anbieter ist es üblich, Prozessoren basierend auf der Speichergröße von SAP HANA hinzuzufügen, sodass ihre eigentliche Zahl durchaus unterschiedlich ausfallen kann. Der CPU-Bedarf wird 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 der aktiven Benutzer zu bestimmen. In der Vergangenheit waren in Data Warehouses 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 SAP HANA verschieben, erhalten Sie die tatsächlichen Nutzungszahlen aus den Systemüberwachungswerkzeugen, die der Administrator wahrscheinlich bereits einsetzt. Sie werden daraus ersehen können, wie viele Ihrer festgelegten Benutzer gegenwärtig Ihr System verwenden, wobei die Aktivitäten dieser Benutzer in»niedrig«,»mittel«und»hoch«aufgegliedert werden. Diese Informationen 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-Serie mit einer Taktrate von 2,5 bis 2,8 GHz ausgestattet. Es ist sehr wahrscheinlich, 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 verwenden. Diese Aufstellung asiert auf ähnlichen Regeln wie den zuvor erläuterten, kategorisiert jedoch die Größen auf praktische Weise in extra kleine bis extra große SAP-HANA-Umgebungen (siehe Tabelle 6.6). Diese Aufstellung lässt sich leicht lesen, sollte aber nicht für die Budgetierung oder Einkaufsentscheidungen genutzt werden, da sie nicht absolut verlässlich ist. Da mehr Kerne zur Verfügung stehen (aktuell zehn pro Prozessor), sollten Kunden, die sich eine Speicherkapazität von mehr als 1.024GB wünschen, zusammen mit ihrem Hardwarepartner mehrere Knotensysteme miteinander verbinden oder größere Knoten für eine erhöhte Skalierbarkeit verwenden. Derzeit haben SAP und IBM neue Systeme mit über 100 TB Speicher vorgeführt, sodass die allgemeine Skalierbarkeit kein größeres Problem für die meisten Unternehmen darstellen sollte. 202 203
SAP Business Suite auf SAP HANA 6.3 Datenkomprimierung (Datenmenge vor Komprimierung) XXL 7.000 250.000 GB 3.072 GB bis 112+ TB XL 3.500 7.000 GB 2.048 2.560 GB Prozessoren 8 x 15 Cores + Intel E7 2,8 GHz 8+ Intel E7 2,5+ GHz L 2.000 3.500 GB 1.024 GB 4 Intel E7 2,5+ GHz M 1.250 2.000 GB 512 GB 4 Intel E7 2,5+ GHz S 500 1.250 GB 256 GB 2 Intel E7 2,5+ GHz XS 256 500 GB 128 GB 2 Intel E7 2,5+ GHz Tabelle 6.6 SAP-HANA-T-Shirt-Sizing Ein anderer wichtiger Faktor für viele wird die Geschwindigkeit sein, mit der Daten repliziert werden können. Die kleineren Systeme sind auf ca. 5 10 GB pro Stunde beschränkt, während die größeren Systeme bis zu 30 GB und mehr erreichen können. Da sich diese Zahlen jedoch mit neuen Hardwareversionen und neuen SAP-HANA-Versionen häufig ändern, sollten sie lediglich als Orientierungshilfe dienen. Dieser Bereich entwickelt sich schnell weiter. Daher sind die meisten Hardwarebeispiele nur begrenzt gültig. 6.3 SAP Business Suite auf SAP HANA SAS/SSD (für Daten) Arbeitsspeicher Replikationsgeschwindigkeit (pro Stunde) 15+ TB 30+ GB 5 10 TB 30+ GB 4 5 TB 10 20 GB 2.048 GB 10 20 GB 1.024 GB 5 10 GB 1.024 GB 5 10 GB Seit Januar 2013 bietet SAP Unterstützung für die SAP Business Suite auf SAP HANA. Dies bedeutet, dass Sie ein neues SAP-ERP-System auf SAP HANA installieren oder Ihr bestehendes System auf SAP HANA migrieren können, um die einfachere Architektur sowie die signifikanten Performancevorteile von SAP HANA zu nutzen. Zahlreiche Unternehmen haben ihre SAP-ERP- Systeme bereits auf SAP HANA verschoben oder dieses installiert. Dieser Trend 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. Hinweis Vor der Migration sollten Sie das optionale Enhancement Package 6 für SAP ERP 6.0 mit der SAP-HANA-Version installieren. Wenn Sie allerdings Branchenlösungen mit Zusatzfunktionen nutzen, werden möglicherweise nicht alle durch das Enhancement Package unterstützt. Lesen Sie SAP-Hinweis 1774566 sorgfältig, bevor Sie mit diesem Prozess beginnen. Sollten Sie sich für den Prozess entscheiden, müssen Sie eine separate Vereinbarung unterzeichnen, in der Einschränkungen hinsichtlich der SAP-Lizenz- und Wartungsvereinbarung erläutert werden. Weitere Informationen hierzu erhalten Sie in SAP-Hinweis 1768031. Es gibt drei Implementierungsoptionen, um ein SAP-Business-Suite-System auf 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 Sie einige Tipps für das Sizing (passend zu den verschiedenen Implementierungsoptionen). Zusätzlich zu diesem Abschnitt empfehlen wir die SAP-Hinweise zu SAP Business Suite auf SAP HANA (siehe Tabelle 6.7). SAP-Hinweis 774615 SAP-Hinweis 855498 SAP-Hinweis 998833 SAP-Hinweis 1730095 Name Support Package Levels for SAP ERP /SAP ECC Installation and Upgrades Installation Prerequisite Checker Release Restrictions: SAP ERP 6.0 Enhancement Packages EHP6 for SAP ERP 6.0 on HANA Release Information Tabelle 6.7 Wichtige Hinweise für SAP Business Suite auf SAP HANA Beschreibung Liste der erforderlichen Support Packs SAP-Software auf UNIX, Windows und IBM i: Überprüfen der Abhängigkeiten der Betriebssysteme Informationen über die Einschränkungen bei den SAP Enhancement Packages für SAP ERP 6.0 Releaseinformationen und Äquivalenzebenen der Support Packs 204 205
SAP Business Suite auf SAP HANA 6.3 Name SAP-Hinweis 1760306 SAP EHP6 for SAP ERP 6.0, version for SAP HANA 1.0: Add-ons SAP-Hinweis 1768031 SAP EHP 6 for SAP ERP 6.0, version for SAP HANA SAP-Hinweis 1774566 SAP-Hinweis 1785057 SAP-Hinweis 1789632 SAP Business Suite Powered by SAP HANA Restrictions Preparatory Steps for Database Migration to SAP HANA EHP6 for SAP ERP 6.0 on HANA HANA Content Activation 6.3.1 Vollständige Neuinstallation Beschreibung Zu berücksichtigende Aspekte beim Einsatz von SAP Enhancement Package 6 für SAP ERP 6.0, Version für SAP HANA in Kombination mit einem Add-on im selben System Einschränkungen hinsichtlich des produktiven Einsatzes von SAP Enhancement Package 6 für SAP ECC 6.0, Version für SAP HANA Einschränkungen für SAP ECC auf SAP HANA Informationen über die vorbereitenden Schritte für die Datenbankmigration auf SAP HANA Informationen über manuell zu aktivierende Inhalte Tabelle 6.7 Wichtige Hinweise für SAP Business Suite auf SAP HANA (Forts.) Dies ist die einfachste Option, um die SAP Business Suite auf SAP HANA zu implementieren. In diesem Szenario erwerben und installieren Sie ein völlig neues SAP-HANA-System einschließlich SAP Business Suite. Auch wenn es sich nicht für die Migration eines Produktivsystems empfiehlt, können Sie hiermit einige Daten in das SAP-HANA-System (d.h. die Stammdaten und offene Bestellungen) migrieren, um die neuen Funktionen von SAP HANA nutzen zu können. Dieser Ansatz eignet sich vor allem für jene, die ältere Implementierungen bereinigen und dabei ein Upgrade auf neuere Versionen der SAP Business Suite vermeiden möchten. Er eignet sich ebenfalls für Benutzer, die die SAP Business Suite zum ersten Mal implementieren. Starten Sie für diese Installation das Installationswerkzeug Software Provisioning Manager 1.0, und folgen Sie dem SAP Installation Guide. Vor der Installation sind folgende Schritte notwendig: 1. Deaktivieren Sie die Windows-Server-Firewall. 2. Vergewissern Sie sich, dass das Windows-Dateisystem NTFS ist (nicht FAT). 3. Überprüfen Sie die Windows-Domänenstruktur. Bei Domain-Installationen 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 der Software 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 Transporthost verwendet werden soll, und geben Sie das Verzeichnis usr\sap auf dem Transporthost als SAPMNT frei. Setzen Sie bei dieser Freigabe die Berechtigung für Everyone auf Full Control. Somit kann das Installationsprogramm das Transportverzeichnis im Standard \\SAPTRANSHOST\ SAPMNT\trans adressieren. Erteilen Sie schließlich Everyone die Berechtigung Full Control für das Transportverzeichnis. 7. Beschaffen Sie die physischen Installationsmedien als Teil des Installationspakets. Sie können den Software Provisioning Manager 1.0 verwenden. 8. Ermitteln Sie die Komponenten für Ihre Installation, wie z.b. die zentrale Serviceinstanz für ABAP (ASCS), die Datenbankinstanz, den Enqueue Replication Server sowie die primäre(n) und zusätzliche(n) Anwendungsserverinstanz(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 blockiert sind. Das Installationswerkzeug Software Provisioning Manager 1.0 verwendet Port 21200 zur Kommunikation mit dem GUI-Server; der GUI- Server verwendet Port 21212 zur Kommunikation mit dem GUI-Client und Port 4239 des HTTP-Servers. Daher müssen alle Ports offen sein. 2. Sorgen Sie dafür, dass im Installationsverzeichnis mindestens 300 MB Speicherplatz für jede Installationsoption sowie 300 MB freier Speicherplatz für die ausführbare Datei des Installationsprogramms zur Verfügung 206 207
SAP Business Suite auf SAP HANA 6.3 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 Datei SWPM10SP<Support Package-Nummer>_<Versionsnummer>.SAR entpackt haben. Der Installationsprozess wird gestartet. Folgen Sie nun den Anweisungen 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 bereits ein funktionierendes SAP-Business-Suite-System haben und auf SAP HANA migrieren möchten. Bei dieser Methode werden im Wesentlichen Änderungen an der Gesamtlandschaft vermieden, indem SID, Hostname, Anwen- dungsserver und Konnektivität beibehalten werden. Folglich wird nur der Datenbankserver während der Installation verändert, und die anderen Teile der Landschaft bleiben weitestgehend intakt. Die Ausfallzeit bei der Migration wird primär zum Verschieben der Datendateien von der alten Datenbank auf die SAP-HANA-Datenbank genutzt. Daher richtet sich die notwendige Ausfallzeit meist nach der Größe des SAP-Business-Suite-Systems. Bei den ersten SAP-Business-Suite-Systemen, die auf SAP HANA migriert wurden, erfolgte dies im Rahmen eines herkömmlichen Upgrades. Hierzu gehörten das Patchen des Systems, ein Upgrade der Anwendung auf die erforderliche Ebene, die Implementierung von Unicode und schließlich die Migration zu SAP HANA. Heute können Sie ein neues Werkzeug mit dem Namen Database Migration Option (DMO) einsetzen und all diese Aufgaben in einem Schritt erledigen. Die Ausfallzeit des Systems ist hierbei auf ein Minimum reduziert. DMO ist kein separates Werkzeug, sondern eine im Software Update Manager (SUM) Version 1 Service Pack 9 verfügbare Option. Wenn Sie eine ältere Version von SAP ERP verwenden, ist das DMO-Werkzeug hervorragend für eine parallele Durchführung von Upgrade und Migration geeignet. Dieses Werkzeug 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 entsprechend zu SAP NetWeaver 7.40 migriert werden. Dieser Vorgang umfasst auch Migrationen von SAP ERP Version 6.0 EHP 7. DMO wird ebenfalls für die Migration von SAP BW auf SAP HANA genutzt. Mithilfe des DMO-Werkzeugs wird innerhalb des SAP-Business-Suite-Systems ein Schattensystem, ein sogenanntes Schatten-Repository, erstellt. Dieses Schattensystem umfasst eine kleine Menge an Daten und wirkt sich nicht auf das bestehende System aus, wenn ausreichend Systemressourcen vorhanden sind. Sie können gemeinsam mit Ihrem Implementierungspartner vor einem Upgrade ermitteln, ob dies der Fall ist. Im zweiten Schritt der Konfigurationsphase stehen Ihnen drei Optionen für die DMO-Migration zur 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 ausreichend sind (siehe Abbildung 6.8). Wenn Sie die erweiterte Option ausgewählt haben, können Sie nun mit den verbleibenden Konfigurations- und Prüfaufgaben fortfahren. Mit dem DMO- Werkzeug werden Sie durch die einzelnen Schritte geleitet. Wenn Sie bei Schritt 4, der sogenannten Vorverarbeitung, angelangt sind, wird das Schat- 208 209
SAP Business Suite auf SAP HANA 6.3 ten-repository erzeugt. Zu diesem Zeitpunkt sind keine Änderungen an der Systemkonfiguration mehr möglich. Falls Sie dennoch Änderungen vorgenommen haben, kann es sein, dass die Konfigurationen des Schatten- und des tatsächlichen Systems nicht mehr übereinstimmen. Benutzer können jedoch weiterhin auf das System zugreifen und Transaktionen buchen; neue Transporte in die Umgebung sind allerdings nicht mehr möglich (siehe Abbildung 6.9). abgeschlossen ist, wird mit dem DMO-Werkzeug das Schattensystem in das SAP-HANA-System verschoben. Die eigentlichen Datenverschiebungen erfolgen als Exporte und Importe. Bei großen SAP-Business-Suite-Systemen empfiehlt sich eine Aufteilung der sehr großen Tabellen, bevor diese verschoben werden. In einigen Fällen sollten Indizes zur Beschleunigung des Prozesses hinzugefügt werden. Die Datenexporte und -importe finden nach der 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 Datenladejobs, Finanzzuordnung, Abschreibungen, Benutzereinträge sowie alle Jobs, mit denen Daten im System geändert, aktualisiert oder neu hinzugefügt werden. Sobald alle Vorbereitungen getroffen sind, können Sie das System sperren und mit dem Transfer beginnen (siehe Abbildung 6.10). Für gewöhnlich bietet sich dazu ein Wochenende an. Abbildung 6.8»Database Migration Option«(DMO) Reduzierung des Systemausfalls Abbildung 6.10»Database Migration Option«(DMO) Sperrung des Quellsystems Abbildung 6.9»Database Migration Option«(DMO) Sperrung der Entwicklungsumgebung Die folgenden Upgradeschritte finden im Schattensystem statt, während das tatsächliche System weiterläuft. Sobald das Upgrade des Schattensystems Nachdem die Daten auf das neue SAP-HANA-System migriert wurden, steht Ihnen ein funktionierendes System zur Verfügung, und die Benutzer können auf die neue Umgebung zugreifen. Im Master Guide des SAP Marketplace gibt es Empfehlungen zu den Nachbereitungsschritten. Sie sollten die aktuelle Version zurate ziehen und prüfen, ob für Ihr System Änderungen notwendig sind und welche Nachbereitungsschritte optional sind. 210 211
SAP Business Suite auf SAP HANA 6.3 Hinweis Weitere Informationen zu DMO finden Sie in den SAP-Hinweisen 1875197 und 1813548. Für Basis-Mitarbeiter empfiehlt sich die zweitägige DMO-Schulung mit dem 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 Suite auf SAP HANA mit der Option zum Kopieren, Upgraden und Migrieren implementieren. Bei dieser Option wird das SAP-Business-Suite-System mithilfe von herkömmlichen Basis-Werkzeugen auf ein anderes System kopiert. Anschließend wird im neuen SAP-HANA-System für die Kopie ein Upgrade durchgeführt. Dabei werden dieselben Schritte wie in Abschnitt 6.3.2 (unter Einsatz von DMO) ausgeführt. Diese Option erfordert mehr Hardware und Schritte als bei der In-Place-Migration. Allerdings sinkt auch das Projektrisiko. Für Benutzer, die vor einer vollständigen Migration einen»proof of Concept«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, und zwar unabhängig davon, welche Implementierung von SAP Business Suite auf SAP HANA Sie auswählen. Hierfür stehen Ihnen drei Optionen zur Verfügung: SAP QuickSizer (den Sie bereits aus Abschnitt 6.2.2 kennen und der im Folgenden beschrieben wird), ein ABAP-Bericht und Anbieterwerkzeuge. SAP QuickSizer Wenn Sie mit dem Sizing in der SAP-HANA-Umgebung beginnen, sollten Sie zuerst die SAP-Richtlinien für das Datenbank-Sizing lesen. Diese finden Sie in SAP-Hinweis 1514966. Mit diesem Grundwissen können Sie die ersten Sizing-Versuche mithilfe des Werkzeugs SAP HANA QuickSizer unternehmen. Dieses Werkzeug finden Sie unter http://service.sap.com/quicksizer. Erstellen Sie zunächst ein Projekt, und geben Sie auf dem Bildschirm in den Bereichen Project Data, Customer Data, Platform and Communication, System Availability und Network Infrastructure so viele Informationen wie möglich ein (siehe Abbildung 6.11). Die meisten dieser Daten werden nicht für das Sizing verwendet, stellen aber SAP und Ihrem Hardwarepartner wertvolle Informationen bereit, wenn Sie die Sizing-Ergebnisse mit diesen teilen. 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 die SAP Business Suite auf SAP HANA. Diese Aktivität unterscheidet sich in SAP QuickSizer nicht von einem Sizing eines herkömmlichen festplattenbasierten Systems. Erst nachdem das Sizing abgeschlossen wurde, können wir mithilfe der SAP-Richtlinien das Ergebnis des klassischen Sizings auf das identische SAP-HANA-Sizing übertragen. Daher müssen wir die zu implementierende Komponente 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 geplanten Datenmengen sehen können (Abbildung 6.12), planen wir die Verarbeitung von durchschnittlich 5 Millionen Rechnungsdokumenten mit durchschnittlich zwei Auftragspositionen pro Tag. Von diesen Dokumenten werden planmäßig ca. 5 % pro Jahr geändert und 25 % angezeigt. Insgesamt sollen in unserem System Daten aus 48 Monaten vorgehalten werden, und die Archivierung ist deaktiviert. Dies ist die durchschnittliche Normallast zwischen 9:00 und 18:00 Uhr. Darunter ist die Spitzenlast zwischen 12:00 und 13:00 Uhr eingetragen (Sie können diese Zeiten entsprechend Ihren Spitzenlasten ändern). Zudem geben wir in Table 3 die geschätzte Anzahl an Datensätzen für die Datensatztypen ohne Auftragspositionen ein. Nachdem wir alle Informationen eingegeben haben, klicken wir im oberen Bereich des Bildschirms auf die Schaltfläche Calculate result und erhalten die Sizing-Ergebnisse (siehe Abbildung 6.13). 212 213
SAP Business Suite auf SAP HANA 6.3 Aus dem Ergebnis geht hervor, dass es sich um ein sehr großes System mit Systemanforderungen von mindestens 2.080.000 SAPS und über 5 TB Speicher handelt. Zur Erinnerung: Dies gilt nur für ein herkömmliches festplattenbasiertes System, und die SAP-Richtlinien sind erforderlich, um dies in aussagekräftige und vergleichende SAP-HANA-Systemgrößen umzusetzen. Informationen darüber, wie Sie diesen Sizing-Schätzwert für SAP HANA umwandeln, erhalten Sie im PDF-Anhang von SAP-Hinweis 1779345. Im Allgemeinen ist es ratsam, das durchsatzbasierte Sizing anstelle eines Sizings zu nutzen, das auf der Anzahl der Benutzer beruht. Denn damit können Sie die Datenhaltungszeiten besser steuern und den benötigten Speicher reduzieren. Selbstverständlich können Sie die Daten auch im Nearline Storage (NLS) vorhalten und auf diese zugreifen, selbst wenn sie nicht physisch in SAP HANA gespeichert werden. Abbildung 6.12 Eingabe der Sizing-Vorgaben für FI-CO ABAP Report Das Sizing der SAP Business Suite auf SAP HANA mithilfe des SAP-QuickSizer-Werkzeugs ist ein sehr guter Ausgangspunkt für eine Neuimplementierung. SAP bietet Ihnen aber auch ein auf ABAP basierendes Sizing-Programm, das für Bestandskunden mit vorhandenem SAP-ERP-System eingesetzt 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-Migrationsprojekt nutzen. Abbildung 6.13 Sizing-Ergebnis für FI-CO Abbildung 6.14 Sizing-Programm für»sap Business Suite auf SAP HANA«SAP-Hinweis 1872170 214 215
SAP Business Suite auf SAP HANA 6.3 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 in der Lage, Ereignisse während der Migration zu prüfen, wie z.b. Depooling, Indizes, Declustering und LOBs (große Objekte). In diesem Werkzeug können 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 sogar einzelne Module wie Financial Accounting oder Materials Management in einer Sidecar-Implementierung Ihres SAP-HANA-Systems auswählen. Wenn Sie das Programm ausführen, wird Ihnen der Fortschritt in einem Bildschirm angezeigt. Dies kann einige Zeit in Anspruch nehmen, abhängig davon, wie viele parallele Dialogprozesse Sie im ersten Eingabebildschirm angegeben haben. Es ist durchaus möglich, dass das Programm in großen Systemen mehr als eine Stunde benötigt. Bei vielen Unternehmen sollte das Programm nach Feierabend ausgeführt werden, wenn mehr Ressourcen zugewiesen werden können und die Auswirkungen auf die Benutzer nur minimal sind. Wie Sie in diesem Beispiel sehen können (Abbildung 6.15), wird die SAP Business 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 die SAP-HANA-Hardware anfordern. Hinweis In SAP-Hinweis 1872170 ist auch ein detailliertes PDF-Dokument mit dem Titel»Frequently Asked Questions«enthalten. Es informiert Sie, wie Sie das Programm herunterladen und ausführen und die Ergebnisse auswerten müssen. Anbieterwerkzeuge Neben SAP QuickSizer und den ABAP-Sizing-Werkzeugen haben viele Hardwareanbieter eigene Tabellenkalkulationen zur Berechnung oder Verifizierung der Hardware-Sizing-Vorhaben generiert. Einige Unternehmen, wie z.b. HP, haben zudem Softwareprogramme entwickelt, die Unterstützung bei einem SAP-HANA-Sizing-Vorhaben bieten. Das Sizing-Werkzeug von HP kann von der Webseite des Unternehmens heruntergeladen und in wenigen Minuten auf dem Desktop installiert werden. Der Vorteil vieler dieser Sizing-Werkzeuge ist, dass sie häufig Preislisten für die Hardware bereitstellen, die der Anbieter für Ihre Sizing-Anforderungen vorschlagen könnte. In unserem Sizing-Beispiel, bei dem das Sizing-Werkzeug von HP zum Einsatz kommt, wird die Entwicklungs- und Sandboxumgebung zur Kostenersparnis auf derselben Hardware positioniert (siehe Abbildung 6.16). Abbildung 6.16 HP-Sizing-Werkzeug für»sap Business Suite auf SAP HANA«Abbildung 6.15 Ergebnis des SAP-HANA-Sizing-Programms für SAP Business Suite Die Qualitäts- und Testumgebung sowie die Produktivumgebung werden separat gehalten. Die drei Umgebungen werden in Abbildung 6.16 darge- 216 217
SAP Business Warehouse auf SAP HANA 6.4 stellt. Das Sizing-Werkzeug von HP gibt an, dass im Produktivsystem die Anforderungen mit einem einzigen SAP-HANA-System mit 1 TB Speicher erfüllt werden können, wobei der interne Festplattenplatz 7 TB beträgt. Weiterhin empfiehlt das Werkzeug zwei SAP-HANA-Systeme mit 256 GB Speicher und 3 TB Festplattenplatz für die anderen Umgebungen. Der Listenpreis für solch eine Konfiguration läge bei insgesamt 270.892 USD vor Dienstleistungen, Steuer und Rabatten. Andere Sizing-Werkzeuge und Tabellenkalkulationen von Unternehmen wie Fujitsu, IBM, Dell, Huawei, NEC, Hitachi und Cisco/EMC sind auf Anfrage erhä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 stehende Anwendung war und SAP BW gleichzeitig das am häufigsten verwendete Berichtssystem für SAP-Kunden ist. Trotz seines Status als meistverwendetes Berichtssystem wurde SAP BW mit signifikanten Problemen konfrontiert und stieß an die Grenzen seiner Leistungsfähigkeit, da sich die Datenvolumen der meisten Unternehmen stetig vermehrten und zig Terabyte groß wurden. Herkömmliche relationale Systeme auf Festplattenbasis konnten 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.3 aktualisieren. Um jedoch die Geschwindigkeit und die Funktionen von SAP HANA voll nutzen zu können, sollten Sie SAP BW 7.4 einsetzen. Diese Version wurde so geschrieben und umgestaltet, dass alle neuen Funktionen von SAP HANA in einem einheitlichen, flexiblen und leistungssteigernden Data Warehouse für Unternehmen des 21. Jahrhunderts bereitgestellt werden. SAP hat z.b. einige Bereiche des standardmäßigen Business Content in Content Release 7.47 SP 7 neu geschrieben, um das Laden der Daten und die Datenarchitektur zu vereinfachen und flexible Datenmodelle zu erzeugen. Der neue, für SAP HANA optimierte Inhalt umfasst Bereiche wie Debitoren- und Kreditorenbuchhaltung, Produktkostenprognose und -simulationen, Profit-Center-Rechnung, Hauptbuch, Vertriebsübersicht, Lieferservices, Fakturakonditionen, Auftragsrückstände, Einkaufsübersicht, Rechnungswesen im Einkauf, Vertragsmanagement, Rechnungsprüfung und Service- Levels. Neue Inhalte für andere Bereiche können in nachfolgenden Releases hinzugefügt werden. In den folgenden Abschnitten nennen wir Ihnen einige zentrale Aspekte, die Sie bei der Umstellung eines SAP-BW-Systems auf SAP HANA berücksichtigen sollten. Wir organisieren die Abschnitte in verschiedene Hauptschritte: Sizing, Vorbereitung für eine Migration, Durchführung einer Migration und Optimierung einer Migration. Abschließend präsentieren wir einige neue Funktionen in SAP BW 7.4, die besonders relevant für die Migration von SAP 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 Warehouse und SAP Business Suite auf SAP HANA erörtert wurde) und das SAP BW Migration Cockpit für SAP HANA. Im Folgenden werden beide Möglichkeiten beschrieben. Sizing von SAP BW mit dem SAP-QuickSizer-Werkzeug Das erste Sizing-Werkzeug von SAP ist QuickSizer (siehe Abbildung 6.17). Er eignet sich für Unternehmen, die noch kein SAP-ERP- bzw. SAP-BW-System einsetzen oder SAP Rapid Deployment Solutions für SAP HANA nutzen möchten und deshalb eine brandneue Implementierung planen. QuickSizer ist nicht für Unternehmen vorgesehen, die bereits eine SAP-ERP- oder SAP- BW-Lösung einsetzen. Diese Kunden sollten stattdessen die von SAP und anderen Anbietern bereitgestellten Werkzeuge verwenden, die in diesem Kapitel vorgestellt wurden. Die Speicheranforderungen von SAP HANA für SAP-BW-Caches und zusätzliche Komponenten sind auf ca. 50 GB festgelegt. (Der Rest wird anhand der Größe der spalten- und zeilenbasierten Speicher gesteuert.) Der erste Schritt für die Anwendung von QuickSizer besteht in der Eingabe der Projektinformationen: Betriebssystem, Hardware und Datenbank. Danach öffnen Sie die QuickSizer-Menüs. Im Bereich Table 1 geben Sie die Planungsinformationen ein (wenn Sie Integrated Planning [IP] in SAP BW verwenden). Die mit einem roten Sternchen markierten Felder sind Pflichtfelder. Für H-PLANN-1 geben Sie im Feld Users die maximale Anzahl gleichzeitiger Benutzer ein. Die Felder S.t. und E.t. beziehen sich auf die Start- und Endzeiten für die Verarbeitung. Durch Eingabe dieser Informationen erhalten Sie am Ende des Sizings zusätzlich eine Schätzung der Lastverteilung auf dem SAP-HANA-System nach Zeitperioden. 218 219