Pour une nouvelle machine que je vais bient=C3=B4t mettre en service, je
souhaite mettre en place un m=C3=A9canisme d'IP flottante qui m'aiderait, l=
e
jour venu, =C3=A0 basculer la production de la nouvelle machine vers une au=
tre
machine la rempla=C3=A7ant.
J'imagine que chaque machine aurait une IP (priv=C3=A9e) qui lui soit sp=C3=
=A9cifique
et persistante qu'ainsi qu'une IP (priv=C3=A9e) qu'elle pourrait un jour
accaparer ou abandonner au profit d'une autre machine selon qu'elle aurait
ou non =C3=A0 produire certains services.
J'ai vu bri=C3=A8vement =C3=A0 l'oeuvre ce genre de basculement avec pacema=
ker et
corosync.
=C3=87a semble r=C3=A9pondre =C3=A0 mon besoin mais pas compl=C3=A8tement c=
ar, si j'ai bien
bien compris, ces outils tout comme les ucarp et keepalived, exigent une
communication permanente entre une machine active et une machine passive
alors que dans mon cas, la machine passive n'existe pas encore et je veux
simplement pr=C3=A9voir sa future existence.
Plus concr=C3=A8tement, j'imaginais simplement:
- lister les services qui doivent pouvoir migrer d'une machine =C3=A0 l'aut=
re
- v=C3=A9rifier que chacun de ces services peut =C3=AAtre configur=C3=A9 po=
ur utiliser
l'IP flottante plut=C3=B4t que l'IP persistante,
- trouver un m=C3=A9canisme pour basculer simplement les ressources (IP
flottante) et services d'une machine =C3=A0 l'autre.
Pour ce dernier m=C3=A9canisme, j'imagine r=C3=A9diger un script pour lance=
r ou
arr=C3=AAter la production.
B=C3=A2ti =C3=A0 coup d'appels =C3=A0 ifup/idown et systemctl enable/disabl=
e/start/stop,
le script n'a pas besoin d'=C3=AAtre tr=C3=A8s rapide (20s pour s'ex=C3=A9c=
uter me parait
acceptable).
Avec un peu de chance, le script pourrait tourner sans modification sur une
machine de remplacement dot=C3=A9e d'une version diff=C3=A9rente de Debian.
Qu'en pensez-vous ?
Des suggestions ou recommandations ?
<div dir=3D"ltr"><div><div><div><div><div><div><div><div>Bonjour,<br><br></=
div>Pour une nouvelle machine que je vais bient=C3=B4t mettre en service, j=
e souhaite mettre en place un m=C3=A9canisme d'IP flottante qui m'a=
iderait, le jour venu, =C3=A0 basculer la production de la nouvelle machine=
vers une autre machine la rempla=C3=A7ant.<br><br></div>J'imagine que =
chaque machine aurait une IP (priv=C3=A9e) qui lui soit sp=C3=A9cifique et =
persistante qu'ainsi qu'une IP (priv=C3=A9e) qu'elle pourrait u=
n jour accaparer ou abandonner au profit d'une autre machine selon qu&#=
39;elle aurait ou non =C3=A0 produire certains services.<br><br></div>J'=
;ai vu bri=C3=A8vement =C3=A0 l'oeuvre ce genre de basculement avec pac=
emaker et corosync.<br></div>=C3=87a semble r=C3=A9pondre =C3=A0 mon besoin=
mais pas compl=C3=A8tement car, si j'ai bien bien compris, ces outils =
tout comme les ucarp et keepalived, exigent une communication permanente en=
tre une machine active et une machine passive alors que dans mon cas, la ma=
chine passive n'existe pas encore et je veux simplement pr=C3=A9voir sa=
future existence.<br><br></div>Plus concr=C3=A8tement, j'imaginais sim=
plement:<br></div>- lister les services qui doivent pouvoir migrer d'un=
e machine =C3=A0 l'autre<br></div>- v=C3=A9rifier que chacun de ces ser=
vices peut =C3=AAtre configur=C3=A9 pour utiliser l'IP flottante plut=
=C3=B4t que l'IP persistante,<br></div>- trouver un m=C3=A9canisme pour=
basculer simplement les ressources (IP flottante) et services d'une ma=
chine =C3=A0 l'autre.<br><div><div><div><div><br></div><div>Pour ce der=
nier m=C3=A9canisme, j'imagine r=C3=A9diger un script pour lancer ou ar=
r=C3=AAter la production.<br></div><div>B=C3=A2ti =C3=A0 coup d'appels =
=C3=A0 ifup/idown et systemctl enable/disable/start/stop, le script n'a=
pas besoin d'=C3=AAtre tr=C3=A8s rapide (20s pour s'ex=C3=A9cuter =
me parait acceptable).<br></div><div>Avec un peu de chance, le script pourr=
ait tourner sans modification sur une machine de remplacement dot=C3=A9e d&=
#39;une version diff=C3=A9rente de Debian.<br><br></div><div><br></div><div=
>Qu'en pensez-vous ?<br></div><div>Des suggestions ou recommandations ?=
<br><br></div><div>Slts<br></div></div></div></div></div>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
daniel huhardeaux
Le 24/01/2017 à 15:35, Olivier a écrit :
Bonjour,
Bonjour
[...] Ça semble répondre à mon besoin mais pas complètement car, si j'ai bien bien compris, ces outils tout comme les ucarp et keepalived, exigent une communication permanente entre une machine active et une machine passive alors que dans mon cas, la machine passive n'existe pas encore et je veux simplement prévoir sa future existence.
[...] ucarp avec une seule machine fonctionne: elle sera maitre et ne s'occupe de rien, pas d'autre exigence. C'est la passive qui s'occupe de reprendre la main si l'active ne répond plus. J'ai développé il y a quelques années des scripts afin d'automatiser le up/down des interfaces et la gestion des services à arrêter/redémarrer. Je les tiens à ta disposition si tu es intéressé. -- Daniel
Le 24/01/2017 à 15:35, Olivier a écrit :
Bonjour,
Bonjour
[...]
Ça semble répondre à mon besoin mais pas complètement car, si j'ai
bien bien compris, ces outils tout comme les ucarp et keepalived,
exigent une communication permanente entre une machine active et une
machine passive alors que dans mon cas, la machine passive n'existe
pas encore et je veux simplement prévoir sa future existence.
[...]
ucarp avec une seule machine fonctionne: elle sera maitre et ne s'occupe
de rien, pas d'autre exigence. C'est la passive qui s'occupe de
reprendre la main si l'active ne répond plus.
J'ai développé il y a quelques années des scripts afin d'automatiser le
up/down des interfaces et la gestion des services à arrêter/redémarrer.
Je les tiens à ta disposition si tu es intéressé.
[...] Ça semble répondre à mon besoin mais pas complètement car, si j'ai bien bien compris, ces outils tout comme les ucarp et keepalived, exigent une communication permanente entre une machine active et une machine passive alors que dans mon cas, la machine passive n'existe pas encore et je veux simplement prévoir sa future existence.
[...] ucarp avec une seule machine fonctionne: elle sera maitre et ne s'occupe de rien, pas d'autre exigence. C'est la passive qui s'occupe de reprendre la main si l'active ne répond plus. J'ai développé il y a quelques années des scripts afin d'automatiser le up/down des interfaces et la gestion des services à arrêter/redémarrer. Je les tiens à ta disposition si tu es intéressé. -- Daniel
Pour une nouvelle machine que je vais bientôt mettre en service, je souhaite mettre en place un mécanisme d'IP flottante qui m'aiderait, le jour venu, à basculer la production de la nouvelle machine vers une autre machine la remplaçant. J'imagine que chaque machine aurait une IP (privée) qui lui soit spécifique et persistante qu'ainsi qu'une IP (privée) qu'elle pourrait un jour accaparer ou abandonner au profit d'une autre machine selon qu'elle aurait ou non à produire certains services. J'ai vu brièvement à l'oeuvre ce genre de basculement avec pacemaker et corosync. Ça semble répondre à mon besoin mais pas complètement car, si j'ai bien bien compris, ces outils tout comme les ucarp et keepalived, exigent une communication permanente entre une machine active et une machine passive alors que dans mon cas, la machine passive n'existe pas encore et je veux simplement prévoir sa future existence. Plus concrètement, j'imaginais simplement: - lister les services qui doivent pouvoir migrer d'une machine à l'autre - vérifier que chacun de ces services peut être configuré pour utiliser l'IP flottante plutôt que l'IP persistante, - trouver un mécanisme pour basculer simplement les ressources (IP flottante) et services d'une machine à l'autre.
heartbeat correspond à ton besoin, il te permet de décrire tous les services concernés par la migration. En l'absence de second serveur, il sera en erreur permanente mais n'empêchera pas le premier serveur de fonctionner. -- Nicolas
Le 24/01/2017 à 15:35, Olivier a écrit :
Bonjour,
Bonjour,
Pour une nouvelle machine que je vais bientôt mettre en service, je
souhaite mettre en place un mécanisme d'IP flottante qui m'aiderait,
le jour venu, à basculer la production de la nouvelle machine vers une
autre machine la remplaçant.
J'imagine que chaque machine aurait une IP (privée) qui lui soit
spécifique et persistante qu'ainsi qu'une IP (privée) qu'elle pourrait
un jour accaparer ou abandonner au profit d'une autre machine selon
qu'elle aurait ou non à produire certains services.
J'ai vu brièvement à l'oeuvre ce genre de basculement avec pacemaker
et corosync.
Ça semble répondre à mon besoin mais pas complètement car, si j'ai
bien bien compris, ces outils tout comme les ucarp et keepalived,
exigent une communication permanente entre une machine active et une
machine passive alors que dans mon cas, la machine passive n'existe
pas encore et je veux simplement prévoir sa future existence.
Plus concrètement, j'imaginais simplement:
- lister les services qui doivent pouvoir migrer d'une machine à l'autre
- vérifier que chacun de ces services peut être configuré pour
utiliser l'IP flottante plutôt que l'IP persistante,
- trouver un mécanisme pour basculer simplement les ressources (IP
flottante) et services d'une machine à l'autre.
heartbeat correspond à ton besoin, il te permet de décrire tous les
services concernés par la migration. En l'absence de second serveur, il
sera en erreur permanente mais n'empêchera pas le premier serveur de
fonctionner.
Pour une nouvelle machine que je vais bientôt mettre en service, je souhaite mettre en place un mécanisme d'IP flottante qui m'aiderait, le jour venu, à basculer la production de la nouvelle machine vers une autre machine la remplaçant. J'imagine que chaque machine aurait une IP (privée) qui lui soit spécifique et persistante qu'ainsi qu'une IP (privée) qu'elle pourrait un jour accaparer ou abandonner au profit d'une autre machine selon qu'elle aurait ou non à produire certains services. J'ai vu brièvement à l'oeuvre ce genre de basculement avec pacemaker et corosync. Ça semble répondre à mon besoin mais pas complètement car, si j'ai bien bien compris, ces outils tout comme les ucarp et keepalived, exigent une communication permanente entre une machine active et une machine passive alors que dans mon cas, la machine passive n'existe pas encore et je veux simplement prévoir sa future existence. Plus concrètement, j'imaginais simplement: - lister les services qui doivent pouvoir migrer d'une machine à l'autre - vérifier que chacun de ces services peut être configuré pour utiliser l'IP flottante plutôt que l'IP persistante, - trouver un mécanisme pour basculer simplement les ressources (IP flottante) et services d'une machine à l'autre.
heartbeat correspond à ton besoin, il te permet de décrire tous les services concernés par la migration. En l'absence de second serveur, il sera en erreur permanente mais n'empêchera pas le premier serveur de fonctionner. -- Nicolas