Ausführen von SAP NetWeaver unter Windows in Azure

In diesem Leitfaden erfahren Sie mehr über bewährte Methoden zum Ausführen von SAP NetWeaver in einer Windows-Umgebung in Azure mit Hochverfügbarkeit. Die Datenbank ist AnyDB. „AnyDB“ ist der SAP-Begriff für alle unterstützten Datenbank-Managementsysteme (DBMS) neben SAP HANA.

Aufbau

Das folgende Diagramm zeigt SAP NetWeaver in einer Windows-Umgebung.

Laden Sie eine Visio-Datei dieser Architektur herunter.

In diesem Leitfaden wird ein Produktionssystem beschrieben. Dieses System wird mit bestimmten virtuellen Computern (VM) bereitgestellt, deren Größe Sie je nach den Anforderungen Ihres Unternehmens ändern können. Das System kann auf eine einzelne VM reduziert werden. In diesem Leitfaden ist das Layout des Netzwerks stark vereinfacht, um die Architekturprinzipien zu demonstrieren. Es dient nicht dazu, ein gesamtes Unternehmensnetzwerk zu beschreiben.

Workflow

Virtuelle Netzwerke. Der Azure Virtual Network-Dienst verbindet Azure-Ressourcen miteinander mit erweiterter Sicherheit. In dieser Architektur wird das virtuelle Netzwerk über ein Azure ExpressRoute-Gateway, das im Hub einer Hub-Spoke-Topologie bereitgestellt ist, mit einem lokalen Netzwerk verbunden. Die Speiche (Spoke) ist das virtuelle Netzwerk, das für die SAP-Anwendungen und die Datenbankschichten verwendet wird. Das virtuelle Hubnetzwerk wird für gemeinsam genutzte Dienste wie Azure Bastion und Sicherung verwendet.

Peering virtueller Netzwerke. Für diese Architektur wird eine Hub-and-Spoke-Netzwerktopologie mit mehreren virtuellen Netzwerken verwendet, die per Peering verbunden sind. Diese Topologie bietet Netzwerksegmentierung und -isolation für Dienste, die in Azure bereitgestellt werden. Peering ermöglicht eine transparente Konnektivität zwischen den gepeerten virtuellen Netzwerken über das Microsoft-Backbone-Netzwerk. Es verursacht keine Leistungseinbußen, wenn es innerhalb einer einzelnen Region bereitgestellt wird. Das virtuelle Netzwerk wird für jede Schicht in getrennte Subnetze unterteilt: Anwendung (SAP NetWeaver), die Datenbank und gemeinsame Dienste wie Bastion und eine Sicherungslösung eines Drittanbieters.

VMs. Diese Architektur verwendet VMs für die Logikschicht und die Datenbankschicht, die wie folgt gruppiert sind:

• SAP NetWeaver: Auf der Logikschicht werden Windows-VMs verwendet, um SAP Central Services und SAP-Anwendungsserver auszuführen. Für Hochverfügbarkeit werden die VMs, auf denen Central Services ausgeführt werden, in einem Windows Server-Failovercluster konfiguriert. Sie werden entweder von Azure-Dateifreigaben oder freigegebenen Azure-Datenträgern unterstützt.

• AnyDB: Auf der Datenbankschicht wird AnyDB als Datenbank ausgeführt, die Microsoft SQL Server, Oracle oder IBM DB2 sein kann.

• Azure Bastion-Dienst. Administratoren verwenden eine VM mit verbesserter Sicherheit, die als Bastion-Host bezeichnet wird, um Verbindungen mit anderen VMs herzustellen. In der Regel ist dies ein Teil von gemeinsam genutzten Diensten wie Sicherungsdiensten. Falls nur das Secure Shell-Protokoll (SSH) und das Remotedesktopprotokoll (RDP) als Dienste für die Serververwaltung genutzt werden, ist ein Azure Bastion-Host eine gute Lösung. Wenn Sie andere Verwaltungstools nutzen, z. B. SQL Server Management Studio oder das SAP-Front-End, verwenden Sie eine herkömmliche selbstbereitgestellte Jumpbox.

Private DNS-Dienst.Privates DNS von Azure bietet einen zuverlässigen und sicheren DNS-Dienst für Ihr virtuelles Netzwerk. Privates Azure-DNS verwaltet Domänennamen im virtuellen Netzwerk und löst diese auf, ohne dass eine benutzerdefinierte DNS-Lösung konfiguriert werden muss.

Lastenausgleichsmodule: Um den Datenverkehr auf virtuelle Computer im Subnetz der SAP-Anwendungsebene zu verteilen, um Hochverfügbarkeit zu erzielen, empfehlen wir die Verwendung von Azure Load Balancer Standard. Beachten Sie, dass ein Azure Load Balancer Standard standardmäßig eine gewisses Maß an Sicherheit bietet. VMs, die sich hinter einem Azure Load Balancer Standard befinden, verfügen über keine ausgehende Internetkonnektivität. Um ausgehende Internetkonnektivität auf den VMs zu aktivieren, müssen Sie Ihre Azure Load Balancer Standard-Konfiguration aktualisieren. Für die Hochverfügbarkeit webbasierter SAP-Anwendungen verwenden Sie den integrierten SAP Web Dispatcher oder einen anderen kommerziell erhältlichen Lastenausgleich. Basieren Sie Ihre Auswahl auf Folgendes:

• Ihr Datenverkehrstyp, z. B. HTTP oder SAP-GUI.
• Die von Ihnen benötigten Netzwerkdienste wie SSL-Abschluss (Secure Sockets Layer).

Einige Beispiele für den Entwurf von ein- und ausgehendem Internetzugriff finden Sie unter Eingehende und ausgehende Internetverbindungen für SAP in Azure.

Load Balancer Standard unterstützt mehrere virtuelle Front-End-IP-Adressen. Diese Unterstützung ist ideal für Clusterimplementierungen, die diese Komponenten einbeziehen:

• Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
• Enqueue-Replikationsserver (ERS)

Die Standard-SKU unterstützt auch SAP-Cluster mit Multi-SID (Multi-Systems Identifier). Mit anderen Worten: Mehrere SAP-Systeme unter Windows können sich eine gemeinsame Hochverfügbarkeitsinfrastruktur teilen, um die Kosten zu senken. Werten Sie die Kosteneinsparungen aus, und platzieren Sie nicht zu viele Systeme in einem Cluster. Azure unterstützt nicht mehr als fünf SIDs pro Cluster.

Application Gateway Azure Application Gateway ist ein Lastenausgleich für Webdatenverkehr, mit dem Sie den eingehenden Datenverkehr für Ihre Webanwendungen verwalten können. Herkömmliche Lastenausgleiche arbeiten auf der Transportschicht (OSI-Schicht 4 – TCP und UDP). Sie leiten den Datenverkehr auf der Grundlage der Quell-IP-Adresse und des Ports an eine Ziel-IP-Adresse und einen Port weiter. Application Gateway kann Routingentscheidungen auf Grundlage zusätzlicher Attribute einer HTTP-Anforderung treffen. Beispiele für solche Attribute wären etwa der URI-Pfad oder die Hostheader. Diese Art des Routings wird als Lastenausgleich auf Anwendungsebene (OSI-Schicht 7) bezeichnet.

Netzwerksicherheitsgruppen: Um eingehenden, ausgehenden und subnetzinternen Datenverkehr in einem virtuellen Netzwerk einzuschränken, erstellen Sie Netzwerksicherheitsgruppen.

Anwendungssicherheitsgruppen: Verwenden Sie Anwendungssicherheitsgruppen anstelle von expliziten IP-Adressen, um detaillierte Netzwerksicherheitsrichtlinien basierend auf Workloads zu definieren, die auf Anwendungen ausgerichtet sind. Anwendungssicherheitsgruppen bieten eine Möglichkeit, VMs nach Namen zu gruppieren und helfen Ihnen, Anwendungen zu schützen, indem sie den Datenverkehr aus vertrauenswürdigen Segmenten Ihres Netzwerks filtern.

Gateway. Mit einem Gateway werden einzelne Netzwerke verbunden, um Ihr lokales Netzwerk auf das virtuelle Azure-Netzwerk zu erweitern. Wir empfehlen, dass Sie ExpressRoute verwenden, um private Verbindungen zu erstellen, die nicht über das öffentliche Internet gehen, aber Sie können auch eine Site-to-Site-Verbindung verwenden. Zur Verringerung der Wartezeit oder zur Erhöhung des Durchsatzes können Sie erwägen, ExpressRoute Global Reach und ExpressRoute FastPath zu verwenden, wie weiter unten in diesem Artikel beschrieben.

„Azure Storage“. Azure Storage bietet Datenpersistenz für einen virtuellen Computer in Form einer virtuellen Festplatte. Wir empfehlen Azure Managed Disks.

Empfehlungen

Diese Architektur beschreibt eine kleine einsatzfähige Bereitstellung für die Produktion. Die Bereitstellung hängt von den geschäftlichen Anforderungen ab, sodass diese Empfehlungen als Startpunkt dienen können.

VMs

Passen Sie in Anwendungsserverpools und -clustern die Anzahl von VMs anhand Ihrer Anforderungen an. Ausführliche Informationen zum Ausführen von SAP NetWeaver auf VMs finden Sie unter Azure Virtual Machines – Planung und Implementierung für SAP NetWeaver.

Ausführliche Informationen zur SAP-Unterstützung für Azure-VM-Typen und Durchsatzmetriken (SAPS) finden Sie in SAP-Hinweis 1928533. Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.

SAP Web Dispatcher

Die Web Dispatcher-Komponente wird für den Lastenausgleich von SAP-Datenverkehr zwischen den SAP-Anwendungsservern verwendet. Zur Erzielung von Hochverfügbarkeit für die Web Dispatcher-Komponente wird Load Balancer verwendet, um entweder den Failovercluster von Web Dispatcher-Instanzen oder das parallele Web Dispatcher-Setup zu implementieren. Eine detaillierte Beschreibung der Lösung finden Sie unter Hochverfügbarkeit für SAP Web Dispatcher.

Anwendungsserverpool

Die SAP-SMLG-Transaktion wird häufig verwendet, um Anmeldegruppen für ABAP-Anwendungsserver zu verwalten und den Lastenausgleich für Anmeldebenutzer durchzuführen. Mit anderen Transaktionen wie SM61 für Batchservergruppen und RZ12 für RFC-Gruppen (Remote Function Call) wird der Lastenausgleich auch für Anmeldebenutzer durchgeführt. Bei diesen Transaktionen wird die Lastenausgleichsfunktion auf dem Nachrichtenserver von SAP Central Services genutzt, um eingehende Sitzungen oder Workloads auf SAP-Anwendungsserverpools für SAP GUIs und RFC-Datenverkehr zu verteilen.

SAP Central Services-Cluster

In dieser Architektur wird Central Services auf virtuellen Computern auf der Logikschicht ausgeführt. Bei der Bereitstellung auf nur einer VM kann Central Services ggf. einen Single Point of Failure darstellen. Für eine Hochverfügbarkeitslösung muss entweder ein Dateifreigabecluster oder ein Datenträgerfreigabe-Cluster verwendet werden.

Für hochverfügbare Dateifreigaben gibt es mehrere Optionen. Wir empfehlen Ihnen, Azure Files-Freigaben als vollständig verwaltete, cloudnative Server Message Block (SMB)- oder Network File System (NFS)-Freigaben zu verwenden. Eine Alternative zu Azure Files ist Azure NetApp Files, das Hochleistungs-NFS- und SMB-Freigaben bietet.

Sie können die hochverfügbaren Dateifreigaben auf den Central Services-Instanzen auch mithilfe eines Windows Server-Failoverclusters mit Azure Files implementieren. Diese Lösung unterstützt auch einen Windows-Cluster mit freigegebenen Datenträgern, indem ein freigegebener Azure-Datenträger als freigegebenes Clustervolumen verwendet wird. Wenn Sie lieber freigegebene Datenträger verwenden möchten, empfiehlt es sich, einen Windows Server-Failovercluster für den SAP Central Services-Cluster mithilfe von freigegebenen Azure-Datenträgern einzurichten.

Es gibt auch Partnerprodukte wie SIOS DataKeeper Cluster Edition von SIOS Technology Corp. Dieses Add-On repliziert den Inhalt unabhängiger Datenträger, die an die ASCS-Clusterknoten angefügt sind, und stellt anschließend die Datenträger für die Clustersoftware als freigegebene Clustervolumes bereit.

Bei der Partitionierung des Clusternetzwerks verwendet die Clustersoftware Quorumabstimmungen, um ein Segment des Netzwerks und die damit verbundenen Dienste auszuwählen, die als „Gehirn“ des fragmentierten Clusters dienen sollen. Windows bietet viele Quorummodelle. Diese Lösung verwendet einen Cloudzeugen, weil dies einfacher ist und höhere Verfügbarkeit bietet als ein Computeknotenzeuge. Der Azure-Dateifreigabezeuge ist eine weitere Alternative, um eine Quorumabstimmung für Cluster bereitzustellen.

Bei einer Azure-Bereitstellung stellen die Anwendungsserver eine Verbindung mit der hochverfügbaren Central Services-Instanz her, indem die virtuellen Hostnamen der ASCS- oder ERS-Dienste verwendet werden. Diese Hostnamen werden der Cluster-Front-End-IP-Konfiguration des Lastenausgleichs zugewiesen. Load Balancer unterstützt mehrere Front-End-IPs, sodass die virtuellen ASCS- und ERS-IPs (VIPs) an einen Lastenausgleich gebunden werden können.

Netzwerk

Bei dieser Architektur wird eine Hub-Spoke-Topologie verwendet. Das virtuelle Hubnetzwerk fungiert als zentraler Konnektivitätspunkt für ein lokales Netzwerk. Die „Speichen“ (Spokes) sind virtuelle Netzwerke, die eine Peeringverbindung mit dem Hub herstellen und die Isolation von Workloads bewirken. Der Datenverkehr wird über eine Gatewayverbindung zwischen dem lokalen Rechenzentrum und dem Hub weitergeleitet.

Netzwerkschnittstellenkarten (NICs)

NICs ermöglichen die gesamte Kommunikation zwischen VMs in einem virtuellen Netzwerk. In herkömmlichen lokalen SAP-Bereitstellungen sind mehrere NICs pro Computer implementiert, um administrativen Datenverkehr von Geschäftsdatenverkehr zu trennen.

In Azure ist das virtuelle Netzwerk eine softwaredefiniertes Netzwerk, in dem der gesamte Datenverkehr über dieselbe Netzwerkstruktur gesendet wird. Es ist also nicht notwendig, aus Leistungsgründen mehrere NICs zu verwenden. Wenn Ihre Organisation den Datenverkehr jedoch trennen muss, können Sie mehrere NICs pro VM bereitstellen und jede NIC mit einem anderen Subnetz verbinden. Sie können dann Netzwerksicherheitsgruppen verwenden, um verschiedene Zugriffssteuerungsrichtlinien zu erzwingen.

Azure-NICs unterstützen mehrere IPs. Diese Unterstützung entspricht der von SAP empfohlenen Vorgehensweise, virtuelle Hostnamen für Installationen zu nutzen. Einen vollständigen Abriss finden Sie in SAP-Hinweis 962955. Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.

Subnetze und Netzwerksicherheitsgruppen

In dieser Architektur wird der Adressraum des virtuellen Netzwerks in Subnetze unterteilt. Sie können jedes Subnetz einer Netzwerksicherheitsgruppe zuordnen, in der die Zugriffsrichtlinien für das Subnetz definiert sind. Platzieren Sie Anwendungsserver in einem separaten Subnetz. Hierdurch können Sie sie einfacher sichern, indem Sie die Sicherheitsrichtlinien des Subnetzes und nicht die einzelnen Server verwalten.

Wenn Sie eine Netzwerksicherheitsgruppe einem Subnetz zuordnen, gilt die Netzwerksicherheitsgruppe für alle Server innerhalb des Subnetzes und bietet eine detailliertere Steuerung der Server. Richten Sie Netzwerksicherheitsgruppen über das Azure-Portal, PowerShell oder die Azure CLI ein.

ExpressRoute Global Reach

Wenn Ihre Netzwerkumgebung zwei oder mehr ExpressRoute-Verbindungen umfasst, kann Ihnen ExpressRoute Global Reach helfen, Netzwerkhops und Wartezeiten zu reduzieren. Diese Technologie ist eine Einrichtung eines Peerings der BGP-Route (Border Gateway Protocol), die zwischen zwei oder mehr ExpressRoute-Verbindungen zur Überbrückung von zwei ExpressRoute-Routingdomänen eingerichtet ist. Global Reach verringert die Wartezeit, wenn der Netzwerkverkehr mehr als eine ExpressRoute-Verbindung durchläuft. Es ist derzeit nur für privates Peering mit ExpressRoute-Leitungen verfügbar.

Zurzeit gibt es keine Zugriffssteuerungslisten oder anderen Attribute für das Netzwerk, die in Global Reach geändert werden können. Dies bedeutet, dass alle Routen, die von einer bestimmten ExpressRoute-Leitung (lokal oder Azure) ermittelt werden, der anderen ExpressRoute-Leitung über das Leitungspeering angekündigt werden. Wir empfehlen Ihnen, die Filterung des Netzwerkdatenverkehrs lokal einzurichten, um den Zugriff auf die Ressourcen zu beschränken.

ExpressRoute FastPath

FastPath wurde entwickelt, um die Datenpfadleistung zwischen Ihrem lokalen Netzwerk und dem virtuellen Netzwerk zu verbessern. Wenn aktiviert, sendet FastPath den Netzwerkdatenverkehr direkt an virtuelle Computer im virtuellen Netzwerk und umgeht das Gateway.

Für alle neuen ExpressRoute-Verbindungen mit Azure ist FastPath die Standardkonfiguration. Wenden Sie sich wegen vorhandener ExpressRoute-Leitungen an den Azure-Support, um FastPath zu aktivieren.

FastPath unterstützt kein Peering virtueller Netzwerke. Wenn andere virtuelle Netzwerke per Peering mit einem Netzwerk verbunden werden, das mit ExpressRoute verbunden ist, wird der Netzwerkdatenverkehr von Ihrem lokalen Netzwerk zu den anderen virtuellen Spoke-Netzwerken an das virtuelle Netzwerkgateway gesendet. Die Problemumgehung besteht darin, alle virtuellen Netzwerke direkt mit der ExpressRoute-Leitung zu verbinden. Dieses Feature ist zurzeit als öffentliche Preview verfügbar.

