Je dispose de deux machines sous mandrake 9.2, l'une sert de serveur de
mail et de proxy pour un réseau interne, l'autre est sensé être son
"backup".
Je dis "sensé", car les deux machines ne sont pas au même niveau de
configuration l'une par rapport à l'autre, les modifs qui ont pu être
fait sur l'une n'ayant pas été reportés sur l'autre.
Ceci dit, la mandrake 9.2 commence à dater, même si elle est mise à jour
régulièrement, et j'aimerais bien passer tout ça en mandriva 2006, et
maintenir la mise à jour des deux machines au même niveau de logiciels
et de configuration de la manière la plus simple possible
("utilisateurement" parlant).
Alors : Cluster ou pas cluster ?
Dans l'affirmative, avez vous des liens qui me permettraient de me
renseigner sur le sujet ?
.. de préférence sur mandrake/mandriva... mais bon..
merci :)
ps: je suis totalement novice en matière de cluster, je ne suis même pas
certain que ça corresponde à mes attentes.. soyez indulgent :)
Mais au minimum, j'aimerais que mes machines soient au même niveau logiciel et de configuration..
Je verrais bien une solution légèrement différente : rsync. En gros, tu fais les éventuelles modifications sur une machine, et une fois que tu es sûr que tu n'as pas fait de connerie, tu les répercutes sur l'autre avec rsync. Évidemment, en mode "autonome" (i.e. quand tu n'es pas les mains dans le cambouis), tu peux programmer un rsync à intervalles réguliers.
En fait, sur la machine de backup, je verrais bien deux installations de Linux : - une première, qui fonctionnerait en temps normal (éventuellement lancée depuis un disque dur secondaire ou un CD-ROM) et se contenterait de répercuter sur le disque dur les modifications effectuées sur la machine principale ; - une seconde, qui ne fonctionnerait que lors d'une panne du serveur principal, avec la même configuration qu'icelui (y compris l'adresse IP).
On Wed, 12 Apr 2006 10:38:59 +0200, Laurent <lpopoz@alussinan.org>:
Mais au minimum, j'aimerais que mes machines soient au même niveau
logiciel et de configuration..
Je verrais bien une solution légèrement différente : rsync.
En gros, tu fais les éventuelles modifications sur une machine, et une
fois que tu es sûr que tu n'as pas fait de connerie, tu les répercutes
sur l'autre avec rsync.
Évidemment, en mode "autonome" (i.e. quand tu n'es pas les mains dans
le cambouis), tu peux programmer un rsync à intervalles réguliers.
En fait, sur la machine de backup, je verrais bien deux installations
de Linux :
- une première, qui fonctionnerait en temps normal
(éventuellement lancée depuis un disque dur secondaire ou un CD-ROM)
et se contenterait de répercuter sur le disque dur les modifications
effectuées sur la machine principale ;
- une seconde, qui ne fonctionnerait que lors d'une panne du
serveur principal, avec la même configuration qu'icelui (y compris
l'adresse IP).
Mais au minimum, j'aimerais que mes machines soient au même niveau logiciel et de configuration..
Je verrais bien une solution légèrement différente : rsync. En gros, tu fais les éventuelles modifications sur une machine, et une fois que tu es sûr que tu n'as pas fait de connerie, tu les répercutes sur l'autre avec rsync. Évidemment, en mode "autonome" (i.e. quand tu n'es pas les mains dans le cambouis), tu peux programmer un rsync à intervalles réguliers.
En fait, sur la machine de backup, je verrais bien deux installations de Linux : - une première, qui fonctionnerait en temps normal (éventuellement lancée depuis un disque dur secondaire ou un CD-ROM) et se contenterait de répercuter sur le disque dur les modifications effectuées sur la machine principale ; - une seconde, qui ne fonctionnerait que lors d'une panne du serveur principal, avec la même configuration qu'icelui (y compris l'adresse IP).
Calimero
Eric Belhomme wrote:
les messages peuvent être stockés sur une partition raid1 via le réseau : les messages sont ainsi en mirroir sur chacune des 2 machines. voir du coté de ENBD (export de device bloc sur le réseau)
Y a DRBD aussi qui est activement maintenu. ENBD ca semble un peu mort non ?
-- @+ Calimero
Eric Belhomme wrote:
les messages peuvent être stockés sur une partition raid1 via le réseau :
les messages sont ainsi en mirroir sur chacune des 2 machines. voir du
coté de ENBD (export de device bloc sur le réseau)
Y a DRBD aussi qui est activement maintenu.
ENBD ca semble un peu mort non ?
les messages peuvent être stockés sur une partition raid1 via le réseau : les messages sont ainsi en mirroir sur chacune des 2 machines. voir du coté de ENBD (export de device bloc sur le réseau)
Y a DRBD aussi qui est activement maintenu. ENBD ca semble un peu mort non ?
-- @+ Calimero
mna
Le Wed, 12 Apr 2006 21:45:34 +0200, Calimero a ecrit dans <e1jlcu$19d2$ :
Eric Belhomme wrote:
les messages peuvent être stockés sur une partition raid1 via le réseau : les messages sont ainsi en mirroir sur chacune des 2 machines. voir du coté de ENBD (export de device bloc sur le réseau)
Y a DRBD aussi qui est activement maintenu. ENBD ca semble un peu mort non ? bonsoir,
j'utilise DRBD sur un cluster linux avec heartbeat depuis maintenant plus d'1 an, je dirai que ça marche plutôt pas mal du tout.
attention toutefois aux procédures de reprise sur incident, si les 2 extrémités du raid1 drbd sont passées en "primary", la réconcialiation des données n'est pas possible, il faut désigner une extrémité comme "primaire" (contenant les données valides) afin que l'autre se re-synchronise.
je déconseillerai donc un re démarrage automatique de la totalité du cluster sans surveillance / intervention / validation humaine.
bon courage.
ps: il faudrait jeter un oeil sur ofs (oracle file system c'est open source) je crois que ça pourrait être sympathique.
Le Wed, 12 Apr 2006 21:45:34 +0200, Calimero a ecrit dans
<e1jlcu$19d2$1@cabale.usenet-fr.net> :
Eric Belhomme wrote:
les messages peuvent être stockés sur une partition raid1 via le
réseau : les messages sont ainsi en mirroir sur chacune des 2 machines.
voir du coté de ENBD (export de device bloc sur le réseau)
Y a DRBD aussi qui est activement maintenu. ENBD ca semble un peu mort non
?
bonsoir,
j'utilise DRBD sur un cluster linux avec heartbeat depuis maintenant plus
d'1 an, je dirai que ça marche plutôt pas mal du tout.
attention toutefois aux procédures de reprise sur incident,
si les 2 extrémités du raid1 drbd sont passées en "primary", la
réconcialiation des données n'est pas possible, il faut désigner une
extrémité comme "primaire" (contenant les données valides) afin que
l'autre se re-synchronise.
je déconseillerai donc un re démarrage automatique de la totalité du
cluster sans surveillance / intervention / validation humaine.
bon courage.
ps: il faudrait jeter un oeil sur ofs (oracle file system c'est open
source) je crois que ça pourrait être sympathique.
Le Wed, 12 Apr 2006 21:45:34 +0200, Calimero a ecrit dans <e1jlcu$19d2$ :
Eric Belhomme wrote:
les messages peuvent être stockés sur une partition raid1 via le réseau : les messages sont ainsi en mirroir sur chacune des 2 machines. voir du coté de ENBD (export de device bloc sur le réseau)
Y a DRBD aussi qui est activement maintenu. ENBD ca semble un peu mort non ? bonsoir,
j'utilise DRBD sur un cluster linux avec heartbeat depuis maintenant plus d'1 an, je dirai que ça marche plutôt pas mal du tout.
attention toutefois aux procédures de reprise sur incident, si les 2 extrémités du raid1 drbd sont passées en "primary", la réconcialiation des données n'est pas possible, il faut désigner une extrémité comme "primaire" (contenant les données valides) afin que l'autre se re-synchronise.
je déconseillerai donc un re démarrage automatique de la totalité du cluster sans surveillance / intervention / validation humaine.
bon courage.
ps: il faudrait jeter un oeil sur ofs (oracle file system c'est open source) je crois que ça pourrait être sympathique.
Calimero
mna wrote:
j'utilise DRBD sur un cluster linux avec heartbeat depuis maintenant plus d'1 an, je dirai que ça marche plutôt pas mal du tout.
attention toutefois aux procédures de reprise sur incident, si les 2 extrémités du raid1 drbd sont passées en "primary", la réconcialiation des données n'est pas possible, il faut désigner une extrémité comme "primaire" (contenant les données valides) afin que l'autre se re-synchronise.
je déconseillerai donc un re démarrage automatique de la totalité du cluster sans surveillance / intervention / validation humaine.
Avec heartbeat tu peux faire du 'stonith' de toute façon, pour éviter tout risque de 'split brain'.
ps: il faudrait jeter un oeil sur ofs (oracle file system c'est open source) je crois que ça pourrait être sympathique.
Coté FS, y a aussi GFS. Mais comme dit, "faudrait jeter un oeil".
-- @+ Calimero
mna wrote:
j'utilise DRBD sur un cluster linux avec heartbeat depuis maintenant plus
d'1 an, je dirai que ça marche plutôt pas mal du tout.
attention toutefois aux procédures de reprise sur incident,
si les 2 extrémités du raid1 drbd sont passées en "primary", la
réconcialiation des données n'est pas possible, il faut désigner une
extrémité comme "primaire" (contenant les données valides) afin que
l'autre se re-synchronise.
je déconseillerai donc un re démarrage automatique de la totalité du
cluster sans surveillance / intervention / validation humaine.
Avec heartbeat tu peux faire du 'stonith' de toute façon, pour éviter
tout risque de 'split brain'.
ps: il faudrait jeter un oeil sur ofs (oracle file system c'est open
source) je crois que ça pourrait être sympathique.
Coté FS, y a aussi GFS. Mais comme dit, "faudrait jeter un oeil".
j'utilise DRBD sur un cluster linux avec heartbeat depuis maintenant plus d'1 an, je dirai que ça marche plutôt pas mal du tout.
attention toutefois aux procédures de reprise sur incident, si les 2 extrémités du raid1 drbd sont passées en "primary", la réconcialiation des données n'est pas possible, il faut désigner une extrémité comme "primaire" (contenant les données valides) afin que l'autre se re-synchronise.
je déconseillerai donc un re démarrage automatique de la totalité du cluster sans surveillance / intervention / validation humaine.
Avec heartbeat tu peux faire du 'stonith' de toute façon, pour éviter tout risque de 'split brain'.
ps: il faudrait jeter un oeil sur ofs (oracle file system c'est open source) je crois que ça pourrait être sympathique.
Coté FS, y a aussi GFS. Mais comme dit, "faudrait jeter un oeil".
