Image

Tutorial Cluster Postgre-XL con 5 Servers

Postgre-XL Tutorial di installazione, configurazione e test per applicazioni B.I. + Analytics

Con questo tutorial vi accompagnerò nell'installazione, la configurazione e test di un cluster Postgres-XL per uso in Businnes Intelligence + Analytics.

I Componenti

  • Global Transaction Manager (GTM)
    Il componente Global Transaction Manager ( GTM ) garantisce la coerenza dei dati all'interno del cluster e gestisce le transazioni e la versione delle tabelle e dei record. Il GTM può essere migliorato con uno o più standby che prendono il controllo in caso di guasti.
  • Coordinatore (Coordinator)
    Il coordinatore (coordinator) gestisce tutto ciò che è sessioni utente e interagisce con le GTM nodi e dati. Riceve le query, avvia i piani di esecuzione e li distribuisce ai nodi dei dati. Diversi coordinatori possono
    essere definiti per distribuire il carico.
  • Nodo dati (Datanode)
    Il nodo dei dati (Datanode) memorizza i immagazzina i dati.
    Esegue anche le query gestite e inviate dai (coordinatori).

Il Cluster
Sono necessari tre nodi per creare un cluster Postgres-XL anche se in realtà  solo un nodo può supportare tutti e tre i tipi di componenti. Tuttavia, questo scenario rimuove tutta la logica di distribuzione fornita da Postgres-XL.
Nel caso normale, un cluster minimalista avrebbe un nodo Global Transaction Manager (GTM), un nodo Coordinatore e due datanode.

Prerequisiti
Come indicazione forniamo gli indirizzi IP che abbiamo usato.
Questi possono essere modificati se vuoi sperimentare sul tuo cluster.
Ecco la scomposizione che abbiamo selezionato per questo esperimento.

  • Nodo 1:
    ruolo: GTM (Global Transaction Manager);
    hostname: pgxl-1
    host: gtm
    IP: 192.168.1.14
  • Nodo 2:
    ruolo: coordinatore;
    hostname: pgxl-2
    host: coord
    IP: 192.168.1.15
  • Nodo 3:
    Ruolo: datanode
    hostname: pgxl-3
    Host: dn1
    IP: 192.168.1.16
  • Nodo 4:
    ruolo: datanode;
    hostname: pgxl-4
    host: dn2
    IP: 192.168.1.17
  • Nodo 5:
    ruolo: Slave di un datanode;
    hostname: pgxl-5
    host: dn2
    IP: 192.168.1.18

Software necessario

  • S.O.: Centos 7 64bit
  • Sorgenti: Postgres-XL

Accedere con l'utente root
$ sudo - su

Disattivare le regole di SELINUX
# sed -i 's/SELINUX=.*/SELINUX=disabled/' /etc/sysconfig/selinux && setenforce 0

Disattivare il servizio del Firewall
# systemctl stop firewalld && systemctl disable firewalld

Installazione dei pacchetti necessari per la compilazione e installazione di postgres-XL
# yum install ansible readline-devel readline zlib-devel wget zip autoconf automake binutils \
bison flex gcc gcc-c++ gettext libtool make patch pkgconfig redhat-rpm-config rpm-build \
rpm-sign python36 python36-devel

Creazione dell'utente postgres
# useradd postgres --shell /bin/bash --home /home/postgres --create-home
# echo -e 'postgres\npostgres\n' | sudo passwd postgres

Aggiungiamo l'utente postgres al gruppo sudo, questa operazione deve essere fatta per tutti i server del cluster
# usermod -aG wheel postgres

Adesso occorre cambiare l'utente passando da root a postgres
su postgres

Creare le chiavi publiche per l'accesso via ssh
Nel server "pgxl-1" occorre generare la chiave di autenticazione per l'ssh,
$ ssh-keygen -t rsa (Alle richieste premere ENTER confermando tutti i valori standard)
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Aggiungere le chiavi necessarie per ogni server dentro del file "authorized_keys"
$ vi ~/.ssh/authorized_keys

dentro di "vi" digitare la sequenza di tasti "yyp" duplicando la prima linea per il numero di server usati.

Appena finita la duplicazione delle linee occorre andare alla fine di ogni linea e al posto di "postgres@pgxl-1" sostituiremo con il nome di ogni server.

Esempio:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCreLboiGllZVmqzneEWnPk9+v6bCQYZjnpyFKUsYkSkMjjhh+ocoDOcFqT0XfMiYV/d6
dqI7ILYOs5BhJgF8cvxWYKng1Cu4hSzGMdIHsyFljR2s/0W51U8HCtt+YOtuo0Q7dN4Tfwoq1lBgfjRBLP/MxQob/3oh4+Q3aDhQjTNQnL
MvrayFp2cJV/sBnVzYuevRgSxCD3r42cfvjpEqFL6nMs6/KsxsWkE+dklMi916pATUfUmL1i2X7Pd5qB8s6HAeX90Gsby2BK8X+y0IEs93
MFpBmiBmH2a+seOgJULd3dDOSLzSe8Q+3HndPNsDs09f3Cja4hOZ76n+5ylGSD postgres@pgxl-1
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCreLboiGllZVmqzneEWnPk9+v6bCQYZjnpyFKUsYkSkMjjhh+ocoDOcFqT0XfMiYV/d6
dqI7ILYOs5BhJgF8cvxWYKng1Cu4hSzGMdIHsyFljR2s/0W51U8HCtt+YOtuo0Q7dN4Tfwoq1lBgfjRBLP/MxQob/3oh4+Q3aDhQjTNQnL
MvrayFp2cJV/sBnVzYuevRgSxCD3r42cfvjpEqFL6nMs6/KsxsWkE+dklMi916pATUfUmL1i2X7Pd5qB8s6HAeX90Gsby2BK8X+y0IEs93
MFpBmiBmH2a+seOgJULd3dDOSLzSe8Q+3HndPNsDs09f3Cja4hOZ76n+5ylGSD postgres@pgxl-2
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCreLboiGllZVmqzneEWnPk9+v6bCQYZjnpyFKUsYkSkMjjhh+ocoDOcFqT0XfMiYV/d6
dqI7ILYOs5BhJgF8cvxWYKng1Cu4hSzGMdIHsyFljR2s/0W51U8HCtt+YOtuo0Q7dN4Tfwoq1lBgfjRBLP/MxQob/3oh4+Q3aDhQjTNQnL
MvrayFp2cJV/sBnVzYuevRgSxCD3r42cfvjpEqFL6nMs6/KsxsWkE+dklMi916pATUfUmL1i2X7Pd5qB8s6HAeX90Gsby2BK8X+y0IEs93
MFpBmiBmH2a+seOgJULd3dDOSLzSe8Q+3HndPNsDs09f3Cja4hOZ76n+5ylGSD postgres@pgxl-3
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCreLboiGllZVmqzneEWnPk9+v6bCQYZjnpyFKUsYkSkMjjhh+ocoDOcFqT0XfMiYV/d6
dqI7ILYOs5BhJgF8cvxWYKng1Cu4hSzGMdIHsyFljR2s/0W51U8HCtt+YOtuo0Q7dN4Tfwoq1lBgfjRBLP/MxQob/3oh4+Q3aDhQjTNQnL
MvrayFp2cJV/sBnVzYuevRgSxCD3r42cfvjpEqFL6nMs6/KsxsWkE+dklMi916pATUfUmL1i2X7Pd5qB8s6HAeX90Gsby2BK8X+y0IEs93
MFpBmiBmH2a+seOgJULd3dDOSLzSe8Q+3HndPNsDs09f3Cja4hOZ76n+5ylGSD postgres@pgxl-4
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCreLboiGllZVmqzneEWnPk9+v6bCQYZjnpyFKUsYkSkMjjhh+ocoDOcFqT0XfMiYV/d6
dqI7ILYOs5BhJgF8cvxWYKng1Cu4hSzGMdIHsyFljR2s/0W51U8HCtt+YOtuo0Q7dN4Tfwoq1lBgfjRBLP/MxQob/3oh4+Q3aDhQjTNQnL
MvrayFp2cJV/sBnVzYuevRgSxCD3r42cfvjpEqFL6nMs6/KsxsWkE+dklMi916pATUfUmL1i2X7Pd5qB8s6HAeX90Gsby2BK8X+y0IEs93
MFpBmiBmH2a+seOgJULd3dDOSLzSe8Q+3HndPNsDs09f3Cja4hOZ76n+5ylGSD postgres@pgxl-5

Dal server "pgxl-1", copiare la directory .ssh nel server pgxl-2, pgxl-3, pgxl-4 e pgxl-5
$ scp -rp ~/.ssh/ postgres@pgxl-2:~/
$ scp -rp ~/.ssh/ postgres@pgxl-3:~/
$ scp -rp ~/.ssh/ postgres@pgxl-4:~/
$ scp -rp ~/.ssh/ postgres@pgxl-5:~/

In tutti i server è necessario cambiare i permessi ai file delle password dell'utente postgres.
$ ssh postgres@pgxl-1 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
$ ssh postgres@pgxl-2 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
$ ssh postgres@pgxl-3 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
$ ssh postgres@pgxl-4 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
$ ssh postgres@pgxl-5 "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Dal server "pgxl-1" provare a connettersi al server pgxl-2, pgxl-3, pgxl-4 e pgxl-5, e accertarsi che non e richiesta la password
$ ssh postgres@pgxl-2
$ ssh postgres@pgxl-3
$ ssh postgres@pgxl-4
$ ssh postgres@pgxl-5

Posizioniamoci dentro la directory /home/postgres del server "pgxl-1"
cd /home/postgres

Facciamo il download del pacchetto contente il sorgente di postgres-xl
Se facciamo il download dal sito ufficiale useremo il comando in basso
wget https://sourceforge.net/projects/postgres-xl/files/Releases/Version_9.5r1/postgres-xl-9.5r1.4.tar.gz

Copiamo il file appena scaricato in tutti i server del cluster
scp postgres-xl-9.5r1.4.tar.gz postgres@pgxl-2:~/ &&\
scp postgres-xl-9.5r1.4.tar.gz postgres@pgxl-3:~/ &&\
scp postgres-xl-9.5r1.4.tar.gz postgres@pgxl-4:~/ &&\
scp postgres-xl-9.5r1.4.tar.gz postgres@pgxl-5:~/

Scompattiamo dentro di ogni rispettivo server il file postgres-xl-9.5r1.4.tar.gz
ssh pgxl-1 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/"
ssh pgxl-2 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/"
ssh pgxl-3 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/"
ssh pgxl-4 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/"
ssh pgxl-5 "tar -zxvf /home/postgres/postgres-xl-9.5r1.4.tar.gz -C /home/postgres/"

Adesso per ogni server del cluster configriamo il codice sorgente e compiliamolo
ssh pgxl-1 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make"
ssh pgxl-2 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make"
ssh pgxl-3 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make"
ssh pgxl-4 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make"
ssh pgxl-5 "cd /home/postgres/postgres-xl-9.5r1.4 && ./configure && make"

Installare Postgres-XL come utente "root" ma prima dobbiamo uscire dall'utente postgres in tutti i servers
exit
ssh root@pgxl-1 "cd /home/postgres/postgres-xl-9.5r1.4 && make install"
ssh root@pgxl-2 "cd /home/postgres/postgres-xl-9.5r1.4 && make install"
ssh root@pgxl-3 "cd /home/postgres/postgres-xl-9.5r1.4 && make install"
ssh root@pgxl-4 "cd /home/postgres/postgres-xl-9.5r1.4 && make install"
ssh root@pgxl-5 "cd /home/postgres/postgres-xl-9.5r1.4 && make install"

N.B.: Per default, Postgres-XL è installato nella directory /usr/local/pgsql/.

Installare pgxc_ctl solamente sul server "pgxl-1"
nella home dell'utente "postgres", entrare nella directory di pgxc_ctl
cd /home/postgres/postgres-xl-9.5r1.4/contrib/pgxc_ctl/
make

Una volta compilato il codice sorgente è necessario installare il modulo con l'utente "root"
exit
make install

Aggiungere "/usr/local/pgsql/bin" nel PATH per l'utente postgres
Adesso e necessario editare il file /home/postgres/.bashrc,
vi /home/postgres/.bashrc

Aggiungere alla fine del file la seguente linea:
export PATH=/usr/local/pgsql/bin:$PATH

N.B.: questa modifica deve essere fatta per ogni server del cluster.

Costruiamo il nostro cluster
La configurazione del cluster è facilitata dallo strumento pgxc_ctl del nodo 1.
Il nodo salva i suoi file di configurazione pre default in /home/postgres/pgxc_ctl ed è fatta principalmente attraverso il file /home/postgres/pgxc_ctl/pgxc_ctl.conf.
Le modifiche possono essere apportate modificando il file manualmente o tramite il comando pgxc_ctl e, in questo caso, useremo quest'ultimo per generare una versione standard del file di configurazione che personalizzeremo in seguito.

Entrare con l'utente postgres
Useremo l'utente postgres dando il comando nel server pgxl-1:
su postgres

Entriamo nella directory /home/postgres/
cd /home/postgres/

Eseguiamo il comando "pgxc_ctl" per la prima volta.
Il risultato sarà  un errore ma creerà  la directory "pgxc_ctl"
pgxc_ctl

Una volta dentro la console di gestione del cluster digiteremo il comando
PGXL prepare config empty

Questo è il momento di personalizzare la configurazione del cluster
vi /home/postgres/pgxc_ctl/pgxc_ctl.conf

Modifichiamo solamente questi tre valori:
# user and path
pgxcOwner=postgres
# L'amministratore del Cluster

# coordinator
coordPgHbaEntries=(192.168.1.0/24)
# Suppone che tutti i coordinatori (master/slave) accettino la stessa connessione
datanodePgHbaEntries=(xxx.yyy.zzz.0/24) # Suppone che tutti i coordinatori (master/slave) accettino la stessa connessione

Il prossimo passo è usare pgxc_ctl per aggiungere i nodi del cluster.
Vengono specificati solo i parametri principali, ovvero il nome del nodo, il suo indirizzo, le porte di connessione e la directory di lavoro.
Il primo nodo da aggiungere sarà  il nodo di gestione (GTM).

Aggiungere il nodo GTM (Global Transaction Manager)
PGXC add gtm master gtm 192.168.1.14 20001 /home/postgres/pgxc/gtm

Aggiungere il secondo nodo che sarà  il coordinatore.
PGXC add coordinator master coord1 192.168.1.15 20004 20010 /home/postgres/pgxc/gtm

Aggiungere il nodo dati datanode1.
PGXC add datanode master datanode1 192.168.1.16 20008 20012 /home/postgres/pgxc/dn1_master none none none

Aggiungere il secondo nodo dati datanode2
PGXC add datanode master datanode2 192.168.1.17 20009 20013 /home/postgres/pgxc/dn2_master none none none

Verificare se tutti i nodi del cluster siano in esecuzione
PGXC monitor all

Questo deve essere il risultado:
Running: gtm master
Running: coordinator master coord1
Running: datanode master datanode1
Running: datanode master datanode2

Sul nodo 1, eseguire il seguente comando per creare un database di test nel cluster.
PGXC pgxc_ctl Createdb test

Utilizzare lo strumento psql per connettersi al nodo coordinatore (nodo 2).
PGXC psql -h 192.168.1.15 -p 20004 test

Creare una tabella hash che verrà  distribuita tra i nodi del cluster in base a un hash della colonna id.
test=# create table hashed (id int, surname TEXT) DISTRIBUTE BY HASH(id);
test=# insert into hashed VALUES (1, 'test');

Eseguire il seguente comando per ottenere le informazioni dalla tabella.
Noteremo, nell'ultima riga, un'informazione che consente di conoscere il nodo su cui è memorizzata questa tabella.
test=# \d+ hashed

Eseguire il seguente comando per elencare le istanze di questa tabella.
test=# select * from hashed;

N.B.: Si noti che l'aggiunta di un altro nodo di dati non ridistribuisce automaticamente i dati già  inseriti.

Per verificare ciò, ci connetteremo al nodo 2 usando la console psql.
PGXC psql -h 192.168.1.15 -p 20004 test
test=# \d+ hashed

Per ridistribuire i dati dalla tabella hash al nuovo nodo, è sufficiente eseguire il seguente comando.
test=# ALTER TABLE hashed ADD NODE (datanode2);

Verifichiamo che i dati della tabella hash siano stati ridistribuiti al nuovo nodo di dati.
test=# \d+ hashed

Nel caso sia necessario aggiungere un nodo slave al nodo dati, sempre dal nodo GTM, eseguire il comando:
PGXC add datanode slave datanode1 192.168.1.xxx 40101 40111 /home/postgres/pgxc/dn1_slave none /home/postgres/pgxc/dn1_archlog.1

Assicuriamoci che il nostro cluster funzioni correttamente.
PGXC monitor all

Questo deve essere il risultado:
Running: gtm master
Running: coordinator master coord1
Running: datanode master datanode1
Running: datanode slave datanode1
Running: datanode master datanode2

È importante sapere che un nodo slave funziona nella replica dei dati di forma sincrona:
test=# EXECUTE DIRECT ON(datanode1) 'SELECT client_hostname, state, sync_state FROM pg_stat_replication';

Simulazione di un failover
Aggiungiamo alcuni dati alla tabella hash per convalidare questa replica.
test=# INSERT INTO hashed SELECT generate_series(1001,1100), 'foo';

Per trovare la distribuzione dei dati in base ai diversi nodi di dati, eseguire il comando seguente.
test=# SELECT p.node_host, p.node_name, count(*) FROM hashed h, pgxc_node p where h.xc_node_id = p.node_id GROUP BY p.node_name, p.node_host;

Per testare la tolleranza di errore e vedere l'interesse del nodo dati slave, fermiamo il nodo dati 1 eseguendo il seguente comando.
PGXC stop -m immediate datanode master datanode1

L'esecuzione di query sul cluster è ora impossibile perchè mancano i dati (53 istanze non sono più disponibili). Per verificare ciò, eseguire la seguente riga di comando.
test=# SELECT p.node_host, p.node_name, count(*) FROM hashed h, pgxc_node p where h.xc_node_id = p.node_id GROUP BY p.node_name, p.node_host;

Poichè Postgres-XL non supporta il failover automatico, deve essere esplicitamente indirizzato. Esegui il seguente comando.
PGXC
failover datanode datanode1

Ora controlliamo che la query precedente funzioni ora correttamente.
test=# SELECT p.node_host, p.node_name, count(*) FROM hashed h, pgxc_node p where h.xc_node_id = p.node_id GROUP BY p.node_name, p.node_host;

Il nodo dati slave ora ha preso il posto del nodo dati master. Questo può essere confermato attraverso i risultati della seguente query.
test=# SELECT oid, * FROM pgxc_node;

Va notato che il nodo dati originale 1 è stato completamente rimosso dal cluster.
Non esiste più nel file di configurazione pgxc_ctl.conf. Un modo per riutilizzarlo se disponibile è impostarlo a sua volta come slave del nuovo nodo dati 1. Eseguire la riga di comando successiva.
PGXC add datanode slave datanode1 192.168.1.16 20008 20012 /home/postgres/pgxc/dn1_master none /home/postgres/pgxc/dn1_archlo

Per assicurarsi che il cluster si trovi nello stato desiderato, eseguire la seguente riga di comando
PGXC monitor all

Questo deve essere il risultado:
Running: gtm master
Running: coordinator master coord1
Running: datanode master datanode1
Running: datanode slave datanode1
Running: datanode master datanode2

Conclusioni
Abbiamo visto attraverso questo tutorial l'installazione di Postgres-XL, una versione distribuita del database PostgreSQL, facendo esperienza su un cluster di test composto da cinque nodi.
Questa versione offre alcune caratteristiche interessanti come, per esempio la (distribuzione di dati e, in particolare, di query distribuite).
Tuttavia, notiamo alcuni svantaggi dovuti, ad esempio, al recupero degli errori in cui occorre gestirli manualmente.

In termini di prospettive, sarebbe interessante controllare Postgres-XL:

  • robustezza durante un aumento del carico orizzontale;
  • funzionamento su un lungo periodo;
  • l'implementazione di un bilanciamento del carico;
  • tolleranza d'errore quando si perdono più nodi.

 

Riferimenti
---------------------------------------
https://www.postgres-xl.org/documentation/install-short.html
https://www.postgres-xl.org/documentation/install-procedure.html
https://sourceforge.net/projects/postgres-xl/files/Releases/Version_9.5r1/
https://www.postgres-xl.org/documentation
https://github.com/mickaelbaron/postgresxl-scripts
https://ruihaijiang.wordpress.com/2015/09/17/postgres-xl-installation-example-on-linux/
https://postgres-x2.github.io/presentation_docs/2014-07-PGXC-Implementation/pgxc.pdf
http://pgsnaga.blogspot.com/2014/06/deploying-postgres-xl-in-2-minutes-with.html