Hochverfügbarkeit von SAP HANA Scale-up mit Azure NetApp Files auf RHEL

In diesem Artikel erfahren Sie, wie Sie die SAP HANA-Systemreplikation in einer Bereitstellung mit Hochskalierung mithilfe von Azure NetApp Files konfigurieren, wenn die HANA-Dateisysteme über NFS eingebunden sind. In den Beispielkonfigurationen und Installationsbefehlen werden die Instanznummer 03 und die HANA-System-ID HN1 verwendet. Die SAP HANA-Systemreplikation umfasst einen primären Knoten und mindestens einen sekundären Knoten.

Einige Schritte in diesem Dokument sind mit Präfixen gekennzeichnet. Diese bedeuten Folgendes:

• [A] : Der Schritt gilt für alle Knoten.
• [1] : Der Schritt gilt nur für Knoten 1.
• [2] : Der Schritt gilt nur für Knoten 2.

Voraussetzungen

Lesen Sie zuerst die folgenden SAP-Hinweise und -Dokumente:

• SAP-Hinweis 1928533 mit folgenden Informationen:
  • 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 Kombinationen von SAP-Software, Betriebssystem und Datenbank.
  • Erforderliche SAP-Kernelversion 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.
• Im SAP-Hinweis 405827 sind empfohlene Dateisysteme für HANA-Umgebungen aufgeführt.
• SAP-Hinweis 2002167 enthält empfohlene Betriebssystemeinstellungen für Red Hat Enterprise Linux.
• SAP-Hinweis 2009879 enthält SAP HANA-Richtlinien für Red Hat Enterprise Linux.
• Der SAP-Hinweis 3108302 enthält SAP HANA-Leitfäden für Red Hat Enterprise Linux 9.x.
• 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 1999351 enthält Informationen zur Problembehandlung für die Azure Enhanced Monitoring-Erweiterung für SAP.
• Das SAP-Community-Wiki 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
• SAP HANA-Systemreplikation im Pacemaker-Cluster
• RHEL HA-Dokumentation:
  • Konfigurieren und Verwalten von Clustern mit Hochverfügbarkeit
  • Supportrichtlinien für RHEL High Availability Cluster – Verwaltung von SAP HANA in einem Cluster
  • Klassisch: Automatisierung der SAP-HANA-Scale-Up-Systemreplikation mithilfe des RHEL HA Add-on
  • Neue Generation – angi: Bereitstellung der SAP HANA-Scale-Up-Systemreplikation mit dem angi-Ressourcen-Agent
  • Konfigurieren der SAP HANA-Systemreplikation mit „Hochskalieren“ in einem Pacemaker-Cluster, wenn sich die HANA-Dateisysteme auf NFS-Freigaben befinden
• Azure-spezifische RHEL-Dokumentation:
  • Unterstützungsrichtlinien für RHEL-Hochverfügbarkeitscluster – Virtuelle Microsoft Azure-Computer als Clustermitglieder
  • Installieren und Konfigurieren eines Red Hat Enterprise Linux 7.4-Hochverfügbarkeitclusters (und höher) in Microsoft Azure
  • Bereitstellen von RHEL auf Azure
• NFS v4.1-Volumes auf Azure NetApp Files für SAP HANA

Übersicht

In einer Hochskalierungsumgebung werden üblicherweise alle Dateisysteme für SAP HANA aus dem lokalen Speicher eingebunden. Informationen zum Einrichten der Hochverfügbarkeit (High Availability, HA) der SAP HANA-Systemreplikation unter Red Hat Enterprise Linux finden Sie unter Einrichten der SAP HANA-Systemreplikation unter RHEL.

Um SAP HANA-Hochverfügbarkeit eines Systems mit Hochskalierung auf Azure NetApp Files-NFS-Freigaben zu erreichen, sind einige weitere Ressourcenkonfigurationen im Cluster erforderlich, damit HANA-Ressourcen wiederhergestellt werden können, wenn der Zugriff eines Knotens auf die NFS-Freigaben in Azure NetApp Files unterbrochen wird. Der Cluster verwaltet die NFS-Bereitstellungen und kann daher die Integrität der Ressourcen überwachen. Zwischen den Dateisystembereitstellungen und den SAP HANA-Ressourcen werden Abhängigkeiten erzwungen.

SAP HANA-Dateisysteme werden mithilfe von Azure NetApp Files auf NFS-Freigaben auf den einzelnen Knoten eingebunden. Die Dateisysteme /hana/data, /hana/log und /hana/shared sind für jeden Knoten eindeutig.

