Share via

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

  • Artikel

Dieser Artikel baut auf Überlegungen und Empfehlungen auf, die unter Entwurfsbereich für Azure-Zielzonen für Business Continuity & Disaster Recovery (BCDR) definiert sind. In diesem Artikel werden die spezifischen Einschränkungen erläutert, die für alle Zielzonen gelten, die eine SAP-Plattform unterstützen. Da es sich bei SAP um eine unternehmenskritische Plattform handelt, sollten Sie sich auch die anderen Anleitungen im Abschnitt Entwurfsbereiche für Azure-Zielzonen dieser Dokumentation anschauen und in Ihren Entwurf einbeziehen.

Szenario und Umfang

Ihre Architektur muss Prinzipien berücksichtigen, die lokale BCDR-Szenarien (Business Continuity & Disaster Recovery) berücksichtigen. Diese Prinzipien gelten auch in Azure. Der Hauptunterschied besteht darin, dass in Azure ggf. eine höhere Hardwarekapazität als in der lokalen Umgebung verfügbar ist, mit der ein Hostausfall ausgeglichen werden kann. Selbst für die größten Azure-VMs kann eine automatische Wiederherstellung durchgeführt werden, indem sie wieder auf einem anderen Server gestartet werden. Richten Sie für Ihre Azure-Bereitstellungen die gleichen Bedingungen ein wie für Ihre lokalen Bereitstellungen. Wenn Sie lokale Systeme oder Bare-Metal-Hardware mit Clusterkonfigurationen mit automatischem Failover bereitgestellt haben, stellen Sie diese in Azure auf dieselbe Weise bereit. SAP-Anwendungen, die die wichtigsten Geschäftsprozesse einer Organisation ausführen, erfordern Folgendes:

  • Verfügbarkeit von Diensten und Geschäftsprozessen.
  • RTOs (Recovery Time Objective) für Fehler- oder Notfallszenarien.
  • Recovery Point Objectives (RPOs) für Fehlerszenarien
  • Aufgaben für den Betrieb und die Lebenszyklusverwaltung und Technologie, die bei Fehlerszenarien Lücken füllt. 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

Einigen Sie sich frühzeitig auf eine HADR-Lösung (Hochverfügbarkeit und Notfallwiederherstellung) für jeden Archetyp in Ihrer SAP-Landschaft. Achten Sie darauf, dass alle SAP-Komponenten mit einer geeigneten Lösung abgedeckt werden.

Konfigurieren Sie HADR in Azure frühzeitig und dauerhaft in mindestens einer Landschaft. Dies gibt Ihren Teams die Möglichkeit, Erfahrungen mit den beteiligten Technologien zu sammeln, die sich u. U. von vorhandenen Technologien unterscheiden. Die frühzeitige Konfiguration von HADR kann Ihnen auch bei der Entwicklung und Weiterentwicklung Ihrer Standardbetriebsverfahren (SOP) helfen.

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 regionsübergreifender 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 Hochverfügbarkeit liegt der Schwerpunkt auf der Sicherstellung der Verfügbarkeit für Single Points of Failure der SAP-Software, z. B.:

  • Datenbank-Managementsysteme.
  • Single Points of Failure in der Anwendung, z. B. ABAP SAP und ASCS + SCS. Beispiele sind SAP NetWeaver und die SAP S/4HANA-Architektur.
  • Andere Tools, z. B. SAP Web Dispatcher.

Beschränken Sie die Verfügbarkeit für andere Szenarien nicht auf Infrastruktur- oder Softwarefehler. Wenden Sie die Verfügbarkeit auf alle notwendigen Aufgaben der Lebenszyklusverwaltung an, z. B. das Patchen des Betriebssystems auf den VMs, des DBMS und der SAP-Software. 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 durch Windows Server-Failoverclustering unterstützt. Unter Linux werden Failover durch Linux Pacemaker oder Drittanbietertools wie SIOS Protection Suite und Veritas InfoScale unterstützt. In Azure können Sie nur einen Teil der Hochverfügbarkeitskonfiguration Ihres eigenen Rechenzentrums bereitstellen.

