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

Articolo
04/08/2024

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

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 macchine virtuali (VM), installare il framework del cluster e 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, che include:
- 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.
- Combinazioni di database e software SAP e sistema operativo 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.
Nota SAP 2002167 ha le impostazioni del sistema operativo consigliate per Red Hat Enterprise Linux.
Nota SAP 2009879 include le linee guida di SAP HANA per Red Hat Enterprise Linux.
Nota SAP 3108302 include 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.
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 in un 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 la panoramica della disponibilità elevata di SAP HANA.

La 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 servizio di 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 manualmente le macchine virtuali Linux 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 SAP HANA Certified IaaS Platforms. Assicurarsi di esaminare i dettagli del tipo di macchina virtuale per ottenere l'elenco completo delle versioni del sistema operativo supportate da SAP HANA per il tipo di macchina virtuale specifico.

Configurare il servizio di bilanciamento del carico di Azure

Durante la configurazione della macchina virtuale, è possibile creare o selezionare l'uscita dal servizio di bilanciamento del carico 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à numberOfProbesdi configurazione del probe di integrità , 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.

Importante

L'indirizzo IP mobile non è supportato in una configurazione IP secondaria della scheda di interfaccia di rete negli scenari di bilanciamento del carico. Per altre informazioni, vedere Limitazioni di Azure Load Balancer. Se è necessario un altro indirizzo IP per la macchina virtuale, distribuire una seconda scheda di interfaccia di rete.

Nota

Quando le macchine virtuali senza indirizzi IP pubblici vengono inserite nel pool back-end di un'istanza interna (nessun indirizzo IP pubblico) di Azure Load Balancer Standard, non esiste connettività Internet in uscita, a meno che non venga eseguita più configurazione per consentire il routing agli endpoint pubblici. Per altre informazioni su come ottenere la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali che usano Azure Load Balancer Standard in scenari di disponibilità elevata SAP.

Importante

Non abilitare i timestamp TCP nelle macchine virtuali di Azure posizionate dietro Azure Load Balancer. L'abilitazione dei timestamp TCP potrebbe causare l'esito negativo dei probe di integrità. Impostare il parametro net.ipv4.tcp_timestamps su 0. Per altre informazioni, vedere Probe di integrità del servizio di bilanciamento del carico e note SAP 2382421.

Installare SAP HANA

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.

