Installazione e configurazione di PostgreSQL in ambienti a disponibilità elevata
Di seguito sono riportate le linee guida per supportare l'implementazione del diagramma precedente. Sono destinate agli amministratori di PostgreSQL e agli utenti che implementano una distribuzione di PostgreSQL a disponibilità elevata.
Per riferimento, l'esempio di distribuzione di PostgreSQL in ambienti a diponibilità elevata con Pgpool-II contiene una procedura dettagliata di esempio di download, sequenze di riga di comando e script utilizzati per implementare questa soluzione.
Documentazione di riferimento
Prima di installare PostgreSQL, leggere con attenzione tutti i documenti di installazione e di configurazione, inclusa la documentazione relativa al software prerequisito richiesto. È importante comprendere e applicare le impostazioni appropriate, inclusi i consigli di protezione.
I link riportati di seguito forniscono informazioni utili per l'installazione e la configurazione a disponibilità elevata di PostgreSQL utilizzando la replica di streaming e Pgpool-II per la gestione dei nodi.
Installazione di PostgreSQL e creazione di un nuovo ruolo utente in PostgreSQL
Le istruzioni per installare e configurare PostgreSQL sono disponibili nella guida Installazione di ThingWorx. Fare riferimento alla guida all'installazione per la versione specifica di ThingWorx da distribuire. È necessario eseguire gli stessi task di installazione e configurazione su tutti e tre i nodi PostgreSQL.
Configurazione ed esecuzione dello script del database PostgreSQL
Le istruzioni per creare il database in PostgreSQL sono disponibili nella guida Installazione di ThingWorx. Fare riferimento alla guida all'installazione per la versione specifica di ThingWorx da distribuire. È necessario eseguire gli stessi task di installazione e configurazione su tutti e tre i nodi PostgreSQL.
Configurazione ed esecuzione dello script dello schema del provider di modelli/dati
Le istruzioni per la creazione dello schema di ThingWorx in PostgreSQL sono disponibili nella guida Installazione di ThingWorx. Fare riferimento alla guida all'installazione per la versione specifica di ThingWorx da distribuire. È necessario eseguire gli stessi task di configurazione su tutti e tre i nodi PostgreSQL.
Creare un utente di replica su tutti i nodi PostgreSQL
Creare un utente PostgreSQL per gestire i task di replica su tutti i nodi. È necessario utilizzare lo stesso nome utente e la stessa password.
Aggiungere parametri di replica a tutti i nodi PostgreSQL
La tabella riportata di seguito contiene i parametri PostgreSQL che controllano i rispettivi servizi di replica.
 |
I valori elencati nella colonna Configurazione riflettono la distribuzione di esempio nell'architettura di riferimento, ma non possono essere modificati nell'ambiente in uso. Per molte delle impostazioni della tabella vengono forniti link che aiutano a determinare i valori di configurazione appropriati per l'ambiente in uso.
|
|
Impostazione
|
Configurazione
|
Descrizione
|
|---|---|---|
|
listen_addresses
|
'*'
|
Resta in ascolto su tutte le interfacce di rete. In alcune situazioni, se sono presenti più interfacce di rete, è preferibile limitarsi a interfacce di rete specifiche.
|
|
Porta
|
5432
|
Il numero di porta di default.
|
|
max_connections
|
200
|
Il valore di default in PostgreSQL è 100. Anche in ThingWorx il valore di default è 100 (maxpoolsize). Aumentare questo valore in base al numero totale di connessioni simultanee previste nel database. Deve essere sempre maggiore del numero di server nel cluster per la dimensione massima del pool configurata nel file platform-settings.json per ThingWorx.
|
|
shared_buffers
|
1024MB
|
Ottimizzazione delle prestazioni facoltativa. Imposta la quantità di memoria che il server di database utilizza per i buffer di memoria condivisa. È consigliabile impostare questa opzione su un quarto della memoria disponibile nel computer. Fare riferimento a Resource Consumption > Memory.
|
|
work_mem
|
32MB
|
Ottimizzazione delle prestazioni facoltativa. Specifica la quantità di memoria che viene utilizzata dalle operazioni di ordinamento interno e dalle tabelle hash prima di scrivere in file di disco temporanei. Fare riferimento a Resource Consumption > Memory. Scorrere verso il basso fino a work_mem.
|
|
maintenance_work_mem
|
512MB
|
Ottimizzazione delle prestazioni facoltativa. Specifica la quantità massima di memoria che deve essere utilizzata dalle operazioni di manutenzione. Fare riferimento a Resource Consumption > Memory. Questa opzione viene visualizzata subito dopo work_mem.
|
|
wal_level
|
enum
|
Ottimizzazione delle prestazioni facoltativa. Specifica la quantità massima di memoria che deve essere utilizzata dalle operazioni di manutenzione. Fare riferimento a Write Ahead Log > Settings.
|
|
synchronous_commit
|
il
|
Accedere a Write Ahead Log > Settings e scorrere verso il basso fino a synchronous_commit (enum).
|
|
archive_mode
|
il
|
|
|
archive_command
|
'cd.'
|
Accedere a Write Ahead Log > Archiving e scorrere verso il basso fino ad archive_command (string).
|
|
max_wal_size
|
10
|
Accedere a Write Ahead Log e fare clic sul link ARCHIVING. Scorrere verso l'alto fino a max_wal_size (integer). Per informazioni dettagliate sulla configurazione WAL, fare riferimento a WAL Configuration nella documentazione di PostgreSQL 10.
|
|
synchronous_standby_names
|
node1, node2 o node2, node0 o node0, node1
|
Come elenco separato da virgole, aggiungere "application_name" dell'altro nodo, come specificato nei rispettivi file recovery.conf. Vedere synchronous_commit nella sezione delle impostazioni di Write Ahead Log.
|
|
hot_standby
|
True/False
|
Per informazioni su questa modalità, fare riferimento a Hot Standby.
|
|
fsync
|
il
|
Accedere a Write Ahead Log > Settings e scorrere verso il basso fino a fsync.
|
|
impostazioni dei checkpoint
|
Per informazioni sulle impostazioni dei checkpoint, fare riferimento a Checkpoints.
|
Specifica degli script start_replication e retargetMaster
In ogni nodo definire uno script per attivare i servizi di replica e assicurarsi che il nodo PostgreSQL sia sincronizzato con il sistema.
Sempre su ciascun nodo definire uno script in grado di creare e implementare un file recovery.conf. Il file recovery.conf deve contenere le modifiche necessarie per stabilire qual è il nodo master e qual è quello di standby, a seconda dell'errore che si verifica.
Impostazione dei parametri di connessione esterni per tutti i nodi PostgreSQL
Modificare i parametri in ogni file pg_hba.conf per consentire all'utente e al database di memorizzare i dati di ThingWorx a cui accedere dall'IP. Questo IP si connetterà al database.
|
|
Se si effettua la connessione da Pgpool-II, verificare che l'accesso di autenticazione sia conforme alla documentazione di Pgpool-II (md5 o trust) disponibile qui.
|
Per ulteriori informazioni sul file pg_hba.conf, fare riferimento al file pg_hba.conf nella documentazione di PostgreSQL 10.
Riavvio dei servizi PostgreSQL per iniziare la replica
Riavviare tutti i nodi PostgreSQL in sequenza per controllare qual è il nodo master (avviato per primo), qual è quello di standby principale (avviato per secondo) e qual è il terzo (avviato per ultimo).
Per il nodo master, avviare i servizi PostgreSQL.
Per il nodo di standby principale, eseguire prima lo script start_replication per sincronizzarlo con il nodo master. Quindi avviare i servizi PostgreSQL.
Per il secondo nodo di standby, eseguire prima lo script start_replication per sincronizzarlo con il nodo di standby principale. Quindi avviare i servizi PostgreSQL.
Installazione dei nodi Pgpool-II
Prima di installare Pgpool, leggere con attenzione tutti i documenti di installazione, inclusa la documentazione relativa al software prerequisito necessario. È importante comprendere e applicare le impostazioni appropriate, inclusi i consigli di protezione.
Le informazioni di download per Pgpool-II sono disponibili qui:
Per istruzioni sull'installazione di Pgpool-II, consultare la documentazione del sistema operativo. Per eseguire i servizi Pgpool-II, è necessario che in tutti i nodi sia installata la stessa versione di Pgpool-II.
Configurazione dei nodi Pgpool-II
La tabella riportata di seguito contiene i parametri da modificare per un'installazione di Pgpool-II. Tutti i parametri Pgpool-II vengono mantenuti nel file pgpool.conf. Tali proprietà e valori devono essere aggiunti a tutti i nodi Pgpool-II.
|
Impostazione
|
Valore
|
Descrizione
|
||
|---|---|---|---|---|
|
listen_addresses
|
'*'
|
Scegliere i valori che consentono al provider di modelli dell'applicazione ThingWorx di connettersi a Pgpool-II, che si trovi sullo stesso server o su un server diverso.
|
||
|
port
|
5432
|
Porta TCP per l'ascolto delle connessioni client
|
||
|
pcp_listen_address
|
*
|
Filtro IP/host per connessioni PCP (Port Control Protocol) (* consente tutto)
|
||
|
pcp_port
|
9898
|
Porta TCP per l'ascolto delle connessioni PCP
|
||
|
backend_hostname
backend_port
backend_weight
backend_data_directory
backend_flag
|
<ip of backend#>
<porta di back-end n.>
1
/var/lib/postgresql/10.x/main
ALLOW_TO_FAILOVER
|
Impostare i valori di configurazione del back-end per ciascuno dei tre nodi (il nodo master e i due nodi di standby). Ad esempio, backend_hostname0 è il nodo master, backend_hostname1 è il nodo di standby uno e così via. Per ulteriori informazioni, fare riferimento alla documentazione in linea di PostgreSQL.
|
||
|
enable_pool_hba
|
il
|
Attiva pool_hba.conf
|
||
|
master_slave_mode
|
il
|
Indica a PostgreSQL che viene utilizzata la replica master/standby.
|
||
|
load_balance_mode
|
off
|
|
||
|
master_slave_sub_mode
|
flusso
|
Indica a Pgpool-II di utilizzare la replica di streaming PostgreSQL predefinita.
|
||
|
replication_mode
|
off
|
Non utilizzare la replica di Pgpool-II, bensì la replica di streaming PostgreSQL predefinita.
|
||
|
sr_check_period
|
10
|
Ritardo della replica di streaming in secondi
|
||
|
sr_check_user
|
replicator
|
Utente della replica di streaming
|
||
|
sr_check_password
|
replicator
|
Password della replica di streaming
|
||
|
sr_check_database
|
postgres
|
Database della replica di streaming
|
||
|
health_check_user
|
postgres
|
Utente del controllo dello stato del failover
|
||
|
health_check_password
|
postgres
|
Password del controllo dello stato del failover
|
||
|
health_check_database
|
postgres
|
Database del controllo dello stato del failover
|
||
|
failover_command
|
/etc/pgpool2/failover.sh %d %h %D %m %H %R %M %P
|
Per ulteriori informazioni su questa impostazione, vedere la sezione failover_command riportata di seguito.
Vedere inoltre gli script di esempio seguenti nell'Appendice C:
• failover.sh
• retargetMaster_001.sh
• retargetMaster_002.sh
• retargetMaster_003.sh
|
||
|
num_init_children
max_pool
max_child_connections
superuser_reserved_connections
|
Parametri di ottimizzazione delle prestazioni. Queste impostazioni sono correlate alle funzionalità di pool di connessioni di Pgpool-II. Assicurarsi di fornire un numero sufficiente di connessioni all'avvio, necessarie per le specifiche esigenze di throughput del traffico di volumi di dati più elevati e di non superare il numero massimo di connessioni impostato per i nodi del database PostgreSQL. Fare riferimento alla sezione del manuale relativa ai pool (vedere il link sopra) per suggerimenti e formule per il calcolo dei valori.
|
Configurare lo script di failover PostgreSQL
Definire uno script di failover in ogni nodo Pgpool-II che il servizio Pgpool-II chiamerà quando vengono rilevati errori. Questo script deve contenere la logica e i task da eseguire per qualsiasi errore dei nodi PostgreSQL.
Fare riferimento alla sezione failover della documentazione di PostgreSQL 10 online.
Aggiornamento della configurazione PCP
Aggiornare il file pool_hba.conf per riconoscere tutti i server ThingWorx.
Per le richieste ThingWorx a PostgreSQL, Pgpool-II si connetterà ai nodi PostgreSQL utilizzando le credenziali ThingWorx per gestire i privilegi e le limitazioni di accesso stabiliti. Il file pool_hba.conf utilizza lo stesso formato, gli stessi metodi di autenticazione e le stesse opzioni di autenticazione (md5, trust e così via) di pg_hba.conf.
Per informazioni dettagliate sulla configurazione di pool_hba.conf, vedere http://www.pgpool.net/docs/latest/en/html/client-authentication.html.
Aggiornamento dell'autenticazione client
Aggiornare il file pool_hba.conf per riconoscere tutti i server ThingWorx.
Per le richieste ThingWorx a PostgreSQL, Pgpool-II si connetterà ai nodi PostgreSQL utilizzando le credenziali ThingWorx per gestire i privilegi e le limitazioni di accesso stabiliti. Il file pool_hba.conf utilizza lo stesso formato, gli stessi metodi di autenticazione e le stesse opzioni di autenticazione (md5, trust e così via) di pg_hba.conf.
Per informazioni dettagliate sulla configurazione di pool_hba.conf, vedere http://www.pgpool.net/docs/latest/en/html/client-authentication.html.
Configurazione di Pgpool-II per il failover
Nelle configurazioni a disponibilità elevata Pgpool-II ha un funzionamento attivo/passivo, in genere con un nodo Pgpool-II attivo e un nodo di standby. Pgpool-II fornisce il processo del watchdog per monitorare lo stato del nodo e attiva il nodo di standby in caso di errore del nodo principale.
Per ulteriori informazioni e per informazioni sulla configurazione del watchdog, consultare la documentazione di Pgpool (http://www.pgpool.net/docs/latest/en/html/example-watchdog.html).
La tabella che segue contiene le impostazioni e i valori da considerare durante la configurazione del watchdog in Pgpool-II. Queste impostazioni e i valori devono essere aggiunti al file pgpool.conf di ogni nodo Pgpool-II.
|
Impostazione
|
Valore
|
Descrizione
|
|---|---|---|
|
use_watchdog
|
il
|
Attiva il watchdog in Pgpool-II
|
|
wd_hostname
|
'{IP address of this Pgpool-II node}'
|
Nome host o indirizzo IP di questo watchdog
|
|
wd_port
|
9000
|
Numero di porta di questo watchdog
|
|
delegate_IP
|
'{Virtual IP address to access PostgreSQL}'
|
Indirizzo IP virtuale utilizzato dai client per accedere a PostgreSQL (attraverso Pgpool-II)
|
|
ifconfig_path
|
/etc/pgpool2
|
Percorso assoluto della directory contenente gli script o i comandi if_up_cmd e if_down_cmd.
|
|
if_up_cmd
|
'ifup.sh $_IP_$ <eni id of Pgpool node>'
|
Il comando che viene eseguito quando Pgpool-II prova a visualizzare l'interfaccia IP virtuale con l'indirizzo delegate_IP. È possibile recuperare l'ID eni del nodo Pgpool-II accedendo alla console di amministrazione EC2 e alla propria istanza Pgpool-II. Nella relativa descrizione nella console individuare la voce Network interfaces, fare clic su eth0 e individuare l'ID dell'interfaccia. Utilizzarlo per $<eni id of Pgpool node>.
|
|
if_down_cmd
|
'ifdown.sh $_IP_$ <eni id of Pgpool node>'
|
Il comando che viene eseguito quando Pgpool-II prova a chiudere l'interfaccia IP virtuale con l'indirizzo delegate_IP. Vedere if_up_cmd per ottenere l'ID eni del nodo Pgpool-II.
|
|
arping_path
|
/usr/bin
|
Percorso del package di installazione iputils-arping
|
|
arping_cmd
|
arping -U $_IP_$ -w 1
|
Il comando arping utilizzato per verificare gli IP.
|
|
heartbeat_destination0
|
'{IP address of the other Pgpool-II node}'
|
L'indirizzo IP su cui viene eseguito il controllo heartbeat; il valore dell'impostazione other_pgpool_hostname0
|
|
heartbeat_destination_port0
|
9694
|
Utilizzare il valore di default.
|
|
heartbeat_device
|
'eth0'
|
Il dispositivo NIC per l'indirizzo IP per la comunicazione heartbeat
|
|
other_pgpool_hostname0
|
'{IP address of the other Pgpool-II node}'
|
L'indirizzo IP dell'altra istanza del server Pgpool-II
|
|
other_pgpool_port0
|
5432
|
La porta su cui è in ascolto l'altro nodo Pgpool-II
|
|
other_wd_port0
|
9000
|
La porta su cui è in ascolto l'altra funzionalità watchdog Pgpool-II
|