Richtlinien für die Notfallwiederherstellung für SAP-Anwendungen
Zum Konfigurieren der Notfallwiederherstellung für SAP-Workloads in Azure müssen Sie den Prozess regelmäßig testen, optimieren und aktualisieren. Das Testen der Notfallwiederherstellung hilft dabei, die Reihenfolge der erforderlichen abhängigen Dienste zu ermitteln, bevor Sie das Failover zur Notfallwiederherstellung der SAP-Workload auslösen oder das System am sekundären Standort starten können. Organisationen verbinden ihre SAP-Systeme in der Regel mit den Diensten Active Directory (AD) und Domain Name System (DNS), damit sie wie gewünscht funktionieren. Wenn Sie die Notfallwiederherstellung für Ihre SAP-Workload einrichten, stellen Sie sicher, dass AD- und DNS-Dienste funktionieren, ehe Sie SAP- und andere Nicht-SAP-Systeme wiederherstellen, um sicherzustellen, dass die Anwendung einwandfrei funktioniert. Eine Anleitung zum Schutz von Active Directory und DNS finden Sie unter Schützen von Active Directory und DNS. Die in diesem Dokument beschriebenen Empfehlungen für Notfallwiederherstellung für SAP-Anwendungen sind lediglich abstrakter Natur. Sie müssen Ihre Notfallwiederherstellungsstrategie auf Grundlage Ihrer spezifischen Einrichtung entwerfen und das End-to-End-Szenario lückenlos dokumentieren.
Empfehlung zur Notfallwiederherstellung für SAP-Workloads
In der Regel sind in verteilten SAP NetWeaver-Systemen Central Services, Datenbank und freigegebener Speicher (NFS/SMB) Single Point of Failures (SPOF). Um die Auswirkungen verschiedener SPOF abzufedern, müssen Sie für diese Komponenten Redundanz einrichten. Die Redundanz dieser SPOF-Komponenten in der primären Region wird durch Konfiguration von Hochverfügbarkeit erreicht. Die Einrichtung der Komponente für Hochverfügbarkeit schützt das SAP-System vor lokalen Ausfällen oder Katastrophen. Um jedoch SAP-Anwendungen vor geografisch verteilten Katastrophen zu schützen, muss eine Notfallwiederherstellungsstrategie für alle SAP-Komponenten implementiert werden.
Für auf virtuellen Computern betriebene SAP-Systeme können Sie mit Azure Site Recovery einen Plan für die Notfallwiederherstellung erstellen. Es folgt der empfohlene Notfallwiederherstellungsansatz für alle Komponenten eines SAP-Systems. Eigenständige nicht zu NetWeaver gehörige SAP-Engines wie TREX und nicht von SAP stammende Anwendungen werden in diesem Dokument nicht behandelt.
| Komponenten | Empfehlung |
|---|---|
| SAP Web Dispatcher | Replizieren einer VM mithilfe von Azure Site Recovery |
| SAP Central Services | Replizieren einer VM mithilfe von Azure Site Recovery |
| SAP-Anwendungsserver | Replizieren einer VM mithilfe von Azure Site Recovery |
| SAP-Datenbank | Verwenden der von der Datenbank angebotenen Replikationsmethode |
| Freigegebener Speicher | Replizieren von Inhalten mithilfe der je nach Speichertyp geeigneten Methode |
SAP Web Dispatcher
Die Komponente SAP Web Dispatcher dient zum Lastenausgleich von SAP-Datenverkehr unter SAP-Anwendungsservern. Sie haben verschiedene Optionen, um Hochverfügbarkeit von SAP Web Dispatcher in der primären Region zu erreichen. Weitere Informationen zu dieser Option finden Sie unter Hochverfügbarkeit von SAP Web Dispatcher und Einrichtung für Hochverfügbarkeit von SAP Web Dispatcher in Azure.
- Option 1: Hochverfügbarkeit mithilfe einer Clusterlösung.
- Option 2: Hochverfügbarkeit mithilfe paralleler SAP Web Dispatcher-Instanzen.
Um die Notfallwiederherstellung für hochverfügbare SAP Web Dispatcher-Instanzen in der primären Region zu ermöglichen, steht Ihnen Azure Site Recovery zur Verfügung. Für parallele Web Dispatcher (Option 2), die in der primären Region ausgeführt werden, können Sie Azure Site Recovery konfigurieren, um Notfallwiederherstellung bereitzustellen. Wenn Sie SAP Web Dispatcher jedoch in der primären Region mit Option 1 konfiguriert haben, müssen Sie nach dem Failover einige zusätzliche Änderungen vornehmen, um in der Notwiederherstellungsregion ähnliche Hochverfügbarkeit zu erreichen. Die Konfiguration von Hochverfügbarkeit für SAP Web Dispatcher mithilfe einer Clusterlösung erfolgt analog zu SAP Central Services. Befolgen Sie die gleichen Leitlinien wie für SAP Central Services.
SAP Central Services
Die zentralen SAP-Dienste mit Warteschlangeneinreihungs- und Nachrichtenserver gehören zu den Single Points of Failure (SPOF) Ihrer SAP-Anwendung. In einem SAP-System kann es nur eine solche Instanz geben, die für Hochverfügbarkeit konfiguriert werden kann. Lesen Sie Hochverfügbarkeit für SAP Central Services, um die verschiedenen Hochverfügbarkeitslösungen für die SAP-Workload in Azure zu verstehen.
Durch Konfiguration von Hochverfügbarkeit für SAP Central Services werden Ressourcen und Prozesse vor lokalen Vorfällen geschützt. Mit Azure Site Recovery können Sie eine Notfallwiederherstellung für SAP Central Services erreichen. Azure Site Recovery repliziert VMs und die angefügten verwalteten Datenträger, es gibt aber zusätzliche Überlegungen für die Notfallwiederherstellungsstrategie. Weitere Informationen finden Sie im folgenden Abschnitt basierend auf dem Betriebssystem für SAP Central Services.
Für das SAP-System wird Redundanz der SPOF-Komponente in der primären Region durch Konfigurieren von Hochverfügbarkeit erreicht. Um eine ähnliche Hochverfügbarkeitseinrichtung in der Notfallwiederherstellungsregion nach dem Failover zu erreichen, müssen Sie zusätzliche Punkte wie die Neukonfiguration des Clusters, die Verfügbarkeit der gemeinsam genutzten SAP-Verzeichnisse sowie die Replikation von VMs und angefügten verwalteten Datenträgern an den Standort für die Notfallwiederherstellung mit Azure Site Recovery berücksichtigen. Unter Linux kann Hochverfügbarkeit der SAP-Anwendung mithilfe der Clusterlösung Pacemaker erreicht werden. Das folgende Diagramm zeigt die verschiedenen Komponenten, die beim Konfigurieren von Hochverfügbarkeit für SAP Central Services mit Pacemaker beteiligt sind. Jede Komponente muss dahingehend berücksichtigt werden, dass am Standort für die Notfallwiederherstellung eine ähnlich Hochverfügbarkeit gewährleistet ist. Wenn Sie SAP Web Dispatcher mit der Clusterlösung Pacemaker konfiguriert haben, gelten auch ähnliche Aspekte.
Interner Lastenausgleich
Azure Site Recovery repliziert VMs an den Standort für die Notfallwiederherstellung, aber der Azure-Lastenausgleich wird nicht repliziert. Sie müssen vor bzw. nach dem Failover am Standort für die Notfallwiederherstellung einen separaten internen Lastenausgleich einrichten. Wenn Sie im Voraus einen internen Lastenausgleich erstellen, legen Sie einen leeren Back-End-Pool an, dem Sie nach dem Failoverereignis VMs hinzufügen.
Die Clusterlösung Pacemaker
Die Konfigurationen eines Pacemaker-Clusters befinden sich in lokalen Dateien von VMs, die mit Azure Site Recovery zum Standort für die Notfallwiederherstellung repliziert werden. Die vordefinierte Pacemaker-Clusterkonfiguration funktioniert nach dem Failover auf den VMs nicht im standardmäßigen Zustand. Damit die Lösung funktioniert, ist eine zusätzliche Neukonfiguration des Clusters erforderlich.
Lesen Sie diese Blogs, um mehr über die Neukonfiguration von Pacemaker-Clustern in der Notwiederherstellungsregion zu erfahren, und zwar basierend auf dem Typ Ihres Speicher- und Fencingmechanismus.
- Failover eines SAP ASCS/ERS-Hochverfügbarkeitsclusters mit SBD-Gerät (mithilfe des iSCSI-Zielservers) in die Notfallwiederherstellungsregion mithilfe von Azure Site Recovery.
- Failover des SAP ASCS-Hochverfügbarkeitsclusters (im Linux-Betriebssystem) in die Notfallwiederherstellungsregion mithilfe von Azure Site Recovery.
Freigegebene SAP-Verzeichnisse für Linux
Für Hochverfügbarkeit von SAP NetWeaver oder ABAP-Plattform wird der Enqueue-Replikationsserver genutzt, um Redundanz auf Anwendungsebene für den Enqueue-Service des SAP-Systems mit der Konfiguration des Pacemaker-Clusters zu erreichen. Für Hochverfügbarkeit von SAP Central Services (ASCS und ERS) werden NFS-Mounts genutzt. Sie müssen also sicherstellen, dass SAP-Binärdateien und -Daten in diesen NFS-Mounts zum Standort für die Notfallwiederherstellung repliziert werden. Azure Site Recovery repliziert VMs und angefügte lokale verwaltete Datenträger, aber keine NFS-Mounts. Abhängig vom Typ des NFS-Speichers, den Sie für die Einrichtung konfiguriert haben, müssen Sie sicherstellen, dass die Daten repliziert werden und am Standort für die Notfallwiederherstellung verfügbar sind. Die regionsübergreifende Replikationsmethodik für jeden Speicher wird auf abstrakter Ebene dargestellt. Sie müssen die genauen Schritte zur Replikation von Speicher bestätigen und Tests durchführen.
| Freigegebene SAP-Verzeichnisse | Regionsübergreifende Replikation |
|---|---|
| NFS in Azure Files | Benutzerdefiniert (z. B. rsync) |
| NFS in ANF | Ja (Regionsübergreifende Replikation) |
| NFS-Cluster | Benutzerdefiniert |
Tipp
Sie sollten einen der Erstanbieter-NFS-Dienste von Azure bereitstellen: NFS für Azure Files oder NFS ANF-Volumes zum Speichern freigegebener Daten in einem hoch verfügbaren SAP-System. Beachten Sie, dass wir SAP-Referenzarchitekturen in den Hintergrund stellen und NFS-Cluster verwenden.
Fencingmechanismus
Unabhängig vom Betriebssystem (SLES oder RHEL) und seiner Version benötigt Pacemaker einen gültigen Fencingmechanismus, damit die gesamte Lösung ordnungsgemäß funktioniert. Je nach Typ des Fencingmechanismus, den Sie in Ihrer primären Region eingerichtet haben, müssen Sie sicherstellen, dass derselbe Fencingmechanismus nach dem Failover am Standort für die Notfallwiederherstellung eingerichtet ist.
| Fencingmechanismus | Empfehlung für regionsübergreifende Notfallwiederherstellung |
|---|---|
| SBD mit iSCSI-Zielserver | Replizieren Sie den iSCSI-Zielserver mithilfe von Azure Site Recovery. Ermitteln Sie auf VMs für die Notfallwiederherstellung den iSCSI-Datenträger erneut. |
| Azure-Fence-Agent | Aktivieren Sie verwaltete Systemidentitäten (Managed System Identities, MSI) auf VMs für die Notfallwiederherstellung. Weisen Sie benutzerdefinierte Rollen zu. Aktualisieren Sie die Fence-Agent-Ressource im Cluster. |
| SBD mit freigegebenem Azure-Datenträger* | Konfigurieren Sie den neuen freigegebenen Azure-Datenträger in der Notfallwiederherstellungsregion. Fügen Sie nach dem Failover den freigegebenen Azure-Datenträger an die VMs für die Notfallwiederherstellung an.Richten Sie das SBD-Gerät für den freigegebenen Azure-Datenträger ein. |
*ZRS für freigegebene Azure-Datenträger ist in bestimmten Regionen verfügbar.
Hinweis
Zur Vereinfachung von Betrieb und Notfallwiederherstellung empfehlen wir, denselben Fencingmechanismus für sowohl die primäre Region als auch die Notwiederherstellungsregion zu verwenden. Es wird davon abgeraten, nach einem Failover zum Standort für die Notfallwiederherstellung einen anderen Fencingmechanismus zu verwenden.
SAP-Anwendungsserver
In der primären Region wird die Redundanz der SAP-Anwendungsserver durch Installation von Instanzen in mehreren VMs erreicht. Um die Notfallwiederherstellung für SAP-Anwendungsserver zu ermöglichen, kann Azure Site Recovery für jede Anwendungsserver-VM eingerichtet werden. Für freigegebene Speicher (Transportdateisystem, Dateisystem für Schnittstellendaten), die an die Anwendungsserver angefügt sind, befolgen Sie die entsprechenden Notfallwiederherstellungsverfahren basierend auf dem Typ des freigegebenen Speichers.
SAP-Datenbankserver
Verwenden Sie für Datenbanken mit SAP-Workload die native DBMS-Replikationstechnologie, um die Notfallwiederherstellung zu konfigurieren. 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. Die Replikationstechnologie ist für jede Datenbank anders. Befolgen Sie daher die Leitlinien für die jeweilige Datenbank. Die folgende Tabelle zeigt die Liste der Datenbanken für SAP-Workloads und die entsprechende Empfehlung für die Notfallwiederherstellung.
| Datenbank | Empfehlung für die Notfallwiederherstellung |
|---|---|
| SAP HANA | HANA-Systemreplikation (HSR) |
| Oracle | Oracle Data Guard (FarSync) |
| IBM DB2 | Hochverfügbarkeit und Notfallwiederherstellung (HADR) |
| Microsoft SQL | Microsoft SQL Always On |
| SAP ASE | ASE HADR Always On |
| SAP MaxDB | Standbydatenbank |
Für eine kostenoptimierte Lösung können Sie sogar die Sicherungs- und Wiederherstellungsoption als Notfallwiederherstellungsstrategie für Datenbanken nutzen.
Sichern und Wiederherstellen
Sicherung und Wiederherstellung ist eine andere mögliche Lösung, um eine Notfallwiederherstellung für Ihre SAP-Workloads zu erreichen, wenn das geschäftliche RTO und RPO nicht kritisch sind. Sie können mit Azure Backup einen cloudbasierten Sicherungsdienst nutzen, um Kopien verschiedener Komponenten Ihrer SAP-Workload wie virtuelle Computer, verwaltete Datenträger und unterstützte Datenbanken zu erstellen. Weitere Informationen zu den allgemeinen Supporteinstellungen und Einschränkungen für Azure Backup-Szenarien und -Bereitstellungen finden Sie unter Unterstützungsmatrix für Azure Backup.
| Dienste | Komponente | Unterstützung von Azure Backup |
|---|---|---|
| Compute | Virtuelle Azure-Computer | Unterstützt |
| Storage | Azure Managed Disks einschließlich freigegebener Datenträger | Unterstützt |
| Storage | Azure-Dateifreigabe – SMB (Standard oder Premium) | Unterstützt |
| Storage | Azure-Blobs | Unterstützt |
| Storage | Azure-Dateifreigabe – NFS (Standard oder Premium) | Nicht unterstützt |
| Storage | Azure NetApp Files | Nicht unterstützt |
| Datenbank | SAP HANA-Datenbank in Azure-VMs | Unterstützt |
| Datenbank | SQL Server in Azure-VMs | Unterstützt |
| Datenbank | Oracle | Unterstützt* |
| Datenbank | IBM DB2, SAP ASE | Nicht unterstützt |
Hinweis
*Azure Backup unterstützt Oracle-Datenbank mit Azure-VM-Sicherung für datenbankkonsistente Momentaufnahmen.
Azure Backup unterstützt nicht alle Azure-Speicher und -Datenbanken, die für SAP-Workloads verwendet werden.
Azure Backup speichert Sicherungen im Tresor des Wiederherstellungsdiensts, der Ihre Daten basierend auf dem ausgewählten Replikationstyp (LRS, ZRS oder GRS) repliziert. Für georedundanten Speicher (GRS) werden Ihre Sicherungsdaten in eine gekoppelte sekundäre Region repliziert. Bei aktiviertem Feature für die regionsübergreifende Wiederherstellung können Sie Daten des unterstützten Verwaltungstyps in der sekundären Region wiederherstellen.
Sicherung und Wiederherstellung ist ein herkömmlicher, kostenoptimierter Ansatz, der jedoch mit einem höheren RTO einhergeht. Bei einem Failover in die Notwiederherstellungsregion müssen Sie alle Anwendungen aus der Sicherung wiederherstellen. Sie müssen also den Bedarf Ihres Unternehmens analysieren und eine entsprechende Notfallwiederherstellungsstrategie ausarbeiten.