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:
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 von SAP mit einer ASCS/SCS-Hochverfügbarkeitsinstanz
Wichtig
Wenn Sie SIOS zum Darstellen der freigegebenen Datenträger verwenden, platzieren Sie die Auslagerungsdatei nicht in den gespiegelten SIOS DataKeeper-Volumes. Belassen Sie die Auslagerungsdatei auf dem temporären Laufwerk D eines virtuellen Azure-Computers (dies ist auch die Standardeinstellung). Wenn sie sich noch nicht dort befindet, verschieben Sie die Windows-Auslagerungsdatei auf Laufwerk D des virtuellen Azure-Computers.
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
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
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
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
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.
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.
Tipp
Die SAP-Installationsdokumentation beschreibt, wie der erste ASCS/SCS-Clusterknoten installiert wird.
Ä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.
Wenn Sie ERS1 verwenden, fügen Sie diesen Profilparameter dem Profil der SAP ASCS/SCS-Instanz hinzu.
enque/encni/set_so_keepalive = trueStellen 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.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.
Wichtig
In dieser Beispielkonfiguration ist ProbePort auf „620Nr“ festgelegt. Für die SAP ASCS-Instanz mit der Nummer 00 lautet der Port „62000“. 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:
Für eine SAP ASC/SCS-Instanz:
Set-AzureLoadBalancerHealthCheckProbePortOnSAPClusterIPResource -SAPSID SID -ProbePort 62000Bei 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.
Ü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 $SAPClusterGroupStarten 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.
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.
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.
Überprüfung
Überprüfen Sie nach dem Failover, ob die SAP <SID-Clustergruppe> auf 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.