Übersicht über die Notfallwiederherstellung und Leitlinien für die Infrastruktur für SAP-Workloads

  • Artikel

Viele Organisationen, die kritische Geschäftsanwendungen in Azure ausführen, arbeiten Strategien für sowohl Hochverfügbarkeit als auch Notfallwiederherstellung aus. Der Zweck von Hochverfügbarkeit ist es, die SLA von Geschäftssystemen zu erhöhen, indem Single Points of Failure aus der zugrunde liegenden Systeminfrastruktur beseitigt werden. Hochverfügbarkeitstechnologien reduzieren die Auswirkungen ungeplanter Infrastrukturausfälle und helfen bei geplanten Wartungen. Die Notfallwiederherstellung umfasst Richtlinien, Tools und Verfahren, die die Wiederherstellung oder Kontinuität wichtiger IT-Infrastrukturen und -Systeme nach einer Natur- oder von Menschen verursachten Katastrophe ermöglichen.

Um eine hohe Verfügbarkeit für SAP-Workload auf Azure zu erzielen, werden virtuelle Computer in der Regel in einem Verfügbarkeitssatz, in verfügbarkeitszonen oder in flexibler Skalierung bereitgestellt, um Anwendungen vor der Infrastruktur Standard Zurücksetzung oder Fehlern innerhalb der Region zu schützen. Aber die Bereitstellung schützt Anwendungen nicht vor einer großflächigen Katastrophe innerhalb der Region. Um also Anwendungen vor regionalen Katastrophen zu schützen, sollten Sie eine Strategie zur Notfallwiederherstellung für die Anwendungen ausarbeiten. Die Notfallwiederherstellung ist ein dokumentierter und strukturierter Ansatz, der eine Organisation bei der Durchführung der Wiederherstellungsprozesse als Reaktion auf eine Katastrophe unterstützen soll, um IT-Dienste vor Unterbrechungen zu schützen oder diese zu minimieren und die Wiederherstellung zu erleichtern.

Dieses Dokument enthält Einzelheiten zum Schutz von SAP-Workloads vor großflächigen Katastrophen durch Implementieren eines strukturierten Ansatzes für die Notfallwiederherstellung. Die Details in diesem Dokument werden auf abstrakter Ebene basierend auf verschiedenen Azure-Diensten und SAP-Komponenten vorgestellt. Die konkrete Notfallwiederherstellungsstrategie sowie die Reihenfolge der Wiederherstellung für Ihre SAP-Workload müssen regelmäßig getestet, dokumentiert und optimiert werden. Außerdem konzentriert sich das Dokument auf die Azure-zu-Azure-Strategie zur Notfallwiederherstellung für SAP-Workloads.

Allgemeine Aspekte des Notfallwiederherstellungsplans

Die SAP-Workload in Azure wird auf virtuellen Computern in Kombination mit verschiedenen Azure-Diensten ausgeführt, um verschiedene Ebenen (Central Services, Anwendungsserver, Datenbankserver) einer typischen SAP NetWeaver-Anwendung bereitzustellen. Generell sollte eine Notfallwiederherstellungsstrategie für die gesamte in Azure betriebene IT-Landschaft geplant werden, was bedeutet, dass auch Nicht-SAP-Anwendungen berücksichtigt werden müssen. Die in SAP-Systemen ausgeführte Geschäftslösung funktioniert möglicherweise nicht in vollem Umfang, wenn die abhängigen Dienste oder Ressourcen am Standort der Notfallwiederherstellung nicht wiederhergestellt werden. Daher benötigen Sie einen sorgfältig ausgearbeiteten, umfassenden Notfallwiederherstellungsplan, der alle Komponenten und Systeme berücksichtigt.

Für die Notfallwiederherstellung in Azure sollten Organisationen verschiedene Szenarien berücksichtigen, die möglicherweise ein Failover auslösen.

  • Verfügbarkeit von SAP-Anwendungen oder -Geschäftsprozessen.
  • Nichtverfügbarkeit von Azure-Diensten (z. B. virtuelle Computer, Speicher, Lastenausgleich usw.) in einer Region aufgrund eines großflächigen Ausfalls.
  • Potenzielle Bedrohungen und Sicherheitsrisiken für die Anwendung (z. B. DDoS-Angriff auf Anwendungsebene)
  • Zur Einhaltung geschäftlicher Vorgaben sind betriebliche Vorgänge zum Testen der Strategie für die Notfallwiederherstellung erforderlich (z. B. jährliche Übung zur Notfallwiederherstellung nach Ausfall gemäß den Vorgaben).

Um das Wiederherstellungsziel für verschiedene Szenarien zu erreichen, muss die Organisation das RTO (Recovery Time Objective) und RPO (Recovery Point Objective) für ihre Workload basierend auf den Geschäftsanforderungen festlegen. Das RTO gibt die Zeit an, die eine Anwendung ausfallen darf, normalerweise gemessen in Stunden, Minuten oder Sekunden. Das RPO beschreibt die Menge an Transaktionsdaten, deren Verlust für das Unternehmen akzeptabel ist, damit der normale Geschäftsbetrieb fortgesetzt werden kann. Das Festlegen von RTO und RPO für Ihr Unternehmen ist von entscheidender Bedeutung, da es Ihnen hilft, Ihre Notfallwiederherstellungsstrategie optimal zu gestalten. Die an der SAP-Workload beteiligten Komponenten (Compute, Speicher, Datenbank usw.) werden mithilfe verschiedener Techniken (native Azure-Dienste, native Datenbankreplikationstechnologie, benutzerdefinierte Skripts) in die Notfallwiederherstellungsregion repliziert. Jede Technik stellt ein unterschiedliches RPO bereit, was beim Entwerfen einer Notfallwiederherstellungsstrategie berücksichtigt werden muss. In Azure können Sie einige der nativen Azure-Dienste wie Azure Site Recovery und Azure Backup nutzen, die Ihnen helfen, das RTO und RPO Ihrer SAP-Workloads zu erfüllen. Informationen zur optimalen Abstimmung auf Ihr RTO und RPO finden Sie in der Vereinbarung zum Servicelevel (SLA) von Azure Site Recovery und Azure Backup.

Entwurfsaspekte für die Notfallwiederherstellung in Azure

Es gibt verschiedene Elemente, die beim Entwerfen einer Notfallwiederherstellungslösung in Azure zu berücksichtigen sind. Die Prinzipien und Konzepte, die beim Entwerfen lokaler Notfallwiederherstellungslösungen beachtet werden, gelten auch für Azure. In Azure ist die Regionsauswahl jedoch ein wichtiger Bestandteil beim Entwerfen der Strategie für die Notfallwiederherstellung. Beachten Sie also bei der Auswahl der Region für die Notfallwiederherstellung in Azure die folgenden Punkte.

  • Geschäftliche oder gesetzliche Anforderungen können eine bestimmte Entfernung zwischen dem primären Standort und dem Standort für die Notfallwiederherstellung vorschreiben. Eine Vorgabe zur Entfernung trägt dazu bei, Verfügbarkeit zu gewährleisten, wenn sich eine Naturkatastrophe in einem größeren geografischen Gebiet ereignet. In einem solchen Fall kann eine Organisation eine andere Azure-Region als Standort für die Notfallwiederherstellung wählen. Die Entfernung zwischen Azure-Regionen ist häufig groß und kann wie in den USA mehrere Hundert oder sogar Tausend Kilometer betragen. Aufgrund der Entfernung ist die Latenz für den Netzwerkroundtrip höher, was zu einem höheren RPO führen kann.

  • Kunden, die ihre lokale Notfallwiederherstellung in Azure simulieren möchten, können Verfügbarkeitszonen für die Notfallwiederherstellung verwenden. Aber eine Notfallwiederherstellung zwischen Zonen kann den Anforderungen an Resilienz nicht genügen, wenn es zu einer geografisch großflächigen Naturkatastrophe kommt.

  • In Azure ist jede Region mit einer anderen Region innerhalb desselben geografischen Gebiets gekoppelt (mit Ausnahme von Brasilien, Süden). Dieser Ansatz ermöglicht eine von der Plattform bereitgestellte regionsübergreifende Replikation von Ressourcen. Die Vorteile der Wahl gekoppelter Regionen finden Sie im Dokument zu Regionspaaren. Wenn sich eine Organisation für gekoppelte Azure-Regionen entscheidet, müssen für eine SAP-Workload einige zusätzliche Punkte berücksichtigt werden:

    • Nicht alle Azure-Dienste bieten die regionsübergreifende Replikation in eine gekoppelte Region.

    • Die Azure-Dienste und -Features in gekoppelten Azure-Regionen sind möglicherweise nicht symmetrisch. Azure NetApp Files und VM-SKUs wie die M-Serie, die in der primären Region verfügbar sind, sind möglicherweise in der gekoppelten Region nicht verfügbar. Weitere Informationen darüber, ob Azure-Produkte oder -Dienste in einer Region verfügbar sind, finden Sie unter Azure-Produkte nach Region.

    • Die Option GRS (georedundanter Speicher) ist für ein Speicherkonto mit einem Standardspeichertyp verfügbar, bei dem Daten in eine gekoppelte Region repliziert werden. Standardspeicher eignet sich jedoch nicht für ein SAP-Datenbank-Managementsystem (DBMS) oder virtuelle Datenträger.

    • Der Dienst Azure Backup, der zum Sichern unterstützter Lösungen verwendet wird, kann Sicherungen nur zwischen gekoppelten Regionen replizieren. Führen Sie für alle anderen Daten eigene Replikationen mit nativen DBMS-Features wie SQL Server Always On, SAP HANA-Systemreplikation und anderen Diensten aus. Verwenden Sie für die SAP-Anwendungsebene eine Kombination aus Azure Site Recovery, rsync oder robocopy und anderer Drittanbietersoftware.

Referenzbereitstellung für SAP-Workload

Nachdem Sie eine Notwiederherstellungsregion bestimmt haben, ist es wichtig, dass das Spektrum der Azure-Kerndienste (wie Netzwerk, Compute, Storage), das Sie in der primären Region konfiguriert haben, auch in der Notwiederherstellungsregion verfügbar ist und konfiguriert werden kann. Die Organisation muss für die SAP-Workload ein Bereitstellungsmuster für die Notfallwiederherstellung entwickeln. Das Bereitstellungsmuster variiert und muss den Anforderungen der Organisation entsprechen.

  • Stellen Sie die SAP-Produktionsworkload in Ihrer primären Region und die Nicht-Produktionsworkload in der Notfallwiederherstellungsregion bereit.
  • Stellen Sie alle SAP-Workloads (Produktion und Nicht-Produktion) in Ihrer primären Region bereit. Die Notfallwiederherstellungsregion wird nur verwendet, wenn ein Failover erfolgt.

Die folgende Referenzarchitektur zeigt das typische in Azure ausgeführte SAP NetWeaver-System mit Hochverfügbarkeit in der primären Region. Der unten gezeigte sekundäre Standort ist der Standort für die Notfallwiederherstellung, an dem die SAP-Systeme nach einer Katastrophe wiederhergestellt werden. Sowohl die primäre als auch die Notfallwiederherstellungsregion gehören zum selben Abonnement. Um eine Notfallwiederherstellung für eine SAP-Workload zu erreichen, müssen Sie die Wiederherstellungsstrategie für jede SAP-Ebene zusammen mit den verschiedenen Azure-Diensten bestimmen, die die Anwendung nutzt.

Organisationen müssen eine Notfallwiederherstellungsstrategie für ihre gesamte IT-Landschaft planen und entwerfen. Normalerweise sind SAP-Systeme, die in einer Produktionsumgebung betrieben werden, in verschiedene Dienste und Schnittstellen wie Active Directory, DNS, Anwendungen von Drittanbietern usw. integriert. Sie müssen daher auch die Nicht-SAP-Systeme und andere Dienste in die Planung Ihrer Notfallwiederherstellung einbeziehen. Dieses Dokument konzentriert sich auf die Wiederherstellungsplanung für SAP-Anwendungen. Sie können jedoch Größe und Umfang der Notfallwiederherstellung auf abhängige Komponenten ausdehnen, um Ihre Anforderungen zu erfüllen.

Disaster Recovery reference architecture for SAP workload

Infrastrukturkomponenten der Notfallwiederherstellungslösung für SAP-Workload

Eine in Azure ausgeführte SAP-Workload verwendet zum Betreiben einer Geschäftslösung verschiedene Infrastrukturkomponenten. Um die Notfallwiederherstellung für eine solche Lösung zu planen, ist es wichtig, dass alle in der primären Region konfigurierten Infrastrukturkomponenten verfügbar sind und auch in der Notwiederherstellungsregion konfiguriert werden können. Die folgenden Infrastrukturkomponenten sollten bei der Notfallwiederherstellungslösung für die SAP-Workload in Azure berücksichtigt werden.

  • Netzwerk
  • Compute
  • Storage

Netzwerk

  • Mit ExpressRoute können Sie Ihr lokales Netzwerk mithilfe eines Konnektivitätsanbieters über eine private Verbindung mit der Microsoft-Cloud verbinden. Beim Entwerfen einer Architektur für die Notfallwiederherstellung muss der Aufbau einer stabilen Back-End-Netzwerkkonnektivität mithilfe einer georedundanten ExpressRoute-Leitung berücksichtigt werden. Es wird empfohlen, mindestens eine ExpressRoute-Leitung zwischen der lokalen Umgebung und der primären Region einzurichten. Die anderen Leitungen sollten mit der Notfallwiederherstellungsregion verbunden sein. Lesen Sie den Artikel "Entwerfen von Azure ExpressRoute für Notfallwiederherstellung ", in dem verschiedene Szenarien zum Entwerfen der Notfallwiederherstellung für ExpressRoute beschrieben werden.

    Hinweis

    Erwägen Sie zur Absicherung von Azure ExpressRoute das Einrichten eines Site-to-Site-VPN (S2S). Weitere Informationen finden Sie unter Verwenden von S2S-VPN als Absicherung für privates ExpressRoute-Peering.

  • Virtuelle Netzwerke und Subnetze umfassen alle Verfügbarkeitszonen in einer Region. Für eine zwei Regionen übergreifende Notfallwiederherstellung müssen Sie separate virtuelle Netzwerke und Subnetze in der Notfallwiederherstellungsregion konfigurieren. Weitere Informationen zur Einrichtung von Netzwerken in der Notwiederherstellungsregion finden Sie unter Informationen zu Netzwerken für die Notfallwiederherstellung für virtuelle Azure-Computer.

  • Azure Load Balancer Standard bietet Netzwerkelemente für den Hochverfügbarkeitsentwurf Ihrer SAP-Systeme. Für gruppierte Systeme stellt Load Balancer Standard die virtuelle IP-Adresse für den Clusterdienst bereit, wie ASCS/SCS-Instanzen und Datenbanken, die auf virtuellen Computern ausgeführt werden. Um ein hochverfügbares SAP-System am Standort der Notfallwiederherstellung zu betreiben, muss ein separater Lastenausgleich eingerichtet und die Clusterkonfiguration entsprechend angepasst werden.

  • Azure Application Gateway ist ein Lastenausgleich für Webdatenverkehr. Mit seiner Web Application Firewall-Funktionalität eignet sich dieser Dienst besonders, um Webanwendungen mit verbesserter Sicherheit für das Internet verfügbar zu machen. Azure Application Gateway kann je nach Konfiguration entweder für öffentliche (Internet-) oder private Clients oder beide dienen. Nach einem Failover muss in der Notwiederherstellungsregion eine separate Azure Application Gateway-Instanz konfiguriert werden, um ähnlichen eingehenden HTTP(s)-Datenverkehr zuzulassen.

  • Da Netzwerkkomponenten (wie virtuelles Netzwerk, Firewall usw.) in der Notfallwiederherstellungsregion separat erstellt werden, müssen Sie sicherstellen, dass die SAP-Workload in der Notwiederherstellungsregion an die Netzwerkänderungen wie DNS-Aktualisierung, Firewall usw. angepasst wird.

  • Virtuelle Netzwerke in beiden Regionen sind unabhängig voneinander. Um die Kommunikation zwischen beiden herzustellen, müssen Sie ein Peering virtueller Netzwerke zwischen den beiden Regionen aktivieren.

Virtuelle Computer

  • In Azure werden verschiedene Komponenten eines einzelnen SAP-Systems auf virtuellen Computern mit unterschiedlichen SKU-Typen ausgeführt. Für die Notfallwiederherstellung kann der Schutz einer Anwendung (SAP NetWeaver und Nicht-SAP), die in Azure-VMs ausgeführt wird, durch die Replikation von Komponenten mithilfe von Azure Site Recovery in eine andere Azure-Region oder -Zone ermöglicht werden. Mit Azure Site Recovery werden Azure-VMs kontinuierlich vom primären Standort an den Standort der Notfallwiederherstellung repliziert. Je nach ausgewählter Azure-Region für die Notfallwiederherstellung ist der Typ der VM-SKU möglicherweise nicht am Standort für die Notfallwiederherstellung verfügbar. Sie müssen sicherstellen, dass die erforderlichen Typen von VM-SKUs auch in der Azure-Region für die Notfallwiederherstellung verfügbar sind. Prüfen Sie Azure-Produkte nach Region, um festzustellen, ob der erforderliche SKU-Typ der VM-Familie verfügbar ist oder nicht.

    Wichtig

    Wenn SAP-System mit flexiblem Skalierungssatz mit FD=1 konfiguriert ist, müssen Sie PowerShell verwenden, um Azure Site Recovery für die Notfallwiederherstellung einzurichten. Derzeit ist es die einzige Methode zum Konfigurieren der Notfallwiederherstellung für VMs, die im Skalierungssatz bereitgestellt werden.

  • Für Datenbanken, die auf virtuellen Azure-Computern betrieben werden, wird empfohlen, die native Datenbankreplikationstechnologie zu verwenden, um die Daten mit dem Standort für die Notfallwiederherstellung zu synchronisieren. Die großen VMs, auf denen die Datenbanken betrieben werden, sind möglicherweise nicht in allen Regionen verfügbar. Wenn Sie Verfügbarkeitszonen für die Notfallwiederherstellung verwenden, müssen Sie prüfen, ob die entsprechenden VM-SKUs in der Zone Ihres Standorts für die Notfallwiederherstellung verfügbar sind.

    Hinweis

    Es wird nicht empfohlen, Azure Site Recovery für Datenbanken zu verwenden, da diese Lösung keine Datenbankkonsistenz garantiert und eine Einschränkung aufgrund von Datenänderungsraten aufweist.

  • Bei Produktionsanwendungen, die ständig in der primären Region ausgeführt werden, werden in der Regel reservierte Instanzen verwendet, um Azure-Kosten zu sparen. Bei reservierter Instanzen müssen Sie sich für eine verpflichtende Nutzungsdauer von einem oder drei Jahren registrieren, was für den Standort für die Notfallwiederherstellung möglicherweise nicht wirtschaftlich ist. Außerdem garantiert Ihnen das Einrichten von Azure Site Recovery nicht die Kapazität der benötigten VM-SKU während des Failovers. Um sicherzustellen, dass die VM-SKU-Kapazität verfügbar ist, können Sie eine Option zur Aktivierung einer bedarfsgesteuerten Kapazitätsreservierung in Betracht ziehen. Damit reservieren Sie ohne Verpflichtung Computekapazität in einer Azure-Region oder -Verfügbarkeitszone für eine beliebige Zeitspanne. Azure Site Recovery ist in die bedarfsgesteuerte Kapazitätsreservierung integriert. Dank dieser Integration können Sie die Leistungsfähigkeit von Kapazitätsreservierungen mit Azure Site Recovery nutzen, um die Computekapazität am Standort für die Notfallwiederherstellung zu reservieren und den Erfolg Ihrer Failovers zu garantieren. Weitere Informationen finden Sie unter Einschränkungen bei der bedarfsgesteuerten Kapazitätsreservierung .

  • Ein Azure-Abonnement verfügt über Kontingente für VM-Familien (z. B. die Mv2-Familie) und andere Ressourcen. Mitunter möchten Organisationen ein anderes Azure-Abonnement für die Notfallwiederherstellung einsetzen. Jedem Abonnement (primär und für die Notfallwiederherstellung) können für jede VM-Familie unterschiedliche Kontingente zugewiesen sein. Stellen Sie sicher, dass das für den Standort für die Notfallwiederherstellung verwendete Abonnement über genügend Kontingente für Computekapazität verfügt.

Storage

  • Wenn Sie Azure Site Recovery für eine VM aktivieren, um die Notfallwiederherstellung einzurichten, werden der Betriebssystem- und die lokalen Datenträger, die an VMs angefügt sind, an den Standort für die Notfallwiederherstellung repliziert. Während der Replikation werden Schreibvorgänge auf dem VM-Datenträger an ein Cachespeicherkonto in der Quellregion gesendet. Daten werden von dort aus in die Zielregion gesendet, und aus den Daten werden Wiederherstellungspunkte generiert. Wenn Sie während der Notfallwiederherstellung ein Failover für eine VM ausführen, wird ein Wiederherstellungspunkt genutzt, um die VM in der Zielregion wiederherzustellen. Azure Site Recovery unterstützt jedoch nicht alle in Azure verfügbaren Speichertypen. Weitere Informationen finden Sie unter Azure Site Recovery-Unterstützungsmatrix für Speicher.

  • Zusätzlich zu den an VMs angefügten verwalteten Datenträgern in Azure werden verschiedene native Azure-Speicherlösungen verwendet, um SAP-Anwendungen in Azure auszuführen. Der Ansatz für die Notfallwiederherstellung kann für jede Azure-Speicherlösung unterschiedlich sein, da nicht alle in Azure verfügbaren Speicherdienste von Azure Site Recovery unterstützt werden. Es folgt eine Liste der Speichertypen, die typischerweise für die SAP-Workload verwendet werden.

    Speichertyp Empfehlung für Notfallwiederherstellungsstrategie
    Managed Disk Azure Site Recovery
    NFS für Azure-Dateien (LRS oder ZRS) Benutzerdefiniertes Skript zum Replizieren von Daten zwischen zwei Standorten (z. B. rsync)
    NFS für Azure NetApp Files Verwenden der regionsübergreifenden Replikation von Azure NetApp Files-Volumes
    Freigegebener Azure-Datenträger (LRS oder ZRS) Benutzerdefinierte Lösung zum Replizieren von Daten zwischen zwei Standorten
    SMB für Azure-Dateien (LRS oder ZRS) Verwenden von RoboCopy zum Kopieren von Dateien zwischen zwei Standorten
    SMB für Azure NetApp Files Verwenden der regionsübergreifenden Replikation von Azure NetApp Files-Volumes

  • Bei benutzerdefinierten Speicherlösungen wie NFS-Clustern müssen Sie sicherstellen, dass die entsprechende Strategie für die Notfallwiederherstellung eingerichtet ist.

  • Verschiedene native Azure-Speicherdienste (wie Azure Files, Azure NetApp Files, freigegebener Azure-Datenträger) sind möglicherweise nicht in allen Regionen verfügbar. Um also nach einem Failover eine ähnliche SAP-Einrichtung in der Notfallwiederherstellungsregion zu haben, stellen Sie sicher, dass der entsprechende Dienst am Standort für die Notfallwiederherstellung geboten wird. Weitere Informationen finden Sie unter Azure-Produkte nach Region.

  • Wenn Sie für die Notfallwiederherstellung Verfügbarkeitszonen verwenden, beachten Sie die folgenden Punkte:

    • Azure NetApp Files wertet derzeit noch keine Zonen aus. Das Azure NetApp Files-Feature wird bisher nicht in allen Verfügbarkeitszonen in einer Azure-Region bereitgestellt. Es kann vorkommen, dass der Dienst Azure NetApp Files in der gewählten Verfügbarkeitszone für Ihre Notfallswiederherstellungsstrategie nicht verfügbar ist.
    • Die regionsübergreifende Replikation von Azure NetApp File-Volumes ist nur in festen Regionenpaaren und nicht zonenübergreifend möglich.

  • Wenn Sie Ihren Speicher mit Active Directory-Integration konfiguriert haben, sollten Sie eine ähnliche Einrichtung auch für das Speicherkonto am Standort für die Notfallwiederherstellung vornehmen.

  • Für freigegebene Azure-Datenträger ist Clustersoftware wie Windows Server Failover Cluster (WSFC) erforderlich, die die Kommunikation der Clusterknoten und Schreibsperren verwaltet. Um eine Notfallwiederherstellungsstrategie für freigegebene Azure-Datenträger zu verfolgen, sind daher auch am Standort für die Notfallwiederherstellung von der Clustersoftware verwaltete freigegebene Datenträger erforderlich. Sie können dann mithilfe eines Skripts Daten von einem an einen Cluster in der primären Region angefügten freigegebenen Datenträger auf einen an einen anderen Cluster in der Notwiederherstellungsregion angefügten freigegebenen Datenträger kopieren.

Nächste Schritte