Dela via


SAP ASCS/SCS-instans med hög tillgänglighet för flera SID med Windows Server-redundansklustring och delad Azure-disk

Windows OS Windows

Den här artikeln fokuserar på hur du går från en enda SAP ASCS/SCS-installation till konfiguration av flera SAP-system-ID:n (SID) genom att installera ytterligare SAP ASCS/SCS-klustrade instanser i ett befintligt WSFC-kluster (Windows Server Failover Clustering) med en Delad Azure-disk. När du har slutfört den här processen har du konfigurerat ett SAP multi-SID-kluster.

Förutsättningar och begränsningar

Du kan använda Azure Premium SSD-diskar som Delade Azure-diskar för SAP ASCS/SCS-instansen. Följande begränsningar finns för närvarande:

  • Azure Ultra Disk Storage-diskar och Azure Standard SSD-diskar stöds inte som Delade Azure-diskar för SAP-arbetsbelastningar.
  • Azure-delade diskar med Premium SSD-diskar stöds för SAP-distribution i tillgänglighetsuppsättningar och tillgänglighetszoner.
  • Azure-delade diskar med Premium SSD-diskar har två lagringsalternativ:
    • Lokalt redundant lagring (LRS) för delade Premium SSD-diskar (skuName värdet Premium_LRS) stöds med distribution i tillgänglighetsuppsättningar.
    • Zonredundant lagring (ZRS) för delade Premium SSD-diskar (skuName värdet Premium_ZRS) stöds med distribution i tillgänglighetszoner.
  • MaxShares för azure-delad disk avgör hur många klusternoder som kan använda den delade disken. För en SAP ASCS/SCS-instans konfigurerar du vanligtvis två noder i WSFC. Sedan anger du värdet för maxShares till 2.
  • En Azure-närhetsplaceringsgrupp (PPG) krävs inte för delade Azure-diskar. Men för SAP-distribution med PPG:er följer du dessa riktlinjer:
    • Om du använder PPG:er för ett SAP-system som distribueras i en region måste alla virtuella datorer som delar en disk vara en del av samma PPG.
    • Om du använder PPG:er för ett SAP-system som distribueras mellan zoner, enligt beskrivningen i Närhetsplaceringsgrupper med zonindelade distributioner, kan du ansluta Premium_ZRS lagring till virtuella datorer som delar en disk.

Mer information finns i avsnittet Begränsningar i dokumentationen för delade Azure-diskar.

Viktiga överväganden för delade Premium SSD-diskar

Tänk på dessa viktiga punkter om delade Azure Premium SSD-diskar:

  • LRS för delade Premium SSD-diskar:

    • SAP-distribution med LRS för Delade Premium SSD-diskar fungerar med en enda delad Azure-disk i ett lagringskluster. Om det uppstår ett problem med lagringsklustret där den delade Azure-disken distribueras påverkar det din SAP ASCS/SCS-instans.
  • ZRS för delade Premium SSD-diskar:

    • Skrivfördröjningen för ZRS är högre än LRS eftersom datakopiering mellan zonindelningar är högre.
    • Avståndet mellan tillgänglighetszoner i olika regioner varierar, och det gör även ZRS-diskfördröjningen mellan tillgänglighetszoner. Jämför diskarna för att identifiera svarstiden för ZRS-diskar i din region.
    • ZRS för Premium SSD-delade diskar replikerar synkront data över tre tillgänglighetszoner i regionen. Om det uppstår ett problem i ett av lagringsklusterna fortsätter SAP ASCS/SCS-instansen att köras eftersom redundansväxlingen för lagring är transparent för programskiktet.
    • Mer information finns i avsnittet Begränsningar i dokumentationen om ZRS för hanterade diskar.

Viktigt!

Konfigurationen måste uppfylla följande villkor:

  • SID för varje databashanteringssystem (DBMS) måste ha ett eget dedikerat WSFC-kluster.
  • SAP-programservrar som tillhör ett SAP SID måste ha egna dedikerade virtuella datorer (VM).
  • En blandning av Enqueue Replication Server 1 (ERS1) och Enqueue Replication Server 2 (ERS2) i samma kluster stöds inte.

Operativsystemversioner som stöds

Windows Server 2016, 2019 och senare stöds. Använd de senaste datacenterbilderna.

Vi rekommenderar starkt att du använder minst Windows Server 2019 Datacenter av följande skäl:

  • WSFC i Windows Server 2019 är Azure-medveten.
  • Windows Server 2019 Datacenter innehåller integrering och medvetenhet om Underhåll av Azure-värdar och förbättrad upplevelse genom övervakning av schemalagda Händelser i Azure.
  • Du kan använda distribuerade nätverksnamn. (Det är standardalternativet.) Det finns ingen anledning att ha en dedikerad IP-adress för klustrets nätverksnamn. Du behöver inte heller konfigurera en IP-adress på en intern Azure-lastbalanserare.

