Disponibilità elevata di SAP HANA con scalabilità orizzontale con Azure NetApp Files in SU edizione Standard 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 (ANF). 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, il significato è il seguente:

  • [A]: 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 nell'ambiente di 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 su SU edizione Standard Enterprise Linux è pubblicata nella guida Configurare la replica di sistema SAP HANA in SLES

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

SAP HANA HA Scale-up on ANF

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 su node1 (hanadb1)

  • 10.3.1.4:/hanadb1-data-mnt00001 su /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 su /hana/data
  • 10.3.1.4:/hanadb2-log-mnt00001 in /hana/log
  • 10.3.1.4:/hanadb2-shared-mnt0001 su /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 HANA a disponibilità elevata sap 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 file di Azure NetApp

Prima di continuare con la configurazione per l'infrastruttura di Azure NetApp Files, acquisire familiarità con la documentazione di Azure NetApp Files. Azure NetApp Files è disponibile in diverse 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 Livello 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 valutare l'uso del gruppo di volumi di applicazioni di Azure NetApp Files per SAP HANA.

Nota

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 e le macchine virtuali di Azure NetApp Files, in cui vengono montate le risorse di Azure NetApp Files, devono essere distribuite nella stessa rete virtuale di Azure o nelle 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 il pool di capacità di Azure NetApp Files seguendo le istruzioni riportate in Configurare un pool di capacità di 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 Premiumdi Azure NetApp Files.

  3. Delegare una subnet ad Azure NetApp Files, come descritto nelle istruzioni riportate in Delegare una subnet ad 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 vengono assegnati automaticamente.

    Tenere presente che le risorse di Azure NetApp Files e le macchine virtuali di Azure devono trovarsi nella stessa rete virtuale di Azure o nelle 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 SU edizione Standard Linux Enterprise Server for SAP Applications 12 o 15 è disponibile in Azure Marketplace. È possibile usare l'immagine per distribuire nuove macchine virtuali.

Distribuire macchine virtuali Linux manualmente tramite il portale di Azure

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

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

Importante

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

Configurare il servizio di bilanciamento del carico di Azure

Durante la configurazione della macchina virtuale, è possibile creare o selezionare l'uscita dal servizio di bilanciamento del carico nella sezione Rete. Seguire questa procedura per configurare il servizio di bilanciamento del carico standard per la configurazione a disponibilità elevata del database HANA.

Seguire la guida alla creazione del servizio di bilanciamento del carico per configurare un servizio di bilanciamento del carico standard per un sistema SAP a disponibilità elevata usando il portale di Azure. Durante la configurazione del servizio di bilanciamento del carico, prendere in considerazione i punti seguenti.

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

Nota

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

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

Importante

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

Nota

Quando le macchine virtuali senza indirizzi IP pubblici vengono inserite nel pool back-end del Load Balancer interno standard di Azure (nessun indirizzo IP pubblico), non vi sarà connettività Internet in uscita, a meno che non venga eseguita una configurazione aggiuntiva per consentire il routing a endpoint pubblici. Per informazioni dettagliate su come ottenere la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali usando Load Balancer Standard di Azure negli scenari a disponibilità elevata SAP.

