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

Om du vill etablera hög tillgänglighet i en lokal SAP HANA-distribution kan du använda sap hana-systemreplikering eller delad lagring.

För närvarande är SAP HANA-systemreplikering på Azure den enda funktionen för hög tillgänglighet som stöds på virtuella Azure-datorer (VM).

SAP HANA-systemreplikering 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 de virtuella datorerna, installerar klusterramverket och installerar och konfigurerar SAP HANA-systemreplikering.

Läs följande SAP-anteckningar och dokument innan du börjar:

• SAP Note 1928533. Anteckningen innehåller:
  • 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, operativsystem (OS) och databaskombinationer som stöds.
  • Nödvändiga SAP-kernelversioner för Windows och Linux på Microsoft Azure.
• SAP Note 2015553 listar kraven för SAP-programdistributioner som stöds i Azure.
• SAP Obs 2205917 har rekommenderade os-inställningar för SUSE Linux Enterprise Server 12 (SLES 12) för SAP-program.
• SAP Obs 2684254 har rekommenderade OS-inställningar för SUSE Linux Enterprise Server 15 (SLES 15) för SAP-program.
• SAP Note 2235581 har SAP HANA-operativsystem som stöds
• SAP Note 2178632 innehåller detaljerad information om alla övervakningsmått som rapporteras för SAP i Azure.
• SAP Obs 2191498 har den sap-värdagentversion som krävs för Linux i Azure.
• SAP Note 2243692 har information om SAP-licensiering för Linux i Azure.
• SAP Note 1984787 har allmän information om SUSE Linux Enterprise Server 12.
• SAP Note 1999351 innehåller mer felsökningsinformation för Azure Enhanced Monitoring Extension för SAP.
• SAP Obs 401162 har information om hur du undviker "adress som redan används"-fel när du konfigurerar HANA-systemreplikering.
• SAP Community Support Wiki har alla nödvändiga SAP-anteckningar för Linux.
• SAP HANA-certifierade IaaS-plattformar.
• Planering och implementering av Azure Virtual Machines för SAP på Linux-guide .
• Azure Virtual Machines-distribution för SAP i Linux-guide .
• Azure Virtual Machines DBMS-distribution för SAP i Linux-guide .
• Metodguider för SUSE Linux Enterprise Server för SAP-program 15 och metodtipsguider för SUSE Linux Enterprise Server för SAP-program 12:
  • Konfigurera en SAP HANA SR-prestandaoptimerad infrastruktur (SLES för SAP-program). Guiden innehåller all nödvändig information för att konfigurera SAP HANA-systemreplikering för lokal utveckling. Använd den här guiden som baslinje.
  • Konfigurera en kostnadsoptimerad SAP HANA SR-infrastruktur (SLES för SAP-program).

Planera för hög tillgänglighet för SAP HANA

För att uppnå hög tillgänglighet installerar du 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 behöver du en lastbalanserare för att distribuera en virtuell IP-adress.

Föregående bild visar ett exempel på en lastbalanserare som har följande konfigurationer:

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

Förbered infrastrukturen

Resursagenten för SAP HANA ingår i SUSE Linux Enterprise Server för SAP-program. En avbildning för SUSE Linux Enterprise Server för SAP-program 12 eller 15 finns på Azure Marketplace. Du kan använda avbildningen för att distribuera nya virtuella datorer.

Distribuera virtuella Linux-datorer manuellt via Azure Portal

Det här dokumentet förutsätter att du redan har distribuerat en resursgrupp, Azure Virtual Network och undernät.

Distribuera virtuella datorer för SAP HANA. Välj en lämplig SLES-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 SAP HANA-klientdatabaser eller SAP Note 2388694.

Skapa ett Pacemaker-kluster

Följ stegen i Konfigurera Pacemaker på SUSE Linux Enterprise Server i Azure för att skapa ett grundläggande Pacemaker-kluster för den här HANA-servern. Du kan använda samma Pacemaker-kluster för SAP HANA och SAP NetWeaver (A)SCS.

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.

Ersätt <placeholders> med värdena för SAP HANA-installationen.

1. [A] Konfigurera disklayouten med hjälp av 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.

   1. Kör det här kommandot för att visa en lista över alla tillgängliga diskar:

      /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
      

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

   3. Skapa en volymgrupp för datafilerna. Använd en volymgrupp för loggfilerna och en volymgrupp för den delade katalogen för 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. 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 beskrivs i SAP HANA VM-lagringskonfigurationer. Argumentet -i ska vara antalet underliggande fysiska volymer och -I argumentet är randstorleken.

      Om två fysiska volymer till exempel används för datavolymen anges växelargumentet -i till 2 och stripe-storleken 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!

      När du använder mer än en fysisk volym för varje datavolym, loggvolym eller delad volym använder du växeln -i och anger antalet underliggande fysiska volymer. När du skapar en randig volym använder du växeln -I för att ange randstorleken.

      Rekommenderade lagringskonfigurationer, inklusive randstorlekar och antalet diskar, finns i SAP HANA VM-lagringskonfigurationer.

      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. Skapa monteringskatalogerna och kopiera den universellt unika identifieraren (UUID) för alla logiska volymer:

      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. Redigera /etc/fstab-filen för att skapa fstab poster för de tre logiska volymerna:

      sudo vi /etc/fstab
      

   7. Infoga följande rader i filen /etc/fstab :

      /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. Montera de nya volymerna:

      sudo mount -a
      

2. [A] Konfigurera disklayouten med hjälp av oformaterade diskar.

   För demosystem kan du placera DINA HANA-data och loggfiler på en disk.

   1. Skapa en partition på /dev/disk/azure/scsi1/lun0 och formatera den med hjälp av 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. Infoga den här raden i /etc/fstab-filen :

      /dev/disk/by-uuid/<UUID> /hana xfs  defaults,nofail  0  2
      

   3. Skapa målkatalogen och montera disken:

      sudo mkdir /hana
      sudo mount -a
      

