Disponibilità elevata multi-SID dell'istanza di SAP ASCS/SCS con Windows Server Failover Clustering e disco condiviso di Azure

  • Articolo

Windows OS Windows

Questo articolo è incentrato su come passare da una singola installazione di SAP ASCS/SCS alla configurazione di più ID di sistema SAP (SID) installando istanze cluster SAP ASCS/SCS aggiuntive in un cluster WSFC (Windows Server Failover Clustering) esistente con un disco condiviso di Azure. Al termine di questo processo, è stato configurato un cluster SAP multi-SID.

Prerequisiti e limitazioni

È possibile usare dischi SSD Premium di Azure come dischi condivisi di Azure per l'istanza di SAP ASCS/SCS. Sono attualmente in vigore le limitazioni seguenti:

  • Dischi Ultra di Azure Archiviazione e dischi SSD Standard di Azure non sono supportati come dischi condivisi di Azure per i carichi di lavoro SAP.
  • I dischi condivisi di Azure con dischi SSD Premium sono supportati per la distribuzione SAP in set di disponibilità e zone di disponibilità.
  • I dischi condivisi di Azure con dischi SSD Premium sono dotati di due opzioni di archiviazione:
    • L'archiviazione con ridondanza locale per i dischi condivisi SSD Premium (skuName valore ) è supportata con la distribuzione nei set di Premium_LRSdisponibilità.
    • L'archiviazione con ridondanza della zona (ZRS) per i dischi condivisi SSD Premium (skuName valore ) è supportata con la distribuzione nelle zone di Premium_ZRSdisponibilità.
  • Il valore maxShares del disco condiviso di Azure determina il numero di nodi del cluster che possono usare il disco condiviso. Per un'istanza di SAP ASCS/SCS, in genere si configurano due nodi in WSFC. Impostare quindi il valore per maxShares su 2.
  • Un gruppo di posizionamento di prossimità di Azure (PPG) non è necessario per i dischi condivisi di Azure. Tuttavia, per la distribuzione SAP con gruppi di disponibilità, seguire queste linee guida:
    • Se si usano gruppi di disponibilità per un sistema SAP distribuito in un'area, tutte le macchine virtuali che condividono un disco devono far parte dello stesso PPG.
    • Se si usano gruppi di disponibilità per un sistema SAP distribuito tra zone, come descritto in Gruppi di posizionamento di prossimità con distribuzioni di zona, è possibile collegare Premium_ZRS l'archiviazione alle macchine virtuali che condividono un disco.

Per altre informazioni, vedere la sezione Limitazioni della documentazione relativa ai dischi condivisi di Azure.

Considerazioni importanti per i dischi condivisi SSD Premium

Considerare questi punti importanti sui dischi condivisi ssd Premium di Azure:

  • Archiviazione con ridondanza locale per dischi condivisi SSD Premium:

    • La distribuzione SAP con archiviazione con ridondanza locale per dischi condivisi SSD Premium opera con un singolo disco condiviso di Azure in un cluster di archiviazione. Se si verifica un problema con il cluster di archiviazione in cui viene distribuito il disco condiviso di Azure, influisce sull'istanza di SAP ASCS/SCS.

  • Archiviazione con ridondanza della zona per dischi condivisi SSD Premium:

    • La latenza di scrittura per l'archiviazione con ridondanza della zona è superiore a quella dell'archiviazione con ridondanza locale perché la copia tra zone dei dati.
    • La distanza tra le zone di disponibilità in aree diverse varia e quindi la latenza del disco con ridondanza della zona tra zone di disponibilità. Eseguire il benchmark dei dischi per identificare la latenza dei dischi dell'archiviazione con ridondanza della zona nell'area.
    • L'archiviazione con ridondanza della zona per dischi condivisi SSD Premium replica in modo sincrono i dati in tre zone di disponibilità nell'area. Se si verifica un problema in uno dei cluster di archiviazione, l'istanza di SAP ASCS/SCS continua a essere eseguita perché il failover di archiviazione è trasparente al livello dell'applicazione.
    • Per altre informazioni, vedere la sezione Limitazioni della documentazione sull'archiviazione con ridondanza della zona per i dischi gestiti.

Importante

Il programma di installazione deve soddisfare le condizioni seguenti:

  • Il SID per ogni sistema di gestione di database (DBMS) deve avere un proprio cluster WSFC dedicato.
  • I server applicazioni SAP che appartengono a un SID SAP devono avere macchine virtuali dedicate.
  • Non è supportata una combinazione di Server di replica accodamento 1 (ERS1) e Replica accodamento server 2 (ERS2) nello stesso cluster.

Versioni del sistema operativo supportate

Windows Server 2016, 2019 e versioni successive sono supportati. Usare le immagini più recenti del data center.

Per questi motivi, è consigliabile usare almeno Windows Server 2019 Datacenter:

  • WSFC in Windows Server 2019 è compatibile con Azure.
  • Windows Server 2019 Datacenter include l'integrazione e la consapevolezza della manutenzione degli host di Azure e un'esperienza migliorata monitorando gli eventi pianificati di Azure.
  • È possibile usare nomi di rete distribuiti. È l'opzione predefinita. Non è necessario avere un indirizzo IP dedicato per il nome di rete del cluster. Inoltre, non è necessario configurare un indirizzo IP in un servizio di bilanciamento del carico interno di Azure.

Architettura

Sia ERS1 che ERS2 sono supportati in una configurazione multi-SID. Una combinazione di ERS1 e ERS2 non è supportata nello stesso cluster.

L'esempio seguente illustra due SID SAP. Entrambi hanno un'architettura ERS1 in cui:

  • SAP SID1 viene distribuito in un disco condiviso con ERS1. L'istanza di ERS viene installata in un host locale e in un'unità locale.

    SAP SID1 ha un proprio indirizzo IP virtuale (SID1 (A)SCS IP1), configurato nel servizio di bilanciamento del carico interno di Azure.

  • SAP SID2 viene distribuito in un disco condiviso con ERS1. L'istanza di ERS viene installata in un host locale e in un'unità locale.

    SAP SID2 ha un proprio indirizzo IP virtuale (SID2 (A)SCS IP2), configurato nel servizio di bilanciamento del carico interno di Azure.

Diagram of two high-availability SAP ASCS/SCS instances with an ERS1 configuration.

L'esempio seguente mostra anche due SID SAP. Entrambi hanno un'architettura ERS2 in cui:

  • SAP SID1 viene distribuito in un disco di partizione con ERS2, cluster e distribuito in un'unità locale.

    SAP SID1 ha un proprio indirizzo IP virtuale (SID1 (A)SCS IP1), configurato nel servizio di bilanciamento del carico interno di Azure.

    SAP ERS2 ha un proprio indirizzo IP virtuale (SID1 ERS2 IP2), configurato nel servizio di bilanciamento del carico interno di Azure.

  • SAP SID2 viene distribuito in un disco di partizione con ERS2, che viene clusterato e distribuito in un'unità locale.

    SAP SID2 ha un proprio indirizzo IP virtuale (SID2 (A)SCS IP3), configurato nel servizio di bilanciamento del carico interno di Azure.

    SAP ERS2 ha un proprio indirizzo IP virtuale (SID2 ERS2 IP4), configurato nel servizio di bilanciamento del carico interno di Azure.

  • È presente un totale di quattro indirizzi IP virtuali:

    • SID1 (A)SCS IP1
    • SID2 ERS2 IP2
    • SID2 (A)SCS IP3
    • SID2 ERS2 IP4

Diagram of two high-availability SAP ASCS/SCS instances with an ERS1 and ERS2 configuration.

Preparazione dell'infrastruttura

Si installa una nuova istanza DI SAP SID PR2, oltre all'istanza SAP PR1 ASCS/SCS esistente in cluster.

Nomi host e indirizzi IP

In base al tipo di distribuzione, i nomi host e gli indirizzi IP dello scenario devono essere simili agli esempi seguenti.

Ecco i dettagli per una distribuzione SAP in un set di disponibilità di Azure:

Ruolo nome host Host name Indirizzo IP statico Set di disponibilità Valore disco SkuName
Cluster ASCS/SCS del primo nodo del cluster pr1-ascs-10 10.0.0.4 pr1-ascs-avset Premium_LRS
Cluster ASCS/SCS del secondo nodo del cluster pr1-ascs-11 10.0.0.5 pr1-ascs-avset
Nome di rete del cluster pr1clust 10.0.0.42 (solo per un cluster Windows Server 2016) Non applicabile
SiD1 nome di rete del cluster ASCS pr1-ascscl 10.0.0.43 Non applicabile
Nome di rete del cluster SID1 ERS (solo per ERS2) pr1-erscl 10.0.0.44 Non applicabile
Nome di rete del cluster SID2 ASCS pr2-ascscl 10.0.0.45 Non applicabile
Nome di rete del cluster SID2 ERS (solo per ERS2) pr1-erscl 10.0.0.46 Non applicabile

Ecco i dettagli per una distribuzione SAP nelle zone di disponibilità di Azure:

Ruolo nome host Host name Indirizzo IP statico Zona di disponibilità Valore disco SkuName
Cluster ASCS/SCS del primo nodo del cluster pr1-ascs-10 10.0.0.4 AZ01 Premium_ZRS
Cluster ASCS/SCS del secondo nodo del cluster pr1-ascs-11 10.0.0.5 AZ02
Nome di rete del cluster pr1clust 10.0.0.42 (solo per un cluster Windows Server 2016) Non applicabile
SiD1 nome di rete del cluster ASCS pr1-ascscl 10.0.0.43 Non applicabile
Nome di rete del cluster SID2 ERS (solo per ERS2) pr1-erscl 10.0.0.44 Non applicabile
Nome di rete del cluster SID2 ASCS pr2-ascscl 10.0.0.45 Non applicabile
Nome di rete del cluster SID2 ERS (solo per ERS2) pr1-erscl 10.0.0.46 Non applicabile

I passaggi descritti in questo articolo rimangono invariati per entrambi i tipi di distribuzione. Tuttavia, se il cluster è in esecuzione in un set di disponibilità, è necessario distribuire l'archiviazione con ridondanza locale per dischi condivisi SSD Premium di Azure (Premium_LRS). Se il cluster è in esecuzione in una zona di disponibilità, è necessario distribuire l'archiviazione con ridondanza della zona per i dischi condivisi ssd Premium di Azure (Premium_ZRS).

Creare un servizio di bilanciamento del carico interno di Azure

Per la configurazione a più sid di SAP SID, PR2, è possibile usare lo stesso servizio di bilanciamento del carico interno creato per il sistema SAP SID, PR1. Per l'architettura ENSA1 in Windows, è necessario un solo indirizzo IP virtuale per SAP ASCS/SCS. D'altra parte, l'architettura ENSA2 richiede due indirizzi IP virtuali, uno per SAP ASCS e un altro per ERS2.

Configurare altre regole di bilanciamento del carico e IP front-end per SAP SID, sistema PR2 nel servizio di bilanciamento del carico esistente usando le linee guida seguenti. Questa sezione presuppone che la configurazione del servizio di bilanciamento del carico interno standard per SAP SID, PR1 sia già disponibile come descritto in Creare il servizio di bilanciamento del carico.

  1. Aprire lo stesso servizio di bilanciamento del carico interno standard creato per il sistema SAP SID, PR1.
  2. Configurazione IP front-end: creare un indirizzo IP front-end (ad esempio: 10.0.0.45).
  3. Pool back-end: il pool back-end è uguale a quello del sistema SAP SID PR1.
  4. Regole in ingresso: creare una regola di bilanciamento del carico.
    • Indirizzo IP front-end: selezionare ip front-end
    • Pool back-end: selezionare il pool back-end
    • Controllare "Porte a disponibilità elevata"
    • Protocollo: TCP
    • Probe di integrità: creare un probe di integrità con i dettagli seguenti
      • Protocollo: TCP
      • Porta: [ad esempio: 620<Instance-no.> per SAP SID, PR2 ASCS]
      • Intervallo: 5
      • Soglia probe: 2
    • Timeout di inattività (minuti): 30
    • Selezionare "Enable Floating IP" (Abilita IP mobile)
  5. Applicabile solo all'architettura ENSA2: creare un indirizzo IP front-end aggiuntivo (10.0.0.44), una regola di bilanciamento del carico (usare 621<Instance-no.> per la porta probe di integrità ERS2), come descritto nel punto 1 e 3.

Nota

Il numero della proprietà di configurazione del probe di integritàOfProbes, altrimenti noto come "Soglia non integra" nel portale, non viene rispettato. Per controllare il numero di probe consecutivi riusciti o non riusciti, impostare la proprietà "probeThreshold" su 2. Attualmente non è possibile impostare questa proprietà usando portale di Azure, quindi usare l'interfaccia della riga di comando di Azure o il comando di PowerShell.

Importante

Un indirizzo IP mobile non è supportato in una configurazione IP secondaria della scheda di interfaccia di rete (NIC) in scenari di bilanciamento del carico. Per informazioni dettagliate, vedere Limitazioni di Azure Load Balancer. Se è necessario un altro indirizzo IP per la macchina virtuale, distribuire una seconda scheda di interfaccia di rete.

Nota

Quando le macchine virtuali senza indirizzi IP pubblici vengono inserite nel pool back-end di un servizio di bilanciamento del carico Di Azure Standard (nessun indirizzo IP pubblico), non ci sarà connettività Internet in uscita, a meno che non si esegua una configurazione aggiuntiva per consentire il routing agli endpoint pubblici. Per informazioni dettagliate su come ottenere la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali con Azure Load Balancer Standard in scenari di disponibilità elevata SAP.

Creare e collegare un secondo disco condiviso di Azure

Eseguire questo comando in uno dei nodi del cluster. Modificare i valori per i dettagli, ad esempio il gruppo di risorse, l'area di Azure e il 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

Formattare il disco condiviso usando PowerShell

  1. Ottenere il numero del disco. Eseguire questi comandi di PowerShell in uno dei nodi del 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

  2. Formattare il disco. In questo esempio si tratta del numero di disco 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

  3. Verificare che il disco sia ora visibile come disco del 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\}

  4. Registrare il disco nel 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

Creare un nome host virtuale per l'istanza ASCS/SCS di SAP in cluster

  1. Creare una voce DNS per il nome host virtuale per la nuova istanza di SAP ASCS/SCS nella gestione DNS Windows.

    L'indirizzo IP assegnato al nome host virtuale in DNS deve corrispondere all'indirizzo IP assegnato in Azure Load Balancer.

    Screenshot that shows options for defining a DNS entry for the SAP ASCS/SCS cluster virtual name and IP address.

  2. Se si usa un'istanza in cluster di SAP ERS2, è necessario riservare in DNS un nome host virtuale per ERS2.

    L'indirizzo IP assegnato al nome host virtuale per ERS2 in DNS deve corrispondere all'indirizzo IP assegnato in Azure Load Balancer.

    Screenshot that shows options for defining a DNS entry for the SAP ERS2 cluster virtual name and IP address.

  3. Per definire l'indirizzo IP assegnato al nome host virtuale, selezionare Gestore DNS>Dominio.

    Screenshot that shows a new virtual name and IP address for SAP ASCS/SCS and ERS2 cluster configuration.

Installazione di SAP

Installare il primo nodo del cluster SAP

Seguire la procedura di installazione descritta da SAP. Assicurarsi di selezionare First Cluster Node (Primo nodo cluster) come opzione per avviare l'installazione. Selezionare Cluster Shared Disk (Disco condiviso cluster) come opzione di configurazione. Scegliere il disco condiviso appena creato.

Modificare il profilo SAP dell'istanza di ASCS/SCS

Se si esegue ERS1, aggiungere il parametro enque/encni/set_so_keepalivedel profilo SAP . Il parametro del profilo impedisce la chiusura delle connessioni tra i processi di lavoro SAP e il server di accodamento quando sono inattive per troppo tempo. Il parametro SAP non è necessario per ERS2.

  1. Aggiungere questo parametro di profilo al profilo di istanza di SAP ASCS/SCS, se si usa ERS1:

    enque/encni/set_so_keepalive = true

    Per ERS1 e ERS2, assicurarsi che i parametri del keepalive sistema operativo siano impostati come descritto nella nota SAP 1410736.

  2. Per applicare le modifiche al parametro del profilo SAP, riavviare l'istanza di SAP ASCS/SCS.

Configurare una porta probe nella risorsa cluster

Usare la funzionalità probe del servizio di bilanciamento del carico interno per il corretto funzionamento della configurazione del cluster con Azure Load Balancer. Il servizio di bilanciamento del carico interno di Azure distribuisce in genere il carico di lavoro in ingresso in modo uniforme tra le macchine virtuali.

Tuttavia, questo approccio non funzionerà in alcune configurazioni del cluster perché è attiva una sola istanza. L'altra istanza è passiva e non può accettare carichi di lavoro. Una funzionalità probe è utile quando il servizio di bilanciamento del carico interno di Azure rileva quale istanza è attiva e è destinata solo all'istanza attiva.

Importante

In questa configurazione di esempio la porta probe è impostata su 620nr. Per SAP ASCS con numero di istanza 02, è 62002.

È necessario modificare la configurazione in modo che corrisponda ai numeri di istanza SAP e al SID SAP.

Per aggiungere una porta probe, eseguire questo modulo di PowerShell in una delle macchine virtuali del cluster:

  • Se si usa SAP ASC/SCS con il numero di istanza 02:

    Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62002

  • Se si usa ERS2 con il numero di istanza 12, configurare una porta probe. Non è necessario configurare una porta probe per ERS1. ERS2 con numero di istanza 12 è cluster, mentre ERS1 non è cluster.

    Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62012 -IsSAPERSClusteredInstance $True

Il codice per la funzione Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource è simile all'esempio seguente:

 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 {}
 }

Continuare con l'installazione di SAP

  1. Installare l'istanza del database seguendo il processo descritto nella guida all'installazione di SAP.

  2. Installare SAP nel secondo nodo del cluster seguendo i passaggi descritti nella guida all'installazione di SAP.

  3. Installare l'istanza di SAP Primary Application Server (PAS) nella macchina virtuale designata per ospitare il pas.

    Seguire il processo descritto nella guida all'installazione di SAP. Non sono presenti dipendenze in Azure.

  4. Installare server applicazioni SAP aggiuntivi nelle macchine virtuali designate per ospitare istanze del server applicazioni SAP.

    Seguire il processo descritto nella guida all'installazione di SAP. Non sono presenti dipendenze in Azure.

Testare il failover dell'istanza di SAP ASCS/SCS

I test di failover descritti presuppongono che SAP ASCS sia attivo nel nodo A.

  1. Verificare che il sistema SAP possa eseguire correttamente il failover dal nodo A al nodo B. In questo esempio, il test è per SAP SID PR2.

    Assicurarsi che ogni SID SAP possa passare correttamente all'altro nodo del cluster. Scegliere una di queste opzioni per avviare un failover del gruppo di cluster <SID> di SAP dal nodo A al nodo B del cluster:

    • Gestione cluster di failover
    • Comandi di PowerShell per i cluster di failover
    $SAPSID = "PR2"     # SAP <SID>

$SAPClusterGroup = "SAP $SAPSID"
Move-ClusterGroup -Name $SAPClusterGroup

  2. Riavviare il nodo A del cluster all'interno del sistema operativo guest Windows. Questo passaggio avvia un failover automatico del gruppo di cluster SID> SAP <dal nodo A al nodo B.

  3. Riavviare il nodo A del cluster dal portale di Azure. Questo passaggio avvia un failover automatico del gruppo di cluster SID> SAP <dal nodo A al nodo B.

  4. Riavviare il nodo A del cluster usando Azure PowerShell. Questo passaggio avvia un failover automatico del gruppo di cluster SID> SAP <dal nodo A al nodo B.

Passaggi successivi