Arkitektur

Både ERS1 och ERS2 stöds i en konfiguration med flera SID. En blandning av ERS1 och ERS2 stöds inte i samma kluster.

I följande exempel visas två SAP-SID:er. Båda har en ERS1-arkitektur där:

  • SAP SID1 distribueras på en delad disk med ERS1. ERS-instansen installeras på en lokal värd och på en lokal enhet.

    SAP SID1 har en egen virtuell IP-adress (SID1 (A)SCS IP1), som är konfigurerad på den interna Azure-lastbalanseraren.

  • SAP SID2 distribueras på en delad disk med ERS1. ERS-instansen installeras på en lokal värd och på en lokal enhet.

    SAP SID2 har en egen virtuell IP-adress (SID2 (A)SCS IP2), som konfigureras på den interna Azure-lastbalanseraren.

Diagram över två SAP ASCS/SCS-instanser med hög tillgänglighet med en ERS1-konfiguration.

I nästa exempel visas även två SAP-SID:er. Båda har en ERS2-arkitektur där:

  • SAP SID1 distribueras på en sharddisk med ERS2, som är klustrad och distribueras på en lokal enhet.

    SAP SID1 har en egen virtuell IP-adress (SID1 (A)SCS IP1), som är konfigurerad på den interna Azure-lastbalanseraren.

    SAP ERS2 har en egen virtuell IP-adress (SID1 ERS2 IP2), som är konfigurerad på den interna Azure-lastbalanseraren.

  • SAP SID2 distribueras på en sharddisk med ERS2, som är klustrad och distribueras på en lokal enhet.

    SAP SID2 har en egen virtuell IP-adress (SID2 (A)SCS IP3), som är konfigurerad på den interna Azure-lastbalanseraren.

    SAP ERS2 har en egen virtuell IP-adress (SID2 ERS2 IP4), som konfigureras på den interna Azure-lastbalanseraren.

  • Det finns totalt fyra virtuella IP-adresser:

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

Diagram över två SAP ASCS/SCS-instanser med hög tillgänglighet med en ERS1- och ERS2-konfiguration.

Förberedelse av infrastruktur

Du installerar en ny SAP SID PR2-instans utöver den befintliga klustrade SAP PR1 ASCS/SCS-instansen.

Värdnamn och IP-adresser

Baserat på din distributionstyp bör värdnamnen och IP-adresserna i scenariot vara som i följande exempel.

Här följer information om en SAP-distribution i en Azure-tillgänglighetsuppsättning:

Värdnamnsroll Värdnamn Statisk IP-adress Tillgänglighetsuppsättning Diskvärde SkuName
ASCS/SCS-kluster för första klusternoden pr1-ascs-10 10.0.0.4 pr1-ascs-avset Premium_LRS
Ascs/SCS-kluster för andra klusternoden pr1-ascs-11 10.0.0.5 pr1-ascs-avset
Klusternätverksnamn pr1clust 10.0.0.42 (endast för ett Windows Server 2016-kluster) Inte tillämpligt
SID1 ASCS-klusternätverksnamn pr1-ascscl 10.0.0.43 Inte tillämpligt
SID1 ERS-klusternätverksnamn (endast för ERS2) pr1-erscl 10.0.0.44 Inte tillämpligt
SID2 ASCS-klusternätverksnamn pr2-ascscl 10.0.0.45 Inte tillämpligt
SID2 ERS-klusternätverksnamn (endast för ERS2) pr1-erscl 10.0.0.46 Inte tillämpligt

Här följer information om en SAP-distribution i Azure-tillgänglighetszoner:

Värdnamnsroll Värdnamn Statisk IP-adress Availability zone Diskvärde SkuName
ASCS/SCS-kluster för första klusternoden pr1-ascs-10 10.0.0.4 AZ01 Premium_ZRS
Ascs/SCS-kluster för andra klusternoden pr1-ascs-11 10.0.0.5 AZ02
Klusternätverksnamn pr1clust 10.0.0.42 (endast för ett Windows Server 2016-kluster) Inte tillämpligt
SID1 ASCS-klusternätverksnamn pr1-ascscl 10.0.0.43 Inte tillämpligt
SID2 ERS-klusternätverksnamn (endast för ERS2) pr1-erscl 10.0.0.44 Inte tillämpligt
SID2 ASCS-klusternätverksnamn pr2-ascscl 10.0.0.45 Inte tillämpligt
SID2 ERS-klusternätverksnamn (endast för ERS2) pr1-erscl 10.0.0.46 Inte tillämpligt

