Go to Hackademy website

Mise en place d'un cluster PostgreSQL avec Pgpool II

Théo Delaune

Posté par Théo Delaune dans les catégories outils

Bonjour à tous, aujourd’hui nous allons approcher la notion de cluster postgresql en haute disponibilité.

Certaines infrastructures critiques nécessitent de la haute disponibilité. La base de donnée est un point critique de toute application web. Pour garantir une qualité de service à vos utilisateurs il peut être intéressant de mettre en place un cluster de bases de données.

Nous allons nous intéresser plus précisément à la mise en place d’une haute disponibilité pour PostgreSQL en utilisant l’outil Pgpool II.

Pgpool est une application qui se place entre notre accès et PostgreSQL. Il permet notamment de faire la liaison entre les diffèrentes instances de PostgreSQL, tout en permettant de mettre en place de la réplication, de la haute disponibilité et du load balancing.

Pgpool fonctionne par le principe de duplication de requêtes pour gérer la réplication. Chaque écriture sur PostgreSQL sera effectué sur chaque serveur PostgreSQL du cluster.

Une fois la réplication et load balancing mis en place, certaines requêtes SELECT seront réparties entre les différents serveurs PostgreSQL. Voir la documention Pgpool pour connaître les conditions de requêtes en mode load balancing.

Pgpool gère nativement la haute disponibilité avec Watchdog. Il nous permet de mettre en place une ip virtuelle, c’est à dire que les deux instances Pgpool vont se partager une ip unique qui pointera sur le Pgpool ayant le status master. Si le master n’est plus disponible, le serveur en standby va prendre la place du master et prendre aussi l’ip virtuelle. Le but de cette ip virtuelle est d’avoir un seul et même point d’entrée dans le cluster.

Nous pourrions également avoir une seule instance Pgpool, mais dans ce cas là nous nous exposons à un single point of failure, car il n’y a aucune redondance de Pgpool.

Dans cette exemple nous allons prendre le cas de deux serveurs hébergeant chacun un serveur PostgreSQL. Nous allons pour cela répliquer les données sur les deux serveurs, activer le load balancing et mettre en place la haute disponibilité.

Le but de cette architecture est de pouvoir avoir accéder à nos données même si l’un des deux serveurs n’est plus accessible. Cette architecture est extensible car nous pouvons rajouter autant de serveurs que nous voulons à notre cluster.

Voici les différents points que nous allons aborder dans cet article :

  • Illustration de l’architecture finale
  • Création de notre cluster:
    • Installation de PostgreSQL
    • Configuration de PostgreSQL
    • Mise en place de Pgpool
    • Haute disponibilité de notre cluster
  • Tests
    • Réplication
    • Haute disponibilité

Illustration de l’architecture finale

                   Serveur web
                        +
                        |
                        |
                        v
                   Ip virtuelle
                       + +
                       | |
+--------------------+ | | +--------------------+
|                    <-+ +->                    |
|      Pgpool 1      |     |     Pgpool 2       |
|       master       |     |      standby       |
+--------+-----------+     +---------+----------+
         |                           |
         +---------------------+     |
         |       +-------------------+
         |       |             |     |
+--------v-------v---+     +---v-----v----------+
|                    |     |                    |
|    PostgreSQL 1    |     |    PostgreSQL 2    |
|                    |     |                    |
+--------------------+     +--------------------+

Les status Pgpool: - master: Écriture et lecture sur les instances PostgreSQL - standby: Lecture seule sur les instances PostgreSQL

Création de notre cluster:

Pour cet article nous sommes partis de deux machines virtuelles sous debian 7.5 x64.

Machine 1: - pgpool 1 - postgresql 1

Machine 2: - pgpool 2 - postgresql 2

Par simplicité dans la présentation nous ne mettons pas en place de stratégie d’authentification. Veillez donc à configurer correctement PostgreSQL lorsque vous mettrez cette architecture en production.

Installation de PostgreSQL

/!\ Cette étape est à effectuer sur chaque serveur de notre cluster.

PostgreSQL maintien son propre dépôt avec des packages debian à jour du SGBD. Nous allons donc récupérer la dernière version dans les dépôts de PostgreSQL.

$ sudo echo "deb http://apt.postgresql.org/pub/repos/apt/ wheezy-pgdg main" >> /etc/apt/sources.list

Pour pouvoir avoir accès au dépôt nous devons ajouté la clé signé fournie par PostgreSQL.

$ wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc \ sudo apt-key add -

Mettons à jour la liste des paquets disponibles et installons PostgreSQL.

$ sudo aptitude update
$ sudo aptitude install postgresql-9.3

Configuration de PostgreSQL

/!\ Cette étape est à effectuer sur chaque serveur de notre cluster.

Nous allons maintenant configurer PostgreSQL, attention cette configuration est valide juste pour notre exemple, veillez bien à remplacer trust par une méthode d’authentification.

Nous allons modifier le fichier /etc/postgresql/9.3/main/pg_hba.conf qui gère l’authentification de la connexion à notre instance PostgreSQL:

# Database administrative login by Unix domain socket
local   all             postgres                                trust

# TYPE  DATABASE        USER            ADDRESS                 METHOD
# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local   replication     postgres                                peer
#host    replication     postgres        127.0.0.1/32            md5
#host    replication     postgres        ::1/128                 md5
host     replication     all              0.0.0.0/0              trust

Configurons maintenant /etc/postgresql/9.3/main/postgresql.conf pour activer la réplication ainsi que pour accéder à notre instance PostgreSQL depuis n’importe quel endroit. En production il est préférable de restreindre l’écoute d’adresses.

listen_addresses = '*' # accepter toutes les connexions entrantes
wal_level = hot_standby # mode permettant de passer Postgres en master avec des noeuds en standby
max_wal_senders = 2
wal_keep_segments = 50
hot_standby = on
archive_mode = on

Validons la configuration en redémarrant l’instance PostgreSQL sur chaque serveur:

$ sudo /etc/init.d/postgresql restart

Mise en place de Pgpool II

/!\ Cette étape est à effectuer sur chaque serveur de notre cluster.

Nous allons récupérer directement les sources sur le site de Pgpool, puis nous allons décompresser l’archive.

$ wget http://www.pgpool.net/download.php?f=pgpool-II-3.3.3.tar.gz
$ tar xvfz download.php?f=pgpool-II-3.3.3.tar.gz

Pour pouvoir compiler Pgpool nous devons installer la librairie libpq-dev:

$ sudo apt-get install libpq-dev

Nous allons maintenant procéder à l’installation de Pgpool:

$ cd pgpool-II-3.3.3
$ ./configure
$ make
$ make install

Nous allons créer le dossier pour le stockage du pid de Pgpool:

$ sudo mkdir /var/run/pgpool

Une fois l’installation terminée nous pouvons passer à la configuration de pgpool. Nous allons copier le fichier de configuration à partir du fichier de configuration d’exemple.

$ sudo cp /usr/local/etc/pgpool.conf.sample /usr/local/etc/pgpool.conf

Configurons maintenant pgpool.conf: ~~~ listen_addresses = ‘*’

backend_hostname0 = ‘ip serveur 1’ backend_port0 = 5432 backend_weight0 = 1

backend_hostname1 = ‘ip serveur 2’ backend_port1 = 5432 backend_weight1 = 1

replication_mode = on # permet de répliqué chaque action sur chaque instance PostgreSQL load_balance_mode = on # permet d’avoir load balancé la lecture sur chaque instance de notre cluster ~~~

Haute disponibilité de notre cluster

Pour l’instant si l’un des deux serveurs tombe, nous n’avons plus accès à nos données. Nous allons voir ici comment mettre en place la haute disponibilité de Pgpool pour accéder à notre cluster grâce à une ip virtuelle.

La configuration de notre ip virtuelle passe également par le fichier pgpool.conf:

serveur 1:

use_watchdog = on
delegate_IP = 'ip virtuelle'
heartbeat_destination0 = 'ip serveur 2'
other_pgpool_hostname0 = 'ip serveur 2'
other_pgpool_port0 = 9999
other_wd_port0 = 9000

serveur 2:

use_watchdog = on
delegate_IP = 'ip virtuelle'
heartbeat_destination0 = 'ip serveur 1'
other_pgpool_hostname0 = 'ip serveur 1'
other_pgpool_port0 = 9999
other_wd_port0 = 9000

Tests

Nous allons tout d’abord lancer nos deux instances Pgpool. Assurer vous que votre instance PostgreSQL est lancée sur chaque serveur.

Sur chaque serveur le lancement de Pgpool s’effectue en lançant l’instance Pgpool:

$ pgpool -D
# l'option -D est à effectuer seulement au premier démarrage ou lors d'un crash de l'une de nos instances.
# L'option -D permet ne de pas prendre en compte le status précédent de notre instance Pgpool

Le premier serveur sur lequel sera lancé Pgpool passera en mode master, tandis que le second passera en mode standby.

Réplication

Notre cluster est à présent configuré, il est donc maintenant possible d’y accéder via l’adresse ip virtuelle que nous lui avons spécifié.

Nous allons à partir de notre machine hôte créé sur notre cluster une base de donnée et vérifier qu’elle est correctement répliquée sur les deux serveurs PostgreSQL:

# Connexion à notre cluster via psql
# Nous spécifions le user postgres car pour ce test nous n'avons la nécessité de créer un utilisateur diffèrent
# Le port correspond au port de Pgpool
psql -h ip virtuelle -p 9999 -U -l postgres
postgres=# create database VERIFICATION_CLUSTER;

Nous allons maintenant vérifier sur chacun des serveurs PostgreSQL l’existence de la base VERIFICATION_CLUSTER.

serveur 1:

# Le port correspond au port de notre instance PostgreSQL
$ psql -h ip serveur 1 -p 5432 -U postgres -l
############
                                       List of databases
         Name         |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
----------------------+----------+----------+-------------+-------------+-----------------------
 verification_cluster | postgres | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 |

serveur 2:

# Le port correspond au port de notre instance PostgreSQL
$ psql -h ip serveur 2 -p 5432 -U postgres -l
############
                                       List of databases
         Name         |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
----------------------+----------+----------+-------------+-------------+-----------------------
 verification_cluster | postgres | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 |

Nous remarquons que la base verification_cluster s’est correctement répliquée sur nos deux serveurs PostgreSQL.

Haute disponibilité

Le serveur 1 étant en master, nous allons le couper pour vérifier que la haute disponibilité fonctionne correctement.

serveur 1:

$ pgpool stop

Nous allons attendre environ 30 secondes le temps que le serveur 2 soit promu master et allons vérifier que nous avons toujours accès au cluster:

# Le port correspond au port de notre instance Pgpool
$ psql -h ip virtuelle -p 9999 -U postgres -l
############
                                       List of databases
         Name         |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
----------------------+----------+----------+-------------+-------------+-----------------------
 verification_cluster | postgres | UTF8     | fr_FR.UTF-8 | fr_FR.UTF-8 |

Il ne nous reste plus qu’à relancer Pgpool sur le serveur 1:

$ pgpool

Le serveur 1 passe donc en standby. Il est resynchronisé à partir du serveur 2 qui lui est le nouveau master.

Notre cluster est maintenant pleinement fonctionnel.

Nous avons à présent un cluster PostgreSQL hautement disponible et load balancé en lecture. Il vous reste donc à configurer correctement la sécurité de vos instances PostgreSQL et Pgpool pour pouvoir déployer cette architecture en production en toute sécurité.


L’équipe Synbioz.

Libres d’être ensemble.

Articles connexes

Un plugin Vim à la mimine

03/01/2019

Dans l’article précédent, intitulé une assez bonne intimité, je vous présentais GPG et le chiffrement de courriels. Nous avons alors remarqué que le contenu d’un courriel était encodé de sorte que le...

Une assez bonne intimité

20/12/2018

Si vous êtes utilisateur de MacOS, il y a de fortes chances que vous utilisiez Apple Mail pour échanger des courriels. Et comme vous êtes sensible à la confidentialité des informations que vous...

Tests end to end avec Jest et Puppeteer

05/07/2018

Dans cet article, on va partir sur des tests end to end. Pour planter le décor, un test end to end (e2e) est un test logiciel qui a pour but de valider que le système testé répond correctement à un...

Chasser les requêtes N+1 avec Bullet

05/04/2018

Aujourd’hui nous allons parler des requêtes N+1 dans une application Rails : vous savez ces lignes quasiment identiques, qui s’ajoutent de manière exponentielle aux logs, dès lors que l’on appelle...