Disponibilità elevata per SAP HANA in macchine virtuali di Azure su SU edizione Standard Linux Enterprise Server

Articolo
04/08/2024

Per stabilire la disponibilità elevata in una distribuzione SAP HANA locale, è possibile usare la replica di sistema SAP HANA o l'archiviazione condivisa.

Attualmente nelle macchine virtuali di Azure, la replica di sistema SAP HANA in Azure è l'unica funzione di disponibilità elevata supportata.

La replica di sistema 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 e installare e configurare la replica di sistema SAP HANA.

Prima di iniziare, leggere le note e i documenti SAP seguenti:

Nota SAP 1928533. La nota 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.
- Le combinazioni di software SAP, sistema operativo e database supportate.
- Versioni del kernel SAP necessarie per Windows e Linux in Microsoft Azure.
Nota SAP 2015553, che elenca i prerequisiti per le distribuzioni di software SAP supportate da SAP in Azure.
Nota SAP 2205917 ha le impostazioni consigliate del sistema operativo per SU edizione Standard Linux Enterprise Server 12 (SLES 12) per le applicazioni SAP.
Nota SAP 2684254 ha le impostazioni consigliate del sistema operativo per SU edizione Standard Linux Enterprise Server 15 (SLES 15) per le applicazioni SAP.
Nota SAP 2235581 include sistemi operativi supportati da SAP HANA
Nota SAP 2178632 include informazioni dettagliate su tutte le metriche di monitoraggio segnalate per SAP in Azure.
Nota SAP 2191498 ha la versione dell'agente host SAP necessaria per Linux in Azure.
Nota SAP 2243692 contiene informazioni sulle licenze SAP per Linux in Azure.
La nota SAP 1984787 contiene informazioni generali su SUSE Linux Enterprise Server 12.
Nota SAP 1999351 contiene altre informazioni sulla risoluzione dei problemi per l'estensione di monitoraggio avanzato di Azure per SAP.
Nota SAP 401162 contiene informazioni su come evitare errori di "indirizzo già in uso" durante la configurazione della replica di sistema HANA.
Sap Community Support Wiki include tutte le note SAP necessarie per Linux.
Sap HANA Certified IaaS Platforms(Piattaforme IaaS certificate per SAP HANA).
Guida alla pianificazione e all'implementazione di macchine virtuali di Azure per SAP in Linux.
Guida alla distribuzione di Azure Macchine virtuali per SAP in Linux.
Guida Distribuzione di DBMS in macchine virtuali di Azure per SAP in Linux.
Guide alle procedure consigliate su SU edizione Standard Linux Enterprise Server for SAP Applications 15 e SU edizione Standard Linux Enterprise Server for SAP Applications 12:
- Configurazione di un'infrastruttura ottimizzata per le prestazioni di SAP HANA SR (SLES for SAP Applications). La guida contiene tutte le informazioni necessarie per configurare la replica di sistema SAP HANA per lo sviluppo locale. Usare la guida per le indicazioni di base.
- Configurazione di un'infrastruttura ottimizzata per i costi di SAP HANA SR (SLES for SAP Applications).

Pianificare la disponibilità elevata di SAP HANA

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

Diagramma che mostra una 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 distribuire un indirizzo IP virtuale.

La figura precedente mostra un servizio di bilanciamento del carico di esempio con queste configurazioni:

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

Preparare l'infrastruttura

L'agente delle risorse per SAP HANA è incluso in SUSE Linux Enterprise Server for SAP Applications. Un'immagine per SU edizione Standard Linux Enterprise Server for SAP Applications 12 o 15 è disponibile in Azure Marketplace. È possibile usare l'immagine per distribuire nuove macchine virtuali.

Distribuire macchine virtuali Linux manualmente tramite il portale di Azure

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

Distribuire macchine virtuali per SAP HANA. Scegliere un'immagine SLES appropriata supportata per il sistema HANA. È possibile distribuire una macchina virtuale in una delle opzioni di disponibilità, ovvero 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

Un indirizzo IP mobile non è supportato in una configurazione IP secondaria della scheda di interfaccia di rete (NIC) in scenari di bilanciamento del carico. Per informazioni dettagliate, 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 che non dispongono di indirizzi IP pubblici vengono inserite nel pool back-end di un'istanza standard (nessun indirizzo IP pubblico) di Azure Load Balancer, la configurazione predefinita non è connettività Internet in uscita. È possibile eseguire passaggi aggiuntivi per consentire il routing agli endpoint pubblici. Per informazioni dettagliate su come ottenere la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali usando Azure Load Balancer Standard in scenari a disponibilità elevata SAP.

Importante

Non abilitare i timestamp TCP nelle macchine virtuali di Azure posizionate dietro Azure Load Balancer. L'abilitazione dei timestamp TCP causa l'esito negativo dei probe di integrità. Impostare il parametro net.ipv4.tcp_timestamps su 0. Per informazioni dettagliate, vedere Probe di integrità di Load Balancer o note SAP 2382421.
Per impedire a saptune di modificare il valore impostato net.ipv4.tcp_timestamps manualmente da 0 a 1, aggiornare la versione di saptune alla versione 3.1.1 o successiva. Per altri dettagli, vedere saptune 3.1.1 – Do I Need to Update?.

Creare un cluster Pacemaker

Seguire la procedura descritta in Configurare Pacemaker su SU edizione Standard Linux Enterprise Server in Azure per creare un cluster Pacemaker di base per questo server HANA. È possibile usare lo stesso cluster Pacemaker per SAP HANA e SAP NetWeaver (A)SCS.

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.

Sostituire <placeholders> con i valori per l'installazione di SAP HANA.

[A] Configurare il layout dei dischi usando l’utilità di gestione dei volumi logici (LVM).

È 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 usati per creare due volumi.
1. Eseguire questo comando per elencare tutti i dischi disponibili:
```
/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
```
2. 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
```
3. Creare un gruppo di volumi per i file di dati. Usare un gruppo di volumi per i file di log e un gruppo di volumi per la directory condivisa di SAP HANA:
```
sudo vgcreate vg_hana_data_<HANA SID> /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
sudo vgcreate vg_hana_log_<HANA SID> /dev/disk/azure/scsi1/lun2
sudo vgcreate vg_hana_shared_<HANA SID> /dev/disk/azure/scsi1/lun3
```
4. 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 descritti nelle configurazioni di archiviazione delle macchine virtuali SAP HANA. L'argomento -i deve essere il numero di volumi fisici sottostanti e l'argomento -I è la dimensione della striscia.
  
  Ad esempio, se per il volume di dati vengono usati due volumi fisici, l'argomento -i switch è impostato su 2 e le dimensioni di striping per il volume di dati sono pari a 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
  
  Quando si usano più volumi fisici per ogni volume di dati, volume di log o volume condiviso, usare l'opzione e impostarne il -i numero di volumi fisici sottostanti. Quando si crea un volume con striping, usare l'opzione -I per specificare le dimensioni della striscia.
  
  Per le configurazioni di archiviazione consigliate, incluse le dimensioni di striping e il numero di dischi, vedere Configurazioni di archiviazione delle macchine virtuali SAP HANA.
```
sudo lvcreate <-i number of physical volumes> <-I stripe size for the data volume> -l 100%FREE -n hana_data vg_hana_data_<HANA SID>
sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_<HANA SID>
sudo lvcreate -l 100%FREE -n hana_shared vg_hana_shared_<HANA SID>
sudo mkfs.xfs /dev/vg_hana_data_<HANA SID>/hana_data
sudo mkfs.xfs /dev/vg_hana_log_<HANA SID>/hana_log
sudo mkfs.xfs /dev/vg_hana_shared_<HANA SID>/hana_shared
```
5. Creare le directory di montaggio e copiare l'identificatore univoco universale (UUID) di tutti i volumi logici:
```
sudo mkdir -p /hana/data/<HANA SID>
sudo mkdir -p /hana/log/<HANA SID>
sudo mkdir -p /hana/shared/<HANA SID>
# Write down the ID of /dev/vg_hana_data_<HANA SID>/hana_data, /dev/vg_hana_log_<HANA SID>/hana_log, and /dev/vg_hana_shared_<HANA SID>/hana_shared
sudo blkid
```
6. Modificare il file /etc/fstab per creare fstab voci per i tre volumi logici:
```
sudo vi /etc/fstab
```
7. Inserire le righe seguenti nel file /etc/fstab :
```
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_data_<HANA SID>-hana_data> /hana/data/<HANA SID> xfs  defaults,nofail  0  2
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_log_<HANA SID>-hana_log> /hana/log/<HANA SID> xfs  defaults,nofail  0  2
/dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_<HANA SID>-hana_shared> /hana/shared/<HANA SID> xfs  defaults,nofail  0  2
```
8. Montare i nuovi volumi:
```
sudo mount -a
```
[A] Configurare il layout del disco usando dischi semplici.

Per sistemi demo, è possibile inserire i dati e i file di log HANA in un solo disco.
1. Creare una partizione in /dev/disk/azure/scsi1/lun0 e formattarla usando XFS:
```
sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0'
sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1

# Write down the ID of /dev/disk/azure/scsi1/lun0-part1
sudo /sbin/blkid
sudo vi /etc/fstab
```
2. Nel file /etc/fstab Inserire la riga seguente:
```
/dev/disk/by-uuid/<UUID> /hana xfs  defaults,nofail  0  2
```
3. Creare la directory di destinazione e montare il disco:
```
sudo mkdir /hana
sudo mount -a
```
[T] 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. Questo esempio illustra come usare il file /etc/hosts . Sostituire gli indirizzi IP e i nomi host nei comandi seguenti.
1. Modificare il file /etc/hosts :
```
sudo vi /etc/hosts
```
2. Inserire le righe seguenti nel file /etc/hosts . Modificare gli indirizzi IP e i nomi host in modo che corrispondano all'ambiente.
```
10.0.0.5 hn1-db-0
10.0.0.6 hn1-db-1
```
[T] Installare i pacchetti di disponibilità elevata SAP HANA:
- Eseguire il comando seguente per installare i pacchetti a disponibilità elevata:
```
sudo zypper install SAPHanaSR
```
Per installare la replica di sistema SAP HANA, vedere il capitolo 4 nella guida agli scenari ottimizzati per le prestazioni di SAP HANA SR.
[A] Eseguire il programma hdblcm dal supporto di installazione di HANA.

Quando richiesto, immettere i valori seguenti:
1. Choose installation: immettere 1.
2. Select additional components for installation: immettere 1.
3. Immettere il percorso di installazione: immettere /hana/shared e selezionare INVIO.
4. Immettere il nome host locale: immettere .. e selezionare INVIO.
5. Aggiungere altri host al sistema? (y/n): immettere n e selezionare INVIO.
6. Immettere l'ID di sistema SAP HANA: immettere il SID HANA.
7. Immettere il numero di istanza: immettere il numero di istanza di HANA. Se è stato distribuito usando il modello di Azure o se è stata seguita la sezione distribuzione manuale di questo articolo, immettere 03.
8. Selezionare la modalità di database/ Immettere l'indice: immettere o selezionare 1 e selezionare INVIO.
9. Selezionare l'utilizzo del sistema/ Immettere l'indice: selezionare il valore di utilizzo del sistema 4.
10. Immettere il percorso dei volumi di dati: immettere /hana/data/<SID> HANA e selezionare Invio.
11. Immettere il percorso dei volumi di log: immettere /hana/log/<SID> HANA e selezionare Invio.
12. Limitare l'allocazione massima di memoria?: immettere n e selezionare INVIO.
13. Immettere il nome host del certificato per l'host: immettere ... e selezionare INVIO.
14. Immettere la password dell'utente dell'agente host SAP (sapadm): immettere la password utente dell'agente host e quindi premere INVIO.
15. Confermare la password dell'utente dell'agente host SAP (sapadm): immettere di nuovo la password utente dell'agente host e quindi selezionare Invio.
16. Immettere la password dell'amministratore di sistema (hdbadm): immettere la password dell'amministratore di sistema e quindi premere INVIO.
17. Confermare la password dell'amministratore di sistema (hdbadm): immettere di nuovo la password dell'amministratore di sistema e quindi selezionare Invio.
18. Immettere la home directory dell'amministratore di sistema: immettere /usr/sap/<HANA SID>/home e selezionare Invio.
19. Immettere la shell di accesso dell'amministratore di sistema: immettere /bin/sh e selezionare INVIO.
20. Immettere l'ID utente amministratore di sistema: immettere 1001 e selezionare INVIO.
21. Immettere l'ID del gruppo di utenti (sapsys): immettere 79 e selezionare INVIO.
22. Immettere la password dell'utente del database (SYSTEM): immettere la password utente del database e quindi selezionare INVIO.
23. Confermare la password dell'utente del database (SYSTEM): immettere di nuovo la password utente del database e quindi selezionare Invio.
24. Riavviare il sistema dopo il riavvio del computer? (y/n): immettere n e selezionare INVIO.
25. Vuoi continuare? (y/n): verificare il riepilogo. Immettere y per continuare.
[A] Aggiornare l'agente host SAP.

Scaricare l'archivio più recente dell'agente host SAP da SAP Software Center. Eseguire il comando seguente per aggiornare l'agente. Sostituire il percorso dell'archivio in modo che punti al file scaricato.
```
sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP host agent SAR>
```

Configurare la replica di sistema 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.

Sostituire <placeholders> con i valori per l'installazione di SAP HANA.

[1] Creare il database tenant.

Se si usa SAP HANA 2.0 o SAP HANA MDC, creare un database tenant per il sistema SAP NetWeaver.

Eseguire il comando seguente come <adm SID>DI HANA:
```
hdbsql -u SYSTEM -p "<password>" -i <instance number> -d SYSTEMDB 'CREATE DATABASE <SAP SID> SYSTEM USER PASSWORD "<password>"'
```

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

Prima di tutto, eseguire il backup dei database come <adm SID>DI HANA:

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

Copiare quindi i file PKI (Public Key Infrastructure) del sistema nel sito secondario:

scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/SSFS_<HANA SID>.DAT   hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/data/
scp /usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/SSFS_<HANA SID>.KEY  hn1-db-1:/usr/sap/<HANA SID>/SYS/global/security/rsecssfs/key/

Creare il sito primario:

hdbnsutil -sr_enable --name=<site 1>

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

Registrare il secondo nodo per avviare la replica di sistema.

Eseguire il comando seguente come <adm SID>DI HANA:

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

Configurare la replica di sistema 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.

Sostituire <placeholders> con i valori per l'installazione di SAP HANA.

[1] Creare gli utenti richiesti.

Eseguire il comando seguente come Root:

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

[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/<HANA SID>/HDB<instance number>/exe"
hdbuserstore SET hdbhaloc localhost:3<instance number>15 hdbhasync <password>

[1] Eseguire il backup del database.

Eseguire il backup dei database come utente ROOT:

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

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

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

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

Creare il sito primario come <adm SID>DI HANA:
```
su - hdbadm
hdbnsutil -sr_enable --name=<site 1>
```

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

Registrare il sito secondario come <adm SID>DI HANA:

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

Implementare hook HANA SAPHanaSR e susChkSrv

In questo passaggio importante si ottimizza l'integrazione con il cluster e si migliora il rilevamento quando è necessario un failover del cluster. È consigliabile configurare l'hook Python SAPHanaSR. Per HANA 2.0 SP5 e versioni successive, è consigliabile implementare l'hook SAPHanaSR e l'hook susChkSrv.

L'hook susChkSrv estende la funzionalità del provider di disponibilità elevata SAPHanaSR principale. Agisce quando il processo HDbindexserver di HANA si arresta in modo anomalo. Se un singolo processo si arresta in modo anomalo, HANA tenta in genere di riavviarlo. Il riavvio del processo indexserver può richiedere molto tempo, durante il quale il database HANA non risponde.

Con susChkSrv implementato, viene eseguita un'azione immediata e configurabile. L'azione attiva un failover nel periodo di timeout configurato anziché attendere il riavvio del processo hdbindexserver nello stesso nodo.

[A] Installare l'hook di replica di sistema HANA. L'hook deve essere installato in entrambi i nodi del database HANA.

Suggerimento

L'hook Python SAPHanaSR può essere implementato solo per HANA 2.0. Il pacchetto SAPHanaSR deve essere almeno la versione 0.153.

L'hook python susChkSrv richiede l'installazione di SAP HANA 2.0 SP5 e della versione di SAPHanaSR 0.161.1_BF o versioni successive.
1. Arrestare HANA in entrambi i nodi.
  
  Eseguire il codice seguente come <sapsid>adm:
```
sapcontrol -nr <instance number> -function StopSystem
```
2. Modificare global.ini in ogni nodo del cluster. Se i requisiti per l'hook susChkSrv non sono soddisfatti, rimuovere l'intero [ha_dr_provider_suschksrv] blocco dai parametri seguenti.
  
  È possibile modificare il comportamento di susChkSrv usando il action_on_lost parametro . I valori validi sono [ ignorekill | fencestop | | ].
```
# add to global.ini
[ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR
execution_order = 1

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

[trace]
ha_dr_saphanasr = info
```
  Se si punta al percorso standard /usr/share/SAPHanaSR , 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 usata.
[A] Il cluster richiede la configurazione sudoers in ogni nodo del cluster per <l'adm SAP SID>. In questo esempio si ottiene creando un nuovo file.

Eseguire il comando seguente come Root:
```
 cat << EOF > /etc/sudoers.d/20-saphana
 # Needed for SAPHanaSR and susChkSrv Python hooks
 hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
 hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=HN1 --case=fenceMe
 EOF
```
Per informazioni dettagliate sull'implementazione dell'hook di replica di sistema SAP HANA, vedere Configurare i provider ha/ripristino di emergenza di HANA.
[A] Avviare SAP HANA in entrambi i nodi.

Eseguire il comando seguente come <ADM SAP SID>:
```
 sapcontrol -nr <instance number> -function StartSystem 
```

[1] Verificare l'installazione dell'hook.

Eseguire il comando seguente come <ADM SAP SID>nel sito di replica del sistema HANA attivo:

 cdtrace
 awk '/ha_dr_SAPHanaSR.*crm_attribute/ \
 { printf "%s %s %s %s\n",$2,$3,$5,$16 }' nameserver_*
 # Example output
 # 2021-04-08 22:18:15.877583 ha_dr_SAPHanaSR SFAIL
 # 2021-04-08 22:18:46.531564 ha_dr_SAPHanaSR SFAIL
 # 2021-04-08 22:21:26.816573 ha_dr_SAPHanaSR SOK

Verificare l'installazione dell'hook susChkSrv.

Eseguire il comando seguente come <ADM SAP SID>in tutte le macchine virtuali HANA:

 cdtrace
 egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
 # Example output
 # 2022-11-03 18:06:21.116728  susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
 # 2022-11-03 18:06:27.613588  START: indexserver event looks like graceful tenant start
 # 2022-11-03 18:07:56.143766  START: indexserver event looks like graceful tenant start (indexserver started)

Creare le risorse cluster SAP HANA

Prima di tutto, creare la topologia HANA.

Eseguire i comandi seguenti in uno dei nodi del cluster Pacemaker:

sudo crm configure property maintenance-mode=true

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

sudo crm configure primitive rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> ocf:suse:SAPHanaTopology \
  operations \$id="rsc_sap2_<HANA SID>_HDB<instance number>-operations" \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="<HANA SID>" InstanceNumber="<instance number>"

sudo crm configure clone cln_SAPHanaTopology_<HANA SID>_HDB<instance number> rsc_SAPHanaTopology_<HANA SID>_HDB<instance number> \
  meta clone-node-max="1" target-role="Started" interleave="true"

Creare quindi le risorse HANA:

Importante

Nei test recenti, netcat smette di rispondere alle richieste a causa di un backlog e a causa della limitazione della gestione di una sola connessione. La netcat risorsa smette di ascoltare le richieste di Azure Load Balancer e l'INDIRIZZO IP mobile non è più disponibile.

Per i cluster Pacemaker esistenti, in precedenza è consigliabile sostituire netcat con socat. Attualmente, è consigliabile usare l'agente azure-lb di risorse, che fa parte di un pacchetto di resource-agents. Sono necessarie le versioni del pacchetto seguenti:

Per SLES 12 SP4/SP5 la versione deve essere almeno resource-agents-4.3.018.a7fb5035-3.30.1.
Per SLES 15/15 SP1 la versione deve essere almeno resource-agents-4.3.0184.6ee15eb2-4.13.1.

Per apportare questa modifica è necessario un breve tempo di inattività.

Per i cluster Pacemaker esistenti, se la configurazione è già stata modificata per l'uso socat come descritto in Protezione avanzata del rilevamento di Azure Load Balancer, non è necessario passare immediatamente all'agente azure-lb di risorse.

Nota

Questo articolo contiene riferimenti a termini che Microsoft non usa più. Quando questi termini verranno rimossi dal software, verranno rimossi da questo articolo.

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

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

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

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

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

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

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

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

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

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

sudo crm configure property priority-fencing-delay=30

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

Importante

È consigliabile impostare su AUTOMATED_REGISTERfalse solo mentre si completano test di failover completi, per impedire a un'istanza primaria non riuscita di eseguire automaticamente la registrazione come secondaria. Al termine dei test di failover, impostare su AUTOMATED_REGISTERtrue, in modo che dopo l'acquisizione, la replica di sistema riprende automaticamente.

Assicurarsi che lo stato del cluster sia OK e che tutte le risorse siano avviate. Non importa in quale nodo sono in esecuzione le risorse.

sudo crm_mon -r

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Configurare la replica di sistema attiva/abilitata per la lettura haNA in un cluster Pacemaker

In SAP HANA 2.0 SPS 01 e versioni successive SAP consente un'installazione attiva/abilitata per la lettura per la replica di sistema SAP HANA. In questo scenario, i sistemi secondari della replica di sistema SAP HANA possono essere usati attivamente per carichi di lavoro a elevato utilizzo di lettura.

Per supportare questa configurazione in un cluster, è necessario un secondo indirizzo IP virtuale in modo che i client possano accedere al database SAP HANA abilitato per la lettura secondario. Per assicurarsi che il sito di replica secondario sia ancora accessibile dopo un'acquisizione, il cluster deve spostare l'indirizzo IP virtuale con il database secondario della risorsa SAPHana.

Questa sezione descrive i passaggi aggiuntivi necessari per gestire una replica di sistema attiva/abilitata per la lettura di HANA in un cluster su edizione Standard a disponibilità elevata che usa un secondo indirizzo IP virtuale.

Prima di procedere, assicurarsi di aver configurato completamente il cluster SU edizione Standard a disponibilità elevata che gestisce il database SAP HANA, come descritto nelle sezioni precedenti.

Diagramma che mostra un esempio di disponibilità elevata di SAP HANA con un indirizzo IP secondario abilitato per la lettura.

Configurare il servizio di bilanciamento del carico per la replica di sistema attiva/abilitata per la lettura

Per procedere con passaggi aggiuntivi per effettuare il provisioning del secondo indirizzo IP virtuale, assicurarsi di aver configurato Azure Load Balancer come descritto in Distribuire manualmente le macchine virtuali Linux tramite portale di Azure.

Per il servizio di bilanciamento del carico standard , completare questi passaggi aggiuntivi sullo stesso servizio di bilanciamento del carico creato in precedenza.

Creare un secondo pool di indirizzi IP front-end:
1. Aprire il servizio di bilanciamento del carico, selezionare Pool di indirizzi IP front-end e quindi Aggiungi.
2. Immettere il nome del secondo pool di indirizzi IP front-end, ad esempio hana-secondaryIP.
3. Impostare Assegnazione su Statico e immettere l'indirizzo IP, ad esempio 10.0.0.14.
4. Seleziona OK.
5. Dopo aver creato il nuovo pool di indirizzi IP front-end, prendere nota dell'indirizzo IP front-end.
Creare un probe di integrità:
1. Nel servizio di bilanciamento del carico selezionare probe di integrità e selezionare Aggiungi.
2. Immettere il nome del nuovo probe di integrità, ad esempio hana-secondaryhp.
3. Selezionare TCP come protocollo e numero> di istanza della porta 626<. Mantenere il valore interval impostato su 5 e il valore soglia non integro impostato su 2.
4. Seleziona OK.
Creare le regole di bilanciamento del carico:
1. Nel servizio di bilanciamento del carico selezionare Regole di bilanciamento del carico e selezionare Aggiungi.
2. Immettere il nome della nuova regola di bilanciamento del carico, ad esempio hana-secondarylb.
3. 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.
4. Selezionare Porte a disponibilità elevata.
5. Aumentare il timeout di inattività a 30 minuti.
6. Assicurarsi di abilitare l'indirizzo IP mobile.
7. 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 in Configurare la replica di sistema SAP HANA 2.0. Se si distribuisce uno scenario secondario abilitato per la lettura, quando si configura la replica di sistema nel secondo nodo, eseguire il comando seguente come <adm SID>HANA:

sapcontrol -nr <instance number> -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2> --operationMode=logreplay_readaccess

Aggiungere una risorsa indirizzo IP virtuale secondario

È possibile configurare il secondo indirizzo IP virtuale e il vincolo di condivisione appropriato usando i comandi seguenti:

crm configure property maintenance-mode=true

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

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

crm configure group g_secip_<HANA SID>_HDB<instance number> rsc_secip_<HANA SID>_HDB<instance number> rsc_secnc_<HANA SID>_HDB<instance number>

crm configure colocation col_saphana_secip_<HANA SID>_HDB<instance number> 4000: g_secip_<HANA SID>_HDB<instance number>:Started \
 msl_SAPHana_<HANA SID>_HDB<instance number>:Slave 

crm configure property maintenance-mode=false

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

sudo crm_mon -r

# Online: [ hn1-db-0 hn1-db-1 ]
#
# Full list of resources:
#
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
# Resource Group: g_secip_HN1_HDB03:
#     rsc_secip_HN1_HDB03       (ocf::heartbeat:IPaddr2):        Started hn1-db-1
#     rsc_secnc_HN1_HDB03       (ocf::heartbeat:azure-lb):       Started hn1-db-1

Nella sezione successiva viene descritto il set tipico di test di failover da eseguire.

Considerazioni quando si testa un cluster HANA configurato con un database secondario abilitato per la lettura:

Quando si esegue la migrazione della SAPHana_<HANA SID>_HDB<instance number> risorsa cluster a hn1-db-1, il secondo indirizzo IP virtuale passa a hn1-db-0. Se è stata configurata AUTOMATED_REGISTER="false" e la replica di sistema HANA non viene registrata automaticamente, il secondo indirizzo IP virtuale viene eseguito perché hn1-db-0 il server è disponibile e i servizi del cluster sono online.
Quando si verifica un arresto anomalo del server, le seconde risorse IP virtuali (rsc_secip_<HANA SID>_HDB<instance number>) e la risorsa porta del servizio di bilanciamento del carico di Azure (rsc_secnc_<HANA SID>_HDB<instance number>) vengono eseguite nel server primario insieme alle risorse IP virtuali primarie. Mentre il server secondario è inattivo, le applicazioni connesse a un 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 mentre il server secondario non è disponibile.
Quando il server secondario è disponibile e i servizi del cluster sono online, la seconda risorsa ip virtuale e porta passa automaticamente al server secondario, anche se la replica di sistema HANA potrebbe non essere registrata come secondaria. Assicurarsi di registrare il database HANA secondario come abilitato per la lettura prima di avviare i servizi cluster in tale server. È possibile configurare la risorsa cluster dell'istanza di HANA per registrare automaticamente il database secondario impostando il parametro AUTOMATED_REGISTER="true".
Durante il failover e il fallback, le connessioni esistenti per le applicazioni, che quindi usano il secondo IP virtuale per connettersi al database HANA, potrebbero essere interrotte.

Testare la configurazione del cluster

Questa sezione descrive come testare la configurazione. Ogni test presuppone che sia stato eseguito l'accesso come radice e che il master SAP HANA sia in esecuzione nella hn1-db-0 macchina virtuale.

Test della migrazione

Prima di avviare il test, assicurarsi che Pacemaker non abbia alcuna azione non riuscita (esecuzione crm_mon -r), che non siano presenti vincoli di posizione imprevisti (ad esempio, a sinistra di un test di migrazione) e che HANA sia in stato di sincronizzazione, ad esempio eseguendo SAPHanaSR-showAttr.

hn1-db-0:~ # SAPHanaSR-showAttr
Sites    srHook
----------------
SITE2    SOK
Global cib-time
--------------------------------
global Mon Aug 13 11:26:04 2018
Hosts    clone_state lpa_hn1_lpt node_state op_mode   remoteHost    roles                            score site  srmode sync_state version                vhost
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    1534159564  online     logreplay nws-hana-vm-1 4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.030.00.1522209842 nws-hana-vm-0
hn1-db-1 DEMOTED     30          online     logreplay nws-hana-vm-0 4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.030.00.1522209842 nws-hana-vm-1

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

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

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 sarà simile all'esempio crm_mon -r seguente:

Online: [ hn1-db-0 hn1-db-1 ]

Full list of resources:
stonith-sbd     (stonith:external/sbd): Started hn1-db-1
 Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
     Started: [ hn1-db-0 hn1-db-1 ]
 Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
     Masters: [ hn1-db-1 ]
     Stopped: [ hn1-db-0 ]
 Resource Group: g_ip_HN1_HDB03
     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
Failed Actions:
* rsc_SAPHana_HN1_HDB03_start_0 on hn1-db-0 'not running' (7): call=84, status=complete, exitreason='none',
    last-rc-change='Mon Aug 13 11:31:37 2018', queued=0ms, exec=2095ms

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 comando:

su - <hana sid>adm

# Stop the HANA instance, just in case it is running
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> sapcontrol -nr <instance number> -function StopWait 600 10
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

La migrazione crea vincoli di posizione che devono essere eliminati di nuovo:

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

È anche necessario eseguire la pulizia dello stato della risorsa nodo secondario:

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

Monitorare lo stato della risorsa HANA usando crm_mon -r. Quando HANA viene avviato in hn1-db-0, l'output è simile all'esempio seguente:

Online: [ hn1-db-0 hn1-db-1 ]

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

Blocco delle comunicazioni di rete

Stato delle risorse prima dell'avvio del test:

Online: [ hn1-db-0 hn1-db-1 ]

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

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 tenteranno di steccato l'uno contemporaneamente, causando una gara di isolamento.

Quando si configura un dispositivo di isolamento, è consigliabile configurare pcmk_delay_max la proprietà. Pertanto, in caso di scenario split-brain, il cluster introduce un ritardo casuale fino al pcmk_delay_max valore, all'azione di isolamento in ogni nodo. Il nodo con il ritardo più breve verrà selezionato per l'isolamento.

Inoltre, per assicurarsi che il nodo che esegue il master HANA ha la priorità e vince la gara di recinzione in uno scenario split brain, è consigliabile impostare priority-fencing-delay la proprietà nella configurazione del cluster. Abilitando la proprietà priority-fencing-delay, il cluster può introdurre un ritardo aggiuntivo 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'isolamento SBD

È possibile testare la configurazione di SBD uccidendo il processo di inquisitore:

hn1-db-0:~ # ps aux | grep sbd
root       1912  0.0  0.0  85420 11740 ?        SL   12:25   0:00 sbd: inquisitor
root       1929  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014056f268462316e4681b704a9f73 - slot: 0 - uuid: 7b862dba-e7f7-4800-92ed-f76a4e3978c8
root       1930  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-360014059bc9ea4e4bac4b18808299aaf - slot: 0 - uuid: 5813ee04-b75c-482e-805e-3b1e22ba16cd
root       1931  0.0  0.0  85456 11776 ?        SL   12:25   0:00 sbd: watcher: /dev/disk/by-id/scsi-36001405b8dddd44eb3647908def6621c - slot: 0 - uuid: 986ed8f8-947d-4396-8aec-b933b75e904c
root       1932  0.0  0.0  90524 16656 ?        SL   12:25   0:00 sbd: watcher: Pacemaker
root       1933  0.0  0.0 102708 28260 ?        SL   12:25   0:00 sbd: watcher: Cluster
root      13877  0.0  0.0   9292  1572 pts/0    S+   12:27   0:00 grep sbd

hn1-db-0:~ # kill -9 1912

Il <HANA SID>-db-<database 1> nodo del cluster viene riavviato. Il servizio Pacemaker potrebbe non essere riavviato. Assicurarsi di ricominciare.

Testare un failover manuale

È possibile testare un failover manuale arrestando il servizio Pacemaker nel hn1-db-0 nodo:

service pacemaker stop

Dopo il failover, è possibile avviare nuovamente il servizio. 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:

service pacemaker start
su - <hana sid>adm

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

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

Test SUSE

Importante

Assicurarsi che il sistema operativo selezionato sia certificato SAP per SAP HANA nei tipi di vm specifici che si prevede di usare. È 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 che si prevede di usare per ottenere l'elenco completo delle versioni del sistema operativo supportate da SAP HANA per quel tipo di macchina virtuale.

Eseguire tutti i test case elencati nella guida per scenari ottimizzati per le prestazioni di SAP HANA SR o nella guida dello scenario con ottimizzazione dei costi di SAP HANA SR, a seconda dello scenario in uso. È possibile trovare le guide elencate in SLES per le procedure consigliate per SAP.

I test seguenti sono una copia delle descrizioni dei test della guida di SUSE Linux Enterprise Server for SAP Applications 12 SP1 per lo scenario di ottimizzazione delle prestazioni della replica di sistema SAP HANA. Per una versione aggiornata, leggere anche la guida stessa. Assicurarsi sempre che HANA sia sincronizzato prima di avviare il test e assicurarsi che la configurazione di Pacemaker sia corretta.

Nelle descrizioni dei test seguenti si presuppone PREFER_SITE_TAKEOVER="true" che e AUTOMATED_REGISTER="false".

Nota

I test seguenti sono progettati per essere eseguiti in sequenza. Ogni test dipende dallo stato di uscita del test precedente.

Test 1: Arrestare il database primario nel nodo 1.

Stato della risorsa prima di avviare il test:

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

Eseguire i comandi seguenti come <hana sid>adm nel hn1-db-0 nodo:

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

Pacemaker rileva l'istanza di HANA arrestata e esegue il failover nell'altro nodo. Al termine del failover, l'istanza di HANA nel hn1-db-0 nodo viene arrestata perché Pacemaker non registra automaticamente il nodo come secondario HANA.

Eseguire i comandi seguenti per registrare il hn1-db-0 nodo come secondario e pulire la risorsa non riuscita:

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

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

Stato della risorsa dopo il test:

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

Test 2: Arrestare il database primario nel nodo 2.

Stato della risorsa prima di avviare il test:

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

Eseguire i comandi seguenti come <hana sid>adm nel hn1-db-1 nodo:

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

Pacemaker rileva l'istanza di HANA arrestata e esegue il failover nell'altro nodo. Al termine del failover, l'istanza di HANA nel hn1-db-1 nodo viene arrestata perché Pacemaker non registra automaticamente il nodo come secondario HANA.

Eseguire i comandi seguenti per registrare il hn1-db-1 nodo come secondario e pulire la risorsa non riuscita:

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

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

Stato della risorsa dopo il test:

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

Test 3: Arrestare in modo anomalo il database primario nel nodo 1.

Stato della risorsa prima di avviare il test:

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

Eseguire i comandi seguenti come <hana sid>adm nel hn1-db-0 nodo:

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

Pacemaker rileva l'istanza hana terminata e ne esegue il failover nell'altro nodo. Al termine del failover, l'istanza di HANA nel hn1-db-0 nodo viene arrestata perché Pacemaker non registra automaticamente il nodo come secondario HANA.

Eseguire i comandi seguenti per registrare il hn1-db-0 nodo come secondario e pulire la risorsa non riuscita:

hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

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

Stato della risorsa dopo il test:

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

Test 4: Arrestare in modo anomalo il database primario nel nodo 2.

Stato della risorsa prima di avviare il test:

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

Eseguire i comandi seguenti come <hana sid>adm nel hn1-db-1 nodo:

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

Pacemaker rileva l'istanza hana terminata e ne esegue il failover nell'altro nodo. Al termine del failover, l'istanza di HANA nel hn1-db-1 nodo viene arrestata perché Pacemaker non registra automaticamente il nodo come secondario HANA.

Eseguire i comandi seguenti per registrare il hn1-db-1 nodo come secondario e pulire la risorsa non riuscita.

hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

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

Stato della risorsa dopo il test:

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

Test 5: Arrestare in modo anomalo il nodo del sito primario (nodo 1).

Stato della risorsa prima di avviare il test:

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

Eseguire i comandi seguenti come radice nel hn1-db-0 nodo:

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

Pacemaker rileva il nodo del cluster terminato e delimita il nodo. Quando il nodo è delimitato, Pacemaker attiva un acquisizione dell'istanza di HANA. Quando il nodo delimitato viene riavviato, Pacemaker non viene avviato automaticamente.

Eseguire i comandi seguenti per avviare Pacemaker, pulire i messaggi SBD per il hn1-db-0 nodo, registrare il hn1-db-0 nodo come secondario e pulire la risorsa non riuscita:

# run as root
# list the SBD device(s)
hn1-db-0:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-0:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-0 clear

hn1-db-0:~ # systemctl start pacemaker

# run as <hana sid>adm
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

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

Stato della risorsa dopo il test:

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

Test 6: Arrestare in modo anomalo il nodo del sito secondario (nodo 2).

Stato della risorsa prima di avviare il test:

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

Eseguire i comandi seguenti come radice nel hn1-db-1 nodo:

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

Eseguire i comandi seguenti per avviare Pacemaker, pulire i messaggi SBD per il hn1-db-1 nodo, registrare il hn1-db-1 nodo come secondario e pulire la risorsa non riuscita:

# run as root
# list the SBD device(s)
hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear

hn1-db-1:~ # systemctl start pacemaker

# run as <hana sid>adm
hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=<instance number> --replicationMode=sync --name=<site 2>

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

Stato della risorsa dopo il test:

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

Test 7: Arrestare il database secondario nel nodo 2.

Stato della risorsa prima di avviare il test:

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

Eseguire i comandi seguenti come <hana sid>adm nel hn1-db-1 nodo:

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

Pacemaker rileva l'istanza di HANA arrestata e contrassegna la risorsa come non riuscita nel hn1-db-1 nodo. Pacemaker riavvia automaticamente l'istanza di HANA.

Eseguire il comando seguente per pulire lo stato di errore:

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

Stato della risorsa dopo il test:

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

Test 8: arresto anomalo del database secondario nel nodo 2.

Stato della risorsa prima di avviare il test:

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

Eseguire i comandi seguenti come <hana sid>adm nel hn1-db-1 nodo:

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

Pacemaker rileva l'istanza hana terminata e contrassegna la risorsa come non riuscita nel hn1-db-1 nodo. Eseguire il comando seguente per pulire lo stato di errore. Pacemaker riavvia quindi automaticamente l'istanza di HANA.

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

Stato della risorsa dopo il test:

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

Test 9: Arrestare in modo anomalo il nodo del sito secondario (nodo 2) che esegue il database HANA secondario.

Stato della risorsa prima di avviare il test:

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

Eseguire i comandi seguenti come radice nel hn1-db-1 nodo:

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

Pacemaker rileva il nodo del cluster terminato e delimitato il nodo. Quando il nodo delimitato viene riavviato, Pacemaker non viene avviato automaticamente.

Eseguire i comandi seguenti per avviare Pacemaker, pulire i messaggi SBD per il hn1-db-1 nodo e pulire la risorsa non riuscita:

# run as root
# list the SBD device(s)
hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
# SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"

hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear

hn1-db-1:~ # systemctl start pacemaker  

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

Stato della risorsa dopo il test:

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

Test 10: Arresto anomalo del server di indicizzazione del database primario

Questo test è rilevante solo quando è stato configurato l'hook susChkSrv come descritto in Implementare hook HANA SAPHanaSR e susChkSrv.

Stato della risorsa prima di avviare il test:

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

Eseguire i comandi seguenti come radice nel hn1-db-0 nodo:

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

Quando il server index viene terminato, l'hook susChkSrv rileva l'evento e attiva un'azione per recinto il nodo 'hn1-db-0' e avvia un processo di acquisizione.

Eseguire i comandi seguenti per registrare hn1-db-0 il nodo come secondario e pulire la risorsa non riuscita:

# run as <hana sid>adm
hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=<instance number> --replicationMode=sync --name=<site 1>

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

Stato della risorsa dopo il test:

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

È possibile eseguire un test case paragonabile causando l'arresto anomalo del server index nel nodo secondario. In caso di arresto anomalo del server index, l'hook susChkSrv riconoscerà l'occorrenza e avvierà un'azione per l'isolamento del nodo secondario.

Disponibilità elevata per SAP HANA in macchine virtuali di Azure su SU edizione Standard Linux Enterprise Server

Pianificare la disponibilità elevata di SAP HANA

Preparare l'infrastruttura

Distribuire macchine virtuali Linux manualmente tramite il portale di Azure

Configurare il servizio di bilanciamento del carico di Azure

Creare un cluster Pacemaker

Installare SAP HANA

Configurare la replica di sistema SAP HANA 2.0

Configurare la replica di sistema SAP HANA 1.0

Implementare hook HANA SAPHanaSR e susChkSrv

Creare le risorse cluster SAP HANA

Configurare la replica di sistema attiva/abilitata per la lettura haNA in un cluster Pacemaker

Configurare il servizio di bilanciamento del carico per la replica di sistema attiva/abilitata per la lettura

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

Aggiungere una risorsa indirizzo IP virtuale secondario

Testare la configurazione del cluster

Test della migrazione

Blocco delle comunicazioni di rete

Testare l'isolamento SBD

Testare un failover manuale

Test SUSE

Passaggi successivi

Risorse aggiuntive