IP flottante du pauvre

Le
Olivier
--001a113cef2a9bef960546d808bc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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, l=
e
jour venu, à basculer la production de la nouvelle machine vers une au=
tre
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 pacema=
ker et
corosync.
Ça semble répondre à mon besoin mais pas complètement 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évoir sa future existence.

Plus concrètement, j'imaginais simplement:
- lister les services qui doivent pouvoir migrer d'une machine à l'aut=
re
- vérifier que chacun de ces services peut être configuré po=
ur 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.

Pour ce dernier mécanisme, j'imagine rédiger un script pour lance=
r ou
arrêter la production.
Bâti à coup d'appels à ifup/idown et systemctl enable/disabl=
e/start/stop,
le script n'a pas besoin d'être très rapide (20s pour s'exéc=
uter me parait
acceptable).
Avec un peu de chance, le script pourrait tourner sans modification sur une
machine de remplacement dotée d'une version différente de Debian.


Qu'en pensez-vous ?
Des suggestions ou recommandations ?

Slts

--001a113cef2a9bef960546d808bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div><div><div><div><div><div><div><div>Bonjour,<br><br></=
div>Pour une nouvelle machine que je vais bientôt mettre en service, j=
e souhaite mettre en place un mécanisme d&#39;IP flottante qui m&#39;a=
iderait, le jour venu, à basculer la production de la nouvelle machine=
vers une autre machine la remplaçant.<br><br></div>J&#39;imagine que =
chaque machine aurait une IP (privée) qui lui soit spécifique et =
persistante qu&#39;ainsi qu&#39;une IP (privée) qu&#39;elle pourrait u=
n jour accaparer ou abandonner au profit d&#39;une autre machine selon qu&#=
39;elle aurait ou non à produire certains services.<br><br></div>J&#39=
;ai vu brièvement à l&#39;oeuvre ce genre de basculement avec pac=
emaker et corosync.<br></div>Ça semble répondre à mon besoin=
mais pas complètement car, si j&#39;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&#39;existe pas encore et je veux simplement prévoir sa=
future existence.<br><br></div>Plus concrètement, j&#39;imaginais sim=
plement:<br></div>- lister les services qui doivent pouvoir migrer d&#39;un=
e machine à l&#39;autre<br></div>- vérifier que chacun de ces ser=
vices peut être configuré pour utiliser l&#39;IP flottante plut=
ôt que l&#39;IP persistante,<br></div>- trouver un mécanisme pour=
basculer simplement les ressources (IP flottante) et services d&#39;une ma=
chine à l&#39;autre.<br><div><div><div><div><br></div><div>Pour ce der=
nier mécanisme, j&#39;imagine rédiger un script pour lancer ou ar=
rêter la production.<br></div><div>Bâti à coup d&#39;appels =
à ifup/idown et systemctl enable/disable/start/stop, le script n&#39;a=
pas besoin d&#39;être très rapide (20s pour s&#39;exécuter =
me parait acceptable).<br></div><div>Avec un peu de chance, le script pourr=
ait tourner sans modification sur une machine de remplacement dotée d&=
#39;une version différente de Debian.<br><br></div><div><br></div><div=
>Qu&#39;en pensez-vous ?<br></div><div>Des suggestions ou recommandations ?=
<br><br></div><div>Slts<br></div></div></div></div></div>

