Hohe Verfügbarkeit von SAP ASCS/SCS-Instanzen mit Windows Server-Failoverclustering und gemeinsam genutztem Azure-Datenträger

  • Artikel

Windows OS Windows

Dieser Artikel konzentriert sich auf die Umstellung von einer einzelnen SAP ASCS/SCS-Installation auf die Konfiguration mehrerer SAP-System-IDs (SIDs), indem zusätzliche SAP ASCS/SCS-Clusterinstanzen in einem vorhandenen Windows Server Failover Clustering (WSFC)-Cluster mit einem gemeinsam genutzten Azure-Datenträger installiert werden. Wenn Sie diesen Vorgang abschließen, haben Sie einen SAP Multi-SID-Cluster konfiguriert.

Voraussetzungen und Einschränkungen

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

  • Azure Ultra Disk Storage-Datenträger und Azure Standard-SSD-Datenträger werden nicht als freigegebene Azure-Datenträger für SAP-Workloads unterstützt.
  • Azure shared disks with Premium SSD disks are supported for SAP deployment in availability sets and availability zones.
  • Azure shared disks with Premium SSD disks come with two storage options:
    • Lokal redundanter Speicher (LRS) für freigegebene Premium-SSD-Datenträger (skuName Wert von Premium_LRS) wird mit der Bereitstellung in Verfügbarkeitsgruppen unterstützt.
    • Zonenredundanter Speicher (ZRS) für freigegebene Premium-SSD-Datenträger (skuName Wert von Premium_ZRS) wird mit der Bereitstellung in Verfügbarkeitszonen unterstützt.
  • Der freigegebene Azure-Datenträgerwert maxShares 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 auf maxShares2.
  • Eine Azure-Näherungsgruppe (Proximity Placement Group, PPG) ist für azure shared disks nicht erforderlich. Beachten Sie jedoch für die SAP-Bereitstellung mit PPGs die folgenden Richtlinien:
    • Wenn Sie PPGs für ein in einer Region bereitgestelltes SAP-System verwenden, müssen alle virtuellen Computer, die einen Datenträger gemeinsam nutzen, Teil desselben PPG sein.
    • Wenn Sie PPGs für ein SAP-System verwenden, das über Zonen hinweg bereitgestellt wird, wie in Näherungsgruppen mit zonenübergreifenden Bereitstellungen beschrieben, können Sie Speicherplatz an virtuelle Computer anfügen Premium_ZRS , die einen Datenträger freigeben.

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

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

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

  • LRS für freigegebene SSD-Festplatten für Premium:

    • Die SAP-Bereitstellung mit LRS for Premium SSD shared disks arbeitet mit einem einzigen gemeinsam genutzten Azure-Datenträger auf einem Speichercluster. Wenn ein Problem mit dem Speichercluster auftritt, bei dem der freigegebene Azure-Datenträger bereitgestellt wird, wirkt sich dies auf Ihre SAP ASCS/SCS-Instanz aus.

  • ZRS für freigegebene SSD-Festplatten für Premium:

    • Die Schreiblatenz für ZRS ist höher als die von LRS, da datenübergreifendes Kopieren von Daten überschritten wird.
    • Der Abstand zwischen Verfügbarkeitszonen in verschiedenen Regionen variiert, sodass die ZRS-Datenträgerlatenz über Verfügbarkeitszonen hinweg erfolgt. Messen Sie Ihre Datenträger , um die Latenz von ZRS-Datenträgern in Ihrer Region zu identifizieren.
    • ZRS for Premium SSD shared disks synchron repliziert Daten über drei Verfügbarkeitszonen in der Region. Wenn in einem der Speichercluster ein Problem auftritt, wird Ihre SAP ASCS/SCS-Instanz weiterhin ausgeführt, da das Speicherfailover für die Anwendungsschicht transparent ist.
    • Weitere Informationen hierzu können Sie im Abschnitt "Einschränkungen " der Dokumentation zu ZRS für verwaltete Datenträger lesen.

Wichtig

Das Setup muss die folgenden Bedingungen erfüllen:

  • Die SID für jedes Datenbankverwaltungssystem (DBMS) muss über einen eigenen dedizierten WSFC-Cluster verfügen.
  • SAP-Anwendungsserver, die zu einer SAP-SID gehören, müssen über eigene dedizierte virtuelle Computer (VMs) verfügen.
  • Eine Mischung aus Enqueue Replication Server 1 (ERS1) und Enqueue Replication Server 2 (ERS2) im selben Cluster wird nicht unterstützt.

Unterstützte Betriebssystemversionen

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

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

  • WSFC in Windows Server 2019 ist Azure bekannt.
  • Windows Server 2019 Datacenter umfasst Integration und Bewusstsein für Azure-Host Standard Tenance und verbesserte Erfahrung durch Überwachung für geplante Azure-Ereignisse.
  • Sie können verteilte Netzwerknamen verwenden. (Dies ist die Standardoption.) Für den Clusternetzwerknamen ist keine dedizierte IP-Adresse erforderlich. Außerdem müssen Sie keine IP-Adresse für einen internen Azure-Lastenausgleich konfigurieren.

Aufbau

Sowohl ERS1 als auch ERS2 werden in einer Multi-SID-Konfiguration unterstützt. Eine Mischung aus ERS1 und ERS2 wird im selben Cluster nicht unterstützt.

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

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

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

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

    SAP SID2 verfügt über eine eigene virtuelle IP-Adresse (SID2 (A)SCS IP2), die im internen Azure-Lastenausgleich konfiguriert ist.

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

Das nächste Beispiel zeigt auch zwei SAP-SIDs. Beide verfügen über eine ERS2-Architektur, wobei:

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

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

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

  • SAP SID2 wird auf einem Shard-Datenträger mit ERS2 bereitgestellt, das 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-Lastenausgleich konfiguriert ist.

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

  • Es gibt insgesamt vier virtuelle IP-Adressen:

    • 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.

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 sollten die Hostnamen und die IP-Adressen des Szenarios wie die folgenden Beispiele aussehen.

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

Hostnamenrolle Hostname Statische IP-Adresse Verfügbarkeitsgruppe Datenträgerwert SkuName
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ägerwert SkuName
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 sind für beide Bereitstellungstypen neu Standard identisch. Wenn Ihr Cluster jedoch in einem Verfügbarkeitssatz ausgeführt wird, müssen Sie LRS für freigegebene Azure Premium-SSD-Datenträger (Premium_LRS) bereitstellen. Wenn Ihr Cluster in einer Verfügbarkeitszone ausgeführt wird, müssen Sie ZRS für freigegebene Azure Premium-SSD-Datenträger (Premium_ZRS) bereitstellen.

Erstellen eines internen Azure-Lastenausgleichsmoduls

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 System 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 im Erstellen des Lastenausgleichs beschrieben.

  1. Öffnen Sie den gleichen standardmäßigen internen Lastenausgleich, den Sie für SAP SID, PR1-System erstellt haben.
  2. Front-End-IP-Konfiguration: Erstellen sie frontend IP (Beispiel: 10.0.0.45).
  3. Back-End-Pool: Back-End-Pool ist identisch mit dem des SAP SID PR1-Systems.
  4. Eingehende Regeln: Erstellen einer Lastenausgleichsregel.
    • Front-End-IP-Adresse: Frontend-IP auswählen
    • Back-End-Pool: Back-End-Pool auswählen
    • Überprüfen von "Ports für hohe Verfügbarkeit"
    • Protokoll: TCP
    • Integritätsuntersuchung: Erstellen einer Integritätssonde mit den folgenden Details
      • Protokoll: TCP
      • Port: [beispiel: 620<Instance-No.> for SAP SID, PR2 ASCS]
      • Intervall: 5
      • Probeschwellenwert: 2
    • Leerlauftimeout (Minuten): 30
    • Aktivieren von unverankerten IP-Adressen
  5. Gilt nur für die ENSA2-Architektur: Erstellen Sie zusätzliche Front-End-IP (10.0.0.44), 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 die Anzahl der erfolgreichen oder fehlgeschlagenen aufeinanderfolgenden Probes zu steuern, legen Sie die Eigenschaft "probeThreshold" auf 2 fest. Es ist derzeit nicht möglich, diese Eigenschaft mit Azure-Portal festzulegen. Verwenden Sie daher entweder den Azure CLI- oder PowerShell-Befehl.

