SAP HANA – Administration · SAP HANA ist seit der ersten Version der Datenbank als Multi-Node-Verfügbarkeit System verfügbar und wird kontinuierlich weiterentwickelt. Im Gegensatz

163

Kapitel 4

Keine zwei Systemlandschaften sind gleich. Da die individu-ellen Anforderungen bestimmen, welche technischen Kom-ponenten zum Einsatz kommen und wie diese eingesetzt werden, beschreibt dieses Kapitel die unterschiedlichen Rahmenbedingungen, unter denen SAP HANA betrieben werden kann, und welche Optionen Systemarchitekten unter diesen Bedingungen zur Verfügung stehen.

4 Betriebskonzepte

Zusammen mit der Produkteinführung von SAP HANA ist neben derSoftware selbst auch das sogenannte Appliance-Konzept von SAP ein-geführt worden. Mit diesem Konzept wurde der Betrieb von SAPHANA auf Server eingeschränkt, die bestimmte Konfigurations- undLeistungsmerkmale erfüllen und nach diesen Kriterien zertifiziertsind. Neben den Hardware- und Softwarebeschränkungen hat SAPauch die unterstützten Installationsvarianten auf eine SAP-HANA-Instanz pro Server eingeschränkt, um eine gleichbleibend hohe Per-formance und eine hohe Kompatibilität zu erreichen.

Von der Appliance zu verschiedenen Betriebskonzepten

In den letzten Jahren hat SAP jedoch die Notwendigkeit weitererBetriebskonzepte erkannt, um die unterschiedlichen Anforderungender Kunden abzudecken. In diesem Rahmen wurden die Beschrän-kungen für verschiedene Szenarien gelockert oder aufgehoben.Zusätzlich sind weitere Konzepte wie Cloud-Services und Multi-Tenant-Architekturen hinzugekommen, um auch neuartige Szena-rien realisieren zu können.

In diesem Kapitel stellen wir Ihnen die unterschiedlichen Arten vonBetriebskonzepten vor und erklären, für welche Szenarien welcheKonzepte sinnvoll sind. Zur besseren Übersicht gliedern wir dasKapitel in zwei Abschnitte zum Landschaftsaufbau und zu den Instal-lationsvarianten. Im ersten Abschnitt beschreiben wir die unter-schiedlichen Hardwaretypen, auf denen SAP-HANA-Systeme betrie-ben werden können, und gehen darauf ein, welche Auswirkungendiese verschiedenen Hardwaretypen haben. Im zweiten Abschnitt

4 Betriebskonzepte

164

des Kapitels erläutern wir die verschiedenen Installationsvariantenvon SAP HANA, durch die unterschiedliche Anforderungen erfülltwerden können.

4.1 Landschaftsaufbau

Der Landschaftsaufbau, d. h., welche Hardwarestruktur für denBetrieb von SAP HANA genutzt wird, ist ausschlaggebend für denAufwand bei der Konfiguration und beim Betrieb sowie für die Fle-xibilität und die Wachstumsmöglichkeiten des Systems. Für den spä-teren Betrieb ist es daher wichtig, das für den Anwendungsfall besteSetup auszuwählen.

4.1.1 Appliances

SAP HANA in derBlack Box

Der gängige Weg, eine SAP-HANA-Datenbank zu betreiben, ist alssogenannte SAP HANA Appliance. Als Appliance bezeichnet SAP einezertifizierte Kombination von Hardware und Software, die alsbetriebsfertige Black Box ausgeliefert wird, wie in Abbildung 4.1 ver-anschaulicht. Bei dieser Betriebsvariante wird die Konfiguration zuweiten Teilen von SAP vorgegeben. Die Vorgaben decken Hardware,Betriebssystem, die installierten SAP-HANA-Komponenten undandere Software ab, die auf dem Server installiert sein darf. EineAnpassung der Konfiguration an spezifische Anforderungen vonKunden ist bei diesem Konzept nicht vorgesehen; man hat aus-schließlich die Wahl zwischen Servern mit unterschiedlichem Sizing.Pro Appliance ist nur eine SAP-HANA-Datenbank vorgesehen.

Die Appliance-Server werden von den verschiedenen Hardwareher-stellern anhand fester Spezifikationen erstellt und von SAP zertifi-ziert. Damit wird sichergestellt, dass SAP-HANA-Systeme, die aufAppliance-Servern laufen, ein von SAP definiertes Minimum an Per-formance bereitstellen. Als Betriebssystemvarianten kommen ange-passte Versionen von SUSE Enterprise Linux (SLES) oder Red HatEnterprise Linux (RHEL) zum Einsatz.

Verfügbare SAP HANA Appliances

Eine Übersicht über alle verfügbaren SAP-HANA-Appliance-Server kön-nen Sie unter http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/appliances.html einsehen.

Landschaftsaufbau 4.1

165

Abbildung 4.1 Single-Node Appliance

Vorgaben für Appliance-Server

Für die Appliance-Server gelten im Wesentlichen die folgenden Vor-gaben:

� Central Processing Unit (CPU)Für den produktiven Betrieb ist ein bestimmtes Verhältnis vonProzessorkernen zu Arbeitsspeicher vorgegeben, sodass eine Min-destmenge an Rechenressourcen zur Verfügung steht. Das Verhält-nis hängt von der Prozessorarchitektur und dem Einsatzweck ab.Neuere Architekturen arbeiten effizienter, dementsprechend setztSAP bei diesen Architekturen weniger Prozessorkerne pro GBArbeitsspeicher voraus. Für die SAP Business Suite auf SAP HANA(SAP ERP, CRM, SRM, SCM und PLM) wird ein kleinerer Wert fürdas Verhältnis zwischen Prozessorkernen und Arbeitsspeicher vonSAP vorgegeben, da in solchen Systemen üblicherweise vieleDaten gespeichert, aber nicht alle gleichzeitig verarbeitet werden.Für SAP-Business-Suite-Systeme auf HANA werden daher spezielleAppliance-Server angeboten.

� Random Access Memory (RAM)Appliances, die für den produktiven Einsatz vorgesehen sind, sindmit mindestens 128 GB Arbeitsspeicher ausgestattet. Die maxi-male Hardwareausstattung für Single-Node-Systeme liegt bei 2 TB.Für SAP-HANA-Systeme, die als Datenbank für ein SAP-Business-

SAP-zertifizierter Server

SLES/RHEL-Betriebssystem

SAP-HANA-Datenbank

lokale Festplatte

4 Betriebskonzepte

166

Suite-System (z. B. SAP ERP oder SAP CRM) laufen, existieren spe-zielle Server mit bis zu 6 TB Arbeitsspeicher.

Neben Prozessor und Arbeitsspeicher, die ausschlaggebend für diemaximale Größe der SAP-HANA-Datenbank, die auf dem Server in-stalliert werden kann, sind, werden auch alle anderen Komponentenfür die Appliance-Server vorgegeben. So verfügen diese über meh-rere 10-GBit-Ethernet-Netzwerkanschlüsse für die Konnektivität so-wie über Flash- und Festplattenspeicher als Persistenzschicht. EineAnbindung an ein Storage-Area-Network-System (SAN) ist im Appli-ance-Konzept nicht vorgesehen, sondern dem Tailored-Data-Center-Ansatz (TDI) vorbehalten, den wir in Abschnitt 4.1.4 beschreiben.

UnterstützteBetriebssysteme

Zurzeit werden zwei verschiedene Linux-Distributionen als Betriebs-systeme unterstützt: SUSE Enterprise Linux 11/12 und Red HatEnterprise Linux 6. Die Auswahl hängt, wie die aller anderen Kom-ponenten, von dem gewählten Appliance-Server ab.

KompatibleInstallations-

varianten

Auch wenn Appliance-Server für Single-Database-System-Installatio-nen, d. h. für Installationen mit einer einzigen SAP-HANA-Daten-bank auf einem Server (siehe Abschnitt 4.2.1, »Single-Database-System«), vorgesehen sind, können alle in Abschnitt 4.2, »Installati-onsvarianten«, genannten Installationsvarianten auf Appliance-Ser-vern eingesetzt werden. Es ist allerdings zu beachten, dass für dieInstallation eine SAP-Zertifizierung notwendig ist (siehe auchAbschnitt 4.1.4, »Tailored Data Center Integration«).

Appliance-Systeme sind unabhängig von der genutzten Installations-variante insbesondere für mittelgroße, produktive Systeme gedacht,bei denen eine berechenbare Leistung erforderlich ist. Durch diestarke Standardisierung und Zertifizierung der Systeme sind sowohldas Setup als auch der Betrieb weniger komplex als bei Lösungen, dieindividueller zusammengestellt werden.

Vor- und Nachteile Das Konzept des Appliance-Servers bringt sowohl Vor- als auchNachteile mit sich, die bei der Konzeption einer Systemlandschaft indie Planung mit einbezogen werden müssen:

� Vorteile:

– Die Performance der Datenbank kann sehr genau abgeschätztund garantiert werden.

– Probleme oder Fehler können durch das homogene Setup leichtidentifiziert werden.


167

– Der Kunde muss sich nicht um das Setup und die Konfigurationder einzelnen Komponenten kümmern, sondern bekommt eineBlack Box mit klar definierten Leistungsparametern.

� Nachteile:

– Es gibt nur ein eingeschränktes Angebot an Appliances.

– Kundenspezifische Anpassungen, wie z. B. eine proportionaleVergrößerung des Arbeitsspeichers, sind nicht möglich.

– Durch die notwendige Zertifizierung der verschiedenen Appli-ances liegt der Preis höher als für vergleichbar ausgestattete Ser-ver, die individuell konfiguriert werden.

– Eine Integration der Appliance-Systeme in bestehende System-landschaften ist, je nach bestehender Infrastruktur, nicht immerohne Weiteres möglich (z. B. bei vollständig virtualisierten Sys-temlandschaften).

Insgesamt muss von Fall zu Fall entschieden werden, ob ein SAP-HANA-System auf einem einzelnen Appliance-Server betrieben wer-den soll oder ob eine individuellere Lösung besser passt. Bei derAnschaffung müssen Sie entsprechend die verschiedenen Vor- undNachteile abwägen. Darüber hinaus sollten Sie für den Betriebberücksichtigen, welche Komponenten der Appliance unter welchenVoraussetzungen durch SAP, den Hardwarehersteller oder Sie alsKunden geändert werden dürfen.

Informationen zu Rollen und Verantwortlichkeiten

Eine Übersicht über die generelle Aufteilung von Rollen und Verantwort-lichkeiten einer SAP HANA Appliance finden Sie unter http://help.sap.com/saphelp_hanaplatform/helpdata/en/e2/43909cbb571057a135a7faa61d61f4/content.htm. Beachten Sie, dass sich diese abhängig von denSupport-Verträgen ändern können.

Um Verwirrung bezüglich der Verantwortlichkeitsbereiche zu vermeiden,sollten diese bei der Anschaffung klar definiert werden.

Hinweise zu Konfigurationsänderungen

In den SAP-Hinweisen 1730999 und 1731000 finden Sie die empfohle-nen bzw. nicht empfohlenen Konfigurationsänderungen für SAP HANAAppliances.

4 Betriebskonzepte

168

Auch wenn SAP HANA Appliances als einzig verfügbare Betriebskon-zeptvariante zum Start von SAP HANA viel Kritik wegen fehlenderFlexibilität einstecken mussten, bietet diese Betriebsart viel Sicher-heit durch Standardisierung. Insbesondere für mittelgroße SAP-Busi-ness-Suite-Systeme auf SAP HANA, bei denen ein lückenloser Sup-port für alle Komponenten und eine garantierte Leistung wichtigsind, ist die Appliance deswegen immer noch das Mittel der Wahl.Für die Zukunft ist zu erwarten, dass durch die technologischen Fort-schritte größere Appliance-Server mit mehr Arbeitsspeicher möglichwerden. Insbesondere für nicht-produktive Systeme werden Appli-ance-Server in Zukunft durch andere, preiswertere Systeme, wiez. B. Cloud-Systeme, verdrängt werden.

4.1.2 Multi-Node Appliances

Einzelne Server, auf denen SAP HANA läuft, im einschlägigen Jargonauch Single-Node Appliances genannt, sind gut für kleinere und mittel-große Systeminstallationen geeignet, besitzen aber durch die begrenzteAnzahl von Prozessorsockeln auch eine begrenzte Anzahl von Prozes-sorkernen und Arbeitsspeicher. Damit ist auch die maximale Größevon SAP-HANA-Systemen auf Single-Node Appliances begrenzt.

Appliances fürgrößere Systeme

