Business Continuity & Disaster Recovery für eine SAP-Migration

Dieser Artikel baut auf Überlegungen und Empfehlungen auf, die Sie im Entwurfsbereich für Azure-Zielzonen für BCDR finden. In diesem Artikel werden eindeutige Einschränkungen für Zielzonen beschrieben, die eine SAP-Plattform unterstützen. SAP ist eine unternehmenskritische Plattform, daher sollten Sie auch andere unternehmenskritische Anleitungen in Ihren Entwurf integrieren.

Szenario und Umfang

Integrieren Sie Prinzipien in Ihre Architektur, die lokale BCDR-Szenarien (Business Continuity and Disaster Recovery) berücksichtigen. Diese Prinzipien gelten auch in Azure. Azure verfügt jedoch möglicherweise über mehr Hardwarekapazität als Ihre lokale Umgebung, um einen Hostausfall auszugleichen. Um selbst die größten virtuellen Azure-Computer (VMs) automatisch wiederherzustellen, können Sie sie so konfigurieren, dass sie auf einem anderen Server neu gestartet werden. Richten Sie für Ihre Azure-Bereitstellungen die gleichen Bedingungen ein wie für Ihre lokalen Bereitstellungen. Wenn Sie automatische Failoverclusterkonfigurationen zum Bereitstellen lokaler Systeme oder Bare-Metal-Hardware verwenden, stellen Sie diese auf die gleiche Weise in Azure bereit. SAP-Anwendungen, die die wichtigsten Geschäftsprozesse Ihres Unternehmens ausführen, erfordern:

• Verfügbarkeit von Diensten und Geschäftsprozessen.

• Recovery Time Objectives (RTOs) für Ausfall- oder Katastrophenszenarien.

• Recovery Point Objectives (RPOs) für Fehlerszenarien

• Für Aufgaben in Bezug auf den Betrieb und die Lebenszyklusverwaltung und die Technologie, die bei Ausfallszenarien ausgeführt wird. Beispiele für diese Verwaltungsaufgaben sind das Patchen von Gastbetriebssystemen und Datenbankverwaltungssystemen, das Durchführen von Klonvorgängen und das Aktualisieren von SAP-Systemen.

Tipp

Bestimmen Sie frühzeitig eine HADR-Lösung (High Availability and Disaster Recovery) für jeden der Archetypen in Ihrer SAP-Landschaft. Stellen Sie sicher, dass die Lösung alle SAP-Komponenten abdeckt.

Konfigurieren Sie frühzeitig eine HADR-Lösung in Azure in mindestens einer Umgebung und halten Sie sie aktiv. Dann können Ihre Teams Erfahrungen mit den Technologien der Lösung sammeln, die sich möglicherweise von den vorhandenen Technologien unterscheiden. Konfigurieren Sie HADR frühzeitig, um Ihre Standardarbeitsanweisungen (SOPs) zu entwickeln und weiterzuentwickeln.

Planen Sie einen vollständigen Hochverfügbarkeits-, Notfallwiederherstellungs- und Sicherungsschutz für Produktionsworkloads, sobald das System live ist.

In diesem Artikel werden die folgenden Aspekte von BCDR für ein SAP-Szenario auf Unternehmensebene beschrieben:

• Hochverfügbarkeit innerhalb einer Azure-Region

• Überlegungen zu Sicherung und Wiederherstellung

• Kriterien für die Entscheidung zwischen überregionaler und regionaler Notfallwiederherstellung

Hochverfügbarkeit innerhalb einer Azure-Region

In den folgenden Abschnitten finden Sie Überlegungen und Empfehlungen zum Entwurf für Hochverfügbarkeit innerhalb einer Azure-Region für ein SAP-Unternehmensszenario.

Überlegungen zum Entwurf für Hochverfügbarkeit

Bei der Implementierung von Hochverfügbarkeit besteht das Ziel darin, die Verfügbarkeit für den Single Point of Failure der SAP-Software zu gewährleisten. Beispiel:

• Datenbank-Managementsysteme.

• Einzelne Fehlerpunkte in einer Anwendung, z. B. SAP Advanced Business Application Programming (ABAP), ABAP SAP Central Services (ASCS) und SAP Central Services (SCS). Beispiele für die Hochverfügbarkeit sind SAP NetWeaver und die SAP S/4HANA-Architektur.

• Andere Tools, z. B. SAP Web Dispatcher.

Beschränken Sie die Verfügbarkeit in anderen Szenarien nicht auf Infrastruktur- oder Softwarefehler. Wenden Sie die Verfügbarkeit auf alle erforderlichen Lebenszyklusverwaltungsaufgaben an. Beispielsweise können Sie das Betriebssystem in den virtuellen Computern, dem Datenbankverwaltungssystem (DBMS) und der SAP-Software patchen. Verwenden Sie gängige Tools, die Ihre Systeme vor ungeplanten Dienstunterbrechungen schützen, um Ausfälle zu minimieren, die durch geplante Downtimes und Vorgänge im Rahmen der Lebenszyklusverwaltung entstehen können.

Für SAP und SAP-Datenbanken werden Cluster mit automatischem Failover unterstützt. Unter Windows werden Failover vom Feature Windows Server-Failoverclustering unterstützt. Unter Linux unterstützen Linux Pacemaker oder Partnertools wie SIOS Protection Suite und Veritas InfoScale die Ausfallsicherung. In Azure können Sie nur einen Teil der Hochverfügbarkeitskonfiguration Ihres eigenen Rechenzentrums bereitstellen.

Weitere Informationen finden Sie unter Unterstützte Szenarien für SAP-Workloads auf Azure-VMs und Unterstützte Szenarien für SAP HANA (große Instanzen).

Für die DBMS-Ebene besteht das gängige Architekturmuster darin, Datenbanken gleichzeitig und mit anderen als den von den primären und sekundären VMs verwendeten Speicherstapeln zu replizieren. Azure unterstützt keine Architekturen, in denen die primäre und sekundäre VMs den Speicher für DBMS-Daten gemeinsam nutzen. Azure unterstützt auch keine Transaktionsprotokolle oder Wiederholungsprotokolle. Das Grundprinzip besteht darin, auch dann zwei unabhängige Speicherstapel zu verwenden, wenn diese auf NFS-Freigaben (Network File System) basieren. Diese Einschränkungen gelten ausschließlich für Azure-Lösungen und nicht für lokale Lösungen.

Azure bietet weitere Optionen, da es die Freigabe von NFS und Server Message Block unterstützt. Sie können freigegebene Azure-Datenträger in Windows für ASCS- und SCS-Komponenten und bestimmte Hochverfügbarkeitsszenarien verwenden. Richten Sie Ihre Failovercluster separat für Komponenten der SAP-Anwendungsebene und die DBMS-Ebene ein. Azure unterstützt keine Hochverfügbarkeitsarchitekturen, bei denen Komponenten der SAP-Anwendungsebene und die DBMS-Ebene in einem Failovercluster kombiniert sind.

Für die meisten Failovercluster für Komponenten der SAP-Anwendungsebene und die DBMS-Ebene ist eine spezielle virtuelle IP-Adresse erforderlich. Eine bekannte Ausnahme ist die Verwendung von Oracle Data Guard, da für die Funktionalität hier keine virtuelle IP-Adresse benötigt wird. In allen anderen Fällen sollte die virtuelle IP-Adresse von Azure Load Balancer verarbeitet werden. Sie können für jede Clusterkonfiguration einen Lastenausgleich verwenden. Hierfür wird die Verwendung der Standardversion des Load Balancers empfohlen. Weitere Informationen finden Sie im Artikel Konnektivität öffentlicher Endpunkte für VMs, die Azure Load Balancer Standard in SAP-Hochverfügbarkeitsszenarios verwenden.

Weitere Informationen finden Sie unter Architektur und Szenarien für die Hochverfügbarkeit von SAP NetWeaver

Die folgende Tabelle zeigt die plattformbasierten Service-Level-Agreements (SLAs) für verschiedene Hochverfügbarkeits-Bereitstellungsoptionen. Die Partner, die die verwalteten Dienste bereitstellen, stellen auch die SLA auf Anwendungsebene bereit.

Tarif	Hochverfügbarkeitsszenario	Plattform-SLA
1	Verfügbarkeitszone	99,99 %
2	Verfügbarkeitsgruppe	99,95 %
3	Einzelner virtueller Computer (Selbstreparatur)	99,90 %

Vergleich: Azure-Verfügbarkeitsgruppen und Verfügbarkeitszonen

Entscheiden Sie vor der Bereitstellung Ihrer Infrastruktur für Hochverfügbarkeit, ob Sie eine Azure-Verfügbarkeitsgruppe oder eine Verfügbarkeitszone für die Bereitstellung verwenden möchten, je nach gewählter Region. Die Hauptunterschiede für VMs, die über eine Verfügbarkeitsgruppe bereitgestellt werden, sind:

• Die VMs sind nicht auf unterschiedliche Verfügbarkeitszonen verteilt.

• Der Typ von VMs, der über eine einzelne Verfügbarkeitsgruppe bereitgestellt werden kann, ist begrenzt, da der Host basierend auf der ersten VM definiert wird, die in der Gruppe bereitgestellt wird. Sie können beispielsweise keine VMs der M-Serie und VMs der E-Serie in einer Verfügbarkeitsgruppe kombinieren.

Wenn Sie Ihre Hochverfügbarkeitsarchitektur über verschiedene Verfügbarkeitszonen hinweg einsetzen, können Sie eine höhere SLA für die VMs festlegen. Weitere Informationen finden Sie unter Azure-VM-SLAs. Je nach Azure-Region stellen Sie ggf. fest, dass für den Netzwerkdatenverkehr zwischen VMs ggf. unterschiedliche Bedingungen in Bezug auf die Netzwerklatenz gelten. Weitere Informationen finden Sie unter SAP-Workloadkonfigurationen mit Azure-Verfügbarkeitszonen.

Wenn Sie sich für einen zonenbasierten Bereitstellungsansatz entscheiden, sollten Sie berücksichtigen, wie sich die zonenübergreifende Latenz für die gewählte Azure-Region auf die Leistung und die Architektur auswirken könnte. Berücksichtigen Sie die Latenz zwischen dem Anwendungsserver und der Datenbank sowie die Latenz zwischen den beiden Datenbankknoten.

Wenn Sie eine aktive/passive zonenbasierte Implementierung auf Anwendungsserverebene verwenden, bei der sich die Anwendungsserver mit der Datenbank in derselben Verfügbarkeitszone verbinden müssen, konfigurieren Sie die Automatisierung und erstellen Sie eine SOP, um eine schnelle und automatisierte Wiederherstellung zu ermöglichen, wenn ein Datenbankausfall eintritt.

Legen Sie bei Verwendung von Verfügbarkeitszonen in Ihrer SAP-Lösung alle anderen Azure-Dienste und Infrastrukturkomponenten in Ihrer SAP-Landschaft ebenfalls für Zonenredundanz aus, damit Sie eine echte Zonenredundanz erreichen können. Zu den zu berücksichtigenden Diensten und Komponenten gehören beispielsweise Azure ExpressRoute-Gateways, Load Balancer, Azure Files, Azure NetApp Files, Reverse Proxys, Firewalls, Antivirus-Dienste und Sicherungsinfrastruktur.

Entwurfsempfehlungen für die Hochverfügbarkeit

• Azure bietet mehrere Optionen, mit denen Sie die Infrastruktur-SLAs Ihrer Anwendungen erfüllen können. Sie sollten für alle drei SAP-Komponenten (zentrale Dienste, Anwendungsserver und Datenbank) jeweils die gleiche Option wählen. Weitere Informationen zu SLAs für VMs, Verfügbarkeitsgruppen und Verfügbarkeitszonen finden Sie unter SLAs für Onlinedienste.

• Wenn Sie VMs in einer Verfügbarkeitsgruppe bereitstellen, verhindert ein Abgleich mit Fehler- und Updatedomänen, dass sich die VMs auf derselben Hosthardware befinden, was Schutz vor Hardwareausfällen bietet. Wenn Sie VMs über Verfügbarkeitszonen bereitstellen und verschiedene Zonen verwenden, erstellen Sie die VMs an verschiedenen physischen Standorten. Diese Konfiguration bietet zusätzlichen Schutz vor Strom-, Kühlungs- oder Netzwerkproblemen, die sich auf die Rechenzentren der Zone als Ganzes auswirken. Sie können Azure-Verfügbarkeitsgruppen jedoch nicht in einer Azure-Verfügbarkeitszone bereitstellen, solange Sie keine Azure-Näherungsplatzierungsgruppe verwenden.

  Wenn Sie sich für eine Bereitstellung mit Zonen entscheiden, werden DBMS, zentrale Dienste und Anwendungsebenen für SAP in verschiedenen Verfügbarkeitszonen ausgeführt. Jede Verfügbarkeitszone verfügt jedoch höchstwahrscheinlich über mehrere Anwendungsserver. In diesem Szenario profitieren die Anwendungsserver in den einzelnen Zonen nicht automatisch von Fehler- und Updatedomänen. Sie können Verfügbarkeitsgruppen verwenden, um diese Vorteile zu erzielen. Weitere Informationen finden Sie unter Azure-Näherungsplatzierungsgruppen für optimale Netzwerklatenz bei SAP.

• Verwenden Sie beim Erstellen von Verfügbarkeitsgruppen die maximale Anzahl verfügbarer Fehler- und Updatedomänen. Wenn Sie beispielsweise mehr als zwei VMs in einer Verfügbarkeitsgruppe bereitstellen, verwenden Sie die maximale Anzahl von Fehlerdomänen (drei). Und verwenden Sie genügend Updatedomänen, um die Auswirkungen potenzieller physischer Hardwarefehler, Netzwerkausfälle oder Stromunterbrechungen zusätzlich zu den geplanten Wartungsarbeiten in Azure zu begrenzen. Die Standardanzahl von Fehlerdomänen ist zwei. Sie kann später nicht mehr online geändert werden.

• Bei einer Bereitstellung mit Verfügbarkeitsgruppen muss sich jede Komponente eines SAP-Systems in einer eigenen Verfügbarkeitsgruppe befinden. SAP-VMs für zentrale Dienste, Datenbanken und Anwendungen sollten sich jeweils in eigenen Verfügbarkeitsgruppen befinden.