Load Balancer

SAP Web Dispatcher verwaltet den Lastenausgleich von HTTP(S)-Datenverkehr in einem Pool von SAP-Anwendungsservern. Dieser Softwarelastenausgleich bietet Anwendungsschichtdienste (im ISO-Netzwerkmodell als „Schicht 7“ bezeichnet), die SSL-Beendigung und andere Abladungsfunktionen ausführen können.

Azure Load Balancer ist ein Dienst auf der Netzwerkübertragungsschicht (Schicht 4), der den Datenverkehr mithilfe eines aus den Datenströmen berechneten 5-Tupel-Hashs ausgleicht. Der Hash basiert auf Quell-IP, Quellport, Ziel-IP, Zielport und Protokolltyp. Bei SAP-Bereitstellungen in Azure wird der Lastenausgleich in Clustersetups genutzt, um Datenverkehr an die primäre Dienstinstanz oder bei einem Fehler an den fehlerfreien Knoten zu leiten.

Wir empfehlen Ihnen, Load Balancer Standard für alle SAP-Szenarien zu verwenden. Wenn VMs im Back-End-Pool öffentliche ausgehende Konnektivität benötigen oder im Rahmen einer Azure-Zonenbereitstellung verwendet werden, sind für Load Balancer Standard weitere Konfigurationsschritte erforderlich, da sie standardmäßig sicher sind. Sie lassen ausgehende Verbindungen nur zu, wenn Sie diese explizit konfigurieren.

Für Datenverkehr von SAP GUI-Clients, die sich über das DIAG-Protokoll oder RFC mit einem SAP-Server verbinden, verteilt der Central Services-Nachrichtenserver die Last über SAP-Anwendungsserver-Anmeldungsgruppen. Sie benötigen für diese Art von Setup keinen weiteren Lastenausgleich.

Storage

Einige Organisationen verwenden den Standardspeicher für ihre Anwendungsserver. Managed Disks Standard werden nicht unterstützt. Weitere Informationen finden Sie im SAP-Hinweis 1928533. Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto. Es wird empfohlen, in allen Fällen verwaltete Azure-Premium-Datenträger zu verwenden. Durch ein vor Kurzem durchgeführtes Update an SAP-Hinweis 2015553 wird die Verwendung von HDD Standard-Speicher und SSD Standard-Speicher für einige spezielle Anwendungsfälle nicht mehr möglich sein.

Anwendungsserver hosten keine Geschäftsdaten. So können Sie auch die kleineren P4- und P6-Premium-Datenträger verwenden, um Kosten zu minimieren. Auf diese Weise können Sie auch von der SLA für Einzelinstanz-VMs profitieren, wenn Sie eine zentrale SAP-Stapelinstallation haben.

Für Hochverfügbarkeitsszenarios können Sie Azure-Dateifreigaben und freigegebene Azure-Datenträger verwenden. Verwaltete Azure SSD Premium-Datenträger und Azure Disk Storage Ultra sind für freigegebene Azure-Datenträger verfügbar, und SSD Premium ist für Azure-Dateifreigaben verfügbar.

Azure Storage wird auch vom Cloudzeugen verwendet, um das Quorum mit einem Gerät in einer Azure-Remoteregion außerhalb der primären Region zu verwalten, in der sich der Cluster befindet.

Für den Sicherungsdatenspeicher empfiehlt es sich, die Azure-Zugriffsebenen „Kalt“ und „Archiv“ zu verwenden. Diese Speicherebenen bieten kostengünstige Möglichkeiten zum Speichern langlebiger Daten, auf die eher selten zugegriffen wird.

Azure SSD Premium v2-Datenträgerspeicher ist für leistungskritische Workloads wie Onlinetransaktionsverarbeitungssysteme konzipiert, die eine Latenz von unter einer Millisekunde in Kombination mit hohem IOPS und hohem Durchsatz benötigen.

Disk Storage Ultra reduziert die Datenträgerlatenz erheblich. Davon profitieren leistungskritische Anwendungen wie die SAP-Datenbankserver. Informationen zum Vergleichen der Optionen für Blockspeicher in Azure finden Sie unter Verwaltete Azure-Datenträgertypen.

Verwenden Sie für einen hochverfügbaren, hochleistungsfähigen freigegebenen Datenspeicher Azure NetApp Files. Diese Technologie ist insbesondere für die Datenbankschicht nützlich, wenn Sie Oracle verwenden, und wenn Sie Anwendungsdaten hosten.

Überlegungen zur Leistung

SAP-Applikationsserver kommunizieren ständig mit den Datenbankservern. Für leistungskritische Anwendungen, die auf Datenbankplattformen ausgeführt werden, aktivieren Sie die Schreibbeschleunigung für das Protokollvolume, wenn Sie SSD Premium v1 verwenden. Dadurch können sich die Wartezeiten der Protokollschreibvorgänge verbessern. Die Schreibbeschleunigung ist für VMs der M-Serie verfügbar.

Um die serverübergreifende Kommunikation zu optimieren, verwenden Sie den beschleunigten Netzwerkbetrieb. Die meisten Größen universeller, computeoptimierter VM-Instanzen mit mindestens zwei vCPUs unterstützen den beschleunigten Netzwerkbetrieb. Auf Instanzen, die Hyperthreading unterstützen, wird der beschleunigte Netzwerkbetrieb auf VM-Instanzen mit mindestens vier vCPUs unterstützt.

Um hohe IOPS und einen hohen Datenträgerdurchsatz zu erzielen, befolgen Sie die gängigen Praktiken zur Optimierung der Leistung von Speichervolumes, die auch für das Azure-Speicherlayout gelten. Sie können beispielsweise mehrere Datenträger zusammen positionieren, um ein Stripeset-Datenträgervolume zu erstellen und so die E/A-Leistung zu verbessern. Eine Aktivierung des Lesecaches für Speicherinhalte, die sich in unregelmäßigen Abständen ändern, bewirkt eine höhere Geschwindigkeit beim Datenabruf.

SSD Premium v2 bietet eine höhere Leistung als Premium-SSDs und ist im Allgemeinen kostengünstiger. Sie können einen SSD Premium-Datenträger (v2) auf jede unterstützte Größe Ihrer Wahl festlegen und dann ohne Downtime Feinanpassungen an der Leistung vornehmen.

Disk Storage Ultra ist für E/A-intensive Anwendungen verfügbar. Wenn diese Datenträger verfügbar sind, empfehlen wir ihre Verwendung anstelle von Premium-Speicher mit Schreibbeschleunigung. Sie können Leistungsmetriken wie IOPS und MBps individuell erhöhen oder verringern, ohne einen Neustart durchführen zu müssen.

Einen Leitfaden zur Optimierung von Azure-Speicher für SAP-Workloads auf SQL Server finden Sie unter Azure Virtual Machines – Planung und Implementierung für SAP NetWeaver.

Die Platzierung eines virtuellen Netzwerkgerät (Network Virtual Appliance, NVA) zwischen der Anwendungs- und der Datenbankschicht für einen beliebigen SAP-Anwendungsstapel wird nicht unterstützt. Diese Vorgehensweise führt zu einer erheblichen Verarbeitungsdauer für Datenpakete und somit zu einer inakzeptablen Anwendungsleistung.

Näherungsplatzierungsgruppen

Einige SAP-Anwendungen müssen häufig mit der Datenbank kommunizieren. Die physische Nähe der Anwendungs- und Datenbankschichten zueinander wirkt sich auf die Netzwerklatenz aus, und hierdurch kann die Anwendungsleistung negativ beeinflusst werden.

Zur Optimierung der Netzwerklatenz können Sie Näherungsplatzierungsgruppen verwenden, mit denen für die in Verfügbarkeitsgruppen bereitgestellten VMs eine logische Einschränkung festgelegt wird. Bei Näherungsplatzierungsgruppen haben „Zusammenstellung“ (Co-Location) und Leistung Vorrang vor Skalierbarkeit, Verfügbarkeit und Kosten. Sie können eine deutliche Verbesserung der Benutzererfahrung für die meisten SAP-Anwendungen bewirken. Skripts, die auf GitHub vom SAP-Bereitstellungsteam zur Verfügung gestellt werden, finden Sie unter Skripts.

Verfügbarkeitszonen

Verfügbarkeitszonen bieten Ihnen die Möglichkeit, rechenzentrumsübergreifend VMs bereitzustellen, d. h. über physisch getrennte Standorte innerhalb einer bestimmten Azure-Region hinweg. Sie dienen zur Verbesserung der Dienstverfügbarkeit. Die zonenübergreifende Bereitstellung von Ressourcen kann jedoch die Wartezeit erhöhen, sodass Sie die leistungsbezogenen Überlegungen im Auge behalten sollten.

Administratoren benötigen ein eindeutiges Netzwerklatenzprofil zwischen allen Zonen einer Zielregion, bevor sie die Ressourcenanordnung mit möglichst geringer Latenz zwischen Zonen bestimmen können. Stellen Sie zur Erstellung dieses Profils in jeder Zone zu Testzwecken VMs bereit. Empfohlene Tools für diese Tests sind beispielsweise PsPing und Iperf. Wenn die Tests abgeschlossen sind, entfernen Sie die VMs, die Sie für die Tests verwendet haben. Alternativ können Sie ein Tool zur Überprüfung der Wartezeit zwischen Azure-Zonen verwenden.

Überlegungen zur Skalierbarkeit

Für die SAP-Logikschicht sind in Azure viele verschiedene VM-Größen für Hochskalieren und Aufskalieren verfügbar. Eine umfassende Liste finden Sie im SAP-Hinweis 1928533: „SAP-Anwendungen in Azure: Unterstützte Produkte und Azure-VM-Typen“. Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.

Sie können die SAP-Anwendungsserver und die Central Services-Cluster hoch- und herunterskalieren. Sie können sie auch auf- oder abskalieren, indem Sie die Anzahl der von Ihnen verwendeten Instanzen ändern. Die AnyDB-Datenbank kann hoch- und herunterskaliert, aber nicht aufskaliert werden. Der SAP-Datenbankcontainer für AnyDB unterstützt kein Sharding.

Überlegungen zur Verfügbarkeit

Ressourcenredundanz ist das allgemeine Thema bei hochverfügbaren Infrastrukturlösungen. Die verschiedenen Speichertypen zugeordneten SLAs für die Verfügbarkeit von Einzelinstanz-VMs finden Sie unter SLA für virtuelle Computer. Um die Dienstverfügbarkeit in Azure zu erhöhen, stellen Sie VM-Ressourcen mit Virtual Machine Scale Sets mit flexibler Orchestrierung, Verfügbarkeitszonen oder Verfügbarkeitsgruppen bereit.

Mit Azure kann die Bereitstellung von SAP-Workloads je nach Verfügbarkeits- und Resilienzanforderungen der SAP-Anwendungen entweder regional oder zonal sein. Azure bietet verschiedene Bereitstellungsoptionen wie Virtual Machine Scale Sets mit flexibler Orchestrierung (FD=1), Verfügbarkeitszonen und Verfügbarkeitsgruppen, um die Verfügbarkeit von Ressourcen zu verbessern. Umfassende Informationen zu den verfügbaren Bereitstellungsoptionen und deren Anwendbarkeit in verschiedenen Azure-Regionen (auch zonenübergreifend, innerhalb einer einzelnen Zone oder in einer Region ohne Zonen) finden Sie unter Hochverfügbarkeitsarchitektur und -szenarien für SAP NetWeaver.

Bei dieser verteilten Installation der SAP-Anwendung wird die Basisinstallation repliziert, um Hochverfügbarkeit zu erzielen. Der Entwurf für die Hochverfügbarkeit variiert für jede Ebene der Architektur.

Web Dispatcher auf Anwendungsserverschicht

Die Web Dispatcher-Komponente wird als Lastenausgleichsmodul für SAP-Datenverkehr zwischen den SAP-Anwendungsservern verwendet. Zur Erzielung von Hochverfügbarkeit für SAP Web Dispatcher wird von Load Balancer entweder der Failovercluster oder das parallele Web Dispatcher-Setup implementiert.

Für Kommunikation im Internet empfehlen wir eine eigenständige Lösung im Umkreisnetzwerk (auch als DMZ bezeichnet), um Sicherheitsanforderungen zu erfüllen.

Embedded Web Dispatcher auf ASCS ist eine besondere Option. Wenn Sie diese Option verwenden, sollten Sie wegen der zusätzlichen Workload für ASCS die richtige Dimensionierung auswählen.

Central Services auf Anwendungsserverschicht

Hochverfügbarkeit von Central Services wird mit einem Windows Server-Failovercluster implementiert. Wenn der Clusterspeicher für den Failovercluster in Azure bereitgestellt wird, können Sie ihn auf zwei Arten konfigurieren: als freigegebener Clusterdatenträger oder als Clusterdateifreigabe.

• Wir empfehlen, dass Sie Azure Files als vollständig verwaltete, cloudnative SMB- oder NFS-Freigaben verwenden. Eine weitere Möglichkeit besteht darin, Azure NetApp Files zu verwenden, das hochleistungsfähige NFS- und SMB-Freigaben auf Unternehmensniveau bietet.

• Ein Cluster kann auf zwei Arten mit freigegebenen Datenträgern in Azure eingerichtet werden. Zunächst empfiehlt es sich, einen Windows Server-Failovercluster für SAP Central Services mithilfe von freigegebenen Azure-Datenträgern einzurichten. Ein Implementierungsbeispiel finden Sie unter ASCS-Cluster mit freigegebenen Azure-Datenträgern. Eine weitere Möglichkeit zum Implementieren eines freigegebenen Clusterdatenträgers ist die Verwendung von SIOS DataKeeper, um folgende Aufgaben auszuführen:

  • Replizieren des Inhalts von unabhängigen Datenträgern, die an die Clusterknoten angefügt sind.
  • Abstrahieren Sie die Laufwerke als freigegebenes Clustervolumen für den Cluster-Manager.

  Implementierungsdetails finden Sie unter Clustering von SAP ASCS in Azure mit SIOS.

Wenn Sie Load Balancer Standard verwenden, können Sie den Hochverfügbarkeitsport aktivieren. Auf diese Weise können Sie vermeiden, Lastenausgleichsregeln für mehrere SAP-Ports konfigurieren zu müssen. Wenn Sie Azure Load Balancer einrichten, aktivieren Sie außerdem die Funktion Direct Server Return (DSR), die auch als Floating IP bezeichnet wird. So können die Serverantworten den Lastenausgleich umgehen. Diese direkte Verbindung verhindert, dass der Lastenausgleich zu einem Engpass auf dem Datenübertragungspfad wird. Wir empfehlen, DSR für die ASCS- und Datenbankcluster zu aktivieren.

Anwendungsdienste auf Anwendungsserverschicht

Hochverfügbarkeit für die SAP-Anwendungsserver wird erzielt, indem für Datenverkehr in einem Pool mit Anwendungsservern ein Lastenausgleich durchgeführt wird. Sie benötigen keine Clustersoftware, keinen SAP Web Dispatcher oder keinen Azure Load Balancer. Der SAP-Nachrichtenserver kann für den Clientdatenverkehr einen Lastenausgleich auf den Anwendungsservern durchführen, die durch die Transaktions-SMLG in einer ABAP-Anmeldegruppe definiert sind.

Datenbankschicht

Bei dieser Architektur wird die Quelldatenbank in AnyDB ausgeführt – einem DBMS wie SQL Server, SAP ASE, IBM DB2 oder Oracle. Die native Replikationsfunktion der Datenbankschicht bietet entweder manuelles oder automatisches Failover zwischen replizierten Knoten:

Implementierungsdetails zu bestimmten Datenbanksystemen finden Sie unter Azure Virtual Machines – DBMS-Bereitstellung für SAP NetWeaver.

Bereitstellung von VMs über Verfügbarkeitszonen hinweg

Eine Verfügbarkeitszone besteht aus mindestens einem Rechenzentrum. Sie soll die Verfügbarkeit von Workloads verbessern und Anwendungsdienste und VMs vor Rechenzentrumsausfällen schützen. Virtuelle Computer in einer Zone werden so behandelt, als würden sie sich in einer einzelnen Fehlerdomäne befinden. Wenn Sie die Zonenbereitstellung auswählen, werden die VMs in derselben Zone auf bestmögliche Weise auf Fehlerdomänen verteilt.

In Azure-Regionen, die mehrere Zonen unterstützen, sind mindestens drei Zonen verfügbar. Der maximale Abstand zwischen Rechenzentren in diesen Zonen ist allerdings nicht garantiert. Für die zonenübergreifende Bereitstellung eines SAP-Systems mit mehreren Ebenen müssen Sie die Netzwerkwartezeit innerhalb einer Zone und für die Zielzonen kennen. Ferner müssen Sie wissen, wie empfindlich Ihre bereitgestellten Anwendungen in Bezug auf die Netzwerkwartezeit sind.

Berücksichtigen Sie diese Überlegungen, wenn Sie sich für die Bereitstellung von Ressourcen über Verfügbarkeitszonen hinweg entscheiden:

• Wartezeit zwischen VMs in einer Zone
• Wartezeit zwischen VMs in ausgewählten Zonen
• Verfügbarkeit der gleichen Azure-Dienste (VM-Typen) in den ausgewählten Zonen

Beispiel für Aktiv/Inaktiv-Bereitstellung

Bei dieser Beispielbereitstellung bezieht sich der Aktiv/Passiv-Status auf den Status des Anwendungsdiensts in den Zonen. Auf der Anwendungsschicht sind alle vier aktiven Anwendungsserver des SAP-Systems in Zone 1 enthalten. Eine weitere Gruppe mit vier passiven Anwendungsservern wird in Zone 2 erstellt, dann aber heruntergefahren. Sie werden nur aktiviert, wenn sie benötigt werden.

Die Cluster mit zwei Knoten für Central Services und die Datenbankdienste sind auf zwei Zonen verteilt. Falls Zone 1 ausfällt, werden Central Services und die Datenbankdienste in Zone 2 ausgeführt. Die passiven Anwendungsserver in Zone 2 werden aktiviert. Da sich nun alle Komponenten dieses SAP-Systems in derselben Zone befinden, wird die Netzwerklatenz verringert.

Beispiel für Aktiv/Aktiv-Bereitstellung

Bei einer Aktiv/Aktiv-Bereitstellung werden zwei Gruppen mit Anwendungsservern in zwei Zonen erstellt. In jeder Zone sind jeweils zwei Anwendungsserver der Servergruppe inaktiv, da sie heruntergefahren sind. Es gibt also in beiden Zonen während des Normalbetriebs aktive Anwendungsserver.

