SAP NetWeaver-HA-Installation auf einem Windows-Failovercluster und freigegebenen Datenträger für eine SAP ASCS/SCS-Instanz in Azure

In diesem Artikel wird beschrieben, wie Sie ein HOCHverfügbarkeits-SAP-System in Azure mithilfe eines Windows Server-Failoverclusters und eines freigegebenen Clusterdatenträgers für das Clustering einer SAP ASCS/SCS-Instanz installieren und konfigurieren. Wie im Architekturleitfaden: Clustern einer SAP ASCS/SCS-Instanz in einem Windows-Failovercluster mithilfe eines gemeinschaftlich genutzten Clusterdatenträgers beschrieben, gibt es zwei Alternativen für gemeinschaftlich genutzte Clusterdatenträger:

Freigegebene Azure-Datenträger
Verwenden von SIOS DataKeeper Cluster Edition zum Erstellen eines gespiegelten Speichers, der die freigegebenen Clusterdatenträger simuliert

Voraussetzungen

Lesen Sie die folgenden Dokumente, bevor Sie mit der Installation beginnen:

Das DBMS-Setup wird in diesem Artikel nicht beschrieben, da die Einrichtung vom verwendeten DBMS abhängt. Es wird davon ausgegangen, dass auf Hochverfügbarkeit bezogene Aspekte des DBMS mit den Funktionen verwaltet werden, die verschiedene DBMS-Hersteller für Azure unterstützen. Beispiele hierfür sind Always On oder Datenbankspiegelung für SQL Server und Oracle Data Guard für Oracle-Datenbanken. Die Hochverfügbarkeitsszenarien für DBMS werden in diesem Artikel nicht beschrieben.

Es sind keine Besonderheiten zu berücksichtigen, wenn unterschiedliche DBMS-Dienste mit einer SAP ASCS/SCS-Clusterkonfiguration in Azure interagieren.

Hinweis

Der Installationsvorgang von SAP NetWeaver ABAP-, Java- und ABAP+Java-Systemen ist nahezu identisch. Der wichtigste Unterschied ist, dass ein SAP ABAP-System eine ASCS-Instanz hat. Das SAP Java-System hat eine SCS-Instanz. Das SAP ABAP+Java-System hat eine ASCS- und eine SCS-Instanz, die in der gleichen Microsoft-Failoverclustergruppe ausgeführt werden. Unterschiede bei der Installation der einzelnen SAP NetWeaver-Installationsstapel werden explizit angegeben. Sie können davon ausgehen, dass die verbleibenden Schritte die gleichen sind.

Installieren Sie SAP mit einer Hochverfügbarkeitsinstanz für ASCS/SCS.

Wichtig

Wenn Sie SIOS zum Darstellen der freigegebenen Datenträger verwenden, platzieren Sie die Auslagerungsdatei nicht in den gespiegelten SIOS DataKeeper-Volumes. Sie können Ihre Seitendatei auf dem temporären Laufwerk D: einer Azure-VM belassen, die der Standardwert ist. Wenn sie noch nicht vorhanden ist, verschieben Sie die Windows-Seitendatei auf Laufwerk D: Ihrer Azure-VM.

Das Installieren von SAP mit einer ASCS/SCS-Instanz mit hoher Verfügbarkeit umfasst die folgenden Aufgaben:

Erstellen eines virtuellen Hostnamens für die SAP ASCS/SCS-Clusterinstanz
Installieren von SAP auf dem ersten Clusterknoten
Ändern des SAP-Profils der ASCS/SCS-Instanz
Fügen Sie einen Prüfport hinzu.
Öffnen Sie den Windows Firewall-Prüfpunktport.

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

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

Festlegen des DNS-Eintrags für den virtuellen Namen des SAP ASCS/SCS Clusters und der TCP/IP-Adresse

Wichtig

Bei der IP-Adresse, die Sie dem virtuellen Hostnamen der ASCS/SCS-Instanz zuweisen, muss es sich um die IP-Adresse handeln, die Sie der Azure Load Balancer-Instanz zugewiesen haben.
Wenn Sie den neuen SAP Enqueue Replication Server 2 verwenden, bei dem es sich ebenfalls um eine Clusterinstanz handelt, müssen Sie in DNS auch einen virtuellen Hostnamen für ERS2 reservieren.

Wichtig

