• Contenu
  • Bas de page
logo ouidoulogo ouidoulogo ouidoulogo ouidou
  • Qui sommes-nous ?
  • Offres
    • 💻 Applications métier
    • 🤝 Collaboration des équipes
    • 🛡️ Sécurisation et optimisation du système d’information
    • 🔗 Transformation numérique
  • Expertises
    • 🖥️ Développement logiciel
    • ♾️ DevSecOps
    • ⚙️ Intégration de logiciels et négoce de licences
      • Atlassian : Jira, Confluence, Bitbucket…
      • Plateforme monday.com
      • GitLab
      • SonarQube
    • 📚​ Logiciel de CRM et de gestion
    • 🎨 UX/UI design
    • 🌐 Accessibilité Numérique
    • 🗂️​ Démarches simplifiées
    • 📝 Formations Atlassian
  • Références
  • Carrières
    • 🧐 Pourquoi rejoindre Ouidou ?
    • ✍🏻 Nous rejoindre
    • 👨‍💻 Rencontrer nos collaborateurs
    • 🚀 Grandir chez Ouidou
  • RSE
  • Ressources
    • 🗞️ Actualités
    • 🔍 Articles techniques
    • 📖 Livres blancs
    • 🎙️ Interviews Clients
Nous contacter
✕
Une carte de France en SVG
Une carte de France en SVG
6 février 2014
Blocks, Proc et Lambda en Ruby
Blocks, Proc et Lambda en Ruby
3 février 2015
Ressources > Articles techniques > Mise en place d’un cluster PostgreSQL avec Pgpool II

Mise en place d’un cluster PostgreSQL avec Pgpool II

Écrit par Théo Délaune

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 cet 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édé à 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 ajouter la clé signée 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ée.

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é.

À lire aussi

Fresque numérique miniature image
16 avril 2025

Fresque du Numérique

Lire la suite

intelligence artificielle Ouicommit miniature image
17 mars 2025

Ouicommit – L’intelligence artificielle en entreprise, on y est ! 

Lire la suite

Image miniature Hackathon Women in Tech
13 mars 2025

Hackathon Women in Tech :  un engagement pour une tech plus inclusive 

Lire la suite

image miniature les nouveautés Atlassian
26 février 2025

Les nouveautés Atlassian en 2025

Lire la suite

Articles associés

Fresque numérique miniature image
16 avril 2025

Fresque du Numérique


Lire la suite
intelligence artificielle Ouicommit miniature image
17 mars 2025

Ouicommit – L’intelligence artificielle en entreprise, on y est ! 


Lire la suite
Image miniature Hackathon Women in Tech
13 mars 2025

Hackathon Women in Tech :  un engagement pour une tech plus inclusive 


Lire la suite

À propos

  • Qui sommes-nous ?
  • Références
  • RSE
  • Ressources

Offres

  • Applications métier
  • Collaboration des équipes
  • Sécurisation et optimisation du système d’information
  • Transformation numérique

Expertises

  • Développement logiciel
  • DevSecOps
  • Intégration de logiciels et négoce de licences
  • Logiciel de CRM et de gestion
  • UX/UI design
  • Accessibilité Numérique
  • Démarches simplifiées
  • Formations Atlassian

Carrières

  • Pourquoi rejoindre Ouidou ?
  • Nous rejoindre
  • Rencontrer nos collaborateurs
  • Grandir chez Ouidou

SIEGE SOCIAL
70-74 boulevard Garibaldi, 75015 Paris

Ouidou Nord
165 Avenue de Bretagne, 59000 Lille

Ouidou Rhône-Alpes
4 place Amédée Bonnet, 69002 Lyon

Ouidou Grand-Ouest
2 rue Crucy, 44000 Nantes

Ouidou Grand-Est
7 cour des Cigarières, 67000 Strasbourg

  • Linkedin Ouidou
  • GitHub Ouidou
  • Youtube Ouidou
© 2024 Ouidou | Tous droits réservés | Plan du site | Mentions légales | Déclaration d'accessibilité
    Nous contacter