--001a113cef2a9bef960546d808bc--
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
daniel huhardeaux
Le #26424456
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
Daniel Caillibaud
Le #26424497
Le 24/01/17 à 15:35, Olivier O> Bonjour,
O>
O> Pour une nouvelle machine que je vais bientôt mettre en service, je
O> souhaite mettre en place un mécanisme d'IP flottante qui m'aiderait , le
O> jour venu, à basculer la production de la nouvelle machine vers une autre
O> machine la remplaçant.
O>
O> J'imagine que chaque machine aurait une IP (privée) qui lui soit sp écifique
O> et persistante qu'ainsi qu'une IP (privée) qu'elle pourrait un jour
O> accaparer ou abandonner au profit d'une autre machine selon qu'elle aura it
O> ou non à produire certains services.
Ça ça dépend de ton infra réseau, est-ce que chaque mac hine peut décider de l'ip qu'elle veut
prendre ou pas.
O> J'ai vu brièvement à l'oeuvre ce genre de basculement avec pac emaker et
O> corosync.
O> Ça semble répondre à mon besoin mais pas complètemen t car, si j'ai bien
O> bien compris, ces outils tout comme les ucarp et keepalived, exigent une
O> communication permanente entre une machine active et une machine passive
O> alors que dans mon cas, la machine passive n'existe pas encore et je veux
O> simplement prévoir sa future existence.
O>
O> Plus concrètement, j'imaginais simplement:
O> - lister les services qui doivent pouvoir migrer d'une machine à l' autre
O> - vérifier que chacun de ces services peut être configuré pour utiliser
O> l'IP flottante plutôt que l'IP persistante,
O> - trouver un mécanisme pour basculer simplement les ressources (IP
O> flottante) et services d'une machine à l'autre.
O>
O> Pour ce dernier mécanisme, j'imagine rédiger un script pour la ncer ou
O> arrêter la production.
O> Bâti à coup d'appels à ifup/idown et systemctl enable/dis able/start/stop,
O> le script n'a pas besoin d'être très rapide (20s pour s'exà ©cuter me parait
O> acceptable).
O> Avec un peu de chance, le script pourrait tourner sans modification sur une
O> machine de remplacement dotée d'une version différente de Debi an.
O>
O>
O> Qu'en pensez-vous ?
Qu'il manque des infos pour une réponse pertinente.
Par ex, si tu es sur un reseau x.y.z.0/24, et que toutes les machines dedan s peuvent
s'attribuer une ip là-dedans, suffit d'utiliser ces ip (tu démarr es une machine qq part, et
pour migrer tu l'arrête et en redémarre une autre qui prend son i p).
Vouloir déménager une ip n'est pas forcément le plus simple pour déménager un service, et ça
implique en général une coupure.
O> Des suggestions ou recommandations ?
Pour des backends web, tu as un frontal avec une ip publique, et c'est plus simple d'aller
changer les ip privées dans sa conf que de basculer des ip d'une machi ne à une autre.
Pour faire ce genre de chose j'utilise une zone statique dans mon réso lveur local (unbound),
c'est un lan.domaine.tld, qui n'existe pas dans les dns public, seulement l ocalement sur mes
machines (qui utilisent ces unbound).
- un fichier txt avec mes lignes "host ip", parce que c'est simple à éditer
- un script passe un coup de sed dessus pour le mettre au format unbound, i l transforme ma ligne
truc.lan.domaine.tld. 192.168.x.y
en
local-data: "truc.lan.domaine.tld. IN A 192.168.x.y"
local-data-ptr: "192.168.x.y truc.lan.domaine.tld"
puis déploie ça sur tous mes unbound (dans un /etc/unbound/unbo und.conf.d/lan.conf) et
fait un reload sur chacun d'eux (et remet l'ancien si le reload plante)
Ça permet d'utiliser dans toutes mes conf des noms qui ne changent jam ais (j'utilise les noms
courts "truc" car j'ai du search lan.domaine.tld dans mes /etc/resolv.conf, mais sinon tu peux
utiliser les noms complets), et basculer un service d'un serveur à un autre sans couper
le service (les nouvelles connexions se font sur le nouveau et celles qui a vaient démarré
juste avant se terminent sur l'ancien).
Évidemment, ça marche pas forcément pour tous les services, si le service enregistre de l'info
et ne peut pas la synchroniser avec l'autre instance il faut couper l'ancie n avant de basculer
sur le nouveau. Le seul cas que j'ai comme ça est un serveur mail qui stocke localement les
mails, mais c'est aussi celui qu'il n'est pas gênant de couper qq s (v oire plusieurs minutes,
le mail supporte ça très bien, l'expéditeur renverra plus ta rd).
--
Daniel
Rien n'est plus utile que la recherche inutile.
Carlo Rubbia, 26 novembre 1993
Nicolas Courtel
Le #26424511
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.
--
Nicolas
Publicité
Poster une réponse
Anonyme