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