Importante

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

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 (ad esempio la macchina virtuale) e il server NFS, ad esempio la configurazione di Azure NetApp, le autorizzazioni per i file nei volumi Di Azure NetApp montati nelle macchine virtuali verranno visualizzate come nessuno.

  3. [A] Modificare /etc/fstab in entrambi i nodi per montare in modo permanente i volumi rilevanti per ogni nodo. Di seguito è riportato un esempio di 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 più elevata è consigliabile usare l'opzione nconnect di montaggio, 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 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. 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. Questo esempio mostra 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 - Linux Kernel Impostazioni per NetApp NFS. Creare il file di configurazione /etc/sysctl.d/91-NetApp-HANA.conf per le impostazioni di configurazione di NetApp.

    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 impostazioni di ottimizzazione aggiuntive.

    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 sunrpc, come consigliato nella nota SAP 3024346 - Kernel Linux Impostazioni per NetApp NFS.

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

    Inserire la riga seguente

    options sunrpc tcp_max_slot_table_entries=128

  5. [A] Configurazione di SLES per HANA

    Configurare SLES come descritto nella nota SAP seguente in base alla versione SLES

  6. [T] Installare SAP HANA

    A partire da HANA 2.0 SPS 01, MDC è l'opzione predefinita. Quando si installa il sistema HANA, SYSTEMDB e un tenant con lo stesso SID verranno creati insieme. In alcuni casi, non si vuole che il tenant predefinito. Se non si vuole creare il tenant iniziale insieme all'installazione, è possibile seguire la 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: immettere 1 (per l'installazione)
      • Per Selezionare componenti aggiuntivi per l'installazione: immettere 1.
      • Per Invio percorso di installazione [/hana/shared]: premere INVIO per accettare il valore predefinito
      • Per Immettere il nome host locale [..]: premere INVIO per accettare il valore predefinito
      • In Aggiungere altri host al sistema? (y/n) [n]: n
      • Per Immettere l'ID sistema SAP HANA: immettere HN1.
      • Per Immettere il numero di istanza [00]: immettere 03
      • Per Select Database Mode /Enter Index [1]: premere INVIO per accettare il valore predefinito
      • Per Select System Usage /Enter Index [4]: enter 4 (for custom) (Seleziona utilizzo sistema/Immettere indice [4]: immettere 4 (per personalizzato)
      • Per Enter Location of Data Volumes [/hana/data]: premere INVIO per accettare l'impostazione predefinita
      • Per Enter Location of Log Volumes [/hana/log]: premere INVIO per accettare l'impostazione predefinita
      • Per Limitare l'allocazione massima della memoria? [n]: premere INVIO per accettare il valore predefinito
      • Per Immettere il nome host del certificato per l'host '...' [...]: premere INVIO per accettare il valore predefinito
      • Per Immettere la password dell'utente dell'agente host SAP (sapadm): immettere la password utente dell'agente host
      • Per Confermare la password dell'utente dell'agente host SAP (sapadm): immettere di nuovo la password utente dell'agente host per confermare
      • Per Enter System Amministrazione istrator (hn1adm) Password: immettere la password dell'amministratore di sistema
      • Per Confirm System Amministrazione istrator (hn1adm) Password: immettere di nuovo la password dell'amministratore di sistema per confermare
      • Per Enter System Amministrazione istrator Home Directory [/usr/sap/HN1/home]: premere INVIO per accettare l'impostazione predefinita
      • Per Enter System Amministrazione istrator Login Shell [/bin/sh]: premere INVIO per accettare l'impostazione predefinita
      • Per Enter System Amministrazione istrator User ID [1001]: premere INVIO per accettare l'impostazione predefinita
      • Per ENTER ID of User Group (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 Conferma 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 il valore predefinito
      • Per continuare? (y/n): verificare il riepilogo. Immettere y per continuare

  7. [A] 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 Configurare la 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 facile del cluster quando SAP HANA è installato nelle condivisioni NFS usando Azure NetApp Files.

Creare un cluster Pacemaker

Seguire la procedura descritta in Configurare Pacemaker su SU edizione Standard Enterprise Linux in Azure per creare un cluster Pacemaker di base per questo server HANA.

Implementare hook HANA SAPHanaSR e susChkSrv

Si tratta di un passaggio importante per ottimizzare l'integrazione con il cluster e migliorare il rilevamento, quando è necessario un failover del cluster. È consigliabile configurare sia gli hook PYTHON SAPHanaSR che susChkSrv. Seguire i passaggi indicati in Implementare gli hook sapHanaSR e susChkSrv per la replica di sistema Python

Configurare le risorse del 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 nella 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, che monitora e segnala gli errori, nel caso in cui si verifichi un problema durante l'accesso al file system /hana/sharedmontato da NFS. Ciò consente al cluster di attivare il failover, nel caso in cui si verifichi un problema durante l'accesso a /hana/shared. Per altre informazioni, vedere Gestione della condivisione NFS non riuscita in SU edizione Standard cluster a disponibilità elevata per la replica del 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 ]

    OCF_CHECK_LEVEL=20 l'attributo viene aggiunto all'operazione di monitoraggio, in modo che le operazioni di monitoraggio eseguano un test di lettura/scrittura nel file system. Senza questo attributo, l'operazione di monitoraggio verifica solo che il file system sia montato. Questo può essere un problema perché quando la connettività viene persa, il file system può rimanere montato, nonostante non sia accessibile.

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

Importante

I timeout nella configurazione precedente potrebbero essere necessari per adattarsi all'impostazione 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 informazioni dettagliate, vedere la documentazione su edizione Standard.

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), nessun vincolo di posizione imprevisto (ad esempio i leftover di un test di migrazione) e che la replica del 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 il comando seguente

    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 (di seguito, ad esempio viene mostrato 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. Un test che può essere eseguito consiste nel rimontare il file system come di sola lettura. Questo approccio verifica che il cluster sia in grado di eseguire il failover, se l'accesso a /hana/shared viene perso nel nodo attivo.

    Risultato previsto: in caso /hana/shared di file system di sola lettura, l'attributo OCF_CHECK_LEVEL della risorsa hana_shared1, che esegue un'operazione di lettura/scrittura nel file system avrà esito negativo perché non è in grado di scrivere nulla nel file system e eseguirà il failover delle 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 posizionare /hana/shared in modalità di sola lettura nel nodo del cluster attivo, usando il comando seguente:

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

    hanadb1 riavvierà o si spegnerà in base al set di azioni. Quando 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 anche i test descritti in Replica di sistema SAP HANA.

Passaggi successivi