Bearbeiten

Freigeben über

SAP-Bereitstellung in Azure unter Verwendung einer Oracle-Datenbank

Azure ExpressRoute
SAP HANA in Azure (große Instanzen)
Azure Virtual Machines
Azure Virtual Network
Azure NetApp Files

Diese Referenzarchitektur zeigt einige bewährte Methoden für die Ausführung einer SAP NetWeaver-Anwendung für Hochverfügbarkeit mit Oracle Database in Azure. Die Architekturprinzipien sind zwar betriebssystemunabhängig, aber diese Architektur basiert auf Linux, sofern nichts anderes angegeben ist.

Das erste Diagramm zeigt eine Referenzarchitektur für SAP in Oracle in Azure. Es wird empfohlen, dass Sie über zwei Verfügbarkeitszonen hinweg bereitstellen.

Diagramm: Architektur eines SAP-Produktionssystems in Oracle in Azure

Laden Sie eine Visio-Datei mit Diagrammen dieser und ähnlicher Architekturen herunter.

Hinweis

Zum Bereitstellen dieser Referenzarchitektur benötigen Sie eine passende Lizenzierung von SAP-Produkten und anderen, nicht von Microsoft stammenden Technologiekomponenten.

Komponenten

Bei dieser Referenzarchitektur handelt es sich um ein typisches SAP-Produktionssystem, das unter Oracle Database in Azure in einer hochverfügbaren Bereitstellung ausgeführt wird, um die Systemverfügbarkeit zu maximieren. Die Architektur und ihre Komponenten können basierend auf den geschäftlichen Anforderungen (Recovery Time Objective (RTO), Recovery Point Objective (RPO), erwartete Uptime, Systemrolle) angepasst und ggf. auf einen einzelnen virtuellen Computer reduziert werden. Das Netzwerklayout wurde vereinfacht, um die Architekturprinzipien einer solchen SAP-Umgebung zu veranschaulichen, und dient nicht dazu, ein vollständiges Unternehmensnetzwerk zu beschreiben.

Netzwerk

Virtuelle Netzwerke. Der Azure Virtual Network-Dienst verbindet Azure-Ressourcen miteinander mit erweiterter Sicherheit. In dieser Architektur stellt das virtuelle Netzwerk über ein VPN-Gateway (Virtual Private Network), das im Hub einer Hub-Speichentopologie bereitgestellt wird, eine Verbindung mit dem lokalen Netzwerk herstellt. SAP-Anwendungen und die Datenbank befinden sich in einem eigenen virtuellen Spoke-Netzwerk. Die virtuellen Netzwerke sind für jede Ebene jeweils in getrennte Subnetze unterteilt: Anwendung (SAP NetWeaver), Datenbank, gemeinsam genutzte Dienste (z. B. Azure Bastion).

In dieser Architektur wird der Adressraum des virtuellen Netzwerks in Subnetze unterteilt. Platzieren Sie Anwendungsserver und Datenbankserver in separaten Subnetzen. Dadurch können Sie anstelle der einzelnen Server die Subnetzsicherheitsrichtlinien verwalten, was den Schutz vereinfacht, und Sicherheitsregeln für Datenbanken sind klar von Anwendungsservern getrennt.

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 -isolierung 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.

Zonenredundantes 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. Verwenden Sie zonenredundante Azure ExpressRoute- oder VPN-Gateways, um vor Zonenfehlern zu schützen. Informationen zu den Unterschieden zwischen einer zonenorientierten und zonenredundanten Bereitstellung finden Sie unter Zonenredundante Gateways für virtuelle Netzwerke. Hinweis: Für eine Zonenbereitstellung der Gateways müssen die verwendeten IP-Adressen von der Standard-SKU stammen.

Netzwerksicherheitsgruppen: Erstellen Sie Netzwerksicherheitsgruppen (NSGs), um den eingehenden, ausgehenden und subnetzinternen Datenverkehr im virtuellen Netzwerk einzuschränken. Diese Netzwerksicherheitsgruppen werden dann wiederum bestimmten Subnetzen zugewiesen. Datenbank- und Anwendungssubnetze werden durch workloadspezifische NSGs geschützt.

Anwendungssicherheitsgruppen: Verwenden Sie Anwendungssicherheitsgruppen anstelle von expliziten IP-Adressen, um detaillierte Netzwerksicherheitsrichtlinien in Ihren Netzwerksicherheitsgruppen basierend auf Workloads zu definieren, die auf Anwendungen ausgerichtet sind. Hiermit können Sie VMs nach Name gruppieren und Anwendungen schützen, indem Sie Datenverkehr aus vertrauenswürdigen Segmenten Ihres Netzwerks filtern.

Netzwerkschnittstellenkarten (NICs). Netzwerkschnittstellenkarten ermöglichen die gesamte Kommunikation zwischen virtuellen Computern 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 für die einzelnen Subnetze zu erzwingen.

Azure-NICs unterstützen mehrere IPs. Diese Unterstützung hält die von SAP empfohlene Vorgehensweise ein, virtuelle Hostnamen für Installationen zu nutzen. Einen vollständigen Abriss finden Sie in SAP-Hinweis 962955. (Für den Zugriff auf SAP-Notizen benötigen Sie ein SAP Service Marketplace-Konto.)

Virtuelle Computer

In dieser Architektur werden virtuelle Computer (Virtual Machines, VMs) verwendet. Für SAP-Anwendungsebene werden VMs für alle Instanzrollen bereitgestellt – Web Dispatcher und Anwendungsserver – sowohl zentrale Dienste SAP (A)SCS und ERS als auch Anwendungsserver (PAS, AAS). Passen Sie die Anzahl virtueller Computer an Ihre Anforderungen an. Die Anleitung zur Planung und Implementierung von virtuellen Azure-Computern enthält Informationen über das Ausführen von SAP NetWeaver auf virtuellen Computern.

Analog dazu werden für alle Oracle-Zwecke virtuelle Computer verwendet – sowohl für Oracle Database als auch für Oracle Observer. Virtuelle Observer-Computer in dieser Architektur sind kleiner als die eigentlichen Datenbankserver.

  • VMs mit eingeschränkter vCPU. Erwägen Sie die Verwendung von VMs mit eingeschränkter vCPU, um ggf. Kosten für die Oracle-Lizenzierung zu sparen.
  • Zertifizierte VM-Familien für SAP. Ausführliche Informationen zur SAP-Unterstützung für die Typen virtueller Azure-Computer und die Durchsatzmetriken (SAPS) finden Sie in SAP-Hinweis 1928533. (Für den Zugriff auf SAP-Notizen benötigen Sie ein SAP Service Marketplace-Konto.)

Näherungsplatzierungsgruppen (PPGs). Wenn virtuelle Computer in Verfügbarkeitszonen bereitgestellt werden, ist die Latenz innerhalb der Zone in der Regel ideal für SAP-Anwendungen. In seltenen Situationen, in dem die Latenz zwischen der Datenbank und virtuellen Anwendungscomputern verringert werden muss, können Sie Näherungsplatzierungsgruppen verwenden. Für solche Situationen stellen PPGs die Kollokation sicher, d. h., dass sich virtuelle Computer im gleichen Rechenzentrum befinden, um die Anwendungslatenz zu minimieren. Aufgrund potenzieller Einschränkungen mit PPGs sollte das Hinzufügen der Datenbank AvSet zur PPG des SAP-Systems nur sparsam und nur bei Bedarf erfolgen. Weitere Informationen zu den Verwendungsszenarien für PPGs finden Sie in der verlinkten Dokumentation.

VMs der 2. Generation (Gen2). Beim Bereitstellen von VMs bietet Azure Ihnen die Wahl: Generation 1 oder Generation 2. VMs der zweiten Generation unterstützen wichtige Features, die für VMs der ersten Generation nicht verfügbar sind. Dies ist insbesondere bei sehr großen Oracle-Datenbanken wichtig, da einige VM-Familien wie Mv2 oder Mdsv2nur für Gen2-VMs unterstützt werden. Ebenso bietet die SAP in Azure-Zertifizierung bei einigen neueren VMs u. U. nur für Gen2-VMs vollständige Unterstützung, obwohl Azure die Verwendung beider Generationen zulässt. Weitere Informationen finden Sie im SAP-Hinweis 1928533 (SAP-Anwendungen in Microsoft Azure: Unterstützte Produkte und Azure-VM-Typen).

