• Conseils sur l'exploitation d'un cluster Keepalived

    From Olivier@21:1/5 to All on Wed Aug 18 16:40:01 2021
    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

    <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><
    <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><
    </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>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gregory@21:1/5 to All on Thu Aug 19 09:20:02 2021
    Hello

    Le Wed, 18 Aug 2021 16:35:23 +0200,
    Olivier <oza.4h07@gmail.com> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)