Plusieurs SID de haute disponibilité pour SAP NetWeaver sur les machines virtuelles Azure sur Red Hat Enterprise Linux for SAP Applications
Cet article explique comment déployer plusieurs systèmes hautement disponibles SAP NetWeaver (plusieurs SID) dans un cluster à deux nœuds sur des machines virtuelles Azure avec Red Hat Enterprise Linux for SAP Applications.
Dans les exemples de configuration, 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 virtuelmsnw1ascs
. Numéro d'instance ER 02 et nom d'hôte virtuelmsnw1ers
.NW2
: Numéro d'instance ASCS 10 et nom d'hôte virtuelmsnw2ascs
. Numéro d'instance ER 12 et nom d'hôte virtuelmsnw2ers
.NW3
: Numéro d'instance ASCS 20 et nom d'hôte virtuelmsnw3ascs
. Numéro d'instance ER 22 et nom d'hôte virtuelmsnw3ers
.
Cet article ne couvre pas la couche de base de données et le déploiement des partages NFS SAP.
Les exemples de cet article utilisent le volume Azure NetApp FilessapMSID
pour les partages NFS, en supposant que le volume est déjà déployé. Les exemples supposent que le volume Azure NetApp Files est déployé avec le protocole NFSv3. Ils utilisent les chemins d’accès de fichier suivants pour les ressources de cluster pour les instances ASCS et ERS des systèmes NW1
SAP, NW2
et NW3
:
- volume sapMSID (nfs://10.42.0.4/sapmntNW1)
- volume sapMSID (nfs://10.42.0.4/usrsapNW1ascs)
- volume sapMSID (nfs://10.42.0.4/usrsapNW1sys)
- volume sapMSID (nfs://10.42.0.4/usrsapNW1ers)
- volume sapMSID (nfs://10.42.0.4/sapmntNW2)
- volume sapMSID (nfs://10.42.0.4/usrsapNW2ascs)
- volume sapMSID (nfs://10.42.0.4/usrsapNW2sys)
- volume sapMSID (nfs://10.42.0.4/usrsapNW2ers)
- volume sapMSID (nfs://10.42.0.4/sapmntNW3)
- volume sapMSID (nfs://10.42.0.4/usrsapNW3ascs)
- volume sapMSID (nfs://10.42.0.4/usrsapNW3sys)
- volume sapMSID (nfs://10.42.0.4/usrsapNW3ers)
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.
- Documentation Azure NetApp Files.
- La note SAP 2015553 répertorie les conditions préalables pour les déploiements de logiciels SAP pris en charge par SAP dans Azure.
- La note SAP 2002167 recommande des paramètres de système d’exploitation pour Red Hat Enterprise Linux.
- La note SAP 2009879 conseille sur SAP HANA pour Red Hat Enterprise Linux.
- 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 1999351 contient des informations supplémentaires sur le dépannage de l’extension Azure Enhanced Monitoring 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.
- SAP Netweaver dans le cluster pacemaker.
- Documentation RHEL générale :
- Vue d’ensemble des modules complémentaires de haute disponibilité
- Administration des modules complémentaires de haute disponibilité
- Référence des modules complémentaires de haute disponibilité
- Configuration d’ASC/ERS pour SAP Netweaver avec des ressources autonomes dans RHEL 7.5
- Configuration de SAP S/4HANA ASCS/ERS avec Standalone Enqueue Server 2 (ENSA2) dans Pacemaker sur RHEL
- Documentation RHEL spécifique à Azure :
- 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.
Des partages hautement disponibles sont requis par SAP NetWeaver pour la haute disponibilité. Cet article montre des exemples pour lesquels les partages SAP sont déployés sur des volumes NFS Azure NetApp Files. Vous pouvez également héberger les partages sur un cluster GlusterFS hautement disponible, qui peut être utilisé par plusieurs systèmes SAP.
Important
La prise en charge du clustering multi-SID de SAP ASCS/ERS avec Red Hat Linux comme système d’exploitation invité sur les 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.
SAP NetWeaver ASCS, SAP NetWeaver SCS et SAP NetWeaver ERS 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.
- Adresses IP de front-end pour ASCS : 10.3.1.50 (NW1), 10.3.1.52 (NW2) et 10.3.1.54 (NW3)
- Adresses IP de front-end pour ERS : 10.3.1.51 (NW1), 10.3.1.53 (NW2) et 10.3.1.55 (NW3)
- Port de sonde 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 timestamps TCP sur des machines virtuelles Azure placées derrière Azure Load Balancer. L’activation des horodateurs TCP provoque l’échec des sondes d’intégrité. Définissez le paramètre net.ipv4.tcp_timestamps
à 0. Pour plus d’informations, consultez Sondes d’intégrité Load Balancer.
Partages 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 hautement disponibles. Vous devez déterminer l’architecture de vos partages SAP. Il est possible de les déployer sur des volumes NFS Azure NetApp Files. Avec Azure NetApp Files, vous bénéficiez d’une haute disponibilité intégrée pour les partages NFS SAP.
Vous pouvez également créer un cluster GlusterFS sur des machines virtuelles Azure sur Red Hat Enterprise Linux for SAP NetWeaver, partageable entre plusieurs systèmes SAP.
Déployer le premier système SAP dans le cluster
Après avoir déterminé l’architecture des partages SAP, déployez le premier système SAP dans le cluster, en suivant la documentation correspondante.
- Si vous utilisez des volumes NFS Azure NetApp Files, consultez Haute disponibilité des machines virtuelles Azure pour SAP NetWeaver sur Red Hat Enterprise Linux avec Azure NetApp Files for SAP Applications.
- Si vous utilisez un cluster GlusterFS, consultez GlusterFS sur les machines virtuelles Azure sur Red Hat Enterprise Linux for SAP NetWeaver.
Ces articles vous guident tout au long des étapes de préparation de l’infrastructure nécessaire, de création du cluster et de préparation du système d’exploitation à 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. Cet exemple montre 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 des systèmes SAP supplémentaires dans le cluster, déployez le premier système SAP du cluster. Il existe des étapes qui ne sont nécessaires que lors du premier déploiement du système.
Cet article suppose que vous avez :
- 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 a été 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
etNW3
) à l'instance Azure Load Balancer existante. Pour ce faire, consultez Déployer 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 le fichier /etc/hosts sur tous les nœuds. Cet exemple montre 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.52 msnw2ascs # IP address of the load balancer frontend configuration for NW3 ASCS 10.3.1.54 msnw3ascs # IP address of the load balancer frontend configuration for NW2 ERS 10.3.1.53 msnw2ers # IP address of the load balancer frontend configuration for NW3 ERS 10.3.1.55 msnw3ers
[A] Créez les répertoires partagés pour les systèmes SAP
NW2
etNW3
à déployer 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] Ajoutez les entrées de montage pour les systèmes de fichiers /sapmnt/SID et /usr/sap/SID/SYS d’autres systèmes SAP que vous déployez sur le cluster. Dans cet exemple, il s’agit de
NW2
etNW3
.Mettez à jour le fichier
/etc/fstab
avec les systèmes de fichiers pour les autres systèmes SAP que vous déployez sur le cluster.- Si vous utilisez Azure NetApp Files, suivez les instructions sur la page Haute disponibilité des machines virtuelles Azure pour SAP NW sur RHEL avec Azure NetApp File
- Si vous utilisez le cluster GlusterFS, suivez les instructions sur la page Haute disponibilité des machines virtuelles Azure pour SAP NW sur SLES
Installer ASCS/ERS
Créez l’adresse IP virtuelle et les ressources de cluster de sonde d’intégrité des instances ASCS d’autres systèmes SAP que vous déployez sur le cluster. Cet exemple utilise
NW2
etNW3
ASCS et NFS sur des volumes Azure NetApp Files avec le protocole NFSv3.sudo pcs resource create fs_NW2_ASCS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW2ascs' \ directory='/usr/sap/NW2/ASCS10' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW2_ASCS sudo pcs resource create vip_NW2_ASCS IPaddr2 \ ip=10.3.1.52 \ --group g-NW2_ASCS sudo pcs resource create nc_NW2_ASCS azure-lb port=62010 \ --group g-NW2_ASCS sudo pcs resource create fs_NW3_ASCS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW3ascs' \ directory='/usr/sap/NW3/ASCS20' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW3_ASCS sudo pcs resource create vip_NW3_ASCS IPaddr2 \ ip=10.3.1.54 \ --group g-NW3_ASCS sudo pcs resource create nc_NW3_ASCS azure-lb port=62020 \ --group g-NW3_ASCS
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] Installez 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 estmsnw2ascs
,10.3.1.52
et le numéro d’instance que vous avez utilisé pour la sonde de l’équilibreur de charge, par exemple10
. Pour le systèmeNW3
, le nom d’hôte virtuel estmsnw3ascs
,10.3.1.54
et le numéro d’instance que vous avez utilisé pour la sonde de l’équilibreur de charge, par exemple20
. Notez le nœud de cluster sur lequel vous avez installé ASCS pour chaque SID SAP.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ètreSAPINST_USE_HOSTNAME
pour installer SAP à l’aide du nom d’hôte virtuel.# Allow access to SWPM. This rule is not permanent. If you reboot the machine, you have to run the command again sudo firewall-cmd --zone=public --add-port=4237/tcp sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostname
Si aucun sous-dossier n’est créé dans /usr/sap/<SID>/ASCS<Instance#>lors de l'installation, essayez de définir le propriétaire sur <sid>adm 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. Cet exemple concerne
NW2
etNW3
ERS et utilise NFS sur des volumes Azure NetApp Files avec le protocole NFSv3.sudo pcs resource create fs_NW2_AERS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW2ers' \ directory='/usr/sap/NW2/ERS12' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW2_AERS sudo pcs resource create vip_NW2_AERS IPaddr2 \ ip=10.3.1.53 \ --group g-NW2_AERS sudo pcs resource create nc_NW2_AERS azure-lb port=62112 \ --group g-NW2_AERS sudo pcs resource create fs_NW3_AERS Filesystem device='10.42.0.4:/sapMSIDR/usrsapNW3ers' \ directory='/usr/sap/NW3/ERS22' fstype='nfs' force_unmount=safe \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-NW3_AERS sudo pcs resource create vip_NW3_AERS IPaddr2 \ ip=10.3.1.55 \ --group g-NW3_AERS sudo pcs resource create nc_NW3_AERS azure-lb port=62122 \ --group g-NW3_AERS
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
rhelmsscl1
, assurez-vous que le groupe NW2 ERS est en cours d'exécution surrhelmsscl2
. Pour migrer le groupe NW2 ERS versrhelmsscl2
, exécutez la commande suivante pour l’une des ressources de cluster du groupe :pcs resource move fs_NW2_AERS rhelmsscl2
[2] Installez 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 estmsnw2ers
,10.3.1.53
et le numéro d’instance que vous avez utilisé pour la sonde de l’équilibreur de charge, par exemple12
. Pour le systèmeNW3
, le nom d’hôte virtuel seramsnw3ers
,10.3.1.55
et le numéro d’instance que vous avez utilisé pour la sonde de l’équilibreur de charge, par exemple22
.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ètreSAPINST_USE_HOSTNAME
pour installer SAP à l’aide du nom d’hôte virtuel.# Allow access to SWPM. This rule is not permanent. If you reboot the machine, you have to run the command again sudo firewall-cmd --zone=public --add-port=4237/tcp sudo swpm/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin SAPINST_USE_HOSTNAME=virtual_hostname
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>/ERS<Instance#> lors de l'installation, essayez de définir le propriétaire sur <sid>adm 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 la contrainte en exécutant la commande suivante. Cet exemple est donné pour les systèmes SAP
NW2
etNW3
. Veillez à supprimer les contraintes temporaires de la ressource que vous avez utilisée dans la commande pour déplacer le groupe de clusters ERS.pcs resource clear fs_NW2_AERS pcs resource clear fs_NW3_AERS
[1] Adaptez les profils d’instance ASCS/SCS et ERS aux systèmes SAP récemment installés. L’exemple illustré ci-dessous correspond à
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 keep alive parameter, if using ENSA1 enque/encni/set_so_keepalive = TRUE
Pour ENSA1 et ENSA2, assurez-vous que les
keepalive
Paramè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) # remove Autostart from ERS profile # Autostart = 1
[A] Mettez à jour le fichier /usr/sap/sapservices.
Pour empêcher le démarrage des instances par le script de démarrage sapinit, toutes les instances gérées par Pacemaker doivent être commentées à partir du fichier /usr/sap/sapservices. L’exemple ci-dessous correspond aux systèmes SAP
NW2
etNW3
.# Depending on whether the SAP Startup framework is integrated with systemd, you may observe below entries on the node for ASCS instances. You should comment out the line(s). # LD_LIBRARY_PATH=/usr/sap/NW2/ASCS10/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW2/ASCS10/exe/sapstartsrv pf=/usr/sap/NW2/SYS/profile/NW2_ASCS10_msnw2ascs -D -u nw2adm # LD_LIBRARY_PATH=/usr/sap/NW3/ASCS20/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW3/ASCS20/exe/sapstartsrv pf=/usr/sap/NW3/SYS/profile/NW3_ASCS20_msnw3ascs -D -u nw3adm # systemctl --no-ask-password start SAPNW2_10 # sapstartsrv pf=/usr/sap/NW2/SYS/profile/NW2_ASCS10_msnw2ascs # systemctl --no-ask-password start SAPNW3_20 # sapstartsrv pf=/usr/sap/NW3/SYS/profile/NW3_ASCS20_msnw3ascs # Depending on whether the SAP Startup framework is integrated with systemd, you may observe below entries on the node for ERS instances. You should comment out the line(s). #LD_LIBRARY_PATH=/usr/sap/NW2/ERS12/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW2/ERS12/exe/sapstartsrv pf=/usr/sap/NW2/ERS12/profile/NW2_ERS12_msnw2ers -D -u nw2adm #LD_LIBRARY_PATH=/usr/sap/NW3/ERS22/exe:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; /usr/sap/NW3/ERS22/exe/sapstartsrv pf=/usr/sap/NW3/ERS22/profile/NW3_ERS22_msnw3ers -D -u nw3adm # systemctl --no-ask-password start SAPNW2_12 # sapstartsrv pf=/usr/sap/NW2/ERS12/profile/NW2_ERS12_msnw2ers # systemctl --no-ask-password start SAPNW3_22 # sapstartsrv pf=/usr/sap/NW3/ERS22/profile/NW3_ERS22_msnw3ers
Important
Avec le SAP Startup Framework basé sur systemd, les instances SAP peuvent désormais être gérées par systemd. La version minimale requise de Red Hat Enterprise Linux (RHEL) est RHEL 8 pour SAP. Comme décrit dans la note SAP 3115048, une nouvelle installation d’un noyau SAP avec prise en charge de SAP Startup Framework basée sur le système intégré entraîne toujours une instance SAP contrôlée par le système. Après une mise à niveau du noyau SAP d’une installation SAP existante vers un noyau qui a la prise en charge de SAP Startup Framework basée sur le système, toutefois, certaines étapes manuelles doivent être effectuées comme documentées dans la note SAP 3115048 pour convertir l’environnement de démarrage SAP existant en un environnement contrôlé par le système.
Lors de l'utilisation des services Red Hat HA pour SAP (configuration en grappe) pour gérer les instances de serveurs d'applications SAP telles que SAP ASCS et SAP ERS, des modifications supplémentaires seront nécessaires pour assurer la compatibilité entre l'agent de ressources SAPInstance et le nouveau cadre de démarrage SAP basé sur systemd. Par conséquent, une fois que les instances de serveur d’applications SAP ont été installées ou basculées vers un noyau SAP activé par le système conformément à la note SAP 3115048, les étapes mentionnées dans Red Hat KBA 6884531 doivent être effectuées avec succès sur tous les nœuds de cluster.
[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 SAP
NW2
etNW3
de la manière suivante. 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 pour la prise en charge du serveur de file d’attente 2.Si vous utilisez l’architecture du serveur de mise en file d’attente 2 (ENSA2), installez l’agent de ressources resource-agents-sap-4.1.1-12.el7.x86_64 ou version ultérieure et définissez les ressources pour les systèmes SAP
NW2
etNW3
de la manière suivante :sudo pcs property set maintenance-mode=true sudo pcs resource create rsc_sap_NW2_ASCS10 SAPInstance \ InstanceName=NW2_ASCS10_msnw2ascs START_PROFILE="/sapmnt/NW2/profile/NW2_ASCS10_msnw2ascs" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 migration-threshold=1 failure-timeout=60 \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW2_ASCS sudo pcs resource meta g-NW2_ASCS resource-stickiness=3000 sudo pcs resource create rsc_sap_NW2_ERS12 SAPInstance \ InstanceName=NW2_ERS12_msnw2ers START_PROFILE="/sapmnt/NW2/profile/NW2_ERS12_msnw2ers" \ AUTOMATIC_RECOVER=false IS_ERS=true \ op monitor interval=20 on-fail=restart timeout=60 op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW2_AERS sudo pcs constraint colocation add g-NW2_AERS with g-NW2_ASCS -5000 sudo pcs constraint location rsc_sap_NW2_ASCS10 rule score=2000 runs_ers_NW2 eq 1 sudo pcs constraint order start g-NW2_ASCS then stop g-NW2_AERS kind=Optional symmetrical=false sudo pcs resource create rsc_sap_NW3_ASCS20 SAPInstance \ InstanceName=NW3_ASCS20_msnw3ascs START_PROFILE="/sapmnt/NW3/profile/NW3_ASCS20_msnw3ascs" \ AUTOMATIC_RECOVER=false \ meta resource-stickiness=5000 migration-threshold=1 failure-timeout=60 \ op monitor interval=20 on-fail=restart timeout=60 \ op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW3_ASCS sudo pcs resource meta g-NW3_ASCS resource-stickiness=3000 sudo pcs resource create rsc_sap_NW3_ERS22 SAPInstance \ InstanceName=NW3_ERS22_msnw3ers START_PROFILE="/sapmnt/NW3/profile/NW2_ERS22_msnw3ers" \ AUTOMATIC_RECOVER=false IS_ERS=true \ op monitor interval=20 on-fail=restart timeout=60 op start interval=0 timeout=600 op stop interval=0 timeout=600 \ --group g-NW3_AERS sudo pcs constraint colocation add g-NW3_AERS with g-NW3_ASCS -5000 sudo pcs constraint location rsc_sap_NW3_ASCS20 rule score=2000 runs_ers_NW3 eq 1 sudo pcs constraint order start g-NW3_ASCS then stop g-NW3_AERS kind=Optional symmetrical=false sudo pcs property set maintenance-mode=false
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.
Notes
Les délais d’expiration de la configuration ci-dessus sont simplement des exemples et doivent être adaptés à la configuration SAP spécifique.
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
etNW3
au cluster.sudo pcs status # Online: [ rhelmsscl1 rhelmsscl2 ] # Full list of resources: # rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 # Resource Group: g-NW1_ASCS # fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW1_AERS # fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 # vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 # nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 # rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 # Resource Group: g-NW2_ASCS # fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW2_AERS # fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW3_ASCS # fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 # Resource Group: g-NW3_AERS # fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 # vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 # nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 # rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl1
[A] Ajoutez des règles de pare-feu pour ASCS et ERS sur les deux nœuds. L’exemple ci-dessous montre celles des systèmes SAP
NW2
etNW3
.# NW1 - ASCS sudo firewall-cmd --zone=public --add-port={62010,3210,3610,3910,8110,51013,51014,51016}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62010,3210,3610,3910,8110,51013,51014,51016}/tcp # NW2 - ERS sudo firewall-cmd --zone=public --add-port={62112,3212,3312,51213,51214,51216}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62112,3212,3312,51213,51214,51216}/tcp # NW3 - ASCS sudo firewall-cmd --zone=public --add-port={62020,3220,3620,3920,8120,52013,52014,52016}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62020,3220,3620,3920,8120,52013,52014,52016}/tcp # NW3 - ERS sudo firewall-cmd --zone=public --add-port={62122,3222,3322,52213,52214,52216}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62122,3222,3322,52213,52214,52216}/tcp
Poursuivre l’installation de SAP
Finalisez votre installation SAP en procédant comme suit :
- Préparez vos serveurs d'applications SAP NetWeaver.
- Installez une instance SGBD.
- Installez un serveur d’applications SAP principal.
- Installez une ou plusieurs autres instances d’application SAP.
Tester la configuration de cluster multi-SID
Les tests suivants représentent une partie des cas de test des guides des meilleures pratiques de Red Hat. 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 des volumes NFS Azure NetApp Files, consultez Haute disponibilité des machines virtuelles Azure pour SAP NetWeaver sur RHEL avec Azure NetApp Files for SAP Applications.
- Si vous utilisez un cluster
GlusterFS
hautement disponible, consultez Haute disponibilité des machines virtuelles Azure pour SAP NetWeaver sur RHEL for SAP Applications.
Consultez systématiquement les guides des meilleures pratiques Red Hat et effectuez tous les tests qui y sont ajoutés. Les tests présentés se trouvent dans un cluster à deux nœuds, multi-SID, avec trois systèmes SAP installés.
Migrer manuellement l’instance ASCS L’exemple montre comment migrer l’instance ASCS pour le système SAP NW3.
État des ressources avant le début du test :
Online: [ rhelmsscl1 rhelmsscl2 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl1
Exécutez les commandes suivantes en tant que racine pour migrer l’instance NW3 ASCS.
pcs resource move rsc_sap_NW3_ASCS200 # Clear temporary migration constraints pcs resource clear rsc_sap_NW3_ASCS20 # Remove failed actions for the ERS that occurred as part of the migration pcs resource cleanup rsc_sap_NW3_ERS22
État des ressources après le test :
Online: [ rhelmsscl1 rhelmsscl2 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl2
Simulez l’incident de nœud.
État des ressources avant le début du test :
Online: [ rhelmsscl1 rhelmsscl2 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl1 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl2
Exécutez la commande suivante en tant que racine sur un nœud où au moins une instance ASCS est en cours d’exécution. Cet exemple exécute la commande sur
rhelmsscl1
, où les instances ASCS pourNW1
,NW2
etNW3
sont en cours d’exécution.echo c > /proc/sysrq-trigger
L'état après le test et après le redémarrage du nœud qui a rencontré un problème, devrait ressembler à ces résultats :
Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started rhelmsscl2 Resource Group: g-NW1_ASCS fs_NW1_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW1_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW1_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW1_AERS fs_NW1_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW1_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW1_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW1_ERS02 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW2_ASCS fs_NW2_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW2_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW2_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW2_ASCS10 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW2_AERS fs_NW2_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW2_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW2_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW2_ERS12 (ocf::heartbeat:SAPInstance): Started rhelmsscl1 Resource Group: g-NW3_ASCS fs_NW3_ASCS (ocf::heartbeat:Filesystem): Started rhelmsscl2 vip_NW3_ASCS (ocf::heartbeat:IPaddr2): Started rhelmsscl2 nc_NW3_ASCS (ocf::heartbeat:azure-lb): Started rhelmsscl2 rsc_sap_NW3_ASCS20 (ocf::heartbeat:SAPInstance): Started rhelmsscl2 Resource Group: g-NW3_AERS fs_NW3_AERS (ocf::heartbeat:Filesystem): Started rhelmsscl1 vip_NW3_AERS (ocf::heartbeat:IPaddr2): Started rhelmsscl1 nc_NW3_AERS (ocf::heartbeat:azure-lb): Started rhelmsscl1 rsc_sap_NW3_ERS22 (ocf::heartbeat:SAPInstance): Started rhelmsscl1
S’il y a des messages d’échec pour certaines ressources, nettoyez l’état de ces ressources. Par exemple :
pcs resource cleanup rsc_sap_NW1_ERS02
É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.