Da alle anderen VMs, die SAP unterstützen, die Wahl zwischen „Nur Gen2“ oder „Gen1+2“ zulassen, wird empfohlen, alle SAP VMs als „Gen2“ bereitzustellen, auch wenn die Arbeitsspeicheranforderungen sehr gering sind. Selbst die kleinsten virtuellen Computer, die als Gen2 bereitgestellt wurden, können mit einem einfachen Deallocate- und Größenänderungsvorgang auf den größten verfügbaren Skaliert werden. Die Größe von Gen1-VMs kann nur in VM-Familien geändert werden, bei denen die Ausführung von Gen1-VMs zulässig ist.

Storage

In dieser Architektur werden verwaltete Azure-Datenträger für virtuelle Computer sowie Azure-Dateifreigaben oder Azure NetApp Files für alle Anforderungen im Zusammenhang mit freigegebenem NFS-Speicher (beispielsweise sapmnt und SAP-Transport-NFS-Volumes) verwendet. Richtlinien für die Speicherbereitstellung mit SAP in Azure werden im Leitfaden Azure Storage-Typen für die SAP-Workload ausführlich beschrieben.

Hochverfügbarkeit

Die oben gezeigte Architektur stellt eine Hochverfügbarkeitsbereitstellung dar, bei sich die einzelnen Anwendungsebenen jeweils auf zwei oder mehr VMs befinden. Die folgenden Komponenten werden verwendet.

Bei Azure kann die SAP-Workloadbereitstellung entweder regional oder zonal sein, abhängig von den Verfügbarkeits- und Resilienzanforderungen der SAP-Anwendungen und der ausgewählten Region. Azure bietet verschiedene Bereitstellungsoptionen wie VM-Skalierungsgruppen mit flexibler Orchestrierung (FD=1), Verfügbarkeitszonen und Verfügbarkeitsgruppen, um die Verfügbarkeit von Ressourcen zu verbessern. Umfassende Informationen zu den Bereitstellungsoptionen und deren Anwendbarkeit in verschiedenen Azure-Regionen (zonenübergreifend, innerhalb einer einzelnen Zone oder in einer Region ohne Zonen) finden Sie unter Hochverfügbarkeitsarchitektur und -szenarien für SAP NetWeaver.

Lastenausgleich. Azure Load Balancer wird verwendet, um den Datenverkehr auf VMs in den SAP-Subnetzen zu verteilen. Wenn Sie Azure Load Balancer in einer zonenbasierten SAP-Bereitstellung einbinden, wählen Sie unbedingt die Standard-SKU von Load Balancer aus. Die Basic-SKU unterstützt keine Zonenredundanz.

Berücksichtigen Sie beim Bereitstellen von virtuellen Computern zwischen Verfügbarkeitszonen für SAP die Entscheidungsfaktoren. Die Verwendung von Näherungsplatzierungsgruppen mit einer Verfügbarkeitszonenbereitstellung muss ausgewertet werden und ist nur für virtuelle Computer auf Anwendungsebene zulässig.

Hinweis

Verfügbarkeitszonen unterstützen regionale Hochverfügbarkeit, sind aber für die Notfallwiederherstellung (DR) nicht effektiv. Die Abstände zwischen den Zonen sind zu kurz. Regionen für die Notfallwiederherstellung sollten normalerweise mindestens 160 km von der primären Region entfernt sein.

