Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive come implementare un sistema SAP HANA a disponibilità elevata in una configurazione con scale-out con la replica di sistema HANA (HSR) e Pacemaker in macchine virtuali (VM) di Azure SUSE Linux Enterprise Server. 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 richiesta 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 SUSE Linux Enterprise Server for SAP Applications
- Nota SAP 1944799: contiene le linee guida SAP per SUSE Linux Enterprise Server for SAP Applications
- Nota SAP 2178632: contiene informazioni dettagliate su tutte le metriche di monitoraggio segnalate per SAP in Azure
- Nota SAP 2191498: contiene la versione dell'agente host SAP per Linux necessaria in Azure
- Nota SAP 2243692: contiene informazioni sulle licenze SAP in Linux in Azure
- Nota SAP 1984787: contiene informazioni generali su SUSE LINUX Enterprise Server 12
- Nota SAP 1999351: contiene informazioni 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
- Community Wiki SAP: contiene tutte le note su SAP necessarie per Linux
- Pianificazione e implementazione di Macchine virtuali di Azure per SAP in Linux
- Distribuzione di Macchine virtuali di Azure per SAP in Linux
- Distribuzione DBMS di Macchine virtuali di Azure per SAP in Linux
- Guide alle procedure consigliate per SUSE SAP HA: 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 SUSE High Availability Extension 12 SP5
- Gestione della condivisione NFS non riuscita nel cluster SUSE 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 scale-out 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 di database (DB) HANA.
Nell'architettura presentata è possibile implementare il file system /hana/shared
condiviso HANA usando Azure NetApp Files o la condivisione NFS su Azure Files. Ogni nodo HANA all'interno dello stesso sito di replica di sistema HANA monta il file system condiviso HANA tramite NFS. 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 prendere in considerazione l'uso del gruppo di volumi di applicazioni di Azure NetApp Files per SAP HANA.
Avviso
La distribuzione di /hana/data
e /hana/log
su NFS in Azure Files 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 di 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
Dato che /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/shared
vengono 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 sia già stato creato il gruppo di risorse e la rete virtuale di Azure con tre subnet: client
, inter
e hsr
.
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 del 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
Distribuire le macchine virtuali come nodi del database SAP usando le dimensioni delle macchine virtuali certificate per SAP HANA, come elencato nelle piattaforme IaaS certificate di SAP HANA. Assicurarsi che la rete accelerata sia abilitata durante la distribuzione dei nodi del database HANA.
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 subnet client
.
Distribuire dischi gestiti localmente per /hana/data
e /hana/log
. La configurazione di archiviazione minima consigliata per /hana/data
e /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 client
della rete virtuale.
Quando la macchina virtuale viene distribuita tramite il 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 rete virtuale di Azure client
come hana-s1-db1-client, hana-s1-db2-client, hana-s1-db3-client e così via.
Importante
- Accertarsi che il sistema operativo selezionato sia dotato di certificazione SAP per SAP HANA sugli specifici tipi di macchina virtuale in uso. Per ottenere un elenco dei tipi di macchina virtuale certificati per SAP HANA e delle versioni di sistema operativo correlate, vedere il sito delle piattaforme IaaS certificate per 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
su NFS su Azure Files, è consigliabile eseguire la distribuzione su SUSE Linux Enterprise Server (SLES) 15 SP2 e versioni successive.
Creare sei interfacce di rete, una per ogni macchina virtuale del database HANA, nella subnet di rete virtuale
inter
(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:
- Passare alla macchina virtuale nel portale di Azure.
- Nel riquadro sinistro, selezionare Macchine virtuali. Filtrare in base al nome della macchina virtuale (ad esempio, hana-s1-db1) e poi selezionare la macchina virtuale.
- Nel riquadro Panoramica, selezionare Arresta per deallocare la macchina virtuale.
- Selezionare Rete e poi collegare l'interfaccia di rete. Nell'elenco a discesa Collega interfaccia di rete, selezionare le interfacce di rete già create per le subnet
inter
ehsr
. - Seleziona Salva.
- 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 ).
- 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 subnet
inter
ehsr
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 subnet
inter
ehsr
.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
Nota
Non è necessario installare il pacchetto dell'interfaccia della riga di comando di Azure nei nodi HANA per eseguire
az
il comando. È possibile eseguirlo da qualsiasi computer in cui sia installata l'interfaccia della riga di comando o usare Azure Cloud Shell.
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 il servizio di bilanciamento del carico esistente nella sezione Rete. Seguire questa procedura per configurare il servizio di bilanciamento del carico standard per la configurazione a disponibilità elevata del database HANA.
Nota
- Per il ridimensionamento HANA, selezionare l'interfaccia di rete per la
client
subnet quando si aggiungono le macchine virtuali nel pool di back-end. - Il set completo di comandi nell'interfaccia della riga di comando di Azure e PowerShell aggiunge le macchine virtuali con l'interfaccia di rete primaria nel pool back-end.
Seguire la procedura descritta in Creare il servizio di bilanciamento del carico per configurare un servizio di bilanciamento del carico standard per un sistema SAP a disponibilità elevata usando il portale di Azure. Durante la configurazione del servizio di bilanciamento del carico, considerare i punti seguenti:
- Configurazione IP front-end: creare un indirizzo IP front-end. Selezionare la stessa rete virtuale e il nome della subnet delle macchine virtuali di database.
- Pool back-end: creare un pool back-end e aggiungere macchine virtuali di database.
-
Regole in ingresso: creare una regola di bilanciamento del carico. Seguire la stessa procedura per entrambe le regole di bilanciamento del carico.
- Indirizzo IP front-end: selezionare un indirizzo IP front-end.
- Pool back-end: selezionare un pool back-end.
- Porte a disponibilità elevata: selezionare questa opzione.
- Protocollo: selezionare TCP.
-
Probe di integrità: creare un probe di integrità con i dettagli seguenti:
- Protocollo: selezionare TCP.
- Porta: ad esempio, 625<instance-no.>.
- Intervallo: immettere 5.
- Soglia probe: immettere 2.
- Timeout di inattività (minuti): immettere 30.
- Abilita IP mobile: selezionare questa opzione.
Nota
La proprietà di configurazione del probe di integrità numberOfProbes
, altrimenti nota come soglia non integra nel portale, non viene rispettata. Per controllare il numero di probe consecutivi riusciti o non riusciti, impostare la proprietà probeThreshold
su 2
. Non è attualmente possibile impostare questa proprietà usando il portale di Azure, quindi usare l'interfaccia della riga di comando di Azure o il comando di PowerShell.
Nota
Quando le macchine virtuali senza indirizzi IP pubblici vengono inserite nel pool back-end di un servizio di bilanciamento del carico Standard di Azure (nessun indirizzo IP pubblico), non esiste connettività Internet in uscita, a meno che non venga eseguita una configurazione aggiuntiva per abilitare il routing agli endpoint pubblici. Per informazioni dettagliate su come configurare la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali con Azure Load Balancer Standard in scenari di 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
su0
. Per informazioni dettagliate, vedere Probe di integrità di Load Balancer e la nota SAP 2382421. - Per impedire a saptune di modificare il valore
net.ipv4.tcp_timestamps
impostato manualmente da0
a1
, aggiornare la versione di saptune alla versione 3.1.1 o successiva. Per ulteriori dettagli, vedere saptune 3.1.1 – Devo fare l’aggiornamento?.
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.
Configurazione dell'infrastruttura Azure NetApp Files
Distribuire volumi di Azure NetApp Files per il file system /hana/shared
. È necessario un volume /hana/shared
separato per ogni sito di replica di sistema HANA. Per ulteriori 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 di File di Azure
Distribuire condivisioni NFS di File di Azure per il file system /hana/shared
. È necessaria una condivisione NFS di File di Azure /hana/shared
separata per ogni sito di replica di sistema HANA. Per ulteriori informazioni, vedere Come creare una condivisione NFS.
In questo esempio sono state usate le condivisioni NFS di File di Azure 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 le voci seguenti a
/etc/hosts
.# 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 ulteriori informazioni, vedere la nota SAP 2382421.
[AH] Preparare le macchine virtuali: applicare le impostazioni consigliate per la nota SAP 2205917 per SUSE 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 - Impostazioni del kernel Linux 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] Regolare le impostazioni sunrpc, come consigliato nella nota SAP 3024346 - Impostazioni del kernel Linux 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. Verificare che il dominio sia configurato come dominio di Azure NetApp Files predefinito, ovvero
defaultv4iddomain.com
, e che il mapping sia impostato su nobody (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 comenobody
.sudo cat /etc/idmapd.conf # Example [General] Domain = defaultv4iddomain.com [Mapping] Nobody-User = nobody Nobody-Group = nobody
[AH] Verificare
nfs4_disable_idmapping
. Il valore deve essere impostato su Y. Per creare la struttura di directory in cui si trovanfs4_disable_idmapping
, 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
/hana/shared/
corrispondenti 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 (NFS di File di Azure)
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
/hana/shared/
corrispondenti 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.
È necessario eseguire i passaggi 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 (Logical Volume Manager, LVM). L'esempio seguente 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 i volumi fisici per tutti i dischi da usare:
sudo pvcreate /dev/disk/azure/scsi1/lun0 sudo pvcreate /dev/disk/azure/scsi1/lun1 sudo pvcreate /dev/disk/azure/scsi1/lun2
[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. La dimensione di striping per il volume di dati è 256KiB. Un volume fisico viene usato per il volume di log, quindi non viene usata alcuna opzione-i
o-I
in modo esplicito per i comandi del volume di log.Importante
Usare l'opzione
-i
e impostarla sul numero del volume fisico sottostante quando si usano più volumi fisici per ogni volume di dati 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 voci
fstab
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, compreso il produttore di maggioranza nel cluster.
Per un cluster con scalabilità orizzontale, assicurarsi che i parametri seguenti siano impostati correttamente:
- Non impostare
quorum expected-votes
su 2, perché non si tratta di un cluster a due nodi. - Assicurarsi che la proprietà
concurrent-fencing=true
del cluster sia impostata, in modo che l'isolamento del nodo venga deserializzato. - La risorsa stonith-sbd deve includere il parametro
pcmk_action_limit=-1
con valore negativo 1 (illimitato) per consentire azioni stonith deserializzate.
Installazione
In questo esempio per la distribuzione di SAP HANA nella configurazione con scale-out con HSR in macchine virtuali di Azure è stato usato HANA 2.0 SP5.
Prepararsi per l'installazione di HANA
[AH] Prima dell'installazione di HANA, impostare la password radice. È possibile disabilitare la password radice al termine dell'installazione. Eseguire come
root
comandopasswd
.[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 le 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 nel 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 ulteriori informazioni, vedere la nota SAP 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 parametrointernal_network
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. Immettere i valori seguenti al prompt:
- Per Scegli 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 Nome host locale: premere Invio per accettare l'impostazione predefinita
- Per Intendi aggiungere host al sistema?: immettere n
- Per ID di 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 Selezionare utilizzo del sistema / Immettere indice [4]: immettere 4 (per personalizzato).
- 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 Limitare l’allocazione massima della memoria? [n]: immettere n
- Per Nome host del certificato per Host hana-s1-db1 [hana-s1-db1]: premere Invio per accettare l’impostazione predefinita
- Per 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 Password amministratore di sistema (hn1adm): immettere la password
- Per Home directory dell'amministratore di sistema [/usr/sap/HN1/home]: premere Invio per accettare l'impostazione predefinita
- Per System Administrator Login Shell [/bin/sh]: premere Invio per accettare l'impostazione predefinita
- Per ID utente amministratore di sistema [1001]: premere Invio per accettare l'impostazione predefinita
- Per Immettere l’ID del gruppo di utenti (sapsys) [79]: premere Invio per accettare l’impostazione predefinita
- Per Password utente database di sistema (system): immettere la password del sistema
- Per Conferma password utente database di sistema (sistema):immettere la password del sistema
- Per Riavviare il 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 accertarsi 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 subnet
inter
elisteninterface
deve essere impostata su.internal
. Verificare la sezione internal_hostname_resolution. Deve avere gli indirizzi IP per le macchine virtuali HANA che appartengono alla subnetinter
.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
per 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 comunicazione
client
.# 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 la 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. Immettere i valori seguenti al prompt:
- 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 Selezionare i ruoli per l’host 'hana-s1-db2' [1]: 1 (per ruolo di lavoro)
- Per Gruppo di failover host per l’host 'hana-s1-db2' [impostazione predefinita]: premere Invio per accettare l’impostazione predefinita
- Per Immettere il numero di partizione di archiviazione per l'host 'hana-s1-db2' [<<assegnare automaticamente>>]: premere Invio per accettare il valore predefinito
- Per Immettere il gruppo del ruolo di lavoro per l’host 'hana-s1-db2' [impostazione predefinita]: premere Invio per accettare l’impostazione predefinita
- Per Selezionare i ruoli per l’host 'hana-s1-db3' [1]: 1 (per ruolo di lavoro)
- Per Immettere il gruppo di failover host per l’host 'hana-s1-db3' [impostazione predefinita]: premere Invio per accettare l’impostazione predefinita
- Per Immettere il numero di partizione di archiviazione per l'host 'hana-s1-db3' [<<assegnare automaticamente>>]: premere Invio per accettare il valore predefinito
- Per Immettere il gruppo del ruolo di lavoro per l’host 'hana-s1-db3' [impostazione predefinita]: premere Invio per accettare il valore predefinito
- Per Password amministratore di sistema (hn1adm): 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 del certificato per l’host hana-s1-db2 [hana-s1-db2]: premere Invio per accettare l'impostazione predefinita
- Per Nome host del certificato per l’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 nel SITE 1:
Eseguire il backup dei database come ADM hn1:
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 di chiave di archiviazione sicura del 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 nel SITE 2:
Registrare il secondo nodo per avviare la replica di sistema. Eseguire il comando seguente come ADM <hanasid>:
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 subnet
hsr
.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 ulteriori informazioni, vedere Risoluzione dei nomi host per la replica di sistema.
Implementare agenti di risorse HANA
SUSE fornisce due diversi pacchetti software per l'agente di risorse Pacemaker per gestire SAP HANA. I pacchetti software SAPHanaSR-ScaleOut e SAPHanaSR-angi usano una sintassi e parametri leggermente diversi e non sono compatibili. Per informazioni dettagliate e differenze tra SAPHanaSR-angi e SAPHanaSR-ScaleOut, vedere le note sulla versione di SUSE e la documentazione . Questo documento illustra entrambi i pacchetti in schede separate nelle rispettive sezioni.
Avviso
Non sostituire il pacchetto SAPHanaSR-angi con SAPHanaSR-ScaleOut in un cluster già configurato. L'aggiornamento da SAPHanaSR a SAPHanaSR-angi richiede una procedura specifica. Per altre informazioni, vedere il post di blog di SUSE Come eseguire l'aggiornamento a SAPHanaSR-angi.
- [T] Installare i pacchetti di disponibilità elevata SAP HANA:
Nota
SAPHanaSR-angi ha un requisito di versione minima di SAP HANA 2.0 SPS 05 e SUSE SLES for SAP Applications 15 SP4 o versione successiva.
Eseguire il comando seguente in tutte le macchine virtuali del cluster, incluso il produttore di maggioranza per installare i pacchetti a disponibilità elevata:
sudo zypper install SAPHanaSR-angi
sudo zypper in -t pattern ha_sles
Configurare i provider SAP HANA HA/DR
I provider SAP HANA HA/DR ottimizzano l'integrazione con il cluster e migliorano il rilevamento quando è necessario un failover del cluster. Lo script hook principale è susHanaSR (per SAPHanaSR-angi) o SAPHanaSrMultiTarget (per il pacchetto SAPHanaSR-ScaleOut). Per l'integrazione del cluster è obbligatorio configurare l'hook python susHanaSR/SAPHanaSrMultiTarget. Per HANA 2.0 SPS 05 e versioni successive, è consigliabile implementare sia susHanaSR/SAPHanaSrMultiTarget che gli hook susChkSrv.
L'hook susChkSrv estende la funzionalità del fornitore HA principale susHanaSR/SAPHanaSrMultiTarget. Agisce quando 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. L'azione attiva un failover nel periodo di timeout configurato, anziché attendere il riavvio del processo hdbindexserver nello stesso nodo. In HANA scale-out, susChkSrv agisce per ogni nodo del cluster che esegue HANA in modo indipendente. L'azione configurata termina HANA o delimita la macchina virtuale interessata, che attiva un failover nel periodo di timeout configurato.
[1,2] Arrestare HANA in entrambi i siti di replica di sistema. Eseguire come <sid>adm:
sapcontrol -nr 03 -function StopSystem
[1,2] Installare gli hook del provider HANA. Gli hook devono essere installati in entrambi i siti di database HANA.
[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. Valori validi:[ ignore | stop | kill | fence ]
.# add to global.ini on both sites. Do not copy global.ini between sites. [ha_dr_provider_sushanasr] provider = susHanaSR path = /usr/share/SAPHanaSR-angi execution_order = 1 [ha_dr_provider_suschksrv] provider = susChkSrv path = /usr/share/SAPHanaSR-angi execution_order = 3 action_on_lost = kill [trace] ha_dr_sushanasr = info ha_dr_suschksrv = info
SUSE fornisce per impostazione predefinita i ganci HA nella directory
/usr/share/SAPHanaSR-angi
. L'uso del percorso standard garantisce che gli aggiornamenti del pacchetto del sistema operativo aggiornino automaticamente il codice hook di Python e HANA utilizzi il codice aggiornato al riavvio successivo. In alternativa, è possibile specificare il proprio percorso, ad esempio/hana/shared/myHooks
, per 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 il comando indicato di seguito come utente ROOT. Sostituire <sid con ID di sistema SAP minuscolo> , <SID> per ID sistema SAP maiuscolo e <siteA/B> con i nomi dei siti HANA scelti.
cat << EOF > /etc/sudoers.d/20-saphana # SAPHanaSR-angi requirements for HA/DR hook scripts Cmnd_Alias SOK_SITEA = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias SFAIL_SITEA = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SFAIL -t crm_config -s SAPHanaSR Cmnd_Alias SOK_SITEB = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias SFAIL_SITEB = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SFAIL -t crm_config -s SAPHanaSR Cmnd_Alias HELPER_TAKEOVER = /usr/bin/SAPHanaSR-hookHelper --sid=<SID> --case=checkTakeover Cmnd_Alias HELPER_FENCE = /usr/bin/SAPHanaSR-hookHelper --sid=<SID> --case=fenceMe <sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB, HELPER_TAKEOVER, HELPER_FENCE
Per informazioni dettagliate sull'implementazione dell'hook di replica di sistema SAP HANA, vedere Configurare i provider HA/DR di HANA.
- [1,2] Avviare SAP HANA in entrambi i siti di replica. Eseguire come <sid>adm.
sapcontrol -nr 03 -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
grep HADR.*load.*susHanaSR nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.30301.453.trc:[140145]{-1}[-1/-1] 2025-05-26 07:51:34.677221 i ha_dr_provider HADRProviderManager.cpp(00083) : loading HA/DR Provider 'susHanaSR' from /usr/share/SAPHanaSR-angi
grep susHanaSR.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.30301.453.trc:[140157]{-1}[-1/-1] 2025-05-26 07:51:34.724422 i ha_dr_susHanaSR susHanaSR.py(00042) : susHanaSR.init() version 1.001.1
- [AH] Verificare l'installazione dell'hook susChkSrv. Eseguire il comando seguente come <sap-sid>adm in qualsiasi nodo HANA.
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 la risorsa della topologia di HANA. Assicurarsi che il cluster sia in modalità di manutenzione.
sudo crm configure property maintenance-mode=true
# Replace <placeholders> with your instance number and HANA system ID
sudo crm configure primitive rsc_SAPHanaTopology_<SID>_HDB<InstNum> ocf:suse:SAPHanaTopology \
op monitor interval="50" timeout="600" \
op start interval="0" timeout="600" \
op stop interval="0" timeout="300" \
params SID="<SID>" InstanceNumber="<InstNum>"
sudo crm configure clone cln_SAPHanaTopology_<SID>_HDB<InstNum> rsc_SAPHanaTopology_<SID>_HDB<InstNum> \
meta clone-node-max="1" interleave="true"
- [1] Creare quindi la risorsa dell'istanza di HANA.
# Replace <placeholders> with your instance number and HANA system ID
sudo crm configure primitive rsc_SAPHanaController_<SID>_HDB<InstNum> ocf:suse:SAPHanaController \
op start interval="0" timeout="3600" \
op stop interval="0" timeout="3600" \
op promote interval="0" timeout="900" \
op demote interval="0" timeout="320" \
op monitor interval="60" role="Promoted" timeout="700" \
op monitor interval="61" role="Unpromoted" timeout="700" \
params SID="<SID>" InstanceNumber="<InstNum>" PREFER_SITE_TAKEOVER="true" \
DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \
HANA_CALL_TIMEOUT="120"
sudo crm configure clone mst_SAPHanaController_<SID>_HDB<InstNum> rsc_SAPHanaController_<SID>_HDB<InstNum> \
meta clone-node-max="1" interleave="true" promotable="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 il takeover del sistema, la replicazione possa riprendere automaticamente.
- [1] Creare agenti di risorse del file system per /hana/shared
SAPHanaSR-angi aggiunge un nuovo agente di risorse SAPHanaFilesystem per monitorare l'accesso in lettura/scrittura a /hana/shared/SID. Il sistema operativo monta il file system /hana/shared/SID con ogni host con voci in /etc/fstab. SAPHanaFilesystem e Pacemaker non montano il file system per HANA.
# Replace <placeholders> with your instance number and HANA system ID
sudo crm configure primitive rsc_SAPHanaFilesystem_<SID>_HDB<InstNum> ocf:suse:SAPHanaFilesystem \
op start interval="0" timeout="10" \
op stop interval="0" timeout="20" \
op monitor interval="120" timeout="120" \
params SID="<SID>" InstanceNumber="<InstNum>" ON_FAIL_ACTION="fence"
sudo crm configure clone cln_SAPHanaFilesystem_<SID>_HDB<InstNum> rsc_SAPHanaFilesystem_<SID>_HDB<InstNum> \
meta clone-node-max="1" interleave="true"
# Add a location constraint to not run filesystem check on majority maker VM
sudo crm configure location loc_SAPHanaFilesystem_not_on_majority_maker cln_SAPHanaFilesystem_<SID>_HDB<InstNum> -inf: hana-s-mm
- [1] Continuare con le risorse del cluster per indirizzi IP virtuali e vincoli.
# Replace <placeholders> with your instance number and HANA system ID, and respective IP address and load balancer port
sudo crm configure primitive rsc_ip_<SID>_HDB<InstNum> ocf:heartbeat:IPaddr2 \
op start timeout=60s on-fail=fence \
op monitor interval="10s" timeout="20s" \
params ip="10.23.0.27"
sudo crm configure primitive rsc_nc_<SID>_HDB<InstNum> azure-lb port=62503 \
op monitor timeout=20s interval=10 \
meta resource-stickiness=0
sudo crm configure group g_ip_<SID>_HDB<InstNum> rsc_ip_<SID>_HDB<InstNum> rsc_nc_<SID>_HDB<InstNum>
Creare i vincoli del cluster
# Colocate the IP with primary HANA node
sudo crm configure colocation col_saphana_ip_<SID>_HDB<InstNum> 4000: g_ip_<SID>_HDB<InstNum>:Started \
mst_SAPHanaController_<SID>_HDB<InstNum>:Promoted
# Start HANA Topology before HANA instance
sudo crm configure order ord_SAPHana_<SID>_HDB<InstNum> Optional: cln_SAPHanaTopology_<SID>_HDB<InstNum> \
mst_SAPHanaController_<SID>_HDB<InstNum>
# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaController_not_on_majority_maker mst_SAPHanaController_<SID>_HDB<InstNum> -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTopology_not_on_majority_maker cln_SAPHanaTopology_<SID>_HDB<InstNum> -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
sudo 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 SAPHanaSR-showAttr
Global cib-update dcid prim sec sid topology
----------------------------------------------------------
global 0.165361.0 7 HANA_S2 HANA_S1 HN1 ScaleOut
Resource promotable
-------------------------------------------
msl_SAPHanaController_HN1_HDB03 true
cln_SAPHanaTopology_HN1_HDB03
Site lpt lss mns opMode srHook srMode srPoll srr
----------------------------------------------------------------------
HANA_S2 1748611494 4 hana-s2-db1 logreplay PRIM sync PRIM P
HANA_S1 10 4 hana-s1-db1 logreplay SOK sync SFAIL S
Host clone_state roles score site srah version vhost
----------------------------------------------------------------------------------------------
hana-s1-db1 DEMOTED master1:master:worker:master 100 HANA_S1 - 2.00.074.00 hana-s1-db1
hana-s1-db2 DEMOTED slave:slave:worker:slave -12200 HANA_S1 - 2.00.074.00 hana-s1-db2
hana-s1-db3 DEMOTED slave:slave:worker:slave -12200 HANA_S1 - 2.00.074.00 hana-s1-db3
hana-s2-db1 PROMOTED master1:master:worker:master 150 HANA_S2 - 2.00.074.00 hana-s2-db1
hana-s2-db2 DEMOTED slave:slave:worker:slave -10000 HANA_S2 - 2.00.074.00 hana-s2-db2
hana-s2-db3 DEMOTED slave:slave:worker:slave -10000 HANA_S2 - 2.00.074.00 hana-s2-db3
hana-mm hana-mm
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. SAPHanaSR-angi consente altre opzioni per un'azione più rapida durante un evento del cluster. Vedere la documentazione su SUSE per informazioni dettagliate sul parametro ON_FAIL_ACTION di SAPHanaController, l'agente facoltativo SAPHanaSR-alert-fencing e altre opzioni. L'implementazione deve essere seguita da ulteriori test estesi del cluster nell'ambiente in uso.
Testare il failover di SAP HANA
Nota
Questo articolo contiene riferimenti a termini che Microsoft non usa più. Quando questi termini verranno 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 scale-out per replica SLES ottimizzato per le prestazioni.
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 in
/hana/shared
per 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 al file system/hana/shared
montato su 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
ocrm 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 Azure NetApp Files, verificare prima di tutto l'indirizzo IP per il volume
/hana/shared
di Azure NetApp Files nel sito primario. A tale scopo, eseguiredf -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 file system NFS
/hana/shared
eseguendo il comando seguente in una delle macchine virtuali del sito di replica del sistema HANA primario.In questo esempio, il comando è stato eseguito in hana-s1-db1 per Azure NetApp Files volume
/hana/shared
.iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP
Le risorse del cluster vengono migrate nell'altro sito di replica di sistema HANA.
Se si imposta AUTOMATED_REGISTER="false", è necessario configurare la replica del sistema SAP HANA nel sito secondario dopo l'acquisizione. 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
- Se si usa NFS in Azure NetApp Files, verificare prima di tutto l'indirizzo IP per il volume
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 ottenere la disponibilità elevata e un piano di ripristino di emergenza di SAP HANA nelle macchine virtuali di Azure, vedere Disponibilità elevata di SAP HANA nelle macchine virtuali di Azure (VM).