Für größere Systeme, wie z. B. SAP-Business-Warehouse-Systeme (SAPBW) größerer Unternehmen oder für Big-Data-Anwendungen werdensogenannte Multi-Node oder auch Scale-out Appliances benötigt. DieseAppliances bestehen aus mehreren Servern, auf denen eine verteilteSAP-HANA-Datenbank läuft, wie in Abbildung 4.2 dargestellt.

Abbildung 4.2 SAP HANA als Multi-Node Appliance



lokale Festplatte


SLES/RHEL-BetriebssystemSLES/RHEL-Betriebssystem

SAP-HANA-Datenbank

lokale Festplattelokale Festplatte



169

Durch das Hinzufügen von mehr Serverknoten kann die Datenbankmit mehr Prozessorkernen und mehr Speicher vergrößert werden.Die gleiche Mechanik kann genutzt werden, um ein SAP-HANA-Sys-tem hochverfügbar zu machen. Bestimmte Knoten können alsStandby-Knoten definiert werden, die bestimmte Aufgaben vonanderen aktiven Knoten übernehmen können, falls diese ausfallen(siehe auch Abschnitt 2.2.2, »Multiple-Host-Systeme«).

Die SAP-HANA-Datenbank wurde von Entwicklungsbeginn an alsverteilte Datenbank konzipiert. Die Datenbank ist dabei als klassi-sche partitionierte Datenbank gebaut, d. h., es gibt einen Master-Knoten, der für die Verwaltung der Datenbank zuständig ist, undzwei oder mehr Worker-Knoten, die die Datenhaltung und -verarbei-tung übernehmen. Wie bei anderen verteilten Datenbanksystemenkönnen auch hier Tabellen partitioniert und über mehrere Daten-bankknoten verteilt werden. Wenn genug Knoten vorhanden sind,können einzelne Knoten auch im Standby-Modus betrieben werden,um bei Ausfall eines aktiven Knotens einzuspringen. Mithilfe diesesMechanismus können Hochverfügbarkeitssysteme aufgebaut wer-den, die weitgehend gegen Ausfälle geschützt sind. Diese Technikkann auch eingesetzt werden, um ein Upgrade der Datenbank mitZero-Downtime durchzuführen.

Im Vergleich zu Single-Node Appliances sind Multi-Node-Systemevor allem für sehr große Systeme geeignet oder für solche, die inZukunft stark wachsen. Durch die Möglichkeit, während des Betriebsneue Knoten zum SAP-HANA-System hinzuzufügen, kann man dieDatenbank leicht skalieren. Neben diesen großen Systemen sind alszweites Einsatzgebiet für Multi-Node-Systeme solche Systeme zu nen-nen, die die Hochverfügbarkeitsfunktion der Datenbank nutzen.

Diese Möglichkeit zusätzlicher Funktionen bzw. die zusätzliche Fle-xibilität in der Skalierung werden durch eine höhere Komplexität derSystemlandschaft erkauft. Dies gilt sowohl für die Hardware bzw. diegenutzte Appliance als auch für den eigentlichen Systembetrieb. AlleAdministrationstools von Backup- bis Monitoring-Werkzeugen müs-sen für das Zusammenspiel mit einem Multi-Node-System ausgelegtsein.

VerfügbarkeitSAP HANA ist seit der ersten Version der Datenbank als Multi-Node-System verfügbar und wird kontinuierlich weiterentwickelt. ImGegensatz zu vielen anderen Datenbanken, die Multi-Node-Funktio-

4 Betriebskonzepte

170

nen besitzen, wurde SAP HANA von vornherein mit diesen Funktionentwickelt, was sich in vielen Bereichen zeigt.

Anforderungen andie Appliances

Wie die klassischen Single-Node-Systeme werden auch Multi-Node-Systeme für SAP HANA als Appliances ausgeliefert. Im Gegensatz zuden einfachen Systemen besteht eine Multi-Node Appliance aller-dings aus einer Vielzahl von Komponenten, die in der Regel einenganzen Serverschrank in Beschlag nehmen.

Multi-Node Appliances sind oft als Blade-Systeme ausgelegt, beidenen jeder Blade-Server (oder jeder Node) bis zu vier Prozessorso-ckel und bis zu 1 TB Arbeitsspeicher hat. Neben den Blade-Servernbzw. den Nodes benötigt die Appliance normalerweise noch SANStorage, mehrere Switches und Management Server. Aufgrund derkomplexen Konfiguration der verschiedenen Komponenten werdenauch Multi-Node Appliances als vorinstallierte Gesamtpakete ausge-liefert. Inzwischen ist auch eine Integration bestehender Komponen-ten über den Tailored-Data-Center-Ansatz möglich (siehe Abschnitt4.1.4, »Tailored Data Center Integration«).

Die verschiedenen Datenbankknoten teilen sich einen gemeinsamenSpeicher, der von einem SAN-System bereitgestellt wird. Das Daten-banksystem selbst ist als Shared-Nothing-Lösung konzipiert, d. h.,dass jeder Knoten seine eigenen Daten verwaltet und die Daten nichtmit anderen Knoten teilt.

Sizing von Multi-Node Appliances

Als sinnvolle Untergrenze beim Sizing von Multi-Node-SAP-HANA-Systemen kann man die größten Single-Node-Server angeben. DieObergrenze liegt derzeit bei 56 TB (größtes zertifiziertes System). BeiBedarf könnte die Obergrenze sicherlich noch nach oben verschobenwerden, wie Test-Setups von SAP und verschiedenen Hardwareher-stellern mit über 100 TB zeigen.

Um die Möglichkeiten eines Multi-Node-Systems voll auszunutzen,wird es in der Regel mit einer Datenbank installiert. Darüber hinauswerden allerdings auch Multi-Tenant-Database-Container in diesenScale-out-Systemen unterstützt.

Multi-Node-Systeme aufsetzen

Wie für Single-Node-Systeme gilt auch für Multi-Node-Systeme, dassdiese nur in von SAP freigegebenen Rahmen aufgesetzt werden dür-fen, was in der Regel auf eine Appliance oder ein Tailored Data Cen-ter hinausläuft. Hier gelten die gleichen Regeln, wie in Abschnitt4.1.1, »Appliances«, für Single-Node Appliances bzw. in Abschnitt


171

4.1.4, »Tailored Data Center Integration«, für Tailored Data Centerbeschrieben, mit wenigen Ausnahmen. Die genauen Restriktionenund die zugelassenen Systeme finden Sie auf der Webseite http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/appliances.html.

Bevor Sie die Umsetzung eines Multi-Node-Systems für SAP HANAangehen, sollten Sie abwägen, ob der zusätzliche Aufwand, den manbei der Administration des Systems hat, im richtigen Verhältnis zumNutzen steht. Bei dieser Einschätzung sind insbesondere Informatio-nen über die Daten, die auf dem System vorgehalten werden sollen,und das zu erwartende Lastprofil wertvoll. Es gibt hier die gleichenFallstricke wie bei allen verteilten Datenbanksystemen: Wenn dieDaten nicht so verteilt werden können, dass sie parallel bearbeitetwerden können, ist die Gesamt-Performance des Systems durch denerhöhten Netzwerkverkehr und den Overhead für das Zusammenfü-gen der Daten schlechter.

EinsatzszenarienDas typische Einsatzszenario für ein Multi-Node-System im Kontextvon SAP HANA sind SAP-BW-Systeme auf SAP HANA, die über 4 TBDaten (nach Kompression) vorhalten. Bei dieser Systemart lassensich die Daten normalerweise gut über die einzelnen Knoten vertei-len, und je nach Lastprofil kann durch die erhöhte Anzahl von CPU-Kernen sogar ein Geschwindigkeitsgewinn erreicht werden.

Für die SAP Business Suite auf SAP HANA sind Scale-out-Systeme,die nicht als reine Hochverfügbarkeitslösung genutzt werden, bishernur eingeschränkt verfügbar, d. h., jede Implementierung mussgesondert mit SAP abgestimmt werden. Ein Grund für die Restrikti-onen seitens SAP hinsichtlich der Umsetzung von SAP-Business-Suite-Systemen auf SAP HANA als Scale-out-Systemen ist unter ande-rem in der optimalen Verteilung der Daten (Table Redistribution) zufinden. Die SAP-Hinweise 1885758 und 1899817 beschreiben dieTabellenverteilung für die SAP Business Suite auf SAP HANA im Rah-men von Multi-Node Appliances.

Unterstützung von Multi-Node-Systemen für die SAP Business Suite auf SAP HANA

In SAP-Hinweis 1825774 werden die von SAP unterstützten Szenarien fürMulti-Node-Systeme beschrieben. Dieser Hinweis nennt alle Restriktio-nen und dient als Ausgangspunkt für weitere SAP-Hinweise, die auf dieverschiedenen einzelnen Produkte eingehen.

4 Betriebskonzepte

172

Hardwarevoraussetzungen für die SAP Business Suite auf SAP HANA in einem Scale-out-Szenario

Der SAP-Hinweis 1950470 beschreibt die Mindestanforderungen an dieHardware, auf der SAP-Business-Suite-Systeme auf SAP HANA laufenkönnen.

Allgemein gesprochen, kommen Multi-Node-Konfigurationen fürSAP HANA für Systeme infrage, die größer als 2 TB sind. Die größtenzertifizierten produktiven SAP-HANA-Datenbanken liegen derzeitbei 56 TB, die größten Labor-Setups haben aber bereits über 160 TBerreicht. Multi-Node-Systeme sollten Sie dann in Betracht ziehen,wenn keine ausreichend großen Appliance-Systeme zur Verfügungstehen (beachten Sie das Datenwachstum!) oder wenn Hochverfüg-barkeitsanforderungen an Ihr System bestehen.

Vor- und Nachteile Neben der Hochverfügbarkeit und der initialen Größe sprechennoch weitere Faktoren für Multi-Node-Systeme. Bei einem kontinu-ierlichen Datenwachstum, wie es in allen Informationssystemen vor-kommt, kann ein solches System mitwachsen und ist kaum an eineobere Grenze gebunden. Zusätzlich skaliert das SAP-HANA-Systemfast linear mit der Anzahl der Knoten, solange die Daten über meh-rere Knoten verteilt werden können.

Diese Vorteile erkauft man sich allerdings durch eine wesentlich hö-here Komplexität beim Setup und Betrieb des Systems sowie bei Back-up, Recovery, Restore, Monitoring, Performance-Optimierung etc.Neben dem höheren Arbeitsaufwand für den Betrieb des Systemsmuss auch der zusätzliche Schulungsaufwand berücksichtigt werden,der betrieben werden muss, um Administratoren und Systemarchi-tekten adäquat vorzubereiten. Eine unzureichende Konfigurationkann sich schnell auf die Gesamt-Performance des Systems auswirken.

Da heute nicht nur die Rechenleistung von Prozessoren steigt, son-dern auch die Gesamtgröße des adressierbaren Arbeitsspeichers proSockel, sind in Zukunft immer größere Single-Node Appliances zuerwarten (Scale-up). Diese Systeme werden Multi-Node-Konfigurati-onen nicht ablösen, aber in vielen Fällen über ausreichend Kapazitätverfügen, um bevorzugt eingesetzt zu werden, auch wegen ihrergeringeren Komplexität. Trotzdem wird es in Zukunft weiterhinMulti-Node-Systeme im Kontext von SAP HANA geben, weshalb SAPfortlaufend Neuerungen für diese Betriebskonzept entwickelt.


173

4.1.3 Virtualisierung

Nicht-produktiver virtualisierter Betrieb von SAP HANA

Das Thema Virtualisierung ist heute in den meisten Rechenzentrenvon Unternehmen weltweit angekommen. Das Appliance-Konzeptvon SAP HANA passt mit seinem einen physischen Server pro Daten-bank natürlich nicht zu dieser Entwicklung. SAP hat diese Problema-tik erkannt und SAP HANA relativ früh für den nicht-produktivenBetrieb freigegeben, allerdings mit einigen Einschränkungen. Auf-grund des komplexen Zusammenspiels der Virtualisierungssoftwareund der Software, die auf den virtuellen Maschinen läuft, sind imMoment nur einige wenige Lösungen für den produktiven Einsatzvirtualisierter SAP-HANA-Systeme freigegeben. Gleichzeitig sind(noch) nicht alle Funktionen, die die Virtualisierung für Unterneh-men attraktiv machen, freigegeben.

Unterstützung von Hardware-partitionierung

Über die im Folgenden beschriebenen Lösungen hinaus kann SAPHANA inzwischen auch auf Systemen laufen, die über eine soge-nannte Hardwarepartitionierung in ihren Ressourcen beschränktsind. Unterstützt werden in diesem Bereich zurzeit die Lösungen HPnPartitions und Fujitsu PPAR.

Übersicht über SAP HANA in virtuellen Maschinen

In SAP-Hinweis 1788665 finden Sie aktuelle Informationen über dieunterschiedlichen Virtualisierungslösungen, die von SAP HANA unter-stützt werden. Dieser SAP-Hinweis ist ein guter Einstieg, wenn Sie dieEinführung einer virtualisierten SAP-HANA-Landschaft planen.

Abbildung 4.3 Virtualisierte SAP-HANA-Systeme

Im Unterschied zum direkten Betrieb von SAP HANA auf einem odermehreren physischen Servern liegt bei der Virtualisierung zwischen


Hypervisor


SAP-HANA-Datenbank

virtualisierte Festplatte virtualisierte Festplatte

SAP-HANA-Datenbank


4 Betriebskonzepte

174

der SAP-HANA-Datenbank und dem physischen Server ein Hyper-visor, der die vorhandenen Hardwareressourcen abstrahiert (sieheAbbildung 4.3). Der genaue Aufbau der Landschaft ist von der einge-setzten Virtualisierungstechnologie abhängig. Die Konfiguration dervirtuellen Maschinen selbst unterscheidet sich nicht essenziell vonder regulärer physischer Maschinen.

Die Virtualisierung von SAP HANA ist ab SPS 07 entweder mitVMware vSphere 5.5 oder mit Hitachi LPAR 2.0 möglich. Dabei wer-den die Ressourcen eines physischen Servers auf mehrere virtuelleMaschinen aufgeteilt. Jede dieser virtuellen Maschinen verhält sichdabei wie ein physischer Rechner. Im Prinzip ist es hier ohne Pro-bleme möglich, mehrere virtuelle Maschinen gleichzeitig laufen zulassen und eine Überprovisionierung der Ressourcen vorzunehmen,d. h. mehr Ressourcen zu vergeben, als eigentlich vorhanden sind,wenn man davon ausgehen kann, dass nicht alle virtuellen Maschi-nen gleichzeitig ausgelastet werden. Sowohl das Verteilen der Res-sourcen als auch die Überprovisionierung bieten im normalenBetrieb wesentliche Vorteile, weil sich durch die effizientere Res-sourcennutzung Geld sparen lässt. Allerdings kann es bei der gleich-zeitigen Auslastung mehrerer virtueller Maschinen auf einem physi-schen Server zu Performance-Engpässen kommen. Aus diesemGrund gibt SAP für den produktiven Betrieb von SAP HANA in virtu-ellen Maschinen ausschließlich die Konfiguration einer virtuellenMaschine pro physischem Server frei. Der hauptsächliche Grund fürdiese Beschränkung ist der drohende Performance-Verlust, falls sichzwei unter Last stehende virtuelle Maschinen in die Quere kommen.

Vor- und Nachteileder Virtualisierung

Im Gegensatz zum Betrieb von SAP HANA auf physischen Servernbietet die Virtualisierung einige Vorteile. So können neue SAP-HANA-Systeme sehr leicht und schnell zurückgesetzt oder geklontwerden, indem eine komplette virtuelle Maschine geklont oderzurückgesetzt wird. Das erlaubt eine insgesamt beschleunigte Provi-sionierung, die bei bereits virtualisierten Landschaften keinen neuenProzess darstellt. Natürlich bringt die Virtualisierung nicht aus-schließlich Vorteile. Von SAP ausgeführte Messungen beziffern dendurchschnittlichen Geschwindigkeitsverlust durch die Virtualisie-rung auf ungefähr 12 %. Zusätzlich muss man mit einem Leistungs-Overhead für den Betrieb von Gastbetriebssystemen und Hypervisorrechnen. Der endgültige Overhead hängt von der verwendetenVirtualisierungslösung ab.


175

Außerdem fehlt zurzeit noch eine Vielzahl von Funktionen, die dieVirtualisierung von SAP-HANA-Systemen erst wirklich interessantmachen. Dazu zählen in erster Linie die vollständige Unterstützungmehrerer virtueller SAP-HANA-Maschinen auf einem physischenHost im produktiven Betrieb sowie weitere Funktionen wie dieÜberprovisionierung von Hosts.

Virtualisierung produktiver Systeme

SAP HANA unterstützt die Virtualisierung nicht-produktiver Systemebereits seit SPS 05. Seit SPS 07 wird auch die Virtualisierung produk-tiver Systeme unterstützt. Details können Sie dem SAP-Hinweis1788665 entnehmen.

VMwareFür unterschiedliche Virtualisierungstechnologien gelten verschie-dene Einschränkungen. Die wahrscheinlich prominenteste Lösungfür die Virtualisierung von SAP HANA ist VMware, die auch eine derersten unterstützten Lösungen war. Diese ist seit VMware vSphere5.1 für nicht-produktive und seit VMware 5.5 für produktive Sys-teme freigegeben. Allerdings ist dabei zu beachten, dass für produk-tive Systeme nur je eine virtuelle Maschine pro physischem Serverunterstützt wird. Mehrere virtuelle Maschinen oder Scale-out-Szena-rien sind zurzeit noch nicht vollständig freigegeben. Darüber hinausdürfen ausschließlich zertifizierte Appliance-Server als Basis für dievirtualisierten Systeme dienen.

Weitere Informationen zu SAP HANA auf VMware

In SAP-Hinweis 1995460 werden die zugelassenen Einsatzszenarien fürmit VMware virtualisierte SAP-HANA-Systeme und deren Einschränkun-gen im Detail beschrieben.

Die maximale Größe des Arbeitsspeichers ist bei produktiven Syste-men auf 1 TB und die maximale Anzahl der Prozessorkerne auf 64beschränkt. Für nicht-produktive Systeme gelten wesentlich wenigerEinschränkungen. So sind hier auch TDI-Server und mehrere virtu-elle Maschinen pro physischem Server erlaubt.

Weitere Informationen zu SAP HANA auf LPAR, PPAR und nPAR

Neben VMware werden auch weitere Virtualisierungstechnologien ande-rer Hersteller unterstützt, wie z. B. LPAR, PPAR und nPAR. Die erlaubtenEinsatzszenarien und Beschränkungen können Sie den folgenden SAP-Hinweisen entnehmen:

4 Betriebskonzepte

176

� SAP-Hinweis 2230704 beschreibt die zugelassenen Einsatzszenarienund Beschränkungen, wenn Sie mehrere SAP-HANA-Systeme auf ver-schiedenen LPAR-Partitionen eines physischen Servers betreibenmöchten.

� SAP-Hinweis 2111714 beschreibt die zugelassenen Einsatzszenarienfür mehrere SAP-HANA-Systeme auf PPAR-Partitionen.

� SAP-Hinweis 2103848 beschreibt die zugelassenen Einsatzszenarienfür mehrere SAP-HANA-Systeme auf nPAR-Partitionen.

Falls Sie eine Virtualisierung von SAP-HANA-Lösungen planen, stellen Siesicher, dass Sie die aktuellen SAP-Hinweise zu diesem Thema kennen.Aufgrund der kurzen Release-Zyklen ändern sich diese häufig.

Einsatzszenarien Viele Parameter virtueller Maschinen, die bei physischen Servern fixsind, lassen sich leicht ändern, wie z. B. zugeordnete Ressourcenoder der Betriebszustand. Daher eignen sich virtuelle Maschinenbesonders in Bereichen, in denen diese Eigenschaften ausgenutztwerden können. Prädestiniert sind hier vor allem nicht-produktiveSysteme wie Qualitätssicherungs- oder Testsysteme, die oft geklontoder gestartet/gestoppt werden.

Hinsichtlich der auf der Virtualisierungslösung betriebenen SAP-HANA-Systeme gibt es keine Unterschiede zu Single-Node-Syste-men. Dementsprechend können virtuelle SAP-HANA-Systeme auchmit verschiedenen Installationsvarianten, wie z. B. Multi-Tenant-Database-Containern, kombiniert werden.

Virtuelle Maschinen als Basis für SAP HANA bieten viele Vorteile,wenn es um den Betrieb kleinerer SAP-HANA-Systeme geht. Die Res-sourcen können wesentlich einfacher und strikter zwischen mehre-ren SAP-HANA-Systemen getrennt werden, die auf dem gleichenphysischen Server laufen. Das Gleiche gilt für die Trennung der SAP-Systeme selbst: Da die SAP-HANA-Systeme auf unterschiedlichenComputern laufen (auch wenn diese virtualisiert sind), ist eine voll-ständige Trennung der Daten und Zugriffe gewährleistet. Zusätzlichkönnen virtuelle Maschinen, vorausgesetzt, es sind noch genügendRessourcen verfügbar, relativ einfach skaliert (sowohl nach oben alsauch unten) und zwischen physischen Hosts verschoben werden.Dies hilft, SAP-HANA-Systeme an sich ändernde Lastprofile anzupas-sen. Gleichzeitig können Systeme durch das Klonen virtuellerMaschinen relativ leicht kopiert werden. Dies ist z. B. für Systemak-tualisierungen in Drei-System-Landschaften von Vorteil.


177

Da virtualisierte Rechenzentren keine Exoten mehr darstellen, son-dern in vielen Unternehmen bereits Alltag sind, kann sich auch SAPHANA diesem Trend nicht widersetzen. Gerade für VMware werdenin Zukunft mehr und mehr Funktionen freigegeben, wie z. B. meh-rere produktive virtualisierte SAP-HANA-Systeme auf einem physi-schen Server oder Scale-out-Konfigurationen. Darüber hinaus ist zuerwarten, dass neuere Versionen von vSphere unterstützt werden,sodass Setups mit bis zu 4 TB Arbeitsspeicher möglich werden. Allesin allem kann davon ausgegangen werden, dass virtualisierte Sys-teme einen festen Platz in der SAP-HANA-Landschaft erhalten wer-den.

4.1.4 Tailored Data Center Integration

Nutzung bestehender Ressourcen

So gut wie jedes Unternehmen, das SAP HANA einsetzen und selbstbetreiben möchte, besitzt bereits eine Landschaft von IT-Systemenund damit auch ein Rechenzentrum. In den meisten modernenRechenzentren werden bestimmte Teile der Infrastruktur zentralund nicht für jeden Server einzeln bereitgestellt, wie z. B. Kühlungund Storage. Damit Unternehmen diese zentralen Services ihrerbestehenden Rechenzentrumsinfrastruktur auch im Zusammenspielmit SAP HANA nutzen können, hat SAP die Tailored Data Center Inte-gration (TDI) eingeführt. Abbildung 4.4 zeigt den Aufbau einer Sys-temlandschaft, die nach diesem Modell aufgesetzt wurde. Auf dieeinzelnen Komponenten gehen wir im Folgenden noch ein.

Abbildung 4.4 Tailored Data Center Integration

Dieses Programm erlaubt es SAP-Kunden, bestehende Hardware-und Infrastrukturkomponenten für den Betrieb von SAP HANA zu

Storage Area Network



Netzwerk-SwitchSAP-HANA-Datenbank

4 Betriebskonzepte

178

nutzen. Die Rahmenparameter für die einzelnen Komponenten wer-den auch bei diesem Ansatz von SAP vorgegeben (z. B. die minimaleBandbreite von Storage-Systemen in Megabyte), allerdings ist esdabei möglich, die einzelnen Komponenten selbst auszusuchen,bestehende Komponenten zu nutzen und SAP-HANA-Server kosten-günstiger anzuschaffen.

FAQ zur Tailored Data Center Integration

Unter der Webadresse https://scn.sap.com/docs/DOC-62942 finden Sieeine kontinuierlich aktualisierte Liste mit oft gestellten Fragen zum ThemaTailored Data Center Integration.

Vorgaben von SAP SAP gibt die Kernkomponenten für Server im TDI-Betrieb weiterhinvor. So darf nicht jeder Server für SAP-HANA-Installationen genutztwerden. Allerdings wurden die Beschränkungen mit der Zeit immerweiter aufgehoben. Trotzdem orientieren sich die Beschränkungenfür TDI-Landschaften weiterhin an den Appliance-Systemen, umbestimmte Systemparameter wie z. B. eine Mindestgeschwindigkeitder Datenbank garantieren zu können.

Der TDI-Ansatz ist dementsprechend weniger dafür konzipiert, kom-plett eigene Server für SAP HANA nutzbar zu machen, sondern, umbestehende Teile vorhandener Infrastruktur mit SAP HANA zu inte-grieren. Wegen der Ähnlichkeit zu regulären Appliance-Servern gel-ten für TDI-Server in der Regel auch ähnliche Einschränkungen,wodurch die meisten Einsatzszenarien abgedeckt werden. Dazu zähltz. B. die Unterstützung aller Installationsvarianten, die auch für regu-läre Appliance-Server gelten.

Das TDI-Programm besteht aus mehreren Phasen, die nacheinandereingeführt wurden. Mit jeder Phase wurden zusätzliche Appliance-Komponenten für eine individuelle Nutzung freigegeben.

Phase 1 In der ersten Phase wurden mit SAP HANA SPS 07 bestimmte Enter-prise-Storage-Systeme für den Einsatz mit SAP HANA freigegeben.Um für den Betrieb mit SAP HANA zugelassen zu werden, müssenverschiedene Systeme bei SAP zertifiziert werden. Die meisten gro-ßen Hersteller, die auch Appliances anbieten, zertifizieren ihreneuen Storage-Systeme für den TDI-Betrieb mit SAP HANA. ÄltereSysteme werden meist nicht mehr zertifiziert.


179

Liste aller zertifizierten Enterprise-Storage-Systeme

Unter der Webadresse http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/enterprise-storage.html finden Sie eine aktuelleListe aller zertifizierten Enterprise-Storage-Systeme.

Beachten Sie, dass in der Regel mehrere Modelle desselben Storage-Systems zertifiziert sind. Normalerweise wird nur ein System auseiner Produktfamilie für die Zertifizierung getestet. Voraussetzungenfür die Nutzung eines anderen Systems aus derselben Produktfamiliesind:

� Die Systeme müssen auf der gleichen Architektur aufbauen.

� Die Systeme müssen die gleichen Storage-Konnektoren nutzen.

� Die Systeme müssen vergleichbare Komponenten wie das für dieZertifizierung getestete System besitzen.

� Die für die Zertifizierung vorgegebenen Key Performance Indi-cators (KPIs) müssen von allen Mitgliedern der Produktfamilieerfüllt werden.

Ob und in welcher Konfiguration ein System für den TDI-Betrieb mitSAP HANA geeignet ist, erfahren Sie bei Ihrem Hardwarepartner.

Phase 2In der zweiten Phase des TDI-Programms wurde die Möglichkeit auf-genommen, bestehende Netzwerkkomponenten in SAP-HANA-Setups zu integrieren. Dies betrifft in erster Linie Konfigurationenvon Multi-Node-Systemen, die verschiedene Netzwerkkomponentenfür die Verbindung der einzelnen Serverknoten benötigen.

Voraussetzungen für SAP-HANA-Netzwerkkomponenten

Unter der Webadresse https://scn.sap.com/docs/DOC-63221 finden Siedie Voraussetzungen für die Integration bestehender Netzwerkkompo-nenten in SAP-HANA-Setups. Das ausführliche Dokument enthält auchinteressante Informationen zum grundsätzlichen SAP-HANA-Netzwerk-Setup, unabhängig von TDI.

Phase 3Die mit SAP HANA SPS 09 umgesetzte dritte Phase der TDI eröffnetKunden die Möglichkeit, kleiner dimensionierte Server für denBetrieb von SAP HANA einzusetzen. Diese sogenannten Entry-Level-Systeme bauen auf Intel-Xeon-E5-Prozessoren auf und sind für klei-nere und günstigere SAP-HANA-Installationen bestimmt. Die Ein-stiegssysteme unterliegen Einschränkungen, auch um sie von den

4 Betriebskonzepte

180

großen Appliances abzugrenzen. So dürfen ausschließlich Zwei-Sockel-Systeme (zwei CPUs mit mindestens acht Kernen pro CPU)mit einer Arbeitsspeicherausstattung zwischen 128 und 1.536 GBArbeitsspeicher im Single-Node-Betrieb genutzt werden. GrößereSysteme mit mehr Arbeitsspeicher, mehr Prozessoren oder mit mehrKnoten im Multi-Node-Betrieb sind nicht erlaubt.

Liste aller zertifizierten Entry-Level-Systeme

Unter der Webadresse http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/entry-level-systems.html finden Sie eine aktuelleListe aller zertifizierten Entry-Level-Systeme.

Um eine SAP-HANA-Datenbank nach dem TDI-Ansatz betreiben zudürfen, müssen mehrere Bedingungen erfüllt sein. Dies gilt sowohlfür die Ausbildung des Personals, für die Übernahme bestimmterPflichten als Kunde als auch für die Auswahl der Hardwarekompo-nenten für Server und Rechenzentrumskomponenten. Wird ein SAP-HANA-System nach dem TDI-Ansatz betrieben, geht die Verantwor-tung für die Installation des SAP-HANA-Systems und der umliegen-den Komponenten vom Hardwarepartner auf den Kunden über.

NotwendigeZertifizierungen

Die obligatorische Voraussetzung, die sich aus dieser geändertenAufgabenverteilung für die Einrichtung des Systems und den Betriebergibt, ist die Zertifizierung eines Mitarbeiters als SAP Certified Tech-nology Specialist (Edition 2014) – SAP HANA Installation (E_HANAINS141 oder E_HANAINS142). Voraussetzung für die Zulas-sung zu einer dieser Zertifizierungen ist der erfolgreiche Abschlussder Zertifizierung SAP Certified Technology Associate (Edition 2014) –SAP HANA (C_HANATEC141 oder C_HANATEC142). Der Unter-schied zwischen den Kursen 141 und 142 liegt in der darin genutz-ten Version von SAP HANA (SPS 07 bzw. SPS 08). Bis auf die versi-onsabhängigen Änderungen werden bei beiden Zertifizierungen diegleichen Themenbereiche und Tools abgefragt. Die Zertifizierungenfragen breit gefächert Wissen über Konfiguration und Betrieb vonSAP-HANA-Systemen ab und erstrecken sich über die Themen Land-schaftsplanung, (De-)Installation, Backup und Recovery, Monitoring,Betrieb, Fehlerbehandlung, High Availability und Desaster Recovery,Migration, Scale-out und angrenzende Themengebiete. Der erfolg-reiche Abschluss beider Zertifizierungen befähigt zur eigenständigenInstallation und zum Betrieb von SAP-HANA-Systemen. Das für die


181

Zertifizierungen erforderliche Wissen kann durch die SAP-Educa-tion-Kurse »SAP HANA – Introduction« (HA100) und »SAP HANA –Operations & Administration« (HA200) sowie durch das intensiveStudium der offiziellen Leitfäden für SAP-HANA-Server-Installation,Administration, SAP-HANA-Studio-Installation sowie Update & Kon-figuration erworben werden. Die Zertifizierungsvoraussetzung giltauch, wenn Betrieb und Hosting durch einen Dienstleister vorge-nommen werden.

SAP-HANA-Kurse und Zertifizierungen

Unter der Webadresse https://training.sap.com/de/de können Sie die offi-ziellen SAP-Kurse und -Zertifizierungen für SAP HANA einsehen undbuchen.

Die genannten Leitfäden (für den jeweils neuesten Support PackageStack) finden Sie unter der URL http://help.sap.com/hana_platform.

Prüfung der Hardware-konfiguration

Um prüfen zu können, ob ein Server für den Betrieb von SAP HANAgeeignet und zugelassen ist, kann das von SAP bereitgestellte Toolzur Prüfung der Hardwarekonfiguration (SAP HANA Hardware Confi-guration Check Tool) genutzt werden. Es ist Bestandteil des Installati-onspakets SAP HANA Platform Edition und befindet sich im Ver-zeichnis DATA_UNITS/SAP_HANA_HWCCT_LINUX_X86_64.

Sie können das Tool auch unter https://support.sap.com/swdc � Sup-port Packages and Patches � A–Z � H � SAP HANA Platform Edi-tion � SAP HANA Platform Edition 1.0 � Entry by Component �HANA config check � SAP HANA HW CONFIG CHECK 1.0 � Linuxon x86_64_64bit herunterladen. Achten Sie beim Herunterladendarauf, dass die Revisionsnummer im Dateinamen kompatibel zuIhrem SAP-HANA-System ist: HWCCT__xxxxxxxx.SAR.

Informationen zum SAP HANA Hardware Configuration Check Tool

In SAP-Hinweis 1943937 finden Sie die Bedienungsanleitung für das Toolsowie Beispielkonfigurationen und wichtige Hinweise für den Einsatz.

Einsatzszenarien für TDI-Ansatz

Der Einsatz des TDI-Ansatzes für den Betrieb von SAP-HANA-Syste-men lohnt sich vor allem in zwei Szenarien:

� wenn bereits eine Rechenzentrumsinfrastruktur betrieben wird,in die SAP HANA mittels TDI integriert werden kann (z. B. einSAP-HANA-zertifiziertes SAN-System)

4 Betriebskonzepte

182

� wenn ein (hinsichtlich des Arbeitsspeichers) kleineres SAP-HANA-System betrieben werden soll, wobei die Prozessorleistung für dasLastprofil der Applikation nicht im Vordergrund steht

Bei der Implementierung des TDI-Ansatzes muss immer daraufgeachtet werden, dass sowohl zusätzliche Kosten für die Ausbildungdes Personals als auch Pflichten für die Konfiguration und denBetrieb anfallen. Da zu erwarten ist, dass SAP den TDI-Ansatz weiterausbaut, kann auch davon ausgegangen werden, dass sich weitereEinsatzmöglichkeiten ergeben.

Vor- und Nachteile Das Konzept der Tailored Data Center Integration bietet im Vergleichzu anderen Einsatzszenarien Vor- und Nachteile. Zu den Vorteilengehört z. B. die erhöhte Flexibilität, die sich bei der Anschaffungneuer Systeme ergibt, weil diese genauer dimensioniert werden kön-nen und die bestehende Infrastruktur weiterhin genutzt werdenkann. Diese Flexibilität sorgt auch dafür, dass sowohl die Anschaf-fungs- als auch die Betriebskosten wesentlich geringer sind als dieeiner »normalen« Appliance.

Die genannten Vorteile werden durch Nachteile erkauft, die sichdirekt aus positiven Faktoren ergeben. Durch die Integration beste-hender Hardwarekomponenten ergibt sich ein höherer Integrations-aufwand, und die Möglichkeit, eine SAP HANA Appliance mittelsPlug & Play in Betrieb zu nehmen, entfällt. Neben der erhöhtenDauer für die Einrichtung der SAP HANA Appliance ist, je nach Kon-figuration, eine geringere Performance möglich. Da bei »normalen«Appliance-Servern in der Regel nur Komponenten verbaut werden,die sich am oberen Ende des Leistungsspektrums befinden, könnenÄnderungen an der Serverkonfiguration die Performance leichtnegativ beeinflussen. Dies gilt insbesondere für die Einstiegssystemeaus Phase 3 der TDI, von denen nicht die gleiche Geschwindigkeiterwartet werden kann wie von den Standard-Appliances.

Weitere Nachteile des Betriebs eines SAP-HANA-Systems nach demTDI-Ansatz sind die Verantwortung für das ordnungsgemäße Aufset-zen des SAP-HANA-Systems und die damit verbundenen Schulungs-,Zertifizierungs- und Personalkosten, die man als Betreiber zu tragenhat.

Das TDI-Programm wird in Zukunft sicherlich noch weiter ausge-baut, und die Anzahl der zur Verfügung stehenden Serverkonfigura-


183

tionen wird dann noch erweitert. Zu erwarten ist hier eine nochbreitere Palette von Appliance-Konfigurationen für unterschiedlicheAnwendungszwecke.

4.1.5 Cloud

Cloud-Angebote, d. h. virtualisierte Ressourcen, die auf einer Pay-per-Use-Basis, also pro Stunde, abgerechnet werden, sind heutzutagenicht mehr aus modernen IT-Landschaften wegzudenken. Ganzgleich, ob als Private Cloud (alle genutzten Ressourcen werden vomUnternehmen selbst betrieben und sind exklusiv) oder als PublicCloud (alle genutzten Ressourcen werden außerhalb des Unterneh-mens betrieben und werden mit anderen Nutzern geteilt) – fast jedesUnternehmen nutzt heutzutage IT-Komponenten, die in der Cloudliegen, oder plant eine Einführung.

Dynamische Bereitstellung

Die dynamische Bereitstellung von Ressourcen widerspricht derAppliance-Idee, mit der SAP versucht, die Leistung der SAP-HANA-Plattform garantieren zu können. Allerdings hat SAP bereits früherkannt, dass für nicht-produktive Systeme keine Leistung garantiertwerden muss, sondern die schnelle und kostengünstige Bereitstel-lung im Vordergrund steht. Seit Mai 2012 (bzw. SAP HANA SPS 04)bieten SAP und Amazon die In-Memory-Datenbank aus der PublicCloud und nach dem Pay-per-Use-Modell an. Seitdem hat sich nichtnur die Liste der Cloud-Anbieter für SAP HANA wesentlich verlän-gert (unter anderem bietet SAP selbst Cloud-Dienstleitungen an),sondern auch die Möglichkeiten, wie und für welchen Zweck Sys-teme in der Cloud betrieben werden können, sind gewachsen.

Definition des Cloud-Begriffs

Da für die Begrifflichkeiten rund um die Cloud viele Definitionen imUmlauf sind, grenzen wir sie hier kurz ab, um ein gemeinsames Verständ-nis als Grundlage für die weiteren Erläuterungen in diesem Abschnitt zuschaffen.

Als Private Cloud bezeichnen wir virtualisierte Ressourcen, deren Benut-zerbasis vorbestimmt ist und die durch Abschottung nicht durch andereBenutzer beeinflusst werden kann. Diese Private Clouds werden in derRegel im eigenen Unternehmen betrieben und sind dementsprechendabgeschottet.

Die sogenannte Public Cloud bezeichnet unserem Verständnis nach Res-sourcen, die eine unbestimmte Benutzerbasis haben und auf Pay-per-Use-Basis bezogenen werden können, d. h., man zahlt ausschließlich für

4 Betriebskonzepte

184

die Ressourcen, die man auch nutzt. Bei diesem Modell muss man davonausgehen, dass die genutzte Landschaft auch durch andere Unternehmenoder Privatpersonen genutzt wird und dass man – abhängig von den Ver-einbarungen mit dem Cloud-Anbieter – unter Umständen Leistungseinbu-ßen bei gemeinsam genutzten Komponenten wie z. B. dem Netzwerk hin-nehmen muss. Public Clouds werden in der Regel außerhalb des eigenenUnternehmens betrieben.

In diesem Abschnitt beschäftigen wir uns in erster Linie mit Clouds,die von externen Unternehmen betrieben werden. Systeme, die aufvirtualisierten Ressourcen innerhalb des Unternehmens betriebenwerden, haben wir in Abschnitt 4.1.3, »Virtualisierung«, behandelt.

Public-Cloud-Angebote

Ein Großteil der von diesen externen Unternehmen bereitgestelltenLandschaften kann unter dem Begriff Public Clouds eingeordnet wer-den. Dazu zählen z. B. die Angebote von Amazon Web Services(http://aws.amazon.com/de/sap/saphana) oder Microsoft Azure (http://azure.microsoft.com/de-de/campaigns/sap), über die SAP-HANA-Sys-teme in unterschiedlichen Größen (von 56 GB bis zu 1,2 TB) betrie-ben werden können.

Neben den Public Clouds von Amazon und Microsoft existiert nocheine Vielzahl anderer Hosting-Angebote, die meist als Private Cloudsausgelegt sind und von großen Hosting-Anbietern wie z. B. Atos, HPoder T-Systems betrieben werden. Diese Angebote sind in der Regelfür den produktiven Betrieb ausgelegt und erfüllen Anforderungen,die dem klassischen IT-Outsourcing entsprechen.

SAP HANAEnterprise Cloud

Neben den bekannten Hosting-Anbietern bietet auch SAP selbst mitder SAP HANA Enterprise Cloud (HEC) einen Private-Cloud-Servicean. Dieser seit Anfang 2013 bestehende Service beinhaltet nicht nurdas Hosting SAP-HANA-basierter Systeme auf SAP-eigenen Rechen-zentren in Deutschland, sondern, wie auch bei anderen großen Hos-ting-Dienstleistern üblich, eine Vielzahl von Managed Services, wiez. B. Integration, Migration und Monitoring. Die SAP HANA Enter-prise Cloud ist insbesondere zum Produktivbetrieb SAP-HANA-basierter Lösungen wie der SAP Business Suite gedacht und dahinge-hend konzipiert. Neben SAP betreibt auch IBM Rechenzentren, dieals SAP HANA Enterprise Cloud zertifiziert sind.

Für Applikationen, die nativ auf SAP HANA laufen, bietet SAP nocheine Public-Cloud-Variante des Platform-as-a-Service (PaaS) an: DieSAP HANA Cloud Platform (HCP). Bei dieser Plattform hat der Kunde


185

keinen Zugriff auf das darunterliegende System, sondern kann sie fürdas Deployment und die Verwaltung von Applikationen verwenden.

Betrieb von Cloud-Lösungen

Im Gegensatz zum selbstständigen Betrieb im eigenen Unternehmenentfallen beim Gang in die Cloud viele Teile der Systemlebenszyklus-verwaltung, da diese durch die Anbieter übernommen werden, wiez. B. Hardware- und Softwarebeschaffung und -integration oder In-stallation. Je nach Anbieter und Ausprägung der Cloud-Lösung un-terscheiden sich die standardmäßigen und zusätzlichen Services(z. B. Integration mit anderen Diensten). Bei der Wahl des Anbieterssollten Sie abwägen, inwieweit Aufgaben des IT-Betriebs in dieHände der Cloud-Anbieter gegeben werden sollen. Auch sollten Siebeachten, dass ein großer Teil der potenziellen Kosteneinsparungen,die beim Gang in die Cloud möglich sind, durch die starke Standar-disierung der angebotenen Lösungen möglich werden.

Literatur zu SAP-Cloud-Lösungen

Mehr Informationen zu SAP-Cloud-Lösungen und der SAP HANA CloudPlatform finden Sie in den folgenden Büchern:

� Bögelsack, Baader, Prifti, Zimmermann, Krcmar: »SAP-Systeme in derCloud. Implementierung und Betrieb« (SAP PRESS 2016)

� James Wood: »SAP HANA Cloud Platform. Das Handbuch für Entwick-ler« (SAP PRESS 2015)

� Hufgard, Rauff, Zinow: »SAP Cloud. Szenarien, Lösungen und Techno-logie« (SAP PRESS 2015)

SAP unterstützt verschiedene Cloud-Anbieter für unterschiedlicheSzenarien. Am prominentesten treten dabei Amazon Web Servicesauf, die SAP HANA seit SPS 04 in der Cloud anbieten, seit Oktober2012 auch für die produktive Nutzung. Neben dieser Public Cloudbietet SAP seit SPS 07 selbst SAP HANA aus der eigenen PrivateCloud in Form der SAP HANA Enterprise Cloud an. Die PaaS-LösungSAP HANA Cloud Platform ist ebenfalls seit SPS 07 verfügbar.

Architektur der Cloud-Lösungen

Wie die Cloud-Lösungen aufgebaut sind, hängt sowohl von der Artder Cloud als auch vom Anbieter ab. So bietet Amazon stark standar-disierte SAP-HANA-Lösungen an, die auf virtuellen Maschinen vonAmazon Web Services laufen. Entsprechend gibt es nur bestimmteVirtual-Machine-Größen, die in unterschiedlichen Konfigurationengenutzt werden können. Darüber hinausgehende Anpassungen sindnicht vorgesehen. Das Setup der virtuellen Maschinen erfolgt über

4 Betriebskonzepte

186

die sogenannte SAP Cloud Appliance Library (CAL), die vorkonfigu-rierte Virtual-Machine-Images bereitstellt, die in angemietete virtu-elle Maschinen von Amazon Web Services geladen werden können.Beachten Sie, dass neben den Kosten für die Amazon-Web-Services-Instanz selbst in der Regel noch weitere Gebühren für Backup-Spei-cher oder Datenverkehr anfallen.

Weitere Informationen zu SAP HANA auf Amazon Web Services und der SAP Cloud Appliance Library

In SAP-Hinweis 1964437 finden Sie weiterführende Informationen sowieEinschränkungen zum Betrieb von SAP HANA auf Amazon Web Services.

Mehr Informationen zur SAP Cloud Appliance Library finden Sie auf derWebseite http://scn.sap.com/docs/DOC-33673 und unter https://cal.sap.com/.

Unterschiedebei den Cloud-

Anbietern

Für SAP-HANA-Instanzen auf Basis der Amazon Web Services gibt esunterschiedliche Lizenzmodelle: von der kostenfreien SAP HANADeveloper License, mit der nicht-produktive Demoszenarien getestetwerden können, bis hin zum Modell Bring Your Own License, bei demeine separat erworbene, produktive SAP-HANA-Lizenz in ein vorge-fertigtes Virtual-Machine-Image eingespielt wird.

Im Gegensatz zu den Lösungen von Amazon ist die SAP HANA Enter-prise Cloud als Private Cloud ausgelegt, bei der wesentlich mehrÄnderungen an Systemen vorgenommen werden können und beider auch zugeschnittene Services (Managed Services) erworben wer-den können. Entsprechend mehr Flexibilität wird geboten.

Weitere Informationen zur SAP HANA Enterprise Cloud

Weitere Informationen zur SAP HANA Enterprise Cloud finden Sie unterhttp://hana.sap.com/implementation/deployment/cloud/hana-enterprise-cloud.html.

Die SAP HANA Enterprise Cloud ist nicht nur aus den SAP-eigenenRechenzentren verfügbar, sondern auch von IBM. Im Gegensatzdazu wird SAP HANA als PaaS bisher ausschließlich von SAP bereit-gestellt. Im Gegensatz zur SAP HANA Enterprise Cloud ist die SAPHANA Cloud Platform im Funktionsumfang wesentlich einge-schränkt, da kein vollständiger Zugriff auf die Datenbank besteht.Allerdings sind in der SAP HANA Cloud Platform viele zusätzlicheSysteme neben SAP HANA sowie Konnektoren für On-Premise-Sys-


187

teme verfügbar, die für die Anwendungsentwicklung interessantsind, wie etwa SAP Adaptive Server Enterprise (früher Sybase ASE)oder Apache Tomcat.

Alle hier beschriebenen Cloud-Lösungen sind von SAP für den pro-duktiven Einsatz zugelassen, wobei Amazon Web Services und SAPHANA Enterprise Cloud in erster Linie für den Betrieb SAP-NetWea-ver-basierter Anwendungssysteme gedacht sind, die auf SAP HANAlaufen. Die SAP HANA Cloud Platform ist dagegen für selbst entwi-ckelte Applikationen vorgesehen.

Einsatzszenarien und Cloud-Lösungen

Je nach Einsatzszenario und Anforderung können unterschiedlicheCloud-Lösungen genutzt werden:

� Für den produktiven Einsatz SAP-HANA-basierter Systeme undwenn im eigenen Unternehmen nur wenig Know-how aufgebautwerden soll, bietet sich die SAP HANA Enterprise als Cloud-Platt-form an. Hier können Managed Services für die Einführung einge-kauft werden, und die Betriebsverantwortung bleibt bei SAP.

� Falls Sie kein vollständiges SAP-HANA-System benötigen, um z. B.ein SAP-Business-Suite-System darauf zu betreiben, sondern nurApplikationen auf SAP HANA entwickeln möchten, bietet sich dieSAP HANA Cloud Platform an. Über die PaaS können Sie die ganzePalette der Funktionen von SAP HANA nutzen und haben dieMöglichkeit, Ihre genutzten Ressourcen zu skalieren.

� Amazon Web Services und andere Anbieter sind insbesonderedann interessant, wenn Sie neue Funktionen oder Systeme testenmöchten und dafür kurzfristig Ressourcen benötigen.

Vor- und NachteileAllen Cloud-Systemen ist gemein, dass diese eine hohe Flexibilitätbieten. Dies gilt sowohl für die Skalierung der Ressourcen nach obenund unten als auch für den Preis. Falls Sie nur Teilbereiche einesSAP-HANA-Systems nutzen möchten, nur für wenige Wochen einenProof-of-Concept durchführen oder nicht in die teure Hardwareinvestieren möchten, kann eine Cloud-Lösung eine Option für Siesein. Neben der Flexibilität bieten insbesondere die Managed Ser-vices die Möglichkeit, Teile der Administration auszulagern.Dadurch muss kein kostenintensives Know-how aufgebaut werden.

Es gibt jedoch auch cloud-spezifische Nachteile. So ist z. B. der Kos-tenvorteil einer Cloud-Lösung stark von der Nutzung abhängig. Fallsdie Systeme kontinuierlich genutzt werden, bietet der Gang in die

4 Betriebskonzepte

188

Cloud in der Regel keinen Preisvorteil. Darüber hinaus ist es oftschwer, die tatsächlichen Kosten eines Angebots zu berechnen, dadiese von vielen Faktoren abhängen, wie etwa der verursachten Last,dem Netzwerkverkehr, Backups etc. Das genaue Abrechnungsmodellhängt dabei natürlich vom Anbieter ab.

Neben den Kosten für den eigentlichen Betrieb darf man nicht dieIntegrationskosten übersehen, die bei der Anschaffung von Cloud-Systemen entstehen. Da in der Regel nicht alle Systeme eines Unter-nehmens in die Cloud verlagert werden, müssen die Systeme inner-halb des Unternehmens mit den Systemen in der Cloud integriert wer-den. Der dafür notwendige Aufwand darf nicht unterschätzt werden.

Wägt man Vor- und Nachteile ab, kann der Gang in die Cloud durch-aus Vorteile für bestimmte Applikationen bieten. Auf jeden Fall ist essinnvoll, die Entwicklung bei SAP im Bereich der Cloud zu verfolgen.Die Cloud ist inzwischen ein fester Bestandteil der offiziellen SAP-Strategie. Dementsprechend kann man erwarten, dass die Cloud-Kapazitäten von SAP HANA noch weiter ausgebaut werden. Dies istbereits zu erkennen, wenn man die neue Business Suite SAP S/4HANAbetrachtet, bei der eine Integration von in der Cloud laufendenAnwendungen mit On-Premise-Anwendungen vorgesehen ist.

4.2 Installationsvarianten

Neben den verschiedenen Varianten, die Landschaft aufzusetzen,gibt es für SAP HANA verschiedene Installationsvarianten, über diesich Applikationen auf SAP HANA betreiben lassen. Im Folgendenbeschreiben wir neben der Variante Single-Database-System, die denStandardfall darstellt, alle von SAP unterstützten Szenarien. BeachtenSie, dass nicht alle Landschaftssetups mit allen Installationsvariantenkompatibel sind. Die zugelassenen Kombinationen nennen wir inden jeweiligen Abschnitten.

4.2.1 Single-Database-System

Die einfachste Installationsvariante für ein SAP-HANA-System isteine einfache Single-Database-System-Installation. Dabei wird genaueine SAP-HANA-Datenbank auf einem System installiert. Diese In-stallationsvariante (siehe Abbildung 4.5) war zum ersten Release von

Installationsvarianten 4.2

189

SAP HANA die einzige verfügbare und ist noch immer der Standard,an dem sich andere Installationsvarianten messen lassen müssen.

Abbildung 4.5 Single-Database-System

Dementsprechend sind alle in Abschnitt 4.1, »Landschaftsaufbau«,genannten Landschaftskonfigurationen für diese Installationsvari-ante zugelassen. Bei einem echten Single-Database-System läuft aufder Datenbank auch nur eine einzige Applikation, z. B. ein SAP-BW-System. Dieser Lösung stehen datenbankseitig alle Ressourcen zurVerfügung, die vom Server bereitgestellt werden. Eine solche Konfi-guration ist normalerweise auch auf Appliance-Servern zu finden.

EinsatzszenarienDa diese Installationsvariante den Standard darstellt, ist sie vor allemfür produktive Systeme zu empfehlen, solange nur eine einzigeApplikation betrieben werden soll. Ein Vorteil bei diesem Szenarioist vor allem die einfache Konfiguration. Sobald mehr als eine Appli-kation auf einer SAP-HANA-Datenbank läuft oder mehr als eine SAP-HANA-Datenbank auf einem Server betrieben werden soll, müssendagegen Maßnahmen zur Regulation der genutzten Ressourcengetroffen werden, was eine andere Installationsvariante erfordert.

Tabelle ATabelle B

…

Server und Betriebssystem

SAP-HANA-Datenbank

Schema SAP

SAP-System

4 Betriebskonzepte

190

Dies ist bei SAP HANA besonders wichtig, da die Datenbank ohneweitere Konfiguration alle zur Verfügung stehenden Ressourcennutzt und nicht auf andere Komponenten achtet.

Da für SAP HANA immer mehr Applikationen veröffentlicht werden,die auf den Daten anderer Applikationen aufbauen, wie z. B. SAPHANA Live, das die Daten eines SAP-Business-Suite-Systems auf SAPHANA nutzt, treten andere Installationsvarianten immer stärker inden Vordergrund. Dies gilt insbesondere seit der Einführung derMulti-Tenant-Database-Container, über die eine besonders strikteTrennung von Applikationen und Ressourcen innerhalb einer SAP-HANA-Datenbank möglich ist. Dennoch wird das Konzept derSingle-Database-Systeme weiterhin die Standardlösung bleiben.

4.2.2 Multiple Components One System

Der Betrieb mehrerer SAP-Systeme erfolgt meistens nicht nach demSchema »Ein System pro physischem Server«, sondern es werdenmehrere SAP-Systeme betrieben, die parallel auf einem physischenServer laufen, um die Ressourcen besser auszulasten. Dies gilt insbe-sondere für Qualitätssicherungs- und Testsysteme, die nicht auf einekontinuierlich hohe Performance und exklusive Ressourcen ange-wiesen sind.

Parallelbetriebmehrerer Systeme

Klassische SAP-NetWeaver-Systeme sind darauf ausgelegt, nebenein-ander betrieben zu werden. SAP stellte mit SAP Landscape Virtualiz-ation Management ein Tool zur Verwaltung von SAP-Landschaftenzur Verfügung, mit dessen Hilfe SAP-Systeme zwischen physischenHosts verschoben werden konnten. Die Aufteilung von Ressourcenwiderspricht dem Appliance-Konzept, auf dessen Basis SAP HANAursprünglich entwickelt wurde. Beim Appliance-Konzept nutzt eineSAP-HANA-Datenbank alle Ressourcen, die auf dem System zur Ver-fügung stehen. Zwar bringt SAP HANA die Möglichkeit mit, den Res-sourcenverbrauch einzuschränken, diese Funktion war aber langenicht für den produktiven Betrieb vorgesehen.

Inzwischen ist der Betrieb mehrerer SAP-HANA-Datenbanken aufeinem physischen Host nach dem Prinzip Multiple Components OneSystem (MCOS) sowohl für Qualitätssicherungs- und Testsysteme alsauch für Produktivsysteme von SAP zugelassen. Abbildung 4.6 ver-anschaulicht eine entsprechende Architektur.


191

Szenarien für das Prinzip »Multiple Components One System«

SAP-Hinweis 1681092 beschreibt die zulässigen Szenarien und die damitverbundenen Einschränkungen für den Betrieb mehrerer SAP-HANA-Datenbanken auf einem Server.

Abbildung 4.6 Multiple Components One System

Multi-SID-KonzeptBeim MCOS-Konzept, oft auch Multi-SID-Konzept genannt, werdenmehrere SAP-HANA-Datenbanken auf einem physischen Serverbetrieben. Die Datenbanken laufen dabei unter verschiedenen Ins-tanznummern und mit verschiedenen System-IDs (SIDs). Da diemeisten Parameter in SAP HANA, die die Interaktion der Datenbankmit externen Entitäten beeinflussen (wie z. B. Portnummern, Ver-zeichnisstrukturen o. Ä.), entweder die Instanznummer oder die SIDmit einbeziehen, lassen sich mehrere SAP-HANA-Datenbanken rela-tiv leicht nebeneinander installieren, ohne dass diese sich in dieQuere kommen.

Instanznummern und SIDs in Portnummern und Verzeichnisstrukturen

Die Abhängigkeit von den Instanznummern und den SIDs erkennt manz. B. an den verwendeten Portnummern von SAP HANA (300 bis 399) oder der Verzeichnisstruktur der SAP-HANA-Installation (/usr/sap//… etc.).

Vor- und NachteileDer MCOS-Betrieb erfordert zusätzlichen Aufwand, da die zur Verfü-gung stehenden Ressourcen wie Arbeitsspeicher, Festplattenspeicheroder CPU-Zeit auf die verschiedenen SAP-HANA-Systeme verteilt

SAP-System SAP-System

SAP-HANA-Datenbank SAP-HANA-Datenbank

Tabelle A

Tabelle B

…

Schema SAP


Tabelle A

Tabelle B

…

Schema SAP

4 Betriebskonzepte

192

werden müssen. Eine Überprovisionierung von Ressourcen ist nichtmöglich.

Im Gegensatz zu anderen Ansätzen, bei denen mehrere SAP-HANA-Systeme auf einem Server betrieben werden sollen, bietet MCOS eineextrem starke Trennung von Daten und Ressourcen. Da die verschie-denen SAP-HANA-Datenbanken vollständig unabhängig betriebenwerden können, gilt das Gleiche für die Applikationen, die auf den Da-tenbanken laufen. Allerdings bringen die fehlenden Abhängigkeitenauch einen Mehraufwand mit sich, da zum einen mehrere Datenban-ken betrieben werden müssen und zum anderen zusätzliche Konfigu-ration notwendig ist. Es muss festgelegt werden, welche SAP-HANA-Datenbank wie viel Arbeitsspeicher und welche logischen Prozessor-kerne erhält. Da keine Überprovisionierung erlaubt ist, gestaltet sicheine optimale Ressourcenverteilung schwierig, insbesondere, wenndie Datenbanken um die verfügbaren Ressourcen konkurrieren.

Beachten Sie auch, dass sich eine Fehleranalyse komplexer und kom-plizierter gestaltet, da Störeinflüsse zwischen den Datenbanken trotzder tief gehenden Trennung auftreten können. Deswegen kann esvorkommen, dass der SAP-Support Sie bei Störungen oder Perfor-mance-Problemen bittet, alle SAP-HANA-Datenbanken bis auf eineherunterzufahren, um Fehler eingrenzen zu können.

Der MCOS-Ansatz spielt seine Vorzüge vor allem aus, wenn mehrereSAP-HANA-Systeme parallel betrieben werden sollen, auf denenApplikationen mit unterschiedlichen Anforderungen laufen sollen.

Wenn ein Appliance-Server nicht vollständig von einer einzigenSAP-HANA-Datenbank ausgelastet wird, kann dieser durch denMCOS-Ansatz besser ausgenutzt werden. Wenn die unterschiedli-chen Applikationen, die auf den SAP-HANA-Datenbanken laufen sol-len, grundlegend verschiedene Anforderungen an die Datenbankenstellen, weil sie z. B. verschiedene Versionen erfordern, ist diese In-stallationsvariante alternativlos, außer ein zweiter Appliance-Serversteht zur Verfügung.

Freigabe imProduktivbetrieb

Das MCOS-Konzept ist seit SAP HANA SPS 05 für nicht-produktiveSzenarien freigegeben. Hier wird vor allem auf das Szenario »einAppliance-Server für das Produktivsystem und ein Appliance-Serverfür das Qualitätssicherungs- und das Testsystem« abgezielt. Seit SAPHANA SPS 10 wird MCOS auch für produktive Systeme unterstützt.


193

Neue Parameter, die mit diesem Release eingeführt wurden, ermög-lichen eine bessere Aufteilung der Serverressourcen.

ImplementierungZur Implementierung des Konzepts werden mehrere SAP-HANA-Systeme mit unterschiedlichen SIDs und Instanznummern auf einemServer installiert. Im Anschluss müssen die einzelnen Systeme sokonfiguriert werden, dass keine Ressourcen doppelt allokiert sind.Die Größe jedes Systems wird dabei wie die eines normalen Single-Database-Systems berechnet.

EinsatzszenarienAuf SAP-HANA-Systemen, die nach dem MCOS-Ansatz eingerichtetwurden, dürfen beliebige Applikationen installiert werden. DerMCOS-Ansatz darf mit dem Multi-Tenant-Betriebskonzept kombi-niert werden, sodass auf einem physischen Server mehrere SAP-HANA-Systeme, jeweils mit mehreren Tenants, installiert werden.Dieser Ansatz sollte aufgrund der komplexen Konfiguration nur vonerfahrenen Datenbankadministratoren umgesetzt werden.

Der MCOS-Ansatz ist insbesondere für nicht-produktive Systemewie Qualitätssicherungs- und Testsysteme interessant, da bei diesendie Performance in der Regel nicht kritisch ist. Sollte jedoch für einesder Systeme mehr Performance-Leistung erforderlich sein, könnenSie diesem über eine Rekonfiguration mehr Ressourcen zuweisen.Dadurch können leicht Kosten eingespart werden.

Kompatible Landschafts-konzepte

Der MCOS-Ansatz darf für alle in diesem Kapitel beschriebenenLandschaftskonzepte, bis auf Multi-Node-Systeme (Scale-out-Sys-teme), eingesetzt werden. Auf einem Multi-Node-Server ist MCOSvon SAP im Moment noch nicht für den produktiven Betrieb zuge-lassen.

Solange Applikationen mit verschiedenen Revisionsanforderungenan SAP HANA kostengünstig parallel betrieben werden sollen, gibtes keine Alternativen zum MCOS-Betrieb.

4.2.3 Multiple Components One Database

Wenn nur geringe Anforderungen an die Trennung der Daten zwi-schen Applikationen bestehen oder sogar eine anwendungsübergrei-fende Datenhaltung notwendig ist, müssen mehrere Applikationenauf der gleichen Datenbank installiert werden. Dieser Ansatz wirdvon SAP Multiple Components One Database (MCOD) genannt und istin Abbildung 4.7 illustriert. Die Applikationen, die beim MCOD-

4 Betriebskonzepte

194

Ansatz auf einer Datenbank installiert werden, können, müssen abernicht auf die Daten anderer Applikationen zugreifen.

Abbildung 4.7 Multiple Components One Database

Einsatzszenarien Dieser Ansatz kommt in der Regel für zwei Anwendungszwecke zumEinsatz:

� wenn mehrere Applikationen mit einem geringen Overheadnebeneinander betrieben werden sollen, aber keine Notwendig-keit für eine starke Trennung auf Datenbankebene besteht (z. B.verschiedene Webapplikationen, die SAP HANA als Datenbanknutzen und ihre Daten in verschiedenen Schemata ablegen)

� wenn mehrere Applikationen nebeneinander betrieben werden,die auf die Daten der anderen Applikationen zugreifen

Der am häufigsten auftretende Anwendungsfall ist wahrscheinlichdie Kombination SAP-NetWeaver-basierter Informationssysteme mitzusätzlichen Applikationen, die ebenfalls von SAP bereitgestellt wer-den. Beispiele dafür sind etwa Systeme der SAP Business Suite aufSAP HANA, auf deren Datenbank der SAP HANA Live Content instal-liert wird.

Architektur Der Aufbau des Parallelbetriebs mehrerer Applikationen auf einerSAP-HANA-Datenbank ist von den Applikationen selbst abhängig.Grundsätzlich kann aber gesagt werden, dass in jedem Fall eine auf-wendige Konfiguration vorgenommen werden muss, um sowohl dieBerechtigungen für die verschiedenen Datenbankobjekte richtig zusetzen als auch das Workload Management an die verschiedenenLastprofile anzupassen.



SAP-HANA-Datenbank

Tabelle A

Tabelle B

…

Schema SAP

Tabelle A

Tabelle B

…

Schema SAP


195

Falls Sie SAP-Software auf dem SAP-HANA-System betreiben möch-ten und für diese Lösungen den SAP-Support nutzen möchten, geltengewisse Einschränkungen hinsichtlich des MCOD-Betriebs. Auf einerSAP-HANA-Datenbank dürfen nur Applikationen zusammen betrie-ben werden, die auf einer Whitelist aufgeführt sind, die von SAPgepflegt wird. Die ständig aktualisierte Whitelist finden Sie in SAP-Hinweis 1661202. Der Hinweis beschreibt alle erlaubten Szenarienund Einschränkungen, die im Zusammenhang mit MCOD existieren.

EinschränkungenDie Einsatzgebiete für den MCOD-Ansatz sind dementsprechendeingeschränkt. So ist diese Konfiguration nur dann sinnvoll, wennSAP HANA als Applikationsplattform eingesetzt wird oder die ver-schiedenen zugelassenen SAP-Applikationen parallel betrieben wer-den. Im ersten Fall würden verschiedene Eigenentwicklungen paral-lel auf einem SAP-HANA-System laufen, um von dessen Funktionenzu profitieren. Weil dann der Support beim Anwendungsentwicklerund nicht bei SAP liegt, gelten nur die Einschränkungen der Applika-tion selbst.

Der zweite Anwendungsfall, also der parallele Betrieb mehrerer SAP-Applikationen auf einem SAP-HANA-System, wird in Zukunft häufi-ger auftreten. Das liegt an den Vorteilen, die sich durch die anwen-dungsübergreifende Datenhaltung ergeben. Durch anwendungs-übergreifende Datenhaltung entfällt die Notwendigkeit einesDatenladeprozesses und einer doppelten Datenhaltung. Darüber hin-aus sind alle Daten, auf die zugegriffen wird, live. Ein Beispiel fürsolche Applikationen sind analytische SAP-Fiori-Apps, die sowohlauf den Applikationsserver eines SAP-Business-Suite-Systems aufSAP HANA zugreifen als auch direkt auf die Daten des SAP-HANA-Systems, auf dem die SAP-Business-Suite-Anwendung läuft.

Vor- und NachteileIm Gegensatz zu anderen Betriebskonzepten, bei denen mehrereApplikationen auf SAP HANA betrieben werden sollen, bietet dieseLösung den geringsten Overhead, da nur eine einzige SAP-HANA-Datenbank betrieben werden muss. Allerdings sollten Sie beachten,dass der geringe Overhead und die damit verbundene Kostenerspar-nis durch eine höhere Betriebskomplexität erkauft werden.

Falls unabhängige Anwendungen parallel betrieben werden sollen,bietet der MCOD-Ansatz im Wesentlichen zwei Vorteile: zum einenden geringen Overhead pro Applikation für das SAP-HANA-Systemselbst, der je nach Revision zwischen 6 und 20 GB betragen kann.

4 Betriebskonzepte

196

Zum anderen wird der Administrationsaufwand reduziert, da nureine einzige Datenbank verwaltet werden muss.

Diesen Vorteilen stehen jedoch schwerwiegende Nachteile gegen-über. Wenn unabhängige Applikationen auf einer einzigen SAP-HANA-Datenbank laufen sollen, muss zunächst einmal ein korrektesBerechtigungskonzept ausgearbeitet und implementiert werden, dasdafür sorgt, dass keine Applikation Zugriff auf die Daten der anderenApplikationen hat. Falls SAP HANA als reine Datenbank genutztwird, ist diese Aufgabe noch durchführbar, wenn auch mit hohemAufwand verbunden. Sollen allerdings alle Funktionen von SAPHANA genutzt werden, erhöht sich die Komplexität drastisch. Dazukommt, dass eine Ressourcentrennung zwischen den Applikationennur über das seit SAP HANA SPS 10 verfügbare Workload Manage-ment durchgeführt werden kann. Schließlich müssen Sie beachten,dass alle administrativen Funktionen der Datenbank wie z. B. Moni-toring, Backup und Recovery nur für die gesamte Datenbank ausge-führt werden können und nicht für jede Applikation.

Der MCOD-Ansatz wird in Zukunft weiterhin bestehen und oft ein-gesetzt werden, insbesondere durch Applikationen, die neben SAP-NetWeaver-basierten Informationssystemen laufen und auf dieDaten dieser Informationssysteme zugreifen. Für den Betrieb mehre-rer unabhängiger Applikationen rechnet sich in Zukunft immer mehrder Multi-Tenant-Database-Container-Ansatz, den wir im folgendenAbschnitt beschreiben, insbesondere wenn hier der Overhead fürneue Tenants weiter reduziert wird.

4.2.4 Multi-Tenant-Database-Container

»Mandanten-fähigkeit«

Seit SAP HANA SPS 09 gibt es noch ein weiteres Betriebskonzept, dasauf der Datenbankebene ansetzt und sich mit anderen Konzeptenkombinieren lässt: Multi-Tenant-Database-Container (MDC). Mit die-sem Konzept macht SAP die SAP-HANA-Datenbank mandantenfähig,d. h., dass unterschiedliche Applikationen auf demselben SAP-HANA-System laufen können, ohne dass sich die Applikationengegenseitig sehen und beeinflussen können. Ein schematischer Auf-bau dieses Modells ist in Abbildung 4.8 zu sehen. Im Gegensatz zurMandantenfähigkeit in SAP-NetWeaver-basierten Systemen geht dietechnische Implementierung bei SAP HANA wesentlich weiter.


197

Abbildung 4.8 Multi-Tenant-Datenbanksystem

Getrennte TenantsIn einem Multi-Tenant-SAP-HANA-System sind die einzelnen Man-danten, im SAP-HANA-Jargon Tenants genannt, auf Betriebssystem-prozessebene getrennt. Diese Trennung auf einem sehr niedrigenLevel hat viele Implikationen für den Betrieb, z. B. die Möglichkeit,einzelne Tenants unabhängig voneinander zu starten, zu stoppen, zusichern und wiederherzustellen. Das Konzept ermöglicht auch, ver-schiedene SAP-Systeme auf unterschiedlichen Tenants der Daten-bank zu betreiben und unterschiedlich zu behandeln. Die einzigenKomponenten, die sich mehrere Tenants auf einer Datenbank teilen,sind alle grundlegenden Funktionen der Datenbank wie die Topolo-gie etc. Diese Funktionen sind in einen eigenen Tenant ausgelagert,sodass man effektiv eine Trennung zwischen Systembetrieb undDatenhaltungssystemen erreicht.

Kombination mit anderen Betriebs-konzepten

Das MDC-Konzept stellt weniger einen Gegenentwurf zu anderenBetriebskonzepten dar, sondern erweitert diese vielmehr. Geradewenn man eine klassische Appliance ohne Virtualisierung betreibenmöchte, aber mehr als ein SAP-HANA-System benötigt, ist ein MDC-System ein gangbarer Weg, solange die technische Basis aller SAP-HANA-Systeme gleich sein kann.

Multi-Tenant-Database-Container sind seit SAP HANA SPS 09 verfüg-bar, aber in diesem Release nur über SQL zu bedienen. Seit SPS 10wurden verschiedene Interfaces im SAP HANA Cockpit implemen-tiert, die grundlegende Operationen wie das Erstellen eines Tenantsvereinfachen (siehe Abschnitt 5.1.3, »Gruppe ›SAP HANA System



SAP-HANA-Datenbank

Tabelle A

Tabelle B

…

Schema SAP

System-datenbank

Schema SAP

Tabelle A

Tabelle B

…

4 Betriebskonzepte

198

Administration‹«). Zusätzlich wurde mit diesem Release eine strik-tere Trennung der Tenants implementiert, bei der jeder Tenant miteinem separaten Betriebssystemnutzer betrieben wird. Ein weitererAusbau der Technologie ist für die Zukunft geplant.

Systemdatenbank Ein SAP-HANA-MDC-System enthält mindestens den Tenant derSYSTEMDB. Dieser Tenant, die Systemdatenbank, ist für die Verwaltungder SAP-HANA-Datenbank und aller anderen Tenants zuständig undenthält auch die Datenbanktopologie, die dafür notwendigen Prozesseund Administrationswerkzeuge. Im Gegensatz zu anderen Tenants istdie SYSTEMDB nicht für die applikative Nutzung vorgesehen.

Weitere Tenants Zusätzlich kann eine beliebige Anzahl weiterer Tenants (manchmalauch Databases genannt) für das SAP-HANA-System vom TenantSYSTEMDB aus erstellt werden. Jeder dieser Tenants besteht aus einemeigenen indexserver-Prozess inklusive der eingebetteten Prozessestatisticsserver und xsengine. Das bedeutet, dass alle Tabellen,Schemata, Benutzer und andere Objekte auf jedem Tenant existierenund dass sich jeder Tenant wie eine separate SAP-HANA-Datenbankverhält. Weitere Informationen zu dieser Architektur erhalten Sie inAbschnitt 2.2.3, »Multiple-Container-Systeme«.

Zugriff aufandere Tenants

Ein Zugriff von einem Tenant auf einen anderen (Cross-Tenant Access)ist möglich, muss aber explizit aktiviert und auf beiden Tenants kon-figuriert werden. Im Moment ist ausschließlich ein lesender Zugriffmöglich, für die Zukunft ist auch ein Schreibzugriff geplant. Die Kon-figuration der Tenants erfolgt über die SYSTEMDB, kann aber zu Teilenauch an die Tenants selbst delegiert werden, um Tenant-Administra-toren mehr Gestaltungsfreiheit zu geben.

Die Aktivierung des MDC-Konzepts kann entweder bei der Installa-tion des SAP-HANA-Systems erfolgen oder zu einem späteren Zeit-punkt nachgeholt werden (etwa bei der Migration eines Single-Data-base-Systems zu einem MDC). Beachten Sie, dass eine Umwandlungeines MDC-Systems zu einem Single-Database-System nicht möglichist.

Einschränkungen Für die Applikationen, die in Multi-Tenant-Database-Containern lau-fen, gibt es in der Regel keine Einschränkungen. Das Sizing für jedenContainer sollte jedoch so durchgeführt werden wie das Sizing fürein Single-Database-System. Auch wenn das MDC-Konzept bereitsfür die SAP Business Suite und SAP BW freigegeben ist, sollten Sie


199

dessen Einsatz und das Sizing konservativ angehen, da die Technolo-gie noch relativ neu ist.

Zurzeit rät SAP, Szenarien, die bisher nach dem MCOD-Konzept lie-fen, auf das MDC-Modell zu migrieren. Langfristig sind aber ver-schiedene Szenarien mit mehreren Informationssystemen, dienebeneinander laufen, vorstellbar. Insbesondere mit der Möglich-keit, Lesezugriffe zwischen einzelnen Tenants und damit auch zwi-schen den Informationssystemen einzurichten, bestünde viel Poten-zial.

Vor- und NachteileAuch wenn solche Szenarien noch nicht unbedingt für den Durch-schnittsbenutzer empfehlenswert sind, weist das MDC-Konzeptbereits verschiedene Vorteile auf, die beim Betrieb von mehr alseinem SAP-HANA-System zum Tragen kommen. So muss, solange alleApplikationen auf der gleichen SAP-HANA-Revision laufen, nur eineinziges SAP-HANA-System betrieben werden. Jede Applikation kanndann in einem eigenen Tenant isoliert von allen anderen Applikatio-nen laufen, wobei viele Aufgaben des Systembetriebs nur noch eineinziges Mal für das gesamte System durchgeführt werden müssen.

Daraus resultierend ist es auch möglich, jede Applikation unabhän-gig von den anderen zu sichern (Backup) und wiederherzustellen(Recovery). Dies ist insbesondere gegenüber dem MCOD-Modell einwesentlicher Vorteil.

Es müssen jedoch auch einige Nachteile für den Betrieb beachtetwerden. Zum einen bedeutet die Reduktion der Anzahl der Systeme,dass ein Single Point of Failure geschaffen wird, der vorher nichtbestand (außer beim MCOD-Ansatz). Hier muss das Ausfallrisikogegen die zu erwartenden Auswirkungen abgewogen werden.Gleichzeitig sind Änderungen an der SAP-HANA-Datenbank selbst,also z. B. die Installation von Komponenten oder ein Upgrade desSystems, nur noch möglich, wenn sie keine negativen Auswirkungenauf alle Applikationen haben.

Für die Zukunft plant SAP, das Konzept der Multi-Tenant-Database-Container weiter auszubauen und sowohl Funktionen für Tenant-Kopien als auch für Tenant-Umzüge sowie für den Cross-ClientAccess mit Schreibzugriff einzuführen. Die nächsten größeren Inno-vationen für MDC sind für SAP HANA SPS 12 geplant.

25

Kapitel 1

Bevor wir uns in diesem Buch mit der Administration von SAP HANA beschäftigen, bringen wir Ihnen in diesem Kapi-tel zunächst die technologischen Grundlagen und einige wei-tere Facetten von SAP HANA näher.

1 Einführung

Bevor wir uns in diesem Buch auf die Administration und denBetrieb von SAP HANA konzentrieren und im Detail auf die Techno-logie der Plattform eingehen, werfen wir in diesem Kapitel zunächsteinen Blick auf einige Aspekte des In-Memory Computings als techno-logischer Grundlage von SAP HANA. Dieser Begriff wird oft in einemAtemzug mit SAP HANA genannt. Außerdem stellen wir Ihneneinige grundlegende Eigenschaften von SAP HANA in diesem Kapitelvor.

Wenn Sie sich mit diesen Themen bereits beschäftigt haben, könnenSie dieses Grundlagen-Kapitel auch überspringen und mit dem fol-genden Kapitel direkt tiefer in die Architektur von SAP HANA ein-steigen.

Was ist In-Memory Computing?

Primär besagt In-Memory Computing, dass die Datenverarbeitung zueinem großen Teil bzw. vollständig im Hauptspeicher eines Compu-ters durchgeführt wird. Es bei dieser Definition zu belassen würdedie Merkmale des In-Memory Computings jedoch nicht ausreichenderfassen. Wie bei vielen Begriffen in der Informationstechnologiegibt es aber auch hier keine eindeutige Beschreibung.

Hohe Verarbeitungs-geschwindigkeit

Eines der wesentlichen Merkmale von Datenverarbeitungssoftwareim Umfeld des In-Memory Computings ist die in der Regel höhereVerarbeitungsgeschwindigkeit im Vergleich zu anderen Implementie-rungen. Im Wesentlichen liegt diese Verarbeitungsgeschwindigkeitdaran, dass die der Datenverarbeitung zugrunde liegenden Daten imPrimärspeicher, also dem Hauptspeicher, vorgehalten werden.

1 Einführung

26

Die wesentliche Voraussetzung dafür, der Hauptspeicher, wurde inden letzten Jahren einerseits wesentlich günstiger und andererseitsje Server in größeren Mengen verfügbar. Verallgemeinernd kannman sagen, dass die Preise für Hauptspeicher in den letzten zehn Jah-ren auf ca. ein Fünftel des damaligen Wertes gesunken sind. Auchdie Ausstattung der Server bezüglich des Hauptspeichers in Rechen-zentren stieg in den zurückliegenden Jahren stark an.

Damit ist zwar nicht automatisch jeder Rechner für In-Memory Com-puting geeignet, aber doch eine wesentliche Voraussetzung erfüllt.Die notwendige Hardware ist einerseits technisch und andererseitserschwinglich verfügbar.

Durch die Datenhaltung im Hauptspeicher verringern sich, vergli-chen mit der Datenverarbeitung und dem Zugriff auf den Festplat-tenspeicher, die Zugriffszeiten auf die Daten in der Regel von Milli-auf Nanosekunden. Das bedeutet, dass im gleichen Zeitraum einVielfaches mehr Daten abgerufen und verarbeitet werden kann.

SpaltenorientierteDatenspeicherung

Die In-Memory-Technologie darauf zu reduzieren reicht aber, wieeingangs erwähnt, nicht aus. Mit dem Performance-Gewinn durchdie primäre Nutzung des Hauptspeichers gehen auch wesentlicheandere Paradigmenwechsel einher. Beschäftigt man sich mit dem In-Memory Computing und legt wie wir einen speziellen Fokus auf SAPHANA, trifft man schnell auf den Begriff Column-oriented Storage Lay-out, also die spaltenorientierte Speicherung von Daten. Im Gegensatzzu relationalen Datenbanken, die ihre Daten in Tabellen und zeilen-weise organisieren und speichern, werden die Daten bei diesem Lay-out spaltenweise abgelegt. Grundsätzlich sind die Daten sowohl beider zeilen- als auch bei der spaltenorientierten Datenhaltung logischin Tabellen organisiert. Tabelle 1.1 verdeutlich das anhand eines Bei-spiels.

Die Tabelle zeigt eine beispielhafte Kundenliste. Die zeilenorien-tierte Speicherung der Daten würde nach diesem Beispiel dem fol-genden Muster folgen:

400;Müller;DE;414;Martineau;FR;428;Voncken;NL;432;Bédard;CA

Bei einer spaltenorientierten Speicherung werden die Daten dagegennach ihren Spalten abgelegt:

400;414;428;432;Müller;Martineau;Voncken;Bédard;DE;FR;NL;CA

Einführung 1

27

Gerade bei einem lesenden und insbesondere bei einem analyti-schen Zugriff auf die Daten zeigt die spaltenorientierte Speicherungihre Stärken. Dies hängt unter anderem damit zusammen, dass die inBlöcken gespeicherten Daten bei einer Abfrage zusammenhängendim Cache eines Prozessors des Rechners zur Verfügung gestellt undvom Prozessor selbst verarbeitet werden können.

Die Trefferrate der Daten, die so schon im Cache des Prozessors vor-handen und für die weitere Verarbeitung relevant sind, ist meisthöher. Es müssen also insgesamt weniger Blöcke aus dem Hauptspei-cher geladen werden, was letztlich insgesamt eine schnellere Daten-verarbeitung ermöglicht.

Dictionary Encoding

Die Art der Datenspeicherung begünstigt auch die effiziente Speiche-rung von Daten. Einen wesentlichen Effekt erzielt SAP HANA bei derDatenspeicherung durch die sogenannte Dictionary Encoding. DieWerte in einer Spalte werden durch eindeutige Nummern ersetzt,die in der Regel mit weniger Speicherverbrauch abgelegt werdenkönnen. Die Darstellung der Tabelle 1.1 würde sich also dahinge-hend ändern, dass Werte der Spalten Name und Land durch eindeu-tige Zahlen ersetzt werden und zu jeder Spalte sozusagen eineLegende gepflegt wird. Als Beispiel ziehen wir in Tabelle 1.2 dazueine Erweiterung der Tabelle 1.1 hinzu:

Kundennummer Name Land

400 Müller DE

414 Martineau FR

428 Voncken NL

432 Bédard CA

Tabelle 1.1 Beispielhafte Kundenliste

Kundennummer Name Land Kundennummer Name Land

400 Müller DE 446 Müller DE

414 Martineau FR 450 Müller NL

428 Voncken NL 464 Voncken FR

432 Bédard CA 478 Bédard CA

Tabelle 1.2 Erweiterte Beispieltabelle mit Kunden

1 Einführung

28

Im Rahmen der Codierung werden die Werte der Spalten ersetzt, wiebeschrieben (siehe Tabelle 1.3), und die zugehörigen Werte werdenzusätzlich gespeichert (siehe Tabelle 1.4 und Tabelle 1.5).

WarumSAP HANA?

SAP HANA wuchs im Laufe der letzten Jahre von einer reinen Daten-bank zu einer Plattform heran, die mit zusätzlichen Funktionen,Komponenten und Anwendungen vielseitige Szenarien ermöglicht.Auch ist SAP HANA inzwischen eine Basis für die SAP-Kernanwen-dungen der SAP Business Suite und die neue UnternehmenssoftwareSAP S/4HANA.

Kundennummer Name Land

400 1 1

414 2 2

428 3 3

432 4 4

446 1 1

450 1 3

464 3 2

478 4 4

Tabelle 1.3 Codierte Tabelle

Nummer Name

1 Müller

2 Martineau

3 Voncken

4 Bédard

Tabelle 1.4 Werte der Spalte »Name«

Nummer Land

1 DE

2 FR

3 NL

4 CA

Tabelle 1.5 Werte der Spalte »Land«

Einführung 1

29

Die Abkürzung HANA stand ursprünglich für High Performance Ana-lytic Appliance. Mit SAP HANA können Szenarien umgesetzt werden,die zuvor entweder nicht möglich oder nicht sinnvoll umsetzbarwaren. Die Verarbeitung und Analyse von Datenmengen, die demBereich Big Data zuzuordnen sind, in Sekundenbruchteilen, Sekun-den oder Minuten anstelle von Minuten, Stunden oder Tagen lässtneue Denkansätze und Softwareanwendungen zu.

Mit prominenten Beispielen zeigte SAP gemeinsam mit seinen Part-nern die Möglichkeiten dieser neuen Plattform, z. B. im Umfeld derGesundheitsbranche. Die individuelle Analyse von bis zu zwei Tera-byte Daten pro Patient helfen Krankenhäusern und Ärzten z. B.,Krankheiten besser zu diagnostizieren und die Behandlung besserauf den jeweiligen Patienten abzustimmen.

Echtzeitdaten-verarbeitung

Ein weiteres Schlagwort in diesem Zusammenhang ist die Datenver-arbeitung in Echtzeit (Realtime). Durch einen direkten Blick auf dieaktuellen Daten eines Unternehmens können Unternehmen direktund schneller reagieren. Das Berichtswesen kann so beschleunigtwerden und liefert einen Blick auf den Ist-Zustand des jeweiligenUnternehmens ohne Wartezeiten auf Aggregate. Damit ergeben sichneue Möglichkeiten für die Unternehmenssteuerung und die Gestal-tung von Prozessen.

Der Bericht The Forrester Wave des Forschungsinstituts Forresterstellte im dritten Quartal 2015 SAP HANA als eine der führenden –wenn nicht sogar die führende – In-Memory-Plattform dar. Seit derMarkteinführung im Jahr 2011 kann SAP inzwischen über 7.000Kunden für SAP HANA zählen. Die Nutzung von SAP HANA erfolgthier nicht nur für SAP Business Warehouse, die SAP Business Suiteoder SAP S/4HANA, sondern auch neue Nicht-SAP-Anwendungenkommen verstärkt ins Spiel.

In den letzten Jahren sind aufbauend auf der SAP-HANA-Plattformverschiedene zusätzliche Anwendungen ents

Documents

SAP HANA – Administration · SAP HANA ist seit der ersten Version der Datenbank als Multi-Node-Verfügbarkeit System verfügbar und wird kontinuierlich weiterentwickelt. Im Gegensatz