Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je tente une migration vers postgreSQL 8.4 depuis un autre SGDB et il se pose la question de la haute disponibilité.
L'idée suivie pour le moment est :
- d'utiliser un disque partagé où nous stockerions le groupe de base de données.
- l’utilisation de Windows Server avec l'utilisation de Microsoft Cluster Service pour gérer le failover (et l'ip virtuelle).
PostgreSQL offrant des services windows, ceux-ci sont ils fait de manière à ce que deux instance ne puisse tourner en même temps ?
Remarque qui a amené la question : Nous avons constaté qu'avec certains services l’arrêt est détecté par Windows avant que le service soit bien totalement arrêté, et "l'esclave" peut redémarrer avant que le "maitre" s’arrête.
Pour le dossier partagé il sera probablement sur un SAN (ce qui d’après la documentation ne doit pas poser des problèmes) , mais pour les premiers tests nous utiliserons un répertoire partagé (CIFS/SMB).
J'ai vu également une remarque concernant les montages NFS :
Beaucoup d'installations créent les clusters de bases de données sur des systèmes de fichiers réseau. Parfois, cela utilise directement par NFS. Cela peut aussi passer par un NAS (acronyme de Network Attached Storage), périphérique qui utilise NFS en interne. PostgreSQL™ ne fait rien de particulier avec les systèmes de fichiers NFS, ceci signifiant que PostgreSQL™ suppose que NFS se comporte exactement comme les lecteurs connectés en local (DAS, acronyme de Direct Attached Storage). Si les implémentations du client et du serveur NFS ont une sémantique non standard, cela peut poser des problèmes de fiabilité (voir http://www.time-travellers.org/shane/pa … mful.html). En particulier, des écritures asynchrones (décalées dans le temps) sur le serveur NFS peuvent poser des soucis de fiabilité. Si possible, montez les systèmes de fichiers NFS en synchrone (autrement dit sans cache) pour éviter cela. De même, le montage NFS n'est pas recommandé. Les SAN utilisent un protocole de communication bas-niveau plutôt que NFS.
J'ai quelques difficultés à comprendre ceci (la version anglaise ne m’éclaire pas plus) : Si possible, montez les systèmes de fichiers NFS en synchrone (autrement dit sans cache) pour éviter cela. De même, le montage NFS n'est pas recommandé.
Peut on utiliser NFS en synchrone ? pour CIFS/SMB y'a t il la même problématique ?
La solution semble t elle cohérente ou y a-t-il quelque chose de plus adapté à la haute disponibilité ?
Merci d'avance pour les réponses
Hors ligne
PostgreSQL offrant des services windows, ceux-ci sont ils fait de manière à ce que deux instance ne puisse tourner en même temps ?
Non, vous pouvez lancer autant d'instances (instance au sens PostgreSQL, donc répertoire de données différent, port différent).
Peut on utiliser NFS en synchrone ?
Évitez NFS le plus possible.
pour CIFS/SMB y'a t il la même problématique ?
Je n'ai pas particulièrement d'informations sur SMB, mais j'ai un gros doute.
La solution semble t elle cohérente ou y a-t-il quelque chose de plus adapté à la haute disponibilité ?
C'est difficilement une solution de haute-disponibilité si vous n'avez qu'un répertoire de données. Que se passe-t-il en cas de panne du SAN ?
Guillaume.
Hors ligne
Merci pour les réponses.
C'est difficilement une solution de haute-disponibilité si vous n'avez qu'un répertoire de données. Que se passe-t-il en cas de panne du SAN ?
Il me semblait qu'un SAN était conçu pour avoir une très haute disponibilité.
Toutefois si des solutions plus pertinentes qui permettent :
d’éviter la perte de données
de conserver les performances
et qui sont compatibles windows/linux existent, je suis preneur.
Hors ligne
Tout dépend du prix du san 
mettre tous ses oeufs dans le même panier c'est jamais le mieux 
Hors ligne
Il me semblait qu'un SAN était conçu pour avoir une très haute disponibilité.
Ça ne l'empêche pas de pouvoir tomber en panne. Surtout qu'à l'intérieur, ce sont des disques, et que les disques sont faillibles.
Et ce que dit kenrio est très juste: mettre tous ses oeufs dans le même panier c'est jamais le mieux
Bref, tout dépend de l'importance et du but de cette haute disponibilité. Difficile d'en dire plus sans en savoir plus sur le besoin.
Guillaume.
Hors ligne
Bref, tout dépend de l'importance et du but de cette haute disponibilité
Bonjour,
Je ne vois pas les différents buts à part que cela soit disponible ?
L'application qui va dépendre de la base de données devra fonctionner 24/24 7/7 (99.99% ou mieux) et devrait faire quasi en permanence des requêtes sur celle ci (persistance d'un fournisseur de service JMS).
Merci pour les réponses
Hors ligne
Avec si peu d'infos, je dirais que j'irais au plus simple : deux serveurs en Streaming Replication (la réplication interne de PostgreSQL, évidemment disponible sous Windows). Pour plus d'infos sur cette réplication, lire http://www.dalibo.org/glmf131_mise_en_p … resl_9.0_1 et http://www.dalibo.org/glmf131_mise_en_p … resl_9.0_2.
Guillaume.
Hors ligne
La question est la suivante:
Quels sont vos RPO et RTO ?
http://fr.wikipedia.org/wiki/Exigences_d'architecture_technique
C'est principalement cela qui va déterminer la solution de haute dispo, donc ses contraintes et son coût.
Marc.
Hors ligne
Merci pour les réponses. Je vais voir les informations que je peux récupérer.
Hors ligne
Pages : 1
