Re: IP flottante du pauvre
Le 24/01/17 à 15:35, Olivier <oza.4h07@gmail.com> a écrit :
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 aurait
O> ou non à produire certains services.
Ça ça dépend de ton infra réseau, est-ce que chaque machine 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 pacemaker et
O> corosync.
O> Ça semble répondre à mon besoin mais pas complètement 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 lancer ou
O> arrêter la production.
O> Bâti à coup d'appels à ifup/idown et systemctl enable/disable/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 Debian.
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 dedans peuvent
s'attribuer une ip là-dedans, suffit d'utiliser ces ip (tu démarres une machine qq part, et
pour migrer tu l'arrête et en redémarre une autre qui prend son ip).
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 machine à une autre.
Pour faire ce genre de chose j'utilise une zone statique dans mon résolveur local (unbound),
c'est un lan.domaine.tld, qui n'existe pas dans les dns public, seulement localement 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, il 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/unbound.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 jamais (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 avaient 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'ancien 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 (voire plusieurs minutes,
le mail supporte ça très bien, l'expéditeur renverra plus tard).
--
Daniel
Rien n'est plus utile que la recherche inutile.
Carlo Rubbia, 26 novembre 1993
Reply to: