Oui.

Oui. J'ai créé un user du domaine qui lance le service postgresql et dispose des permissions de modification sur tout le partage (dossiers, sous-dossiers et fichiers).

Toujours le même résultat...

L'utilisateur démarrant le service postgresql est "postgres". C'est un utilisateur standard (non admin) et il a bien toutes les autorisations d'accès (droits de modification et suppression) au répertoire data et aux fichiers et sous-dossiers dans ce dossier. Mais, sous windows (je ne connais que très peu Linux), il y a une notion d'appartenance des comptes utilisateurs à un ordinateur. Par exemple, l'installation de postgresql sur le premier noeud de mon cluster attribue les permissions d'accès au user NODE1\postgres, où "NODE1" est le nom du serveur composant ce premier noeud. Lors de l'installation de postgresql sur le second noeud, il attribue ces mêmes permissions au user NODE2\postgres.

Cela ne devrait pas gêner et pourtant, c'est bien depuis l'installation sur le NODE2 que j'ai ces soucis.

Du coup il semble que le répertoire du CSV soit bien accessible par le user NODE1\postgres mais pas par le user NODE2\postgres. J'ai bien vérifié que les permissions étaient identiques entre ces deux comptes. J'ai même passé le user NODE2\postgres en "contrôle total" sur tous les fichiers et dossiers dans le CSV; sans succès. Au contraire, après avoir fait cette manip, c'est mon installation sur le NODE1 qui ne fonctionne plus non plus (même erreur : "Access denied"). A ce stade, je n'ai pas trouvé d'autre solution que de désinstaller postgresql sur les deux noeuds, supprimer le dossier data et réinstaller le tout.

Lorsque j'aurais réinstallé, je tenterai une expérience : Au lieu de pointer le dossier data vers le CSV, je vais utiliser temporairement un partage réseau classique; juste pour lever le doute sur le CSV. Si je rencontre les mêmes problèmes, mon architecture ne sera pas en cause.

Merci pour cette réponse, rjuju, qui s'approche de ce que j'ai pu apprendre lors d'une conversation que j'ai eu sur l'IRC de postgresql.org. On m'a aussi conseillé d'utiliser le mode Hot Standby mais cela engendre d'autres contraintes plus gênantes encore comme le fait qu'un serveur en standby, lorsqu'il devient actif suite à une défaillance du serveur actif d'origine, ne peut revenir à son état standby. En plus, il faut que chaque serveur composant le cluster ait son propre fichier de conf posgresql.conf.

Le principe du cluster à basculement de Windows repose sur le fait que le cluster "monitore" l'état du service (postgresql dans notre cas) et le démarre sur un seul des noeuds qui le compose. Donc, en théorie, cela devrait fonctionner mais ce n'est pas le cas. Le schéma de principe est identique à celui-ci : http://3.bp.blogspot.com/-nBKMs4n5y_U/T … 600/ha.PNG qui est issu de cet article http://raghavt.blogspot.fr/2011/10/high … -with.html

Il doit donc surement s'agir d'un pb entre le CSV et de les permissions sur le dossier data malgré le fait que le service postgresql démarré sur un noeud ait toutes les permissions requises. Un verrou imposé par postgre ?

Quoi qu'il en soit, c'est vraiment dommage... J'avoue débuter avec postgre par nécessité car je suis plus à l'aise avec MySql qui autorise ce type de fonctionnement en cluster avec un seul stockage partagé des données en haute dispo. Va falloir que je trouve une autre approche. Peut-être abandonner l'idée de la haute disponibilité... Je ne souhaite pas mettre en place une réplication car cela imposerait de dupliquer les données sur plusieurs volumes (un par noeud de cluster). Trop lourd, couteux et impactant les performances d'I/O des disques.

Pour info, un Cluster Shared Volume est un volume (généralement distribué par un SAN) qui est géré par le cluster de manière à ce qu'il soit toujours accessible en simultané par tous les noeuds composant le cluster. Le chemin d'accès est identique quelque soit le serveur (sous Windows, ce sera C:/ClusterStorage/VolumeX où X est le numéro d'ordre du volume). Les permissions d'accès sont gérées par le filesystem de l'OS de la même manière que s'il s'agissait d'un volume classique. Ce n'est donc pas un SPOF. Dans le schéma fourni plus haut, le CSV correspondrait au /data_dir.