Disponibilità elevata per il sistema sap HANA con scalabilità orizzontale con HSR su SU edizione Standard Linux Enterprise Server

Articolo
01/16/2024

Questo articolo descrive come distribuire un sistema SAP HANA a disponibilità elevata in una configurazione con scalabilità orizzontale con la replica di sistema HANA (HSR) e Pacemaker in Azure SU edizione Standard macchine virtuali Linux Enterprise Server (VM). I file system condivisi nell'architettura presentata sono montati in NFS e vengono forniti da Azure NetApp Files o dalla condivisione NFS in File di Azure.

Nelle configurazioni di esempio, i comandi di installazione e così via, l'istanza di HANA è 03 e l'ID di sistema HANA è HN1.

Prima di iniziare, fare riferimento alle note e ai documenti SAP seguenti:

Documentazione di Azure NetApp Files
Documentazione su File di Azure
La nota SAP 1928533 include:
- Elenco delle dimensioni delle macchine virtuali di Azure supportate per la distribuzione del software SAP
- Importanti informazioni sulla capacità per le dimensioni delle VM di Azure
- Software SAP e combinazioni di sistemi operativi e database supportati
- Versione del kernel SAP necessaria per Windows e Linux in Microsoft Azure
Nota SAP 2015553: elenca i prerequisiti per le distribuzioni di software SAP supportate da SAP in Azure
Nota SAP 2205917: contiene le impostazioni consigliate del sistema operativo per SU edizione Standard Linux Enterprise Server per le applicazioni SAP
Nota SAP 1944799: contiene le linee guida SAP per SU edizione Standard Linux Enterprise Server per le applicazioni SAP
Nota SAP 2178632: contiene informazioni dettagliate su tutte le metriche di monitoraggio segnalate per SAP in Azure
Nota SAP 2191498: contiene la versione richiesta dell'agente host SAP per Linux in Azure
Nota SAP 2243692: contiene informazioni sulle licenze SAP in Linux in Azure
Nota SAP 1984787: contiene informazioni generali su SU edizione Standard Linux Enterprise Server 12
Nota SAP 1999351: contiene informazioni aggiuntive sulla risoluzione dei problemi per l'estensione di monitoraggio avanzato di Azure per SAP
Nota SAP 1900823: contiene informazioni sui requisiti di archiviazione di SAP HANA
Wiki della community SAP: contiene tutte le note SAP necessarie per Linux
Pianificazione e implementazione di Macchine virtuali di Azure per SAP in Linux
Distribuzione di Macchine virtuali di Azure per SAP in Linux
Distribuzione DBMS di Macchine virtuali di Azure per SAP in Linux
SU edizione Standard SAP HA Best Practice Guides: contiene tutte le informazioni necessarie per configurare la disponibilità elevata netWeaver e la replica di sistema SAP HANA in locale (da usare come baseline generale; forniscono informazioni molto più dettagliate)
Note sulla versione di SU edizione Standard High Availability Extension 12 SP5
Gestione della condivisione NFS non riuscita in SU edizione Standard cluster a disponibilità elevata per la replica di sistema HANA
Volumi NFS v4.1 in Azure NetApp Files per SAP HANA

Panoramica

Un metodo per ottenere la disponibilità elevata di HANA per le installazioni con scalabilità orizzontale haNA consiste nel configurare la replica di sistema HANA e proteggere la soluzione con il cluster Pacemaker per consentire il failover automatico. Quando un nodo attivo ha esito negativo, il cluster esegue il failover delle risorse HANA nell'altro sito.
La configurazione presentata mostra tre nodi HANA in ogni sito, oltre a un nodo di maggioranza per evitare scenari split brain. Le istruzioni possono essere adattate per includere più macchine virtuali come nodi del database HANA.

Il file system /hana/shared condiviso HANA nell'architettura presentata può essere fornito da Azure NetApp Files o dalla condivisione NFS in File di Azure. Il file system condiviso HANA è montato su ogni nodo HANA nello stesso sito di replica di sistema HANA. I file system /hana/data e /hana/log sono file system locali e non vengono condivisi tra i nodi del database HANA. SAP HANA verrà installato in modalità non condivisa.

Per le configurazioni di archiviazione sap HANA consigliate, vedere Configurazioni di archiviazione delle macchine virtuali di Azure SAP HANA.

Importante

Se si distribuiscono tutti i file system HANA in Azure NetApp Files, per i sistemi di produzione, dove le prestazioni sono fondamentali, è consigliabile valutare e valutare l'uso del gruppo di volumi di applicazioni di Azure NetApp Files per SAP HANA.

Avviso

La distribuzione /hana/data e /hana/log in NFS in File di Azure non è supportata.

Nel diagramma precedente tre subnet sono rappresentate all'interno di una rete virtuale di Azure, seguendo le raccomandazioni sulla rete SAP HANA:

per la comunicazione client - client 10.23.0.0/24
per la comunicazione interna tra nodi HANA - inter 10.23.1.128/26
per la replica di sistema HANA - hsr 10.23.1.192/26

Come /hana/data e /hana/log vengono distribuiti nei dischi locali, non è necessario distribuire subnet separate e schede di rete virtuale separate per la comunicazione con l'archiviazione.

Se si usa Azure NetApp Files, i volumi NFS per /hana/sharedvengono distribuiti in una subnet separata, delegata ad Azure NetApp Files: anf 10.23.1.0/26.

Preparare l'infrastruttura

Nelle istruzioni seguenti si presuppone che il gruppo di risorse sia già stato creato, la rete virtuale di Azure con tre subnet di rete di Azure: cliente interhsr.

Distribuire macchine virtuali Linux tramite il portale di Azure

Distribuire le macchine virtuali di Azure.

Per la configurazione presentata in questo documento, distribuire sette macchine virtuali:
- tre macchine virtuali da usare come nodi del database HANA per il sito di replica HANA 1: hana-s1-db1, hana-s1-db2 e hana-s1-db3
- tre macchine virtuali da usare come nodi di database HANA per il sito di replica HANA 2: hana-s2-db1, hana-s2-db2 e hana-s2-db3
- una piccola macchina virtuale da usare come maggior produttore: hana-s-mm
Le macchine virtuali distribuite come nodi SAP DB HANA devono essere certificate da SAP per HANA come pubblicato nella directory Hardware di SAP HANA. Quando si distribuiscono i nodi del database HANA, assicurarsi che sia selezionata l'opzione Rete accelerata.

Per il nodo di maggioranza dei creatori, è possibile distribuire una macchina virtuale di piccole dimensioni, perché questa macchina virtuale non esegue alcuna delle risorse di SAP HANA. La macchina virtuale del produttore di maggioranza viene usata nella configurazione del cluster per ottenere un numero dispari di nodi del cluster in uno scenario split-brain. In questo esempio la macchina virtuale di maggioranza necessita solo di un'interfaccia di rete virtuale nella client subnet.

Distribuire dischi gestiti locali per /hana/data e /hana/log. La configurazione di archiviazione minima consigliata per /hana/data ed /hana/log è descritta in Configurazioni di archiviazione delle macchine virtuali di Azure SAP HANA.

Distribuire l'interfaccia di rete primaria per ogni macchina virtuale nella subnet della client rete virtuale.
Quando la macchina virtuale viene distribuita tramite portale di Azure, il nome dell'interfaccia di rete viene generato automaticamente. In queste istruzioni per semplicità si farà riferimento alle interfacce di rete primarie generate automaticamente, collegate alla subnet della client rete virtuale di Azure come hana-s1-db1-client, hana-s1-db2-client, hana-s1-db3-client e così via.
Importante
- Assicurarsi che il sistema operativo selezionato sia certificato SAP per SAP HANA nei tipi di macchina virtuale specifici in uso. Per un elenco dei tipi di macchina virtuale certificati SAP HANA e delle versioni del sistema operativo per questi tipi, passare al sito delle piattaforme IaaS certificate di SAP HANA. Fare clic sui dettagli del tipo di macchina virtuale elencato per ottenere l'elenco completo delle versioni del sistema operativo supportate da SAP HANA per tale tipo.
- Se si sceglie di eseguire la distribuzione /hana/shared in NFS in File di Azure, è consigliabile eseguire la distribuzione in SLES 15 SP2 e versioni successive.
Creare sei interfacce di rete, una per ogni macchina virtuale del database HANA, nella inter subnet di rete virtuale (in questo esempio, hana-s1-db1-inter, hana-s1-db2-inter, hana-s1-db3-inter, hana-s2-db1-inter, hana-s2-db2-inter e hana-s2-db3-inter).
Creare sei interfacce di rete, una per ogni macchina virtuale del database HANA, nella hsr subnet di rete virtuale (in questo esempio, hana-s1-db1-hsr, hana-s1-db2-hsr, hana-s1-db3-hsr, hana-s2-db1-hsr, hana-s2-db2-hsr e hana-s2-db3-hsr).
Collegare le interfacce di rete virtuale appena create alle macchine virtuali corrispondenti:
1. Passare alla macchina virtuale nel portale di Azure.
2. Nel riquadro sinistro selezionare Macchine virtuali. Filtrare in base al nome della macchina virtuale (ad esempio, hana-s1-db1) e quindi selezionare la macchina virtuale.
3. Nel riquadro Panoramica selezionare Arresta per deallocare la macchina virtuale.
4. Selezionare Rete e quindi collegare l'interfaccia di rete. Nell'elenco a discesa Collega interfaccia di rete selezionare le interfacce di rete già create per le inter subnet e hsr .
5. Seleziona Salva.
6. Ripetere i passaggi b-e per le macchine virtuali rimanenti (in questo esempio, hana-s1-db2, hana-s1-db3, hana-s2-db1, hana-s2-db2 e hana-s2-db3).
7. Lasciare le macchine virtuali in stato di arresto per il momento. Successivamente, si abiliterà la rete accelerata per tutte le interfacce di rete appena collegate.

Abilitare la rete accelerata per le interfacce di rete aggiuntive per le inter subnet e hsr seguendo questa procedura:

Aprire Azure Cloud Shell nel portale di Azure.

Eseguire i comandi seguenti per abilitare la rete accelerata per le interfacce di rete aggiuntive collegate alle inter subnet e hsr .

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-inter --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-inter --accelerated-networking true

az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-hsr --accelerated-networking true
az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-hsr --accelerated-networking true

Avviare le macchine virtuali del database HANA

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.

Nota

Per l'aumento del numero di istanze di HANA, selezionare la scheda di interfaccia di rete per la client subnet quando si aggiungono le macchine virtuali nel pool back-end.
Il set completo di comandi nell'interfaccia della riga di comando di Azure e PowerShell aggiunge le macchine virtuali con scheda di interfaccia di rete primaria nel pool back-end.

Seguire la guida alla creazione del 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, prendere in considerazione i punti seguenti.

Configurazione IP front-end: creare un indirizzo IP front-end. Selezionare la stessa rete virtuale e la stessa subnet delle macchine virtuali del database.
Pool back-end: creare un pool back-end e aggiungere macchine virtuali del 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 ip front-end
- Pool back-end: selezionare il pool back-end
- Controllare "Porte a disponibilità elevata"
- Protocollo: TCP
- Probe di integrità: creare un probe di integrità con i dettagli seguenti
  - Protocollo: TCP
  - Porta: [ad esempio: 625<instance-no.>]
  - Intervallo: 5
  - Soglia probe: 2
- Timeout di inattività (minuti): 30
- Selezionare "Enable Floating IP" (Abilita IP mobile)

Nota

Il numero della proprietà di configurazione del probe di integritàOfProbes, altrimenti noto come "Soglia non integra" nel portale, non viene rispettato. Per controllare il numero di probe consecutivi riusciti o non riusciti, impostare la proprietà "probeThreshold" su 2. Attualmente non è possibile impostare questa proprietà usando portale di Azure, quindi usare l'interfaccia della riga di comando di Azure o il comando di PowerShell .

Il set completo di codici dell'interfaccia della riga di comando di Azure visualizza la configurazione del servizio di bilanciamento del carico, che include due macchine virtuali nel pool back-end. A seconda del numero di macchine virtuali nella scalabilità orizzontale di HANA, è possibile aggiungere altre macchine virtuali nel pool back-end.

# 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

Il set completo di codice di PowerShell visualizza la configurazione del servizio di bilanciamento del carico, che include due macchine virtuali nel pool back-end. A seconda del numero di macchine virtuali nella scalabilità orizzontale di HANA, è possibile aggiungere altre macchine virtuali nel pool back-end.

# 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

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 informazioni dettagliate, vedere Limitazioni del servizio di bilanciamento del carico di Azure. Se è necessario un indirizzo IP aggiuntivo 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 del Load Balancer interno standard di Azure (nessun indirizzo IP pubblico), non vi sarà connettività Internet in uscita, a meno che non venga eseguita una configurazione aggiuntiva per consentire il routing a endpoint pubblici. Per informazioni dettagliate su come ottenere la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali usando Load Balancer Standard di Azure negli scenari a disponibilità elevata SAP.

Importante

Non abilitare i timestamp TCP nelle macchine virtuali di Azure che si trovano dietro Azure Load Balancer. Se si abilitano i timestamp TCP, i probe di integrità avranno esito negativo. Impostare il parametro net.ipv4.tcp_timestamps su 0. Per informazioni dettagliate, vedere Probe di integrità di Load Balancer e 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?.

Distribuire NFS

Sono disponibili due opzioni per la distribuzione di NFS nativo di Azure per /hana/shared. È possibile distribuire il volume NFS in Azure NetApp Files o nella condivisione NFS in File di Azure. I file di Azure supportano il protocollo NFSv4.1, NFS in Azure NetApp Files supporta sia NFSv4.1 che NFSv3.

Le sezioni successive descrivono i passaggi per distribuire NFS: è necessario selezionare solo una delle opzioni.

Suggerimento

Si è scelto di eseguire la distribuzione /hana/shared nella condivisione NFS in File di Azure o nel volume NFS in Azure NetApp Files.

Distribuire l'infrastruttura di Azure NetApp Files

Distribuire volumi ANF per il /hana/shared file system. È necessario un volume separato /hana/shared per ogni sito di replica di sistema HANA. Per altre informazioni, vedere Configurare l'infrastruttura di Azure NetApp Files.

In questo esempio sono stati usati i volumi di Azure NetApp Files seguenti:

volume HN1-shared-s1 (nfs://10.23.1.7/ HN1-shared-s1)
volume HN1-shared-s2 (nfs://10.23.1.7/ HN1-shared-s2)

Distribuire NFS nell'infrastruttura File di Azure

Distribuire File di Azure condivisioni NFS per il /hana/shared file system. È necessaria una condivisione NFS File di Azure separata /hana/shared per ogni sito di replica di sistema HANA. Per altre informazioni, vedere Come creare una condivisione NFS.

In questo esempio sono state usate le File di Azure condivisioni NFS seguenti:

share hn1-shared-s1 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1)
share hn1-shared-s2 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2)

Configurazione e preparazione del sistema operativo

Le istruzioni nelle sezioni successive sono precedute da una delle abbreviazioni seguenti:

[A]: applicabile a tutti i nodi, incluso il produttore di maggioranza
[AH]: applicabile a tutti i nodi del database HANA
[M]: applicabile solo al nodo di maggioranza
[AH1]: applicabile a tutti i nodi del database HANA in SITE 1
[AH2]: applicabile a tutti i nodi del database HANA in SITE 2
[1]: applicabile solo al nodo 1 del database HANA, SITE 1
[2]: applicabile solo al nodo 1 del database HANA, SITE 2

Configurare e preparare il sistema operativo seguendo questa procedura:

[A] Gestire i file host nelle macchine virtuali. Includere voci per tutte le subnet. Per questo esempio sono state aggiunte /etc/hosts le voci seguenti.

# Client subnet
10.23.0.19      hana-s1-db1
10.23.0.20      hana-s1-db2
10.23.0.21      hana-s1-db3
10.23.0.22      hana-s2-db1
10.23.0.23      hana-s2-db2
10.23.0.24      hana-s2-db3
10.23.0.25      hana-s-mm    

# Internode subnet
10.23.1.132     hana-s1-db1-inter
10.23.1.133     hana-s1-db2-inter
10.23.1.134     hana-s1-db3-inter
10.23.1.135     hana-s2-db1-inter
10.23.1.136     hana-s2-db2-inter
10.23.1.137     hana-s2-db3-inter

# HSR subnet
10.23.1.196     hana-s1-db1-hsr
10.23.1.197     hana-s1-db2-hsr
10.23.1.198     hana-s1-db3-hsr
10.23.1.199     hana-s2-db1-hsr
10.23.1.200     hana-s2-db2-hsr
10.23.1.201     hana-s2-db3-hsr

[A] Creare il file di configurazione /etc/sysctl.d/ms-az.conf con le impostazioni di configurazione di Microsoft per Azure.
```
vi /etc/sysctl.d/ms-az.conf

# Add the following entries in the configuration file
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.tcp_max_syn_backlog = 16348
net.ipv4.conf.all.rp_filter = 0
sunrpc.tcp_slot_table_entries = 128
vm.swappiness=10
```
Suggerimento

Evitare di impostare net.ipv4.ip_local_port_range e net.ipv4.ip_local_reserved_ports in modo esplicito nei file di configurazione sysctl per consentire all'agente host SAP di gestire gli intervalli di porte. Per altre informazioni, vedere la nota SAP 2382421.
[A] SU edizione Standard offre agenti di risorse speciali per SAP HANA e per impostazione predefinita vengono installati gli agenti per sap HANA. Disinstallare i pacchetti per aumentare le prestazioni, se installati e installare i pacchetti per lo scenario con scalabilità orizzontale di SAP HANA. Il passaggio deve essere eseguito in tutte le macchine virtuali del cluster, incluso il produttore di maggioranza.

Nota

È necessario installare SAPHanaSR-ScaleOut versione 0.181 o successiva.
```
# Uninstall scale-up packages and patterns
sudo zypper remove patterns-sap-hana
sudo zypper remove SAPHanaSR SAPHanaSR-doc yast2-sap-ha

# Install the scale-out packages and patterns
sudo zypper in SAPHanaSR-ScaleOut SAPHanaSR-ScaleOut-doc 
sudo zypper in -t pattern ha_sles
```
[AH] Preparare le macchine virtuali: applicare le impostazioni consigliate per ogni nota SAP 2205917 per SU edizione Standard Linux Enterprise Server for SAP Applications.

Preparare i file system

Si è scelto di distribuire le directory condivise SAP nella condivisione NFS in File di Azure o nel volume NFS in Azure NetApp Files.

Montare i file system condivisi (NFS di Azure NetApp Files)

In questo esempio i file system HANA condivisi vengono distribuiti in Azure NetApp Files e montati su NFSv4.1. Seguire i passaggi descritti in questa sezione, solo se si usa NFS in Azure NetApp Files.

[AH] Preparare il sistema operativo per l'esecuzione di SAP HANA in NetApp Systems con NFS, come descritto nella nota SAP 3024346 - Linux Kernel Impostazioni per NetApp NFS. Creare il file di configurazione /etc/sysctl.d/91-NetApp-HANA.conf per le impostazioni di configurazione di NetApp.

vi /etc/sysctl.d/91-NetApp-HANA.conf

# Add the following entries in the configuration file
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1

[AH] Modificare le impostazioni sunrpc, come consigliato nella nota SAP 3024346 - Linux Kernel Impostazioni per NetApp NFS.
```
vi /etc/modprobe.d/sunrpc.conf

# Insert the following line
options sunrpc tcp_max_slot_table_entries=128
```
[AH] Creare punti di montaggio per i volumi di database HANA.
```
mkdir -p /hana/shared
```
[AH] Verificare l'impostazione del dominio NFS. Assicurarsi che il dominio sia configurato come dominio predefinito di Azure NetApp Files, defaultv4iddomain.com ovvero e che il mapping sia impostato su nessuno.
Questo passaggio è necessario solo se si usa Azure NetAppFiles NFSv4.1.

Importante

Verificare di impostare il dominio NFS in /etc/idmapd.conf sulla macchina virtuale in modo che corrisponda alla configurazione del dominio predefinito in Azure NetApp Files: defaultv4iddomain.com. In caso di mancata corrispondenza tra la configurazione del dominio nel client NFS (ovvero la macchina virtuale) e nel server NFS, ad esempio la configurazione di Azure NetApp, le autorizzazioni per i file nei volumi Azure NetApp montati nelle VM verranno visualizzate come nobody.
```
sudo cat /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
```

[AH] Verificare nfs4_disable_idmapping. Deve essere impostato su Y. Per creare la struttura di directory in cui nfs4_disable_idmapping si trova, eseguire il comando mount. Non sarà possibile creare manualmente la directory in/sys/modules, perché l'accesso è riservato per il kernel/driver.
Questo passaggio è necessario solo se si usa Azure NetAppFiles NFSv4.1.

# Check nfs4_disable_idmapping 
cat /sys/module/nfs/parameters/nfs4_disable_idmapping
# If you need to set nfs4_disable_idmapping to Y
mkdir /mnt/tmp
mount 10.23.1.7:/HN1-share-s1 /mnt/tmp
umount  /mnt/tmp
echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
# Make the configuration permanent
echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

[AH1] Montare i volumi condivisi di Azure NetApp Files nelle macchine virtuali del database HANA SITE1.

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s1 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] Montare i volumi condivisi di Azure NetApp Files nelle macchine virtuali del database HANA SITE2.

sudo vi /etc/fstab
# Add the following entry
10.23.1.7:/HN1-shared-s2 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
# Mount the volume
sudo mount -a

[AH] Verificare che i file system corrispondenti /hana/shared/ siano montati in tutte le macchine virtuali del database HANA con la versione del protocollo NFS NFSv4.1.

sudo nfsstat -m
# Verify that flag vers is set to 4.1 
# Example from SITE 1, hana-s1-db1
/hana/shared from 10.23.1.7:/HN1-shared-s1
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.1.7
# Example from SITE 2, hana-s2-db1
/hana/shared from 10.23.1.7:/HN1-shared-s2
 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.1.7

Montare i file system condivisi (File di Azure NFS)

In questo esempio i file system HANA condivisi vengono distribuiti in NFS in File di Azure. Seguire la procedura descritta in questa sezione solo se si usa NFS in File di Azure.

[AH] Creare punti di montaggio per i volumi di database HANA.
```
mkdir -p /hana/shared
```

[AH1] Montare i volumi condivisi di Azure NetApp Files nelle macchine virtuali del database HANA SITE1.

sudo vi /etc/fstab
# Add the following entry
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount all volumes
sudo mount -a

[AH2] Montare i volumi condivisi di Azure NetApp Files nelle macchine virtuali del database HANA SITE2.

sudo vi /etc/fstab
# Add the following entries
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
# Mount the volume
sudo mount -a

[AH] Verificare che i file system corrispondenti /hana/shared/ siano montati in tutte le macchine virtuali del database HANA con la versione del protocollo NFS NFSv4.1.

sudo nfsstat -m
# Example from SITE 1, hana-s1-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.0.35
# Example from SITE 2, hana-s2-db1
sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.0.35

Preparare i file system locali di dati e log

Nella configurazione presentata, i file system /hana/data e /hana/log vengono distribuiti su disco gestito e sono collegati localmente a ogni macchina virtuale del database HANA. Sarà necessario eseguire la procedura per creare i volumi di dati e log locali in ogni macchina virtuale del database HANA.

Configurare il layout del disco con Gestione volumi logici (LVM). Nell'esempio seguente si presuppone che ogni macchina virtuale HANA abbia tre dischi dati collegati, usati per creare due volumi.

[AH] 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

[AH] 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

[AH] 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

[AH] Creare i volumi logici.

Quando si usa lvcreate senza l'opzione -i, viene creato un volume lineare. Si consiglia di creare un volume con striping per migliorare le prestazioni di I/O e allineare le dimensioni di striping ai valori documentati in Configurazioni di archiviazione della macchina virtuale SAP HANA. L'argomento -i deve essere il numero dei volumi fisici sottostanti e l'argomento -I è la dimensione della striscia. In questo documento vengono usati due volumi fisici per il volume di dati, quindi l'argomento dell'opzione -i è impostato su 2. Le dimensioni di striping per il volume di dati sono pari a 256 KiB. 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 o di log. Usare l'opzione -I per specificare le dimensioni di striping durante la creazione di un volume con striping.
Vedere Configurazioni di archiviazione della macchina virtuale SAP HANA per le configurazioni di archiviazione consigliate, incluse le dimensioni di striping e il numero di dischi.
```
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 mkfs.xfs /dev/vg_hana_data_HN1/hana_data
sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
```

[AH] Creare le directory di montaggio e copiare l'UUID di tutti i volumi logici:

sudo mkdir -p /hana/data/HN1
sudo mkdir -p /hana/log/HN1
# Write down the ID of /dev/vg_hana_data_HN1/hana_data and /dev/vg_hana_log_HN1/hana_log
sudo blkid

[AH] Creare fstab voci per i volumi logici e montare:

sudo vi /etc/fstab

Inserire la riga seguente nel file /etc/fstab:

/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_data_HN1-hana_data /hana/data/HN1 xfs  defaults,nofail  0  2
/dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_log_HN1-hana_log /hana/log/HN1 xfs  defaults,nofail  0  2

Montare i nuovi volumi:

sudo mount -a

Creare un cluster Pacemaker

Seguire i passaggi descritti in Setting up Pacemaker on SUSE Linux Enterprise Server in Azure (Configurazione di Pacemaker su SUSE Linux Enterprise Server in Azure) per creare un cluster Pacemaker di base per questo server HANA. Includere tutte le macchine virtuali, incluso il produttore di maggioranza nel cluster.

Importante

Non impostare su quorum expected-votes 2, perché non si tratta di un cluster a due nodi.
Assicurarsi che la proprietà concurrent-fencing del cluster sia abilitata, in modo che l'isolamento del nodo sia deserializzato.

Installazione

In questo esempio per la distribuzione di SAP HANA nella configurazione con scalabilità orizzontale con HSR in macchine virtuali di Azure è stato usato HANA 2.0 SP5.

Preparare l'installazione di HANA

