Haute disponibilité pour SAP NetWeaver sur des machines virtuelles Azure sur SUSE Linux Enterprise Server pour les applications SAP multi-SID

Cet article explique comment déployer plusieurs systèmes SAP NetWeaver ou S/4HANA hautement disponibles (multi-SID) dans un cluster à deux nœuds sur des machines virtuelles Azure avec SUSE Linux Enterprise Server pour les applications SAP. Le clustering multi-SID vous permet d’exécuter plusieurs instances SAP avec différents identificateurs système sur le même cluster Pacemaker, en optimisant l’utilisation des ressources tout en conservant la haute disponibilité.

Dans les exemples de configurations, les commandes d’installation et etc., trois systèmes SAP NetWeaver 7.50 sont déployés dans un cluster à haute disponibilité à deux nœuds unique. Les SID des systèmes SAP sont les suivants :

NW1 : Numéro d’instance ASCS 00 et nom d’hôte virtuel msnw1ascs ; numéro d’instance ERS 02 et nom d’hôte virtuel msnw1ers.
NW2 : Numéro d’instance ASCS 10 et nom d’hôte virtuel msnw2ascs ; numéro d’instance ERS 12 et nom d’hôte virtuel msnw2ers.
NW3 : Numéro d’instance ASCS 20 et nom d’hôte virtuel msnw3ascs ; numéro d’instance ERS 22 et nom d’hôte virtuel msnw3ers.

Cet article ne couvre pas la couche de base de données et le déploiement des partages NFS SAP. Dans les exemples de cet article, nous utilisons des noms virtuels nw2-nfs pour les partages NW2 NFS et nw3-nfs pour les partages NW3 NFS, en supposant qu’un cluster NFS a été déployé.

Avant de commencer, reportez-vous aux notes et documents SAP suivants :

Note SAP 1928533, qui contient :
- Liste des tailles de machine virtuelle Azure prises en charge pour le déploiement de logiciels SAP
- Informations importantes sur la capacité pour les tailles de machine virtuelle Azure
- Combinaisons de logiciels SAP, de systèmes d’exploitation et de bases de données prises en charge
- Version requise du noyau SAP pour Windows et Linux sur Microsoft Azure
La note SAP 2015553 présente les prérequis pour les déploiements de logiciels SAP pris en charge par SAP dans Azure.
La note SAP 2205917 présente les paramètres de système d’exploitation recommandés pour SUSE Linux Enterprise Server pour les applications SAP.
La note SAP 1944799 contient SAP HANA instructions pour SUSE Linux Enterprise Server pour les applications SAP.
La note SAP 2178632 contient des informations détaillées sur toutes les métriques de surveillance signalées pour SAP dans Azure.
La note SAP 2191498 a la version requise de l’agent hôte SAP pour Linux dans Azure.
La note SAP 2243692 contient des informations sur les licences SAP sur Linux dans Azure.
La note SAP 1984787 contient des informations sur SUSE Linux Enterprise Server 12.
La note SAP 1999351 contient d’autres informations de résolution des problèmes pour l’extension de supervision améliorée Azure pour SAP.
Le WIKI de la communauté SAP contient toutes les notes SAP requises pour Linux.
Planification et implémentation des machines virtuelles Azure pour SAP sur Linux.
Déploiement Azure Virtual Machines pour SAP sur Linux.
Déploiement de SGBD sur Azure Virtual Machines pour SAP sur Linux.
Guides sur les meilleures pratiques pour SUSE SAP HA - Les guides contiennent toutes les informations nécessaires pour configurer la réplication locale des systèmes Netweaver HP et SAP HANA. Servez-vous de ces guides comme base de référence générale. Ils fournissent des informations beaucoup plus détaillées.
Notes de publication de l’extension de haute disponibilité SUSE 12 SP3.
Guide du cluster SUSE multi-SID pour SLES 12 et SLES 15.
NetApp SAP Applications sur Microsoft Azure à l’aide de Azure NetApp Files.

Vue d’ensemble

Les machines virtuelles participant au cluster doivent être dimensionnées de manière à exécuter toutes les ressources, en cas de basculement. Chaque SID SAP peut basculer indépendamment des autres dans le cluster à haute disponibilité multi-SID. Si vous utilisez l'isolation SBD, les appareils SBD peuvent être partagés entre plusieurs clusters.

Pour obtenir une haute disponibilité, SAP NetWeaver nécessite des partages NFS hautement disponibles. Dans cet exemple, nous partons du principe que les partages NFS SAP sont hébergés sur un serveur de fichiers NFS hautement disponible, que plusieurs systèmes SAP peuvent utiliser. Ou que les partages sont déployés sur des volumes NFS Azure NetApp Files.

Diagramme d’un cluster Pacemaker avec des informations détaillées sur deux clusters multi-SID.

Important

La prise en charge du clustering multi-SID de SAP ASCS/ERS avec SUSE Linux en tant que système d’exploitation invité dans les machines virtuelles Azure est limitée à cinq (5) SIDs SAP sur le même cluster. Chaque nouveau SID augmente la complexité. Une combinaison de SAP Enqueue Replication Server 1 et de SAP Enqueue Replication Server 2 sur le même cluster n’est pas prise en charge. Le clustering multi-SID décrit l’installation de plusieurs instances de SAP ASCS/ERS avec des SID différents dans un cluster Pacemaker. Actuellement, le clustering multi-SID est uniquement pris en charge pour ASCS/ERS.

