Hochverfügbarkeit für horizontal skalierte SAP HANA-Systeme mit HSR unter SUSE Linux Enterprise Server

Artikel
01/16/2024

In diesem Artikel wird beschrieben, wie Sie ein hochverfügbares SAP HANA-System in einer Konfiguration mit horizontaler Skalierung mit HANA-Systemreplikation (HANA System Replication, HSR) und Pacemaker auf virtuellen Azure SUSE Linux Enterprise Server-Computern (Virtual Machines, VMs) bereitstellen. Die freigegebenen Dateisysteme in der vorgestellten Architektur sind über NFS eingebunden und werden von Azure NetApp Files oder über eine NFS-Freigabe in Azure Files bereitgestellt.

In den Beispielkonfigurationen, Installationsbefehlen usw. werden die HANA-Instanz 03 und HANA-System-ID HN1 verwendet.

Bevor Sie beginnen, lesen Sie die folgenden SAP-Hinweise und Dokumente:

Azure NetApp Files-Dokumentation
Dokumentation zu Azure Files
SAP-Hinweis 1928533 enthält:
- Liste der für die Bereitstellung von SAP-Software unterstützten Azure-VM-Größen
- Wichtige Kapazitätsinformationen für Größen von Azure-VMs
- Unterstützte SAP-Software und Kombinationen aus Betriebssystem (OS) und Datenbank
- Die erforderliche SAP-Kernelversion für Windows und Linux in Microsoft Azure
SAP-Hinweis 2015553: Enthält eine Liste der Voraussetzungen für Bereitstellungen von SAP-Software in Azure, die von SAP unterstützt werden
SAP-Hinweis 2205917: Enthält empfohlene Betriebssystemeinstellungen für SUSE Linux Enterprise Server für SAP-Anwendungen
SAP-Hinweis 1944799: Enthält SAP-Richtlinien für SUSE Linux Enterprise Server für SAP-Anwendungen
SAP-Hinweis 2178632: Enthält ausführliche Informationen zu allen Überwachungsmetriken, die für SAP in Azure gemeldet werden
SAP-Hinweis 2191498: Enthält die erforderliche SAP Host Agent-Version für Linux in Azure
SAP-Hinweis 2243692: Enthält Informationen zur SAP-Lizenzierung unter Linux in Azure
SAP-Hinweis 1984787: Enthält allgemeine Informationen zu SUSE Linux Enterprise Server 12
SAP-Hinweis 1999351: Enthält Informationen zur Problembehandlung für die Azure-Erweiterung zur verbesserten Überwachung für SAP
SAP-Hinweis 1900823: Enthält Informationen zu SAP HANA-Speicheranforderungen
Wiki der SAP Community: Enthält alle erforderlichen SAP-Hinweise für Linux.
Azure Virtual Machines – Planung und Implementierung für SAP unter Linux
Bereitstellung von Azure Virtual Machines für SAP unter Linux
Azure Virtual Machines – DBMS-Bereitstellung für SAP unter Linux
Best Practices für SUSE SAP HA: Enthält alle erforderlichen Informationen zum lokalen Einrichten von NetWeaver-Hochverfügbarkeit und SAP Hana System Replication (als allgemeine Basis zu verwenden, sie bieten jedoch weitaus ausführlichere Informationen)
Versionshinweise zur SUSE Linux Enterprise-Hochverfügbarkeitserweiterung 12 SP5
Behandeln fehlerhafter NFS-Freigaben im SUSE-Hochverfügbarkeitscluster für die HANA-Systemreplikation
NFS v4.1-Volumes unter Azure NetApp Files für SAP HANA

Übersicht

Eine Methode zum Erreichen von HANA-Hochverfügbarkeit für Installationen horizontaler HANA-Skalierungen besteht darin, die HANA-Systemreplikation zu konfigurieren und die Lösung mit einem Pacemaker-Cluster zu schützen, um ein automatisches Failover zu ermöglichen. Wenn ein aktiver Knoten ausfällt, führt der Clusterknoten einen Failover zu den HANA-Ressourcen am anderen Standort aus.
Die vorgestellte Konfiguration zeigt drei HANA-Knoten an jedem Standort sowie einen Majority Maker-Knoten, um ein Split-Brain-Szenario zu verhindern. Die Anweisungen können angepasst werden, um mehr virtuelle Computer als HANA DB-Knoten einzubeziehen.

Das freigegebene HANA-Dateisystem /hana/shared in der vorgestellten Architektur kann von Azure NetApp Files oder einer NFS-Freigabe in Azure Files bereitgestellt werden. Das freigegebene HANA-Dateisystem wird als NFS auf jedem HANA-Knoten an demselben HANA-Systemreplikationsstandort bereitgestellt. Die Dateisysteme /hana/data und /hana/log sind lokale Dateisysteme und werden nicht gemeinsam von den HANA-DB-Knoten verwendet. SAP HANA wird im nicht freigegebenen Modus installiert.

Informationen zu empfohlenen SAP HANA-Speicherkonfigurationen finden Sie unter Speicherkonfigurationen für SAP HANA Azure VMs.

Wichtig

Wenn Sie alle HANA-Dateisysteme in Azure NetApp Files bereitstellen, wird empfohlen, für Produktionssysteme, bei denen die Leistung wichtig ist, die Verwendung einer Azure NetApp Files-Anwendungsvolumegruppe für SAP HANA in Betracht zu ziehen.

Warnung

Das Bereitstellen von /hana/data und /hana/log in NFS in Azure Files wird nicht unterstützt.

Im vorangehenden Diagramm werden drei Subnetze in einem virtuellen Azure-Netzwerk dargestellt, das den Empfehlungen für SAP HANA-Netzwerke entspricht:

Für die Clientkommunikation – client 10.23.0.0/24
Für die interne Kommunikation zwischen SAP HANA-Knoten – inter 10.23.1.128/26
Für die HANA-Systemreplikation – hsr 10.23.1.192/26

Da /hana/data und /hana/log auf lokalen Datenträgern bereitgestellt werden, müssen kein separates Subnetz und keine separaten virtuellen Netzwerkkarten für die Kommunikation mit dem Speicher verwendet werden.

Wenn Sie Azure NetApp Files verwenden, werden die NFS-Volumes für /hana/shared in einem separaten Subnetz bereitgestellt und an Azure NetApp Files delegiert: anf 10.23.1.0/26.

Vorbereiten der Infrastruktur

In den folgenden Anweisungen wird davon ausgegangen, dass Sie bereits die Ressourcengruppe und das Azure Virtual Network mit drei Azure Virtual Network-Subnetzen erstellt haben: client, inter und hsr.

Bereitstellen von virtuellen Linux-Computern über das Azure-Portal

Stellen Sie die virtuellen Azure-Computer bereit.

Stellen Sie für die in diesem Dokument vorgestellte Konfiguration sieben virtuelle Computer bereit:
- Drei virtuelle Computer, die als HANA DB-Knoten für HANA-Replikationsstandort 1 dienen: hana-s1-db1, hana-s1-db2 und hana-s1-db3
- Drei virtuelle Computer, die als HANA DB-Knoten für HANA-Replikationsstandort 2 dienen: hana-s2-db1, hana-s2-db2 and hana-s2-db3
- Ein kleiner virtueller Computer, der als Majority Maker dient: hana-s-mm
Die virtuellen Computer, die als SAP DB HANA-Knoten bereitgestellt werden, sollten von SAP für HANA zertifiziert sein, wie im SAP HANA-Hardwareverzeichnis veröffentlicht. Stellen Sie bei der Bereitstellung der HANA DB-Knoten sicher, dass Beschleunigtes Netzwerk aktiviert ist.

Für den Majority Maker-Knoten können Sie einen kleinen virtuellen Computer bereitstellen, da auf diesem keine der SAP HANA-Ressourcen ausgeführt wird. Der virtuelle Majority Maker-Computer wird in der Clusterkonfiguration verwendet, um eine ungerade Anzahl von Clusterknoten in einem Split-Brain-Szenario zu erreichen. Der virtuelle Majority Maker-Computer benötigt in diesem Beispiel nur eine virtuelle Netzwerkschnittstelle im Subnetz client.

Stellen Sie lokal verwaltete Datenträger für /hana/data und /hana/log bereit. Die empfohlene Mindestspeicherkonfiguration für /hana/data und /hana/log ist in der Speicherkonfigurationen für SAP HANA Azure VMs beschrieben.

Stellen Sie die primäre Netzwerkschnittstelle für die einzelnen virtuellen Computer im client-Subnetz des virtuellen Netzwerks bereit.
Wenn der virtuelle Computer über das Azure-Portal bereitgestellt wird, erfolgt die automatische Generierung des Namens der Netzwerkschnittstelle. In diesen Anweisungen werden die automatisch generierten primären Netzwerkschnittstellen, die mit dem client-Subnetz des virtuellen Azure-Netzwerks verbunden sind, der Einfachheit halber als hana-s1-db1-client, hana-s1-db2-client, hana-s1-db3-client usw. bezeichnet.
Wichtig
- Stellen Sie sicher, dass das von Ihnen ausgewählte Betriebssystem SAP-zertifiziert ist für SAP HANA auf den spezifischen VM-Typen, die Sie verwenden. Eine Liste der SAP HANA-zertifizierten VM-Typen und BS-Releases für diese finden Sie auf der Website Zertifizierte SAP HANA-IaaS-Plattformen. Klicken Sie in die Details des jeweils aufgeführten VM-Typs, um die vollständige Liste der von SAP HANA unterstützten BS-Releases für diesen Typ anzuzeigen.
- Wenn Sie sich für das Bereitstellen von /hana/shared in NFS in Azure Files entscheiden, wird die Bereitstellung in SLES 15 SP2 und höher empfohlen.
Erstellen Sie sechs Netzwerkschnittstellen, eine für jeden virtuellen HANA DB-Computer im inter-Subnetz des virtuellen Netzwerks (in diesem Beispiel hana-s1-db1-inter, hana-s1-db2-inter, hana-s1-db3-inter, hana-s2-db1-inter, hana-s2-db2-inter und hana-s2-db3-inter).
Erstellen Sie sechs Netzwerkschnittstellen, eine für jeden virtuellen HANA DB-Computer im hsr-Subnetz des virtuellen Netzwerks (in diesem Beispiel hana-s1-db1-hsr, hana-s1-db2-hsr, hana-s1-db3-hsr, hana-s2-db1-hsr, hana-s2-db2-hsr und hana-s2-db3-hsr).
Fügen Sie die neu erstellten virtuellen Netzwerkschnittstellen an die entsprechenden virtuellen Computer an:
1. Navigieren Sie im Azure-Portal zum virtuellen Computer.
2. Wählen Sie im linken Bereich Virtuelle Computer aus. Filtern Sie nach dem Namen des virtuellen Computers (z. B. hana-s1-db1), und wählen Sie dann den virtuellen Computer aus.
3. Klicken Sie im Bereich Übersicht auf Beenden, um die Zuordnung des virtuellen Computers aufzuheben.
4. Wählen Sie Netzwerk aus, und fügen Sie dann die Netzwerkschnittstelle an. Wählen Sie in der Dropdownliste Netzwerkschnittstelle anfügen die bereits erstellten Netzwerkschnittstellen für die Subnetze inter und hsr aus.
5. Wählen Sie Speichern aus.
6. Wiederholen Sie die Schritte b bis e für die übrigen VMs (in diesem Beispiel hana-s1-db2, hana-s1-db3, hana-s2-db1, hana-s2-db2 und hana-s2-db3).
7. Belassen Sie die virtuelle Computer für den Moment im Status „Beendet“. Als Nächstes aktivieren wir den beschleunigten Netzwerkbetrieb für alle neu angefügten Netzwerkschnittstellen.

Aktivieren Sie den beschleunigten Netzwerkbetrieb für die zusätzlichen Netzwerkschnittstellen für die Subnetze inter und hsr mit den folgenden Schritten:

Öffnen Sie Azure Cloud Shell im Azure-Portal.

Führen Sie die folgenden Befehle aus, um den beschleunigten Netzwerkbetrieb für die zusätzlichen Netzwerkschnittstellen zu aktivieren, die wir an die Subnetze inter und hsr angefügt haben.

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-inter --accelerated-networking true

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-hsr --accelerated-networking true

Starten der virtuellen HANA DB-Computer

Konfigurieren von Azure Load Balancer

Während der VM-Konfiguration können Sie im Abschnitt „Netzwerk“ einen Lastenausgleich erstellen oder einen vorhandenen Lastenausgleich auswählen. Führen Sie die folgenden Schritte aus, um den Standardlastenausgleich für das Hochverfügbarkeitssetup der HANA-Datenbank einzurichten.

Hinweis

Wählen Sie für die HANA-Aufskalierung die NIC für das Subnetz client aus, wenn Sie die VMs im Back-End-Pool hinzufügen.
Der vollständige Befehlssatz in der Azure-Befehlszeilenschnittstelle und in PowerShell fügt die VMs mit der primären NIC im Back-End-Pool hinzu.

Führen Sie die unter Erstellen eines Lastenausgleichs beschriebenen Schritte aus, um über das Azure-Portal einen Standardlastenausgleich für ein SAP-Hochverfügbarkeitssystem einzurichten. Berücksichtigen Sie beim Einrichten des Lastenausgleichs die folgenden Punkte:

Front-End-IP-Konfiguration: Erstellen Sie eine IP-Adresse für das Front-End. Wählen Sie dasselbe virtuelle Netzwerk und Subnetz aus wie für Ihre Datenbank-VMs.
Back-End-Pool: Erstellen Sie einen Back-End-Pool, und fügen Sie Datenbank-VMs hinzu.
Regeln für eingehenden Datenverkehr: Erstellen Sie eine Lastenausgleichsregel. Führen Sie die gleichen Schritte für beide Lastenausgleichsregeln aus.
- Front-End-IP-Adresse: Wählen Sie eine Front-End-IP-Adresse aus.
- Back-End-Pool: Wählen Sie einen Back-End-Pool aus.
- Hochverfügbarkeitsports: Wählen Sie diese Option aus.
- Protokoll: Wählen Sie TCP.
- Integritätstest: Erstellen Sie einen Integritätstest mit folgenden Details:
  - Protokoll: Wählen Sie TCP.
  - Port: Beispielsweise 625<Instanznr.>
  - Intervall: Geben Sie 5 ein.
  - Testschwellenwert: Geben Sie 2 ein.
- Leerlauftimeout (Minuten): Geben Sie 30 ein.
- Unverankerte IP aktivieren: Wählen Sie diese Option aus.

Hinweis

Die Konfigurationseigenschaft numberOfProbes für Integritätstests, im Portal als Fehlerschwellenwert bezeichnet, wird nicht berücksichtigt. Legen Sie die probeThreshold-Eigenschaft auf 2 fest, um die Anzahl erfolgreicher oder nicht erfolgreicher aufeinanderfolgender Integritätstests zu steuern. Diese Eigenschaft kann derzeit nicht über das Azure-Portal festgelegt werden. Verwenden Sie daher entweder die Azure-Befehlszeilenschnittstelle oder den PowerShell-Befehl.

Der gesamte Azure CLI-Code zeigt das Setup des Lastenausgleichs an, der zwei VMs im Back-End-Pool enthält. Je nach Anzahl der VMs in Ihrer HANA-Skalierung können Sie weitere VMs im Back-End-Pool hinzufügen.

# Create the load balancer resource with frontend IP. Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address.
az network lb create -g MyResourceGroup -n MyLB --sku Standard --vnet-name MyVMsVirtualNetwork --subnet MyVMsSubnet --backend-pool-name MyBackendPool --frontend-ip-name MyDBFrontendIpName

# Create the health probe
az network lb probe create -g MyResourceGroup --lb-name MyLB -n MyDBHealthProbe --protocol tcp --port MyDBHealthProbePort --interval 5 --probe-threshold 2
 
# Create load balancing rule
az network lb rule create -g MyResourceGroup --lb-name MyLB -n MyDBRuleName --protocol All --frontend-ip-name MyDBFrontendIpName --frontend-port 0 --backend-pool-name MyBackendPool --backend-port 0 --probe-name MyDBHealthProbe --idle-timeout-in-minutes 30 --enable-floating-ip 

# Add database VMs in backend pool
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm1IpConfigName --nic-name DBVm1NicName -g MyResourceGroup --lb-name MyLB
az network nic ip-config address-pool add --address-pool MyBackendPool --ip-config-name DBVm2IpConfigName --nic-name DBVm2NicName -g MyResourceGroup --lb-name MyLB

Erweitern, um den vollständigen CLI-Code anzuzeigen

# Define variables for Resource Group, and Database VMs.

rg_name="resourcegroup-name"
vm1_name="db1-name"
vm2_name="db2-name"

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

lb_name="sap-db-sid-ilb"
bkp_name="db-backendpool"
db_fip_name="db-frontendip"

db_hp_name="db-healthprobe"
db_hp_port="625<instance-no>"

db_rule_name="db-lb-rule"
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name. 
 
vm1_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm1_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm1_nic_name=$(basename $vm1_primary_nic)
vm1_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm1_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vm2_primary_nic=$(az vm nic list -g $rg_name --vm-name $vm2_name --query "[?primary == \`true\`].{id:id} || [?primary == \`null\`].{id:id}" -o tsv)
vm2_nic_name=$(basename $vm2_primary_nic)
vm2_ipconfig=$(az network nic ip-config list -g $rg_name --nic-name $vm2_nic_name --query "[?primary == \`true\`].name" -o tsv)
 
vnet_subnet_id=$(az network nic show -g $rg_name -n $vm1_nic_name --query ipConfigurations[0].subnet.id -o tsv)
vnet_name=$(basename $(dirname $(dirname $vnet_subnet_id)))
subnet_name=$(basename $vnet_subnet_id)
 
# Create the load balancer resource with frontend IP.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter --private-ip-address. 
  
az network lb create -g $rg_name -n $lb_name --sku Standard --vnet-name $vnet_name --subnet $subnet_name --backend-pool-name $bkp_name --frontend-ip-name $db_fip_name
 
# Create the health probe
 
az network lb probe create -g $rg_name --lb-name $lb_name -n $db_hp_name --protocol tcp --port $db_hp_port --interval 5 --probe-threshold 2
 
# Create load balancing rule
  
