SAP HANA Betriebsmodi | MDC | MCOD | MCOS

(Last Updated On: 1. 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 „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 „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 „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 Wahl. Denn spätestens wenn Sie auf SAP HANA 2.0 SPS01 oder später upgraden wollen, müssen Sie auf diesen Betriebsmodus. Sie ersparen sich also den Aufwand der späteren Konvertierung Ihrer Datenbank in die Multitenancy, wenn Sie Ihre Datenbank von Anfang an so implementieren.

Sie können zwar grundsätzlich ein MCOS oder MCOD Szenario verwenden. Z. B. könnte man über das MCOS Szenario nachdenken, wenn man explizit nicht will, dass zwei verschiedene Applikationen einen gemeinsamen Failover in der SAP HANA System Replication durchführen müssen. Auf der anderen Seite: Wenn die Datenbank-Instanz, das Betriebssystem oder die Hardware abschmiert, müssen Sie ohnehin beide Applikationen auf den Sekundärknoten wechseln.

SAP HANA MDC FAQ

In dieser Sektion beantworte ich kurz die häufigsten Fragen zu SAP HANA Multitenant Database Containters (MDC), die Kunden auf den Nägeln brennen.

FrageAntwort
Wie läuft das mit dem Sizing?Das Sizing ist einfach additiv. Das heißt, Sie führen für jede einzelne Applikation ein eigenes Sizing durch, und addieren dann die Ergebnisse. Einen Zusatz für den „Overhead“ brauchen Sie nicht einrechnen, der ist nämlich minimal. Beim Sizing müssen Sie vor allem darauf achten, dass Sie einer Applikation die richtige Anzahl an CPU Sockets zuweisen.
die SAP empfiehlt Ihnen jedoch, bei SAP BW bzw. BW/4HANA nicht all zu viele zusätzliche Applikationen an die HANA Instanz anzubinden. Eine genaue Zahl wird jedoch nicht genannt (SAP Note 2121768).
Wie ist das mit dem Log Modus?Sie können den Log Modus einmal für die System Datenbank und einmal für jede einzelne Tenant Datenbank setzen. In der Downtime Phase eines SAP Upgrades würden Sie das Log Archiving für die Tenant Datenbank deaktivieren, aber für die System-Datenbank anlassen.
Wie läuft das mit dem Ressourcenverbrauch?Sie können an jede einzelne Tenant Datenbanken Limits allokieren. Das ist auch notwendig, weil zwischen OLAP Systemen wie einem SAP BW on HANA oder BW/4HANA und einem OLTP System wie einem Suite on HANA oder einem S/4HANA unterschiedliche Anforderungen an das Verhältnis zwischen genutzten CPU Sockets und RAM gestellt werden. Diese Anforderungen können Sie jedoch erfüllen, indem Sie die entsprechenden Zuweisungen machen.
Wie läuft das mit der HochverfügbarkeitHochverfügbarkeit greift immer nur für die gesamte HANA Instanz. Wenn Sie bei einer Tenant Datenbank einen Failover machen müssen, müssen Sie die gesamte HANA Instanz und somit alle Applikationen failovern. Das wäre in den meisten Fällen aber so oder so nötig, weil bei einem Ausfall von Harware oder Betriebssystem ohnehin die gesamte Instanz weg bricht.
Kann ich auf Daten anderer Tenant Datenbanken zugreifen?Ja, das ist möglich, und auch der Sicherheit wird hierbei Rechnung getragen. Sie können mit SAP BW on HANA 7.5 SP04 oder neuer beispielsweise über sogenannte Open ODS Views komplett ohne traditionelle Prozesskettenverarbeitung direkt auf die Daten der OLTP-Systeme in der selben Datenbank zugreifen, wenn Sie dies entsprechend konfigurieren. Details entnehmen Sie Hinweis 2312583.
Wie ist das mit ERP und Scale-OutGrundsätzlich unterstützt MDC den Scale-Out Betrieb. Während beispielsweise SAP BW on HANA bzw. BW/4HANA für Scale-Out freigegeben ist,
sollten Business Suite Systeme (ERP, CRM, SRM, etc.) jedoch nicht in einem Scale-Out Verbund genutzt werden (Quelle: SAP Note 1825774 und 2121768). Sie können dieses Problem lösen, indem Sie die Business Suite Applikationen in einem MDC Scale-Out Verbund nur einen einzigen Knoten zuzuweisen, was möglich ist. Grund für die Beschränkung auf Scale-Up sind die Folgen eines Rollbacks für den Sclae-Out Verbund, der in einem OLTP System durchaus mal öfter passieren kann.
Wie läuft das mit den Lizenzen?In der SAP HANA MDC Instanz spielen Sie rein technisch nur eine Lizenz ein. Für die einzelnen Lizenzkombinationen greift die gleiche Regelung wie zuvor: es wird nach „Usage Types“ abgerechnet. Es kann hierbei eine Kombination aus Runtime und Platform Lizenzen geben.
Wie ist das mit dem PatchenAlle Tenant Datenbanken laufen unter ein und der selben SAP HANA Revision bzw. unter dem selben SPS. Patchen muss man nur noch einmal machen, um zeitgleich den Versionsstand aller Tenant Datenbanken anzugleichen. Vorteil: Weniger Patchdays, Nachteil: Höherer Business Impact, der sich jedoch mit der HANA System Replication reduzieren lässt.
Ist MDC in Kombination mit Virtualisierung bzw. Hardware Partitioning möglich?Absolut, MDC ist für den produktiven Einsatz unter Virtualisierung bzw. Hardware Partitioning freigegeben.
Wir arbeiten bisher unter verschiedenenVersionen der Application Function Library (AFL), wie ist das bei MDC?Aktuell gilt eine Version der AFL für alle Tenant Datenbanken. Jede Tenant Datenbank kann entscheiden, ob sie die AFL laden will, oder nicht.
Kann ein MDC Tenant in eine andere MDC Instanz verschoben werden?Ja, solange die Revisionsnummer bzw. der SPS der HANA Instanz gleich oder neuer ist und die Endianness (Big Endian, Little Endian) auf dem Betriebssystem gleich bleibt.
Wie ist das mit Dynamic Tiering?Dynamic Tiering funktioniert, aber nur wenn das Isolationslevel zwischen den Tenant Datenbanken auf Low gestellt ist.
Wie sieht es aus mit Smart Data Access zwischen den Tenants?Smart Data Access ist supported, es ist also möglich per SDA auf eine andere Tenant Datenbank zuzugreifen. Es macht aber häufig keinen Sinn, SDA zu nutzen, weil der Cross-Database Access zwischen den Tenants wesentlich schneller ist.
Wie ist das, kann ich von einer Datenbank aus eine Query auf eine andere Datenbank ausführen?Das sind sogenannte Cross-Tenant Querys. Diese müssen explizit konfiguriert und aktiviert werden. Des weiteren muss ein Mapping zwischen den Datenbankbenutzern stattfinden, sprich: Wenn ich auf Datenbank A mit User A.LOIBL eine Query auf Datenbank B absetze, mit welchem User auf Datenbank B wird diese dann ausgeführt?
Wie ist das mit der Sicherheit im Cross Database Access?Sie müssen Cross Database Access zunächst explizit im System aktivieren. Danach geschieht ein Mapping zwischen den Benutzern in der Quelldatenbank und den Benutzern in der Zieldatenbank. Die Berechtigungen der Benutzer in der Zieldatenbank bestimmen die Berechtigungen zum Lesen der dortigen Daten. Cross Database Access ist Read Only.
Wie läuft das mit Point in Time RecoveryWie beim Log Mode bereits erklärt, läuft die Persistenschicht der Indexserver jeder einzelnen Tenant Datenbank autonom. Sie können also den Indexserver einer Tenant Datenbank getrennt vom Nameserver der Systemdatenbank Point in Time recovern. Deswegen gibt es hier in der Regel keine Probleme.
Einziges Manko: Das Recovern einer Tenant Datenbank über HANA Snapshots ist nicht möglich.
Kann ich Business Suite und BW on HANA zusammen auf einer MDC Installation betreiben?Ja, unter MDC ist das unterstützt. Die Einschränkungen aus den SAP Hinweisen 1661202 und 1826100 greifen NICHT für MDC. Jedoch in einer Tenant Datenbank wiederum als MCOD dürfen die beiden lösungen nicht betrieben werden, das heißt die beiden Systeme müssen jeweils auf ihrer eigenen Tenant Datenbank liegen. Sie müssen außerdem vorsichtig mit der Ressourcenallokierung sein, insbesondere im Hinblick auf die verwendeten CPU Sockets pro Tenant Datenbank und das Verhältnis zum RAM

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.