Disponibilità elevata di SAP HANA in macchine virtuali di Azure su Red Hat Enterprise Linux

Articolo
11/05/2024

Per lo sviluppo locale, è possibile usare la replica di sistema HANA oppure l'archiviazione condivisa per fornire la disponibilità elevata per SAP HANA. In Macchine virtuali di Azure la replica di sistema HANA in Azure è attualmente l'unica funzione per la disponibilità elevata supportata.

La replica SAP HANA è costituita da un nodo primario e da almeno un nodo secondario. Le modifiche ai dati nel nodo primario vengono replicate nel nodo secondario in modo sincrono o asincrono.

Questo articolo descrive come distribuire e configurare le macchine virtuali, installare il framework del cluster, nonché installare e configurare la replica di sistema SAP HANA.

Nelle configurazioni di esempio e nei comandi di installazione vengono usati il numero di istanza 03 e l'ID di sistema HANA HN1.

Prerequisiti

Leggere prima di tutto i documenti e le note SAP seguenti:

Nota SAP 1928533, contenente:
- Elenco delle dimensioni delle macchine virtuali di Azure supportate per la distribuzione di software SAP.
- Informazioni importanti sulla capacità per le dimensioni delle macchine virtuali di Azure.
- Software SAP e combinazioni di sistemi operativi e database supportati.
- Versione del kernel SAP richiesta per Windows e Linux in Microsoft Azure.
La nota SAP 2015553 elenca i prerequisiti per le distribuzioni di software SAP supportate da SAP in Azure.
La nota SAP 2002167 indica le impostazioni del sistema operativo consigliate per Red Hat Enterprise Linux.
La nota SAP 2009879 contiene le linee guida di SAP HANA per Red Hat Enterprise Linux.
La nota SAP 3108302 contiene le linee guida di SAP HANA per Red Hat Enterprise Linux 9.x.
La nota SAP 2178632 contiene informazioni dettagliate su tutte le metriche di monitoraggio segnalate per SAP in Azure.
La nota SAP 2191498 contiene la versione dell'agente host SAP per Linux necessaria in Azure.
La nota SAP 2243692 contiene informazioni sulle licenze SAP in Linux in Azure.
La nota SAP 1999351 contiene altre informazioni sulla risoluzione dei problemi per l'estensione di monitoraggio avanzato di Azure per SAP.
Community WIKI SAP contiene tutte le note su SAP necessarie per Linux.
Pianificazione e implementazione di Macchine virtuali di Azure per SAP in Linux
Distribuzione di Macchine virtuali di Microsoft Azure per SAP in Linux (questo articolo)
Distribuzione DBMS di Macchine virtuali di Azure per SAP in Linux
Replica di sistema SAP HANA nel cluster Pacemaker
Documentazione generale di RHEL:
- High Availability Add-On Overview (Panoramica dei componenti aggiuntivi a disponibilità elevata)
- High Availability Add-On Administration (Amministrazione dei componenti aggiuntivi a disponibilità elevata)
- High Availability Add-On Reference (Riferimento dei componenti aggiuntivi a disponibilità elevata)
- Replica del sistema con scalabilità orizzontale di HANA con componente aggiuntivo RHEL HA
Documentazione di RHEL specifica di Azure:
- Support Policies for RHEL High Availability Clusters - Microsoft Azure Virtual Machines as Cluster Members (Criteri di supporto per cluster RHEL a disponibilità elevata - Macchine virtuali di Microsoft Azure come membri del cluster)
- Installing and Configuring a Red Hat Enterprise Linux 7.4 (and later) High-Availability Cluster on Microsoft Azure (Installazione e configurazione di un cluster Red Hat Enterprise Linux 7.4 e versioni successive a disponibilità elevata in Microsoft Azure)
- Install SAP HANA on Red Hat Enterprise Linux for Use in Microsoft Azure (Installare SAP HANA su Red Hat Enterprise Linux per l'uso in Microsoft Azure)

Panoramica

Per ottenere la disponibilità elevata, SAP HANA viene installato in due macchine virtuali. I dati vengono replicati tramite la replica di sistema HANA.

Diagramma che mostra una panoramica della disponibilità elevata SAP HANA.

La procedura di configurazione della replica di sistema SAP HANA usa un nome host virtuale dedicato e indirizzi IP virtuali. In Azure è necessario un servizio di bilanciamento del carico per usare un indirizzo IP virtuale. La configurazione presentata mostra un bilanciamento del carico con:

Indirizzo IP front-end: 10.0.0.13 per hn1-db
Porta probe: 62503

Preparare l'infrastruttura

Azure Marketplace contiene immagini qualificate per SAP HANA con il componente aggiuntivo a disponibilità elevata, che è possibile usare per distribuire nuove macchine virtuali usando diverse versioni di Red Hat.

Distribuire macchine virtuali Linux manualmente tramite il portale di Azure

Questo documento presuppone che sia già stato distribuito un gruppo di risorse, una rete virtuale di Azure e una subnet.

Distribuire macchine virtuali per SAP HANA. Scegliere un'immagine RHEL appropriata supportata per il sistema HANA. È possibile distribuire una macchina virtuale in una delle opzioni di disponibilità: set di scalabilità di macchine virtuali, zona di disponibilità o set di disponibilità.

Importante

Assicurarsi che il sistema operativo selezionato sia certificato SAP per SAP HANA nei tipi di macchina virtuale specifici che si prevede di usare nella distribuzione. È possibile cercare i tipi di VM certificati SAP HANA e le relative versioni del sistema operativo in Piattaforme IaaS certificate per SAP HANA. Assicurarsi di esaminare ogni voce dei tipi di macchina virtuale per ottenere l'elenco completo delle versioni di sistema operativo supportate da SAP HANA per lo specifico tipo di macchina virtuale.

Configurare il servizio di bilanciamento del carico di Azure

Durante la configurazione della macchina virtuale, è possibile creare o selezionare il servizio di bilanciamento del carico esistente nella sezione Rete. Seguire questa procedura per configurare il servizio di bilanciamento del carico standard per la configurazione a disponibilità elevata del database HANA.

Seguire la procedura descritta in Creare il servizio di bilanciamento del carico per configurare un servizio di bilanciamento del carico standard per un sistema SAP a disponibilità elevata usando il portale di Azure. Durante la configurazione del servizio di bilanciamento del carico, considerare i punti seguenti:

Configurazione IP front-end: creare un indirizzo IP front-end. Selezionare la stessa rete virtuale e il nome della subnet delle macchine virtuali di database.
Pool back-end: creare un pool back-end e aggiungere macchine virtuali di database.
Regole in ingresso: creare una regola di bilanciamento del carico. Seguire la stessa procedura per entrambe le regole di bilanciamento del carico.
- Indirizzo IP front-end: selezionare un indirizzo IP front-end.
- Pool back-end: selezionare un pool back-end.
- Porte a disponibilità elevata: selezionare questa opzione.
- Protocollo: selezionare TCP.
- Probe di integrità: creare un probe di integrità con i dettagli seguenti:
  - Protocollo: selezionare TCP.
  - Porta: ad esempio, 625<instance-no.>.
  - Intervallo: immettere 5.
  - Soglia probe: immettere 2.
- Timeout di inattività (minuti): immettere 30.
- Abilita IP mobile: selezionare questa opzione.

Nota

La proprietà di configurazione del probe di integrità numberOfProbes, altrimenti nota come soglia non integra nel portale, non viene rispettata. Per controllare il numero di probe consecutivi riusciti o non riusciti, impostare la proprietà probeThreshold su 2. Non è attualmente possibile impostare questa proprietà usando il portale di Azure, quindi usare l'interfaccia della riga di comando di Azure o il comando di PowerShell.

# 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

Espandere per visualizzare il codice completo dell'interfaccia della riga di comando

# 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

Espandere per visualizzare il codice di PowerShell completo

# 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

Per altre informazioni sulle porte necessarie per SAP HANA, leggere il capitolo Connections to Tenant Databases (Connessioni a database tenant) della guida SAP HANA Tenant Databases (Database tenant SAP HANA) o la nota SAP 2388694.

Nota

Se vengono inserite macchine virtuali senza indirizzi IP pubblici nel pool back-end di un'istanza di Load Balancer Standard interno ad Azure (nessun indirizzo IP pubblico), non è presente alcuna connettività Internet in uscita, a meno che non venga eseguita un’altra configurazione per consentire il routing a endpoint pubblici. Per maggiori informazioni su come ottenere la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali usando Load Balancer Standard di Azure negli scenari a disponibilità elevata SAP.

Importante

Non abilitare i timestamp TCP nelle macchine virtuali di Azure che si trovano dietro Azure Load Balancer. Se si abilitano i timestamp TCP, i probe di integrità potrebbero avere esito negativo. Impostare il parametro net.ipv4.tcp_timestamps su 0. Per altre informazioni, vedere Probe di integrità di Load Balancer e SAP Note 2382421.

Installare SAP HANA

Nei passaggi descritti in questa sezione vengono usati i prefissi seguenti:

[T]: il passaggio si applica a tutti i nodi.
[1]: il passaggio si applica solo al nodo 1.
[2]: Il passaggio si applica solo al nodo 2 del cluster Pacemaker.

[T] Configurare il layout dei dischi: gestione volumi logici (LVM, Logical Volume Manager).

È consigliabile usare LVM per i volumi che archiviano file di log e dati. L'esempio seguente presuppone che le macchine virtuali abbiano quattro dischi dati collegati, usati per creare due volumi.

Elencare tutti i dischi disponibili:
```
ls /dev/disk/azure/scsi1/lun*
```
Output di esempio:
```
/dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2  /dev/disk/azure/scsi1/lun3
```
Creare i volumi fisici per tutti i dischi da usare:
```
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
```
Creare un gruppo di volumi per i file di dati. Usare un gruppo di volumi per i file di log e uno per la directory condivisa di 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
```
Creare i volumi logici. Quando si usa lvcreate senza l'opzione -i, viene creato un volume lineare. È consigliabile creare un volume con striping per migliorare le prestazioni di I/O. Allineare le dimensioni di striping ai valori documentati in configurazioni di archiviazione delle macchine virtuali SAP HANA. L'argomento -i deve essere il numero dei volumi fisici sottostanti e l'argomento -I è la dimensione della striscia.

In questo documento vengono usati due volumi fisici per il volume di dati, quindi l'argomento dell'opzione -i è impostato su 2. La dimensione di striping per il volume di dati è 256KiB. Un volume fisico viene usato per il volume di log, quindi non viene usata alcuna opzione -i o -I in modo esplicito per i comandi del volume di log.

Importante

Usare l'opzione -i e impostarla sul numero del volume fisico sottostante quando si usano più volumi fisici per ogni volume di dati, di log o condiviso. Usare l'opzione -I per specificare le dimensioni di striping durante la creazione di un volume con striping. Vedere Configurazioni di archiviazione della macchina virtuale SAP HANA per le configurazioni di archiviazione consigliate, incluse le dimensioni di striping e il numero di dischi. Gli esempi di layout seguenti non soddisfano necessariamente le linee guida per le prestazioni per una determinata dimensione del sistema. Sono solo per l'illustrazione.
```
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
```
Non montare le directory eseguendo comandi di montaggio. Immettere invece le configurazioni nel fstab ed eseguire un mount -a finale per convalidare la sintassi. Per iniziare, creare le directory di montaggio per ogni volume:
```
sudo mkdir -p /hana/data
sudo mkdir -p /hana/log
sudo mkdir -p /hana/shared
```
Creare quindi fstab voci per i tre volumi logici inserendo le righe seguenti nel file /etc/fstab:

/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

Infine, montare i nuovi volumi contemporaneamente:
```
sudo mount -a
```
[A] Configurare la risoluzione dei nomi host per tutti gli host.

È possibile usare un server DNS o modificare il file /etc/hosts in tutti i nodi creando voci per tutti i nodi come questo in /etc/hosts:

10.0.0.5 hn1-db-0 10.0.0.6 hn1-db-1
[A] Eseguire la configurazione di RHEL per HANA.

Configurare RHEL come descritto nelle note seguenti:
- 2447641 : pacchetti aggiuntivi necessari per l'installazione di SAP HANA SPS 12 in RHEL 7.X
- 2292690 - SAP HANA DB: Recommended OS settings for RHEL 7 (2292690 - SAP HANA DB: impostazioni del sistema operativo consigliate per RHEL 7)
- 2292690 - SAP HANA DB: impostazioni del sistema operativo consigliate per RHEL 9
- 2455582 - Linux: Esecuzione di applicazioni SAP compilate con GCC 6.x
- 2593824 - Linux: Esecuzione di applicazioni SAP compilate con GCC 7.x
- 2886607 - Linux: Esecuzione di applicazioni SAP compilate con GCC 9.x
[A] Installare SAP HANA, seguendo la documentazione di SAP.

[A] Configurare il firewall.

Creare la regola del firewall per la porta probe di Azure Load Balancer.

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

Configurare la replica di sistema di SAP HANA 2.0

Per i passaggi in questa sezione vengono usati i prefissi seguenti:

[T]: il passaggio si applica a tutti i nodi.
[1]: il passaggio si applica solo al nodo 1.
[2]: Il passaggio si applica solo al nodo 2 del cluster Pacemaker.

[A] Configurare il firewall.

Creare regole del firewall per consentire il traffico di HANA System Replication e del client. Le porte necessarie sono elencate in TCP/IP Ports of All SAP Products (Porte TCP/IP per tutti i prodotti SAP). I comandi seguenti sono solo un esempio per consentire il traffico di HANA 2.0 System Replication e del client al database SYSTEMDB, HN1 e NW1.
```
 sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp --permanent
 sudo firewall-cmd --zone=public --add-port={40302,40301,40307,40303,40340,30340,30341,30342}/tcp
```

[1] Creare il database tenant.

Eseguire il comando seguente come <hanasid>adm:

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

[1] Configurare la replica di sistema nel primo nodo.

Eseguire il backup dei database come <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')"

Copiare i file PKI di sistema nel sito secondario:

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/

Creare il sito primario:

hdbnsutil -sr_enable --name=SITE1

[2] Configurare la replica di sistema nel secondo nodo.

Registrare il secondo nodo per avviare la replica di sistema. Eseguire il comando seguente come <hanasid>adm:
```
sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
```
[2] Avviare HANA.

Eseguire il comando seguente come <hanasid>adm per avviare HANA:
```
sapcontrol -nr 03 -function StartSystem
```

[1] Verificare lo stato della replica.

Verificare lo stato della replica e attendere che tutti i database siano sincronizzati. Se lo stato rimane UNKNOWN (SCONOSCIUTO), controllare le impostazioni del firewall.

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

Creare un cluster Pacemaker

Seguire i passaggi della procedura di configurazione di Pacemaker in Red Hat Enterprise Linux in Azure per creare un cluster Pacemaker di base per questo server HANA.

Importante

Con SAP Startup Framework basato su sistema, le istanze di SAP HANA possono ora essere gestite dal sistema. La versione minima richiesta di Red Hat Enterprise Linux (RHEL) è RHEL 8 per SAP. Come descritto nella nota SAP 3189534, in tutte le nuove installazioni di SAP HANA SPS07 versione 70 o successive o gli aggiornamenti ai sistemi HANA a HANA 2.0 SPS07 versione 70 o successiva, SAP Startup Framework verrà registrato automaticamente con systemd.

Quando si usano soluzioni a disponibilità elevata per gestire la replica del sistema SAP HANA in combinazione con le istanze di SAP HANA abilitate per il sistema (vedere SAP Note 3189534), sono necessari dei passaggi aggiuntivi per garantire che il cluster a disponibilità elevata possa gestire l'istanza SAP senza interferenze di sistema. Pertanto, per il sistema SAP HANA integrato con systemd, i passaggi aggiuntivi descritti in Red Hat KBA 7029705 devono essere seguiti in tutti i nodi del cluster.

Implementare hook di replica di sistema SAP HANA

Questo passaggio importante ottimizza l'integrazione con il cluster e migliora il rilevamento quando è necessario un failover del cluster. È obbligatorio per un'operazione del cluster corretta per abilitare l'hook SAPHanaSR. È consigliabile configurare sia gli hook PYTHON SAPHanaSR che ChkSrv.

[A] Installare gli agenti di risorse SAP HANA in tutti i nodi. Assicurarsi di abilitare un repository contenente il pacchetto. Non è necessario abilitare più repository, se si usa un'immagine abilitata per RHEL 8.x o versione successiva.
```
# 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
```
Nota

Per RHEL 8.x e RHEL 9.x, verificare che il pacchetto resource-agents-sap-hana installato sia versione 0.162.3-5 o successiva.
[A] Installare system replication hooks HANA . La configurazione per gli hook di replica deve essere installata in entrambi i nodi del database HANA.
1. Arrestare HANA in entrambi i nodi. Esegui come <sid>adm.
```
sapcontrol -nr 03 -function StopSystem
```
2. Regolare global.ini in ogni nodo del cluster.
```
[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
```
Se si punta path al percorso predefinito /usr/share/SAPHanaSR/srHook , il codice hook Python viene aggiornato automaticamente tramite gli aggiornamenti del sistema operativo o gli aggiornamenti dei pacchetti. HANA usa gli aggiornamenti del codice hook al successivo riavvio. Con un percorso personalizzato facoltativo, ad esempio /hana/shared/myHooks, è possibile separare gli aggiornamenti del sistema operativo dalla versione hook che VERRÀ usata da HANA.

È possibile modificare il comportamento dell'hook ChkSrv usando il action_on_lost parametro . Valori validi: ignore | stop | kill.

[A] Il cluster richiede la configurazione di sudoers in ogni nodo del cluster per <sid>adm. In questo esempio lo si ottiene creando un nuovo file. Usare il comando visudo per modificare il file di eliminazione 20-saphana come root.

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

Inserire le righe seguenti e quindi salvare:

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] Avviare HANA in entrambi i nodi. Esegui come <sid>adm.
```
sapcontrol -nr 03 -function StartSystem 
```

[1] Verificare l'installazione dell'hook SRHanaSR. Eseguire come <sid>adm nel sito di replica di sistema HANA attivo.

 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] Verificare l'installazione dell'hook ChkSrv. Eseguire come <sid>adm nel sito di replica di sistema HANA attivo.
```
 cdtrace
 tail -20 nameserver_chksrv.trc
```

Per altre informazioni sull'implementazione degli hook SAP HANA, vedere Abilitazione dell'hook srConnectionChanged() di SAP HANA e Abilitazione dell'hook srServiceStateChanged() di SAP HANA per l'azione di errore del processo hdbindexserver (facoltativo).

Creare le risorse cluster SAP HANA

Creare la topologia HANA. Eseguire i comandi seguenti in uno dei nodi del cluster Pacemaker. In queste istruzioni assicurarsi di sostituire il numero di istanza, l'ID di sistema HANA, gli indirizzi IP e i nomi di sistema, se appropriato.

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

Creare poi le risorse HANA.

Nota

Questo articolo contiene riferimenti a un termine che Microsoft non usa più. Quando il termine verrà rimosso dal software, verrà rimosso anche dall'articolo.

Se si sta creando un cluster in RHEL 7.x, usare i comandi seguenti:

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

Se si sta creando un cluster in RHEL 8.x/9.x, usare i comandi seguenti:

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

Per configurare priority-fencing-delay per SAP HANA (applicabile solo a partire da pacemaker-2.0.4-6.el8 o versione successiva), è necessario eseguire i comandi seguenti.

Nota

Se si dispone di un cluster a due nodi, è possibile configurare la proprietà del cluster priority-fencing-delay. Questa proprietà introduce un ritardo nell'isolamento di un nodo con priorità totale più elevata quando si verifica uno scenario split-brain. Per altre informazioni, vedere È possibile che Pacemaker esegua l'isolamento del nodo del cluster con le risorse più in esecuzione?.

La proprietà priority-fencing-delay è applicabile per pacemaker-2.0.4-6.el8 versione o successiva. Se si sta configurando priority-fencing-delay in un cluster esistente, assicurarsi di annullare l'impostazione dell'opzione pcmk_delay_max nel dispositivo di isolamento.

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

Importante

È consigliabile impostare AUTOMATED_REGISTER su false, mentre si eseguono test di failover, per evitare che un'istanza primaria non riuscita venga registrata automaticamente come secondaria. Dopo il test, come procedura consigliata, impostare AUTOMATED_REGISTER su true, in modo che dopo l'acquisizione, la replica di sistema possa riprendere automaticamente.

Assicurarsi che lo stato del cluster sia corretto e che tutte le risorse siano avviate. Il nodo in cui vengono eseguite le risorse non è importante.

Nota

I timeout nella configurazione precedente sono solo esempi e possono essere adattati alla configurazione HANA specifica. Ad esempio, potrebbe essere necessario aumentare il timeout di avvio, se l'avvio del database di SAP HANA richiede più tempo.

Usare il comando sudo pcs status per controllare lo stato delle risorse del cluster create:

# 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

Configurare la replica di sistema attiva/abilitata per la lettura di HANA nel cluster Pacemaker

A partire da SAP HANA 2.0 SPS 01, SAP consente configurazioni attive/abilitate per la lettura per la replica di sistema SAP HANA, in cui i sistemi secondari della replica di sistema SAP HANA possono essere usati attivamente per carichi di lavoro con un'intensa attività di lettura.

Per supportare tale configurazione in un cluster, è necessario un secondo indirizzo IP virtuale, che consente ai client di accedere al database SAP HANA abilitato per la lettura secondario. Per assicurarsi che il sito di replica secondario sia ancora accessibile dopo che si è verificata un'acquisizione, il cluster deve spostare l'indirizzo IP virtuale con la risorsa SAPHana secondaria.

Questa sezione descrive gli altri passaggi necessari per gestire la replica di sistema attiva/abilitata per la lettura di HANA in un cluster Red Hat HA con un secondo indirizzo IP virtuale.

Prima di continuare, assicurarsi di aver configurato completamente il cluster Red Hat HANA che gestisce un database SAP HANA, come descritto nei segmenti precedenti della documentazione.

Diagramma che mostra SAP HANA HA con lettura secondaria abilitata per la lettura.

Configurazione aggiuntiva in Azure Load Balancer per la configurazione attiva/abilitata per la lettura

Per procedere con altri passaggi per il provisioning di un secondo indirizzo IP virtuale, assicurarsi di aver configurato Azure Load Balancer come descritto nella sezione Distribuire manualmente macchine virtuali Linux tramite il portale di Azure.

Per un servizio di bilanciamento del carico Standard, seguire questa procedura sullo stesso servizio di bilanciamento del carico creato in una sezione precedente.

a. Creare un secondo pool di indirizzi IP front-end:
- Aprire il servizio di bilanciamento del carico, selezionare Pool di indirizzi IP front-end e quindi Aggiungi.
- Immettere il nome del secondo pool di indirizzi IP front-end (ad esempio, hana-secondaryIP).
- Impostare Assegnazione su statico e immettere l'indirizzo IP, ad esempio 10.0.0.14.
- Seleziona OK.
- Dopo aver creato il nuovo pool di indirizzi IP front-end, annotare l'indirizzo IP del pool.
b. Creare un probe di integrità:
- Aprire il servizio di bilanciamento del carico, selezionare Probe integrità e quindi Aggiungi.
- Immettere il nome del nuovo probe di integrità (ad esempio, hana-secondaryhp).
- Selezionare TCP come protocollo e la porta 62603. Lasciare il valore di Intervallo impostato su 5 e il valore di Soglia di non integrità impostato su 2.
- Seleziona OK.
c. Creare le regole del servizio di bilanciamento del carico:
- Aprire il servizio di bilanciamento del carico, selezionare Regole di bilanciamento del carico e quindi Aggiungi.
- Immettere il nome della nuova regola di bilanciamento del carico (ad esempio, hana-secondarylb).
- Selezionare l'indirizzo IP front-end, il pool back-end e il probe di integrità creati in precedenza (ad esempio, hana-secondaryIP, hana-backend e hana-secondaryhp).
- Selezionare Porte a disponibilità elevata.
- Assicurarsi di selezionare Abilita l'indirizzo IP mobile.
- Seleziona OK.

Configurare la replica di sistema attiva/abilitata per la lettura di HANA

I passaggi per configurare la replica di sistema HANA sono descritti nella sezione Configurare la replica di sistema SAP HANA 2.0. Se si distribuisce uno scenario secondario abilitato per la lettura, durante la configurazione della replica di sistema nel secondo nodo, eseguire il comando seguente come hanasidadm:

sapcontrol -nr 03 -function StopWait 600 10 

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

Aggiungere una risorsa indirizzo IP virtuale secondario per un'installazione attiva/abilitata per la lettura

Il secondo indirizzo IP virtuale e il vincolo di condivisione appropriato possono essere configurati con i comandi seguenti:

pcs property set maintenance-mode=true

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

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

pcs resource group add g_secip_HN1_03 secnc_HN1_03 secvip_HN1_03

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

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

pcs property set maintenance-mode=false

Assicurarsi che lo stato del cluster sia corretto e che tutte le risorse siano avviate. Il secondo indirizzo IP virtuale viene eseguito nel sito secondario insieme alla risorsa secondaria SAPHana.

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

Nella sezione successiva è possibile trovare il set tipico di test di failover da eseguire.

Tenere presente il secondo comportamento IP virtuale durante il test di un cluster HANA configurato con secondario abilitato per la lettura:

Quando si esegue la migrazione della risorsa cluster SAPHana_HN1_03 al sito secondario hn1-db-1, il secondo indirizzo IP virtuale continua a essere eseguito nello stesso sito hn1-db-1. Se è stato impostato AUTOMATED_REGISTER="true" per la risorsa e la replica di sistema HANA viene registrata automaticamente in hn1-db-0, anche il secondo IP virtuale passa a hn1-db-0.
Durante il test dell'arresto anomalo del server, le seconde risorse IP virtuali (secvip_HN1_03) e la risorsa porta di Azure Load Balancer (secnc_HN1_03) vengono eseguite nel server primario, insieme alle risorse IP virtuali primarie. Quindi, fino al momento in cui il server secondario è inattivo, le applicazioni connesse al database HANA abilitato per la lettura si connettono al database HANA primario. Il comportamento è previsto perché non si desidera che le applicazioni connesse a un database HANA abilitato per la lettura non siano inaccessibili fino al momento in cui il server secondario non è disponibile.
Durante il failover e il fallback del secondo indirizzo IP virtuale, le connessioni esistenti nelle applicazioni che usano il secondo IP virtuale per connettersi al database HANA potrebbero essere interrotte.

La configurazione ottimizza il tempo di assegnazione della seconda risorsa IP virtuale a un nodo in cui è in esecuzione un'istanza di SAP HANA integra.

Testare la configurazione del cluster

Questa sezione descrive come testare la configurazione. Prima di avviare un test, assicurarsi che Pacemaker non abbia alcuna azione non riuscita (tramite lo stato pcs), non ci siano vincoli di posizione imprevisti (ad esempio, a sinistra di un test di migrazione) e che HANA sia in stato di sincronizzazione, ad esempio, con systemReplicationStatus.

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

Test della migrazione

Stato delle risorse prima dell'avvio del 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

È possibile eseguire la migrazione del nodo master SAP HANA eseguendo il comando seguente come radice:

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

Il cluster dovrebbe eseguire la migrazione del nodo master SAP HANA e del gruppo che contiene l'indirizzo IP virtuale in hn1-db-1.

Al termine della migrazione, l'output sudo pcs status sarà simile al seguente:

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

Con AUTOMATED_REGISTER="false", il cluster non riavvia il database HANA non riuscito o lo registra nel nuovo database primario in hn1-db-0. In questo caso, configurare l'istanza di HANA come secondaria eseguendo questo comandi, come hn1adm:

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

La migrazione crea vincoli di posizione che devono essere eliminati di nuovo. Eseguire il comando indicato di seguito come utente radice, o tramite sudo:

pcs resource clear SAPHana_HN1_03-master

Monitorare lo stato della risorsa HANA usando pcs status. Dopo l'avvio di HANA in hn1-db-0, l'output dovrebbe essere simile al seguente:

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

Bloccare la comunicazione di rete

Stato delle risorse prima dell'avvio del 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

Eseguire la regola del firewall per bloccare la comunicazione in uno dei nodi.

# 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

Quando i nodi del cluster non possono comunicare tra loro, esiste il rischio di uno scenario split-brain. In tali situazioni, i nodi del cluster tentano di recintarsi l'uno dall'altro contemporaneamente, comportando una gara di recinzione. Per evitare una situazione di questo tipo, è consigliabile impostare la proprietà priority-fencing-delay nella configurazione del cluster (applicabile solo per pacemaker-2.0.4-6.el8 o versione successiva).

Abilitando la proprietà priority-fencing-delay, il cluster introduce un ritardo nell'azione di isolamento, in particolare nel nodo che ospita la risorsa master HANA, consentendo al nodo di vincere la gara di isolamento.

Eseguire il comando seguente per eliminare la regola del firewall:

# 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

Testare l'agente di isolamento di Azure

Nota

Questo articolo contiene riferimenti a un termine che Microsoft non usa più. Quando il termine verrà rimosso dal software, verrà rimosso anche dall'articolo.

Stato delle risorse prima dell'avvio del 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

È possibile testare la configurazione dell'agente di isolamento di Azure disabilitando l'interfaccia di rete nel nodo in cui SAP HANA viene eseguito come master. Per una descrizione su come simulare un errore della rete, vedere l'articolo 79523 della Knowledge base di Red Hat.

In questo esempio viene usato lo script net_breaker come radice per bloccare tutti gli accessi alla rete:

sh ./net_breaker.sh BreakCommCmd 10.0.0.6

La macchina virtuale dovrebbe ora venire riavviata o arrestata, a seconda della configurazione del cluster. Se si imposta stonith-action su off, la macchina virtuale viene arrestata e le risorse vengono migrate nella macchina virtuale in esecuzione.

Una volta riavviata la macchina virtuale, la risorsa SAP HANA non viene avviata come secondaria se si imposta AUTOMATED_REGISTER="false". In questo caso, configurare l'istanza di HANA come secondaria eseguendo questo comando come utente hn1adm:

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

Tornare alla radice e pulire lo stato di errore:

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

Stato delle risorse dopo il 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

Testare un failover manuale

Stato delle risorse prima dell'avvio del 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

È possibile testare un failover manuale arrestando il cluster nel nodo hn1-db-0 come radice:

pcs cluster stop

Dopo il failover, è possibile avviare di nuovo il cluster. Se si imposta AUTOMATED_REGISTER="false", la risorsa SAP HANA nel nodo hn1-db-0 non viene avviata come secondaria. In questo caso, configurare l'istanza di HANA come secondaria eseguendo questo comando come radice:

pcs cluster start

Eseguire il comando seguente come hn1adm:

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

Quindi come radice:

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

Stato delle risorse dopo il 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

Condividi tramite

Disponibilità elevata di SAP HANA in macchine virtuali di Azure su Red Hat Enterprise Linux

Prerequisiti

Panoramica

Preparare l'infrastruttura

Distribuire macchine virtuali Linux manualmente tramite il portale di Azure

Configurare il servizio di bilanciamento del carico di Azure

Installare SAP HANA

Configurare la replica di sistema di SAP HANA 2.0

Creare un cluster Pacemaker

Implementare hook di replica di sistema SAP HANA

Creare le risorse cluster SAP HANA

Configurare la replica di sistema attiva/abilitata per la lettura di HANA nel cluster Pacemaker

Configurazione aggiuntiva in Azure Load Balancer per la configurazione attiva/abilitata per la lettura

Configurare la replica di sistema attiva/abilitata per la lettura di HANA

Aggiungere una risorsa indirizzo IP virtuale secondario per un'installazione attiva/abilitata per la lettura

Testare la configurazione del cluster

Test della migrazione

Bloccare la comunicazione di rete

Testare l'agente di isolamento di Azure

Testare un failover manuale

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive