Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Dans le cadre de la création d'un hébergeur web alternatif (associatif) nous souhaitons proposer à nos adhérents la possibilité d'avoir 5 bases de données par adhérents (de toutes tailles : utilisation perso à gros SIG ).
(nous sommes nombreux ;-)), il nous faudrait donc un cluster postgresql (3 nœuds mini)
Quelle(s) solution(s) de haute disponibilité est, selon vous, la plus performante avec postgresql ?
j'ai cru comprendre que pour l’instant postgresql ne fait pas comme, mariadb, du clustering multi-maitre.
Hors ligne
Pour moi, le meilleur adjectif à utiliser pour une solution de haute disponibilité n'est certainement pas "performant", mais "fiable". Si vous cherchez une solution fiable, robuste et éprouvée je vous conseillerais donc corosync/pacemaker avec le resource agent PAF: https://clusterlabs.github.io/PAF/. Le seul bémol est qu'il s'agit d'une solution complexe à prendre en main (ce qui est normal vu que le problème à résoudre est complexe).
Julien.
https://rjuju.github.io/
En ligne
Oui , fiable me semble le bon mot .... mais il nous faut aussi des performances pour une prod. , ce n 'est pas pour un POC mais bien pour pas mal d'utilisateurs ;-)
j'avais lorgné sur Corosync et pacemaker mais avais en tête aussi : pgpool-ii, repmgr , patroni mais aussi ... HAProxy/Keepalived, OpenSVC.
Je te remercie de ta réponse.
Je vais chercher avec les brique systèmes que tu me conseilles.
Dernière modification par ledufakademy (04/04/2020 11:32:10)
Hors ligne
pgpool nécessite l'écriture d'un paquet de scripts, ce qui fait qu'au final, vous n'y gagnez rien, sauf des problèmes. Dans la liste, seuls PAF et patroni semblent être suffisamment fiables.
Le multi-maître n'existe pas actuellement nativement avec PostgreSQL. BDM de 2ndQuadrant et Bucardo de End Point Corporation sont souvent cités comme des solutions potentielles. Je n'ai jamais essayé le premier, mais je sais que le second a été une galère monumentale à administrer. Donc plus jamais 
Guillaume.
Hors ligne
pgpool nécessite l'écriture d'un paquet de scripts, ce qui fait qu'au final, vous n'y gagnez rien, sauf des problèmes. Dans la liste, seuls PAF et patroni semblent être suffisamment fiables.
Le multi-maître n'existe pas actuellement nativement avec PostgreSQL. BDM de 2ndQuadrant et Bucardo de End Point Corporation sont souvent cités comme des solutions potentielles. Je n'ai jamais essayé le premier, mais je sais que le second a été une galère monumentale à administrer. Donc plus jamais
J'avais vu ces solutions aussi : donc patroni ou PAF.
ok, merci beaucoup.
Dernière modification par ledufakademy (04/04/2020 16:48:24)
Hors ligne
pgpool nécessite l'écriture d'un paquet de scripts, ce qui fait qu'au final, vous n'y gagnez rien, sauf des problèmes. Dans la liste, seuls PAF et patroni semblent être suffisamment fiables.
Le multi-maître n'existe pas actuellement nativement avec PostgreSQL. BDM de 2ndQuadrant et Bucardo de End Point Corporation sont souvent cités comme des solutions potentielles. Je n'ai jamais essayé le premier, mais je sais que le second a été une galère monumentale à administrer. Donc plus jamais
je viens d'acheter et suis en train de lire : PostgreSQL 12 High Availability Cookbook: Over (3rd edition)
Oui l'auteur semble dire :
Primary - replica (et witness nodes) (pas de multi-maitre donc ...? vs Mariadb avec galera ou c'est ok.)
Est ce que pour une conf avec trois sites , c'est bon comme archi. :
https://nuage.ilinux.fr/s/yzS3BBpDW38QNEF
Dernière modification par ledufakademy (05/04/2020 20:24:05)
Hors ligne
Bonjour,
Pour avoir testé pas mal de solutions (repmgr, paf , pgpool et patroni).
Pour moi, la solution la plus fiable, moderne et facile a mettre en place est patroni.
Elle est de plus largement éprouvée par l'entreprise conceptrice du produit (zalando)
Cordialement
Hors ligne
Bonjour,
Ma petite contribution :
Pgpool : testé et abandonné aussitôt (problèmes de bascule, de cohérence de données (séquences), peu résistant à un arrêt brutal électrique, complexe à mettre en œuvre si on veut faire les choses bien)
pacemaker/corosync/PAF : actuellement en production dans notre (grosse) entreprise : ça marche très bien. Un peu de complexité au départ mais une fois que c'est en place, ça fait bien le boulot (au niveau de la disponibilité).
Patroni : en cours d'évaluation chez nous car il semble très prometteur et plus simple que pacemaker/PAF et plus fiable d'après les tests que j'ai pu voir en POC. En plus adossé à du HA proxy, si votre application est faite pour, on peut faire de la répartition de charge (select sur les slaves) pour faire de la scalabilité horizontale.
Les autres technos, je ne connais pas.
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Ma petite contribution :
Pgpool : testé et abandonné aussitôt (problèmes de bascule, de cohérence de données (séquences), peu résistant à un arrêt brutal électrique, complexe à mettre en œuvre si on veut faire les choses bien)
pacemaker/corosync/PAF : actuellement en production dans notre (grosse) entreprise : ça marche très bien. Un peu de complexité au départ mais une fois que c'est en place, ça fait bien le boulot (au niveau de la disponibilité).
Patroni : en cours d'évaluation chez nous car il semble très prometteur et plus simple que pacemaker/PAF et plus fiable d'après les tests que j'ai pu voir en POC. En plus adossé à du HA proxy, si votre application est faite pour, on peut faire de la répartition de charge (select sur les slaves) pour faire de la scalabilité horizontale.Les autres technos, je ne connais pas.
ben déjà merci pour ta réponse : ca fait toujours plaisir d'avoir des avis solides.
Sinon le lien mis au-dessus niveau archi, ils vous semblent jouable ? (on a trois sites) :
https://nuage.ilinux.fr/s/yzS3BBpDW38QNEF
Note : j'ai pas trop compris la différence entre des serveurs
- PG StandBy (???) ,
- PG Replica
- PG Witness replica ?
- PG primary ?
Dernière modification par ledufakademy (06/04/2020 17:52:04)
Hors ligne
oui avec 3 sites c'est jouable sans probleme. tel qu'indiqué dans le lien.
primary : c'est le master qui est ouvert en ecriture.
replica et standby : ce sont les slaves en lecture seule et en attente.
witness : ?
Cordialement,
Sébastien.
Hors ligne
D'après le support de formation Dalibo (les outils de réplication):
L’outil repmgr3 de 2ndQuadrant permet la gestion de la haute disponibilité avec notamment la gestion des opérations de clonage, de promotion d’une instance en primaire et lad émotion d’une instance.L’outil repmgr peut également être en charge de la promotion automatique du nœud secondaire en cas de panne du nœud primaire, cela implique la mise en place d’un serveur supplémentaire par cluster HA (paire primaire/secondaire) appelé témoin (witness). Cette machine héberge une instance PostgreSQL dédiée au processus daemon repmgrd, processus responsable d’effectuer les contrôles d’accès réguliers à l’instance primaire et de promouvoir le nœud secondaire lorsqu’une panne est détectée et confirmée suite à plusieurs tentatives échouées consécutives.Afin de faciliter la bascule du trafic sur l’instance secondaire en cas de panne du primaire,l’utilisation d’une adresse IP virtuelle (VIP) est requise. Les applications clientes (hors administration) doivent se connecter directement à la VIP.
Ce concept de témoin est un concept général souvent utilisé dans les systèmes de haute-disponibilité.
Dernière modification par pifor (06/04/2020 18:20:04)
Pierre
Hors ligne
oui avec 3 sites c'est jouable sans probleme. tel qu'indiqué dans le lien.
primary : c'est le master qui est ouvert en ecriture.
replica et standby : ce sont les slaves en lecture seule et en attente.
witness : ?
Witness est le témoin pour le quorum du cluster. (nombre impairs pour les votes !)
Hors ligne
Salut,
notice: dev PAF et j'aime la HA
Les deux solutions viables actuelles sont Patroni et Pacemaker/PAF, pour une raison claire: ils font de la HA correctement et pas avec des bouts de scotch ou en laissant l'administrateur développer lui même les points critique de l'archi.
Repmgr ou pgPool ne supportent ni le fencing, ni le watchdog, ni de (vrai) quorum. Ils nécessitent de fournir des scripts où vous aurez à gérer ce type de notions vous même. Des notions dev et maintenues par des experts en HA depuis plus de dix ans dans Pacemaker. Vous n'obtiendrez jamais quelque chose de propre et fiable. Néanmoins, si vous avez précisément identifié les différents cas où l'outil n'est pas capable de gérer correctement une bascule, que vous acceptez ce risque et que vous avez bien tout documenté, alors pourquoi pas.
Concernant repmgr, le witness n'est pas un vrai qorum. Chaque nœud dans son coin décide de quand il faut faire une élection. Sur ce point, c'est déjà un peu risqué. Ensuite, si il "voit" le witness, il le compte d'office pour une voix dans son calcul. Le witness est complètement passif. On pourrait le comparer au qdevice dans une stack Pacemaker, sauf que le qdevice prend réellement part à l'élection et décide à qui il donne sa voix en fonction de l'algo choisi. Mais bon, contrairement à pgPool, on peut éventuellement construire une stack repmgr convenable avec beaucoup d'investissement et une surcouche de développement importante pour fiabiliser la chose au maximum. Reste ensuite à documenter ce qui ne va pas, comme d'hab.
Patroni ne supporte pas le fencing. Mais lui, il a un vrai quorum grâce au cluster DCS (à monter de préférence *à part*) et surtout supporte le watchdog. Une stack Patroni saine active le watchdog. Il y a deux/trois petits détails (peu significatifs) dans Patroni qui me font malgré tout préférer Pacemaker. En outre, la gestion d'une vIP pour atteindre le primaire est plus complexe qu'il n'y parait. Du coup, utilisez HAProxy, mais ça rajoute un service à gérer dans votre stack...Ou collez l'intelligence dans la couche applicative si vous le pouvez, mais votre archi devient invasive coté applicatif. Nous avons creusé vip-manager ces derniers temps, plutôt une bonne idée, mais le diable se cache dans les détails. Bref, Ici aussi, tant qu'on a conscience des failles possibles de son archi et que c'est documenté, on peut dormir sur ses deux oreilles. Moi, je dors mieux en sachant Patroni/DCS aux manettes qu'avec l'un des deux précédents. Surtout quand un watchdog est prêt à te coller un reset derrière les oreilles si ton process n'est pas obéissant 
Enfin, Pacemaker supporte le fencing, le quorum, le watchdog, le qdevice ou encore le storage base death (sbd). Avec tout ça, vous pouvez construire tout pleins d'archis fiables différentes et rigolotes (j'en fait trop ?) en fonction de vos moyens, matériel dispo, équipes concernées, etc:
* un cluster 2 nœuds FIABLE avec quorum (un peu spécial) et fencing quand on est serré en nombre de machine
* l'équivalent de Patroni avec 2+ nœuds + un qdevice (capable de participer à plusieurs clusters comme un cluster DCS)
* un cluster shared storage, simple et efficace si bien construit
* un cluster shared nothing avec PAF, pas très compliqué à monter et efficace si bien construit
* du poison pill pour le fencing si vous avez du stockage accessible depuis tous les nœuds (sbd)
* ...
Mais c'est bien là le problème de Pacemaker. Il propose de gérer la HA de tout type de services, le plus correctement possible. La HA et toutes ces notions sont complexes, donc Pacemaker est complexe et on se perd dans la jungle des notions et possibilités. Mais une fois l'archi construite et comprise, c'est que du bonheur. En échange:
* gérer une vIP avec Pacemaker, c'est 4 lignes de **définition** (https://clusterlabs.github.io/PAF/Quick … -resources). Nous n'avons toujours pas trouver comment faire fiable avec les autres solutions.
* une bascule de rôle se fait en une commande, sans redémarrage des standby
* pas de split brain possible
* un projet *activement* développé par RedHat, Suse, Linbit et hastexo
* du support professionnel coté système (RH et Suse entre autre)
* paquets dispos et à jour sur toutes les distro Linux de bon goût (utilisez pcs!)
* intégrer HAProxy au dessus de votre stack Pacemaker (inutile de l'y intégrer), c'est aussi complexe qu'avec Patroni. Pas plus pas moins. Bienvenue la répartition de charge
Bref, je suis biaisé, c'est évident. Plus je creuse Pacemaker, plus je découvre sa souplesse et sa robustesse. Sans parler de sa petite communauté bienveillante et accueillante. On peut éventuellement lui reprocher de ne pas avoir assez de documentation, mais nous avons tenté d'y répondre un peu dans la doc PAF...et nous devrions encore ajouter des pages de doc.
Concernant Patroni, il est simple et fiable et je l'aime aussi pour ça. Mais pour être juste dans la comparaison, il faut aussi compter la montée en compétence sur le DCS choisi (mais parfois déjà présent dans le réseau) et l'ajout au dessus d'autres briques (eg. HAProxy, confd). Reste que se prendre des backtrace python sur de la prod (coté cli ou daemon) ça peut parfois effrayer un peu (rare hein, mais par exemple: https://github.com/zalando/patroni/issues/1418)
Quelque soit l'outil choisi, vous ne devez pas faire l'économie de tests poussés, de torture de votre cluster, de tout documenter, d'écrire **toutes** les procédures, de penser à vos backups, de prévenir l'équipe réseau, l'équipe SAN, les dev ou devops. Bref, préparez-vous à l'imprévisible
Bon courage !
Hors ligne
je vous remercie tous pour vos réponses : elles m'aident beaucoup.
le logiciel libre a un sacré coup à jouer en ce moment ! croyez moi.
Hors ligne
Pages : 1