• Bei Verwendung von Azure-Näherungsplatzierungsgruppen in der Bereitstellung einer Verfügbarkeitsgruppe sollten alle drei SAP-Komponenten (zentrale Dienste, Anwendungsserver und Datenbank) in derselben Näherungsplatzierungsgruppe enthalten sein.

• Bei der Verwendung von Näherungsplatzierungsgruppen verwenden Sie jeweils eine für jede SAP System Identification (SID). Gruppen reichen nicht über Verfügbarkeitszonen oder Azure-Regionen hinweg.

• Bei Verwendung von Azure-Näherungsplatzierungsgruppen in der Bereitstellung einer Verfügbarkeitszone sollten alle beiden SAP-Komponenten (zentrale Dienste und Anwendungsserver) in derselben Näherungsplatzierungsgruppe enthalten sein. Die Datenbank-VMs in den beiden Zonen sind nicht mehr Teil der Näherungsplatzierungsgruppen. Die Näherungsplatzierungsgruppen für jede Zone sind jetzt auf die Bereitstellung der VM, auf der die SAP-ASCS- und SCS-Instanzen ausgeführt werden, zugewiesen. Der Vorteil dieser Konfiguration besteht darin, dass Sie mehr Flexibilität bei der Größenänderung von VMs haben. Sie können auch problemlos zu den neuen VM-Typen in der DBMS-Schicht oder der Anwendungsschicht des SAP-Systems wechseln.

• Azure unterstützt nicht die Kombination von ASCS und Datenbankhochverfügbarkeit in einem einzelnen Linux-Pacemaker-Cluster. Sie müssen in einzelne Cluster getrennt werden. Sie können bis zu fünf Cluster mit mehreren zentralen Diensten in einem VM-Paar kombinieren.

• Verwenden Sie vor ASCS- und Datenbank-Clustern einen Standard Load Balancer.

• Führen Sie alle Produktionssysteme auf Azure Premium-SSDs, und verwenden Sie Azure NetApp Files oder Azure Disk Storage Ultra. Stellen Sie mindestens sicher, dass sich der Betriebssystemdatenträger auf der Premium-Stufe befindet, damit Sie die Leistung verbessern und die beste SLA erzielen können.

• Stellen Sie beide virtuellen Computer im Hochverfügbarkeitspaar in einer Verfügbarkeitsgruppe oder in Verfügbarkeitszonen bereit. Stellen Sie sicher, dass diese VMs die gleiche Größe und die gleiche Speicherkonfiguration haben.

• Verwenden Sie die native Datenbankreplikationstechnologie, um die Datenbank in einem Hochverfügbarkeitspaar zu synchronisieren.

• Verwenden Sie je nach Betriebssystem einen der folgenden Dienste, um SAP-Cluster für zentrale Dienste auszuführen:

  • Ein SUSE Linux Enterprise Server Pacemaker-Cluster unterstützt einen Azure-Zaun-Agent und bis zu drei Knotenisolationsgeräte.

  • Ein Red Hat Enterprise Linux Pacemaker-Cluster unterstützt einen Azure-Zaun-Agent, aber keine keine Knotenisolationsgeräte.

  • Ein Windows-Cluster.

  • SAP-zertifizierte, nicht von Microsoft stammende Clustersoftware.

• Richten Sie die in der Dokumentation empfohlenen Clustertimeoutparameter für Cluster mit zentralen Diensten und Datenbanken einrichten.

Speicher für SAP-Workloads

• Wählen Sie die richtigen Speicheroptionen aus, wenn Sie die Resilienz in Ihrer SAP-Workload entwerfen. Ein geeigneter Azure-Speicherentwurf für SAP-Workloads kann die Latenz minimieren und den Durchsatz maximieren. Berücksichtigen Sie die jeweilige Implementierung und wie die nachstehenden Anleitungen architektonische Entscheidungen für Ihre SAP-Implementierung in Azure unterstützen können. Weitere Informationen finden Sie unter Azure-Speichertypen für SAP-Workloads.

• Sie sollten SAP HANA in Azure nur für SAP-zertifizierte Speichertypen ausführen. Sie müssen bestimmte Volumes auf bestimmten Datenträgerkonfigurationen ausführen. Beispielsweise können Konfigurationen Write Accelerator aktivieren oder Premium-SSD-Speicher verwenden. Außerdem müssen Sie sicherstellen, dass das ausgeführte Dateisystem im Speicher mit dem DBMS kompatibel ist, das auf dem Computer ausgeführt wird. Weitere Informationen finden Sie unter Speicherkonfigurationen für SAP HANA.

• Zusätzlich zu den verwalteten Azure-Datenträgern, die an VMs angefügt sind, führen verschiedene Azure-native freigegebene Speicherlösungen SAP-Anwendungen in Azure aus. Ihre Hochverfügbarkeitskonfiguration kann sich unterscheiden, da Azure Site Recovery einige Speicherdienste, die in Azure verfügbar sind, nicht unterstützt. Verwenden Sie die folgenden Speichertypen für SAP-Workloads.

  Speichertyp	Unterstützung der Hochverfügbarkeitskonfiguration
  Freigegebene Azure-Datenträger (lokal redundanter Speicher (LRS) oder zonenredundanter Speicher (ZRS))	Windows Server 2022-Failovercluster. Weitere Informationen zur Konfiguration finden Sie unter Entwerfen der SAP-Hochverfügbarkeit mit Windows Server 2022-Failoverclustering.
  NFS in Azure Files (LRS oder ZRS)	Pacemaker-basierte Cluster in Linux-Umgebungen. Überprüfen Sie unbedingt die Verfügbarkeit von NFS in verschiedenen Regionen.
  NFS für Azure NetApp Files	Pacemaker-basierte Cluster in Linux-Umgebungen. Weitere Informationen finden Sie unter Azure NetApp Files für SAP-VMs.
  SMB in Azure Files (LRS oder ZRS)	Windows Server 2022-Failovercluster. Konfigurationsdetails finden Sie unter Installieren der Hochverfügbarkeit für SAP NetWeaver mit Azure Files SMB.
  SMB für Azure NetApp Files	Windows Server 2022-Failovercluster. Weitere Informationen zur Konfiguration finden Sie unter Hochverfügbarkeit für SAP NetWeaver mit Azure NetApp Files (SMB) für SAP-Anwendungen.

• Anstelle von Azure-nativen freigegebenen Speicherdiensten können Sie herkömmliche NFS-Cluster (basierend auf der Replikation von verteilten replizierten Blockgeräten), GlusterFS oder ein freigegebenes Clustervolume mit Storage Spaces Direct als alternative freigegebene Speicherlösung zum Ausführen von SAP-Workloads in Azure verwenden. Diese Optionen sind besonders nützlich, wenn native freigegebene Azure-Speicherdienste in der Azure-Zielregion nicht verfügbar sind oder die Zielarchitektur nicht unterstützen. Weitere Informationen zur Verfügbarkeit von Speicherdiensten finden Sie unter Azure-Produkte nach Region.

• Informationen zu Speicheroptionen, die für SAP-Workloads in Azure verfügbar sind, finden Sie unter Speicherempfehlungen und -richtlinien zum Einrichten der Notfallwiederherstellung.

Sichern und Wiederherstellen

In den folgenden Abschnitten finden Sie Überlegungen und Empfehlungen zum Entwurf von Sicherung und Wiederherstellung in einem SAP-Szenario.

Obwohl Sicherung und Wiederherstellung in der Regel nicht als geeignete Hochverfügbarkeitslösung für eine SAP-Produktionsworkload betrachtet werden, bietet die Technologie andere Vorteile. Die meisten Unternehmen, die SAP-Anwendungen verwenden, müssen Compliance-Vorschriften befolgen, die eine langfristige Speicherung von Sicherungskopien vorschreiben. In anderen Szenarien müssen Sie auch über Sicherungen verfügen, die Sie wiederherstellen können. In diesem Leitfaden wird davon ausgegangen, dass Sie die Sicherung und Wiederherstellung bereits eingerichtet und die bewährten Methoden für SAP-Anwendungen befolgt haben, sodass Sie Folgendes tun können:

• Durchführen einer Zeitpunktwiederherstellung für Ihre Produktionsdatenbanken zu beliebigen Zeitpunkten und in einem Zeitrahmen, der Ihrem RTO-Ziel entspricht. Die Zeitpunktwiederherstellung schützt in der Regel vor Bedienerfehlern, z. B. das versehentliche Löschen von Daten auf der DBMS-Ebene oder über SAP.

• Aufbewahren langfristiger Sicherungen in einem geeigneten Speicher, um die Konformitätsbestimmungen einzuhalten.

• Verwenden Sie Datenbanksicherungen, um ein SAP-System zu klonen und diese Sicherungen für einen anderen Server bzw. eine andere VM wiederherzustellen.

• Nutzen Sie die Daten der Produktionsdatenbank aus Datenbanksicherungen, um nicht für die Produktion bestimmte Systeme zu aktualisieren.

• Erstellen Sie Sicherungen von SAP-Anwendungsservern und -VMs, Datenträgern oder VM-Momentaufnahmen.

• Sichern eines SAP HANA-Systems mit aktivierter Replikation

• Sichern von SAP HANA-Datenbankinstanz-Momentaufnahmen

Wenn Sie lokal sichern und wiederherstellen, müssen Sie diese Funktionen in SAP-Systeme unter Azure einbinden. Wenn Sie mit Ihrer derzeitigen Lösung zufrieden sind, sollten Sie überprüfen, ob Ihr Sicherungsanbieter Azure-Bereitstellungen unterstützt oder ob er eine SaaS-Lösung (Software-as-a-Service) für Azure hat.

Azure bietet den SaaS-Sicherungsdienst namens Azure Backup an, bei dem VM-Momentaufnahmen erstellt werden und das Streamen von SQL Server- und SAP HANA-Sicherungen verwaltet wird. Wenn Sie Azure NetApp Files zum Speichern Ihrer SAP HANA-Datenbanken verwenden, können Sie Sicherungsvorgänge basierend auf HANA-konsistenten Speichermomentaufnahmen ausführen.

Sie können Azure Backup auch verwenden, um Datenbanken zu sichern, die die SAP HANA-Systemreplikation (HSR) aktiviert haben. Azure Backup verwaltet automatisch Sicherungen, wenn ein Failover auftritt, und beseitigt die Notwendigkeit eines manuellen Eingriffs. Backup bietet außerdem Folgendes:

• Sofortiger Schutz ohne erneute vollständige Sicherungen, wodurch Sie die HANA-Instanzen oder HSR-Setupknoten als einen einzelnen HSR-Container schützen können.

• Der Vorteil der sofortigen Sicherung und Wiederherstellung.

• Ein HANA-konsistenter, auf Momentaufnahmen basierter Ansatz, der in Backint für SAP HANA integriert wird. Sie können Backup als einzelnes Produkt für Ihre gesamte HANA-Landschaft und für jede Datenbankgröße verwenden.

Weitere Informationen finden Sie unter SAP HANA-Datenbanksystem mit aktivierter Replikation und SAP HANA-Instanz-Momentaufnahmesicherung.

Entwurfsempfehlungen für die Sicherung und Wiederherstellung

• Sie können Azure Backup zum Sichern von VMs mit SAP-Anwendungsservern und zentralen Diensten verwenden.

• Sie können eine SAP HANA-Sicherung für HANA-Bereitstellungen mit bis zu 8 TB verwenden. Weitere Informationen finden Sie in der Unterstützungsmatrix für die Sicherung von SAP HANA-Datenbanken auf Azure-VMs.

• Wenn Sie eine Infrastructure-as-a-Service-Backup-Lösung verwenden, sollten Sie die Backup-Infrastruktur so dimensionieren, dass sie alle Systeme in Produktionsgröße gleichzeitig oder, wie in einem realen Szenario, innerhalb des erwarteten Zeitrahmens sichern kann. Verwenden Sie eine Produktionseinrichtung oder ein ähnliches Setup für Bereiche wie Netzwerk und Sicherheit.

• Testen Sie die Sicherungs- und Wiederherstellungszeiten, um sicherzustellen, dass sie Ihren RTO-Anforderungen entsprechen, um alle Systeme nach einem Notfall gleichzeitig wiederherzustellen.

• Idealerweise sollten Sie eine Übertragung der Sicherungen aus Azure in Ihre lokale Sicherungsinfrastruktur vermeiden. Dies gilt besonders für große Datenbanken. Dieser Ansatz kann sich darauf auswirken, wie viel Bandbreite von den ExpressRoute-Leitungen verwendet wird.

• Führen Sie einen Auslastungstest für die Sicherungs- und Wiederherstellungs-Tools im Rahmen des Leistungstestplans durch.

Notfallwiederherstellung

In den folgenden Abschnitten finden Sie Überlegungen und Empfehlungen zum Entwurf der Notfallwiederherstellung in einem SAP-Szenario.

Überlegungen zum Entwurf für die Notfallwiederherstellung

Auf der Karte mit den Azure-Regionen werden mehr als 65 Azure-Regionen angezeigt, und nicht in allen werden die gleichen Dienste ausgeführt. Suchen Sie bei umfangreicheren SAP-Softwarebereitstellungen, insbesondere bei solchen mit SAP HANA nach Azure-Regionen, in denen VMs der Azure M-Serie oder VMs der Mv2-Serie. Bei Azure Storage werden auch unterschiedliche Regionen gekoppelt, um einen kleineren Teil der Speichertypen in einer anderen Region zu replizieren. Weitere Informationen finden Sie unter Business Continuity & Disaster Recovery (BCDR): Azure-Regionspaare.

Die wichtigsten Hürden bei der Kopplung von Azure-Regionen für SAP-Workloads sind:

• Die Paare sind nicht immer mit den VM-Diensten der M-Serie oder Mv2-Serie konsistent. Viele Organisationen, die SAP-Systeme bereitstellen, verwenden keine Azure-Regionspaare. Stattdessen werden Regionen basierend auf der Verfügbarkeit der erforderlichen VM-Typen ausgewählt.

