Cluster PostgreSQL à stockage partagé

ioguix

Intro

Programme

  • présentation
  • points d’attentions
  • démo

Présentation

Principe de fonctionnement des clusters à stockage partagé.

Deux slides: très simple à expliquer !

Fonctionnement 1/2

  • un stockage accessible depuis plusieurs serveurs
  • les données de l’instance sont placées dans ce stockage
  • un seul à la fois serveur peut :
    • accéder au stockage
    • démarrer PostgreSQL

Fonctionnement 2/2

Cas d’une bascule sur incident:

  • retirer l’accès au stockage à l’ancien serveur
  • donner accès au stockage à un autre serveur
  • démarrer PostgreSQL sur cet autre serveur

Exemple

Cinématique simplifiée d’une bascule

Bilan

La HA, c’est pas si compliqué…

…mais c’est complexe.

Points d’attention

## HA du stockage

Un SPoF évident: le stockage

Nécessite :

  • un SAN répliqué
  • un SAN en HA (multipath, RAID dans le SAN, etc)
  • BONNE NOUVELLE: hors de notre périmètre !

Réservation du stockage

Obligation d’empêcher plus d’un serveur à la fois à accéder aux données.

  • le fencing nous protège déjà
  • …mais nous ne sommes jamais loin d’une erreur humaine
  • solutions :
    • configuration SAN (eg. réservation)
    • LVM systemid

LVM systemid

Configuration du systemid:

root@srv1:~# cat /etc/lvm/lvmlocal.conf
global {
        system_id_source = "uname"
}

Voir lvmsystemid(7).

Effet du systemid

root@srv1:~# vgchange -ay vg_san
  Cannot access VG vg_san with system ID srv2 with
  local system ID srv1.

root@srv1:~# vgchange --systemid srv1 vg_san
  Cannot access VG vg_san with system ID srv2
  local system ID srv1.

root@srv1:~# vgchange -y --systemid srv1 \
  --config 'local/extra_system_ids=["srv2"] vg_san

Fencing

Plusieurs possiblités:

  • fencing actif de serveur (droits système ?)
  • coupure d’accès au SAN (droits SAN ?)
  • sbd, watchdog et poison pill !

SBD

  • partition dédiée sur un stockage partagé
  • peut résider dans le même stockage que PostgreSQL
  • redondance possible jusqu’à 3 disques
  • quelques Mo pour des centaines de nœuds
  • serveur en mode standby si plus d’accès au SBD
  • reset watchdog si ça tourne mal
    • arrêt des ressources impossible
    • n’est plus capable de réagir assez vite…
  • canal de communication entre les nœuds
    • self-fencing à la réception d’un poison pill

Cold Standby

Inacceptable ?

Avantages

  • hyper simple à mettre en œuvre
    • géré par les équipes système et SAN
    • pas besoin de réplication PostgreSQL
  • indépendant de la configuration de PostgreSQL
  • possibilité d’ajout des secondaires triviale

Désavantage

  • Nécessite un stockage redondé et en HA

Démo

Briques

  • Debian 11
  • Pacemaker avec pcs
  • pas de fencing actif: SBD + watchdog
  • stockage disponible sur tous les nœuds
    • utilisation de LVM systemid
    • 2 partitions: SBD et PostgreSQL
  • lien de /etc/postgresql/12/main vers le SAN
  • une IP suivant le positionnement de PostgreSQL
  • une ressource dummy symbolisant une application
  • vagrant disponible:
    https://github.com/ioguix/vagrant-pgsql-sbd

Actions

  • démarrage
  • bascule
  • standby
  • boom

Fin

Questions