hoge beschikbaarheid van SAP HANA in Azure-VM's in Red Hat Enterprise Linux

Artikel
12/04/2024

Voor on-premises ontwikkeling kunt u HANA-systeemreplicatie of gedeelde opslag gebruiken om hoge beschikbaarheid (HA) voor SAP HANA tot stand te brengen. Op virtuele Azure-machines is HANA-systeemreplicatie in Azure momenteel de enige ondersteunde ha-functie.

SAP HANA-replicatie 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 virtuele machines (VM's) implementeert en configureert, het clusterframework installeert en SAP HANA-systeemreplicatie installeert en configureert.

In de voorbeeldconfiguraties worden installatieopdrachten, exemplaarnummer 03 en HANA-systeem-id HN1 gebruikt.

Vereisten

Lees eerst de volgende SAP-notities en -documenten:

SAP-notitie 1928533, met:
- 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 en -besturingssystemen en -databases.
- De vereiste SAP-kernelversie voor Windows en Linux in Microsoft Azure.
SAP Note 2015553 bevat vereisten voor SAP-ondersteunde SAP-software-implementaties in Azure.
SAP Note 2002167 heeft aanbevolen besturingssysteeminstellingen voor Red Hat Enterprise Linux.
SAP Note 2009879 heeft SAP HANA-richtlijnen voor Red Hat Enterprise Linux.
SAP Note 3108302 heeft SAP HANA-richtlijnen voor Red Hat Enterprise Linux 9.x.
SAP Note 2178632 bevat gedetailleerde informatie over alle metrische bewakingsgegevens die zijn gerapporteerd voor SAP in Azure.
SAP-opmerking 2191498 beschikt over de vereiste VERSIE van de SAP Host Agent voor Linux in Azure.
SAP Note 2243692 informatie heeft over SAP-licenties in Linux in Azure.
SAP-opmerking 1999351 meer informatie over het oplossen van problemen heeft voor de Uitgebreide Bewakingsextensie van Azure voor SAP.
SAP Community WIKI bevat alle vereiste SAP-notities voor Linux.
Azure Virtual Machines plannen en implementeren voor SAP in Linux
Azure Virtual Machines-implementatie voor SAP in Linux (dit artikel)
DBMS-implementatie van Azure Virtual Machines voor SAP in Linux
SAP HANA-systeemreplicatie in een Pacemaker-cluster
Algemene RHEL-documentatie:
Azure-specifieke RHEL-documentatie:

Overzicht

Sap HANA wordt op twee VM's geïnstalleerd om hoge beschikbaarheid te bereiken. 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 is een load balancer vereist voor het gebruik van een virtueel IP-adres. De gepresenteerde configuratie toont een load balancer met:

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

De infrastructuur voorbereiden

Azure Marketplace bevat installatiekopieën die zijn gekwalificeerd voor SAP HANA met de invoegtoepassing Hoge beschikbaarheid, die u kunt gebruiken om nieuwe VM's te implementeren met behulp van verschillende versies van Red Hat.

Virtuele Linux-machines handmatig implementeren via Azure Portal

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

Vm's implementeren voor SAP HANA. Kies een geschikte RHEL-installatiekopieën die worden ondersteund voor het HANA-systeem. U kunt een VIRTUELE machine 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 Verbindingen met tenantdatabases in de handleiding sap HANA-tenantdatabases of SAP Note 2388694.

Notitie

Wanneer VM's zonder openbare IP-adressen worden geplaatst in de back-endpool van een intern exemplaar (geen openbaar IP-adres) van Standard Azure Load Balancer, is er geen uitgaande internetverbinding, tenzij er meer configuratie wordt uitgevoerd 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, kunnen de statustests mislukken. Stel de parameter in net.ipv4.tcp_timestamps op 0. Zie Statustests van Load Balancer en SAP Note 2382421 voor meer informatie.

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.

[A] Stel de schijfindeling in: 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 op de VM's vier gegevensschijven zijn gekoppeld die worden gebruikt om twee volumes te maken.

Geef alle beschikbare schijven weer:
```
ls /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
```
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
```
Maak een volumegroep voor de gegevensbestanden. Gebruik één volumegroep voor de logboekbestanden en een voor de gedeelde map van SAP HANA:
```
sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3
```
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.

In dit document worden twee fysieke volumes gebruikt voor het gegevensvolume, dus het -i schakelargument is ingesteld op 2. De stripegrootte voor het gegevensvolume is 256KiB. Er wordt één fysiek volume gebruikt voor het logboekvolume, dus er worden geen -i -I switches expliciet gebruikt voor de logboekvolumeopdrachten.

Belangrijk

Gebruik de schakeloptie en stel deze -i in op het aantal onderliggende fysieke volumes wanneer u meer dan één fysiek volume gebruikt voor elke gegevens, logboek of gedeelde volumes. Gebruik de -I schakeloptie om de stripegrootte op te geven wanneer u een gestreept volume maakt. Zie SAP HANA VM-opslagconfiguraties voor aanbevolen opslagconfiguraties, waaronder stripegrootten en het aantal schijven. De volgende indelingsvoorbeelden voldoen niet noodzakelijkerwijs aan de prestatierichtlijnen voor een bepaalde systeemgrootte. Ze zijn alleen ter illustratie.
```
sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1
sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_shared
```
Koppel de directory's niet door koppelopdrachten uit te geven. Voer in plaats daarvan de configuraties in en fstab geef een definitieve opdracht mount -a om de syntaxis te valideren. Begin met het maken van de koppelmappen voor elk volume:
```
sudo mkdir -p /hana/data
sudo mkdir -p /hana/log
sudo mkdir -p /hana/shared
```
Maak fstab vervolgens vermeldingen voor de drie logische volumes door de volgende regels in het bestand in te /etc/fstab voegen:

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

Koppel ten slotte de nieuwe volumes allemaal tegelijk:
```
sudo mount -a
```
[A] Hostnaamomzetting instellen voor alle hosts.

U kunt een DNS-server gebruiken of het /etc/hosts bestand op alle knooppunten wijzigen door vermeldingen te maken voor alle knooppunten, zoals in /etc/hosts:

10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1
[A] VOER RHEL uit voor HANA-configuratie.

Configureer RHEL zoals beschreven in de volgende notities:
[A] Installeer SAP HANA, volgens de documentatie van SAP.

[A] Configureer de firewall.

Maak de firewallregel voor de testpoort van Azure Load Balancer.

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

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.

[A] Configureer de firewall.

Maak firewallregels om HANA-systeemreplicatie en clientverkeer toe te staan. De vereiste poorten worden vermeld op TCP/IP-poorten van alle SAP-producten. De volgende opdrachten zijn slechts een voorbeeld om HANA 2.0-systeemreplicatie en clientverkeer naar database SYSTEMDB, HN1 en NW1 toe te staan.
```
 sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp --permanent
 sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp
```

[1] Maak de tenantdatabase.

Voer de volgende opdracht uit als <hanasid>adm:

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

[1] Configureer systeemreplicatie op het eerste knooppunt.

Maak een back-up van de databases als <hanasid>adm:

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

Kopieer de PKI-systeembestanden naar de secundaire site:

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

Maak de primaire site:

hdbnsutil -sr_enable --name=SITE1

[2] Configureer systeemreplicatie op het tweede knooppunt.

Registreer het tweede knooppunt om de systeemreplicatie te starten. Voer de volgende opdracht uit als <hanasid>adm:
```
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
```
[2] Start HANA.

Voer de volgende opdracht uit als <hanasid>adm om HANA te starten:
```
sapcontrol -nr 03 -function StartSystem
```

[1] Controleer de replicatiestatus.

Controleer de replicatiestatus en wacht totdat alle databases zijn gesynchroniseerd. Als de status ONBEKEND blijft, controleert u de firewallinstellingen.

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

Een Pacemaker-cluster maken

Volg de stappen in Pacemaker instellen op Red Hat Enterprise Linux in Azure om een eenvoudig Pacemaker-cluster voor deze HANA-server te maken.

Belangrijk

Met het systeemgebaseerde SAP Startup Framework kunnen SAP HANA-exemplaren nu worden beheerd door een systeem. De minimaal vereiste Red Hat Enterprise Linux-versie (RHEL) is RHEL 8 voor SAP. Zoals beschreven in SAP Note 3189534, worden nieuwe installaties van SAP HANA SPS07 revisie 70 of hoger of updates van HANA-systemen naar HANA 2.0 SPS07 revisie 70 of hoger automatisch geregistreerd bij systemd.

Wanneer u HA-oplossingen gebruikt voor het beheren van SAP HANA-systeemreplicatie in combinatie met SAP HANA-exemplaren met systeemfunctionaliteit (raadpleeg SAP Note 3189534), zijn er aanvullende stappen nodig om ervoor te zorgen dat het HA-cluster het SAP-exemplaar zonder systeeminterferentie kan beheren. Voor het SAP HANA-systeem dat is geïntegreerd met systemd, moeten extra stappen die worden beschreven in Red Hat KBA 7029705 worden gevolgd op alle clusterknooppunten.

SAP HANA-systeemreplicatiehook implementeren

Deze belangrijke stap optimaliseert de integratie met het cluster en verbetert de detectie wanneer een clusterfailover nodig is. Het is verplicht voor de juiste clusterbewerking om de SAPHanaSR-hook in te schakelen. We raden u ten zeerste aan om zowel SAPHanaSR- als ChkSrv Python-hooks te configureren.

[A] Installeer de SAP HANA-resourceagents op alle knooppunten. Zorg ervoor dat u een opslagplaats inschakelt die het pakket bevat. U hoeft niet meer opslagplaatsen in te schakelen als u een RHEL 8.x- of hogere installatiekopieën met hoge beschikbaarheid gebruikt.
```
# Enable repository that contains SAP HANA resource agents
sudo subscription-manager repos --enable="rhel-sap-hana-for-rhel-7-server-rpms"

sudo dnf install -y resource-agents-sap-hana
```
Notitie

Controleer voor RHEL 8.x en RHEL 9.x of het geïnstalleerde resource-agents-sap-hana-pakket versie 0.162.3-5 of hoger is.
[A] Installeer de HANA system replication hooks. De configuratie voor de replicatiehook moet worden geïnstalleerd op beide HANA DB-knooppunten.
1. Stop HANA op beide knooppunten. Uitvoeren als <sid>adm.
```
sapcontrol -nr 03 -function StopSystem
```
2. Pas het clusterknooppunt aan global.ini .
```
[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR/srHook
execution_order = 1

[ha_dr_provider_chksrv]
provider = ChkSrv
path = /usr/share/SAPHanaSR/srHook
execution_order = 2
action_on_lost = kill

[trace]
ha_dr_saphanasr = info
ha_dr_chksrv = info
```
Als u de parameter path naar de standaardlocatie /usr/share/SAPHanaSR/srHook wijst, 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 hook-versie die door HANA wordt gebruikt.

U kunt het gedrag van hook aanpassen met behulp van ChkSrv de action_on_lost parameter. Geldige waarden zijn [ ignorekill | stop | ].

[A] Het cluster vereist sudoers configuratie op elk clusterknooppunt voor <sid>adm. In dit voorbeeld wordt dit bereikt door een nieuw bestand te maken. Gebruik de visudo opdracht om het 20-saphana drop-in-bestand te bewerken als root.

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

Voeg de volgende regels in en sla deze op:

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

[A] START SAP HANA op beide knooppunten. Uitvoeren als <sid>adm.
```
sapcontrol -nr 03 -function StartSystem 
```

[1] Controleer de SRHanaSR-hookinstallatie. Voer als <sid>adm uit op de actieve HANA-systeemreplicatiesite.

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

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

[1] Controleer de ChkSrv-hookinstallatie. Voer als <sid>adm uit op de actieve HANA-systeemreplicatiesite.
```
 cdtrace
 tail -20 nameserver_chksrv.trc
```

Zie De SAP HANA srConnectionChanged() hook inschakelen en de SAP HANA srConnectionChanged() hook inschakelen en de SAP HANA srServiceStateChanged() hook inschakelen voor hdbindexserver process failure action (optioneel).

SAP HANA-clusterbronnen maken

Maak de HANA-topologie. Voer de volgende opdrachten uit op een van de Pacemaker-clusterknooppunten. Zorg ervoor dat u in deze instructies uw exemplaarnummer, HANA-systeem-id, IP-adressen en systeemnamen vervangt, indien van toepassing.

sudo pcs property set maintenance-mode=true

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

Maak vervolgens de HANA-resources.

Notitie

Dit artikel bevat verwijzingen naar een term die microsoft niet meer gebruikt. Zodra de term uit de software wordt verwijderd, verwijderen we deze uit dit artikel.

Als u een cluster bouwt op RHEL 7.x, gebruikt u de volgende opdrachten:

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

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

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

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

sudo pcs property set maintenance-mode=false

Als u een cluster bouwt op RHEL 8.x/9.x, gebruikt u de volgende opdrachten:

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

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

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

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

sudo pcs property set maintenance-mode=false

Als u wilt configureren priority-fencing-delay voor SAP HANA (alleen van toepassing op pacemaker-2.0.4-6.el8 of hoger), moeten de volgende opdrachten worden uitgevoerd.

Notitie

Als u een cluster met twee knooppunten hebt, kunt u de priority-fencing-delay clustereigenschap configureren. Deze eigenschap introduceert een vertraging bij het afschermen van een knooppunt met een hogere totale resourceprioriteit wanneer er een split-brain-scenario optreedt. Zie Kan Pacemaker het clusterknooppunt omheinen met de minste actieve resources? voor meer informatie.

De eigenschap priority-fencing-delay is van toepassing op pacemaker-2.0.4-6.el8 of hoger. Als u priority-fencing-delay een bestaand cluster instelt, moet u de pcmk_delay_max optie in het fencing-apparaat uitschakelen.

sudo pcs property set maintenance-mode=true

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

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

sudo pcs property set maintenance-mode=false

Belangrijk

Het is een goed idee om in te stellen AUTOMATED_REGISTER falseop , terwijl u failovertests uitvoert, om te voorkomen dat een mislukt primair exemplaar automatisch wordt geregistreerd als secundair. Na het testen, als best practice, ingesteld AUTOMATED_REGISTER op true zodat de systeemreplicatie na overname automatisch kan worden hervat.

Zorg ervoor dat de clusterstatus in orde is en dat alle resources zijn gestart. Het is niet belangrijk op welk knooppunt de resources worden uitgevoerd.

Notitie

De time-outs in de voorgaande configuratie zijn alleen voorbeelden en moeten mogelijk worden aangepast aan de specifieke HANA-installatie. U moet bijvoorbeeld de time-out voor de start verhogen als het langer duurt om de SAP HANA-database te starten.

Gebruik de opdracht sudo pcs status om de status van de gemaakte clusterbronnen te controleren:

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

HANA-systeemreplicatie met actief/gelezen-ingeschakeld configureren in Pacemaker-cluster

Vanaf SAP HANA 2.0 SPS 01 biedt SAP actieve/leesfuncties voor SAP HANA-systeemreplicatie, waarbij de secundaire systemen van SAP HANA-systeemreplicatie actief kunnen worden gebruikt voor leesintensieve werkbelastingen.

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

In deze sectie worden de andere stappen beschreven die nodig zijn voor het beheren van systeemreplicatie met actieve/leesfunctionaliteit van HANA in een Red Hat HA-cluster met een tweede virtueel IP-adres.

Voordat u verdergaat, moet u ervoor zorgen dat u het Red Hat HA-cluster voor het beheren van een SAP HANA-database volledig hebt geconfigureerd, zoals beschreven in voorgaande segmenten van de documentatie.

Diagram met SAP HANA HA met secundaire leesfunctionaliteit.

Aanvullende installatie in Azure Load Balancer voor installatie met actief/gelezen functionaliteit

Als u wilt doorgaan met meer stappen voor het inrichten van een tweede virtueel IP-adres, moet u Ervoor zorgen dat u Azure Load Balancer hebt geconfigureerd, zoals beschreven in de sectie Linux-VM's handmatig implementeren via de sectie Azure Portal .

Voer voor een standard load balancer deze stappen uit op dezelfde load balancer die u in een eerdere sectie hebt gemaakt.

a. Maak een tweede front-end-IP-adresgroep:
- Open de load balancer, selecteer front-end-IP-adresgroep en selecteer Toevoegen.
- Voer de naam in van de tweede front-end-IP-adresgroep (bijvoorbeeld hana-secondaryIP).
- Stel de toewijzing in op Statisch en voer het IP-adres in (bijvoorbeeld 10.0.0.14).
- Selecteer OK.
- Nadat de nieuwe front-end-IP-adresgroep is gemaakt, noteert u het IP-adres van de groep.
b. Een statustest maken:
- Open de load balancer, selecteer statustests en selecteer Toevoegen.
- Voer de naam in van de nieuwe statustest (bijvoorbeeld hana-secondaryhp).
- Selecteer TCP als protocol en poort 62603. Houd de intervalwaarde ingesteld op 5 en de drempelwaarde Voor beschadigde status ingesteld op 2.
- Selecteer OK.
c. Maak de taakverdelingsregels:
- Open de load balancer, selecteer taakverdelingsregels en selecteer Toevoegen.
- Voer de naam in van de nieuwe load balancer-regel (bijvoorbeeld hana-secondarylb).
- 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).
- Selecteer HA-poorten.
- Zorg ervoor dat u Zwevend IP-adres inschakelt.
- Selecteer OK.

Active/read-enabled systeemreplicatie van HANA configureren

De stappen voor het configureren van HANA-systeemreplicatie worden beschreven in de sectie SAP HANA 2.0-systeemreplicatie configureren. Als u een secundair scenario met leesbewerkingen implementeert terwijl u systeemreplicatie configureert op het tweede knooppunt, voert u de volgende opdracht uit als hanasidadm:

sapcontrol -nr 03 -function StopWait 600 10 

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

Een secundaire virtuele IP-adresresource toevoegen voor een installatie met actief/gelezen functionaliteit

Het tweede virtuele IP-adres en de juiste colocatiebeperking kunnen worden geconfigureerd met de volgende opdrachten:

pcs property set maintenance-mode=true

pcs resource create secvip_HN1_03 ocf:heartbeat:IPaddr2 ip="10.40.0.16"
pcs resource create secnc_HN1_03 ocf:heartbeat:azure-lb port=62603
pcs resource group add g_secip_HN1_03 secnc_HN1_03 secvip_HN1_03

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

# Set the priority to primary IPaddr2 and azure-lb resource if priority-fencing-delay is configured
sudo pcs resource update vip_HN1_03 meta priority=5
sudo pcs resource update nc_HN1_03 meta priority=5

pcs property set maintenance-mode=false

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

sudo pcs status

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

In de volgende sectie vindt u de typische set failovertests die moeten worden uitgevoerd.

Houd rekening met het tweede virtuele IP-gedrag tijdens het testen van een HANA-cluster dat is geconfigureerd met secundaire leesfunctionaliteit:

Wanneer u de SAPHana_HN1_03-clusterresource migreert naar de secundaire site hn1-db-1, blijft het tweede virtuele IP-adres actief op dezelfde site hn1-db-1. Als u hebt ingesteld AUTOMATED_REGISTER="true" voor de resource en HANA-systeemreplicatie automatisch wordt geregistreerd op hn1-db-0, wordt uw tweede virtuele IP ook verplaatst naar hn1-db-0.
Bij het testen van een servercrash worden de tweede virtuele IP-resources (secvip_HN1_03) en de Azure Load Balancer-poortresource (secnc_HN1_03) uitgevoerd op de primaire server naast de primaire virtuele IP-resources. Dus tot de tijd dat de secundaire server uitvalt, maken toepassingen die zijn verbonden met de HANA-database met leesfunctionaliteit verbinding met de primaire HANA-database. Het gedrag wordt verwacht omdat u niet wilt dat toepassingen die zijn verbonden met de HANA-database met leesfunctionaliteit, niet toegankelijk zijn totdat de secundaire server niet beschikbaar is.
Tijdens failover en terugval van het tweede virtuele IP-adres worden de bestaande verbindingen op toepassingen die gebruikmaken van het tweede virtuele IP-adres mogelijk onderbroken om verbinding te maken met de HANA-database.

De installatie maximaliseert de tijd dat de tweede virtuele IP-resource wordt toegewezen aan een knooppunt waarop een gezond SAP HANA-exemplaar wordt uitgevoerd.

De clusterinstallatie testen

In deze sectie wordt beschreven hoe u uw installatie kunt testen. Voordat u een test start, moet u ervoor zorgen dat Pacemaker geen mislukte actie heeft (via pcs-status), er geen onverwachte locatiebeperkingen zijn (bijvoorbeeld resten van een migratietest) en dat HANA de synchronisatiestatus heeft, bijvoorbeeld met systemReplicationStatus.

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

De migratie testen

Resourcestatus voordat u de test start:

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

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

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

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

Nadat de migratie is voltooid, ziet de sudo pcs status uitvoer er als volgt uit:

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

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 opdrachten uit te voeren, als hn1adm:

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

Tijdens de migratie worden locatiebeperkingen gemaakt die opnieuw moeten worden verwijderd. Voer de volgende opdracht uit als root of via sudo:

pcs resource clear SAPHana_HN1_03-master

Bewaak de status van de HANA-resource met behulp van pcs status. Nadat HANA is gestart hn1-db-0, moet de uitvoer er als volgt uitzien:

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

Netwerkcommunicatie blokkeren

Resourcestatus voordat u de test start:

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

Voer de 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 een heksrace. Om een dergelijke situatie te voorkomen, raden we u aan de eigenschap prioriteitsafgrenzingsvertraging in de clusterconfiguratie in te stellen (alleen van toepassing op pacemaker-2.0.4-6.el8 of hoger).

Door de priority-fencing-delay eigenschap in te schakelen, introduceert het cluster een vertraging in de afschermingsactie specifiek op het knooppunt dat als host fungeert voor de HANA-hoofdresource, zodat het knooppunt de heksrace kan winnen.

Voer de volgende 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

De Azure-afschermingsagent testen

Notitie

Dit artikel bevat verwijzingen naar een term die microsoft niet meer gebruikt. Zodra de term uit de software wordt verwijderd, verwijderen we deze uit dit artikel.

Resourcestatus voordat u de test start:

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

U kunt de installatie van de Azure-fencing-agent testen door de netwerkinterface uit te schakelen op het knooppunt waarop SAP HANA wordt uitgevoerd als master. Zie Red Hat Knowledge Base-artikel 79523 voor een beschrijving van het simuleren van een netwerkfout.

In dit voorbeeld gebruiken we het net_breaker script als hoofdmap om alle toegang tot het netwerk te blokkeren:

sh ./net_breaker.sh BreakCommCmd 10.0.0.6

De VM moet nu opnieuw worden opgestart of gestopt, afhankelijk van de clusterconfiguratie. Als u de stonith-action instelling offinstelt op, wordt de VIRTUELE machine gestopt en worden de resources gemigreerd naar de actieve VM.

Nadat u de VIRTUELE machine opnieuw hebt gestart, kan de SAP HANA-resource niet worden gestart als secundair als u instelt AUTOMATED_REGISTER="false". In dit geval configureert u het HANA-exemplaar als secundair door deze opdracht uit te voeren als de hn1adm-gebruiker :

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

Ga terug naar de hoofdmap en schoon de mislukte status op:

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

Resourcestatus na de test:

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

Een handmatige failover testen

Resourcestatus voordat u de test start:

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

U kunt een handmatige failover testen door het cluster op het hn1-db-0 knooppunt te stoppen als hoofdmap:

pcs cluster stop

Na de failover kunt u het cluster 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 als root:

pcs cluster start

Voer het volgende uit als hn1adm:

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

Vervolgens als hoofdmap:

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

Resourcestatus na de test:

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

Delen via

hoge beschikbaarheid van SAP HANA in Azure-VM's in Red Hat Enterprise Linux

Vereisten

Overzicht

De infrastructuur voorbereiden

Virtuele Linux-machines handmatig implementeren via Azure Portal

Azure Load Balancer configureren

SAP HANA installeren

SAP HANA 2.0-systeemreplicatie configureren

Een Pacemaker-cluster maken

SAP HANA-systeemreplicatiehook implementeren

SAP HANA-clusterbronnen maken

HANA-systeemreplicatie met actief/gelezen-ingeschakeld configureren in Pacemaker-cluster

Aanvullende installatie in Azure Load Balancer voor installatie met actief/gelezen functionaliteit

Active/read-enabled systeemreplicatie van HANA configureren

Een secundaire virtuele IP-adresresource toevoegen voor een installatie met actief/gelezen functionaliteit

De clusterinstallatie testen

De migratie testen

Netwerkcommunicatie blokkeren

De Azure-afschermingsagent testen

Een handmatige failover testen

Volgende stappen

Feedback

Aanvullende resources