az network lb rule create -g $rg_name --lb-name $lb_name -n  $db_rule_name --protocol All --frontend-ip-name $db_fip_name --frontend-port 0 --backend-pool-name $bkp_name --backend-port 0 --probe-name $db_hp_name --idle-timeout-in-minutes 30 --enable-floating-ip 
 
# Add database VMs in backend pool
 
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm1_ipconfig --nic-name $vm1_nic_name -g $rg_name --lb-name $lb_name
az network nic ip-config address-pool add --address-pool $bkp_name --ip-config-name $vm2_ipconfig --nic-name $vm2_nic_name -g $rg_name --lb-name $lb_name

# [OPTIONAL] Change the assignment of frontend IP address from dynamic to static
dbfip=$(az network lb frontend-ip show --lb-name $lb_name -g $rg_name -n $db_fip_name --query "{privateIPAddress:privateIPAddress}" -o tsv)
az network lb frontend-ip update --lb-name $lb_name -g $rg_name -n $db_fip_name --private-ip-address $dbfip

Der gesamte PowerShell-Code zeigt das Setup des Lastenausgleichs an, der zwei VMs im Back-End-Pool enthält. Je nach Anzahl der VMs in Ihrer HANA-Skalierung können Sie weitere VMs im Back-End-Pool hinzufügen.

# Create frontend IP configurations
$db_fip = New-AzLoadBalancerFrontendIpConfig -Name MyDBFrontendIpName -SubnetId MyDBSubnetName

# Create backend pool
$bePool = New-AzLoadBalancerBackendAddressPoolConfig -Name MyBackendPool

# Create health probe
$db_healthprobe = New-AzLoadBalancerProbeConfig -Name MyDBHealthProbe -Protocol 'tcp' -Port MyDBHealthProbePort -IntervalInSeconds 5 -ProbeThreshold 2 -ProbeCount 1

# Create load balancing rule
$db_rule = New-AzLoadBalancerRuleConfig -Name MyDBRuleName -Probe $db_healthprobe -Protocol 'All' -IdleTimeoutInMinutes 30 -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -EnableFloatingIP

# Create the load balancer resource
$lb = New-AzLoadBalancer -ResourceGroupName MyResourceGroup -Name MyLB -Location MyRegion -Sku 'Standard' -FrontendIpConfiguration $db_fip -BackendAddressPool $bePool -LoadBalancingRule $db_rule -Probe $db_healthprobe

Erweitern, um den vollständigen PowerShell-Code anzuzeigen

# Define variables for Resource Group, and Database VMs.

$rg_name = 'resourcegroup-name'
$vm1_name = 'db1-name'
$vm2_name = 'db2-name'

# Define variables for the load balancer that will be utilized in the creation of the load balancer resource.

$lb_name = 'sap-db-sid-ilb'
$bkp_name = 'db-backendpool'
$db_fip_name = 'db-frontendip'
 
$db_hp_name = 'db-healthprobe'
$db_hp_port = '625<instance-no>'
 
$db_rule_name = 'db-lb-rule'
 
# Command to get VMs network information like primary NIC name, primary IP configuration name, virtual network name, and subnet name.
 
$vm1 = Get-AzVM -ResourceGroupName $rg_name -Name $vm1_name
$vm1_primarynic = $vm1.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm1_nic_name = $vm1_primarynic.Id.Split('/')[-1]
 
$vm1_nic_info = Get-AzNetworkInterface -Name $vm1_nic_name -ResourceGroupName $rg_name
$vm1_primaryip = $vm1_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm1_ipconfig_name = ($vm1_primaryip).Name
 
$vm2 = Get-AzVM -ResourceGroupName $rg_name -Name $vm2_name
$vm2_primarynic = $vm2.NetworkProfile.NetworkInterfaces | Where-Object {($_.Primary -eq "True") -or ($_.Primary -eq $null)}
$vm2_nic_name = $vm2_primarynic.Id.Split('/')[-1]
 
$vm2_nic_info = Get-AzNetworkInterface -Name $vm2_nic_name -ResourceGroupName $rg_name
$vm2_primaryip = $vm2_nic_info.IpConfigurations | Where-Object -Property Primary -EQ -Value "True"
$vm2_ipconfig_name = ($vm2_primaryip).Name
 
$vnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-3]
$subnet_name = $vm1_primaryip.Subnet.Id.Split('/')[-1]
$location = $vm1.Location
 
# Create frontend IP resource.
# Allocation of private IP address is dynamic using below command. If you want to pass static IP address, include parameter -PrivateIpAddress
 
$db_lb_fip = @{
    Name = $db_fip_name
    SubnetId = $vm1_primaryip.Subnet.Id
}
$db_fip = New-AzLoadBalancerFrontendIpConfig @db_lb_fip

# Create backend pool
 
$bepool = New-AzLoadBalancerBackendAddressPoolConfig -Name $bkp_name

# Create the health probe
 
$db_probe = @{
    Name = $db_hp_name
    Protocol = 'tcp'
    Port = $db_hp_port
    IntervalInSeconds = '5'
    ProbeThreshold = '2'
    ProbeCount = '1'
}
$db_healthprobe = New-AzLoadBalancerProbeConfig @db_probe
    
# Create load balancing rule
 
$db_lbrule = @{
    Name = $db_rule_name
    Probe = $db_healthprobe
    Protocol = 'All'
    IdleTimeoutInMinutes = '30'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool 
} 
$db_rule = New-AzLoadBalancerRuleConfig @db_lbrule -EnableFloatingIP 
 
# Create the load balancer resource
 
$loadbalancer = @{
    ResourceGroupName = $rg_name
    Name = $lb_name
    Location = $location
    Sku = 'Standard'
    FrontendIpConfiguration = $db_fip
    BackendAddressPool = $bePool
    LoadBalancingRule = $db_rule
    Probe = $db_healthprobe
} 
$lb = New-AzLoadBalancer @loadbalancer

# Add DB VMs in backend pool
 
$vm1_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm2_primaryip.LoadBalancerBackendAddressPools.Add($lb.BackendAddressPools[0])
$vm1_nic_info | Set-AzNetworkInterface
$vm2_nic_info | Set-AzNetworkInterface

Wichtig

Floating IP-Adressen werden in IP-Konfigurationen mit zwei NICs in Szenarien mit Lastenausgleich nicht unterstützt. Weitere Informationen 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 virtuelle Computer ohne öffentliche IP-Adressen im Back-End-Pool einer internen Azure Load Balancer Standard-Instanz (ohne öffentliche IP-Adresse) platziert werden, liegt keine ausgehende Internetverbindung vor, sofern nicht in einer zusätzlichen Konfiguration das Routing an öffentliche Endpunkte zugelassen wird. Ausführliche Informationen zum Erreichen ausgehender Konnektivität finden Sie unter Public endpoint connectivity for Virtual Machines using Azure Standard Load Balancer in SAP high-availability scenarios (Konnektivität mit öffentlichen Endpunkten für virtuelle Computer mithilfe von Azure Load Balancer Standard in SAP-Szenarien mit Hochverfügbarkeit).

Wichtig

Aktivieren Sie keine TCP-Zeitstempel auf Azure-VMs hinter Azure Load Balancer. Das Aktivieren von TCP-Zeitstempeln bewirkt, dass bei Integritätstests Fehler auftreten. Legen Sie den Parameter net.ipv4.tcp_timestamps auf 0 fest. Details finden Sie unter Load Balancer Health Probes sowie im SAP-Hinweis 2382421.
Um zu verhindern, dass saptune den manuell festgelegten net.ipv4.tcp_timestamps-Wert von 0 wieder in 1 ändert, muss saptune mindestens auf die Version 3.1.1 aktualisiert werden. Weitere Informationen finden Sie unter saptune 3.1.1: Muss ich ein Update durchführen?.

Bereitstellen von NFS

Es gibt zwei Optionen für die Bereitstellung von für Azure natives NFS für /hana/shared. Sie können das NFS-Volume in Azure NetApp Files oder in einer NFS-Freigabe in Azure Files bereitstellen. Azure Files unterstützt das NFSv4.1-Protokoll. NFS in Azure NetApp Files unterstützt sowohl NFSv4.1 als auch NFSv3.

In den nächsten Abschnitten werden die Schritte zum Bereitstellen von NFS beschrieben – Sie müssen nur eine der Optionen auswählen.

Tipp

Sie haben sich entschieden, /hana/shared in einer NFS-Freigabe in Azure Files oder das NFS-Volume in Azure NetApp Files bereitzustellen.

Bereitstellen der Infrastruktur für Azure NetApp Files

Stellen Sie ANF-Volumes für das /hana/shared-Dateisystem bereit. Sie benötigen ein separates /hana/shared-Volume für jeden Replikationsstandort des HANA-Systems. Weitere Informationen finden Sie unter Einrichten der Infrastruktur für Azure NetApp Files.

In diesem Beispiel wurden die folgenden Azure NetApp Files-Volumes verwendet:

Volume „HN1-shared-s1 (nfs://10.23.1.7/HN1-shared-s1)“
Volume „HN1-shared-s2 (nfs://10.23.1.7/HN1-shared-s2)“

Bereitstellen von NFS in der Azure Files-Infrastruktur

Stellen Sie Azure Files NFS-Freigaben für das /hana/shared-Dateisystem bereit. Sie benötigen eine separate Azure Files-NFS-Freigabe /hana/shared für jeden Replikationsstandort des HANA-Systems. Weitere Informationen finden Sie unter Erstellen einer NFS-Freigabe.

In diesem Beispiel wurden die folgenden Azure Files-NFS-Freigaben verwendet:

share hn1-shared-s1 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1)
share hn1-shared-s2 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2)