Oracle-spezifische Komponenten. Oracle Database-VMs werden in einer Verfügbarkeitsgruppe oder in verschiedenen Verfügbarkeitszonen bereitgestellt. Jeder virtuelle Computer enthält eine eigene Installation der Datenbanksoftware und des VM-lokalen Datenbankspeichers. Richten Sie zwischen den Datenbanken eine synchrone Datenbankreplikation über Oracle Data Guard ein, um die Konsistenz sicherzustellen und im Falle einzelner Fehler niedrige RTO- und RPO-Dienstzeiten zu ermöglichen. Für ein Oracle Data Guard Fast-Start Failover-Setup sind neben den Datenbank-VMs weitere virtuelle Computer mit Oracle Data Guard Observer erforderlich. Die Oracle Observer-VMs überwachen den Datenbank- und Replikationsstatus und ermöglichen automatisierte Datenbankfailover ohne Cluster-Manager. Die Verwaltung der Datenbankreplikation kann dann mithilfe von Oracle Data Guard Broker erfolgen, um die Benutzerfreundlichkeit zu verbessern.

Ausführliche Informationen zur Oracle Data Guard-Bereitstellung finden Sie in der Dokumentation zu Oracle Data Guard in Azure.

Diese Architektur verwendet native Oracle-Tools ohne tatsächliche Clustersoftware oder die Notwendigkeit eines Lastenausgleichs in der Datenbankebene. Mit Oracle Data Guard Fast-Start Failover und SAP-Konfiguration wird der Failoverprozess automatisiert, und von SAP-Anwendungen wird im Falle eines Failovers wieder eine Verbindung mit der neuen primären Datenbank hergestellt. Alternativ stehen verschiedene Clusterlösungen von Drittanbietern wie etwa SIOS Protection Suite oder Veritas InfoScale zur Verfügung. Details zur Bereitstellung finden Sie in der Dokumentation des jeweiligen Drittanbieters.

Oracle RAC. Oracle Real Application Cluster (RAC) ist derzeit von Oracle in Azure nicht zertifiziert und wird nicht unterstützt. Oracle Data Guard-Technologien und Architekturen für Hochverfügbarkeit können jedoch hochgradig resiliente SAP-Umgebungen mit Schutz vor Dienstunterbrechungen auf Rack-, Rechenzentrums- oder Regionsebene bieten.

NFS-Ebene. Bei allen hochverfügbaren SAP-Bereitstellungen muss eine resiliente NFS-Ebene verwendet werden, die NFS-Volumes für das SAP-Transportverzeichnis, das sapmnt-Volume für SAP-Binärdateien sowie weitere Volumes für (A)SCS- und ERS-Instanzen bietet. Für die Bereitstellung einer NFS-Ebene stehen folgende Optionen zur Verfügung:

  • Azure Files NFS mit zonenredundantem Speicher (ZRS): Leitfäden für SLES und RHEL
  • Azure NetApp Files-Bereitstellung von NFS-Volumes: Leitfäden für SLES und RHEL
  • VM-basierter NFS-Cluster: Zwei zusätzliche virtuelle Computer mit lokalem Speicher, der zwischen virtuellen Computern mit DRBD (Distributed Replicated Block Device) repliziert wird: Leitfäden für SLES und RHEL

SAP Central Services-Cluster. Diese Referenzarchitektur führt Central Services auf separaten VMs aus. Bei der Bereitstellung auf nur einer VM kann Central Services ggf. einen Single Point of Failure darstellen. Für die Implementierung einer hochverfügbaren Lösung ist eine Clusterverwaltungssoftware erforderlich, die das Failover von (A)SCS- und ERS-Instanzen auf den jeweiligen virtuellen Computer automatisiert. Dies ist stark an die ausgewählte NFS-Lösung gebunden.

Für die gewählte Clusterlösung wird ein Entscheidungsmechanismus für die Frage benötigt, von welchem virtuellen Computer die jeweiligen Dienste bereitgestellt werden sollen, falls Software oder Infrastruktur nicht verfügbar sein sollte. Mit SAP in Azure stehen zwei Optionen für die Linux-basierte Implementierung von STONITH zur Verfügung (Umgang mit nicht reagierenden virtuellen Computern oder Anwendungen).

  • Nur SUSE Linux: STONITH-Blockgerät (STONITH Block Device, SBD): Mit einem oder drei zusätzlichen virtuellen Computern, die als iSCSI-Exporte eines kleinen Blockgeräts fungieren, auf das regelmäßig von den tatsächlichen Clustermitglieds-VMs zugegriffen wird: zwei (A)SCS/ERS-VMs in diesem Clusterpool. Diese SBD-Bereitstellungen werden von den virtuellen Computern verwendet, um Stimmen abzugeben und so ein Quorum für Clusterentscheidungen zu erreichen. Die Architektur auf dieser Seite verfügt NICHT über eine oder drei zusätzliche SBD-VM(s).
  • Azure-Fence-Agent. Die regelmäßige Überprüfung der VM-Verfügbarkeit erfolgt über die Azure-Verwaltungs-API – es sind keine weiteren VMs erforderlich.

