Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:rapports:2021:03-04 [2021/06/18 10:33] – créée tierce
+++ fr:rapports:2021:03-04 [2021/12/28 16:42] (Version actuelle) – supprimée tharyrok
@@ Ligne 1: / Ligne 1: @@
-# 2021/04/03 (Neutriton) : PostgreSQL HA
-* [Réunion précédente](https://wiki.neutrinet.be/fr/rapports/2021/03-13)
-* [Pad de la réunion](https://pad.libre.brussels/neutrinet-neutriton-2021-04-03)
-* [Liste des sujets Neutriton](https://pad.libre.brussels/mXBNhtS_R5ONoq2ZOkhwSw#)
-Présences :
- - Liberfix
- - Celo
- - Hgo
- - Tharyrok
-Jitsi : https://jitsi.belnet.be/neutriton
-Caldarium : https://caldarium.be/fr:contact
-## Météo
-*Moment informel durant lequel on exprime **en peu de mots** comment on se sent et si on a une attente forte pour la réunion.*
-*Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire :-)*
-### Attente(s) forte(s)
-*Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.*
-* Pouvoir decider de la solution du ha de psql
-## Ordre du jour
-### Resources
-* https://medium.com/searce/design-a-highly-available-postgresql-cluster-with-patroni-in-gcp-part-1-dfb6ed277806 (patroni uniquement)
-* https://scalegrid.io/blog/managing-high-availability-in-postgresql-part-1/
-* https://medium.com/@kristi.anderson/whats-the-best-postgresql-high-availability-framework-paf-vs-repmgr-vs-patroni-infographic-8f11f3972ef3
-Résumé des différents modes de HA: https://www.postgresql.org/docs/13/different-replication-solutions.html#HIGH-AVAILABILITY-MATRIX
-### Présentation de Patroni
-Il faut vraiment voir Patroni comme un framework. Il va utiliser plusieurs pièces.
-Etcd : permet à patroni de mettre dans la configuration et faire le quorum. Comme une db clé-valeur mais avec une notion de quorum. C'est simple à utiliser. Patroni supporte d'autres solutions pour gérer le quorum (voir la doc de Patroni). Il en faut trois pour avoir un quorum, mais pas obligé d'avoir trois PostgreSQL.
-Debian fournit une commande magique qui boostrap tout pour nous :
-```shell
-pg_createconfig_patroni 11 neutrinet
-```
-Patroni va communiquer avec la db qu'il gère et etcd. Il communique aussi avec les autres Patroni pour leur dire de synchroniser leurs données.
-HAProxy va contacter Patroni pour lui demander qui est le primary et qui sont les replicas. Un des patroni va répondre, et HAProxy va rediriger les requêtes SQL vers la DB en primary.
-Si la DB primary est déficiente, alors un des replicas va être élu en primary pour prendre le relais (c'est patroni qui s'occupe d'élire le primary).
-#### Installation de etcd
-On commence par etcd, qui est dans les repos debian :) Bien entendu, on le fait pour les trois serveurs:
-```shell
-apt install etcd
-```
-On crée un réseau privé pour etcd et patroni.
-psql-01 -> 10.0.0.4
-psql-02 -> 10.0.0.3
-psql-03 -> 10.0.0.2
-Dans `/etc/default/etcd` se trouve la config de etcd.
-On donne un nom au cluster (ex : `ǹeutrinet`)
-```conf
-# nom du serveur
-ETCD_NAME="psql-0X"
-# port d'écoute pour d'autres etcd
-# on doit définir tout ça pour lui dire d'écouter sur localhost ET sur son ip privée
-ETCD_LISTEN_PEER_URLS="http://10.0.0.4:2380"
-ETCD_LISTEN_CLIENT_URLS="http://localhost:2379, http://10.50.20.41:2379"
-ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.4:2380"
-# on définit tous les membres du cluster
-ETCD_INITIAL_CLUSTER="psql-01=http://10.0.0.4:2380,psql-02=http://10.0.0.3:2380,psql-03=http://10.0.0.2:2380"
-# si pas de configuration, tu fais quoi ? ben tu crées un nouveau cluster
-ETCD_INITIAL_CLUSTER_STATE="new"
-# token utilisé pour initialiser le cluster
-ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
-# clients peuvent savoir combien de clients dans le cluster existent, comme ça le client est capable d'aller sur un autre serveur
-ETCD_ADVERTISE_CLIENT_URLS="http://localhost:2379, http://10.0.0.4:2379"
-```
-Quand on parle de client, ce sont les patroni (ce sont eux qui vont parler à etcd).
-On supprime la config par défaut de etcd:
-```shell
-rm /var/lib/etcd/default
-```
-On redémarre les etcd :
-```shell
-systemctl restart etcd
-```
-Dans cette config, on n'a pas configuré la communication TLS, mais bon c'est qu'une démo ;)
-Commandes pour vérifier le statut du cluster:
-- cluster-health -> doit renvoyer `cluster is healthy` :sunflower:
-- member list -> doit renvoyer la liste des serveurs
-Dans les logs on va voir quel serveur devient leader. Chaque serveur possède un id unique (on voit à qui correspond l'id avec la commande `member list`)
-#### Installation de patroni
-```shell
-apt install patroni postgresql-contrib postgresql-client postgresql haproxy
-```
-Il faut détruire le cluster db postgresql par défaut. Par défaut, Debian créé un cluster main et le démarre. Donc :
-```
-pg_ctlcluster 11 main stop
-pg_lsclusters
-pg_dropcluster 11 main
-```
-Pour manipuler le cluster, Debian fournit une commande patroni :
-```
-pg_createconfig_patroni 11 neutrinet
-```
-Patroni a déjà des valeurs par défaut. Par contre, il faut lui dire comment se connecter à etcd.
-Patroni peut utiliser soit zookeeper, consul ou etcd pour gérer le quorum du cluster. Patroni peut juste se connecter à son etcd local et apprendre où se trouvent les autres Patroni.
-Par défaut, Patroni crée deux utilisateurs :
-- postgres
-- replica
-Dans `/etc/patroni/11-neutrinet.yml` on va modifier les IP publiques par les IP privées du cluster.
-pg_hba : définit comment les clients psql peuvent se connecter à la db. En mode tcp, il faut définir un mot de passe. En mode socket, on utilise le système de permissions Unix. Colonne 1: tcp vs socket (host vs local), et puis j'ai plus suivi :p
-On active le cluster puis on redémarre le patroni:
-```
-systemctl enable patroni@11-neutrinet
-systemctl restart patroni@11-neutrinet
-```
-Dans les logs, Patroni va fanfaronner que c'est lui le chef en agitant un cadenas: `i am the leader with the lock`
-Et les autres vont dire qu'ils sont secondaires et qu'ils suivent leur chef...
-Patroni possède une API REST avec laquelle on va un peu jouer. Notamment, des healtcheck pour savoir qui est le primary ou qui sont les replicas. On peut aussi forcer un primary à devenir replicas, etc.
-On doit viser l'url sur l'IP privée (sur localhost ça ne va pas marcher) :
-```shell
-curl http://10.0.0.4:8008/patroni | jq .
-```
-Pour avoir les infos du cluster:
-```shell
-curl http://10.0.0.4:8008/cluster | jq .
-```
-#### Installation de HAProxy
-On accélère, de toute façon la config va tenir sur quelques lignes.
-On active les metrics prometheus fournies par HAProxy… Enfin si la version est suffisamment récente :sweat_smile:
-Puis on va faire un reverse proxy du port par défaut de psql (5432) vers le port défini dans patroni (ici on met 5442). HAProxy va regarder le endpoint `/master` pour savoir qui est le master parmi les trois serveurs. Si le serveur ne répond pas 200 OK, alors HAProxy va considérer que ce serveur n'est pas primary.
-On fait pareil pour les replicas, sauf qu'on écoute sur le port 5433 et on regarde le endpoint `/replica`.
-Dans les logs de HAProxy, on va bien que psql-02 et psql-03 sont considérés DOWN sur /master (code http 503 Service unavailable), et psql-01 est considéré DOWN sur /replica (donc c'est lui le primary).
-- Il est plus important d'avoir un monitoring ?
-- Quel genre de problème peut-il y avoir quand il n'y a qu'un serveur physique ? (3 psql sur le même serveur) Qu'est-ce que ça apporte de plus à part de la charge sur le serveur ?
-- Patroni a l'air simple d'utilisation, les différents niveaux semblent logique.
-- Est-ce que Patroni va simplifier les choses ou rajouter de la complexité ? Notamment au niveau de la maintenance…
-- Patroni a beaucoup d'options et il y a moyen de tuner des choses. La configuration de base est sans doute suffisante pour Neutrinet.
-![](https://pad.libre.brussels/uploads/upload_e11c7f18c12793e5aecbe7da694b2d04.png)
-Raison de la HA : ne pas courir en cas d'incident. Si un des deux Proxmox crash, cela ne doit pas générer de la panique chez Neutrinet. L'autre aspect, ce sont les mises à jour. Sans réplication, on doit couper tous les services pour mettre à jour.
-En résumé : On a une VIP gérée par keepalived qui va se coller à une VM encore UP, et le HAProxy va détecter qui est le primary et qui sont les secondary. Mais, si on n'utilise pas le mode read-only, alors on peut virer le HAProxy. Mais alors comment on détecte le primary ? c'est keepalived qui peut tester ça grâce à l'API de patroni.
-```shell
-curl -X OPTIONS -I http://10.0.0.3:8008/primary
-```
-Patroni simplifie les backups : on peut prendre un replica et le sortir du cluster mais il est tout de même mis à jour. C'est sur celui-là qu'on envoit les backups.
-### Comparaison avec d'autres outils de PostgreSQL HA
-Alternatives sont
-- PAF (Postgresql Automatic Failover)
-- repmgr -> pas vraiment HA
-Patroni est sous licence MIT. PAF a pas vraiment de licence claire…
-Personne n'a de connaissance sur PAF, donc on irait plutôt vers Patroni.
-On décide d'utiliser Patroni \o/ \./ \O/ \°/
-## Prochaine réunion
-Prochain Neutriton (pfsense NAT) : 25/04 à 14h
-Lieu : Jitsi et/ou Caldarium
-Après ça, on aimerait faire un atelier dans la serre pour installer les VMs. On commencerait avec les sites statics (mediawiki, wikijs).
-## Météo de fin
-*Moment informel durant lequel on exprime **en peu de mots** comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif.*
-*Si une ou plusieurs **tension est née** durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.*