3. [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. Det här exemplet visar hur du använder filen /etc/hosts . Ersätt IP-adresserna och värdnamnen i följande kommandon.

   1. Redigera filen /etc/hosts:

      sudo vi /etc/hosts
      

   2. Infoga följande rader i filen /etc/hosts . Ändra IP-adresserna och värdnamnen så att de matchar din miljö.

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

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

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.

Ersätt <placeholders> med värdena för SAP HANA-installationen.

1. [1] Skapa klientdatabasen.

   Om du använder SAP HANA 2.0 eller SAP HANA MDC skapar du en klientdatabas för ditt SAP NetWeaver-system.

   Kör följande kommando som <HANA SID>adm:

   hdbsql -u SYSTEM -p "<password>" -i <instance number> -d SYSTEMDB 'CREATE DATABASE <SAP SID> SYSTEM USER PASSWORD "<password>"'
   

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

   Säkerhetskopiera först databaserna som <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>')"
   

   Kopiera sedan PKI-filerna (System Public Key Infrastructure) till den sekundära platsen:

   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/
   

   Skapa den primära platsen:

   hdbnsutil -sr_enable --name=<site 1>
   

3. [2] Konfigurera systemreplikering på den andra noden:

   Registrera den andra noden för att starta systemreplikeringen.

   Kör följande kommando som <HANA SID>adm:

   sapcontrol -nr <instance number> -function StopWait 600 10
   hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> 
   

Implementera HANA-resursagenter

SUSE tillhandahåller två olika programvarupaket för Pacemaker-resursagenten för att hantera SAP HANA. Programvarupaketen SAPHanaSR och SAPHanaSR-angi använder lite olika syntax och parametrar och är inte kompatibla. Mer information och skillnader mellan SAPHanaSR och SAPHanaSR-angi finns i viktig information och dokumentation om SUSE. Det här dokumentet beskriver båda paketen på separata flikar i respektive avsnitt.

1. [A] Installera SAP HANA-paket med hög tillgänglighet:

sudo zypper install SAPHanaSR

sudo zypper install SAPHanaSR-angi

Konfigurera SAP HANA HA/DR-leverantörer

SAP HANA HA/DR-leverantörerna optimerar integreringen med klustret och förbättrar identifieringen när ett kluster redundans behövs. Huvudhookskriptet är SAPHanaSR (för SAPHanaSR-paketet) /susHanaSR (för SAPHanaSR-angi). Vi rekommenderar starkt att du konfigurerar SAPHanaSR/susHanaSR Python-kroken. För HANA 2.0 SPS 05 och senare rekommenderar vi att du implementerar både SAPHanaSR/susHanaSR och susChkSrv-krokarna.

SusChkSrv-kroken utökar funktionerna i huvudleverantören SAPHanaSR/susHanaSR HA. Den fungerar när HANA-processen hdbindexserver kraschar. Om en enskild process kraschar försöker HANA vanligtvis starta om den. Det kan ta lång tid att starta om indexserverprocessen, under vilken HANA-databasen inte svarar.

När susChkSrv har implementerats körs en omedelbar och konfigurerbar åtgärd. Åtgärden utlöser en redundans under den konfigurerade tidsgränsen i stället för att vänta på att hdbindexserverprocessen ska startas om på samma nod.

1. [A] Stoppa HANA på båda noderna.

Kör följande kod som <sap-sid>adm:

sapcontrol -nr <instance number> -function StopSystem

2. [A] Installera HANA-systemreplikeringskrokar. Krokarna måste installeras på båda HANA-databasnoderna.

   Dricks

   SAPHanaSR Python-kroken kan endast implementeras för HANA 2.0. SAPHanaSR-paketet måste vara minst version 0.153.
   SAPHanaSR-angi Python-kroken kan endast implementeras för HANA 2.0 SPS 05 och senare.
   Python-kroken susChkSrv kräver SAP HANA 2.0 SPS 05 och SAPHanaSR-version 0.161.1_BF eller senare måste installeras.

   • SAPHanaSR
   • SAPHanaSR-angi

   1. [A] Justera global.ini på varje klusternod.

      Om kraven för susChkSrv-kroken inte uppfylls tar du bort hela [ha_dr_provider_suschksrv] blocket från följande parametrar. Du kan justera beteendet för med hjälp av susChkSrv parametern action_on_lost . Giltiga värden är [ ignorefence | | stop | kill].

      [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
      

      Om du pekar parametersökvägen till standardplatsen /usr/share/SAPHanaSR 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 du använder.

   2. [A] Klustret kräver sudoers-konfiguration på varje klusternod för <sap-sid>adm. I det här exemplet uppnås detta genom att skapa en ny fil.

      Kör följande kommando som rot. Ersätt <sid> med sap-system-ID med gemener, <SID> med versaler för SAP-system-ID och <siteA/B> med hana-platsnamn valda.

      cat << EOF > /etc/sudoers.d/20-saphana
      # Needed for SAPHanaSR and susChkSrv Python hooks
      Cmnd_Alias SOK_SITEA      = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEA    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias SOK_SITEB      = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEB    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias HELPER_TAKEOVER = /usr/sbin/SAPHanaSR-hookHelper --sid=<SID> --case=checkTakeover
      Cmnd_Alias HELPER_FENCE    = /usr/sbin/SAPHanaSR-hookHelper --sid=<SID> --case=fenceMe
      
      <sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB, HELPER_TAKEOVER, HELPER_FENCE
      EOF
      

   Mer information om hur du implementerar SAP HANA-systemreplikeringskroken finns i Konfigurera HANA HA/DR-leverantörer.

3. [A] Starta SAP HANA på båda noderna. Kör följande kommando som <sap-sid>adm:

   sapcontrol -nr <instance number> -function StartSystem 
   

4. [1] Kontrollera hookinstallationen. Kör följande kommando som <sap-sid>adm på den aktiva HANA-systemreplikeringsplatsen:

   • SAPHanaSR
   • SAPHanaSR-angi

   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
   

5. [1] Kontrollera installationen av susChkSrv-kroken. Kör följande kommando som <sap-sid>adm på virtuella HANA-datorer:

   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)
   

Skapa SAP HANA-klusterresurser

1. [1] Skapa först HANA-topologiresursen.

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"

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 \
  op monitor interval="50" 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" interleave="true"

2. [1] Skapa sedan HANA-resurserna:

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

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"

# Run the following command if the cluster nodes are running on SLES 12 SP05.
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"

# Run the following command if the cluster nodes are running on SLES 15 SP03 or later.
sudo crm configure clone 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" promotable="true"

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

# Replace <placeholders> with your instance number and HANA system ID. 
sudo crm configure primitive rsc_SAPHanaCon_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop  interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op demote  interval="0" timeout="320"  \
  op monitor interval="60" role="Promoted" timeout="700" \
  op monitor interval="61" role="Unpromoted" timeout="700" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \
  meta priority=100

sudo crm configure clone mst_SAPHanaCon_<HANA SID>_HDB<instance number> rsc_SAPHanaCon_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true" promotable="true"

# Replace <placeholders> with your instance number and HANA system ID. 
sudo crm configure primitive rsc_SAPHanaFil_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaFilesystem \
  op start interval="0" timeout="10" \
  op stop interval="0" timeout="20" \
  op monitor interval="120" timeout="120" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" ON_FAIL_ACTION="fence"

sudo crm configure clone cln_SAPHanaFil_<HANA SID>_HDB<instance number> rsc_SAPHanaFil_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" interleave="true"

3. [1] Fortsätt med klusterresurser för virtuella IP-adresser, standardvärden och begränsningar.

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

# 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_ip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
  meta target-role="Started" \
  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 \
  mst_SAPHanaCon_<HANA SID>_HDB<instance number>:Promoted  

sudo crm configure order ord_SAPHana_<HANA SID>_HDB<instance number> Optional: cln_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  mst_SAPHanaCon_<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_SAPHanaCon_<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

Kontrollera att klusterstatusen är OK och att alla resurser har startats. Det spelar ingen roll vilken nod resurserna körs på.

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

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

I SAP HANA 2.0 SPS 01 och senare versioner tillåter SAP en aktiv/läsaktiverad installation för SAP HANA-systemreplikering. I det här scenariot kan de sekundära systemen för SAP HANA-systemreplikering aktivt användas för läsintensiva arbetsbelastningar.

För att stödja den här konfigurationen i ett kluster krävs en andra virtuell IP-adress så att klienterna 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 extra steg som krävs för att hantera en HANA-aktiv/läsaktiverad systemreplikering i ett SUSE-kluster med hög tillgänglighet som använder en andra virtuell IP-adress.

Innan du fortsätter kontrollerar du att du har konfigurerat SUSE-klustret med hög tillgänglighet som hanterar SAP HANA-databasen enligt beskrivningen i tidigare avsnitt.

Konfigurera lastbalanseraren för aktiv/läsaktiverad systemreplikering

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

För standardlastbalanseraren utför du de här extra stegen på samma lastbalanserare som du skapade tidigare.

1. Skapa en andra IP-pool på klientsidan:
   1. Öppna lastbalanseraren, välj KLIENTDELS-IP-pool och välj Lägg till.
   2. Ange namnet på den andra IP-poolen på klientsidan (till exempel hana-secondaryIP).
   3. Ange tilldelningen till Statisk och ange IP-adressen (till exempel 10.0.0.14).
   4. Välj OK.
   5. När den nya KLIENTDELS-IP-poolen har skapats noterar du IP-adressen för klientdelen.
2. Skapa en hälsoavsökning:
   1. I lastbalanseraren väljer du hälsoavsökningar och väljer Lägg till.
   2. Ange namnet på den nya hälsoavsökningen (till exempel hana-secondaryhp).
   3. Välj TCP som protokoll och port 626-instansnummer><. Behåll värdet Intervall inställt på 5 och tröskelvärdet Ej felfri är inställt på 2.
   4. Välj OK.
3. Skapa belastningsutjämningsreglerna:
   1. I lastbalanseraren väljer du belastningsutjämningsregler och väljer Lägg till.
   2. Ange namnet på den nya lastbalanseringsregeln (till exempel hana-secondarylb).
   3. Välj klientdelens IP-adress, serverdelspoolen och hälsoavsökningen som du skapade tidigare (till exempel hana-secondaryIP, hana-backend och hana-secondaryhp).
   4. Välj HA-portar.
   5. Öka tidsgränsen för inaktivitet till 30 minuter.
   6. Kontrollera att du aktiverar flytande IP-adress.
   7. Välj OK.

Konfigurera HANA-aktiv/läsaktiverad systemreplikering

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

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 

Lägga till en sekundär virtuell IP-adressresurs

Du kan konfigurera den andra virtuella IP-adressen och lämplig samlokaliseringsbegränsning med hjälp av följande kommandon:

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

crm configure property maintenance-mode=true

crm configure primitive rsc_secip_<HANA SID>_HDB<instance number> ocf:heartbeat:IPaddr2 \
 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 \
 mst_SAPHanaCon_<HANA SID>_HDB<instance number>:Unpromoted 

crm configure property maintenance-mode=false

Kontrollera att klusterstatusen är OK 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 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

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

Överväganden när du testar ett HANA-kluster som har konfigurerats med en läsaktiverad sekundär:

• När du migrerar klusterresursen SAPHana_<HANA SID>_HDB<instance number> till hn1-db-1flyttas den andra virtuella IP-adressen till hn1-db-0. Om du har konfigurerat AUTOMATED_REGISTER="false" och HANA-systemreplikeringen inte registreras automatiskt körs den andra virtuella IP-adressen på hn1-db-0 eftersom servern är tillgänglig och klustertjänsterna är online.

• När du testar en serverkrasch körs den andra virtuella IP-resurserna (rsc_secip_<HANA SID>_HDB<instance number>) och Azure Load Balancer-portresursen (rsc_secnc_<HANA SID>_HDB<instance number>) på den primära servern tillsammans med de primära virtuella IP-resurserna. När den sekundära servern är nere ansluter de program som är anslutna till en läsaktiverad HANA-databas till den primära HANA-databasen. Beteendet är förväntat eftersom du inte vill att program som är anslutna till en läsaktiverad HANA-databas ska vara otillgängliga när den sekundära servern inte är tillgänglig.

• När den sekundära servern är tillgänglig och klustertjänsterna är online flyttas den andra virtuella IP- och portresurserna automatiskt till den sekundära servern, även om HANA-systemreplikeringen kanske inte registreras som sekundär. Kontrollera att du registrerar den sekundära HANA-databasen som läsaktiverad innan du startar klustertjänster på den servern. Du kan konfigurera HANA-instansklusterresursen för att automatiskt registrera den sekundära genom att ange parametern AUTOMATED_REGISTER="true".

• Under redundansväxling och återställning kan befintliga anslutningar för program, som sedan använder den andra virtuella IP-adressen för att ansluta till HANA-databasen, avbrytas.

Testa klusterkonfigurationen

I det här avsnittet beskrivs hur du kan testa konfigurationen. Varje test förutsätter att du är inloggad som rot och att SAP HANA-huvudservern körs på den hn1-db-0 virtuella datorn.

Testa migreringen

Innan du startar testet kontrollerar du att Pacemaker inte har någon misslyckad åtgärd (kör crm_mon -r), 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 genom att köra SAPHanaSR-showAttr.

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

hn1-db-0:~ # SAPHanaSR-showAttr
Global cib-update dcid prim      sec sid topology
--------------------------------------------------
global 0.130728.2 1    SITE1 -   HN1 ScaleUp

Resource                      promotable
-----------------------------------------
mst_SAPHanaCon_HN1_HDB03      true
cln_SAPHanaTopology_HN1_HDB03

Site        lpt        lss mns      opMode    srHook srMode srPoll srr
-----------------------------------------------------------------------
SITE1       1722604101 4   hn1-db-0 logreplay PRIM   sync   PRIM   P
SITE2       30         4   hn1-db-1 logreplay SWAIT  sync   SOK    S

Host     clone_state roles                        score site    sra srah version     vhost
---------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    master1:master:worker:master 150   SITE1   -   -    2.00.074.00 hn1-db-0
hn1-db-1 DEMOTED     master1:master:worker:master 100   SITE2       -    2.00.074.00 hn1-db-1

Host     clone_state roles                        score site      sra srah version     vhost
------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    master1:master:worker:master 150   SITE1     -   -    2.00.074.00 hn1-db-0
hn1-db-1                                                SITE2                          hn1-db-1

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

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

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

När migreringen är klar crm_mon -r ser utdata ut så här:

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

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 det här kommandot:

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>

Migreringen skapar platsbegränsningar som måste tas bort igen:

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

Du måste också rensa tillståndet för den sekundära nodresursen:

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

Övervaka tillståndet för HANA-resursen med hjälp crm_mon -rav . När HANA startas hn1-db-0ser utdata ut som i det här exemplet:

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

Blockera nätverkskommunikation

Resurstillstånd innan testet startas:

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

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 stängselrace.

När du konfigurerar en fäktningsenhet rekommenderar vi att du konfigurerar pcmk_delay_max egenskapen. I händelse av split-brain-scenario introducerar klustret därför en slumpmässig fördröjning upp till pcmk_delay_max värdet, till fäktningsåtgärden på varje nod. Noden med den kortaste fördröjningen väljs för stängsel.

För att säkerställa att noden som kör HANA-mastern prioriteras och vinner stängselracet i ett scenario med delad hjärna rekommenderar vi att du anger priority-fencing-delay egenskapen i klusterkonfigurationen. Genom att aktivera egenskapen priority-fencing-delay kan klustret införa ytterligare 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 kommandot nedan 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 SBD-fäktning

Du kan testa konfigurationen av SBD genom att döda inkvisitorprocessen:

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

Klusternoden <HANA SID>-db-<database 1> startas om. Pacemakertjänsten kanske inte startas om. Se till att du startar den igen.

Testa en manuell redundansväxling

Du kan testa en manuell redundansväxling genom att stoppa Pacemaker-tjänsten på hn1-db-0 noden:

service pacemaker stop

Efter redundansväxlingen kan du starta tjänsten 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:

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-tester

Kör alla testfall som visas i guiden för prestandaoptimerade SAP HANA SR-scenarion eller kostnadsoptimerade SAP HANA SR-scenarion, beroende på ditt scenario. Du hittar guiderna i SLES för bästa praxis för SAP.

Följande tester är en kopia av testbeskrivningarna av SAP HANA SR Performance Optimized Scenario SUSE Linux Enterprise Server for SAP Applications 12 SP1 guide. För en uppdaterad version läser du även själva guiden. Kontrollera alltid att HANA är synkroniserat innan du startar testet och kontrollera att Pacemaker-konfigurationen är korrekt.

I följande testbeskrivningar antar PREFER_SITE_TAKEOVER="true" vi och AUTOMATED_REGISTER="false".

1. Test 1: Stoppa den primära databasen på nod 1.

   Resurstillståndet innan testet startas:

   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
   

   Kör följande kommandon som <hana sid>adm på hn1-db-0 noden:

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

   Pacemaker identifierar den stoppade HANA-instansen och redundansväxlar till den andra noden. När redundansväxlingen är klar stoppas HANA-instansen hn1-db-0 på noden eftersom Pacemaker inte automatiskt registrerar noden som HANA sekundär.

   Kör följande kommandon för att registrera hn1-db-0 noden som sekundär och rensa den misslyckade resursen:

   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
   

   Resurstillståndet efter testet:

   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
   

2. Test 2: Stoppa den primära databasen på nod 2.

   Resurstillståndet innan testet startas:

   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
   

   Kör följande kommandon som <hana sid>adm på hn1-db-1 noden:

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

   Pacemaker identifierar den stoppade HANA-instansen och redundansväxlar till den andra noden. När redundansväxlingen är klar stoppas HANA-instansen hn1-db-1 på noden eftersom Pacemaker inte automatiskt registrerar noden som HANA sekundär.

   Kör följande kommandon för att registrera hn1-db-1 noden som sekundär och rensa den misslyckade resursen:

   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
   

   Resurstillståndet efter testet:

   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
   

3. Test 3: Krascha den primära databasen på nod 1.

   Resurstillståndet innan testet startas:

   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
   

   Kör följande kommandon som <hana sid>adm på hn1-db-0 noden:

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

   Pacemaker identifierar den dödade HANA-instansen och redundansväxlar till den andra noden. När redundansväxlingen är klar stoppas HANA-instansen hn1-db-0 på noden eftersom Pacemaker inte automatiskt registrerar noden som HANA sekundär.

   Kör följande kommandon för att registrera hn1-db-0 noden som sekundär och rensa den misslyckade resursen:

   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
   

   Resurstillståndet efter testet:

   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
   

4. Test 4: Krascha den primära databasen på nod 2.

   Resurstillståndet innan testet startas:

   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
   

   Kör följande kommandon som <hana sid>adm på hn1-db-1 noden:

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

   Pacemaker identifierar den dödade HANA-instansen och redundansväxlar till den andra noden. När redundansväxlingen är klar stoppas HANA-instansen hn1-db-1 på noden eftersom Pacemaker inte automatiskt registrerar noden som HANA sekundär.

   Kör följande kommandon för att registrera hn1-db-1 noden som sekundär och rensa den misslyckade resursen.

   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
   

   Resurstillståndet efter testet:

   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
   

5. Test 5: Krascha den primära platsnoden (nod 1).

   Resurstillståndet innan testet startas:

   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
   

   Kör följande kommandon som rot på hn1-db-0 noden:

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

   Pacemaker identifierar den avdödade klusternoden och stänger noden. När noden är inhägnad utlöser Pacemaker ett övertagande av HANA-instansen. När den inhägnade noden startas om startar Pacemaker inte automatiskt.

   Kör följande kommandon för att starta Pacemaker, rensa SBD-meddelandena för hn1-db-0 noden, registrera hn1-db-0 noden som sekundär och rensa den misslyckade resursen:

   # 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
   

   Resurstillståndet efter testet:

   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
   

6. Test 6: Krascha den sekundära platsnoden (nod 2).

   Resurstillståndet innan testet startas:

   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
   

   Kör följande kommandon som rot på hn1-db-1 noden:

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

   Pacemaker identifierar den avdödade klusternoden och stänger noden. När noden är inhägnad utlöser Pacemaker ett övertagande av HANA-instansen. När den inhägnade noden startas om startar Pacemaker inte automatiskt.

   Kör följande kommandon för att starta Pacemaker, rensa SBD-meddelandena för hn1-db-1 noden, registrera hn1-db-1 noden som sekundär och rensa den misslyckade resursen:

   # 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
   

   Resurstillståndet efter testet:

   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>
   

7. Test 7: Stoppa den sekundära databasen på nod 2.

   Resurstillståndet innan testet startas:

   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
   

   Kör följande kommandon som <hana sid>adm på hn1-db-1 noden:

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

   Pacemaker identifierar den stoppade HANA-instansen och markerar resursen som misslyckad på hn1-db-1 noden. Pacemaker startar automatiskt om HANA-instansen.

   Kör följande kommando för att rensa det misslyckade tillståndet:

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

   Resurstillståndet efter testet:

   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
   

8. Test 8: Krascha den sekundära databasen på nod 2.

   Resurstillståndet innan testet startas:

   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
   

   Kör följande kommandon som <hana sid>adm på hn1-db-1 noden:

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

   Pacemaker identifierar den dödade HANA-instansen och markerar resursen som misslyckad på hn1-db-1 noden. Kör följande kommando för att rensa det misslyckade tillståndet. Pacemaker startar sedan automatiskt om HANA-instansen.

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

   Resurstillståndet efter testet:

   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
   

9. Test 9: Krascha den sekundära platsnoden (nod 2) som kör den sekundära HANA-databasen.

   Resurstillståndet innan testet startas:

   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
   

   Kör följande kommandon som rot på hn1-db-1 noden:

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

   Pacemaker identifierar den avdödade klusternoden och avgränsar noden. När den inhägnade noden startas om startar Pacemaker inte automatiskt.

   Kör följande kommandon för att starta Pacemaker, rensa SBD-meddelandena för noden och rensa den misslyckade resursen hn1-db-1 :

   # 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
   

   Resurstillståndet efter testet:

   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
   

10. Test 10: Kraschindexserver för primär databas

    Det här testet är endast relevant när du har konfigurerat susChkSrv-kroken enligt beskrivningen i Implementera HANA-resursagenter.

    Resurstillståndet innan testet startas:

    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
    

    Kör följande kommandon som rot på hn1-db-0 noden:

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

    När indexservern avslutas identifierar susChkSrv-kroken händelsen och utlöser en åtgärd för att stänga noden "hn1-db-0" och initiera en uppköpsprocess.

    Kör följande kommandon för att registrera hn1-db-0 noden som sekundär och rensa den misslyckade resursen:

    # 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
    

    Resurstillståndet efter testet:

    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
    

    Du kan köra ett jämförbart testfall genom att orsaka att indexservern på den sekundära noden kraschar. I händelse av indexserverkrasch identifierar susChkSrv-kroken förekomsten och initierar en åtgärd för att avgränsa den sekundära noden.

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