Impedir que o VRRP Master se torne Mestre depois de falhar

12

Eu tenho duas máquinas (A e B, A é mestre) executando VRPP (de keepalived) para um IP virtual.

Como posso impedir que A se torne mestre novamente se falhar e retornar (por qualquer motivo)?

Estou fazendo isso para que tenhamos um único failover na segunda caixa e voltar ao normal exigiria intervenção manual.

linux keepalived vrrp

— MrMagu
fonte

Eu sou muito novo para criar tag "VRRP"

— MrMagu

14

De acordo com esse segmento relativamente antigo da lista de desenvolvedores mantidos vivos, isso pode ser feito. Você define os dois servidores para ter a mesma prioridade (ou nenhum) e não declara o estado como MASTER ou BACKUP e, em vez disso, define o estado como EQUAL para ambos.

EDIT (07-Dez-2017):

Parece que EQUAL não é realmente um estado válido, apesar de parecer fornecer o efeito desejado no momento em que esta resposta foi postada. Observe os comentários abaixo, em particular o link para a lista de problemas atuais para manutenção fornecida por @cristi.

— James Sneeringer
fonte

3

Obrigado - Também vale a pena notar que, usando a configuração acima (de igual prioridade e usando "EQUAL") se nenhum mestre assumiu o controle, a instância VRRP com IP mais baixo se tornará MASTER.

— MrMagu 22/07/2009

1

Isto está errado. Veja esta mensagem dos desenvolvedores: github.com/acassen/keepalived/issues/707

— cristi

@cristi - Era uma solução funcional no momento em que foi publicada (2009), que, por sua vez, se baseava em informações que reconheci claramente que eram antigas até então (2003). Atualizei o link na minha resposta para um que funcione, já que o osdir.com parece não ter mais os arquivos keepalived-devel. Eu diria que, na época, o software ignorou silenciosamente a EQUALdiretiva inválida e a tratou como se nenhuma prioridade fosse definida (o que aconteceu com o efeito desejado).

— James Sneeringer

8

A maneira como resolvemos isso foi adicionando a nopreemptflag ao nosso arquivo de configuração keepalived. Não precisava mudar mais nada (ainda deixava um como MASTERe um como BACKUPe assim por diante). Basicamente, isso diz para ele não trocar de mestre apenas porque um novo servidor ficou online, somente alterna quando o mestre atual falhar.

— davr
fonte

4

from " article.gmane.org/gmane.linux.keepalived.devel/1537 " Se "state" estiver definido como MASTER, "nopreempt" será basicamente ignorado, pois quando a máquina com "state MASTER" retornar, apenas o IP será capturado. a máquina com "estado BACKUP" sem sequer realizar uma eleição. Eu tive que configurar minhas duas máquinas para indicar BACKUP com uma prioridade mais alta para que "nopreempt" funcionasse como pretendido.

— MrMagu

Prioridade e estado excluídos e adição não permitida. Funciona bem para mim

— Rihard Novozhilov

-1

Pelo que entendi, quando um novo servidor VRRP é lançado, ele força uma eleição, e o servidor atual não obtém nenhum benefício, então o velho mestre aparece e vence a eleição. Duvido que haja muito que você possa fazer para impedir isso, além do bastante brutal Shoot The Other Node In The Head. Keepalive pode ter alguma configuração para controlar o processo eleitoral. Infelizmente não tenho tempo para verificar agora, mas vou tentar olhar mais tarde.

— David Pashley
fonte

Há um sinalizador de configuração para fazer isso, então esta resposta está errada.

— davr 22/07/09

A resposta votada está correta para uma implantação geral do vrrp em que você não deseja que um mestre assuma o controle quando retornar ao serviço. Como você diz, também há uma maneira de manter isso sempre ativo, o que provavelmente é mais correto ao fazer coisas de alta disponibilidade no Linux, em vez de apenas usar o vrrp para fornecer redundância L3 para uma rota padrão (o motivo mais tradicional para usar o vrrp).

— chris