Un peu d'histoire ...
A l'origine du projet (début des années 2000), Tatsuo Ishii principal développeur de la solution souhaitait créer un simple logiciel de gestion de pool de connexion pour Postgresql. Il l'appela donc PGPool.
Après plusieurs versions et diverses fonctions ajoutées, il a décidé en 2006 de renommer le projet en PGPool-II, nom qu'il porte toujours aujourd'hui.
Pour quoi faire ?
PGPool-II est un middleware qui se place entre les applications et les instances Postgresql. Il a diverses fonctions dont celles de gérer des pools de connexion applicatives, la répartition de charge (lectures sur le slave), et la gestion du failover des Postgresql. Le service PGPool-II peut lui-même être mis en haute disponibilité grâce à un système de watchdog (principalement développé par Muhammad Usama, core dev de PGPool-II sur la partie haute disponibilité du service).
Nous allons voir dans cet article les principes de base du fonctionnement de PGPool-II en ce qui concerne la haute disponibilité du service et la gestion du failover Postgresql.
Architecture :
Voici le schéma de l'architecture type que l'on met en place chez Claranet :
Nous avons deux serveurs sur lesquels sont installés PGPool-II et Postgresql.
Nous avons une réplication de type streaming (réplication native Postgresql) entre le serveur 1 (qui a l'instance Postgresql primaire) et le serveur 2 (qui a l'instance Postgresql standby).
PGPool est configuré en HA, il y a une notion de Master/Slave sur le service, et le premier qui démarre devient Master et monte la VIP (IP virtuelle qui peut être monté sur l'un ou l'autre des serveurs). Le Slave restera à l'écoute du Master et reprendra la VIP en cas de perte du Master.
La haute disponibilité du service PGPool-II
Là je tire mon chapeau à Muhammad Usama ! L'idée d'utiliser une liste de serveurs témoin (qui n'ont besoin de rien d'autre que savoir répondre au ping), est peut-être simple mais diablement efficace !
Les deux services PGPool-II (celui du serveur 1 et celui du serveur 2) échanges des trames heartbeat entre eux. Lorsqu'ils n'arrivent plus à se joindre, ils vont chacun tenter de « pinguer » la liste de serveurs témoin (nous utilisons généralement la liste des serveurs applicatifs, AppSrv1 à 3 sur le schéma). Si aucun de ces serveurs témoin n'est joignable le service PGPool-II va considérer qu'il est isolé du réseau. S'il était Master, il va démonter sa VIP et stopper son service. Si le slave peut joindre les serveurs témoin mais pas le Master PGPool-II, il va se promouvoir Master et monter la VIP. Je vous l'avais dit, simple mais efficace :)
Le failover des Postgresqls
Le Master PGPool-II va en permanence vérifier la disponibilité des Postgresql primaire et standby. Si on perd le Postgresql standby, PGPool-II note qu'il n'est plus disponible mais le service continu d'être assuré par le primaire. SI on perd le Postgresql primaire, PGPool-II note qu'il n'est plus disponible, promeut le standby en primaire(via un script à mettre en place) et redirige toute les requêtes vers ce nouveau primaire. Suite à cela il faudra reconstruire l'ex-primaire en standby et le réintégrer dans PGPool-II. Il recevra alors les requêtes de lecture (car load-balancing des lectures par PGPool-II).
Le tuning de PGPool-II, pas si simple
PGPool-II comporte énormément de paramètres, ce qui permet d'avoir une configuration aux petits oignons. Le revers de la médaille c'est qu'il n'est parfois pas évident de trouver la cause de comportement différents entre des serveurs physiques et des virtuels par exemple.
Conclusion
Si vous utilisez Postgresql (avec réplication) mais ne connaissez pas PGPool-II, je vous conseille fortement de vous y intéresser. Ce middleware a beaucoup de cordes à son arc, mais sa gestion de la haute disponibilité des instances Postgresql est celle qui m'a séduit le plus et je trouve que ce serait dommage de s'en priver.