Conseil

Le clustering multi-SID de SAP ASCS/ERS relève d'une solution particulièrement complexe. Il est plus complexe d’implémenter. En outre, il implique plus d'effort administratif lors de l’exécution d’activités de maintenance (application de correctifs au système d’exploitation, par exemple). Avant de commencer l’implémentation réelle, planifiez soigneusement le déploiement et tous les composants impliqués, tels que les machines virtuelles, les montages NFS, les adresses IP virtuelles, les configurations d’équilibreur de charge, et ainsi de suite.

Le serveur NFS, SAP NetWeaver ASCS, SAP NetWeaver SCS, SAP NetWeaver ERS et la base de données SAP HANA utilisent le nom d’hôte virtuel et les adresses IP virtuelles. Sur Azure, un équilibreur de charge est nécessaire pour utiliser une adresse IP virtuelle. Nous vous recommandons d’utiliser Standard Load Balancer.

La configuration présentée pour cet exemple de cluster multi-SID avec trois systèmes SAP montre un équilibreur de charge avec :

Adresses IP frontales pour ASCS : 10.3.1.14 (NW1), 10.3.1.16 (NW2) et 10.3.1.13 (NW3)
Adresses IP frontales pour ERS : 10.3.1.15 (NW1), 10.3.1.17 (NW2) et 10.3.1.19 (NW3)
Sonde d'intégrité du port 62000 pour NW1 ASCS, 62010 pour NW2 ASCS et 62020 pour NW3 ASCS
Port de sonde 62102 pour NW1 ASCS, 62112 pour NW2 ASCS et 62122 pour NW3 ASCS

Remarque

Lorsque les machines virtuelles sans adresses IP publiques sont ajoutées au pool principal d’un Azure Load Balancer Standard interne, elles n’ont pas de connectivité Internet sortante. Une autre configuration est nécessaire pour activer le routage vers des points de terminaison publics. Pour plus d’informations sur la façon d’obtenir une connectivité sortante, consultez Connectivité de point de terminaison public pour les machines virtuelles à l’aide de Azure Standard Load Balancer dans des scénarios de haute disponibilité SAP.

Important

N'activez pas les horodatages TCP sur Azure machines virtuelles placées derrière Azure Load Balancer. L’activation des horodateurs TCP entraîne l’échec des sondes d’intégrité. Définissez le paramètre net.ipv4.tcp_timestamps sur 0. Pour plus d’informations, consultez sondes de santé du Load Balancer.
Pour empêcher saptune de modifier la valeur net.ipv4.tcp_timestamps qui avait été définie manuellement de 0 à 1, vous devez mettre à jour saptune vers la version 3.1.1 ou ultérieure. Pour plus d’informations, consultez Saptune 3.1.1 – Dois-je mettre à jour ?.

Partages NFS SAP

SAP NetWeaver nécessite un stockage partagé pour le répertoire de transport, de profil, etc. Pour garantir la haute disponibilité d'un système SAP, il est important de disposer de partages NFS à haute disponibilité. Vous devez déterminer l’architecture de vos partages NFS SAP. Une option consiste à déployer un cluster NFS hautement disponible sur des machines virtuelles Azure avec le SUSE Linux Enterprise Server, qui peut être partagé entre plusieurs systèmes SAP.

Une autre option consiste à déployer les partages sur Azure NetApp Files volumes NFS. Avec Azure NetApp Files, vous obtenez une haute disponibilité intégrée pour les partages NFS SAP.

Déployer le premier système SAP dans le cluster

En fonction de l’architecture des partages NFS SAP, déployez le premier système SAP dans le cluster, en suivant la documentation correspondante.

Si vous utilisez un serveur NFS hautement disponible, suivez Haute disponibilité de SAP NetWeaver sur VMs Azure sur SUSE Linux Enterprise Server pour les applications SAP.
Si vous utilisez des volumes NFS Azure NetApp Files, consultez Haute disponibilité pour SAP NetWeaver sur les machines virtuelles Azure sur SUSE Linux Enterprise Server avec Azure NetApp Files pour les applications SAP.

Les articles référencés vous guident tout au long des étapes permettant de préparer les infrastructures nécessaires, de générer le cluster et de préparer le système d’exploitation pour l’exécution de l’application SAP.

Conseil

Testez toujours la fonctionnalité de basculement du cluster une fois le premier système déployé et avant d’ajouter d’autres SID SAP au cluster. Les tests sont essentiels pour que vous sachiez que la fonctionnalité de cluster fonctionne avant d’ajouter la complexité des systèmes SAP supplémentaires au cluster.

Déployer plusieurs systèmes SAP dans le cluster

Dans cet exemple, nous partons du principe que le système NW1 a déjà été déployé dans le cluster. Nous montrons également comment déployer des systèmes SAP NW2 et NW3 dans le cluster.

Les éléments suivants sont précédés de :

[A] : applicable à tous les nœuds
[1] : applicable uniquement au nœud 1
[2] : applicable uniquement au nœud 2

Prérequis

Important

Avant de suivre les instructions pour déployer plusieurs systèmes SAP dans le cluster, suivez les instructions pour déployer le premier système SAP dans le cluster, car il existe des étapes nécessaires uniquement pendant le premier déploiement du système.

Cette documentation suppose ce qui suit :

Le cluster Pacemaker est déjà configuré et en cours d’exécution.
Au moins un système SAP (instance ASCS/ERS) est déjà déployé et est en cours d’exécution dans le cluster.
La fonctionnalité de basculement du cluster est testée.
Les partages NFS de tous les systèmes SAP sont déployés.

Préparer l’installation de SAP NetWeaver

Ajoutez la configuration du système nouvellement déployé (NW2 et NW3) au Azure Load Balancer existant, en suivant les instructions configure Azure Load Balancer manuellement via Azure portail. Ajustez les adresses IP, les ports de sonde d’intégrité et les règles d’équilibrage de charge pour votre configuration.

[A] Configurez la résolution de noms pour les autres systèmes SAP. Vous pouvez utiliser un serveur DNS ou modifier /etc/hosts sur tous les nœuds. Cet exemple vous explique comment utiliser le fichier /etc/hosts. Adaptez les adresses IP et les noms d’hôte à votre environnement.

sudo vi /etc/hosts

# IP address of the load balancer frontend configuration for NW2 ASCS
10.3.1.16 msnw2ascs

# IP address of the load balancer frontend configuration for NW3 ASCS
10.3.1.13 msnw3ascs

# IP address of the load balancer frontend configuration for NW2 ERS
10.3.1.17 msnw2ers

# IP address of the load balancer frontend configuration for NW3 ERS
10.3.1.19 msnw3ers

# IP address for virtual host name for the NFS server for NW2
10.3.1.31 nw2-nfs

# IP address for virtual host name for the NFS server for NW3
10.3.1.32 nw3-nfs

[A] Créez les répertoires partagés pour les systèmes SAP NW2 et NW3 que vous déployez sur le cluster.

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] Configurez autofs pour monter les systèmes de fichiers /sapmnt/SID et /usr/sap/SID/SYS pour les autres systèmes SAP que vous déployez dans le cluster. Dans cet exemple, NW2 et NW3.

Mettez à jour le fichier /etc/auto.direct avec les systèmes de fichiers pour les autres systèmes SAP que vous déployez sur le cluster.
- Si vous utilisez un serveur de fichiers NFS, suivez les instructions sur la page Haute disponibilité des machines virtuelles Azure pour SAP NetWeaver sur SLES
- Si vous utilisez Azure NetApp Files, suivez les instructions sur la haute disponibilité des machines virtuelles Azure pour SAP NW sur SLES avec Azure NetApp Files page
Vous devez redémarrer le service autofs pour activer les partages nouvellement ajoutés.

Installer ASCS/ERS

Créez les ressources de cluster pour l'adresse IP virtuelle et la sonde d'intégrité de l'instance ASCS de l'autre système SAP que vous déployez dans le cluster. L’exemple illustré concerne NW2 et NW3 ASCS, à l’aide d’un serveur NFS hautement disponible.
Important

Les tests récents ont révélé des situations où netcat cesse de répondre aux demandes en raison d'une surcharge de requêtes et de sa limitation à ne gérer qu'une seule connexion. La ressource netcat cesse d’écouter les requêtes d’équilibreur de charge Azure et l’adresse IP flottante devient indisponible. Pour les clusters Pacemaker existants, nous avions recommandé par le passé de remplacer netcat par socat. Actuellement, nous vous recommandons d’utiliser azure-lb l’agent de ressources, qui fait partie des agents de ressources de package, avec les exigences de version de package suivantes :
- Pour SLES 12 SP4/SP5, la version minimum est resource-agents-4.3.018.a7fb5035-3.30.1.
- Pour SLES 15/15 SP1, la version minimale doit être resource-agents-4.3.0184.6ee15eb2-4.13.1.
La modification nécessite un temps d’arrêt bref. Pour les clusters Pacemaker existants, si la configuration a déjà été modifiée pour utiliser socat comme décrit dans Renforcement de la détection Azure Load-Balancer, il n'est pas nécessaire de passer immédiatement à l'agent de ressource azure-lb.
```
sudo crm configure primitive fs_NW2_ASCS Filesystem device='nw2-nfs:/NW2/ASCS' directory='/usr/sap/NW2/ASCS10' fstype='nfs4' \
   op start timeout=60s interval=0 \
   op stop timeout=60s interval=0 \
   op monitor interval=20s timeout=40s

sudo crm configure primitive vip_NW2_ASCS IPaddr2 \
    params ip=10.3.1.16 \
    op monitor interval=10 timeout=20

sudo crm configure primitive nc_NW2_ASCS azure-lb port=62010 \
    op monitor timeout=20s interval=10

sudo crm configure group g-NW2_ASCS fs_NW2_ASCS nc_NW2_ASCS vip_NW2_ASCS \
     meta resource-stickiness=3000

sudo crm configure primitive fs_NW3_ASCS Filesystem device='nw3-nfs:/NW3/ASCS' directory='/usr/sap/NW3/ASCS20' fstype='nfs4' \
    op start timeout=60s interval=0 \
    op stop timeout=60s interval=0 \
    op monitor interval=20s timeout=40s

sudo crm configure primitive vip_NW3_ASCS IPaddr2 \
   params ip=10.3.1.13 \
   op monitor interval=10 timeout=20

sudo crm configure primitive nc_NW3_ASCS azure-lb port=62020 \
   op monitor timeout=20s interval=10

sudo crm configure group g-NW3_ASCS fs_NW3_ASCS nc_NW3_ASCS vip_NW3_ASCS \
    meta resource-stickiness=3000
```
Les ressources créées peuvent être attribuées à différentes ressources du cluster. Lorsque vous les regroupez, ils sont migrés vers l’un des nœuds de cluster. Vérifiez que l’état du cluster est OK et que toutes les ressources sont démarrées. Le nœud sur lequel les ressources s’exécutent n’a aucune importance.
[1] Installer SAP NetWeaver ASCS

Installez SAP NetWeaver ASCS en tant que racine à l’aide d’un nom d’hôte virtuel mappé à l’adresse IP de la configuration frontend d’équilibreur de charge pour l'instance ASCS. Par exemple, pour le système NW2, le nom d’hôte virtuel est msnw2ascs, 10.3.1.16 et le numéro d’instance que vous avez utilisé pour la sonde de l’équilibreur de charge, par exemple 10. Pour le système NW3, le nom d’hôte virtuel est msnw3ascs, 10.3.1.13 et le numéro d’instance que vous avez utilisé pour la sonde de l’équilibreur de charge, par exemple 20.

Vous pouvez utiliser le paramètre sapinst SAPINST_REMOTE_ACCESS_USER pour autoriser un utilisateur non racine à se connecter à sapinst. Vous pouvez utiliser le paramètre SAPINST_USE_HOSTNAME pour installer SAP à l’aide du nom d’hôte virtuel.
```
sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostname
```
Si aucun sous-dossier n’est créé dans /usr/sap/SID/ASCSInstance# lors de l'installation, essayez de définir le propriétaire sur sidadm et le groupe sur sapsys pour l'instance ASCS # , puis réessayez.

[1] Créez une adresse IP virtuelle et des ressources de cluster de sonde d’intégrité pour l’instance ERS d’un autre système SAP que vous déployez sur le cluster. L’exemple illustré concerne NW2 et NW3 ERS, à l’aide d’un serveur NFS hautement disponible.

sudo crm configure primitive fs_NW2_ERS Filesystem device='nw2-nfs:/NW2/ASCSERS' directory='/usr/sap/NW2/ERS12' fstype='nfs4' \
 op start timeout=60s interval=0 \
 op stop timeout=60s interval=0 \
 op monitor interval=20s timeout=40s

sudo crm configure primitive vip_NW2_ERS IPaddr2 \
 params ip=10.3.1.17 \
 op monitor interval=10 timeout=20

sudo crm configure primitive nc_NW2_ERS azure-lb port=62112 \
 op monitor timeout=20s interval=10

sudo crm configure group g-NW2_ERS fs_NW2_ERS nc_NW2_ERS vip_NW2_ERS

sudo crm configure primitive fs_NW3_ERS Filesystem device='nw3-nfs:/NW3/ASCSERS' directory='/usr/sap/NW3/ERS22' fstype='nfs4' \
 op start timeout=60s interval=0 \
 op stop timeout=60s interval=0 \
 op monitor interval=20s timeout=40s

sudo crm configure primitive vip_NW3_ERS IPaddr2 \
 params ip=10.3.1.19 \
 op monitor interval=10 timeout=20

sudo crm configure primitive nc_NW3_ERS azure-lb port=62122 \
 op monitor timeout=20s interval=10

sudo crm configure group g-NW3_ERS fs_NW3_ERS nc_NW3_ERS vip_NW3_ERS

Les ressources créées peuvent être attribuées à différents nœuds du cluster. Lorsque vous les regroupez, ils sont migrés vers l’un des nœuds de cluster. Vérifiez que l’état du cluster est OK et que toutes les ressources sont démarrées.

Assurez-vous ensuite que les ressources du groupe ERS récemment créé sont en cours d’exécution sur le nœud de cluster, à l’inverse du nœud de cluster dans lequel l’instance ASCS correspondant au même système SAP a été installée. Par exemple, si NW2 ASCS a été installé sur slesmsscl1, assurez-vous que le groupe NW2 ERS est en cours d'exécution sur slesmsscl2. Vous pouvez migrer le groupe NW2 ERS vers slesmsscl2 en exécutant la commande suivante :

crm resource migrate g-NW2_ERS slesmsscl2 force

[2] Installer SAP NetWeaver ERS

Installez l'instance SAP NetWeaver ERS en tant qu'utilisateur root sur l'autre nœud, à l'aide d'un nom d'hôte virtuel mappé à l'adresse IP de la configuration frontend de l'équilibreur de charge pour l'instance ERS. Par exemple, pour le système NW2, le nom d’hôte virtuel est msnw2ers, 10.3.1.17 et le numéro d’instance que vous avez utilisé pour la sonde de l’équilibreur de charge, par exemple 12. Pour le système NW3, le nom d’hôte virtuel sera msnw3ers, 10.3.1.19 et le numéro d’instance que vous avez utilisé pour la sonde de l’équilibreur de charge, par exemple 22.

Vous pouvez utiliser le paramètre sapinst SAPINST_REMOTE_ACCESS_USER pour autoriser un utilisateur non racine à se connecter à sapinst. Vous pouvez utiliser le paramètre SAPINST_USE_HOSTNAME pour installer SAP à l’aide du nom d’hôte virtuel.
```
sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostname
```
Remarque

Utilisez SWPM SP 20 PL 05 ou ultérieur. Les versions antérieures ne définissent pas correctement les autorisations à l’origine de l’échec de l’installation.

Si aucun sous-dossier n’est créé dans /usr/sap/NW2/ERSInstance# lors de l'installation, essayez de définir le propriétaire sur sidadm et le groupe sur sapsys pour l'instance ERS # , puis réessayez.

Si vous avez dû migrer le groupe ERS du système SAP récemment déployé vers un nœud de cluster différent, n’oubliez pas de supprimer la contrainte d’emplacement pour le groupe ERS. Vous pouvez supprimer cette contrainte en exécutant la commande suivante (l’exemple correspond aux systèmes SAP NW2 et NW3).
```
crm resource unmigrate g-NW2_ERS
crm resource unmigrate g-NW3_ERS
```

[1] Adaptez les profils d’instance ASCS/SCS et ERS pour un ou plusieurs systèmes SAP nouvellement installés. L’exemple illustré concerne NW2. Vous devez adapter les profils ASCS/SCS et ERS pour toutes les instances SAP ajoutées au cluster.

Profil ASCS/SCS

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 following lines
service/halib = $(DIR_EXECUTABLE)/saphascriptco.so
service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector

# Add the keep alive parameter, if using ENSA1
enque/encni/set_so_keepalive = TRUE

Pour ENSA1 et ENSA2, assurez-vous que les keepaliveParamètres de système d’exploitation sont définis comme décrit dans la note SAP 1410736.

Profil ERS

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)

# Add the following lines
service/halib = $(DIR_EXECUTABLE)/saphascriptco.so
service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector

# remove Autostart from ERS profile
# Autostart = 1

[A] Configurez les utilisateurs SAP pour le système SAP récemment déployé, dans cet exemple NW2 et NW3.
```
# Add sidadm to the haclient group
sudo usermod -aG haclient nw2adm
sudo usermod -aG haclient nw3adm
```

Ajoutez les services SAP ASCS et ERS pour le système SAP récemment installé au fichier sapservice. L’exemple illustré concerne les systèmes SAP NW2 et NW3.

Ajoutez l’entrée de service ASCS au deuxième nœud et copiez l’entrée de service ERS dans le premier nœud. Exécutez les commandes pour chaque système SAP du nœud, où l’instance ASCS correspondant au système SAP a été installée.

# Execute the following commands on slesmsscl1,assuming the NW2 ASCS instance was installed on slesmsscl1
cat /usr/sap/sapservices | grep ASCS10 | sudo ssh slesmsscl2 "cat >>/usr/sap/sapservices"
sudo ssh slesmsscl2 "cat /usr/sap/sapservices" | grep ERS12 | sudo tee -a /usr/sap/sapservices

# Execute the following commands on slesmsscl2, assuming the NW3 ASCS instance was installed on slesmsscl2
cat /usr/sap/sapservices | grep ASCS20 | sudo ssh slesmsscl1 "cat >>/usr/sap/sapservices"
sudo ssh slesmsscl1 "cat /usr/sap/sapservices" | grep ERS22 | sudo tee -a /usr/sap/sapservices

[A] Désactivation des services systemd des instances SAP ASCS et ERS. Cette étape s’applique uniquement si systemd gère l’infrastructure de démarrage SAP conformément à la note SAP 3115048.

Remarque

Lorsque vous gérez des instances SAP telles que SAP ASCS et SAP ERS à l’aide de la configuration du cluster SLES, vous devez apporter d’autres modifications pour intégrer le cluster à l’infrastructure de démarrage SAP native basée sur le système pour garantir que les procédures de maintenance ne compromissaient pas la stabilité du cluster. Une fois que vous avez installé ou modifié l’infrastructure de démarrage SAP pour qu’elle utilise une configuration basée sur systemd, conformément à la note SAP 3115048, vous devez désactiver les services systemd pour les instances SAP ASCS et ERS.
```
# Stop all ASCS and ERS instances using <sid>adm
sapcontrol -nr 10 -function Stop
sapcontrol -nr 10 -function StopService

sapcontrol -nr 12 -function Stop
sapcontrol -nr 12 -function StopService

# Execute below command on VM where you have performed ASCS instance installation for each SAP system (e.g. slesmsscl1)
sudo systemctl disable SAPNW2_10
sudo systemctl disable SAPNW3_20
# Execute below command on VM where you have performed ERS instance installation for each SAP system (e.g. slesmsscl2)
sudo systemctl disable SAPNW2_12
sudo systemctl disable SAPNW2_22
```

[1] Créez les ressources de cluster SAP pour le système SAP récemment installé.

Selon que vous exécutez un système ENSA1 ou ENSA2, sélectionnez l’onglet correspondant pour définir les ressources des systèmes NW2 et NW3 . SAP a introduit la prise en charge d’ENSA2, y compris la réplication, dans SAP NetWeaver 7.52. À compter de ABAP Platform 1809, ENSA2 est installé par défaut. Pour la prise en charge d’ENSA2, consultez la note SAP 2630416.

ENSA1
ENSA2

sudo crm configure property maintenance-mode="true"

sudo crm configure primitive rsc_sap_NW2_ASCS10 SAPInstance \
  operations \$id=rsc_sap_NW2_ASCS10-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW2_ASCS10_msnw2ascs START_PROFILE="/sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs" \
  AUTOMATIC_RECOVER=false \
  meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10

sudo crm configure primitive rsc_sap_NW2_ERS12 SAPInstance \
  operations \$id=rsc_sap_NW2_ERS12-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW2_ERS12_msnw2ers START_PROFILE="/sapmnt/NW2/profile/NW2_ERS12_msnw2ers" AUTOMATIC_RECOVER=false IS_ERS=true \
  meta priority=1000

sudo crm configure modgroup g-NW2_ASCS add rsc_sap_NW2_ASCS10
sudo crm configure modgroup g-NW2_ERS add rsc_sap_NW2_ERS12

sudo crm configure colocation col_sap_NW2_no_both -5000: g-NW2_ERS g-NW2_ASCS
sudo crm configure location loc_sap_NW2_failover_to_ers rsc_sap_NW2_ASCS10 rule 2000: runs_ers_NW2 eq 1
sudo crm configure order ord_sap_NW2_first_start_ascs Optional: rsc_sap_NW2_ASCS10:start rsc_sap_NW2_ERS12:stop symmetrical=false

sudo crm configure primitive rsc_sap_NW3_ASCS20 SAPInstance \
  operations \$id=rsc_sap_NW3_ASCS20-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW3_ASCS10_msnw3ascs START_PROFILE="/sapmnt/NW3/profile/NW3_ASCS20_msnw3ascs" \
  AUTOMATIC_RECOVER=false \
  meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10

sudo crm configure primitive rsc_sap_NW3_ERS22 SAPInstance \
  operations \$id=rsc_sap_NW3_ERS22-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW3_ERS22_msnw3ers START_PROFILE="/sapmnt/NW3/profile/NW3_ERS22_msnw2ers" AUTOMATIC_RECOVER=false IS_ERS=true \
  meta priority=1000

sudo crm configure modgroup g-NW3_ASCS add rsc_sap_NW3_ASCS20
sudo crm configure modgroup g-NW3_ERS add rsc_sap_NW3_ERS22

sudo crm configure colocation col_sap_NW3_no_both -5000: g-NW3_ERS g-NW3_ASCS
sudo crm configure location loc_sap_NW3_failover_to_ers rsc_sap_NW3_ASCS10 rule 2000: runs_ers_NW3 eq 1
sudo crm configure order ord_sap_NW3_first_start_ascs Optional: rsc_sap_NW3_ASCS20:start rsc_sap_NW3_ERS22:stop symmetrical=false
sudo crm configure property maintenance-mode="false"

sudo crm configure property maintenance-mode="true"

sudo crm configure primitive rsc_sap_NW2_ASCS10 SAPInstance \
  operations \$id=rsc_sap_NW2_ASCS10-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW2_ASCS10_msnw2ascs START_PROFILE="/sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs" \
  AUTOMATIC_RECOVER=false \
  meta resource-stickiness=5000

sudo crm configure primitive rsc_sap_NW2_ERS12 SAPInstance \
  operations \$id=rsc_sap_NW2_ERS12-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW2_ERS12_msnw2ers START_PROFILE="/sapmnt/NW2/profile/NW2_ERS12_msnw2ers" AUTOMATIC_RECOVER=false IS_ERS=true

sudo crm configure modgroup g-NW2_ASCS add rsc_sap_NW2_ASCS10
sudo crm configure modgroup g-NW2_ERS add rsc_sap_NW2_ERS12

sudo crm configure colocation col_sap_NW2_no_both -5000: g-NW2_ERS g-NW2_ASCS
sudo crm configure order ord_sap_NW2_first_start_ascs Optional: rsc_sap_NW2_ASCS10:start rsc_sap_NW2_ERS12:stop symmetrical=false

sudo crm configure primitive rsc_sap_NW3_ASCS20 SAPInstance \
  operations \$id=rsc_sap_NW3_ASCS20-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW3_ASCS10_msnw3ascs START_PROFILE="/sapmnt/NW3/profile/NW3_ASCS20_msnw3ascs" \
  AUTOMATIC_RECOVER=false \
  meta resource-stickiness=5000

sudo crm configure primitive rsc_sap_NW3_ERS22 SAPInstance \
  operations \$id=rsc_sap_NW3_ERS22-operations \
  op monitor interval=11 timeout=60 on-fail=restart \
  params InstanceName=NW3_ERS22_msnw3ers START_PROFILE="/sapmnt/NW3/profile/NW3_ERS22_msnw2ers" AUTOMATIC_RECOVER=false IS_ERS=true

sudo crm configure modgroup g-NW3_ASCS add rsc_sap_NW3_ASCS20
sudo crm configure modgroup g-NW3_ERS add rsc_sap_NW3_ERS22

sudo crm configure colocation col_sap_NW3_no_both -5000: g-NW3_ERS g-NW3_ASCS
sudo crm configure order ord_sap_NW3_first_start_ascs Optional: rsc_sap_NW3_ASCS20:start rsc_sap_NW3_ERS22:stop symmetrical=false
sudo crm configure property maintenance-mode="false"

Si vous effectuez une mise à niveau à partir d’une version antérieure et que vous passez au serveur de file d’attente 2, consultez la note SAP 2641019.

Vérifiez que l’état du cluster est OK et que toutes les ressources sont démarrées. Le nœud sur lequel les ressources s’exécutent n’a aucune importance.

L’exemple suivant illustre l’état des ressources de cluster, après ajout des systèmes SAP NW2 et NW3 au cluster.

sudo crm_mon -r

# Online: [ slesmsscl1 slesmsscl2 ]

#Full list of resources:

#stonith-sbd     (stonith:external/sbd): Started slesmsscl1
# Resource Group: g-NW1_ASCS
#     fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
#     nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
#     vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
#     rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
# Resource Group: g-NW1_ERS
#     fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
#     nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
#     vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
#     rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
# Resource Group: g-NW2_ASCS
#     fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
#     nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
#     vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
#     rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
# Resource Group: g-NW2_ERS
#     fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
#     nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
#     vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
#     rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
# Resource Group: g-NW3_ASCS
#     fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
#     nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
#     vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
#     rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
# Resource Group: g-NW3_ERS
#     fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
#     nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
#     vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
#     rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl2

L’illustration suivante montre à quoi ressembleraient les ressources dans High Availability Web Konsole (HAWK), avec les ressources du système SAP NW2 développées.

Remarque

Le cluster SAP ASCS/ERS peut être étendu de 2 nœuds à 3 nœuds, le 3e nœud servant de nœud de rechange pour le basculement des services ASCS ou ERS.

La configuration à 3 nœuds ne peut être utilisée que pour les systèmes SAP à l’aide de SAP Replication Server 2 (ENSA2).
La propriété priority-fencing-delay de cluster ne doit pas être utilisée dans un cluster à 3 nœuds.

Poursuivre l’installation de SAP

Finalisez votre installation SAP en procédant comme suit :

Préparer vos serveurs d'applications SAP NetWeaver
Installer une instance SGBD
Installer un serveur d’applications SAP principal
Installation d’instances d’application SAP supplémentaires

Tester la configuration du cluster multi-SID

Les tests suivants sont un sous-ensemble des cas de test dans les guides des meilleures pratiques de SUSE. Ils sont inclus pour des raisons pratiques. Pour obtenir la liste complète des tests de cluster, reportez-vous à la documentation suivante :

Si vous utilisez un serveur NFS hautement disponible, suivez Haute disponibilité de SAP NetWeaver sur VMs Azure sur SUSE Linux Enterprise Server pour les applications SAP.
Si vous utilisez les volumes NFS d'Azure NetApp Files, suivez Haute disponibilité de SAP NetWeaver sur les machines virtuelles Azure exécutées sur SUSE Linux Enterprise Server avec Azure NetApp Files pour les applications SAP

Lisez toujours les guides de bonnes pratiques SUSE et effectuez tous les tests si nécessaire. Les tests présentés se trouvent dans un cluster multi-SID à deux nœuds avec trois systèmes SAP installés.

Testez HAGetFailoverConfig et HACheckFailoverConfig.

Exécutez les commandes suivantes en tant que <sapsid>adm sur le nœud où l’instance ASCS est actuellement en cours d’exécution. Si le nom d’hôte contient des tirets, les commandes risquent d’échouer avec FAIL : Mémoire insuffisante (problème connu). SUSE doit le corriger dans le paquet sap-suse-cluster-connector.

 slesmsscl1:nw1adm 57> sapcontrol -nr 00 -function HAGetFailoverConfig

# 10.12.2019 21:33:08
# HAGetFailoverConfig
# OK
# HAActive: TRUE
# HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4
# HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 (sap_suse_cluster_connector 3.1.0)
# HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
# HAActiveNode: slesmsscl1
# HANodes: slesmsscl1, slesmsscl2

slesmsscl1:nw1adm 53> sapcontrol -nr 00 -function HACheckFailoverConfig

# 19.12.2019 21:19:58
# HACheckFailoverConfig
# OK
# state, category, description, comment
# SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version, SAPInstance includes is-ers patch

slesmsscl2:nw2adm 35> sapcontrol -nr 10 -function HAGetFailoverConfig

# 10.12.2019 21:37:09
# HAGetFailoverConfig
# OK
# HAActive: TRUE
# HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4
# HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 (sap_suse_cluster_connector 3.1.0)
# HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
# HAActiveNode: slesmsscl2
# HANodes: slesmsscl2, slesmsscl1

slesmsscl2:nw2adm 52> sapcontrol -nr 10 -function HACheckFailoverConfig

# 19.12.2019 21:17:39
# HACheckFailoverConfig
# OK
# state, category, description, comment
# SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version, SAPInstance includes is-ers patch

slesmsscl1:nw3adm 49> sapcontrol -nr 20 -function HAGetFailoverConfig

# 10.12.2019 23:35:36
# HAGetFailoverConfig
# OK
# HAActive: TRUE
# HAProductVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4
# HASAPInterfaceVersion: SUSE Linux Enterprise Server for SAP Applications 12 SP4 (sap_suse_cluster_connector 3.1.0)
# HADocumentation: https://www.suse.com/products/sles-for-sap/resource-library/sap-best-practices/
# HAActiveNode: slesmsscl1
# HANodes: slesmsscl1, slesmsscl2

slesmsscl1:nw3adm 52> sapcontrol -nr 20 -function HACheckFailoverConfig

# 19.12.2019 21:10:42
# HACheckFailoverConfig
# OK
# state, category, description, comment
# SUCCESS, SAP CONFIGURATION, SAPInstance RA sufficient version, SAPInstance includes is-ers patch

Migrer manuellement l’instance ASCS L’exemple montre comment migrer l’instance ASCS pour le système SAP NW2.

État des ressources avant le début du test :

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

Exécutez les commandes suivantes en tant que racine pour migrer l’instance ASCS NW2.

 crm resource migrate rsc_sap_NW2_ASCS10 force
 # INFO: Move constraint created for rsc_sap_NW2_ASCS10

 crm resource unmigrate rsc_sap_NW2_ASCS10
 # INFO: Removed migration constraints for rsc_sap_NW2_ASCS10

 # Remove failed actions for the ERS that occurred as part of the migration
 crm resource cleanup rsc_sap_NW2_ERS12

État des ressources après le test :

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

Testez HAFailoverToNode. Le test présenté ici montre comment migrer l’instance ASCS pour le système SAP NW2.

État des ressources avant le début du test :

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

Exécutez les commandes suivantes en tant que nw2adm pour migrer l’instance ASCS NW2.

slesmsscl2:nw2adm 53> sapcontrol -nr 10 -host msnw2ascs -user nw2adm password -function HAFailoverToNode ""

# run as root
# Remove failed actions for the ERS that occurred as part of the migration
crm resource cleanup rsc_sap_NW2_ERS12

# Remove migration constraints
crm resource clear rsc_sap_NW2_ASCS10

#INFO: Removed migration constraints for rsc_sap_NW2_ASCS10

État des ressources après le test :

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

Simuler un plantage de nœud

État des ressources avant le début du test :

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

Exécutez la commande suivante en tant que racine sur le nœud où au moins une instance ASCS est en cours d’exécution. Dans cet exemple, nous avons exécuté la commande dans slesmsscl2, où les instances ASCS pour NW1 et NW3 sont en cours d’exécution.

slesmsscl2:~ # echo b > /proc/sysrq-trigger

Si vous utilisez SBD, Pacemaker ne doit pas démarrer automatiquement sur le nœud tué. L’état après le redémarrage du nœud devrait ressembler à ce qui suit.

 Online: [ slesmsscl1 ]
 OFFLINE: [ slesmsscl2 ]
 Full list of resources:

 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl1

 Failed Resource Actions:
 * rsc_sap_NW1_ERS02_monitor_11000 on slesmsscl1 'not running' (7): call=125, status=complete, exitreason='',
     last-rc-change='Fri Dec 13 19:32:10 2019', queued=0ms, exec=0ms
 * rsc_sap_NW2_ERS12_monitor_11000 on slesmsscl1 'not running' (7): call=126, status=complete, exitreason='',
     last-rc-change='Fri Dec 13 19:32:10 2019', queued=0ms, exec=0ms
 * rsc_sap_NW3_ERS22_monitor_11000 on slesmsscl1 'not running' (7): call=127, status=complete, exitreason='',
     last-rc-change='Fri Dec 13 19:32:10 2019', queued=0ms, exec=0ms

Exécutez les commandes suivantes pour démarrer Pacemaker sur le nœud tué, nettoyer les messages SBD et nettoyer les ressources ayant échoué.

# run as root
# list the SBD device(s)
cat /etc/sysconfig/sbd | grep SBD_DEVICE=

# output is like:
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message slesmsscl2 clear

systemctl start pacemaker
crm resource cleanup rsc_sap_NW1_ERS02
crm resource cleanup rsc_sap_NW2_ERS12
crm resource cleanup rsc_sap_NW3_ERS22

État des ressources après le test :

 Full list of resources:
 stonith-sbd     (stonith:external/sbd): Started slesmsscl1
  Resource Group: g-NW1_ASCS
      fs_NW1_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW1_ERS
      fs_NW1_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW1_ERS02  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW2_ASCS
      fs_NW2_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW2_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW2_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW2_ERS
      fs_NW2_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW2_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW2_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW2_ERS12  (ocf::heartbeat:SAPInstance):   Started slesmsscl2
  Resource Group: g-NW3_ASCS
      fs_NW3_ASCS        (ocf::heartbeat:Filesystem):    Started slesmsscl1
      nc_NW3_ASCS        (ocf::heartbeat:azure-lb):      Started slesmsscl1
      vip_NW3_ASCS       (ocf::heartbeat:IPaddr2):       Started slesmsscl1
      rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance):   Started slesmsscl1
  Resource Group: g-NW3_ERS
      fs_NW3_ERS (ocf::heartbeat:Filesystem):    Started slesmsscl2
      nc_NW3_ERS (ocf::heartbeat:azure-lb):      Started slesmsscl2
      vip_NW3_ERS        (ocf::heartbeat:IPaddr2):       Started slesmsscl2
      rsc_sap_NW3_ERS22  (ocf::heartbeat:SAPInstance):   Started slesmsscl2

Étapes suivantes

Planification et implémentation de SAP sur Azure Virtual Machines
Déploiement de Azure Virtual Machines pour SAP
Déploiement de SGBD Azure Virtual Machines pour SAP
Pour savoir comment établir une haute disponibilité et planifier la récupération d’urgence de SAP HANA sur des machines virtuelles Azure, consultez Disponibilité de SAP HANA sur Azure Virtual Machines (machines virtuelles)

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-03-11

Haute disponibilité pour SAP NetWeaver sur des machines virtuelles Azure sur SUSE Linux Enterprise Server pour les applications SAP multi-SID

Vue d’ensemble

Partages NFS SAP

Déployer le premier système SAP dans le cluster

Déployer plusieurs systèmes SAP dans le cluster

Prérequis

Préparer l’installation de SAP NetWeaver

Installer ASCS/ERS

Poursuivre l’installation de SAP

Tester la configuration du cluster multi-SID

Étapes suivantes

Commentaires

Ressources supplémentaires