Monatsarchiv: Februar 2019

Mit SAP HANA 2.0 SP01 ist der Betriebsmodus der Multi Database Containers (MDC) der einzige aktiv empfohlene Betriebsmodus, mit der Ausnahme, dass innerhalb einer Tenant Datenbank auch noch ein MCOD-Szenario abgebildet werden kann. Wenn Ihnen bis hier schon schwindlig geworden ist, Sie ein Upgrade von SAP HANA 1.0 auf SAP HANA 2.0 vornehmen wollen, oder sich generell für die Betriebsmodi von SAP HANA gleich welchen Releases interessieren, möchte ich Sie an dieser Stelle abholen. Multiple Components on HANA – was heißt das? Sie können auf einem einzigen SAP HANA Datenbankserver mehrere Applikationen betreiben. So könnte es beispielsweise sein, dass Sie nur einen einzigen SAP HANA Datenbankserver installiert haben, auf diesem jedoch sowohl ein SAP ERP on HANA als auch ein SAP BW on HANA betrieben wird. Der Hersteller SAP bietet hierzu verschiedene Szenarien: Multiple Components on One System (MCOS), Multiple Components on one Database (MCOD) und Multitenant Database Containers (MDC). Einfach gesagt ist der Unterschied zwischen diesen Betriebsmodi folgender: Bei Multiple Components on One System (MCOS) installieren Sie auf einem einzigen Betriebssystem mehrere SAP HANA Datenbankserver. Es sind also im Endeffekt zwei sogenannte Instanzen, die jedoch auf ein und dem selben physikalischen oder virtualisierten Betriebssystem laufen. Bei Multiple Components on One Database (MCOD) laufen die beiden Applikationen nicht nur auf dem selben SAP HANA Datenbankserver bzw. der selben SAP HANA Instanz, sondern auch noch in der selben Datenbank. Eine Trennung wird hierbe auf Schema-Ebene realisiert. Das heißt, die Applikationen teilen sich gemeinsame Datenbankkomponenten, wie etwa die Datenbankuser, die Persistenz und die Konfigurationsparameter. Die Daten sind jedoch nach Schema getrennt und der Zugriff auf diese Daten wird auch auf Schema-Ebene über Berechtigungen geregelt. Bei Multitenant Database Containers (MDC) haben Sie innerhalb einer SAP HANA Instanz mehrere sogenannte Tenant Datenbanken. Sie können sich die SAP HANA Instanz hierbei wie ein Mietshaus vorstellen, in dem mehrere Mieter (die Tenant Datenbanken) einziehen können. Dabei können diese Mieter einziehen (eine neue Tenant Datenbank kommt hinzu), aber auch ausziehen (eine Tenant Datenbank wird gelöscht bzw. in eine andere Instanz verschoben). Jede Tenant Datenbank hat ihre eigenen User, ihre eigene Persistenz und ihre eigenen Konfigurationsparameter. SAP HANA 2.0 – Wie funktioniert Multitenancy. Wichtig zu verstehen ist, dass Sie sich nur dann noch gegen MDC entscheiden können, solange Sie unterhalb von SAP HANA 2.0 SPS01 operieren. Ab SAP HANA 2.0 SPS01 gibt es nur noch den Operationsmodus &bdquo;Multitenant Database Containers“ (MDC) gemäß SAP Note 2423367. Das frühere Standard-Deployment mit nur einer Datenbank wird quasi in Zukunft so realisiert, dass es am Anfang nur eine Tenant Datenbank gibt, der aber später weitere hinzugefügt werden können. Sie können das Multitenant Database Containers Szenario auch unter HANA 2.0 mit den anderen beiden Betriebsmodi – MCOS und MCOD – kombinieren, solange Sie sich an die weiter unten diskutierten Einschränkungen halten. Jedoch gibt es nicht wirklich einen praktikablen Grund dafür, warum Sie das tun sollten. Zu Beginn einer HANA (ohne zugehörige Installation der Applikation über beispielsweise den SWPM) im Operationsmodus MDC gibt es eine SYSTEM Datenbank und noch keine einzige Tenant Datenbank. Die erste Tenant Datenbank müssen Sie erst erstellen. Jede einzelne Tenant Datenbank bekommt ihr eigenes Port-Mapping, mit der sie die Datenbank auf ISO/OSI Layer 4 ansprechen können. Standardmäßig können Sie maximal die Ports für 20 Tenant Datenbanken reservieren, weswegen es ohne weitere Konfiguration ein Limit von 20 Tenant Datenbanken auf der MDC Instanz gibt. Sie können jedoch durch entsprechende Konfigurationsschritte weitere Ports reservieren und damit die Limitierung übergehen (SAP Note 2101244). Es gibt derzeit ein theoretisches Limit von 2000 Tenants (Quelle: SAP note 2104291). Auf der System-Datenbank läuft der Nameserver. Über diesen Port erreichen sie also datenbankübergreifend zentrale technische Komponenten wie das Monitoring der HANA-Systemlandschaft sowie die Konfiguration der HANA Instanz. Alle HANA-Prozesse, die keine datenbankbezogenen Informationen persistieren, laufen auf der zentralen Systemdatenbank. Darunter zählen neben dem Nameserver beispielsweise der Compileserver und der Preprocessor Server, nicht jedoch der Indexserver und die XS-Engine. Die datenbankbezogenen Informationen werden also in den Prozessen der jeweiligen Tenant Datenbank verwaltet und sind daher nicht über die Systemdatenbank erreichbar. Die zentrale Systemdatenbank verfügt jedoch über ihren eigenen Indexserver, den sogenannten Master Indexserver. Die SAP HANA Datenbank hat im MDC Szenario einen integrierten HDB Web Dispatcher, der die eingehenden HTTP Requests zuverlässig an die jeweilige SAP HANA XS Engine der jeweiligen Datenbank weiterleitet. Hinweis: Dieser Web Dispatcher ersetzt natürlich nicht den Einsatz eines Reverse Proxys in Ihrer demilitarisierten Zone, wenn Sie aus dem öffentlichen Internet auf die XS Engine zugreifen wollen. Sie können sich sicher vorstellen, dass die Multitenancy von Hause aus einen Performancevorteil, aber auch gleichzeitig ein Sicherheitsbedenken mit sich bringt: Da alle Datenbanken auf der selben Instanz sind, ist es sehr performant und daher opportun, Daten zwischen den einzelnen Tenant Datenbanken auszutauschen. Noch wie wäre es etwa so einfach gewesen, zwischen einem ERP- und einem CRM-System Materialsätze auszutauschen. Andererseits könnte dies natürlich ein Problem für die Informationssicherheit darstellen. Deswegen können Sie den sogenannten Cross-Tenant Access konfigurieren. Der SAP Hinweis 2196359 bietet Ihnen hierzu die notwendige Unterstützung. Überblick über die SAP HANA Deployment Szenarien. Zunächst einmal zeige ich die einzelnen Optionen im Detail auf. Die Abbildung visualisiert die Unterschiede zwischen den verschiedenen Szenarien. Multitenant Database Containers (MDC) Einziges Szenario, in welchem mehrere Datenbanken auf einer einzigen HANA Instanz laufen. einziges Szenario, in welchem mehrere BW Systeme auf der selben Datenbank laufen dürfen (SAP Note 1666670) In diesem Szenario sind nicht nur die Daten getrennt, sondern auch die Datenbank-Benutzer. Jede Datenbank hat ihre eigenen User. Durch ein Mapping der User vom Quell-Tenant zum Ziel-Tenant wird ein Cross-Tenant Lesezugriff möglich. Für jede Datenbank können Ressourcen allokiert werden (CPU + RAM, aber nicht I/O und Netzwerkbandbreite) Häufig ausgewählt von Cloud Anbietern, die auf einer einzigen HANA Installation mehrere Kunden bedienen wollen. Wartung nur noch auf einer einzigen Instanz nötig, dafür Business Impact bei allen Anwendungen. Failover einer Anwendung bedeutet automatisch Failover aller anderen Anwendungen (All or Nothing). MCOD ist innerhalb von MDC möglich. Das heißt innerhalb einer MDC Tenant Datenbank kann wiederum ein MCOD-Szenario gefahren werden. MDC ist grundsätzlich für alle SAP-Applikationen produktiv freigegeben. Die Restriktionen bzw. die Freigabelisten aus den Notes für MCOD (SAP Note 1661202, 1826100) greifen daher NICHT für MDC, außer wenn innerhalb einer MDC Tenant Datenbank wiederum ein MCOD Szenario gekapselt wird. Sizing für MDC: Additiv, SAP Notes 1774566, 1825774, 2121768. SAP HANA HW Configuration Check muss &bdquo;pro Applikation“ durchgeführt werden. SAP Note 1943937. Jede Tenant Datenbank hat ihren eigenen Index Server, der für sich genommen (bereits ohne Daten) jeweils 8 GB RAM benötigt. SAP HANA 1.0 Standard Deployment Datenbanken müssen erst per Systemkopie in eine HANA 1.0 MDC-Datenbank kopiert werden, damit diese dort dann gebackupt und in der Zieldatenbank wiederhergestellt werden kann (SAP Note 2096000) Parameter allocationlimit und max_concurrency müssen konfiguriert werden. Einige Funktionen sind erst ab HANA 2.0 SPSXX verfügbar, SAP Note 2096000. Multiple Components in one System (MCOS), auch &bdquo;Multi-SID“ Nicht mehr empfohlen, stattdessen MDC verwenden (gemäß SAP Note 2096000) Mehrere HANA Instanzen laufen auf einem System. unter SAP HANA 1.0 damals am häufigsten genutzte Variante für den Betrieb des SAP Solution Manager 7.2 (eine Instanz für ABAP und eine für Java Stack) Nur für Produktion freigegeben bei Scale-Up Szenario, Scale-Out nicht supported (SAP Note 1681092) Scale-Out freigegeben für Non-Production. Wartung von Betriebssystem und Hardware wird vereinheitlicht, die Wartung der Datenbank ist aber getrennt und erfolgt daher doppelt. Das Allocation Limit muss für beide Instanzen konfiguriert werden, damit sich nicht eine HANA Instanz alleine sämtliche Ressourcen schnappt. Failover betrifft nur die jeweilige instanz. Multiple Components in one Database (MCOD) MCOD ist innerhalb von MDC möglich. Das heißt innerhalb einer MDC Tenant Datenbank kann wiederum ein MCOD-Szenario gefahren werden. Innerhalb einer Datenbank gibt es mehrere Schemata für die verschiedenen Applikationen. Die beiden Schemata sind in der selben Datenbank, das heißt die selben User können sich an der Datenbank anmelden, Zugriffsberechtigungen für die Schemata müssen gesteuert werden, SYSTEM User sieht beide Schemata. Nur bestimmte Applikationen dürfen zusammen in einer Datebank betrieben werden. Die hierzu konsultierenden SAP Notes sind 1661202, 1666670 (BW) und 1826100 (Suite on HANA). Steuerung der Ressourcen zwischen den Datenbanken ist nicht wirklich möglich. Sizing: additiver Approach. Freigegeben für Scale-Out. Aber: Eine Datenbank im Scale-Out bedeutet: Alle darauf laufenden Anwendungen sind automatisch Scale-Out. Backup/Recovery sowie Failover betrifft beide Applikationen. Systemkopie nicht getrennt nach Applikation möglich. Was ist empfehlenswert? MCOD, MCOS oder MDC? Die Beratung ist an dieser Stelle aus meiner Sicht mittlerweile relativ einfach. Multitenant Database Containers (MDC) ist der Betriebsmodus der...

Monatsarchiv: Februar 2019

SAP S/4HANA System Conversion: Line of Business Vorarbeiten

SAP HANA Side-by-Side Ansätze mit AnyDB

SAP HANA Betriebsmodi | MDC | MCOD | MCOS

Neueste Beiträge

Neueste Kommentare

Archive

Kategorien

Meta