Haute disponibilité multi-SID pour une instance SAP ASCS/SCS avec le clustering de basculement Windows Server et un disque partagé Azure

Article
06/21/2024

Windows

Cet article explique comment passer d’une installation ASCS/SCS unique à une configuration de plusieurs ID système (SID) SAP en installant des instances SAP ASCS/SCS en cluster supplémentaires dans un cluster de basculement Windows Server (WSFC) existant avec un disque partagé Azure. Une fois ce processus terminé, vous avez configuré un cluster multi-SID SAP.

Conditions préalables et limitations

Vous pouvez utiliser des disques Azure SSD Premium comme disques partagés Azure pour l’instance SAP ASCS/SCS. Quelques limitations s'appliquent pour le moment :

Les disques de stockage Ultra Azure et les disques SSD Standard Azure ne sont pas pris en charge comme disques partagés Azure pour les charges de travail SAP.
Les disques partagés Azure avec des disques SSD Premium sont pris en charge pour le déploiement de SAP dans des groupes à haute disponibilité et des zones de disponibilité.
Les disques partagés Azure avec des disques SSD Premium offrent deux options de stockage :
- Le stockage localement redondant (LRS) pour les disques partagés SSD Premium (valeur de skuName égale à Premium_LRS) est pris en charge pour le déploiement dans les groupes à haute disponibilité.
- Le stockage redondant interzone (ZRS) pour les disques partagés SSD Premium (valeur de skuName égale à Premium_ZRS) est pris en charge pour le déploiement dans les zones de disponibilité.
La valeur de maxShares du disque partagé Azure détermine le nombre de nœuds de cluster que le disque partagé peut utiliser. Pour une instance SAP ASCS/SCS, vous configurez généralement deux nœuds dans WSFC. Vous définissez ensuite la valeur de maxShares sur 2.
Un groupe de placement de proximité Azure n’est pas requis pour les disques partagés Azure. Pour le déploiement de SAP avec des groupes de placement de proximité, suivez ces instructions :
- Si vous utilisez des groupes de placement de proximité pour un système SAP déployé dans une région, toutes les machines virtuelles qui partagent un disque doivent faire partie du même groupe de placement de proximité.
- Si vous utilisez des groupes de placement de proximité pour le système SAP déployé sur plusieurs zones, comme décrit dans Groupes de placement de proximité avec des déploiements sur plusieurs zones, vous pouvez attacher le stockage Premium_ZRS aux machines virtuelles qui partagent un disque.

Pour plus d’informations, consultez la section Limitations de la documentation relative aux disques partagés Azure.

Considérations importantes pour les disques partagés SSD Premium

Prenez en compte ces points importants sur les disques partagés SSD Premium Azure :

Stockage LRS pour des disques partagés SSD Premium :
- Un déploiement SAP avec stockage LRS pour des disques partagés SSD Premium fonctionne avec un seul disque partagé Azure par cluster de stockage. S’il y a un problème avec le cluster de stockage où le disque partagé Azure est déployé, il affecte votre instance SAP ASCS/SCS.
Stockage ZRS pour des disques partagés SSD Premium :
- La latence en écriture du stockage ZRS est supérieure à celle du stockage LRS en raison de la copie des données entre les zones.
- La distance entre les zones de disponibilité de différentes régions varie, et la latence des disques ZRS entre les zones de disponibilité varie donc aussi. Établissez un point de référence de vos disques pour identifier la latence des disques ZRS dans votre région.
- Le stockage ZRS pour les disques partagés SSD Premium réplique les données de façon synchrone dans trois zones de disponibilité de la région. En cas de problème dans un des clusters de stockage, votre instance SAP ASCS/SCS continue de s’exécuter, car le basculement du stockage est transparent pour la couche d’application.
- Pour plus d’informations, consultez la section Limitations de la documentation relative à ZRS pour les disques managés.

Important

La configuration doit répondre aux conditions suivantes :

Le SID pour chaque système de gestion de base de données (SGBD) doit avoir son propre cluster WSFC dédié.
Les serveurs d’applications SAP appartenant à un seul SID SAP doivent avoir leurs propres machines virtuelles dédiées.
La combinaison d’ERS1 (Enqueue Replication Server 1) et d’ERS2 (Enqueue Replication Server 2) sur le même cluster n’est pas prise en charge.

Versions du système d'exploitation prises en charge

Windows Server 2016, 2019 et ultérieur sont pris en charge. Utilisez les images mes plus récentes du centre de données.

Nous vous recommandons vivement d’utiliser au moins Windows Server 2019 Datacenter pour ces raisons :

WSFC dans Windows Server 2019 reconnaît Azure.
Windows Server 2019 Datacenter inclut l’intégration et la compatibilité de la maintenance de l’hôte Azure, et une expérience améliorée grâce à la supervision des événements planifiés d’Azure.
Vous pouvez utiliser des noms de réseau distribué. (C’est l’option par défaut.) Il n’est pas nécessaire de disposer d’une adresse IP dédiée pour le nom réseau du cluster. En outre, vous n’avez pas besoin de configurer une adresse IP sur un équilibreur de charge interne Azure.

Architecture

ERS1 et ERS2 sont tous deux pris en charge dans une configuration multi-SID. La combinaison d’ERS1 et d’ERS2 n’est pas prise en charge dans le même cluster.

L’exemple suivant montre deux SID SAP. Tous deux ont une architecture ERS1 où :

SAP SID1 est déployé sur un disque partagé avec ERS1. L’instance ERS est installée sur un hôte local et sur un lecteur local.

SAP SID1 a sa propre adresse IP virtuelle (SID1 (A)SCS IP1), qui est configurée sur l’équilibreur de charge interne Azure.
SAP SID2 est déployé sur un disque partagé avec ERS1. L’instance ERS est installée sur un hôte local et sur un lecteur local.

SAP SID2 a sa propre adresse IP virtuelle (SID2 (A)SCS IP2), qui est configurée sur l’équilibreur de charge interne Azure.

Diagramme de deux instances SAP ASCS/SCS à haute disponibilité avec une configuration ERS1.

L’exemple suivant montre aussi deux SID SAP. Tous deux ont une architecture ERS2 où :

SAP SID1 est déployé sur un disque de partition avec ERS2, qui est en cluster et est déployé sur un lecteur local.

SAP SID1 a sa propre adresse IP virtuelle (SID1 (A)SCS IP1), qui est configurée sur l’équilibreur de charge interne Azure.

SAP ERS2 a sa propre adresse IP virtuelle (SID1 ERS2 IP2), qui est configurée sur l’équilibreur de charge interne Azure.
SAP SID2 est déployé sur un disque de partition avec ERS2, qui est en cluster et est déployé sur un lecteur local.

SAP SID2 a sa propre adresse IP virtuelle (SID2 (A)SCS IP3), qui est configurée sur l’équilibreur de charge interne Azure.

SAP ERS2 a sa propre adresse IP virtuelle (SID2 ERS2 IP4), qui est configurée sur l’équilibreur de charge interne Azure.
Il y a un total de quatre adresses IP virtuelles :
- SID1 (A)SCS IP1
- SID2 ERS2 IP2
- SID2 (A)SCS IP3
- SID2 ERS2 IP4

Diagramme de deux instances SAP ASCS/SCS à haute disponibilité avec une configuration ERS1 et ERS2.

Préparation de l'infrastructure

Vous installez une nouvelle instance SAP SID PR2, en plus de l’instance SAP PR1 ASCS/SCS en cluster existante.

Noms d’hôtes et adresses IP

En fonction du type de votre déploiement, les noms d’hôte et les adresses IP du scénario devraient se présenter comme les exemples suivants.

Voici les détails d’un déploiement SAP dans un groupe à haute disponibilité Azure :

Rôle du nom d'hôte	Nom de l’hôte	Adresse IP statique	Groupe à haute disponibilité	Valeur de `SkuName` pour le disque
Premier nœud de cluster du cluster ASCS/SCS	pr1-ascs-10	10.0.0.4	pr1-ascs-avset	`Premium_LRS`
Second nœud de cluster du cluster ASCS/SCS	pr1-ascs-11	10.0.0.5	pr1-ascs-avset
Nom du réseau de cluster	pr1clust	10.0.0.42 (seulement pour un cluster Windows Server 2016)	Non applicable
Nom réseau du cluster SID1 ASCS	pr1-ascscl	10.0.0.43	Non applicable
Nom réseau du cluster SID1 ERS (uniquement pour ERS2)	pr1-erscl	10.0.0.44	Non applicable
Nom réseau du cluster SID2 ASCS	pr2-ascscl	10.0.0.45	Non applicable
Nom réseau du cluster SID2 ERS (uniquement pour ERS2)	pr1-erscl	10.0.0.46	Non applicable

Voici les détails pour un déploiement SAP dans des zones de disponibilité Azure :

Rôle du nom d'hôte	Nom de l’hôte	Adresse IP statique	Zone de disponibilité	Valeur de `SkuName` pour le disque
Premier nœud de cluster du cluster ASCS/SCS	pr1-ascs-10	10.0.0.4	AZ01	`Premium_ZRS`
Second nœud de cluster du cluster ASCS/SCS	pr1-ascs-11	10.0.0.5	AZ02
Nom du réseau de cluster	pr1clust	10.0.0.42 (seulement pour un cluster Windows Server 2016)	Non applicable
Nom réseau du cluster SID1 ASCS	pr1-ascscl	10.0.0.43	Non applicable
Nom réseau du cluster SID2 ERS (uniquement pour ERS2)	pr1-erscl	10.0.0.44	Non applicable
Nom réseau du cluster SID2 ASCS	pr2-ascscl	10.0.0.45	Non applicable
Nom réseau du cluster SID2 ERS (uniquement pour ERS2)	pr1-erscl	10.0.0.46	Non applicable

Les étapes décrites dans cet article restent les mêmes pour les deux types de déploiement. Cependant, si votre cluster s’exécute dans un groupe à haute disponibilité, vous devez déployer LRS pour les disques partagés SSD Premium Azure (Premium_LRS). Cependant, si votre cluster s’exécute dans une zone de disponibilité, vous devez déployer ZRS pour les disques partagés SSD Premium Azure (Premium_ZRS).

Créer un équilibreur de charge interne Azure

Pour une configuration multi-SID de SAP SID PR2, vous pouvez utiliser le même équilibreur de charge interne que celui que vous avez créé pour le système SAP SID PR1. Pour l’architecture ENSA1 sur Windows, vous n’avez besoin que d’une seule adresse IP virtuelle pour SAP ASCS/SCS. En revanche, l’architecture ENSA2 nécessite deux adresses IP virtuelles : une pour SAP ASCS et une autre pour ERS2.

Configurez une adresse IP front-end supplémentaire une règle d’équilibrage de charge pour le système SAP SID PR2 sur l’équilibreur de charge existant en utilisant les instructions suivantes. Cette section suppose que la configuration de l’équilibreur de charge interne Standard pour SAP SID PR1 est déjà en place, comme décrit dans Créer un équilibreur de charge.

Ouvrez le même équilibreur de charge interne Standard que celui que vous avez créé pour le système SAP SID PR1.
Configuration d’une adresse IP front-end : créez une adresse IP front-end (par exemple : 10.0.0.45).
Pool de back-ends : le pool de back-ends est le même que celui du système SAP SID PR1.
Règles de trafic entrant : créez une règle 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éez une sonde d’intégrité avec les détails ci-dessous
  - Protocole : TCP
  - Port : [par exemple : 620<Numéro-instance> pour SAP SID PR2 ASCS]
  - Intervalle : 5
  - Seuil de la sonde : 2
- Délai d’inactivité (minutes) : 30
- Cocher « Activer l’adresse IP flottante »
Applicable uniquement à l’architecture ENSA2 : créez une adresse IP front-end supplémentaire (10.0.0.0.44), une règle d’équilibrage de charge (utilisez 621<Numéro-instance> pour le port de la sonde d’intégrité d’ERS2) comme décrit aux points 1 et 3.

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.

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.

Créer et attacher un deuxième disque partagé Azure

Exécutez la commande suivante sur l’un des nœuds du cluster. Ajustez les valeurs des informations telles que votre groupe de ressources, la région Azure et le SID SAP.

$ResourceGroupName = "MyResourceGroup"
$location = "MyRegion"
$SAPSID = "PR2"
$DiskSizeInGB = 512
$DiskName = "$($SAPSID)ASCSSharedDisk"
$NumberOfWindowsClusterNodes = 2

# For SAP deployment in an availability set, use this storage SkuName value
$SkuName = "Premium_LRS"
# For SAP deployment in an availability zone, use this storage SkuName value
$SkuName = "Premium_ZRS"

$diskConfig = New-AzDiskConfig -Location $location -SkuName $SkuName  -CreateOption Empty  -DiskSizeGB $DiskSizeInGB -MaxSharesCount $NumberOfWindowsClusterNodes
    
$dataDisk = New-AzDisk -ResourceGroupName $ResourceGroupName -DiskName $DiskName -Disk $diskConfig
##################################
## Attach the disk to cluster VMs
##################################
# ASCS cluster VM1
$ASCSClusterVM1 = "pr1-ascs-10"
# ASCS cluster VM2
$ASCSClusterVM2 = "pr1-ascs-11"
# Next free LUN
$LUNNumber = 1

# Add the Azure shared disk to Cluster Node 1
$vm = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $ASCSClusterVM1 
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun $LUNNumber
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroupName -Verbose

# Add the Azure shared disk to Cluster Node 2
$vm = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $ASCSClusterVM2
$vm = Add-AzVMDataDisk -VM $vm -Name $DiskName -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun $LUNNumber
Update-AzVm -VM $vm -ResourceGroupName $ResourceGroupName -Verbose

Formater le disque partagé en utilisant PowerShell

Procurez-vous le numéro du disque. Exécutez les commandes PowerShell suivantes sur l’un des nœuds du cluster :

 Get-Disk | Where-Object PartitionStyle -Eq "RAW"  | Format-Table -AutoSize 
 # Example output
 # Number Friendly Name     Serial Number HealthStatus OperationalStatus Total Size Partition Style
 # ------ -------------     ------------- ------------ ----------------- ---------- ---------------
 # 3      Msft Virtual Disk               Healthy      Online                512 GB RAW

Formatez le disque. Dans cet exemple, il s’agit du disque numéro 3 :

 # Format SAP ASCS disk number 3, with drive letter S
 $SAPSID = "PR2"
 $DiskNumber = 3
 $DriveLetter = "S"
 $DiskLabel = "$SAPSID" + "SAP"

 Get-Disk -Number $DiskNumber | Where-Object PartitionStyle -Eq "RAW" | Initialize-Disk -PartitionStyle GPT -PassThru |  New-Partition -DriveLetter $DriveLetter -UseMaximumSize | Format-Volume  -FileSystem ReFS -NewFileSystemLabel $DiskLabel -Force -Verbose
 # Example outout
 # DriveLetter FileSystemLabel FileSystem DriveType HealthStatus OperationalStatus SizeRemaining      Size
 # ----------- --------------- ---------- --------- ------------ ----------------- -------------      ----
 # S           PR2SAP          ReFS       Fixed     Healthy      OK                    504.98 GB 511.81 GB

Vérifiez que le disque est maintenant visible en tant que disque de cluster :

 # List all disks
 Get-ClusterAvailableDisk -All
 # Example output
 # Cluster    : pr1clust
 # Id         : c469b5ad-d089-4d8f-ae4c-d834cbbde1a2
 # Name       : Cluster Disk 2
 # Number     : 3
 # Size       : 549755813888
 # Partitions : {\\?\GLOBALROOT\Device\Harddisk3\Partition2\}

Inscrivez le disque dans le cluster :

 # Add the disk to the cluster 
 Get-ClusterAvailableDisk -All | Add-ClusterDisk
 # Example output 
 # Name           State  OwnerGroup        ResourceType 
 # ----           -----  ----------        ------------ 
 # Cluster Disk 2 Online Available Storage Physical Disk

Créer un nom d’hôte virtuel pour l’instance SAP ASCS/SCS en cluster

Créez une entrée DNS pour le nom d'hôte virtuel de la nouvelle instance SAP ASCS/SCS dans le gestionnaire DNS Windows.

L’adresse IP que vous affectez au nom d’hôte virtuel dans le DNS doit être identique à celle que vous avez affectée dans Azure Load Balancer.
Si vous utilisez une instance en cluster de SAP ERS2, vous devez réserver dans DNS un nom d’hôte virtuel pour ERS2.

L’adresse IP que vous affectez au nom d’hôte virtuel pour ERS2 dans le DNS doit être identique à celle que vous avez affectée dans Azure Load Balancer.
Pour définir l’adresse IP affectée au nom d’hôte virtuel, sélectionnez Gestionnaire DNS>Domaine.

Installation de SAP

Installer le premier nœud de cluster SAP

Suivez la procédure d’installation décrite par SAP. Veillez à sélectionner Premier nœud de cluster comme option de démarrage de l’installation. Sélectionnez Disque partagé du cluster comme option de configuration. Choisissez le disque partagé nouvellement créé.

Modifier le profil SAP de l'instance ASCS/SCS

Si vous exécutez ERS1, ajoutez le paramètre de profil SAP enque/encni/set_so_keepalive. Le paramètre de profil empêche les connexions entre les processus de travail SAP et le serveur de mise en file d’attente de se fermer quand elles sont inactives pendant trop longtemps. Le paramètre SAP n’est pas nécessaire pour ERS2.

Si vous utilisez ERS1, ajoutez ce paramètre de profil au profil de l’instance SAP ASCS/SCS :
```
enque/encni/set_so_keepalive = true
```
Pour ERS1 et ERS2, assurez-vous que les paramètres de système d’exploitation keepalive sont définis comme décrit dans la note SAP 1410736.
Pour appliquer les changements au paramètre du profil SAP, redémarrez l’instance SAP ASCS/SCS.

Configurer un port de sonde sur la ressource de cluster

Utilisez la fonctionnalité de sondage de l’équilibrage de charge interne pour que la configuration de cluster entière fonctionne avec Azure Load Balancer. Généralement, l’équilibrage de charge interne Azure répartit équitablement la charge de travail entrante entre les machines virtuelles participantes.

Cependant, cette approche ne fonctionne pas dans certaines configurations de cluster, car une seule instance est active. L’autre instance est passive et ne peut accepter aucune partie de la charge de travail. La fonctionnalité de sonde est utile quand l’équilibreur de charge interne Azure détecte quelle instance est active et ne cible que l’instance active.

Important

Dans cet exemple de configuration, le port de la sonde est défini sur 620numéro. Pour SAP ASCS avec le numéro d’instance 02, il est défini sur 62002.

Vous devrez ajuster la configuration pour qu’elle corresponde à vos numéros d’instance SAP et à votre SID SAP.

Pour ajouter un port de sonde, exécutez ce module PowerShell sur une des machines virtuelles du cluster :

Si vous utilisez SAP ASC/SCS avec le numéro d’instance 02 :

Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62002

Si vous utilisez ERS2 avec le numéro d’instance 12, configurez un port de sonde. Il n’est pas nécessaire de configurer un port de sonde pour ERS1. ERS2 avec le numéro d’instance 12 est en cluster, tandis que ERS1 n’est pas en cluster.
```
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62012 -IsSAPERSClusteredInstance $True
```

Le code de la fonction Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource ressemble à cet exemple :

 function Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource {
 <#
 .SYNOPSIS 
 Set-AzureLoadBalancerHealthProbePortOnSAPClusterIPResource will set a new Azure Load Balancer health probe port on the SAP $SAPSID IP cluster resource.
    
 .DESCRIPTION
 Set-AzureLoadBalancerHealthProbePortOnSAPClusterIPResource will set a new Azure Load Balancer health probe port on the SAP $SAPSID IP cluster resource.
 It will also restart the SAP cluster group (default behavior), to activate the changes. 
    
 You need to run it on one of the SAP ASCS/SCS Windows cluster nodes.
    
 The expectation is that the SAP group is installed with the official SWPM installation tool, which will set the default expected naming convention for:
 - SAP cluster group:               SAP $SAPSID
 - SAP cluster IP address resource: SAP $SAPSID IP 
    
 .PARAMETER SAPSID 
 SAP SID - three characters, starting with a letter.
    
 .PARAMETER ProbePort 
 Azure Load Balancer health check probe port.
    
 .PARAMETER RestartSAPClusterGroup 
 Optional parameter. Default value is $True, so the SAP cluster group will be restarted to activate the changes.
    
 .PARAMETER IsSAPERSClusteredInstance 
 Optional parameter. Default value is $False.
 If it's set to $True, then handle the clustered new SAP ERS2 instance.
    
    
 .EXAMPLE 
 # Set the probe port to 62000 on SAP cluster resource SAP AB1 IP, and restart the SAP cluster group SAP AB1 to activate the changes.
 Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID AB1 -ProbePort 62000 
    
 .EXAMPLE 
 # Set the probe port to 62000 on SAP cluster resource SAP AB1 IP. SAP cluster group SAP AB1 is not restarted, so the changes are not active.
 # To activate the changes, you need to manually restart the SAP AB1 cluster group.
 Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID AB1 -ProbePort 62000 -RestartSAPClusterGroup $False
    
 .EXAMPLE 
 # Set the probe port to 62001 on SAP cluster resource SAP AB1 ERS IP. SAP cluster group SAP AB1 ERS is restarted to activate the changes.
 Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID AB1 -ProbePort 62000 -IsSAPERSClusteredInstance $True
        
 #> 
    
     [CmdletBinding()]
     param(
            
         [Parameter(Mandatory=$True)]
         [ValidateNotNullOrEmpty()]  
         [ValidateLength(3,3)]      
         [string]$SAPSID,

         [Parameter(Mandatory=$True)]
         [ValidateNotNullOrEmpty()]        
         [int] $ProbePort,
    
         [Parameter(Mandatory=$False)] 
         [bool] $RestartSAPClusterGroup = $True,
    
         [Parameter(Mandatory=$False)] 
         [bool] $IsSAPERSClusteredInstance = $False
      
     )
  
     BEGIN{}
        
     PROCESS{
         try{                                      
                
             if($IsSAPERSClusteredInstance){
                 #Handle clustered SAP ERS instance
                 $SAPClusterRoleName = "SAP $SAPSID ERS"
                 $SAPIPresourceName = "SAP $SAPSID ERS IP"            
             }else{
                 #Handle clustered SAP ASCS/SCS instance
                 $SAPClusterRoleName = "SAP $SAPSID"
                 $SAPIPresourceName = "SAP $SAPSID IP"
             }

             $SAPIPResourceClusterParameters =  Get-ClusterResource $SAPIPresourceName | Get-ClusterParameter
             $IPAddress = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "Address" }).Value
             $NetworkName = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "Network" }).Value
             $SubnetMask = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "SubnetMask" }).Value
             $OverrideAddressMatch = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "OverrideAddressMatch" }).Value
             $EnableDhcp = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "EnableDhcp" }).Value
             $OldProbePort = ($SAPIPResourceClusterParameters | Where-Object {$_.Name -eq "ProbePort" }).Value
    
             $var = Get-ClusterResource | Where-Object {  $_.name -eq $SAPIPresourceName  }
    
             #Write-Host "Current configuration parameters for SAP IP cluster resource '$SAPIPresourceName' are:" -ForegroundColor Cyan
             Write-Output "Current configuration parameters for SAP IP cluster resource '$SAPIPresourceName' are:" 
   
             Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
    
             Write-Output " "
             Write-Output "Current probe port property of the SAP cluster resource '$SAPIPresourceName' is '$OldProbePort'." 
             Write-Output " "
             Write-Output "Setting the new probe port property of the SAP cluster resource '$SAPIPresourceName' to '$ProbePort' ..." 
             Write-Output " "
    
             $var | Set-ClusterParameter -Multiple @{"Address"=$IPAddress;"ProbePort"=$ProbePort;"Subnetmask"=$SubnetMask;"Network"=$NetworkName;"OverrideAddressMatch"=$OverrideAddressMatch;"EnableDhcp"=$EnableDhcp}
    
             Write-Output " "
    
             #$ActivateChanges = Read-Host "Do you want to take restart SAP cluster role '$SAPClusterRoleName', to activate the changes (yes/no)?"
    
             if($RestartSAPClusterGroup){
                 Write-Output ""
                 Write-Output "Activating changes..." 
    
                 Write-Output " "
                 Write-Output "Taking SAP cluster IP resource '$SAPIPresourceName' offline ..."
                 Stop-ClusterResource -Name $SAPIPresourceName
                 sleep 5
    
                 Write-Output "Starting SAP cluster role '$SAPClusterRoleName' ..."
                 Start-ClusterGroup -Name $SAPClusterRoleName
    
                 Write-Output "New ProbePort parameter is active." 
                 Write-Output " "
    
                 Write-Output "New configuration parameters for SAP IP cluster resource '$SAPIPresourceName':" 
                 Write-Output " " 
                 Get-ClusterResource -Name $SAPIPresourceName | Get-ClusterParameter
             }else
             {
                 Write-Output "SAP cluster role '$SAPClusterRoleName' is not restarted, therefore changes are not activated."
             }
         }
         catch{
            Write-Error  $_.Exception.Message
        }
    
     }
    
     END {}
 }

Poursuivre l'installation de SAP

Installez l’instance de base de données en suivant la procédure décrite dans le guide d’installation de SAP.
Installez SAP sur le deuxième nœud de cluster en suivant les étapes décrites dans le guide d'installation de SAP.
Installez l’instance du serveur d’application principal (PAS) SAP sur la machine virtuelle qui est désignée pour héberger le serveur PAS.

Suivez la procédure décrite dans le guide d'installation de SAP. Il n’y a aucune dépendance vis-à-vis d’Azure.
Installez des serveurs d’applications SAP supplémentaires sur les machines virtuelles qui sont désignées pour héberger des instances de serveur d’applications SAP.

Suivez la procédure décrite dans le guide d'installation de SAP. Il n’y a aucune dépendance vis-à-vis d’Azure.

Tester le basculement de l’instance SAP ASCS/SCS

Les tests de basculement décrits supposent que SAP ASCS est actif sur le nœud A.

Vérifiez que le système SAP peut basculer correctement du nœud A vers le nœud B. Dans cet exemple, le test est effectué pour SAP SID PR2.

Vérifiez que chaque SID SAP peut passer sur l’autre nœud du cluster. Choisissez l’une des options suivantes pour lancer le basculement du groupe de clusters SAP <SID> du nœud de cluster A au nœud de cluster B :
- Gestionnaire du cluster de basculement
- Commandes PowerShell pour les clusters de basculement
```
$SAPSID = "PR2"     # SAP <SID>

$SAPClusterGroup = "SAP $SAPSID"
Move-ClusterGroup -Name $SAPClusterGroup
```
Redémarrez le nœud de cluster A dans le système d’exploitation invité Windows. Cette étape lance un basculement automatique du groupe de clusters <SID> SAP du nœud A vers le nœud B.
Redémarrez le nœud de cluster A à partir du portail Azure. Cette étape lance un basculement automatique du groupe de clusters <SID> SAP du nœud A vers le nœud B.
Redémarrez le nœud de cluster A à l’aide d’Azure PowerShell. Cette étape lance un basculement automatique du groupe de clusters <SID> SAP du nœud A vers le nœud B.

Partager via