SAP NetWeaver à haute disponibilité avec montage simple et NFS sur SLES pour les machines virtuelles d’applications SAP

Article
07/25/2024

Cet article décrit comment déployer et configurer des machines virtuelles Azure, installer l’infrastructure du cluster et installer un système SAP NetWeaver à haute disponibilité (HA) avec une structure de montage simple. Vous pouvez implémenter l’architecture présentée à l’aide de l’un des services de système de fichiers réseau (NFS) natifs Azure suivants :

La configuration de montage simple est censée être la valeur par défaut pour les nouvelles implémentations sur SLES for les applications SAP 15.

Prérequis

Les guides suivants contiennent toutes les informations requises pour configurer un système HA NetWeaver :

SAP S/4 HANA - Mise en file d’attente du cluster à haute disponibilité 2 de réplication avec montage simple
L’utilisation d’une ressource de système de fichiers pour la configuration de services centraux SAP ABAP (ASCS)/ERS HA n’est pas possible
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
- Logiciels SAP, systèmes d’exploitation et combinaisons pris en charge
- la version du noyau SAP requise pour Windows et Linux sur Microsoft Azure
La note SAP 2015553, qui répertorie les conditions préalables au déploiement de logiciels SAP pris en charge par SAP dans Azure.
La note SAP 2205917, qui contient des paramètres de système d’exploitation recommandés pour SUSE Linux Enterprise Server (SLES) pour les applications SAP
La note SAP 2178632, qui contient des informations détaillées sur toutes les métriques de surveillance rapportées pour SAP dans Azure
La note SAP 2191498, qui contient la version requise de l’agent hôte SAP pour Linux dans Azure
La note SAP 2243692, qui contient des informations sur les licences SAP sur Linux dans Azure
La note SAP 2578899, qui contient des informations sur SUSE Linux Enterprise Server 15
La note SAP 1275776, qui contient des informations sur la préparation de SUSE Linux Enterprise Server pour les environnements SAP
La note SAP 1999351, qui contient des informations de résolution des problèmes supplémentaires pour l’extension d’analyse Azure améliorée pour SAP
Le Wiki de la communauté SAP, qui contient toutes les notes SAP nécessaires 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 de haute disponibilité SAP pour SUSE
Notes de publication de SUSE High Availability Extension
Documentation Azure Files
Meilleures pratiques de NetApp NFS

Vue d’ensemble

Cet article décrit une configuration de haute disponibilité pour ASCS avec une structure de montage simple. Pour déployer la couche d’application SAP, vous avez besoin de répertoires partagés comme /sapmnt/SID, /usr/sap/SID et /usr/sap/trans qui sont hautement disponibles. Vous pouvez déployer ces systèmes de fichiers sur NFS sur Azure Files ou Azure NetApp Files.

Vous avez quand même besoin d’un cluster Pacemaker pour protéger les composants à point de défaillance unique comme les services centraux SAP (SCS) et ASCS.

Par rapport à la configuration classique du cluster Pacemaker, avec le déploiement de montage simple, le cluster ne gère pas les systèmes de fichiers. Cette configuration est prise en charge uniquement sur SLES pour les applications SAP 15 et ultérieures. Cet article ne couvre pas la couche de base de données en détail.

Les exemples de configurations et les commandes d’installation utilisent les numéros d’instance suivants.

Nom de l’instance	Numéro d’instance
ASCS	00
Serveur de réplication en file d’attente (ERS)	01
Server d’applications principal (PAS)	02
Serveur d’applications supplémentaire (AAS)	03
Identificateur système SAP	NW1

Important

La configuration avec une structure de montage simple est prise en charge uniquement sur SLES pour les applications SAP 15 et versions ultérieures.

Diagramme illustrant la haute disponibilité SAP NetWeaver avec montage simple et NFS.

Préparer l’infrastructure

L’agent de ressource pour SAP Instance est inclus dans SUSE Linux Enterprise Server for SAP Applications. Une image pour SUSE Linux Enterprise Server for SAP Applications 12 ou 15 est disponible sur la Place de marché Azure. Vous pouvez utiliser l’image pour déployer de nouvelles machines virtuelles.

Déployer manuellement des machines virtuelles Linux via le portail Azure

Ce document part du principe que vous avez déjà déployé un groupe de ressources, un réseau virtuel Azure et un sous-réseau.

Déployez des machines virtuelles avec l’image SLES for SAP Applications. Choisissez une version appropriée de l’image SLES prise en charge pour le système SAP. Vous pouvez déployer une machine virtuelle dans n’importe laquelle des options de disponibilité : groupe de machines virtuelles identiques, zone de disponibilité ou groupe à haute disponibilité.

Configurer l’équilibrage de charge Azure

Pendant la configuration de la machine virtuelle, vous avez la possibilité de créer ou de sélectionner un équilibreur de charge existant dans la section réseau. Suivez les étapes ci-dessous pour configurer un équilibreur de charge standard pour la configuration à haute disponibilité de SAP ASCS et SAP ERS.

Suivez le guide Créer un équilibreur de charge afin de configurer un équilibreur de charge standard pour un système SAP à haute disponibilité à l’aide du portail Azure. Pendant la configuration de l’équilibreur de charge, tenez compte des points suivants.

Configuration de l’IP front-end : créez deux adresses IP front-end, une pour ASCS et une autre pour ERS. Sélectionnez le même réseau virtuel et le même sous-réseau que vos machines virtuelles ASCS/ERS.
Pool de back-ends : créez un pool de back-ends et ajoutez des machines virtuelles ASCS et ERS.
Règles de trafic entrant : créez deux règles d’équilibrage de charge, une pour ASCS et une autre pour ERS. Suivez les mêmes étapes pour les deux règles d’équilibrage de charge.
- Adresse IP front-end : sélectionner l’adresse IP front-end
- Pool de back-ends : sélectionner un pool de back-ends
- Cocher « Ports à haute disponibilité »
- Protocole : TCP
- Sonde d’intégrité : créer une sonde d’intégrité avec les détails ci-dessous (s’applique à ASCS ou ERS)
  - Protocole : TCP
  - Port : [par exemple : 620<numéro d’instance> for ASCS, 621<numéro d’instance> pour ERS]
  - Intervalle : 5
  - Seuil de la sonde : 2
- Délai d’inactivité (minutes) : 30
- Cocher « Activer l’adresse IP flottante »

Remarque

La propriété de configuration de la sonde d’intégrité numberOfProbes, appelé « Seuil de défaillance d’intégrité » dans le portail, n’est pas respectée. Donc, pour contrôler le nombre de sondes consécutives qui ont réussi ou échoué, définissez la propriété « probeThreshold » sur 2. Il n’est actuellement pas possible de définir cette propriété dans le portail Azure, donc utilisez l’interface Azure CLI ou une commande PowerShell.

Pour créer un équilibreur de charge standard Azure pour une configuration à haute disponibilité du système SAP à l’aide d’Azure CLI, suivez les étapes ci-dessous.

# Create the load balancer resource and another frontend IP resource for ERS. Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address.
az network lb create -g MyResourceGroup -n MyLB --sku Standard --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet --backend-pool-name MyBackendPool --frontend-ip-name MyASCSFrontendIpName
az network lb frontend-ip create -g MyResourceGroup --lb-name MyLB -n MyERSFrontendIpName --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet

# Create the health probe for ASCS and ERS
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyASCSHealthProbe --protocol tcp --port MyASCSHealthProbePort --interval 5 --probe-threshold 2
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyERSHealthProbe --protocol tcp --port MyERSHealthProbePort --interval 5 --probe-threshold 2
 
# Create load balancing rule for ASCS and ERS
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyASCSRuleName --protocol All --frontend-ip-name MyASCSFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyASCSHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip 
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyERSRuleName --protocol All --frontend-ip-name MyERSFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyERSHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip  

# Add ASCS and ERS VMs in backend pool
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name ASCSVmIpConfigName --nic-name ASCSVmNicName -g MyResourceGroup --lb-name MyLB
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name ERSVmIpConfigName --nic-name ERSVmNicName -g MyResourceGroup --lb-name MyLB

Développer pour afficher l’intégralité du code CLI

# Define variables for Resource Group, ASCS/ERS VMs.

rg_name="resourcegroup-name"
vm1_name="ascs-vm-name"
vm2_name="ers-vm-name"

# Define variables for the load balancer that will be use in the creation of the load balancer resource.

lb_name="sap-ci-sid-ilb"
bkp_name="ascs-ers-backendpool"
ascs_fip_name="ascs-frontendip"
ers_fip_name="ers-frontendip"

ascs_hp_name="ascs-healthprobe"
ascs_hp_port="62000"
ers_hp_name="ers-healthprobe"
ers_hp_port="62101"

ascs_rule_name="ascs-lb-rule"
ers_rule_name="ers-lb-rule"
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name.
 
vm1_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm1_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm1_nic_name=$(basename $vm1_primary_nic)
vm1_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm1_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vm2_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm2_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm2_nic_name=$(basename $vm2_primary_nic)
vm2_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm2_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vnet_subnet_id=$(az network nic show -g $rg_name -n $vm1_nic_name --query ipConfigurations[0].subnet.id -o tsv)
vnet_name=$(basename $(dirname $(dirname $vnet_subnet_id)))
subnet_name=$(basename $vnet_subnet_id)
 
# Create the load balancer resource and another frontend IP resource for ERS.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address. 
  
az network lb create -g $rg_name -n $lb_name --sku Standard --vnet-name $vnet_name --subnet $subnet_name --backend-pool-name $bkp_name --frontend-ip-name $ascs_fip_name
az network lb frontend-ip create -g $rg_name --lb-name $lb_name -n $ers_fip_name --vnet-name $vnet_name --subnet $subnet_name
 
# Create the health probe for ASCS and ERS
 
az network lb probe create -g $rg_name --lb-name $lb_name -n $ascs_hp_name --protocol tcp --port $ascs_hp_port --interval 5 --probe-threshold 2
az network lb probe create -g $rg_name --lb-name $lb_name -n $ers_hp_name --protocol tcp --port $ers_hp_port --interval 5 --probe-threshold 2
 
# Create load balancing rule for ASCS and ERS
  
az network lb rule create -g $rg_name --lb-name $lb_name -n  $ascs_rule_name --protocol All --frontend-ip-name $ascs_fip_name --frontend-port 0 --backend-pool-name $bkp_name --backend-port 0 --probe-name $ascs_hp_name --idle-timeout-in-minutes 30 --enable-floating-ip 
az network lb rule create -g $rg_name --lb-name $lb_name -n  $ers_rule_name --protocol All --frontend-ip-name $ers_fip_name --frontend-port 0 --backend-pool-name $bkp_name --backend-port 0 --probe-name $ers_hp_name --idle-timeout-in-minutes 30 --enable-floating-ip 
 
# Add ASCS and ERS VMs in backend pool
 
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm1_ipconfig --nic-name $vm1_nic_name -g $rg_name --lb-name $lb_name
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm2_ipconfig --nic-name $vm2_nic_name -g $rg_name --lb-name $lb_name

# [OPTIONAL] Change the assignment of frontend IP address from dynamic to static
afip=$(az network lb frontend-ip show --lb-name $lb_name -g $rg_name -n $ascs_fip_name --query "{privateIPAddress:privateIPAddress}" -o tsv)
az network lb frontend-ip update --lb-name $lb_name -g $rg_name -n $ascs_fip_name --private-ip-address $afip

efip=$(az network lb frontend-ip show --lb-name $lb_name -g $rg_name -n $ers_fip_name --query "{privateIPAddress:privateIPAddress}" -o tsv)
az network lb frontend-ip update --lb-name $lb_name -g $rg_name -n $ers_fip_name --private-ip-address $efip

Pour créer un équilibreur de charge standard Azure pour une configuration à haute disponibilité du système SAP à l’aide d’Azure PowerShell, suivez les étapes ci-dessous.

# Create frontend IP configurations
$ascs_fip = New-AzLoadBalancerFrontendIpConfig -Name MyASCSFrontendIpName -SubnetId MyASCSSubnetName
$ers_fip = New-AzLoadBalancerFrontendIpConfig -Name MyERSFrontendIpName -SubnetId MyERSSubnetName

# Create backend pool
$bePool = New-AzLoadBalancerBackendAddressPoolConfig -Name MyBackendPool

# Create health probes for ASCS and ERS
$ascs_healthprobe = New-AzLoadBalancerProbeConfig -Name MyASCSHealthProbe -Protocol 'tcp' -Port MyASCSHealthProbePort -IntervalInSeconds 5 -ProbeThreshold 2 -ProbeCount 1
$ers_healthprobe = New-AzLoadBalancerProbeConfig -Name $ers_hp_name -Protocol 'tcp' -Port MyASCSHealthProbePort -IntervalInSeconds 5 -ProbeThreshold 2 -ProbeCount 1

# Create load balancing rules for ASCS and ERS
$ascs_rule = New-AzLoadBalancerRuleConfig -Name MyASCSRuleName -Probe $ascs_healthprobe -Protocol 'All' -IdleTimeoutInMinutes 30 -FrontendIpConfiguration $ascs_fip -BackendAddressPool $bePool -EnableFloatingIP
$ers_rule = New-AzLoadBalancerRuleConfig -Name MyERSRuleName -Probe $ers_healthprobe -Protocol 'All' -IdleTimeoutInMinutes 30 -FrontendIpConfiguration $ers_fip -BackendAddressPool $bePool -EnableFloatingIP

# Create the load balancer resource
$lb = New-AzLoadBalancer -ResourceGroupName MyResourceGroup -Name MyLB -Location MyRegion -Sku 'Standard' -FrontendIpConfiguration $ascs_fip, $ers_fip -BackendAddressPool $bePool -LoadBalancingRule $ascs_rule, $ers_rule -Probe $ascs_healthprobe, $ers_healthprobe

Développer pour afficher l’intégralité du code PowerShell

# Define variables for Resource Group, and Database VMs.

$rg_name = 'resourcegroup-name'
$vm1_name = 'ascs-vm-name'
$vm2_name = 'ers-vm-name'

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

$lb_name = 'sap-ci-sid-ilb'
$bkp_name = 'ascs-ers-backendpool'
$ascs_fip_name = 'ascs-frontendip'
$ers_fip_name = 'ers-frontendip'
 
$ascs_hp_name = 'ascs-healthprobe'
$ascs_hp_port = '62000'
$ers_hp_name = 'ers-healthprobe'
$ers_hp_port = '62101'
 
$ascs_rule_name = 'ascs-lb-rule'
$ers_rule_name = 'ers-lb-rule'
 
# Command to get VMs network information like NIC name, IP configuration name, Virtual Network name, and Subnet 
 
$vm1 = Get-AzVM -ResourceGroupName $rg_name -Name $vm1_name
$vm1_primarynic = $vm1.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm1_nic_name = $vm1_primarynic.Id.Split('/')[-1]
 
$vm1_nic_info = Get-AzNetworkInterface -Name $vm1_nic_name -ResourceGroupName $rg_name
$vm1_primaryip = $vm1_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm1_ipconfig_name = ($vm1_primaryip).Name
 
$vm2 = Get-AzVM -ResourceGroupName $rg_name -Name $vm2_name
$vm2_primarynic = $vm2.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm2_nic_name = $vm2_primarynic.Id.Split('/')[-1]
 
$vm2_nic_info = Get-AzNetworkInterface -Name $vm2_nic_name -ResourceGroupName $rg_name
$vm2_primaryip = $vm2_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm2_ipconfig_name = ($vm2_primaryip).Name
 
$vnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-3]
$subnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-1]
$location = $vm1.Location
 
# Create frontend IP resource for ASCS and ERS.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter -PrivateIpAddress
 
$ascs_lb_fip = @{
    Name = $ascs_fip_name
    SubnetId = $vm1_primaryip.Subnet.Id
}
$ascs_fip = New-AzLoadBalancerFrontendIpConfig @ascs_lb_fip
 
$ers_lb_fip = @{
    Name = $ers_fip_name
    SubnetId = $vm2_primaryip.Subnet.Id
}
$ers_fip = New-AzLoadBalancerFrontendIpConfig @ers_lb_fip

# Create backend pool
 
$bepool = New-AzLoadBalancerBackendAddressPoolConfig -Name $bkp_name

# Create the health probe for ASCS and ERS
 
$ascs_probe = @{
    Name = $ascs_hp_name
    Protocol = 'tcp'
    Port = $ascs_hp_port
    IntervalInSeconds = '5'
    ProbeThreshold = '2'
    ProbeCount = '1'
}
$ascs_healthprobe = New-AzLoadBalancerProbeConfig @ascs_probe
    
$ers_probe = @{
    Name = $ers_hp_name
    Protocol = 'tcp'
    Port = $ers_hp_port
    IntervalInSeconds = '5'
    ProbeThreshold = '2'
    ProbeCount = '1'
}
$ers_healthprobe = New-AzLoadBalancerProbeConfig @ers_probe

# Create load balancing rule for ASCS and ERS
 
$ascs_lbrule = @{
    Name = $ascs_rule_name
    Probe = $ascs_healthprobe
    Protocol = 'All'
    IdleTimeoutInMinutes = '30'
    FrontendIpConfiguration = $ascs_fip
    BackendAddressPool = $bePool 
} 
$ascs_rule = New-AzLoadBalancerRuleConfig @ascs_lbrule -EnableFloatingIP 
 
$ers_lbrule = @{
    Name = $ers_rule_name
    Probe = $ers_healthprobe
    Protocol = 'All'
    IdleTimeoutInMinutes = '30'
    FrontendIpConfiguration = $ers_fip
    BackendAddressPool = $bePool 
} 
$ers_rule = New-AzLoadBalancerRuleConfig @ers_lbrule -EnableFloatingIP

# Create the load balancer resource
 
$loadbalancer = @{
    ResourceGroupName = $rg_name
    Name = $lb_name
    Location = $location
    Sku = 'Standard'
    FrontendIpConfiguration = $ascs_fip,$ers_fip
    BackendAddressPool = $bePool 
    LoadBalancingRule = $ascs_rule,$ers_rule
    Probe = $ascs_healthprobe,$ers_healthprobe 
} 
$lb = New-AzLoadBalancer @loadbalancer

# Add ASCS and ERS VMs in backend pool of load balanceer
 
$vm1_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm2_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm1_nic_info | Set-AzNetworkInterface
$vm2_nic_info | Set-AzNetworkInterface

Remarque

Lorsque des machines virtuelles sans adresse IP publique sont placées dans le pool principal d’un équilibreur Azure Standard interne (aucune adresse IP publique), il n’y a pas de connectivité Internet sortante, sauf si vous effectuez une configuration supplémentaire pour autoriser le routage vers des points de terminaison publics. Pour savoir plus en détails comment bénéficier d’une connectivité sortante, consultez 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 ?.

Déployer NFS

Il existe deux options pour déployer Azure Native NFS pour héberger les répertoires partagés SAP. Vous pouvez déployer un partage de fichiers NFS sur Azure Files ou déployer un volume NFS sur Azure NetApp Files. NFS sur Azure Files prend en charge le protocole NFSv4.1. NFS sur Azure NetApp Files prend en charge NFSv4.1 et NFSv3.

Les sections suivantes décrivent les étapes à suivre pour déployer NFS. Sélectionnez une seule des options.

Déployer un compte de stockage Azure Files et des partages NFS

NFS sur Azure Files s’exécute sur un stockage Azure Files Premium. Avant de configurer NFS sur Azure Files, consultez Comment créer un partage NFS.

Il existe deux options de redondance au sein d’une région Azure :

Stockage localement redondant (LRS) offre une réplication de données locale, dans la zone et synchrone.
Stockage redondant interzone (ZRS) réplique vos données de façon synchrone dans les trois zones de disponibilité de la région.

Vérifiez si votre région Azure sélectionnée propose NFSv4.1 sur Azure Files avec la redondance appropriée. Passez en revue la disponibilité d’Azure Files par région Azure pour Stockage Fichier Premium. Si votre scénario bénéficie de ZRS, vérifiez que les partages de fichiers Premium avec ZRS sont pris en charge dans votre région Azure.

Nous vous recommandons d’accéder à votre compte de stockage Azure par le biais d’un point de terminaison privé Azure. Veillez à déployer le point de terminaison du compte de stockage Azure Files, ainsi que les machines virtuelles sur lesquels vous devez monter les partages NFS, dans le même réseau virtuel Azure ou dans des réseaux virtuels Azure appairés.

Déployez un compte de stockage Azure Files nommé sapnfsafs. Cet exemple utilise ZRS. Si vous ne connaissez pas bien le processus, consultez Créer un compte de stockage dans le portail Azure.
Sous l’onglet Informations de base, utilisez ces paramètres :
1. Pour Nom du compte de stockage, entrez sapnfsafs.
2. Pour Performances, sélectionnez Premium.
3. Pour Type de compte Premium, sélectionnez FileStorage.
4. Pour Réplication, sélectionnez Redondance de zone (ZRS).
Sélectionnez Suivant.
Sous l’onglet Avancé, désactivez Exiger un transfert sécurisé pour API REST. Si vous ne désactivez pas cette option, vous ne pouvez pas monter le partage NFS sur votre machine virtuelle. L’opération de montage expirera.
Cliquez sur Suivant.
Dans la section Mise en réseau, configurez ces paramètres :
1. Sous Connectivité réseau, pour Méthode de connectivité, sélectionnez Point de terminaison privé.
2. Sous Point de terminaison privé, sélectionnez Ajouter un point de terminaison privé.
Dans le volet Créer un point de terminaison privé, sélectionnez vos abonnement, groupe de ressources et emplacement. Effectuez ensuite les sélections suivantes :
1. Pour Nom, entrez sapnfsafs_pe.
2. Pour Sous-ressource de stockage, sélectionnez fichier.
3. Sous Mise en réseau, pour Réseau virtuel, sélectionnez le réseau virtuel et le sous-réseau à utiliser. Là encore, vous pouvez utiliser le réseau virtuel où vos machines virtuelles SAP se trouvent ou un réseau virtuel appairé.
4. Sous Intégration de DNS privé, acceptez l’option par défaut Oui pour Intégrer à une zone DNS privée. Veillez à sélectionner votre zone DNS privée.
5. Sélectionnez OK.
Encore sous l’onglet Mise en réseau, sélectionnez Suivant.
Sous l’onglet Protection des données, conservez tous les paramètres par défaut.
Sélectionnez Vérifier + créer pour valider votre configuration.
Attendez que la validation se termine. Corrigez les problèmes avant de continuer.
Sous l’onglet Review + create (Vérifier + créer) , sélectionnez Créer.

Ensuite, déployez les partages NFS dans le compte de stockage que vous avez créé. Dans cet exemple, il existe deux partages NFS, sapnw1 et saptrans.

Connectez-vous au portail Azure.
Sélectionnez ou recherchez des comptes de Stockage.
Dans la page Comptes de stockage, sélectionnez sapafsnfs.
Dans le menu de ressource pour sapafsnfs, sélectionnez Partages de fichiers sous Stockage de données.
Dans la page Partages de fichiers, sélectionnez Partage de fichiers, puis :
1. Pour Nom, entrez sapnw1, saptrans.
2. Sélectionnez une taille de partage appropriée. Tenez compte de la taille des données stockées sur le partage, des besoins en termes d’E/S par seconde (IOPS) et de débit. Pour plus d’informations, consultez Cibles des partages de fichiers Azure.
3. Sélectionnez le protocole NFS.
4. Sélectionnez Pas de Squash racine. Sinon, quand vous montez les partages sur vos machines virtuelles, vous ne pouvez pas voir le propriétaire ou le groupe du fichier.

Les systèmes de fichiers SAP qui n’ont pas besoin d’être montés par le biais de NFS peuvent également être déployés sur un stockage sur disque Azure. Dans cet exemple, vous pouvez déployer /usr/sap/NW1/D02 et /usr/sap/NW1/D03 sur un stockage sur disque Azure.

Considérations importantes pour NFS sur des partages Azure Files

Lorsque vous planifiez votre déploiement avec NFS sur Azure Files, tenez compte des points importants suivants :

La taille de partage minimale s’élève à 100 gibioctets (Gio). Vous payez uniquement pour la capacité des partages approvisionnés.
Dimensionnez vos partages NFS non seulement en fonction de vos besoins en capacité, mais aussi de vos besoins en termes d’IOPS et de débit. Pour plus d’informations, consultez Cibles des partages de fichiers Azure.
Testez la charge de travail pour valider votre dimensionnement et vérifier que vos objectifs de performances sont atteints. Pour savoir comment résoudre les problèmes de performances avec NFS sur Azure Files, consultez Résoudre les problèmes de performances de partage de fichiers Azure.
Pour les systèmes SAP J2EE, placer /usr/sap/<SID>/J<nr> sur NFS sur Azure Files n’est pas pris en charge.
Si votre système SAP a une charge importante de programmes de traitement par lots, vous risquez d’avoir des millions de journaux de travaux. Si les journaux des programmes de traitement par lots SAP sont stockés dans le système de fichiers, portez une attention particulière au dimensionnement du partage sapmnt. À partir de SAP_BASIS 7.52, le comportement par défaut des journaux des programmes de traitement par lots doit être stocké dans la base de données. Pour plus d’informations, consultez Journal des travaux dans la base de données.
Déployez un partage sapmnt distinct pour chaque système SAP.
N’utilisez pas le partage sapmnt pour une autre activité, comme des interfaces.
N’utilisez pas le partage saptrans pour une autre activité, comme des interfaces.
Évitez de regrouper les partages d’un trop grand nombre de systèmes SAP dans un seul compte de stockage. Il existe également des objectifs de performance et de scalabilité pour les comptes de stockage. Veillez à ne pas dépasser les limites du compte de stockage, également.
En général, ne regroupez pas les partages de plus de cinq systèmes SAP dans un seul compte de stockage. Cette règle vous permet d’éviter de dépasser les limites de comptes de stockage et de simplifier l’analyse des performances.
En général, évitez de mélanger des partages tels que sapmnt pour les systèmes SAP hors production et de production dans le même compte de stockage.
Nous vous recommandons de déployer sur SLES 15 SP2 ou version ultérieure pour tirer parti des améliorations apportées aux clients NFS.
Utilisez un point de terminaison privé. Dans l’éventualité peu probable d’une défaillance zonale, vos sessions NFS sont automatiquement redirigées vers une zone saine. Vous n’avez pas besoin de remonter les partages NFS sur vos machines virtuelles.
Si vous déployez vos machines virtuelles sur des zones de disponibilité, utilisez un compte de stockage avec ZRS dans les régions Azure qui prennent en charge ZRS.
Azure Files ne prend actuellement pas en charge la réplication interrégionale automatique pour les scénarios de reprise d’activité après sinistre.

Déployer des ressources Azure NetApp Files

Vérifiez si le service Azure NetApp Files est disponible dans la région de votre choix.
Créez le compte NetApp dans la région Azure sélectionnée. Suivez ces instructions.
Configurez le pool de capacité Azure NetApp Files. Suivez ces instructions.

L’architecture de SAP NetWeaver présentée dans cet article utilise un seul pool de capacité Azure NetApp Files, référence SKU Premium. Nous vous recommandons la référence SKU Premium d’Azure NetApp Files pour les charges de travail applicatives de SAP NetWeaver sur Azure.
Déléguez un sous-réseau vers Azure NetApp Files, comme décrit dans ces instructions.
Déployez des volumes Azure NetApp Files en suivant ces instructions. Déployez les volumes dans le sous-réseau Azure NetApp Files désigné. Les adresses IP des volumes Azure NetApp sont attribuées automatiquement.

Gardez à l’esprit que les ressources Azure NetApp Files et les machines virtuelles Azure doivent être dans le même réseau virtuel Azure ou dans des réseaux virtuels Azure appairés. Cet exemple utilise deux volumes Azure NetApp Files : sapnw1 et trans. Les chemins d’accès de fichier montés sur les points de montage correspondants sont les suivants :
- Volume sapnw1 (nfs://10.27.1.5/sapnw1/sapmntNW1)
- Volume sapnw1 (nfs://10.27.1.5/sapnw1/usrsapNW1)
- Volume trans (nfs://10.27.1.5/trans)

Les systèmes de fichiers SAP qui n’ont pas besoin d’être montés par le biais de NFS peuvent également être déployés sur un stockage sur disque Azure. Par exemple, /usr/sap/NW1/D02 et /usr/sap/NW1/D03 peuvent être déployés en tant que stockage disque Azure.

Considérations importantes pour NFS sur Azure NetApp Files

Lorsque vous envisagez d’utiliser Azure NetApp Files pour l’architecture à haute disponibilité SAP NetWeaver, tenez compte des considérations importantes suivantes :

La taille de pool de capacité minimale est de 4 tébioctets (Tio). Vous pouvez augmenter la taille du pool de capacité par incréments de 1 Tio.
Le volume minimal est de 100 Gio.
Azure NetApp Files et toutes les machines virtuelles, où des volumes Azure NetApp Files sont montés, doivent se trouver dans le même réseau virtuel Azure ou dans des réseaux virtuels appairés de la même région. L’accès à Azure NetApp Files par l’appairage de réseaux virtuels dans la même région est pris en charge. L’accès à Azure NetApp Files via le Peering mondial n’est pas encore pris en charge.
Le réseau virtuel sélectionné doit avoir un sous-réseau délégué à Azure NetApp Files.
Les caractéristiques de débit et de performance d’un volume Azure NetApp Files sont une fonction du quota de volume et du niveau de service, comme décrit dans Niveau de service pour Azure NetApp Files. Lorsque vous dimensionnez les volumes Azure NetApp Files pour SAP, assurez-vous que le débit obtenu répond à la configuration requise pour l’application.
Azure NetApp Files offre une stratégie d’exportation. Vous pouvez contrôler les clients autorisés et le type d’accès (par exemple, lecture/écriture ou lecture seule).
Azure NetApp Files ne tient pas encore compte des zones. Actuellement, Azure NetApp Files n’est pas déployé dans toutes les zones de disponibilité d’une région Azure. Méfiez-vous de l’impact potentiel sur les temps de latence dans certaines régions Azure.
Les volumes Azure NetApp Files peuvent être déployés en tant que volumes NFSv3 ou NFSv4.1. Les deux protocoles sont pris en charge pour la couche application SAP (ASCS/ERS, serveurs d’applications SAP).

Configurer ASCS

Ensuite, vous allez préparer et installer les instances SAP ASCS et ERS.

Créez un cluster Pacemaker

Suivez les étapes décrites à la page Configuration de Pacemaker sur SUSE Linux Enterprise Server dans Azure pour créer un cluster Pacemaker de base pour SAP ASCS.

Préparer l’installation

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

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

[A] Installez la dernière version du connecteur SUSE.
```
sudo zypper install sap-suse-cluster-connector
```

[A] Installez l’agent de ressources sapstartsrv.

sudo zypper install sapstartsrv-resource-agents

[A] Mettez à jour les agents de ressources SAP.

Pour utiliser la configuration décrite dans cet article, vous avez besoin d’un patch pour le package resource-agents. Pour vérifier si le patch est déjà installé, utilisez la commande suivante.
```
sudo grep 'parameter name="IS_ERS"' /usr/lib/ocf/resource.d/heartbeat/SAPInstance
```
La sortie doit ressembler à celle de l’exemple suivant.
```
<parameter name="IS_ERS" unique="0" required="0">;
```
Si la commande grep ne trouve pas le paramètre IS_ERS, vous devez installer le patch répertorié dans la page de téléchargement SUSE.

Important

Vous devez installer au moins la version 0.91 de sapstartsrv-resource-agents et resource-agents 4.x à partir de novembre 2021.

[A] Configurez la résolution de noms d’hôte.

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.

sudo vi /etc/hosts

Insérez les lignes suivantes dans /etc/hosts. Modifiez l’adresse IP et le nom d’hôte en fonction de votre environnement.

 # IP address of cluster node 1
 10.27.0.6    sap-cl1
 # IP address of cluster node 2
 10.27.0.7     sap-cl2
 # IP address of the load balancer's front-end configuration for SAP NetWeaver ASCS
 10.27.0.9   sapascs
 # IP address of the load balancer's front-end configuration for SAP NetWeaver ERS
 10.27.0.10    sapers

[A] Configurez le fichier SWAP.

sudo vi /etc/waagent.conf

# Check if the ResourceDisk.Format property is already set to y, and if not, set it.
ResourceDisk.Format=y

# Set the ResourceDisk.EnableSwap property to y.
# Create and use the SWAP file on the resource disk.
ResourceDisk.EnableSwap=y

# Set the size of the SWAP file with the ResourceDisk.SwapSizeMB property.
# The free space of resource disk varies by virtual machine size. Don't set a value that's too big. You can check the SWAP space by using the swapon command.
ResourceDisk.SwapSizeMB=2000

Redémarrer l’Agent pour activer la modification.

sudo service waagent restart

Préparer des répertoires SAP si vous utilisez NFS sur Azure Files

[1] Créez les répertoires SAP sur le partage NFS.

Montez temporairement le partage NFS sapnw1 sur l’une des machines virtuelles et créez les répertoires SAP à utiliser comme points de montage imbriqués.

# Temporarily mount the volume.
sudo mkdir -p /saptmp
sudo mount -t nfs sapnfsafs.file.core.windows.net:/sapnfsafs/sapnw1 /saptmp -o noresvport,vers=4,minorversion=1,sec=sys
# Create the SAP directories.
sudo cd /saptmp
sudo mkdir -p sapmntNW1
sudo mkdir -p usrsapNW1
# Unmount the volume and delete the temporary directory.
cd ..
sudo umount /saptmp
sudo rmdir /saptmp

[A] Créez les répertoires partagés.

sudo mkdir -p /sapmnt/NW1
sudo mkdir -p /usr/sap/NW1
sudo mkdir -p /usr/sap/trans

sudo chattr +i /sapmnt/NW1
sudo chattr +i /usr/sap/NW1
sudo chattr +i /usr/sap/trans

[A] Montez les systèmes de fichiers.

Avec la configuration de montage simple, le cluster Pacemaker ne contrôle pas les systèmes de fichiers.

echo "sapnfsafs.file.core.windows.net:/sapnfsafs/sapnw1/sapmntNW1 /sapmnt/NW1 nfs noresvport,vers=4,minorversion=1,sec=sys  0  0" >> /etc/fstab
echo "sapnfsafs.file.core.windows.net:/sapnfsafs/sapnw1/usrsapNW1/ /usr/sap/NW1 nfs noresvport,vers=4,minorversion=1,sec=sys  0  0" >> /etc/fstab
echo "sapnfsafs.file.core.windows.net:/sapnfsafs/saptrans /usr/sap/trans nfs noresvport,vers=4,minorversion=1,sec=sys  0  0" >> /etc/fstab   
# Mount the file systems.
mount -a

Préparer des répertoires SAP si vous utilisez NFS sur Azure NetApp Files

Les instructions de cette section s’appliquent uniquement si vous utilisez des volumes Azure NetApp Files avec le protocole NFSv4.1. Effectuez la configuration sur toutes les machines virtuelles où des volumes Azure NetApp Files NFSv4.1 seront montés.

[A] Désactivez le mappage d’ID.

Vérifiez le paramètre de domaine NFS. Assurez-vous que le domaine est configuré en tant que domaine Azure NetApp Files par défaut , defaultv4iddomain.com. Vérifiez également que le mappage est défini sur nobody.
```
sudo cat /etc/idmapd.conf
# Examplepython-azure-mgmt-compute
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
```

Vérifier nfs4_disable_idmapping Sa valeur doit être Y.

Pour créer la structure de répertoire où se trouve nfs4_disable_idmapping, exécutez la commande mount. Vous ne serez pas en mesure de créer manuellement le répertoire sous /sys/modules, car l’accès est réservé pour le noyau et les pilotes.

# Check nfs4_disable_idmapping. 
cat /sys/module/nfs/parameters/nfs4_disable_idmapping
# If you need to set nfs4_disable_idmapping to Y:
mkdir /mnt/tmp
mount 10.27.1.5:/sapnw1 /mnt/tmp
umount  /mnt/tmp
echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
# Make the configuration permanent.
echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

[1] Montez temporairement le volume Azure NetApp Files sur l’une des machines virtuelles et créez les répertoires SAP (chemins d’accès de fichier).

# Temporarily mount the volume.
sudo mkdir -p /saptmp
# If you're using NFSv3:
sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,nfsvers=3,tcp 10.27.1.5:/sapnw1 /saptmp
# If you're using NFSv4.1:
sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,nfsvers=4.1,sec=sys,tcp 10.27.1.5:/sapnw1 /saptmp
# Create the SAP directories.
sudo cd /saptmp
sudo mkdir -p sapmntNW1
sudo mkdir -p usrsapNW1
# Unmount the volume and delete the temporary directory.
sudo cd ..
sudo umount /saptmp
sudo rmdir /saptmp

[A] Créez les répertoires partagés.

sudo mkdir -p /sapmnt/NW1
sudo mkdir -p /usr/sap/NW1
sudo mkdir -p /usr/sap/trans

sudo chattr +i /sapmnt/NW1
sudo chattr +i /usr/sap/NW1
sudo chattr +i /usr/sap/trans

[A] Montez les systèmes de fichiers.

Avec la configuration de montage simple, le cluster Pacemaker ne contrôle pas les systèmes de fichiers.

# If you're using NFSv3:
echo "10.27.1.5:/sapnw1/sapmntNW1 /sapmnt/NW1 nfs nfsvers=3,hard 0 0" >> /etc/fstab
echo "10.27.1.5:/sapnw1/usrsapNW1 /usr/sap/NW1 nfs nfsvers=3,hard 0 0" >> /etc/fstab
echo "10.27.1.5:/saptrans /usr/sap/trans nfs nfsvers=3,hard 0 0" >> /etc/fstab
# If you're using NFSv4.1:
echo "10.27.1.5:/sapnw1/sapmntNW1 /sapmnt/NW1 nfs nfsvers=4.1,sec=sys,hard 0 0" >> /etc/fstab
echo "10.27.1.5:/sapnw1/usrsapNW1 /usr/sap/NW1 nfs nfsvers=4.1,sec=sys,hard 0 0" >> /etc/fstab
echo "10.27.1.5:/saptrans /usr/sap/trans nfs nfsvers=4.1,sec=sys,hard 0 0" >> /etc/fstab
# Mount the file systems.
mount -a

Installer SAP NetWeaver ASCS et ERS

[1] Créez une ressource IP virtuelle et une sonde d’intégrité pour l’instance ASCS.

Important

Nous vous recommandons d’utiliser l’agent de ressources azure-lb, qui fait partie du package resource-agents avec une version minimale de resource-agents-4.3.0184.6ee15eb2-4.13.1.

sudo crm node standby sap-cl2   
sudo crm configure primitive vip_NW1_ASCS IPaddr2 \
  params ip=10.27.0.9 \
  op monitor interval=10 timeout=20

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

sudo crm configure group g-NW1_ASCS nc_NW1_ASCS vip_NW1_ASCS \
  meta resource-stickiness=3000

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.

sudo crm_mon -r
# Node sap-cl2: standby
# Online: [ sap-cl1 ]
#
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started sap-cl1
# Resource Group: g-NW1_ASCS
#  nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started sap-cl1
#  vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started sap-cl1

[1] Installez SAP NetWeaver ASCS comme racine sur le premier nœud.

Utilisez un nom d’hôte virtuel qui correspond à l’adresse IP de la configuration front-end de l’équilibreur de charge pour ASCS (par exemple, sapascs, 10.27.0.9) et le numéro d’instance que vous avez utilisé pour la sonde de l’équilibreur de charge (par exemple, 00).

Vous pouvez utiliser le paramètresapinstSAPINST_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/NW1/ASCS00 lors de l’installation, définissez le propriétaire et le groupe du dossier ASCS00, puis réessayez.
```
chown nw1adm /usr/sap/NW1/ASCS00
chgrp sapsys /usr/sap/NW1/ASCS00
```

[1] Créez une ressource IP virtuelle et une sonde d’intégrité pour l’instance ERS.

sudo crm node online sap-cl2
sudo crm node standby sap-cl1

sudo crm configure primitive vip_NW1_ERS IPaddr2 \
  params ip=10.27.0.10 \
  op monitor interval=10 timeout=20

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

sudo crm configure group g-NW1_ERS nc_NW1_ERS vip_NW1_ERS

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.

sudo crm_mon -r

# Node sap-cl1: standby
# Online: [ sap-cl2 ]
# 
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started sap-cl2
#  Resource Group: g-NW1_ASCS
#      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started sap-cl2
#      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started sap-cl2
#  Resource Group: g-NW1_ERS
#      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started sap-cl2
#      vip_NW1_ERS  (ocf::heartbeat:IPaddr2):     Started sap-cl2

[2] Installez SAP NetWeaver ERS comme racine sur le deuxième nœud.

Utilisez un nom d’hôte virtuel qui correspond à l’adresse IP de la configuration front-end de l’équilibreur de charge pour ERS (par exemple, sapers, 10.27.0.10) et le numéro d’instance que vous avez utilisé pour la sonde de l’équilibreur de charge (par exemple, 01).

Vous pouvez utiliser le paramètreSAPINST_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.
```
<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 correctement les autorisations et provoquent l’échec de l’installation.

Si aucun sous-dossier n’est créé dans /usr/sap/NW1/ERS01 lors de l’installation, définissez le propriétaire et le groupe du dossier ERS01, puis réessayez.
```
chown nw1adm /usr/sap/NW1/ERS01
chgrp sapsys /usr/sap/NW1/ERS01
```

[1] Adaptez le profil d’instance ASCS.

sudo vi /sapmnt/NW1/profile/NW1_ASCS00_sapascs

# 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 keepalive parameter, if you're using ENSA1.
enque/encni/set_so_keepalive = true

Pour le serveur de file d’attente autonome 1 et 2 (ENSA1 et ENSA2), vérifiez que les paramètres de système d’exploitation keepalive sont définis comme décrit dans la note SAP 1410736.

Adaptez maintenant le profil d’instance ERS.

sudo vi /sapmnt/NW1/profile/NW1_ERS01_sapers

# 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 the ERS profile.
# Autostart = 1

[A] Configurez keepalive.

La communication entre le serveur d’applications SAP NetWeaver et ASCS est routée par l’intermédiaire d’un équilibreur de charge logiciel. L’équilibreur de charge déconnecte les connexions inactives après un délai configurable.

Pour éviter cette déconnexion, vous devez définir un paramètre dans le profil SAP NetWeaver ASCS, si vous utilisez ENSA1. Modifiez les paramètres keepalive du système Linux sur tous les serveurs SAP pour ENSA1 et ENSA2. Pour plus d’informations, consultez la note SAP 1410736.
```
# Change the Linux system configuration.
sudo sysctl net.ipv4.tcp_keepalive_time=300
```

[A] Configurez les utilisateurs SAP après l’installation.

# Add sidadm to the haclient group.
sudo usermod -aG haclient nw1adm

[1] Ajoutez les services ASCS et ERS SAP au fichier sapservice.

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.

cat /usr/sap/sapservices | grep ASCS00 | sudo ssh sap-cl2 "cat >>/usr/sap/sapservices"
sudo ssh sap-cl2 "cat /usr/sap/sapservices" | grep ERS01 | sudo tee -a /usr/sap/sapservices

[A] Désactiver les services systemd de l’instance ASCS et ERS SAP. 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. Après l’installation ou le basculement de l’infrastructure de démarrage SAP vers une configuration compatible avec le système conformément à la note SAP 3115048, vous devez désactiver les services systemd pour les instances ASCS et ERS SAP.
```
# Stop ASCS and ERS instances using <sid>adm
sapcontrol -nr 00 -function Stop
sapcontrol -nr 00 -function StopService

sapcontrol -nr 01 -function Stop
sapcontrol -nr 01 -function StopService

# Execute below command on VM where you have performed ASCS instance installation (e.g. sap-cl1)
sudo systemctl disable SAPNW1_00
# Execute below command on VM where you have performed ERS instance installation (e.g. sap-cl2)
sudo systemctl disable SAPNW1_01
```
[A] Activez sapping et sappong. L’agent sapping s’exécute avant sapinit pour masquer le fichier /usr/sap/sapservices. L’agent sappong s’exécute après sapinit pour afficher le fichier sapservices pendant le démarrage de la machine virtuelle. SAPStartSrv n’est pas démarré automatiquement pour une instance SAP au moment du démarrage, car le cluster Pacemaker la gère.
```
sudo systemctl enable sapping
sudo systemctl enable sappong
```
[1] Créez une ressource SAPStartSrv pour ASCS et ERS en créant un fichier, puis en le chargeant.
```
vi crm_sapstartsrv.txt
```
Entrer l’élément primitif ci-dessous dans le fichier crm_sapstartsrv.txt, puis enregistrer
```
primitive rsc_sapstartsrv_NW1_ASCS00 ocf:suse:SAPStartSrv \
 params InstanceName=NW1_ASCS00_sapascs

primitive rsc_sapstartsrv_NW1_ERS01 ocf:suse:SAPStartSrv \
 params InstanceName=NW1_ERS01_sapers
```
Chargez le fichier en utilisant la commande ci-dessous.
```
sudo crm configure load update crm_sapstartsrv.txt
```
Remarque

Si vous avez configuré une ressource SAPStartSrv en utilisant la commande « crm configure primitive » sur une version 4.4.0+20220708.6ed6b56f-150400.3.3.1 ou ultérieure, il est important de passer en revue la configuration des éléments primitifs de ressource SAPStartSrv. Si une opération de moniteur est présente, elle doit être supprimée. Bien qu SUSE suggère également de supprimer les opérations de démarrage et d’arrêt, celles-ci ne sont pas cruciales comme opération de moniteur. Pour découvrir plus d’informations, voir des modifications récentes apportées au package crmsh peuvent entraîner une configuration non prise en charge de l’agent de ressource SAPStartSrv dans un cluster HA SAP NetWeaver.

[1] Créez les ressources de cluster SAP.

Selon que vous exécutez un système ENSA1 ou ENSA2, sélectionnez l’onglet correspondant pour définir les ressources. 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"

# If you're using NFS on Azure Files or NFSv3 on Azure NetApp Files:
sudo crm configure primitive rsc_sap_NW1_ASCS00 SAPInstance \
 op monitor interval=11 timeout=60 on-fail=restart \
 params InstanceName=NW1_ASCS00_sapascs START_PROFILE="/sapmnt/NW1/profile/NW1_ASCS00_sapascs" \
 AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \
 meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10

# If you're using NFS on Azure Files or NFSv3 on Azure NetApp Files:
sudo crm configure primitive rsc_sap_NW1_ERS01 SAPInstance \
 op monitor interval=11 timeout=60 on-fail=restart \
 params InstanceName=NW1_ERS01_sapers START_PROFILE="/sapmnt/NW1/profile/NW1_ERS01_sapers" \
 AUTOMATIC_RECOVER=false IS_ERS=true MINIMAL_PROBE=true \
 meta priority=1000

# If you're using NFSv4.1 on Azure NetApp Files:
sudo crm configure primitive rsc_sap_NW1_ASCS00 SAPInstance \
 op monitor interval=11 timeout=105 on-fail=restart \
 params InstanceName=NW1_ASCS00_sapascs START_PROFILE="/sapmnt/NW1/profile/NW1_ASCS00_sapascs" \
 AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \
 meta resource-stickiness=5000 failure-timeout=60 migration-threshold=1 priority=10

# If you're using NFSv4.1 on Azure NetApp Files:
sudo crm configure primitive rsc_sap_NW1_ERS01 SAPInstance \
 op monitor interval=11 timeout=105 on-fail=restart \
 params InstanceName=NW1_ERS01_sapers START_PROFILE="/sapmnt/NW1/profile/NW1_ERS01_sapers" \
 AUTOMATIC_RECOVER=false IS_ERS=true MINIMAL_PROBE=true \
 meta priority=1000

sudo crm configure modgroup g-NW1_ASCS add rsc_sapstartsrv_NW1_ASCS00
sudo crm configure modgroup g-NW1_ASCS add rsc_sap_NW1_ASCS00
sudo crm configure modgroup g-NW1_ERS add rsc_sapstartsrv_NW1_ERS01
sudo crm configure modgroup g-NW1_ERS add rsc_sap_NW1_ERS01

sudo crm configure colocation col_sap_NW1_no_both -5000: g-NW1_ERS g-NW1_ASCS
sudo crm configure location loc_sap_NW1_failover_to_ers rsc_sap_NW1_ASCS00 rule 2000: runs_ers_NW1 eq 1
sudo crm configure order ord_sap_NW1_first_start_ascs Optional: rsc_sap_NW1_ASCS00:start rsc_sap_NW1_ERS01:stop symmetrical=false

sudo crm_attribute --delete --name priority-fencing-delay

sudo crm node online sap-cl1
sudo crm configure property maintenance-mode="false"

Remarque

Si vous disposez d’un cluster à deux nœuds exécutant ENSA2, vous avez la possibilité de configurer la propriété de cluster priority-fencing-delay. Cette propriété introduit un délai supplémentaire dans un délimiteur de nœud qui a une priorité de ressource totale supérieure lorsqu’un scénario split-brain se produit. Si vous souhaitez obtenir plus d’informations, consultez le Guide d’administration de l’extension de haute disponibilité SUSE Linux Enteprise Server.

La propriété priority-fencing-delay s’applique uniquement à ENSA2 qui s’exécute sur un cluster à deux nœuds. Si vous souhaitez obtenir plus d’informations, consultez Cluster haute disponibilité Enqueue Replication 2 avec montage simple

sudo crm configure property maintenance-mode="true"

sudo crm configure property priority-fencing-delay=30

# If you're using NFS on Azure Files or NFSv3 on Azure NetApp Files:
sudo crm configure primitive rsc_sap_NW1_ASCS00 SAPInstance \
 op monitor interval=11 timeout=60 on-fail=restart \
 params InstanceName=NW1_ASCS00_sapascs START_PROFILE="/sapmnt/NW1/profile/NW1_ASCS00_sapascs" \
 AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \
 meta resource-stickiness=5000 priority=100

# If you're using NFS on Azure Files or NFSv3 on Azure NetApp Files:   
sudo crm configure primitive rsc_sap_NW1_ERS01 SAPInstance \
 op monitor interval=11 timeout=60 on-fail=restart \
 params InstanceName=NW1_ERS01_sapers START_PROFILE="/sapmnt/NW1/profile/NW1_ERS01_sapers" \
 AUTOMATIC_RECOVER=false IS_ERS=true MINIMAL_PROBE=true

# If you're using NFSv4.1 on Azure NetApp Files:
sudo crm configure primitive rsc_sap_NW1_ASCS00 SAPInstance \
 op monitor interval=11 timeout=105 on-fail=restart \
 params InstanceName=NW1_ASCS00_sapascs START_PROFILE="/sapmnt/NW1/profile/NW1_ASCS00_sapascs" \
 AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \
 meta resource-stickiness=5000 priority=100

# If you're using NFSv4.1 on Azure NetApp Files:   
sudo crm configure primitive rsc_sap_NW1_ERS01 SAPInstance \
 op monitor interval=11 timeout=105 on-fail=restart \
 params InstanceName=NW1_ERS01_sapers START_PROFILE="/sapmnt/NW1/profile/NW1_ERS01_sapers" \
 AUTOMATIC_RECOVER=false IS_ERS=true MINIMAL_PROBE=true

sudo crm configure modgroup g-NW1_ASCS add rsc_sapstartsrv_NW1_ASCS00
sudo crm configure modgroup g-NW1_ASCS add rsc_sap_NW1_ASCS00
sudo crm configure modgroup g-NW1_ERS add rsc_sapstartsrv_NW1_ERS01
sudo crm configure modgroup g-NW1_ERS add rsc_sap_NW1_ERS01

sudo crm configure colocation col_sap_NW1_no_both -5000: g-NW1_ERS g-NW1_ASCS
sudo crm configure order ord_sap_NW1_first_start_ascs Optional: rsc_sap_NW1_ASCS00:start rsc_sap_NW1_ERS01:stop symmetrical=false

sudo crm node online sap-cl1
sudo crm configure property maintenance-mode="false"

Si vous effectuez une mise à niveau à partir d’une version antérieure et que vous passez à ENSA2, 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.

sudo crm_mon -r
# Full list of resources:
# 
# stonith-sbd     (stonith:external/sbd): Started sap-cl2
#  Resource Group: g-NW1_ASCS
#      nc_NW1_ASCS        (ocf::heartbeat:azure-lb):      Started sap-cl1
#      vip_NW1_ASCS       (ocf::heartbeat:IPaddr2):       Started sap-cl1
#      rsc_sapstartsrv_NW1_ASCS00 (ocf::suse:SAPStartSrv):        Started sap-cl1
#      rsc_sap_NW1_ASCS00 (ocf::heartbeat:SAPInstance):   Started sap-cl1
#  Resource Group: g-NW1_ERS
#      nc_NW1_ERS (ocf::heartbeat:azure-lb):      Started sap-cl2
#      vip_NW1_ERS        (ocf::heartbeat:IPaddr2):       Started sap-cl2
#      rsc_sapstartsrv_NW1_ERS01  (ocf::suse:SAPStartSrv):        Started sap-cl2
#      rsc_sap_NW1_ERS01  (ocf::heartbeat:SAPInstance):   Started sap-cl1

Préparer le serveur d’applications SAP

Certaines bases de données exigent que vous exécutiez l’installation de la base de données sur un serveur d’applications. Préparez les machines virtuelles du serveur d’applications pour pouvoir exécuter l’installation de la base de données.

Les étapes courantes suivantes partent du principe que vous installez le serveur d’applications sur un serveur différent des serveurs ASCS et HANA :

Configurez la résolution de noms d’hôte.

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.
```
sudo vi /etc/hosts
```
Insérez les lignes suivantes dans /etc/hosts. Modifiez l’adresse IP et le nom d’hôte en fonction de votre environnement.
```
10.27.0.6   sap-cl1
10.27.0.7   sap-cl2
# IP address of the load balancer's front-end configuration for SAP NetWeaver ASCS
10.27.0.9   sapascs
# IP address of the load balancer's front-end configuration for SAP NetWeaver ERS
10.27.0.10  sapers
10.27.0.8   sapa01
10.27.0.12  sapa02
```

Configurez le fichier SWAP.

sudo vi /etc/waagent.conf

# Set the ResourceDisk.EnableSwap property to y.
# Create and use the SWAP file on the resource disk.
ResourceDisk.EnableSwap=y

# Set the size of the SWAP file by using the ResourceDisk.SwapSizeMB property.
# The free space of the resource disk varies by virtual machine size. Don't set a value that's too big. You can check the SWAP space by using the swapon command.
ResourceDisk.SwapSizeMB=2000

Redémarrer l’Agent pour activer la modification.

sudo service waagent restart

Préparer des répertoires SAP

Si vous utilisez NFS sur Azure Files, suivez les instructions suivantes pour préparer les répertoires SAP sur les machines virtuelles du serveur d’applications SAP :

Créez les points de montage.

sudo mkdir -p /sapmnt/NW1
sudo mkdir -p /usr/sap/trans

sudo chattr +i /sapmnt/NW1
sudo chattr +i /usr/sap/trans

Montez les systèmes de fichiers.

echo "sapnfsafs.file.core.windows.net:/sapnfsafs/sapnw1/sapmntNW1 /sapmnt/NW1  nfs noresvport,vers=4,minorversion=1,sec=sys  0  0" >> /etc/fstab
echo "sapnfsafs.file.core.windows.net:/sapnfsafs/saptrans /usr/sap/trans  nfs noresvport,vers=4,minorversion=1,sec=sys  0  0" >> /etc/fstab   
# Mount the file systems.
mount -a

Si vous utilisez NFS sur Azure NetApp Files, suivez les instructions suivantes pour préparer les répertoires SAP sur les machines virtuelles du serveur d’applications SAP :

Créez les points de montage.

sudo mkdir -p /sapmnt/NW1
sudo mkdir -p /usr/sap/trans

sudo chattr +i /sapmnt/NW1
sudo chattr +i /usr/sap/trans

Montez les systèmes de fichiers.

# If you're using NFSv3:
echo "10.27.1.5:/sapnw1/sapmntNW1 /sapmnt/NW1 nfs nfsvers=3,hard 0 0" >> /etc/fstab
echo "10.27.1.5:/saptrans /usr/sap/trans nfs nfsvers=3, hard 0 0" >> /etc/fstab
# If you're using NFSv4.1:
echo "10.27.1.5:/sapnw1/sapmntNW1 /sapmnt/NW1 nfs nfsvers=4.1,sec=sys,hard 0 0" >> /etc/fstab    
echo "10.27.1.5:/saptrans /usr/sap/trans nfs nfsvers=4.1,sec=sys,hard 0 0" >> /etc/fstab
# Mount the file systems.
mount -a

Installez la base de données.

Dans cet exemple, SAP NetWeaver est installé sur SAP HANA. Vous pouvez utiliser n’importe quelle base de données prise en charge pour cette installation. Pour plus d’informations sur l’installation de SAP HANA dans Azure, consultez Haute disponibilité de SAP HANA sur des machines virtuelles Azure. Pour obtenir la liste des bases de données prises en charge, consultez la note SAP 1928533.

Installez l’instance de base de données SAP NetWeaver en tant que racine à l’aide d’un nom d’hôte virtuel mappé à l’adresse IP de la configuration front-end d’équilibreur de charge pour la base de données. Vous pouvez utiliser le paramètreSAPINST_REMOTE_ACCESS_USER pour autoriser un utilisateur non racine à se connecter à sapinst.

sudo <swpm>/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin

Installer le serveur d’applications SAP NetWeaver

Suivez ces étapes pour installer un serveur d’applications SAP :

[A] Préparez le serveur d’applications.

Suivez les étapes dans Préparation du serveur d’applications SAP NetWeaver.
[A] Installez un serveur d’applications SAP NetWeaver principal ou supplémentaire.

Vous pouvez utiliser le paramètreSAPINST_REMOTE_ACCESS_USER pour autoriser un utilisateur non racine à se connecter à sapinst.
```
sudo <swpm>/sapinst SAPINST_REMOTE_ACCESS_USER=sapadmin
```
[A] Mettez à jour la banque d’informations sécurisée SAP HANA pour qu’elle pointe vers le nom virtuel de la configuration de la réplication système SAP HANA.

Exécutez la commande suivante pour répertorier les entrées.
```
hdbuserstore List
```
La commande doit répertorier toutes les entrées et ressembler à cet exemple.
```
DATA FILE       : /home/nw1adm/.hdb/sapa01/SSFS_HDB.DAT
KEY FILE        : /home/nw1adm/.hdb/sapa01/SSFS_HDB.KEY

KEY DEFAULT 
  ENV : 10.27.0.4:30313
  USER: SAPABAP1
  DATABASE: NW1
```
Dans cet exemple, l’adresse IP de l’entrée par défaut pointe vers la machine virtuelle, et non l’équilibreur de charge. Modifiez l’entrée de sorte qu’elle pointe vers le nom d’hôte virtuel de l’équilibreur de charge. Veillez à utiliser le même port et le même nom de base de données. Par exemple, utilisez 30313 et NW1 dans l’exemple de sortie.
```
su - nw1adm
hdbuserstore SET DEFAULT nw1db:30313@NW1 SAPABAP1 <password of ABAP schema>
```

Tester la configuration de votre cluster

Testez minutieusement votre cluster Pacemaker. Exécutez les tests de basculement classiques.

Partage via

SAP NetWeaver à haute disponibilité avec montage simple et NFS sur SLES pour les machines virtuelles d’applications SAP

Prérequis

Vue d’ensemble

Préparer l’infrastructure

Déployer manuellement des machines virtuelles Linux via le portail Azure

Configurer l’équilibrage de charge Azure

Déployer NFS

Déployer un compte de stockage Azure Files et des partages NFS

Considérations importantes pour NFS sur des partages Azure Files

Déployer des ressources Azure NetApp Files

Considérations importantes pour NFS sur Azure NetApp Files

Configurer ASCS

Créez un cluster Pacemaker

Préparer l’installation

Préparer des répertoires SAP si vous utilisez NFS sur Azure Files

Préparer des répertoires SAP si vous utilisez NFS sur Azure NetApp Files

Installer SAP NetWeaver ASCS et ERS

Préparer le serveur d’applications SAP

Préparer des répertoires SAP

Installez la base de données.

Installer le serveur d’applications SAP NetWeaver

Tester la configuration de votre cluster

Étapes suivantes

Commentaires

Ressources supplémentaires