[AH] Prima dell'installazione di HANA, impostare la password radice. È possibile disabilitare la password radice dopo il completamento dell'installazione. Eseguire come root comando passwd.
[1,2] Modificare le autorizzazioni per /hana/shared
```
chmod 775 /hana/shared
```
[1] Verificare che sia possibile accedere tramite SSH alle macchine virtuali del database HANA in questo sito hana-s1-db2 e hana-s1-db3, senza che venga richiesta una password. In caso contrario, scambiare chiavi SSH come descritto in Abilitare l'accesso SSH tramite chiave pubblica.
```
ssh root@hana-s1-db2
ssh root@hana-s1-db3
```
[2] Verificare che sia possibile accedere tramite SSH alle macchine virtuali del database HANA in questo sito hana-s2-db2 e hana-s2-db3, senza che venga richiesta una password.
In caso contrario, scambiare chiavi SSH.
```
ssh root@hana-s2-db2
ssh root@hana-s2-db3
```
[AH] Installare pacchetti aggiuntivi, necessari per HANA 2.0 SP4 e versioni successive. Per altre informazioni, vedere SAP Note 2593824 per la versione di SLES.
```
# In this example, using SLES12 SP5
sudo zypper install libgcc_s1 libstdc++6 libatomic1
```

Installazione di HANA nel primo nodo in ogni sito

[1] Installare SAP HANA seguendo le istruzioni riportate nella guida all'installazione e all'aggiornamento di SAP HANA 2.0. Nelle istruzioni seguenti viene illustrata l'installazione di SAP HANA nel primo nodo in SITE 1.

