Disponibilità elevata di SAP HANA in macchine virtuali di Azure su SUSE Linux Enterprise Server

Per lo sviluppo locale, è possibile usare la replica di sistema HANA oppure l'archiviazione condivisa per fornire la disponibilità elevata per SAP HANA. In Macchine virtuali di Azure la replica di sistema HANA in Azure è attualmente l'unica funzione per la disponibilità elevata supportata. La replica SAP HANA è costituita da un nodo primario e da almeno un nodo secondario. Le modifiche ai dati nel nodo primario vengono replicate nel nodo secondario in modo sincrono o asincrono.

Questo articolo descrive come distribuire e configurare le macchine virtuali, installare il framework del cluster, nonché installare e configurare la replica di sistema SAP HANA. Nelle configurazioni di esempio e nei comandi di installazione vengono usati il numero di istanza 03 e l'ID di sistema HANA HN1.

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

  • Nota SAP 1928533, contenente:
    • Elenco delle dimensioni delle macchine virtuali di Azure supportate per la distribuzione di software SAP.
    • Informazioni importanti sulla capacità per le dimensioni delle macchine virtuali di Azure.
    • 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, che elenca i prerequisiti per le distribuzioni di software SAP supportate da SAP in Azure.
  • Nota SAP 2205917 ha consigliato le impostazioni del sistema operativo per SUSE Linux Enterprise Server per le applicazioni SAP.
  • Nota SAP 1944799 include linee guida per SAP HANA per SUSE Linux Enterprise Server for SAP Applications.
  • Nota SAP 2178632, che contiene informazioni dettagliate su tutte le metriche di monitoraggio segnalate per SAP in Azure.
  • La nota SAP 2191498 contiene la versione dell'agente host SAP per Linux necessaria in Azure.
  • La nota SAP 2243692 contiene informazioni sulle licenze SAP in Linux in Azure.
  • La nota SAP 1984787 contiene informazioni generali su SUSE Linux Enterprise Server 12.
  • La nota SAP 1999351 contiene informazioni aggiuntive sulla risoluzione dei problemi per l'estensione di monitoraggio avanzato di Azure per SAP.
  • La nota SAP 401162 contiene informazioni su come evitare l'errore "indirizzo già in uso" quando si configura la replica di sistema HANA.
  • Community WIKI SAP, che contiene tutte le note SAP necessarie per Linux.
  • SAP HANA Certified IaaS Platforms
  • Guida alla pianificazione e all'implementazione di macchine virtuali di Azure per SAP in Linux.
  • Distribuzione di Macchine virtuali di Azure per SAP in Linux (questo articolo).
  • Guida Distribuzione di DBMS in macchine virtuali di Azure per SAP in Linux.
  • Guide alle procedure consigliate per SUSE Linux Enterprise Server for SAP Applications 12 SP3
    • Configurazione di un'infrastruttura ottimizzata per le prestazioni per la replica di sistema SAP HANA (SLES for SAP Applications 12 SP1). La guida contiene tutte le informazioni necessarie per configurare la replica di sistema SAP HANA per lo sviluppo locale. Usare la guida per le indicazioni di base.
    • Configurazione di un'infrastruttura ottimizzata per i costi per la replica di sistema SAP HANA (SLES for SAP Applications 12 SP1)

Panoramica

Per ottenere disponibilità elevata, il sistema SAP HANA viene installato in due macchine virtuali. I dati vengono replicati tramite la replica di sistema HANA.

Panoramica della disponibilità elevata SAP HANA

La procedura di configurazione della replica di sistema SAP HANA usa un nome host virtuale dedicato e indirizzi IP virtuali. Per usare un indirizzo IP virtuale in Azure, occorre il bilanciamento del carico. La configurazione presentata mostra un servizio di bilanciamento del carico con:

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

Eseguire la distribuzione per Linux

L'agente delle risorse per SAP HANA è incluso in SUSE Linux Enterprise Server for SAP Applications. Azure Marketplace contiene un'immagine per SUSE Linux Enterprise Server for SAP Applications 12 che è possibile usare per distribuire nuove macchine virtuali.

Eseguire la distribuzione con un modello

È possibile usare uno dei modelli di avvio rapido di GitHub per distribuire tutte le risorse necessarie. Il modello consente di distribuire le macchine virtuali, il servizio di bilanciamento del carico, il set di disponibilità e così via. Per distribuire il modello, seguire questi passaggi:

  1. Aprire il modello di database o il modello convergente nel portale di Azure. Il modello di database crea le regole di bilanciamento del carico solo per un database. Il modello con convergenza crea anche le regole di bilanciamento del carico per un'istanza di ASCS/SCS ed ERS (solo Linux). Se si prevede di installare un sistema basato su SAP NetWeaver e si vuole installare l'istanza di ASCS/SCS negli stessi computer, usare il modello convergente.

  2. Immettere i parametri seguenti:

    • Sap System ID: Immettere l'ID del sistema SAP che si vuole installare. L'ID viene usato come prefisso per le risorse distribuite.
    • Stack Type (Tipo di stack): (questo parametro è applicabile solo se si usa il modello con convergenza). Selezionare il tipo di stack di SAP NetWeaver.
    • Tipo di sistema operativo: Selezionare una delle distribuzioni Linux. Per questo esempio, selezionare SLES 12.
    • Tipo di database: Selezionare HANA.
    • Sap System Size (Dimensioni sistema SAP): immettere il numero di istanze SAP fornite dal nuovo sistema. Se non si è certi del numero di istanze SAP necessarie per il sistema, chiedere all'integratore di sistemi o al partner tecnologico SAP.
    • Disponibilità del sistema: Selezionare HA.
    • Nome utente amministratore e password amministratore: viene creato un nuovo utente che può essere usato per accedere al computer.
    • New Or Existing Subnet (Subnet nuova o esistente): determina se devono essere create una nuova rete virtuale e una nuova subnet o se deve essere usata una subnet esistente. Se è già disponibile una rete virtuale connessa alla rete locale, selezionare Esistente.
    • ID subnet: Se si vuole distribuire la macchina virtuale in una rete virtuale esistente in cui è stata definita la subnet a cui assegnare la macchina virtuale, specificare l'ID di tale subnet. L'ID è in genere simile a /subscriptions/<subscription ID>/resourceGroups/resource group name>/<providers/Microsoft.Network/virtualNetworks/<virtual network name>/subnets/<subnet name>.

Distribuzione manuale

Importante

Assicurarsi che il sistema operativo selezionato sia dotato di certificazione SAP per SAP HANA sugli specifici tipi di macchina virtuale in uso. L'elenco dei tipi e delle versioni del sistema operativo certificati SAP HANA per tali macchine virtuali può essere cercato in SAP HANA Certified IaaS Platforms. Fare clic su ogni voce presente nell'elenco dei tipi di macchina virtuale per ottenere l'elenco completo delle versioni di sistema operativo supportate da SAP HANA per lo specifico tipo di VM.

  1. Creare un gruppo di risorse.

  2. Creare una rete virtuale.

  3. Creare un set di disponibilità.

    • Impostare il numero massimo di domini di aggiornamento.
  4. Creare un servizio di bilanciamento del carico (interno). Si consiglia di usare Load Balancer Standard. Selezionare la rete virtuale creata nel passaggio 2.

  5. Creare la macchina virtuale 1.

    • Usare un'immagine SLES4SAP nella raccolta di Azure che sia supportata per SAP HANA nel tipo di macchina virtuale selezionato.
    • Selezionare il set di disponibilità creato nel passaggio 3.
  6. Creare la macchina virtuale 2.

    • Usare un'immagine SLES4SAP nella raccolta di Azure che sia supportata per SAP HANA nel tipo di macchina virtuale selezionato.
    • Selezionare il set di disponibilità creato nel passaggio 3.
  7. Aggiungere dischi dati.

    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

    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 sarà presente alcuna 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.

  8. Per configurare il servizio di bilanciamento del carico standard, seguire questa procedura di configurazione:

    1. Prima, creare il pool di indirizzi IP front-end:

      1. Aprire il servizio di bilanciamento del carico, selezionare Pool di indirizzi IP front-end e quindi Aggiungi.
      2. Immettere il nome del nuovo pool di indirizzi IP front-end (ad esempio, hana-frontend).
      3. Impostare Assegnazione su Statico e immettere l'indirizzo IP (ad esempio, 10.0.0.13).
      4. Selezionare OK.
      5. Dopo aver creato il nuovo pool di indirizzi IP front-end, annotare l'indirizzo IP del pool.
    2. Creare quindi un pool back-end:

      1. Aprire il servizio di bilanciamento del carico, selezionare Pool back-end e quindi Aggiungi.
      2. Immettere il nome del nuovo pool back-end (ad esempio, hana-backend).
      3. Selezionare Rete virtuale.
      4. Selezionare Aggiungi una macchina virtuale.
      5. Selezionare **Macchina virtuale**.
      6. Selezionare le macchine virtuali del cluster SAP HANA e il rispettivo indirizzo IP.
      7. Selezionare Aggiungi.
    3. Creare quindi un probe di integrità:

      1. Aprire il servizio di bilanciamento del carico, selezionare Probe integrità e quindi Aggiungi.
      2. Immettere il nome del nuovo probe di integrità (ad esempio, hana-hp).
      3. Selezionare TCP come protocollo e la porta 62503. Lasciare il valore di Intervallo impostato su 5 e il valore di Soglia di non integrità impostato su 2.
      4. Selezionare OK.
    4. Successivamente, creare le regole del servizio di bilanciamento del carico:

      1. Aprire il servizio di bilanciamento del carico, selezionare Regole di bilanciamento del carico e quindi Aggiungi.
      2. Immettere il nome della nuova regola di bilanciamento del carico (ad esempio, hana-lb).
      3. Selezionare l'indirizzo IP front-end, il pool back-end e il probe di integrità creati in precedenza (ad esempio, hana-frontend, hana-backend e hana-hp).
      4. Selezionare Porte a disponibilità elevata.
      5. Assicurarsi di selezionare Abilita l'indirizzo IP mobile.
      6. Selezionare OK.
  9. In alternativa, solo se lo scenario determina l'uso del servizio di bilanciamento del carico di base, seguire invece questi passaggi di configurazione:

    1. Prima, creare il pool di indirizzi IP front-end:

      1. Aprire il servizio di bilanciamento del carico, selezionare Pool di indirizzi IP front-end e quindi Aggiungi.
      2. Immettere il nome del nuovo pool di indirizzi IP front-end (ad esempio, hana-frontend).
      3. Impostare Assegnazione su Statico e immettere l'indirizzo IP (ad esempio, 10.0.0.13).
      4. Selezionare OK.
      5. Dopo aver creato il nuovo pool di indirizzi IP front-end, annotare l'indirizzo IP del pool.
    2. Creare quindi un pool back-end:

      1. Aprire il servizio di bilanciamento del carico, selezionare Pool back-end e quindi Aggiungi.
      2. Immettere il nome del nuovo pool back-end (ad esempio, hana-backend).
      3. Selezionare Aggiungi una macchina virtuale.
      4. Selezionare il set di disponibilità creato nel passaggio 3.
      5. Selezionare le macchine virtuali del cluster SAP HANA.
      6. Selezionare OK.
    3. Creare quindi un probe di integrità:

      1. Aprire il servizio di bilanciamento del carico, selezionare Probe integrità e quindi Aggiungi.
      2. Immettere il nome del nuovo probe di integrità (ad esempio, hana-hp).
      3. Selezionare TCP come protocollo e la porta 62503. Lasciare il valore di Intervallo impostato su 5 e il valore di Soglia di non integrità impostato su 2.
      4. Selezionare OK.
    4. Per SAP HANA 1.0, creare le regole di bilanciamento del carico:

      1. Aprire il servizio di bilanciamento del carico, selezionare Regole di bilanciamento del carico e quindi Aggiungi.
      2. Immettere il nome della nuova regola di bilanciamento del carico (ad esempio, hana-lb-30315).
      3. Selezionare l'indirizzo IP front-end, il pool back-end e il probe di integrità creati in precedenza (ad esempio, hana-frontend).
      4. Lasciare il valore di Protocollo impostato su TCP e immettere la porta 30315.
      5. Aumentare il valore di Timeout di inattività a 30 minuti.
      6. Assicurarsi di selezionare Abilita l'indirizzo IP mobile.
      7. Selezionare OK.
      8. Ripetere questi passaggi per la porta 30317.
    5. Per SAP HANA 2.0, creare le regole di bilanciamento del carico per il database di sistema:

      1. Aprire il servizio di bilanciamento del carico, selezionare Regole di bilanciamento del carico e quindi Aggiungi.
      2. Immettere il nome della nuova regola di bilanciamento del carico (ad esempio, hana-lb-30313).
      3. Selezionare l'indirizzo IP front-end, il pool back-end e il probe di integrità creati in precedenza (ad esempio, hana-frontend).
      4. Lasciare il valore di Protocollo impostato su TCP e immettere la porta 30313.
      5. Aumentare il valore di Timeout di inattività a 30 minuti.
      6. Assicurarsi di selezionare Abilita l'indirizzo IP mobile.
      7. Selezionare OK.
      8. Ripetere questi passaggi per la porta 30314.
    6. Per SAP HANA 2.0, creare prima le regole di bilanciamento del carico per il database tenant:

      1. Aprire il servizio di bilanciamento del carico, selezionare Regole di bilanciamento del carico e quindi Aggiungi.
      2. Immettere il nome della nuova regola di bilanciamento del carico (ad esempio, hana-lb-30340).
      3. Selezionare l'indirizzo IP front-end, il pool back-end e il probe di integrità creati in precedenza (ad esempio, hana-frontend).
      4. Lasciare il valore di Protocollo impostato su TCP e immettere la porta 30340.
      5. Aumentare il valore di Timeout di inattività a 30 minuti.
      6. Assicurarsi di selezionare Abilita l'indirizzo IP mobile.
      7. Selezionare OK.
      8. Ripetere questi passaggi per le porte 30341 e 30342.

    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

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. Vedere anche la nota SAP 2382421.

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. È possibile usare lo stesso cluster Pacemaker per SAP HANA e SAP NetWeaver (A)SCS.

Installare SAP HANA

Per i passaggi in questa sezione vengono usati i prefissi seguenti:

  • [A] : il passaggio si applica a tutti i nodi.
  • [1] : il passaggio si applica solo al nodo 1.
  • [2] : il passaggio si applica solo al nodo 2 del cluster Pacemaker.
  1. [A] Configurare il layout dei dischi: Gestione volumi logici (LVM) .

    È consigliabile usare LVM per i volumi che archiviano file di log e dati. L'esempio seguente presuppone che le macchine virtuali abbiano quattro dischi dati collegati, usati per creare due volumi.

    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  /dev/disk/azure/scsi1/lun3
    

    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
    sudo pvcreate /dev/disk/azure/scsi1/lun3
    

    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
    sudo vgcreate vg_hana_shared_HN1 /dev/disk/azure/scsi1/lun3
    

    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, di log o condiviso. 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 lvcreate -l 100%FREE -n hana_shared vg_hana_shared_HN1
    sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
    sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
    sudo mkfs.xfs /dev/vg_hana_shared_HN1/hana_shared
    

    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
    sudo mkdir -p /hana/shared/HN1
    # Write down the ID of /dev/vg_hana_data_HN1/hana_data, /dev/vg_hana_log_HN1/hana_log, and /dev/vg_hana_shared_HN1/hana_shared
    sudo blkid
    

    Creare voci fstab per i tre volumi logici:

    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
    /dev/disk/by-uuid/<UUID of /dev/mapper/vg_hana_shared_HN1-hana_shared> /hana/shared/HN1 xfs  defaults,nofail  0  2
    

    Montare i nuovi volumi:

    sudo mount -a
    
  2. [A] Configurare il layout dei dischi: Dischi normali.

    Per sistemi demo, è possibile inserire i dati e i file di log HANA in un solo disco. Creare una partizione in /dev/disk/azure/scsi1/lun0 e formattarla con XFS:

    sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0'
    sudo mkfs.xfs /dev/disk/azure/scsi1/lun0-part1
    
    # Write down the ID of /dev/disk/azure/scsi1/lun0-part1
    sudo /sbin/blkid
    sudo vi /etc/fstab
    

    Inserire questa riga nel file /etc/fstab:

    /dev/disk/by-uuid/<UUID> /hana xfs  defaults,nofail  0  2
    

    Creare la directory di destinazione e montare il disco:

    sudo mkdir /hana
    sudo mount -a
    
  3. [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.0.0.5 hn1-db-0
    10.0.0.6 hn1-db-1
    
  4. [A] Installare i pacchetti di disponibilità elevata SAP HANA:

    sudo zypper install SAPHanaSR
    

Per installare la replica di sistema SAP HANA, seguire il capitolo 4 della guida SAP HANA SR Performance Optimized Scenario (Scenario di ottimizzazione delle prestazioni della replica di sistema SAP HANA).

  1. [T] Eseguire il programma hdblcm dal DVD di HANA. Immettere i valori seguenti al prompt:

    • Scegliere l'installazione: Immettere 1.
    • Selezionare i componenti aggiuntivi per l'installazione: Immettere 1.
    • Immettere il percorso di installazione [/hana/shared]: Selezionare Invio.
    • Immettere il nome host locale [..]: Selezionare Invio.
    • Aggiungere altri host al sistema? (y/n) [n]: Selezionare Invio.
    • Immettere l'ID di sistema SAP HANA: Immettere il SID di HANA, ad esempio: HN1.
    • Immettere il numero di istanza [00]: Immettere il numero di istanza di HANA. Immettere 03 se è stato usato il modello di Azure o se è stata seguita la sezione di questo articolo relativa alla distribuzione manuale.
    • Selezionare la modalità di database/immettere l'indice [1]: Selezionare Invio.
    • Selezionare l'utilizzo del sistema/immettere l'indice [4]: Selezionare il valore di utilizzo del sistema.
    • Immettere il percorso dei volumi di dati [/hana/data/HN1]: Selezionare Invio.
    • Immettere il percorso dei volumi di log [/hana/log/HN1]: Selezionare Invio.
    • Limitare l'allocazione massima della memoria? [n]: Selezionare Invio.
    • Immettere il nome host del certificato per l'host '...' [...]: Selezionare Invio.
    • Immettere la password dell'utente agente host SAP (sapadm): Immettere la password utente dell'agente host.
    • Confermare la password dell'utente agente host SAP (sapadm): Immettere nuovamente la password utente dell'agente host per confermarla.
    • Immettere la password dell'amministratore di sistema (hdbadm): Immettere la password amministratore di sistema.
    • Confermare la password dell'amministratore di sistema (hdbadm): Immettere nuovamente la password dell'amministratore di sistema per confermarla.
    • Immettere la home directory dell'amministratore di sistema [/usr/sap/HN1/home]: Selezionare Invio.
    • Immettere la shell di accesso dell'amministratore di sistema [/bin/sh]: Selezionare Invio.
    • Immettere l'ID utente dell'amministratore di sistema [1001]: Selezionare Invio.
    • Immettere l'ID del gruppo di utenti (sapsys) [79]: Selezionare Invio.
    • Immettere la password dell'utente del database (SYSTEM): Immettere la password utente del database.
    • Confermare la password dell'utente del database (SYSTEM): Immettere nuovamente la password utente del database per confermarla.
    • Riavviare il sistema dopo il riavvio della macchina? [n]: Selezionare Invio.
    • Continuare? (y/n): Convalidare il riepilogo. Immettere y per continuare.
  2. [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>
    

Configurare la replica di sistema di SAP HANA 2.0

Per i passaggi in questa sezione vengono usati i prefissi seguenti:

  • [A] : il passaggio si applica a tutti i nodi.
  • [1] : il passaggio si applica solo al nodo 1.
  • [2] : il passaggio si applica solo al nodo 2 del cluster Pacemaker.
  1. [1] Creare il database tenant.

    Se si usa SAP HANA 2.0 o MDC, creare un database tenant per il sistema SAP NetWeaver. Sostituire NW1 con il SID del sistema SAP.

    Eseguire il comando seguente come <adm hanasid>:

    hdbsql -u SYSTEM -p "passwd" -i 03 -d SYSTEMDB 'CREATE DATABASE NW1 SYSTEM USER PASSWORD "passwd"'
    
  2. [1] Configurare la replica di sistema nel primo nodo:

    Eseguire il backup dei database come <adm hanasid>:

    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')"
    hdbsql -d NW1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupNW1')"
    

    Copiare i file PKI di sistema nel sito secondario:

    scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT   hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
    scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hn1-db-1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/
    

    Creare il sito primario:

    hdbnsutil -sr_enable --name=SITE1
    
  3. [2] Configurare la replica di sistema nel secondo nodo:

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

    sapcontrol -nr 03 -function StopWait 600 10
    hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 
    

Configurare la replica di sistema di SAP HANA 1.0

Per i passaggi in questa sezione vengono usati i prefissi seguenti:

  • [A] : il passaggio si applica a tutti i nodi.
  • [1] : il passaggio si applica solo al nodo 1.
  • [2] : il passaggio si applica solo al nodo 2 del cluster Pacemaker.
  1. [1] Creare gli utenti richiesti.

    Eseguire il comando indicato di seguito come utente ROOT. Assicurarsi di sostituire le stringhe in grassetto (ID di sistema HANA HN1 e numero di istanza 03) con i valori dell'installazione di SAP HANA in uso:

    PATH="$PATH:/usr/sap/HN1/HDB03/exe"
    hdbsql -u system -i 03 'CREATE USER hdbhasync PASSWORD "passwd"'
    hdbsql -u system -i 03 'GRANT DATA ADMIN TO hdbhasync'
    hdbsql -u system -i 03 'ALTER USER hdbhasync DISABLE PASSWORD LIFETIME'
    
  2. [T] Creare una voce di archivio chiavi.

    Eseguire il comando seguente come utente ROOT per creare una nuova voce di archivio chiavi:

    PATH="$PATH:/usr/sap/HN1/HDB03/exe"
    hdbuserstore SET hdbhaloc localhost:30315 hdbhasync passwd
    
  3. [1] Eseguire il backup del database.

    Eseguire il backup dei database come utente ROOT:

    PATH="$PATH:/usr/sap/HN1/HDB03/exe"
    hdbsql -d SYSTEMDB -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"
    

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

    hdbsql -d HN1 -u system -i 03 "BACKUP DATA USING FILE ('initialbackup')"
    
  4. [1] Configurare la replica di sistema nel primo nodo.

    Creare il sito primario come <adm hanasid>:

    su - hdbadm
    hdbnsutil -sr_enable –-name=SITE1
    
  5. [2] Configurare la replica di sistema nel nodo secondario.

    Registrare il sito secondario come <adm hanasid>:

    sapcontrol -nr 03 -function StopWait 600 10
    hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 
    

Implementare hook HANA SAPHanaSR e susChkSrv

Questo è un passaggio importante per ottimizzare l'integrazione con il cluster e migliorare il rilevamento quando è necessario un failover del cluster. È consigliabile configurare l'hook Python SAPHanaSR. Per HANA 2.0 SP5 e versioni successive, è consigliabile implementare SAPHanaSR insieme all'hook susChkSrv.

SusChkSrv estende la funzionalità del provider SAPHanaSR HA principale. Agisce nella situazione in cui si arresta l'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 è reattivo.

Con susChkSrv implementato, viene eseguita un'azione immediata e configurabile, che attiva un failover nel periodo di timeout configurato, anziché attendere il processo hdbindexserver per riavviare lo stesso nodo.

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

    Suggerimento

    L'hook Python SAPHanaSR può essere implementato solo per HANA 2.0. Il pacchetto SAPHanaSR deve essere almeno la versione 0.153.
    l'hook python susChkSrv richiede l'installazione di SAP HANA 2.0 SP5 e SAPHanaSR versione 0.161.1_BF o versione successiva.

    1. Arrestare HANA in entrambi i nodi. Eseguire come <sid>adm:
    sapcontrol -nr 03 -function StopSystem
    
    1. Regolare global.ini in ogni nodo del cluster. Se i requisiti per l'hook susChkSrv non sono soddisfatti, rimuovere l'intero blocco [ha_dr_provider_suschksrv] dai parametri seguenti.
      È possibile modificare il comportamento di susChkSrv con il parametro action_on_lost.
      I valori validi sono [ ignore | stop | kill | fence ].
    # add to global.ini
    [ha_dr_provider_SAPHanaSR]
    provider = SAPHanaSR
    path = /usr/share/SAPHanaSR
    execution_order = 1
    
    [ha_dr_provider_suschksrv]
    provider = susChkSrv
    path = /usr/share/SAPHanaSR
    execution_order = 3
    action_on_lost = fence
    
    [trace]
    ha_dr_saphanasr = info
    

La configurazione che punta alla posizione standard /usr/share/SAPHanaSR offre un vantaggio, che il codice hook Python viene aggiornato automaticamente tramite gli aggiornamenti del sistema operativo o del pacchetto e viene usato da HANA al riavvio successivo. Con un percorso personalizzato facoltativo, ad esempio /hana/shared/myHooks, è possibile separare gli aggiornamenti del sistema operativo con la versione hook usata.

  1. [A] Il cluster richiede la configurazione sudoers in ogni nodo del cluster per <sid>adm. In questo esempio ottenuto creando un nuovo file. Eseguire il comando come root e adattare i valori in grassetto di hn1/HN1 con SID corretto.
    
     cat << EOF > /etc/sudoers.d/20-saphana
     # Needed for SAPHanaSR and susChkSrv Python hooks
     hn1adm ALL=(ALL) NOPASSWD: /usr/sbin/crm_attribute -n hana_hn1_site_srHook_*
     hniadm ALL=(ALL) NOPASSWD: /usr/sbin/SAPHanaSR-hookHelper --sid=HN1 --case=fenceMe
     EOF
     

Per altre informazioni sull'implementazione dell'hook di replica di sistema SAP HANA, vedere Configurare i provider HANA HA/DR.

  1. [A] Avviare SAP HANA in entrambi i nodi. Eseguire come <sid>adm.

    sapcontrol -nr 03 -function StartSystem 
    
  2. [1] Verificare l'installazione dell'hook. Eseguire come <sid>adm nel sito di replica di sistema HANA attivo.

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

    Verificare l'installazione dell'hook susChkSrv. Eseguire come <sid>adm in tutte le macchine virtuali HANA

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

Creare le risorse cluster SAP HANA

Prima di tutto, creare la topologia HANA. Eseguire i comandi seguenti in uno dei nodi del cluster Pacemaker:

sudo crm configure property maintenance-mode=true

# Replace the bold string with your instance number and HANA system ID

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

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

Creare quindi le risorse HANA:

Importante

Sono state rilevate situazioni di test recenti, in cui netcat smette di rispondere alle richieste dovute al backlog e alla limitazione della gestione di una sola connessione. La risorsa netcat smette di essere in ascolto delle richieste del servizio di bilanciamento del carico di Azure e l'IP mobile diventa non disponibile.
Per i cluster Pacemaker esistenti, in passato era consigliabile sostituire netcat con socat. Attualmente è consigliabile usare l'agente di risorse azure-lb, che fa parte degli agenti di risorse del pacchetto, con i requisiti di versione del pacchetto seguenti:

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

Si noti che la modifica richiederà un breve tempo di inattività.
Per i cluster Pacemaker esistenti, se la configurazione è stata già modificata per usare socat, come descritto in Azure Load-Balancer Detection Hardening (Protezione avanzata dei rilevamenti del servizio di bilanciamento del carico di Azure), non è necessario passare immediatamente all'agente delle risorse azure-lb.

Nota

Questo articolo contiene riferimenti ai termini master e slave, termini che Microsoft non usa più. Quando queste condizioni vengono rimosse dal software, verranno rimosse da questo articolo.

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

sudo crm configure primitive rsc_SAPHana_HN1_HDB03 ocf:suse:SAPHana \
  operations \$id="rsc_sap_HN1_HDB03-operations" \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="3600" \
  op monitor interval="60" role="Master" timeout="700" \
  op monitor interval="61" role="Slave" timeout="700" \
  params SID="HN1" InstanceNumber="03" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false"

sudo crm configure ms msl_SAPHana_HN1_HDB03 rsc_SAPHana_HN1_HDB03 \
  meta notify="true" clone-max="2" clone-node-max="1" \
  target-role="Started" interleave="true"

sudo crm configure primitive rsc_ip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
  meta target-role="Started" \
  operations \$id="rsc_ip_HN1_HDB03-operations" \
  op monitor interval="10s" timeout="20s" \
  params ip="10.0.0.13"

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

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
  msl_SAPHana_HN1_HDB03:Master  

sudo crm configure order ord_SAPHana_HN1_HDB03 Optional: cln_SAPHanaTopology_HN1_HDB03 \
  msl_SAPHana_HN1_HDB03

# Clean up the HANA resources. The HANA resources might have failed because of a known issue.
sudo crm resource cleanup rsc_SAPHana_HN1_HDB03

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

Importante

È consigliabile impostare solo AUTOMATED_REGISTER su no, mentre si eseguono test di failover completi, per evitare che l'istanza primaria non sia riuscita per la registrazione automatica come secondaria. Dopo aver completato correttamente i test di failover, impostare AUTOMATED_REGISTER su , in modo che dopo la replica del sistema di acquisizione possa riprendere automaticamente.

Assicurarsi che lo stato del cluster sia corretto e che tutte le risorse siano avviate. Non è importante il nodo su cui sono in esecuzione le risorse.

sudo crm_mon -r

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

Configurare la replica di sistema attiva/di lettura HANA nel cluster Pacemaker

A partire da SAP HANA 2.0 SPS 01 SAP consente l'installazione attiva/abilitata per la lettura per la replica di sistema SAP HANA, in cui i sistemi secondari della replica di sistema SAP HANA possono essere usati attivamente per carichi di lavoro con intensa attività di lettura. Per supportare tale configurazione in un cluster è necessario un secondo indirizzo IP virtuale che consente ai client di accedere al database SAP HANA abilitato per la lettura secondario. Per assicurarsi che il sito di replica secondaria sia ancora accessibile dopo che si è verificato un acquisizione, il cluster deve spostare l'indirizzo IP virtuale con il database secondario della risorsa SAPHana.

Questa sezione descrive i passaggi aggiuntivi necessari per gestire la replica di sistema abilitata per la lettura/active-read di HANA in un cluster a disponibilità elevata SUSE con il secondo indirizzo IP virtuale.
Prima di procedere, assicurarsi di aver configurato completamente il cluster a disponibilità elevata SUSE che gestisce il database SAP HANA, come descritto nei segmenti precedenti della documentazione.

Disponibilità elevata di SAP HANA con replica secondaria abilitata per la lettura

Configurazione aggiuntiva nel servizio di bilanciamento del carico di Azure per l'installazione attiva/abilitata per la lettura

Per procedere con passaggi aggiuntivi sul provisioning di un secondo indirizzo IP virtuale, assicurarsi di aver configurato Azure Load Balancer come descritto nella sezione Distribuzione manuale.

  1. Per il servizio di bilanciamento del carico standard , seguire i passaggi aggiuntivi seguenti sullo stesso servizio di bilanciamento del carico creato in precedenza.

    a. Creare un secondo pool di indirizzi IP front-end:

    • Aprire il servizio di bilanciamento del carico, selezionare Pool di indirizzi IP front-end e quindi Aggiungi.
    • Immettere il nome del secondo pool di indirizzi IP front-end, ad esempio hana-secondaryIP.
    • Impostare Assegnazione su Statico e immettere l'indirizzo IP, ad esempio 10.0.0.14.
    • Selezionare OK.
    • Dopo aver creato il nuovo pool di indirizzi IP front-end, prendere nota dell'indirizzo IP front-end.

    b. Creare quindi un probe di integrità:

    • Aprire il servizio di bilanciamento del carico, selezionare Probe integrità e quindi Aggiungi.
    • Immettere il nome del nuovo probe di integrità, ad esempio hana-secondaryhp.
    • Selezionare TCP come protocollo e porta 62603. Lasciare il valore di Intervallo impostato su 5 e il valore di Soglia di non integrità impostato su 2.
    • Selezionare OK.

    c. Successivamente, creare le regole del servizio di bilanciamento del carico:

    • Aprire il servizio di bilanciamento del carico, selezionare Regole di bilanciamento del carico e quindi Aggiungi.
    • Immettere il nome della nuova regola di bilanciamento del carico, ad esempio hana-secondarylb.
    • Selezionare l'indirizzo IP front-end , il pool back-end e il probe di integrità creato in precedenza, ad esempio hana-secondaryIP, hana-backend e hana-secondaryhp.
    • Selezionare Porte a disponibilità elevata.
    • Aumentare il valore di Timeout di inattività a 30 minuti.
    • Assicurarsi di selezionare Abilita l'indirizzo IP mobile.
    • Selezionare OK.

Configurare la replica di sistema attiva/lettura haNA abilitata

I passaggi per configurare la replica di sistema HANA sono descritti nella sezione Configurare la replica di sistema di SAP HANA 2.0 . Se si distribuisce uno scenario secondario abilitato per la lettura, durante la configurazione della replica di sistema nel secondo nodo, eseguire il comando seguente come hanasidadm:

sapcontrol -nr 03 -function StopWait 600 10 

hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2 --operationMode=logreplay_readaccess 

Aggiunta di una risorsa indirizzo IP virtuale secondario per un'installazione attiva/abilitata per la lettura

Il secondo indirizzo IP virtuale e il vincolo di corilevazione appropriato possono essere configurati con i comandi seguenti:

crm configure property maintenance-mode=true

crm configure primitive rsc_secip_HN1_HDB03 ocf:heartbeat:IPaddr2 \
 meta target-role="Started" \
 operations \$id="rsc_secip_HN1_HDB03-operations" \
 op monitor interval="10s" timeout="20s" \
 params ip="10.0.0.14"

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

crm configure group g_secip_HN1_HDB03 rsc_secip_HN1_HDB03 rsc_secnc_HN1_HDB03

crm configure colocation col_saphana_secip_HN1_HDB03 4000: g_secip_HN1_HDB03:Started \
 msl_SAPHana_HN1_HDB03:Slave 

crm configure property maintenance-mode=false

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

sudo crm_mon -r

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

Nella sezione successiva è possibile trovare il set tipico di test di failover da eseguire.

Tenere presente il secondo comportamento ip virtuale durante il test di un cluster HANA configurato con secondario abilitato per la lettura:

  1. Quando si esegue la migrazione di SAPHana_HN1_HDB03 risorsa cluster a hn1-db-1, il secondo indirizzo IP virtuale passerà all'altro server hn1-db-0. Se è stata configurata AUTOMATED_REGISTER="false" e la replica di sistema HANA non viene registrata automaticamente, il secondo indirizzo IP virtuale verrà eseguito in hn1-db-0, perché il server è disponibile e i servizi cluster sono online.

  2. Durante il test di un arresto anomalo del server, le seconde risorse IP virtuali (rsc_secip_HN1_HDB03) e la risorsa porta del servizio di bilanciamento del carico di Azure (rsc_secnc_HN1_HDB03) verranno eseguite nel server primario insieme alle risorse IP virtuali primarie. Mentre il server secondario è inattivo, le applicazioni connesse al database HANA abilitato per la lettura si connetteranno al database HANA primario. Il comportamento è previsto perché non si vuole che le applicazioni connesse al database HANA abilitato per la lettura siano inaccessibili mentre il server secondario non è disponibile.

  3. Quando il server secondario è disponibile e i servizi cluster sono online, il secondo indirizzo IP virtuale e le risorse della porta verranno spostate automaticamente nel server secondario, anche se la replica di sistema HANA potrebbe non essere registrata come secondaria. È necessario assicurarsi di registrare il database HANA secondario come letto abilitato prima di avviare i servizi cluster in tale server. È possibile configurare la risorsa cluster dell'istanza di HANA per registrare automaticamente il database secondario impostando il parametro AUTOMATED_REGISTER=true.

  4. Durante il failover e il fallback, le connessioni esistenti per le applicazioni, usando il secondo indirizzo IP virtuale per connettersi al database HANA possono essere interrotte.

Testare la configurazione del cluster

Questa sezione descrive come testare la configurazione. Ogni test presuppone che si usi l'account utente ROOT e che il master SAP HANA sia in esecuzione nella macchina virtuale hn1-db-0.

Test della migrazione

Prima di iniziare il test, assicurarsi che in Pacemaker non vi siano azioni non riuscite (tramite crm_mon - r), non siano presenti vincoli di posizione imprevisti (ad esempio rimasti da un test di migrazione precedente) e che HANA si trovi nello stato di sincronizzazione, ad esempio con SAPHanaSR-showAttr:

hn1-db-0:~ # SAPHanaSR-showAttr
Sites    srHook
----------------
SITE2    SOK

Global cib-time
--------------------------------
global Mon Aug 13 11:26:04 2018

Hosts    clone_state lpa_hn1_lpt node_state op_mode   remoteHost    roles                            score site  srmode sync_state version                vhost
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
hn1-db-0 PROMOTED    1534159564  online     logreplay nws-hana-vm-1 4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.030.00.1522209842 nws-hana-vm-0
hn1-db-1 DEMOTED     30          online     logreplay nws-hana-vm-0 4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.030.00.1522209842 nws-hana-vm-1

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

crm resource move msl_SAPHana_HN1_HDB03 hn1-db-1 force

Se si imposta AUTOMATED_REGISTER="false", questa sequenza di comandi esegue la migrazione del nodo master SAP HANA e del gruppo contenente l'indirizzo IP virtuale a hn1-db-1.

Al termine della migrazione, l'output di crm_mon -r è simile al seguente

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

Full list of resources:

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

Failed Actions:
* rsc_SAPHana_HN1_HDB03_start_0 on hn1-db-0 'not running' (7): call=84, status=complete, exitreason='none',
    last-rc-change='Mon Aug 13 11:31:37 2018', queued=0ms, exec=2095ms

La risorsa SAP HANA in hn1-db-0 non viene avviata come secondaria. In questo caso, configurare l'istanza di HANA come secondaria eseguendo questo comando:

su - hn1adm

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

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

# Switch back to root and clean up the failed state
exit
hn1-db-0:~ # crm resource clear msl_SAPHana_HN1_HDB03

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

hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0

Monitorare lo stato della risorsa HANA usando crm_mon -r. Dopo l'avvio di HANA in hn1-db-0, l'output dovrebbe essere simile al seguente

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

Full list of resources:

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

Testare l'agente di isolamento di Azure (non SBD)

È possibile testare la configurazione dell'agente di isolamento di Azure disabilitando l'interfaccia di rete nel nodo hn1-db-0:

sudo ifdown eth0

La macchina virtuale dovrebbe ora venire riavviata o arrestata, a seconda della configurazione del cluster. Se si imposta stonith-action su off, la macchina virtuale viene arrestata e viene eseguita la migrazione delle risorse alla macchina virtuale in esecuzione.

Una volta riavviata la macchina virtuale, la risorsa SAP HANA non viene avviata come secondaria se si imposta AUTOMATED_REGISTER="false". In questo caso, configurare l'istanza di HANA come secondaria eseguendo questo comando:

su - hn1adm

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

# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0

Testare l'isolamento SBD

È possibile testare la configurazione di SBD terminando il processo inquisitor.

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

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

Il nodo del cluster hn1-db-0 deve essere riavviato. In seguito, il servizio Pacemaker potrebbe non venire avviato. Assicurarsi di riavviarlo.

Testare un failover manuale

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

service pacemaker stop

Dopo il failover, è possibile avviare nuovamente il servizio. Se si imposta AUTOMATED_REGISTER="false", la risorsa SAP HANA nel nodo hn1-db-0 non viene avviata come secondaria. In questo caso, configurare l'istanza di HANA come secondaria eseguendo questo comando:

service pacemaker start
su - hn1adm

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

# Switch back to root and clean up the failed state
exit
crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0

Test SUSE

Importante

Assicurarsi che il sistema operativo selezionato sia dotato di certificazione SAP per SAP HANA sugli specifici tipi di macchina virtuale in uso. L'elenco dei tipi di macchina virtuale certificati SAP HANA e delle versioni del sistema operativo per tali versioni può essere ricercato nelle piattaforme IaaS certificati SAP HANA. Fare clic su ogni voce presente nell'elenco dei tipi di macchina virtuale per ottenere l'elenco completo delle versioni di sistema operativo supportate da SAP HANA per lo specifico tipo di VM.

Eseguire tutti i test case elencati nella guida allo scenario di ottimizzazione delle prestazioni della replica di sistema SAP HANA o dello scenario di ottimizzazione dei costi della replica di sistema SAP HANA, a seconda del caso d'uso. Le guide sono disponibili nella pagina di procedure consigliate per SLES per SAP.

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

Nelle descrizioni dei test seguenti si presuppone che PREFER_SITE_TAKEOVER="true" e AUTOMATED_REGISTER="false". NOTA: i test seguenti sono progettati per essere eseguiti in sequenza e dipendono dal risultato dei test precedenti.

  1. TEST 1: ARRESTARE IL DATABASE PRIMARIO NEL NODO 1

    Stato delle risorse prima dell'avvio del test:

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

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

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

    Pacemaker rileva l'istanza HANA arrestata ed esegue il failover nell'altro nodo. Una volta completato il failover, l'istanza HANA nel nodo hn1-db-0 viene arrestata perché Pacemaker non registra automaticamente il nodo come nodo secondario HANA.

    Eseguire i comandi seguenti per registrare il nodo hn1-db-0 come secondario e pulire la risorsa per la quale si è verificato un errore.

    hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1
    
    # run as root
    hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0
    

    Stato delle risorse dopo il test:

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-1 ]
       Slaves: [ hn1-db-0 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
    
  2. TEST 2: ARRESTARE IL DATABASE PRIMARIO NEL NODO 2

    Stato delle risorse prima dell'avvio del test:

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

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

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

    Pacemaker rileva l'istanza HANA arrestata ed esegue il failover nell'altro nodo. Una volta completato il failover, l'istanza HANA nel nodo hn1-db-1 viene arrestata perché Pacemaker non registra automaticamente il nodo come nodo secondario HANA.

    Eseguire i comandi seguenti per registrare il nodo hn1-db-1 come secondario e pulire la risorsa per la quale si è verificato un errore.

    hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
    
    # run as root
    hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1
    

    Stato delle risorse dopo il test:

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-0 ]
       Slaves: [ hn1-db-1 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
    
  3. TEST 3: PROVOCARE UN ARRESTO ANOMALO DEL DATABASE PRIMARIO NEL NODO

    Stato delle risorse prima dell'avvio del test:

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

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

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

    Pacemaker rileva l'istanza HANA terminata ed esegue il failover nell'altro nodo. Una volta completato il failover, l'istanza HANA nel nodo hn1-db-0 viene arrestata perché Pacemaker non registra automaticamente il nodo come nodo secondario HANA.

    Eseguire i comandi seguenti per registrare il nodo hn1-db-0 come secondario e pulire la risorsa per la quale si è verificato un errore.

    hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1
    
    # run as root
    hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0
    

    Stato delle risorse dopo il test:

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-1 ]
       Slaves: [ hn1-db-0 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
    
  4. TEST 4: PROVOCARE UN ARRESTO ANOMALO DEL DATABASE PRIMARIO NEL NODO 2

    Stato delle risorse prima dell'avvio del test:

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

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

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

    Pacemaker rileva l'istanza HANA terminata ed esegue il failover nell'altro nodo. Una volta completato il failover, l'istanza HANA nel nodo hn1-db-1 viene arrestata perché Pacemaker non registra automaticamente il nodo come nodo secondario HANA.

    Eseguire i comandi seguenti per registrare il nodo hn1-db-1 come secondario e pulire la risorsa per la quale si è verificato un errore.

    hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
    
    # run as root
    hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1
    

    Stato delle risorse dopo il test:

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-0 ]
       Slaves: [ hn1-db-1 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
    
  5. TEST 5: PROVOCARE UN ARRESTO ANOMALO DEL NODO DEL SITO PRIMARIO (NODO 1)

    Stato delle risorse prima dell'avvio del test:

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

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

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

    Pacemaker rileva il nodo del cluster terminato e isola il nodo. Una volta isolato il nodo, Pacemaker attiva un'operazione di acquisizione dell'istanza HANA. Quando il nodo isolato viene riavviato, Pacemaker non si avvia automaticamente.

    Eseguire i comandi seguenti per avviare Pacemaker, pulire i messaggi SBD per il nodo hn1-db-0, registrare il nodo hn1-db-0 come secondario e pulire la risorsa per la quale si è verificato un errore.

    # run as root
    # list the SBD device(s)
    hn1-db-0:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
    # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
    
    hn1-db-0:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-0 clear
    
    hn1-db-0:~ # systemctl start pacemaker
    
    # run as <hanasid>adm
    hn1adm@hn1-db-0:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-1 --remoteInstance=03 --replicationMode=sync --name=SITE1
    
    # run as root
    hn1-db-0:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-0
    

    Stato delle risorse dopo il test:

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-1 ]
       Slaves: [ hn1-db-0 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-1
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-1
    
  6. TEST 6: PROVOCARE UN ARRESTO ANOMALO DEL NODO DEL SITO SECONDARIO (NODO 2)

    Stato delle risorse prima dell'avvio del test:

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

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

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

    Pacemaker rileva il nodo del cluster terminato e isola il nodo. Una volta isolato il nodo, Pacemaker attiva un'operazione di acquisizione dell'istanza HANA. Quando il nodo isolato viene riavviato, Pacemaker non si avvia automaticamente.

    Eseguire i comandi seguenti per avviare Pacemaker, pulire i messaggi SBD per il nodo hn1-db-1, registrare il nodo hn1-db-1 come secondario e pulire la risorsa per la quale si è verificato un errore.

    # run as root
    # list the SBD device(s)
    hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
    # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
    
    hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear
    
    hn1-db-1:~ # systemctl start pacemaker
    
    # run as <hanasid>adm
    hn1adm@hn1-db-1:/usr/sap/HN1/HDB03> hdbnsutil -sr_register --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=sync --name=SITE2
    
    # run as root
    hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1
    

    Stato delle risorse dopo il test:

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-0 ]
       Slaves: [ hn1-db-1 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
    
  7. TEST 7: ARRESTARE IL DATABASE SECONDARIO NEL NODO 2

    Stato delle risorse prima dell'avvio del test:

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

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

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

    Pacemaker rileva l'istanza HANA arrestata e contrassegna la risorsa come in errore nel nodo hn1-db-1. Pacemaker dovrebbe riavviare automaticamente l'istanza HANA. Eseguire il comando seguente per pulire lo stato di errore.

    # run as root
    hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1
    

    Stato delle risorse dopo il test:

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-0 ]
       Slaves: [ hn1-db-1 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
    
  8. TEST 8: PROVOCARE UN ARRESTO ANOMALO DEL DATABASE SECONDARIO NEL NODO 2

    Stato delle risorse prima dell'avvio del test:

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

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

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

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

    # run as root
    hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1
    

    Stato delle risorse dopo il test:

    Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
       Started: [ hn1-db-0 hn1-db-1 ]
    Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
       Masters: [ hn1-db-0 ]
       Slaves: [ hn1-db-1 ]
    Resource Group: g_ip_HN1_HDB03
       rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
       rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0
    
  9. TEST 9: PROVOCARE UN ARRESTO ANOMALO DEL NODO DEL SITO SECONDARIO (NODO 2) CHE ESEGUE IL DATABASE HANA SECONDARIO

    Stato delle risorse prima dell'avvio del test:

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

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

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

    Pacemaker rileva il nodo del cluster terminato e isola il nodo. Quando il nodo isolato viene riavviato, Pacemaker non si avvia automaticamente.

    Eseguire i comandi seguenti per avviare Pacemaker, pulire i messaggi SBD per il nodo hn1-db-1 e pulire la risorsa per la quale si è verificato un errore.

    # run as root
    # list the SBD device(s)
    hn1-db-1:~ # cat /etc/sysconfig/sbd | grep SBD_DEVICE=
    # SBD_DEVICE="/dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116;/dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1;/dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3"
    
    hn1-db-1:~ # sbd -d /dev/disk/by-id/scsi-36001405772fe8401e6240c985857e116 -d /dev/disk/by-id/scsi-36001405034a84428af24ddd8c3a3e9e1 -d /dev/disk/by-id/scsi-36001405cdd5ac8d40e548449318510c3 message hn1-db-1 clear
    
    hn1-db-1:~ # systemctl start pacemaker  
    
    hn1-db-1:~ # crm resource cleanup msl_SAPHana_HN1_HDB03 hn1-db-1
    

    Stato delle risorse dopo il test:

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

Passaggi successivi