• Sie können Standardspeicher zwischen gekoppelten Regionen replizieren, aber keinen Standardspeicher zum Speichern Ihrer Datenbanken oder virtuellen Festplatten verwenden. Sie können Sicherungen nur zwischen gekoppelten Regionen replizieren, die Sie verwenden. Führen Sie für alle anderen Daten die Replikation mithilfe systemeigener DBMS-Features wie SQL Server Always On oder SAP HANA-Systemreplikation aus. Verwenden Sie eine Kombination aus Site Recovery, Tools wie rsync oder robocopy und anderer Software, die nicht von Microsoft stammt, für die SAP-Anwendungsschicht.

• Bei einen Notfall wechseln mehrere betroffene Kunden in einer Azure-Region zu der entsprechenden gekoppelten Notfallwiederherstellungsregion. Diese Situation führt zu einem Wettbewerb um Ressourcen, um ruhende VMs in der Notfallwiederherstellungsregion wieder hochzufahren. Die Problemumgehung besteht darin, Nichtproduktionssysteme in der Notfallwiederherstellungsregion auszuführen und dieselben Ressourcen zum Hosten von Notfallwiederherstellungsreplikaten von Produktionssystemen zu verwenden. Diese doppelte Verwendung von Azure-Infrastrukturen in der Notfallwiederherstellungsregion hilft Ihnen, Kapazitätseinschränkungen bei Ressourcen zu vermeiden.

Ein weiterer wichtiger Aspekt ist die Sicherung der erforderlichen Betriebskapazität in der Notfallregion. Wenn ein Notfall auftritt, müssen Sie die SAP-Anwendung möglicherweise nur für ein minimales Zeitfenster mit minimaler IT-Kapazität und kritischen Personalressourcen ausführen, während Sie an der Wiederherstellung des normalen Betriebs in der primären Region arbeiten. Diese Strategie setzt voraus, dass in der Notfallwiederherstellungsregion nur eine minimale IT-Infrastruktur verfügbar ist.

Nachdem Sie Ihre Azure-Regionen definiert haben, müssen Sie ein Bereitstellungsmuster auswählen:

• Werden Produktionssysteme in der primären Region bereitgestellt?

• Werden SAP-Systeme, die nicht für die Produktion bestimmt sind, in der Notfallwiederherstellungsregion bereitgestellt?

• Verwend Sie eine Architektur, bei der alle SAP-Systeme in der primären Region gruppiert werden? Diese Konfiguration stellt sicher, dass die Notfallwiederherstellungsregion nur für die Notfallwiederherstellung verwendet wird.

Die meisten Organisationen verwenden beide Regionen für den Betrieb von SAP-Systemen. Organisationen, die vollständige Kopien der Produktionssysteme als Systeme für geschäftliche Regressionstests ausführen, planen meist, das entsprechende Regressionstestsystem der SAP-Produktlinie als Ziel für die Notfallwiederherstellung zu verwenden.

Wenn Sie eine Notfallwiederherstellungsregion auswählen, stellen Sie sicher, dass ExpressRoute-Konnektivität mit dieser Region besteht. Wenn mehrere ExpressRoute-Leitungen mit Azure verbunden sind, muss mindestens eine dieser Leitungen eine Verbindung mit der primären Azure-Region herstellen. Die anderen sollten mit der Notfallwiederherstellungsregion verbunden sein. Bei dieser Art der Architektur wird eine Verbindung mit dem Azure-Netzwerk in einer anderen geografischen oder geopolitischen Region hergestellt, was zum Schutz Ihrer Verbindung beiträgt, wenn eine der Azure-Regionen von einem Notfall betroffen ist.

Einige Organisationen verwenden eine Kombination aus Hochverfügbarkeits- und Notfallwiederherstellungsarchitektur, bei der Hochverfügbarkeit und Notfallwiederherstellung in derselben Azure-Region gruppiert werden. Das Gruppieren von Hochverfügbarkeit und Notfallwiederherstellung ist jedoch keine ideale Lösung. Diese Architektur wird von Azure-Verfügbarkeitszonen unterstützt. Die Entfernung zwischen Verfügbarkeitszonen innerhalb einer Azure-Region ist nicht so groß wie die Entfernung zwischen zwei unterschiedlichen Azure-Regionen, sodass diese Architektur durch eine Naturkatastrophe in der betroffenen Region ggf. gefährdet sein. Sie müssen auch die Latenz zwischen SAP-Anwendungsservern und -Datenbankservern berücksichtigen. Gemäß SAP-Hinweis 1100926 ist eine Roundtripzeit von weniger als oder gleich 0,3 ms ein guter Wert, und eine Zeit von weniger als oder gleich 0,7 ms ist ein moderater Wert. Für Zonen mit hohen Latenzen sollten Sie daher über Betriebsverfahren verfügen, um sicherzustellen, dass SAP-Anwendungsserver und Datenbankserver immer in derselben Zone ausgeführt werden. Organisationen wählen diese Architektur aus den folgenden Gründen:

• Ausreichende Konformität mit Konfigurationen, die geringere Entfernungen zwischen der Produktionsbereitstellung und einem Notfallwiederherstellungsziel unterstützen.

• Datenhoheit ist ein Faktor.

• Geopolitische Faktoren spielen eine Rolle.

• Es handelt sich um eine kostengünstige Option, die zonenbasierte Ausfälle unterstützt, manchmal in Kombination mit einer Sicherungsübertragung in die sekundäre Region für Naturkatastrophen, die einen großen Radius betreffen.

Ein weiterer Faktor, den Sie bei der Auswahl Ihrer Notfallwiederherstellungsregion berücksichtigen sollten, sind die RPO- und RTO-Werte für das Failover zum Notfallwiederherstellungsstandort. Je größer die Entfernung zwischen der Produktionsregion und den Notfallwiederherstellungsregionen ist, desto höher ist die Netzwerklatenz. Sie replizieren asynchron zwischen Azure-Regionen, aber die Netzwerklatenz kann sich auf den Durchsatz, den Sie replizieren können, und das RPO-Ziel auswirken. Um Ihr RPO zu minimieren, können Sie eine kombinierte Hochverfügbarkeits- und Notfallwiederherstellungsarchitektur verwenden. Diese Konfiguration erhöht jedoch u. U. das Risiko bei weiträumigen Naturkatastrophen.

Entwurfsempfehlungen für die Notfallwiederherstellung

• Achten Sie darauf, dass das klassenlose domänenübergreifende Routing (Classless Inter-Domain Routing, CIDR) für das primäre virtuelle Netzwerk zu keinen Konflikten oder Überlappungen mit dem CIDR des virtuellen Netzwerks des Notfallwiederherstellungsstandorts führt.

• Richten Sie ExpressRoute-Verbindungen von der lokalen Umgebung mit der primären und sekundären Azure-Region für die Notfallwiederherstellung ein.

• Erwägen Sie das Einrichten von VPN-Verbindungen von der lokalen Umgebung zu den primären und sekundären Azure-Regionen für die Notfallwiederherstellung. Nutzen Sie diese Methode als Alternative zur Verwendung von ExpressRoute.

• Verwenden Sie Site Recovery, um einen Anwendungsserver an einem Notfallwiederherstellungsstandort zu replizieren. Site Recovery kann Sie auch beim Replizieren von virtuellen Computern im Cluster für zentrale Dienste am Notfallwiederherstellungsstandort unterstützen. Wenn Sie die Notfallwiederherstellung starten, müssen Sie den Linux Pacemaker-Cluster am Notfallwiederherstellungsstandort neu konfigurieren. Beispielsweise müssen Sie die virtuelle IP-Adresse oder SBD ersetzen oder corosync.conf ausführen.

• Replizieren Sie Key Vault-Inhalte wie Zertifikate, Geheimnisse oder Schlüssel regionsübergreifend, damit Sie Daten in der Notfallwiederherstellungsregion entschlüsseln können.

• Verwenden Sie die regionsübergreifende Replikation in Azure NetApp Files, um Dateivolumes zwischen der primären Region und der Notfallwiederherstellungsregion zu synchronisieren.

• Verwenden Sie anstelle von Azure Site Recovery die native Datenbankreplikation, um Daten mit dem Notfallwiederherstellungsstandort zu synchronisieren.

• Stellen Sie eine Peerverbindung zwischen dem primären VNet und dem VNet für die Notfallwiederherstellung her. Für die HANA-Systemreplikation müssen Sie z. B. ein virtuelles SAP HANA DB-Netzwerk mit dem virtuellen SAP HANA DB-Netzwerk des Notfallwiederherstellungsstandorts verbinden.

• Falls Sie Azure NetApp Files-Speicher für Ihre SAP-Bereitstellungen nutzen, erstellen Sie mindestens zwei Azure NetApp Files-Konten mit Premium-Tarif in zwei Regionen.

• Erwägen Sie die Gruppierung von Systemen basierend auf ihrer geschäftlichen Bedeutung und Lageabhängigkeit basierend auf der Anwendungsleistung. Um die geschäftlichen Auswirkungen eines regionalen Ausfalls zu minimieren, stellen Sie jede Gruppe in einer separaten Region in einem gekoppelten Regionskonstrukt bereit. Um beispielsweise die Auswirkungen eines regionalen Ausfalls zu minimieren, können Sie zwei kritische ERP-Central-Component-Systeme einsetzen, die zwei verschiedene Geschäftseinheiten in Süd- und Westengland bedienen.

Nächster Schritt

Bereitstellungsoptionen für SAP in Azure