Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server

Artikel
04/08/2024

Um Hochverfügbarkeit in einer lokalen SAP HANA-Bereitstellung zu erzielen, können Sie entweder die SAP HANA-Systemreplikation oder gemeinsam genutzten Speicher verwenden.

Die SAP HANA-Systemreplikation in Azure ist derzeit die einzige auf Azure-VMs (virtuelle Computer) unterstützte Hochverfügbarkeitsfunktion.

Die SAP HANA-Systemreplikation umfasst einen primären Knoten und mindestens einen sekundären Knoten. Änderungen an den Daten auf dem primären Knoten werden synchron oder asynchron an den sekundären Knoten repliziert.

In diesem Artikel wird das Bereitstellen und Konfigurieren der VMs, das Installieren des Clusterframeworks sowie das Installieren und Konfigurieren der SAP HANA-Systemreplikation beschrieben.

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

SAP-Hinweis 1928533. Der Hinweis enthält Folgendes:
- Liste der Azure-VM-Größen, die für die Bereitstellung von SAP-Software unterstützt werden
- Wichtige Kapazitätsinformationen für Azure-VM-Größen
- Unterstützte SAP-Software und Kombinationen aus Betriebssystem (OS) und Datenbank
- Die erforderlichen SAP-Kernelversionen für Windows und Linux in Microsoft Azure
In SAP-Hinweis 2015553 sind die Voraussetzungen für Bereitstellungen von SAP-Software in Azure aufgeführt, die von SAP unterstützt werden.
Der SAP-Hinweis 2205917 enthält empfohlene Betriebssystemeinstellungen für SUSE Linux Enterprise Server 12 (SLES 12) für SAP Applications.
Der SAP-Hinweis 2684254 enthält empfohlene Betriebssystemeinstellungen für SUSE Linux Enterprise Server 15 (SLES 15) für SAP Applications.
SAP-Hinweis 2235581 hat SAP HANA unterstützte Betriebssysteme
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 für 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 Enhanced Monitoring-Erweiterung für SAP.
SAP-Hinweis 401162 enthält Informationen dazu, wie Sie beim Einrichten der HANA-Systemreplikation Fehler vom Typ „Adresse bereits verwendet“ vermeiden.
Das Support-Wiki der SAP-Community enthält alle erforderlichen SAP-Hinweise für Linux.
Zertifizierte SAP HANA-IaaS-Plattformen.
Leitfaden Azure Virtual Machines – Planung und Implementierung für SAP unter Linux
Bereitstellung von Azure Virtual Machines für SAP unter Linux (Leitfaden).
Leitfaden Azure Virtual Machines – DBMS-Bereitstellung für SAP unter Linux
SUSE Linux Enterprise Server for SAP Applications 15 - Best Practices-Leitfäden und SUSE Linux Enterprise Server for SAP Applications 12 - Best Practices-Leitfäden:
- Einrichten einer leistungsoptimierten Infrastruktur für die SAP HANA-Systemreplikation (SLES for SAP Applications). Dieser Leitfaden enthält alle erforderlichen Informationen zum Einrichten der SAP HANA-Systemreplikation für die lokale Entwicklung. Verwenden Sie dieses Handbuch als Grundlage.
- Einrichten einer kostenoptimierten Infrastruktur für die SAP HANA-Systemreplikation (SLES for SAP Applications).

Planen von Hochverfügbarkeit für SAP HANA

Um Hochverfügbarkeit zu erreichen, installieren Sie SAP HANA auf zwei VMs. Die Daten werden mit der HANA-Systemreplikation repliziert.

Diagramm, das eine Übersicht über SAP HANA-Hochverfügbarkeit zeigt.

Das Setup der SAP HANA-Systemreplikation verwendet einen dedizierten virtuellen Hostnamen und virtuelle IP-Adressen. In Azure benötigen Sie einen Lastenausgleich, um eine virtuelle IP-Adresse bereitzustellen.

Die obige Abbildung zeigt ein Beispiel für den Lastenausgleich mit den folgenden Konfigurationen:

Front-End-IP-Adresse: 10.0.0.13 für HN1-db
Testport: 62503

Vorbereiten der Infrastruktur

Der Ressourcen-Agent für SAP HANA ist im SUSE Linux Enterprise Server für SAP-Anwendungen enthalten. Ein Image für SUSE Linux Enterprise Server for SAP Applications 12 oder 15 ist in Azure Marketplace verfügbar. Sie können das Image verwenden, um neue virtuelle Computer bereitzustellen.

Manuelles Bereitstellen von Linux-VMs über das Azure-Portal

In diesem Dokument wird davon ausgegangen, dass Sie bereits eine Ressourcengruppe, ein virtuelles Azure-Netzwerk und ein Subnetz bereitgestellt haben.

Stellen Sie virtuelle Computer für SAP HANA bereit. Wählen Sie ein geeignetes SLES-Image aus, das für das HANA-System unterstützt wird. Sie können VMs über die verschiedenen Verfügbarkeitsoptionen (VM-Skalierungsgruppe, Verfügbarkeitszone oder Verfügbarkeitsgruppe) bereitstellen.

Wichtig

Vergewissern Sie sich, dass das von Ihnen gewählte Betriebssystem für SAP HANA auf den VM-Typen, die Sie verwenden möchten, SAP-zertifiziert ist. Sie können für SAP HANA zertifizierte VM-Typen und deren Betriebssystemversionen unter Für SAP HANA zertifizierte IaaS-Plattformen nachschlagen. Stellen Sie sicher, dass Sie sich die Details des jeweils aufgeführten VM-Typs ansehen, um die vollständige Liste der von SAP HANA unterstützten Betriebssystemversionen für den spezifischen VM-Typ zu erhalten.

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.

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.
- Floating 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 (Command Line Interface, CLI) oder den PowerShell-Befehl.

# 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

# 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

Weitere Informationen zu den erforderlichen Ports für SAP HANA finden Sie im Kapitel zu Verbindungen mit Mandantendatenbanken im Handbuch zu SAP HANA-Mandantendatenbanken oder im SAP-Hinweis 2388694.

Wichtig

Eine Floating IP-Adresse wird in Lastenausgleichsszenarios bei einer sekundären IP-Konfiguration für eine Netzwerkschnittstellenkarte (Network Interface Card, NIC) nicht unterstützt. Einzelheiten finden Sie unter Azure Load Balancer Einschränkungen. Wenn Sie zusätzliche IP-Adressen für die VM benötigen, stellen Sie eine zweite NIC bereit.

Hinweis

Wenn VMs, die keine öffentlichen IP-Adressen besitzen, im Back-End-Pool einer internen Standardinstanz (keine öffentliche IP-Adresse) von Azure Load Balancer platziert werden, bietet die Standardkonfiguration keine ausgehende Internetverbindung. Sie können zusätzliche Schritte ausführen, um das Routing an öffentliche Endpunkte zuzulassen. Ausführliche Informationen zum Erreichen ausgehender Konnektivität finden Sie unter Konnektivität mit öffentlichen Endpunkten für VMs mithilfe von Azure Load Balancer Standard in SAP-Szenarien mit Hochverfügbarkeit.

Wichtig