Eingebunden auf „node1“ (hanadb1):

• 10.32.2.4:/hanadb1-data-mnt00001 in /hana/data
• 10.32.2.4:/hanadb1-log-mnt00001 in /hana/log
• 10.32.2.4:/hanadb1-shared-mnt00001 in /hana/shared

Eingebunden auf „node2“ (hanadb2):

• 10.32.2.4:/hanadb2-data-mnt00001 in /hana/data
• 10.32.2.4:/hanadb2-log-mnt00001 in /hana/log
• 10.32.2.4:/hanadb2-shared-mnt00001 in /hana/shared

Die Konfiguration der SAP HANA-Systemreplikation verwendet einen dedizierten virtuellen Hostnamen und virtuelle IP-Adressen. Für die Verwendung einer virtuellen IP-Adresse ist in Azure ein Lastenausgleich erforderlich. Die hier dargestellte Konfiguration umfasst einen Lastenausgleich mit:

• Front-End-IP-Adresse: 10.32.0.10 für hn1-db
• Testport: 62503

Einrichten der Infrastruktur für Azure NetApp Files

Bevor Sie mit der Einrichtung der Azure NetApp Files-Infrastruktur beginnen, sollten Sie sich mit der Azure NetApp Files-Dokumentation vertraut machen.

Azure NetApp Files ist in verschiedenen Azure-Regionen verfügbar. Überprüfen Sie, ob Azure NetApp Files in Ihrer ausgewählten Azure-Region angeboten wird.

Informationen zur Verfügbarkeit von Azure NetApp Files in den einzelnen Azure-Regionen finden Sie unter Verfügbarkeit von Azure NetApp Files nach Azure-Region.

Wichtige Hinweise

Beachten Sie beim Erstellen Ihrer Azure NetApp Files-Volumes für SAP HANA-Hochskalierungssysteme die wichtigen Überlegungen unter NFS v4.1-Volumes unter Azure NetApp Files für SAP HANA.

Dimensionierung einer HANA-Datenbank in Azure NetApp Files

Der Durchsatz eines Azure NetApp Files-Volumes ist eine Funktion der Volumegröße und der Dienstebene, wie in Dienstebenen für Azure NetApp Files beschrieben.

Beachten Sie beim Entwerfen der Infrastruktur für SAP HANA in Azure mit Azure NetApp Files die Empfehlungen unter NFS v4.1-Volumes unter Azure NetApp Files für SAP HANA.

Für die Konfiguration in diesem Artikel werden einfache Azure NetApp Files-Volumes verwendet.

Bereitstellen von Azure NetApp Files-Ressourcen

In der folgenden Anleitung wird davon ausgegangen, dass Sie Ihr virtuelles Azure-Netzwerk bereits bereitgestellt haben. Sie müssen die Azure-NetApp-Files-Ressourcen und die VMs, auf denen die Azure-NetApp-Files-Ressourcen eingebunden sind, im selben virtuellen Azure-Netzwerk oder in gepeerten virtuellen Azure-Netzwerken bereitstellen.

1. Erstellen Sie entsprechend den Anweisungen in Erstellen eines NetApp-Kontos ein NetApp-Konto in der ausgewählten Azure-Region.

2. Richten Sie entsprechend den Anweisungen in Einrichten eines Kapazitätspools einen Azure NetApp Files-Kapazitätspool ein.

   Die in diesem Artikel gezeigte HANA-Architektur verwendet einen einzigen Azure NetApp Files-Kapazitätspool auf der Dienstebene Ultra. Für HANA-Workloads auf Azure empfehlen wir die Verwendung Azure NetApp Files Ultra oder PremiumService Level.

3. Delegieren Sie ein Subnetz an Azure NetApp Files, wie in den Anweisungen in Delegieren eines Subnetzes an Azure NetApp Files beschrieben.

