Guide de haute disponibilité multi-SID pour SAP NetWeaver sur les machines virtuelles Azure sur SUSE Linux Enterprise Server pour les applications SAP

Article
07/25/2024

Cet article explique comment déployer plusieurs systèmes hautement disponible SAP NetWeaver ou S4HANA (c’est-à-dire, plusieurs SID) dans un cluster à deux nœuds sur des machines virtuelles Azure avec SUSE Linux Enterprise Server pour les applications SAP.

Dans les exemples de configuration, commandes d’installation, etc., trois systèmes SAP NetWeaver 7.50 sont déployés dans un même cluster à deux nœuds à haute disponibilité. 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 les noms virtuels nw2-nfs pour les partages NFS NW2 et nw3-nfs pour les partages NFS NW3, en partant du principe que le cluster NFS a été déployé.

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

Note SAP 1928533, qui contient :
- une liste des tailles de machines virtuelles Azure prises en charge pour le déploiement de logiciels SAP
- des informations importantes sur la capacité en fonction de la taille des machines virtuelles Azure
- les logiciels SAP pris en charge et les combinaisons entre système d’exploitation et base de données
- la version du noyau SAP requise pour Windows et Linux sur Microsoft Azure
La note SAP 2015553 répertorie les conditions préalables au déploiement de logiciels SAP pris en charge par SAP sur Azure.
La note SAP 2205917 contient des paramètres de système d’exploitation recommandés pour SUSE Linux Enterprise Server pour les applications SAP
La note SAP 1944799 contient des instructions SAP HANA 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 rapportées pour SAP sur Azure.
La note SAP 2191498 contient la version requise de l’agent hôte SAP pour Linux sur 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 des informations de dépannage supplémentaires pour l’extension d’analyse Azure améliorée pour SAP.
Le WIKI de la communauté SAP contient toutes les notes SAP requises pour Linux.
Planification et implémentation de machines virtuelles Azure pour SAP sur Linux
Déploiement de machines virtuelles Azure pour SAP sur Linux
Déploiement SGBD de machines virtuelles Azure pour SAP sur Linux
Guides sur les meilleures pratiques pour SUSE SAP HA Les guides contiennent toutes les informations nécessaires pour configurer la haute disponibilité Netweaver et la réplication système SAP HANA localement. Utilisez ces guides comme planning de référence. Ils fournissent des informations beaucoup plus détaillées.
Notes de publication de SUSE High Availability Extension 12 SP3
Guide du cluster multi-SID SUSE pour SLES 12 et SLES 15
Applications SAP NetApp su Microsoft Azure avec 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, susceptible d'être utilisé par plusieurs systèmes SAP. Ou que les partages sont déployés sur des volumes NFS Azure NetApp Files.

Le cluster Pacemaker présente des informations détaillées sur deux clusters multi-SID, msidcl1 et msidcl2.

Important

La prise en charge du clustering multi-SID de SAP ASC/ERS avec SUSE Linux comme système d’exploitation invité des machines virtuelles Azure est limitée à cinq SID SAP sur le même cluster. Chaque nouveau SID augmente la complexité. La combinaison de Enqueue Replication Server 1 et Enqueue Replication Server 2 SAP 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 s'avère plus difficile à 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 procéder à l'implémentation, prenez le temps de planifier soigneusement le déploiement et tous les composants impliqués, tels que les machines virtuelles, montages NFS, adresses IP virtuelles, configurations d’équilibreur de charge, etc.

Le serveur NFS, SAP NetWeaver ASCS, SAP NetWeaver SCS, SAP NetWeaver ERS et la base de données SAP HANA utilisent un nom d’hôte virtuel et des 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 des machines virtuelles sans adresse IP publique sont placées dans le pool principal d’Azure Standard Load Balancer interne (aucune adresse IP publique), il n’y a pas de connectivité Internet sortante, sauf si une configuration supplémentaire est effectuée pour autoriser le routage vers des points de terminaison publics. Pour savoir plus en détails comment bénéficier d’une connectivité sortante, voir Connectivité des points de terminaison publics pour les machines virtuelles avec Azure Standard Load Balancer dans les scénarios de haute disponibilité SAP.

Important

N’activez pas les horodatages TCP sur les machines virtuelles Azure placées derrière Azure Load Balancer. L’activation des timestamps 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 d’intégrité Load Balancer.
Pour empêcher que saptune redéfinisse sur 1 la valeur net.ipv4.tcp_timestamps qui avait été définie manuellement sur 0, 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 un système SAP hautement disponible, il est important de disposer de partages NFS hautement disponibles. Vous devez déterminer l’architecture de vos partages NFS SAP. Vous pouvez notamment créer un cluster NFS hautement disponible sur des machines virtuelles Azure sur SUSE Linux Enterprise Server, et celui-ci peut être partagé entre plusieurs systèmes SAP.

Vous pouvez également déployer les partages sur des volumes NFS Azure NetApp Files. Avec Azure NetApp Files, vous bénéficieriez d’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, consultez Haute disponibilité pour SAP NetWeaver sur les machines virtuelles 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 documents listés ci-dessus vous guideront tout au long des étapes de préparation des infrastructures nécessaires, de création du cluster et de préparation du système d’exploitation pour l’exécution de l’application SAP.

Conseil

Testez systématiquement la fonctionnalité de basculement du cluster, une fois le premier système déployé, avant d’ajouter les SID SAP supplémentaires au cluster. Vous vous assurerez ainsi du bon fonctionnement de la fonctionnalité de cluster, avant d’ajouter des systèmes SAP supplémentaires au cluster.

Déployer des systèmes SAP supplémentaires au cluster

Dans cet exemple, nous partons du principe que le système NW1 a déjà été déployé dans le cluster. Nous allons vous expliquer comment effectuer un déploiement dans les systèmes SAP du cluster NW2 et NW3.

Les éléments suivants sont précédés de [A] (applicable à tous les nœuds), de [1] (applicable uniquement au nœud 1) ou de [2] (applicable uniquement au nœud 2).

Prérequis

Important

Avant de suivre les instructions pour déployer des systèmes SAP supplémentaires dans le cluster, suivez les instructions visant à déployer le premier système SAP dans le cluster, car certaines étapes sont uniquement requises lors du 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 une configuration pour le système récemment déployé (à savoir, NW2, NW3) à l'instance Azure Load Balancer existante en suivant les instructions dans Configurer Azure Load Balancer manuellement via le Portail Azure. 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 systèmes SAP supplémentaires. 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 supplémentaires 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 systèmes SAP supplémentaires que vous déployez sur le cluster. Dans cet exemple, NW2 et NW3.

Mettez à jour le fichier /etc/auto.direct avec les systèmes de fichiers pour les systèmes SAP supplémentaires 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 page Haute disponibilité des machines virtuelles Azure pour SAP NW sur SLES avec Azure NetApp File
Vous devez redémarrer le service autofs pour monter les partages récemment ajoutés.

Installer ASCS/ERS

Créez l'adresse IP virtuelle et les ressources de cluster de sonde d’intégrité pour l’instance ASCS du système SAP supplémentaire que vous déployez sur le cluster. L’exemple illustré ici correspond à NW2 et NW3 ASCS et utilise un serveur NFS hautement disponible.
Important

Des tests récents ont révélé des cas où netcat cessait de répondre aux demandes en raison du backlog et de sa capacité à ne gérer qu’une seule connexion. La ressource netcat cesse d’écouter les demandes d’Azure Load Balancer et l’adresse IP flottante devient indisponible.
Pour les clusters Pacemaker existants, nous vous recommandons de remplacer netcat par socat. Actuellement, nous vous recommandons d'utiliser l'agent de ressources azure-lb, qui fait partie du package resource-agents, avec la configuration requise suivante pour la version du package :
- 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 minimum est resource-agents-4.3.0184.6ee15eb2-4.13.1.
Notez que la modification nécessitera un bref temps d’arrêt.
Pour les clusters Pacemaker existants, si la configuration a déjà été modifiée pour utiliser socat comme décrit à la page Azure Load-Balancer Detection Hardening, il n’est pas nécessaire de passer immédiatement à l’agent de ressources 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. Si vous les regroupez, elles migreront vers l’un des nœuds du 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 du système SAP supplémentaire que vous déployez sur le cluster. L’exemple illustré ici correspond à NW2 et NW3 ERS, avec 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. Si vous les regroupez, elles migreront vers l’un des nœuds du 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 ERS SAP NetWeaver en tant que racine sur l'autre nœud, à l’aide d’un nom d’hôte virtuel mappé à l’adresse IP de la configuration frontend d’é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
```
Notes

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

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 au(x) système(s) SAP récemment installé(s). L’exemple illustré ci-dessous correspond à NW2. Vous devrez 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_CT_RUN)/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_CT_RUN)/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 ci-dessous correspond aux 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 l’infrastructure de démarrage SAP est gérée par systemd conformément à la note SAP 3115048

Remarque

Quand vous gérez des instances SAP telles que SAP ASCS et SAP ERS à l’aide de la configuration de cluster SLES, vous devez apporter des modifications supplémentaires pour intégrer le cluster à l’infrastructure de démarrage SAP native basée sur systemd. Cela vous permet d’avoir la certitude que les procédures de maintenance ne compromettent 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. À partir de la plateforme ABAP 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 HA Web Konsole (Hawk), avec les ressources du système SAP NW2 développées.

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
Installer une ou plusieurs instances d’application SAP supplémentaires

Tester la configuration de 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, consultez Haute disponibilité pour SAP NetWeaver sur les machines virtuelles 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.

Consultez systématiquement les guides des meilleures pratiques SUSE et effectuez tous les tests supplémentaires qui pourraient y être ajoutés.
Les tests présentés se trouvent dans un cluster à deux nœuds, multi-SID, 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 les commandes échouent avec ÉCHEC : Mémoire insuffisante apparait, cela peut être dû à des tirets dans votre nom d’hôte. Ceci est un problème connu et il sera corrigé par SUSE dans le package 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 l’incident 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 machines virtuelles Azure pour SAP
Déploiement de machines virtuelles Azure pour SAP
Déploiement SGBD de machines virtuelles Azure 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 Haute disponibilité de SAP HANA sur des machines virtuelles Azure

Partager via

Guide de haute disponibilité multi-SID pour SAP NetWeaver sur les machines virtuelles Azure sur SUSE Linux Enterprise Server pour les applications SAP

Vue d’ensemble

Partages NFS SAP

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

Déployer des systèmes SAP supplémentaires au cluster

Prérequis

Préparer l’installation de SAP NetWeaver

Installer ASCS/ERS

Poursuivre l’installation de SAP

Tester la configuration de cluster multi-SID

Étapes suivantes

Commentaires

Ressources supplémentaires