Central Services und die Datenbankdienste werden in Zone 1 ausgeführt. Die Anwendungsserver in Zone 2 verfügen aufgrund der physischen Entfernung zwischen den Zonen ggf. über eine höhere Netzwerkwartezeit beim Herstellen der Verbindung mit Central Services und den Datenbankdiensten.

Wenn Zone 1 in den Offlinezustand versetzt wird, wird für Central Services und die Datenbankdienste ein Failover in Zone 2 ausgeführt. Sie können die ruhenden Anwendungsserver in den Onlinezustand versetzen, um die vollständige Kapazität für die Anwendungsverarbeitung bereitzustellen.

Überlegungen zur Notfallwiederherstellung

Für jede Ebene im SAP-Anwendungsstapel wird ein anderer Ansatz genutzt, um den Schutz per Notfallwiederherstellung bereitzustellen. Ausführliche Informationen zu Notfallwiederherstellungstrategien und Implementierungsdetails finden Sie unter Übersicht über die Notfallwiederherstellung und Leitlinien für die Infrastruktur für SAP-Workloads und Richtlinien zur Notfallwiederherstellung für SAP-Anwendungen.

Aspekte der Verwaltung und des Betriebs

Damit Ihr System in der Produktion ausgeführt werden kann, sollten Sie die folgenden Punkte beachten.

Azure Center for SAP solutions

Azure Center for SAP solutions ist eine End-to-End-Lösung, mit der Sie SAP-Systeme als einheitliche Workload in Azure erstellen und ausführen können und die eine nahtlosere Grundlage für Innovationen bietet. Überdies erstellt die von Azure Center for SAP solutions gesteuerte Bereitstellung die erforderlichen Compute-, Speicher- und Netzwerkkomponenten, die Sie zum Ausführen Ihres SAP-Systems benötigen. Sie hilft dann dabei, die Installation von SAP-Software gemäß den bewährten Methoden von Microsoft zu automatisieren. Sie können die Vorteile der Verwaltungsfunktionen sowohl für neue als auch für bestehende Azure-basierte SAP-Systeme nutzen. Weitere Informationen finden Sie unter Azure Center for SAP solutions

Wenn Sie stärkere Kontrolle über Wartungsereignisse oder Hardwareisolierung benötigen, sei es aus Leistungs- oder aus Compliancegründen, sollten Sie erwägen, Ihre VMs auf dedizierten Hosts bereitzustellen.

Backup

Datenbanken sind kritische Workloads, für die ein niedriger RPO-Wert (Recovery Point Objective) und eine Langzeitaufbewahrung erforderlich sind.

• Für SAP unter SQL Server besteht ein Ansatz darin, Azure Backup zum Sichern von SQL Server-Datenbanken zu nutzen, die auf VMs ausgeführt werden. Eine weitere Möglichkeit ist die Verwendung von Azure Files-Momentaufnahmen zum Sichern von SQL Server-Datenbankdateien.

• Informationen zu SAP unter Oracle/Windows finden Sie im Abschnitt „Sichern/Wiederherstellen“ unter Azure Virtual Machines – DBMS-Bereitstellung für SAP-Workload.

• Lesen Sie für andere Datenbanken in den Sicherungsempfehlungen Ihres Datenbankanbieters nach. Wenn die Datenbank den Windows-Volumeschattenkopie-Dienst (VSS) unterstützt, verwenden Sie VSS-Momentaufnahmen für anwendungskonsistente Sicherungen.

Identitätsverwaltung

Verwenden Sie ein zentralisiertes Identitätsverwaltungssystem wie Microsoft Entra ID und Active Directory Domain Services (AD DS), um den Zugriff auf Ressourcen auf allen Ebenen zu steuern:

• Stellen Sie Zugriff auf Azure-Ressourcen über die rollenbasierte Zugriffssteuerung in Azure (Azure RBAC) bereit.

• Verwenden Sie Lightweight Directory Access Protocol (LDAP), Microsoft Entra ID, Kerberos oder ein anderes System, um Zugriff auf Azure-VMs zu gewähren.

Ermöglichen Sie Zugriff in den Anwendungen selbst über die Dienste, die SAP bereitstellt. Oder verwenden Sie OAuth 2.0- und Microsoft Entra-ID.

Monitoring

Verwenden Sie Azure Monitor zum Maximieren der Verfügbarkeit und Leistung Ihrer Anwendungen und Dienste in Azure. Dies ist eine umfassende Lösung für das Sammeln, Analysieren und Reagieren auf Telemetriedaten aus Ihren cloudbasierten und lokalen Umgebungen. In Azure Monitor wird angezeigt, welches Leistungsverhalten Ihre Anwendungen aufweisen. Es werden proaktiv Probleme erkannt, die diese Anwendungen und die Ressourcen, von denen sie abhängen, betreffen. Informationen zu SAP-Anwendungen, die auf SAP HANA und anderen wichtigen Datenbanklösungen ausgeführt werden, finden Sie unter Azure Monitor für SAP-Lösungen. Hier erfahren Sie, wie Azure Monitor für SAP Ihnen helfen kann, die Verfügbarkeit und Leistung von SAP-Diensten zu verwalten.

Sicherheitsüberlegungen

SAP verfügt über ein eigenes Modul für die Benutzerverwaltung (User Management Engine, UME), um den rollenbasierten Zugriff und die Autorisierung in der SAP-Anwendung und den Datenbanken zu steuern. Eine ausführliche Anleitung zur Anwendungssicherheit finden Sie im Sicherheitsleitfaden zu SAP NetWeaver.

Um zusätzliche Netzwerksicherheit zu erzielen, sollten Sie erwägen, ein Umkreisnetzwerk zu verwenden, das ein virtuelles Netzwerkgerät (NVA) nutzt, um eine Firewall vor dem Subnetz für Web Dispatcher zu erstellen.

Sie können ein virtuelles Netzwerkgerät (NVA) bereitstellen, um Datenverkehr zwischen virtuellen Netzwerken zu filtern, aber Sie sollten es nicht zwischen der SAP-Anwendung und der Datenbank anordnen. Überprüfen Sie auch die Routingregeln, die im Subnetz konfiguriert sind, und vermeiden Sie es, Datenverkehr an eine Einzelinstanz-NVA zu leiten. Dies kann zu Ausfallzeiten aufgrund von Wartungsvorgängen und zu Netzwerk- oder Clusterknotenfehlern führen.