Die IP-Adresse, die Sie dem virtuellen Hostnamen der ERS2-Instanz zuweisen, muss die zweite IP-Adresse sein, die Sie Azure Load Balancer zugewiesen haben.

Definieren des DNS-Eintrags für den Namen und die TCP/IP-Adresse des virtuellen SAP ERS2-Clusters
So definieren Sie die IP-Adresse, die dem virtuellen Hostnamen im DNS-Manager zugewiesen ist:
1. Erweitern Sie Ihre Zone.
2. Öffnen Sie den Eintrag, den Sie zum Definieren der IP-Adresse benötigen.
Neuer virtueller Name und neue TCP/IP-Adresse für die SAP ASCS/SCS-Clusterkonfiguration

Installieren des ersten SAP-Clusterknotens

Führen Sie die Option für den ersten Clusterknoten auf dem Clusterknoten A aus. Wählen Sie Folgendes aus:
- ABAP-System: ASCS-Instanznummer 00
- Java-System: SCS-Instanznummer 01
- ABAP + Java-System: ASCS-Instanznummer 00 und SCS-Instanznummer 01
Wichtig

Die Konfiguration in den Regeln des internen Azure-Lastenausgleichsdienstes (bei Verwendung eines Basic SKU) und der ausgewählten SAP-Instanznummer muss übereinstimmen.
Führen Sie das von SAP beschriebene Installationsverfahren aus. Stellen Sie sicher, dass in der Startinstallationsoption unter "Erster Clusterknoten" die Option "Freigegebener Clusterdatenträger" als Konfigurationsoption ausgewählt ist.

Tipp

Die SAP-Installationsdokumentation beschreibt, wie der erste ASCS/SCS-Clusterknoten installiert wird.

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

Wenn Sie über Enqueue Replication Server 1 verfügen, fügen Sie den SAP-Profilparameter enque/encni/set_so_keepalivehinzu. 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.

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 für ERS1 und ERS2 sicher, dass die keepalive Betriebssystemparameter wie in SAP Note 1410736 beschrieben festgelegt werden.
Starten Sie die SAP ASCS/SCS-Instanz neu, um die Änderungen der SAP-Profilparameter zu übernehmen.

Füge einen Prüfport hinzu

Damit die gesamte Clusterkonfiguration mit Azure Load Balancer funktioniert, verwenden Sie die Probefunktion des internen Lastenausgleichs. Der interne Azure-Lastenausgleich verteilt in der Regel die eingehende Workload gleichmäßig zwischen teilnehmenden virtuellen Computern (VMs).

Die Workloadverteilung funktioniert jedoch in einigen Clusterkonfigurationen nicht, da nur eine Instanz aktiv ist. Die andere Instanz ist passiv und kann daher keine Arbeitslast 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 ist ProbePort auf „620Nr“ festgelegt. Für die SAP ASCS-Instanz mit der Nummer 00,** beträgt sie 62000. Sie müssen die Konfiguration entsprechend Ihren SAP-Instanznummern und Ihrer SAP-SID anpassen.

Um einen Probeport hinzuzufügen, führen Sie dieses PowerShell-Modul auf einem der Cluster-VMs aus:

Für die SAP ASC/SCS-Instanz

Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID SID -ProbePort 62000

Falls ERS2 verwendet wird, das in einem Cluster läuft. Für ERS1 muss kein Testport konfiguriert werden, da dieser Server nicht zu einem Cluster gehört.

Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID SID -ProbePort 62001 -IsSAPERSClusteredInstance $True

Der Code für die Funktion Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource sieht wie folgt aus:

function Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource {

<#
.SYNOPSIS
Set-AzureLoadBalancerHealthProbePortOnSAPClusterIPResource will set a new Azure Load Balancer Health Probe Port on 'SAP $SAPSID IP' cluster resource.

.DESCRIPTION
Set-AzureLoadBalancerHealthProbePortOnSAPClusterIPResource will set a new Azure Load Balancer Health Probe Port on 'SAP $SAPSID IP' cluster resource.
It will also restart SAP Cluster group (default behavior), to activate the changes.

You need to run it on one of the SAP ASCS/SCS Windows cluster nodes.

Expectation is that SAP group is installed with official SWPM installation tool, which will set default expected naming convention for:

- SAP Cluster Group:               'SAP $SAPSID'
- SAP Cluster IP Address Resource: 'SAP $SAPSID IP'

.PARAMETER SAPSID
SAP SID - 3 characters staring with letter.

.PARAMETER ProbePort
Azure Load Balancer Health Check Probe Port.

.PARAMETER RestartSAPClusterGroup
Optional parameter. Default value is '$True', so SAP cluster group will be restarted to activate the changes.

.PARAMETER IsSAPERSClusteredInstance
Optional parameter.Default value is '$False'.
If set to $True , then handle clustered new SAP ERS2 instance.

.EXAMPLE
# Set 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 probe port to 62000, on SAP cluster resource 'SAP AB1 IP'. SAP cluster group 'SAP AB1' IS NOT restarted, therefore changes are NOT active.
# To activate the changes you need to manually restart 'SAP AB1' cluster group.
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID AB1 -ProbePort 62000 -RestartSAPClusterGroup $False

.EXAMPLE
# Set 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-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 " "

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

Öffnen des Windows Firewall-Prüfpunktports

Öffnen Sie einen Windows Firewall-Prüfpunktport auf beiden Clusterknoten. Verwenden Sie das folgende Skript, um einen Windows Firewall-Probeport zu öffnen. Aktualisieren Sie die PowerShell-Variablen für Ihre Umgebung. Bei Verwendung von ERS2 müssen Sie den Firewallport für den ERS2-Prüfpunktport öffnen.

$ProbePort = 62000   # ProbePort of the Azure internal load balancer
New-NetFirewallRule -Name AzureProbePort -DisplayName "Rule for Azure Probe Port" -Direction Inbound -Action Allow -Protocol TCP -LocalPort $ProbePort

Installieren der Datenbankinstanz

Um die Datenbankinstanz zu installieren, befolgen Sie den in der SAP-Installationsdokumentation beschriebenen Prozess.

Installieren des zweiten Clusterknotens

Führen Sie zum Installieren des zweiten Clusters die im SAP-Installationshandbuch beschriebenen Schritte aus.

Installieren des primären SAP-Anwendungsservers

Installieren Sie die Instanz <SID>-di-0 (Primary Application Server, PAS) auf der VM, die Sie zum Hosten des PAS festlegen. Es gibt keine Abhängigkeiten in Azure. Bei Verwendung von SIOS gibt es keine DataKeeper-spezifischen Einstellungen.

Installieren des zusätzlichen SAP-Anwendungsservers

Installieren Sie einen SAP Additional Application Server (AAS) auf allen virtuellen Computern, die zum Hosten einer SAP Application Server-Instanz festgelegt sind.

Testen des SAP ASCS-/SCS-Instanzfailovers

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

Stellen Sie sicher, dass das SAP-System erfolgreich von Knoten A zu Knoten B umschalten 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-Cmdlets für Failover-Cluster
```
$SAPSID = "PR1"     # SAP <SID>
$SAPClusterGroup = "SAP $SAPSID"
Move-ClusterGroup -Name $SAPClusterGroup
```
Starten Sie Clusterknoten A unter dem Windows-Gastbetriebssystem neu. Dadurch wird ein automatisches Failover der SAP <SID-Clustergruppe> von Knoten A zu Knoten B initiiert.
Starten Sie Clusterknoten A im Azure-Portal neu. Dadurch wird ein automatisches Failover der SAP <SID-Clustergruppe> von Knoten A zu Knoten B initiiert.
Starten Sie Clusterknoten A mit Azure PowerShell neu. Dadurch wird ein automatisches Failover der SAP <SID-Clustergruppe> von Knoten A zu Knoten B initiiert.
Überprüfen Sie nach dem Failover, ob die Clustergruppe „SAP <SID>“ auf dem Clusterknoten B ausgeführt wird.

Failovercluster-Manager: Die SAP <SID>-Clustergruppe wird auf Clusterknoten B ausgeführt.
- Überprüfen Sie nach dem Failover, ob der freigegebene Datenträger jetzt auf dem Clusterknoten B eingebunden ist.
- Stellen Sie nach dem Failover sicher, dass, wenn SIOS verwendet wird, SIOS DataKeeper Daten vom Quellvolumelaufwerk S: auf dem Clusterknoten B zum Zielvolumelaufwerk S: auf dem Clusterknoten A repliziert.
SIOS DataKeeper repliziert das lokale Volume vom Clusterknoten B auf den Clusterknoten A.

Feedback

War diese Seite hilfreich?

Last updated on 2026-03-12