Aktivieren Sie keine TCP-Zeitstempel auf Azure-VMs, die sich hinter Azure Load Balancer befinden. Die Aktivierung von TCP-Zeitstempeln führt dazu, dass die Health Probes fehlschlagen. Legen Sie den Parameter net.ipv4.tcp_timestamps auf 0 fest. Details finden Sie unter Load Balancer-Integritätstests 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?.

Erstellen eines Pacemaker-Clusters

Führen Sie die Schritte in Einrichten von Pacemaker unter SUSE Linux Enterprise Server in Azure aus, um einen einfachen Pacemaker-Cluster für diesen HANA-Server zu erstellen. Sie können denselben Pacemaker-Cluster für SAP HANA und SAP NetWeaver (A)SCS verwenden.

Installieren von SAP HANA

Für die Schritte in diesem Abschnitt werden die folgenden Präfixe verwendet:

[A] : Der Schritt gilt für alle Knoten.
[1]: Der Schritt gilt nur für Knoten 1.
[2]: Der Schritt gilt nur für den Knoten 2 des Pacemaker-Clusters.

Ersetzen Sie <placeholders> durch die Werte für Ihre SAP HANA-Installation.

[A]: Richten Sie das Datenträgerlayout mit LVM (Logical Volume Manager) ein.

Es wird empfohlen, LVM für Volumes zu verwenden, die Daten- und Protokolldateien speichern. Im folgenden Beispiel wird davon ausgegangen, dass die VMs über vier angefügte Datenträger verfügen, die zum Erstellen von zwei Volumes verwendet werden.
1. Führen Sie diesen Befehl aus, um alle verfügbaren Datenträger auflisten:
```
/dev/disk/azure/scsi1/lun*
```
  Beispielausgabe:
```
/dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2  /dev/disk/azure/scsi1/lun3
```
2. 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
sudo pvcreate /dev/disk/azure/scsi1/lun3
```
3. 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_<HANA SID> /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_<HANA SID> /dev/disk/azure/scsi1/lun2
sudo vgcreate vg_hana_shared_<HANA SID> /dev/disk/azure/scsi1/lun3
```
4. Erstellen Sie die logischen Volumes.
  
  Ein lineares Volume wird erstellt, wenn Sie lvcreate ohne den Schalter -i verwenden. Für eine bessere E/A-Leistung wird empfohlen, ein Striped-Volume zu erstellen. Passen Sie die Bereichsstreifengrößen an die in SAP HANA-VM-Speicherkonfigurationen beschriebenen Werte an. Das -i-Argument sollte die Anzahl der zugrunde liegenden physischen Volumes und das -I-Argument die Bereichsstreifengröße sein.
  
  Wenn beispielsweise zwei physische Volumes für das Datenvolume verwendet werden, wird das -i-Argument auf 2 festgelegt, und die Bereichsstreifengröß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-, Protokoll- oder freigegebenen Volumes mehrere physische Datenträger verwenden. Wenn Sie ein Stripesetvolume erstellen, verwenden Sie den Schalter -I, um die Bereichsstreifengröße anzugeben.
  
  Informationen zu empfohlenen Speicherkonfigurationen, einschließlich Bereichsstreifengrößen und Anzahl der Datenträger, finden Sie unter SAP HANA-VM-Speicherkonfigurationen.
```
sudo lvcreate <-i number of physical volumes> <-I stripe size for the data volume> -l 100%FREE -n hana_data vg_hana_data_<HANA SID>
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_<HANA SID>
sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_<HANA SID>
sudo mkfs.xfs /dev/vg_hana_data_<HANA SID>/hana_data
sudo mkfs.xfs /dev/vg_hana_log_<HANA SID>/hana_log
sudo mkfs.xfs /dev/vg_hana_shared_<HANA SID>/hana_shared
```
5. Erstellen Sie die Bereitstellungsverzeichnisse, und kopieren Sie die universellen eindeutigen Bezeichner (UUID) aller logischen Volumes:
```
sudo mkdir -p /hana/data/<HANA SID>
sudo mkdir -p /hana/log/<HANA SID>
sudo mkdir -p /hana/shared/<HANA SID>
# Write down the ID of /dev/vg_hana_data_<HANA SID>/hana_data, /dev/vg_hana_log_<HANA SID>/hana_log, and /dev/vg_hana_shared_<HANA SID>/hana_shared
sudo blkid
```
6. Bearbeiten Sie die Datei /etc/fstab, um fstab-Einträge für die drei logischen Volumes zu erstellen:
```
sudo vi /etc/fstab
```
7. Fügen Sie in der Datei /etc/fstab die folgenden Zeilen hinzu:
```
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_data_<HANA SID>-hana_data> /hana/data/<HANA SID> xfs  defaults,nofail  0  2
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_log_<HANA SID>-hana_log> /hana/log/<HANA SID> xfs  defaults,nofail  0  2
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_<HANA SID>-hana_shared> /hana/shared/<HANA SID> xfs  defaults,nofail  0  2
```
8. Stellen Sie die neuen Volumes bereit:
```
sudo mount -a
```
[A] Richten Sie das Datenträgerlayout mithilfe einfacher Datenträger ein.

Für Demosysteme können Sie Ihre HANA-Daten- und Protokolldateien auf einem Datenträger platzieren.
1. Erstellen Sie auf /dev/disk/azure/scsi1/lun0 eine Partition, und formatieren Sie sie mit XFS:
```
sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0'
sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1

# Write down the ID of /dev/disk/azure/scsi1/lun0-part1
sudo /sbin/blkid
sudo vi /etc/fstab
```
2. Fügen Sie diese Zeile in die Datei /etc/fstab ein:
```
/dev/disk/by-uuid/<UUID> /hana xfs  defaults,nofail  0  2
```
3. Erstellen Sie das Zielverzeichnis, und stellen Sie den Datenträger bereit:
```
sudo mkdir /hana
sudo mount -a
```
[A] Richten Sie die Hostnamensauflösung für alle Hosts ein.

Sie können entweder einen DNS-Server verwenden oder die Datei /etc/hosts auf allen Knoten ändern. In diesem Beispiel wird die Verwendung der Datei /etc/hosts veranschaulicht. Ersetzen Sie in den folgenden Befehlen die IP-Adressen und Hostnamen.
1. Bearbeiten Sie die Datei etc/hosts:
```
sudo vi /etc/hosts
```
2. Fügen Sie in der Datei /etc/hosts die folgenden Zeilen hinzu. Ändern Sie die IP-Adressen und Hostnamen entsprechend Ihrer Umgebung.
```
10.0.0.5 hn1-db-0
10.0.0.6 hn1-db-1
```
[A] Installieren Sie die Hochverfügbarkeitspakete für SAP HANA.
- Führen Sie den folgenden Befehl aus, um die Hochverfügbarkeitspakete zu installieren:
```
sudo zypper install SAPHanaSR
```
Installieren Sie die SAP HANA-Systemreplikation gemäß Kapitel 4 des Leitfadens Szenario mit leistungsoptimierter SAP HANA-Systemreplikation.
[A] Führen Sie das Programm hdblcm von den HANA-Installationsmedien aus.

