SAP-Bereitstellung in Azure unter Verwendung einer Oracle-Datenbank

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

Anhand dieser Referenzarchitektur werden einige bewährte Methoden für die Ausführung von SAP NetWeaver mit Oracle Database in Azure mit Hochverfügbarkeit veranschaulicht. Die Architekturprinzipien sind zwar betriebssystemunabhängig, ohne anderslautende Angabe wird jedoch von Linux als Grundlage ausgegangen.

Das erste Diagramm zeigt eine Referenzarchitektur für SAP unter Oracle in Azure mit Verfügbarkeitsgruppen:

Diagramm: Architektur eines SAP-Produktionssystems unter Oracle in AzureAbbildung: Architektur eines SAP-Produktionssystems unter Oracle in Azure mit Verfügbarkeitsgruppen

Das zweite Diagramm zeigt eine Referenzarchitektur für SAP unter Oracle in Azure mit Verfügbarkeitszonen für eine höhere Resilienz:

Diagramm: Architektur eines SAP-Produktionssystems unter Oracle in AzureAbbildung: Architektur eines SAP-Produktionssystems unter Oracle in Azure mit Verfügbarkeitszonen

Laden Sie eine Visio-Datei dieser Architektur 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 Dienst Azure Virtual Network verbindet Azure-Ressourcen miteinander und bietet erweiterte 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 sind in einem eigenen virtuellen Spoke-Netzwerk enthalten. Die virtuellen Netzwerke werden für jede Ebenenanwendung (SAP NetWeaver) sowie für die Datenbank und gemeinsam genutzte Dienste (wie Jumpbox und DNS-Server) jeweils in getrennte Subnetze unterteilt.

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 mittels Peering verknüpft 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 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 expliziter IP-Adressen, um in Ihren NSGs differenzierte Netzwerksicherheitsrichtlinien basierend auf anwendungsorientierten Workloads zu definieren. Hiermit können Sie VMs nach Name gruppieren und Anwendungen schützen, indem Sie Datenverkehr aus vertrauenswürdigen Segmenten Ihres Netzwerks filtern.

Netzwerkschnittstellenkarten (Network Interface Cards, 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.)

Virtual Machines

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.

  • Virtuelle Computer mit eingeschränkter vCPU Erwägen Sie die Verwendung virtueller Computer 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 Azure-VM-Typen sowie die Durchsatzmetriken (SAPS) finden Sie im SAP-Hinweis 1928533. (Um auf SAP-Hinweise zugreifen zu können, benötigen Sie ein SAP Service Marketplace-Konto.)

Näherungsplatzierungsgruppen (Proximity Placement Groups, PPGs) Zur Optimierung der Netzwerklatenz können Näherungsplatzierungsgruppen verwendet werden, bei denen die Platzierung am gleichen Ort im Vordergrund steht. Das bedeutet, dass sich virtuelle Computer im gleichen Rechenzentrum befinden, um die Wartezeit von Anwendungen 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 zweiten Generation (Gen2). Azure bietet Ihnen beim Bereitstellen von VMs die Möglichkeit, zwischen VMs der ersten oder zweiten Generation zu wählen. 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 Beachten Sie ähnlich wie bei zertifizierten VM-Typen für die SAP-Nutzung die Details im SAP-Hinweis 2015553 und im SAP-Hinweis 2039619.
  • Speicherentwurf für SAP unter Oracle Den empfohlenen Speicherentwurf für SAP unter Oracle in Azure finden Sie in dieser Dokumentation – einschließlich spezifischen Informationen zum Dateisystemlayout, Empfehlungen zur Datenträgerdimensionierung und anderen Speicheroptionen.
  • Speichern von Oracle Database-Dateien Unter Linux muss für die Datenbank das ext4- oder das xfs-Dateisystem verwendet werden. Für Windows-Bereitstellungen muss NTFS verwendet werden. Oracle ASM wird auch für Oracle-Bereitstellungen für Oracle Database ab 12c Release 2 unterstützt.
  • Optionen für verwaltete DatenträgerAzure NetApp Files kann auch für Oracle Database verwendet werden. Ausführliche Informationen finden Sie im oben erwähnten 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.

Hochverfügbarkeit

Die obige Architektur stellt eine hochverfügbare Bereitstellung dar, bei sich die einzelnen Anwendungsschichten jeweils auf zwei oder mehr virtuellen Computern befinden. Folgende Komponenten werden verwendet:

LastenausgleichAzure Load Balancer wird verwendet, um Datenverkehr auf virtuelle Computer in den SAP-Subnetzen zu verteilen. Bei der Integration von Azure Load Balancer in eine zonale Bereitstellung von SAP muss der Lastenausgleich der Standard-SKU ausgewählt werden, da der Lastenausgleich der Basic-SKU nicht über Zonenredundanz verfügt. In einem Cluster

Verfügbarkeitsgruppen Durch Verfügbarkeitsgruppen werden Server über die physische Azure-Infrastruktur verteilt, um sie auf verschiedene Fehler- und Updatedomänen aufzuteilen und so die Dienstverfügbarkeit zu verbessern. Um Vereinbarungen zum Servicelevel (Service-Level-Agreements, SLAs) zu erfüllen, fassen Sie virtuelle Computer, die dieselbe Rolle ausführen, in einer Verfügbarkeitsgruppe zusammen. Auf diese Weise können Sie sich vor geplanten und ungeplanten Ausfallzeiten schützen, die durch die Wartung der Azure-Infrastruktur oder durch Hardwarefehler verursacht werden. Um eine höhere Vereinbarung zum Servicelevel zu erhalten, müssen Sie mindestens zwei virtuelle Computer pro Verfügbarkeitsgruppe verwenden.

Alle virtuellen Computer in einer Gruppe müssen dieselbe Rolle ausführen. Mischen Sie keine Server mit unterschiedlichen Rollen in derselben Verfügbarkeitsgruppe. Platzieren Sie also beispielsweise keinen ASCS-Knoten in der Verfügbarkeitsgruppe mit den Anwendungsservern oder Datenbanken.

Sie können Azure-Verfügbarkeitsgruppen in Azure-Verfügbarkeitszonen anordnen, wenn Sie eine Näherungsplatzierungsgruppe verwenden.

VerfügbarkeitszonenVerfügbarkeitszonen sind physisch getrennte Standorte innerhalb einer bestimmten Azure-Region. Sie dienen zur weiteren Verbesserung der Dienstverfügbarkeit. Aufgrund ihrer potenziellen geografischen und netzwerkbezogenen Platzierung benötigen Administratoren ein eindeutiges Netzwerklatenzprofil zwischen allen Zonen einer Zielregion, um die Ressourcenplatzierung mit möglichst geringer Wartezeit zwischen Zonen bestimmen zu können. Stellen Sie zur Erstellung dieses Profils in jeder Zone zu Testzwecken virtuelle Computer bereit. Empfohlene Tools für diese Tests sind beispielsweise PsPing und Iperf. Wenn die Tests abgeschlossen sind, entfernen Sie die virtuellen Computer, die Sie für die Tests verwendet haben. Alternativ steht auch ein Tool zur Überprüfung der Wartezeit zwischen Azure-Zonen zur Verfügung.

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 nicht zertifiziert und wird von Oracle in Azure 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 Für alle hochverfügbaren SAP-Bereitstellungen muss eine robuste NFS-Ebene verwendet werden, die NFS-Volumes für das SAP-Transportverzeichnis, ein 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 In dieser Referenzarchitektur wird Central Services auf diskreten virtuellen Computern ausgeführt. 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: Ohne zusätzliche virtuelle Computer wird die Azure-Verwaltungs-API für die regelmäßige Überprüfung der VM-Verfügbarkeit verwendet.

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 Zwei oder mehr Anwendungsserver, auf denen Hochverfügbarkeit durch den Lastenausgleich von Anforderungen per SAP-Nachrichtenserver oder 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 Lastenausgleich 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

Diagramm der Architektur eines SAP-Produktionssystems unter Oracle in Azure.Abbildung: Architektur eines SAP-Produktionssystems unter Oracle in Azure mit Verfügbarkeitszone und Notfallwiederherstellung

Laden Sie eine Visio-Datei dieser Architektur herunter.

Für jede Ebene des SAP-Anwendungsstapels wird eine andere Strategie für die Notfallwiederherstellung verwendet.

Zentrale Dienste und Anwendungsserverebene Zentrale SAP-Dienste und Anwendungsserver enthalten keine Geschäftsdaten. In Azure besteht eine einfache Strategie für die Notfallwiederherstellung darin, SAP-Anwendungsserver in der sekundären Region zu erstellen und die Server dann herunterzufahren. Bei Konfigurationsänderungen oder Kernel-Updates auf dem primären Anwendungsserver müssen Sie dieselben Änderungen auf die virtuellen Computer in der sekundären Region anwenden. Kopieren Sie z. B. die ausführbaren Dateien des SAP-Kernels auf die virtuellen Computer für die Notfallwiederherstellung.

Sollen Anwendungsserver automatisch in einer sekundären Region repliziert werden, empfehlen wir hierfür Azure Site Recovery. Sie können Azure Site Recovery auch verwenden, um die Notfallwiederherstellung für die Bereitstellung einer SAP NetWeaver-Anwendung mit mehreren Ebenen einzurichten. Beim Schutz einer Clusterumgebung mit Azure Site Recovery müssen vorab geskriptete Aktionen in benutzerdefinierten Skripts vorbereitet, getestet und so festgelegt werden, dass sie in Wiederherstellungsplänen von Azure Site Recovery ausgeführt werden, um Clusterdienste zu ändern oder zu deaktivieren.

NFS-Ebene Da sich die meisten unternehmenskritischen Daten innerhalb zentraler freigegebener SAP-NFS-Volumes wie dem Transportverzeichnis und sapmnt befinden, ist der Schutz für eine Unterbrechung, die ein Failover für die Notfallwiederherstellung erfordert, von entscheidender Bedeutung. Je nach NFS-Architektur sind verschiedene Lösungen möglich:

  • Dateibasierte Replikation Mit NFS-Ebenen, die in verschiedenen Regionen bereitgestellt werden, aber ohne direkte dienstgesteuerte Replikation, können VM-gebundene Tools wie rsync nach Zeitplan ausgeführt werden, um eine asynchrone Replikation von NFS-Volumes der Quellregion auf NFS-Volumes der Zielregion durchzuführen. Für Azure Files NFS kann ein virtueller Computer in der primären Region (z. B. eine (A)SCS-VM) über globales VNET-Peering auf ein NFS-Volume in einer anderen Region zugreifen. Während eines Failovers für die Notfallwiederherstellung muss ein DNS- und/oder Konfigurationswechsel erfolgen, damit die SAP-Systeme in der Notfallwiederherstellungsregion eine Verbindung mit den NFS-Volumes in der Notfallwiederherstellungsumgebung herstellen.
  • Azure NetApp Files-Volumes können mit automatisierter, asynchroner Speicherreplikation geschützt werden. Regionsübergreifende Replikation steht zwischen ausgewählten Regionspaaren zur Verfügung. Eine Alternative für Regionen, die nicht zu den ausgewählten Regionspaaren gehören, ist die Verwendung der zuvor erwähnten dateibasierten Replikation. Hierzu muss in der Zielregion ein betriebsbereiter virtueller Computer mit eingebundenem NetApp-NFS-Volume aus der gleichen Region vorhanden sein, da Azure NetApp Files für NFS-Volumes keinen regionsübergreifenden Zugriff zulässt. Bei der dateibasierten Replikation handelt es sich somit um eine VM-zu-VM-Replikation zwischen Regionen, wobei jeweils das NetApp-NFS-Volume der entsprechenden Region eingebunden wird.
  • Sicherungstools von Drittanbietern Tools von anderen Anbietern, die eine dateibasierte Replikation zwischen NFS-Volumes einer beliebigen Quelle und eines beliebigen Ziels bereitstellen.

Datenbankebene

Für die regionsübergreifende Replikation von Oracle Database wird Oracle Data Guard im asynchronen Modus empfohlen. Bei der asynchronen Replikation werden die Protokolländerungen in der primären Region committet, bevor sie in der Datenbank der sekundären Region eintreffen. Die Entfernung zwischen den Regionen ist somit kein Faktor mehr für die Gesamtleistung des SAP-Systems.

Die Zieldatenbank-VM in der Region für die Notfallwiederherstellung kann eine geringere Größe haben, da sie keine zusätzliche CPU-Leistung und keinen zusätzlichen Arbeitsspeicher benötigt, um eine schnelle SAP-Antwortzeit zu bieten, weil lediglich Änderungen aus der Datenbankreplikation angewendet werden müssen. In jedem Wiederherstellungsplan oder -prozess muss eine solche VM-Größenänderung eingeplant oder vollständig automatisiert werden.

Backup

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

  • Azure BackupVon 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 Azure Blob NFS, in Azure Blob oder in Azure Files-Speicherdiensten gespeichert und versioniert werden. Ausführliche Informationen zur Sicherung von Oracle-Daten und -Protokollen finden Sie in der Dokumentation.
  • Sicherungslösungen von Drittanbietern Sehen Sie sich die Architektur Ihres Sicherungsspeicheranbieters mit Unterstützung von Oracle in Azure an.

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: