Alterado o estado do servidor como BACKUP. Primário com prioridade mais alta e com nopreempt, ambos com o mesmo ID de roteador. Isso funciona para mim.
Eu quero usar a opção nopreempt com a configuração keeprrived vrrp para executar o nó de backup como master quando o master for desativado e novamente voltar à rede.
Configurei a opção nopreempt nos dois servidores e configurei o estado como backup nos dois servidores, mas devido ao nopreempt de alta prioridade não está funcionando.
Por favor, orientar para resolvê-lo?
Master Machine:
! Configuration File for keepalived
vrrp_instance VI_1 {
state BACKUP
nopreempt
interface eth0
virtual_router_id 1
priority 250
advert_int 1
virtual_ipaddress {
192.168.1.2/24
}
}
Backup Machine :
! Configuration File for keepalived
vrrp_instance VI_1 {
state BACKUP
nopreempt
interface eth0
virtual_router_id 1
priority 200
advert_int 1
virtual_ipaddress {
192.168.1.2/24
}
}
Atenciosamente, Ben
Alterado o estado do servidor como BACKUP. Primário com prioridade mais alta e com nopreempt, ambos com o mesmo ID de roteador. Isso funciona para mim.
Primeiro de tudo: estou usando o CentOS 6 e keepalived 1.2.7 (02 / 21,2013)
Eu também experimentei o nopreempt e depois de alguns testes ele funciona como esperado.
A execução do master e do backup com a mesma prioridade de vrrp é uma idéia porque existe um bug (AFAICT) que leva a uma situação em que ambos os servidores iniciam o VIP. De acordo com o link , o keepalive com o IP mais alto deve permanecer / se tornar master. Eu não pude observar esse comportamento!
(AFAICT novamente) Você tem que remover a declaração "estado" do arquivo de configuração, se você pretende ver nopreempt funcionando. Se o keepalive com "state MASTER" no arquivo config for iniciado, ele inicia como master e se auto-anuncia como tal = bad. Se não houver instrução "state" no arquivo de configuração, o keepalived inicia no estado BACKUP e escuta vrrp. por causa de "nopreempt", ele não se tornará MASTER, mesmo se for executado com a mais alta prioridade. isto é contrário à página man keepalived.conf 5, onde o estado não importa muito.
O keepalive com o prio 255 sempre se torna master - independentemente da opção nopreempt ativada ou desativada.
Se você testar o serviço de manutenção, veja de perto as regras do firewall / nat. É sempre uma boa idéia executar algo como o tcpdump para verificar se os anúncios vrrp passam e têm o IP do remetente correto (o do outro keepalived (s), não o gw padrão!) Isto é especialmente verdadeiro se você usar kvm / qemu guests, pois existem regras nat padrão que alteram os anúncios vrrp.
nopreempt só funciona para keepalived no estado BACKUP. (RTFM) se keepalived (1.2.7) estiver em execução e o link de rede ficar inativo, as alterações de manutenção de status ficarão no estado FAULT. quando o link de rede voltar, o keepalive se tornará MASTER se o prio for alto o suficiente. Eu não sei se isso é um bug, mas isso faz com que o nopreempt seja inútil. Vou enviar uma pergunta para a lista de discussão.
Divirta-se! Atenciosamente
Stefan Kärst
Isso pode ou não ser a solução correta para você, mas eu só tenho dois servidores de manutenção de tarefas.
Se você não quiser que um servidor anteceda o outro, um servidor com prioridade mais alta que o outro não importa em um cenário de dois servidores como o meu. Funciona para mim se eu ativar nopreempt
e definir os dois servidores para terem a mesma prioridade.
UPDATE
Exemplo de configuração conforme solicitado:
vrrp_sync_group VRRP_SYNCS {
group {
public_http_ips
}
}
vrrp_instance public_http_ips {
state MASTER
interface eth0
virtual_router_id 18
priority 100
advert_int 1
nopreempt
virtual_ipaddress {
192.168.0.254/24 dev eth0
}
}
O backup é exatamente o mesmo, mas diz "estado BACKUP".
Eu tentei muitas configurações para conseguir isso e o único que funcionava era configurar os dois servidores para estado BACKUP , um servidor com prioridade 51 , o outro com < strong> 50 e definindo nopreempt . Aqui está a configuração de exemplo:
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 51
nopreempt
advert_int 1
authentication {
auth_type PASS
auth_pass XXXXXXXX
}
virtual_ipaddress {
192.168.69.100/28
}
}
Basta definir a prioridade para 50 no segundo servidor e todos devem funcionar.
Você deve definir as opções "fall" e "rise" no script vrrp. Exemplo de configuração em execução:
vrrp_script chk_haproxy {
script "killall -0 haproxy"
interval 1
fall 2
rise 2
}
vrrp_instance VI_1 {
interface eth0
track_interface {
eth0
eth1
}
state BACKUP # same as other node
priority 101 # your choice
virtual_router_id 53
advert_int 1
nopreempt
authentication {
auth_type PASS
auth_pass 8CHARPASS
}
unicast_src_ip 172.31.10.11 # other node: 172.31.10.12
unicast_peer {
172.31.10.12 # other node: 172.31.10.11
}
virtual_ipaddress {
172.31.20.20 dev eth1
}
track_script {
chk_haproxy
}
}
Tags keepalived