Die im Abschnitt zur NFS-Ebene verlinkten Leitfäden enthalten die erforderlichen Schritte und den Entwurf für die jeweilige Clusteroption. Azure-zertifizierte Clustermanager von Drittanbietern können auch verwendet werden, um hohe Verfügbarkeit der SAP Central Services bereitzustellen.

SAP-Anwendungsserverpool. Mindestens zwei Anwendungsserver, auf denen Hochverfügbarkeit durch Lastenausgleich von Anforderungen über einen SAP-Nachrichtenserver oder SAP Web Dispatcher erreicht wird. Jeder Anwendungsserver ist unabhängig, und für diesen VM-Pool ist kein Netzwerklastenausgleich erforderlich.

SAP Web Dispatcher-Pool. 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 Azure Load Balancer entweder der Failovercluster oder das parallele Web Dispatcher-Setup implementiert.

Embedded Web Dispatcher in (A)SCS ist eine besondere Option. Achten Sie aufgrund der zusätzlichen Workload in (A)SCS auf eine ausreichende Dimensionierung.

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

Windows-Bereitstellungen. In diesem Dokument werden, wie eingangs angekündigt, in erster Linie Linux-basierte Bereitstellungen behandelt. Für die Verwendung mit Windows gelten die gleichen Architekturprinzipien, und es gibt mit Oracle keine Architekturunterschiede zwischen Linux und Windows.

Informationen zum SAP-Anwendungsteil finden Sie in den Details des Architekturleitfadens Ausführen von SAP NetWeaver unter Windows in Azure.

Überlegungen

Notfallwiederherstellung

Das folgende Diagramm zeigt die Architektur eines SAP-Produktionssystems in Oracle in Azure. Die Architektur bietet Notfallwiederherstellung und verwendet Verfügbarkeitszonen.

Diagramm: Architektur eines SAP-Produktionssystems in Oracle in Azure

Laden Sie eine Visio-Datei mit Diagrammen dieser und ähnlicher Architekturen herunter.

Jede Architekturebene im SAP-Anwendungsstapel verwendet einen anderen Ansatz, um für DR-Schutz zu sorgen. Ausführliche Informationen zu Strategien und Implementierung der Notfallwiederherstellung 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.

Backup

Die Sicherung für Oracle in Azure kann auf verschiedene Arten erreicht werden:

  • Azure Backup. Skripts, die von Azure für Oracle Database und Azure Backup für Oracle bereitgestellt und verwaltet werden, erfüllen sicherungsanforderungen.
  • „Azure Storage“. Nutzung dateibasierter Datenbanksicherungen – beispielsweise mit den BR-Tools von SAP geplant –, die als Dateien bzw. Verzeichnisse in den Speicherdiensten Azure Blob NFS, Azure Blob oder Azure Files gespeichert und versioniert werden. Ausführliche Informationen zur Sicherung von Oracle-Daten und -Protokollen finden Sie in der Dokumentation.
  • Sicherungslösungen von Drittanbietern. Informationen hierzu finden Sie beim Anbieter Ihres Sicherungsspeichers, der Oracle in Azure unterstützt.

Für datenbankfremde virtuelle Computer wird Azure Backup für virtuelle Computer empfohlen, um SAP-Anwendungs-VMs und die umgebende Infrastruktur wie SAP Web Dispatcher zu schützen.

Beitragende

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

Hauptautor:

Nächste Schritte

Communitys

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

Weitere Informationen und Beispiele für SAP-Workloads, für die einige dieser Technologien verwendet werden, finden Sie im folgenden Artikel: