Vous n'êtes pas identifié(e).
Bonjour à tous,
Je souhaite installer PostgreSql 9.0.4.1 (version imposée) sur un cluster à basculement composé de 2 noeuds sous Windows 2008 r2 afin d'avoir le service en haute disponibilité. J'ai pu installer PostgreSql sur le premier noeud (qui sera le serveur actif) en choisissant C:\Program Files\PostgreSQL\9.0 pour le dossier d'installation et un volume partagé de cluster (CSV) pour recevoir les data.
Jusque là, tout va bien. Là ou çà se gâte c'est quand j'installe PostgreSql sur le deuxième noeud dans le mêmes conditions. Le programme m'avertit qu'une base de donnée existe déjà et sera mise à jour (sous entendu : le compte de service local "postgres" va prendre possession des fichiers de données). L'installation se termine pourtant sans problème mais impossible de démarrer le service sur le deuxième noeud du cluster (en prenant garde d'arrêter le service sur le premier noeud au préalable).
L'observateur d'évènements du second noeud m'indique ceci :
"La description de l’ID d’événement 0 dans la source PostgreSQL est introuvable. Le composant qui a déclenché cet événement n’est pas installé sur l’ordinateur local ou l’installation est endommagée. Vous pouvez installer ou réparer le composant sur l’ordinateur local.
Si l’événement provient d’un autre ordinateur, les informations d’affichage doivent être enregistrées avec l’événement.
Les informations suivantes étaient incluses avec l’événement :
postgres ne peut pas accéder au fichier de configuration à C:/ClusterStorage/Volume2/data/postgresql.conf : No such file or directory"
Le fichier postgresql.conf est pourtant bien accessible.
Et si je redémarre le service postgresql sur le premier noeud (précédemment arrêté pour ne pas gêner l'installation sur le second noeud), je retrouve la même erreur et impossible de démarrer le service... Et toute mon installation est en vrac :-(
Je pense à un problème de permission pour l'utilisateur "postgres" sur le volume partagé de cluster qui supporte les data mais j'ai beau donner tous les droits, cela ne change rien. Si quelqu'un a déjà rencontré ce souci et connait la solution, je suis preneur ;-)
Cordialement,
Eric
Hors ligne
Bonjour,
la philosophie de base de postgres n'est pas de partager un répertoire de données pour faire de la haute disponibilité. Cela implique certaines problématiques, notamment l'assurance que les 2 postgres n'accèderont pas en même temps au répertoire data. De plus, dans ces conditions le stockage devient lui-même un SPOF (sauf erreur de ma part, je ne connais pas la technologie cluster shared volume).
Cependant, démarrer un postgres sur un répertoire data sur l'une ou l'autre des machines devrait pouvoir fonctionner. Les erreurs probablement du aux ménanismes du CSV, les messages remontés faisant allusions à des problèmes d'accès aux données côté windows plutôt qu'à un problème postgres.
Je vous conseillerais plutôt de regarder du coté de la streaming replication pour maintenir un esclave à jour et de promouvoir celui-ci en cas d'incident.
Julien.
https://rjuju.github.io/
Hors ligne
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.
Cordialement,
Eric
Hors ligne
Si, rjuju a raison. Le SPOF est votre SAN. Si votre SAN tombe, aucun accès n'est possible à la base de données.
Quant à la techno que vous voulez utiliser, je ne la connais pas mais il me semble que votre problème est plus un problème de configuration des utilisateurs au niveau Windows qu'un problème technique au niveau de PostgreSQL. En tout cas, le coup du répertoire partagé entre plusieurs machines Unix fonctionne. Cela étant, ma connaissance de Windows n'est pas suffisante pour aller plus loin.
Guillaume.
Hors ligne
Si, rjuju a raison. Le SPOF est votre SAN. Si votre SAN tombe, aucun accès n'est possible à la base de données.
Oui, après relecture, le SPOF est bien mon SAN. Sachant qu'il est fortement redondé (double contrôleur / alim, 2x4 ports réseau, RAID 5 sur 12 disques,...), j'ai moins de craintes :-)
Quant à la techno que vous voulez utiliser, je ne la connais pas mais il me semble que votre problème est plus un problème de configuration des utilisateurs au niveau Windows qu'un problème technique au niveau de PostgreSQL. En tout cas, le coup du répertoire partagé entre plusieurs machines Unix fonctionne. Cela étant, ma connaissance de Windows n'est pas suffisante pour aller plus loin.
Il est difficile, a priori, de trouver des utilisateurs avancés de PostgreSql sur Windows, et particulièrement sur la configuration avec le failover cluster de Windows 2008 r2. Je pense aussi qu'il y a un problème au niveau de l'attribution des permissions d'accès aux données sous Windows mais je ne parviens pas à trouver l'astuce.
Peut-être qu'un spécialiste de PostgreSql sous Windows passera par là...
Merci en tous cas pour vos réponses.
Cordialement,
Eric
Hors ligne
Oui, après relecture, le SPOF est bien mon SAN. Sachant qu'il est fortement redondé (double contrôleur / alim, 2x4 ports réseau, RAID 5 sur 12 disques,...), j'ai moins de craintes :-)
Il faut quand même faire attention et ne pas faire aveuglément confiance à un élément du cluter, ça peut parfois éviter de mauvaises surprises.
Je suppose que le san est partagé avec d'autres services ? Un raid 5 est déjà assez mauvais avec une base de données, si celui-ci est partagé, vous risquez d'avoir des performances vraiment mauvaises.
De plus, un unique raid 5 avec autant de disques multiplie les probabilités d'une panne simultanée sur 2 disques.
Sinon, effectivement il y a peu de monde qui utilise postgres sous windows. VOus avez sans doute déjà vérifié, mais il faut regarder l'utilisateur démarrant le service postgres et s'assurer qu'il ait toutes les autorisations sur le répertoire data ainsi que sur tous les éléments présents dans ce dossier. De plus, cet utilisateur ne doit pas être administrateur.
Sinon, est-ce que le répertoire du CSV est bien accessible pour cet utilisateur ?
Julien.
https://rjuju.github.io/
Hors ligne
Sinon, effectivement il y a peu de monde qui utilise postgres sous windows. VOus avez sans doute déjà vérifié, mais il faut regarder l'utilisateur démarrant le service postgres et s'assurer qu'il ait toutes les autorisations sur le répertoire data ainsi que sur tous les éléments présents dans ce dossier. De plus, cet utilisateur ne doit pas être administrateur.
Sinon, est-ce que le répertoire du CSV est bien accessible pour cet utilisateur ?
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.
Cordialement,
Eric
Hors ligne
Je vois le problème. C'est peut-être une sécurité de CSV pour éviter l'accès simultané par les 2 instances. Le seul moyen de contourner ça serait d'utiliser un utilisateur active directory, accessible par les 2 machines. Ou un scripts qui modifie les droits et l'appartenance avant le lancement du service.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Suite de mes essais sur le sujet : J'ai partagé un dossier sur un de mes serveurs. Nom de partage : "BasePgsql". Ce partage est mappé de manière permanente sur les premier noeud de mon cluster sous la lettre K:.
J'ai ensuite installé PostgreSql sur ce même noeud en pointant les data vers un dossier "data" sur le partage. Soit k:\data\. A la fin de l'installation, le service postgresql ne démarre pas et j'ai à nouveau l'erreur suivante dans les journaux de Windows :
Nom du journal :Application
Source : PostgreSQL
Date : 20/11/2012 09:45:07
ID de l’événement :0
Catégorie de la tâche :Aucun
Niveau : Erreur
Mots clés : Classique
Utilisateur : N/A
Ordinateur : NODE1
Description :
La description de l’ID d’événement 0 dans la source PostgreSQL est introuvable. Le composant qui a déclenché cet événement n’est pas installé sur l’ordinateur local ou l’installation est endommagée. Vous pouvez installer ou réparer le composant sur l’ordinateur local.Si l’événement provient d’un autre ordinateur, les informations d’affichage doivent être enregistrées avec l’événement.
Les informations suivantes étaient incluses avec l’événement :
postgres ne peut pas accéder au fichier de configuration à K:/data/postgresql.conf : No such file or directory
Le fichier K:/data/postgresql.conf est bien présent mais impossible d'autoriser le compte local de service NODE1\postgres a accéder à cette ressource. Et c'est normal !
Il faudrait que le compte de service soit un compte de mon domaine pour permettre cela mais il ne doit pas avoir les privilèges "admin". J'ai donc créé un compte d'utilisateur du domaine MONDOMAINE\postgres et je lui ai attribué les permissions de lecture-écriture-modification-suppression sur le dossier K:/data/ et tous ses éléments récursifs.
Résultat : Pas mieux :-(
Toujours impossible de démarrer le service qui retourne la même erreur que précédemment. Je veux bien admettre que le filesystem de mon NODE1 puisse avoir des problèmes (bien que je n'y crois pas) mais là, il s'agit du FS d'un autre serveur qui fonctionne parfaitement et qui partage déjà plusieurs autres dossiers. Donc, le CSV n'est peut-être pas en cause... Et je suis toujours sans solution pour l'instant.
Cordialement,
Eric
Hors ligne
S'agit-il d'un lecteur réseau ? (net use)
Si oui, le partage est-il bien effectué avec le user (local ou domaine) lançant le service ?
Julien.
https://rjuju.github.io/
Hors ligne
S'agit-il d'un lecteur réseau ? (net use)
Oui.
Si oui, le partage est-il bien effectué avec le user (local ou domaine) lançant le service ?
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...
Cordialement,
Eric
Hors ligne
Je voulais dire, est-ce que le partage est fait avec cet utilisateur ? Car les lecteurs réseaux ne sont pas communs à tous les utilisateurs. Si vous ouvrez un explorateur en tant que cet utilisateur, est-ce que le lecteur K est bien disponible ?
Julien.
https://rjuju.github.io/
Hors ligne
Oui le partage K: est disponible pour ce user en lecture et en écriture. Je peux créer manuellement un fichier et un dossier sur ce partage depuis le compte de l'utilisateur en question et supprimer tous ce qu'il y a dedans.
Cordialement,
Eric
Hors ligne
