Ausführen von SAP HANA in Azure (große Instanzen)

Anhand dieser Referenzarchitektur werden einige bewährte Methoden für die Ausführung von SAP HANA in Azure (große Instanzen) mit Hochverfügbarkeit (High Availability, HA) und Notfallwiederherstellung (Disaster Recovery, DR) veranschaulicht. Große HANA-Instanzen (HANA Large Instances, HLIs) werden auf physischen Servern in Azure-Regionen bereitgestellt. Diese Lösung zeigt ein einfaches Hochskalierungsszenario, um grundlegende Konzepte bei der Bereitstellung und dem Betrieb eines SAP HANA-Systems in Azure zu veranschaulichen. Optionen finden Sie in anderen Installationsszenarien für große HANA-Instanzen.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Diese Architektur umfasst die folgenden Infrastrukturkomponenten.

• Virtuelles Netzwerk. Der Dienst Azure Virtual Network (VNET) verbindet auf sichere Weise Azure-Ressourcen miteinander und wird in separate Subnetze für jede Ebene unterteilt. SAP-Anwendungsebenen werden auf virtuellen Azure-Computern (VMs) bereitgestellt, um eine Verbindung mit der HANA-Datenbankebene herzustellen, die in großen Instanzen gespeichert ist.

• Netzwerk mit HLI-Revision 4.5. Ab Juli 2021 ist die aktualisierte Version des HLI Rev 4 verfügbar. Diese aktualisierte Implementierung [rev4.5] umfasst viele Verbesserungen in der Infrastruktur, z.B. 100Gb/s-Netzwerk für den NFS-Speicher und eine bessere Netzwerkredundanz des DB-Servers. Bei diesem Entwurf werden die HLI-Server in Azure-Rechenzentren in unmittelbarer physischer Nähe zu den Azure-VMs eingesetzt, auf denen die SAP-Anwendungsserver ausgeführt werden. Wenn Rev 4.5 mit einer [ExpressRoute FastPath][fastpath]-Konfiguration verwendet wird, erhöht sich die Anwendungsleistung. Diese Netzwerkfeatures unterstützen auch die Bereitstellungen von Rev 3 und Rev 4.

• Virtuelle Computer (Virtual Machines, VMs) : VMs werden in der SAP-Anwendungsebene und der Ebene für gemeinsame Dienste verwendet. Letztere enthält eine Jumpbox, die von Administratoren verwendet wird, um große HANA-Instanzen einzurichten und Zugriff auf andere VMs bereitzustellen. Um die SAP-Anwendungsserver in demselben Rechenzentrum wie die großen HANA-Instanzen zu platzieren, verwenden Sie Näherungsplatzierungsgruppen.

• Große HANA-Instanz. Dieser physische Server, der für die SAP HANA TDI-Standards (Tailored Datacenter Integration) zertifiziert ist, führt SAP HANA aus. Diese Architektur verwendet zwei große HANA-Instanzen: eine primäre und eine sekundäre Compute-Einheit. Hochverfügbarkeit auf der Datenebene wird über HSR (HANA System Replication) bereitgestellt.

• Hochverfügbarkeitspaar: Eine Gruppe von Blades der großen HANA-Instanzen wird gemeinsam verwaltet, um Datenbankredundanz und -zuverlässigkeit zu bieten.

• Microsoft Enterprise Edge (MSEE) . MSEE ist ein Verbindungspunkt von einem Verbindungsanbieter oder Ihrem Netzwerkedge über eine ExpressRoute-Verbindung.

• Netzwerkschnittstellenkarten (NICs) : Um die Kommunikation zu ermöglichen, stellt der Server für große HANA-Instanzen standardmäßig vier virtuelle NICs bereit. Diese Architektur erfordert eine NIC für die Clientkommunikation, eine zweite NIC für die für HSR erforderliche Konnektivität zwischen den Knoten, eine dritte NIC für den Speicher der großen HANA-Instanz und eine vierte NIC für iSCSI im Hochverfügbarkeitsclustering.

• NFS-Speicher (Network File System ) : Der NFS-Server unterstützt die Netzwerkdateifreigabe, die sichere Datenpersistenz für die große HANA-Instanz bereitstellt.

• ExpressRoute: ExpressRoute ist der empfohlene Azure-Netzwerkdienst für die Erstellung privater Verbindungen zwischen einem lokalen Netzwerk und Azure-VNETs, die nicht über das öffentliche Internet genutzt werden. Virtuelle Azure-Computer stellen über eine weitere ExpressRoute-Verbindung eine Verbindung mit großen HANA-Instanzen her. Die ExpressRoute-Verbindung zwischen dem Azure-VNET und den großen HANA-Instanzen wird als Teil des Microsoft-Angebots eingerichtet.

• Gateway: Das ExpressRoute-Gateway wird verwendet, um das für die SAP-Anwendungsebene verwendete Azure-VNET mit dem Netzwerk der großen HANA-Instanz zu verbinden. Verwenden Sie die SKU für Hohe Leistung oder Höchstleistung.

• Notfallwiederherstellung (Disaster Recovery, DR) : Zu den Optionen für die Notfallwiederherstellung gehören die HANA-Systemreplikation (HSR), die HANA-Dateisicherung und -Dateiwiederherstellung und die Speicherreplikation. Das Microsoft Service Management-Team kann auf Anfrage die Speicherserver und -volumes konfigurieren. Sie sind dafür verantwortlich, die Speichermomentaufnahme zu planen, das System zu testen und sich mit dem Wiederherstellungsprozess vertraut zu machen. Weitere Überlegungen gelten für die Anwendungsebene für SAP NetWeaver und SAP S/4HANA in Azure.

Empfehlungen

Die Anforderungen können unterschiedlich sein, daher sollten Sie diese Empfehlungen als Ausgangspunkt verwenden.

Compute mit großen HANA-Instanzen

Große HANA-Instanzen sind physische Server, die auf der CPU-Architektur Broadwell und Cascade Lake von Intel basieren und in einem Umfeld für große Instanzen – also in einer bestimmten Gruppe von Servern oder Blades – konfiguriert werden. Eine Compute-Einheit entspricht einem Server oder Blade, und ein Stempel setzt sich aus mehreren Servern oder Blades zusammen. In einem Umfeld für große Instanzen werden Server nicht gemeinsam verwendet und sind für die Ausführung der SAP HANA-Bereitstellung eines Kunden reserviert.

Eine Vielzahl von SKUs sind für große HANA-Instanzen verfügbar und unterstützen bei einer Einzelinstanz bis zu 24 TB (120 TB horizontale Skalierung) Speicher für BW/4HANA- oder andere SAP HANA-Workloads.

Wählen Sie eine SKU aus, die die Größenanforderungen erfüllt, die Sie in Ihrer Architektur und Ihren Entwurfssitzungen festgelegt haben. Stellen Sie immer sicher, dass Ihre Größenangabe für die richtige SKU gilt. Funktionen und Bereitstellungsanforderungen sind abhängig vom Typ unterschiedlich, und die Verfügbarkeit ist von der Region abhängig. Sie können auch aus einer SKU in eine größere SKU wechseln.

Microsoft unterstützt Sie bei der Einrichtung der großen Instanz, aber es liegt in Ihrer Verantwortung, die Konfigurationseinstellungen des Betriebssystems zu überprüfen. Beachten Sie unbedingt die aktuellsten SAP-Hinweise für Ihr spezifisches Linux-Release.

Storage

Speicherlayout wird gemäß der Empfehlung der TDI für SAP HANA implementiert. Große HANA-Instanzen verfügen über eine bestimmte-Speicherkonfiguration für die TDI-Standardspezifikationen. Allerdings können Sie zusätzlichen Speicher in Schritten von 1 TB erwerben.

Um die Anforderungen der unternehmenswichtigen Umgebungen einschließlich schneller Wiederherstellung zu unterstützen, wird NFS verwendet und kein direkt zugeordneter Speicher. Der NFS-Speicherserver für große HANA-Instanzen wird in einer mehrinstanzenfähigen Umgebung gehostet, in der Mandanten mit Compute-, Netzwerk- und Speicherisolierung getrennt und gesichert werden.

Um hohe Verfügbarkeit am primären Standort zu unterstützen, verwenden Sie unterschiedliche Speicherlayouts. Bei einer horizontalen Skalierung mit mehreren Hosts wird beispielsweise der Speicher gemeinsam genutzt. Eine weitere Option für Hochverfügbarkeit ist die anwendungsbasierte Replikation (z. B. HSR). Für die Notfallwiederherstellung wird jedoch eine auf Momentaufnahmen basierende Speicherreplikation verwendet.