Stegen i den här artikeln är desamma för båda distributionstyperna. Men om klustret körs i en tillgänglighetsuppsättning måste du distribuera LRS för delade Azure Premium SSD-diskar (Premium_LRS). Om klustret körs i en tillgänglighetszon måste du distribuera ZRS för delade Azure Premium SSD-diskar (Premium_ZRS).

Skapa en intern Azure-lastbalanserare

För multi-sid-konfiguration av SAP SID, PR2, kan du använda samma interna lastbalanserare som du har skapat för SAP SID, PR1-system. För ENSA1-arkitekturen i Windows behöver du bara en virtuell IP-adress för SAP ASCS/SCS. Å andra sidan kräver ENSA2-arkitekturen två virtuella IP-adresser – en för SAP ASCS och en annan för ERS2.

Konfigurera ytterligare ip-adress och belastningsutjämningsregel för SAP SID, PR2-system på den befintliga lastbalanseraren med hjälp av följande riktlinjer. Det här avsnittet förutsätter att konfigurationen av den interna standardlastbalanseraren för SAP SID, PR1 redan finns på plats enligt beskrivningen i skapa lastbalanserare.

  1. Öppna samma interna standardlastbalanserare som du har skapat för SAP SID, PR1-systemet.
  2. Ip-konfiguration för klientdelen: Skapa klientdels-IP (exempel: 10.0.0.45).
  3. Serverdelspool: Serverdelspoolen är samma som för SAP SID PR1-systemet.
  4. Regler för inkommande trafik: Skapa belastningsutjämningsregel.
    • Klientdels-IP-adress: Välj klientdels-IP
    • Serverdelspool: Välj serverdelspool
    • Kontrollera "Portar med hög tillgänglighet"
    • Protokoll: TCP
    • Hälsoavsökning: Skapa hälsoavsökning med information nedan
      • Protokoll: TCP
      • Port: [till exempel: 620<Instans-nej.> för SAP SID, PR2 ASCS]
      • Intervall: 5
      • Tröskelvärde för avsökning: 2
    • Tidsgräns för inaktivitet (minuter): 30
    • Kontrollera "Aktivera flytande IP"
  5. Gäller endast för ENSA2-arkitektur: Skapa ytterligare klientdels-IP (10.0.0.44), belastningsutjämningsregel (använd 621<Instans-nr.> för ERS2-hälsoavsökningsporten) enligt beskrivningen i punkt 1 och 3.

Kommentar

Egenskapsnummer för hälsoavsökningskonfigurationOfProbes, även kallat "Tröskelvärde för feltillstånd" i portalen, respekteras inte. Så om du vill kontrollera antalet lyckade eller misslyckade efterföljande avsökningar anger du egenskapen "probeThreshold" till 2. Det går för närvarande inte att ange den här egenskapen med hjälp av Azure Portal, så använd antingen Azure CLI- eller PowerShell-kommandot.

Kommentar

När virtuella datorer utan offentliga IP-adresser placeras i serverdelspoolen för en intern (ingen offentlig IP-adress) Standard Azure-lastbalanserare, kommer det inte att finnas någon utgående Internetanslutning om du inte utför ytterligare konfiguration för att tillåta routning till offentliga slutpunkter. Mer information om hur du uppnår utgående anslutning finns i Offentlig slutpunktsanslutning för virtuella datorer som använder Azure Standard Load Balancer i SAP-scenarier med hög tillgänglighet.

Skapa och koppla en andra Delad Azure-disk

Kör det här kommandot på en av klusternoderna. Justera värdena för information som din resursgrupp, Azure-region och SAP SID.

$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

Formatera den delade disken med hjälp av PowerShell

  1. Hämta disknumret. Kör dessa PowerShell-kommandon på en av klusternoderna:

     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. Formatera disken. I det här exemplet är det disknummer 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. Kontrollera att disken nu visas som en klusterdisk:

     # 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. Registrera disken i klustret:

     # 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
    

Skapa ett virtuellt värdnamn för den klustrade SAP ASCS/SCS-instansen

  1. Skapa en DNS-post för det virtuella värdnamnet för den nya SAP ASCS/SCS-instansen i Windows DNS-hanteraren.

    IP-adressen som du tilldelade till det virtuella värdnamnet i DNS måste vara samma som IP-adressen som du tilldelade i Azure Load Balancer.

    Skärmbild som visar alternativ för att definiera en DNS-post för SAP ASCS/SCS-klustrets virtuella namn och IP-adress.

  2. Om du använder en klustrad instans av SAP ERS2 måste du reservera ett virtuellt värdnamn för ERS2 i DNS.

    IP-adressen som du tilldelade till det virtuella värdnamnet för ERS2 i DNS måste vara samma som IP-adressen som du tilldelade i Azure Load Balancer.

    Skärmbild som visar alternativ för att definiera en DNS-post för sap ERS2-klustrets virtuella namn och IP-adress.

  3. Om du vill definiera IP-adressen som tilldelats det virtuella värdnamnet väljer du DNS Manager-domän>.

    Skärmbild som visar ett nytt virtuellt namn och EN IP-adress för SAP ASCS/SCS- och ERS2-klusterkonfiguration.