Wichtig

Eine unverankerte IP-Adresse wird in Szenarien zum Lastenausgleich nicht für eine Netzwerkschnittstelle Karte (NIC) sekundäre IP-Konfiguration unterstützt. Einzelheiten finden Sie unter Azure Load Balancer Einschränkungen. Wenn Sie zusätzliche IP-Adressen für die VM benötigen, stellen Sie eine zweite NIC bereit.

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 ist die Datenträgernummer 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. Stellen Sie sicher, 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 mit der IP-Adresse übereinstimmen, die Sie in Azure Load Balancer zugewiesen haben.

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

  2. Wenn Sie eine clusterierte 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 mit der IP-Adresse übereinstimmen, die Sie in Azure Load Balancer zugewiesen haben.

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

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

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

SAP-Installation

Installieren des ersten SAP-Clusterknotens

Befolgen Sie das von SAP beschriebene Installationsverfahren. Stellen Sie sicher, dass Sie "First Cluster Node" als Option zum Starten der Installation auswählen. Wählen Sie den freigegebenen 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_keepalivehinzu. Der Profilparameter verhindert, dass Verbindungen zwischen SAP-Arbeitsprozessen und dem Enqueue-Server geschlossen werden, wenn sie zu lang im Leerlauf sind. Der SAP-Parameter ist für ERS2 nicht erforderlich.

  1. Fügen Sie diesen Profilparameter zum SAP ASCS/SCS-Instanzprofil hinzu, wenn Sie ERS1 verwenden:

    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. Um die Änderungen auf den SAP-Profilparameter anzuwenden, starten Sie die SAP ASCS/SCS-Instanz neu.

Konfigurieren eines Probeports 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.

Dieser Ansatz funktioniert jedoch in einigen Clusterkonfigurationen nicht, da nur eine Instanz aktiv ist. Die andere Instanz ist passiv und kann daher keine Workload annehmen. Eine Probefunktion hilft, wenn der interne Azure-Lastenausgleich erkennt, welche Instanz aktiv ist und nur auf die aktive Instanz ausgerichtet ist.

Wichtig

In dieser Beispielkonfiguration wird der Probeport auf 620nr festgelegt. Für SAP ASCS mit Instanznummer 02 ist es 62002.

Sie müssen die Konfiguration so anpassen, dass sie Ihren SAP-Instanzennummern und Ihrer SAP-SID entspricht.

Um einen Probeport hinzuzufügen, führen Sie dieses PowerShell-Modul auf einem 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 Probeport. 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 den im SAP-Installationshandbuch beschriebenen Prozess 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 Primary Application Server (PAS)-Instanz auf dem virtuellen Computer, der für die Hostung des PAS festgelegt ist.

    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 für die Hostung von SAP-Anwendungsserverinstanzen vorgesehen sind.

    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 davon ausgegangen, dass SAP ASCS auf Knoten A aktiv ist.

  1. Stellen Sie sicher, dass das SAP-System erfolgreich von Knoten A zu Knoten B fehlschlagen kann. In diesem Beispiel gilt der Test für SAP SID PR2.

    Stellen Sie sicher, dass jede SAP-SID erfolgreich zum anderen Clusterknoten wechseln 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. In diesem Schritt wird ein automatisches Failover der SAP <SID-Clustergruppe> von Knoten A zu Knoten B initiiert.

  3. Starten Sie Clusterknoten A im Azure-Portal neu. In diesem Schritt wird ein automatisches Failover der SAP <SID-Clustergruppe> von Knoten A zu Knoten B initiiert.

  4. Starten Sie Clusterknoten A mit Azure PowerShell neu. In diesem Schritt wird ein automatisches Failover der SAP <SID-Clustergruppe> von Knoten A zu Knoten B initiiert.

Nächste Schritte