Netzwerk

Diese Architektur verwendet virtuelle und physische Netzwerke. Das virtuelle Netzwerk ist Bestandteil von Azure IaaS (Infrastructure-as-a-Service) und stellt eine Verbindung mit einem diskreten physischen Netzwerk mit großen HANA-Instanzen über ExpressRoute-Verbindungen her. Ein standortübergreifendes Gateway verbindet Ihre Workloads im Azure-VNET mit Ihren lokalen Standorten.

Bei allen Bereitstellungen großer HANA-Instanzen seit Juli 2019 werden Rev 4-Stempel verwendet, die in unmittelbarer Nähe der für die SAP-Anwendungsserver verwendeten Azure-VM-Hosts bereitgestellt werden. Demzufolge minimiert die Rev 4-Bereitstellung die Netzwerklatenz zwischen der Anwendungs- und Datenbankebene.

Netzwerke mit großen HANA-Instanzen werden aus Sicherheitsgründen voneinander isoliert. Instanzen, die sich in unterschiedlichen Regionen befinden, kommunizieren mit Ausnahme der dedizierten Speicherreplikation nicht miteinander. Um HSR verwenden zu können, ist jedoch Kommunikation zwischen den Regionen erforderlich. [Azure Global Reach][globalreach], IP-Routingtabellen oder Proxys können verwendet werden, um regionsübergreifende HSR zu aktivieren.

Alle Azure-VNETs, die eine Verbindung mit großen HANA-Instanzen in einer Region herstellen, können verbindungsübergreifend über ExpressRoute mit großen HANA-Instanzen in einer sekundären Region verbunden werden.

Die ExpressRoute-Verbindung für große HANA-Instanzen ist während der Bereitstellung standardmäßig enthalten. Für die Einrichtung ist ein bestimmtes Netzwerklayout, einschließlich der erforderlichen CIDR-Adressbereiche (Classless Inter-Domain Routing) und Domänenrouting, erforderlich. Details finden Sie unter Infrastruktur und Verbindungen mit SAP HANA in Azure (große Instanzen).

Um die Netzwerklatenz zu verringern und die Leistung zu verbessern, sollten Sie FastPath aktivieren (auch als MSEE v2 bezeichnet). Diese Netzwerkkonfiguration ermöglicht Datenverkehr von der lokalen Umgebung zum Azure-VNET und vom VNET zu großen HANA-Instanzen, um das Azure-Gateway zu umgehen.

Überlegungen

Skalierbarkeit

Um hoch- oder herunterzuskalieren, können Sie aus vielen Größen von Servern auswählen, die für große HANA-Instanzen verfügbar sind. Sie sind als Typ I und Typ II kategorisiert und auf unterschiedliche Workloads zugeschnitten. Wählen Sie eine Größe aus, die mit Ihrer Workload während der nächsten drei Jahre wachsen kann. Einjährige Vertragslaufzeiten sind ebenfalls verfügbar.

Eine Bereitstellung für horizontales Skalieren mit mehreren Hosts wird in der Regel als eine Art von Datenbankpartitionierungsstrategie für BW/4HANA-Bereitstellungen verwendet. Zum Zeitpunkt der Erstellung dieses Artikels kann BW/4HANA auf großen HANA-Instanzen auf 120 TB horizontal hochskaliert werden. Planen Sie die Platzierung der HANA Tabellen vor der Installation, um das Aufskalieren zu ermöglichen. Aus infrastruktureller Sicht sind mehrere Hosts mit einem gemeinsamen Speichervolume verbunden, was eine schnelle Übernahme durch Standbyhosts ermöglicht, falls einer der Computeworkerknoten im HANA-System ausfällt.

S/4HANA und SAP Business Suite für HANA auf einem einzelnen Blade können mit einem Knoten mit einer einzelnen Instanz bis zu 24 TB zentral hochskaliert werden. Große HANA-Instanzen und die Azure-Speicherinfrastruktur unterstützen auch Bereitstellungen für horizontales Skalieren mit S/4HANA und BW/4HANA. Informationen zu bestimmten SKUs, die für horizontales Skalieren zertifiziert sind, finden Sie im [Verzeichnis der SAP-zertifizierten Hardware][directory].

Der Arbeitsspeicherbedarf für HANA nimmt mit zunehmender Datenmenge zu. Verwenden Sie den aktuellen Speicherverbrauch Ihres Systems als Grundlage für die Vorhersage des zukünftigen Verbrauchs, und ordnen Sie dann Ihren Bedarf einer der Größen der großen HANA-Instanzen zu.

Wenn Sie bereits über SAP-Bereitstellungen verfügen, stellt SAP Berichte zur Verfügung, mit denen Sie die von vorhandenen Systemen verwendeten Daten überprüfen und den Speicherbedarf für eine HANA-Instanz berechnen können. Siehe beispielsweise die folgenden SAP-Hinweise (der Zugriff erfordert ein SAP Service Marketplace-Konto):

• SAP-Hinweis 1793345: Größenanpassung für die SAP-Suite für HANA
• SAP-Hinweis 1872170: Bericht zur Größenanpassung für die Suite für HANA und S/4 HANA
• SAP-Hinweis 2121330 – Häufig gestellte Fragen: Bericht zur Größenanpassung für SAP BW unter HANA
• SAP-Hinweis 1736976: Bericht zur Größenanpassung für BW unter HANA
• SAP-Hinweis 2296290: Neuer Bericht zur Größenanpassung für BW unter HANA

Verfügbarkeit

Ressourcenredundanz ist das allgemeine Thema bei hochverfügbaren Infrastrukturlösungen. Arbeiten Sie mit SAP, Ihrem Systemintegrator oder Microsoft zusammen, um eine Hochverfügbarkeits- und Notfallwiederherstellungsstrategie zu entwickeln und zu implementieren. Diese Architektur folgt der Vereinbarung zum Servicelevel (Service-Level Agreement, SLA) für HANA in Azure (große Instanzen). Um Ihre Verfügbarkeitsanforderungen zu beurteilen, sollten Sie die einzelnen Fehlerpunkte, die gewünschte Verfügbarkeit der Dienste und diese allgemeinen Metriken berücksichtigen:

• RTO (Recovery Time Objective) ist die Zeitspanne, in der der Server für große HANA-Instanzen nicht verfügbar ist.

• RPO (Recovery Point Objective) ist der maximal tolerierbare Zeitraum, in welchem Kundendaten aufgrund eines Fehlers verloren gehen können.

Für Hochverfügbarkeit sollten Sie mehrere Instanzen in einem HA-Paar bereitstellen und HSR in einem synchronen Modus verwenden, um Datenverluste und Ausfallzeiten zu minimieren. Zusätzlich zu einem lokalen Hochverfügbarkeitssetup mit zwei Knoten unterstützt HSR die Replikation mit mehreren Ebenen, wobei sich ein dritter Knoten in einer separaten Azure-Region als Replikationsziel beim sekundären Replikat des geclusterten HSR-Paars registriert. Auf diese Weise entsteht eine Replikationsverkettung.

Das Failover zum Notfallwiederherstellungsknoten ist ein manueller Prozess ohne Linux-Clustering. Für die automatische Fehlererkennung und automatisches Failover können Sie Pacemaker so konfigurieren, dass es zu geringeren Ausfallzeiten aufgrund von Software- oder Hardwarefehlern kommt. Ab HANA 2.0 SPS 04 unterstützt HSR auch die Replikation mit mehreren Zielen. Statt Verkettung zu verwenden, verfügt diese Form der Replikation über einen primären und mehrere sekundäre Abonnenten.

Wenn Sie HSR für große HANA-Instanzen mit automatischem Failover einrichten, können Sie das Microsoft Service Management-Team bitten, ein STONITH-Gerät für Ihre Server mit großen HANA-Instanzen einzurichten.

Notfallwiederherstellung

Diese Architektur unterstützt die Notfallwiederherstellung zwischen großen HANA-Instanzen in verschiedenen Azure-Regionen. Es gibt zwei Möglichkeiten zur Unterstützung von Notfallwiederherstellung mit großen HANA-Instanzen:

• Speicherreplikation. Der Inhalt des primären Speichers wird ständig in die Remotespeichersysteme für die Notfallwiederherstellung repliziert, die auf dem designierten Server für die Notfallwiederherstellung der großen HANA-Instanzen verfügbar sind. Bei der Speicherreplikation wird die HANA-Datenbank nicht in den Arbeitsspeicher geladen. Diese Notfallwiederherstellungsoption ist aus Verwaltungssicht einfacher. Um festzustellen, ob dies eine geeignete Strategie ist, berücksichtigen Sie die Datenbankladezeit im Vergleich zur Verfügbarkeits-SLA. Speicherreplikation ermöglicht Ihnen außerdem, Zeitpunktwiederherstellung auszuführen. Wenn Mehrzweck-Notfallwiederherstellung (kostenoptimiert) eingerichtet ist, müssen Sie zusätzlichen Speicher mit derselben Größe am Notfallwiederherstellungs-Standort erwerben. Microsoft stellt Self-Service-Speichermomentaufnahme- und -Failoverskripts für HANA-Failover als Teil des Angebots großer HANA-Instanzen bereit.

• HSR mit mehreren Ebenen oder Zielen mit einem dritten Replikat in der Notfallwiederherstellungsregion (wobei die HANA-Datenbank in den Speicher geladen wird). Diese Option unterstützt eine schnellere Wiederherstellung, jedoch keine Zeitpunktwiederherstellung. Für HSR ist ein sekundäres System erforderlich. Der Datenverkehr der HANA-Systemreplikation für den Notfallwiederherstellungs-Standort kann über Proxys (z. B. nginx) oder IP-Tabellen geleitet werden. Alternativ kann Global Reach verwendet werden, um die ExpressRoute-Verbindungen miteinander zu verknüpfen, sodass zugelassene Benutzer eine direkte Verbindung mit großen HANA-Instanzen herstellen können.

Kostenoptimierung

Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln.

Weitere Informationen finden Sie im Abschnitt zu Kosten im Microsoft Azure Well-Architected Framework.

SKUs können sich auf das Abrechnungsmodell auswirken. Hier sind einige Kostenaspekte beschrieben.

Virtuelle Computer

In dieser Referenzarchitektur werden virtuelle Computer zum Hosten von SAP-Anwendungen, SAP-Diensten und gemeinsamen Diensten, z. B. Verwaltungsjumpboxen, verwendet. Für HANA (große Instanzen) gibt es bestimmte zertifizierte SKUs. Die Konfigurationen richten sich nach Workload, CPU-Ressourcen, gewünschtem Arbeitsspeicher und Budget.

SKUs für große HANA-Instanzen sind als reservierte VM-Instanzen verfügbar. Mit Azure-Reservierungen können Sie Ihre Kosten senken, wenn Sie sich zu einer ein- oder dreijährigen Nutzung verpflichten können. Mit VM-Reservierungen können die Kosten im Vergleich zu den Preisen für die nutzungsbasierte Bezahlung auf bis zu 72 Prozent gesenkt werden. Sie erhalten eine spezielle SAP HANA-Infrastruktur mit Compute-, Speicher- und Netzwerkressourcen. Große HANA-Instanzen sind mit NFS-Speicher und -Netzwerkkomponenten gekoppelt und verfügen über integrierte Unterstützung für Sicherungen per Speichermomentaufnahme, Hochverfügbarkeit und Notfallwiederherstellung und Konfigurationen mit horizontaler Skalierung. Falls für Ihre Workloads der Abschlusszeitpunkt oder der Ressourcenverbrauch nicht vorhersehbar ist, bietet sich die nutzungsbasierte Bezahlung an.

Verwenden Sie die Übersicht über den Azure-Sparplan, und kombinieren Sie sie mit Azure-Reservierungen. Der Azure-Sparplan ist ein flexibler und kostensparender Plan, der im Vergleich mit nutzungsbasierten Preisen erhebliche Einsparungen bietet. Sie vereinbaren einen Vertrag mit einer Laufzeit von einem Jahr oder drei Jahren und erhalten Preisnachlässe auf berechtigte Compute-Dienste. Einsparungen gelten für diese Compute-Dienste unabhängig von Region, Instanzgröße oder Betriebssystem. Weitere Informationen finden Sie in der Dokumentation zum Azure-Sparplan.

