PGSQL-HA: Difference between revisions

From Essential
Jump to navigation Jump to search
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
==PGSQL HA==
==PGSQL HA==
Voici un exemple de diagramme POSTGRES en HA :<br><br>
Voici un exemple de diagramme POSTGRES en HA :
<br><br>
[[File:PGSQL-HA.drawio.png]]
[[File:PGSQL-HA.drawio.png]]
<br><br>
<br><br>
Et voici le diagramme lors de la perte d'un noeud :<br><br>
Et voici le diagramme lors de la perte d'un noeud :
<br><br>
[[File:PGSQL-HA-DOWN.drawio.png]]
[[File:PGSQL-HA-DOWN.drawio.png]]
<br><br>
<br><br>
En date du 28/06/2022, seul la version 12 PostgreSQL est supporté avec cette architecture en RHEL8 :
Lors de la perte d'un noeud, les ressources redémarrent sur un autre noeud.
<br><br>
En date du 28/06/2022, seul la version 10 et 12 PostgreSQL est supporté avec cette architecture en RHEL8 :
*https://access.redhat.com/articles/5393501
*https://access.redhat.com/articles/5393501
*https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle?extIdCarryOver=true&sc_cid=7013a0000030xHQAAY
*https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle?extIdCarryOver=true&sc_cid=7013a0000030xHQAAY
Line 22: Line 26:
     *PROXY (pour mise à jour ou autrement répos interne)
     *PROXY (pour mise à jour ou autrement répos interne)


    *Choisissir entre clusteurs à 2 nœuds ou plus.
     *Pour une architecture à 2 nœuds, il faut une configuration particulière pour COROSYNC et s'assurer de configurer un "FENCING" retardé de quelques secondes pour l'un des nœuds, sinon il en résultera un cluster instable.
 
     *Pour une architecture à 2 nœuds, il est nécessaire une configuration à 2 nœuds sur COROSYNC et s'assurer de configurer un "FENCING" fermeture retardé de quelques secondes pour l'un des nœuds (sinon il en résultera un cluster instable).


     *Les ressources sont sans état.
     *Les ressources sont sans état.

Latest revision as of 12:00, 1 July 2022

PGSQL HA

Voici un exemple de diagramme POSTGRES en HA :

PGSQL-HA.drawio.png

Et voici le diagramme lors de la perte d'un noeud :

PGSQL-HA-DOWN.drawio.png

Lors de la perte d'un noeud, les ressources redémarrent sur un autre noeud.

En date du 28/06/2022, seul la version 10 et 12 PostgreSQL est supporté avec cette architecture en RHEL8 :

Architecture typique

   *2 salles
   *2FC / serveur (actif/actif) (SAN)
   *2*10Gbit/s ethernet / serveur (actif/passif, possible actif/actif si PXE sur VLAN 0 natif)
   *VLAN IPMI (pour le "FENCING")
   *VLAN ADMIN qui doit être le VLAN natif si BOOTSTRAP par PXE (admin, provisioning, heartbeat)
   *VLAN UTILISATEUR (services applicatifs)
   *NTP
   *DNS+DHCP+PXE+TFTP+HTTP pour le provisionnement automatique
   *PROXY (pour mise à jour ou autrement répos interne)
   *Pour une architecture à 2 nœuds, il faut une configuration particulière pour COROSYNC et s'assurer de configurer un "FENCING" retardé de quelques secondes pour l'un des nœuds, sinon il en résultera un cluster instable.
   *Les ressources sont sans état.
   *Pour les ressources DB il faut prévoir 8Go par base en général et le double pour un cluster à 2 nœuds (perte d'un nœud). Pour les ressources CPU, en règle générale, il n'y a pas de grandes exigences. Pour les sauvegardes à froid, PZSTD est actuellement conseillé.

Modèle de service typique

   *MULTIPATH
   *LUN
   *LVM
   *FS
   *NFS
   *USER
   *IP
   *DNS name
   *PROCESS
   *LISTENER

PGSQL HA STREAMING

En date du 28/06/2022, seul la version 10 PostgreSQL est supporté avec cette architecture en RHEL8.

PGSQL HA LOGICAL

Le mode "logical replication" n'est pas supporté actuellement.