Vous trouverez en ligne les différentes versions complètes de ce document.

Vous n’avez pas le droit d’utiliser cette création à des fins commerciales.

Si vous modifiez, transformez ou adaptez cette création, vous n’avez le droit de distribuer la création qui en résulte que sous un contrat identique à celui-ci.

Vous devez citer le nom de l’auteur original de la manière indiquée par l’auteur de l’œuvre ou le titulaire des droits qui vous confère cette autorisation (mais pas d’une manière qui suggérerait qu’ils vous soutiennent ou approuvent votre utilisation de l’œuvre). À chaque réutilisation ou distribution de cette création, vous devez faire apparaître clairement au public les conditions contractuelles de sa mise à disposition. La meilleure manière de les indiquer est un lien vers cette page web. Chacune de ces conditions peut être levée si vous obtenez l’autorisation du titulaire des droits sur cette œuvre. Rien dans ce contrat ne diminue ou ne restreint le droit moral de l’auteur ou des auteurs.

Le texte complet de la licence est disponible sur http://creativecommons.org/licenses/by-nc-sa/2.0/fr/legalcode

Cela inclut les diapositives, les manuels eux-mêmes et les travaux pratiques. Cette formation peut également contenir quelques images et schémas dont la redistribution est soumise à des licences différentes qui sont alors précisées.

Sur les versions précédentes susceptibles d’être encore rencontrées en production, seuls quelques points très importants sont évoqués, en plus éventuellement de quelques éléments historiques.

Sauf précision contraire, le système d’exploitation utilisé est Linux.

Une architecture de type Shared Storage repose essentiellement sur un disque partagé entre au moins deux serveurs. Les données de l’instance sont situées sur le disque partagé. En cas de panne sur le serveur actif, le ou les disques sont montés sur l’un des serveurs de secours et l’instance PostgreSQL y est démarrée.

L’avantage d’une telle architecture est son apparente simplicité. Les données étant habituellement situées dans un SAN, il est aisé en cas d’incident sur le serveur principal de monter les disques dans un serveur de secours et redémarrer PostgreSQL. La configuration de PostgreSQL reste au plus simple et l’espace occupé par les données de l’instance n’est pas dupliqué à travers plusieurs serveurs.

La haute disponibilité des données doit être prise en charge par une réplication au niveau disque (SAN, DRBD, etc).

La disponibilité du service dépend de la technologie utilisée : machine virtuelle, lame, serveur physique. Certaines technologies de virtualisation sont capables de « migrer » une machine virtuelle et ses disques en cas de panne sur un hyperviseur. D’autres cluster-wares (comme Pacemaker, rgmanager) sont capables de basculer le disque et le service sur un serveur tiers du cluster.

L’autre architecture de clustering est appelée Share Nothing. Dans une telle architecture, chaque nœud du cluster est totalement indépendant.

Dans le cadre de PostgreSQL, cela signifie que les données sont situées sur plusieurs serveurs grâce à la réplication interne de ce dernier. Les solutions que nous proposons par la suite sont toutes de type Share Nothing.

Patroni assure l’exploitation d’un cluster PostgreSQL en réplication et est capable d’effectuer une bascule automatique en cas d’incident sur l’instance primaire.

Le projet repose sur un DCS externe comme stockage distribué de sa configuration. etcd, basé sur le protocole Raft, est sans doute le plus simple, mais d’autres sont possibles.

Le DCS nécessite au moins 3 nœuds (donc 3 serveurs ou machines virtuelles) pour assurer son quorum propre, la sécurité et la viabilité de ses données. Néanmoins un même cluster DCS peut ensuite gérer plusieurs clusters Patroni.

Se reposer sur un DCS fiable permet à Patroni plus de robustesse et de se focaliser sur l’expertise PostgreSQL uniquement. Le mécanisme de modification atomique de la base de configuration distribuée permet notamment une élection fiable en cas d’incident.

Depuis la version 2.0, Patroni permet aussi d’utiliser le protocole Raft, sans utiliser de DCS externe. Nous n’avons aucun recul sur cette technologie pour le moment. Nous utiliserons Patroni avec etcd par la suite.

En plus de ce DCS fiable et d’un mécanisme d’élection ne laissant aucune place aux race conditions, Patroni supporte l’utilisation d’un watchdog matériel. Le couple DCS+watchdog permet donc d’éviter les situations de split-brain.

Depuis la version 2.0, Patroni offre la possibilité d’exécuter une action pré-promotion, capable d’annuler la promotion si nécessaire. Cette fonctionnalité a été ajoutée afin de permettre l’ajout d’une action de fencing de l’ancien primaire. Nous n’avons pour le moment aucun recul sur cette fonctionnalité. Il faut notamment étudier quelles informations sont accessibles depuis le callback pour décider d’un fencing ou non.

Patroni est un projet simple, rapide à déployer et prendre en main. Il est toutefois toujours hautement recommandé de former une équipe à son administration.

Pacemaker est la solution de haute disponibilité de référence sur les distributions Linux modernes. Plusieurs entreprises telle que RedHat, Suse ou Linbit investissent du temps de recherche et développement pour la maintenance et l’évolution du projet. RedHat et Suse supportent officiellement les clusters Pacemaker (souvent au travers de souscriptions complémentaires) en imposant certaines contraintes de robustesse à leurs clients (comme un fencing obligatoire).

Le projet est très complet, supporte plusieurs types de fencing, avec escalade possible, le quorum, l’utilisation de watchdog, le clustering étendu (déployé entre deux datacenters). Il est capable de mettre en haute disponibilité plusieurs dizaines de services tels que des bases de données, des serveurs HTTP, mail, des machines virtuelles, des containers, etc.

Cette souplesse a néanmoins un prix en matière d’apprentissage et de maintenance. Il est largement recommandé d’être formé à l’utilisation et la maintenance de Pacemaker avant de le mettre en production.

Concernant la gestion de PostgreSQL, nous recommandons l’utilisation de l’agent PAF (PostgreSQL Automatic Failover). Son développement a été lancé au sein de Dalibo, et il est maintenu actuellement par Jehan-Guillaume de Rorthais. afin de corriger ou contourner les problèmes et limitations de l’agent officiel existant. Il est entré au sein de l’organisme ClusterLabs regroupant les différents projets liés à Pacemaker.

Il existe plusieurs solutions pour gérer l’accès des applications à l’instance principale.

La plus simple est l’utilisation d’une IP virtuelle. Cette solution est à privilégier avec Pacemaker, ce dernier gérant alors à la fois la localisation de l’IP virtuelle et de l’instance primaire. Cette solution est aussi envisageable avec Patroni, à condition d’utiliser un script en callback ou d’ajouter un service supplémentaire dédié à cette tâche. Cette solution n’est cependant pas totalement robuste avec Patroni.

Une autre solution revient à utiliser un tiers faisant office de proxy entre les clients et l’instance principale. HAProxy est une solution populaire, mais il en existe bien d’autres, propriétaires ou non. La solution doit être capable de déterminer où se trouve l’instance primaire au sein du cluster.

Enfin, la dernière solution consiste à intégrer l’intelligence nécessaire directement dans les couches applicatives. La chaîne de connexion à l’instance peut par exemple comporter plusieurs destinataires et désigner le rôle recherché (target_session_attrs=read-write). Il est aussi possible d’utiliser un gestionnaire de configuration centralisé aux applications tel que confd.

La mise en œuvre de la haute disponibilité apporte un certain nombre de complications et complexifications à l’architecture. Avec une disponibilité exigée de 99,5% (soit 44 h d’indisponibilité par an !), nous déconseillons la mise en œuvre d’une telle architecture. Il est plus sage de reposer sur des procédures connues et éprouvées, outillées, avec une phase de prise de décision humaine optimisée pour être déclenchée le plus vite possible.

Une meilleure maîtrise de l’architecture évite souvent les appels d’astreintes impromptus et se substitue avantageusement à une bascule automatique beaucoup plus difficile à maîtriser et budgétiser.

Si une bascule automatisée est nécessaire, nous recommandons principalement l’utilisation de Patroni ou de Pacemaker/PAF, d’une part pour leur robustesse, d’autre part pour leur adoption importante au sein de la communauté.

Si vos instances sont critiques et nécessitent une haute disponibilité de service et/ou de données, rappelons qu’il est vital de porter un soin particulier à la supervision pour anticiper les incidents et aux sauvegardes pour pallier aux incidents majeurs.

Enfin, la formation des équipes et la documentation à jour du montage utilisé sont indispensables.