[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. Nell'esempio seguente si presuppone che le macchine virtuali abbiano quattro dischi dati collegati che vengono 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 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 nelle 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 di striping.

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 quando si crea 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 in fstab e rilasciare una finale mount -a 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
```
fstab Creare quindi voci per i tre volumi logici inserendo le righe seguenti nel /etc/fstab file:

/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 /etc/hosts file 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)
- 2777782 - DATABASE SAP HANA: Impostazioni del sistema operativo consigliato per RHEL 8
- 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.

Per installare la replica di sistema SAP HANA, vedere Automating SAP HANA Scale-Up System Replication using the RHEL HA ADD-On (Automazione della replica del sistema SAP HANA tramite il componente aggiuntivo RHEL HA).

Eseguire il programma hdblcm dal DVD di HANA. Immettere i valori seguenti al prompt:
1. Choose installation: immettere 1.
2. Select additional components for installation: immettere 1.
3. Immettere percorso di installazione [/hana/shared]: selezionare INVIO.
4. Immettere il nome host locale [..]: selezionare INVIO.
5. Aggiungere altri host al sistema? (y/n) [n]: premere INVIO.
6. Immettere l'ID sistema SAP HANA: immettere il SID di HANA, ad esempio: HN1.
7. Immettere il numero di istanza [00]: immettere il numero di istanza di HANA. Immettere 03 se è stato usato il modello di Azure o se è stata seguita la sezione di questo articolo relativa alla distribuzione manuale.
8. Selezionare la modalità di database / Immettere l'indice [1]: selezionare Invio.
9. Selezionare Utilizzo sistema/Immettere indice [4]: selezionare il valore di utilizzo del sistema.
10. Immettere la posizione dei volumi di dati [/hana/data]: selezionare INVIO.
11. Immettere il percorso dei volumi di log [/hana/log]: selezionare INVIO.
12. Limitare l'allocazione massima della memoria? [n]: premere INVIO.
13. Immettere il nome host del certificato per l'host '...' [...]: selezionare Invio.
14. Immettere la password dell'utente dell'agente host SAP (sapadm): immettere la password utente dell'agente host.
15. Confermare la password dell'utente dell'agente host SAP (sapadm): immettere di nuovo la password utente dell'agente host per confermare.
16. Immettere System Amministrazione istrator (hdbadm) Password: immettere la password dell'amministratore di sistema.
17. Confermare la password di System Amministrazione istrator (hdbadm): immettere di nuovo la password dell'amministratore di sistema per confermare.
18. Immettere System Amministrazione istrator Home Directory [/usr/sap/HN1/home]: Selezionare INVIO.
19. Immettere System Amministrazione istrator Login Shell [/bin/sh]: Selezionare INVIO.
20. Immettere l'ID utente di System Amministrazione istrator [1001]: selezionare INVIO.
21. Immettere l'ID del gruppo di utenti (sapsys) [79]: selezionare INVIO.
22. Immettere Password utente database (SYSTEM): immettere la password utente del database.
23. Conferma password utente database (SYSTEM): immettere di nuovo la password utente del database per confermare.
24. Riavviare il sistema dopo il riavvio della macchina? [n]: premere INVIO.
25. Vuoi continuare? (y/n): convalidare il riepilogo. Immettere y per continuare.
[T] Aggiornare l'agente host SAP.

Scaricare l'archivio dell'agente host SAP più recente dal sito SAP Software Center ed eseguire il comando seguente per aggiornare l'agente. Sostituire il percorso dell'archivio in modo da puntare al file scaricato:
```
sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent>;
```

[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 la replica di sistema HANA 2.0 e il traffico 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.

Se si usa SAP HANA 2.0 o MDC, creare un database tenant per il sistema SAP NetWeaver. Sostituire NW1 con il SID del sistema SAP.

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

[1] Controllare lo stato della replica.

Controllare lo stato della replica e attendere che tutti i database siano sincronizzati. Se lo stato rimane UNKNOWN, 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

Configurare la replica di sistema di SAP HANA 1.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 HANA 2.0 System Replication. Adattarli alla propria installazione di SAP HANA 1.0.
```
sudo firewall-cmd --zone=public --add-port=40302/tcp --permanent
sudo firewall-cmd --zone=public --add-port=40302/tcp
```
[1] Creare gli utenti richiesti.

Eseguire il comando indicato di seguito come utente ROOT. Assicurarsi di sostituire i valori per HANA System ID (ad esempio, HN1), numero di istanza (03) ed eventuali nomi utente, con i valori dell'installazione di SAP HANA:
```
PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbsql -u system -i 03 'CREATE USER hdbhasync PASSWORD "passwd"'
hdbsql -u system -i 03 'GRANT DATA ADMIN TO hdbhasync'
hdbsql -u system -i 03 'ALTER USER hdbhasync DISABLE PASSWORD LIFETIME'
```
[T] Creare una voce di archivio chiavi.

Eseguire il comando seguente come utente ROOT per creare una nuova voce di archivio chiavi:
```
PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbuserstore SET hdbhaloc localhost:30315 hdbhasync passwd
```

[1] Eseguire il backup del database.

Eseguire il backup dei database come utente ROOT:

PATH="$PATH:/usr/sap/HN1/HDB03/exe"
hdbsql -d SYSTEMDB -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"

Se si usa un'installazione multi-tenant, eseguire anche il backup del database tenant:

hdbsql -d HN1 -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"

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

Creare il sito primario come <hanasid>adm:
```
su - hdbadm
hdbnsutil -sr_enable –-name=SITE1
```

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

Registrare il sito secondario come <hanasid>adm:

HDB stop
hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
HDB start

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, 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 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 l'hook di replica del sistema Python SAPHanaSR

Questo passaggio importante ottimizza l'integrazione con il cluster e migliora il rilevamento quando è necessario un failover del cluster. È consigliabile configurare l'hook Python SAPHanaSR.

[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 la disponibilità elevata di RHEL 8.x.
```
# Enable repository that contains SAP HANA resource agents
sudo subscription-manager repos --enable="rhel-sap-hana-for-rhel-7-server-rpms"

sudo yum install -y resource-agents-sap-hana
```

[A] Installare HANA system replication hook. L'hook deve essere installato in entrambi i nodi del database HANA.

Suggerimento

L'hook Python può essere implementato solo per HANA 2.0.

Preparare l'hook come root.

 mkdir -p /hana/shared/myHooks
 cp /usr/share/SAPHanaSR/srHook/SAPHanaSR.py /hana/shared/myHooks
 chown -R hn1adm:sapsys /hana/shared/myHooks

Arrestare HANA in entrambi i nodi. Eseguire come <sid>adm.
```
sapcontrol -nr 03 -function StopSystem
```

Regolare global.ini in ogni nodo del cluster.

[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /hana/shared/myHooks
execution_order = 1

[trace]
ha_dr_saphanasr = info

[A] Il cluster richiede la sudoers configurazione in ogni nodo del cluster per <sid>adm. In questo esempio si ottiene creando un nuovo file. Usare il visudo comando per modificare il 20-saphana file di rilascio 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 SAP HANA in entrambi i nodi. Eseguire come <sid>adm.
```
sapcontrol -nr 03 -function StartSystem 
```

[1] Verificare l'installazione dell'hook. 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

Per altre informazioni sull'implementazione dell'hook di replica di sistema SAP HANA, vedere Abilitare l'hook del provider SAP HA/DR.

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 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 priority-fencing-delay cluster. 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 Can Pacemaker fence the cluster node with the fewest running resources?.

La proprietà priority-fencing-delay è applicabile per pacemaker-2.0.4-6.el8 versione o successiva. Se si sta priority-fencing-delay configurando 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 su AUTOMATED_REGISTERfalse, 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 su AUTOMATED_REGISTERtrue 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 vengano avviate. Il nodo in cui vengono eseguite le risorse non è importante.

Nota

I timeout nella configurazione precedente sono solo esempi e potrebbero essere necessari per adattarsi alla configurazione specifica di HANA. Ad esempio, potrebbe essere necessario aumentare il timeout di avvio, se l'avvio del database 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 le macchine virtuali Linux tramite 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 porta 62603. Mantenere il valore interval impostato su 5 e il valore soglia non integro 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à creato 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 vengano 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 è stata impostata AUTOMATED_REGISTER="true" per la risorsa e la replica di sistema HANA viene registrata automaticamente in hn1-db-0, anche il secondo INDIRIZZO IP virtuale passa a hn1-db-0.
Durante il test di un 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 al 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 eseguirà la migrazione del nodo master SAP HANA e del gruppo contenente l'indirizzo IP virtuale a 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 questi 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 seguente come 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 steccato l'uno contemporaneamente, causando 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 priority-fencing-delay proprietà, il cluster introduce un ritardo nell'azione di isolamento specificamente 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 di rete, vedere l'articolo della Knowledge Base di Red Hat 79523.

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

sh ./net_breaker.sh BreakCommCmd 10.0.0.6

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

Dopo aver avviato nuovamente 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 hn1-db-0 nodo, 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 hn1-db-0 nodo 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

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

Prerequisiti

Panoramica

Preparare l'infrastruttura

Distribuire manualmente le macchine virtuali Linux 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

Configurare la replica di sistema di SAP HANA 1.0

Creare un cluster Pacemaker

Implementare l'hook di replica del sistema Python SAPHanaSR

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

Risorse aggiuntive