00____1076.book Seite 3 Freitag, 5. Oktober 2007 3:07 15
Alexander Davidenkoff, Detlef Werner
Globale SAP®-Systeme – Konzeption und Architektur
Bonn Boston
00____1076.book Seite 5 Freitag, 5. Oktober 2007 3:07 15
Auf einen Blick 1
Einführung ..............................................................
13
2
Geschäftsvoraussetzungen für globale Systeme ....
37
3
Architekturen im Überblick ...................................
83
4
Einflussfaktoren auf Systemarchitekturen ............ 155
5
IT-Realisation der Architektur ............................... 213
6
Kundenszenarien und Entscheidungsfindung ........ 279
7
Zusammenfassung .................................................. 317
A
Glossar .................................................................... 319
B
Literatur .................................................................. 325
C
Die Autoren ............................................................. 329
00____1076.book Seite 7 Freitag, 5. Oktober 2007 3:07 15
Inhalt Vorwort ........................................................................................ 11
1
Einführung ............................................................... 13 1.1 1.2 1.3 1.4
2
13 19 26 35
Geschäftsvoraussetzungen für globale Systeme .... 37 2.1
2.2
2.3
3
Die Rolle der IT in der Globalisierung ........................ Die Bedeutung eines geeigneten Unternehmensmodells ..................................................................... Vom Mainframe zu verteilten Systemen ..................... Zusammenfassung .....................................................
Abdeckung regionaler und globaler Anforderungen ... 2.1.1 Rechtliche Anforderungen und regionale Geschäftspraktiken ........................................ 2.1.2 Wünsche der EDV-Benutzer .......................... Sprachen, Zeitzonen und Datenübertragung .............. 2.2.1 Sprachabhängiges Customizing ...................... 2.2.2 Customizing auffüllen (Transaktion SMLT) ..... 2.2.3 Spezielle Werkzeuge ..................................... 2.2.4 Manuelles Übersetzen von Customizing-Texten ...................................... 2.2.5 Adressversionen ............................................ 2.2.6 Zeitzonenanforderungen im internationalen Geschäft ........................................................ 2.2.7 Datenübertragung im Unternehmen und mit externen Systemen .................................. Zusammenfassung .....................................................
37 39 50 63 69 70 71 73 73 74 76 80
Architekturen im Überblick .................................... 83 3.1 3.2 3.3 3.4
Aus der Vergangenheit in die Zukunft ........................ Überblick über globale (zentrale) oder verteilte (dezentrale) Architekturen ........................................ Voraussetzungen und Definitionen ........................... Dezentrale Architektur .............................................. 3.4.1 Einteilung .................................................... 3.4.2 Lokale und vollständig verteilte dezentrale Architektur ...................................................
83 90 94 100 100 105 7
00____1076.book Seite 8 Freitag, 5. Oktober 2007 3:07 15
Inhalt
3.5
3.6
3.7
3.8
3.9
4
114 114 117 124 124 124 128 129 129 130 133 145 145 146 148
149 152
Einflussfaktoren auf Systemarchitekturen ............ 155 4.1 4.2
4.3 4.4 4.5
4.6
8
Regionale Architektur mit Shared Services ................ 3.5.1 Konzeption .................................................. 3.5.2 Vor- und Nachteile ...................................... Zentralisierte dezentrale Architektur ......................... 3.6.1 Konzeption .................................................. 3.6.2 Vor- und Nachteile ....................................... Zentrale Architektur ................................................. 3.7.1 Konzeption .................................................. 3.7.2 Single-Instance-System – zentrales Einmandantensystem .................................. 3.7.3 Zentrales Mehrmandantensystem ................. 3.7.4 Vor- und Nachteile ....................................... Varianten und kombinierte (Hybrid-)Architekturen .. 3.8.1 Übersicht ..................................................... 3.8.2 Varianten der elementaren Architekturen ..... 3.8.3 Kombinationen mehrerer Architekturen in einer Systemlandschaft ............................. 3.8.4 Integration mehrerer SAP Business Suite-Komponenten mit verschiedenen Architekturen ............................................... Zusammenfassung ....................................................
Generelle Betrachtungen ........................................... Drei-Dimensionen-Modell der Globalisierung ........... 4.2.1 1. Dimension: Produkt ................................. 4.2.2 2. Dimension: Organisationen ...................... 4.2.3 3. Dimension: Prozesse ............................... Geschäftsprozesse ..................................................... Business Process Management (BPM) ....................... Organisationen ........................................................ 4.5.1 Corporate Governance ................................ 4.5.2 Globale Unternehmenskultur ........................ 4.5.3 Anforderungen an die Supportorganisation ................................................ 4.5.4 Anforderungen an das Rechenzentrum ........ 4.5.5 Service Level Agreements (SLA) .................... 4.5.6 ITIL-Standard .............................................. Produkt .................................................................... 4.6.1 Technische Sprachunterstützung und Sprachkombinationen ...................................
155 159 160 160 161 163 167 175 175 177 180 182 184 187 189 191
00____1076.book Seite 9 Freitag, 5. Oktober 2007 3:07 15
Inhalt
4.6.2 4.6.3 4.6.4 4.6.5 4.6.6
4.7
5
Zeitzonen ...................................................... SAP-Release-Strategie .................................. Industrielösungen ........................................ SAP ERP-Länderversionen ............................ Länderversionen in Industrielösungen und anderen SAP Business SuiteKomponenten ............................................... 4.6.7 Expansion in neue Länder und Auswirkungen auf die Architektur ........................................ Zusammenfassung .....................................................
193 196 197 199
203 204 209
IT-Realisation der Architektur ............................... 213 5.1
5.2
5.3
5.4
Allgemeine Anforderungen an das Rechenzentrum ... 214 5.1.1 Hardware-Konsolidierung und Adaptive Computing ................................................... 216 5.1.2 Planung der geeigneten Plattform ................ 217 IT-Infrastruktur für eine zentrale Architektur der globalen Lösung ................................................. 218 5.2.1 Planung für eine globale Single-InstanceArchitektur .................................................... 220 5.2.2 Server-Sizing ................................................ 221 5.2.3 Netzwerk-Sizing und Infrastruktur ................ 223 5.2.4 Workstation-Infrastruktur ............................ 225 5.2.5 Druckerinfrastruktur ...................................... 227 Betrieb eines SAP-Single-Instance-Systems ................ 229 5.3.1 Ausfallzeiten und Verfügbarkeit .................... 230 5.3.2 Spezielle Empfehlungen zur Reduktion geplanter Ausfallzeiten ................................. 234 5.3.3 Auslastung und Jobverarbeitung .................... 238 5.3.4 SAP Solution Manager ................................. 239 Realisierung globaler SAP-Projekte mit der gewählten Architektur ....................................................................... 240 5.4.1 Entwicklung und Konfiguration in globalen Systemen ....................................... 241 5.4.2 Entwicklung und Konfiguration bei verschiedenen Architekturen ......................... 244 5.4.3 Release-Management der globalen IT-Lösung ...................................................... 248 5.4.4 Konzern-Roll-out mit dem GlobalTemplate-Ansatz .......................................... 253
9
00____1076.book Seite 10 Freitag, 5. Oktober 2007 3:07 15
Inhalt
5.4.5
5.5
5.6
6
6.2 6.3
A B
C
259 265 265 273 275
Kundenszenarien und Entscheidungsfindung ......... 279 6.1
7
Implementierung neuer Länder in einem zentralen System .......................................... Werkzeuge zur Veränderung bestehender Architekturen ........................................................... 5.5.1 System Landscape Optimization (SLO) .......... 5.5.2 Spezielle Technologien: Migration und Conversion Workbench ............................... Zusammenfassung ....................................................
Erfahrungen von SAP-Kunden mit unterschiedlichen Systemtopologien ..................................................... 6.1.1 Das zentrale System .................................... 6.1.2 Der dezentrale Ansatz mit Einzelsystemen ... 6.1.3 Verteilte Systeme mit integrierten und konsolidierten Geschäftsprozessen ............... 6.1.4 Der dezentrale Ansatz mit Shared Services ... 6.1.5 Projektbeispiel: von verteilten Systemen zur Single Box .............................................. Leitfaden zur Entscheidungsfindung .......................... Zusammenfassung .....................................................
279 280 287 290 293 296 300 315
Zusammenfassung ................................................... 317 Glossar ................................................................................ Literatur .............................................................................. B.1 Bücher und Artikel .................................................... B.2 Links ......................................................................... B.2.1 Allgemeine Links .......................................... B.2.2 SAP-Links ..................................................... Die Autoren ........................................................................
319 325 325 327 327 327 329
Index ........................................................................................... 331
10
00____1076.book Seite 213 Freitag, 5. Oktober 2007 3:07 15
Wenn sich das globale Unternehmen für eine Architektur entschieden hat, muss diese für die Implementierung und den laufenden Betrieb optimiert werden. Hierbei gibt es vieles zu beachten. In diesem Kapitel erfahren Sie, wie die gewählte globale Architektur effizient realisiert werden kann.
5
IT-Realisation der Architektur
Bei der Umsetzung der Systemarchitektur (insbesondere der zentralen) stellen sich unter anderem folgende Fragen: ob und wie der optimale und störungsfreie Betrieb in einem globalen SingleInstance-System möglich ist, wie die Ausfallzeiten sicher gemanagt werden, das Netzwerk optimal funktioniert und eine gute Performance erreicht werden kann. Für die Projektteams geht es darum, wie ein globales Projekt und der Konzern-Roll-out mit dem GlobalTemplate-Ansatz bewältigt werden können, wie neue Länder in ein globales, produktives System sicher implementiert werden, wie die Istarchitektur einer bestehenden Systemlandschaft in eine neue Sollarchitektur konvertiert werden kann und vieles mehr. Wir gehen in diesem Kapitel auf diese und weitere Fragestellungen ein und geben wichtige Informationen und Empfehlungen an Sie weiter, die aus zahlreichen Analysen, Workshops, konkreten Projekten und eigenen Betrachtungen stammen. Dabei konzentrieren wir uns überwiegend auf die zentrale Single-Instance-Architektur, da hier erfahrungsgemäß am meisten Informationsbedarf besteht. Allerdings können die Ausführungen genauso gut auf regional ausgeprägte Architekturen angewendet werden, zum Beispiel auf Systeme, auf denen die Länder einer geografischen Region (zum Beispiel AsiaPacific) implementiert sind, die dann für die Region ein zentrales System darstellen. Zunächst gehen wir in den Abschnitten 5.1, 5.2 und 5.3 auf die infrastrukturellen Aspekte ein, die sich auf den Betrieb im Rechenzentrum und die Hardwareaustattung konzentrieren, danach behandeln wir in Abschnitt 5.4 die Planung, Implemen-
213
00____1076.book Seite 214 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
tierung und Entwicklung, insbesondere mit dem Global-TemplateAnsatz. In Abschnitt 5.5 geben wir einen Überblick über die Funktionalität und Arbeitsweise von Werkzeugen zur Veränderung einer bestehenden Systemarchitektur, wie zum Beispiel die Konsolidierung zweier getrennter Systeme in ein zentrales System. Natürlich können wir nicht immer auf alle Aspekte im Detail eingehen, denn dies würde den Rahmen dieses Buches sprengen. Wir konzentrieren uns vielmehr auf die typischen Fragestellungen einer globalen ITLösung und verweisen den interessierten Leser an weiterführende Literatur, etwa zum Rechenzentrumsbetrieb.
5.1
Allgemeine Anforderungen an das Rechenzentrum
Bei der komplexen und oft kontroversen Diskussion über die optimale Architektur der globalen IT-Lösung steht also die Frage im Mittelpunkt, ob und wie die Architektur in der Praxis realisiert werden kann, und zwar überwiegend in Bezug auf folgende Aspekte: 왘 Wirtschaftlichkeit 왘 hohe Leistung 왘 24 x 7-Betrieb und hohe Verfügbarkeit 왘 Sicherheit 왘 Änderbarkeit 왘 Globaler Service und Support Niedrige TCO für den Betrieb der IT-Lösung
Zunächst muss sichergestellt werden, dass die TCO (Total Cost of Ownership) für die Realisierung und den Betrieb der IT-Lösung insgesamt möglichst günstig ist. Dies ist eine selbstverständliche Forderung, die jedes Unternehmen an das IT-Team stellt, das mit der Realisierung der globalen IT-Lösung beauftragt wird. Die Schwierigkeit bei der Berechnung der TCO ist, dass nicht nur die Kosten auf der ITSeite, sondern auch auf der Business-Seite berücksichtigt werden müssen, da mit der Modellierung der Geschäftsprozesse, Änderungsaufgaben, Umstrukturierungen usw. ein direkter Einfluss auf die ITLösung und Architektur genommen wird. Im idealen Fall hängt die Auswahl und Entscheidung für die optimale Architektur der globalen
214
00____1076.book Seite 215 Freitag, 5. Oktober 2007 3:07 15
Allgemeine Anforderungen an das Rechenzentrum
5.1
Lösung nicht mehr nur von der IT ab. In der Praxis ist dies – auch wenn es hin und wieder durchaus berechtigt sein kann – noch zu selten der Fall. Die Weichen für die Auswahl einer Architektur sollten generell in einer Kooperation zwischen Business und IT gestellt werden, insbesondere wenn es um die Frage geht, ob das Unternehmen die Reife für eine vollständig globale Lösung hat oder eine verteilte Architektur vorziehen sollte. In Bezug auf die IT-Infrastruktur, also die Leistung der Hardware, Datenbanken, Server und Netzwerke, sind heute alle Architekturen realisierbar, auch für hohes bis sehr hohes Datenvolumen. Allerdings stellt hierbei die zentrale globale Single-Instance-Lösung die größte Herausforderung dar. Diesbezüglich werden in der Tat auch die kontroversesten Diskussionen geführt, nämlich, ob die IT eine Single Instance mit allen Anforderungen realisieren und betreiben kann. Aber auch jede andere Architektur muss sich günstig, schnell und sicher betreiben lassen, sodass an die IT-Infrastruktur im Rechenzentrum hohe bis sehr hohe Anforderungen gestellt werden.
Alle Architekturen technisch machbar
In den Abschnitten 4.5.3 bis 4.5.6 haben wir bereits gesehen, was ein modernes Rechenzentrum und die Betreiberteams grundsätzlich an Infrastruktur, Services und Prozessen für den Betrieb einer komplexen globalen Lösung bereitstellen müssen. Diesbezüglich kann das Unternehmen entweder ein eigenes Rechenzentrum betreiben oder einen Dienstleister damit beauftragen, wobei dann die Festlegung und Einhaltung von Service Level Agreements sowie ein Vorgehen nach den ITIL-Standards für das IT- und Applikationsmanagement sehr wichtig sind (siehe Abschnitte 4.5.5 und 4.5.6). Der interessierte Leser sei hier auf weiterführende Literatur verwiesen, zum Beispiel: Vital Anderhub: Service Level Management – the ITIL Process in SAP Operations, SAP PRESS Essentials 21, 2006. Wir möchten in diesem Abschnitt genauer auf die konkreten und wichtigsten Anforderungen an die IT eingehen, die als kritisch für die Realisierung der globalen IT-Lösung gelten. Diesbezüglich steht die zentrale Single-Instance-Lösung im Mittelpunkt des Interesses, mit der die globale IT-Lösung weltweit rund um den Globus 24 Stunden täglich und an sieben Wochentagen betrieben werden soll. Aber auch für jede andere dezentrale Architektur gelten die folgenden Aspekte in ähnlicher Weise, mit den entsprechenden Anpassungen.
215
Schwerpunkt Single-InstanceLösung
00____1076.book Seite 216 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
5.1.1
Hardware-Konsolidierung und Adaptive Computing
Server- und Speicherkonsolidierung
Die Server-Technologie ist mittlerweile sehr weit fortgeschritten, und es ist möglich, mehrere Systeme auf einem Server zu betreiben und gemeinsame Speichersysteme zu benutzen, die mehrere Systeme unterstützen. Man denke hier an die bekannten SAN- (Storage Area Network) Speichersysteme. Soll für die globale Lösung eine dezentrale Architektur eingesetzt werden, und kann ein zentrales Rechenzentrum an einem Standort die gesamte Systemlandschaft betreiben, so ist es oft möglich und effizient, mehrere dezentrale Systeme auf einer gemeinsamen Hardware zu betreiben. Dabei bleiben natürlich die Architektur, Anwendungen und Daten dezentral, aber aufgrund einer leistungsfähigen gemeinsamen Hardware werden die Kosten für die Infrastruktur gesenkt. In der Praxis wird oft eine Server- und Storage-Konsolidierung vorgenommen, insbesondere bei Änderungen oder Migrationen der Hardware, beispielsweise, wenn die verteilte Systemlandschaft der dezentralen IT-Lösung aus mehreren Rechenzentren in ein zentrales Rechenzentrum umzieht.
Adaptive Computing
Es gibt noch einen erheblichen Vorteil bei gemeinsam genutzter Hardware: Mithilfe der neuen Adaptive-Computing-Technologie können dynamisch Hardware-Ressourcen, je nach Bedarf, den verschiedenen Systemen zugewiesen werden, sodass eine bessere Auslastung erreicht werden und auf Spitzensituationen besser reagiert werden kann.1 SAP hat mit SAP NetWeaver die Adaptive-Computing-Technologie speziell für SAP-Systeme eingeführt. Mit den neuen Adaptive-Computing-Funktionen von SAP NetWeaver können Unternehmen ihre Anwendungen und Daten bestimmten Servern oder Speichersystemen flexibel zuweisen und so auf wechselnde Anforderungen an die Rechenleistung und auf Veränderungen in der Hardwareverfügbarkeit reagieren. Auf diese Weise ist es beispielsweise möglich, verschiedene Software- oder Datenbankprozesse parallel auf einem Server laufen zu lassen. Anwender und die Betreiber des Rechenzentrums erhalten so die Möglichkeit, ihre Ressourcen besser zu nutzen. Beide Aspekte der Hardware-Konsolidierung und der Adaptive-Computing-Technologie eignen sich gut für die IT-Infrastruktur der globalen IT-Lösung – für jede Architektur. 1 Siehe zum Beispiel Michael Missbach et al.: Adaptive Hardware-Infrastrukturen für SAP. SAP PRESS 2005.
216
00____1076.book Seite 217 Freitag, 5. Oktober 2007 3:07 15
Allgemeine Anforderungen an das Rechenzentrum
Für die Unterstützung von Adaptive Computing in SAP NetWeaver finden Sie weitere Informationen im SAP Service Marketplace unter dem Link http://service.sap.com/netweaver SAP NETWEAVER IM DETAIL SOLUTION LIFE-CYCLE MANAGEMENT ADAPTIVE COMPUTING.
5.1.2
Planung der geeigneten Plattform
Die SAP-Software unterstützt mehrere Betriebssysteme und Datenbanken (Plattformen), sodass das IT-Team des Unternehmens die geeignete Plattform auswählen kann. Extrem wichtig ist dabei, nur eine für die eingesetzten SAP Business Suite-Komponenten freigegebene Plattform zu wählen, die auch für zukünftige Planungen ausgelegt ist. Die SAP Platform Availability Matrix (PAM), die Sie auf dem SAP Service Marketplace unter dem Link http://service.sap.com/pam finden, gibt diesbezüglich genaue Auskunft.2 Es gelten die folgenden Empfehlungen: 왘 Zusammenarbeit mit SAP-Plattform-Partnern Die genaue Auswahl der geeigneten Hardware, also des Datenbank-Servers, des Applikationsservers, des Speichersystems und anderer Komponenten, erfolgt in Zusammenarbeit mit den Plattform-Partnern. Diese verfügen über detaillierte Daten und Fakten und Benchmarks zu den erhältlichen Servermodellen und arbeiten entsprechend den Sizing-Anforderungen des Unternehmens konkrete Vorschläge der Hardwarelandschaft aus. 왘 64-Bit-Strategie Für ein globales System mit großem Volumen kommen nur 64Bit-Plattformen infrage. Heutzutage dominiert die 64-Bit-Technologie den Servermarkt. Neue Dimensionen der Leistung und Skalierbarkeit werden erreicht, und insbesondere die 32-Bit-AdressBeschränkungen des Hauptspeichers für einen Prozess auf vier GB (in der Praxis in der Regel noch darunter, siehe zum Beispiel SAPHinweis 308375) werden aufgehoben. Die Aufhebung dieser und weiterer Limits ist aber gerade die Voraussetzung, die eine Single Instance und auch jede andere dezentrale Architektur mit hohem Datenvolumen und -duchsatz benötigt.
2 Weitere Details und Informationen hierzu finden Sie im SAP Service Marketplace unter http://service.sap.com/platforms.
217
PlattformStrategie für SAP-Systeme
5.1
00____1076.book Seite 218 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
왘 Unicode-Unterstützung Um auf einer Single-Instance-Lösung uneingeschränkte Sprachunterstützung zu ermöglichen, kommt nur ein SAP-Unicode-System infrage. Viele globale Unternehmen, die noch kein Unicode-System einsetzen, sind sich dieser Tatsache bewusst und führen bereits ein Unicode-Projekt durch oder befinden sich in der Planung. Neue Installationen sollten nur noch in Unicode erfolgen; ab 2007 werden Neuinstallationen neuer SAP-Produkte nur noch in Unicode ausgeliefert. Daher sollte die Plattform für die globale Lösung für eine jetzige oder zukünftige Unicode-Plattform ausgelegt sein. Release-Abhängigkeit der Plattform
Bei der Planung der Datenbank- und Betriebssystem-Version muss beachtet werden, ab wann und wie lange diese Versionen vom Datenbank- und Hardwarehersteller unterstützt werden. Diese Informationen sind mit der Release-Strategie der eingesetzten SAP-Komponente abzugleichen und sollten genau befolgt werden.3 Etwaige Ausnahmeregelungen oder Besonderheiten müssen sehr genau und im Detail analysiert werden. Dies wird in der Praxis oft vernachlässigt, was zu Problemen aufgrund von Inkompatibilitäten zwischen Plattform und SAP-System führt.
5.2
IT-Infrastruktur für eine zentrale Architektur der globalen Lösung
Die folgenden Betrachtungen gelten für den Single-Instance-Fall, können aber auf jede andere Architektur mit großen Systemen, zum Beispiel auf regionale Systeme mit vielen Ländern eines Kontinents und hoher Anzahl von Benutzern, angewendet werden. Single-InstanceRealisierungen
Bei der Single-Instance-Architektur stellt sich die Hauptfrage, ob eine technische Realisierung überhaupt möglich ist. Wie schon mehrfach erwähnt, ist die IT heutzutage auf einem so hohen technologischen Stand, dass selbst Systeme mit mehreren Zigtausend Benutzern und einer Datenbank im zweistelligen TB-Bereich technisch möglich sind. Das heißt aber bei Weitem nicht, dass jede globale Lösung auf einer Single Instance ohne Weiteres betrieben werden kann, da viele Bedingungen erfüllt sein müssen.
3 Siehe http://service.sap.com/releasestrategy; http://service.sap.com/pam.
218
00____1076.book Seite 219 Freitag, 5. Oktober 2007 3:07 15
IT-Infrastruktur für eine zentrale Architektur der globalen Lösung
5.2
Bei der Diskussion um die technische Machbarkeit einer SingleInstance-Lösung wird fast immer zuerst die Frage gestellt, ob es bereits große Unternehmen gibt, die diese Architektur erfolgreich mit SAP einsetzen. Da jedes Unternehmen und damit die globale ITLösung individuell ist, sollten die Aussagen mit Vorsicht interpretiert werden; jedoch dienen sie als guter Anhaltspunkt. Um dem Leser einen allgemeinen Eindruck darüber zu vermitteln, ob und in welchen Dimensionen Unternehmen globale SingleInstance-ERP-Systeme einsetzen, zeigt Tabelle 5.1 eine kleine Auswahl bekannter produktiver SAP-Systeme (Stand 2007) mit den folgenden Kennzahlen: 왘 Single Instance: Angabe, ob es sich um ein Single-Instance-System handelt 왘 Anzahl der aktiven Benutzer: durchschnittliche Anzahl der weltweiten Benutzer, die an 24 Stunden aktiv im System arbeiten 왘 Datenbankgröße: aktuelle Größe der zentralen Datenbank in Terabyte 왘 ERP-Anwendungen: produktive SAP-Applikationen 왘 Unicode: Angabe, ob das globale System in Unicode läuft Kunde Single Instance
Anzahl aktiver Benutzer
Datenbankgröße in TB
ERP-Anwen- Unicode dungen ja/nein
1
Ja, live in EMEA und Asien; USA in 2007
30 000 geplant für Ende 2009
0,7; Plan 12 TB in 2009
Alle ohne HCM
Ja
2
Ja
5 600
0,8
Alle
Ja
3
Ja
5 000
5
FI, CO, SD, In 2007 MM, PP, WM
4
Ja
8 000
4,8
FI, CO, SD, MM, PP
Nein
5
Ja, mit 2 glo- 15 000 je balen SysteSystem men; Plan, auf 1 zu mergen
1,8
FI, CO, MM, SD, PS, CS, AM
In 2007
6
Ja
1
SD, MM, PS, HR inklusive ESS/MSS
In 2007
33 000
Tabelle 5.1 Reale Beispiele von globalen SAP ERP-Single-Instance-Systemen (4.7, ECC 5.0 ECC 6.0)
219
Single-InstanceBeispiele
00____1076.book Seite 220 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
Wie Sie sehen können, handelt es sich in allen Fällen um eine beachtliche Anzahl von aktiven Benutzern; fast alle Datenbanken liegen im Terabyte-Bereich, und in einem Fall besteht sogar der Plan, zwei große globale Systeme zu einem zu konsolidieren. Auf die Zusammenführung von SAP-Systemen gehen wir in Abschnitt 5.5 ein. Es sei angemerkt, dass es auch für andere SAP Business Suite-Komponenten produktive und sehr große Single-Instance-Systeme gibt, vorzugsweise mit SAP NetWeaver BI, bei denen Implementierungen mit Datenbankgrößen von etwa 10 TB und mehr bekannt sind (Stand 2007). Damit kann also gezeigt werden, dass die Single-Instance-Lösung generell technisch realisierbar ist; allerdings, ohne zunächst sagen zu können, ob dies auch für den jeweils konkreten Fall zutrifft. In den nächsten Abschnitten erörtern wir in einer fallstudienähnlichen Vorgehensweise die verschiedenen Anforderungen und Fragestellungen hinsichtlich der technischen Infrastruktur einer Single-InstanceLösung und leiten daraus die Fakten und Empfehlungen ab, die auf jede andere globale IT-Architektur übertragbar sind.
5.2.1
Planung für eine globale Single-Instance-Architektur
Betrachten wir die folgende Aufgabe: Beispielaufgabe
Ein Unternehmen möchte eine weltweite Single-Instance-Lösung für alle SAP ERP-Core-Anwendungen mit etwa 10 000 aktiven Benutzern in Amerika, EMEA und Asien-Pazifik realisieren. Die Datenbank hat eine Größe von mehreren TB, und das SAP-System wird in Unicode betrieben. Das System ist geschäftskritisch und muss daher sehr sicher, effizient und rund um die Uhr an allen Wochentagen verfügbar sein. Die durchschnittliche Antwortzeit für die Endbenutzer soll weltweit bei maximal einer Sekunde liegen, ohne Berücksichtigung etwaiger Netzwerklatenzen. Dabei müssen die folgenden Aspekte analysiert und geklärt werden: Kritische Aspekte für SingleInstance- Systeme
왘 Server-Sizing und Leistung 왘 Netzwerk-Sizing und Leistung 왘 Workstation- und Druckerinfrastruktur 왘 Betrieb 왘 24 x 7-Betrieb 왘 Hochverfügbarkeit 왘 geplante und ungeplante Ausfallzeiten 왘 Auslastung und Jobverarbeitung 왘 Wartungsarbeiten
220
00____1076.book Seite 221 Freitag, 5. Oktober 2007 3:07 15
IT-Infrastruktur für eine zentrale Architektur der globalen Lösung
5.2.2
5.2
Server-Sizing
Um die erforderliche Hardwarekapazität zu ermitteln, muss zuerst eine geeignete Planung der benötigten Hardware erfolgen, die als Sizing bezeichnet wird.4 Das Sizing erfolgt in Zusammenarbeit des IT-Teams des Unternehmens, der Hardwareanbieter beziehungsweise -Partner und gegebenenfalls SAP. SAP bietet das Werkzug Quick Sizer5 an, das in der Lage ist, aus technischen und anwendungsspezifischen Eckdaten des Unternehmens eine erste Abschätzung für die notwendige Leistung der Hardware zu liefern.
Sizing der Hardware
Der Quick Sizer berechnet Bedarfskategorien für CPU, Harddisk und Hauptspeicher, die auf Leistungskennzahlen und der Anzahl von Benutzern für die unterschiedlichen SAP Business Suite-Komponenten beruhen und plattformunabhängig sind. Das Ergebnis ist eine Schätzung der notwendigen Hardwarekapazität und dient als erste Annäherung für die Hardware- und Infrastrukturplanung. Zusammen mit Hardware-Partnern werden die Quick-Sizer-Ergebnisse in einem iterativen Prozess verfeinert, bis eine genaue Planung für die konkrete Hardware steht.
Quick Sizer
Für ein geeignetes Sizing der Hardware, ist es sinnvoll, einen plattformunabhängigen Index zur Verfügung zu haben, der die Leistung der Hardware in Bezug zu den SAP-Anwendungen setzt. Damit sind die Hardwareanbieter in der Lage, konkrete Hardwaremodelle verschiedener Ausstattungen zu vermessen und deren Leistungen, ähnlich der PS-Zahl eines Autos, zu veröffentlichen. Beim Sizing wird aufgrund der Anforderungen des Unternehmens für die IT-Lösung, die in den Sizing-Schritten verwendet werden, ein Indexwert errechnet, den die Hardware liefern muss. Dieser Index dient also zum einen dazu, sich einen Überblick über die Leistung einer bestehenden Installation zu verschaffen, zum anderen ist er Grundlage für eine grobe Abschätzung des Sizings einer zu planenden Infrastruktur für den SAP-Betrieb. Dieser Index SAPS steht für SAP Application Performance Standard und gibt an, wie viele SD-Auftragspositionen (Order Line Items) ein SAP-System pro Zeiteinheit verarbeiten kann. Der SAPS-Wert wird 4 Wir geben hier nur eine kurze Übersicht; Details finden Sie im SAP Service Marketplace unter http://service.sap.com/sizing. 5 Details unter http://service.sap.com/quicksizer.
221
SAP Application Performance Standard (SAPS)
00____1076.book Seite 222 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
durch die Ausführung des SD-Benchmarks ermittelt, bei dem es sich um eine genau festgelegte Abfolge von Arbeitsschritten im Salesund Distribution-Bereich des SAP-Systems handelt. 100 SAPS entsprechen 2 000 vollständig verarbeiteten Auftragspositionen pro Stunde im Standard SD-Applikation-Benchmark oder 6 000 Dialogschritten beziehungsweise 2 400 SAP SD-Transaktionen pro Stunde.6 Die Definition von SAPS basiert also auf dem betriebswirtschaftlichen Prozess und ist somit unabhängig von einer speziellen Konfiguration oder von der verwendeten Version. Damit kann er auch gut für das Sizing der globalen Lösung herangezogen werden. Um eine Vorstellung davon zu erhalten, was die Hardware beim heutigen Stand der Technik maximal erreichen kann und wann die Single-Instance-Lösung an ihre Grenzen stoßen würde, zeigt Tabelle 5.2 einen Benchmark-Auszug aus maximal erreichten Messungen und realen produktiven Systemen.7 Messgrößen
Ergebnis
Höchster erreichter SD-Benchmark in 2005
Etwa 850 000 SAPS mit 16 Millionen verarbeiteten SDAuftragspositionen pro Stunde
Reale aktive Benutzer
Zwischen 3 000+ und 12 000+
Real erreichte SAPS bei Kunden im Dauerbetrieb
> 100 000
Reale Datenbankgröße
15 TB
Tabelle 5.2 Ausgewählte maximale Benchmark-Referenzen
Nehmen wir also im realen Produktivsystem etwa 100 000 SAPS an, dann heißt das, dass damit etwa 2 400 × 1 000 = 2,4 Millionen SDStandardtransaktionen pro Stunde erreicht werden können – eine sehr beeindruckende Zahl. Zusammen mit einer möglichen Anzahl von vielen Tausend aktiven Benutzern und der Annahme der Gültigkeit des Moorschen Gesetzes (siehe Kapitel 3, Abbildung 3.1) sind die technischen Grenzen für eine Single Instance extrem hoch,
6 Siehe http://service.sap.com/benchmark. 7 Unter dem Link http://service.sap.com/benchmark SAP STANDARD APPLICATION BENCHMARKS – PUBLISHED RESULTS werden fortlaufend Benchmark-Messungen veröffentlicht.
222
00____1076.book Seite 223 Freitag, 5. Oktober 2007 3:07 15
IT-Infrastruktur für eine zentrale Architektur der globalen Lösung
5.2
sodass auf der Serverseite eine Single Instance mit den SAP ERPAnwendungen für ein globales Unternehmen mit hoher Wahrscheinlichkeit machbar ist; allerdings nur dann, wenn auch das Netzwerk und die Frontend-Infrastruktur leistungsfähig genug sind.
5.2.3
Netzwerk-Sizing und Infrastruktur
Die für die Single Instance häufig geforderte durchschnittliche Antwortzeit von etwa einer Sekunde setzt sich aus mehreren Laufzeiten zusammen, nämlich im Wesentlichen aus der Frontend-, der Netzwerk- und Serverlaufzeit.8 Die Frontend-Laufzeit ist die Bearbeitungszeit auf dem PC des Endbenutzers; die Netzwerklaufzeit ist die Übertragungszeit vom Endbenutzer zum SAP-System und zurück; und die Serverlaufzeit ist die Verweildauer im SAP-System des Dialogschritts von der Anfrage bis zur Antwort.
Leistungsfähiges Netzwerk zu den weltweiten Standorten
Da die Endbenutzer weltweit an verschiedenen Standorten arbeiten, müssen an das Fernverbindungsnetzwerk hohe Kapazitätsanforderungen gestellt werden. Heute wird das Scheitern einer weltweiten Single Instance häufiger durch ein zu langsames Netzwerk als durch zu langsame Server verursacht. Ein grobe Schätzung für die maximale Antwortzeit von einer Sekunde kann etwa so angesetzt werden, dass die Serverlaufzeit 800 msec, die Netzwerklaufzeit 100-200 msec und die Frontend-Laufzeit vernachlässigbar ist. Während die Laufzeiten für die Server und Frontend-Seite in der Regel kein Problem darstellt, ist sie in Bezug auf das Netzwerk problematischer. Zur Vereinfachung nehmen wir an, dass die Endbenutzer fast ausschließlich mit dem SAP GUI-Frontend arbeiten.9 Werden Internetbrowser-basierte Anwendungen, etwa über das SAP NetWeaver-Portal eingesetzt, so müssen weitere Analysen gemacht werden. Für die Berechnung der Bandbreite muss abgeschätzt werden, wie viele parallel aktive Benutzer welche Datenmenge pro Zeiteinheit über das Netzwerk bidirektional übertragen. Arbeitet der Endbenut8 Dies ist ein vereinfachtes Modell, da wir hier nicht auf alle Details eingehen können. 9 Details, Informationen und Anforderungen an das Netzwerk mit SAP GUI finden Sie in: SAP AG: Frontend Network Requirements for SAP Solutions, V 5.2, March 2003 sowie unter http://service.sap.com/sapgui.
223
Erforderliche Netzwerkbandbreite
00____1076.book Seite 224 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
zer mit dem SAP GUI Frontend, können im Durchschnitt zwischen etwa 2.5 und 5 bis 6 KB pro Dialogschritt angenommen werden; bei einem Internetbrowser dagegen etwa 15 KB. Pro Minute werden in etwa drei Dialogschritte von jedem Benutzer ausgeführt. Kennt man die Anzahl der parallel aktiven Benutzer in einem Netzwerksegment, kann daraus die Mindestbandbreite für den Dialogbetrieb abgeleitet werden. Hierzu müssen alle weiteren Datenflüsse addiert werden, wie E-Mail, Drucken, File Transfer, Internetbenutzung und Weitere. Netzwerklatenz
Unter der Netzwerklatenz wird im Allgemeinen die Laufzeit eines Datenpakets durch das Netzwerk verstanden. Dies entspricht also der weiter oben definierten Netzwerklaufzeit. Beispiele hierfür sind etwa 10-20 msec in einem LAN; 50-250 msec in einem kabelbasierten WAN und 200-600 msec über Satellit. Das Datenpaket wird aber meist nie sofort und direkt, sondern je nach Netzwerkanbieter durch Einwahl und über mehrere Zwischenstationen, Vermittlungsknoten und Router übertragen. Hierdurch entstehen zusätzliche technische Warte- oder Verzögerungszeiten bei der Einwahl oder in den Vermittlungsknoten, die die gesamte Netzwerklaufzeit erheblich verlängern können. Während die Lösung des Einwahlproblems recht einfach ist, können die Wartezeiten in den Vermittlungsknoten nicht unmittelbar beeinflusst werden, sodass das Problem nur über den Netzwerkanbieter gelöst werden kann.
Auswahl geeigneter Netzwerkanbieter
Um die Netzwerklaufzeit im geforderten Rahmen von maximal mehreren 100 msec zu halten, muss der Netzwerkdienstleister die folgenden Anforderungen erfüllen: 왘 hohe Verfügbarkeit des Netzwerks im 24 x 7-Betrieb mit alternativem Backup-Netzwerk 왘 garantierte Mindestbandbreite, selbst bei kurzfristig hoher Last 왘 stabile und geringe Latenz in den Vermittlungsknoten 왘 kein beziehungsweise geringer Datenverlust 왘 hohe Sicherheit 왘 Bereitstellung verschiedener Service Level Agreements (SLA) 왘 Netzwerkservice und -support mit 24 x 7-Erreichbarkeit
224
00____1076.book Seite 225 Freitag, 5. Oktober 2007 3:07 15
IT-Infrastruktur für eine zentrale Architektur der globalen Lösung
5.2.4
5.2
Workstation-Infrastruktur
Für den Support des Endbenutzers ist es notwendig, weltweit in allen Büros einen internen IT-Support zu etablieren, der sich um die Belange des Users kümmert. Dabei ist es oft eine Herausforderung, eine unternehmensweite globale Infrastruktur für die Workstations der Endbenutzer festzulegen. Insbesondere bereiten lokale Besonderheiten in bestimmten Ländern Probleme, da diese aufgrund der notwendigen Sprachunterstützung verschiedene Software benötigen, zum Beispiel in der Geschäftsstelle in Japan ein japanisches Windows XP. Die gleiche Problematik tritt bei Druckern auf, die spezielle Hardware – sogenannte Font-Zusätze – benötigen, um die gewünschten Texte drucken zu können. Dies erfordert eine gute Planung und Zusammenarbeit der zentralen IT-Teams im Rechenzentrum mit den lokalen Supportteams in den Landesgesellschaften. Wegen der lokalen Besonderheiten in den Ländern, die primär durch die Sprachunterstützung bedingt sind, ist es in der Regel nicht möglich, die Workstation-Infrastruktur und insbesondere die Workstation-Software weltweit einheitlich festzulegen. Dennoch sollte sie, wenn möglich, zentral sein. Allgemein gelten folgende Empfehlungen:10
Ausstattung der Arbeitsplätze der Endbenutzer
왘 wenn möglich, Einsatz von weltweit einheitlicher WorkstationSoftware, wie zum Beispiel Windows XP
Empfehlungen für einheitliche Workstation-Software und -Konfiguration
왘 lokale abweichende Workstation-Software nur dann, wenn wirklich nötig (zum Beispiel japanisches Windows XP in Japan) 왘 einheitliche Versionen und Service-Packs der Workstation-Software, auch in den Ausnahmeländern, zum Beispiel Windows XP SP2 auch in Japan 왘 global einheitliche SAP-Workstation, Softwarestrategie, Versionund Patch-Levels, insbesondere für SAP GUI, aber auch für abhängige Software, wie zum Beispiel MS Internet Explorer bei der Arbeit mit webbasierten SAP-Anwendungen 왘 lokale Konfigurationen zu den lokalen MS Windows-Einstellungen für die SAP GUI-Software, zusätzlich je nach Sprache, um die Sprachunterstützung in den verschiedenen Ländern zu ermöglichen, und zwar für die Arbeit mit den optimalen Fonts, dem Zei10 Siehe http://service.sap.com/globalization; http://service.sap.com/I18N sowie die zahlreichen SAP-Hinweise zu diesem Thema für Details und weitere Informationen.
225
00____1076.book Seite 226 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
chensatz der Sprache, dem Upload und Download von Dateien mit lokalen Texten und mehr (sogenannte Internationalisierung mit dem I18N-Flag). Dies gilt für SAP-Unicode- und Non-UnicodeSysteme, wobei bei Unicode erheblich weniger zu konfigurieren ist. Um eine möglichst globale SAP GUI-Konfiguration auszurollen, die alle SAP-Sprachen unterstützt und auch gemischte Logins in SAP-Unicode- und Non-Unicode-Systemen auf einer Workstation ermöglicht, sollte unabhängig vom SAP-Release der BusinessSuite-Komponenten die Version SAP GUI 6.40 oder höher mit dem gesetzten I18N-Flag ausgerollt werden (SAP GUI MENÜ ANPASSUNG DES LOKALEN LAYOUTS OPTIONEN MULTIBYTE-FUNKTIONALITÄTEN AKTIVIEREN). Dann müssen auf den lokalen Workstations im Allgemeinen nur geringfügige Einstellungen erfolgen. 왘 Bereitstellung zentraler und automatischer Update-Werkzeuge für die SAP-Software auf den lokalen Workstations. Um die Wartung und den Support für die Workstation-Software möglichst effizient zu gestalten, sollten entsprechende Werkzeuge eingesetzt werden, die die notwendigen Patches, Updates, usw. beim Einschalten des PCs automatisch einspielen.
Einsatz von Windows Terminal Servern Citrix Terminal Server
Liegen Netzwerkengpässe vor, eventuell nur in bestimmten Ländern, sind die PCs an den Arbeitsplätzen der Endbenutzer unzureichend ausgestattet oder ist die Software-Wartung der lokalen Workstations zu aufwendig. So kann der Einsatz von Windows Terminal Servern, zum Beispiel Citrix-Servern,11 sinnvoll sein. Der Endbenutzer meldet sich auf dem Terminal-Server über eine konfigurierte Client-Software an, zum Beispiel Citrix ICA, auf dem die komplette Workstation-Software inklusive SAP GUI und anderer Software installiert ist. Der Benutzer benutzt dann seinen lokalen PC als einfaches Terminal, das nur die Tastatureingaben und Anzeigen managt. Die eigentliche Arbeit des Benutzers erfolgt auf dem entfernten Server. Dies hat folgende Vorteile: 왘 Die Workstation-Software wird zentral auf dem Terminal-Server installiert und gewartet; der Endbenutzer braucht sich um nichts zu kümmern. 11 Für Details siehe http://www.citrix.com.
226
00____1076.book Seite 227 Freitag, 5. Oktober 2007 3:07 15
IT-Infrastruktur für eine zentrale Architektur der globalen Lösung
5.2
왘 Die Terminal-Server-Technologie ist heutzutage sehr zuverlässig und stabil. 왘 Auf einem Citrix-Server können mehr als 50 aktive Benutzer parallel arbeiten. 왘 Intelligente Komprimierungsmethoden können den Netzwerkverkehr zwischen Benutzer und Terminal-Server erheblich optimieren. 왘 Müssen sich mobile Benutzer von außerhalb in das Firmennetz einloggen, so bietet Citrix zusammen mit zusätzlicher SicherheitsHardware und Software (zum Beispiel SMART Cards ) eine geeignete und vor allem sichere Lösung. 왘 Bei der Konfiguration der Workstation-Software müssen die gegebenenfalls notwendigen lokalen Anforderungen der Benutzer berücksichtigt werden; zum Beispiel muss die japanische Sprachunterstützung und Eingabemethode auf der Server-Workstation installiert werden. 왘 SAP-Frontend-Druck wird aus dem Windows Terminal Server unterstützt.
5.2.5
Druckerinfrastruktur
Üblicherweise wird die Druckerinfrastruktur zentral vom globalen IT-Team ausgearbeitet, das heißt, dass die Druckerhardware zentral geplant, ausgewählt und an die betreffenden IT-Supportteams in den Landesgesellschaften kommuniziert wird, die die Drucker beschaffen, installieren und anschließen. Dabei besteht in der Praxis der Trend zum Einsatz schneller, effizienter und kostengünstiger Netzwerkdrucker, die in der Lage sind, direkt über das Unternehmensnetzwerk zu drucken. Oft werden auch spezielle Drucker-Management-Systeme eingerichtet, um zusätzliche Funktionalität und einen hohen Durchsatz zu erlangen.
Druckerunterstützung für alle Sprachen
Der ideale Fall für eine weltweit einheitliche Druckerinfrastruktur ist ein SAP-Unicode-System, in dem nur Unicode-Drucker eingesetzt werden,12 sodass Dokumente in allen Sprachen in allen Zeichensätzen unbeschränkt und überall ausgedruckt werden können. Solche
Unicode- und NonUnicode-Drucker mit Font-Zusätzen
12 SAP unterstützt derzeit (Stand 2007) Unicode-Drucker von HP und Lexmark; weitere Modelle werden von SAP-Partnern angeboten.
227
00____1076.book Seite 228 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
Drucker sind aber heutzutage noch recht teuer und oft noch langsam oder haben nicht die passenden Fonts. Daher werden meist Drucker eingesetzt, die nur Sprachen eines oder weniger Zeichensätze beziehungsweise einer Codepage unterstützen, etwa nur die west- und osteuropäischen Sprachen. Soll in Sprachen anderer Zeichensätze beziehungsweise Codepages gedruckt werden, wie zum Beispiel in Russisch oder in den asiatischen Sprachen, so müssen oft spezielle Hardwarezusätze – genannt Font Cartridges oder DIMM Modul – in den Drucker eingebaut und ein geeigneter SAP-Gerätetyp mit der passenden Druckerkonfiguration für diese Hardwarezusätze vorhanden sein. Heutzutage gibt es Tausende verschiedener Druckermodelle auf dem Markt. Drucker sind allerdings immer noch technisch sehr individuelle Geräte, die sehr speziell konfiguriert und programmiert werden müssen – teilweise noch mit hexadezimal-ähnlicher Kodierung, wie zum Beispiel bei PCL (Printer Control Language). Daher ist es in vielen Fällen notwendig, für solche speziellen Drucker mit dieser Hardware-Erweiterung eigene SAP-Gerätetypen zu entwickeln, sofern sie nicht im SAP-Standard angeboten werden. Dies ist bei der Planung der Drucker-Infrastruktur unbedingt zu berücksichtigen. Multilinguales Drucken über MS Windows
Empfehlungen für einheitliche Drucker-Infrastruktur
Einfachere Lösungen ohne Hardwarezusatz arbeiten mit softwarebasierten Verfahren, indem entweder für die benötigte Sprache ein geeigneter Font geladen wird oder der Ausdruck aus dem SAP-System über das MS Windows Drucker-Management erfolgt, das viele Tausend Druckermodelle und alle Sprachen unterstützt. Für den Druck über MS Windows kann in SAP-Unicode-Systemen mit der Cascading-Font-Technik schnell und einfach ein eigener Font mit den gewünschten Zeichensätzen samt SAP-Gerätetyp erzeugt werden.13 Diese Methoden haben den Vorteil, dass sie für alle Sprachen einfach und schnell einzurichten sind. Nachteilig ist, dass sie langsamer sind, mehr Netzwerkbelastung zwischen SAP-Server und Drucker verursachen und in der Regel nicht immer die aus SAP direkte Ansteuerung von LAN-Netzwerkdruckern zulassen. Allgemein gelten folgende Empfehlungen: 왘 Bei der Planung und Auswahl der Drucker sollte von Anfang an die Unterstützung aller Sprachen der globalen IT-Lösung als hartes Kriterium einbezogen werden. 13 Für Details siehe Nils Bürckel, Alexander Davidenkoff, Detlef Werner: Unicode in SAP-Systemen. SAP PRESS 2007.
228
00____1076.book Seite 229 Freitag, 5. Oktober 2007 3:07 15
Betrieb eines SAP-Single-Instance-Systems
왘 Der Einsatz von Unicode-Druckern sollte in Erwägung gezogen werden. 왘 Drucker mit einfachen Zeichensätzen beziehungsweise SingleCodepages werden in SAP-Unicode-Systemen unterstützt und erlauben den Ausdruck in den Sprachen des unterstützten Zeichensatzes. 왘 Drucker mit gut etablierten Drucker-Programmiersprachen sind empfehlenswert, etwa PostScript oder PCL. 왘 Beim Einsatz von Druckern mit speziellen Hardwarezusätzen für Sprachen sollten bei den Herstellern genaue Informationen bezüglich folgender Fragen eingeholt werden: Welche Sprachen werden mit welchem Zusatz unterstützt; wo und wie werden die Zusätze beschafft; bietet der Hersteller weltweit technischen Support an; gibt es bereits einen SAP-Gerätetyp für diesen Hardwarezusatz? 왘 Für die ausgewählten Drucker und/oder Zusätze sollte eine Planung der Entwicklung oder Anpassung von SAP-Gerätetypen durchgeführt werden, falls nicht im SAP-Standard vorhanden. 왘 Beim Einsatz softwarebasierter Gerätetypen sollten langsamerer Druck und höhere Netzwerklast berücksichtigt werden. 왘 Drucker mit speziellen Hardwarezusätzen erfordern die Zusammenarbeit der globalen IT-Supportteams mit dem lokalen IT-Support, oder ein Spezialist für die Sonderlösung muss Mitglied im globalen Team des Rechenzentrums sein. Alle aufgeführten Punkte gelten in ähnlicher Weise für Peripheriegeräte, die aufgrund lokaler Anforderungen mit spezieller Hardware ausgestattet sind, um zum Beispiel Faxe in lokaler Sprache zu erzeugen und zu versenden. Die Software und Steuerung solcher Geräte muss oft in ähnlicher Weise wie bei den Druckern angepasst werden, sofern die Standardsoftware dies nicht bereits erledigt.
5.3
Betrieb eines SAP-Single-Instance-Systems
In diesem Abschnitt gehen wir auf die wichtige Frage ein, wie ein Single-Instance-System sicher, performant und störungsfrei betrieben werden kann. Möchte ein Unternehmen sich für die zentrale Single-Instance-Architektur entscheiden, so stellt sich meist die zentrale Frage, ob es realistisch ist, ein solches System rund um den Globus, rund um die Uhr und an sieben Wochentagen zu betreiben.
229
5.3
00____1076.book Seite 230 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
5.3.1 Kritische Faktoren, Ausfallzeit und Verfügbarkeit
Ausfallzeiten und Verfügbarkeit
Eines der oft größten Hindernisse bezüglich des Betriebs einer globalen Single-Instance-Lösung ist die Problematik der Ausfallzeiten, auch wenn die Hardware- und Netzwerkkapazität gut ausreichen würde. Wegen des 24 x 7-Betriebs muss das System rund um die Uhr benutzbar sein; es gibt keine Tages- und Nachtschichten für etwaige Wartungsarbeiten, da an einem Standort des Unternehmens immer Tag ist. Es stellt sich daher die Frage, ob es möglich ist, die Ausfallzeiten zu managen. Hinweis
Eine sehr wichtige Tatsache sei vorweg erwähnt: Eine technisch 100 %ige Verfügbarkeit eines Systems ist nicht möglich.
Es gilt also, möglichst nahe an die 100% heranzukommen, wobei der Aufwand moderat bleiben sollte, unter Berücksichtigung eines nahezu exponentiellen Anstiegs, je näher man sich der 100%-Marke nähert. In der Praxis ist es möglich, mit vertretbarem Aufwand an etwa 99 - 99,9% Verfügbarkeit heranzukommen. Kann ein Unternehmen dieses Limit nicht akzeptieren, ist dies ein Grund für den Einsatz einer dezentralen Architektur. Es ist in jedem Fall lohnenswert, alle Optionen zu erörtern und zu hinterfragen, ob, wenn keine anderen Gründe vorliegen, wegen eines kleinen Bruchteils Ausfallzeit eine komplett neue Systemlandschaft aufgebaut und betrieben werden muss. Tabelle 5.3 zeigt eine Hochverfügbarkeits-Skala für ITSysteme mit den dazugehörigen Eigenschaften:14 Verfügbarkeit in %
Ausfallzeit Aktivität pro Woche
Ausfallzeit pro Jahr
Aktivität
99,9999
0,5 sec
26 sec
99,999
6 sec
Wöchentliches Switch-over (*)
5 min
1 Durchstart pro Jahr
99,99
1 min
Tägliches Switch-over
52 min
Eine Wartung im Jahr
Hypothetisch
Tabelle 5.3 Beispielhafte Hochverfügbarkeits-Skala
14 Mehr Details finden Sie in http://service.sap.com/ha.
230
00____1076.book Seite 231 Freitag, 5. Oktober 2007 3:07 15
Betrieb eines SAP-Single-Instance-Systems
Verfügbarkeit in %
Ausfallzeit Aktivität pro Woche
Ausfallzeit pro Jahr
Aktivität
99,9
10 min
Ein Durchstart pro Woche
8 h 45 min
Ein OfflineBackup pro Jahr
99
1 h 40 min
Offline-Software-Wartung
87,5 h
Vierteljährliche Wartung und Einspielen von SupportPackages, , Upgrade, Unicode-Konvertierung
90
16 h 48 min 1 OfflineBackup pro Woche
36 Tage
Wöchentliche Offline-Wartung
5.3
Realistisch
(*) Switch-over: Umschalten auf das Stand-by-System Tabelle 5.3 Beispielhafte Hochverfügbarkeits-Skala (Forts.)
Sie können aus dieser Tabelle erkennen, dass es bei einem pragmatisch-realistischen Ansatz in der Regel ausreichend ist, das System vierteljährlich zu stoppen, um größere Wartungen vorzunehmen, wie den Import von Support-Packages oder sogar ein Upgrade oder die Durchführung einer Unicode-Konvertierung, da die geplante Verfügbarkeit immer noch bei 99% liegt. Heutzutage hat jeder Hardwarehersteller eine passende Hochverfügbarkeitslösung (High Availability, HA) für die jeweilige Plattform, und die SAP-Technologie unterstützt und erweitert ständig das Portfolio an HA-Lösungen für die SAP-Komponenten. Somit kann davon ausgegangen werden, dass eine geeignete HA für das globale SingleInstance-System geplant werden kann. Diesbezüglich sollten die folgenden Fakten berücksichtigt werden: 왘 Vermeidung sogenannter Single Point of Failures (SPOF), also technisch zentraler Komponenten, bei deren Ausfall das ganze System oder große Teile davon betroffen sind. Alle SPOF-Komponenten müssen redunant verfügbar sein. 왘 Einsatz einer HA-Lösung für die Datenbank und den Applikationsserver; es gibt zahlreiche Lösungen auf dem Markt
231
Hochverfügbarkeit
00____1076.book Seite 232 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
왘 Einsatz einer speziellen und sehr sicheren HA-Lösung für die zentrale SAP-Services-Message und den Enqueue-Server, da diese kritische zentrale SPOFs darstellen 왘 Einsatz einer HA-Lösung für gemeinsame File-Systeme 왘 Einsatz von HA-Lösungen mit minimaler Auswirkung auf die Endbenutzer Ausfallzeiten
Es gilt grundsätzlich, zwischen geplanten und ungeplanten Ausfallzeiten zu unterscheiden: 왘 Geplante Ausfallzeiten Unter geplanten Ausfallzeiten verstehen wir Ausfallzeiten, die lange vorher angekündigt werden, um bestimmte Wartungsmaßnahmen am System vornehmen zu können. Gründe für geplante Ausfallzeiten sind beispielsweise das Einspielen von Support-Packages und wichtigen Korrekturen, die Anpassung wichtiger Systemparameter, die im Online-Betrieb nicht erfolgen können, und insbesondere Upgrades auf ein neues SAP-Release; außerdem Migrationen, Unicode-Konvertierungen und andere größere Aktionen, die lange vorbereitet wurden. Die geplanten Ausfallzeiten sind in der Regel weniger kritisch; und es gilt für das globale IT-Supportteam, eine präzise Planung für eine möglichst lange Zeit, etwa ein Jahr, vorzunehmen. In der Praxis erweisen sich vierteljährliche Wochenenden mit Ausfallzeiten als brauchbar. 왘 Ungeplante Ausfallzeiten Ungeplante Ausfallzeiten treten aufgrund plötzlicher und unerwarteter Ereignisse ein. Die Ursache kann ein Systemausfall, eine dringend notwendige Korrektur, aber auch ein gravierender Fehler in der Anwendung sein, der eine Wiederherstellung der Datenbank erforderlich macht, weil zum Beispiel ein Löschreport unzulässigerweise produktive Daten gelöscht hat. Gemäß einer Studie der Gartner Group15 werden ungeplante Ausfälle zu etwa 20% durch Hardwarefehler verursacht, 40% durch betriebliche Bedienungsfehler und 40% durch Anwendungsfehler. Mit modernen Hochverfügbarkeitslösungen und verbesser15 Gartner Group: Gartner Group's Networked Systems Management Research Note QA-05-2701, July 29, 1998, http://www.gartner.com/webletter/ibmglobal/edition2/ article5/article5.html.
232
00____1076.book Seite 233 Freitag, 5. Oktober 2007 3:07 15
Betrieb eines SAP-Single-Instance-Systems
tem Betrieb ist es heutzutage möglich, nahezu jede Art von Systemausfällen ohne Datenverluste und lange Ausfallzeiten zu managen. Problematischer sind die Ausfälle aufgrund von Bedienungsund Anwendungsfehlern, also aufgrund menschlichen Versagens, die zusammen etwa 80% ausmachen. Hinzu kommen unerwartete Notkorrekturen oder andere dringende Gründe, die das Herunterfahren des Systems erforderlich machen. Hier helfen Verbesserungen und Vereinfachungen im SystemManagement mit neuen, einfachen und sicheren Werkzeugen. Zur Verminderung von Anwendungsproblemen sind Ausbildungsmaßnahmen sowie Verbesserungen des Änderungs- und ProblemManagements sinnvoll und nicht zuletzt auch ein guter Endbenutzer-Support. Gute Prävention kann auch mit einer qualitativ hochwertigen Implementierung erfolgen, die zum Beispiel die Ausführung ungewollter Löschreports abfängt. Abbildung 5.1 zeigt eine Übersicht häufig notwendiger Wartungsarbeiten in geplanten Ausfallzeiten, mit ihrer Häufigkeit und der etwaigen Dauer.
Hohe Frequenz Wöchentlich
OfflineBackups mit SplitMirror
Kundenabhängige Aufgaben
Transporte Reparaturen
SAP-abhängige Aufgaben
Transporte kleine Anzahl
Monatlich
ProfileparameterÄnderungen
Technische Änderungen Transporte große Anzahl
Kernel Upgrades
Quartalsweise
Architekturänderungen
Geringe Frequenz
Jährlich Minuten Kurze Dauer
0.5-2 Stunden
Datenbankreorganisationen
SAP Support Packages
ReleaseUpgrades
15-20 Stunden Lange Dauer
Abbildung 5.1 Typische Wartungsarbeiten in globalen Systemen in geplanten Ausfallzeiten
233
5.3
00____1076.book Seite 234 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
5.3.2
Spezielle Empfehlungen zur Reduktion geplanter Ausfallzeiten
Aus der Erfahrung mit vielen Tausend produktiven SAP-Systemen ist bekannt, dass bestimmte, wiederkehrende Aktivitäten und Praktiken das Herunterfahren des globalen Systems erforderlich machen. In etlichen Fällen kann das Herunterfahren aber vermieden werden, indem die optimalen Funktionen und Maßnahmen bei der Systemadministration eingesetzt werden. Diese sind allerdings oft nicht bekannt. Weiterhin entwickelt SAP fortlaufend Verbesserungen und neue Funktionen, um Ausfallzeiten zu reduzieren. Im Folgenden werden einige wichtige Funktionen und Empfehlungen beschrieben, die die Ausfallzeiten reduzieren. Da wir an dieser Stelle nicht alle Methoden und Empfehlungen beschreiben können, verweisen wir den interessiertem Leser an spezielle Dokumentation wie Architecting a High Availability SAP NetWeaver Infrastructure von Matt Kangas.16 Ausgewählte Empfehlungen
왘 Soft Shutdown von Applikationsservern (seit SAP WEB AS 6.20) Ein Applikationsserver kann heruntergefahren werden und laufende Aktivitäten vollständig beenden, aber keine neuen Anfragen entgegennehmen, die auf andere Applikationsserver umgeleitet werden. Damit wird der Applikationsserver »weich« heruntergefahren, ohne den laufenden Betrieb zu stören. 왘 Einsatz von Betriebsarten und Online-Änderung von Systemparametern
Das SAP CCMS (Computer Center Management System) unterstützt schon lange den dynamischen Wechsel der Betriebsarten, in dem sich der Typ von Arbeitsprozessen dynamisch ändern kann. So ist es beispielsweise möglich, entsprechend einem vorgegebenen Zeitprofil die geeigneten Betriebsarten zu wählen, beispielsweise dreimal innerhalb von 24 Stunden zusätzliche Dialogprozesse für je eine Stunde einzuplanen, wenn in den drei Kontinenten AsienPazifik, EMEA und Amerika die lokalen Arbeitszeiten beginnen und es dadurch beim Anmelden am System zu Dialogbetriebsspitzen kommt. Ebenfalls eignen sich die CCMS-Betriebsartenumschaltungen gut für die Einplanung von benötigten Hintergrundprozessen auf einem speziellen Server für lang laufende Hintergrundjobs. Mit der CCMS-Funktionalität können viele SAP16 SAP Professional Journal, March/April 2007 Issue, www.sappro.com.
234
00____1076.book Seite 235 Freitag, 5. Oktober 2007 3:07 15
Betrieb eines SAP-Single-Instance-Systems
Systemparameter im Online-Betrieb geändert werden, ohne dass ein Stoppen des Applikationsservers erforderlich ist; allerdings gilt dies nicht für alle Parameter. 왘 Rolling Kernel Switch Es wird ein neues Verfahren geben, um einen SAP Kernel Patch einspielen zu können, ohne das gesamte System stoppen zu müssen, das heißt, dass während des Austausches des Kernels das SAPSystem verfügbar bleibt. Das Rolling-Kernel-Switch-Verfahren beruht darauf, dass die Applikationsserver nicht gleichzeitig, sondern nacheinander mit neuen Kernel Patches versehen werden. Zu diesem Zweck müssen Kernel Patches verwendet werden, die kompatibel sind. Anschließend kann jeder Applikationsserver einzeln nacheinander heruntergefahren werden, der Kernel ausgetauscht und der Applikationsserver wieder hochgefahren werden. Am Ende sollten alle Applikationsserver die gleiche KernelPatch-Nummer haben. Das Verfahren wird in naher Zukunft freigegeben; der interessierte Leser kann bei SAP anfragen, um weitere Details zu erfahren.17 Abbildung 5.2 zeigt dieses Verfahren anschaulich. Es ist zu beachten, dass dabei der SAP Message und Enqueue Service mit hoher Verfügbarkeit, idealerweise separat, betrieben werden sollte.
Instanz 1
Instanz 2
Instanz 3
Anfangsstatus
Patch x
Patch x
Patch x
Schritt 1
Patch x
Patch x
Patch y
Schritt 2
Patch x
Patch y
Patch y
Schritt 3
Patch y
Patch y
Patch y
Datenbank
Die Instanzen müssen nicht alle gleichzeitig, sondern nacheinander gestoppt werden. Das Gesamtsystem bleibt verfügbar. Die gleichzeitige SoftShutdown-Methode minimiert Störungen.
Central Services MessageService
EnqueueService
Abbildung 5.2 Rolling-Kernel-Switch-Verfahren
17 Siehe http://service.sap.com/patches.
235
5.3
00____1076.book Seite 236 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
왘 Import von Support-Packages mit minimaler Ausfallzeit Um die SAP-Support-Packages, die neben den SAP-Standard-Softwarekomponenten auch die Add-on-Komponenten aus Industrielösungen und Add-on-Länderversionen umfassen, innerhalb der geplanten Ausfallzeit schnell importieren zu können, werden folgende Vorgehensweisen und Techniken empfohlen: SchattenimportMethode
Mit der Schattenimport-Methode werden Support-Packages zunächst ohne Störung des Online-Betriebes in Schattenobjekte importiert; danach wird das System gestoppt, um die Schattenobjekte in die aktiven Objekte zu übernehmen und zu aktivieren. Dies bringt den großen Vorteil, dass die lange Importzeit der Objekte in der Ausfallzeit entfällt. Abbildung 5.3 zeigt dieses Verfahren im Überblick.
Uptime Anfangszustand neue Objekte für Import
aktive Objekte
Schatten import
Downtime
Uptime
Umschaltung inaktiv/aktiv
Endzustand
inaktive Objekte
aktive Objekte
aktive Objekte
obsolete Objekte
aktive Objekte
Legende : Uptime: Paralleler Import der neuen Objekte und Downtime: Import der Data-Dictionary-Objekte und Hauptimport sowie Umschaltung auf die neuen aktiven Objekte Uptime: Bereinigung der alten Objekte Abbildung 5.3 Support-Package-Schattenimport-Verfahren
Viele Aktivitäten und Prüfungen, wie zum Beispiel die Generierung von Objekten, erfolgen einmal pro Support-Package-Queue. Wenn keine anderen Gründe vorliegen, sollten Queues mit möglichst vielen Support-Packages importiert werden, sodass diese Prüfungen nur einmal durchgeführt werden. Dies lässt sich gut mit dem Konzept der vierteljährlich geplanten Ausfallzeit vereinen, da in diesem Zeitraum in der Regel mehrere SupportPackages anfallen. Diese Ausführungen zu den Support-Packages
236
00____1076.book Seite 237 Freitag, 5. Oktober 2007 3:07 15
Betrieb eines SAP-Single-Instance-Systems
gelten in gleicher Weise für andere Packages, die mit gleicher oder ähnlicher Technik installiert werden, zum Beispiel für die ab SAP ERP 6.0 verfügbaren SAP Enhancement Packages.18 왘 Umstellung von Sommer- auf Winterzeit und umgekehrt Falls die Zeitzone des globalen Systems die Sommer- und Winterzeit enthält, ändern sich die Systemzeiten zweimal jährlich um je eine Stunde. Für die Endbenutzer kann das bis zu zwei Stunden Verschiebung bedeuten, wenn auf der Nordhalbkugel auf Sommerzeit und auf der Südhalbkugel auf Winterzeit (oder umgekehrt) umgestellt wird. Während die Umstellung von Winter- auf Sommerzeit in der Regel unkritisch ist und keine Ausfallzeit erfordert, ist es bei der Umstellung von Sommer- auf Winterzeit am sichersten, das System für zwei Stunden zu stoppen. Um die Umstellung zwischen Winter- und Sommerzeit in einem globalen System zu vermeiden, empfehlen wir, die Systemzeitzone UTC (Universal Time Coordinate) zu wählen, die keine Winter- und Sommerzeit hat, sodass diese Problematik nicht besteht. Weitere Details hierzu finden Sie in Abschnitt 4.5.2, »Zeitzonen«. Kommt dies nicht infrage, und auch nicht die Nutzung dieser geplanten Ausfallzeit für Wartungsaktivitäten, kann ab SAP WEB AS 6.40 der Einsatz einer neuen Technik in Erwägung gezogen werden. Während beim Übergang von Sommer- auf Winterzeit innerhalb von zwei Stunden die »doppelte Stunde« (meistens nachts zwischen 2:00 h und 3:00 h) zweimal abläuft, läuft die Uhr des SAPSystems mit halber Geschwindigkeit und dadurch um nur eine Stunde weiter. Der Zeitsprung nach hinten wird dadurch vermieden. Die Abweichung zwischen der Uhrzeit des SAP-Systems und der offiziellen Uhrzeit steigt in der ersten Stunde auf -30 min an, springt dann auf +30 min und geht in der zweiten Stunde auf 0 min zurück. Die Werte, zum Beispiel der SAP ABAP-Systemzeit (Felder SY-UZEIT/SY-DATUM) entsprechen also während dieses Übergangs nicht der offiziellen Uhrzeit. Voraussetzungen und weitere Details hierzu finden Sie im SAP-Hinweis 7417 und Referenzen.
18 Siehe http://service.sap.com/erp.
237
Sommer- und Winterzeit
5.3
00____1076.book Seite 238 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
5.3.3
Auslastung und Jobverarbeitung
Hohe Dauerlast rund um die Uhr
Ein weiteres, sehr wichtiges Thema bei einer globalen SingleInstance-Lösung ist die Frage, wie die hohen Lasten der Jobverarbeitung (Hintergrundverarbeitung) mit der Dialogverarbeitung der Endbenutzer zusammenpassen. Da es bei einem 24 x 7-Betrieb rund um den Globus keine Nacht gibt, in der üblicherweise ressourcenintensive Hintergrundjobs und ähnliche Verwaltungsaktivitäten eingeplant werden können, müssen spezielle Maßnahmen getroffen werden, um die Dauerbelastung aus Dialogarbeit und Hintergrundjobs zu managen.
Strikte Zeitfenster für die Jobverarbeitung
Es hat sich in der Praxis gezeigt, dass sich erfolgreiche globale SingleInstance-Kunden immer an eine strikte Planung mit vorgegebenen Zeitfenstern halten, die für die Jobverarbeitung auch eingehalten werden müssen. Zunächst muss herausgefunden werden, wie die etwaige Lastverteilung innerhalb von 24 Stunden für Dialog- und Hintergrundbetrieb aussieht. Daraus können dann entsprechende Maßnahmen abgeleitet werden. Abbildung 5.4 zeigt ein Beispiel einer typischen Lastverteilung bei einem angenommen globalen Single-Instance-System mit Endbenutzern in Amerika, EMEA und Asien: 160
Virtuelle CPU-Last
140 120 100 80 60 40 20 0 01
02
03
04
05
06
07 08
09
10
11
12
13
14
15
16
17
18
19 20
21
22
23
24
01
02
Zeit in MEZ
Asien Dia
Asien Batch
Europa Dia
Europa Batch
Amerika Dia
Amerika Batch
Laufzeit der Hintergrundjobs (Zeitfenster): ca. 5-6 Stunden Ca. 66% Resourcenverbrauch durch die Hintergrundjobs
Abbildung 5.4 Beispiel einer CPU-Lastverteilung für Dialog- und Hintergrundbetrieb (Batch) in 24 Stunden Empfehlungen für die Jobverarbeitung
Wie Sie erkennen, müssen etwa drei Zeitfenster von bis zu ca. sechs Stunden für die Hintergrundjobs (Batch) pro Kontinent/Region eingeplant werden, was bedeutet, dass die Hintergrundjobs Zweidrittel
238
00____1076.book Seite 239 Freitag, 5. Oktober 2007 3:07 15
Betrieb eines SAP-Single-Instance-Systems
5.3
eines Tages laufen und somit etwa 66% der CPU beanspruchen. Folgende allgemeine Empfehlungen, wie dies zu managen ist, haben sich bei realen globalen Single-Instance-Systemen bewährt: 왘 Strikte Organisation und Einplanung der Hintergrundjobs in den gegebenen Zeitfenstern. Eventuell ist es sinnvoll, ein externes Job-Management-System einzusetzen. 왘 Einsatz zeitabhängiger SAP CCMS-Betriebsarten, um zu bestimmten Zeiten mehr oder weniger Hintergrund-Workprozesse zu konfigurieren 왘 Ein oder mehrere separate Applikationsserver für ausschließlichen Hintergrundbetrieb 왘 Einsatz der Adaptive-Computing-Technologie, um in Zeiten von Spitzenlasten zusätzliche Hardware-Ressourcen dynamisch dazuzuschalten 왘 Analyse und Tuning der Programme für den Hintergrundbetrieb: Oft laufen die Hintergrundjobs unnötig lang, weil das Design oder die Selektionsparameter ungünstig gewählt sind; oder es handelt sich um Eigenentwicklungen, die nicht performant programmiert wurden und viel Tuning-Potenzial haben.
5.3.4
SAP Solution Manager
Um den laufenden Betrieb allgemein effizient zu unterstützen, eignet sich der Einsatz des SAP Solution Managers.19 Mit zahlreichen Funktionen, wie Systemüberwachung und Service-Desk für den BenutzerSupport ist er gut dazu geeignet, die globale Lösung optimal zu unterstützen und dabei zu helfen, Ausfallzeiten zu reduzieren. Weitere wichtige Funktionen sind das Änderungsmanagement und das Test-Management, das gut dazu geeignet ist, den Aufwand bei wiederkehrenden Wartungsarbeiten, wie Import von Support-Packages, zu reduzieren, indem ein zentrales Test-Management zusammen mit automatisierten Testwerkzeugen (z.B. SAP eCATT, also extended Computer Aided Test Tool oder Mercury Loadrunner20) realisiert werden kann. Der SAP Solution Manager folgt den ITIL-Standards für ITService- und Applikationsmanagement und kann dadurch gut als 19 Siehe Matthias Melich, Marc O. Schäfer: SAP Solution Manager. SAP PRESS 2006; sowie http://service.sap.com/solutionmanager. 20 Siehe http://www.mercury.com für Details.
239
Generalwerkzeug für den Support
00____1076.book Seite 240 Freitag, 5. Oktober 2007 3:07 15
IT-Realisation der Architektur
Werkzeug in die Service und Supportprozesses des Rechenzentrums integriert werden. Abbildung 5.5 zeigt die Funktionen des SAP Solution Managers im Überblick.
Implementierung von SAP-Lösungen
Lösungsüberwachung
Imple
KERNGESCHÄFTS-
trieb
Upgrade von SAP-Lösungen
g iun nt Be
m e
SAP-Methoden und -Tools Globales Roll-out Synchron. Customizing E-Learning-Management Testmanagement
Systemüberwachung Geschäftsprozessüberwachung Zentrale Systemadministration EarlyWatch Alert/SL-Reporting Lösungs -Reporting
PROZESSE
SAP-Methoden und -Tools E-Learning-Management Testmanagement
Optimierun g
5
Service Desk Best Practices für Nachrichtenübermittlung Integration von Help Desks anderer Anbieter Solution Manager Diagnostics
Verwaltung von Änderungsanträgen
Bereitstellung von SAP-Services
Nach ITIL-Standards Wartungsprozesse
Vor Ort oder Remote SAP Safeguarding
Abbildung 5.5 SAP Solution Manager im Überblick
Natürlich gibt es noch viele weitere Aspekte, die bei der Planung und dem Betrieb einer globalen Single-Instance-Lösung eine wichtige Rolle spielen. Diese jedoch alle detailliert zu beschreiben, würde den Rahmen dieses Buches sprengen. Der interessierte Leser sei an die zahlreiche Spezialliteratur zu diesen Themen im SAP Service Marketplace unter http://service.sap.com und im SAP Developer Network unter http://sdn.sap.com verwiesen.
5.4
Realisierung globaler SAP-Projekte mit der gewählten Architektur
Neben der wichtigen Frage nach dem Betrieb einer Single-InstanceLösung stellt die Planung und Implementierung globaler Projekte hohe Anforderungen an das IT-Team. Wir beschreiben in diesem
240
00____1076.book Seite 241 Freitag, 5. Oktober 2007 3:07 15
Realisierung globaler SAP-Projekte mit der gewählten Architektur
5.4
Abschnitt die Einrichtung einer geeigneten Customizing- und Entwicklungsumgebung für ein globales Projekt, geeignete Vorgehensweisen zur internen Release- und Projektplanung bis zur bewährten Global-Template-Vorgehensweise für den Konzern-Roll-out.
5.4.1
Entwicklung und Konfiguration in globalen Systemen
Ein sehr wichtiger Faktor für die geeignete Architektur ist die Frage, wie die globale Lösung hinsichtlich Entwicklung und Customizing implementiert und gewartet wird. In Kapitel 3 haben wir bei der Beschreibung der verschiedenen Architekturen bereits wichtige Aspekte erörtert und gesehen, dass es selbst bei einer dezentralen Architektur Möglichkeiten gibt, die Entwicklung und das Customizing, zumindest teilweise, zentral einzurichten.
Komplexe und umfangreiche Entwicklung in globalen Projekten
In der Praxis kommt es immer wieder vor, dass große globale Unternehmen klagen, wie unübersichtlich die gesamte globale IT-Lösung nach mehreren Jahren geworden sei; es gebe weder eine komplette Dokumentation, noch Personen, die einen Überblick über alle produktiv genutzten Entwicklungen haben. Die Folge ist, dass viele Tausend eigene Kundenentwicklungen entstehen und gewartet werden müssen, die meist unabhängig voneinander sind und oft funktionale Redundanzen aufweisen. Es stellt sich daher die Frage, ob auch bei einer dezentral orientierten Architektur neben der dezentralen Entwicklung noch eine zentrale Entwicklung möglich ist. Bei der Entwicklung und der Konfiguration in einem SAP ERP-System stellt sich immer wieder die Frage, wie viele und für welche Zwecke die SAP-Mandanten benötigt werden. Diesbezüglich gibt es keine perfekte Lösung, da die Ausprägung sehr von den individuellen Anforderungen, der Organisation der Entwicklungs- und Konfigurations-Projektteams und der definierten Prozesse abhängt. Die folgende Empfehlung gilt für die Annahme, dass die Entwicklungsund Konfigurationsarbeit zentral koordiniert wird und den allgemeinen SAP-Empfehlungen für eine Drei-Systeme-Transportlandschaft mit einem DEV-System für Entwicklung und Customizing, einem QAS-System für Konsolidierung und Test und einem PRD-System für den Produktivbetrieb sowie potenziell weiteren Systemen für Training, Sandbox, usw. folgt.
241
Drei-SystemeTransportlandschaft und Mandantenkonzept
00____1076.book Seite 242 Freitag, 5. Oktober 2007 3:07 15
5
IT-Realisation der Architektur
Korrekturen können im Notfall direkt im PRD- oder QAS-System gemacht werden, müssen aber immer im DEV-System nachgezogen werden, damit stets das Ursprungsprinzip gilt, das heißt, dass für jedes Entwicklungsobjekt immer nur genau eine zentrale neueste Version gewartet werden soll, sodass es keine Inkonsistenzen mit verschiedenen Versionen gibt. Dies hört sich sehr plausibel und einfach an, ist aber in der Praxis in einem großen globalen Projekt mit bis zu vielen Tausend Entwicklungsobjekten nicht einfach umzusetzen und bedarf daher einer guten Planung. Die folgenden Empfehlungen für die Mandantenkonfiguration und benutzung gelten primär für eine zentrale Architektur, können aber leicht auf jede andere übertragen werden. Es sei ausdrücklich darauf hingewiesen, dass das Mandantenkonzept nur für ABAP-Entwicklungen und -Anwendungen geeignet ist, da bei Java-basierter Entwicklung und Konfiguration andere Vorgehensweisen gelten, auf die wir hier nicht näher eingehen und den interessierten Leser auf Dokumentation und weiterführende Literatur verweisen, zum Beispiel: Karl Kessler, Peter Tillert, and Panayot Dobrikov: Java Programming with the SAP Web Application Server, SAP PRESS, 2005. Abbildung 5.6 zeigt ein typisches Mandantenkonzept für eine zentrale Architektur der globalen Lösung.
DEV
PRD
QAS
Rückführung nach DEV von direkten oder Notkorrekturen Gold-Mandant
Gold Test
Gold-Backup
Integrationstest
Einheitstest
Dokumentation
ABAP und mandantenunabhg. CustomizingVorbereitung
Produktion
Übersetzung Trainingsvorlage Trainingsmandant
Sandbox Support
Support RDBMS
Support RDBMS
Abbildung 5.6 Mandantenkonzept in einer globalen Systemlandschaft
242
RDBMS
00____1076.book Seite 331 Freitag, 5. Oktober 2007 3:07 15
Index 24 x 7-Betrieb 214, 220 24-Stunden-Support 181 64-Bit-Strategie 217
Auslastung 238 Auslastung und Jobverarbeitung 220 Availability-Management 189
A
B
ABAP-Textpooleinträge 67 absolute Zeit 75 Adaptive Computing 144, 216 Add-on 197, 200, 211 Add-on-Länderversionen 201 Adressversionen 73 ALE 31, 91, 319 ALE-Verteilungsmodell 31 Änderungskonzept, dreistufiges 255 ANSI 319 Anwendungen, multilinguale 192 API 319 Applikationsserver 319 Architektur dezentrale 100 Hybridarchitekturen 145 Kombination 148 lokale und vollständig verteilte dezentrale 105 regionale mit Shared Services 114 Überblick 83 Varianten 145 verteilte 90 vollständig dezentrale 114 zentrale 90, 128, 133 zentralisierte dezentrale 124, 128 Archivierung 298 ARIS for NetWeaver-Plattform 169 ASCII 320 asiatische Zeichensätze 55 asynchron 27 asynchrone Übertragung 319 Auffüllsprache 63, 71 Ausfallrisiko 281 Ausfallzeiten 109, 220, 230 geplante 232 ungeplante 232 Ausgliederung 268
Backup 319 Bandbreite 319 BAPI 32 Batch 319 BDC 319 Benutzerzeit 17 Benutzerzeitzone 75 BIDI 319 Big Endian 319 Binärdatei 319 BOM 319 BPEL4WS 170 Branchenlösungen 39 BTF 319 Business Address Services 73 Business Blueprint 173 Business Cluster 306, 308, 309, 310, 311 Business Process Management (BPM) 167, 169 Business Process Monitoring 172 Business-Systeme 99 Byte 319 Byte-swapped 319
C Capacity-Management 189 Case lower 319 upper 319 CBL 319 Central European Time 75 Central Single Instance 130 CGI 319 Change-Management 158, 188 Character Composition 55 Character Encoding Form 320
331
00____1076.book Seite 332 Freitag, 5. Oktober 2007 3:07 15
Index
Character Encoding Scheme 320 Character Set 320 Citrix Terminal Server 137, 226 CJK 320 CJKV 320 Client-Server-Architektur 84 Client-Server-Konzept 27 Cluster-Technik 274 Codepage 88, 320 Codepoint 51 Connectivity 79 Continuity-Management 189 Conversion Workbench (CWB) 272, 273, 274, 275 Corporate Governance 175 Kennzeichen guter 176 Country Advocate 48 CPU 320 CPU-Lastverteilung 238
D Datenhaltung, redundante 112 Datenübertragung 76 DBCS 320 Dezentrale Architektur 287, 288 Dezentrale Architektur mit Shared Services 293 DIMM-Modul 228 Disaster Recovery Center 130, 183 Dokumentation der Länderversionen 48 Double Byte 55 Double Byte Character Set 320 Drei-Dimensionen-Modell der Globalisierung 155, 159, 162, 210 dreistufige Konfiguration 28 Drei-Systeme-Transportlandschaft 95 Drucken, multilinguales 228 Druckerinfrastruktur 227, 228
E eCATT 239, 320 EDIFACT 320 Eigenentwicklungen, redundante 112 Eingliederung 269 Einmandantensystem, zentrales 129
332
Encoding Form 320 Encoding Scheme 320 Enterprise Models 22, 35 Enterprise SOA 19, 89 Enterprise-Architekten 166 Entscheidungsmatrix 279, 312 Entwicklung 241, 244 ERP-Software 317 ESA 19 EUC 320 Expansion 204 externe Zeit 75
F Failover 320 Financial-Management für IT-Services 189 Firmenzusammenschlüsse 13 Follow-the-Sun-Modell 181 Font 320 Font Cartridges 228 Font-Zusätze 225 FTP 320
G German ASCII 320 Gesamtkapitalrentabilität 23 Geschäftsmatrix 305 Geschäftsprozesse 163 Geschäftsprozessmodellierung 164 Geschäftsprozess-Plattform 34 GKB 44 Global ASAP 257 Global Template 253, 257, 321 Global Template Roadmap 258 globaler Service und Support 180 globaler Zeichensatz 54 Globalisierung 15, 156 Global-Template-Ansatz 113, 254 Global-Template-Konzept 256 Glyphe 321 GMT (Greenwich Mean Time) 75 GUI 321
00____1076.book Seite 333 Freitag, 5. Oktober 2007 3:07 15
Index
H Hangul 321 Hardwareanforderungen 80 Hardwarekonsolidierung 216 Hochverfügbarkeit 220, 230, 231 homogene Kommunikation 78 horizontale Integration 103 Hosting-Services 183 HTML 321
I IDoc 32, 79, 321 Implementierung neuer Länder 259 und Entwicklung 97 Incident-Management 188 Industrielösungen 197 Industrieversionen 39 inhomogene Kommunikation 78 Installation neuer Länder manuelle Vorgehensweise 263 Integrationsszenarien, komplexe 125 Interface 321 Internationalisierung 15 interne Zeit 75 Internet 32 Internet Transaction Server 321 ISCII 321 ISO 321 ISO 8859 56 ISO/IEC 10646 58 ITIL 183, 187 IT-Infrastruktur 218
Katakana 321 Key Performance Indicators 168 Konfiguration 241, 244 Konsolidierung 270 dezentraler SAP-Systemlandschaften 267 Konzern-Roll-out 253 Konzernsprache 178 Kopplung 104 Kostenrechnungskreis-Zusammenführung 270 KPI 23 Kryptographie 321 Kundenszenario 279 dezentraler Ansatz mit Einzelsystemen 288 Single Box 281 verteilte Systeme mit Integration und Konsolidierung 291
L
J2EE 321 JDBC 321 Jobverarbeitung 238
Länder-Cluster 209 Länderinstallation 263 Länderinstallationsprogramm 261 Länderversion 40, 203, 204, 281 Aktivierung 262 Ländervorlage 41 Latenz 321 LATIN-1-Zeichensatz 54 Latin-4 322 Lebenszyklus-Prozesse 97 Little Endian 322 Load Balancing 28, 322 Logische Systeme 99 lokale Verhaltensweisen und Traditionen 178 Lokalisierung 15 lose Kopplung 104 Lösungslandschaft 95, 96 LSB 322
K
M
Kanji 321 Kapitalrendite 23
Mainframes 83 Mandant 98
J
333
00____1076.book Seite 334 Freitag, 5. Oktober 2007 3:07 15
Index
Mandantenkonzept 242, 243 Mandantenzusammenführung 270 manuelles Übersetzen von Customizing 73 Markup 322 Materialnummernumstellung 270 MBCS 322 MDMP 57 Mehrmandantensystem 98 Einschränkungen 131 zentrales 129, 130 Mercury Loadrunner 239 Message Broker 322 Message Queuing 322 Middleware 78, 322 Migration Workbench (MWB) 273 Modellierung 22 Modellierungsstrategie 23 Moore’s Law 85 MSB 322 Multi Byte Character Set 322 Multibyte 55
P Patch 322 PCL 322 Performance 144 Plain Text 322 Plattform geeignete 217 Release-Abhängigkeit 218 Portal 322 Problem-Management 188 Produktivbetrieb 97 Projektmanagement 24 Prozess Prozessausführungsmodell 170 Prozessebenen 170 Prozessintegration 124, 165 Prozesskonfiguration 165 Prozesskonfigurationsmodell 170 Prozessverantwortung 165
Q N Netzwerkanbieter Auswahl geeigneter 224 Netzwerke 85 Netzwerkinfrastruktur 87 Netzwerklatenz 87, 224, 322 Netzwerk-Sizing 220, 223 NNTP 322
O Objektzeit 17 Octet 322 ODBC 322 Order Line Items 221 Organisationseinheiten einrichten 41 Ortszeit 75 OS 322
334
quasi-globale Architektur 245 Quick Sizer 221
R RAID 322 RAM 323 Rechenzentrum 182 Anforderungen, allgemeine 214 Dienstleister 183 Reengineering 24 regionale Supportzentren 181 Release-Management 188, 248, 249 Release-Stände 112 Release-Strategie 248 Reporting 124, 138 Retrofit 201 RFC 79, 323 Rich Text 323 RMI 323 Roadmap 303 RoI 23 Rolling Kernel Switch 235
00____1076.book Seite 335 Freitag, 5. Oktober 2007 3:07 15
Index
Roll-out, globaler 253 Roll-out, phasenweise 256 RSREFILL 71
S SAP Business Suite 92, 95, 99 SAP CCMS 234 SAP CEE-Add-on 202 SAP Country Version 16 SAP Enterprise Extension Sets 198 SAP ERP-Länderversionen 199 SAP Globalization Knowledge Base 44 SAP-Industrielösungen 198 SAP-Mandant 98, 241 SAP NetWeaver 33, 169, 216 SAP NetWeaver BI 220 SAP NetWeaver Master Data Management 95 SAP NetWeaver Mobile 95 SAP NetWeaver PI 95, 170 SAP NetWeaver Portal 95 SAP Plattform Availability Matrix (PAM) 217 SAP R/3 84 SAP-Referenzmodelle 172 SAP-Release-Strategie 196 SAP SLO Migration Workbench (MWB) 272 SAP-Software 211 SAP Solution Manager 95, 118, 171, 172, 173, 174, 239, 240, 257, 258 Referenzprozesse 172 SAP-Sprachpaket 62 SAP-Sprachunterstützung 57 SAP-Standard-Systemlandschaft 96 SAP Support Package 67 SAPS 221, 323 SBCS 323 Schattenimport-Methode 236 Schnittstellen 111, 122, 287, 293 Script 323 SE63 66 Server-Sizing 220, 221 Service Delivery 188 Service-Desk (Helpdesk) 188
Service Level Agreements (SLA) 162, 183, 184, 185 Service Level Management 189 Service Level Requirements 186 serviceorientierte Architektur 18, 323 Service-Support 188 SGML 323 Shared Services 114, 293 Shared-Services-Architektur 123 Shared-Services-Systeme 115, 118 globales Entwickungssystem 116 globales Stammdatenpflegesystem 116 Shift-JIS 323 Single-Codepage-System 83 Single Instance 29, 218, 219, 220, 229, 272, 280, 281, 300, 307 kritische Aspekte 220 Single Instance ERP 130 Single-Instance-Lösung 215 Single-Instance-System 89, 129 Single Point of Failures 231 Sizing 323 SJIS 323 SLO 323 SLO Conversion Workbench 270 SMLT 66, 68, 70 SOA 18, 323 Soft Shutdown 234 Software für globale Lösungen 191 Sommer- und Winterzeit 237 SPAM 67 Spin-offs 13 Split 22 sprachabhängige Objekte 64 sprachabhängiges Customizing 69 Sprachen 17, 191 Sprachen-CD 67 Sprachgruppe 88 Sprachimport 63 Sprachkombinationen 192 Sprachunterstützung, technische 191 SQL 323 Stammdatenpflege, globale 121 Standard-Länderversion 43 Standards, globale 180 starke Kopplung 104 Storage Area Network 216
335
00____1076.book Seite 336 Freitag, 5. Oktober 2007 3:07 15
Index
Strategie definieren 303 Supportorganisation 180 Supportorganisation, globale Anforderungen an 182 Support-Packages, Import von 236 Supportzentren, regionale 181 Switch-Framework-Architektur 198 synchron 27 synchrone Übertragung 323 System Landscape Optimization Services (SLO) 265, 266 Systemarchitektur 155, 280 System-Codepage 51, 56 Systemkonsolidierung 272 Systemlandschaft 99 Systemtopologie 22, 90 historische Entwicklung 280 Systemzeit 17
T TCP/IP 324 Template 305, 323 Template-System 245 Topologien 92 Transportlandschaft 95, 245, 247 TREX 95
U Überprüfung des Unternehmensmodelles 25 Übersetzung 281 Übersetzungsstrategie 62 Übersetzungs-Workbench 66 Übertragung asynchron 319 synchron 323 UCS 324 Umstrukturierung 269 Unicode 108, 193, 205, 218 Unicode Encoding Forms 324 Unicode Encoding Schemes 324 Unicode Transformation Format 324 Unicode-Codepage 58 Unicode-Drucker 227
336
Unicode-Standard 58 Unicodesysteme 17 Unternehmenskultur, globale 177 Upgrade 140 UTC 75 UTF 324 UTF-16 60 UTF-8 60 UUEncode 324
V Verfügbarkeit 230 Versagen, menschliches 141 Versionierungskonzept 253 verteilte Architektur 290 verteilte Systeme 29 Verteilung globaler und lokaler Funktionen 38 vertikale Integration 104 Voice over IP 324 Vorschlagspool 63
W W3C 324 Währungen 16 Wartung 97, 220, 233 Windows Terminal Server 226 WML 324 Workstation-Infrastruktur 225 WSDL 324
X XBRL 324 XHTML 324 XML 324
Z Zeichensatz 51, 191, 205 Zeitzonen 17, 193, 195 Zeitzonenanforderungen 74 Zentralisierung, vollständige 131
