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 SAP-Hochverfügbarkeitssystem in Azure für das Clustering einer SAP ASCS/SCS-Instanz unter Verwendung eines Windows Server-Failoverclusters und eines freigegebenen Datenträgers für den Cluster installieren und konfigurieren. Wie im Architekturleitfaden: Gruppieren einer SAP ASCS/SCS-Instanz in einem Windows-Failovercluster mithilfe freigegebener Clusterdatenträger in Azure beschrieben, gibt es zwei Alternativen für freigegebene 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:

• Architekturleitfaden: Gruppieren einer SAP ASCS/SCS-Instanz in einem Windows-Failovercluster mithilfe freigegebener Clusterdatenträger in Azure

• Vorbereiten der Azure-Infrastruktur für SAP HA mit einem Windows-Failovercluster und einem freigegebenen Datenträger für eine SAP ASCS/SCS-Instanz

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.

Installieren von SAP mit einer ASCS/SCS-Hochverfügbarkeitsinstanz

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
• Hinzufügen eines Testports
• Öffnen des Windows-Firewall-Testports

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

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

   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.

   

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

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

   Bei der IP-Adresse, die Sie dem virtuellen Hostnamen der ERS2-Instanz zuweisen, muss es sich um die zweite IP-Adresse handeln, die Sie der Azure Load Balancer-Instanz zugewiesen haben.

   

   Definieren des DNS-Eintrags für den Namen und die TCP/IP-Adresse des virtuellen SAP ERS2-Clusters

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

   

   Neuer virtueller Name und neue TCP/IP-Adresse für die SAP ASCS/SCS-Clusterkonfiguration

Installieren des ersten SAP-Clusterknotens

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

   Denken Sie daran, dass die Konfiguration in den Lastenausgleichsregeln für die interne Azure Load Balancer-Instanz (bei Verwendung der SKU „Basic“) und die ausgewählten SAP-Instanznummern übereinstimmen müssen.

2. Führen Sie das von SAP beschriebene Installationsverfahren aus. Stellen Sie sicher, dass Sie bei der Option zum Starten der Installation für „Erster Clusterknoten“ die Konfigurationsoption „Freigegebener Clusterdatenträger“ auswählen.

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

Wenn Sie Enqueue Replication Server 1 ausführen, fügen Sie den SAP-Profilparameter enque/encni/set_so_keepalive wie nachfolgend beschrieben 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 der SAP-Profilparameter zu übernehmen.

Hinzufügen eines Testports

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

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

• Für eine SAP ASC/SCS-Instanz:

  Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID SID -ProbePort 62000
  

• Bei Verwendung von ERS2 (gehört zu einem Cluster); 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 clsutered 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 manualy 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-Testports

Öffnen Sie einen Windows-Firewall-Testport auf beiden Clusterknoten. Verwenden Sie das folgende Skript, um einen Windows-Firewall-Testport zu öffnen. Aktualisieren Sie die PowerShell-Variablen für Ihre Umgebung.
Bei Verwendung von ERS2 müssen Sie auch den Firewallport für den ERS2-Testport ö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

Führen Sie für die Installation der Datenbankinstanz die in der SAP-Installationsdokumentation beschriebene Vorgehensweise durch.

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 PAS-Instanz (primärer Anwendungsserver) <SID>-di-0 auf dem virtuellen Computer, den Sie als Host für den PAS vorgesehen haben. 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 zusätzlichen SAP-Anwendungsserver (Additional Application Server, AAS) auf allen virtuellen Computern, die Sie als Hosts von SAP-Anwendungsserverinstanzen festgelegt haben.

Testen des SAP ASCS-/SCS-Instanzfailovers

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

1. Überprüfen Sie, ob das SAP-System ein Failover von Knoten A zu Knoten B ausführen kann. Initiieren Sie mithilfe einer der folgenden Optionen ein Failover der Clustergruppe „SAP <SID>“ vom Clusterknoten A zum Clusterknoten B:

   • Failovercluster-Manager
   • Failovercluster-PowerShell

   $SAPSID = "PR1"     # SAP <SID>
   
   $SAPClusterGroup = "SAP $SAPSID"
   Move-ClusterGroup -Name $SAPClusterGroup
   
   

2. Starten Sie Clusterknoten A unter dem Windows-Gastbetriebssystem neu. Dadurch 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. Dadurch 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. Dadurch wird ein automatisches Failover der SAP-Clustergruppe <SID> von Knoten A auf Knoten B ausgelöst.

5. Überprüfung

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

   • Überprüfen Sie nach dem Failover mithilfe von SIOS, ob SIOS DataKeeper Daten vom Quellvolumelaufwerk S auf dem Clusterknoten B im Zielvolumelaufwerk S auf dem Clusterknoten A repliziert.

     

     SIOS DataKeeper repliziert das lokale Volume vom Clusterknoten B auf den Clusterknoten A.