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. Die Architektur verwendet Verfügbarkeitsgruppen.

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 (RTO, 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 wird das virtuelle Netzwerk über ein VPN-Gateway mit einer lokalen Umgebung verbunden, und dieses Gateway wird im Hub einer Hub-Spoke-Topologie bereitgestellt. 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. Es verursacht keine Leistungseinbußen, wenn es innerhalb einer einzelnen Region bereitgestellt wird.

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. Azure ExpressRoute- oder VPN-Gateways können zonenübergreifend bereitgestellt werden, um den Schutz vor Zonenausfällen zu ermöglichen. 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, 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. (Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.)

Virtuelle Computer

In dieser Architektur werden virtuelle Computer (Virtual Machines, VMs) verwendet. Für die SAP-Logikschicht werden virtuelle Computer für alle Instanzrollen bereitgestellt (Web Dispatcher und Anwendungsserver) – sowohl für SAP (A)SCS und ERS als auch für 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. (Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.)

Näherungsplatzierungsgruppen (PPGs). Zur Optimierung der Netzwerklatenz können Sie Näherungsplatzierungsgruppen verwenden, die bevorzugt am selben Ort platziert werden. Das bedeutet, dass sich die VMs im selben Rechenzentrum befinden, um die Latenz zu minimieren. Sie können eine deutliche Verbesserung der Benutzererfahrung für die meisten SAP-Anwendungen bewirken. Aufgrund potenzieller Einschränkungen durch PPGs sollte die Verfügbarkeitsgruppe (AvSet) der Datenbank nur vereinzelt und nur, wenn dies aufgrund der Wartezeit beim Datenverkehr zwischen SAP-Anwendung und Datenbank erforderlich ist, der PPG des SAP-Systems hinzugefügt werden. 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 VMs können nach der Bereitstellung als Gen2-VMs mit einer einfachen Aufhebung der Zuordnung und Änderung der Größe auf die größte verfügbare Größe 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 Files NFS 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.

  • Zertifizierter Speicher für SAP. Entsprechen zertifizierten VM-Typen für den SAP-Einsatz. Weitere Informationen dazu finden Sie in den SAP-Hinweisen 2015553 und 2039619.
  • Speicherentwurf für SAP in Oracle. Unter Oracle-DBMS-Bereitstellung für SAP-Workload auf Azure Virtual Machines finden Sie einen empfohlenen Speicherentwurf. Dieser Artikel enthält spezifische Anleitungen zum Dateisystemlayout, Empfehlungen für die Datenträgerdimensionierung und weitere Speicheroptionen.
  • Speichern von Oracle Database-Dateien. Unter Linux müssen die Dateisysteme ext4 oder xfs für die Datenbank verwendet werden, bei Windows-Bereitstellungen ist NTFS erforderlich. Oracle ASM wird auch für Oracle-Bereitstellungen für Oracle Database ab 12c Release 2 unterstützt.
  • Alternativen zu verwalteten Datenträgern. Sie können alternativ auch Azure NetApp Files für die Oracle Database-Instanz verwenden. Weitere Informationen finden Sie im SAP-Hinweis 2039619 und in der Dokumentation zu Oracle in Azure. NFS-Volumes in Azure Files sind im Gegensatz zu Azure NetApp Files nicht zum Speichern von Oracle Database-Dateien vorgesehen.
  • Azure SSD Premium v2 ist für leistungskritische Workloads wie SAP konzipiert. Unter Bereitstellen eines SSD Premium v2-Datenträgers finden Sie Informationen zu den Vorteilen und aktuellen Einschränkungen dieser Speicherlösung.

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.

In Azure kann die Bereitstellung von SAP-Workloads je nach Verfügbarkeits- und Resilienzanforderungen der SAP-Anwendungen entweder regions- oder zonenbasiert sein. 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 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 Bereitstellung von Oracle Data Guard finden Sie hier:

In dieser Architektur werden native Oracle-Tools ohne Clustereinrichtung und ohne Bedarf für einen Lastenausgleich auf Datenbankebene genutzt. 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 ist. 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). Von RedHat werden keine SBD-Implementierungen in Azure unterstützt. Daher ist diese Option nur für das SUSE SLES-Betriebssystem verfügbar.
  • 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 Cluster-Manager von Drittanbietern können auch verwendet werden, um die Hochverfügbarkeit der zentralen SAP-Dienste zu gewährleisten.

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.Von Azure bereitgestellte und verwaltete Skripts für Oracle Database-Instanzen, um Oracle-Aktionen vor und nach der Sicherung zu unterstützen.
  • „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 in diesen Artikeln: