opção nopreempt keepalived não funciona

6

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

    
por Ben 08.04.2013 / 11:42

5 respostas

3

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.

    
por 05.03.2014 / 14:06
1

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

    
por 16.10.2013 / 22:54
0

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".

    
por 09.04.2013 / 18:00
0

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.

    
por 28.08.2013 / 20:03
0

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
    }
}
    
por 17.02.2017 / 14:10

Tags