Disponibilità elevata di IBM Db2 LUW in macchine virtuali di Azure su SUSE Linux Enterprise Server con Pacemaker
IBM Db2 per Linux, UNIX e Windows (LUW) nella configurazione della disponibilità elevata e del ripristino di emergenza (HADR) è costituito da un nodo che esegue un'istanza di database primaria e almeno un nodo che esegue un'istanza di database secondaria. Le modifiche apportate all'istanza di database primaria vengono replicate in un'istanza di 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 verranno 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 l'installazione di HADR o del software SAP. Per facilitare l'esecuzione di queste attività, vengono forniti riferimenti ai manuali di installazione di SAP e IBM. Questo articolo è incentrato su 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 del supporto |
| 2178632 | Metriche chiave del monitoraggio per SAP in Azure |
| 2191498 | SAP in Linux con Azure: monitoraggio avanzato |
| 2243692 | Linux in una macchina virtuale di Azure (IaaS): problemi delle licenze SAP |
| 1984787 | SUSE LINUX Enterprise Server 12: note di installazione |
| 1999351 | Risoluzione dei problemi del monitoraggio avanzato di Azure per SAP |
| 2233094 | DB6: informazioni aggiuntive sulle applicazioni SAP in Azure che usano IBM Db2 per Linux, UNIX e Windows |
| 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 le zone di disponibilità o in un set di disponibilità.
Nella grafica seguente viene mostrata 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 attive e in esecuzione. In HADR, un'istanza di database in una delle macchine virtuali di Azure ha il ruolo di istanza primaria. Tutti i client sono connessi a questa istanza primaria. Tutte le modifiche apportate alle transazioni del database vengono mantenute in locale nel log delle transazioni di Db2. Poiché i record del log delle transazioni sono persistenti in locale, vengono trasferiti tramite TCP/IP all'istanza di 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 resta sincronizzato con il server primario.
HADR è solo una funzionalità di replica. Non ha la funzione di rilevamento degli errori e né di acquisizione o failover automatici. Un'acquisizione o un trasferimento al server di standby deve essere avviato manualmente da un amministratore di database. Per ottenere le funzioni automatiche di rilevamento degli errori e acquisizione, è 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 primaria si arresta in modo anomalo, Pacemaker avvia un'acquisizione HADR automatica dal server di standby. Pacemaker garantisce anche che l'indirizzo IP virtuale sia assegnato al nuovo server primario.
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 di database primaria. In un ambiente Azure è necessario un servizio di bilanciamento del carico di Azure per usare un indirizzo IP virtuale nel modo richiesto da HADR di IBM Db2.
Per illustrare al meglio il modo in cui IBM Db2 LUW con HADR e Pacemaker si adatta a una configurazione del 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 di IBM Db2, è necessario seguire questa procedura:
- Pianificare l'ambiente.
- Distribuire le macchine virtuali.
- Aggiornare SUSE 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 Distribuito/Disponibilità elevata (SWPM).
- Installare e creare un nodo e un'istanza di database secondari e configurare HADR.
- Verificare che HADR funzioni.
- Applicare la configurazione di Pacemaker per controllare IBM Db2.
- Configurare Azure Load Balancer.
- Installare i server applicazioni primari e con finestre 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 (database parte dell'ambiente SAP) sono elencati nella tabella seguente:
| Argomento | Descrizione breve |
|---|---|
| Definire i gruppi di risorse di Azure | Gruppi di risorse in cui si esegue la distribuzione di macchina virtuale, rete virtuale, Azure Load Balancer e altre risorse. Può essere nuovo o esistente. |
| Definizione della subnet/rete virtuale | In cui vengono distribuite le macchine virtuali per IBM Db2 e Azure Load Balancer. Possono essere esistenti o appena creati. |
| 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 usati per la connessione dei server applicazioni SAP. db-virt-hostname, db-virt-ip. |
| Isolamento tramite Azure | Isolamento tramite Azure o SBD (altamente consigliato). Metodo per evitare situazioni di split brain. |
| Macchina virtuale SBD | Dimensioni, archiviazione e rete della macchina virtuale SBD. |
| Azure Load Balancer | Utilizzo del servizio Standard (scelta consigliata), porta probe per il database Db2 (si consiglia la porta 62500) porta probe. |
| 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 su SUSE Linux Enterprise Server in Azure.
Importante
Per Db2 versione 11.5.6 e successive è consigliabile la soluzione integrata che usa Pacemaker di IBM.
Distribuzione in SUSE Linux
L'agente di risorse per IBM Db2 LUW è incluso in SUSE Linux Enterprise Server per le applicazioni SAP. Per la configurazione descritta in questo documento, è necessario usare SUSE Linux Server applicazioni SAP. Azure Marketplace contiene un'immagine per SUSE Enterprise Server per applicazioni SAP 12 che è possibile usare per distribuire nuove macchine virtuali di Azure. Tenere presente i vari modelli di supporto o di servizio offerti da SUSE tramite Azure Marketplace quando si sceglie un'immagine della macchina virtuale nel marketplace della macchina virtuale Azure.
Host: aggiornamenti del DNS
Creare un elenco di tutti i nomi host, inclusi i nomi host virtuali e aggiornare i server DNS per abilitare l'indirizzo IP corretto per la risoluzione dei nomi host. 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 del 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 le versioni di Db2 è disponibile nella nota SAP 1928533. L'elenco delle versioni del sistema operativo in base alla singola versione di Db2 è disponibile nel documento Product Availability Matrix di SAP. È consigliabile usare almeno SLES 12 SP4 per i miglioramenti delle prestazioni correlati ad Azure in questa o nelle versioni successive di SUSE 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 i dischi dati alle macchine virtuali e successivamente consultare le raccomandazioni sulla configurazione del file system nell'articolo Distribuzione DBMS per IBM Db2 di macchine virtuali di Azure per un carico di lavoro SAP.
Installare IBM Db2 LUW e l'ambiente 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 SAP usando lo strumento di ricerca della guida all'installazione SAP.
È possibile ridurre il numero di guide visualizzate nel portale impostando i filtri seguenti:
- I want to: "Install a new system"
- My Database: "IBM Db2 for Linux, Unix, and Windows"
- Altri filtri 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 per High availability o Distributed.
- Installare SAP ASCS/ERS e l'istanza di database.
- Eseguire un backup del database appena installato.
Importante
Annotare il valore di "Database Communication port" impostato durante l'installazione. Il numero di porta deve essere lo stesso 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 System copy>Target systems>Distributed>Database instance.
Come metodo di copia, selezionare Homogeneous System in modo da poter usare il backup per ripristinare un backup nell'istanza del server di 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, viene posta una domanda esplicita sulla disponibilità elevata per IBM Db2 LUW:
- Non selezionare IBM Db2 pureScale.
- Non selezionare Install IBM Tivoli System Automation for Multiplatforms.
- Non selezionare Generate cluster configuration files.
Quando si usa un dispositivo SBD per Linux Pacemaker, impostare i parametri HADR Db2 seguenti:
- HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 300
- HADR timeout value (HADR_TIMEOUT) = 60
Quando si usa un agente di isolamento Pacemaker per Azure, impostare i parametri seguenti:
- HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 900
- HADR timeout value (HADR_TIMEOUT) = 60
È consigliabile usare i parametri precedenti in base ai test iniziali di failover/acquisizione. È obbligatorio verificare che il failover e l'acquisizione funzionino correttamente con queste impostazioni dei parametri. Poiché le singole configurazioni possono variare, i parametri potrebbero richiedere modifiche.
Importante
Specifico per IBM Db2 con configurazione di HADR con avvio normale: l'istanza di database secondaria o standby deve essere attiva e in esecuzione prima di poter avviare l'istanza di database primaria.
A scopo dimostrativo e per le procedure descritte in questo articolo, il SID del database è PTR.
Controllo di HADR IBM Db2
Dopo aver configurato HADR e quando lo stato è PEER e CONNECTED nei nodi primario e di standby, eseguire il controllo 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 il servizio di bilanciamento del carico esistente 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 procedura descritta in Creare il servizio di bilanciamento del carico per configurare un servizio di bilanciamento del carico standard per un sistema SAP a disponibilità elevata usando il portale di Azure. Durante la configurazione del servizio di bilanciamento del carico, considerare i punti seguenti:
- Configurazione IP front-end: creare un indirizzo IP front-end. Selezionare la stessa rete virtuale e il nome della subnet delle macchine virtuali di database.
- Pool back-end: creare un pool back-end e aggiungere macchine virtuali di 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 un indirizzo IP front-end.
- Pool back-end: selezionare un pool back-end.
- Porte a disponibilità elevata: selezionare questa opzione.
- Protocollo: selezionare TCP.
- Probe di integrità: creare un probe di integrità con i dettagli seguenti:
- Protocollo: selezionare TCP.
- Porta: ad esempio, 625<instance-no.>.
- Intervallo: immettere 5.
- Soglia probe: immettere 2.
- Timeout di inattività (minuti): immettere 30.
- Abilita IP mobile: selezionare questa opzione.
Nota
La proprietà di configurazione del probe di integrità numberOfProbes, altrimenti nota come soglia non integra nel portale, non viene rispettata. Per controllare il numero di probe consecutivi riusciti o non riusciti, impostare la proprietà probeThreshold su 2. Non è attualmente possibile impostare questa proprietà usando il portale di Azure, quindi usare l'interfaccia della riga di comando di Azure o il comando di PowerShell.
Nota
Se vengono inserite macchine virtuali senza indirizzi IP pubblici nel pool back-end di un'istanza di Load Balancer Standard interno ad Azure (nessun indirizzo IP pubblico), non è presente alcuna connettività Internet in uscita, a meno che non venga eseguita un’altra configurazione per consentire il routing a endpoint pubblici. Per maggiori informazioni su come ottenere la connettività in uscita, vedere Connettività degli endpoint pubblici per le macchine virtuali usando Load Balancer Standard di Azure negli scenari a disponibilità elevata SAP.
Importante
Non abilitare i timestamp TCP nelle macchine virtuali di Azure che si trovano dietro Azure Load Balancer. Se si abilitano i timestamp TCP, i probe di integrità potrebbero avere esito negativo. 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 Configurazione di Pacemaker su SUSE 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 di Db2 e Pacemaker. Questa sezione descrive questo tipo di configurazione.
Gli elementi seguenti sono preceduti da uno degli elementi seguenti:
- [A]: applicabile a tutti i nodi
- [1]: applicabile solo al nodo 1
- [1]: applicabile solo al nodo 2
[A] Prerequisiti per la configurazione di Pacemaker:
- Arrestare entrambi i server di database con l'utente db2<sid> 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 di Pacemaker specifica per IBM Db2 HADR:
# 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 in modalità Fuori 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 corretto e che tutte le risorse siano avviate. Non è importante il nodo su cui sono in esecuzione le risorse.
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 Db2 di Pacemaker in cluster usando gli strumenti di 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 dell'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 i server applicazioni primari e con finestre di dialogo
Quando si installano server applicazioni primari e server di dialogo in una configurazione Db2 HADR, usare il nome host virtuale scelto per la configurazione.
Se l'installazione è stata eseguita prima di creare la configurazione Db2 HADR, apportare le modifiche come descritto nella sezione precedente e come indicato di seguito per gli stack Java di SAP.
Controllo dell'URL JDBC per i sistemi stack ABAP+Java o Java
Usare lo strumento di configurazione J2EE per controllare o aggiornare l'URL JDBC. Poiché lo strumento di configurazione J2EE è uno strumento grafico, è necessario che sia installato il server X:
Accedere al server applicazioni primario dell'istanza di J2EE ed eseguire:
sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.shNel riquadro sinistro scegliere archivio di sicurezza.
Nel frame a destra 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 di 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 di standby devono essere in grado di recuperare i file di archivio dei log da tutte le posizioni di archiviazione dei log in cui una delle istanze di 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 nel 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 per una directory del profilo. Per altre informazioni, vedi:
- Disponibilità elevata per NFS in macchine virtuali di Azure su SUSE Linux Enterprise Server.
- Disponibilità elevata per SAP NetWeaver su macchine virtuali di Azure su SUSE 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 la configurazione Db2 HADR. Ogni test presuppone che l'utente abbia eseguito l'accesso come utente root e che l'istanza primaria IBM Db2 sia in esecuzione nella macchina virtuale azibmdb01.
Lo stato iniziale per tutti i test case è illustrato qui: (crm_mon -r o crm status)
- crm status è uno snapshot dello stato di Pacemaker in fase di esecuzione.
- crm_mon -r è l'output continuo dello stato di 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 Transaction DBACOCKPIT > Configuration > Overview, come illustrato nell'immagine seguente:
Acquisizione di test di IBM Db2
Importante
Prima di avviare il test, assicurarsi che:
In Pacemaker non ci siano azioni non riuscite (crm status).
Non esistano vincoli di posizione (residui del test di migrazione).
La sincronizzazione di IBM Db2 HADR funzioni. 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 di crm status è 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 Transaction DBACOCKPIT > Configuration > Overview, 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 in 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 con l'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, viene testato l'isolamento tramite SBD, che è consigliabile eseguire quando si usa SUSE 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 di IBM Db2 verrà spostato in azibmdb02. Quando azibmdb01 è di nuovo online, l'istanza di Db2 viene spostata nel ruolo di un'istanza di database secondaria.
Se il servizio Pacemaker non viene avviato automaticamente nell'istanza primaria precedentemente riavviata, 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 avviare nuovamente 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 ha 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 di database primaria Db2 nello stesso nodo oppure esegue il failover nel nodo che esegue l'istanza di database secondaria 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 di database secondaria
azibmdb02:~ # ps -ef|grep db2s
db2ptr 65250 65248 0 Feb11 ? 00:09:27 db2sysc 0
azibmdb02:~ # kill -9
Il nodo si trova in uno stato di operazione non riuscita 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 di 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> eseguire il comando 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 di database secondaria Db2 HADR è 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 di database primaria HADR
#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger
Pacemaker alza di livello l'istanza secondaria al ruolo dell'istanza primaria. L'istanza primaria precedente viene 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 di database primaria HADR con "halt"
#Linux kernel panic - halts OS
azibmdb01:~ # echo b > /proc/sysrq-trigger
In questo caso Pacemaker rileva che il nodo che esegue l'istanza di database primaria 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 presenza di una situazione Split brain. Dopo che il nodo integro ha determinato che il nodo che ha eseguito per ultimo l'istanza di database primaria è 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 interruzione del nodo, il nodo non riuscito deve essere riavviato tramite gli strumenti di gestione di Azure (nel portale di Azure, in PowerShell o nell'interfaccia della riga di comando di Azure). Quando 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 ]
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per