Weitere Informationen zur Azure-Unterstützung von SAP finden Sie unter Unterstützte Szenarien für SAP-Workloads auf virtuellen Azure-Computern und Unterstützte Szenarien für große SAP HANA-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 VM den Speicher für DBMS-Daten gemeinsam nutzen. Azure unterstützt auch keine Transaktions- bzw. Wiederholungsprotokolle. Das Grundprinzip besteht darin, auch dann zwei unabhängige Speicherstapel zu verwenden, wenn diese auf NFS-Freigaben (Network File System) basieren. Dieser Ansatz ist die Haupteinschränkung beim Vergleich der lokalen Möglichkeiten mit den Möglichkeiten in Azure.

Azure bietet weitere Optionen, da entweder NFS oder die Server Message Block-Freigabe (SMB) unterstützt wird. Sie können einen freigegebenen Azure-Datenträger in Windows für ASCS + SCS-Komponenten und bestimmte Szenarien mit Hochverfügbarkeit verwenden. Richten Sie Ihre Failovercluster separat für Komponenten der SAP-Anwendungsebene und die DBMS-Ebene ein. Azure unterstützt derzeit 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 verbreitete Ausnahme ist die Verwendung von Oracle Data Guard. Hier ist keine virtuelle IP-Adresse erforderlich. In allen anderen Fällen sollte die virtuelle IP-Adresse von Azure Load Balancer verarbeitet werden. Ein Entwurfsprinzip ist die Verwendung eines Load Balancers pro Clusterkonfiguration. Hierfür wird die Verwendung der Standardversion des Load Balancers empfohlen. Weitere Informationen finden Sie unter Konnektivität öffentlicher Endpunkte für VMs, die Azure Load Balancer Standard in SAP-Hochverfügbarkeitsszenarios verwenden.

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

Im Folgenden sind die SLAs auf Plattformebene für verschiedene Optionen für Hochverfügbarkeitsbereitstellungen aufgeführt. Die Partner, die die verwalteten Dienste anbieten, stellen die SLA auf Anwendungsebene bereit.

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

Weitere Informationen finden Sie im nächsten Abschnitt.

Vergleich: Azure-Verfügbarkeitsgruppen und Verfügbarkeitszonen

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

  • Die VMs sind nicht auf unterschiedliche Verfügbarkeitszonen verteilt.
  • Die VM-Typen, die über eine einzelne Verfügbarkeitsgruppe bereitgestellt werden können, sind begrenzt, da der Host basierend auf der ersten VM definiert wird, die in der Gruppe bereitgestellt wird. Sie können daher beispielsweise in einer Verfügbarkeitsgruppe keine VMs der M-Serie und der E-Serie kombinieren.

Ein Vorteil der Bereitstellung Ihrer Architektur für Hochverfügbarkeit in verschiedenen Verfügbarkeitszonen ist, dass Ihre Vereinbarung zum Servicelevel (Service Level Agreement, SLA) für die VMs höher sein kann. Ausführlichere Informationen finden Sie unter SLA für Virtuelle Computer. 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 eine Bereitstellung mit Zonen entscheiden, sollten Sie die Auswirkungen der zonenübergreifenden Latenz für die ausgewählte Azure-Region, zwischen Anwendungsserver und Datenbank sowie zwischen den beiden Datenbankknoten auf Leistung und Architekturentwurfsoptionen berücksichtigen.

