Freigeben über

Multi-SID-Hochverfügbarkeit für SAP ASCS/SCS-Instanzen mit Windows Server-Failoverclustering und freigegebenem Azure-Datenträger

  • Artikel

Windows-Betriebssystem Windows

In diesem Artikel wird der Übergang von einer einzelnen SAP ASCS/SCS-Installation zur Konfiguration mehrerer SAP-System-IDs (SIDs) durch Installation zusätzlicher SAP ASCS/SCS-Clusterinstanzen in einem vorhandenen WSFC-Cluster (Windows Server-Failoverclustering) mit einem freigegebenen Azure-Datenträger behandelt. Wenn Sie diesen Vorgang abgeschlossen haben, haben Sie einen SAP Multi-SID-Cluster konfiguriert.

Voraussetzungen und Einschränkungen

Sie können Azure SSD Premium-Datenträger als freigegebene Azure-Datenträger für die SAP ASCS/SCS-Instanz verwenden. Derzeit gelten die folgenden Einschränkungen:

  • Der Azure Disk Storage Ultra-Datenträger und Azure SSD-Standard-Datenträger werden nicht als freigegebener Azure-Datenträger für SAP-Workloads unterstützt.
  • Freigegebene Azure-Datenträger mit SSD Premium-Datenträgern werden für die SAP-Bereitstellung in Verfügbarkeitsgruppen und Verfügbarkeitszonen unterstützt.
  • Freigegebene Azure-Datenträger SSD Premium-Datenträgern verfügen über zwei Speicheroptionen:
    • Lokal redundanter Speicher (LRS) für freigegebenen SSD Premium-Datenträger (skuName-Wert von Premium_LRS) wird bei der Bereitstellung in Verfügbarkeitsgruppen unterstützt.
    • Zonenredundanter Speicher (ZRS) für freigegebenen SSD Premium-Datenträger (skuName-Wert von Premium_ZRS) wird bei der Bereitstellung in Verfügbarkeitszonen unterstützt.
  • Der Wert maxShares des freigegebenen Azure-Datenträgers bestimmt, wie viele Clusterknoten den freigegebenen Datenträger verwenden können. Bei einer SAP ASCS/SCS-Instanz konfigurieren Sie in der Regel zwei Knoten in WSFC. Anschließend legen Sie den Wert für maxShares auf 2 fest.
  • Eine Azure-Näherungsplatzierungsgruppe (PPG) ist für freigegebene Azure-Datenträger nicht erforderlich. Für die Bereitstellung von SAP mit PPGs sollten Sie jedoch diese Richtlinien befolgen:
    • Wenn Sie PPGs für ein SAP-System verwenden, die in einer Region bereitgestellt werden, müssen alle VMs, die sich einen Datenträger teilen, Teil derselben PPG sein.
    • Wenn Sie PPGs für ein SAP-System verwenden, die über Zonen hinweg bereitgestellt werden, wie in Näherungsplatzierungsgruppen mit zonalen Bereitstellungen beschrieben, können Sie Premium_ZRS-Speicher für VMs anfügen, die sich einen Datenträger teilen.

Weitere Informationen hierzu erfahren Sie im Abschnitt Einschränkungen der Dokumentation für freigegebene Azure-Datenträger.

Wichtige Überlegungen für freigegebene SSD Premium-Datenträger

Beachten Sie die folgenden wichtigen Punkte zu freigegebenen Azure SSD Premium-Datenträgern:

  • LRS für freigegebene SSD Premium-Datenträger

    • Die SAP-Bereitstellung mit LRS für freigegebene SSD Premium-Datenträger wird mit einem einzelnen freigegebenen Azure-Datenträger in einem Speichercluster ausgeführt. Wenn ein Problem mit dem Speichercluster auftritt, in dem der freigegebene Azure-Datenträger bereitgestellt wird, beeinträchtigen Ihre SAP ASCS/SCS-Instanz.

  • ZRS für freigegebene SSD Premium-Datenträger:

    • Die Wartezeit beim Schreiben für ZRS ist aufgrund der zonenübergreifenden Kopie von Daten höher als die von LRS.
    • Der Abstand zwischen Verfügbarkeitszonen in verschiedenen Regionen variiert, ebenso wie ZRS-Datenträgerlatenz über Verfügbarkeitszonen. Vergleichen Sie Ihre Datenträger, um die Latenz der ZRS-Datenträger in Ihrer Region zu ermitteln.
    • ZRS für freigegebene SSD Premium-Datenträger repliziert Daten synchron über drei Verfügbarkeitszonen in der Region. Im Falle eines Problems in einem der Speichercluster wird Ihre SAP ASCS/SCS-Instanz weiterhin ausgeführt, da das Speicherfailover für die Anwendungsschicht transparent ist.
    • Weitere Informationen hierzu erfahren Sie im Abschnitt Einschränkungen der Dokumentation für ZRS für verwaltete Datenträger.

Wichtig

Das Setup muss die folgenden Bedingungen erfüllen:

  • Die SID für jedes Datenbank-Verwaltungssystem (DBMS) muss über ihren eigenen dedizierten WSFC-Cluster verfügen.
  • SAP-Anwendungsserver, die zur gleichen SAP-SID gehören, müssen eigene dedizierte virtuelle Computer (VMs) aufweisen.
  • Eine Kombination von Enqueue Replication Server 1 (ERS1) und Enqueue Replication Server 2 (ERS2) im gleichen Cluster wird nicht unterstützt.

Unterstützte Betriebssystemversionen

Windows Server 2016, 2019 oder höher wird unterstützt. Verwenden Sie die neuesten Bilder des Rechenzentrums.

Aus folgenden Gründen wird dringend empfohlen, mindestens Windows Server 2019 Datacenter zu verwenden:

  • WSFC in Windows Server 2019 ist Azure-fähig.
  • Windows Server 2019 Datacenter umfasst Integration und Kenntnisse über die Azure-Hostwartung sowie verbesserte Benutzerfreundlichkeit durch die Überwachung auf geplante Azure-Ereignisse.
  • Sie können verteilte Netzwerknamen verwenden. (Das ist die Standardoption.) Eine dedizierte IP-Adresse für den Namen des Clusternetzwerks ist nicht erforderlich. Außerdem müssen Sie keine IP-Adresse auf einem internen Azure Load Balancer konfigurieren.

Aufbau

Sowohl ERS1 als auch ERS2 werden in einer Multi-SID-Konfiguration unterstützt. Eine Kombination von ERS1 und ERS2 im gleichen Cluster wird nicht unterstützt.

Das folgende Beispiel zeigt zwei SAP-SIDs. Beide haben eine ERS1-Architektur, in der:

  • SAP-SID1 auf einem freigegebenen Datenträger mit ERS1 bereitgestellt wird. Die ERS-Instanz auf dem lokalen Host und dem lokalen Laufwerk installiert ist.

    SAP-SID1 über eine eigene (virtuelle) IP-Adresse (SID1 (A)SCS IP1) verfügt, die auf dem internen Azure Load Balancer konfiguriert wird.

  • SAP-SID2 auf einem freigegebenen Datenträger mit ERS1 bereitgestellt wird. Die ERS-Instanz auf dem lokalen Host und dem lokalen Laufwerk installiert ist.

    SAP-SID2 über eine eigene (virtuelle) IP-Adresse (SID2 (A)SCS IP2) verfügt, die auf dem internen Azure Load Balancer konfiguriert wird.

Diagramm von zwei SAP ASCS/SCS-Instanzen mit Hochverfügbarkeit und einer ERS1-Konfiguration

Das nächste Beispiel zeigt auch zwei SAP-SIDs. Beide haben eine ERS2-Architektur, in der:

  • SAP-SID1 auf einem freigegebenen Datenträger mit ERS2 bereitgestellt wird, der gruppiert ist und auf einem lokalen Laufwerk bereitgestellt wird.

    SAP-SID1 über eine eigene (virtuelle) IP-Adresse (SID1 (A)SCS IP1) verfügt, die auf dem internen Azure Load Balancer konfiguriert wird.

    SAP-ERS2 über eine eigene (virtuelle) IP-Adresse (SID1 ERS2 IP2) verfügt, die auf dem internen Azure Load Balancer konfiguriert wird.

  • SAP-SID2 auf einem freigegebenen Datenträger mit ERS2 bereitgestellt wird, der gruppiert ist und auf einem lokalen Laufwerk bereitgestellt wird.

    SAP-SID2 verfügt über eine eigene (virtuelle) IP-Adresse (SID2 (A)SCS IP3), die auf dem internen Azure Load Balancer konfiguriert wird.

    SAP-ERS2 über eine eigene (virtuelle) IP-Adresse (SID2 ERS2 IP4) verfügt, die auf dem internen Azure Load Balancer konfiguriert wird.

  • Es gibt insgesamt vier virtuelle IP-Adressen:

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

Diagramm von zwei SAP ASCS/SCS-Instanzen mit Hochverfügbarkeit und einer ERS1- und ERS2-Konfiguration

Infrastrukturelle Vorbereitung

Sie installieren zusätzlich zur vorhandenen gruppierten SAP PR1 ASCS/SCS-Instanz eine neue SAP SID PR2-Instanz.

Hostnamen und IP-Adressen

Basierend auf Ihrem Bereitstellungstyp würden die Hostnamen und IP-Adressen des Szenarios wie in den folgenden Beispielen lauten.

Hier sind die Details für eine SAP-Bereitstellung in einem Azure-Verfügbarkeitssatz:

Hostnamenrolle Hostname Statische IP-Adresse Verfügbarkeitsgruppe Datenträger-SkuName-Wert
Erster ASCS-/SCS-Cluster des Clusterknotens pr1-ascs-10 10.0.0.4 pr1-ascs-avset Premium_LRS
Zweiter ASCS-/SCS-Cluster des Clusterknotens pr1-ascs-11 10.0.0.5 pr1-ascs-avset
Name des Clusternetzwerks: pr1clust 10.0.0.42 (nur für einen Windows Server 2016-Cluster) Nicht zutreffend
Name des ASCS-Clusternetzwerks von SID1 pr1-ascscl 10.0.0.43 Nicht zutreffend
Name des ERS-Clusternetzwerks von SID1 (nur für ERS2) pr1-erscl 10.0.0.44 Nicht zutreffend
Name des ASCS-Clusternetzwerks von SID2 pr2-ascscl 10.0.0.45 Nicht zutreffend
Name des ERS-Clusternetzwerks von SID2 (nur für ERS2) pr1-erscl 10.0.0.46 Nicht zutreffend

Hier sind die Details für eine SAP-Bereitstellung in Azure-Verfügbarkeitszonen:

Hostnamenrolle Hostname Statische IP-Adresse Verfügbarkeitszone Datenträger-SkuName-Wert
Erster ASCS-/SCS-Cluster des Clusterknotens pr1-ascs-10 10.0.0.4 AZ01 Premium_ZRS
Zweiter ASCS-/SCS-Cluster des Clusterknotens pr1-ascs-11 10.0.0.5 AZ02
Name des Clusternetzwerks: pr1clust 10.0.0.42 (nur für einen Windows Server 2016-Cluster) Nicht zutreffend
Name des ASCS-Clusternetzwerks von SID1 pr1-ascscl 10.0.0.43 Nicht zutreffend
Name des ERS-Clusternetzwerks von SID2 (nur für ERS2) pr1-erscl 10.0.0.44 Nicht zutreffend
Name des ASCS-Clusternetzwerks von SID2 pr2-ascscl 10.0.0.45 Nicht zutreffend
Name des ERS-Clusternetzwerks von SID2 (nur für ERS2) pr1-erscl 10.0.0.46 Nicht zutreffend

Die Schritte in diesem Artikel bleiben für beide Bereitstellungstypen gleich. Wenn Ihr Cluster jedoch in einem Verfügbarkeitssatz ausgeführt wird, müssen Sie LRS für freigegebene Azure SSD Premium-Datenträger (Premium_LRS) bereitstellen. Wenn Ihr Cluster jedoch in einer Verfügbarkeitszone ausgeführt wird, müssen Sie ZRS für freigegebene Azure SSD Premium-Datenträger (Premium_ZRS) bereitstellen.

Erstellen einer internen Azure Load Balancer-Instanz

Für die Multi-Sid-Konfiguration von SAP-SID, PR2, könnten Sie den gleichen internen Lastenausgleich verwenden, den Sie für SAP-SID, PR1, erstellt haben. Für die ENSA1-Architektur unter Windows benötigen Sie nur eine virtuelle IP-Adresse für SAP ASCS/SCS. Andererseits erfordert die ENSA2-Architektur zwei virtuelle IP-Adressen: eine für SAP ASCS und eine für ERS2.

Konfigurieren Sie zusätzliche Front-End-IP und Lastenausgleichsregel für SAP-SID, PR2-System, auf dem vorhandenen Lastenausgleich mithilfe der folgenden Richtlinien. In diesem Abschnitt wird davon ausgegangen, dass die Konfiguration des standardmäßigen internen Lastenausgleichs für SAP-SID, PR1, bereits vorhanden ist, wie in Erstellen des Lastenausgleichs beschrieben.

  1. Öffnen Sie den gleichen standardmäßigen internen Lastenausgleich, den Sie für SAP-SID, PR1, erstellt haben.
  2. Front-End-IP-Konfiguration: Erstellen Sie die IP-Adresse des Front-Ends (Beispiel: 10.0.0.45).
  3. Back-End-Pool: Der Back-End-Pool ist identisch mit dem des SAP-SID PR1-Systems.
  4. Regeln für eingehenden Datenverkehr: Erstellen Sie die Lastenausgleichsregel.
    • Front-End-IP-Adresse: Wählen Sie die Front-End-IP-Adresse aus.
    • Back-End-Pool: Wählen Sie den Back-End-Pool aus.
    • Aktivieren Sie „Hochverfügbarkeitsports“.
    • Protokoll: TCP
    • Integritätstest: Erstellen Sie einen Integritätstest mit folgenden Details:
      • Protokoll: TCP
      • Port: [z. B. „620<Instanz-Nr.>“ für SAP-SID, PR2 ASCS]
      • Intervall: 5
      • Schwellenwert für Integritätstest: 2
    • Leerlauftimeout (Minuten): 30
    • Aktivieren Sie „Floating IP aktivieren“.
  5. Gilt nur für die ENSA2-Architektur: Erstellen Sie eine zusätzliche Front-End-IP (10.0.0.44), eine Lastenausgleichsregel (verwenden Sie 621<Instanz-Nr.> für den ERS2-Integritätssondenport), wie in Punkt 1 und 3 beschrieben.

Hinweis

Die Konfigurationseigenschaft „numberOfProbes“ für Integritätstests (im Portal als „Fehlerschwellenwert“ bezeichnet) wird nicht berücksichtigt. Um also die Anzahl erfolgreicher oder nicht erfolgreicher aufeinanderfolgender Integritätstests zu steuern, legen Sie die Eigenschaft „probeThreshold“ auf „2“ fest. Es ist derzeit nicht möglich, diese Eigenschaft über das Azure-Portal festzulegen. Verwenden Sie daher entweder den Befehl für die Azure CLI oder den Befehl für PowerShell.

Hinweis

Wenn VMs ohne öffentliche IP-Adressen im Back-End-Pool einer internen Azure Load Balancer Standard-Instanz (ohne öffentliche IP-Adresse) platziert werden, besteht keine Internetkonnektivität in ausgehender Richtung, sofern Sie nicht durch zusätzliche Konfigurationsschritte das Routing an öffentliche Endpunkte zulassen. Ausführliche Informationen zum Erreichen ausgehender Konnektivität finden Sie unter Konnektivität mit öffentlichen Endpunkten für VMs mithilfe von Azure Load Balancer Standard in SAP-Szenarien mit Hochverfügbarkeit.

Erstellen und Anfügen eines zweiten freigegebenen Azure-Datenträgers

Führen Sie diesen Befehl auf einem der Clusterknoten aus. Passen Sie die Werte für Details wie Ihre Ressourcengruppe, Azure-Region und SAP-SID an.

$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

Formatieren des freigegebenen Datenträgers mithilfe von PowerShell

  1. Rufen Sie die Datenträgernummer ab. Führen Sie diese PowerShell-Befehle auf einem der Clusterknoten aus:

     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. Formatieren Sie den Datenträger. In diesem Beispiel handelt es sich um Datenträger Nr. 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 output
 # DriveLetter FileSystemLabel FileSystem DriveType HealthStatus OperationalStatus SizeRemaining      Size
 # ----------- --------------- ---------- --------- ------------ ----------------- -------------      ----
 # S           PR2SAP          ReFS       Fixed     Healthy      OK                    504.98 GB 511.81 GB

  3. Vergewissern Sie sich, dass der Datenträger jetzt als Clusterdatenträger sichtbar ist:

     # 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. Registrieren Sie den Datenträger im 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

Erstellen eines virtuellen Hostnamens für die SAP ASCS/SCS-Clusterinstanz

  1. Erstellen Sie einen DNS-Eintrag für den virtuellen Hostnamen der neuen SAP ASCS/SCS-Instanz im Windows-DNS-Manager.

    Die IP-Adresse, die Sie dem virtuellen Hostnamen in DNS zugewiesen haben, muss der IP-Adresse entsprechen, die Sie in Azure Load Balancer zugewiesen haben.

    Screenshot: Optionen für das Definieren eines DNS-Eintrags für den virtuellen SAP ASCS/SCS-Clusternamen und der IP-Adresse

  2. Wenn Sie eine gruppierte Instanz von SAP ERS2 verwenden, müssen Sie in DNS einen virtuellen Hostnamen für ERS2 reservieren.

    Die IP-Adresse, die Sie dem virtuellen Hostnamen für ERS2 in DNS zugewiesen haben, muss der IP-Adresse entsprechen, die Sie in Azure Load Balancer zugewiesen haben.

    Screenshot: Optionen für das Definieren eines DNS-Eintrags für den virtuellen SAP ERS2-Clusternamen und der IP-Adresse

  3. Wählen Sie zum Definieren der IP-Adresse, die dem virtuellen Hostnamen zugewiesen ist, die Option DNS-Manager>Domäne.

    Screenshot: Neuer virtueller Name und IP-Adresse für SAP ASCS/SCS- und ERS2-Clusterkonfiguration

SAP-Installation

Installieren des ersten SAP-Clusterknotens

Führen Sie das von SAP beschriebene Installationsverfahren aus. Achten Sie darauf, den ersten Clusterknoten als Option zum Starten der Installation auszuwählen. Wählen Sie Freigegebener Clusterdatenträger als Konfigurationsoption aus. Wählen Sie den neu erstellten freigegebenen Datenträger aus.

Ändern des SAP-Profils der ASCS/SCS-Instanz

Wenn Sie ERS1 ausführen, fügen Sie den SAP-Profilparameter enque/encni/set_so_keepalive hinzu. Dieser Profilparameter verhindert das Schließen von Verbindungen zwischen SAP-Workprozessen und dem Enqueue-Server, wenn diese sich zu lange im Leerlauf befinden. Der SAP-Parameter ist für ERS2 nicht erforderlich.

  1. Wenn Sie ERS1 verwenden, fügen Sie diesen Profilparameter dem Profil der SAP ASCS/SCS-Instanz hinzu.

    enque/encni/set_so_keepalive = TRUE

    Stellen Sie sowohl für ERS1 als auch für ERS2 sicher, dass die keepalive-Parameter für das Betriebssystem wie im SAP-Hinweis 1410736 beschrieben festgelegt sind.

  2. Starten Sie die SAP ASCS/SCS-Instanz neu, um die Änderungen am SAP-Profilparameter zu übernehmen.

Konfigurieren eines Testports für die Clusterressource