SAP-installation

Installera den första SAP-klusternoden

Följ installationsproceduren som beskrivs i SAP. Se till att välja Första klusternoden som alternativ för att starta installationen. Välj Klusterdelade diskar som konfigurationsalternativ. Välj den nyligen skapade delade disken.

Ändra SAP-profilen för ASCS/SCS-instansen

Om du kör ERS1 lägger du till SAP-profilparametern enque/encni/set_so_keepalive. Profilparametern förhindrar att anslutningar mellan SAP-arbetsprocesser och enqueue-servern stängs när de är inaktiva för länge. SAP-parametern krävs inte för ERS2.

  1. Lägg till den här profilparametern i SAP ASCS/SCS-instansprofilen om du använder ERS1:

    enque/encni/set_so_keepalive = TRUE
    

    För både ERS1 och ERS2 kontrollerar du att OS-parametrarna har angetts enligt beskrivningen keepalive i SAP-1410736.

  2. Om du vill tillämpa ändringarna på SAP-profilparametern startar du om SAP ASCS/SCS-instansen.

Konfigurera en avsökningsport på klusterresursen

Använd den interna lastbalanserarens avsökningsfunktion för att få hela klusterkonfigurationen att fungera med Azure Load Balancer. Den interna Azure-lastbalanseraren distribuerar vanligtvis den inkommande arbetsbelastningen lika mellan deltagande virtuella datorer.

Den här metoden fungerar dock inte i vissa klusterkonfigurationer eftersom endast en instans är aktiv. Den andra instansen är passiv och kan inte acceptera någon av arbetsbelastningen. En avsökningsfunktion hjälper till när den interna Azure-lastbalanseraren identifierar vilken instans som är aktiv och endast riktar in sig på den aktiva instansen.

Viktigt!

I den här exempelkonfigurationen är avsökningsporten inställd på 620nr. För SAP ASCS med instansnummer 02 är det 62002.

Du måste justera konfigurationen så att den matchar dina SAP-instansnummer och DITT SAP SID.

Om du vill lägga till en avsökningsport kör du den här PowerShell-modulen på någon av de virtuella klusterdatorerna:

  • Om du använder SAP ASC/SCS med instansnummer 02:

    Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62002
    
  • Om du använder ERS2 med instansnummer 12 konfigurerar du en avsökningsport. Du behöver inte konfigurera en avsökningsport för ERS1. ERS2 med instansnummer 12 är klustrad, medan ERS1 inte är klustrad.

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

Koden för funktionen Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource ser ut så här:

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

Fortsätt med SAP-installationen

  1. Installera databasinstansen genom att följa den process som beskrivs i SAP-installationsguiden.

  2. Installera SAP på den andra klusternoden genom att följa stegen som beskrivs i SAP-installationsguiden.

  3. Installera PAS-instansen (SAP Primary Application Server) på den virtuella dator som är avsedd att vara värd för PAS.

    Följ den process som beskrivs i SAP-installationsguiden. Det finns inga beroenden i Azure.

  4. Installera ytterligare SAP-programservrar på de virtuella datorer som är avsedda att vara värdar för SAP-programserverinstanser.

    Följ den process som beskrivs i SAP-installationsguiden. Det finns inga beroenden i Azure.

Testa SAP ASCS/SCS-instansens redundans

De konturerade redundanstesterna förutsätter att SAP ASCS är aktivt på nod A.

  1. Kontrollera att SAP-systemet kan redundansväxla från nod A till nod B. I det här exemplet är testet för SAP SID PR2.

    Kontrollera att varje SAP SID kan flyttas till den andra klusternoden. Välj något av följande alternativ för att initiera en redundansväxling av SAP <SID-klustergruppen> från klusternod A till klusternod B:

    • Hanterare av redundanskluster
    • PowerShell-kommandon för redundanskluster
    $SAPSID = "PR2"     # SAP <SID>
    
    $SAPClusterGroup = "SAP $SAPSID"
    Move-ClusterGroup -Name $SAPClusterGroup
    
    
  2. Starta om klusternoden A i Windows gästoperativsystem. Det här steget initierar en automatisk redundansväxling av SAP <SID-klustergruppen> från nod A till nod B.

  3. Starta om klusternoden A från Azure Portal. Det här steget initierar en automatisk redundansväxling av SAP <SID-klustergruppen> från nod A till nod B.

  4. Starta om klusternoden A med hjälp av Azure PowerShell. Det här steget initierar en automatisk redundansväxling av SAP <SID-klustergruppen> från nod A till nod B.

Nästa steg