Konfiguration und Vorbereitung des Betriebssystems

Die Anweisungen in den nächsten Abschnitten weisen eine der folgenden Abkürzungen auf:

[A]: Gilt für alle Knoten (einschließlich Majority Maker)
[AH]: gilt für alle HANA DB-Knoten
[M]: Gilt nur für den Majority Maker-Knoten
[AH1]: gilt für alle HANA DB-Knoten an STANDORT 1
[AH2]: gilt für alle HANA DB-Knoten an STANDORT 2
[1]: gilt nur für HANA DB-Knoten 1, STANDORT 1
[2]: gilt nur für HANA DB-Knoten 1, STANDORT 2

Führen Sie die folgenden Schritte aus, um das Betriebssystem zu konfigurieren und vorzubereiten:

[A] Verwalten Sie die Hostdateien auf den virtuellen Computern. Schließen Sie Einträge für alle Subnetze ein. Die folgenden Einträge wurden für dieses Beispiel zu /etc/hosts hinzugefügt.

# Client subnet
10.23.0.19      hana-s1-db1
10.23.0.20      hana-s1-db2
10.23.0.21      hana-s1-db3
10.23.0.22      hana-s2-db1
10.23.0.23      hana-s2-db2
10.23.0.24      hana-s2-db3
10.23.0.25      hana-s-mm    

# Internode subnet
10.23.1.132     hana-s1-db1-inter
10.23.1.133     hana-s1-db2-inter
10.23.1.134     hana-s1-db3-inter
10.23.1.135     hana-s2-db1-inter
10.23.1.136     hana-s2-db2-inter
10.23.1.137     hana-s2-db3-inter

# HSR subnet
10.23.1.196     hana-s1-db1-hsr
10.23.1.197     hana-s1-db2-hsr
10.23.1.198     hana-s1-db3-hsr
10.23.1.199     hana-s2-db1-hsr
10.23.1.200     hana-s2-db2-hsr
10.23.1.201     hana-s2-db3-hsr

[A] Erstellen Sie die Konfigurationsdatei /etc/sysctl.d/ms-az.conf mit Microsoft für Azure-Konfigurationseinstellungen.
```
vi /etc/sysctl.d/ms-az.conf

# Add the following entries in the configuration file
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.tcp_max_syn_backlog = 16348
net.ipv4.conf.all.rp_filter = 0
sunrpc.tcp_slot_table_entries = 128
vm.swappiness=10
```
Tipp

Legen Sie „net.IPv4.ip_local_port_range“ und „net.IPv4.ip_local_reserved_ports“ nicht explizit in den sysctl-Konfigurationsdateien fest, damit der SAP-Host-Agent die Portbereiche verwalten kann. Weitere Informationen finden Sie im SAP-Hinweis 2382421.
[A] SUSE stellt spezielle Ressourcen-Agents für SAP HANA bereit, und Agents für vertikale SAP HANA-Skalierung sind standardmäßig installiert. Deinstallieren Sie die Pakete für vertikale Skalierung, wenn diese installiert sind, und installieren Sie die Pakete für das SAP HANA-Szenario für horizontales Hochskalieren. Der Schritt muss auf allen Cluster-VMs ausgeführt werden, einschließlich des Majority Maker.

Hinweis

SAPHanaSR-ScaleOut Version 0.181 oder höher muss installiert sein.
```
# Uninstall scale-up packages and patterns
sudo zypper remove patterns-sap-hana
sudo zypper remove SAPHanaSR SAPHanaSR-doc yast2-sap-ha

# Install the scale-out packages and patterns
sudo zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc 
sudo zypper in -t pattern ha_sles
```
[AH] Vorbereiten der VMs: Wenden Sie die empfohlenen Einstellungen gemäß SAP-Hinweis 2205917 für SUSE Linux Enterprise Server für SAP-Anwendungen an.

Vorbereiten der Dateisysteme

Sie haben sich entschieden, die freigegebenen SAP-Verzeichnisse auf einer NFS-Freigabe auf Azure Files oder in einem NFS-Volume auf Azure NetApp Files bereitzustellen.

Einbinden der freigegebenen Dateisysteme (Azure NetApp Files NFS)

In diesem Beispiel werden die freigegebenen HANA-Dateisysteme in Azure NetApp Files bereitgestellt und über NFSv4.1 eingebunden. Führen Sie die Schritte in diesem Abschnitt nur aus, wenn Sie NFS in Azure NetApp Files verwenden.

[A] Vorbereiten des Betriebssystems für die Ausführung von SAP HANA in NetApp Systems mit NFS, wie in SAP-Hinweis 3024346 – Linux-Kerneleinstellungen für NetApp NFS beschrieben. Erstellen Sie die Konfigurationsdatei /etc/sysctl.d/91-NetApp-HANA.conf für die NetApp-Konfigurationseinstellungen.

vi /etc/sysctl.d/91-NetApp-HANA.conf

# Add the following entries in the configuration file
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1

[A] Passen Sie die sunrpc-Einstellungen an, wie im SAP-Hinweis 3024346 – Linux-Kerneleinstellungen für NetApp NFS empfohlen.
```
vi /etc/modprobe.d/sunrpc.conf

# Insert the following line
options sunrpc tcp_max_slot_table_entries=128
```
[AH] Erstellen Sie Bereitstellungspunkte für die HANA-Datenbankvolumes.
```
mkdir -p /hana/shared
```
[AH] Überprüfen Sie die Einstellung für die NFS-Domäne. Stellen Sie sicher, dass die Domäne als Azure NetApp Files-Standarddomäne (also defaultv4iddomain.com) konfiguriert und die Zuordnung auf nobody festgelegt ist.
Dieser Schritt ist nur erforderlich, wenn Sie Azure NetAppFiles NFSv4.1 verwenden.

Wichtig

Stellen Sie sicher, dass die NFS-Domäne in /etc/idmapd.conf auf der VM so festgelegt ist, dass sie mit der Standarddomänenkonfiguration für Azure NetApp Files übereinstimmt: defaultv4iddomain.com . Wenn es einen Konflikt zwischen der Domänenkonfiguration auf dem NFS-Client (also der VM) und dem NFS-Server (also der Azure NetApp-Konfiguration) gibt, werden die Berechtigungen für Dateien auf Azure NetApp Files-Volumes, die auf den VMs eingebunden sind, als nobody angezeigt.
```
sudo cat /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
```
[AH] Überprüfen Sie nfs4_disable_idmapping. Diese Angabe sollte auf Y (Ja) festgelegt sein. Führen Sie den Einbindungsbefehl aus, um bei nfs4_disable_idmapping die Verzeichnisstruktur zu erstellen. Sie können das Verzeichnis unter „/sys/modules“ nicht manuell erstellen, da der Zugriff für den Kernel bzw. die Treiber reserviert ist.
Dieser Schritt ist nur erforderlich, wenn Sie Azure NetAppFiles NFSv4.1 verwenden.
```
# Check nfs4_disable_idmapping 
cat /sys/module/nfs/parameters/nfs4_disable_idmapping
# If you need to set nfs4_disable_idmapping to Y
mkdir /mnt/tmp
mount 10.23.1.7:/HN1-share-s1 /mnt/tmp
umount  /mnt/tmp
echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
# Make the configuration permanent
echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
```

[AH1] Binden Sie die freigegebenen Azure NetApp Files-Volumes auf den virtuellen HANA DB-Computern von STANDORT 1 ein.

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s1 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] Binden Sie die freigegebenen Azure NetApp Files-Volumes auf den virtuellen HANA DB-Computern von STANDORT 2 ein.

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s2 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount the volume
sudo mount -a

[AH] Überprüfen Sie, ob die entsprechenden /hana/shared/-Dateisysteme auf allen virtuellen HANA DB-Computern mit NFS-Protokollversion NFSv4.1 eingebunden sind.

sudo nfsstat -m
# Verify that flag vers is set to 4.1 
# Example from SITE 1, hana-s1-db1
/hana/shared from 10.23.1.7:/HN1-shared-s1
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.1.7
# Example from SITE 2, hana-s2-db1
/hana/shared from 10.23.1.7:/HN1-shared-s2
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.1.7

Einbinden der freigegebenen Dateisysteme (Azure Files NFS)

In diesem Beispiel werden die freigegebenen HANA-Dateisysteme in NFS in Azure Files bereitgestellt. Führen Sie die Schritte in diesem Abschnitt nur aus, wenn Sie NFS in Azure Files verwenden.

[AH] Erstellen Sie Bereitstellungspunkte für die HANA-Datenbankvolumes.
```
mkdir -p /hana/shared
```

[AH1] Binden Sie die freigegebenen Azure NetApp Files-Volumes auf den virtuellen HANA DB-Computern von STANDORT 1 ein.

sudo vi /etc/fstab
# Add the following entry
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] Binden Sie die freigegebenen Azure NetApp Files-Volumes auf den virtuellen HANA DB-Computern von STANDORT 2 ein.

sudo vi /etc/fstab
# Add the following entries
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount the volume
sudo mount -a

[AH] Überprüfen Sie, ob die entsprechenden /hana/shared/-Dateisysteme auf allen virtuellen HANA DB-Computern mit NFS-Protokollversion NFSv4.1 eingebunden sind.

sudo nfsstat -m
# Example from SITE 1, hana-s1-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.0.35
# Example from SITE 2, hana-s2-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.0.35

Vorbereiten der Daten und Protokollieren lokaler Dateisysteme

In der dargestellten Konfiguration werden die Dateisysteme /hana/data und /hana/log auf einem verwalteten Datenträger bereitgestellt und lokal an die einzelnen virtuellen HANA DB-Computer angefügt. Sie müssen die Schritte zum Erstellen der lokalen Daten- und Protokollvolumes auf jedem virtuellen HANA DB-Computer ausführen.

Richten Sie das Layout des Datenträgers mit Logical Volume Manager (LVM) ein. Im folgenden Beispiel wird davon ausgegangen, dass jeder virtuelle HANA-Computer über drei Datenträger verfügen, die zum Erstellen von zwei Volumes verwendet werden.

[AH] Auflisten aller verfügbaren Datenträger:

ls /dev/disk/azure/scsi1/lun*

Beispielausgabe:

/dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2

[AH] Erstellen Sie physische Volumes für alle Datenträger, die Sie verwenden möchten:

sudo pvcreate /dev/disk/azure/scsi1/lun0
sudo pvcreate /dev/disk/azure/scsi1/lun1
sudo pvcreate /dev/disk/azure/scsi1/lun2

[AH] Erstellen Sie eine Volumegruppe für die Datendateien. Erstellen Sie eine Volumegruppe für Protokolldateien und eine für das freigegebene Verzeichnis von SAP HANA:\
```
sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
```
[AH] Erstellen Sie die logischen Volumes.

Ein lineares Volume wird erstellt, wenn Sie lvcreate ohne den Schalter -i verwenden. Es wird empfohlen, ein Stripesetvolume für eine bessere E/A-Leistung zu erstellen und die Stripegrößen an die in SAP HANA VM-Speicherkonfigurationen dokumentierten Werte anzupassen. Das -i-Argument sollte die Anzahl der zugrunde liegenden physischen Volumes und das -I-Argument die Stripegröße sein. In diesem Dokument werden zwei physische Volumes für das Datenvolume verwendet, daher wird das Argument für den Schalter -i auf 2 festgelegt. Die Stripegröße für das Datenvolume beträgt 256 KiB. Für das Protokollvolume wird ein physisches Volume verwendet, sodass keine -i- oder -I-Schalter explizit für die Protokollvolumebefehle verwendet werden.

Wichtig

Verwenden Sie den Schalter -i, und ändern Sie die Zahl in die Anzahl der zugrunde liegenden physischen Volumes, wenn Sie für die einzelnen Daten- oder Protokollvolumes mehrere physische Datenträger verwenden. Verwenden Sie den Schalter -I, um die Stripegröße festzulegen, wenn Sie ein Stripesetvolume erstellen.
Informationen zu empfohlenen Speicherkonfigurationen, einschließlich Stripegrößen und Anzahl der Datenträger, finden Sie unter SAP HANA VM-Speicherkonfigurationen.
```
sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
```

[AH] Erstellen Sie die Bereitstellungsverzeichnisse, und kopieren Sie die UUID aller logischen Volumes:

sudo mkdir -p /hana/data/HN1
sudo mkdir -p /hana/log/HN1
# Write down the ID of /dev/vg_hana_data_HN1/hana_data and /dev/vg_hana_log_HN1/hana_log
sudo blkid

[AH] Erstellen Sie fstab-Einträge für die logischen Volumes, und binden Sie Folgendes an:

sudo vi /etc/fstab

Fügen Sie die folgende Zeile in die Datei /etc/fstab ein:

/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_data_HN1-hana_data /hana/data/HN1 xfs  defaults,nofail  0  2
/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_log_HN1-hana_log /hana/log/HN1 xfs  defaults,nofail  0  2

Stellen Sie die neuen Volumes bereit:

sudo mount -a

Erstellen eines Pacemaker-Clusters

Führen Sie die Schritte in Einrichten von Pacemaker auf SUSE Linux Enterprise Server in Azure zum Erstellen eines grundlegenden Pacemaker-Clusters für diesen HANA-Server aus. Beziehen Sie alle virtuellen Computer ein, einschließlich Majority Maker im Cluster.

Wichtig

Legen Sie quorum expected-votes nicht auf 2 fest, da es sich nicht um einen Cluster mit zwei Knoten handelt.
Stellen Sie sicher, dass die Clustereigenschaft concurrent-fencing aktiviert ist, damit das Knotenfencing deserialisiert wird.

Installation

In diesem Beispiel für die Bereitstellung von SAP HANA in einer Konfiguration mit horizontaler Skalierung mit HSR auf Azure-VMs haben wir HANA 2.0 SP5 verwendet.

Vorbereiten der HANA-Installation

[AH] Legen Sie vor der HANA-Installation das Stammkennwort fest. Nachdem die Installation abgeschlossen wurde, können Sie das Stammkennwort deaktivieren. Führen Sie den Befehl passwd als root aus.
[1,2] Ändern der Berechtigungen für /hana/shared
```
chmod 775 /hana/shared
```
[1] Überprüfen Sie, ob Sie sich über SSH bei den virtuellen HANA DB-Computern an diesem Standort, hana-s1-db2 und hana-s1-db3, anmelden können, ohne nach einem Kennwort gefragt zu werden. Wenn dies nicht der Fall ist, tauschen Sie die SSH-Schlüssel wie unter Aktivieren des SSH-Zugriffs mit einem öffentlichen Schlüssel beschrieben aus.
```
ssh root@hana-s1-db2
ssh root@hana-s1-db3
```
[2] Überprüfen Sie, ob Sie sich über SSH bei den virtuellen HANA DB-Computern an diesem Standort, hana-s2-db2 und hana-s2-db3, anmelden können, ohne nach einem Kennwort gefragt zu werden.
Wenn dies nicht der Fall ist, tauschen Sie die SSH-Schlüssel aus.
```
ssh root@hana-s2-db2
ssh root@hana-s2-db3
```
[AH] Installieren Sie zusätzliche Pakete, die für HANA 2.0 SP4 oder höher erforderlich sind. Weitere Informationen finden Sie im SAP-Hinweis 2593824 für Ihre SLES-Version.
```
# In this example, using SLES12 SP5
sudo zypper install libgcc_s1 libstdc++6 libatomic1
```

HANA-Installation auf dem ersten Knoten an jedem Standort

[1] Installieren Sie SAP HANA gemäß den Anweisungen im SAP HANA 2.0 Installation and Update Guide (Installations- und Updateleitfaden für SAP HANA 2.0). In den folgenden Anweisungen wird die SAP HANA-Installation auf dem ersten Knoten an STANDORT 1 veranschaulicht.

a. Starten Sie das Programm hdblcm als root über das HANA-Installationssoftwareverzeichnis. Verwenden Sie den internal_network-Parameter, und übergeben Sie den Adressraum für das Subnetz, das für die interne Kommunikation zwischen HANA-Knoten verwendet wird.
```
./hdblcm --internal_network=10.23.1.128/26
```
b. Geben Sie an der Eingabeaufforderung folgende Werte ein:
- Für Aktion auswählen: Geben Sie 1 ein (für „installieren“).
- Für Additional components for installation (Zusätzliche Komponenten für die Installation): Geben Sie 2, 3 ein.
- Für den Installationspfad: Drücken Sie die EINGABETASTE (Standardwert „/hana/shared“).
- Für Local Host Name (Name des lokalen Hosts): Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Do you want to add hosts to the system? (Möchten Sie dem System Hosts hinzufügen?): Geben Sie n ein.
- Für SAP HANA System ID (SAP HANA-System-ID): Geben Sie HN1 ein.
- Für Instance number (Instanznummer) [00]: Geben Sie 03 ein.
- Für Local Host Worker Group (Workergruppe des lokalen Hosts): Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Select System Usage / Enter index [4] (Systemnutzung auswählen/Index eingeben): Geben Sie 4 (für benutzerdefiniert) ein.
- Für Location of Data Volumes (Speicherort der Datenvolumes) [/Hana/Data/HN1]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Location of Log Volumes (Speicherort der Protokollvolumes) [/Hana/log/HN1]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Möchten Sie die maximale Speicherbelegung beschränken? [n]: Geben Sie n ein.
- Für Certificate Host Name For Host hana-s1-db1 [hana-s1-db1]: (Zertifikathostname für Host „hana-s1-db1“): Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für SAP Host Agent User (sapadm) Password (Kennwort für SAP-Host-Agent-Benutzer): Geben Sie das Kennwort ein.
- Für Confirm SAP Host Agent User (sapadm) Password (Kennwort für SAP-Host-Agent-Benutzer bestätigen): Geben Sie das Kennwort ein.
- Für System Administrator (hn1adm) Password (Kennwort für den Systemadministrator (hn1adm)): Geben Sie das Kennwort ein.
- Für System Administrator Home Directory (Stammverzeichnis des Systemadministrators) [/usr/sap/HN1/home]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für System Administrator Login Shell (Anmelde-Shell für den Systemadministrator) [/bin/sh]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für System Administrator User ID (Benutzer-ID des Systemadministrators) [1001]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Enter ID of User Group (sapsys) (ID der Benutzergruppe (sapsys) eingeben) [79]: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- For System Database User (system) Password (Kennwort für den Systemdatenbankbenutzer (system)): Geben Sie das Kennwort für das System ein.
- For Confirm System Database User (system) Password (Kennwort für den Systemdatenbankbenutzer (system) bestätigen): Geben Sie das Kennwort für das System ein.
- Für Soll das System nach dem Neustart des Computers neu starten? [n]: Geben Sie n ein.
- Für Möchten Sie fortfahren (y/n)? : Überprüfen Sie die Zusammenfassung. Wenn alle Werte korrekt sind, geben Sie y ein.
[2] Wiederholen Sie den vorhergehenden Schritt, um SAP HANA auf dem ersten Knoten an STANDORT 2 zu installieren.
[1,2] Überprüfen Sie die „global.ini“.

Zeigen Sie die „global. ini“ an, und stellen Sie sicher, dass die Konfiguration für die interne SAP HANA-Kommunikation zwischen Knoten eingerichtet ist. Überprüfen Sie den Abschnitt communication. Dieser sollte den Adressraum für das inter-Subnetz enthalten, und listeninterface sollte auf .internal festgelegt sein. Überprüfen Sie den Abschnitt internal_hostname_resolution. Er sollte die IP-Adressen für die virtuellen HANA-Computer enthalten, die zum inter-Subnetz gehören.
```
  sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
  # Example from SITE1 
  [communication]
  internal_network = 10.23.1.128/26
  listeninterface = .internal
  [internal_hostname_resolution]
  10.23.1.132 = hana-s1-db1
  10.23.1.133 = hana-s1-db2
  10.23.1.134 = hana-s1-db3
```
[1,2] Bereiten Sie global.ini für die Installation in einer nicht freigegebenen Umgebung vor, wie in SAP-Hinweis 2080991 beschrieben.
```
 sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
 [persistence]
 basepath_shared = no
```

[1,2] Starten Sie SAP HANA neu, um die Änderungen zu aktivieren.

 sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem
 sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem

[1,2] Stellen Sie sicher, dass die Clientschnittstelle zur Kommunikation die IP-Adressen aus dem client-Subnetz verwendet.
```
# Execute as hn1adm
/usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from SYS.M_HOST_INFORMATION'|grep net_publicname
# Expected result - example from SITE 2
"hana-s2-db1","net_publicname","10.23.0.22"
```
Weitere Informationen zum Überprüfen der Konfiguration finden Sie im SAP-Hinweis 2183363 – Konfiguration des internen SAP HANA-Netzwerks.
[AH] Ändern Sie die Berechtigungen für die Daten- und Protokollverzeichnisse, um einen HANA-Installationsfehler zu vermeiden.
```
 sudo chmod o+w -R /hana/data /hana/log
```
[1] Installieren Sie die sekundären HANA-Knoten. Die Beispielanweisungen in diesem Schritt beziehen sich auf STANDORT 1.

a. Starten Sie das Programm hdblcm als root.
```
 cd /hana/shared/HN1/hdblcm
 ./hdblcm 
```
b. Geben Sie an der Eingabeaufforderung folgende Werte ein:
- Für Aktion auswählen: Geben Sie 2 ein (für „Hosts installieren“).
- Für Enter comma separated host names to add (Durch Komma getrennte hinzuzufügende Hostnamen eingeben): hana-s1-db2, hana-s1-db3
- Für Additional components for installation (Zusätzliche Komponenten für die Installation): Geben Sie 2, 3 ein.
- Für Enter Root User Name [root] (Root-Benutzername [root] eingeben): Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Select roles for host 'hana-s1-db2' [1] (Rollen für Host 'hana-s1-db2' [1] eingeben): 1 (für Worker)
- Für Enter Host Failover Group for host 'hana-s1-db2' [default] (Hostfailovergruppe für Host 'hana-s1-db2' [Standard] eingeben): Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Geben Sie die Nummer der Speicherpartition für den Host „hana-s1-db2“ [<<automatisch zuweisen>>] ein: Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Enter Worker Group for host 'hana-s1-db2' [default] (Workergruppe für Host 'hana-s1-db2' [Standard] eingeben): Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Select roles for host 'hana-s1-db3' [1] (Rollen für Host 'hana-s1-db3' [1] eingeben): 1 (für Worker)
- Für Enter Host Failover Group for host 'hana-s1-db3' [default] (Hostfailovergruppe für Host 'hana-s1-db3' [Standard] eingeben): Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Geben Sie die Nummer der Speicherpartition für den Host „hana-s1-db3“ [<<automatisch zuweisen>>] ein: Drücken Sie die Eingabetaste, um die Standardeinstellung zu übernehmen.
- Für Enter Worker Group for host 'hana-s1-db3' [default] (Workergruppe für Host 'hana-s1-db3' [Standard] eingeben): Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für System Administrator (hn1adm) Password (Kennwort für den Systemadministrator (hn1adm)): Geben Sie das Kennwort ein.
- Für Enter SAP Host Agent User (sapadm) Password (Kennwort für SAP-Host-Agent-Benutzer (sapadm) eingeben): Geben Sie das Kennwort ein.
- Für Confirm SAP Host Agent User (sapadm) Password (Kennwort für SAP-Host-Agent-Benutzer bestätigen): Geben Sie das Kennwort ein.
- Für Certificate Host Name For Host hana-s1-db2 [hana-s1-db2]: (Zertifikathostname für Host „hana-s1-db2“): Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Certificate Host Name For Host hana-s1-db3 [hana-s1-db3]: (Zertifikathostname für Host „hana-s1-db3“): Drücken Sie die EINGABETASTE, um die Standardeinstellung zu übernehmen.
- Für Möchten Sie fortfahren (y/n)? : Überprüfen Sie die Zusammenfassung. Wenn alle Werte korrekt sind, geben Sie y ein.
[2] Wiederholen Sie den vorhergehenden Schritt, um die sekundären SAP HANA-Knoten auf STANDORT 2 zu installieren.

Konfigurieren der SAP HANA 2.0-Systemreplikation

[1] Konfigurieren Sie die Systemreplikation auf STANDORT 1.

Sichern Sie die Datenbanken als hn1adm:

hdbsql -d SYSTEMDB -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
hdbsql -d HN1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"

Kopieren Sie die PKI-Systemdateien auf den sekundären Standort:

scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

Erstellen Sie den primären Standort:

hdbnsutil -sr_enable --name=HANA_S1

[2] Konfigurieren Sie die Systemreplikation auf STANDORT 2.

Registrieren Sie den zweiten Standort zum Starten der Replikation. Führen Sie den folgenden Befehl als <hanasid>adm aus:

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=sync --name=HANA_S2
sapcontrol -nr 03 -function StartSystem

[1] Überprüfen Sie den Replikationsstatus.

Überprüfen Sie den Replikationsstatus, und warten Sie, bis alle Datenbanken synchronisiert wurden.

sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"

# | Database | Host          | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary     | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
# |          |               |       |              |           |         |           | Host          | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
# | -------- | ------------- | ----- | ------------ | --------- | ------- | --------- | ------------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | HN1      | hana-s1-db3   | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db3   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | SYSTEMDB | hana-s1-db1   | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1   |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1   |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db2   | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db2   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
# status system replication site "2": ACTIVE
# overall system replication status: ACTIVE
#
# Local System Replication State
#
# mode: PRIMARY
# site id: 1
# site name: HANA_S1

[1,2] Ändern Sie die HANA-Konfiguration so, dass die Kommunikation für die HANA-Systemreplikation über die virtuellen Netzwerkschnittstellen der HANA-Systemreplikation geleitet wird.
- HANA an beiden Standorten beenden
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB
```
- Bearbeiten Sie „global.ini“, um die Hostzuordnung für die HANA-Systemreplikation hinzuzufügen: Verwenden Sie die IP-Adressen aus dem Subnetz hsr.
```
sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
#Add the section
[system_replication_hostname_resolution]
10.23.1.196 = hana-s1-db1
10.23.1.197 = hana-s1-db2
10.23.1.198 = hana-s1-db3
10.23.1.199 = hana-s2-db1
10.23.1.200 = hana-s2-db2
10.23.1.201 = hana-s2-db3
```
- HANA an beiden Standorten starten
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB
```
Weitere Informationen finden Sie unter Hostnamensauflösung für die Systemreplikation.

Erstellen von Dateisystemressourcen

Erstellen Sie eine Dummy-Dateisystemclusterressource, die Fehler überwacht und meldet, falls beim Zugreifen auf das über NFS eingebundene Dateisystem /hana/shared ein Problem auftritt. Dann kann der Cluster ein Failover auslösen, falls beim Zugreifen auf /hana/shared ein Problem auftritt. Weitere Informationen hierzu finden Sie unter Behandeln fehlerhafter NFS-Freigaben im SUSE-Hochverfügbarkeitscluster für die HANA-Systemreplikation.

[1] Versetzen Sie Pacemaker in den Wartungsmodus, als Vorbereitung für die Erstellung der HANA-Clusterressourcen.
```
crm configure property maintenance-mode=true
```
[1,2] Erstellen Sie das Verzeichnis im in NFS eingebundenen Dateisystem „/hana/shared“, das in der speziellen Überwachungsressource des Dateisystems verwendet wird. Die Verzeichnisse müssen an beiden Standorten erstellt werden.
```
mkdir -p /hana/shared/HN1/check
```
[AH] Erstellen Sie das Verzeichnis, das zum Einbinden der speziellen Überwachungsressource des Dateisystems verwendet wird. Das Verzeichnis muss auf allen HANA-Clusterknoten erstellt werden.
```
mkdir -p /hana/check
```
[1] Erstellen Sie die Clusterressourcen des Dateisystems.
```
crm configure primitive fs_HN1_HDB03_fscheck Filesystem \
  params device="/hana/shared/HN1/check" \
  directory="/hana/check" fstype=nfs4 \
  options="bind,defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock" \
  op monitor interval=120 timeout=120 on-fail=fence \
  op_params OCF_CHECK_LEVEL=20 \
  op start interval=0 timeout=120 op stop interval=0 timeout=120

crm configure clone cln_fs_HN1_HDB03_fscheck fs_HN1_HDB03_fscheck \
  meta clone-node-max=1 interleave=true

crm configure location loc_cln_fs_HN1_HDB03_fscheck_not_on_mm \
  cln_fs_HN1_HDB03_fscheck -inf: hana-s-mm    
```
Das Attribut OCF_CHECK_LEVEL=20 wird dem Überwachungsvorgang hinzugefügt, sodass Überwachungsvorgänge einen Lese-/Schreibtest auf dem Dateisystem ausführen. Ohne dieses Attribut überprüft der Überwachungsvorgang nur, ob das Dateisystem eingebunden ist. Dies kann ein Problem sein, denn im Fall eines Konnektivitätsverlusts bleibt das Dateisystem möglicherweise eingebunden, es kann aber nicht darauf zugegriffen werden.

Das Attribut on-fail=fence wird dem Überwachungsvorgang ebenfalls hinzugefügt. Durch diese Option wird ein Knoten sofort eingegrenzt, wenn beim Überwachungsvorgang für diesen Knoten ein Fehler auftritt.

Implementieren von HANA-Hochverfügbarkeitshooks, SAPHanaSR und susChkSrv

Dieser wichtige Schritt optimiert die Integration in den Cluster und die Erkennung, wann ein Clusterfailover möglich ist. Es wird dringend empfohlen, den Python-Hook „SAPHanaSrMultiTarget“ zu konfigurieren. Für HANA 2.0 SP5 und höher wird die Implementierung der SAPHanaSrMultiTarget- und susChkSrv-Hooks empfohlen.

Hinweis

Der SAPHanaSrMultiTarget-Hochverfügbarkeitsanbieter ersetzt SAPHanaSR für horizontale HANA-Skalierung. SAPHanaSR wurde in einer früheren Version dieses Dokuments beschrieben.
Weitere Informationen zu Änderungen durch den neuen HANA-Hochverfügbarkeitshook finden Sie im SUSE-Blogbeitrag.

Die angegebenen Schritte für den SAPHanaSrMultiTarget-Hook gelten für eine Neuinstallation. Das Upgrade einer vorhandenen Umgebung von SAPHanaSR auf den SAPHanaSrMultiTarget-Anbieter erfordert mehrere Änderungen und wird in diesem Dokument NICHT beschrieben. Wenn die vorhandene Umgebung keinen dritten Standort für die Notfallwiederherstellung und keine HANA-Systemreplikation mit mehreren Zielen verwendet, kann der SAPHanaSR-Hochverfügbarkeitsanbieter weiterhin genutzt werden.

SusChkSrv erweitert die Funktionalität des wichtigsten SAPHanaSrMultiTarget-Hochverfügbarkeitsanbieters. Der Hook wird wirksam, wenn der HANA-Prozess hdbindexserver abstürzt. Wenn ein einzelner Prozess abstürzt, versucht HANA in der Regel, ihn neu zu starten. Das Neustarten des Indexserverprozesses kann lange dauern. In dieser Zeit reagiert die HANA-Datenbank nicht. Wenn susChkSrv implementiert ist, wird eine sofortige und konfigurierbare Aktion ausgeführt, anstatt auf den hdbindexserver-Prozess zu warten, bis dieser auf demselben Knoten neu gestartet wird. In horizontaler HANA-Skalierung agiert susChkSrvunabhängig für jede HANA-VM. Die konfigurierte Aktion beendet HANA oder grenzt die betroffene VM ein, wodurch ein Failover im konfigurierten Timeoutzeitraum ausgelöst wird.

SUSE SLES 15 SP1 oder höher ist für den Betrieb der beiden HANA-Hochverfügbarkeitshooks erforderlich. Die folgende Tabelle zeigt weitere Abhängigkeiten.

SAP HANA-Hochverfügbarkeitshook	Erforderliche HANA-Version	SAPHanaSR-ScaleOut erforderlich
SAPHanaSrMultiTarget	HANA 2.0 SPS4 oder höher	0.180 oder höher
susChkSrv	HANA 2.0 SPS5 oder höher	0.184.1 oder höher

Schritte zum Implementieren der beiden Hooks:

[1,2] Beenden Sie HANA an beiden Systemreplikationsstandorten. Führen Sie den Vorgang als <sid>adm aus:
```
sapcontrol -nr 03 -function StopSystem
```
[1,2] Passen Sie die Datei global.ini an jeder Clustersite an. Wenn die Voraussetzungen für den susChkSrv-Hook nicht erfüllt sind, sollte der gesamte Block [ha_dr_provider_suschksrv] nicht konfiguriert werden.
Sie können das Verhalten von susChkSrv mit dem Parameter action_on_lost anpassen. Gültige Werte sind [ ignore | stop | kill | fence ].
```
# add to global.ini on both sites. Do not copy global.ini between sites.
[ha_dr_provider_saphanasrmultitarget]
provider = SAPHanaSrMultiTarget
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 3
action_on_lost = kill

[trace]
ha_dr_saphanasrmultitarget = info
```
Der Standardspeicherort der Hochverfügbarkeitshooks bereitgestellt durch SUSE lautet: /usr/share/SAPHanaSR-ScaleOut. Die Verwendung des Standardspeicherorts hat den Vorteil, dass der Python-Hookcode durch Betriebssystem- oder Paketupdates automatisch aktualisiert und beim nächsten Neustart von HANA verwendet wird. Mit einem optionalen eigenen Pfad wie /hana/shared/myHooks können Sie Betriebssystemupdates von der verwendeten Hookversion entkoppeln.

[AH] Der Cluster erfordert sudoers-Konfiguration auf den Clusterknoten für <sid>adm. In diesem Beispiel wird dies durch das Erstellen einer neuen Datei erreicht. Führen Sie die Befehle als root aus, und passen Sie die Werte von hn1 mit der richtigen SID in Kleinbuchstaben an.

cat << EOF > /etc/sudoers.d/20-saphana
# SAPHanaSR-ScaleOut needs for HA/DR hook scripts
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_gsh *
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=hn1 *
EOF

[1,2] Starten Sie SAP HANA an beiden Replikationsstandorten. Führen Sie den Vorgang als <sid>adm aus:
```
sapcontrol -nr 03 -function StartSystem 
```

[A] Überprüfen Sie, ob die Hookinstallation auf allen Clusterknoten aktiv ist. Führen Sie den Vorgang als <sid>adm aus:

cdtrace
grep HADR.*load.*SAPHanaSrMultiTarget nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[14162]{-1}[-1/-1] 2023-01-26 12:53:55.728027 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'SAPHanaSrMultiTarget' from /usr/share/SAPHanaSR-ScaleOut/
grep SAPHanaSr.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256705 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00080) : SAPHanaSrMultiTarget.init() CALLING CRM: <sudo /usr/sbin/crm_attribute -n hana_hn1_gsh -v 2.2  -l reboot> rc=0
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256739 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00081) : SAPHanaSrMultiTarget.init() Running srHookGeneration 2.2, see attribute hana_hn1_gsh too

Überprüfen Sie die Installation des susChkSrv-Hooks. Führen Sie den Vorgang als <sid>adm aus:

cdtrace
egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
# Example output
# 2023-01-19 08:23:10.581529  [1674116590-10005] susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
# 2023-01-19 08:23:31.553566  [1674116611-14022] START: indexserver event looks like graceful tenant start
# 2023-01-19 08:23:52.834813  [1674116632-15235] START: indexserver event looks like graceful tenant start (indexserver started)

Erstellen von SAP HANA-Clusterressourcen

[1] Erstellen Sie die HANA-Clusterressourcen. Führen Sie die folgenden Befehle als root aus.

Stellen Sie sicher, dass sich der Cluster bereits im Wartungsmodus befindet.

Als nächstes erstellen Sie die HANA-Topologieressource.

sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="HN1" InstanceNumber="03"

sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \
 meta clone-node-max="1" target-role="Started" interleave="true"

Als nächstes erstellen Sie die HANA-Instanzressource.

Hinweis

In diesem Artikel werden Begriffe verwendet, die von Microsoft nicht mehr genutzt werden. Sobald diese Begriffe aus der Software entfernt wurden, werden sie auch aus diesem Artikel gelöscht.
```
sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op monitor interval="60" role="Master" timeout="700" \
  op monitor interval="61" role="Slave" timeout="700" \
  params SID="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
  meta clone-node-max="1" master-max="1" interleave="true"
```
Wichtig

Es wird als bewährte Methode empfohlen, AUTOMATED_REGISTER nur auf no festzulegen, während gründliche Failovertests durchgeführt werden, um zu verhindern, dass sich eine fehlerhafte primäre Instanz automatisch als sekundäre Instanz registriert. Nachdem die Failover-Tests erfolgreich abgeschlossen sind, legen Sie AUTOMATED_REGISTER auf yes fest, sodass nach der Übernahme die Systemreplikation automatisch wieder aufgenommen werden kann.

Erstellen Sie die virtuelle IP-Adresse und zugehörige Ressourcen.

sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"

sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

Erstellen der Clustereinschränkungen

# Colocate the IP with HANA master
sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
  msl_SAPHana_HN1_HDB03:Master  

# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
  msl_SAPHana_HN1_HDB03

# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaCon_not_on_majority_maker msl_SAPHana_HN1_HDB03 -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_HN1_HDB03 -inf: hana-s-mm

[1] Konfigurieren Sie zusätzliche Clustereigenschaften.

sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=50

[1] Beenden Sie für den Cluster den Wartungsmodus. Stellen Sie sicher, dass der Clusterstatus gültig ist und alle Ressourcen gestartet sind.

# Cleanup any failed resources - the following command is example 
crm resource cleanup rsc_SAPHana_HN1_HDB03

# Place the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false

[1] Überprüfen Sie die Kommunikation zwischen dem HANA-Hochverfügbarkeitshook und dem Cluster, und zeigen Sie den SOK-Status für die SID und beide Replikationsstandorte mit dem Status P(rimär) oder S(ekundär) an.
```
sudo /usr/sbin/SAPHanaSR-showAttr
# Expected result
# Global cib-time                 maintenance prim  sec sync_state upd
# ---------------------------------------------------------------------
# HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
# 
# Sites     lpt        lss mns        srHook srr
# -----------------------------------------------
# HANA_S1     1674815869 4   hana-s1-db1 PRIM   P
# HANA_S2     30         4   hana-s2-db1 SWAIT  S
```
Hinweis

Die Timeouts in der oben beschriebenen Konfiguration sind nur Beispiele und müssen möglicherweise an das spezifische HANA-Setup angepasst werden. Beispielsweise müssen Sie ggf. das Starttimeout erhöhen, wenn es länger dauert, bis die SAP HANA-Datenbank gestartet wird.

Testen des SAP HANA-Failovers

Hinweis

In diesem Artikel werden Begriffe verwendet, die von Microsoft nicht mehr genutzt werden. Sobald diese Begriffe aus der Software entfernt wurden, werden sie auch aus diesem Artikel gelöscht.

Bevor Sie einen Test starten, überprüfen Sie den Cluster und den Replikationsstatus des SAP HANA-Systems.

a. Überprüfen Sie, ob es keine fehlerhaften Clusteraktionen gibt.

#Verify that there are no failed cluster actions
crm status
# Example 
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Full list of resources:
#
# stonith-sbd    (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s1-db1

b. Überprüfen Sie, ob die SAP HANA-Systemreplikation synchronisiert ist.

# Verify HANA HSR is in sync
sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
#| Database | Host         | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary    | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
#|          |              |       |              |           |         |           | Host         | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
#| -------- | ------------ | ----- | ------------ | --------- | ------- | --------- | ------------ | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
#| SYSTEMDB | hana-s1-db1  | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1  |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1  |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db3  | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db3  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db2  | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db2  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
#status system replication site "1": ACTIVE
#overall system replication status: ACTIVE
#
#Local System Replication State
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
#mode: PRIMARY
#site id: 1
#site name: HANA_S1

Es wird empfohlen, die SAP HANA-Clusterkonfiguration gründlich zu überprüfen, indem Sie die Tests durchführen, die unter Hochverfügbarkeit von SAP HANA auf Azure-VMs unter SUSE Linux Enterprise Server und SLES SAP HANA-Systemreplikation (horizontale Skalierung) – leistungsoptimiertes Szenario dokumentiert sind.
Überprüfen Sie die Clusterkonfiguration auf ein Fehlerszenario, bei dem ein Knoten den Zugriff auf die NFS-Freigabe (/hana/shared) verliert.

Die SAP HANA-Ressourcen-Agents benötigen in /hana/shared gespeicherte Binärdateien, um während eines Failovers Vorgänge auszuführen. Das Dateisystem /hana/shared ist in der dargestellten Konfiguration über NFS eingebunden. Ein Test, der durchgeführt werden kann, besteht darin, eine temporäre Firewallregel zu erstellen, um den Zugriff auf das in NFS eingebundene Dateisystem /hana/shared auf einer der VMs des primären Standorts zu blockieren. Auf diese Weise lässt sich überprüfen, ob der Cluster ein Failover ausführen wird, wenn der Zugriff auf /hana/shared am aktiven Systemreplikationsstandort verloren geht.

Erwartetes Ergebnis: Wenn Sie den Zugriff auf das in NFS eingebundene Dateisystem /hana/shared auf einer der VMs des primären Standorts blockieren, schlägt der Überwachungsvorgang fehl, der Lese-/Schreibvorgänge für das Dateisystem ausführt, weil er nicht auf das Dateisystem zugreifen kann und ein HANA-Ressourcenfailover auslöst. Dasselbe Ergebnis ist zu erwarten, wenn der HANA-Knoten den Zugriff auf die NFS-Freigabe verliert.

Sie können den Zustand der Clusterressourcen prüfen, indem Sie crm_mon oder crm status ausführen. Zustand der Ressource vor dem Starten des Tests:
```
# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1     
```
So simulieren Sie ein Failover für /hana/shared:
- Wenn Sie NFS in ANF verwenden, bestätigen Sie zunächst die IP-Adresse für das ANF-Volume /hana/shared am primären Standort. Dazu können Sie den Befehl df -kh|grep /hana/shared ausführen.
- Wenn Sie NFS in Azure Files verwenden, bestimmen Sie zunächst die IP-Adresse des privaten Endpunkts für Ihr Speicherkonto.
Richten Sie dann eine temporäre Firewallregel ein, um den Zugriff auf die IP-Adresse des NFS-Dateisystems /hana/shared zu blockieren, indem Sie auf einer der VMs des primären HANA-Systemreplikationsstandorts den folgenden Befehl ausführen.

In diesem Beispiel wurde der Befehl auf „hana-s1-db1“ für das ANF-Volume /hana/shared ausgeführt.
```
iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP
```
Die Clusterressourcen werden zum anderen HANA-Systemreplikationsstandort migriert.

Wenn Sie AUTOMATED_REGISTER="false" festlegen, müssen Sie die SAP HANA-Systemreplikation am sekundären Standort konfigurieren. In diesem Fall können Sie diese Befehle ausführen, um SAP HANA als sekundär neu zu konfigurieren.
```
# Execute on the secondary 
su - hn1adm
# Make sure HANA is not running on the secondary site. If it is started, stop HANA
sapcontrol -nr 03 -function StopWait 600 10
# Register the HANA secondary site
hdbnsutil -sr_register --name=HANA_S1 --remoteHost=hana-s2-db1 --remoteInstance=03 --replicationMode=sync
# Switch back to root and cleanup failed resources
crm resource cleanup SAPHana_HN1_HDB03
```
Der Zustand der Ressourcen nach dem Test:
```
# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s2-db1 ]
#     Slaves: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1
```

Nächste Schritte

Azure Virtual Machines – Planung und Implementierung für SAP
Azure Virtual Machines – Bereitstellung für SAP
Azure Virtual Machines – DBMS-Bereitstellung für SAP
NFS v4.1-Volumes unter Azure NetApp Files für SAP HANA
Informationen zur Erzielung von Hochverfügbarkeit und zur Planung der Notfallwiederherstellung für SAP HANA auf Azure-VMs finden Sie unter Hochverfügbarkeit für SAP HANA auf Azure Virtual Machines (VMs).

Hochverfügbarkeit für horizontal skalierte SAP HANA-Systeme mit HSR unter SUSE Linux Enterprise Server

Übersicht

Vorbereiten der Infrastruktur

Bereitstellen von virtuellen Linux-Computern über das Azure-Portal

Konfigurieren von Azure Load Balancer

Bereitstellen von NFS

Bereitstellen der Infrastruktur für Azure NetApp Files

Bereitstellen von NFS in der Azure Files-Infrastruktur

Konfiguration und Vorbereitung des Betriebssystems

Vorbereiten der Dateisysteme

Einbinden der freigegebenen Dateisysteme (Azure NetApp Files NFS)

Einbinden der freigegebenen Dateisysteme (Azure Files NFS)

Vorbereiten der Daten und Protokollieren lokaler Dateisysteme

Erstellen eines Pacemaker-Clusters

Installation

Vorbereiten der HANA-Installation

HANA-Installation auf dem ersten Knoten an jedem Standort

Konfigurieren der SAP HANA 2.0-Systemreplikation

Erstellen von Dateisystemressourcen

Implementieren von HANA-Hochverfügbarkeitshooks, SAPHanaSR und susChkSrv

Erstellen von SAP HANA-Clusterressourcen

Testen des SAP HANA-Failovers

Nächste Schritte

Zusätzliche Ressourcen