Condividi tramite

Disponibilità elevata di SAP HANA con scalabilità orizzontale con Azure NetApp Files in SUSE Enterprise Linux

  • Articolo

Questo articolo descrive come configurare la replica di sistema SAP HANA nella distribuzione con scalabilità orizzontale quando i file system HANA vengono montati tramite NFS usando Azure NetApp Files. Nelle configurazioni di esempio e nei comandi di installazione vengono usati il numero di istanza 03 e l'ID di sistema HANA HN1. La replica SAP HANA è costituita da un nodo primario e da almeno un nodo secondario.

Quando i passaggi in questo documento sono contrassegnati con i prefissi seguenti, significano:

  • [T]: il passaggio si applica a tutti i nodi.
  • [1]: il passaggio si applica solo a node1.
  • [2]: il passaggio si applica solo a node2.

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

Nota

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

Panoramica

Tradizionalmente, in un ambiente con scalabilità orizzontale, tutti i file system per SAP HANA vengono montati dall'archiviazione locale. La configurazione della disponibilità elevata della replica di sistema SAP HANA in SUSE Enterprise Linux è pubblicata in Configurare la replica di sistema SAP HANA in SLES.

Per ottenere la disponibilità elevata di SAP HANA di un sistema di scalabilità orizzontale nelle condivisioni NFS di Azure NetApp Files, è necessaria una configurazione aggiuntiva delle risorse nel cluster. Questa configurazione è necessaria per consentire il ripristino delle risorse HANA quando un nodo perde l'accesso alle condivisioni NFS in Azure NetApp Files.

Diagramma che mostra la scalabilità orizzontale di SAP HANA in Azure NetApp Files.

I file system SAP HANA vengono montati in condivisioni NFS usando Azure NetApp Files in ogni nodo. I file system /hana/data, /hana/log e /hana/shared sono univoci per ogni nodo.

Montato in node1 (hanadb1):

  • 10.3.1.4:/hanadb1-data-mnt00001 in /hana/data
  • 10.3.1.4:/hanadb1-log-mnt00001 in /hana/log
  • 10.3.1.4:/hanadb1-shared-mnt00001 in /hana/shared

Montato in node2 (hanadb2):

  • 10.3.1.4:/hanadb2-data-mnt00001 in /hana/data
  • 10.3.1.4:/hanadb2-log-mnt00001 in /hana/log
  • 10.3.1.4:/hanadb2-shared-mnt0001 in /hana/shared

Nota

I file system /hana/shared, /hana/data e /hana/log non vengono condivisi tra i due nodi. Ogni nodo del cluster ha un proprio file system separato.

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

  • Indirizzo IP di configurazione front-end: 10.3.0.50 per hn1-db
  • Porta probe: 62503

Configurare l'infrastruttura Azure NetApp Files

Prima di proseguire con la configurazione dell'infrastruttura Azure NetApp Files, acquisire familiarità con la documentazione di Azure NetApp Files.

Azure NetApp Files è disponibile in numerose aree di Azure. Verificare se l'area di Azure selezionata offre Azure NetApp Files.

Per informazioni sulla disponibilità di Azure NetApp Files per area di Azure, vedere Disponibilità di Azure NetApp Files in base all'area di Azure.

Considerazioni importanti

Quando si crea Azure NetApp Files per i sistemi con scalabilità orizzontale SAP HANA, tenere presenti le considerazioni importanti documentate nei volumi NFS v4.1 in Azure NetApp Files per SAP HANA.

Ridimensionamento del database HANA in Azure NetApp Files

La velocità effettiva di un volume di Azure NetApp Files è una funzione delle dimensioni del volume e del livello di servizio, come documentato in Livelli di servizio per Azure NetApp Files.

Durante la progettazione dell'infrastruttura per SAP HANA in Azure con Azure NetApp Files, tenere presente le raccomandazioni nei volumi NFS v4.1 in Azure NetApp Files per SAP HANA.

La configurazione in questo articolo viene presentata con semplici volumi di Azure NetApp Files.

Importante

Per i sistemi di produzione, dove le prestazioni sono fondamentali, è consigliabile valutare e prendere in considerazione l'uso di gruppo di volumi di applicazioni di Azure NetApp Files per SAP HANA.

Tutti i comandi per montare /hana/shared in questo articolo vengono presentati per volumi NFSv4.1 /hana/shared. Se i volumi /hana/shared sono stati distribuiti come volumi NFSv3, non dimenticare di modificare i comandi di montaggio per /hana/shared per NFSv3.

Distribuire le risorse di Azure NetApp Files

Le istruzioni seguenti presuppongono che la rete virtuale di Azure sia già stata distribuita. Le risorse di Azure NetApp Files e tutte le macchine virtuali, in cui le risorse di Azure NetApp Files vengono montate, devono essere distribuite nella stessa istanza di Rete virtuale di Azure o in reti virtuali di Azure con peering.

  1. Creare un account NetApp nell'area di Azure selezionata seguendo le istruzioni in Creare un account NetApp.

  2. Configurare un pool di capacità di Azure NetApp Files, seguendo le istruzioni su come Configurare un pool di capacità Azure NetApp Files.

    L'architettura HANA presentata in questo articolo usa un singolo pool di capacità di Azure NetApp Files a livello di servizio Ultra. Per i carichi di lavoro HANA in Azure, è consigliabile usare il livello di servizio Ultra o Premium di Azure NetApp Files.

  3. Delegare una subnet ai file di Azure NetApp come descritto nelle istruzioni per Delegare una subnet a Azure NetApp Files.

  4. Distribuire volumi di Azure NetApp Files seguendo le istruzioni riportate in Creare un volume NFS per Azure NetApp Files.

    Quando si distribuiscono i volumi, assicurarsi di selezionare la versione NFSv4.1. Distribuire i volumi nella subnet di Azure NetApp Files designata. Gli indirizzi IP dei volumi di Azure NetApp Files vengono assegnati automaticamente.

    Le risorse di Azure NetApp Files e le macchine virtuali di Azure devono trovarsi nella stessa istanza di Rete virtuale di Azure o in reti virtuali di Azure con peering. Ad esempio, hanadb1-data-mnt00001, hanadb1-log-mnt00001 e così via sono i nomi di volume, e nfs://10.3.1.4/hanadb1-data-mnt00001, nfs://10.3.1.4/hanadb1-log-mnt00001 e così via sono i percorsi di file per i volumi di Azure NetApp Files.

    In hanadb1:

    • Volume hanadb1-data-mnt00001 (nfs://10.3.1.4:/hanadb1-data-mnt00001)
    • Volume hanadb1-log-mnt00001 (nfs://10.3.1.4:/hanadb1-log-mnt00001)
    • Volume hanadb1-shared-mnt00001 (nfs://10.3.1.4:/hanadb1-shared-mnt00001)

    In hanadb2:

    • Volume hanadb2-data-mnt00001 (nfs://10.3.1.4:/hanadb2-data-mnt00001)
    • Volume hanadb2-log-mnt00001 (nfs://10.3.1.4:/hanadb2-log-mnt00001)
    • Volume hanadb2-shared-mnt00001 (nfs://10.3.1.4:/hanadb2-shared-mnt00001)

Preparare l'infrastruttura

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

Distribuire macchine virtuali Linux manualmente tramite il portale di Azure

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

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

Importante

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

Configurare Azure Load Balancer

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

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

  1. 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.
  2. Pool back-end: creare un pool back-end e aggiungere macchine virtuali di database.
  3. 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.

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

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

Importante

  • Non abilitare i timestamp TCP nelle macchine virtuali di Azure che si trovano dietro il bilanciamento del carico. Se si abilitano i timestamp TCP, i probe di integrità hanno esito negativo. Impostare il parametro net.ipv4.tcp_timestamps su 0. Per altre informazioni, vedere Probe di integrità di Load Balancer e SAP Note 2382421.
  • Per impedire a saptune di modificare manualmente il valore net.ipv4.tcp_timestamps da 0 a 1, aggiornare la versione di saptune alla versione 3.1.1 o successiva. Per altre informazioni, vedere saptune 3.1.1 – Devo fare l’aggiornamento?.

Montare il volume di Azure NetApp Files

  1. [A] Creare punti di montaggio per i volumi di database HANA.

    sudo mkdir -p /hana/data/HN1/mnt00001
sudo mkdir -p /hana/log/HN1/mnt00001
sudo mkdir -p /hana/shared/HN1

  2. [A] Verificare l'impostazione del dominio NFS. Assicurarsi che il dominio sia configurato come dominio predefinito di Azure NetApp Files, ovvero defaultv4iddomain.com e che il mapping sia impostato su nessuno.

    sudo cat /etc/idmapd.conf

    Output di esempio:

    [General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

    Importante

    Assicurarsi di impostare il dominio NFS in /etc/idmapd.conf nella macchina virtuale in modo che corrisponda alla configurazione di dominio predefinita in Azure NetApp Files: defaultv4iddomain.com. Se si verifica una mancata corrispondenza tra la configurazione del dominio nel client NFS (ovvero la macchina virtuale) e il server NFS (ovvero la configurazione di Azure NetApp Files), le autorizzazioni per i file nei volumi di Azure NetApp Files montati nelle macchine virtuali vengono visualizzate come nessuno.

  3. [A] Modificare /etc/fstab in entrambi i nodi per montare in modo permanente i volumi rilevanti per ogni nodo. Nell'esempio seguente viene illustrato come montare i volumi in modo permanente.

    sudo vi /etc/fstab

    Aggiungere le voci seguenti in /etc/fstab in entrambi i nodi.

    Esempio per hanadb1:

    10.3.1.4:/hanadb1-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb1-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0

    Esempio per hanadb2:

    10.3.1.4:/hanadb2-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb2-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
10.3.1.4:/hanadb2-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0

    Montare tutti i volumi.

    sudo mount -a

    Per i carichi di lavoro che richiedono una velocità effettiva maggiore, è consigliabile usare l'opzione di montaggio nconnect, come descritto in Volumi NFS v4.1 in Azure NetApp Files per SAP HANA. Controllare se nconnect è supportato da Azure NetApp Files nella versione Linux.

  4. [A] Verificare che tutti i volumi HANA siano montati con la versione del protocollo NFS NFSv4.

    sudo nfsstat -m

    Verificare che il flag vers sia impostato su 4.1.

    Esempio di hanadb1:

    /hana/log/HN1/mnt00001 from 10.3.1.4:/hanadb1-log-mnt00001
Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
/hana/data/HN1/mnt00001 from 10.3.1.4:/hanadb1-data-mnt00001
Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
/hana/shared/HN1 from 10.3.1.4:/hanadb1-shared-mnt00001
Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4

  5. [A] Verificare nfs4_disable_idmapping. Il valore deve essere impostato su Y. Per creare la struttura di directory in cui si trova nfs4_disable_idmapping, eseguire il comando mount. Non sarà possibile creare manualmente la directory in /sys/modules, perché l'accesso è riservato per il kernel/driver.

    #Check nfs4_disable_idmapping
sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping

#If you need to set nfs4_disable_idmapping to Y
sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping

#Make the configuration permanent
sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

Installazione di SAP HANA

  1. [T] Configurare la risoluzione dei nomi host per tutti gli host.

    È possibile usare un server DNS o modificare il file /etc/hosts in tutti i nodi. In questo esempio viene illustrato come usare il file /etc/hosts. Sostituire l'indirizzo IP e il nome host nei comandi seguenti:

    sudo vi /etc/hosts

    Inserire le righe seguenti nel file /etc/hosts. Modificare l'indirizzo IP e il nome host in base all'ambiente.

    10.3.0.4   hanadb1
10.3.0.5   hanadb2

  2. [A] Preparare il sistema operativo per l'esecuzione di SAP HANA in Azure NetApp 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.

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

    Aggiungere le voci seguenti nel file di configurazione:

    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

  3. [A] Creare il file di configurazione /etc/sysctl.d/ms-az.conf con altre impostazioni di ottimizzazione.

    sudo vi /etc/sysctl.d/ms-az.conf

    Aggiungere le voci seguenti nel file di configurazione:

    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.

  4. [A] Regolare le impostazioni di sunrpc, come consigliato nella nota SAP 3024346 - Linux Kernel Settings for NetApp NFS.

    sudo vi /etc/modprobe.d/sunrpc.conf

    Inserire la riga seguente:

    options sunrpc tcp_max_slot_table_entries=128

  5. [A] Configurare SLES per HANA.

    Configurare SLES come descritto nelle note SAP seguenti in base alla versione SLES:

  6. [T] Installare SAP HANA.

    A partire da HANA 2.0 SPS 01, l'opzione predefinita è Contenitori di database multi-tenant (MDC). Quando si installa il sistema HANA, SYSTEMDB e un tenant con lo stesso SID vengono creati insieme. In alcuni casi, non si vuole il tenant predefinito. Se non si vuole creare il tenant iniziale insieme all'installazione, seguire le istruzioni riportate nella nota SAP 2629711.

    1. Avviare il programma hdblcm dalla directory del software di installazione di HANA.

      ./hdblcm

    2. Al prompt immettere i valori seguenti:

      • Per Scegli installazione: immettere1 (per l'installazione ).
      • Per Selezionare componenti aggiuntivi per l'installazione: immettere 1.
      • Per Immettere il percorso di installazione [/hana/shared]: premere INVIO per accettare l'impostazione predefinita.
      • Per Immettere il nome host locale [..]: premere INVIO per accettare l'impostazione predefinita.
      • In Aggiungere altri host al sistema? (s/n) [n]: Selezionare n.
      • Per immettere l'ID di sistema SAP HANA: immettere HN1.
      • Per Immettere il numero di istanza [00]: immettere 03.
      • Per Selezionare modalità database/ Immettere indice [1]: premere INVIO per accettare l'impostazione predefinita.
      • Per Selezionare Utilizzo sistema/Immettere indice [4]: immettere 4 (per personalizzato).
      • Per Immettere il percorso dei volumi di dati [/hana/data]: premere INVIO per accettare il valore predefinito.
      • Per Immettere il percorso dei volumi di log [/hana/log]: premere INVIO per accettare l'impostazione predefinita.
      • Per Limitare l'allocazione massima della memoria? [n]: premere INVIO per accettare l'impostazione predefinita.
      • Per Immettere il nome host del certificato per l'host '...' [...]: premere INVIO per accettare l'impostazione predefinita.
      • Per Immettere la password dell'utente dell'agente host SAP (sapadm): immettere la password utente dell'agente host.
      • Per Confermare la password dell'agente host SAP (sapadm): immettere di nuovo la password utente dell'agente host per confermare.
      • Per Immettere la password amministratore di sistema (hn1adm): immettere la password dell'amministratore di sistema.
      • Per Confermare la password dell'amministratore di sistema (hn1adm): immettere di nuovo la password dell'amministratore di sistema per confermare.
      • Per Immettere la home directory amministratore di sistema [/usr/sap/HN1/home]: premere INVIO per accettare il valore predefinito.
      • Per Immettere System Administrator Login Shell [/bin/sh]: premere INVIO per accettare l'impostazione predefinita.
      • Per Immettere l'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 il valore predefinito.
      • Per Immettere la password dell'utente del database (SYSTEM): immettere la password utente del database.
      • Per Confermare password utente database (SYSTEM): immettere di nuovo la password utente del database per confermare.
      • Per Riavviare il sistema dopo il riavvio del computer? [n]: premere INVIO per accettare l'impostazione predefinita.
      • Per Proseguire? (s/n): convalidare il riepilogo. Immettere y per continuare.

  7. [T] Aggiornare l'agente host SAP.

    Scaricare l'archivio dell'agente host SAP più recente dal sito SAP Software Center ed eseguire il comando seguente per aggiornare l'agente. Sostituire il percorso dell'archivio in modo da puntare al file scaricato.

    sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>

Configure SAP HANA system replication (Configurare la replica di sistema SAP HANA)

Seguire la procedura descritta in Replica di sistema SAP HANA per configurare la replica di sistema SAP HANA.

Configurazione del cluster

Questa sezione descrive i passaggi necessari per il funzionamento uniforme del cluster quando SAP HANA è installato nelle condivisioni NFS usando Azure NetApp Files.

Creare un cluster Pacemaker

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

Implementare hook HANA SAPHanaSR e susChkSrv

Questo passaggio importante ottimizza l'integrazione con il cluster e migliora il rilevamento quando è necessario un failover del cluster. È consigliabile configurare sia gli hook PYTHON SAPHanaSR che susChkSrv. Seguire la procedura descritta in Implementare gli hook di replica di sistema SAPHanaSR e susChkSrv.

Configurare le risorse cluster SAP HANA

Questa sezione descrive i passaggi necessari per configurare le risorse del cluster SAP HANA.

Creare le risorse cluster SAP HANA

Seguire la procedura descritta in Creazione di risorse cluster SAP HANA per creare le risorse del cluster per il server HANA. Dopo aver creato le risorse, verrà visualizzato lo stato del cluster con il comando seguente:

sudo crm_mon -r

Output di esempio:

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

Creare risorse del file system

Creare una risorsa cluster fittizia del file system. Monitora e segnala gli errori se si verifica un problema durante l'accesso al file system montato su NFS /hana/shared. Ciò consente al cluster di attivare il failover se si verifica un problema durante l'accesso a /hana/shared. Per altre informazioni, vedere Gestione della condivisione NFS non riuscita nel cluster SUSE a disponibilità elevata per la replica di sistema HANA.

  1. [A] Creare la struttura di directory in entrambi i nodi.

    sudo mkdir -p /hana/shared/HN1/check
sudo mkdir -p /hana/shared/check

  2. [1] Configurare il cluster per aggiungere la struttura di directory per il monitoraggio.

    sudo crm configure primitive rsc_fs_check_HN1_HDB03 Filesystem params \
    device="/hana/shared/HN1/check/" \
    directory="/hana/shared/check/" fstype=nfs  \
    options="bind,defaults,rw,hard,rsize=262144,wsize=262144,proto=tcp,noatime,_netdev,nfsvers=4.1,lock,sec=sys" \
    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

  3. [1] Clonare e controllare il volume appena configurato nel cluster.

    sudo crm configure clone cln_fs_check_HN1_HDB03 rsc_fs_check_HN1_HDB03 meta clone-node-max=1 interleave=true

    Output di esempio:

    sudo crm status

# Cluster Summary:
# Stack: corosync
# Current DC: hanadb1 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
# Last updated: Tue Nov  2 17:57:39 2021
# Last change:  Tue Nov  2 17:57:38 2021 by root via crm_attribute on hanadb1
# 2 nodes configured
# 11 resource instances configured

# Node List:
# Online: [ hanadb1 hanadb2 ]

# Full List of Resources:
# Clone Set: cln_azure-events [rsc_azure-events]:
#  Started: [ hanadb1 hanadb2 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
#  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb1 (Monitoring)
#  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb2 (Monitoring)
# Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
#  rsc_SAPHana_HN1_HDB03     (ocf::suse:SAPHana):     Master hanadb1 (Monitoring)
#  Slaves: [ hanadb2 ]
# Resource Group: g_ip_HN1_HDB03:
#  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
#  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
# rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
# Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
#  Started: [ hanadb1 hanadb2 ]

    L'attributo OCF_CHECK_LEVEL=20 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 potrebbe rimanere montato, nonostante non sia accessibile.

    L'attributo on-fail=fence 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.

Importante

I timeout nella configurazione precedente potrebbero essere necessari per adattarsi alla configurazione specifica di HANA per evitare azioni di isolamento non necessarie. Non impostare i valori di timeout troppo bassi. Tenere presente che il monitoraggio del file system non è correlato alla replica di sistema HANA. Per altre informazioni, vedere la documentazione di SUSE.

Testare la configurazione del cluster

Questa sezione descrive come testare la configurazione.

  1. Prima di avviare un test, assicurarsi che Pacemaker non abbia alcuna azione non riuscita (tramite stato crm) e che non siano previsti vincoli di posizione (ad esempio, a sinistra di un test di migrazione). Assicurarsi anche che la replica di sistema HANA sia in stato di sincronizzazione, ad esempio con systemReplicationStatus.

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

  2. Verificare lo stato delle risorse HANA usando questo comando:

    SAPHanaSR-showAttr

# You should see something like below
# hanadb1:~ SAPHanaSR-showAttr
# Global cib-time                 maintenance
# --------------------------------------------
# global Mon Nov  8 22:50:30 2021 false
# Sites srHook
# -------------
# SITE1 PRIM
# SITE2 SOK
# Site2 SOK
# Hosts   clone_state lpa_hn1_lpt node_state op_mode   remoteHost roles                            score site  srmode sync_state version                vhost
# --------------------------------------------------------------------------------------------------------------------------------------------------------------
# hanadb1 PROMOTED    1636411810  online     logreplay hanadb2    4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.058.00.1634122452 hanadb1
# hanadb2 DEMOTED     30          online     logreplay hanadb1    4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.058.00.1634122452 hanadb2

  3. Verificare la configurazione del cluster per uno scenario di errore quando un nodo viene arrestato. L'esempio seguente mostra l'arresto del nodo 1:

    sudo crm status
sudo crm resource move msl_SAPHana_HN1_HDB03 hanadb2 force
sudo crm resource cleanup

    Output di esempio:

    sudo crm status

#Cluster Summary:
# Stack: corosync
# Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
# Last updated: Mon Nov  8 23:25:36 2021
# Last change:  Mon Nov  8 23:25:19 2021 by root via crm_attribute on hanadb2
# 2 nodes configured
# 11 resource instances configured

# Node List:
# Online: [ hanadb1 hanadb2 ]
# Full List of Resources:
# Clone Set: cln_azure-events [rsc_azure-events]:
#  Started: [ hanadb1 hanadb2 ]
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
#  Started: [ hanadb1 hanadb2 ]
# Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
#  Masters: [ hanadb2 ]
#  Stopped: [ hanadb1 ]
# Resource Group: g_ip_HN1_HDB03:
#  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
#  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
# rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
# Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
#  Started: [ hanadb1 hanadb2 ]

    Arrestare HANA in Node1:

    sudo su - hn1adm
sapcontrol -nr 03 -function StopWait 600 10

    Registrare il nodo 1 come nodo secondario e controllare lo stato:

    hdbnsutil -sr_register --remoteHost=hanadb2 --remoteInstance=03 --replicationMode=sync --name=SITE1 --operationMode=logreplay

    Output di esempio:

    #adding site ...
#nameserver hanadb1:30301 not responding.
#collecting information ...
#updating local ini files ...
#done.

    sudo crm status

    sudo SAPHanaSR-showAttr

  4. 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 nello scenario presentato.

    È difficile simulare un errore, in cui uno dei server perde l'accesso alla condivisione NFS. Come test, è possibile rimontare il file system come di sola lettura. Questo approccio verifica che il cluster possa eseguire il failover se l'accesso a /hana/shared viene perso nel nodo attivo.

    Risultato previsto: durante l'esecuzione di /hana/shared come file system di sola lettura, l'attributo OCF_CHECK_LEVEL della risorsa hana_shared1, che esegue operazioni di lettura/scrittura nel file system, ha esito negativo. L'errore non riesce perché non può scrivere nulla nel file system ed esegue un failover di risorse HANA. Lo stesso risultato è previsto quando il nodo HANA perde l'accesso alle condivisioni NFS.

    Stato delle risorse prima dell'avvio del test:

    sudo crm  status

#Cluster Summary:
 # Stack: corosync
 # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
 # Last updated: Mon Nov  8 23:01:27 2021
 # Last change:  Mon Nov  8 23:00:46 2021 by root via crm_attribute on hanadb1
 # 2 nodes configured
 # 11 resource instances configured

 #Node List:
 # Online: [ hanadb1 hanadb2 ]

 #Full List of Resources:
 # Clone Set: cln_azure-events [rsc_azure-events]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
   # Masters: [ hanadb1 ]
   # Slaves: [ hanadb2 ]
 # Resource Group: g_ip_HN1_HDB03:
   # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
   # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
 # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
 # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]

    È possibile inserire /hana/shared in modalità di sola lettura nel nodo del cluster attivo usando questo comando:

    sudo mount -o ro 10.3.1.4:/hanadb1-shared-mnt00001 /hana/sharedb

    Il server hanadb1 viene riavviato o spento in base al set di azioni. Dopo che il server hanadb1 è inattivo, la risorsa HANA passa a hanadb2. È possibile controllare lo stato del cluster da hanadb2.

    sudo crm status

#Cluster Summary:
 # Stack: corosync
 # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
 # Last updated: Wed Nov 10 22:00:27 2021
 # Last change:  Wed Nov 10 21:59:47 2021 by root via crm_attribute on hanadb2
 # 2 nodes configured
 # 11 resource instances configured

 #Node List:
 # Online: [ hanadb1 hanadb2 ]

 #Full List of Resources:
 # Clone Set: cln_azure-events [rsc_azure-events]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]
 # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
   # Masters: [ hanadb2 ]
   # Stopped: [ hanadb1 ]
 # Resource Group: g_ip_HN1_HDB03:
      # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
   # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
 # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
 # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
   # Started: [ hanadb1 hanadb2 ]

    È consigliabile testare accuratamente la configurazione del cluster SAP HANA eseguendo i test descritti nella replica di sistema SAP HANA.

Passaggi successivi