Sujet

Cluster without a VIP
- gh #108
- Google Cloud Engine
- et probablement ailleurs
Comment diriger les connexions vers l’instance de prod ?
Comment configurer la réplication ?
tentative avec HAProxy

Archi présentée

OS : CentOS 7
Pacemaker/PAF
4 nœuds: srv1, srv2, srv3 + log-sink
HAProxy 1.5.18

Rappel vIP

détails du démarrage
détails d’un switchover

HAProxy

proxy TCP couche 4…
les clients “parlent” à HAProxy et ne voient pas les instances pgsql
les instances “parlent” à HAProxy et ne voient pas directement les clients
méthodes de vérifications des serveurs variées
différents algos d’équilibrage de charge
capacités d’analyse jusqu’en couche 7 eg. pour le HTTP

Intégration dans la stack

HAProxy écoute sur 5432 pour l’instance primaire
HAProxy écoute sur 5433 pour les standby
PostgreSQL écoute sur 5434
démarré sur tous les serveurs
- redondance (no SPoF)
- pas en HA => simplicité

Configuration simplifiée de HAProxy

listen prod
    bind           *:5432
    server         srv1 srv1:5434
    server         srv2 srv2:5434
    server         srv3 srv3:5434

listen stdby
    bind           *:5433
    server         srv1 srv1:5434
    server         srv2 srv2:5434
    server         srv3 srv3:5434

Statut des instances

par défaut, roundrobin vers tous les nœuds !
supporte des health check pour filtrer les instances
l’API ReST de Patroni expose le rôle de chaque instance
rien dans Pacemaker/PAF
“développement” nécessaire: pgsql-state

systemd / pgsql-state

cat<<'EOF' > /etc/systemd/system/pgsql-state.socket
[Unit]
Description=Local PostgreSQL state

[Socket]
ListenStream=5431
Accept=yes

[Install] 
WantedBy=sockets.target
EOF

systemd / pgsql-state

cat<<'EOF' > /etc/systemd/system/pgsql-state@.service
[Unit]
Description=Local PostgreSQL state

[Service]
User=postgres
ExecStart=/usr/pgsql-12/bin/psql -p 5434 -Atc          \
  "SELECT CASE WHEN pg_is_in_recovery() THEN 'standby' \
               ELSE 'production' END"
StandardOutput=socket
EOF

systemctl --now enable pgsql-state.socket

systemd / pgsql-state

Test simpliste depuis l’un des serveurs:

srv2:~# for s in srv{1..3}; do
    echo -ne "$s: "
    nc --recv-only "$s" 5431
done
srv1: production
srv2: standby
srv3: standby

systemd / pgsql-state

Tests de défaillance autour de pgsql-state:

# socket arrêté
srv2:~# nc --recv-only srv3 5431
Ncat: Connection refused.

# PostgreSQL arrêté
srv2:~# nc --recv-only srv3 5431
psql: error: could not connect to server: could not connect to server: No such file or directory
  Is the server running locally and accepting
  connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5434"?

Intégration dans HAProxy

listen prod
    bind           *:5432
    option         tcp-check
    tcp-check      connect port 5431
    tcp-check      expect string production
    default-server inter 2s fastinter 1s rise 2 fall 1 on-marked-down shutdown-sessions
    server         srv1 srv1:5434 check
    server         srv2 srv2:5434 check
    server         srv3 srv3:5434 check

Paramètres

inter 2s: vérifie toutes les 2s
fastinter 1s: toutes les secondes en période de transition
rise 2: deux check valides pour devenir accessible
fall 1: inaccessible dès le premier check échoué
on-marked-down shutdown-sessions: déconnecte tous les clients si le backend devient inaccessible

Pour les standby

listen stdby
    bind           *:5433
    balance        leastconn
    option         tcp-check
    tcp-check      connect port 5431
    tcp-check      expect string standby
    default-server inter 2s fastinter 1s rise 2 fall 1 on-marked-down shutdown-sessions
    server         srv1 srv1:5434 check
    server         srv2 srv2:5434 check
    server         srv3 srv3:5434 check

HAProxy et pgsql-state

Récapitulons en image pour eg. le pool prod.

HAProxy et pgsql-state

Jamais plus d’une instance est désignée comme primaire…vraiment ?

Pacemaker (ou Patroni) n’autorise qu’un primaire à la fois…
- aucun problème du point de vue des données
…mais HAProxy peut pointer une connexion vers un standby si mal configuré
default-server [...] rise 2 fall 1 [...]

HAProxy et pgsql-state

Mais pas suffisant:

race condition possible entre deux health check
un standby pourrait s’auto-repliquer !

solution (comme avec une vIP):

local replication all              reject
host  replication all $NODENAME    reject
host  replication all 127.0.0.1/32 reject
host  replication all ::1/128      reject

Archi finale

HAProxy et pgsql-state fusionnés pour simplifier les diagrammes
réplication au travers des HAProxy via localhost
pgsql-state sur le port 5431
clients rw sur le port 5432
clients ro sur le port 5433
PostgreSQL sur le port 5434

stats HAProxy

listen stats
    mode http
    bind *:7000
    stats enable
    stats uri /
    timeout connect 15s
    timeout client  15s
    timeout server  15s

stats HAProxy

Configuration:

global
    stats socket ipv4@*:9999
    stats socket /var/lib/haproxy/stats

Utilisation:

$ echo "show stat" | nc -U /var/lib/haproxy/stats | column -s, -t | less -S
$ echo "show stat" | ncat 10.20.30.51 9999 | column -s, -t | less -S

…ou en mode cli. Il est donc possible de collecter ces statistiques en CSV et de les exploiter eg. dans grafana.

À noter qu’il est aussi possible d’effectuer quelques actions d’administration au travers de ces sockets s’ils l’autorisent. Dans la configuration, ça donne:

stats socket ipv4@*:9999 level admin

Il est alors possible par exemple de déclarer un backend inaccessible administrativement:

$ echo show stat|ncat 10.20.30.51 9999|cut -d, -f 1,2,18,28,29|column -s, -t
# pxname  svname    status  iid  sid
stats     FRONTEND  OPEN    2    0
stats     BACKEND   UP      2    0
prd       FRONTEND  OPEN    3    0
prd       srv1      DOWN    3    1
prd       srv2      DOWN    3    2
prd       srv3      UP      3    3
prd       BACKEND   UP      3    0
stb       FRONTEND  OPEN    4    0
stb       srv1      UP      4    1
stb       srv2      UP      4    2
stb       srv3      DOWN    4    3
stb       BACKEND   UP      4    0

$ echo show stat 4 4 2|ncat 10.20.30.51 9999|cut -d, -f 1,2,18,28,29|column -s, -t
# pxname  svname  status  iid  sid
stb       srv2    UP      4    2

$ echo disable server stb/srv2|ncat 10.20.30.51 9999

$ echo show stat 4 4 2|ncat 10.20.30.51 9999|cut -d, -f 1,2,18,28,29|column -s, -t
# pxname  svname  status  iid  sid
stb       srv2    MAINT   4    2

Travail à la maison

Vagrantfile dispo pour reconstruire cette archi
cf. README
- remplacez 3nodes-vip par 3nodes-haproxy
faites moi des retours

Pros

pas de vIP, la contrainte de base
équilibrage de charge possible vers les standby
pgsql-state ouvert à tous
- information dispo aux couches applicatives
accès direct aux instances toujours possible !

Cons

pgsql-state ouvert à tous
- sécurité ? filtrer par un firewall ?
- information dispo aux couches applicatives, pas nécessairement acceptable
archi plus complexe qu’avec une vIP
dépend de la disponibilité de Systemd
- peu grave
systemd.socket accepte par défaut 100cnx/s
- le service passe en failed
- doit être redémarré (automatiquement ?)
- attention au DoS
- se configure aisément

Pistes de travail

health checks
- utilisation du check-pgsql intégré
  - pas d’authent sécurisée possible
- édition du pg_hba lors de la bascule…
- fermeture de port avec le RA portblock
- autres idées ?
keepalived/LVS

Le tcp-check permet d’envoyer et valider des données binaires. Voici un exemple qui se connecte, sans authentification, et effectue une requête SQL pour déterminer si l’instance est primaire ou non, le tout en binaire pour reproduire le protocole de PostgreSQL:

https://gist.github.com/arkady-emelyanov/af2993ab242f9a1ec0427159434488c4

Dans un article, Percona propose de modifier le contenu du pg_hba lors des bascules pour rejeter un rôle spécifique en fonction de l’état de chaque instance. Plutôt hacky.

https://www.percona.com/blog/2019/11/08/configure-haproxy-with-postgresql-using-built-in-pgsql-check/

Il semble que le projet keepalived soit capable de configurer du LVS et effectuer de l’équilibrage de charge. À creuser, notamment pour ce qui est des health check. Il pourrait être plus performant dans les modes tunnel ou routage, bien moins lourd que la ré-écriture de paquet comme du NAT.

Voir à ce propos le chapitre “LVS CONFIGURATION” dans la documentation officielle: https://www.keepalived.org/manpage.html

Démo

$ ncat --recv-only 10.20.30.53 5431
standby

$ pgbench -i -s 10 -h 10.20.30.53
dropping old tables...
creating tables...
generating data...
100000 of 1000000 tuples (10%) done (elapsed 0.04 s, remaining 0.36 s)
[...]

$ for i in {1..6}; do psql -XAtc 'show cluster_name' "host=10.20.30.53 port=5432" & done
pgsql-srv1
pgsql-srv1
pgsql-srv1
pgsql-srv1
pgsql-srv1
pgsql-srv1

$ for i in {1..6}; do psql -XAtc 'show cluster_name' "host=10.20.30.53 port=5433" & done
pgsql-srv2
pgsql-srv3
pgsql-srv2
pgsql-srv2
pgsql-srv3
pgsql-srv3

HAProxy + PAF

Sujet

Archi présentée

Rappel vIP

HAProxy

Intégration dans la stack

Configuration simplifiée de HAProxy

Statut des instances

systemd / pgsql-state

systemd / pgsql-state

systemd / pgsql-state

systemd / pgsql-state

Intégration dans HAProxy

Paramètres

Pour les standby

HAProxy et pgsql-state

HAProxy et pgsql-state

HAProxy et pgsql-state

Archi finale

stats HAProxy

stats HAProxy

stats HAProxy

Travail à la maison

Pros

Cons

Pistes de travail

Démo