Disponibilità elevata di IBN Db2 LUW in macchine virtuali di Azure su Red Hat Enterprise Linux Server
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 |
| 2002167 | Red Hat Enterprise Linux 7. x: installazione e aggiornamento |
| 2694118 | Componente aggiuntivo Red Hat Enterprise Linux a disponibilità elevata in Azure |
| 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 all'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 RHEL Linux e configurare i file system.
- Installare e configurare Pacemaker.
- Configurare un cluster glusterfs o Azure NetApp Files
- 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 | L'indirizzo IP virtuale o il nome host viene usato per la connessione dei server applicazioni SAP. db-virt-hostname, db-virt-ip. |
| Isolamento di Azure | Il metodo per evitare situazioni del cervello diviso è impedito. |
| 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 Configurazione di Pacemaker in Red Hat Enterprise Linux in Azure.
Importante
Per Db2 versioni 11.5.6 e successive è consigliabile usare Pacemaker con IBM.
Distribuzione in Red Hat Enterprise Linux
L'agente di risorse per IBM Db2 LUW è incluso in Red Hat Enterprise Linux Server HA Addon. Per la configurazione descritta in questo documento, è consigliabile usare Red Hat Enterprise Linux per SAP. Azure Marketplace contiene un'immagine per Red Hat Enterprise Linux 7.4 per SAP o versione successiva che è possibile usare per distribuire nuove macchine virtuali di Azure. Tenere presente i vari modelli di supporto o di servizio offerti da Red Hat 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 Red Hat Enterprise Linux 7.4 per SAP a causa di miglioramenti delle prestazioni correlati ad Azure in questa o versioni successive di Red Hat Enterprise 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 l'immagine Red Hat Enterprise Linux per 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 l'immagine Red Hat Enterprise Linux per 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 di 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:
- Voglio: 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.
Regole del firewall Red Hat
Red Hat Enterprise Linux ha il firewall abilitato per impostazione predefinita.
#Allow access to SWPM tool. Rule is not permanent.
sudo firewall-cmd --add-port=4237/tcp
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.
Impostazioni di IBM Db2 HADR per Azure
Quando si usa un agente di isolamento di Azure Pacemaker, impostare i parametri seguenti:
- Durata della finestra peer HADR (secondi) (HADR_Pedizione EnterpriseR_WINDOW) = 240
- Valore di timeout HADR (HADR_TIMEOUT) = 45
È 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.
Nota
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.
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.
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.
Regole del firewall Red Hat per DB2 HADR
Aggiungere regole del firewall per consentire il funzionamento del traffico verso DB2 e tra DB2 per HADR:
- Porta di comunicazione del database. Se si usano partizioni, aggiungere anche queste porte.
- Porta HADR (valore del parametro DB2 HADR_LOCAL_SVC).
- Porta probe di Azure.
sudo firewall-cmd --add-port=<port>/tcp --permanent
sudo firewall-cmd --reload
Controllo HADR IBM Db2
A scopo dimostrativo e le procedure descritte in questo articolo, il SID del database è ID2.
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 ID2 -- Active -- Up 1 days 15:45:23 -- Date 2019-06-25-10.55.25.349375
HADR_ROLE = PRIMARY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 1
LOG_STREAM_ID = 0
HADR_STATE = PEER
HADR_FLAGS =
PRIMARY_MEMBER_HOST = az-idb01
PRIMARY_INSTANCE = db2id2
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = az-idb02
STANDBY_INSTANCE = db2id2
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 06/25/2019 10:55:05.076494 (1561460105)
HEARTBEAT_INTERVAL(seconds) = 7
HEARTBEAT_MISSED = 5
HEARTBEAT_EXPECTED = 52
HADR_TIMEOUT(seconds) = 30
TIME_SINCE_LAST_RECV(seconds) = 5
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 598.000027
LOG_HADR_WAIT_ACCUMULATED(seconds) = 598.000
LOG_HADR_WAIT_COUNT = 1
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 369280
PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
HADR_LOG_GAP(bytes) = 132242668
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
STANDBY_RECV_REPLAY_GAP(bytes) = 0
PRIMARY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_REPLAY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_RECV_BUF_SIZE(pages) = 2048
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 1000
STANDBY_SPOOL_PERCENT = 0
STANDBY_ERROR_TIME = NULL
PEER_WINDOW(seconds) = 300
PEER_WINDOW_END = 06/25/2019 11:12:03.000000 (1561461123)
READS_ON_STANDBY_ENABLED = N
#Secondary output:
Database Member 0 -- Database ID2 -- Standby -- Up 1 days 15:45:18 -- Date 2019-06-25-10.56.19.820474
HADR_ROLE = STANDBY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 0
LOG_STREAM_ID = 0
HADR_STATE = PEER
HADR_FLAGS =
PRIMARY_MEMBER_HOST = az-idb01
PRIMARY_INSTANCE = db2id2
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = az-idb02
STANDBY_INSTANCE = db2id2
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 06/25/2019 10:55:05.078116 (1561460105)
HEARTBEAT_INTERVAL(seconds) = 7
HEARTBEAT_MISSED = 0
HEARTBEAT_EXPECTED = 10
HADR_TIMEOUT(seconds) = 30
TIME_SINCE_LAST_RECV(seconds) = 1
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 598.000027
LOG_HADR_WAIT_ACCUMULATED(seconds) = 598.000
LOG_HADR_WAIT_COUNT = 1
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 367360
PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
HADR_LOG_GAP(bytes) = 0
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
STANDBY_RECV_REPLAY_GAP(bytes) = 0
PRIMARY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_REPLAY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_RECV_BUF_SIZE(pages) = 2048
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 1000
STANDBY_SPOOL_PERCENT = 0
STANDBY_ERROR_TIME = NULL
PEER_WINDOW(seconds) = 1000
PEER_WINDOW_END = 06/25/2019 11:12:59.000000 (1561461179)
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.
[A] Aggiungere una regola del firewall per la porta probe:
sudo firewall-cmd --add-port=<probe-port>/tcp --permanent
sudo firewall-cmd --reload
Creare il cluster Pacemaker
Per creare un cluster Pacemaker di base per questo server IBM Db2, vedere Configurazione di Pacemaker in Red Hat Enterprise Linux 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] Prerequisito 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:
# Install korn shell: sudo yum install ksh # Change users shell: sudo usermod -s /bin/ksh db2<sid>
Configurazione di Pacemaker
[1] Configurazione pacemaker specifica di IBM Db2:
# Put Pacemaker into maintenance mode sudo pcs property set maintenance-mode=true[1] Creare risorse IBM Db2:
Se si compila un cluster in RHEL 7.x, assicurarsi di aggiornare gli agenti di risorse del pacchetto alla versione
resource-agents-4.1.1-61.el7_9.15o successiva. Usare i comandi seguenti per creare le risorse del cluster:# Replace bold strings with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer. sudo pcs resource create Db2_HADR_ID2 db2 instance='db2id2' dblist='ID2' master meta notify=true resource-stickiness=5000 #Configure resource stickiness and correct cluster notifications for master resoruce sudo pcs resource update Db2_HADR_ID2-master meta notify=true resource-stickiness=5000 # Configure virtual IP - same as Azure Load Balancer IP sudo pcs resource create vip_db2id2_ID2 IPaddr2 ip='10.100.0.40' # Configure probe port for Azure load Balancer sudo pcs resource create nc_db2id2_ID2 azure-lb port=62500 #Create a group for ip and Azure loadbalancer probe port sudo pcs resource group add g_ipnc_db2id2_ID2 vip_db2id2_ID2 nc_db2id2_ID2 #Create colocation constrain - keep Db2 HADR Master and Group on same node sudo pcs constraint colocation add g_ipnc_db2id2_ID2 with master Db2_HADR_ID2-master #Create start order constrain sudo pcs constraint order promote Db2_HADR_ID2-master then g_ipnc_db2id2_ID2Se si compila un cluster in RHEL 8.x, assicurarsi di aggiornare gli agenti di risorse del pacchetto alla versione
resource-agents-4.1.1-93.el8o successiva. Per informazioni dettagliate, vedere La risorsa KBAdb2di Red Hat con HADR non riesce a promuovere con statoPRIMARY/REMOTE_CATCHUP_PENDING/CONNECTED. Usare i comandi seguenti per creare le risorse del cluster:# Replace bold strings with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer. sudo pcs resource create Db2_HADR_ID2 db2 instance='db2id2' dblist='ID2' promotable meta notify=true resource-stickiness=5000 #Configure resource stickiness and correct cluster notifications for master resoruce sudo pcs resource update Db2_HADR_ID2-clone meta notify=true resource-stickiness=5000 # Configure virtual IP - same as Azure Load Balancer IP sudo pcs resource create vip_db2id2_ID2 IPaddr2 ip='10.100.0.40' # Configure probe port for Azure load Balancer sudo pcs resource create nc_db2id2_ID2 azure-lb port=62500 #Create a group for ip and Azure loadbalancer probe port sudo pcs resource group add g_ipnc_db2id2_ID2 vip_db2id2_ID2 nc_db2id2_ID2 #Create colocation constrain - keep Db2 HADR Master and Group on same node sudo pcs constraint colocation add g_ipnc_db2id2_ID2 with master Db2_HADR_ID2-clone #Create start order constrain sudo pcs constraint order promote Db2_HADR_ID2-clone then g_ipnc_db2id2_ID2[1] Avviare le risorse IBM Db2:
Mettere Pacemaker fuori dalla modalità di manutenzione.
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo pcs property set 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 pcs status 2 nodes configured 5 resources configured Online: [ az-idb01 az-idb02 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started az-idb01 Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2] Masters: [ az-idb01 ] Slaves: [ az-idb02 ] Resource Group: g_ipnc_db2id2_ID2 vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb01 nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb01 Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled
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 fotogramma destro scegliere la chiave
jdbc/pool/\<SAPSID>/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 o GlusterFS, in cui i log vengono scritti da entrambi i nodi. La condivisione NFS o GlusterFS deve essere a disponibilità elevata.
È possibile usare condivisioni NFS a disponibilità elevata esistenti o GlusterFS per i trasporti o una directory del profilo. Per altre informazioni, vedi:
- GlusterFS in macchine virtuali di Azure in Red Hat Enterprise Linux per SAP NetWeaver.
- Disponibilità elevata per SAP NetWeaver in macchine virtuali di Azure in Red Hat Enterprise Linux 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 IBM Db2 primary sia in esecuzione nella macchina virtuale az-idb01 . È necessario usare l'utente con privilegi sudo o root (non consigliato).
Lo stato iniziale per tutti i test case è illustrato qui: (crm_mon -r o pcs status)
- lo stato di pcs è uno snapshot dello stato pacemaker in fase di esecuzione.
- crm_mon -r è l'output continuo dello stato pacemaker.
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb01 ]
Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb01
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb01
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
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 ha azioni non riuscite (stato pcs).
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:
# On RHEL 7.x
sudo pcs resource move Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource move Db2_HADR_ID2-clone --master
Al termine della migrazione, l'output dello stato crm sarà simile al seguente:
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
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 "pcs resource move" crea vincoli di posizione. In questo caso, i vincoli di posizione impediscono l'esecuzione dell'istanza IBM Db2 in az-idb01. Se i vincoli di posizione non vengono eliminati, la risorsa non può eseguire il failback.
Rimuovere il vincolo di posizione e il nodo standby verranno avviati in az-idb01.
# On RHEL 7.x
sudo pcs resource clear Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource clear Db2_HADR_ID2-clone
E lo stato del cluster cambia in:
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
Eseguire di nuovo la migrazione della risorsa ad az-idb01 e cancellare i vincoli di posizione
# On RHEL 7.x
sudo pcs resource move Db2_HADR_ID2-master az-idb01
sudo pcs resource clear Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource move Db2_HADR_ID2-clone --master
sudo pcs resource clear Db2_HADR_ID2-clone
- In RHEL 7.x -
pcs resource move <resource_name> <host>: crea vincoli di posizione e può causare problemi di acquisizione - In RHEL 8.x -
pcs resource move <resource_name> --master: crea vincoli di posizione e può causare problemi di acquisizione pcs resource clear <resource_name>: cancella i vincoli di posizionepcs resource cleanup <resource_name>: cancella tutti gli errori della risorsa
Testare un'acquisizione manuale
È possibile testare un'acquisizione manuale arrestando il servizio Pacemaker nel nodo az-idb01 :
systemctl stop pacemaker
status in az-ibdb02
2 nodes configured
5 resources configured
Node az-idb01: pending
Online: [ az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
Dopo il failover, è possibile riavviare il servizio in az-idb01.
systemctl start pacemaker
Terminare il processo Db2 nel nodo che esegue il database primario HADR
#Kill main db2 process - db2sysc
[sapadmin@az-idb02 ~]$ sudo ps -ef|grep db2sysc
db2ptr 34598 34596 8 14:21 ? 00:00:07 db2sysc 0
[sapadmin@az-idb02 ~]$ sudo kill -9 34598
L'istanza db2 avrà esito negativo e Pacemaker sposterà il nodo master e inserirà lo stato seguente:
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=49, status=complete, exitreason='none',
last-rc-change='Wed Jun 26 09:57:35 2019', queued=0ms, exec=362ms
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.
Terminare il processo Db2 nel nodo che esegue l'istanza del database secondario
[sapadmin@az-idb02 ~]$ sudo ps -ef|grep db2sysc
db2id2 23144 23142 2 09:53 ? 00:00:13 db2sysc 0
[sapadmin@az-idb02 ~]$ sudo kill -9 23144
Il nodo viene inserito in non riuscito e viene segnalato un errore.
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb01 ]
Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb01
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb01
Failed Actions:
* Db2_HADR_ID2_monitor_20000 on az-idb02 'not running' (7): call=144, status=complete, exitreason='none',
last-rc-change='Wed Jun 26 10:02:09 2019', queued=0ms, exec=0ms
L'istanza db2 viene riavviata nel ruolo secondario assegnato in precedenza.
Arrestare il database tramite db2stop force sul nodo che esegue l'istanza del database primario HADR
Come utente db2<sid> execute command db2stop force:
az-idb01:db2ptr> db2stop force
Errore rilevato:
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Slaves: [ az-idb02 ]
Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Stopped
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Stopped
Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=110, status=complete, exitreason='none',
last-rc-change='Wed Jun 26 14:03:12 2019', queued=0ms, exec=355ms
L'istanza secondaria del database HADR Db2 è stata alzata di livello nel ruolo primario.
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=110, status=complete, exitreason='none',
last-rc-change='Wed Jun 26 14:03:12 2019', queued=0ms, exec=355ms
Arrestare in modo anomalo la macchina virtuale che esegue l'istanza del database primario HADR con "stop"
#Linux kernel panic.
sudo 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 az-idb01: UNCLEAN (online)
Online: [ az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb01 ]
Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb01
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb01
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: [ az-idb02 ]
OFFLINE: [ az-idb01 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
In caso di panico del kernel, il nodo non riuscito verrà riavviato dall'agente di isolamento. Dopo che il nodo non riuscito è di nuovo online, è necessario avviare il cluster pacemaker tramite
sudo pcs cluster start
avvia l'istanza db2 nel ruolo secondario.
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02