Configurações com manutenção de vida

Question

Eu instalei keepalived em dois firewalls para fornecer failover. Não tenho certeza se as configurações a seguir estão corretas (consulte as configurações abaixo).

Às vezes, tenho problemas para acessar os sites que estão por trás dos firewalls. Eu suspeito que quando keepalived é executado em ambos os firewalls, por um período de aproximadamente um minuto, os sites permanecem inacessíveis .. então a conexão com os sites é recuperada.

Qual poderia ser o problema? Será que o keepalived está mudando de estado (MASTER ou SLAVE) constantemente?

O Firewall-2 é executado no estado MASTER. Quando o keepalived é iniciado em firewall-1 , ele salta para o estado BACKUP.

Existem comandos ou ferramentas como ipvsadm para verificar o estado real de keepalived ?

Configuração keepalived.conf no firwall-1

    root@firewall-1:/etc/keepalived# head -n100 keepalived.conf

    global_defs {
        router_id fw_1 
    }
    vrrp_sync_group loadbalancers {
        group {
            extern
            intern  
        }
    }
    vrrp_instance extern {
        state BACKUP
        priority 100 
        interface eth0.100
        garp_master_delay 5 
        virtual_router_id 40 
        advert_int 1
        authentication {
            auth_type AH 
            auth_pass xxxx
        }
        virtual_ipaddress {
            194.xx.xx.x1
            194.xx.xx.x2
            194.xx.xx.x3
            194.xx.xx.xx
            194.xx.xx.xx
            194.xx.xx.x7
        }
    }   
    vrrp_instance intern {
        state BACKUP
        priority 100 
        notify "/usr/local/sbin/restart_pound"
        interface eth0.200
        garp_master_delay 5 
        virtual_router_id 41 
        advert_int 1
        authentication {
            auth_type AH 
            auth_pass xxxx
        }
        virtual_ipaddress {
            192.168.100.1
            192.168.100.10
        }
    }
..........
..........
..........

Configuração keepalived.conf no firewall-2

    root@firewall-2:/opt# head -n100 /etc/keepalived/keepalived.conf

    global_defs {
        router_id fw_2 
    }
    vrrp_sync_group loadbalancers {
        group {
            extern
            intern  
        }
    }
    vrrp_instance extern {
        state MASTER 
        priority 200 
        interface eth1
        garp_master_delay 5 
        virtual_router_id 40 
        advert_int 1
        authentication {
            auth_type AH 
            auth_pass xxxx
        }
        virtual_ipaddress {
            194.xx.xx.x1
            194.xx.xx.x2
            194.xx.xx.x3
            194.xx.xx.xx
            194.xx.xx.xx
            194.xx.xx.x7
        }
    }   
    vrrp_instance intern {
        state MASTER
        priority 200
        notify "/usr/local/sbin/restart_pound"
        interface eth0.200
        garp_master_delay 5 
        virtual_router_id 41 
        advert_int 1
        authentication {
            auth_type AH 
            auth_pass xxxx
        }
        virtual_ipaddress {
            192.168.100.1
            192.168.100.10
        }
    }
   ........
   ........

    

Answer 1

Você perguntou sobre comandos ou ferramentas para verificar o estado real de keepaived . Provavelmente, o melhor é usar:

tcpdump -i <interface> ‘ip proto 112’

Você deve ver mensagens periódicas do mestre para todos os IDs do roteador virtual (vrid no trave).

    

Answer 2

Eu tentei usar tcpdump -i <interface> 'ip proto 112' e descobri que, a menos que eu estivesse em um sistema keepalived, isso não seria visto. Eu tive que me tornar um membro do grupo multicast com ip maddr add <multicast address> antes do tcpdump relatar o multicast. Se você estiver usando unicast, isso não é um problema.

Desde a minha pergunta eu encontrei algumas coisas que podem ser úteis para os outros. Primeiro, minha experiência é que o keepalived começa no estado MASTER, independentemente da configuração e das transições, para o seu "estado estacionário" em poucos segundos. Isso é crítico se você estiver tentando executar scripts em mudanças de estado que afetam o sistema keepalived, você pode encontrar o script notify_master e o script "steady state notify _... executando simultaneamente e colidindo uns com os outros.

Em segundo lugar, em sistemas mais recentes, systemctl status keepalived pode mostrar estado se executado logo após uma mudança de estado (e os eventos intervenientes não "rolaram"). kill -USR1 <pid of keepalived> criará /tmp/keepalived.data que informa o estado do keepalived e isso é confiável se a execução após o "steady state" for atingida. Usar esse método foi minha solução para o problema do script colidindo - durma o tempo suficiente para atingir o estado estacionário e use kill ... , seguido pelo exame do arquivo.