Wenn Sie eine Aktiv/Passiv-Bereitstellung mit Zonen für die Anwendungsserverebene verwenden (Anwendungsserver müssen über eine Verbindung mit der Datenbank in derselben Verfügbarkeitszone verfügen), müssen Sie eine Automatisierung implementieren und Standardbetriebsverfahren erstellen, um bei einem Datenbankfailover eine schnelle und automatisierte Wiederherstellung zu ermöglichen.

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. Beispiele für Dienste und Komponenten, die berücksichtigt werden sollten, sind Azure ExpressRoute-Gateways, Azure Load Balancer, Azure Files, Azure NetApp Files, Reverseproxy, Firewalls, Antivirensoftware 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. Informationen zu SLAs für VMs, Verfügbarkeitsgruppen und Verfügbarkeitszonen finden Sie unter SLA für Virtuelle Computer.

  • 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 unterschiedliche Zonen verwenden, werden die VMs in verschiedenen physischen Standorte erstellt. Diese Konfiguration bietet zusätzlichen Schutz vor Energie-, Kühlungs- oder Netzwerkproblemen, die sich auf die Rechenzentren der gesamten Zone auswirken. Sie können Azure-Verfügbarkeitsgruppen jedoch nicht in einer Azure-Verfügbarkeitszone bereitstellen, solange Sie keine 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 diese Vorteile erzielen, indem Sie Verfügbarkeitsgruppen verwenden (siehe Beschreibung unter Azure-Näherungsplatzierungsgruppen für optimale Netzwerklatenz von SAP-Anwendungen).

  • Verwenden Sie beim Erstellen von Verfügbarkeitsgruppen die maximale Anzahl verfügbarer Fehler- und Updatedomänen. Verwenden Sie beispielsweise bei der Bereitstellung von mehr als zwei VMs in einer Verfügbarkeitsgruppe die maximale Anzahl von Fehlerdomänen (drei) und genügend Updatedomänen, um die Auswirkungen potenzieller physischer Hardwareausfälle, Netzwerkausfälle oder Unterbrechungen der Stromversorgung über die geplante Azure-Wartung hinaus 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 der Verwendung von Azure-Näherungsplatzierungsgruppen in der Bereitstellung mit Verfügbarkeitsgruppen sollten sich alle drei SAP-Komponenten (zentrale Dienste, Anwendungsserver und Datenbank) in derselben Näherungsplatzierungsgruppe befinden.

  • Wenn Sie Näherungsplatzierungsgruppen nutzen, verwenden Sie eine pro SAP-SID. Gruppen reichen nicht über Verfügbarkeitszonen oder Azure-Regionen hinweg.

  • Bei Verwendung von Azure-Näherungsplatzierungsgruppen in einer Bereitstellung mit Verfügbarkeitszonen sollten sich die beiden SAP-Komponenten (zentrale Dienste und Anwendungsserver) in derselben Näherungsplatzierungsgruppe befinden. Die Datenbank-VMs in den beiden Zonen sind nicht mehr Teil der Näherungsplatzierungsgruppen. Die Näherungsplatzierungsgruppen pro Zone sind mit der Bereitstellung der VM, auf der die SAP ASCS + SCS-Instanzen ausgeführt werden, verknüpft. Der Vorteil dieser Konfiguration besteht darin, dass Sie mehr Flexibilität bei der Größenänderung von VMs haben. Zudem ist es einfacher, in der DBMS-Ebene oder der Anwendungsebene des SAP-Systems zu neuen VM-Typen zu wechseln.

  • Azure unterstützt derzeit keine Kombination von Hochverfügbarkeit für ASCS und Datenbank 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 Datenbankclustern eine Load Balancer Standard-SKU.

  • Führen Sie alle Produktionssysteme auf verwalteten Premium-SSDs aus, und verwenden Sie Azure NetApp Files oder Disk Storage Ultra. Zumindest für den Betriebssystemdatenträger sollte der Premium-Tarif genutzt werden, um die Leistung zu verbessern und eine optimale SLA zu erreichen.

  • Stellen Sie beide virtuellen Computer im Hochverfügbarkeitspaar in einer Verfügbarkeitsgruppe oder in Verfügbarkeitszonen bereit. Diese virtuellen Computer müssen dieselbe Größe und dieselbe Speicherkonfiguration aufweisen.

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

  • Verwenden Sie je nach Betriebssystem einen der folgenden Dienste zum Ausführen zentraler SAP-Dienstcluster:

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

Speicher für SAP-Workloads

  • Der Entwurf von Resilienz für Ihre SAP-Workload umfasst die Auswahl der richtigen Speicheroptionen. Der Entwurf für SAP-Workloads im Azure-Speicher soll 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. Informationen zu den verschiedenen Speichertypen und deren Kompatibilität mit SAP-Workloads und -Komponenten finden Sie unter Azure-Speichertypen für SAP-Workloads.

  • Sie sollten SAP HANA in Azure nur in den von SAP zertifizierten Speichertypen ausführen. Beachten Sie, dass bestimmte Volumes ggf. auf speziellen Datenträgerkonfigurationen ausgeführt werden müssen. Diese Konfigurationen beinhalten die Aktivierung der Schreibbeschleunigung und die Verwendung von Premium-Speicher. 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 an virtuelle Computer angefügten verwalteten Azure-Datenträgern werden verschiedene native, freigegebene Azure-Speicherlösungen verwendet, um SAP-Anwendungen in Azure auszuführen. Ihre Hochverfügbarkeitskonfiguration kann abweichen, da einige Speicherdienste, die in Azure verfügbar sind, von Azure Site Recovery nicht unterstützt werden. Die folgenden Speichertypen werden in der Regel für SAP-Workloads verwendet:

    Speichertyp Unterstützung der Hochverfügbarkeitskonfiguration
    Freigegebene Azure-Datenträger (LRS oder ZRS) Windows Server-Failovercluster. Konfigurationsdetails finden Sie unter Gruppieren einer SAP ASCS/SCS-Instanz in einem Windows-Failovercluster mithilfe freigegebener Clusterdatenträger in Azure.
    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 virtuelle SAP-Computer.
    SMB in Azure Files (LRS oder ZRS) Windows Server-Failovercluster. Konfigurationsdetails finden Sie unter Hochverfügbarkeit für SAP NetWeaver auf Azure VMs auf Windows mit Azure Files Premium SMB für SAP-Anwendungen.
    SMB für Azure NetApp Files Windows Server-Failovercluster. Konfigurationsdetails finden Sie unter Hochverfügbarkeit von SAP NetWeaver auf virtuellen Azure-Computern unter Windows mit Azure NetApp Files (SMB) für SAP-Anwendungen.

  • Anstelle von nativen freigegebenen Azure-Speicherdiensten können Sie herkömmliche NFS-Cluster (basierend auf der DRBD-Replikation), GlusterFS oder freigegebene Clustervolumes mit „Direkte Speicherplätze“ als alternative freigegebene Speicherlösung verwenden, um SAP-Workloads in Azure auszuführen. 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. Informationen zur Verfügbarkeit des Speicherdiensts finden Sie unter Verfügbare Produkte nach Region.

  • Informationen zu Speicheroptionen, die für SAP-Workloads in Azure verfügbar sind, finden Sie in den 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, in denen SAP-Anwendungen verwendet werden, müssen Bestimmungen in Bezug auf die Konformität befolgen, bei denen Sicherungen viele Jahre lang gespeichert werden müssen. Auch in anderen Szenarien sind Sicherungen unabdingbar, um eine Wiederherstellung durchführen zu können. Es wird davon ausgegangen, dass Sie bereits bewährte Methoden für die Sicherung und Wiederherstellung für SAP-Anwendungen eingerichtet haben, die folgende Möglichkeiten bieten:

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

Wenn Sie die Sicherung und Wiederherstellung lokal durchführen, 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 eine SaaS-Lösung (Software-as-a-Service) für Azure verfügbar ist.

Azure bietet den SaaS-Sicherungsdienst 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.

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 von bis zu 8 TB verwenden. Weitere Informationen finden Sie in der Unterstützungsmatrix für die Sicherung von SAP HANA-Datenbanken auf virtuellen Azure-Computern.

  • Wenn Sie eine IaaS-Sicherungslösung verwenden, müssen Sie die Sicherungsinfrastruktur so dimensionieren, dass alle Produktionssysteme gleichzeitig (bzw. wie in einem realen Szenario innerhalb erwarteter Zeitrahmen) und mit einer Produktionseinrichtuung oder einer ähnlichen Einrichtung von Netzwerk, Sicherheit usw. gesichert werden können.

  • Testen Sie die Sicherungs- und Wiederherstellungszeiten, um zu überprüfen, ob sie Ihre RTO-Anforderungen für die gleichzeitige Wiederherstellung aller Systeme nach einem Notfall erfüllen.

  • Idealerweise sollten Sie eine Übertragung der Sicherungen aus Azure in Ihre lokale Sicherungsinfrastruktur vermeiden. Dies gilt besonders für große Datenbanken. Dies wirkt sich auf die genutzte Bandbreite der ExpressRoute-Leitungen aus.

  • 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

Die Karte mit den Azure-Regionen umfasst mehr als 65 Azure-Regionen, in denen nicht immer die gleichen Dienste verfügbar sind. Suchen Sie bei umfangreicheren SAP-Softwarebereitstellungen (vor allem bei Bereitstellungen mit SAP HANA) nach Azure-Regionen, in denen Azure-VMs der M-Serie oder Mv2-Serie angeboten werden. 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 Ihre Replikation mit nativen DBMS-Features wie SQL Server Always On oder SAP HANA System Replication aus. Verwenden Sie eine Kombination aus Site Recovery, rsync oder robocopy und anderer Drittanbietersoftware für die SAP-Anwendungsebene.

  • Wenn ein Notfall auftritt, werden mehrere betroffene Kunden in einer Azure-Region ein Failover auf die entsprechende gekoppelte Notfallwiederherstellungsregion ausführen wollen. Diese Situation führt zu einem Wettbewerb um Ressourcen, um ruhende virtuelle Computer in der Notfallwiederherstellungsregion zu aktivieren. Die Problemumgehung besteht darin, Nichtproduktionssysteme in der Notfallwiederherstellungsregion auszuführen und dieselben Ressourcen zum Hosten von Notfallwiederherstellungsreplikaten von Produktionssystemen zu verwenden. Diese doppelte Nutzung von Azure-Infrastrukturen in der Notfallwiederherstellungsregion hilft Ihnen, Ressourcenkapazitätsengpässe 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. Dies setzt voraus, dass Sie in der Notfallwiederherstellungsregion über eine minimale IT-Infrastruktur verfügen.

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 einer derartigen Architektur wird eine Verbindung mit dem Azure-Netzwerk in einer anderen geografischen oder geopolitischen Region hergestellt. Dies bietet Schutz für Ihre Verbindung, wenn eine Azure-Region durch einen Notfall beeinträchtigt 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. Da die Entfernung zwischen Verfügbarkeitszonen innerhalb einer Azure-Region nicht so groß ist wie die Entfernung zwischen zwei Azure-Regionen, kann eine Naturkatastrophe eine Gefahr für die Anwendungsdienste in der betroffenen Region darstellen. 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. Daher müssen für Zonen mit hohen Latenzen Betriebsverfahren eingerichtet werden, um sicherzustellen, dass SAP-Anwendungsserver und -Datenbankserver jederzeit 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 Zonenausfälle unterstützt, und manchmal mit der Sicherungsübertragung in die sekundäre Region für Naturkatastrophen kombiniert wird, die einen großen Wirkungsradius haben.

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 den Regionen für die Produktion und die Notfallwiederherstellung ist, desto höher ist die Netzwerklatenz. Obwohl die Replikation asynchron zwischen Azure-Regionen erfolgt, kann sich eine die Netzwerklatenz auf den möglichen Durchsatz für die Replikation und das RPO-Ziel auswirken. Oft ist es möglich, die RPO-Ziele durch die Verwendung einer Architektur mit kombinierter Hochverfügbarkeit und Notfallwiederherstellung zu minimieren. 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 als Alternative zu ExpressRoute die Einrichtung von VPN-Verbindungen von der lokalen Umgebung zur primären und sekundären Azure-Region für die Notfallwiederherstellung.
  • 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. Sie müssen z. B. die VIP oder das SBD ersetzen, corosync.conf ausführen usw.
  • Replizieren Sie Schlüsseltresorinhalte 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 (derzeit als Public Preview verfügbar), 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 muss beispielsweise für ein SAP HANA-DB-VNet ein Peering mit dem SAP HANA-DB-VNet des Notfallwiederherstellungsstandorts eingerichtet werden.
  • 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. Stellen Sie jede Gruppe in einer separaten Region in einem gepaarten Regionskonstrukt bereit, um die geschäftlichen Auswirkungen eines regionalen Ausfalls zu minimieren. Beispielsweise können zwei kritische ECC-Systeme für zwei verschiedene Unternehmenseinheiten im Vereinigten Königreich, Süden und im Vereinigten Königreich, Westen bereitgestellt werden, um die Auswirkungen eines regionalen Ausfalls zu minimieren.

Nächste Schritte

Bereitstellungsoptionen für SAP in Azure