Verwenden Sie Azure-Spot-VMs zum Ausführen von Workloads, die unterbrochen werden können und nicht innerhalb eines vordefinierten Zeitrahmens oder einer SLA abgeschlossen werden müssen.

Weitere Informationen finden Sie im Abschnitt „SAP HANA in Azure (große Instanzen)“ unter HLI für SAP HANA Virtual Machines – Preise.

Azure ExpressRoute

Bei dieser Architektur wird Azure ExpressRoute als Netzwerkdienst zum Erstellen von privaten Verbindungen zwischen einem lokalen Netzwerk und virtuellen Azure-Netzwerken verwendet. Virtuelle Azure-Computer stellen über eine weitere ExpressRoute-Verbindung und ein ExpressRoute-Gateway eine Verbindung mit großen HANA-Instanzen her. Als SKU wird „Hohe Leistung“ oder „Höchstleistung“ empfohlen.

Alle eingehenden Datenübertragungen sind kostenlos. Für alle ausgehenden Datenübertragungen wird eine vorab festgelegte Rate berechnet. Weitere Informationen finden Sie unter Azure ExpressRoute – Preise.

Backup

Basierend auf Ihren Geschäftsanforderungen können Sie unter verschiedenen Optionen wählen.

Ausführliche Informationen zu einem Do-it-yourself-Ansatz für die Sicherung und weitere Optionen für große HANA-Instanzen finden Sie im Artikel „[Sichern und Wiederherstellen][backup-restore]“.

Verwaltbarkeit

Überwachen Sie die Ressourcen großer HANA-Instanzen wie CPU, Arbeitsspeicher, Netzwerkbandbreite und Speicherplatz mit SAP HANA Studio, SAP HANA Cockpit, SAP Solution Manager und anderen nativen Linux-Tools. Typ-I-SKUs großer HANA-Instanzen beinhalten keine integrierten Überwachungstools. Typ-II-SKUs bieten vorgefertigte Diagnosetools für die Protokollierung und Problembehandlung von Systemaktivitäten.

Microsoft bietet grundlegende Tools und Ressourcen, mit denen Sie große HANA-Instanzen in Azure überwachen können. Das Microsoft-Supportteam kann Sie auch bei der Behebung von technischen Problemen unterstützen.

Sicherheit

• Seit Ende 2018 ist der Speicher großer HANA-Instanzen standardmäßig verschlüsselt.

• Daten während der Übertragung zwischen großen HANA-Instanzen und den VMs werden nicht verschlüsselt. Um die Datenübertragung zu verschlüsseln, aktivieren Sie die anwendungsspezifische Verschlüsselung. Weitere Informationen finden Sie im SAP-Hinweis 2159014 – Häufig gestellte Fragen: SAP HANA-Sicherheit.

• Isolierung sorgt für Sicherheit zwischen den Mandanten in der mehrinstanzenfähigen HANA-Umgebung (große Instanz). Mandanten werden mit ihrem eigenen VLAN isoliert.

• Bewährte Methoden für die Azure-Netzwerksicherheit bieten hilfreiche Anleitungen.

• Wie bei jeder Bereitstellung wird die Betriebssystemhärtung empfohlen, einschließlich der Härtung des SUSE Linux-Images für SAP in Azure.

• Aus Gründen der physischen Sicherheit ist der Zugriff auf Azure-Datencenter nur durch entsprechend autorisierte Mitarbeiter möglich. Kunden können generell nicht auf die physischen Server zugreifen.

Weitere Informationen finden Sie unter SAP HANA-Sicherheit – Eine Übersicht. (Für den Zugriff ist ein Konto für den SAP Service Marketplace erforderlich.)

Communitys

Communitys können Fragen beantworten und Sie beim Einrichten einer erfolgreichen Bereitstellung unterstützen. Beachten Sie Folgendes:

• Running SAP Applications on the Microsoft Platform (Blog)
• Stack Overflow SAP

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Ben Trinh | Principal Architect

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Zugehörige Ressourcen

Es wird empfohlen, sich das folgende Azure-Beispielszenario anzusehen. Darin wird veranschaulicht, wie einige dieser Technologien in spezifischen Lösungen verwendet werden:

• Ausführen von SAP-Produktionsworkloads mit einer Oracle Database-Instanz in Azure
• Entwicklungs-/Testumgebungen für SAP-Workloads in Azure