Hochverfügbarkeit für SAP NetWeaver auf Azure-VMs unter Red Hat Enterprise Linux für SAP-Anwendungen: Multi-SID
In diesem Artikel wird beschrieben, wie Sie mehrere hochverfügbare SAP NetWeaver-Systeme (Multi-SID) in einem Cluster mit zwei Knoten auf Azure-VMs mit Red Hat Enterprise Linux für SAP-Anwendungen bereitstellen.
In den Beispielkonfigurationen werden drei SAP NetWeaver 7.50-Systeme in einem einzelnen Cluster mit zwei Knoten und Hochverfügbarkeit bereitgestellt. Die SIDs der SAP-Systeme lauten:
NW1
: ASCS-Instanznummer 00 und virtueller Hostnamemsnw1ascs
. ERS-Instanznummer 02 und virtueller Hostnamemsnw1ers
.NW2
: ASCS-Instanznummer 10 und virtueller Hostnamemsnw2ascs
. ERS-Instanznummer 12 und virtueller Hostnamemsnw2ers
.NW3
: ASCS-Instanznummer 20 und virtueller Hostnamemsnw3ascs
. ERS-Instanznummer 22 und virtueller Hostnamemsnw3ers
.
Die Datenbankebene und die Bereitstellung der SAP-NFS-Freigaben werden in diesem Artikel nicht behandelt.
In den Beispielen in diesem Artikel wird das Azure NetApp Files-Volume sapMSID
für die NFS-Freigaben verwendet, wobei davon ausgegangen wird, dass das Volume bereits bereitgestellt wurde. In den Beispielen wird davon ausgegangen, dass das Azure NetApp Files-Volume mit dem NFSv3-Protokoll bereitgestellt wurde. Es werden die folgenden Dateipfade für die Clusterressourcen für die ASCS- und ERS-Instanzen der SAP-Systeme NW1
, NW2
und NW3
verwendet:
- volume sapMSID (nfs://10.42.0.4/sapmntNW1)
- volume sapMSID (nfs://10.42.0.4/usrsapNW1ascs)
- volume sapMSID (nfs://10.42.0.4/usrsapNW1sys)
- volume sapMSID (nfs://10.42.0.4/usrsapNW1ers)
- volume sapMSID (nfs://10.42.0.4/sapmntNW2)
- volume sapMSID (nfs://10.42.0.4/usrsapNW2ascs)
- volume sapMSID (nfs://10.42.0.4/usrsapNW2sys)
- volume sapMSID (nfs://10.42.0.4/usrsapNW2ers)
- volume sapMSID (nfs://10.42.0.4/sapmntNW3)
- volume sapMSID (nfs://10.42.0.4/usrsapNW3ascs)
- volume sapMSID (nfs://10.42.0.4/usrsapNW3sys)
- volume sapMSID (nfs://10.42.0.4/usrsapNW3ers)
Bevor Sie beginnen, lesen Sie die folgenden SAP-Hinweise und Dokumente:
- SAP-Hinweis 1928533 mit folgenden Informationen:
- Liste der Azure-VM-Größen, die für die Bereitstellung von SAP-Software unterstützt werden
- Wichtige Kapazitätsinformationen für Azure-VM-Größen
- Unterstützte SAP-Software und Kombinationen aus Betriebssystem (OS) und Datenbank
- Erforderliche SAP-Kernelversion für Windows und Linux in Microsoft Azure
- Azure NetApp Files Dokumentation.
- SAP-Hinweis 2015553 enthält die Voraussetzungen für von SAP unterstützte SAP-Softwarebereitstellungen in Azure.
- SAP-Hinweis 2002167 enthält empfohlene Betriebssystemeinstellungen für Red Hat Enterprise Linux.
- SAP-Hinweis 2009879 enthält SAP HANA-Richtlinien für Red Hat Enterprise Linux.
- SAP-Hinweis 2178632 enthält ausführliche Informationen zu allen Überwachungsmetriken, die für SAP in Azure gemeldet werden.
- SAP-Hinweis 2191498 enthält die erforderliche SAP Host Agent-Version für Linux in Azure.
- SAP-Hinweis 2243692 enthält Informationen zur SAP-Lizenzierung unter Linux in Azure.
- SAP-Hinweis 1999351 enthält Informationen zur Problembehandlung für die Azure Enhanced Monitoring-Erweiterung für SAP.
- Das WIKI der SAP-Community enthält alle erforderlichen SAP-Hinweise für Linux.
- Azure Virtual Machines Planung und Implementierung für SAP auf Linux.
- Azure Virtual Machines Bereitstellung für SAP auf Linux.
- Azure Virtual Machines DBMS-Bereitstellung für SAP auf Linux.
- SAP NetWeaver im Pacemaker-Cluster
- Allgemeine RHEL-Dokumentation:
- Übersicht über das Hochverfügbarkeits-Add-On
- Verwaltung des Hochverfügbarkeits-Add-Ons
- Referenz zum Hochverfügbarkeits-Add-On
- Konfigurieren von ASCS/ERS für SAP NetWeaver mit eigenständigen Ressourcen in RHEL 7.5
- Konfigurieren von SAP S/4HANA ASCS/ERS mit eigenständigem Enqueue-Server 2 (ENSA2) in Pacemaker unter RHEL
- Azure-spezifische RHEL-Dokumentation:
- NetApp-SAP-Anwendungen in Microsoft Azure mithilfe von Azure NetApp Files
Übersicht
Die VMs im Cluster müssen groß genug sein, um im Fall eines Failovers alle Ressourcen ausführen zu können. Von jeder SAP-SID kann im Multi-SID-Hochverfügbarkeitscluster unabhängig ein Failover durchgeführt werden.
Für Hochverfügbarkeit benötigt SAP NetWeaver hochverfügbare Freigaben. In diesem Artikel werden Beispiele für die SAP-Freigaben vorgestellt, die auf Azure NetApp Files-NFS-Volumes bereitgestellt werden. Sie könnten die Freigaben stattdessen auch auf einem GlusterFS-Cluster mit Hochverfügbarkeit hosten, der von mehreren SAP-Systemen verwendet werden kann.
Wichtig
Die Unterstützung von Multi-SID-Clustering von SAP ASCS/ERS mit Red Hat Linux als Gastbetriebssystem auf virtuellen Azure-Computern ist auf fünf SAP-SIDs pro Cluster beschränkt. Durch jede neue SID erhöht sich die Komplexität. Eine Kombination aus SAP Enqueue Replication Server 1 und Enqueue Replication Server 2 im gleichen Cluster wird nicht unterstützt. Als Multi-SID-Clustering wird die Installation mehrerer SAP ASCS/ERS-Instanzen mit verschiedenen SIDs in einem Pacemaker-Cluster beschrieben. Aktuell wird Multi-SID-Clustering nur für ASCS/ERS unterstützt.
Tipp
Das Multi-SID-Clustering von SAP ASCS/ERS ist eine Lösung mit höherer Komplexität. Dadurch erhöht sich die Komplexität bei der Implementierung. Wartungsaktivitäten wie etwa das Patchen des Betriebssystems sind außerdem mit einem höheren Verwaltungsaufwand verbunden. Bevor Sie mit der eigentlichen Implementierung beginnen, empfiehlt es sich, die Bereitstellung und alle beteiligten Komponenten wie virtuelle Computer, NFS-Einbindungen, VIPs, Lastenausgleichskonfigurationen und Ähnliches sorgfältig zu planen.
SAP NetWeaver ASCS, SAP NetWeaver SCS und SAP NetWeaver ERS verwenden einen virtuellen Hostnamen und virtuelle IP-Adressen. Für die Verwendung einer virtuellen IP-Adresse ist in Azure ein Lastenausgleich erforderlich. Es wird empfohlen, Load Balancer Standard zu verwenden.
- Front-End-IP-Adressen für ASCS: 10.3.1.50 (NW1), 10.3.1.52 (NW2) und 10.3.1.54 (NW3)
- Front-End-IP-Adressen für ERS: 10.3.1.51 (NW1), 10.3.1.53 (NW2) und 10.3.1.55 (NW3)
- Testport 62000 für NW1 ASCS, 62010 für NW2 ASCS und 62020 für NW3 ASCS
- Testport 62102 für NW1 ASCS, 62112 für NW2 ASCS und 62122 für NW3 ASCS
Hinweis
Wenn VMs ohne öffentliche IP-Adressen im Back-End-Pool einer internen Azure Load Balancer Standard-Instanz (ohne öffentliche IP-Adresse) platziert werden, liegt keine ausgehende Internetverbindung vor, sofern nicht in einer zusätzlichen Konfiguration das Routing an öffentliche Endpunkte zugelassen wird. Ausführliche Informationen zum Erreichen ausgehender Konnektivität finden Sie unter Public endpoint connectivity for Virtual Machines using Azure Standard Load Balancer in SAP high-availability scenarios (Konnektivität mit öffentlichen Endpunkten für virtuelle Computer mithilfe von Azure Load Balancer Standard in SAP-Szenarien mit Hochverfügbarkeit).
Wichtig
Aktivieren Sie keine TCP-Zeitstempel auf Azure-VMs hinter Azure Load Balancer. Die Aktivierung von TCP-Zeitstempeln führt dazu, dass die Health Probes fehlschlagen. Legen Sie den Parameter net.ipv4.tcp_timestamps
auf 0 (null) fest. Weitere Informationen finden Sie unter Lastenausgleichs-Integritätstests.
SAP-Freigaben
SAP NetWeaver benötigt freigegebenen Speicher für den Transport, das Profilverzeichnis und Ähnliches. Ein hoch verfügbares SAP-System setzt hoch verfügbare Freigaben voraus. Sie müssen sich für eine Architektur für Ihre SAP-Freigaben entscheiden. Die Freigaben können in NFS-Volumes für Azure NetApp Files bereitgestellt werden. Azure NetApp Files bietet integrierte Hochverfügbarkeit für die SAP-NFS-Freigaben.
Eine weitere Möglichkeit besteht darin, GlusterFS auf virtuellen Azure-Computern unter Red Hat Enterprise Linux für SAP NetWeaver zu erstellen, die zwischen mehreren SAP-Systemen freigegeben werden können.
Bereitstellen des ersten SAP-Systems im Cluster
Nachdem Sie sich für Ihre Architektur für die SAP-Freigaben entschieden haben, stellen Sie das erste SAP-System im Cluster gemäß der entsprechenden Dokumentation bereit.
- Dokumentation bei Verwendung von Azure NetApp Files-NFS-Volumes: Hochverfügbarkeit für SAP NetWeaver auf Azure-VMs unter Red Hat Enterprise Linux mit Azure NetApp Files für SAP-Anwendungen
- Wenn Sie den GlusterFS-Cluster verwenden, befolgen Sie die Anweisungen unter GlusterFS auf Azure-VMs unter Red Hat Enterprise Linux für SAP NetWeaver.
In den aufgeführten Artikeln erfahren Sie Schritt für Schritt, wie Sie die erforderliche Infrastruktur vorbereiten, den Cluster erstellen und das Betriebssystem für die Ausführung der SAP-Anwendung vorbereiten.
Tipp
Testen Sie nach dem Bereitstellen des ersten Systems immer die Failoverfunktion des Clusters, bevor Sie dem Cluster weitere SAP-SIDs hinzufügen. Dadurch wissen Sie, ob die Clusterfunktion funktioniert, bevor die Komplexität des Clusters durch zusätzliche SAP-Systeme erhöht wird.
Bereitstellen zusätzlicher SAP-Systeme im Cluster
In diesem Beispiel wird davon ausgegangen, dass das System NW1
bereits im Cluster bereitgestellt wurde. Im Beispiel wird gezeigt, wie die SAP-Systeme NW2
und NW3
im Cluster bereitgestellt werden.
Die folgenden Elemente haben eines der folgenden Präfixe:
- [A]: gilt für alle Knoten
- [1]: gilt nur für Knoten 1
- [2]: gilt nur für Knoten 2
Voraussetzungen
Wichtig
Bevor Sie die Schritte zum Bereitstellen zusätzlicher SAP-Systeme im Cluster ausführen, müssen Sie das erste SAP-System im Cluster bereitstellen. Einige Schritte sind nur während der Bereitstellung des ersten Systems erforderlich.
In diesem Artikel wird Folgendes vorausgesetzt:
- Der Pacemaker-Cluster ist bereits konfiguriert und wird ausgeführt.
- Mindestens ein SAP-System (ASCS/ERS-Instanz) wurde bereits bereitgestellt und wird im Cluster ausgeführt.
- Die Failoverfunktion des Clusters wurde getestet.
- Die NFS-Freigaben für alle SAP-Systeme wurden bereitgestellt.
Vorbereiten der SAP NetWeaver-Installation
Fügen Sie der vorhandenen Azure Load Balancer-Instanz die Konfiguration für das neu bereitgestellte System (
NW2
undNW3
) hinzu. Eine entsprechende Anleitung finden Sie unter Manuelles Bereitstellen von Azure Load Balancer über das Azure-Portal. Passen Sie die IP-Adressen, Integritätstestports und Lastenausgleichsregeln für Ihre Konfiguration an.[A] Richten Sie die Namensauflösung für die zusätzlichen SAP-Systeme ein. Sie können entweder einen DNS-Server verwenden oder die Datei /etc/hosts auf allen Knoten ändern. In diesem Beispiel wird die Verwendung der Datei /etc/hosts veranschaulicht. Passen Sie die IP-Adressen und die Hostnamen an Ihre Umgebung an.
sudo vi /etc/hosts # IP address of the load balancer frontend configuration for NW2 ASCS 10.3.1.52 msnw2ascs # IP address of the load balancer frontend configuration for NW3 ASCS 10.3.1.54 msnw3ascs # IP address of the load balancer frontend configuration for NW2 ERS 10.3.1.53 msnw2ers # IP address of the load balancer frontend configuration for NW3 ERS 10.3.1.55 msnw3ers
[A] Erstellen Sie die freigegebenen Verzeichnisse für die SAP-Systeme
NW2
undNW3
, die Sie im Cluster bereitstellen.sudo mkdir -p /sapmnt/NW2 sudo mkdir -p /usr/sap/NW2/SYS sudo mkdir -p /usr/sap/NW2/ASCS10 sudo mkdir -p /usr/sap/NW2/ERS12 sudo mkdir -p /sapmnt/NW3 sudo mkdir -p /usr/sap/NW3/SYS sudo mkdir -p /usr/sap/NW3/ASCS20 sudo mkdir -p /usr/sap/NW3/ERS22 sudo chattr +i /sapmnt/NW2 sudo chattr +i /usr/sap/NW2/SYS sudo chattr +i /usr/sap/NW2/ASCS10 sudo chattr +i /usr/sap/NW2/ERS12 sudo chattr +i /sapmnt/NW3 sudo chattr +i /usr/sap/NW3/SYS sudo chattr +i /usr/sap/NW3/ASCS20 sudo chattr +i /usr/sap/NW3/ERS22
[A] Fügen Sie die Bereitstellungseinträge für die Dateisysteme /sapmnt/SID und /usr/sap/SID/SYS der zusätzlichen SAP-Systeme hinzu, die Sie im Cluster bereitstellen. In diesem Beispiel sind dies
NW2
undNW3
.Aktualisieren Sie die Datei
/etc/fstab
mit den Dateisystemen für die zusätzlichen SAP-Systeme, die Sie im Cluster bereitstellen.- Wenn Sie Azure NetApp Files verwenden, befolgen Sie die Anweisungen unter Hochverfügbarkeit von Azure-VMs für SAP NetWeaver unter Red Hat Enterprise Linux mit Azure NetApp Files.
- Wenn Sie GlusterFS-Cluster verwenden, befolgen Sie die Anweisungen unter Hochverfügbarkeit von Azure-VMs für SAP NetWeaver unter Red Hat Enterprise Linux.
Installieren von ASCS/ERS
Erstellen Sie die virtuelle IP-Adresse und die Integritätstest-Clusterressourcen für die ASCS-Instanzen der zusätzlichen SAP-Systeme, die Sie im Cluster bereitstellen. In diesem Beispiel gilt für
NW2
undNW3
ASCS, wobei NFS auf Azure NetApp Files-Volumes mit dem NFSv3-Protokoll verwendet wird.sudo pcs resource create fs_NW2_ASCS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW2ascs' \ directory='/usr/sap/NW2/ASCS10' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW2_ASCS sudo pcs resource create vip_NW2_ASCS IPaddr2 \ ip=10.3.1.52 \ --group g-NW2_ASCS sudo pcs resource create nc_NW2_ASCS azure-lb port=62010 \ --group g-NW2_ASCS sudo pcs resource create fs_NW3_ASCS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW3ascs' \ directory='/usr/sap/NW3/ASCS20' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW3_ASCS sudo pcs resource create vip_NW3_ASCS IPaddr2 \ ip=10.3.1.54 \ --group g-NW3_ASCS sudo pcs resource create nc_NW3_ASCS azure-lb port=62020 \ --group g-NW3_ASCS
Vergewissern Sie sich, dass der Cluster ordnungsgemäß funktioniert und alle Ressourcen gestartet wurden. Es ist nicht wichtig, auf welchem Knoten die Ressourcen ausgeführt werden.
[1] Installieren Sie SAP NetWeaver ASCS.
Installieren Sie SAP NetWeaver ASCS als Root-Benutzer. Verwenden Sie dabei einen virtuellen Hostnamen, der der IP-Adresse der Front-End-Konfiguration für den Lastenausgleich für die ASCS-Instanz zugeordnet ist. Beim System
NW2
setzt sich der virtuelle Hostname beispielsweise ausmsnw2ascs
,10.3.1.52
und der für den Lastenausgleichstest verwendeten Instanznummer (z. B.10
) zusammen. Beim SystemNW3
setzt sich der virtuelle Hostname ausmsnw3ascs
,10.3.1.54
und der für den Lastenausgleichstest verwendeten Instanznummer (z. B20
) zusammen. Notieren Sie sich, auf welchem Clusterknoten Sie ASCS für jede SAP-SID installiert haben.Sie können den
sapinst
-ParameterSAPINST_REMOTE_ACCESS_USER
verwenden, um anderen Benutzer*innen als root das Herstellen einer Verbindung mit sapinst zu ermöglichen. Mithilfe des ParametersSAPINST_USE_HOSTNAME
können Sie SAP unter Verwendung eines virtuellen Hostnamens installieren.# Allow access to SWPM. This rule is not permanent. If you reboot the machine, you have to run the command again sudo firewall-cmd --zone=public --add-port=4237/tcp sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostname
Falls bei der Installation kein Unterordner unter /usr/sap/<SID>/ASCS<Instanznr.> erstellt werden kann, legen Sie den Besitzer auf „<sid>adm“ und die Gruppe auf „sapsys“ des Ordners „ASCS<Instanznr.>“ fest, und wiederholen Sie den Vorgang.
[1] Erstellen Sie eine virtuelle IP-Adresse sowie Integritätstest-Clusterressourcen für die ERS-Instanz des zusätzlichen SAP-Systems, das Sie im Cluster bereitstellen. In diesem Beispiel gilt für
NW2
undNW3
ERS, wobei NFS auf Azure NetApp Files-Volumes mit dem NFSv3-Protokoll verwendet wird.sudo pcs resource create fs_NW2_AERS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW2ers' \ directory='/usr/sap/NW2/ERS12' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW2_AERS sudo pcs resource create vip_NW2_AERS IPaddr2 \ ip=10.3.1.53 \ --group g-NW2_AERS sudo pcs resource create nc_NW2_AERS azure-lb port=62112 \ --group g-NW2_AERS sudo pcs resource create fs_NW3_AERS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW3ers' \ directory='/usr/sap/NW3/ERS22' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW3_AERS sudo pcs resource create vip_NW3_AERS IPaddr2 \ ip=10.3.1.55 \ --group g-NW3_AERS sudo pcs resource create nc_NW3_AERS azure-lb port=62122 \ --group g-NW3_AERS
Vergewissern Sie sich, dass der Cluster ordnungsgemäß funktioniert und alle Ressourcen gestartet wurden.
Stellen Sie als Nächstes sicher, dass die Ressourcen der neu erstellten ERS-Gruppe auf dem Clusterknoten ausgeführt werden, und zwar gegenüber dem Clusterknoten, auf dem die ASCS-Instanz für das gleiche SAP-System installiert wurde. Wenn also beispielsweise die NW2-ASCS-Instanz auf
rhelmsscl1
installiert wurde, muss die NW2-ERS-Gruppe aufrhelmsscl2
ausgeführt werden. Sie können die NW2-ERS-Gruppe zurhelmsscl2
migrieren, indem Sie den folgenden Befehl für eine der Clusterressourcen in der Gruppe ausführen:pcs resource move fs_NW2_AERS rhelmsscl2
[2] Installieren Sie SAP NetWeaver ERS.
Installieren Sie SAP NetWeaver ERS als Root-Benutzer auf dem anderen Knoten. Verwenden Sie dabei einen virtuellen Hostnamen, der der IP-Adresse der Front-End-Konfiguration für den Lastenausgleich für die ERS-Instanz zugeordnet ist. Beim System
NW2
setzt sich der virtuelle Hostname beispielsweise ausmsnw2ers
,10.3.1.53
und der für den Lastenausgleichstest verwendeten Instanznummer (z. B.12
) zusammen. Für das SystemNW3
setzt sich der virtuelle Hostname ausmsnw3ers
,10.3.1.55
und der für den Lastenausgleichstest verwendeten Instanznummer (z. B.22
) zusammen.Sie können den
sapinst
-ParameterSAPINST_REMOTE_ACCESS_USER
verwenden, um anderen Benutzer*innen als root das Herstellen einer Verbindung mit sapinst zu ermöglichen. Mithilfe des ParametersSAPINST_USE_HOSTNAME
können Sie SAP unter Verwendung eines virtuellen Hostnamens installieren.# Allow access to SWPM. This rule is not permanent. If you reboot the machine, you have to run the command again sudo firewall-cmd --zone=public --add-port=4237/tcp sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostname
Hinweis
Verwenden Sie SWPM SP 20 PL 05 oder höher. Bei niedrigeren Versionen werden die Berechtigungen nicht ordnungsgemäß festgelegt, sodass bei der Installation ein Fehler auftritt.
Falls bei der Installation kein Unterordner unter /usr/sap/<NW2>/ERS<Instanznr.> erstellt werden kann, legen Sie den Besitzer auf „<sid>adm“ und die Gruppe auf „sapsys“ des Ordners „ERS<Instanznr.>“ fest, und wiederholen Sie den Vorgang.
Wenn die ERS-Gruppe des neu bereitgestellten SAP-Systems zu einem anderen Clusterknoten migriert werden musste, vergessen Sie nicht, die Ortseinschränkung für die ERS-Gruppe zu entfernen. Die Einschränkung können Sie mithilfe des folgenden Befehls aufheben. Dieses Beispiel gilt für die SAP-Systeme
NW2
undNW3
. Sorgen Sie dafür, die temporären Einschränkungen für dieselbe Ressource aufzuheben, mit der Sie im Befehl die ERS-Clustergruppe verschoben haben.pcs resource clear fs_NW2_AERS pcs resource clear fs_NW3_AERS
[1] Passen Sie die ASCS/SCS- und ERS-Instanzprofile für die neu installierten SAP-Systeme an. Das im Folgenden gezeigte Beispiel gilt für
NW2
. Die ASCS/SCS- und ERS-Profile müssen für alle dem Cluster hinzugefügten SAP-Instanzen angepasst werden.ASCS/SCS-Profil
sudo vi /sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs # Change the restart command to a start command #Restart_Program_01 = local $(_EN) pf=$(_PF) Start_Program_01 = local $(_EN) pf=$(_PF) # Add the keep alive parameter, if using ENSA1 enque/encni/set_so_keepalive = TRUE
Stellen Sie sowohl für ENSA1 als auch für ENSA2 sicher, dass die
keepalive
-Parameter des Betriebssystems wie im SAP-Hinweis 1410736 beschrieben festgelegt sind.ERS-Profil
sudo vi /sapmnt/NW2/profile/NW2_ERS12_msnw2ers # Change the restart command to a start command #Restart_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID) Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID) # remove Autostart from ERS profile # Autostart = 1
[A] Aktualisieren Sie die Datei /usr/sap/sapservices.
Um den Start der Instanzen durch das sapinit-Startskript zu verhindern, müssen alle von Pacemaker verwalteten Instanzen in der Datei /usr/sap/sapservices auskommentiert werden. Das im Anschluss gezeigte Beispiel gilt für die SAP-Systeme
NW2
undNW3
.# Depending on whether the SAP Startup framework is integrated with systemd, you may observe below entries on the node for ASCS instances. You should comment out the line(s). # LD_LIBRARY_PATH=/usr/sap/NW2/ASCS10/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW2/ASCS10/exe/sapstartsrv pf=/usr/sap/NW2/SYS/profile/NW2_ASCS10_msnw2ascs -D -u nw2adm # LD_LIBRARY_PATH=/usr/sap/NW3/ASCS20/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW3/ASCS20/exe/sapstartsrv pf=/usr/sap/NW3/SYS/profile/NW3_ASCS20_msnw3ascs -D -u nw3adm # systemctl --no-ask-password start SAPNW2_10 # sapstartsrv pf=/usr/sap/NW2/SYS/profile/NW2_ASCS10_msnw2ascs # systemctl --no-ask-password start SAPNW3_20 # sapstartsrv pf=/usr/sap/NW3/SYS/profile/NW3_ASCS20_msnw3ascs # Depending on whether the SAP Startup framework is integrated with systemd, you may observe below entries on the node for ERS instances. You should comment out the line(s). #LD_LIBRARY_PATH=/usr/sap/NW2/ERS12/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW2/ERS12/exe/sapstartsrv pf=/usr/sap/NW2/ERS12/profile/NW2_ERS12_msnw2ers -D -u nw2adm #LD_LIBRARY_PATH=/usr/sap/NW3/ERS22/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW3/ERS22/exe/sapstartsrv pf=/usr/sap/NW3/ERS22/profile/NW3_ERS22_msnw3ers -D -u nw3adm # systemctl --no-ask-password start SAPNW2_12 # sapstartsrv pf=/usr/sap/NW2/ERS12/profile/NW2_ERS12_msnw2ers # systemctl --no-ask-password start SAPNW3_22 # sapstartsrv pf=/usr/sap/NW3/ERS22/profile/NW3_ERS22_msnw3ers
Wichtig
Mit dem auf systemd basierten SAP Startup Framework können SAP-Instanzen jetzt von systemd verwaltet werden. Die mindestens erforderliche Red Hat Enterprise Linux(RHEL)-Version ist RHEL 8 für SAP. Wie im SAP-Hinweis 3115048 beschrieben, führt eine Neuinstallation eines SAP-Kernels mit integrierter auf systemd basierter SAP Startup Framework-Unterstützung immer zu einer durch systemd gesteuerten SAP-Instanz. Nach einem SAP-Kernelupgrade einer vorhandenen SAP-Installation auf einen Kernel, der über die auf systemd basierte SAP Startup Framework-Unterstützung verfügt, müssen jedoch einige manuelle Schritte wie im SAP-Hinweis 3115048 dokumentiert ausgeführt werden, um die vorhandene SAP Startup-Umgebung in eine durch systemd gesteuerte zu konvertieren.
Bei der Verwendung von Red Hat HA-Diensten für SAP (Clusterkonfiguration) zum Verwalten von SAP-Anwendungsserverinstanzen wie SAP ASCS und SAP ERS sind zusätzliche Änderungen erforderlich, um die Kompatibilität zwischen dem SAPInstance-Ressourcen-Agent und dem neuen auf systemd basierten SAP-Startup-Framework sicherzustellen. Sobald die SAP-Anwendungsserverinstanzen installiert oder auf einen systemd-fähigen SAP-Kernel gemäß SAP-Hinweis 3115048 umgestellt wurden, müssen die in Red Hat KBA 6884531 genannten Schritte auf allen Clusterknoten erfolgreich abgeschlossen werden.
[1] Erstellen Sie die SAP-Clusterressourcen für das neu installierte SAP-System.
Je nachdem, ob Sie ein ENSA1- oder ENSA2-System ausführen, wählen Sie die entsprechende Registerkarte aus, um die Ressourcen für
NW2
undNW3
des SAP-Systems wie folgt zu definieren. SAP hat in SAP NetWeaver 7.52 Unterstützung für ENSA2 eingeführt, einschließlich Replikation. Ab der ABAP-Plattform 1809 wird ENSA2 standardmäßig installiert. Informationen zur ENSA2-Unterstützung finden Sie im SAP-Hinweis 2630416 für die Unterstützung von Enqueue-Server 2.Wenn Sie die Enqueue-Server-2-Architektur (ENSA2) verwenden, installieren Sie den Ressourcen-Agenten „resource-agents-sap-4.1.1-12.el7.x86_64“ oder neuer und definieren die Ressourcen für
NW2
undNW3
des SAP-Systems wie folgt:sudo pcs property set maintenance-mode=true sudo pcs resource create rsc_sap_NW2_ASCS10 SAPInstance \ InstanceName=NW2_ASCS10_msnw2ascs START_PROFILE="/sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 migration-threshold=1 failure-timeout=60 \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW2_ASCS sudo pcs resource meta g-NW2_ASCS resource-stickiness=3000 sudo pcs resource create rsc_sap_NW2_ERS12 SAPInstance \ InstanceName=NW2_ERS12_msnw2ers START_PROFILE="/sapmnt/NW2/profile/NW2_ERS12_msnw2ers" \ AUTOMATIC_RECOVER=false IS_ERS=true \ op monitor interval=20 on-fail=restart timeout=60 op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW2_AERS sudo pcs constraint colocation add g-NW2_AERS with g-NW2_ASCS -5000 sudo pcs constraint location rsc_sap_NW2_ASCS10 rule score=2000 runs_ers_NW2 eq 1 sudo pcs constraint order start g-NW2_ASCS then stop g-NW2_AERS kind=Optional symmetrical=false sudo pcs resource create rsc_sap_NW3_ASCS20 SAPInstance \ InstanceName=NW3_ASCS20_msnw3ascs START_PROFILE="/sapmnt/NW3/profile/NW3_ASCS20_msnw3ascs" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 migration-threshold=1 failure-timeout=60 \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW3_ASCS sudo pcs resource meta g-NW3_ASCS resource-stickiness=3000 sudo pcs resource create rsc_sap_NW3_ERS22 SAPInstance \ InstanceName=NW3_ERS22_msnw3ers START_PROFILE="/sapmnt/NW3/profile/NW2_ERS22_msnw3ers" \ AUTOMATIC_RECOVER=false IS_ERS=true \ op monitor interval=20 on-fail=restart timeout=60 op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW3_AERS sudo pcs constraint colocation add g-NW3_AERS with g-NW3_ASCS -5000 sudo pcs constraint location rsc_sap_NW3_ASCS20 rule score=2000 runs_ers_NW3 eq 1 sudo pcs constraint order start g-NW3_ASCS then stop g-NW3_AERS kind=Optional symmetrical=false sudo pcs property set maintenance-mode=false
Wenn Sie ein Upgrade von einer älteren Version durchführen und zu Enqueue Server 2 wechseln, lesen Sie den SAP-Hinweis 2641019.
Hinweis
Die Timeouts in der oben beschriebenen Konfiguration sind nur Beispiele und müssen möglicherweise an das spezifische SAP-Setup angepasst werden.
Stellen Sie sicher, dass der Clusterstatus gültig ist und alle Ressourcen gestartet sind. Es ist nicht wichtig, auf welchem Knoten die Ressourcen ausgeführt werden. Das folgende Beispiel zeigt den Clusterressourcenstatus, nachdem die SAP-Systeme
NW2
undNW3
dem Cluster hinzugefügt wurden:sudo pcs status # Online: [ rhelmsscl1 rhelmsscl2 ] # Full list of resources: # rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 # Resource Group: g-NW1_ASCS # fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW1_AERS # fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 # vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 # nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 # rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 # Resource Group: g-NW2_ASCS # fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW2_AERS # fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW3_ASCS # fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW3_AERS # fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl1
[A] Fügen Sie Firewallregeln für ASCS und ERS auf beiden Knoten hinzu. Das folgende Beispiel zeigt die Firewallregeln für beide SAP-Systeme –
NW2
undNW3
.# NW1 - ASCS sudo firewall-cmd --zone=public --add-port={62010,3210,3610,3910,8110,51013,51014,51016}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62010,3210,3610,3910,8110,51013,51014,51016}/tcp # NW2 - ERS sudo firewall-cmd --zone=public --add-port={62112,3212,3312,51213,51214,51216}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62112,3212,3312,51213,51214,51216}/tcp # NW3 - ASCS sudo firewall-cmd --zone=public --add-port={62020,3220,3620,3920,8120,52013,52014,52016}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62020,3220,3620,3920,8120,52013,52014,52016}/tcp # NW3 - ERS sudo firewall-cmd --zone=public --add-port={62122,3222,3322,52213,52214,52216}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62122,3222,3322,52213,52214,52216}/tcp
Fortsetzen der SAP-Installation
Führen Sie die folgenden Schritte aus, um die SAP-Installation abzuschließen:
- Vorbereiten Ihrer SAP NetWeaver-Anwendungsserver
- Installieren einer DBMS-Instanz
- Installieren eines primären SAP-Anwendungsservers
- Installieren mindestens einer zusätzlichen SAP-Anwendungsinstanz
Testen der Einrichtung des Multi-SID-Clusters
Bei den folgenden Tests handelt es sich um eine Auswahl von Testfällen aus den Best Practices-Leitfäden von Red Hat. Sie werden hier der Einfachheit halber bereitgestellt. Die vollständige Liste mit Clustertests finden Sie hier:
- Dokumentation bei Verwendung von Azure NetApp Files-NFS-Volumes: Hochverfügbarkeit für SAP NetWeaver auf Azure-VMs unter RHEL mit Azure NetApp Files für SAP-Anwendungen
- Dokumentation bei Verwendung von hoch verfügbarem
GlusterFS
: Hochverfügbarkeit für SAP NetWeaver auf Azure-VMs unter RHEL für SAP-Anwendungen.
Lesen Sie immer die Best Practices-Leitfäden von Red Hat, und führen Sie alle zusätzlichen Tests aus, die möglicherweise hinzugefügt wurden. Bei den bereitgestellten Tests handelt es sich um Tests in einem Multi-SID-Cluster mit zwei Knoten und drei installierten SAP-Systemen.
Migrieren Sie die ASCS-Instanz manuell. Das Beispiel zeigt die Migration der ASCS-Instanz für das SAP-System „NW3“.
Zustand der Ressource vor dem Starten des Tests:
Online: [ rhelmsscl1 rhelmsscl2 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl1
Führen Sie die folgenden Befehle als Root-Benutzer aus, um die NW3-ASCS-Instanz zu migrieren.
pcs resource move rsc_sap_NW3_ASCS200 # Clear temporary migration constraints pcs resource clear rsc_sap_NW3_ASCS20 # Remove failed actions for the ERS that occurred as part of the migration pcs resource cleanup rsc_sap_NW3_ERS22
Zustand der Ressource nach dem Test:
Online: [ rhelmsscl1 rhelmsscl2 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl2
Simulieren Sie einen Knotenabsturz.
Zustand der Ressource vor dem Starten des Tests:
Online: [ rhelmsscl1 rhelmsscl2 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl2
Führen Sie den folgenden Befehl als root-Benutzer auf einem Knoten aus, auf dem mindestens eine ASCS-Instanz ausgeführt wird. In diesem Beispiel wird der Befehl auf
rhelmsscl1
ausgeführt, auf dem die ASCS-Instanzen fürNW1
,NW2
undNW3
ausgeführt werden.echo c > /proc/sysrq-trigger
Der Status nach dem Test und nach dem Neustart des abgestürzten Knotens sollte den folgenden Ergebnissen ähneln:
Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl2 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl1
Wenn es Meldungen zu fehlerhaften Ressourcen gibt, bereinigen Sie den Status dieser Ressourcen. Beispiel:
pcs resource cleanup rsc_sap_NW1_ERS02
Nächste Schritte
- Azure Virtual Machines – Planung und Implementierung für SAP
- Azure Virtual Machines – Bereitstellung für SAP
- Azure Virtual Machines – DBMS-Bereitstellung für SAP
Informationen zur Erzielung von Hochverfügbarkeit und zur Planung der Notfallwiederherstellung für SAP HANA auf Azure-VMs finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure Virtual Machines (VMs).