Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Conseils sur l'exploitation d'un cluster Keepalived

1 réponse
Avatar
Olivier
--000000000000e03fec05c9d658d1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bonjour,

J'ai cluster Keepalived ̓  deux noeuds sous Debian.
̓€ chaque instant, l'un des deux est actif quand l'autre est passif.
Ces deux noeuds sont des VM h̓©berg̓©es sur des h̓´tes diff̓©rents et
ind̓©pendants.

Pour faciliter les op̓©rations de mise ̓  jour (changement d'OS ou de version
de logiciel), je m'interroge sur l'int̓©r̓ªt de doubler le nombre de noeud
sur chaque h̓´te toute en ne conservant, normalement ̓  chaque instant, qu'un
unique noeud actif.

Avant de tester cela, je serai tr̓¨s curieux de lire vos commentaires,
suggestions et retours d'exp̓©rience sur ce type de mises en oeuvre.

Mes questions en vrac, sont:

1. Le doc [1] mentionne un m̓©canisme de track file avec lequel il me semble
possible de changer ̓  la vol̓©e la priorit̓© d'un noeud et donc de forcer son
̓©tat Actif ou Passif. Ai-je bien compris ce m̓©canisme ? Y a-t-il des
alternatives ?

2. Quels sont les risques d'un cluster dont des membres sont dans des
versions Debian diff̓©rentes (le but est d'aider ̓  la mont̓©e de version) ?

3. J'imagine mettre ̓  niveau de la fa̓§on suivante:
3.1 le m̓ªme jour, on immobilise deux noeuds passifs (1 sur chaque h̓´te de
virtualisation)
3.2 on met ̓  jour les 2 noeuds immobilis̓©s
3.3 ̓  l'heure idoine, on bascule vers l'un des 2 noeuds ̓  jour (avec retour
arri̓¨re en cas d'̓©chec)
3.4 quelques temps apr̓¨s, on immobilise deux noeuds restants et on r̓©p̓¨te
les op̓©rations 3.1 ̓  3.4
Voyez-vous une meilleure fa̓§on de proc̓©der ?
Pour moi, ses inconv̓©nients (qui me semblent acceptables) sont:
deux ruptures de service ̓  chaque migration,
deux noeuds sont migr̓©s sans v̓©ritablement avoir ̓©t̓© test̓©s.

[1] https://www.redhat.com/sysadmin/advanced-keepalived

Slts

--000000000000e03fec05c9d658d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div>Bonjour,</div><div><br></div><div>J&#39;ai cluster Keepalived ̓  deux noeuds sous Debian.</div><div>̓€ chaque instant, l&#39;un des deux est actif quand l&#39;autre est passif.</div><div>Ces deux noeuds sont des VM h̓©berg̓©es sur des h̓´tes diff̓©rents et ind̓©pendants.<br></div><div><br></div><div>Pour faciliter les op̓©rations de mise ̓  jour (changement d&#39;OS ou de version de logiciel), je m&#39;interroge sur l&#39;int̓©r̓ªt de doubler le nombre de noeud sur chaque h̓´te toute en ne conservant, normalement ̓  chaque instant, qu&#39;un unique noeud actif.</div><div><br></div><div>Avant de tester cela, je serai tr̓¨s curieux de lire vos commentaires, suggestions et retours d&#39;exp̓©rience sur ce type de mises en oeuvre.</div><div><br></div><div>Mes questions en vrac, sont:</div><div><br></div><div>1. Le doc [1] mentionne un m̓©canisme de track file avec lequel il me semble possible de changer ̓  la vol̓©e la priorit̓© d&#39;un noeud et donc de forcer son ̓©tat Actif ou Passif. Ai-je bien compris ce m̓©canisme ? Y a-t-il des alternatives ?</div><div><br></div><div>2. Quels sont les risques d&#39;un cluster dont des membres sont dans des versions Debian diff̓©rentes (le but est d&#39;aider ̓  la mont̓©e de version) ?</div><div><br></div><div>3. J&#39;imagine mettre ̓  niveau de la fa̓§on suivante:</div><div>3.1 le m̓ªme jour, on immobilise deux noeuds passifs (1 sur chaque h̓´te de virtualisation)</div><div>3.2 on met ̓  jour les 2 noeuds immobilis̓©s</div><div>3.3 ̓  l&#39;heure idoine, on bascule vers l&#39;un des 2 noeuds ̓  jour (avec retour arri̓¨re en cas d&#39;̓©chec)</div><div>3.4 quelques temps apr̓¨s, on immobilise deux noeuds restants et on r̓©p̓¨te les op̓©rations 3.1 ̓  3.4</div><div>Voyez-vous une meilleure fa̓§on de proc̓©der ?</div><div>Pour moi, ses inconv̓©nients (qui me semblent acceptables) sont:</div><div>deux ruptures de service ̓  chaque migration,</div><div>deux noeuds sont migr̓©s sans v̓©ritablement avoir ̓©t̓© test̓©s.<br></div><div><br></div><div>[1] <a href="https://www.redhat.com/sysadmin/advanced-keepalived">https://www.redhat.com/sysadmin/advanced-keepalived</a></div><div><br></div><div>Slts<br></div></div>

--000000000000e03fec05c9d658d1--

1 réponse

Avatar
Gregory
Hello
Le Wed, 18 Aug 2021 16:35:23 +0200,
Olivier a écrit :
1. Le doc [1] mentionne un mécanisme de track file avec lequel il me
semble possible de changer Í  la volée la priorité d'un noeud et donc
de forcer son état Actif ou Passif. Ai-je bien compris ce mécanisme ?
Y a-t-il des alternatives ?

avec ce mécanisme, mon paragraphe lance un script shell.
Quand je veux forcer un déplacement de master :
* mon script shell check la présence d'un fichier. si ce fichier est
présent je "exit 1" , keepalived fait la bascule en conséquence
* s'assurer de ne pas automatiquement revenir sur " le master
historique " : nopreempt de mémoire
* ne pas faire autre chose que 0 ou 1 comme code retour du script ce
qui est > 1 ne semble pas pris en compte par keepalived
vrrp_script chk_mysql {
script "/etc/keepalived/scripts/chk_mysql.sh"
[...]
[...]
track_script {
chk_mysql
}
2. Quels sont les risques d'un cluster dont des membres sont dans des
versions Debian différentes (le but est d'aider Í  la montée de
version) ?

J'ai jamais eu de problèmes
3. J'imagine mettre Í  niveau de la façon suivante:

j'ai pas compris :-D