Hög tillgänglighet för SAP HANA på virtuella Azure-datorer på Red Hat Enterprise Linux

För lokal utveckling kan du använda ANTINGEN HANA-systemreplikering eller delad lagring för att upprätta hög tillgänglighet (HA) för SAP HANA. På Azure Virtual Machines är HANA System Replication på Azure för närvarande den enda ha-funktionen som stöds.

SAP HANA-replikering består av en primär nod och minst en sekundär nod. Ändringar av data på den primära noden replikeras till den sekundära noden synkront eller asynkront.

Den här artikeln beskriver hur du distribuerar och konfigurerar virtuella datorer , installerar klusterramverket och installerar och konfigurerar SAP HANA-systemreplikering.

I exempelkonfigurationerna används installationskommandon, instansnummer 03 och HANA System ID HN1 .

Förutsättningar

Läs följande SAP-anteckningar och dokument först:

• SAP Note 1928533, som har:
  • Listan över storlekar på virtuella Azure-datorer som stöds för distribution av SAP-programvara.
  • Viktig kapacitetsinformation för vm-storlekar i Azure.
  • Sap-programvara och operativsystem (OS) och databaskombinationer som stöds.
  • Den nödvändiga SAP-kernelversionen för Windows och Linux på Microsoft Azure.
• SAP Note 2015553 listar krav för SAP-programdistributioner som stöds i Azure.
• SAP Obs 2002167 har rekommenderade operativsysteminställningar för Red Hat Enterprise Linux.
• SAP Note 2009879 har SAP HANA-riktlinjer för Red Hat Enterprise Linux.
• SAP Note 3108302 har SAP HANA-riktlinjer för Red Hat Enterprise Linux 9.x.
• SAP Note 2178632 innehåller detaljerad information om alla övervakningsmått som rapporterats för SAP i Azure.
• SAP Note 2191498 har den sap-värdagentversion som krävs för Linux i Azure.
• SAP Note 2243692 har information om SAP-licensiering på Linux i Azure.
• SAP Note 1999351 innehåller mer felsökningsinformation för Azure Enhanced Monitoring Extension för SAP.
• SAP Community WIKI har alla nödvändiga SAP-anteckningar för Linux.
• Planering och implementering av Azure Virtual Machines för SAP i Linux
• Azure Virtual Machines-distribution för SAP på Linux (den här artikeln)
• Azure Virtual Machines DBMS-distribution för SAP på Linux
• SAP HANA-systemreplikering i ett Pacemaker-kluster
• Allmän RHEL-dokumentation:
  • Översikt över tillägg med hög tillgänglighet
  • Tilläggsadministration med hög tillgänglighet
  • Referens för tillägg med hög tillgänglighet
  • HANA Scale-Up System Replication med RHEL HA-tillägg
• Azure-specifik RHEL-dokumentation:
  • Supportprinciper för RHEL-kluster med hög tillgänglighet – Microsoft Azure Virtual Machines som klustermedlemmar
  • Installera och konfigurera ett Red Hat Enterprise Linux 7.4-kluster (och senare) med hög tillgänglighet i Microsoft Azure
  • Installera SAP HANA på Red Hat Enterprise Linux för användning i Microsoft Azure

Översikt

För att uppnå HA installeras SAP HANA på två virtuella datorer. Data replikeras med hjälp av HANA-systemreplikering.

Konfigurationen av SAP HANA-systemreplikering använder ett dedikerat virtuellt värdnamn och virtuella IP-adresser. I Azure krävs en lastbalanserare för att använda en virtuell IP-adress. Den presenterade konfigurationen visar en lastbalanserare med:

• Klientdels-IP-adress: 10.0.0.13 för hn1-db
• Avsökningsport: 62503

Förbered infrastrukturen

Azure Marketplace innehåller avbildningar som är kvalificerade för SAP HANA med tillägget Hög tillgänglighet, som du kan använda för att distribuera nya virtuella datorer med hjälp av olika versioner av Red Hat.

Distribuera virtuella Linux-datorer manuellt via Azure Portal

Det här dokumentet förutsätter att du redan har distribuerat en resursgrupp, ett virtuellt Azure-nätverk och ett undernät.

Distribuera virtuella datorer för SAP HANA. Välj en lämplig RHEL-avbildning som stöds för HANA-systemet. Du kan distribuera en virtuell dator i något av tillgänglighetsalternativen: VM-skalningsuppsättning, tillgänglighetszon eller tillgänglighetsuppsättning.

Konfigurera Azure-lastbalanserare

Under konfigurationen av den virtuella datorn kan du skapa eller välja att avsluta lastbalanseraren i nätverksavsnittet. Följ stegen nedan för att konfigurera standardlastbalanserare för installation av HANA-databas med hög tillgänglighet.

# 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

Mer information om de portar som krävs för SAP HANA finns i kapitlet Anslutningar till klientdatabaser i guiden FÖR SAP HANA-klientdatabaser eller SAP Note 2388694.

Installera SAP HANA

Stegen i det här avsnittet använder följande prefix:

• [A]: Steget gäller för alla noder.
• [1]: Steget gäller endast för nod 1.
• [2]: Steget gäller endast för nod 2 i Pacemaker-klustret.

1. [A] Konfigurera disklayouten: Logical Volume Manager (LVM).

   Vi rekommenderar att du använder LVM för volymer som lagrar data och loggfiler. I följande exempel förutsätts att de virtuella datorerna har fyra anslutna datadiskar som används för att skapa två volymer.

   Visa en lista över alla tillgängliga diskar:

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

   Exempel på utdata>

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

   Skapa fysiska volymer för alla diskar som du vill använda:

   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
   

   Skapa en volymgrupp för datafilerna. Använd en volymgrupp för loggfilerna och en för den delade katalogen för SAP HANA:

   sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
   sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
   sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3
   

   Skapa de logiska volymerna. En linjär volym skapas när du använder lvcreate utan växeln -i . Vi rekommenderar att du skapar en randig volym för bättre I/O-prestanda. Justera randstorlekarna efter de värden som dokumenteras i SAP HANA VM-lagringskonfigurationer. Argumentet -i ska vara antalet underliggande fysiska volymer och -I argumentet är randstorleken.

   I det här dokumentet används två fysiska volymer för datavolymen, så växelargumentet -i är inställt på 2. Randstorleken för datavolymen är 256KiB. En fysisk volym används för loggvolymen, så inga -i eller -I växlar används uttryckligen för loggvolymkommandona.

   Viktigt!

   Använd växeln -i och ange den till antalet underliggande fysiska volymer när du använder mer än en fysisk volym för varje data, logg eller delade volymer. Använd växeln -I för att ange randstorleken när du skapar en randig volym. Se SAP HANA VM-lagringskonfigurationer för rekommenderade lagringskonfigurationer, inklusive randstorlekar och antal diskar. Följande layoutexempel uppfyller inte nödvändigtvis prestandariktlinjerna för en viss systemstorlek. De är bara för illustration.

   sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
   sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
   sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1
   sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
   sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
   sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_shared
   

   Montera inte katalogerna genom att utfärda monteringskommandon. Ange i stället konfigurationerna i fstab och utfärda en slutgiltig mount -a för att verifiera syntaxen. Börja med att skapa monteringskatalogerna för varje volym:

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

   fstab Skapa sedan poster för de tre logiska volymerna genom att infoga följande rader i /etc/fstab filen:

   /dev/mapper/vg_hana_data_HN1-hana_data /hana/data xfs defaults,nofail 0 2 /dev/mapper/vg_hana_log_HN1-hana_log /hana/log xfs defaults,nofail 0 2 /dev/mapper/vg_hana_shared_HN1-hana_shared /hana/shared xfs defaults,nofail 0 2

   Montera slutligen de nya volymerna samtidigt:

   sudo mount -a
   

2. [A] Konfigurera värdnamnsmatchning för alla värdar.

   Du kan antingen använda en DNS-server eller ändra /etc/hosts filen på alla noder genom att skapa poster för alla noder så här i /etc/hosts:

   10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1

3. [A] Utför RHEL för HANA-konfiguration.

   Konfigurera RHEL enligt beskrivningen i följande anteckningar:

   • 2447641 – Ytterligare paket som krävs för att installera SAP HANA SPS 12 på RHEL 7.X
   • 2292690 – SAP HANA DB: Rekommenderade OS-inställningar för RHEL 7
   • 2777782 – SAP HANA DB: Rekommenderade OS-inställningar för RHEL 8
   • 2455582 – Linux: Köra SAP-program som kompilerats med GCC 6.x
   • 2593824 – Linux: Köra SAP-program som kompilerats med GCC 7.x
   • 2886607 – Linux: Köra SAP-program som kompilerats med GCC 9.x

4. [A] Installera SAP HANA enligt SAP:s dokumentation.

5. [A] Konfigurera brandväggen.

   Skapa brandväggsregeln för Azure Load Balancer-avsökningsporten.

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

Konfigurera SAP HANA 2.0-systemreplikering

Stegen i det här avsnittet använder följande prefix:

• [A]: Steget gäller för alla noder.
• [1]: Steget gäller endast för nod 1.
• [2]: Steget gäller endast för nod 2 i Pacemaker-klustret.

1. [A] Konfigurera brandväggen.

   Skapa brandväggsregler för att tillåta HANA-systemreplikering och klienttrafik. De portar som krävs visas på TCP/IP-portar för alla SAP-produkter. Följande kommandon är bara ett exempel för att tillåta HANA 2.0-systemreplikering och klienttrafik till databasen SYSTEMDB, HN1 och NW1.

    sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp --permanent
    sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp
   
   

2. [1] Skapa klientdatabasen.

   Kör följande kommando som <hanasid>adm:

   hdbsql -u SYSTEM -p "[passwd]" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "<passwd>"'
   

3. [1] Konfigurera systemreplikering på den första noden.

   Säkerhetskopiera databaserna som <hanasid>adm:

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

   Kopiera systemets PKI-filer till den sekundära platsen:

   scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT   hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
   scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/
   

   Skapa den primära platsen:

   hdbnsutil -sr_enable --name=SITE1
   

4. [2] Konfigurera systemreplikering på den andra noden.

   Registrera den andra noden för att starta systemreplikeringen. Kör följande kommando som <hanasid>adm:

   sapcontrol -nr 03 -function StopWait 600 10
   hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
   

5. [1] Kontrollera replikeringsstatus.

   Kontrollera replikeringsstatusen och vänta tills alla databaser är synkroniserade. Om statusen förblir OKÄND kontrollerar du brandväggsinställningarna.

   sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
   # | Database | Host     | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
   # |          |          |       |              |           |         |           | Host      | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
   # | -------- | -------- | ----- | ------------ | --------- | ------- | --------- | --------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
   # | SYSTEMDB | hn1-db-0 | 30301 | nameserver   |         1 |       1 | SITE1     | hn1-db-1  |     30301 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
   # | HN1      | hn1-db-0 | 30307 | xsengine     |         2 |       1 | SITE1     | hn1-db-1  |     30307 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
   # | NW1      | hn1-db-0 | 30340 | indexserver  |         2 |       1 | SITE1     | hn1-db-1  |     30340 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
   # | HN1      | hn1-db-0 | 30303 | indexserver  |         3 |       1 | SITE1     | hn1-db-1  |     30303 |         2 | SITE2     | YES           | SYNC        | ACTIVE      |                |
   #
   # status system replication site "2": ACTIVE
   # overall system replication status: ACTIVE
   #
   # Local System Replication State
   # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   #
   # mode: PRIMARY
   # site id: 1
   # site name: SITE1
   

Skapa ett Pacemaker-kluster

Följ stegen i Konfigurera Pacemaker på Red Hat Enterprise Linux i Azure för att skapa ett grundläggande Pacemaker-kluster för den här HANA-servern.

Implementera SAP HANA-systemreplikeringskrokar

Det här viktiga steget optimerar integreringen med klustret och förbättrar identifieringen när ett kluster behöver redundans. Det är obligatoriskt för korrekt klusteråtgärd att aktivera SAPHanaSR-kroken. Vi rekommenderar starkt att du konfigurerar både SAPHanaSR- och ChkSrv Python-krokar.

1. [A] Installera SAP HANA-resursagenterna på alla noder. Se till att aktivera en lagringsplats som innehåller paketet. Du behöver inte aktivera fler lagringsplatser om du använder en RHEL 8.x- eller högre HA-aktiverad avbildning.

   # Enable repository that contains SAP HANA resource agents
   sudo subscription-manager repos --enable="rhel-sap-hana-for-rhel-7-server-rpms"
   
   sudo dnf install -y resource-agents-sap-hana
   

   Kommentar

   För RHEL 8.x och RHEL 9.x kontrollerar du att det installerade paketet resource-agents-sap-hana är version 0.162.3-5 eller senare.

2. [A] Installera HANA system replication hooks. Konfigurationen för replikeringskrokerna måste installeras på båda HANA DB-noderna.

   1. Stoppa HANA på båda noderna. Kör som <sid-adm>.

      sapcontrol -nr 03 -function StopSystem
      

   2. Justera global.ini på varje klusternod.

      [ha_dr_provider_SAPHanaSR]
      provider = SAPHanaSR
      path = /usr/share/SAPHanaSR/srHook
      execution_order = 1
      
      [ha_dr_provider_chksrv]
      provider = ChkSrv
      path = /usr/share/SAPHanaSR/srHook
      execution_order = 2
      action_on_lost = kill
      
      [trace]
      ha_dr_saphanasr = info
      ha_dr_chksrv = info
      

   Om du pekar parametern path på standardplatsen /usr/share/SAPHanaSR/srHook uppdateras Python-hookkoden automatiskt via OS-uppdateringar eller paketuppdateringar. HANA använder hook-koduppdateringarna när den startas om nästa år. Med en valfri egen sökväg som /hana/shared/myHookskan du frikoppla OS-uppdateringar från den krokversion som HANA använder.

   Du kan justera hookens ChkSrv beteende med hjälp av parametern action_on_lost . Giltiga värden är [ ignore | | stopkill ].

3. [A] Klustret kräver sudoers konfiguration på varje klusternod för <sid>adm. I det här exemplet uppnås detta genom att skapa en ny fil. visudo Använd kommandot för att redigera 20-saphana drop-in-filen som root.

   sudo visudo -f /etc/sudoers.d/20-saphana
   

   Infoga följande rader och spara sedan:

   Cmnd_Alias SITE1_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SITE1_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE1 -v SFAIL -t crm_config -s SAPHanaSR
   Cmnd_Alias SITE2_SOK   = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SOK -t crm_config -s SAPHanaSR
   Cmnd_Alias SITE2_SFAIL = /usr/sbin/crm_attribute -n hana_hn1_site_srHook_SITE2 -v SFAIL -t crm_config -s SAPHanaSR
   hn1adm ALL=(ALL) NOPASSWD: SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL
   Defaults!SITE1_SOK, SITE1_SFAIL, SITE2_SOK, SITE2_SFAIL !requiretty
   

4. [A] Starta SAP HANA på båda noderna. Kör som <sid-adm>.

   sapcontrol -nr 03 -function StartSystem 
   

5. [1] Verifiera SRHanaSR-hookinstallationen. Kör som <sid-adm>på den aktiva HANA-systemreplikeringsplatsen.

    cdtrace
    awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
    { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*
   

    # 2021-04-12 21:36:16.911343 ha_dr_SAPHanaSR SFAIL
    # 2021-04-12 21:36:29.147808 ha_dr_SAPHanaSR SFAIL
    # 2021-04-12 21:37:04.898680 ha_dr_SAPHanaSR SOK
   

6. [1] Verifiera ChkSrv-hookinstallationen. Kör som <sid-adm>på den aktiva HANA-systemreplikeringsplatsen.

    cdtrace
    tail -20 nameserver_chksrv.trc
   

Mer information om implementeringen av SAP HANA-krokarna finns i Aktivera SAP HANA srConnectionChanged()-kroken och Aktivera SAP HANA srServiceStateChanged()-kroken för hdbindexserverprocessfel (valfritt).

Skapa SAP HANA-klusterresurser

Skapa HANA-topologin. Kör följande kommandon på en av Pacemaker-klusternoderna. Under de här instruktionerna måste du ersätta instansnumret, HANA-system-ID, IP-adresser och systemnamn, där det är lämpligt.

sudo pcs property set maintenance-mode=true

sudo pcs resource create SAPHanaTopology_HN1_03 SAPHanaTopology SID=HN1 InstanceNumber=03 \
op start timeout=600 op stop timeout=300 op monitor interval=10 timeout=600 \
clone clone-max=2 clone-node-max=1 interleave=true

Skapa sedan HANA-resurserna.

Om du skapar ett kluster på RHEL 7.x använder du följande kommandon:

sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
  op start timeout=3600 op stop timeout=3600 \
  op monitor interval=61 role="Slave" timeout=700 \
  op monitor interval=59 role="Master" timeout=700 \
  op promote timeout=3600 op demote timeout=3600 \
  master notify=true clone-max=2 clone-node-max=1 interleave=true

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-master symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-master 4000

sudo pcs resource defaults resource-stickiness=1000
sudo pcs resource defaults migration-threshold=5000

sudo pcs property set maintenance-mode=false

Om du skapar ett kluster på RHEL 8.x/9.x använder du följande kommandon:

sudo pcs resource create SAPHana_HN1_03 SAPHana SID=HN1 InstanceNumber=03 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
  op start timeout=3600 op stop timeout=3600 \
  op monitor interval=61 role="Slave" timeout=700 \
  op monitor interval=59 role="Master" timeout=700 \
  op promote timeout=3600 op demote timeout=3600 \
  promotable notify=true clone-max=2 clone-node-max=1 interleave=true

sudo pcs resource create vip_HN1_03 IPaddr2 ip="10.0.0.13"
sudo pcs resource create nc_HN1_03 azure-lb port=62503
sudo pcs resource group add g_ip_HN1_03 nc_HN1_03 vip_HN1_03

sudo pcs constraint order SAPHanaTopology_HN1_03-clone then SAPHana_HN1_03-clone symmetrical=false
sudo pcs constraint colocation add g_ip_HN1_03 with master SAPHana_HN1_03-clone 4000

sudo pcs resource defaults update resource-stickiness=1000
sudo pcs resource defaults update migration-threshold=5000

sudo pcs property set maintenance-mode=false

För att konfigurera priority-fencing-delay för SAP HANA (gäller endast för pacemaker-2.0.4-6.el8 eller senare) måste följande kommandon köras.

sudo pcs property set maintenance-mode=true

sudo pcs resource defaults update priority=1
sudo pcs resource update SAPHana_HN1_03-clone meta priority=10

sudo pcs property set priority-fencing-delay=15s

sudo pcs property set maintenance-mode=false

Kontrollera att klusterstatusen är okej och att alla resurser har startats. Vilken nod resurserna körs på är inte viktigt.

Använd kommandot sudo pcs status för att kontrollera tillståndet för de klusterresurser som skapats:

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# azure_fence     (stonith:fence_azure_arm):      Started hn1-db-0
#  Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
#      Started: [ hn1-db-0 hn1-db-1 ]
#  Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
#      Masters: [ hn1-db-0 ]
#      Slaves: [ hn1-db-1 ]
#  Resource Group: g_ip_HN1_03
#      nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
#      vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Konfigurera AKTIV/läsaktiverad HANA-systemreplikering i Pacemaker-kluster

Från och med SAP HANA 2.0 SPS 01 tillåter SAP aktiva/läsaktiverade installationer för SAP HANA-systemreplikering, där de sekundära systemen i SAP HANA System Replication kan användas aktivt för läsintensiva arbetsbelastningar.

För att stödja en sådan installation i ett kluster krävs en andra virtuell IP-adress som gör att klienter kan komma åt den sekundära läsaktiverade SAP HANA-databasen. För att säkerställa att den sekundära replikeringsplatsen fortfarande kan nås efter ett övertagande måste klustret flytta runt den virtuella IP-adressen med den sekundära SAPHana-resursen.

I det här avsnittet beskrivs de andra stegen som krävs för att hantera HANA-aktiv/läsaktiverad systemreplikering i ett Red Hat HA-kluster med en andra virtuell IP-adress.

Innan du fortsätter kontrollerar du att du har konfigurerat Red Hat HA-klustret för att hantera en SAP HANA-databas, enligt beskrivningen i föregående segment i dokumentationen.

Ytterligare installation i Azure Load Balancer för aktiv/läsaktiverad installation

Om du vill fortsätta med fler steg för att etablera en andra virtuell IP-adress kontrollerar du att du har konfigurerat Azure Load Balancer enligt beskrivningen i avsnittet Distribuera virtuella Linux-datorer manuellt via Azure Portal.

1. För en standardlastbalanserare följer du de här stegen i samma lastbalanserare som du skapade i ett tidigare avsnitt.

   a. Skapa en andra IP-pool på klientsidan:

   • Öppna lastbalanseraren, välj KLIENTDELS-IP-pool och välj Lägg till.
   • Ange namnet på den andra IP-poolen på klientsidan (till exempel hana-secondaryIP).
   • Ange Tilldelning till Statisk och ange IP-adressen (till exempel 10.0.0.14).
   • Välj OK.
   • När den nya KLIENTDELS-IP-poolen har skapats noterar du poolens IP-adress.

   b. Skapa en hälsoavsökning:

   • Öppna lastbalanseraren, välj hälsoavsökningar och välj Lägg till.
   • Ange namnet på den nya hälsoavsökningen (till exempel hana-secondaryhp).
   • Välj TCP som protokoll och port 62603. Behåll värdet Intervall inställt på 5 och tröskelvärdet Ej felfri är inställt på 2.
   • Välj OK.

   c. Skapa belastningsutjämningsreglerna:

   • Öppna lastbalanseraren, välj belastningsutjämningsregler och välj Lägg till.
   • Ange namnet på den nya lastbalanseringsregeln (till exempel hana-secondarylb).
   • Välj klientdelens IP-adress, serverdelspoolen och hälsoavsökningen som du skapade tidigare (till exempel hana-secondaryIP, hana-backend och hana-secondaryhp).
   • Välj HA-portar.
   • Se till att aktivera flytande IP-adress.
   • Välj OK.

Konfigurera AKTIV/läsaktiverad HANA-systemreplikering

Stegen för att konfigurera HANA-systemreplikering beskrivs i avsnittet Konfigurera SAP HANA 2.0-systemreplikering . Om du distribuerar ett läsaktiverat sekundärt scenario när du konfigurerar systemreplikering på den andra noden kör du följande kommando som hanasidadm:

sapcontrol -nr 03 -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 --operationMode=logreplay_readaccess 

Lägga till en sekundär virtuell IP-adressresurs för en aktiv/läsaktiverad installation

Den andra virtuella IP-adressen och lämplig samlokaliseringsbegränsning kan konfigureras med följande kommandon:

pcs property set maintenance-mode=true

pcs resource create secvip_HN1_03 ocf:heartbeat:IPaddr2 ip="10.40.0.16"

pcs resource create secnc_HN1_03 ocf:heartbeat:azure-lb port=62603

pcs resource group add g_secip_HN1_03 secnc_HN1_03 secvip_HN1_03

pcs constraint location g_secip_HN1_03 rule score=INFINITY hana_hn1_sync_state eq SOK and hana_hn1_roles eq 4:S:master1:master:worker:master

pcs constraint location g_secip_HN1_03 rule score=4000 hana_hn1_sync_state eq PRIM and hana_hn1_roles eq 4:P:master1:master:worker:master

pcs property set maintenance-mode=false

Kontrollera att klusterstatusen är okej och att alla resurser har startats. Den andra virtuella IP-adressen körs på den sekundära platsen tillsammans med den sekundära SAPHana-resursen.

sudo pcs status

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full List of Resources:
#   rsc_hdb_azr_agt     (stonith:fence_azure_arm):      Started hn1-db-0
#   Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]:
#     Started: [ hn1-db-0 hn1-db-1 ]
#   Clone Set: SAPHana_HN1_03-clone [SAPHana_HN1_03] (promotable):
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
#   Resource Group: g_ip_HN1_03:
#     nc_HN1_03         (ocf::heartbeat:azure-lb):      Started hn1-db-0
#     vip_HN1_03        (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#   Resource Group: g_secip_HN1_03:
#     secnc_HN1_03      (ocf::heartbeat:azure-lb):      Started hn1-db-1
#     secvip_HN1_03     (ocf::heartbeat:IPaddr2):       Started hn1-db-1

I nästa avsnitt hittar du den typiska uppsättningen redundanstester som ska köras.

Tänk på det andra virtuella IP-beteendet när du testar ett HANA-kluster som konfigurerats med läsaktiverad sekundär:

1. När du migrerar den SAPHana_HN1_03 klusterresursen till den sekundära platsen hn1-db-1 fortsätter den andra virtuella IP-adressen att köras på samma plats hn1-db-1. Om du har angett AUTOMATED_REGISTER="true" för resursen och HANA-systemreplikeringen registreras automatiskt på hn1-db-0 flyttas även den andra virtuella IP-adressen till hn1-db-0.

2. När du testar en serverkrasch körs de andra virtuella IP-resurserna (secvip_HN1_03) och Azure Load Balancer-portresursen (secnc_HN1_03) på den primära servern tillsammans med de primära virtuella IP-resurserna. Så tills den sekundära servern är nere ansluter program som är anslutna till den läsaktiverade HANA-databasen till den primära HANA-databasen. Beteendet är förväntat eftersom du inte vill att program som är anslutna till den läsaktiverade HANA-databasen ska vara otillgängliga tills den sekundära servern inte är tillgänglig.

3. Under redundansväxling och återställning av den andra virtuella IP-adressen kan de befintliga anslutningarna i program som använder den andra virtuella IP-adressen för att ansluta till HANA-databasen avbrytas.

Konfigurationen maximerar tiden då den andra virtuella IP-resursen tilldelas till en nod där en felfri SAP HANA-instans körs.

Testa klusterkonfigurationen

I det här avsnittet beskrivs hur du kan testa konfigurationen. Innan du startar ett test kontrollerar du att Pacemaker inte har någon misslyckad åtgärd (via pc-status), att det inte finns några oväntade platsbegränsningar (till exempel rester av ett migreringstest) och att HANA är i synkroniseringstillstånd, till exempel med systemReplicationStatus.

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

Testa migreringen

Resurstillstånd innan testet startas:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Du kan migrera SAP HANA-huvudnoden genom att köra följande kommando som rot:

# On RHEL 7.x
pcs resource move SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource move SAPHana_HN1_03-clone --master

Klustret migrerar SAP HANA-huvudnoden och gruppen som innehåller virtuell IP-adress till hn1-db-1.

När migreringen är klar sudo pcs status ser utdata ut så här:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Stopped: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Med AUTOMATED_REGISTER="false"startar inte klustret om den misslyckade HANA-databasen eller registrerar den mot den nya primära på hn1-db-0. I det här fallet konfigurerar du HANA-instansen som sekundär genom att köra dessa kommandon som hn1adm:

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

Migreringen skapar platsbegränsningar som måste tas bort igen. Kör följande kommando som rot eller via sudo:

pcs resource clear SAPHana_HN1_03-master

Övervaka tillståndet för HANA-resursen med hjälp pcs statusav . När HANA har startats hn1-db-0bör utdata se ut så här:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Blockera nätverkskommunikation

Resurstillstånd innan testet startas:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Kör brandväggsregeln för att blockera kommunikationen på en av noderna.

# 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

När klusternoder inte kan kommunicera med varandra finns det en risk för ett scenario med delad hjärna. I sådana situationer försöker klusternoder att samtidigt avgränsa varandra, vilket resulterar i en stängseltävling. För att undvika en sådan situation rekommenderar vi att du anger egenskapen priority-fencing-delay i klusterkonfigurationen (gäller endast pacemaker-2.0.4-6.el8 eller senare).

Genom att aktivera priority-fencing-delay egenskapen introducerar klustret en fördröjning i fäktningsåtgärden specifikt på noden som är värd för HANA-huvudresursen, vilket gör att noden kan vinna stängselracet.

Kör följande kommando för att ta bort brandväggsregeln:

# 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

Testa Azure-fäktningsagenten

Resurstillstånd innan testet startas:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
    Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Du kan testa konfigurationen av Azure-fäktningsagenten genom att inaktivera nätverksgränssnittet på noden där SAP HANA körs som huvudserver. En beskrivning av hur du simulerar ett nätverksfel finns i Red Hat Knowledge Base-artikeln 79523.

I det här exemplet använder vi skriptet net_breaker som rot för att blockera all åtkomst till nätverket:

sh ./net_breaker.sh BreakCommCmd 10.0.0.6

Den virtuella datorn bör nu startas om eller stoppas beroende på klusterkonfigurationen. Om du ställer in inställningen stonith-action på offstoppas den virtuella datorn och resurserna migreras till den virtuella datorn som körs.

När du har startat den virtuella datorn igen startar inte SAP HANA-resursen som sekundär om du anger AUTOMATED_REGISTER="false". I det här fallet konfigurerar du HANA-instansen som sekundär genom att köra det här kommandot som hn1adm-användare :

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2

Växla tillbaka till roten och rensa det misslyckade tillståndet:

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

Resurstillstånd efter testet:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Testa en manuell redundansväxling

Resurstillstånd innan testet startas:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-0 ]
    Slaves: [ hn1-db-1 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-0
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-0

Du kan testa en manuell redundansväxling genom att stoppa klustret på hn1-db-0 noden som rot:

pcs cluster stop

Efter redundansväxlingen kan du starta klustret igen. Om du anger AUTOMATED_REGISTER="false"startar inte SAP HANA-resursen hn1-db-0 på noden som sekundär. I det här fallet konfigurerar du HANA-instansen som sekundär genom att köra det här kommandot som rot:

pcs cluster start

Kör följande som hn1adm:

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1

Sedan som rot:

# On RHEL 7.x
pcs resource cleanup SAPHana_HN1_03-master
# On RHEL 8.x
pcs resource cleanup SAPHana_HN1_03 node=<hostname on which the resource needs to be cleaned>

Resurstillstånd efter testet:

Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03]
    Started: [ hn1-db-0 hn1-db-1 ]
Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03]
    Masters: [ hn1-db-1 ]
     Slaves: [ hn1-db-0 ]
Resource Group: g_ip_HN1_03
    nc_HN1_03  (ocf::heartbeat:azure-lb):      Started hn1-db-1
    vip_HN1_03 (ocf::heartbeat:IPaddr2):       Started hn1-db-1

Nästa steg

• Planering och implementering av Azure Virtual Machines för SAP
• Distribution av virtuella Azure-datorer för SAP
• Azure Virtual Machines DBMS-distribution för SAP
• Lagringskonfigurationer för virtuella SAP HANA-datorer