Cluster de Haute Disponibilité PostgreSQL :éléphant: :cœur_étincelant:

Cluster de Haute Disponibilité PostgreSQL prêt pour la production (basé sur Patroni). Automatisation avec Ansible.

postgresql_cluster automatise le déploiement et la gestion de clusters PostgreSQL hautement disponibles dans des environnements de production. Cette solution est conçue pour une utilisation sur des serveurs physiques dédiés, des machines virtuelles, et dans des infrastructures à la fois sur site et basées sur le cloud.

Vous pouvez trouver une version de cette documentation qui est facilement navigable et consultable sur postgresql-cluster.org

:trophée: Utilisez le programme sponsoring pour obtenir un soutien personnalisé ou simplement pour contribuer à ce projet.

Configurations Supportées du Cluster Postgres

Trois schémas sont disponibles pour le déploiement :

1. Haute Disponibilité PostgreSQL uniquement

C'est un schéma simple sans équilibrage de charge.

Composants de haute disponibilité :

• Patroni est un modèle pour créer votre propre solution de haute disponibilité personnalisée en utilisant Python et - pour une accessibilité maximale - un magasin de configuration distribué comme ZooKeeper, etcd, Consul ou Kubernetes. Utilisé pour automatiser la gestion des instances PostgreSQL et la commutation automatique.

• etcd est un magasin de clé-valeur distribué et fiable pour les données critiques d'un système distribué. etcd est écrit en Go et utilise l'algorithme de consensus Raft pour gérer un journal répliqué hautement disponible. Il est utilisé par Patroni pour stocker des informations sur l'état du cluster et les paramètres de configuration de PostgreSQL. Qu'est-ce que le Consensus Distribué ?

• vip-manager (optionnel, si la variable cluster_vip est spécifiée) est un service qui démarre sur tous les nœuds du cluster et se connecte au DCS. Si le nœud local possède la clé de leader, vip-manager démarre le VIP configuré. En cas de basculement, vip-manager retire le VIP du leader précédent et le service correspondant sur le nouveau leader le démarre là. Utilisé pour fournir un point d'entrée unique (VIP) pour l'accès à la base de données.

• PgBouncer (optionnel, si la variable pgbouncer_install est true) est un pooler de connexions pour PostgreSQL.

2. Haute Disponibilité PostgreSQL avec Équilibrage de Charge

Ce schéma permet de distribuer la charge pour les opérations de lecture et permet également d'augmenter le cluster avec des répliques en lecture seule.

Lors du déploiement auprès de fournisseurs de cloud tels qu'AWS, GCP, Azure, DigitalOcean et Hetzner Cloud, un équilibreur de charge cloud est automatiquement créé par défaut pour fournir un point d'entrée unique à la base de données (contrôlé par la variable cloud_load_balancer).

Pour des environnements non-cloud, comme lors d'un déploiement sur vos propres machines, l'équilibreur de charge HAProxy est disponible. Pour l'activer, définissez with_haproxy_load_balancing: true dans le fichier vars/main.yml.

:heavy_exclamation_mark: Remarque : Votre application doit être capable d'envoyer des requêtes de lecture à un port personnalisé 5001, et des requêtes d'écriture au port 5000.

• port 5000 (lecture / écriture) maître
• port 5001 (lecture seule) toutes les répliques

si la variable "synchronous_mode" est 'true' (vars/main.yml) :

• port 5002 (lecture seule) uniquement réplique synchrone
• port 5003 (lecture seule) uniquement répliques asynchrones

Composants de l'équilibrage de charge HAProxy :

• HAProxy est une solution gratuite, très rapide et fiable offrant haute disponibilité, équilibrage de charge et proxy pour des applications TCP et HTTP.

• confd gère les fichiers de configuration d'application locaux en utilisant des modèles et des données provenant d'etcd ou de consul. Utilisé pour automatiser la gestion des fichiers de configuration d'HAProxy.

• Keepalived (optionnel, si la variable cluster_vip est spécifiée) fournit une adresse IP virtuelle haute disponibilité (VIP) et un point d'entrée unique pour l'accès aux bases de données. Implémentation du VRRP (Virtual Router Redundancy Protocol) pour Linux. Dans notre configuration, keepalived vérifie l'état du service HAProxy et en cas de défaillance, délègue le VIP à un autre serveur dans le cluster.

3. Haute Disponibilité PostgreSQL avec découverte de service Consul

Pour utiliser ce schéma, spécifiez dcs_type: consul dans le fichier de variables vars/main.yml.

Ce schéma convient à un accès uniquement maître et à l'équilibrage de charge (en utilisant DNS) pour la lecture à travers les répliques. La découverte de service Consul avec résolution DNS est utilisée comme point d'accès client à la base de données.

Point d'accès client (exemple) :

• master.postgres-cluster.service.consul
• replica.postgres-cluster.service.consul

En outre, cela peut être utile pour un cluster distribué à travers différents centres de données. Nous pouvons spécifier à l'avance dans quel centre de données le serveur de base de données est situé et ensuite l'utiliser pour des applications fonctionnant dans le même centre de données.

Exemple : replica.postgres-cluster.service.dc1.consul, replica.postgres-cluster.service.dc2.consul

Cela nécessite l'installation d'un client Consul en mode client sur chaque serveur d'application pour la résolution DNS de service (ou utilisez DNS de transfert vers le serveur Consul distant au lieu d'installer un client Consul local).

Compatibilité

Distributions basées sur RedHat et Debian (x86_64)

Distributions Linux Supportées :

• Debian : 11, 12
• Ubuntu : 22.04, 24.04
• CentOS Stream : 9
• Oracle Linux : 8, 9
• Rocky Linux : 8, 9
• AlmaLinux : 8, 9

Versions de PostgreSQL :

toutes les versions PostgreSQL supportées

:white_check_mark: testé, fonctionne bien : PostgreSQL 10, 11, 12, 13, 14, 15, 16

Tableau des résultats des tests automatiques quotidiens de déploiement de cluster :

Distribution	Résultat du test
Debian 11
Debian 12
Ubuntu 22.04
Ubuntu 24.04
CentOS Stream 9
Oracle Linux 8
Oracle Linux 9
Rocky Linux 8
Rocky Linux 9
AlmaLinux 8
AlmaLinux 9

Version d'Ansible

Version minimale d'Ansible supportée : 8.0.0 (ansible-core 2.15.0)

Exigences

Recommandations

Prise en Main

Pour exécuter la Console de Cluster PostgreSQL, exécutez la commande suivante :

docker run -d --name pg-console \
  --publish 80:80 \
  --publish 8080:8080 \
  --env PG_CONSOLE_API_URL=http://localhost:8080/api/v1 \
  --env PG_CONSOLE_AUTHORIZATION_TOKEN=secret_token \
  --volume console_postgres:/var/lib/postgresql \
  --volume /var/run/docker.sock:/var/run/docker.sock \
  --volume /tmp/ansible:/tmp/ansible \
  --restart=unless-stopped \
  vitabaks/postgresql_cluster_console:2.0.0

Remarque : Il est recommandé d'exécuter la console dans le même réseau que vos serveurs de base de données pour permettre la surveillance de l'état du cluster. Dans ce cas, remplacez localhost par l'adresse IP de votre serveur dans la variable PG_CONSOLE_API_URL.

Ouvrez l'interface de la console

Allez sur http://localhost/ et utilisez secret_token pour l'autorisation.

Remarque : Si vous avez configuré la console sur un autre serveur, remplacez 'localhost' par l'adresse du serveur. Utilisez la valeur de votre token si vous l'avez redéfini dans la variable PG_CONSOLE_AUTHORIZATION_TOKEN.

sudo apt update && sudo apt install -y python3-pip sshpass git
pip3 install ansible

git clone https://github.com/vitabaks/postgresql_cluster.git

cd postgresql_cluster/automation

nano inventory

nano vars/main.yml

ansible-galaxy install -r roles/consul/requirements.yml

ansible all -m ping

ansible-playbook deploy_pgcluster.yml

ansible-playbook deploy_pgcluster.yml -e "enable_timescale=true"

ansible-playbook remove_cluster.yml -e "remove_postgres=true remove_etcd=true"

Évaluez-nous

Si vous trouvez notre projet utile, envisagez de lui donner une étoile sur GitHub ! Votre soutien nous aide à grandir et nous motive à continuer à nous améliorer. Évaluer le projet est une manière simple mais efficace de montrer votre appréciation et d'aider les autres à le découvrir.

Sponsoriser ce projet

En sponsorisant notre projet, vous contribuez directement à son amélioration continue et à son innovation. En tant que sponsor, vous bénéficierez d'avantages exclusifs, y compris un support personnalisé, un accès anticipé aux nouvelles fonctionnalités et la possibilité d'influencer l'orientation du projet. Votre parrainage est inestimable pour nous et contribue à assurer la durabilité et le progrès du projet.

Devenez sponsor dès aujourd'hui et aidez-nous à faire passer ce projet au niveau supérieur !

Soutenez notre travail via GitHub Sponsors

Soutenez notre travail via Patreon

Soutenez notre travail via un portefeuille crypto :

USDT (TRC20) : TSTSXZzqDCUDHDjZwCpuBkdukjuDZspwjj

Licence

Sous licence MIT. Voir le fichier LICENSE pour plus de détails.

Auteur

Vitaliy Kukharik (DBA PostgreSQL)
vitabaks@gmail.com

Retours, rapports de bogues, demandes, ...

Sont les bienvenus !