Hoge beschikbaarheid voor SAP HANA op Azure-VM's op SUSE Linux Enterprise Server

Artikel
04/08/2024

Als u hoge beschikbaarheid wilt instellen in een on-premises SAP HANA-implementatie, kunt u SAP HANA-systeemreplicatie of gedeelde opslag gebruiken.

Momenteel is sap HANA-systeemreplicatie in Azure de enige ondersteunde functie voor hoge beschikbaarheid op virtuele Azure-machines (VM's).

SAP HANA-systeemreplicatie bestaat uit één primair knooppunt en ten minste één secundair knooppunt. Wijzigingen in de gegevens op het primaire knooppunt worden synchroon of asynchroon naar het secundaire knooppunt gerepliceerd.

In dit artikel wordt beschreven hoe u de VM's implementeert en configureert, het clusterframework installeert en SAP HANA-systeemreplicatie installeert en configureert.

Lees voordat u begint de volgende SAP-notities en -documenten:

SAP-notitie 1928533. De opmerking bevat:
- De lijst met Azure VM-grootten die worden ondersteund voor de implementatie van SAP-software.
- Belangrijke capaciteitsinformatie voor Azure VM-grootten.
- De ondersteunde COMBINATIES van SAP-software, besturingssysteem (OS) en database.
- De vereiste SAP-kernelversies voor Windows en Linux in Microsoft Azure.
SAP Note 2015553 een lijst met de vereisten voor SAP-ondersteunde SAP-software-implementaties in Azure.
SAP Note 2205917 heeft aanbevolen besturingssysteeminstellingen voor SUSE Linux Enterprise Server 12 (SLES 12) voor SAP-toepassingen.
SAP Note 2684254 heeft aanbevolen besturingssysteeminstellingen voor SUSE Linux Enterprise Server 15 (SLES 15) voor SAP-toepassingen.
SAP Note 2235581 heeft door SAP HANA ondersteunde besturingssystemen
SAP-opmerking 2178632 bevat gedetailleerde informatie over alle metrische bewakingsgegevens die worden gerapporteerd voor SAP in Azure.
SAP-opmerking 2191498 de vereiste VERSIE van de SAP-hostagent voor Linux in Azure heeft.
SAP-opmerking 2243692 informatie heeft over SAP-licenties voor Linux in Azure.
SAP-opmerking 1984787 bevat algemene informatie over SUSE Linux Enterprise Server 12.
SAP-opmerking 1999351 meer informatie over het oplossen van problemen heeft voor de Uitgebreide Bewakingsextensie van Azure voor SAP.
SAP-opmerking 401162 bevat informatie over het voorkomen van 'adres al in gebruik'-fouten bij het instellen van HANA-systeemreplicatie.
Wiki voor SAP Community-ondersteuning bevat alle vereiste SAP-notities voor Linux.
Sap HANA-gecertificeerde IaaS-platformen.
Planning en implementatie van Azure Virtual Machines voor SAP op Linux .
Implementatie van Azure Virtual Machines voor SAP in Linux .
DBMS-implementatie van Azure Virtual Machines voor SAP in Linux .
Aanbevolen procedures voor SUSE Linux Enterprise Server voor SAP Applications 15 en handleidingen voor aanbevolen procedures voor SUSE Linux Enterprise Server voor SAP Applications 12:
- Een voor SAP HANA SR geoptimaliseerde infrastructuur (SLES voor SAP-toepassingen) instellen. De handleiding bevat alle vereiste informatie voor het instellen van SAP HANA-systeemreplicatie voor on-premises ontwikkeling. Gebruik deze handleiding als basislijn.
- Een SAP HANA SR Cost Optimized Infrastructure (SLES for SAP Applications) instellen.

Plannen voor hoge beschikbaarheid van SAP HANA

Als u hoge beschikbaarheid wilt bereiken, installeert u SAP HANA op twee VM's. De gegevens worden gerepliceerd met behulp van HANA-systeemreplicatie.

Diagram met een overzicht van hoge beschikbaarheid van SAP HANA.

De installatie van sap HANA-systeemreplicatie maakt gebruik van een toegewezen virtuele hostnaam en virtuele IP-adressen. In Azure hebt u een load balancer nodig om een virtueel IP-adres te implementeren.

In de voorgaande afbeelding ziet u een voorbeeld van een load balancer met deze configuraties:

Front-end-IP-adres: 10.0.0.13 voor HN1-db
Testpoort: 62503

De infrastructuur voorbereiden

De resourceagent voor SAP HANA is opgenomen in SUSE Linux Enterprise Server voor SAP-toepassingen. Een installatiekopieën voor SUSE Linux Enterprise Server voor SAP-toepassingen 12 of 15 zijn beschikbaar in Azure Marketplace. U kunt de installatiekopieën gebruiken om nieuwe VM's te implementeren.

Virtuele Linux-machines handmatig implementeren via Azure Portal

In dit document wordt ervan uitgegaan dat u al een resourcegroep, Azure Virtual Network en subnet hebt geïmplementeerd.

Virtuele machines implementeren voor SAP HANA. Kies een geschikte SLES-installatiekopieën die worden ondersteund voor het HANA-systeem. U kunt vm's implementeren in een van de beschikbaarheidsopties: virtuele-machineschaalset, beschikbaarheidszone of beschikbaarheidsset.

Belangrijk

Zorg ervoor dat het besturingssysteem dat u selecteert SAP is gecertificeerd voor SAP HANA op de specifieke VM-typen die u in uw implementatie wilt gebruiken. U kunt sap HANA-gecertificeerde VM-typen en hun besturingssysteemreleases opzoeken in GECERTIFICEERDE IAAS-platformen van SAP HANA. Zorg ervoor dat u de details van het VM-type bekijkt om de volledige lijst met door SAP HANA ondersteunde besturingssysteemreleases voor het specifieke VM-type op te halen.

Azure Load Balancer configureren

Tijdens de VM-configuratie hebt u de mogelijkheid om een load balancer te maken of te selecteren in de sectie Netwerken. Volg de onderstaande stappen om de standaard load balancer in te stellen voor het instellen van hoge beschikbaarheid van de HANA-database.

Volg de stappen in Load Balancer maken om een standaard load balancer in te stellen voor een SAP-systeem met hoge beschikbaarheid met behulp van Azure Portal. Houd rekening met de volgende punten tijdens de installatie van de load balancer:

Front-end-IP-configuratie: maak een front-end-IP-adres. Selecteer dezelfde virtuele netwerk- en subnetnaam als uw virtuele databasemachines.
Back-endpool: maak een back-endpool en voeg database-VM's toe.
Regels voor inkomend verkeer: maak een taakverdelingsregel. Volg dezelfde stappen voor beide taakverdelingsregels.
- Front-end-IP-adres: Selecteer een front-end-IP-adres.
- Back-endpool: Selecteer een back-endpool.
- Poorten voor hoge beschikbaarheid: selecteer deze optie.
- Protocol: selecteer TCP.
- Statustest: maak een statustest met de volgende details:
  - Protocol: selecteer TCP.
  - Poort: bijvoorbeeld 625<instance-no.>.
  - Interval: Voer 5 in.
  - Testdrempel: voer 2 in.
- Time-out voor inactiviteit (minuten): voer 30 in.
- Zwevend IP-adres inschakelen: selecteer deze optie.

Notitie

De configuratie-eigenschap numberOfProbesvan de statustest, ook wel bekend als drempelwaarde voor beschadigde status in de portal, wordt niet gerespecteerd. Als u het aantal geslaagde of mislukte opeenvolgende tests wilt bepalen, stelt u de eigenschap probeThreshold in op 2. Het is momenteel niet mogelijk om deze eigenschap in te stellen met behulp van Azure Portal, dus gebruik de Azure CLI of de PowerShell-opdracht.

# 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

Uitvouwen om volledige CLI-code weer te geven

# 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

Uitvouwen om volledige PowerShell-code weer te geven

# 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

Lees voor meer informatie over de vereiste poorten voor SAP HANA het hoofdstuk Verbinding maken ies voor tenantdatabases in de handleiding voor SAP HANA-tenantdatabases of SAP Note 2388694.

Belangrijk

Een zwevend IP-adres wordt niet ondersteund op een secundaire IP-configuratie van een netwerkinterfacekaart (NIC) in scenario's voor taakverdeling. Zie Azure Load Balancer-beperkingen voor meer informatie. Als u een ander IP-adres voor de virtuele machine nodig hebt, implementeert u een tweede NIC.

Notitie

Wanneer VM's met geen openbare IP-adressen worden geplaatst in de back-endpool van een intern (geen openbaar IP-adres) standaardexemplaren van Azure Load Balancer, is de standaardconfiguratie geen uitgaande internetverbinding. U kunt extra stappen uitvoeren om routering naar openbare eindpunten toe te staan. Zie Openbare eindpuntconnectiviteit voor VM's met behulp van Azure Standard Load Balancer in scenario's met hoge beschikbaarheid van SAP voor meer informatie over het bereiken van uitgaande connectiviteit.

Belangrijk

Schakel TCP-tijdstempels niet in op Azure-VM's die achter Azure Load Balancer worden geplaatst. Als u TCP-tijdstempels inschakelt, mislukken de statustests. Stel de parameter in net.ipv4.tcp_timestamps op 0. Zie Statustests van Load Balancer of SAP-notitie 2382421 voor meer informatie.
Werk saptune-versie bij naar 3.1.1 of hoger om te voorkomen dat saptune de handmatig ingestelde net.ipv4.tcp_timestamps waarde 01wijzigt in. Zie saptune 3.1.1 – Moet ik bijwerken? voor meer informatie.

Een Pacemaker-cluster maken

Volg de stappen in Pacemaker instellen op SUSE Linux Enterprise Server in Azure om een eenvoudig Pacemaker-cluster te maken voor deze HANA-server. U kunt hetzelfde Pacemaker-cluster gebruiken voor SAP HANA en SAP NetWeaver (A)SCS.

SAP HANA installeren

In de stappen in deze sectie worden de volgende voorvoegsels gebruikt:

[A]: De stap is van toepassing op alle knooppunten.
[1]: De stap is alleen van toepassing op knooppunt 1.
[2]: De stap is alleen van toepassing op knooppunt 2 van het Pacemaker-cluster.

Vervang <placeholders> door de waarden voor uw SAP HANA-installatie.

[A] Stel de schijfindeling in met behulp van Logical Volume Manager (LVM).

U wordt aangeraden LVM te gebruiken voor volumes die gegevens en logboekbestanden opslaan. In het volgende voorbeeld wordt ervan uitgegaan dat de VIRTUELE machines vier gekoppelde gegevensschijven hebben die worden gebruikt om twee volumes te maken.
1. Voer deze opdracht uit om alle beschikbare schijven weer te geven:
```
/dev/disk/azure/scsi1/lun*
```
  Voorbeelduitvoer:
```
/dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2  /dev/disk/azure/scsi1/lun3
```
2. Maak fysieke volumes voor alle schijven die u wilt gebruiken:
```
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. Maak een volumegroep voor de gegevensbestanden. Gebruik één volumegroep voor de logboekbestanden en één volumegroep voor de gedeelde map van 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. Maak de logische volumes.
  
  Er wordt een lineair volume gemaakt wanneer u zonder de -i schakelaar gebruiktlvcreate. We raden u aan om een gestreept volume te maken voor betere I/O-prestaties. Lijn de stripegrootten uit op de waarden die worden beschreven in SAP HANA VM-opslagconfiguraties. Het -i argument moet het aantal onderliggende fysieke volumes zijn en het -I argument is de streepgrootte.
  
  Als er bijvoorbeeld twee fysieke volumes worden gebruikt voor het gegevensvolume, wordt het -i schakelargument ingesteld op 2 en is de stripegrootte voor het gegevensvolume 256KiB. Er wordt één fysiek volume gebruikt voor het logboekvolume, dus er worden geen -i-I switches expliciet gebruikt voor de logboekvolumeopdrachten.
  
  Belangrijk
  
  Wanneer u meer dan één fysiek volume gebruikt voor elk gegevensvolume, logboekvolume of gedeeld volume, gebruikt u de -i schakeloptie en stelt u het aantal onderliggende fysieke volumes in. Wanneer u een gestreept volume maakt, gebruikt u de -I schakeloptie om de stripegrootte op te geven.
  
  Zie SAP HANA VM-opslagconfiguraties voor aanbevolen opslagconfiguraties, inclusief stripegrootten en het aantal schijven.
```
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. Maak de koppelmappen en kopieer de UUID (Universally Unique Identifier) van alle logische volumes:
```
sudo mkdir -p /hana/data/<HANA SID>
sudo mkdir -p /hana/log/<HANA SID>
sudo mkdir -p /hana/shared/<HANA SID>
# Write down the ID of /dev/vg_hana_data_<HANA SID>/hana_data, /dev/vg_hana_log_<HANA SID>/hana_log, and /dev/vg_hana_shared_<HANA SID>/hana_shared
sudo blkid
```
6. Bewerk het bestand /etc/fstab om vermeldingen voor de drie logische volumes te maken fstab :
```
sudo vi /etc/fstab
```
7. Voeg de volgende regels in het bestand /etc/fstab in:
```
/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. Koppel de nieuwe volumes:
```
sudo mount -a
```
[A] Stel de schijfindeling in met behulp van gewone schijven.

Voor demosystemen kunt u uw HANA-gegevens en logboekbestanden op één schijf plaatsen.
1. Maak een partitie op /dev/disk/azure/scsi1/lun0 en maak deze op met behulp van 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. Voeg deze regel in het bestand /etc/fstab in:
```
/dev/disk/by-uuid/<UUID> /hana xfs  defaults,nofail  0  2
```
3. Maak de doelmap en koppel de schijf:
```
sudo mkdir /hana
sudo mount -a
```
[A] Hostnaamomzetting instellen voor alle hosts.

U kunt een DNS-server gebruiken of het bestand /etc/hosts op alle knooppunten wijzigen. In dit voorbeeld ziet u hoe u het bestand /etc/hosts gebruikt. Vervang de IP-adressen en de hostnamen in de volgende opdrachten.
1. Bewerk het bestand /etc/hosts :
```
sudo vi /etc/hosts
```
2. Voeg de volgende regels in het bestand /etc/hosts in. Wijzig de IP-adressen en hostnamen zodat deze overeenkomen met uw omgeving.
```
10.0.0.5 hn1-db-0
10.0.0.6 hn1-db-1
```
[A] Installeer de SAP HANA-pakketten met hoge beschikbaarheid:
- Voer de volgende opdracht uit om de pakketten met hoge beschikbaarheid te installeren:
```
sudo zypper install SAPHanaSR
```
Als u SAP HANA-systeemreplicatie wilt installeren, raadpleegt u hoofdstuk 4 in de handleiding voor scenario's die zijn geoptimaliseerd voor SAP HANA-prestaties.
[A] Voer het hdblcm-programma uit vanaf de HANA-installatiemedia.

Wanneer u hierom wordt gevraagd, voert u de volgende waarden in:
1. Kies de installatie: Voer 1 in.
2. Selecteer extra onderdelen voor installatie: Voer 1 in.
3. Voer het installatiepad in: Voer /hana/shared in en selecteer Enter.
4. Voer de naam van de lokale host in: Voer .. in en selecteer Enter.
5. Wilt u extra hosts toevoegen aan het systeem? (y/n): Voer n in en selecteer Enter.
6. Voer de SAP HANA-systeem-id in: Voer uw HANA-SID in.
7. Voer het exemplaarnummer in: Voer het HANA-exemplaarnummer in. Als u hebt geïmplementeerd met behulp van de Azure-sjabloon of als u de sectie voor handmatige implementatie van dit artikel hebt gevolgd, voert u 03 in.
8. Selecteer de databasemodus/Voer de index in: Voer 1 in of selecteer 1 en selecteer Enter.
9. Selecteer het systeemgebruik/Voer de index in: selecteer de waarde van het systeemgebruik 4.
10. Voer de locatie van de gegevensvolumes in: Voer /hana/data/<HANA SID> in en selecteer Enter.
11. Voer de locatie van de logboekvolumes in: Voer /hana/log/<HANA SID> in en selecteer Enter.
12. Maximale geheugentoewijzing beperken?: voer n in en selecteer Enter.
13. Voer de naam van de certificaathost voor de host in: Voer ... in en selecteer Enter.
14. Voer het wachtwoord van de SAP-hostagentgebruiker (sapadm) in: voer het gebruikerswachtwoord van de hostagent in en selecteer Vervolgens Enter.
15. Bevestig het wachtwoord van de SAP-hostagentgebruiker (sapadm): voer het gebruikerswachtwoord van de hostagent opnieuw in en selecteer Vervolgens Enter.
16. Voer het wachtwoord van de systeembeheerder (hdbadm) in: voer het wachtwoord van de systeembeheerder in en selecteer Vervolgens Enter.
17. Bevestig het wachtwoord van de systeembeheerder (hdbadm): voer het wachtwoord van de systeembeheerder opnieuw in en selecteer Vervolgens Enter.
18. Voer de basismap van de systeembeheerder in: Voer /usr/sap/<HANA SID>/home in en selecteer Enter.
19. Voer de aanmeldingsshell van de systeembeheerder in: Voer /bin/sh in en selecteer Enter.
20. Voer de gebruikers-id van de systeembeheerder in: Voer 1001 in en selecteer Enter.
21. Voer de id in van de gebruikersgroep (sapsys): Voer 79 in en selecteer Enter.
22. Voer het wachtwoord van de databasegebruiker (SYSTEM) in: voer het wachtwoord van de databasegebruiker in en selecteer vervolgens Enter.
23. Bevestig het wachtwoord van de databasegebruiker (SYSTEM): voer het wachtwoord van de databasegebruiker opnieuw in en selecteer vervolgens Enter.
24. Start het systeem opnieuw op nadat de computer opnieuw is opgestart? (y/n): Voer n in en selecteer Enter.
25. Wilt u doorgaan? (y/n): Valideer de samenvatting. Voer y in om door te gaan.
[A] Werk de SAP-hostagent bij.

Download het meest recente archief van de SAP-hostagent vanuit het SAP Software Center. Voer de volgende opdracht uit om de agent bij te werken. Vervang het pad naar het archief om te verwijzen naar het bestand dat u hebt gedownload.
```
sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP host agent SAR>
```

SAP HANA 2.0-systeemreplicatie configureren

In de stappen in deze sectie worden de volgende voorvoegsels gebruikt:

[A]: De stap is van toepassing op alle knooppunten.
[1]: De stap is alleen van toepassing op knooppunt 1.
[2]: De stap is alleen van toepassing op knooppunt 2 van het Pacemaker-cluster.

Vervang <placeholders> door de waarden voor uw SAP HANA-installatie.

[1] Maak de tenantdatabase.

Als u SAP HANA 2.0 of SAP HANA MDC gebruikt, maakt u een tenantdatabase voor uw SAP NetWeaver-systeem.

Voer de volgende opdracht uit als <HANA SID>adm:
```
hdbsql -u SYSTEM -p "<password>" -i <instance number> -d SYSTEMDB 'CREATE DATABASE <SAP SID> SYSTEM USER PASSWORD "<password>"'
```

[1] Systeemreplicatie configureren op het eerste knooppunt:

Maak eerst een back-up van de databases als <HANA SID>adm:

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

Kopieer vervolgens de PKI-bestanden (Public Key Infrastructure) van het systeem naar de secundaire site:

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/

Maak de primaire site:

hdbnsutil -sr_enable --name=<site 1>

[2] Systeemreplicatie configureren op het tweede knooppunt:

Registreer het tweede knooppunt om de systeemreplicatie te starten.

Voer de volgende opdracht uit als <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>

SAP HANA 1.0-systeemreplicatie configureren

In de stappen in deze sectie worden de volgende voorvoegsels gebruikt:

[A]: De stap is van toepassing op alle knooppunten.
[1]: De stap is alleen van toepassing op knooppunt 1.
[2]: De stap is alleen van toepassing op knooppunt 2 van het Pacemaker-cluster.

Vervang <placeholders> door de waarden voor uw SAP HANA-installatie.

[1] Maak de vereiste gebruikers.

Voer de volgende opdracht uit als root:

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

[A] Maak de sleutelarchiefvermelding.

Voer de volgende opdracht uit als hoofdmap om een nieuwe sleutelarchiefvermelding te maken:

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

[1] Maak een back-up van de database.

Maak een back-up van de databases als hoofdmap:

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

Als u een installatie met meerdere tenants gebruikt, maakt u ook een back-up van de tenantdatabase:

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

[1] Configureer systeemreplicatie op het eerste knooppunt.

Maak de primaire site als <HANA SID>adm:
```
su - hdbadm
hdbnsutil -sr_enable --name=<site 1>
```

[2] Configureer systeemreplicatie op het secundaire knooppunt.

Registreer de secundaire site als <HANA SID>adm:

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

HANA-hooks SAPHanaSR en susChkSrv implementeren

In deze belangrijke stap optimaliseert u de integratie met het cluster en verbetert u de detectie wanneer een clusterfailover nodig is. U wordt ten zeerste aangeraden de SAPHanaSR Python-hook te configureren. Voor HANA 2.0 SP5 en hoger raden we u aan de SAPHanaSR-hook en de susChkSrv-hook te implementeren.

De susChkSrv hook breidt de functionaliteit van de belangrijkste SAPHanaSR HA-provider uit. Het werkt wanneer het HANA-proces hdbindexserver vastloopt. Als één proces vastloopt, probeert HANA het meestal opnieuw op te starten. Het opnieuw opstarten van het indexserverproces kan lang duren, waarbij de HANA-database niet reageert.

Als susChkSrv is geïmplementeerd, wordt er een onmiddellijke en configureerbare actie uitgevoerd. De actie activeert een failover in de geconfigureerde time-outperiode in plaats van te wachten tot het hdbindexserverproces opnieuw wordt opgestart op hetzelfde knooppunt.

[A] Installeer de HANA-systeemreplicatiehook. De hook moet worden geïnstalleerd op beide HANA-databaseknooppunten.

Tip

De SAPHanaSR Python-hook kan alleen worden geïmplementeerd voor HANA 2.0. Het SAPHanaSR-pakket moet ten minste versie 0.153 zijn.

Voor de susChkSrv Python-hook is SAP HANA 2.0 SP5 vereist en moet de SAPHanaSR-versie 0.161.1_BF of hoger zijn geïnstalleerd.
1. Stop HANA op beide knooppunten.
  
  Voer de volgende code uit als <sapsid>adm:
```
sapcontrol -nr <instance number> -function StopSystem
```
2. Pas global.ini aan op elk clusterknooppunt. Als niet aan de vereisten voor de susChkSrv-hook wordt voldaan, verwijdert u het hele [ha_dr_provider_suschksrv] blok uit de volgende parameters.
  
  U kunt het gedrag aanpassen met behulp van susChkSrv de action_on_lost parameter. Geldige waarden zijn [ ignorekill | fencestop | | ].
```
# add to global.ini
[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR
execution_order = 1

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

[trace]
ha_dr_saphanasr = info
```
  Als u verwijst naar de standaardlocatie /usr/share/SAPHanaSR , wordt de Python-hookcode automatisch bijgewerkt via besturingssysteemupdates of pakketupdates. HANA gebruikt de hookcode-updates wanneer deze opnieuw wordt opgestart. Met een optioneel eigen pad, zoals /hana/shared/myHooks, kunt u besturingssysteemupdates loskoppelen van de hookversie die u gebruikt.
[A] Voor het cluster is sudoers-configuratie vereist op elk clusterknooppunt voor <SAP SID>adm. In dit voorbeeld wordt dit bereikt door een nieuw bestand te maken.

Voer de volgende opdracht uit als root:
```
 cat << EOF > /etc/sudoers.d/20-saphana
 # Needed for SAPHanaSR and susChkSrv Python hooks
 hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
 hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=HN1 --case=fenceMe
 EOF
```
Zie HANA HA/DR-providers instellen voor meer informatie over het implementeren van de SAP HANA-systeemreplicatiehook.
[A] START SAP HANA op beide knooppunten.

Voer de volgende opdracht uit als <SAP SID>adm:
```
 sapcontrol -nr <instance number> -function StartSystem 
```

[1] Controleer de hookinstallatie.

Voer de volgende opdracht uit als <SAP SID>adm op de actieve HANA-systeemreplicatiesite:

 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

Controleer de installatie van de susChkSrv-hook.

Voer de volgende opdracht uit als <SAP SID>adm op alle HANA-VM's:

 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)

SAP HANA-clusterbronnen maken

Maak eerst de HANA-topologie.

Voer de volgende opdrachten uit op een van de Pacemaker-clusterknooppunten:

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"

Maak vervolgens de HANA-resources:

Belangrijk

In recente tests netcat reageert u niet meer op aanvragen vanwege een achterstand en vanwege de beperking van het verwerken van slechts één verbinding. De netcat resource luistert niet meer naar de Azure Load Balancer-aanvragen en het zwevende IP-adres is niet meer beschikbaar.

Voor bestaande Pacemaker-clusters raden we u eerder aan om te vervangen door netcatsocat. Op dit moment wordt u aangeraden de azure-lb resourceagent te gebruiken, die deel uitmaakt van een pakket resource-agents. De volgende pakketversies zijn vereist:

Voor SLES 12 SP4/SP5 moet de versie ten minste resource-agents-4.3.018.a7fb5035-3.30.1 zijn.
Voor SLES 15/15 SP1 moet de versie ten minste resource-agents-4.3.0184.6ee15eb2-4.13.1 zijn.

Voor het aanbrengen van deze wijziging is een korte downtime vereist.

Als uw configuratie al is gewijzigd voor socat bestaande Pacemaker-clusters, zoals beschreven in Azure Load Balancer-detectiebeveiliging, hoeft u niet onmiddellijk over te schakelen naar de azure-lb resourceagent.

Notitie

Dit artikel bevat verwijzingen naar termen die Microsoft niet meer gebruikt. Wanneer deze voorwaarden uit de software worden verwijderd, worden deze uit dit artikel verwijderd.

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

sudo crm configure primitive rsc_SAPHana_<HANA SID>_HDB<instance number> ocf:suse:SAPHana \
  operations \$id="rsc_sap_<HANA SID>_HDB<instance number>-operations" \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op monitor interval="60" role="Master" timeout="700" \
  op monitor interval="61" role="Slave" timeout="700" \
  params SID="<HANA SID>" InstanceNumber="<instance number>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

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

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

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

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

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

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

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

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

sudo crm configure property priority-fencing-delay=30

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

Belangrijk

We raden u aan deze instelling alleen in te false stellen AUTOMATED_REGISTER wanneer u grondige failovertests voltooit, om te voorkomen dat een mislukt primair exemplaar automatisch wordt geregistreerd als secundair exemplaar. Wanneer de failovertests zijn voltooid, stelt u deze in op AUTOMATED_REGISTERtrue, zodat de systeemreplicatie na overname automatisch wordt hervat.

Zorg ervoor dat de clusterstatus is OK en of alle resources zijn gestart. Het maakt niet uit op welk knooppunt de resources worden uitgevoerd.

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

Systeemreplicatie met actief/lezen-ingeschakeld HANA configureren in een Pacemaker-cluster

In SAP HANA 2.0 SPS 01 en latere versies staat SAP een actieve/lees-enabled installatie toe voor SAP HANA-systeemreplicatie. In dit scenario kunnen de secundaire systemen van SAP HANA-systeemreplicatie actief worden gebruikt voor leesintensieve workloads.

Ter ondersteuning van deze installatie in een cluster is een tweede virtueel IP-adres vereist, zodat clients toegang hebben tot de secundaire SAP HANA-database met leestoegang. Om ervoor te zorgen dat de secundaire replicatiesite na een overname nog steeds toegankelijk is, moet het cluster het virtuele IP-adres verplaatsen met de secundaire van de SAPHana-resource.

In deze sectie worden de extra stappen beschreven die nodig zijn voor het beheren van een HANA-systeemreplicatie met actieve/leesfunctionaliteit in een SUSE-cluster met hoge beschikbaarheid dat gebruikmaakt van een tweede virtueel IP-adres.

Voordat u verdergaat, moet u ervoor zorgen dat u het SUSE-cluster met hoge beschikbaarheid volledig hebt geconfigureerd waarmee de SAP HANA-database wordt beheerd, zoals beschreven in eerdere secties.

Diagram met een voorbeeld van hoge beschikbaarheid van SAP HANA met een secundair IP-adres met leesfunctionaliteit.

De load balancer instellen voor systeemreplicatie met actieve/leesfuncties

Als u verder wilt gaan met extra stappen voor het inrichten van het tweede virtuele IP-adres, moet u Ervoor zorgen dat u Azure Load Balancer hebt geconfigureerd zoals beschreven in Virtuele Linux-machines handmatig implementeren via Azure Portal.

Voer voor de standard load balancer deze extra stappen uit op dezelfde load balancer die u eerder hebt gemaakt.

Maak een tweede front-end-IP-adresgroep:
1. Open de load balancer, selecteer front-end-IP-adresgroep en selecteer Toevoegen.
2. Voer de naam in van de tweede front-end-IP-adresgroep (bijvoorbeeld hana-secondaryIP).
3. Stel de toewijzing in op Statisch en voer het IP-adres in (bijvoorbeeld 10.0.0.14).
4. Selecteer OK.
5. Nadat de nieuwe front-end-IP-adresgroep is gemaakt, noteert u het front-end-IP-adres.
Een statustest maken:
1. Selecteer in de load balancer statustests en selecteer Toevoegen.
2. Voer de naam in van de nieuwe statustest (bijvoorbeeld hana-secondaryhp).
3. Selecteer TCP als protocol en poort 626-exemplaarnummer<>. Houd de intervalwaarde ingesteld op 5 en de drempelwaarde voor beschadigde status is ingesteld op 2.
4. Selecteer OK.
Maak de taakverdelingsregels:
1. Selecteer taakverdelingsregels in de load balancer en selecteer Toevoegen.
2. Voer de naam in van de nieuwe load balancer-regel (bijvoorbeeld hana-secondarylb).
3. Selecteer het front-end-IP-adres, de back-endpool en de statustest die u eerder hebt gemaakt (bijvoorbeeld hana-secondaryIP, hana-backend en hana-secondaryhp).
4. Selecteer HA-poorten.
5. Verhoog de time-out voor inactiviteit tot 30 minuten.
6. Zorg ervoor dat u zwevend IP-adres inschakelt.
7. Selecteer OK.

HANA-systeemreplicatie met actieve/leesfunctionaliteit instellen

De stappen voor het configureren van HANA-systeemreplicatie worden beschreven in Sap HANA 2.0-systeemreplicatie configureren. Als u een secundair scenario met leesfunctionaliteit implementeert en u systeemreplicatie instelt op het tweede knooppunt, voert u de volgende opdracht uit als <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> --operationMode=logreplay_readaccess

Een secundaire virtuele IP-adresresource toevoegen

U kunt het tweede virtuele IP-adres en de juiste colocatiebeperking instellen met behulp van de volgende opdrachten:

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

Zorg ervoor dat de clusterstatus is OK en of alle resources zijn gestart. Het tweede virtuele IP-adres wordt uitgevoerd op de secundaire site, samen met de secundaire SAPHana-resource.

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

In de volgende sectie wordt de typische set failovertests beschreven die moeten worden uitgevoerd.

Overwegingen bij het testen van een HANA-cluster dat is geconfigureerd met een secundaire met leesfunctionaliteit:

Wanneer u de SAPHana_<HANA SID>_HDB<instance number> clusterresource naar hn1-db-1migreert, wordt het tweede virtuele IP-adres verplaatst naar hn1-db-0. Als u hebt geconfigureerd AUTOMATED_REGISTER="false" en HANA-systeemreplicatie niet automatisch wordt geregistreerd, wordt het tweede virtuele IP-adres uitgevoerd hn1-db-0 omdat de server beschikbaar is en clusterservices online zijn.
Wanneer u een servercrash test, worden de tweede virtuele IP-resources (rsc_secip_<HANA SID>_HDB<instance number>) en de Azure Load Balancer-poortresource (rsc_secnc_<HANA SID>_HDB<instance number>) uitgevoerd op de primaire server naast de primaire virtuele IP-resources. Terwijl de secundaire server offline is, maken de toepassingen die zijn verbonden met een HANA-database met leesfunctionaliteit, verbinding met de primaire HANA-database. Het gedrag wordt verwacht omdat u niet wilt dat toepassingen die zijn verbonden met een HANA-database met leesfunctionaliteit, niet toegankelijk zijn terwijl de secundaire server niet beschikbaar is.
Wanneer de secundaire server beschikbaar is en de clusterservices online zijn, worden de tweede virtuele IP- en poortresources automatisch naar de secundaire server verplaatst, ook al is HANA-systeemreplicatie mogelijk niet geregistreerd als secundair. Zorg ervoor dat u de secundaire HANA-database registreert als GELEZEN voordat u clusterservices op die server start. U kunt de clusterresource van het HANA-exemplaar configureren om de secundaire resource automatisch te registreren door de parameter AUTOMATED_REGISTER="true"in te stellen.
Tijdens failover en terugval kunnen de bestaande verbindingen voor toepassingen, die vervolgens het tweede virtuele IP-adres gebruiken om verbinding te maken met de HANA-database, worden onderbroken.

De clusterinstallatie testen

In deze sectie wordt beschreven hoe u uw installatie kunt testen. Bij elke test wordt ervan uitgegaan dat u bent aangemeld als hoofdmap en dat de SAP HANA-master wordt uitgevoerd op de hn1-db-0 virtuele machine.

De migratie testen

Voordat u de test start, moet u ervoor zorgen dat Pacemaker geen mislukte actie (uitvoering crm_mon -r) heeft, dat er geen onverwachte locatiebeperkingen zijn (bijvoorbeeld resten van een migratietest) en dat HANA de synchronisatiestatus heeft, bijvoorbeeld door uit te voeren 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

U kunt het SAP HANA-hoofdknooppunt migreren door de volgende opdracht uit te voeren:

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

Het cluster migreert het SAP HANA-hoofdknooppunt en de groep met het virtuele IP-adres naar hn1-db-1.

Wanneer de migratie is voltooid, ziet de crm_mon -r uitvoer er als volgt uit:

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

Het AUTOMATED_REGISTER="false"cluster start de mislukte HANA-database niet opnieuw op of registreert deze niet bij de nieuwe primaire database op hn1-db-0. In dit geval configureert u het HANA-exemplaar als secundair door deze opdracht uit te voeren:

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>

Met de migratie worden locatiebeperkingen gemaakt die opnieuw moeten worden verwijderd:

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

U moet ook de status van de secundaire knooppuntresource opschonen:

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

Bewaak de status van de HANA-resource met behulp van crm_mon -r. Wanneer HANA is gestart hn1-db-0, ziet de uitvoer er als volgt uit:

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

Netwerkcommunicatie blokkeren

Resourcestatus voordat u de test start:

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

Voer een firewallregel uit om de communicatie op een van de knooppunten te blokkeren.

# 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

Wanneer clusterknooppunten niet met elkaar kunnen communiceren, bestaat er een risico op een split-brain-scenario. In dergelijke situaties proberen clusterknooppunten elkaar tegelijkertijd te omheinen, wat resulteert in heksenrace.

Wanneer u een fencing-apparaat configureert, is het raadzaam om de eigenschap te configureren pcmk_delay_max . In het geval van split-brain scenario introduceert het cluster dus een willekeurige vertraging tot aan de pcmk_delay_max waarde, aan de afschermingsactie op elk knooppunt. Het knooppunt met de kortste vertraging wordt geselecteerd voor fencing.

Om ervoor te zorgen dat het knooppunt waarop de HANA-master wordt uitgevoerd, prioriteit krijgt en de heksrace wint in een split brain-scenario, is het raadzaam om de eigenschap in te stellen priority-fencing-delay in de clusterconfiguratie. Door de eigenschap priority-fencing-delay in te schakelen, kan het cluster een extra vertraging veroorzaken in de fencing-actie specifiek op het knooppunt dat als host fungeert voor de HANA-hoofdresource, zodat het knooppunt de omheiningsrace kan winnen.

Voer de onderstaande opdracht uit om de firewallregel te verwijderen.

# 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

SBD-fencing testen

U kunt de installatie van SBD testen door het inquisitor-proces te doden:

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

Het <HANA SID>-db-<database 1> clusterknooppunt wordt opnieuw opgestart. De Pacemaker-service wordt mogelijk niet opnieuw opgestart. Zorg ervoor dat u het opnieuw start.

Een handmatige failover testen

U kunt een handmatige failover testen door de Pacemaker-service op het hn1-db-0 knooppunt te stoppen:

service pacemaker stop

Na de failover kunt u de service opnieuw starten. Als u instelt AUTOMATED_REGISTER="false", kan de SAP HANA-resource op het hn1-db-0 knooppunt niet worden gestart als secundair.

In dit geval configureert u het HANA-exemplaar als secundair door deze opdracht uit te voeren:

service pacemaker start
su - <hana sid>adm

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

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

SUSE-tests

Belangrijk

Zorg ervoor dat het besturingssysteem dat u selecteert SAP is gecertificeerd voor SAP HANA op de specifieke VM-typen die u wilt gebruiken. U kunt sap HANA-gecertificeerde VM-typen en hun besturingssysteemreleases opzoeken in GECERTIFICEERDE IAAS-platformen van SAP HANA. Bekijk de details van het VM-type dat u wilt gebruiken om de volledige lijst met door SAP HANA ondersteunde besturingssysteemreleases voor dat VM-type op te halen.

Voer alle testcases uit die worden vermeld in de handleiding scenario voor SAP HANA SR Performance Optimized Scenario of SAP HANA SR Cost Optimized Scenario, afhankelijk van uw scenario. U vindt de handleidingen in SLES voor best practices voor SAP.

De volgende tests zijn een kopie van de testbeschrijvingen van de handleiding SAP HANA SR Performance Optimized Scenario SUSE Linux Enterprise Server for SAP Applications 12 SP1. Lees ook de handleiding zelf voor een actuele versie. Zorg er altijd voor dat HANA synchroon is voordat u de test start en zorg ervoor dat de Pacemaker-configuratie juist is.

In de volgende testbeschrijvingen gaan we ervan uit dat PREFER_SITE_TAKEOVER="true" en AUTOMATED_REGISTER="false".

Notitie

De volgende tests zijn ontworpen om op volgorde te worden uitgevoerd. Elke test is afhankelijk van de afsluitstatus van de voorgaande test.

Test 1: Stop de primaire database op knooppunt 1.

De resourcestatus voordat u de test start:

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

Voer de volgende opdrachten uit als <hana sid>adm op het hn1-db-0 knooppunt:

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

Pacemaker detecteert het gestopte HANA-exemplaar en voert een failover uit naar het andere knooppunt. Wanneer de failover is voltooid, wordt het HANA-exemplaar op het hn1-db-0 knooppunt gestopt omdat Pacemaker het knooppunt niet automatisch registreert als secundaire HANA.

Voer de volgende opdrachten uit om het hn1-db-0 knooppunt als secundaire te registreren en de mislukte resource op te schonen:

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

De resourcestatus na de test:

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

Test 2: Stop de primaire database op knooppunt 2.

De resourcestatus voordat u de test start:

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

Voer de volgende opdrachten uit als <hana sid>adm op het hn1-db-1 knooppunt:

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

Pacemaker detecteert het gestopte HANA-exemplaar en voert een failover uit naar het andere knooppunt. Wanneer de failover is voltooid, wordt het HANA-exemplaar op het hn1-db-1 knooppunt gestopt omdat Pacemaker het knooppunt niet automatisch registreert als secundaire HANA.

Voer de volgende opdrachten uit om het hn1-db-1 knooppunt als secundaire te registreren en de mislukte resource op te schonen:

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

De resourcestatus na de test:

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

Test 3: Crash de primaire database op knooppunt 1.

De resourcestatus voordat u de test start:

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

Voer de volgende opdrachten uit als <hana sid>adm op het hn1-db-0 knooppunt:

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

Pacemaker detecteert het vermoorde HANA-exemplaar en voert een failover uit naar het andere knooppunt. Wanneer de failover is voltooid, wordt het HANA-exemplaar op het hn1-db-0 knooppunt gestopt omdat Pacemaker het knooppunt niet automatisch registreert als secundaire HANA.

Voer de volgende opdrachten uit om het hn1-db-0 knooppunt als secundaire te registreren en de mislukte resource op te schonen:

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

De resourcestatus na de test:

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

Test 4: Crash de primaire database op knooppunt 2.

De resourcestatus voordat u de test start:

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

Voer de volgende opdrachten uit als <hana sid>adm op het hn1-db-1 knooppunt:

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

Pacemaker detecteert het vermoorde HANA-exemplaar en voert een failover uit naar het andere knooppunt. Wanneer de failover is voltooid, wordt het HANA-exemplaar op het hn1-db-1 knooppunt gestopt omdat Pacemaker het knooppunt niet automatisch registreert als secundaire HANA.

Voer de volgende opdrachten uit om het hn1-db-1 knooppunt als secundaire te registreren en de mislukte resource op te schonen.

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

De resourcestatus na de test:

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

Test 5: crash het primaire siteknooppunt (knooppunt 1).

De resourcestatus voordat u de test start:

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

Voer de volgende opdrachten uit als root op het hn1-db-0 knooppunt:

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

Pacemaker detecteert het vermoorde clusterknooppunt en hekst het knooppunt. Wanneer het knooppunt is omheind, activeert Pacemaker een overname van het HANA-exemplaar. Wanneer het omheinde knooppunt opnieuw wordt opgestart, wordt Pacemaker niet automatisch gestart.

Voer de volgende opdrachten uit om Pacemaker te starten, de SBD-berichten voor het hn1-db-0 knooppunt op te schonen, het hn1-db-0 knooppunt als secundair te registreren en de mislukte resource op te schonen:

# 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

De resourcestatus na de test:

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

Test 6: crash het secundaire siteknooppunt (knooppunt 2).

De resourcestatus voordat u de test start:

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

Voer de volgende opdrachten uit als root op het hn1-db-1 knooppunt:

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

Voer de volgende opdrachten uit om Pacemaker te starten, de SBD-berichten voor het hn1-db-1 knooppunt op te schonen, het hn1-db-1 knooppunt als secundair te registreren en de mislukte resource op te schonen:

# 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

De resourcestatus na de test:

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

Test 7: Stop de secundaire database op knooppunt 2.

De resourcestatus voordat u de test start:

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

Voer de volgende opdrachten uit als <hana sid>adm op het hn1-db-1 knooppunt:

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

Pacemaker detecteert het gestopte HANA-exemplaar en markeert de resource als mislukt op het hn1-db-1 knooppunt. Pacemaker start het HANA-exemplaar automatisch opnieuw op.

Voer de volgende opdracht uit om de status Mislukt op te schonen:

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

De resourcestatus na de test:

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

Test 8: Crash de secundaire database op knooppunt 2.

De resourcestatus voordat u de test start:

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

Voer de volgende opdrachten uit als <hana sid>adm op het hn1-db-1 knooppunt:

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

Pacemaker detecteert het vermoorde HANA-exemplaar en markeert de resource als mislukt op het hn1-db-1 knooppunt. Voer de volgende opdracht uit om de status Mislukt op te schonen. Pacemaker start vervolgens automatisch het HANA-exemplaar opnieuw op.

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

De resourcestatus na de test:

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

Test 9: crash het secundaire siteknooppunt (knooppunt 2) waarop de secundaire HANA-database wordt uitgevoerd.

De resourcestatus voordat u de test start:

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

Voer de volgende opdrachten uit als root op het hn1-db-1 knooppunt:

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

Pacemaker detecteert het vermoorde clusterknooppunt en omheining van het knooppunt. Wanneer het omheinde knooppunt opnieuw wordt opgestart, wordt Pacemaker niet automatisch gestart.

Voer de volgende opdrachten uit om Pacemaker te starten, de SBD-berichten voor het hn1-db-1 knooppunt op te schonen en de mislukte resource op te schonen:

# 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

De resourcestatus na de test:

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

Test 10: crash primaire databaseindexserver

Deze test is alleen relevant wanneer u de susChkSrv-hook hebt ingesteld, zoals wordt beschreven in Implement HANA hooks SAPHanaSR en susChkSrv.

De resourcestatus voordat u de test start:

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

Voer de volgende opdrachten uit als root op het hn1-db-0 knooppunt:

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

Wanneer de indexserver wordt beëindigd, detecteert de susChkSrv-hook de gebeurtenis en activeert u een actie om het hn1-db-0-knooppunt te omheinen en start u een overnameproces.

Voer de volgende opdrachten uit om het knooppunt als secundaire te registreren hn1-db-0 en de mislukte resource op te schonen:

# 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

De resourcestatus na de test:

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

U kunt een vergelijkbare testcase uitvoeren door ervoor te zorgen dat de indexserver op het secundaire knooppunt vastloopt. In het geval van een crash van de indexserver herkent de susChkSrv-hook het exemplaar en initieert u een actie om het secundaire knooppunt te heksen.

Hoge beschikbaarheid voor SAP HANA op Azure-VM's op SUSE Linux Enterprise Server

Plannen voor hoge beschikbaarheid van SAP HANA

De infrastructuur voorbereiden

Virtuele Linux-machines handmatig implementeren via Azure Portal

Azure Load Balancer configureren

Een Pacemaker-cluster maken

SAP HANA installeren

SAP HANA 2.0-systeemreplicatie configureren

SAP HANA 1.0-systeemreplicatie configureren

HANA-hooks SAPHanaSR en susChkSrv implementeren

SAP HANA-clusterbronnen maken

Systeemreplicatie met actief/lezen-ingeschakeld HANA configureren in een Pacemaker-cluster

De load balancer instellen voor systeemreplicatie met actieve/leesfuncties

HANA-systeemreplicatie met actieve/leesfunctionaliteit instellen

Een secundaire virtuele IP-adresresource toevoegen

De clusterinstallatie testen

De migratie testen

Netwerkcommunicatie blokkeren

SBD-fencing testen

Een handmatige failover testen

SUSE-tests

Volgende stappen

Aanvullende resources