a. Avviare il programma hdblcm come root dalla directory del software di installazione di HANA. Usare il internal_network parametro e passare lo spazio degli indirizzi per la subnet, che viene usato per la comunicazione interna tra nodi HANA.
```
./hdblcm --internal_network=10.23.1.128/26
```
b. Al prompt immettere i valori seguenti:
- Per Scegliere un'azione: immettere 1 (per l'installazione)
- Per Componenti aggiuntivi per l'installazione: immettere 2, 3
- Per il percorso di installazione, premere INVIO (l'impostazione predefinita è /hana/shared)
- Per Local Host Name (Nome host locale): premere INVIO per accettare l'impostazione predefinita
- Per Aggiungere host al sistema?: immettere n
- Per SAP HANA System ID (ID sistema SAP HANA): immettere HN1
- Per Numero di istanza [00]: immettere 03
- Per Gruppo di lavoro host locale [impostazione predefinita]: premere INVIO per accettare l'impostazione predefinita
- Per Select System Usage /Enter index [4]: enter 4 (for custom)
- Per Posizione dei volumi di dati [/hana/data/HN1]: premere INVIO per accettare il valore predefinito
- Per Posizione dei volumi di log [/hana/log/HN1]: premere INVIO per accettare il valore predefinito
- Per Limita allocazione massima di memoria? [n]: immettere n
- Per Nome host certificato per Host hana-s1-db1 [hana-s1-db1]: premere INVIO per accettare l'impostazione predefinita
- Per SAP Host Agent User (sapadm) Password: immettere la password
- Per Confermare la password dell'utente dell'agente host SAP (sapadm): immettere la password
- Per System Amministrazione istrator (hn1adm) Password: immettere la password
- Per System Amministrazione istrator Home Directory [/usr/sap/HN1/home]: premere INVIO per accettare il valore predefinito
- Per System Amministrazione istrator Login Shell [/bin/sh]: premere INVIO per accettare l'impostazione predefinita
- Per System Amministrazione istrator User ID [1001]: premere INVIO per accettare il valore predefinito
- Per ENTER ID of User Group (sapsys) [79]: premere INVIO per accettare il valore predefinito
- Per System Database User (system) Password (password): immettere la password del sistema
- Per Conferma password utente database di sistema (sistema): immettere la password del sistema
- Per Riavvia sistema dopo il riavvio del computer? [n]: immettere n
- Per Continuare (y/n): convalidare il riepilogo e, se tutto è corretto, immettere y
[2] Ripetere il passaggio precedente per installare SAP HANA nel primo nodo in SITE 2.
[1,2] Verificare global.ini

Visualizzare global.ini e assicurarsi che sia presente la configurazione per la comunicazione interna tra nodi di SAP HANA. Verificare la sezione di comunicazione . Deve avere lo spazio indirizzi per la inter subnet e listeninterface deve essere impostato su .internal. Verificare la sezione internal_hostname_resolution . Deve avere gli indirizzi IP per le macchine virtuali HANA che appartengono alla inter subnet.
```
  sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
  # Example from SITE1 
  [communication]
  internal_network = 10.23.1.128/26
  listeninterface = .internal
  [internal_hostname_resolution]
  10.23.1.132 = hana-s1-db1
  10.23.1.133 = hana-s1-db2
  10.23.1.134 = hana-s1-db3
```
[1,2] Preparare global.ini l'installazione in un ambiente non condiviso, come descritto nella nota SAP 2080991.
```
 sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
 [persistence]
 basepath_shared = no
```

[1,2] Riavviare SAP HANA per attivare le modifiche.

 sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem
 sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem

[1,2] Verificare che l'interfaccia client usi gli indirizzi IP della subnet per la client comunicazione.
```
# Execute as hn1adm
/usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from SYS.M_HOST_INFORMATION'|grep net_publicname
# Expected result - example from SITE 2
"hana-s2-db1","net_publicname","10.23.0.22"
```
Per informazioni su come verificare la configurazione, vedere SAP Note 2183363 - Configuration of SAP HANA internal network (Nota SAP 2183363 - Configurazione della rete interna di SAP HANA).
[AH] Modificare le autorizzazioni per le directory di dati e log per evitare errori di installazione di HANA.
```
 sudo chmod o+w -R /hana/data /hana/log
```
[1] Installare i nodi HANA secondari. Le istruzioni di esempio in questo passaggio sono relative a SITE 1.

a. Avviare il programma hdblcm residente come root.
```
 cd /hana/shared/HN1/hdblcm
 ./hdblcm 
```
b. Al prompt immettere i valori seguenti:
- Per Scegliere un'azione: immettere 2 (per aggiungere host)
- Per Immettere nomi host delimitati da virgole da aggiungere: hana-s1-db2, hana-s1-db3
- Per Componenti aggiuntivi per l'installazione: immettere 2, 3
- Per Immettere il nome utente radice [root]: premere INVIO per accettare l'impostazione predefinita
- Per Select roles for host 'hana-s1-db2' [1]: 1 (for worker)
- Per Enter Host Failover Group for host 'hana-s1-db2' [default]: premere INVIO per accettare il valore predefinito
- Per Immettere Archiviazione numero di partizione per l'host 'hana-s1-db2' [<<assegna automaticamente>>]: premere INVIO per accettare l'impostazione predefinita
- Per Enter Worker Group for host 'hana-s1-db2' [default]: premere INVIO per accettare il valore predefinito
- Per Select roles for host 'hana-s1-db3' [1]: 1 (for worker)
- Per Enter Host Failover Group for host 'hana-s1-db3' [default]: premere INVIO per accettare il valore predefinito
- Per Immettere Archiviazione numero di partizione per l'host 'hana-s1-db3' [<<assegna automaticamente>>]: premere INVIO per accettare l'impostazione predefinita
- Per Enter Worker Group for host 'hana-s1-db3' [default]: premere INVIO per accettare il valore predefinito
- Per System Amministrazione istrator (hn1adm) Password: immettere la password
- Per Immettere la password dell'utente dell'agente host SAP (sapadm): immettere la password
- Per Confermare la password dell'utente dell'agente host SAP (sapadm): immettere la password
- Per Nome host certificato per host hana-s1-db2 [hana-s1-db2]: premere INVIO per accettare l'impostazione predefinita
- Per Nome host certificato per host hana-s1-db3 [hana-s1-db3]: premere INVIO per accettare l'impostazione predefinita
- Per Continuare (y/n): convalidare il riepilogo e, se tutto è corretto, immettere y
[2] Ripetere il passaggio precedente per installare i nodi SAP HANA secondari in SITE 2.

Configurare la replica di sistema di SAP HANA 2.0

[1] Configurare la replica di sistema in SITE 1:

Eseguire il backup dei database come hn1adm:

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')"

Copiare i file PKI di sistema nel sito secondario:

scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/

Creare il sito primario:

hdbnsutil -sr_enable --name=HANA_S1

[2] Configurare la replica di sistema in SITE 2:

Registrare il secondo sito per avviare la replica di sistema. Eseguire il comando seguente come <hanasid>adm:

sapcontrol -nr 03 -function StopWait 600 10
hdbnsutil -sr_register --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=sync --name=HANA_S2
sapcontrol -nr 03 -function StartSystem

[1] Verificare lo stato della replica

Verificare lo stato della replica e attendere che tutti i database siano sincronizzati.

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 |
# | -------- | ------------- | ----- | ------------ | --------- | ------- | --------- | ------------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
# | HN1      | hana-s1-db3   | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db3   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | SYSTEMDB | hana-s1-db1   | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1   |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1   |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db1   | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
# | HN1      | hana-s1-db2   | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db2   |     30303 |         2 | HANA_S2   | 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: HANA_S1

[1,2] Modificare la configurazione di HANA in modo che la comunicazione per la replica di sistema HANA venga indirizzata tramite le interfacce di rete virtuale di replica del sistema HANA.
- Arrestare HANA in entrambi i siti
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB
```
- Modificare global.ini per aggiungere il mapping host per la replica di sistema HANA: usare gli indirizzi IP della hsr subnet.
```
sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
#Add the section
[system_replication_hostname_resolution]
10.23.1.196 = hana-s1-db1
10.23.1.197 = hana-s1-db2
10.23.1.198 = hana-s1-db3
10.23.1.199 = hana-s2-db1
10.23.1.200 = hana-s2-db2
10.23.1.201 = hana-s2-db3
```
- Avviare HANA in entrambi i siti
```
sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB
```
Per altre informazioni, vedere Risoluzione dei nomi host per la replica di sistema.

Creare risorse del file system

Creare una risorsa cluster fittizia del file system, che monitorerà e segnala gli errori, nel caso in cui si verifichi un problema durante l'accesso al file system /hana/sharedmontato su NFS. Ciò consente al cluster di attivare il failover, nel caso in cui si verifichi un problema durante l'accesso a /hana/shared. Per altre informazioni, vedere Gestione della condivisione NFS non riuscita in SU edizione Standard cluster a disponibilità elevata per la replica di sistema HANA

[1] Posizionare pacemaker in modalità di manutenzione, in preparazione alla creazione delle risorse del cluster HANA.
```
crm configure property maintenance-mode=true
```
[1,2] Creare la directory nel file system montato NFS /hana/shared, che verrà usato nella risorsa speciale di monitoraggio del file system. Le directory devono essere create in entrambi i siti.
```
mkdir -p /hana/shared/HN1/check
```
[AH] Creare la directory, che verrà usata per montare la risorsa di monitoraggio del file system speciale. La directory deve essere creata in tutti i nodi del cluster HANA.
```
mkdir -p /hana/check
```
[1] Creare le risorse del cluster del file system.
```
crm configure primitive fs_HN1_HDB03_fscheck Filesystem \
  params device="/hana/shared/HN1/check" \
  directory="/hana/check" fstype=nfs4 \
  options="bind,defaults,rw,hard,proto=tcp,noatime,nfsvers=4.1,lock" \
  op monitor interval=120 timeout=120 on-fail=fence \
  op_params OCF_CHECK_LEVEL=20 \
  op start interval=0 timeout=120 op stop interval=0 timeout=120

crm configure clone cln_fs_HN1_HDB03_fscheck fs_HN1_HDB03_fscheck \
  meta clone-node-max=1 interleave=true

crm configure location loc_cln_fs_HN1_HDB03_fscheck_not_on_mm \
  cln_fs_HN1_HDB03_fscheck -inf: hana-s-mm    
```
OCF_CHECK_LEVEL=20 l'attributo viene aggiunto all'operazione di monitoraggio, in modo che le operazioni di monitoraggio eseguano un test di lettura/scrittura nel file system. Senza questo attributo, l'operazione di monitoraggio verifica solo che il file system sia montato. Questo può essere un problema perché quando la connettività viene persa, il file system può rimanere montato, nonostante non sia accessibile.

on-fail=fence l'attributo viene aggiunto anche all'operazione di monitoraggio. Con questa opzione, se l'operazione di monitoraggio non riesce in un nodo, tale nodo viene immediatamente delimitato.

Implementare hook HANA SAPHanaSrMultiTarget e susChkSrv

Questo passaggio importante consiste nell'ottimizzare l'integrazione con il cluster e il rilevamento quando è possibile un failover del cluster. È consigliabile configurare l'hook Python SAPHanaSrMultiTarget. Per HANA 2.0 SP5 e versioni successive, è consigliabile implementare sia gli hook SAPHanaSrMultiTarget che susChkSrv.

Nota

Il provider SAPHanaSrMultiTarget HA sostituisce SAPHanaSR per la scalabilità orizzontale di HANA. SAPHanaSR è stato descritto nella versione precedente di questo documento.
Vedere SU edizione Standard post di blog sulle modifiche con il nuovo hook HANA HA.

I passaggi forniti per l'hook SAPHanaSrMultiTarget sono per una nuova installazione. L'aggiornamento di un ambiente esistente da SAPHanaSR al provider SAPHanaSrMultiTarget richiede diverse modifiche e NON è descritto in questo documento. Se l'ambiente esistente non usa un terzo sito per il ripristino di emergenza e la replica del sistema multi-destinazione HANA non viene usata, il provider SAPHanaSR HA può rimanere in uso.

SusChkSrv estende la funzionalità del provider di disponibilità elevata SAPHanaSrMultiTarget principale. Agisce nella situazione in cui si verifica un arresto anomalo del processo HDbindexserver di HANA. Se un singolo processo si arresta in modo anomalo in genere HANA tenta 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, invece di attendere il riavvio del processo hdbindexserver nello stesso nodo. In HANA scale-out susChkSrv agisce in modo indipendente per ogni macchina virtuale HANA. L'azione configurata ucciderà HANA o limiterà la macchina virtuale interessata, che attiva un failover nel periodo di timeout configurato.

SU edizione Standard SLES 15 SP1 o versione successiva è necessario per il funzionamento di entrambi gli hook HANA HA. La tabella seguente mostra altre dipendenze.

Hook SAP HANA HA	Versione di HANA obbligatoria	SAPHanaSR-ScaleOut obbligatorio
SAPHanaSrMultiTarget	HANA 2.0 SPS4 o versione successiva	0.180 o versione successiva
susChkSrv	HANA 2.0 SPS5 o versione successiva	0.184.1 o versione successiva

Passaggi per implementare entrambi gli hook:

[1,2] Arrestare HANA in entrambi i siti di replica di sistema. Eseguire come <sid>adm:
```
sapcontrol -nr 03 -function StopSystem
```
[1,2] Regolare global.ini in ogni sito del cluster. Se i prerequisiti per l'hook susChkSrv non sono soddisfatti, l'intero blocco [ha_dr_provider_suschksrv] non deve essere configurato.
È possibile modificare il comportamento di susChkSrv con il parametro action_on_lost. I valori validi sono [ ignore | stop | kill | fence ].
```
# add to global.ini on both sites. Do not copy global.ini between sites.
[ha_dr_provider_saphanasrmultitarget]
provider = SAPHanaSrMultiTarget
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR-ScaleOut
execution_order = 3
action_on_lost = kill

[trace]
ha_dr_saphanasrmultitarget = info
```
La posizione predefinita degli hook a disponibilità elevata distribuita da SU edizione Standard è /usr/share/SAPHanaSR-ScaleOut. L'uso del percorso standard offre un vantaggio che il codice hook Python viene aggiornato automaticamente tramite gli aggiornamenti del sistema operativo o del pacchetto e viene usato da HANA al successivo riavvio. Con un percorso personalizzato facoltativo, ad esempio /hana/shared/myHooks, è possibile separare gli aggiornamenti del sistema operativo dalla versione hook usata.

[AH] Il cluster richiede la configurazione sudoers nei nodi del cluster per <sid>adm. In questo esempio ottenuto creando un nuovo file. Eseguire i comandi adattando root i valori di hn1 con SID minuscolo corretto.

cat << EOF > /etc/sudoers.d/20-saphana
# SAPHanaSR-ScaleOut needs for HA/DR hook scripts
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_gsh *
so1adm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=hn1 *
EOF

[1,2] Avviare SAP HANA in entrambi i siti di replica. Eseguire come <sid>adm.
```
sapcontrol -nr 03 -function StartSystem 
```

[A] Verificare che l'installazione dell'hook sia attiva in tutti i nodi del cluster. Eseguire come <sid>adm.

cdtrace
grep HADR.*load.*SAPHanaSrMultiTarget nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[14162]{-1}[-1/-1] 2023-01-26 12:53:55.728027 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'SAPHanaSrMultiTarget' from /usr/share/SAPHanaSR-ScaleOut/
grep SAPHanaSr.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256705 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00080) : SAPHanaSrMultiTarget.init() CALLING CRM: <sudo /usr/sbin/crm_attribute -n hana_hn1_gsh -v 2.2  -l reboot> rc=0
# nameserver_hana-s1-db1.31001.000.trc:[17636]{-1}[-1/-1] 2023-01-26 16:30:19.256739 i ha_dr_SAPHanaSrM SAPHanaSrMultiTarget.py(00081) : SAPHanaSrMultiTarget.init() Running srHookGeneration 2.2, see attribute hana_hn1_gsh too

Verificare l'installazione dell'hook susChkSrv. Eseguire come <sid>adm.

cdtrace
egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
# Example output
# 2023-01-19 08:23:10.581529  [1674116590-10005] susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
# 2023-01-19 08:23:31.553566  [1674116611-14022] START: indexserver event looks like graceful tenant start
# 2023-01-19 08:23:52.834813  [1674116632-15235] START: indexserver event looks like graceful tenant start (indexserver started)

Creare le risorse cluster SAP HANA

[1] Creare le risorse del cluster HANA. Eseguire i comandi seguenti come root.

Assicurarsi che il cluster sia già in modalità di manutenzione.

Creare quindi la risorsa topologia HANA.

sudo crm configure primitive rsc_SAPHanaTopology_HN1_HDB03 ocf:suse:SAPHanaTopology \
  op monitor interval="10" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="HN1" InstanceNumber="03"

sudo crm configure clone cln_SAPHanaTopology_HN1_HDB03 rsc_SAPHanaTopology_HN1_HDB03 \
 meta clone-node-max="1" target-role="Started" interleave="true"

Creare quindi la risorsa dell'istanza di HANA.

Nota

Questo articolo contiene riferimenti a termini che Microsoft non usa più. Quando questi termini vengono rimossi dal software, verranno rimossi da questo articolo.
```
sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHanaController \
  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="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
  meta clone-node-max="1" master-max="1" interleave="true"
```
Importante

È consigliabile impostare solo AUTOMATED_REGISTER su no, durante l'esecuzione di test di failover completi, per evitare che l'istanza primaria non riuscita venga registrata automaticamente come secondaria. Dopo aver completato correttamente i test di failover, impostare AUTOMATED_REGISTER su sì, in modo che dopo la replica del sistema di acquisizione possa riprendere automaticamente.

Creare un indirizzo IP virtuale e le risorse associate.

sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"

sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

Creare i vincoli del cluster

# Colocate the IP with HANA master
sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
  msl_SAPHana_HN1_HDB03:Master  

# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
  msl_SAPHana_HN1_HDB03

# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaCon_not_on_majority_maker msl_SAPHana_HN1_HDB03 -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTop_not_on_majority_maker cln_SAPHanaTopology_HN1_HDB03 -inf: hana-s-mm

[1] Configurare proprietà aggiuntive del cluster

sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=50

[1] Posizionare il cluster fuori dalla modalità di manutenzione. Assicurarsi che lo stato del cluster sia corretto e che tutte le risorse siano avviate.

# Cleanup any failed resources - the following command is example 
crm resource cleanup rsc_SAPHana_HN1_HDB03

# Place the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false

[1] Verificare la comunicazione tra l'hook HANA e il cluster, mostrando lo stato SOK per SID ed entrambi i siti di replica con stato P(rimary) o S(econdary).

sudo /usr/sbin/SAPHanaSR-showAttr
# Expected result
# Global cib-time                 maintenance prim  sec sync_state upd
# ---------------------------------------------------------------------
# HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
# 
# Sites     lpt        lss mns        srHook srr
# -----------------------------------------------
# HANA_S1     1674815869 4   hana-s1-db1 PRIM   P
# HANA_S2     30         4   hana-s2-db1 SWAIT  S

Nota

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

Testare il failover di SAP HANA

Nota

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

Prima di avviare un test, controllare lo stato di replica del cluster e del sistema SAP HANA.

a. Verificare che non siano presenti azioni cluster non riuscite

#Verify that there are no failed cluster actions
crm status
# Example 
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Full list of resources:
#
# stonith-sbd    (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#     Stopped: [ hana-s-mm ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s1-db1

b. Verificare che la replica di sistema SAP HANA sia sincronizzata

# Verify HANA HSR is in sync
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 | hana-s1-db1  | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1  |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1  |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db1  | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db3  | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db3  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#| HN1      | hana-s1-db2  | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db2  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
#
#status system replication site "1": ACTIVE
#overall system replication status: ACTIVE
#
#Local System Replication State
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#
#mode: PRIMARY
#site id: 1
#site name: HANA_S1

È consigliabile convalidare accuratamente la configurazione del cluster SAP HANA eseguendo i test, documentati in DISPONIBILITÀ elevata per SAP HANA nelle macchine virtuali di Azure in SLES e nello scenario con scalabilità orizzontale delle prestazioni ottimizzate per la replica SLES.

Verificare la configurazione del cluster per uno scenario di errore quando un nodo perde l'accesso alla condivisione NFS (/hana/shared).

Gli agenti di risorse SAP HANA dipendono dai file binari archiviati per /hana/shared eseguire operazioni durante il failover. Il file system /hana/shared viene montato su NFS nella configurazione presentata. Un test che può essere eseguito consiste nel creare una regola del firewall temporanea per bloccare l'accesso /hana/shared al file system montato NFS in una delle macchine virtuali del sito primario. Questo approccio convalida che il cluster eseguirà il failover, se l'accesso a /hana/shared andrà perso nel sito di replica di sistema attivo.

Risultato previsto: quando si blocca l'accesso al /hana/shared file system montato NFS in una delle macchine virtuali del sito primario, l'operazione di monitoraggio che esegue operazioni di lettura/scrittura nel file system avrà esito negativo, perché non è in grado di accedere al file system e attiverà il failover delle risorse HANA. Lo stesso risultato è previsto quando il nodo HANA perde l'accesso alla condivisione NFS.

È possibile controllare lo stato delle risorse del cluster eseguendo crm_mon o crm status. Stato delle risorse prima dell'avvio del test:

# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s1-db1 ]
#     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1

Per simulare un errore per /hana/shared:

Se si usa NFS in ANF, verificare prima di tutto l'indirizzo IP per il /hana/shared volume ANF nel sito primario. A tale scopo, eseguire df -kh|grep /hana/shared.
Se si usa NFS in File di Azure, determinare prima di tutto l'indirizzo IP dell'endpoint privato per l'account di archiviazione.

Configurare quindi una regola del firewall temporanea per bloccare l'accesso all'indirizzo IP del /hana/shared file system NFS eseguendo il comando seguente in una delle macchine virtuali del sito di replica del sistema HANA primario.

In questo esempio il comando è stato eseguito su hana-s1-db1 per il volume /hana/sharedANF .

iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP

Le risorse del cluster verranno migrate nell'altro sito di replica di sistema HANA.

Se si imposta AUTOMATED_REGISTER="false", è necessario configurare la replica di sistema SAP HANA nel sito secondario. In questo caso, è possibile eseguire questi comandi per riconfigurare SAP HANA come secondario.

# Execute on the secondary 
su - hn1adm
# Make sure HANA is not running on the secondary site. If it is started, stop HANA
sapcontrol -nr 03 -function StopWait 600 10
# Register the HANA secondary site
hdbnsutil -sr_register --name=HANA_S1 --remoteHost=hana-s2-db1 --remoteInstance=03 --replicationMode=sync
# Switch back to root and cleanup failed resources
crm resource cleanup SAPHana_HN1_HDB03

Stato delle risorse, dopo il test:

# Output of crm_mon
#7 nodes configured
#24 resource instances configured
#
#Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
#
#Active resources:
#
#stonith-sbd     (stonith:external/sbd): Started hana-s-mm
# Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hana-s2-db1 ]
#     Slaves: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db2 hana-s2-db3 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1

Passaggi successivi

Pianificazione e implementazione di macchine virtuali di Azure per SAP
Distribuzione di Macchine virtuali di Azure per SAP
Distribuzione DBMS di macchine virtuali di Azure per SAP
Volumi NFS v4.1 in Azure NetApp Files per SAP HANA
Per informazioni su come stabilire la disponibilità elevata e pianificare il ripristino di emergenza di SAP HANA nelle macchine virtuali di Azure, vedere Disponibilità elevata di SAP HANA in Azure Macchine virtuali (VM).

Disponibilità elevata per il sistema sap HANA con scalabilità orizzontale con HSR su SU edizione Standard Linux Enterprise Server

Panoramica

Preparare l'infrastruttura

Distribuire macchine virtuali Linux tramite il portale di Azure

Configurare il servizio di bilanciamento del carico di Azure

Distribuire NFS

Distribuire l'infrastruttura di Azure NetApp Files

Distribuire NFS nell'infrastruttura File di Azure

Configurazione e preparazione del sistema operativo

Preparare i file system

Montare i file system condivisi (NFS di Azure NetApp Files)

Montare i file system condivisi (File di Azure NFS)

Preparare i file system locali di dati e log

Creare un cluster Pacemaker

Installazione

Preparare l'installazione di HANA

Installazione di HANA nel primo nodo in ogni sito

Configurare la replica di sistema di SAP HANA 2.0

Creare risorse del file system

Implementare hook HANA SAPHanaSrMultiTarget e susChkSrv

Creare le risorse cluster SAP HANA

Testare il failover di SAP HANA

Passaggi successivi

Risorse aggiuntive