Um die Sicherheit der Infrastruktur zu gewährleisten, sind die Daten während der Übertragung und im Ruhezustand verschlüsselt. Informationen zur Netzwerksicherheit finden Sie im Abschnitt „Sicherheitsempfehlungen“ in Azure Virtual Machines – Planung und Implementierung für SAP NetWeaver. In diesem Artikel sind auch die Netzwerkports angegeben, die Sie in den Firewalls öffnen müssen, um die Anwendungskommunikation zu ermöglichen.

Um Datenträger einer Windows-VM zu verschlüsseln, können Sie Azure Disk Encryption verwenden. Dieser Dienst verwendet das BitLocker-Feature von Windows, um die Volumeverschlüsselung für die Betriebssystem- und die Daten-Datenträger bereitzustellen. Die Lösung funktioniert auch für Azure Key Vault, damit Sie die Verschlüsselungsschlüssel und Geheimnisse für die Datenträgerverschlüsselung in Ihrem Key Vault-Abonnement steuern und verwalten können. Die Daten auf den Datenträgern der VM werden im Ruhezustand in Ihrem Azure-Speicher verschlüsselt.

Für die Verschlüsselung von ruhenden Daten werden per SQL Server Transparent Data Encryption (TDE) SQL Server-, Azure SQL-Datenbank- und Azure Synapse Analytics-Datendateien verschlüsselt. Weitere Informationen finden Sie unter Azure Virtual Machines – SQL Server-DBMS-Bereitstellung für SAP NetWeaver.

Erwägen Sie die Bereitstellung von Microsoft Sentinel (Vorschauversion), um Bedrohungen innerhalb und außerhalb der Firewall zu überwachen. Die Lösung bietet kontinuierliche Bedrohungserkennung und Analysen für SAP-Systeme, die in Azure, in anderen Clouds oder lokal bereitgestellt werden. Eine Anleitung zur Bereitstellung finden Sie unter Bereitstellen von Threat Monitoring für SAP in Microsoft Sentinel.

Verwalten Sie wie immer Sicherheitsupdates und Patches, um Ihre Informationsressourcen zu schützen. Erwägen Sie, für diese Aufgabe einen Ansatz mit End-to-End-Automatisierung zu nutzen.

Kostenbetrachtung

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.

Wenn Ihre Workload mehr Arbeitsspeicher und weniger CPUs erfordert, sollten Sie die Verwendung einer der eingeschränkten vCPU VM-Größen in Erwägung ziehen, um die Kosten der Softwarelizenzierung zu senken, die pro vCPU berechnet werden.

VMs

In dieser Architektur werden VMs für die Logikschicht und die Datenbankschicht verwendet. Auf der SAP NetWeaver-Schicht werden Windows-VMs verwendet, um SAP-Dienste und -Anwendungen auszuführen. Auf der Datenbankschicht wird AnyDB als Datenbank ausgeführt wie SQL Server, Oracle oder IBM DB2. Virtuelle Computer werden auch als Jumpboxes für die Verwaltung verwendet.

Es gibt verschiedene Zahlungsoptionen für VMs:

• Für Workloads, bei denen der Zeitpunkt des Abschlusses oder der Ressourcenverbrauch nicht vorhersehbar ist, bietet sich die nutzungsbasierte Bezahlung an.

• Verwenden Sie Azure-Reservierungen, wenn Sie die Nutzung einer VM über einen Zeitraum von einem Jahr oder drei Jahren verbindlich zusagen können. VM-Reservierungen können Kosten erheblich reduzieren. Sie zahlen vielleicht nur 72 Prozent der Kosten eines Diensts mit nutzungsbasierter Bezahlung.

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. Azure stellt Spot-VMs bereit, wenn Kapazität verfügbar ist, und entfernt sie, wenn die Kapazität wieder benötigt wird. Die mit Spot-VMs verbundenen Kosten sind niedriger als bei anderen VMs. Spot-VMs bieten sich für die folgenden Workloads an:

• High-Performance Computing, Batchverarbeitungsaufträge oder visuelle Renderinganwendungen
• Testumgebungen, einschließlich Continuous Integration- und Continuous Delivery-Workloads
• Umfangreiche zustandslose Anwendungen

Azure Reserved Virtual Machine Instances können Ihre Gesamtkosten senken, indem Sie Azure Reserved Virtual Machine Instances-Tarife mit einem Abonnement mit nutzungsbasierter Bezahlung kombinieren, sodass Sie die Kosten für vorhersagbare und variable Workloads verwalten können. Weitere Informationen finden Sie unter Azure Reserved Virtual Machine Instances.

Load Balancer

In diesem Szenario wird Load Balancer verwendet, um Datenverkehr auf VMs im Logikschichtsubnetz zu verteilen.

Sie zahlen nur für die Anzahl konfigurierter Lastenausgleichs- und Ausgangsregeln sowie für die durch den Lastenausgleich verarbeiteten Daten. Die Regeln für eingehende Netzwerkadressenübersetzung (NAT) sind kostenlos. Für Load Balancer Standard fallen keine Kosten auf Stundenbasis an, wenn keine Regeln konfiguriert sind.

ExpressRoute

Bei dieser Architektur ist ExpressRoute der Netzwerkdienst, der zum Erstellen von privaten Verbindungen zwischen einem lokalen Netzwerk und virtuellen Azure-Netzwerken verwendet wird.

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.

Communitys

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

• Ausführen von SAP-Anwendungen auf der Microsoft-Plattform (Blog)
• Azure-Communitysupport
• SAP Community
• Stapelüberlauf für 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.

Nächste Schritte

Weitere Informationen und Beispiele für SAP-Workloads, für die einige derselben Technologien wie für diese Architektur verwendet werden, finden Sie in diesen Artikeln:

• Azure Virtual Machines – Planung und Implementierung für SAP NetWeaver
• Verwenden von Azure zum Hosten und Ausführen von SAP-Workloadszenarien

Zugehörige Ressourcen

• Ausführen von SAP-Produktionsworkloads mit einer Oracle Database-Instanz in Azure