Empêcher VRRP Master de devenir Master en cas d'échec

12

J'ai deux machines (A et B, A est maître) exécutant VRPP (de keepalived) pour une IP virtuelle.

Comment puis-je empêcher A de redevenir maître s'il a échoué et revenir (pour une raison quelconque)?

Je fais cela pour que nous ayons un seul basculement vers la deuxième boîte, et revenir à la normale nécessiterait une intervention manuelle.

linux keepalived vrrp

— MrMagu
source

Je suis trop nouveau pour créer le tag "VRRP"

— MrMagu

14

Selon ce fil relativement ancien sur la liste des développeurs keepalived, cela peut être fait. Vous définissez les deux serveurs sur une priorité égale (ou aucun), et ne déclarez pas l'état pour MASTER ou BACKUP, et définissez plutôt l'état sur EQUAL pour les deux.

EDIT (07-déc.-2017):

Il semble qu'EQUAL ne soit pas réellement un état valide, bien qu'il semble fournir l'effet souhaité au moment où cette réponse a été publiée. Veuillez noter les commentaires ci-dessous, en particulier le lien vers la liste des problèmes actuels pour keepalived fournie par @cristi.

— James Sneeringer
source

3

Merci - Il vaut également la peine de noter, en utilisant la configuration ci-dessus (de priorité égale et en utilisant "EQUAL") si aucun maître n'a pris le relais, l'instance VRRP avec l'IP la plus basse deviendra MASTER.

— MrMagu

1

C'est faux. Voir ce message des développeurs: github.com/acassen/keepalived/issues/707

— cristi

@cristi - C'était une solution qui fonctionnait au moment de sa publication (2009), qui à son tour était basée sur des informations dont je reconnaissais clairement qu'elles étaient anciennes (2003). J'ai mis à jour le lien dans ma réponse en un lien fonctionnel depuis osdir.com ne semble plus avoir les archives keepalived-devel. Je suppose que, à l'époque, le logiciel ignorait silencieusement la EQUALdirective invalide et la traitait comme si aucune priorité n'était définie (ce qui s'est avéré justement avoir l'effet souhaité).

— James Sneeringer

8

Nous avons résolu ce problème en ajoutant l' nopreemptindicateur à notre fichier de configuration keepalived. N'a pas eu à changer quoi que ce soit (toujours laissé un comme MASTERet un comme BACKUPet ainsi de suite). Fondamentalement, cela lui dit de ne pas changer de maître simplement parce qu'un nouveau serveur est en ligne, de ne commuter qu'en cas de défaillance du maître actuel.

— davr
source

4

from " article.gmane.org/gmane.linux.keepalived.devel/1537 " Si "state" est défini sur MASTER, "nopreempt" est fondamentalement ignoré car lorsque la machine avec "state MASTER" revient, elle récupérera simplement l'adresse IP de la machine avec "état BACKUP" sans même organiser une élection. J'ai dû régler mes deux machines sur l'état SAUVEGARDE avec une priorité plus élevée pour que "nopreempt" fonctionne comme prévu.

— MrMagu

Suppression de la priorité et de l'état et ajout de nopreempt. Fonctionne bien pour moi

— Rihard Novozhilov

-1

Si je comprends bien, lorsqu'un nouveau serveur VRRP arrive, il force une élection, et le serveur actuel n'obtient aucun avantage, donc l'ancien maître viendra et gagnera l'élection. Je doute qu'il y ait beaucoup que vous puissiez faire pour arrêter cela, au-delà du tournage plutôt brutal de The Other Node In The Head. Keepalive peut avoir une configuration pour contrôler le processus électoral. Malheureusement, je n'ai pas le temps de vérifier maintenant, mais je vais essayer de regarder plus tard.

— David Pashley
source

Il y a un indicateur de configuration pour cela, donc cette réponse est fausse.

— davr

La réponse votée est correcte pour un déploiement général de vrrp où vous ne voulez pas qu'un maître prenne le relais lorsqu'il revient en service. Comme vous le dites, il existe également une manière de le faire qui est probablement plus correcte lorsque vous faites des trucs linux HA au lieu d'utiliser simplement vrrp pour fournir une redondance L3 pour une route par défaut (la raison la plus traditionnelle d'utiliser vrrp).

— chris