Re: Cluster ...

Hervé Piedvache wrote:

>Laurent,
>
>Le Mardi 9 Novembre 2004 10:26, Laurent Mesuré a écrit :
>
>
>>Hervé Piedvache wrote:
>>
>>
>>>Bonjour,
>>>
>>>
>>[SNIP]
>>
>>As tu besoin que les users accèdent directement à la base? Est-ce
>>vraiment necessaire?
>>
>>Ou au contraire tu as une application tierce qui elle va se connecter
>>sur la base
>>
>>en gros :
>>
>>client -----> PostgreSQL
>>
>>ou
>>
>>client -----> Application -----> PostgreSQL
>>
>>Car en général on évite que des client se connectent sur la base et on
>>préfèrera utiliser une application intermédiaire. Car il est plus facile
>>et moins onereux de répartir la charge de l'application que celle de la
>>base de donnée.
>>
>>
>
>Je suis preneur de ce que tu veux ... le site est en Php ... mais quelle
>application entre les deux ?
>DbBalancer est un projet arrêté depuis 3 ans ... C-JDBC ... je pense que ca me
>poser un soucis en PHP ...
>Je suppose que dans ce que tu envisages c'est le serveur d'application qui
>fait la répartition des écritures sur tous les serveurs ... ?
>
>Tu as une idée précise ...
>
>
>
oui en termes d'architecture il faut considérer ton systèmes comme un
ensemble de fonctionnalités. Une fois définies, ces fonctionnalités sont
traduites en termes de services puis de matériels et de logiciels.

Dans ton cas si j'ai bien compris tu as les fonctionnalités suivantes:

- Le client
- Une application PHP sur laquelle tes clients viennent se connecter, et
qui, en fonction des actions de tes utilisateurs via leuirs clients va
se connecter sur la base de donnée pour y réaliser les opérations
demandées (consultation et insertion de données).
- Une basse de données

Du fait des contraintes que tu as exposé, il va donc y avoir beaucoup de
client qui vont se connecter. Il est donc nécessaire de répartir la
charge non pas au niveau de la base de donnée, mais déjà en amont au
niveau de l'application par l'utilisation de frontaux à répartitioin de
charge et par la disposition de plusieurs serveurs d'applications..

Ensuite du fait du fort volume de données mises en jeu, il te faut une
base de donnée importante. Et c'est là que les interrogations vont
commencer.

En effet, pour assurer un gros volumes de données avec une bonne
disponibilité il y a plusieurs solutions:

- Un gros serveurs
- Un cluster matériel
- Un cluster logiciel
- Une grappe

Ils ont tous leurs qualités et leurs défaut.
- Un gros serveur pose des problemes de puissance et de charge, ainsi
qu'un problème de disponibilité.
- Un cluster matériel peut revenir assez cher, c'est la solution la plus
courament utilisée. Pour les utilisateur il n'y a qu'une seule machine.
Pour la machine, les différents constituant sont multiples. Si un
élément a une défillance, c'est un autre élément qui prend en charge.
- Un cluster logiciel necessite que les logiciels utilisés sachent le
faire. Pour ce qui est de PostgreSQL, je ne connais pas assez cet aspect
mais je ne crois pas qu'il dispose d'un équivalent au RAC d'Oracle.
- Une grappe necessite d'avoir plusieurs serveurs ce qui va augmenter
peut être les coût, mais nécessaite d'avoir un mécanisme de réplication
fiable entre les noeud afin d'avoir une cohérence des données.
- enfin il peut etre interessant d'avoir un mix de plusieurs de ces cas.

Je ne connais pas encore toutes les fonctionnalité de ce type au niveau
de PostgreSQL, mais je crois qu'un point de départ (hors considération
de coût dont nous n'avons pas encore assez d'éléments) pourrait être le
suivant:

+-------------+
| Répartition |
| de charge |
+-------------+
| |
| |
+---------+ +---------+
| Frontal | | Frontal |
| web | | web |
+---------+ +---------+
| \ / | DMZ
| ---- | -----------
| / \ | LAN
+---------+ +---------+
| Serveur | | Serveur |
| d'appli | | d'appli |
+---------+ +---------+
| \ / |
| ---- |
| / \ |
+---------+ +---------+
| Serveur | | Serveur |
| BDD Pg | | BDD Pg |
+---------+ +---------+
| |
| |
| |
+----------+
| Baie de |
| Disque |
+----------+

Sachant que:

- La répartition de charge peut être assurée par un proxy, mais les
performance seraient alors moindre
- Les frontaux web peuvent être couplés aux serveurs d'applis mais là
aussi les performances de l'ensemble peuvent s'en trouver affectées. De
plus cela pose un problème de sécurité. En effet la séparation entre la
DMZ et le LAN étant assuré par un parefeu à répartition de charge. Seul
les frontaux sont visible et sont donc susceptibles d'être attaqué. Mais
le reste de la plate-forme, plus sensible, reste à l'abri des indelicats.
- La baie de disque est en RAID. Elle peut être spécifique ou fournie
par un SAN mutualisé ou non.

Voilà schématiquement une solution possible. Je ne sais pas quel est le
budget de ta solution mais celle-ci a déjà pas mal été éprouvée un peu
partout.

reste à savoir si c'est possible avec Pg. Pour le moment je ne vois pas
de contre indications. Cette solution ne necessite pas de replication
particulière. Par contre il est nécéssaire d'avoir une gestion des accès
à la baie de disque rigoureuse afin de ne pas avoir de collision d'accès.

laurent