Disponibilità elevata di IBM Db2 LUW in macchine virtuali di Azure su SU edizione Standard Linux Enterprise Server con Pacemaker
IBM Db2 per Linux, UNIX e Windows (LUW) nella configurazione di disponibilità elevata e ripristino di emergenza è costituito da un nodo che esegue un'istanza del database primario e almeno un nodo che esegue un'istanza di database secondaria. Le modifiche apportate all'istanza del database primario vengono replicate in un'istanza del database secondaria in modo sincrono o asincrono, a seconda della configurazione.
Nota
Questo articolo contiene riferimenti a termini che Microsoft non usa più. Quando questi termini vengono rimossi dal software, verranno rimossi da questo articolo.
Questo articolo descrive come distribuire e configurare le macchine virtuali di Azure, installare il framework del cluster e installare IBM Db2 LUW con la configurazione HADR.
L'articolo non illustra come installare e configurare IBM Db2 LUW con hadr o l'installazione del software SAP. Per facilitare l'esecuzione di queste attività, vengono forniti riferimenti ai manuali di installazione di SAP e IBM. Questo articolo è incentrato sulle parti specifiche dell'ambiente Azure.
Le versioni di IBM Db2 supportate sono 10.5 e successive, come documentato nella nota SAP 1928533.
Prima di iniziare un'installazione, vedere le note e la documentazione SAP seguenti:
| Nota SAP | Descrizione |
|---|---|
| 1928533 | Applicazioni SAP in Azure: prodotti supportati e tipi di macchine virtuali di Azure |
| 2015553 | SAP in Azure: Prerequisiti di supporto |
| 2178632 | Metriche di monitoraggio principali per SAP in Azure |
| 2191498 | SAP in Linux con Azure: Monitoraggio avanzato |
| 2243692 | Linux in una macchina virtuale Di Azure (IaaS): problemi di licenza SAP |
| 1984787 | SUSE LINUX Enterprise Server 12: note di installazione |
| 1999351 | Risoluzione dei problemi del monitoraggio avanzato di Azure per SAP |
| 2233094 | DB6: applicazioni SAP in Azure che usano IBM Db2 per Linux, UNIX e Windows - informazioni aggiuntive |
| 1612105 | DB6: Domande frequenti su Db2 con HADR |
Panoramica
Per ottenere la disponibilità elevata, IBM Db2 LUW con HADR viene installato in almeno due macchine virtuali di Azure, distribuite in un set di scalabilità di macchine virtuali con orchestrazione flessibile tra zone di disponibilità o in un set di disponibilità.
Nella grafica seguente viene visualizzata una configurazione di due macchine virtuali di Azure del server di database. Entrambe le macchine virtuali di Azure del server di database hanno una propria risorsa di archiviazione collegata e sono in esecuzione. In HADR, un'istanza di database in una delle macchine virtuali di Azure ha il ruolo dell'istanza primaria. Tutti i client sono connessi a questa istanza primaria. Tutte le modifiche apportate alle transazioni del database vengono mantenute localmente nel log delle transazioni Db2. Poiché i record del log delle transazioni vengono salvati in modo permanente in locale, i record vengono trasferiti tramite TCP/IP all'istanza del database nel secondo server di database, nel server di standby o nell'istanza di standby. L'istanza di standby aggiorna il database locale eseguendo il roll forward dei record del log delle transazioni trasferiti. In questo modo, il server standby viene mantenuto sincronizzato con il server primario.
HADR è solo una funzionalità di replica. Non dispone di rilevamento degli errori e di nessuna funzionalità di acquisizione o failover automatica. Un'acquisizione o il trasferimento al server di standby deve essere avviato manualmente da un amministratore di database. Per ottenere un rilevamento automatico delle acquisizioni e degli errori, è possibile usare la funzionalità di clustering Di Linux Pacemaker. Pacemaker monitora le due istanze del server di database. Quando l'istanza del server di database primario si arresta in modo anomalo, Pacemaker avvia un'acquisizione automatica di HADR dal server di standby. Pacemaker garantisce anche che il nuovo server primario venga assegnato all'indirizzo IP virtuale.
Per fare in modo che i server applicazioni SAP si connettano al database primario, sono necessari un nome host virtuale e un indirizzo IP virtuale. Dopo un failover, i server applicazioni SAP si connettono alla nuova istanza del database primario. In un ambiente Azure, è necessario un servizio di bilanciamento del carico di Azure per usare un indirizzo IP virtuale nel modo necessario per HADR di IBM Db2.
Per comprendere appieno il modo in cui IBM Db2 LUW con HADR e Pacemaker si inserisce in una configurazione di sistema SAP a disponibilità elevata, l'immagine seguente presenta una panoramica di una configurazione a disponibilità elevata di un sistema SAP basato sul database IBM Db2. Questo articolo illustra solo IBM Db2, ma fornisce riferimenti ad altri articoli su come configurare altri componenti di un sistema SAP.
Panoramica generale dei passaggi necessari
Per distribuire una configurazione IBM Db2, è necessario seguire questa procedura:
- Pianificare l'ambiente.
- Distribuire le macchine virtuali.
- Aggiornare SU edizione Standard Linux e configurare i file system.
- Installare e configurare Pacemaker.
- Installare NFS a disponibilità elevata.
- Installare ASCS/ERS in un cluster separato.
- Installare il database IBM Db2 con l'opzione Distributed/High Availability (SWPM).
- Installare e creare un nodo e un'istanza di database secondari e configurare HADR.
- Verificare che HADR funzioni.
- Applicare la configurazione pacemaker per controllare IBM Db2.
- Configurare Azure Load Balancer.
- Installare i server applicazioni primari e di dialogo.
- Controllare e adattare la configurazione dei server applicazioni SAP.
- Eseguire test di failover e acquisizione.
Pianificare l'infrastruttura di Azure per l'hosting di IBM Db2 LUW con HADR
Completare il processo di pianificazione prima di eseguire la distribuzione. La pianificazione crea le basi per la distribuzione di una configurazione di Db2 con HADR in Azure. Gli elementi chiave che devono far parte della pianificazione per IMB Db2 LUW (parte del database dell'ambiente SAP) sono elencati nella tabella seguente:
| Argomento | Descrizione breve |
|---|---|
| Definire i gruppi di risorse di Azure | Gruppi di risorse in cui si distribuiscono macchine virtuali, rete virtuale, Azure Load Balancer e altre risorse. Può essere esistente o nuovo. |
| Definizione di rete virtuale/subnet | Dove vengono distribuite le macchine virtuali per IBM Db2 e Azure Load Balancer. Può essere esistente o appena creato. |
| Macchine virtuali che ospitano IBM Db2 LUW | Dimensioni della macchina virtuale, archiviazione, rete, indirizzo IP. |
| Nome host virtuale e IP virtuale per il database IBM Db2 | Indirizzo IP virtuale o nome host usato per la connessione dei server applicazioni SAP. db-virt-hostname, db-virt-ip. |
| Isolamento di Azure | Isolamento di Azure o isolamento SBD (altamente consigliato). Metodo per evitare situazioni cerebrali split. |
| SBD VM | Dimensioni della macchina virtuale SBD, archiviazione, rete. |
| Azure Load Balancer | Utilizzo della porta probe Standard (consigliata), porta probe per il database Db2 (raccomandazione 62500). |
| Risoluzione dei nomi | Funzionamento della risoluzione dei nomi nell'ambiente. Il servizio DNS è altamente consigliato. È possibile usare il file host locale. |
Per altre informazioni su Linux Pacemaker in Azure, vedere Configurare Pacemaker su SU edizione Standard Linux Enterprise Server in Azure.
Importante
Per Db2 versioni 11.5.6 e successive è consigliabile usare Pacemaker con IBM.
Distribuzione in SU edizione Standard Linux
L'agente di risorse per IBM Db2 LUW è incluso in SU edizione Standard Linux Enterprise Server for SAP Applications. Per la configurazione descritta in questo documento, è necessario usare SU edizione Standard Linux Server for SAP Applications. Azure Marketplace contiene un'immagine per SU edizione Standard Enterprise Server for SAP Applications 12 che è possibile usare per distribuire nuove macchine virtuali di Azure. Tenere presente i vari modelli di supporto o di servizio offerti da SU edizione Standard tramite Azure Marketplace quando si sceglie un'immagine di macchina virtuale in Azure VM Marketplace.
Host: aggiornamenti DNS
Creare un elenco di tutti i nomi host, inclusi i nomi host virtuali e aggiornare i server DNS per abilitare la risoluzione dei nomi host corretta. Se un server DNS non esiste o non è possibile aggiornare e creare voci DNS, è necessario usare i file host locali delle singole macchine virtuali che partecipano a questo scenario. Se si usano voci di file host, assicurarsi che le voci vengano applicate a tutte le macchine virtuali nell'ambiente di sistema SAP. È tuttavia consigliabile usare il DNS che, idealmente, si estende in Azure
Distribuzione manuale
Assicurarsi che il sistema operativo selezionato sia supportato da IBM/SAP per IBM Db2 LUW. L'elenco delle versioni del sistema operativo supportate per le macchine virtuali di Azure e db2 è disponibile nella nota SAP 1928533. L'elenco delle versioni del sistema operativo in base alla singola versione db2 è disponibile nella matrice di disponibilità del prodotto SAP. È consigliabile usare almeno SLES 12 SP4 a causa di miglioramenti delle prestazioni correlati ad Azure in questa o versioni successive di SU edizione Standard Linux.
- Creare o selezionare un gruppo di risorse.
- Creare o selezionare una rete virtuale e una subnet.
- Scegliere un tipo di distribuzione appropriato per le macchine virtuali SAP. In genere, un set di scalabilità di macchine virtuali con orchestrazione flessibile.
- Creare la macchina virtuale 1.
- Usare SLES per l'immagine SAP in Azure Marketplace.
- Selezionare il set di scalabilità, la zona di disponibilità o il set di disponibilità creato nel passaggio 3.
- Creare la macchina virtuale 2.
- Usare SLES per l'immagine SAP in Azure Marketplace.
- Selezionare il set di scalabilità, la zona di disponibilità o il set di disponibilità creato nel passaggio 3 (non la stessa zona del passaggio 4).
- Aggiungere dischi dati alle macchine virtuali e quindi controllare la raccomandazione di una configurazione del file system nell'articolo IBM Db2 Azure Macchine virtuali distribuzione DBMS per il carico di lavoro SAP.
Installare l'ambiente IBM Db2 LUW e SAP
Prima di avviare l'installazione di un ambiente SAP basato su IBM Db2 LUW, vedere la documentazione seguente:
- Documentazione Azure
- Documentazione sap
- Documentazione ibm
I collegamenti a questa documentazione sono disponibili nella sezione introduttiva di questo articolo.
Controllare i manuali di installazione sap sull'installazione di applicazioni basate su NetWeaver in IBM Db2 LUW.
È possibile trovare le guide nel portale della Guida di SAP usando il Finder della Guida all'installazione di SAP.
È possibile ridurre il numero di guide visualizzate nel portale impostando i filtri seguenti:
- Si vuole: "Installare un nuovo sistema"
- Database personale: "IBM Db2 per Linux, Unix e Windows"
- Filtri aggiuntivi per le versioni di SAP NetWeaver, la configurazione dello stack o il sistema operativo
Hint di installazione per la configurazione di IBM Db2 LUW con HADR
Per configurare l'istanza primaria del database IBM Db2 LUW:
- Usare l'opzione a disponibilità elevata o distribuita.
- Installare l'istanza di SAP ASCS/ERS e database.
- Eseguire un backup del database appena installato.
Importante
Annotare la "porta di comunicazione del database" impostata durante l'installazione. Deve essere lo stesso numero di porta per entrambe le istanze del database 
Per configurare il server di database standby usando la procedura di copia omogenea del sistema SAP, eseguire questi passaggi:
Selezionare l'opzione Copia di sistema Sistemi di>destinazione Istanza di database distribuito.>>
Come metodo di copia, selezionare Sistema omogeneo in modo da poter usare il backup per ripristinare un backup nell'istanza del server standby.
Quando si raggiunge il passaggio di uscita per ripristinare il database per la copia di sistema omogenea, uscire dal programma di installazione. Ripristinare il database da un backup dell'host primario. Tutte le fasi di installazione successive sono già state eseguite nel server di database primario.
Configurare HADR per IBM Db2.
Nota
Per l'installazione e la configurazione specifica di Azure e Pacemaker: durante la procedura di installazione tramite SAP Software Provisioning Manager, esiste una domanda esplicita sulla disponibilità elevata per IBM Db2 LUW:
- Non selezionare IBM Db2 pureScale.
- Non selezionare Install IBM Json System Automation for Multiplatforms (Installa IBM Ibm System Automation for Multiplatforms).
- Non selezionare Genera file di configurazione del cluster.
Quando si usa un dispositivo SBD per Linux Pacemaker, impostare i parametri HADR db2 seguenti:
- Durata della finestra peer HADR (secondi) (HADR_Pedizione EnterpriseR_WINDOW) = 300
- Valore di timeout HADR (HADR_TIMEOUT) = 60
Quando si usa un agente di isolamento di Azure Pacemaker, impostare i parametri seguenti:
- Durata della finestra peer HADR (secondi) (HADR_Pedizione EnterpriseR_WINDOW) = 900
- Valore di timeout HADR (HADR_TIMEOUT) = 60
È consigliabile usare i parametri precedenti in base ai test iniziali di failover/acquisizione. È obbligatorio testare la funzionalità corretta del failover e acquisire acquisizione con queste impostazioni dei parametri. Poiché le singole configurazioni possono variare, i parametri potrebbero richiedere modifiche.
Importante
Specifico di IBM Db2 con configurazione HADR con avvio normale: l'istanza del database secondaria o standby deve essere operativa prima di poter avviare l'istanza del database primario.
A scopo dimostrativo e le procedure descritte in questo articolo, il SID del database è PTR.
Controllo HADR IBM Db2
Dopo aver configurato HADR e lo stato è P edizione Enterprise R e CONNECTED nei nodi primario e standby, eseguire la verifica seguente:
Execute command as db2<sid> db2pd -hadr -db <SID>
#Primary output:
# Database Member 0 -- Database PTR -- Active -- Up 1 days 01:51:38 -- Date 2019-02-06-15.35.28.505451
#
# HADR_ROLE = PRIMARY
# REPLAY_TYPE = PHYSICAL
# HADR_SYNCMODE = NEARSYNC
# STANDBY_ID = 1
# LOG_STREAM_ID = 0
# HADR_STATE = PEER
# HADR_FLAGS = TCP_PROTOCOL
# PRIMARY_MEMBER_HOST = azibmdb02
# PRIMARY_INSTANCE = db2ptr
# PRIMARY_MEMBER = 0
# STANDBY_MEMBER_HOST = azibmdb01
# STANDBY_INSTANCE = db2ptr
# STANDBY_MEMBER = 0
# HADR_CONNECT_STATUS = CONNECTED
# HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.170561 (1549374707)
# HEARTBEAT_INTERVAL(seconds) = 15
# HEARTBEAT_MISSED = 0
# HEARTBEAT_EXPECTED = 6137
# HADR_TIMEOUT(seconds) = 60
# TIME_SINCE_LAST_RECV(seconds) = 13
# PEER_WAIT_LIMIT(seconds) = 0
# LOG_HADR_WAIT_CUR(seconds) = 0.000
# LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000025
# LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
# LOG_HADR_WAIT_COUNT = 223713
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 374400
# PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
# STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
# HADR_LOG_GAP(bytes) = 0
# STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
# STANDBY_RECV_REPLAY_GAP(bytes) = 0
# PRIMARY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
# STANDBY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
# STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
# STANDBY_RECV_BUF_SIZE(pages) = 2048
# STANDBY_RECV_BUF_PERCENT = 0
# STANDBY_SPOOL_LIMIT(pages) = 0
# STANDBY_SPOOL_PERCENT = NULL
# STANDBY_ERROR_TIME = NULL
# PEER_WINDOW(seconds) = 300
# PEER_WINDOW_END = 02/06/2019 15:40:25.000000 (1549467625)
# READS_ON_STANDBY_ENABLED = N
#Secondary output:
# Database Member 0 -- Database PTR -- Standby -- Up 1 days 01:46:43 -- Date 2019-02-06-15.38.25.644168
#
# HADR_ROLE = STANDBY
# REPLAY_TYPE = PHYSICAL
# HADR_SYNCMODE = NEARSYNC
# STANDBY_ID = 0
# LOG_STREAM_ID = 0
# HADR_STATE = PEER
# HADR_FLAGS = TCP_PROTOCOL
# PRIMARY_MEMBER_HOST = azibmdb02
# PRIMARY_INSTANCE = db2ptr
# PRIMARY_MEMBER = 0
# STANDBY_MEMBER_HOST = azibmdb01
# STANDBY_INSTANCE = db2ptr
# STANDBY_MEMBER = 0
# HADR_CONNECT_STATUS = CONNECTED
# HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.205067 (1549374707)
# HEARTBEAT_INTERVAL(seconds) = 15
# HEARTBEAT_MISSED = 0
# HEARTBEAT_EXPECTED = 6186
# HADR_TIMEOUT(seconds) = 60
# TIME_SINCE_LAST_RECV(seconds) = 5
# PEER_WAIT_LIMIT(seconds) = 0
# LOG_HADR_WAIT_CUR(seconds) = 0.000
# LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000023
# LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
# LOG_HADR_WAIT_COUNT = 223725
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 372480
# PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
# STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
# HADR_LOG_GAP(bytes) = 0
# STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
# STANDBY_RECV_REPLAY_GAP(bytes) = 155
# PRIMARY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
# STANDBY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
# STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
# STANDBY_RECV_BUF_SIZE(pages) = 2048
# STANDBY_RECV_BUF_PERCENT = 0
# STANDBY_SPOOL_LIMIT(pages) = 0
# STANDBY_SPOOL_PERCENT = NULL
# STANDBY_ERROR_TIME = NULL
# PEER_WINDOW(seconds) = 300
# PEER_WINDOW_END = 02/06/2019 15:43:19.000000 (1549467799)
# READS_ON_STANDBY_ENABLED = N
Configurare Azure Load Balancer
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 DB2.
Seguire la guida alla creazione del servizio di bilanciamento del carico per configurare un servizio di bilanciamento del carico standard per un sistema SAP a disponibilità elevata usando il portale di Azure. Durante la configurazione del servizio di bilanciamento del carico, prendere in considerazione i punti seguenti.
- Configurazione IP front-end: creare un indirizzo IP front-end. Selezionare la stessa rete virtuale e la stessa subnet delle macchine virtuali del database.
- Pool back-end: creare un pool back-end e aggiungere macchine virtuali del database.
- Regole in ingresso: creare una regola di bilanciamento del carico. Seguire la stessa procedura per entrambe le regole di bilanciamento del carico.
- Indirizzo IP front-end: selezionare ip front-end
- Pool back-end: selezionare il pool back-end
- Controllare "Porte a disponibilità elevata"
- Protocollo: TCP
- Probe di integrità: creare un probe di integrità con i dettagli seguenti
- Protocollo: TCP
- Porta: [ad esempio: 625<instance-no.>]
- Intervallo: 5
- Soglia probe: 2
- Timeout di inattività (minuti): 30
- Selezionare "Enable Floating IP" (Abilita IP mobile)
Nota
Il numero della proprietà di configurazione del probe di integritàOfProbes, altrimenti noto come "Soglia non integra" nel portale, non viene rispettato. Per controllare il numero di probe consecutivi riusciti o non riusciti, impostare la proprietà "probeThreshold" su 2. Attualmente non è possibile impostare questa proprietà usando portale di Azure, quindi usare l'interfaccia della riga di comando di Azure o il comando di PowerShell.
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 altre informazioni, vedere Limitazioni di Azure Load Balancer. Se è necessario un altro indirizzo IP 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 di un'istanza interna (nessun indirizzo IP pubblico) di Azure Load Balancer Standard, non esiste connettività Internet in uscita, a meno che non venga eseguita più configurazione per consentire il routing agli endpoint pubblici. Per altre informazioni su come ottenere la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali che usano Azure Load Balancer Standard in scenari di disponibilità elevata SAP.
Importante
Non abilitare i timestamp TCP nelle macchine virtuali di Azure posizionate dietro Azure Load Balancer. L'abilitazione dei timestamp TCP potrebbe causare l'esito negativo dei probe di integrità. Impostare il parametro net.ipv4.tcp_timestamps su 0. Per altre informazioni, vedere Probe di integrità di Load Balancer.
Creare il cluster Pacemaker
Per creare un cluster Pacemaker di base per questo server IBM Db2, vedere Configurare Pacemaker su SU edizione Standard Linux Enterprise Server in Azure.
Configurazione di Db2 Pacemaker
Quando si usa Pacemaker per il failover automatico in caso di errore del nodo, è necessario configurare di conseguenza le istanze db2 e Pacemaker. Questa sezione descrive questo tipo di configurazione.
Gli elementi seguenti sono preceduti da uno dei due elementi seguenti:
- [A]: applicabile a tutti i nodi
- [1]: applicabile solo al nodo 1
- [2]: applicabile solo al nodo 2
[A] Prerequisiti per la configurazione di Pacemaker:
- Arrestare entrambi i server di database con db2<sid> utente con db2stop.
- Modificare l'ambiente della shell per l'utente db2<sid> in /bin/ksh. È consigliabile usare lo strumento Yast.
Configurazione di Pacemaker
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.
[1] Configurazione pacemaker specifica di IBM Db2:
# Put Pacemaker into maintenance mode sudo crm configure property maintenance-mode=true[1] Creare risorse IBM Db2:
# Replace **bold strings** with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer. sudo crm configure primitive rsc_Db2_db2ptr_PTR db2 \ params instance="db2ptr" dblist="PTR" \ op start interval="0" timeout="130" \ op stop interval="0" timeout="120" \ op promote interval="0" timeout="120" \ op demote interval="0" timeout="120" \ op monitor interval="30" timeout="60" \ op monitor interval="31" role="Master" timeout="60" # Configure virtual IP - same as Azure Load Balancer IP sudo crm configure primitive rsc_ip_db2ptr_PTR IPaddr2 \ op monitor interval="10s" timeout="20s" \ params ip="10.100.0.10" # Configure probe port for Azure load Balancer sudo crm configure primitive rsc_nc_db2ptr_PTR azure-lb port=62500 \ op monitor timeout=20s interval=10 sudo crm configure group g_ip_db2ptr_PTR rsc_ip_db2ptr_PTR rsc_nc_db2ptr_PTR sudo crm configure ms msl_Db2_db2ptr_PTR rsc_Db2_db2ptr_PTR \ meta target-role="Started" notify="true" sudo crm configure colocation col_db2_db2ptr_PTR inf: g_ip_db2ptr_PTR:Started msl_Db2_db2ptr_PTR:Master sudo crm configure order ord_db2_ip_db2ptr_PTR inf: msl_Db2_db2ptr_PTR:promote g_ip_db2ptr_PTR:start sudo crm configure rsc_defaults resource-stickiness=1000 sudo crm configure rsc_defaults migration-threshold=5000[1] Avviare le risorse IBM Db2:
Mettere Pacemaker fuori dalla modalità di manutenzione.
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo crm configure property maintenance-mode=false[1] Assicurarsi che lo stato del cluster sia OK e che tutte le risorse vengano avviate. Non è importante quale nodo le risorse sono in esecuzione.
sudo crm status # 2 nodes configured # 5 resources configured # Online: [ azibmdb01 azibmdb02 ] # Full list of resources: # stonith-sbd (stonith:external/sbd): Started azibmdb02 # Resource Group: g_ip_db2ptr_PTR # rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02 # rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02 # Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR] # Masters: [ azibmdb02 ] # Slaves: [ azibmdb01 ]
Importante
È necessario gestire l'istanza di Pacemaker in cluster Db2 usando gli strumenti Pacemaker. Se si usano comandi db2, ad esempio db2stop, Pacemaker rileva l'azione come errore della risorsa. Se si esegue la manutenzione, è possibile inserire i nodi o le risorse in modalità di manutenzione. Pacemaker sospende le risorse di monitoraggio ed è quindi possibile usare i normali comandi di amministrazione db2.
Apportare modifiche ai profili SAP per usare l'indirizzo IP virtuale per la connessione
Per connettersi all'istanza primaria della configurazione HADR, il livello applicazione SAP deve usare l'indirizzo IP virtuale definito e configurato per Azure Load Balancer. Sono necessarie le modifiche seguenti:
/sapmnt/<SID>/profile/DEFAULT. PFL
SAPDBHOST = db-virt-hostname
j2ee/dbhost = db-virt-hostname
/sapmnt/<SID>/global/db6/db2cli.ini
Hostname=db-virt-hostname
Installare server applicazioni primari e di dialogo
Quando si installano server applicazioni primari e di dialogo in una configurazione HADR Db2, usare il nome host virtuale selezionato per la configurazione.
Se è stata eseguita l'installazione prima di creare la configurazione HADR Db2, apportare le modifiche come descritto nella sezione precedente e come indicato di seguito per gli stack Sap Java.
Controllo dell'URL JDBC per i sistemi stack ABAP+Java o Java
Usare lo strumento J2 edizione Enterprise Config per controllare o aggiornare l'URL JDBC. Poiché lo strumento J2 edizione Enterprise Config è uno strumento grafico, è necessario installare X server:
Accedere al server applicazioni primario dell'istanza di J2 edizione Enterprise ed eseguire:
sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.shNel riquadro sinistro scegliere Archivio di sicurezza.
Nel frame destro scegliere la chiave jdbc/pool/<S piattaforma di strumenti analitici ID>/url.
Modificare il nome host nell'URL JDBC impostando il nome host virtuale.
jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0Selezionare Aggiungi.
Per salvare le modifiche, selezionare l'icona del disco in alto a sinistra.
Chiudere lo strumento di configurazione.
Riavviare l'istanza di Java.
Configurare l'archiviazione dei log per la configurazione di HADR
Per configurare l'archiviazione dei log Db2 per la configurazione di HADR, è consigliabile configurare sia il database primario che il database standby in modo che dispongano della funzionalità di recupero automatico dei log da tutte le posizioni di archiviazione dei log. Sia il database primario che quello standby devono essere in grado di recuperare i file di archivio di log da tutte le posizioni di archiviazione dei log in cui una delle istanze del database potrebbe archiviare i file di log.
L'archiviazione dei log viene eseguita solo dal database primario. Se si modificano i ruoli HADR dei server di database o se si verifica un errore, il nuovo database primario è responsabile dell'archiviazione dei log. Se sono state configurate più posizioni di archiviazione dei log, i log potrebbero essere archiviati due volte. In caso di recupero locale o remoto, potrebbe anche essere necessario copiare manualmente i log archiviati dal server primario precedente al percorso del log attivo del nuovo server primario.
È consigliabile configurare una condivisione NFS comune in cui i log vengono scritti da entrambi i nodi. La condivisione NFS deve essere a disponibilità elevata.
È possibile usare le condivisioni NFS a disponibilità elevata esistenti per i trasporti o una directory del profilo. Per altre informazioni, vedi:
- Disponibilità elevata per NFS in macchine virtuali di Azure in SU edizione Standard Linux Enterprise Server.
- Disponibilità elevata per SAP NetWeaver in macchine virtuali di Azure in SU edizione Standard Linux Enterprise Server con Azure NetApp Files per applicazioni SAP.
- Azure NetApp Files (per creare condivisioni NFS).
Testare la configurazione del cluster
Questa sezione descrive come testare l'installazione di Db2 HADR. Ogni test presuppone che l'utente abbia eseguito l'accesso come radice utente e che il database primario IBM Db2 sia in esecuzione nella macchina virtuale azibmdb01 .
Lo stato iniziale per tutti i test case è illustrato qui: (crm_mon -r o stato crm)
- crm status è uno snapshot dello stato di Pacemaker in fase di esecuzione.
- crm_mon -r è l'output continuo dello stato pacemaker.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Stopped
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
rsc_Db2_db2ptr_PTR (ocf::heartbeat:db2): Promoting azibmdb01
Slaves: [ azibmdb02 ]
Lo stato originale in un sistema SAP è documentato in Panoramica della configurazione > di DBACOCKPIT > delle transazioni, come illustrato nell'immagine seguente:
Acquisizione di test di IBM Db2
Importante
Prima di avviare il test, assicurarsi che:
Pacemaker non dispone di azioni non riuscite (stato crm).
Non esistono vincoli di posizione (a sinistra del test di migrazione.
La sincronizzazione di IBM Db2 HADR funziona. Verificare con l'utente db2<sid>
db2pd -hadr -db <DBSID>
Eseguire la migrazione del nodo che esegue il database Db2 primario eseguendo il comando seguente:
crm resource migrate msl_Db2_db2ptr_PTR azibmdb02
Al termine della migrazione, l'output dello stato crm sarà simile al seguente:
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Slaves: [ azibmdb01 ]
Lo stato originale in un sistema SAP è documentato in Panoramica della configurazione > di DBACOCKPIT > delle transazioni, come illustrato nell'immagine seguente:
La migrazione delle risorse con "crm resource migrate" crea vincoli di posizione. I vincoli di posizione devono essere eliminati. Se i vincoli di posizione non vengono eliminati, la risorsa non può eseguire il failback o si possono riscontrare acquisizioni indesiderate.
Eseguire di nuovo la migrazione della risorsa ad azibmdb01 e cancellare i vincoli di posizione
crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR
- crm resource migrate <res_name><host>: crea vincoli di posizione e può causare problemi di acquisizione
- crm resource clear <res_name>: cancella i vincoli di posizione
- crm resource cleanup <res_name>: cancella tutti gli errori della risorsa
Testare l'isolamento SBD
In questo caso, si testa l'isolamento SBD, che è consigliabile eseguire quando si usa SU edizione Standard Linux.
azibmdb01:~ # ps -ef|grep sbd
root 2374 1 0 Feb05 ? 00:00:17 sbd: inquisitor
root 2378 2374 0 Feb05 ? 00:00:40 sbd: watcher: /dev/disk/by-id/scsi-36001405fbbaab35ee77412dacb77ae36 - slot: 0 - uuid: 27cad13a-0bce-4115-891f-43b22cfabe65
root 2379 2374 0 Feb05 ? 00:01:51 sbd: watcher: Pacemaker
root 2380 2374 0 Feb05 ? 00:00:18 sbd: watcher: Cluster
azibmdb01:~ # kill -9 2374
Il nodo del cluster azibmdb01 deve essere riavviato. Il ruolo HADR primario IBM Db2 verrà spostato in azibmdb02. Quando azibmdb01 è di nuovo online, l'istanza di Db2 verrà spostata nel ruolo di un'istanza di database secondaria.
Se il servizio Pacemaker non viene avviato automaticamente nel computer primario precedente riavviato, assicurarsi di avviarlo manualmente con:
sudo service pacemaker start
Testare un'acquisizione manuale
È possibile testare un'acquisizione manuale arrestando il servizio Pacemaker nel nodo azibmdb01 :
service pacemaker stop
stato in azibmdb02
2 nodes configured
5 resources configured
Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
Dopo il failover, è possibile riavviare il servizio in azibmdb01.
service pacemaker start
Terminare il processo Db2 nel nodo che esegue il database primario HADR
#Kill main db2 process - db2sysc
azibmdb01:~ # ps -ef|grep db2s
db2ptr 34598 34596 8 14:21 ? 00:00:07 db2sysc 0
azibmdb01:~ # kill -9 34598
L'istanza db2 avrà esito negativo e Pacemaker segnala lo stato seguente:
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Stopped
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Slaves: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms
Pacemaker riavvia l'istanza del database primario Db2 nello stesso nodo oppure esegue il failover nel nodo che esegue l'istanza del database secondario e viene segnalato un errore.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms
Terminare il processo Db2 nel nodo che esegue l'istanza del database secondario
azibmdb02:~ # ps -ef|grep db2s
db2ptr 65250 65248 0 Feb11 ? 00:09:27 db2sysc 0
azibmdb02:~ # kill -9
Il nodo si trova in non riuscito e viene segnalato un errore
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
rsc_Db2_db2ptr_PTR (ocf::heartbeat:db2): FAILED azibmdb02
Masters: [ azibmdb01 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms
L'istanza db2 viene riavviata nel ruolo secondario assegnato in precedenza.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms
Arrestare il database tramite db2stop force sul nodo che esegue l'istanza del database primario HADR
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
Come utente db2<sid> execute command db2stop force:
azibmdb01:~ # su - db2ptr
azibmdb01:db2ptr> db2stop force
Errore rilevato
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Stopped
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
rsc_Db2_db2ptr_PTR (ocf::heartbeat:db2): FAILED azibmdb01
Slaves: [ azibmdb02 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=201, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:45:25 2019', queued=1ms, exec=150ms
L'istanza secondaria del database HADR Db2 è stata alzata di livello nel ruolo primario.
nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_start_0 on azibmdb01 'unknown error' (1): call=205, stat
us=complete, exitreason='',
last-rc-change='Tue Feb 12 14:45:27 2019', queued=0ms, exec=865ms
Arresto anomalo della macchina virtuale con riavvio nel nodo che esegue l'istanza del database primario HADR
#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger
Pacemaker promuove l'istanza secondaria al ruolo dell'istanza primaria. L'istanza primaria precedente verrà spostata nel ruolo secondario dopo che la macchina virtuale e tutti i servizi vengono completamente ripristinati dopo il riavvio della macchina virtuale.
nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
Arrestare in modo anomalo la macchina virtuale che esegue l'istanza del database primario HADR con "stop"
#Linux kernel panic - halts OS
azibmdb01:~ # echo b > /proc/sysrq-trigger
In questo caso Pacemaker rileva che il nodo che esegue l'istanza del database primario non risponde.
2 nodes configured
5 resources configured
Node azibmdb01: UNCLEAN (online)
Online: [ azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
Il passaggio successivo consiste nel verificare la situazione di split brain . Dopo che il nodo sopravvissuto ha determinato che il nodo che ha eseguito l'ultima istanza del database primario è inattivo, viene eseguito un failover delle risorse.
2 nodes configured
5 resources configured
Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
In caso di "arresto" del nodo, il nodo non riuscito deve essere riavviato tramite gli strumenti di gestione di Azure (nella portale di Azure, PowerShell o nell'interfaccia della riga di comando di Azure). Dopo che il nodo non riuscito è di nuovo online, avvia l'istanza db2 nel ruolo secondario.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Slaves: [ azibmdb01 ]