4. Stellen Sie Azure NetApp Files-Volumes entsprechend den Anweisungen in Erstellen eines NFS-Volumes für Azure NetApp Files bereit.

   Stellen Sie beim Bereitstellen der Volumes sicher, dass Sie die Version NFSv4.1 auswählen. Stellen Sie die Volumes im festgelegten Subnetz für Azure NetApp Files bereit. Die IP-Adressen der Azure NetApp-Volumes werden automatisch zugewiesen.

   Denken Sie daran, dass sich die Azure NetApp Files-Ressourcen und die virtuellen Azure-Computer im gleichen virtuellen Azure-Netzwerk oder in mittels Peering verknüpften virtuellen Azure-Netzwerken befinden müssen. Beispielsweise sind hanadb1-data-mnt00001 und hanadb1-log-mnt00001 die Volumenamen und nfs://10.32.2.4/hanadb1-data-mnt00001 und nfs://10.32.2.4/hanadb1-log-mnt00001 die Dateipfade für die Azure NetApp Files-Volumes.

   Auf hanadb1:

   • Volume „hanadb1-data-mnt00001“ (nfs://10.32.2.4:/hanadb1-data-mnt00001)
   • Volume „hanadb1-log-mnt00001“ (nfs://10.32.2.4:/hanadb1-log-mnt00001)
   • Volume „hanadb1-shared-mnt00001“ (nfs://10.32.2.4:/hanadb1-shared-mnt00001)

   Auf hanadb2:

   • Volume „hanadb2-data-mnt00001“ (nfs://10.32.2.4:/hanadb2-data-mnt00001)
   • Volume „hanadb2-log-mnt00001“ (nfs://10.32.2.4:/hanadb2-log-mnt00001)
   • Volume „hanadb2-shared-mnt00001“ (nfs://10.32.2.4:/hanadb2-shared-mnt00001)

Vorbereiten der Infrastruktur

Im Azure Marketplace finden Sie Images, die für SAP HANA mit dem Add-On für Hochverfügbarkeit qualifiziert sind und Ihnen das Bereitstellen neuer VMs mithilfe verschiedener Versionen von Red Hat ermöglichen.

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

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

Stellen Sie VMs für SAP HANA bereit. Wählen Sie ein geeignetes RHEL-Image aus, das für das HANA-System unterstützt wird. Sie können eine VM mit einer der folgenden Verfügbarkeitsoptionen bereitstellen: Skalierungsgruppe, Verfügbarkeitszone oder Verfügbarkeitsgruppe.

Konfigurieren von Azure Load Balancer

Während der VM-Konfiguration können Sie einen vorhandenen Lastenausgleich im Netzwerkabschnitt erstellen oder auswählen. Führen Sie die Schritte in den folgenden Abschnitten aus, um einen Standardmäßigen Lastenausgleich für eine Hochverfügbarkeitseinrichtung der HANA-Datenbank einzurichten.

# 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

# 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

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

Einbinden des Azure NetApp Files-Volumes

1. [A] Erstellen Sie Bereitstellungspunkte für die HANA-Datenbankvolumes.

   sudo mkdir -p /hana/data
   sudo mkdir -p /hana/log
   sudo mkdir -p /hana/shared
   

2. [A] Ü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.

   sudo cat /etc/idmapd.conf
   

   Beispielausgabe:

   [General]
   Domain = defaultv4iddomain.com
   [Mapping]
   Nobody-User = nobody
   Nobody-Group = nobody
   

   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. Im Fall eines Konflikts zwischen der Domänenkonfiguration auf dem NFS-Client (also der VM) und dem NFS-Server (also der Azure NetApp Files-Konfiguration) werden die Berechtigungen für Dateien auf Azure NetApp Files-Volumes, die auf den VMs eingebunden sind, als nobody angezeigt.

3. [1] Binden Sie die knotenspezifischen Volumes auf „node1“ ein (hanadb1).

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-log-mnt00001 /hana/log
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-data-mnt00001 /hana/data
   

4. [2] Binden Sie die knotenspezifischen Volumes auf „node2“ ein (hanadb2).

   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-shared-mnt00001 /hana/shared
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-log-mnt00001 /hana/log
   sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-data-mnt00001 /hana/data
   

5. [A] Überprüfen Sie, ob alle HANA-Volumes mit der NFS-Protokollversion „NFSv4“ eingebunden wurden.

   sudo nfsstat -m
   

   Vergewissern Sie sich, dass das Flag vers auf 4.1 festgelegt ist. Beispiel aus „hanadb1“:

   /hana/log from 10.32.2.4:/hanadb1-log-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
   /hana/data from 10.32.2.4:/hanadb1-data-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
   /hana/shared from 10.32.2.4:/hanadb1-shared-mnt00001
   Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
   

6. [A] Überprüfen Sie nfs4_disable_idmapping. Diese Angabe sollte auf Y (Ja) festgelegt sein. Führen Sie den Einbindungsbefehl aus, um die Verzeichnisstruktur zu erstellen, in der sich nfs4_disable_idmapping befindet. Sie können das Verzeichnis unter /sys/modules nicht manuell erstellen, da der Zugriff für den Kernel und Treiber reserviert ist.

   Überprüfen Sie nfs4_disable_idmapping.

   sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping
   

   Wenn Sie nfs4_disable_idmapping festlegen müssen:

   sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
   

   Legen Sie die Konfiguration als dauerhaft fest.

   sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
   

   Weitere Informationen zum Ändern des Parameters nfs_disable_idmapping finden Sie in der Red Hat-Wissensdatenbank.

SAP HANA-Installation

1. [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 gezeigt. Ersetzen Sie die IP-Adresse und den Hostnamen in den folgenden Befehlen:

   sudo vi /etc/hosts
   

   Fügen Sie in der Datei /etc/hosts die folgenden Zeilen ein. Ändern Sie die IP-Adresse und den Hostnamen Ihrer Umgebung entsprechend.

   10.32.0.4   hanadb1
   10.32.0.5   hanadb2
   

2. [A] Bereiten Sie das Betriebssystem wie im SAP-Hinweis 3024346 – Linux-Kerneleinstellungen für NetApp NFS beschrieben für die Ausführung von SAP HANA in Azure NetApp mit NFS vor. Erstellen Sie die Konfigurationsdatei /etc/sysctl.d/91-NetApp-HANA.conf für die NetApp-Konfigurationseinstellungen.

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

   Fügen Sie in der Konfigurationsdatei die folgenden Einträge hinzu.

   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
   

3. [A] Erstellen Sie die Konfigurationsdatei /etc/sysctl.d/ms-az.conf mit weiteren Optimierungseinstellungen.

   sudo vi /etc/sysctl.d/ms-az.conf
   

   Fügen Sie in der Konfigurationsdatei die folgenden Einträge hinzu.

   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 in den sysctl-Konfigurationsdateien nicht explizit fest, damit der SAP-Host-Agent die Portbereiche verwalten kann. Weitere Informationen finden Sie im SAP-Hinweis 2382421.

4. [A] Passen Sie die sunrpc-Einstellungen wie im SAP-Hinweis 3024346 – Linux-Kerneleinstellungen für NetApp NFS empfohlen an.

   sudo vi /etc/modprobe.d/sunrpc.conf
   

   Fügen Sie die folgende Zeile ein:

   options sunrpc tcp_max_slot_table_entries=128
   

5. [A] Führen Sie die RHEL-Betriebssystemkonfiguration für HANA durch.

   Konfigurieren Sie je nach RHEL-Version das Betriebssystem wie in den folgenden SAP-Hinweisen beschrieben:

   • 2777782 – SAP HANA DB: Empfohlene Betriebssystemeinstellungen für RHEL 8
   • 3108302 - SAP HANA DB: Empfohlene Betriebssystemeinstellungen für RHEL 9
   • 3562919 - SAP HANA DB: Empfohlene Betriebssystemeinstellungen für RHEL 10
   • 3057467 – Welches compat-sap-c++-Paket benötige ich für SAP auf RHEL?

6. [A] Installieren Sie SAP HANA nach der Dokumentation von SAP.

7. [A] Konfigurieren Sie eine Firewall.

   Erstellen Sie die Firewallregel für den Testport von Azure Load Balancer.

   sudo firewall-cmd --zone=public --add-port=62503/tcp
   sudo firewall-cmd --zone=public --add-port=62503/tcp –permanent
   

Konfigurieren der SAP HANA-Systemreplikation

Führen Sie die Schritte zum Einrichten der SAP HANA-Systemreplikation aus, um die SAP HANA-Systemreplikation zu konfigurieren.

Clusterkonfiguration

In diesem Abschnitt werden die Schritte beschrieben, die für einen reibungslosen Clusterbetrieb erforderlich sind, wenn SAP HANA unter Verwendung von Azure NetApp Files auf NFS-Freigaben installiert wird.

Erstellen eines Pacemaker-Clusters

Führen Sie die Schritte in "Pacemaker auf Red Hat Enterprise Linux einrichten " aus, um einen grundlegenden Pacemaker-Cluster für diesen HANA-Server zu erstellen.

Implementierung von SAP HANA-Systemreplikations-Hooks

Red Hat bietet zwei Generationen von Ressourcen-Agents für die Konfiguration eines HANA-Systemreplikations-HA-Clusters auf RHEL. Da sich die Konfigurationsverfahren unterscheiden, teilt dieses Dokument sie basierend auf der Ressourcen-Agent-Generierung in separate Registerkarten auf:

• Registerkarte „Classic“: Behandelt die klassische Generation von Ressourcenagents, die im Paket „resource-agents-SAP HANA“ (Scale-Up) bereitgestellt werden.
• Registerkarte "Neue Generation": Deckt die neue Generation von Ressourcenagenten ab, die im Paket "sap-hana-ha" bereitgestellt werden. Im Upstream wird diese Generation als "SAPHanaSR-angi" bezeichnet.

Die klassischen und neuen Generation-Pakete schließen sich gegenseitig aus. Sie können jeweils nur ein Paket auf Ihrem System konfigurieren. Konfigurieren Sie den SAPHanaSR/HanaSR- und den ChkSrv-Python-Hook. Führen Sie die Schritte unter Implementieren des Python Systemreplikations-Hooks SAPHanaSR/HanaSR und ChkSrv aus, und verwenden Sie die entsprechende Registerkarte für Ihre spezifische Konfiguration.

Dateisystem verwalten

Für SAP HANA Scale-up auf Azure NetApp Files NFS-Freigaben verwendet Red Hat je nach Softwarepaket unterschiedliche Ansätze. Mit dem Ressourcen-Agent-Paket der neuen Generation definieren Sie stattdessen die Einbindung in /etc/fstab, und der Ressourcen-Agent SAPHanaFilesystem überwacht das Dateisystem und erkennt Probleme, bevor SAPHanaController sie erkennt. Im Gegensatz dazu nutzt das klassische Ressourcenagentenpaket Pacemaker-Dateisystemclusterressourcen zur Verwaltung von NFS-Freigaben.

Befolgen Sie im nachfolgenden Abschnitt den entsprechenden Schritt, je nachdem, ob Sie HANA Scale-Up auf Azure NetApp Files mit Resource-Agents der neuen Generation oder mit klassischen Resource-Agents konfigurieren.

Konfigurieren von SAP HANA-Clusterressourcen

1. Folgen Sie der entsprechenden Registerkarte in "Erstellen SAP HANA Clusterressourcen", um die SAP HANA Ressourcen im Cluster zu erstellen.

2. Führen Sie nach dem Erstellen der SAP HANA Ressourcen die zusätzlichen Schritte aus. Wählen Sie die entsprechenden Registerkarten basierend auf Ihrer Konfiguration aus.

   • Neue Generation
   • Klassisch

   Das Paket der nächsten Generation führt einen neuen Ressourcenagenten ein, SAPHanaFilesystem, der Lese- und Schreibzugriffe auf den Pfad /hana/shared/SID überwacht. Das Dateisystem wird auf Betriebssystemebene statisch eingehängt, wobei jeder Host über /etc/fstab konfiguriert wird. Weder SAPHanaFilesystem noch Pacemaker sind für das Einhängen dieses Dateisystems für HANA verantwortlich.

   1. [1] Für die SAP HANA-Skalierung auf Azure NetApp Files NFS-Freigaben konfigurieren Sie den Ressourcen-Agent SAPHanaFileSystem.

      sudo pcs resource create rsc_SAPHanaFilesystem_HN1_HDB03 \
          ocf:heartbeat:SAPHanaFilesystem \
          SID=HN1 \
          InstanceNumber=03 \
          ON_FAIL_ACTION="fence" \
          op start interval=0 timeout=10 \
          op stop interval=0 timeout=20 \
          op monitor interval=120 timeout=120 \
          clone cln_SAPHanaFilesystem_HN1_HDB03 \
          meta clone-node-max=1 interleave=true --future
      

3. Überprüfen Sie den Status des Clusters und sämtlicher Ressourcen.

   Hinweis

   In diesem Artikel wird ein Begriff verwendet, der von Microsoft nicht mehr genutzt wird. Sobald der Begriff aus der Software entfernt wurde, wird er auch aus diesem Artikel entfernt.

   • Neue Generation
   • Klassisch

   sudo pcs status
   

   Beispielausgabe:

   Node List:
   * Online: [ hanadb1 hanadb2 ]
   
   Full List of Resources:
   * rsc_hdb_azr_agt        (stonith:fence_azure_arm):       Started hanadb1
   * Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
       * Started: [ hanadb1 hanadb2 ]
   * Clone Set: cln_SAPHanaController_HN1_HDB03 [rsc_SAPHanaController_HN1_HDB03] (promotable):
       * Promoted: [ hanadb1 ]
       * Unpromoted: [ hanadb2 ]
   * Clone Set: cln_SAPHanaFilesystem_HN1_HDB03 [rsc_SAPHanaFilesystem_HN1_HDB03]:
       * Started: [ hanadb1 hanadb2 ]
   * Resource Group: g_ip_HN1_03:
       * nc_HN1_03         (ocf:heartbeat:azure-lb):        Started hanadb1
       * vip_HN1_03        (ocf:heartbeat:IPaddr2):         Started hanadb2
   

Einrichten der HANA-Systemreplikation im aktiv/lesefähigen Modus in einem Pacemaker-Cluster

Mit SAP HANA 2.0 SPS 01 unterstützt SAP aktive und lesefähige Setups für die SAP HANA Systemreplikation. In diesen Setups können Sie die sekundären Systeme von SAP HANA Systemreplikation aktiv für Workloads verwenden, die viel Lesen erfordern. Um dieses Setup in einem Cluster zu unterstützen, benötigen Sie eine zweite virtuelle IP-Adresse. Diese IP-Adresse gewährt Clients Zugriff auf die sekundäre lesefähige SAP HANA-Datenbank.

Um sicherzustellen, dass der sekundäre Replikationsstandort auch nach einer Übernahme noch erreichbar ist, muss der Cluster die virtuelle IP-Adresse mit der sekundären der SAPHana-Ressource umziehen.

Informationen zu der zusätzlichen Konfiguration, die erforderlich ist, um die HANA-Systemreplikation im Modus „Aktiv/Lesezugriff“ in einem Red Hat-Hochverfügbarkeitscluster mit einer zweiten virtuellen IP-Adresse zu verwalten, finden Sie unter Konfigurieren der HANA-Systemreplikation im Modus „Aktiv/Lesezugriff“ in einem Pacemaker-Cluster.

Bevor Sie fortfahren, stellen Sie sicher, dass Sie den Red Hat-Hochverfügbarkeitscluster, der die SAP HANA-Datenbank verwaltet, wie in den obigen Abschnitten der Dokumentation beschrieben, vollständig konfiguriert haben.

Testen des Cluster-Setups

In diesem Abschnitt wird beschrieben, wie Sie Ihre Einrichtung testen können.

1. Stellen Sie vor dem Starten eines Tests sicher, dass Pacemaker keine fehlerhaften Aktionen enthält (mit „pcs status“), dass keine unerwarteten Speicherorteinschränkungen bestehen (z. B. durch zurückgebliebene Elemente eines Migrationstests) und dass die HANA-Systemreplikation synchronisiert ist (z. B. mit systemReplicationStatus).

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

2. Ü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 diesem Szenario über NFS eingebunden.

   Es ist schwierig, einen Fehler zu simulieren, bei dem einer der Server den Zugriff auf die NFS-Freigabe verliert. Zum Testen können Sie das Dateisystem als schreibgeschütztes Dateisystem erneut einbinden. Auf diese Weise lässt sich überprüfen, ob der Cluster ein Failover ausführen kann, wenn der Zugriff auf /hana/shared auf dem aktiven Knoten verloren geht.

   Erwartetes Ergebnis: Wenn Sie ein schreibgeschütztes Dateisystem erstellen /hana/shared , schlagen die Lese-/Schreibvorgänge im Dateisystem fehl, was zu einem Failover führt. Dasselbe Ergebnis ist zu erwarten, wenn der HANA-Knoten den Zugriff auf die NFS-Freigaben verliert.

   Überprüfen Sie den Ressourcenstatus, bevor Sie den Test starten:

   sudo pcs status
   

   Sie können /hana/shared mithilfe des folgenden Befehls auf dem aktiven Clusterknoten in den schreibgeschützten Modus versetzen:

   sudo mount -o ro 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
   

   hanadb wird je nach Aktion, die für stonith festgelegt ist (pcs property show stonith-action), entweder neu gestartet oder abgeschaltet. Wenn der Server (hanadb1) nicht mehr verfügbar ist, wechselt die HANA-Ressource zu hanadb2. Sie können den Status des Clusters über hanadb2 überprüfen.

   sudo pcs status
   

   Es wird empfohlen, die SAP HANA-Clusterkonfiguration gründlich zu testen, indem Sie auch die unter Einrichten der SAP HANA-Systemreplikation unter RHEL beschriebenen Tests ausführen.

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 auf Azure NetApp Files für SAP HANA