Vous utilisez le nœud principal ZFS comme serveur de base de données?

J'utilise un NAS à double tête soutenu par ZFS pour le stockage partagé en cluster à haute disponibilité, basé sur l'architecture recommandée par Nexenta comme indiqué ici:

Les disques dans 1 JBOD stockent les fichiers de base de données pour une seule base de données Postgres de 4 To et les disques dans l'autre JBOD stockent 20 To de gros fichiers plats binaires bruts (résultats de cluster pour les simulations de collision d'objets stellaires volumineux). En d'autres termes, le JBOD soutenant les fichiers Postgres gérera principalement des charges de travail aléatoires tandis que le JBOD soutenant les résultats de la simulation gérera principalement des charges de travail en série. Les deux nœuds principaux ont 256 Go de mémoire et 16 cœurs. Le cluster a environ 200 cœurs chacun conservant une session Postgres, donc je m'attends à environ 200 sessions simultanées.

Je me demande s'il est sage dans ma configuration que les nœuds principaux ZFS agissent simultanément comme une paire miroir de serveurs de base de données Postgres pour mon cluster? Les seuls inconvénients que je peux voir sont:

Moins de flexibilité pour faire évoluer mon infrastructure.
Niveau de redondance légèrement inférieur.
Mémoire et ressources CPU limitées pour Postgres.

Cependant, l'avantage que je vois est que ZFS est assez stupide quant au basculement automatique de toute façon et je n'ai pas à dépenser beaucoup de travail pour que chaque serveur de base de données Postgres détermine si un nœud principal a échoué car il échouera avec la tête nœud.

— elleciel
source

PostgreSQL ne peut être exécuté sous aucune forme de mode de stockage partagé. Les tentatives en ce sens échoueront. Les tentatives de contourner les protections pour vous empêcher de le faire (comme se déplacer / se cacher postmaster.pid) entraîneront une grave corruption des données.

— Craig Ringer

@CraigRinger Hm, est-ce contradictoire avec wiki.postgresql.org/wiki/Shared_Storage ?

— elleciel

Vous pouvez l'exécuter si vous garantissez absolument qu'un seul postmaster peut jamais accéder au répertoire de données en même temps. Un bon STONITH / fencing est une exigence absolue pour éviter la corruption de données à grande échelle. Personnellement, je ne pourrais pas le faire. Cela élimine également les avantages dont vous parlez - déterminer quel est le serveur principal / live automatiquement, etc. - car vous devez gérer le basculement.

— Craig Ringer

J'ai révisé la page wiki pour la rendre plus claire; merci de l'avoir signalé.

— Craig Ringer

Cela n'a aucun sens. La solution HA de Nexenta tire parti du clustering RSF-1 . On dirait que vous faites cela avec ZFS sur Linux sans la pièce RSF-1. Attention, ZFS sur Linux n'a pas vraiment d'option de clustering, donc la référence Nexenta ne s'applique pas. Qu'avez-vous à gagner en ayant deux nœuds principaux?

— ewwhite

Vous ne pouvez pas avoir deux instances Postgres ("clusters" dans la terminologie Postgres) agissant sur les mêmes fichiers physiques.

si vous voulez des performances, le partage peut vous aider (avoir deux instances portant chacune des données différentes)

Si vous souhaitez une haute disponibilité, le basculement avec STONITH peut être la solution. vous devez vous assurer qu'alors le matériel est réparé, il n'essaie pas d'ouvrir la base de données pendant que le deuxième nœud la dessert.

— Jasen
source