SAP-Bereitstellung auf Azure mithilfe einer Oracle-Datenbank

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

Diese Referenzarchitektur beschreibt bewährte Methoden zum Ausführen von SAP NetWeaver mit Oracle Database auf Azure in einer Konfiguration mit hoher Verfügbarkeit (HA). Die allgemeinen Architekturprinzipien gelten für unterstützte Betriebssysteme. Sofern nicht anders angegeben, gehen Sie davon aus, dass diese Architektur Linux verwendet.

Note

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

Architektur

Das folgende Diagramm zeigt eine Referenzarchitektur für SAP auf Oracle in Azure. Empfohlen wird, dass Sie in zwei Verfügbarkeitszonen bereitstellen.

Diagramm der Architektur eines SAP-Produktionssystems auf Oracle in Azure.

Laden Sie eine Visio-Datei dieser Architektur und verwandter Architekturen herunter.

Workflow

Der folgende Workflow entspricht dem vorherigen Diagramm:

  1. Benutzer und Unternehmenssysteme verbinden sich von lokalen Umgebungen oder per Peering verbundenen Azure-Netzwerken durch das Hubnetzwerk mit dem virtuellen SAP-Spoke-Netzwerk.

  2. SAP Web Dispatcher und SAP-Anwendungsserver verarbeiten Anforderungen auf der Anwendungsebene und senden Datenbankaufrufe an den primären Oracle-Knoten.

  3. Oracle Data Guard unterhält eine synchronisierte Standby-Datenbank in einer anderen Verfügbarkeitszone, und Oracle Data Guard Observer-virtuelle Maschinen (VMs) überwachen die Replikation und die Failover-Bereitschaft.

  4. Wenn ein Ausfall eines Datenbankknotens oder einer Zone auftritt, stuft Oracle Data Guard Fast-Start Failover den Standby-Knoten zum primären Knoten hoch, und die SAP-Anwendungsserver verbinden sich erneut mit dem neuen primären Knoten.

  5. Freigegebene SAP-Dateisysteme, wie sapmnt- und transport-Volumes, bleiben über die ausgewählte ausfallsichere NFS-Ebene verfügbar. Sicherungsdienste schützen Datenbank- und Anwendungs-VMs.

Components

Diese Referenzarchitektur beschreibt ein typisches SAP-Produktionssystem, das in Oracle Database in Azure in einem hochverfühbaren Setup ausgeführt wird, um die Systemverfügbarkeit zu maximieren. Sie können die Architektur und die zugehörigen Komponenten basierend auf den Geschäftsanforderungen anpassen, z. B. Wiederherstellungszeitziel (RTO), Recovery Point Objective (RPO), Uptime-Erwartungen und Systemrolle. Für Nichtproduktionsumgebungen oder Workloads, die keinen HA erfordern, können Sie das System auf einer einzelnen VM bereitstellen. Das Netzwerklayout ist vereinfacht, um die wichtigsten Architekturprinzipien einer SAP-Umgebung darzustellen und stellt kein gesamtes Unternehmensnetzwerk dar.

Networking

  • Virtuelle Netzwerke:Azure Virtual Network verbindet Azure Ressourcen mit verbesserter Sicherheit miteinander. In dieser Architektur stellt das virtuelle Netzwerk über ein ExpressRoute-Gateway, das Sie im Hub einer Hub-Spoke-Topologie bereitstellen, eine Verbindung mit der lokalen Umgebung her. Diese Architektur enthält SAP-Anwendungen und Datenbanken in ihrem eigenen speichen virtuellen Netzwerk und unterteilt die virtuellen Netzwerke in separate Subnetze für jede Ebene: Anwendung (SAP NetWeaver), die Datenbank und gemeinsame Dienste wie Azure Bastion.

    In dieser Architektur wird der Adressraum des virtuellen Netzwerks in Subnetze unterteilt. Platzieren Sie Anwendungsserver und Datenbankserver in separaten Subnetzen. Mit diesem Ansatz können Sie Server einfacher sichern, indem Sie die Subnetzsicherheitsrichtlinien anstelle der einzelnen Server verwalten. Sie können auch Sicherheitsregeln für Datenbanken sauber von denen für Anwendungsserver trennen.

  • Peering virtueller Netzwerke: Diese Architektur verwendet eine Hub-and-Spoke-Netzwerktopologie mit mehreren virtuellen Netzwerken, die per Peering miteinander verbunden sind. Diese Topologie bietet Netzwerksegmentierung und Isolation für Dienste, die auf Azure bereitgestellt werden. Peering ermöglicht eine transparente Konnektivität zwischen den gepeerten virtuellen Netzwerken über das Microsoft-Backbone-Netzwerk.

  • Zonenredundantes Gateway: Ein Gateway verbindet unterschiedliche Netzwerke und erweitert Ihr lokales Netzwerk auf das Azure virtuelle Netzwerk. Es wird empfohlen, Azure ExpressRoute zu verwenden, um private Verbindungen zu erstellen, die nicht über das öffentliche Internet gehen, sie können aber auch eine Standort-zu-Standort-Verbindung verwenden. Verwenden Sie zonenredundante ExpressRoute- oder VPN-Gateways, um vor Zonenfehlern zu schützen. Weitere Informationen zu den Unterschieden zwischen einer Zonenbereitstellung und einer zonenredundanten Bereitstellung finden Sie unter Zuverlässigkeit in Azure virtuellen Netzwerkgateways. Gateways in einer Zonenbereitstellung erfordern standardmäßige SKU-IP-Adressen.

  • Netzwerksicherheitsgruppen (NSGs): Um eingehenden, ausgehenden und intrasubnetdatenverkehr im virtuellen Netzwerk einzuschränken, erstellen Sie NSGs , und weisen Sie sie bestimmten Subnetzen zu. Workloadspezifische NSGs sichern Datenbank- und Anwendungssubnetze.

  • Anwendungssicherheitsgruppen (APPLICATION Security Groups, ASGs): Verwenden Sie ASGs anstelle expliziter IP-Adressen, um präzise Netzwerksicherheitsrichtlinien innerhalb Ihrer NSGs zu definieren, die auf Anwendungsrollen basieren. Weisen Sie ASGs VM-Netzwerkschnittstellen zu, und verwenden Sie diese Gruppen als Quellen oder Ziele in NSG-Regeln.

  • Nics: Netzwerkschnittstellencontroller (Network Interface Controller, NICs) ermöglichen die gesamte Kommunikation zwischen virtuellen Computern in einem virtuellen Netzwerk. Herkömmliche lokale SAP-Bereitstellungen implementieren mehrere NICs pro Computer, um administrativen Datenverkehr vom Geschäftsdatenverkehr zu trennen.

    Bei Azure ist das virtuelle Netzwerk ein softwaredefiniertes Netzwerk (SDN), das den gesamten Datenverkehr über dasselbe Netzwerk fabric sendet. Es ist also nicht notwendig, aus Leistungsgründen mehrere NICs zu verwenden. Wenn Ihre Organisation jedoch Datenverkehr trennen muss, können Sie mehrere NICs pro VM bereitstellen und jede NIC mit einem anderen Subnetz verbinden. Anschließend können Sie NSGs verwenden, um unterschiedliche Zugriffssteuerungsrichtlinien für jedes Subnetz zu erzwingen.

    Azure NICs unterstützen mehrere IP-Adressen. Diese Unterstützung entspricht der von SAP empfohlenen Methode, virtuelle Hostnamen für Installationen zu verwenden. 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 Maschinen (VMs)

Diese Architektur verwendet VMs. Für die SAP-Anwendungsebene verwendet die Bereitstellung virtuelle Computer für alle Instanzrollen. Zu diesen Rollen gehören SAP Web Dispatcher und SAP-Anwendungsserver, die zentralen Dienstinstanzen SAP ASCS und Enqueue Replication Server (ERS) sowie die Anwendungsserver Primary Application Server (PAS) und Additional Application Server (AAS). Passen Sie die Anzahl der virtuellen Computer basierend auf Ihren Anforderungen an. Weitere Informationen zum Ausführen von SAP NetWeaver auf VMs finden Sie unter Plan und Implementieren einer SAP-Bereitstellung auf Azure.

Ebenso verwendet die Architektur VMs für alle Oracle-Komponenten, einschließlich der Oracle-Datenbank und der Oracle-Beobachter-VMs. Die Beobachter-VMs in dieser Architektur sind kleiner als die Datenbankserver.

  • Eingeschränkte virtuelle CPU-VMs (vCPU): Um möglicherweise Kosten für oracle-Lizenzierung zu sparen, sollten Sie vCPU-eingeschränkte VMs in Betracht ziehen.

  • Zertifizierte VM-Familien für SAP: Weitere Informationen zur SAP-Unterstützung für Azure VM-Typen und Durchsatzmetriken (SAPS) finden Sie im SAP-Hinweis 1928533.

  • Näherungsplatzierungsgruppen (PPGs): In den meisten Zonenbereitstellungen reicht die Latenz innerhalb der Zone für SAP-Anwendungen aus. Wenn sich die gemessene Latenz zwischen der Anwendung und den Datenbankebenen auf die Arbeitsauslastung auswirkt, verwenden Sie PPGs für sap ASCS/SCS und VMs auf Anwendungsebene. Halten Sie Datenbank-VMs aus der PPG heraus, um die Flexibilität bei Größenänderungen von Datenbank-VMs und SKU-Änderungen zu erhalten.

  • VMs der Generation 2 (Gen2): Wenn Sie VMs in Azure bereitstellen, können Sie entweder die Generation 1 (Gen1) oder Gen2 auswählen. Gen2-VMs unterstützen Features, die Gen1 nicht bereitstellt. Diese Features sind für große Oracle-Datenbanken wichtig, da einige VM-Familien wie Mv2 und Mdsv2 nur als Gen2-VMs ausgeführt werden. Für die SAP on Azure-Zertifizierung kann bei einigen neueren VMs möglicherweise ebenfalls Gen2 für die vollständige Unterstützung erforderlich sein, selbst wenn Azure auf diesen VMs beide Generationen unterstützt. Weitere Informationen finden Sie im SAP-Hinweis 1928533 – Unterstützte Produkte und Azure VM-Typen.

    Alle anderen VMs, die SAP unterstützen, unterstützen entweder nur Gen2 oder sowohl Gen1 als auch Gen2. Es wird empfohlen, alle SAP-VMs als Gen2 bereitzustellen, auch wenn die Speicheranforderungen niedrig sind. Sie können die kleinsten Gen2-VMs skalieren, die einmal als Gen2 bereitgestellt wurden, auf den größten verfügbaren virtuellen Computer mit einem einfachen Deallocate- und Größenänderungsvorgang. VMs der 1. Generation können nur auf VM-Familien skaliert werden, die von Azure für VMs der 1. Generation unterstützt werden.

Storage

Diese Architektur verwendet verwaltete Azure-Datenträger für VMs und Azure-Dateifreigaben oder Azure NetApp Files für alle Anforderungen an gemeinsamen NFS-Speicher, z. B. sapmnt- und SAP transport-NFS-Volumes. Weitere Informationen zur Speicherbereitstellung mit SAP auf Azure finden Sie im Handbuch zu Azure Storage Typen für SAP-Workload.

Hohe Verfügbarkeit

Die vorherige Architektur zeigt eine hoch verfügbare Bereitstellung, wobei jede Anwendungsschicht auf zwei oder mehr virtuellen Computern enthalten ist. Es verwendet die folgenden Komponenten.

Bei Azure kann die BEREITSTELLUNG von SAP-Workload entweder regional oder zonal sein, je nach Verfügbarkeits- und Ausfallsicherheitsanforderungen der SAP-Anwendungen und der ausgewählten Region. Azure bietet verschiedene Bereitstellungsoptionen, z. B. Azure Virtual Machine Scale Sets mit flexibler Orchestrierung (FD=1), Verfügbarkeitszonen und Verfügbarkeitsgruppen, um die Verfügbarkeit von Ressourcen zu erhöhen. Weitere Informationen zu den Bereitstellungsoptionen und deren Anwendbarkeit in verschiedenen Azure Regionen (einschließlich zonenübergreifend, innerhalb einer einzelnen Zone oder in einer Region ohne Zonen) finden Sie unter HA-Architektur und -Szenarien für SAP NetWeaver.

  • Load Balancer: Ein interner Azure Load Balancer verteilt den Datenverkehr auf VMs in den SAP-Subnetzen. Azure Load Balancer unterstützt die zonenredundante Verteilung für zonenbezogene Bereitstellungen von SAP.

    Berücksichtigen Sie die Entscheidungsfaktoren , wenn Sie virtuelle Computer zwischen Verfügbarkeitszonen für SAP bereitstellen. Erwägen Sie PPGs mit einer Bereitstellung in einer Verfügbarkeitszone und verwenden Sie sie nur für VMs der Anwendungsstufe.

    Note

    Verfügbarkeitszonen stellen intraregionsübergreifende HA bereit, aber Zonen-zu-Zone DR erfüllt möglicherweise keine Resilienzanforderungen für eine geografisch weit verbreitete Katastrophe. Wählen Sie eine DR-Region basierend auf den Anforderungen an geschäftliche und behördliche Entfernungen, dienstverfügbarkeit, Latenz und RPO/RTO-Zielen aus.

  • Oracle-spezifische Komponenten: In Zonenregionen stellen Sie Oracle Database-VMs in verschiedenen Verfügbarkeitszonen mit dem SAP-empfohlenen Virtual Machine Scale Sets Bereitstellungsmodell bereit, wobei die Fehlerdomänenanzahl auf 1 (FD=1) festgelegt ist. Verwenden Sie in Regionen ohne Verfügbarkeitszonen regionale HA-Bereitstellungsoptionen. Jeder virtuelle Computer enthält eine eigene Installation der Datenbanksoftware und des VM-lokalen Datenbankspeichers. Richten Sie die synchrone Datenbankreplikation über Oracle Data Guard zwischen den Datenbanken ein, um Konsistenz sicherzustellen und niedrige RTO- und RPO-Dienstzeiten im Falle einzelner Fehler zu ermöglichen. Zusätzlich zu den Datenbank-VMs erfordert eine Oracle Data Guard Fast-Start-Failover-Konfiguration zusätzliche VMs mit dem Oracle Data Guard Observer. Die Oracle-Beobachter-VMs überwachen den Datenbank- und Replikationsstatus und erleichtern das Datenbankfailover auf automatisierte Weise, ohne clustermanager. Sie können die Datenbankreplikationsverwaltung über oracle Data Guard Broker durchführen. Weitere Informationen finden Sie unter Architekturen für Oracle-Datenbank auf Azure Virtual Machines.

    Diese Architektur verwendet systemeigene Oracle-Tools ohne Clustersoftware oder die Notwendigkeit eines Lastenausgleichs in der Datenbankebene. Mit Oracle Data Guard Fast-Start Failover und der SAP-Konfiguration wird der Failover-Prozess automatisiert, und SAP-Anwendungen verbinden sich wieder mit der neuen primären Datenbank, wenn ein Failover auftritt.

    Es gibt verschiedene Clusterlösungen anderer Anbieter als Microsoft als Alternativen, z. B. SIOS Protection Suite oder Veritas InfoScale, und Details zur Bereitstellung finden Sie in der Dokumentation der einzelnen Anbieter.

  • Oracle RAC: Oracle Real Application Clusters (RAC) wird auf Azure VMs nicht unterstützt. Oracle AI Database@Azure unterstützt RAC-Bereitstellungen auf Exadata, aber dieser Dienst ist nicht Teil dieser Architektur. Für dieses VM-basierte Design kann Oracle Data Guard HA und Schutz vor Rack-, Rechenzentrums- oder regionalen Dienstunterbrechungen bereitstellen.

  • NFS-Ebene: Für hoch verfügbare linuxbasierte SAP-Bereitstellungen müssen Sie eine robuste NFS-Ebene verwenden, die NFS-Volumes für das SAP-Transportverzeichnis, das sapmnt Volume für SAP-Binärdateien und zusätzliche Volumes für die (A)SCS- und ERS-Instanzen bereitstellt.

    Zu den Optionen für die Bereitstellung einer NFS-Ebene gehören:

  • SAP Central Services Cluster: Diese Referenzarchitektur führt zentrale Dienste auf diskreten VMs aus. Zentrale Dienste werden zu einem potenziellen einzelnen Fehlerpunkt (Single Point of Failure, SPoF), wenn Sie ihn auf einer einzelnen VM bereitstellen. Um eine hoch verfügbare Lösung zu implementieren, benötigen Sie Clusterverwaltungssoftware, die das Failover der (A)SCS- und ERS-Instanzen auf die jeweilige VM automatisiert. Diese Einrichtung hängt von der ausgewählten NFS-Lösung ab, sodass die Konfiguration den Anforderungen dieser Lösung folgt.

    Ihre Clusterlösung muss bestimmen, welcher virtuelle Computer jedem Dienst dient, wenn Software oder Infrastruktur nicht verfügbar ist. SAP on Azure bietet zwei Optionen für Linux-basierte STONITH-Implementierungen zur Behandlung nicht reagierender VMs oder Anwendungen:

    • STONITH-Blockgerät (SBD): SBD unterstützt zwei Formulare. In der iSCSI-Variante stellen Sie eine oder drei zusätzliche VMs bereit, die als iSCSI-Ziele für ein kleines gemeinsam genutztes Blockspeichergerät dienen. Die VMs des Clustermitglieds (die beiden (A)SCS/ERS-VMs in diesem Clusterpool) greifen regelmäßig auf dieses Gerät zu und verwenden die SBD-Bereitstellungen, um Stimmen abzugeben und das Quorum für Clusterentscheidungen zu erreichen. Diese Architektur enthält nicht die zusätzlichen SBD-VMs. Im Formular für gemeinsam genutzte Azure-Datenträger ersetzt ein gemeinsam genutzter Azure-Datenträger die iSCSI-Ziel-VMs, sodass keine zusätzlichen VMs erforderlich sind. Verwenden Sie für zonalbereitstellungen einen gemeinsam genutzten ZRS-Datenträger, um die Datenträgerverfügbarkeit über Zonen hinweg aufrechtzuerhalten.

    • Azure Zaun-Agent: Diese Option verwendet die Azure-Verwaltungs-API, um fehlgeschlagene Knoten zu zaunieren, indem sie beendet und neu über die Azure Compute-API gestartet werden. Sie erfordert keine zusätzlichen virtuellen Computer.

    Informationen zu Konfigurationsschritten und Designdetails finden Sie in den Anleitungen, auf die im Abschnitt zur NFS-Ebene verwiesen wird. Nicht Microsoft Azure zertifizierte Clustermanager können HA für SAP Central Services bereitstellen.

  • SAP-Anwendungsserverpool: Stellen Sie zwei oder mehr Anwendungsserver bereit. Der SAP-Nachrichtenserver oder die Web-Dispatcher übernehmen den Lastenausgleich für Anfragen, um Hochverfügbarkeit zu erreichen. Jeder Anwendungsserver funktioniert unabhängig, und dieser Pool von virtuellen Computern erfordert keinen Netzwerklastenausgleich.

  • SAP Web Dispatcher-Pool: Die Web Dispatcher-Komponente gleicht DEN SAP-Datenverkehr zwischen den SAP-Anwendungsservern ab. Um HA des SAP Web Dispatcher zu erreichen, verwenden Sie entweder einen Failovercluster oder ein paralleles Web Dispatcher-Setup, und platzieren Sie die Dispatcherinstanzen hinter Load Balancer.

    Embedded Web Dispatcher in (A)SCS ist eine besondere Option. Berücksichtigen Sie die korrekte Dimensionierung aufgrund der zusätzlichen Last für (A)SCS.

    Für kommunikation mit dem Internet empfehlen wir eine eigenständige Lösung im Umkreisnetzwerk (auch als DMZ bezeichnet), um Sicherheitsbedenken zu beheben.

  • Windows Bereitstellungen: Dieser Artikel konzentriert sich hauptsächlich auf Linux-basierte Bereitstellungen. Die gleichen Architekturprinzipien gelten für Windows. Oracle-Architektur unterscheidet sich nicht zwischen Linux und Windows.

    Details zur SAP-Anwendung finden Sie unter Run SAP NetWeaver in Windows on Azure.

Considerations

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Notfallwiederherstellung

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

Diagramm, das eine Architektur eines SAP-Produktionssystems auf Oracle in Azure zeigt.

Laden Sie eine Visio-Datei dieser Architektur und verwandter Architekturen herunter.

Jede Architekturebene im SAP-Anwendungsstapel verwendet einen anderen Ansatz, um für DR-Schutz zu sorgen. Ausführliche Informationen zu DR-Strategien und Implementierungsdetails finden Sie in der DR-Übersicht und in den Infrastrukturrichtlinien für SAP-Workload und DR-Richtlinien für DIE SAP-Anwendung.

Backup

Backup für Oracle in Azure hat mehrere Optionen:

Für VMs, die keine Datenbank sind, empfehlen wir, Azure Backup für VMs zum Schutz von SAP-Anwendungs-VMs und zur Unterstützenden Infrastruktur wie SAP Web Dispatcher zu verwenden.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Design Review-Checkliste für die Kostenoptimierung.

Die wichtigsten Kostentreiber in dieser Architektur sind:

  • Oracle- und SAP-zertifizierte VM-SKUs und die Anzahl der virtuellen Computer über die Anwendungsebene, die Datenbankebene und die Beobachterknoten hinweg.

  • Oracle-Lizenzierungsmodellentscheidungen für Betriebssystem- und Datenbanksoftware. Erwägen Sie die Verwendung von vCPU-eingeschränkten VM-SKUs, um lizenzierbare Kerne ggf. zu reduzieren.

  • Speicherleistungsstufen und bereitgestellte Kapazität für Oracle-Daten, -Protokolle, -Sicherung und freigegebene NFS-Volumes.

  • Netzwerk- und HA-Dienste, insbesondere ExpressRoute- oder VPN-Gateways, Lastenausgleichsgeräte und zonenübergreifender oder regionsübergreifender Replikationsverkehr.

Sehen Sie sich die vorkonfigurierte Schätzung im Azure Preisrechner für eine mittelgroße Oracle hoch verfügbare Architektur an, um die Kosten für Ihre ausgewählte Topologie und SKUs zu schätzen. So kontrollieren Sie die Ausgaben:

  • Dimensionieren Sie VM-Arbeitsspeicher und CPU bedarfsgerecht entsprechend den gemessenen SAPS- und Oracle-Durchsatzanforderungen.

  • Verwenden Sie Speicherebenen mit höheren Kosten nur, wenn Latenz- und Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) sie erfordern.

  • Bewerten Sie Reservierungen oder Sparpläne für die Berechnung des stabilen Zustands nach der Überprüfung der Betriebs- und Lizenzierungsflexibilität.

Contributors

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächste Schritte

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