Re: un ou plusieurs clusters

Bonjour,

J'ai plusieurs (une dizaine) de bases, très modestes, qui concernent des
applications (les miennes) complètement indépendantes sur le même
serveur. Actuellement toutes sur le même cluster.

Récemment j'ai bossé pas mal sur les bases elles-mêmes et pour ça j'ai
utilisé plusieurs clusters, j'ai trouvé ça assez pratique.

Je me demandais s'il était courant d'utiliser plusieurs clusters où si
c'était vraiment du gaspillage. En l'occurence mes applis en prod sont
sur des serveurs virtuels assez petits, je fait donc attention à ne pas
gaspiller les ressources.

Bref, que pensez vous des avantages et inconvénients de travailler sur
plusieurs cluster ?

a+

--
William Dodé - http://flibuste.net
Informaticien Indépendant

William Dode a écrit :
> [...]
> J'ai plusieurs (une dizaine) de bases, très modestes, qui concernent des
> applications (les miennes) complètement indépendantes sur le même
> serveur. Actuellement toutes sur le même cluster.
>
> Récemment j'ai bossé pas mal sur les bases elles-mêmes et pour ça j'ai
> utilisé plusieurs clusters, j'ai trouvé ça assez pratique.
>

Pourquoi pratique ? j'ai quelques clients qui me disent la même chose
mais aucun n'arrive à expliquer en quoi c'est réellement pratique.

> Je me demandais s'il était courant d'utiliser plusieurs clusters où si
> c'était vraiment du gaspillage. En l'occurence mes applis en prod sont
> sur des serveurs virtuels assez petits, je fait donc attention à ne pas
> gaspiller les ressources.
>

Je dirais que ça arrive de temps en temps, surtout chez les DBA
oracliens qui semblent apprécier beaucoup cette façon de faire : une
instance == une base de données.

> Bref, que pensez vous des avantages et inconvénients de travailler sur
> plusieurs cluster ?
>

Avantage :
* permet d'empêcher les connexions à une base de données.

Inconvénients :
* partage des ressources (notamment mémoire) entre les différentes
instances.
* risque de se trouver avec plusieurs checkpoints survenant en même
temps (ceci dit, chacun à moins à faire du coup)
* bien configurer son max_connections si on ne veut pas que son
work_mem se réduise à peau de chagrin

Bref, principalement, tu devras porter une très grande attention à
l'utilisation des ressources mémoire et disque. Bon courage.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

On 17-10-2008, Guillaume Lelarge wrote:
> William Dode a écrit :
>> [...]
>> J'ai plusieurs (une dizaine) de bases, très modestes, qui concernent des
>> applications (les miennes) complètement indépendantes sur le même
>> serveur. Actuellement toutes sur le même cluster.
>>
>> Récemment j'ai bossé pas mal sur les bases elles-mêmes et pour ça j'ai
>> utilisé plusieurs clusters, j'ai trouvé ça assez pratique.
>>
>
> Pourquoi pratique ? j'ai quelques clients qui me disent la même chose
> mais aucun n'arrive à expliquer en quoi c'est réellement pratique.

Pratique pour la maintenance, par exemple configurer différemment le
log_shipping, le détail des logs, arrêter un cluster, le déplacer sur un
autre serveur etc.

Ce que je fais déjà c'est que sur chaque serveur et sur ma machine de
dev j'ai en réplication les clusters des autres serveurs. Juste pour
backup ou faire des tests.

Est-ce qu'il est prévu pour les futures versions d'avoir une réplication
ou log shipping par base ?

>
>> Je me demandais s'il était courant d'utiliser plusieurs clusters où si
>> c'était vraiment du gaspillage. En l'occurence mes applis en prod sont
>> sur des serveurs virtuels assez petits, je fait donc attention à ne pas
>> gaspiller les ressources.
>>
>
> Je dirais que ça arrive de temps en temps, surtout chez les DBA
> oracliens qui semblent apprécier beaucoup cette façon de faire : une
> instance == une base de données.

Je pense que ça sonne plus sûr, l'idée de fichiers séparés etc. Mais
c'est vrai que concrètement le peu de problème que j'ai eu ne s'est
jamais propagé d'une base à l'autre du même cluster...

>
>> Bref, que pensez vous des avantages et inconvénients de travailler sur
>> plusieurs cluster ?
>>
>
> Avantage :
> * permet d'empêcher les connexions à une base de données.

qui peut se gérer dans le même cluster aussi...

>
> Inconvénients :
> * partage des ressources (notamment mémoire) entre les différentes
> instances.
> * risque de se trouver avec plusieurs checkpoints survenant en même
> temps (ceci dit, chacun à moins à faire du coup)
> * bien configurer son max_connections si on ne veut pas que son
> work_mem se réduise à peau de chagrin
>
> Bref, principalement, tu devras porter une très grande attention à
> l'utilisation des ressources mémoire et disque. Bon courage.

C'est ce qui me fait peur, surtout que l'intérêt ne serait que très
ponctuel dans mon cas.

--
William Dodé - http://flibuste.net
Informaticien Indépendant

William Dode a écrit :
> On 17-10-2008, Guillaume Lelarge wrote:
>> William Dode a écrit :
>>> [...]
>>> J'ai plusieurs (une dizaine) de bases, très modestes, qui concernent des
>>> applications (les miennes) complètement indépendantes sur le même
>>> serveur. Actuellement toutes sur le même cluster.
>>>
>>> Récemment j'ai bossé pas mal sur les bases elles-mêmes et pour ça j'ai
>>> utilisé plusieurs clusters, j'ai trouvé ça assez pratique.
>>>
>> Pourquoi pratique ? j'ai quelques clients qui me disent la même chose
>> mais aucun n'arrive à expliquer en quoi c'est réellement pratique.
>
> Pratique pour la maintenance, par exemple configurer différemment le
> log_shipping, le détail des logs, arrêter un cluster, le déplacer sur un
> autre serveur etc.
>

Mouais. En dehors du logshipping (et encore...), je ne suis pas convaincu.

> Ce que je fais déjà c'est que sur chaque serveur et sur ma machine de
> dev j'ai en réplication les clusters des autres serveurs. Juste pour
> backup ou faire des tests.
>

Tu répliques tous les clusters de tous les serveurs ? à quoi sert
d'avoir une base par instance dans ce cas ?

> Est-ce qu'il est prévu pour les futures versions d'avoir une réplication
> ou log shipping par base ?
>

Non. Ce n'est pas dans les préoccupations actuelles, et cela demanderait
un énorme travail pour un résultat qui risque d'être mitigé.

>>> Je me demandais s'il était courant d'utiliser plusieurs clusters où si
>>> c'était vraiment du gaspillage. En l'occurence mes applis en prod sont
>>> sur des serveurs virtuels assez petits, je fait donc attention à ne pas
>>> gaspiller les ressources.
>>>
>> Je dirais que ça arrive de temps en temps, surtout chez les DBA
>> oracliens qui semblent apprécier beaucoup cette façon de faire : une
>> instance == une base de données.
>
> Je pense que ça sonne plus sûr, l'idée de fichiers séparés etc. Mais
> c'est vrai que concrètement le peu de problème que j'ai eu ne s'est
> jamais propagé d'une base à l'autre du même cluster...
>

Plus sûr dans quel contexte ? j'en vois deux possibles : un problème de
sécurité et un problème matériel. Je n'ai jamais entendu qu'un tel
problème de sécurité s'est déjà présenté avec PostgreSQL. Si c'est un
problème de matériel, on peut faire la même chose en plaçant chaque base
dans son tablespace. Évidemment, les journaux de transactions seront
tous sur le même disque, mais généralement un RAID1 voire 1+0 permet de
gérer ce soucis.

Tu as eu quelques types de problèmes ? tu crains quoi ? (comme tu le
dis, c'est pas forcément la même chose)

>>> Bref, que pensez vous des avantages et inconvénients de travailler sur
>>> plusieurs cluster ?
>>>
>> Avantage :
>> * permet d'empêcher les connexions à une base de données.
>
> qui peut se gérer dans le même cluster aussi...
>

Moins facilement, il faut arriver à virer tout le monde. Bref, ça
demande beaucoup d'actions. Alors que dans le cas une base une instance,
il suffit d'arrêter le serveur.

>> Inconvénients :
>> * partage des ressources (notamment mémoire) entre les différentes
>> instances.
>> * risque de se trouver avec plusieurs checkpoints survenant en même
>> temps (ceci dit, chacun à moins à faire du coup)
>> * bien configurer son max_connections si on ne veut pas que son
>> work_mem se réduise à peau de chagrin
>>
>> Bref, principalement, tu devras porter une très grande attention à
>> l'utilisation des ressources mémoire et disque. Bon courage.
>
> C'est ce qui me fait peur, surtout que l'intérêt ne serait que très
> ponctuel dans mon cas.
>

Pour moi, les inconvénients l'emportent très largement sur les
avantages. Mais bon, ça n'empêche pas certains de le faire, et avec de
bonnes perfs.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

On 17-10-2008, Guillaume Lelarge wrote:
> William Dode a écrit :
>> On 17-10-2008, Guillaume Lelarge wrote:
>>> William Dode a écrit :
>>>> [...]
>>>> J'ai plusieurs (une dizaine) de bases, très modestes, qui concernent des
>>>> applications (les miennes) complètement indépendantes sur le même
>>>> serveur. Actuellement toutes sur le même cluster.
>>>>
>>>> Récemment j'ai bossé pas mal sur les bases elles-mêmes et pour ça j'ai
>>>> utilisé plusieurs clusters, j'ai trouvé ça assez pratique.
>>>>
>>> Pourquoi pratique ? j'ai quelques clients qui me disent la même chose
>>> mais aucun n'arrive à expliquer en quoi c'est réellement pratique.
>>
>> Pratique pour la maintenance, par exemple configurer différemment le
>> log_shipping, le détail des logs, arrêter un cluster, le déplacer sur un
>> autre serveur etc.
>>
>
> Mouais. En dehors du logshipping (et encore...), je ne suis pas convaincu.

Par exemple si j'ai un problème sur une base et que je veux logger les
connexions, les requetes, les stats etc... Si j'ai plusieurs bases qui
tournent c'est impossible à lire.

>
>> Ce que je fais déjà c'est que sur chaque serveur et sur ma machine de
>> dev j'ai en réplication les clusters des autres serveurs. Juste pour
>> backup ou faire des tests.
>>
>
> Tu répliques tous les clusters de tous les serveurs ? à quoi sert
> d'avoir une base par instance dans ce cas ?

Justement pour que ce soit plus souple. Par exemple lorsque je travaille
sur une appli en particulier je n'ai pas besoin de rapatrier toutes les
bases.

>
>> Est-ce qu'il est prévu pour les futures versions d'avoir une réplication
>> ou log shipping par base ?
>>
>
> Non. Ce n'est pas dans les préoccupations actuelles, et cela demanderait
> un énorme travail pour un résultat qui risque d'être mitigé.
>
>>>> Je me demandais s'il était courant d'utiliser plusieurs clusters où si
>>>> c'était vraiment du gaspillage. En l'occurence mes applis en prod sont
>>>> sur des serveurs virtuels assez petits, je fait donc attention à ne pas
>>>> gaspiller les ressources.
>>>>
>>> Je dirais que ça arrive de temps en temps, surtout chez les DBA
>>> oracliens qui semblent apprécier beaucoup cette façon de faire : une
>>> instance == une base de données.
>>
>> Je pense que ça sonne plus sûr, l'idée de fichiers séparés etc. Mais
>> c'est vrai que concrètement le peu de problème que j'ai eu ne s'est
>> jamais propagé d'une base à l'autre du même cluster...
>>
>
> Plus sûr dans quel contexte ? j'en vois deux possibles : un problème de
> sécurité et un problème matériel. Je n'ai jamais entendu qu'un tel
> problème de sécurité s'est déjà présenté avec PostgreSQL. Si c'est un
> problème de matériel, on peut faire la même chose en plaçant chaque base
> dans son tablespace. Évidemment, les journaux de transactions seront
> tous sur le même disque, mais généralement un RAID1 voire 1+0 permet de
> gérer ce soucis.
>
> Tu as eu quelques types de problèmes ? tu crains quoi ? (comme tu le
> dis, c'est pas forcément la même chose)

J'ai eu des corruptions d'index sur pg7.4 par ex.
En pratique jamais grave. Je disais "ça sonne" dans le sens où c'est un
vieux réflexe de séparer les choses.

>
>>>> Bref, que pensez vous des avantages et inconvénients de travailler sur
>>>> plusieurs cluster ?
>>>>
>>> Avantage :
>>> * permet d'empêcher les connexions à une base de données.
>>
>> qui peut se gérer dans le même cluster aussi...
>>
>
> Moins facilement, il faut arriver à virer tout le monde. Bref, ça
> demande beaucoup d'actions. Alors que dans le cas une base une instance,
> il suffit d'arrêter le serveur.
>
>>> Inconvénients :
>>> * partage des ressources (notamment mémoire) entre les différentes
>>> instances.
>>> * risque de se trouver avec plusieurs checkpoints survenant en même
>>> temps (ceci dit, chacun à moins à faire du coup)
>>> * bien configurer son max_connections si on ne veut pas que son
>>> work_mem se réduise à peau de chagrin
>>>
>>> Bref, principalement, tu devras porter une très grande attention à
>>> l'utilisation des ressources mémoire et disque. Bon courage.
>>
>> C'est ce qui me fait peur, surtout que l'intérêt ne serait que très
>> ponctuel dans mon cas.
>>
>
> Pour moi, les inconvénients l'emportent très largement sur les
> avantages. Mais bon, ça n'empêche pas certains de le faire, et avec de
> bonnes perfs.

C'est ce qui me semble aussi au final, je vais regarder au cas par cas.

--
William Dodé - http://flibuste.net
Informaticien Indépendant

William Dode a écrit :
> On 17-10-2008, Guillaume Lelarge wrote:
>> William Dode a écrit :
>>> On 17-10-2008, Guillaume Lelarge wrote:
>>>> William Dode a écrit :
>>>>> [...]
>>>>> J'ai plusieurs (une dizaine) de bases, très modestes, qui concernent des
>>>>> applications (les miennes) complètement indépendantes sur le même
>>>>> serveur. Actuellement toutes sur le même cluster.
>>>>>
>>>>> Récemment j'ai bossé pas mal sur les bases elles-mêmes et pour ça j'ai
>>>>> utilisé plusieurs clusters, j'ai trouvé ça assez pratique.
>>>>>
>>>> Pourquoi pratique ? j'ai quelques clients qui me disent la même chose
>>>> mais aucun n'arrive à expliquer en quoi c'est réellement pratique.
>>> Pratique pour la maintenance, par exemple configurer différemment le
>>> log_shipping, le détail des logs, arrêter un cluster, le déplacer sur un
>>> autre serveur etc.
>>>
>> Mouais. En dehors du logshipping (et encore...), je ne suis pas convaincu.
>
> Par exemple si j'ai un problème sur une base et que je veux logger les
> connexions, les requetes, les stats etc... Si j'ai plusieurs bases qui
> tournent c'est impossible à lire.
>

Avec le bon log_line_prefix (%d pour la base... c'est de tête, ne pas
m'en vouloir si ce n'est pas ça :) ), c'est tout à fait jouable. Par
contre, question perfs, c'est clair que ça devient ravageur pour une
instance qui a plusieurs bases de données.

>>> Ce que je fais déjà c'est que sur chaque serveur et sur ma machine de
>>> dev j'ai en réplication les clusters des autres serveurs. Juste pour
>>> backup ou faire des tests.
>>>
>> Tu répliques tous les clusters de tous les serveurs ? à quoi sert
>> d'avoir une base par instance dans ce cas ?
>
> Justement pour que ce soit plus souple. Par exemple lorsque je travaille
> sur une appli en particulier je n'ai pas besoin de rapatrier toutes les
> bases.
>

OK pour un développeur qui doit tester une base.

>>[...]
>> Tu as eu quelques types de problèmes ? tu crains quoi ? (comme tu le
>> dis, c'est pas forcément la même chose)
>
> J'ai eu des corruptions d'index sur pg7.4 par ex.
> En pratique jamais grave. Je disais "ça sonne" dans le sens où c'est un
> vieux réflexe de séparer les choses.
>

À ce niveau-là, on pourrait mettre un fichier par disque :)

Je comprends tes craintes. D'un autre côté, tu n'es pas protégé d'une
corruption d'index avec du logshipping si la corruption vient de PostgreSQL.

>> [...]
>>>> Inconvénients :
>>>> * partage des ressources (notamment mémoire) entre les différentes
>>>> instances.
>>>> * risque de se trouver avec plusieurs checkpoints survenant en même
>>>> temps (ceci dit, chacun à moins à faire du coup)
>>>> * bien configurer son max_connections si on ne veut pas que son
>>>> work_mem se réduise à peau de chagrin
>>>>
>>>> Bref, principalement, tu devras porter une très grande attention à
>>>> l'utilisation des ressources mémoire et disque. Bon courage.
>>> C'est ce qui me fait peur, surtout que l'intérêt ne serait que très
>>> ponctuel dans mon cas.
>>>
>> Pour moi, les inconvénients l'emportent très largement sur les
>> avantages. Mais bon, ça n'empêche pas certains de le faire, et avec de
>> bonnes perfs.
>
> C'est ce qui me semble aussi au final, je vais regarder au cas par cas.
>

Qu'on soit bien d'accord.

Je prêche pour toutes les bases de données dans une instance pour des
raisons de perfs. Il est beaucoup plus simple de savoir d'où vient le
problème des perfs d'une base s'il n'y a qu'une instance sur le serveur
(physique). De plus, c'est aussi pour cela que je suis pour le fait
d'avoir un serveur de bases de données et un serveur applicatif séparé.
C'est aussi pour cela que je n'aime pas les serveurs virtualisés pour
les serveurs de production.

Par contre, je comprends très bien que des DBA ont confiance dans une
certaine façon de travailler, même si cela implique d'avoir une base par
instance et plusieurs instances par serveur physique. En sachant qu'au
prochain petit problème de performances, il faudra revoir toute la façon
de travailler.

Ce n'est que mon opinion :)

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

On 17-10-2008, Guillaume Lelarge wrote:
> William Dode a écrit :
>> On 17-10-2008, Guillaume Lelarge wrote:
>>> William Dode a écrit :
>>>> On 17-10-2008, Guillaume Lelarge wrote:
>>>>> William Dode a écrit :
>>>>>> [...]
>>>>>> J'ai plusieurs (une dizaine) de bases, très modestes, qui concernent des
>>>>>> applications (les miennes) complètement indépendantes sur le même
>>>>>> serveur. Actuellement toutes sur le même cluster.
>>>>>>
>>>>>> Récemment j'ai bossé pas mal sur les bases elles-mêmes et pour ça j'ai
>>>>>> utilisé plusieurs clusters, j'ai trouvé ça assez pratique.
>>>>>>
>>>>> Pourquoi pratique ? j'ai quelques clients qui me disent la même chose
>>>>> mais aucun n'arrive à expliquer en quoi c'est réellement pratique.
>>>> Pratique pour la maintenance, par exemple configurer différemment le
>>>> log_shipping, le détail des logs, arrêter un cluster, le déplacer sur un
>>>> autre serveur etc.
>>>>
>>> Mouais. En dehors du logshipping (et encore...), je ne suis pas convaincu.
>>
>> Par exemple si j'ai un problème sur une base et que je veux logger les
>> connexions, les requetes, les stats etc... Si j'ai plusieurs bases qui
>> tournent c'est impossible à lire.
>>
>
> Avec le bon log_line_prefix (%d pour la base... c'est de tête, ne pas
> m'en vouloir si ce n'est pas ça :) ), c'est tout à fait jouable.

Oui avec un script d'analyse sinon quand il y a une base au milieu qui
a des accès très fréquents c'est l'horreur...

> Par
> contre, question perfs, c'est clair que ça devient ravageur pour une
> instance qui a plusieurs bases de données.
>
>>>> Ce que je fais déjà c'est que sur chaque serveur et sur ma machine de
>>>> dev j'ai en réplication les clusters des autres serveurs. Juste pour
>>>> backup ou faire des tests.
>>>>
>>> Tu répliques tous les clusters de tous les serveurs ? à quoi sert
>>> d'avoir une base par instance dans ce cas ?
>>
>> Justement pour que ce soit plus souple. Par exemple lorsque je travaille
>> sur une appli en particulier je n'ai pas besoin de rapatrier toutes les
>> bases.
>>
>
> OK pour un développeur qui doit tester une base.
>
>>>[...]
>>> Tu as eu quelques types de problèmes ? tu crains quoi ? (comme tu le
>>> dis, c'est pas forcément la même chose)
>>
>> J'ai eu des corruptions d'index sur pg7.4 par ex.
>> En pratique jamais grave. Je disais "ça sonne" dans le sens où c'est un
>> vieux réflexe de séparer les choses.
>>
>
> À ce niveau-là, on pourrait mettre un fichier par disque :)
>
> Je comprends tes craintes. D'un autre côté, tu n'es pas protégé d'une
> corruption d'index avec du logshipping si la corruption vient de PostgreSQL.
>
>>> [...]
>>>>> Inconvénients :
>>>>> * partage des ressources (notamment mémoire) entre les différentes
>>>>> instances.
>>>>> * risque de se trouver avec plusieurs checkpoints survenant en même
>>>>> temps (ceci dit, chacun à moins à faire du coup)
>>>>> * bien configurer son max_connections si on ne veut pas que son
>>>>> work_mem se réduise à peau de chagrin
>>>>>
>>>>> Bref, principalement, tu devras porter une très grande attention à
>>>>> l'utilisation des ressources mémoire et disque. Bon courage.
>>>> C'est ce qui me fait peur, surtout que l'intérêt ne serait que très
>>>> ponctuel dans mon cas.
>>>>
>>> Pour moi, les inconvénients l'emportent très largement sur les
>>> avantages. Mais bon, ça n'empêche pas certains de le faire, et avec de
>>> bonnes perfs.
>>
>> C'est ce qui me semble aussi au final, je vais regarder au cas par cas.
>>
>
> Qu'on soit bien d'accord.
>
> Je prêche pour toutes les bases de données dans une instance pour des
> raisons de perfs.

C'est surtout ça que je voulais savoir vu mes petites configs.

> Il est beaucoup plus simple de savoir d'où vient le
> problème des perfs d'une base s'il n'y a qu'une instance sur le serveur
> (physique). De plus, c'est aussi pour cela que je suis pour le fait
> d'avoir un serveur de bases de données et un serveur applicatif séparé.
> C'est aussi pour cela que je n'aime pas les serveurs virtualisés pour
> les serveurs de production.

C'est curieux, c'est justement pour cette même raison que j'aime les
serveurs virtualisés ! C'est justement plus facile d'avoir plusieurs
petits serveurs et qui sont à la fois plus sécurisés puisque sur une
bonne machine.

>
> Par contre, je comprends très bien que des DBA ont confiance dans une
> certaine façon de travailler, même si cela implique d'avoir une base par
> instance et plusieurs instances par serveur physique. En sachant qu'au
> prochain petit problème de performances, il faudra revoir toute la façon
> de travailler.
>
> Ce n'est que mon opinion :)

C'est le genre de chose où plus on la partage plus elle s'enrichir ;-)

--
William Dodé - http://flibuste.net
Informaticien Indépendant

William Dode a écrit :
> On 17-10-2008, Guillaume Lelarge wrote:
>>[....]
>> Je prêche pour toutes les bases de données dans une instance pour des
>> raisons de perfs.
>
> C'est surtout ça que je voulais savoir vu mes petites configs.
>
>> Il est beaucoup plus simple de savoir d'où vient le
>> problème des perfs d'une base s'il n'y a qu'une instance sur le serveur
>> (physique). De plus, c'est aussi pour cela que je suis pour le fait
>> d'avoir un serveur de bases de données et un serveur applicatif séparé.
>> C'est aussi pour cela que je n'aime pas les serveurs virtualisés pour
>> les serveurs de production.
>
> C'est curieux, c'est justement pour cette même raison que j'aime les
> serveurs virtualisés ! C'est justement plus facile d'avoir plusieurs
> petits serveurs et qui sont à la fois plus sécurisés puisque sur une
> bonne machine.
>