Sie werden aufgefordert, die folgenden Werte einzugeben:
1. Wählen Sie die Installation aus: Geben Sie 1 ein.
2. Wählen Sie weitere Komponenten für die Installation aus: Geben Sie 1 ein.
3. Enter installation path: Geben Sie /hana/shared ein, und drücken Sie die EINGABETASTE.
4. Enter local host name: Geben Sie .. ein, und drücken Sie die EINGABETASTE.
5. Möchten Sie dem System weitere Hosts hinzufügen? (y/n): Geben Sie n ein, und drücken Sie die EINGABETASTE.
6. Enter the SAP HANA system ID: Geben Sie Ihre HANA-SID ein.
7. Enter the instance number: Geben Sie die HANA-Instanznummer ein. Wenn Sie die Azure-Vorlage bereitgestellt haben oder wenn Sie dem Abschnitt für die manuelle Bereitstellung dieses Artikels gefolgt sind, geben Sie 03 ein.
8. Select the database mode / Enter the index: Geben Sie 1 ein, und drücken Sie die EINGABETASTE.
9. Select the system usage / Enter the index: Wählen Sie den Systemnutzungswert 4 aus.
10. Enter the location of the data volumes: Geben Sie /hana/data/<HANA-SID> ein, und drücken Sie die EINGABETASTE.
11. Enter the location of the log volumes: Geben Sie /hana/log/<HANA-SID> ein, und drücken Sie die EINGABETASTE.
12. Restrict maximum memory allocation?: Geben Sie n ein, und drücken Sie die EINGABETASTE.
13. Enter the certificate host name for the host: Geben Sie ... ein, und drücken Sie die EINGABETASTE.
14. Enter the SAP host agent user (sapadm) password: Geben Sie das Kennwort für das Host-Agent-Benutzerkonto ein, und drücken Sie dann die EINGABETASTE.
15. Confirm the SAP host agent user (sapadm) password: Geben Sie das Kennwort des Host-Agent-Benutzerkontos erneut ein, und drücken Sie dann die EINGABETASTE.
16. Enter the system administrator (hdbadm) password: Geben Sie das Kennwort des Systemadministratorkontos ein, und drücken Sie dann die EINGABETASTE.
17. Confirm the system administrator (hdbadm) password: Geben Sie das Kennwort des Systemadministratorkontos erneut ein, und drücken Sie dann die EINGABETASTE.
18. Enter the system administrator home directory: Geben Sie /usr/sap/<HANA-SID>/home ein, und drücken Sie die EINGABETASTE.
19. Enter the system administrator login shell: Geben Sie /bin/sh ein, und drücken Sie die EINGABETASTE.
20. Enter the system administrator user ID: Geben Sie 1001 ein, und drücken Sie die EINGABETASTE.
21. Enter ID of the user group (sapsys): Geben Sie 79 ein, und drücken Sie die EINGABETASTE.
22. Enter the database user (SYSTEM) password: Geben Sie das Kennwort des Datenbankbenutzerkontos ein, und drücken Sie dann die EINGABETASTE.
23. Confirm the database user (SYSTEM) password: Geben Sie das Kennwort des Datenbankbenutzerkontos erneut ein, und drücken Sie dann die EINGABETASTE.
24. Restart the system after machine reboot? (y/n): Geben Sie n ein, und drücken Sie die EINGABETASTE.
25. Möchten Sie fortfahren? (j/n): Überprüfen Sie die Zusammenfassung. Geben Sie y ein, um fortzufahren.
[A] Führen Sie ein Upgrade für den SAP-Host-Agent durch.

Laden Sie das neueste SAP-Host-Agent-Archiv aus dem SAP Software Center herunter. Führen Sie den folgenden Befehl aus, um den Agent zu aktualisieren. Ersetzen Sie den Pfad zum Archiv, um auf die Datei zu verweisen, die Sie heruntergeladen haben.
```
sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP host agent SAR>
```

Konfigurieren Sie die SAP HANA 2.0 Systemreplikation

Für die Schritte in diesem Abschnitt werden die folgenden Präfixe verwendet:

[A] : Der Schritt gilt für alle Knoten.
[1]: Der Schritt gilt nur für Knoten 1.
[2]: Der Schritt gilt nur für den Knoten 2 des Pacemaker-Clusters.

Ersetzen Sie <placeholders> durch die Werte für Ihre SAP HANA-Installation.

[1] Erstellen Sie die Mandantendatenbank.

Wenn Sie SAP HANA 2.0 oder SAP HANA MDC verwenden, erstellen Sie eine Mandantendatenbank für Ihr SAP NetWeaver-System.

Führen Sie den folgenden Befehl als „<HANA-SID>adm“ aus:
```
hdbsql -u SYSTEM -p "<password>" -i <instance number> -d SYSTEMDB 'CREATE DATABASE <SAP SID> SYSTEM USER PASSWORD "<password>"'
```

[1] Konfigurieren Sie die Systemreplikation auf dem ersten Knoten:

Sichern Sie zunächst die Datenbanken als „<HANA-SID>adm“:

hdbsql -d SYSTEMDB -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SYS>')"
hdbsql -d <HANA SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for HANA SID>')"
hdbsql -d <SAP SID> -u SYSTEM -p "<password>" -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file for SAP SID>')"

Kopieren Sie dann die PKI-Dateien (Public Key--Infrastruktur) des Systems an den sekundären Standort:

scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/SSFS_<HANA SID>.DAT   hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/
scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/SSFS_<HANA SID>.KEY  hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/

Erstellen Sie den primären Standort:

hdbnsutil -sr_enable --name=<site 1>

[2] Konfigurieren Sie die Systemreplikation auf dem zweiten Knoten:

Registrieren Sie den zweiten Knoten zum Starten der Replikation.

Führen Sie den folgenden Befehl als „<HANA-SID>adm“ aus:
```
sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> 
```

Konfigurieren der SAP HANA 1.0-Systemreplikation

Für die Schritte in diesem Abschnitt werden die folgenden Präfixe verwendet:

[A] : Der Schritt gilt für alle Knoten.
[1]: Der Schritt gilt nur für Knoten 1.
[2]: Der Schritt gilt nur für den Knoten 2 des Pacemaker-Clusters.

Ersetzen Sie <placeholders> durch die Werte für Ihre SAP HANA-Installation.

[1] Erstellen Sie die erforderlichen Benutzer.

Führen Sie den folgenden Befehl als root aus:

PATH="$PATH:/usr/sap/<HANA SID>/HDB<instance number>/exe"
hdbsql -u system -i <instance number> 'CREATE USER hdbhasync PASSWORD "<password>"'
hdbsql -u system -i <instance number> 'GRANT DATA ADMIN TO hdbhasync'
hdbsql -u system -i <instance number> 'ALTER USER hdbhasync DISABLE PASSWORD LIFETIME'

[A] Erstellen Sie den Keystoreeintrag.

Führen Sie den folgenden Befehl als root aus, um einen neuen Keystoreeintrag zu erstellen:

PATH="$PATH:/usr/sap/<HANA SID>/HDB<instance number>/exe"
hdbuserstore SET hdbhaloc localhost:3<instance number>15 hdbhasync <password>

[1] Sichern Sie die Datenbank.

Sichern Sie die Datenbanken als root:

PATH="$PATH:/usr/sap/<HANA SID>/HDB<instance number>/exe"
hdbsql -d SYSTEMDB -u system -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file>')"

Wenn Sie eine Installation mit mehreren Mandanten verwenden, sichern Sie auch die Mandantendatenbank:

hdbsql -d <HANA SID> -u system -i <instance number> "BACKUP DATA USING FILE ('<name of initial backup file>')"

[1] Konfigurieren Sie die Systemreplikation auf dem ersten Knoten.

Erstellen Sie den primären Standort als „<HANA-SID>adm“:
```
su - hdbadm
hdbnsutil -sr_enable --name=<site 1>
```

[2] Konfigurieren Sie die Systemreplikation auf dem zweiten Knoten.

Registrieren Sie den sekundären Standort als „<HANA-SID>adm“:

sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=<HANA SID>-db-<database 1> --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

Implementieren der HANA-Hooks SAPHanaSR und susChkSrv

Dies ist ein wichtiger Schritt, um die Integration in den Cluster zu optimieren und besser zu erkennen, wann ein Clusterfailover erforderlich ist. Es wird dringend empfohlen, den SAPHanaSR-Python-Hook zu konfigurieren. Für HANA 2.0 SP5 sollten Sie den SAPHanaSR-Hook und den susChkSrv-Hook implementieren.

Der susChkSrv-Hook erweitert die Funktionalität des Hauptanbieters für SAPHanaSR-Hochverfügbarkeit. Es wird ausgeführt, wenn der HANA-Prozess hdbindexserver abstürzt. Wenn ein einzelner Prozess abstürzt, versucht HANA in der Regel, diesen 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. Die Aktion löst ein Failover im konfigurierten Timeoutzeitraum aus, anstatt darauf zu warten, dass der Prozess hdbindexserver auf demselben Knoten neu gestartet wird.

[A] Installieren Sie den HANA-Systemreplikationshook. Der Hook muss auf beiden HANA-Datenbankknoten installiert werden.

Tipp

Der SAPHanaSR-Python-Hook kann nur für HANA 2.0 implementiert werden. Das SAPHanaSR-Paket muss mindestens Version 0.153 aufweisen.

Der susChkSrv-Python-Hook erfordert SAP HANA 2.0 SP5. Außerdem muss die SAPHanaSR-Version 0.161.1_BF oder höher installiert sein.
1. Beenden Sie HANA auf beiden Knoten.
  
  Führen Sie den folgenden Code als „<sapsid>adm“ aus:
```
sapcontrol -nr <instance number> -function StopSystem
```
2. Passen Sie Datei global.ini auf jedem Clusterknoten an. Wenn die Anforderungen für den susChkSrv-Hook nicht erfüllt sind, entfernen Sie den gesamten [ha_dr_provider_suschksrv]-Block aus den folgenden Parametern.
  
  Sie können das Verhalten von susChkSrv mithilfe des action_on_lost-Parameters anpassen. Gültige Werte sind: [ignore | stop | kill | fence].
```
# add to global.ini
[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR
execution_order = 3
action_on_lost = fence

[trace]
ha_dr_saphanasr = info
```
  Wenn Sie auf den Standardspeicherort /usr/share/SAPHanaSR verweisen, wird der Code für den Python-Hook automatisch über Betriebssystem- oder Paketupdates aktualisiert. HANA verwendet beim nächsten Neustart die Codeupdates für den Hook. Bei einem optionalen eigenen Pfad wie /hana/shared/myHooks können Sie Betriebssystemupdates von der verwendeten Hookversion entkoppeln.
[A] Der Cluster erfordert die Konfiguration von sudoers auf jedem Clusterknoten für „<SAP-SID>adm“. In diesem Beispiel wird dies durch das Erstellen einer neuen Datei erreicht.

Führen Sie den folgenden Befehl als root aus:
```
 cat << EOF > /etc/sudoers.d/20-saphana
 # Needed for SAPHanaSR and susChkSrv Python hooks
 hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
 hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=HN1 --case=fenceMe
 EOF
```
Ausführliche Informationen zur Implementierung des Hooks für die SAP HANA-Systemreplikation finden Sie unter Einrichten von HANA-Anbietern für Hochverfügbarkeit/Notfallwiederherstellung (HA/DR).
[A] Starten Sie SAP HANA auf beiden Knoten.

Führen Sie den folgenden Befehl als „<SAP-SID>adm“ aus:
```
 sapcontrol -nr <instance number> -function StartSystem 
```

[1] Überprüfen Sie die Installation des Hooks.

Führen Sie den folgenden Befehl als „<SAP-SID>adm“ am aktiven HANA-Systemreplikationsstandort aus:

 cdtrace
 awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
 { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*
 # Example output
 # 2021-04-08 22:18:15.877583 ha_dr_SAPHanaSR SFAIL
 # 2021-04-08 22:18:46.531564 ha_dr_SAPHanaSR SFAIL
 # 2021-04-08 22:21:26.816573 ha_dr_SAPHanaSR SOK

Überprüfen Sie die Installation des susChkSrv-Hooks.

Führen Sie den folgenden Befehl als „<SAP-SID>adm“ auf allen HANA-VMs aus:

 cdtrace
 egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
 # Example output
 # 2022-11-03 18:06:21.116728  susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
 # 2022-11-03 18:06:27.613588  START: indexserver event looks like graceful tenant start
 # 2022-11-03 18:07:56.143766  START: indexserver event looks like graceful tenant start (indexserver started)

Erstellen von SAP HANA-Clusterressourcen

Erstellen Sie zuerst die HANA-Topologie.

Führen Sie die folgenden Befehle auf einem der Pacemaker-Clusterknoten aus:

sudo crm configure property maintenance-mode=true

# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaTopology \
  operations \$id="rsc_sap2_<HANA SID>_HDB<instance number>-operations" \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="<HANA SID>" InstanceNumber="<instance number>"

sudo crm configure clone cln_SAPHanaTopology_<HANA SID>_HDB<instance number> rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" target-role="Started" interleave="true"

Erstellen Sie als Nächstes die HANA-Ressourcen:

Wichtig

Bei den letzten Tests wurde netcat als Reaktion auf Anforderungen aufgrund eines Backlogs und aufgrund der Einschränkung bei der Verarbeitung nur einer Verbindung beendet. Die netcat-Ressource lauscht dann nicht mehr auf Azure Load Balancer-Anforderungen, und die Floating IP-Adresse ist nicht mehr verfügbar.

Für vorhandene Pacemaker-Cluster wurde bisher empfohlen, netcat durch socat zu ersetzen. Aktuell wird empfohlen, den azure-lb-Ressourcen-Agent zu verwenden, der Teil eines Pakets von resource-agents ist. Die folgenden Paketversionen sind erforderlich:

Für SLES 12 SP4/SP5 muss die Version mindestens resource-agents-4.3.018.a7fb5035-3.30.1 sein.
Für SLES 15/15 SP1 muss die Version mindestens resource-agents-4.3.0184.6ee15eb2-4.13.1 sein.

Wenn Sie Änderung vornehmen, erfordern diese eine kurze Downtime.

Für vorhandene Pacemaker-Cluster müssen Sie nicht sofort zum azure-lb-Ressourcen-Agent wechseln, wenn Ihre Konfiguration bereits wie in Härten der Azure Load Balancer-Erkennung beschrieben geändert wurde, sodass sie socat verwendet.

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.

# Replace <placeholders> with your instance number, HANA system ID, and the front-end IP address of the Azure load balancer. 

sudo crm configure primitive rsc_SAPHana_<HANA SID>_HDB<instance number> ocf:suse:SAPHana \
  operations \$id="rsc_sap_<HANA SID>_HDB<instance number>-operations" \
  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="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_<HANA SID>_HDB<instance number> rsc_SAPHana_<HANA SID>_HDB<instance number> \
  meta notify="true" clone-max="2" clone-node-max="1" \
  target-role="Started" interleave="true"

sudo crm resource meta msl_SAPHana_<HANA SID>_HDB<instance number> set priority 100

sudo crm configure primitive rsc_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
  meta target-role="Started" \
  operations \$id="rsc_ip_<HANA SID>_HDB<instance number>-operations" \
  op monitor interval="10s" timeout="20s" \
  params ip="<front-end IP address>"

sudo crm configure primitive rsc_nc_<HANA SID>_HDB<instance number> azure-lb port=625<instance number> \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_<HANA SID>_HDB<instance number> rsc_ip_<HANA SID>_HDB<instance number> rsc_nc_<HANA SID>_HDB<instance number>

sudo crm configure colocation col_saphana_ip_<HANA SID>_HDB<instance number> 4000: g_ip_<HANA SID>_HDB<instance number>:Started \
  msl_SAPHana_<HANA SID>_HDB<instance number>:Master  

sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  msl_SAPHana_<HANA SID>_HDB<instance number>

# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHana_<HANA SID>_HDB<instance number>

sudo crm configure property priority-fencing-delay=30

sudo crm configure property maintenance-mode=false
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

Wichtig

Es wird empfohlen, AUTOMATED_REGISTER nur dann auf false festzulegen, während Sie gründliche Failovertests durchführen, wenn Sie verhindern möchten, dass eine fehlerhafte primäre Instanz automatisch als sekundär registriert wird. Wenn die Failovertests erfolgreich abgeschlossen wurden, legen Sie AUTOMATED_REGISTER auf true fest, damit die Systemreplikation nach der Übernahme automatisch fortgesetzt wird.

Vergewissern Sie sich, dass der Clusterstatus OK lautet und alle Ressourcen gestartet wurden. Es spielt keine Rolle, auf welchem Knoten die Ressourcen ausgeführt werden.

sudo crm_mon -r

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Konfigurieren der HANA-Systemreplikation im Modus „Aktiv/Lesezugriff“ in einem Pacemaker-Cluster

Ab SAP HANA 2.0 SPS 01 ermöglicht SAP ein Setup der SAP HANA-Systemreplikation im Modus „Aktiv/Lesezugriff“. In diesem Szenario können die sekundären Systeme der SAP HANA-Systemreplikation aktiv für leseintensive Workloads verwendet werden.

Zur Unterstützung eines solchen Setups in einem Cluster ist eine zweite virtuelle IP-Adresse erforderlich, damit Clients auf die sekundäre, lesefähige SAP HANA-Datenbank zugreifen können. Damit nach einer Übernahme weiterhin auf die sekundäre Replikationswebsite zugegriffen werden kann, muss der Cluster die virtuelle IP-Adresse zusammen mit der sekundären Instanz der SAP HANA-Ressource verschieben.

In diesem Abschnitt werden die zusätzlichen Schritte beschrieben, die zum Verwalten der HANA-Systemreplikation im Modus „Aktiv/Lesezugriff“ in einem SUSE-Hochverfügbarkeitscluster mit einer zweiten virtuellen IP-Adresse erforderlich sind.

Bevor Sie fortfahren, stellen Sie sicher, dass Sie den SUSE-Hochverfügbarkeitscluster, der die SAP HANA-Datenbank verwaltet, vollständig wie weiter oben in diesem Artikel beschrieben konfiguriert haben.

Diagramm, das ein Beispiel für eine hohe Verfügbarkeit von SAP HANA mit einer lesefähigen sekundären IP zeigt.

Einrichten des Lastenausgleichs für die Systemreplikation im Modus „Aktiv/Lesezugriff“

Um die zusätzlichen Schritte zum Bereitstellen der zweiten virtuellen IP-Adresse auszuführen, müssen Sie sicherstellen, dass Sie Azure Load Balancer wie unter Manuelles Bereitstellen von Linux-VMs über das Azure-Portal beschrieben konfiguriert haben.

Für den Standard-Loadbalancer führen Sie die zusätzlichen Schritte in der Load Balancer-Instanz aus, die Sie im vorherigen Abschnitt erstellt haben.

Erstellen eines zweiten Front-End-IP-Pools:
1. Öffnen Sie den Lastenausgleich, und wählen Sie den Front-End-IP-Pool und dann Hinzufügen aus.
2. Geben Sie den Namen des zweiten Front-End-IP-Pools ein (z. B. hana-secondaryIP).
3. Legen Sie die Zuweisung auf Statisch fest, und geben Sie die IP-Adresse ein (z. B. 10.0.0.14).
4. Klicken Sie auf OK.
5. Notieren Sie nach Erstellen des neuen Front-End-IP-Pools die Front-End-IP-Adresse.
Erstellen eines Integritätstests:
1. Wählen Sie im Lastenausgleich Integritätstests und dann Hinzufügen aus.
2. Geben Sie den Namen des neuen Integritätstests ein (z. B. hana-secondaryhp).
3. Wählen Sie TCP als Protokoll und Port 626<Instanznummer> aus. Behalten Sie für das Intervall den Wert 5 und als Fehlerschwellenwert2 bei.
4. Klicken Sie auf OK.
Erstellen Sie die Lastenausgleichsregeln:
1. Wählen Sie im Lastenausgleich Lastenausgleichsregeln und dann Hinzufügen aus.
2. Geben Sie den Namen der neuen Lastenausgleichsregel ein (z. B. hana-secondarylb).
3. Wählen Sie die Front-End-IP-Adresse, den Back-End-Pool und die zuvor erstellte Integritätsprüfung aus (zum Beispiel hana-secondaryIP, hana-backend und hana-secondaryhp).
4. Wählen Sie HA-Ports aus.
5. Erhöhen Sie das Leerlauftimeout auf 30 Minuten.
6. Achten Sie darauf, dass Sie Floating IP aktivieren.
7. Klickan Sie auf OK.

Einrichten der HANA-Systemreplikation im Modus „Aktiv/Lesezugriff“

Die Schritte zum Konfigurieren der HANA-Systemreplikation werden unter Konfigurieren der SAP HANA 2.0-Systemreplikation beschrieben. Wenn Sie ein Szenario mit lesefähigem sekundären Standort bereitstellen, führen Sie beim Einrichten der Systemreplikation auf dem zweiten Knoten den folgenden Befehl als „<HANA-SID>adm“ aus:

sapcontrol -nr <instance number> -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> --operationMode=logreplay_readaccess

Hinzufügen einer sekundären virtuellen IP-Adressressource

Sie können die zweite virtuelle IP und die entsprechende Colocation-Einschränkung einrichten, indem Sie die folgenden Befehle ausführen:

crm configure property maintenance-mode=true

crm configure primitive rsc_secip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
 meta target-role="Started" \
 operations \$id="rsc_secip_<HANA SID>_HDB<instance number>-operations" \
 op monitor interval="10s" timeout="20s" \
 params ip="<secondary IP address>"

crm configure primitive rsc_secnc_<HANA SID>_HDB<instance number> azure-lb port=626<instance number> \
 op monitor timeout=20s interval=10 \
 meta resource-stickiness=0

crm configure group g_secip_<HANA SID>_HDB<instance number> rsc_secip_<HANA SID>_HDB<instance number> rsc_secnc_<HANA SID>_HDB<instance number>

crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
 msl_SAPHana_<HANA SID>_HDB<instance number>:Slave 

crm configure property maintenance-mode=false

Vergewissern Sie sich, dass der Clusterstatus OK lautet und alle Ressourcen gestartet wurden. Die zweite virtuelle IP wird zusammen mit der sekundären SAPHana-Ressource am sekundären Standort ausgeführt.

sudo crm_mon -r

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
# Resource Group: g_secip_HN1_HDB03:
#     rsc_secip_HN1_HDB03       (ocf::heartbeat:IPaddr2):        Started hn1-db-1
#     rsc_secnc_HN1_HDB03       (ocf::heartbeat:azure-lb):       Started hn1-db-1

Im nächsten Abschnitt werden die typischen Failovertests beschrieben, die ausgeführt werden sollten.

Überlegungen beim Testen eines HANA-Clusters, der mit einem lesefähigen sekundären Standort konfiguriert ist:

Wenn Sie die SAPHana_<HANA SID>_HDB<instance number>-Clusterressource zu hn1-db-1 migrieren, wird die zweite virtuelle IP in hn1-db-0 geändert. Wenn Sie AUTOMATED_REGISTER="false" konfiguriert haben und die HANA-Systemreplikation nicht automatisch registriert wurde, wird die zweite virtuelle IP in hn1-db-0 ausgeführt, da der Server verfügbar ist und die Clusterdienste online sind.
Wenn Sie einen Serverabsturz testen, werden die zweite virtuelle IP-Ressource (rsc_secip_<HANA SID>_HDB<instance number>) und die Azure Load Balancer-Portressource (rsc_secnc_<HANA SID>_HDB<instance number>) zusammen mit den primären virtuellen IP-Adressressourcen auf dem primären Server ausgeführt. Während der sekundäre Server ausgefallen ist, stellen die Anwendungen, die mit einer HANA-Datenbank mit Lesezugriff verbunden sind, eine Verbindung mit der primären HANA-Datenbank her. Dieses Verhalten wird erwartet, da Sie nicht möchten, dass auf Anwendungen, die mit einer HANA-Datenbank mit Lesezugriff verbunden sind, nicht zugegriffen werden kann, während der sekundäre Server nicht verfügbar ist.
Wenn der sekundäre Server verfügbar ist und die Clusterdienste online sind, werden die zweiten virtuellen IP-Adressressourcen und die Portressourcen automatisch auf den sekundären Server verschoben, auch wenn die HANA-Systemreplikation möglicherweise nicht als sekundär registriert ist. Sie müssen sicherstellen, dass Sie die sekundäre HANA-Datenbank als lesefähig registrieren, bevor Sie Clusterdienste auf diesem Server starten. Sie können die Clusterressource der HANA-Instanz mit der Parameterfestlegung AUTOMATED_REGISTER="true" so konfigurieren, dass die sekundäre Instanz automatisch registriert wird.
Während Failover und Fallback können die bestehenden Verbindungen für Anwendungen, die zu diesem Zeitpunkt die zweite virtuelle IP zur Verbindung mit der HANA-Datenbank verwenden, unterbrochen werden.

Testen der Clustereinrichtung

In diesem Abschnitt wird beschrieben, wie Sie Ihre Einrichtung testen können. Bei jedem Test wird davon ausgegangen, dass Sie als root angemeldet sind und dass der SAP HANA-Master auf der VM hn1-db-0 ausgeführt wird.

Testen der Migration

Bevor Sie den Test starten, stellen Sie sicher, dass Pacemaker keine fehlerhaften Aktionen enthält (indem Sie crm_mon -r ausführen), dass keine unerwarteten Speicherorteinschränkungen bestehen (z. B. durch zurückgebliebene Elemente vom Migrationstest) und dass HANA synchron ist (z. B. indem Sie SAPHanaSR-showAttr ausführen).

hn1-db-0:~ # SAPHanaSR-showAttr
Sites    srHook
----------------
SITE2    SOK
Global cib-time
--------------------------------
global Mon Aug 13 11:26:04 2018
Hosts    clone_state lpa_hn1_lpt node_state op_mode   remoteHost    roles                            score site  srmode sync_state version                vhost
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    1534159564  online     logreplay nws-hana-vm-1 4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.030.00.1522209842 nws-hana-vm-0
hn1-db-1 DEMOTED     30          online     logreplay nws-hana-vm-0 4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.030.00.1522209842 nws-hana-vm-1

Sie können den SAP HANA-Masterknoten migrieren, indem Sie den folgenden Befehl ausführen:

crm resource move msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1 force

Dieses Cluster würde den SAP HANA-Masterknoten und die Gruppe, die die virtuelle IP-Adresse hn1-db-1 enthält, migrieren.

Nach Abschluss der Migration sieht die Ausgabe von crm_mon -r wie im folgenden Beispiel aus:

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Stopped: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
Failed Actions:
* rsc_SAPHana_HN1_HDB03_start_0 on hn1-db-0 'not running' (7): call=84, status=complete, exitreason='none',
    last-rc-change='Mon Aug 13 11:31:37 2018', queued=0ms, exec=2095ms

Mit AUTOMATED_REGISTER="false" würde der Cluster die fehlerhafte HANA-Datenbank nicht neu starten oder sie für die neue primäre auf hn1-db-0 registrieren. In diesem Fall konfigurieren Sie die HANA-Instanz als sekundär, indem Sie diesen Befehl ausführen:

su - <hana sid>adm

# Stop the HANA instance, just in case it is running
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr <instance number> -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

Die Migration erstellt Speicherorteinschränkungen, die erneut gelöscht werden müssen:

# Switch back to root and clean up the failed state
exit
hn1-db-0:~ # crm resource clear msl_SAPHana_<HANA SID>_HDB<instance number>

Darüber hinaus müssen Sie auch den Status der sekundären Knotenressource bereinigen:

hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

Überwachen Sie den Zustand der HANA-Ressource mithilfe von crm_mon -r. Wenn HANA auf hn1-db-0 gestartet wird, sieht die Ausgabe wie im folgenden Beispiel aus:

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Blockieren der Netzwerkkommunikation

Zustand der Ressource vor dem Starten des Tests:

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Führen Sie die Firewallregel aus, um die Kommunikation auf einem der Knoten zu blockieren.

# Execute iptable rule on hn1-db-1 (10.0.0.6) to block the incoming and outgoing traffic to hn1-db-0 (10.0.0.5)
iptables -A INPUT -s 10.0.0.5 -j DROP; iptables -A OUTPUT -d 10.0.0.5 -j DROP

Wenn Clusterknoten nicht miteinander kommunizieren können, besteht das Risiko eines Split-Brain-Szenarios. In solchen Situationen versuchen Clusterknoten, sich gleichzeitig zu umgrenzen, was zu einem Fence Race führt.

Beim Konfigurieren eines Fencinggeräts wird empfohlen, die pcmk_delay_max-Eigenschaft zu konfigurieren. Im Fall eines Split-Brain-Szenarios fügt der Cluster der Fencing-Aktion auf jedem Knoten also eine zufällige Verzögerung bis zum pcmk_delay_max-Wert hinzu. Der Knoten mit der kürzesten Verzögerung wird für das Fencing ausgewählt.

Um sicherzustellen, dass der Knoten, auf dem der HANA-Master ausgeführt wird, Vorrang hat und das Fence Race in einem Split-Brain-Szenario gewinnt, empfiehlt es sich, die priority-fencing-delay-Eigenschaft in der Clusterkonfiguration festzulegen. Durch Aktivieren der priority-fencing-delay-Eigenschaft kann der Cluster eine zusätzliche Verzögerung in der Fencing-Aktion speziell für den Knoten einführen, der die HANA-Masterressource hostet, sodass der Knoten das Fence Race gewinnen kann.

Führen Sie den folgenden Befehl aus, um die Firewallregel zu löschen.

# If the iptables rule set on the server gets reset after a reboot, the rules will be cleared out. In case they have not been reset, please proceed to remove the iptables rule using the following command.
iptables -D INPUT -s 10.0.0.5 -j DROP; iptables -D OUTPUT -d 10.0.0.5 -j DROP

Testen der SBD-Umgrenzung

Sie können das Setup von SBD testen, indem Sie den inquisitor-Prozess beenden:

hn1-db-0:~ # ps aux | grep sbd
root       1912  0.0  0.0  85420 11740 ?        SL   12:25   0:00 sbd: inquisitor
root       1929  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014056f268462316e4681b704a9f73 - slot: 0 - uuid: 7b862dba-e7f7-4800-92ed-f76a4e3978c8
root       1930  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014059bc9ea4e4bac4b18808299aaf - slot: 0 - uuid: 5813ee04-b75c-482e-805e-3b1e22ba16cd
root       1931  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-36001405b8dddd44eb3647908def6621c - slot: 0 - uuid: 986ed8f8-947d-4396-8aec-b933b75e904c
root       1932  0.0  0.0  90524 16656 ?        SL   12:25   0:00 sbd: watcher: Pacemaker
root       1933  0.0  0.0 102708 28260 ?        SL   12:25   0:00 sbd: watcher: Cluster
root      13877  0.0  0.0   9292  1572 pts/0    S+   12:27   0:00 grep sbd

hn1-db-0:~ # kill -9 1912

Der <HANA SID>-db-<database 1>-Clusterknoten wird neu gestartet. Der Pacemaker-Dienst wird möglicherweise nicht neu gestartet. Stellen Sie sicher, dass Sie ihn neu starten.

Testen eines manuellen Failovers

Sie können ein manuelles Failover durch Beenden des Pacemaker-Diensts auf Knoten hn1-db-0 testen:

service pacemaker stop

Nach dem Failover können Sie den Dienst erneut starten. Wenn Sie AUTOMATED_REGISTER="false" festlegen, wird die SAP HANA-Ressource auf dem Knoten hn1-db-0 nicht als sekundär gestartet.

In diesem Fall konfigurieren Sie die HANA-Instanz als sekundär, indem Sie diesen Befehl ausführen:

service pacemaker start
su - <hana sid>adm

# Stop the HANA instance, just in case it is running
sapcontrol -nr <instance number> -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1> 

# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

SUSE-Tests

Wichtig

Stellen Sie sicher, dass das von Ihnen ausgewählte Betriebssystem auf den spezifischen VM-Typen, die Sie verwenden, von SAP für SAP HANA zertifiziert wurde. Sie können für SAP HANA zertifizierte VM-Typen und deren Betriebssystemversionen unter Für SAP HANA zertifizierte IaaS-Plattformen nachschlagen. Überprüfen Sie die Details der VM-Typen, die Sie verwenden möchten, um die vollständige Liste der von SAP HANA unterstützten Betriebssystemreleases für den spezifischen VM-Typ zu erhalten.

Führen Sie abhängig von Ihrem Szenario alle Testfälle aus, die im Szenarioleitfaden zur leistungsoptimierten SAP HANA-Systemreplikation oder zur kostenoptimierten SAP HANA-Systemreplikation aufgeführt werden. Sie finden diese Leitfäden unter SLES for SAP – Best Practices.

Die folgenden Tests sind eine Kopie der Testbeschreibungen aus der Anleitung zum Szenario für die leistungsoptimierte SAP HANA-Systemreplikation unter SUSE Linux Enterprise Server for SAP Applications 12 SP1. Eine aktuelle Version finden Sie im Leitfaden selbst. Stellen Sie vor dem Starten von Tests stets sicher, dass HANA synchron und die Pacemaker-Konfiguration korrekt ist.

In den folgenden Testbeschreibungen wird von PREFER_SITE_TAKEOVER="true" und AUTOMATED_REGISTER="false" ausgegangen.

Hinweis

Die folgenden Tests sind so konzipiert, dass sie nacheinander ausgeführt werden. Jeder Test hängt vom Beendigungszustand des vorherigen Tests ab.

Test 1: Beenden der primären Datenbank auf Knoten 1

Ressourcenzustand vor dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Führen Sie die folgenden Befehle als „<HANA-SID>adm“ auf dem Knoten hn1-db-0 aus:

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB stop

Pacemaker erkennt die angehaltene HANA-Instanz und führt ein Failover zum anderen Knoten aus. Nach Abschluss des Failovers wird die HANA-Instanz auf dem Knoten hn1-db-0 angehalten, da Pacemaker den Knoten nicht automatisch als sekundären HANA-Knoten registriert.

Führen Sie die folgenden Befehle aus, um den Knoten hn1-db-0 als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen:

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

# run as root
hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

Ressourcenzustand nach dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Test 2: Beenden der primären Datenbank auf Knoten 2

Ressourcenzustand vor dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Führen Sie die folgenden Befehle als „<HANA-SID>adm“ auf dem Knoten hn1-db-1 aus:

hn1adm@hn1-db-1:/usr/sap/HN1/HDB01> HDB stop

Pacemaker erkennt die angehaltene HANA-Instanz und führt ein Failover zum anderen Knoten aus. Nach Abschluss des Failovers wird die HANA-Instanz auf dem Knoten hn1-db-1 angehalten, da Pacemaker den Knoten nicht automatisch als sekundären HANA-Knoten registriert.

Führen Sie die folgenden Befehle aus, um den Knoten hn1-db-1 als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen:

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1

Ressourcenzustand nach dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Test 3: Absturz der primären Datenbank auf Knoten 1

Ressourcenzustand vor dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Führen Sie die folgenden Befehle als „<HANA-SID>adm“ auf dem Knoten hn1-db-0 aus:

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> HDB kill-9

Pacemaker erkennt die beendete HANA-Instanz und führt ein Failover zum anderen Knoten aus. Nach Abschluss des Failovers wird die HANA-Instanz auf dem Knoten hn1-db-0 angehalten, da Pacemaker den Knoten nicht automatisch als sekundären HANA-Knoten registriert.

Führen Sie die folgenden Befehle aus, um den Knoten hn1-db-0 als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen:

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

# run as root
hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

Ressourcenzustand nach dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Test 4: Absturz der primären Datenbank auf Knoten 2

Ressourcenzustand vor dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Führen Sie die folgenden Befehle als „<HANA-SID>adm“ auf dem Knoten hn1-db-1 aus:

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9

Pacemaker erkennt die beendete HANA-Instanz und führt ein Failover zum anderen Knoten aus. Nach Abschluss des Failovers wird die HANA-Instanz auf dem Knoten hn1-db-1 angehalten, da Pacemaker den Knoten nicht automatisch als sekundären HANA-Knoten registriert.

Führen Sie die folgenden Befehle aus, um den Knoten hn1-db-1 als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen.

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1

Ressourcenzustand nach dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Test 5: Absturz des Knotens am primären Standort (Knoten 1)

Ressourcenzustand vor dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Führen Sie die folgenden Befehle als root auf dem Knoten hn1-db-0 aus:

hn1-db-0:~ #  echo 'b' > /proc/sysrq-trigger

Pacemaker erkennt den beendeten Clusterknoten und umgrenzt den Knoten. Nachdem der Knoten umgrenzt wurde, löst Pacemaker eine Übernahme der HANA-Instanz aus. Bei einem Neustart des umgrenzten Knotens wird Pacemaker nicht automatisch gestartet.

Führen Sie die folgenden Befehle aus, um Pacemaker zu starten, die SBD-Nachrichten für den Knoten hn1-db-0 zu bereinigen, den Knoten hn1-db-0 als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen:

# run as root
# list the SBD device(s)
hn1-db-0:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-0:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-0 clear

hn1-db-0:~ # systemctl start pacemaker

# run as <hana sid>adm
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

# run as root
hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

Ressourcenzustand nach dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Test 6: Absturz des Knotens am sekundären Standort (Knoten 2)

Ressourcenzustand vor dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Führen Sie die folgenden Befehle als root auf dem Knoten hn1-db-1 aus:

hn1-db-1:~ #  echo 'b' > /proc/sysrq-trigger

Führen Sie die folgenden Befehle aus, um Pacemaker zu starten, die SBD-Nachrichten für den Knoten hn1-db-1 zu bereinigen, den Knoten hn1-db-1 als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen:

# run as root
# list the SBD device(s)
hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear

hn1-db-1:~ # systemctl start pacemaker

# run as <hana sid>adm
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1

Ressourcenzustand nach dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
</code></pre>

Test 7: Beenden der sekundären Datenbank auf Knoten 2

Ressourcenzustand vor dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Führen Sie die folgenden Befehle als „<HANA-SID>adm“ auf dem Knoten hn1-db-1 aus:

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB stop

Pacemaker erkennt die angehaltene HANA-Instanz und kennzeichnet die Ressource auf dem Knoten hn1-db-1 als fehlerhaft. Pacemaker startet die HANA-Instanz automatisch neu.

Führen Sie zum Bereinigen des fehlerhaften Zustands den folgenden Befehl aus:

# run as root
hn1-db-1>:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1

Ressourcenzustand nach dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Test 8: Absturz der sekundären Datenbank auf Knoten 2

Ressourcenzustand vor dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Führen Sie die folgenden Befehle als „<HANA-SID>adm“ auf dem Knoten hn1-db-1 aus:

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> HDB kill-9

Pacemaker erkennt die beendete HANA-Instanz und kennzeichnet die Ressource auf dem Knoten hn1-db-1 als fehlerhaft. Führen Sie zum Bereinigen des fehlerhaften Zustands den folgenden Befehl aus: Pacemaker startet die HANA-Instanz anschließend automatisch neu.

# run as root
hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> HN1-db-1

Ressourcenzustand nach dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Test 9: Absturz des Knotens am sekundären Standort (Knoten 2), auf dem die sekundäre HANA-Datenbank ausgeführt wird

Ressourcenzustand vor dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Führen Sie die folgenden Befehle als root auf dem Knoten hn1-db-1 aus:

hn1-db-1:~ # echo b > /proc/sysrq-trigger

Pacemaker erkennt den beendeten Clusterknoten und umgrenzt den Knoten. Bei einem Neustart des umgrenzten Knotens wird Pacemaker nicht automatisch gestartet.

Führen Sie die folgenden Befehle aus, um Pacemaker zu starten und die SBD-Nachrichten für den Knoten hn1-db-1 sowie die fehlerhafte Ressource zu bereinigen:

# run as root
# list the SBD device(s)
hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear

hn1-db-1:~ # systemctl start pacemaker  

hn1-db-1:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-1

Ressourcenzustand nach dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Test 10: Absturz des Indexservers für die primäre Datenbank

Dieser Test ist nur dann relevant, wenn Sie den susChkSrv-Hook wie in Implementieren der HANA-Hooks SAPHanaSR und susChkSrv eingerichtet haben.

Ressourcenzustand vor dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-0 ]
   Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Führen Sie die folgenden Befehle als root auf dem Knoten hn1-db-0 aus:

hn1-db-0:~ # killall -9 hdbindexserver

Wenn der Indexserver beendet wird, erkennt der susChkSrv-Hook dieses Ereignis, löst eine Aktion zum Umgrenzen des Knotens „hn1-db-0“ aus und initiiert einen Übernahmevorgang.

Führen Sie die folgenden Befehle aus, um den Knoten hn1-db-0 als sekundär zu registrieren und die fehlerhafte Ressource zu bereinigen:

# run as <hana sid>adm
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

# run as root
hn1-db-0:~ # crm resource cleanup msl_SAPHana_<HANA SID>_HDB<instance number> hn1-db-0

Ressourcenzustand nach dem Test:

Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
   Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
   Masters: [ hn1-db-1 ]
   Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_HDB03
   rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
   rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1

Sie können einen vergleichbaren Testfall ausführen, indem Sie den Indexserver auf dem sekundären Knoten zum Absturz bringen. Bei einem Absturz des Indexservers erkennt der susChkSrv-Hook dies und initiiert eine Aktion, um den sekundären Knoten zu umgrenzen.

Hochverfügbarkeit für SAP HANA auf Azure-VMs mit SUSE Linux Enterprise Server

Planen von Hochverfügbarkeit für SAP HANA

Vorbereiten der Infrastruktur

Manuelles Bereitstellen von Linux-VMs über das Azure-Portal

Konfigurieren von Azure Load Balancer

Erstellen eines Pacemaker-Clusters

Installieren von SAP HANA

Konfigurieren Sie die SAP HANA 2.0 Systemreplikation

Konfigurieren der SAP HANA 1.0-Systemreplikation

Implementieren der HANA-Hooks SAPHanaSR und susChkSrv

Erstellen von SAP HANA-Clusterressourcen

Konfigurieren der HANA-Systemreplikation im Modus „Aktiv/Lesezugriff“ in einem Pacemaker-Cluster

Einrichten des Lastenausgleichs für die Systemreplikation im Modus „Aktiv/Lesezugriff“

Einrichten der HANA-Systemreplikation im Modus „Aktiv/Lesezugriff“

Hinzufügen einer sekundären virtuellen IP-Adressressource

Testen der Clustereinrichtung

Testen der Migration

Blockieren der Netzwerkkommunikation

Testen der SBD-Umgrenzung

Testen eines manuellen Failovers

SUSE-Tests

Nächste Schritte

Zusätzliche Ressourcen