Nutzen Sie die Testfunktionalität des internen Lastenausgleichs, damit die gesamte Clusterkonfiguration mit Azure Load Balancer funktioniert. Der interne Azure Load Balancer verteilt in der Regel die eingehende Workload gleichmäßig auf die beteiligten virtuellen Computer.

Allerdings funktioniert dieser Ansatz bei einigen Clusterkonfigurationen nicht, da nur eine Instanz aktiv ist. Die andere Instanz ist passiv und kann daher keine Workload annehmen. Eine Testfunktion hilft, wenn der interne Azure Load Balancer erkennt, welche Instanz aktiv ist, und nur die aktive Instanz zum Ziel hat.

Wichtig

In dieser Beispielkonfiguration ist der Testport auf „620Nr“ festgelegt. Für die SAP ASCS mit der Instanznummer 02 lautet der Port „62002“.

Sie müssen die Konfiguration entsprechend Ihren SAP-Instanznummern und Ihrer SAP-SID anpassen.

Zum Hinzufügen eines Testports führen Sie das folgende PowerShell-Modul auf einer der Cluster-VMs aus:

  • Wenn Sie SAP ASC/SCS mit Instanznummer 02 verwenden:

    Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID PR2 -ProbePort 62002

  • Wenn Sie ERS2 mit Instanznummer 12 verwenden, konfigurieren Sie einen Testport. Es ist nicht erforderlich, einen Probeport für ERS1 zu konfigurieren. ERS2 mit Instanznummer 12 ist gruppiert, während ERS1 nicht gruppiert ist.

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

Der Code für die Funktion Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource sieht wie im folgenden Beispiel aus:

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

Fortfahren mit der SAP-Installation

  1. Installieren Sie die Datenbankinstanz, indem Sie das im SAP-Installationshandbuch beschriebene Verfahren ausführen.

  2. Installieren Sie SAP auf dem zweiten Clusterknoten, indem Sie die im SAP-Installationshandbuch beschriebenen Schritte ausführen.

  3. Installieren Sie die SAP PAS-Instanz (primärer Anwendungsserver) auf dem virtuellen Computer, den Sie als Host für den PAS vorgesehen haben.

    Führen Sie das im SAP-Installationshandbuch beschriebene Verfahren aus. Es gibt keine Abhängigkeiten in Azure.

  4. Installieren Sie zusätzliche SAP-Anwendungsserver auf den virtuellen Computern, die als Hosts von SAP-Anwendungsserverinstanzen festgelegt wurden.

    Führen Sie das im SAP-Installationshandbuch beschriebene Verfahren aus. Es gibt keine Abhängigkeiten in Azure.

Testen des SAP ASCS/SCS-Instanzfailovers

Bei den beschriebenen Failovertests wird angenommen, dass SAP ASCS auf Knoten A aktiv ist.

  1. Vergewissern Sie sich, dass für das SAP-System ein erfolgreiches Failover von Knoten A auf Knoten B durchgeführt werden kann. In diesem Beispiel wird der Test für SAP-SID PR2 ausgeführt.

    Stellen Sie sicher, dass jede SAP-SID erfolgreich auf den anderen Clusterknoten verschoben werden kann. Wählen Sie eine dieser Optionen, um ein Failover der SAP-Clustergruppe <SID> von Clusterknoten A auf Clusterknoten B auszulösen:

    • Failovercluster-Manager
    • PowerShell-Befehle für Failovercluster
    $SAPSID = "PR2"     # SAP <SID>

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

  2. Starten Sie Clusterknoten A unter dem Windows-Gastbetriebssystem neu. Durch diesen Schritt wird ein automatisches Failover der SAP-Clustergruppe <SID> von Knoten A auf Knoten B ausgelöst.

  3. Starten Sie Clusterknoten A im Azure-Portal neu. Durch diesen Schritt wird ein automatisches Failover der SAP-Clustergruppe <SID> von Knoten A auf Knoten B ausgelöst.

  4. Starten Sie Clusterknoten A mit Azure PowerShell neu. Durch diesen Schritt wird ein automatisches Failover der SAP-Clustergruppe <SID> von Knoten A auf Knoten B ausgelöst.

Nächste Schritte