Là, je ne pige pas. Avoir un serveur virtualisé indique forcément une
couche supplémentaire, la couche de virtualisation. Comment savoir avec
ça si les problèmes de performance du serveur virtualisé 1 sont dûs à
une mauvaise config des applis de ce serveur ou alors à d'autres
serveurs virtualisés ou alors même à la couche de virtualisation ?

Sans compter que "le plus sécurisé car une bonne grosse machine", j'y
crois pas une seconde. Dans le cas d'un problème matériel (ou de la
couche de virtualisation), plusieurs de tes serveurs tombent d'un coup.

>> Par contre, je comprends très bien que des DBA ont confiance dans une
>> certaine façon de travailler, même si cela implique d'avoir une base par
>> instance et plusieurs instances par serveur physique. En sachant qu'au
>> prochain petit problème de performances, il faudra revoir toute la façon
>> de travailler.
>>
>> Ce n'est que mon opinion :)
>
> C'est le genre de chose où plus on la partage plus elle s'enrichir ;-)
>

Exact :)

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

On 17-10-2008, Guillaume Lelarge wrote:
> William Dode a écrit :
>> On 17-10-2008, Guillaume Lelarge wrote:
>>>[....]
>>> Je prêche pour toutes les bases de données dans une instance pour des
>>> raisons de perfs.
>>
>> C'est surtout ça que je voulais savoir vu mes petites configs.
>>
>>> Il est beaucoup plus simple de savoir d'où vient le
>>> problème des perfs d'une base s'il n'y a qu'une instance sur le serveur
>>> (physique). De plus, c'est aussi pour cela que je suis pour le fait
>>> d'avoir un serveur de bases de données et un serveur applicatif séparé.
>>> C'est aussi pour cela que je n'aime pas les serveurs virtualisés pour
>>> les serveurs de production.
>>
>> C'est curieux, c'est justement pour cette même raison que j'aime les
>> serveurs virtualisés ! C'est justement plus facile d'avoir plusieurs
>> petits serveurs et qui sont à la fois plus sécurisés puisque sur une
>> bonne machine.
>>
>
> Là, je ne pige pas. Avoir un serveur virtualisé indique forcément une
> couche supplémentaire, la couche de virtualisation. Comment savoir avec
> ça si les problèmes de performance du serveur virtualisé 1 sont dûs à
> une mauvaise config des applis de ce serveur ou alors à d'autres
> serveurs virtualisés ou alors même à la couche de virtualisation ?
>
> Sans compter que "le plus sécurisé car une bonne grosse machine", j'y
> crois pas une seconde. Dans le cas d'un problème matériel (ou de la
> couche de virtualisation), plusieurs de tes serveurs tombent d'un coup.

Je parle de serveurs virtuels loués. Dans ceux que j'utilise (sivit):
La puissance et la mémoire sont bien cloisonnés. Et même mieux,
burstable si c'est possible.
C'est le faible coût qui me permet d'en avoir plusieurs (et pas
forcément sur la même machine) au lieu d'un gros dédié. Et même à faible
coût le matériel est en raid, alim redondante etc. ce qui ne serait pas
le cas sur un dédié équivalent en prix.

Encore un peu de pub, gandi a lancé ces serveurs flexibles, ça permet de
jouer vraiment facilement sur plusieurs machines, différentes puissances
etc. C'est ce qui m'a permis d'expérimenter les dernières versions de
postgres et les réplications dans tous les sens !

--
William Dodé - http://flibuste.net
Informaticien Indépendant

Le vendredi 17 octobre 2008 11:47:26 Guillaume Lelarge, vous avez écrit :
> William Dode a écrit :
> > [...]
> > J'ai plusieurs (une dizaine) de bases, très modestes, qui concernent des
> > applications (les miennes) complètement indépendantes sur le même
> > serveur. Actuellement toutes sur le même cluster.
> >
> > Récemment j'ai bossé pas mal sur les bases elles-mêmes et pour ça j'ai
> > utilisé plusieurs clusters, j'ai trouvé ça assez pratique.
>
> Pourquoi pratique ? j'ai quelques clients qui me disent la même chose
> mais aucun n'arrive à expliquer en quoi c'est réellement pratique.

En fait, sous Oracle, une des principales raisons qu'on peut vouloir avoir
d'avoir plusieurs bases séparées, c'est de pouvoir faire un recover (un PITR)
sur une seule base. Dans le cas de bases assez grosses évidemment...
Si on met plusieurs bases dans des schemas différents (c'est comme cela qu'on
compense l'absence de multi-base sous Oracle), et qu'on a besoin de revenir
dans le passé (suite à un delete malencontreux par exemple, genre le dba qui a
passé un script de migration sur la mauvaise base, c'est con mais ça arrive),
on n'est pas obligé de restaurer toutes les autres bases de tous les autres
clients, ce qui permet de faire l'opération beaucoup plus vite (on restaure
juste la base dans un coin sur un autre serveur ou dans un autre répertoire et
on fait le recover dessus, puis un export/import dans la base de prod).

Il y a aussi l'autre idée, mentionnée plus bas dans le thread : ne pas mettre
tous ses oeufs dans le même panier. Un problème technique sur une base
n'impactera pas forcément les autres. Bon, évidemment, si c'est qu'on perd un
groupe de disque sur lequel se trouvent toutes les bases ...

Comme pour Oracle, le gros inconvénient d'avoir plusieurs clusters, c'est
l'utilisation moins efficace des ressources du serveur (obligé de découper la
mémoire entre les bases, concurrence d'accès au disque ...)

Avoir un ou plusieurs clusters, c'est à mon avis un compromis entre les
performances et les conséquences (temps de reprise sur incident et nombre
d'environnements impactés) d'une panne. Mais dans le cas de petites bases,
c'est du gâchis, on peut finir par se retrouver avec plus de volume de fichiers
de WAL que de fichiers de données :)