keepalived: o segundo VRRP_Script nunca parece rodar

Question

Estou tentando implementar keepalived em 3 caixas mongodb, a idéia é que se mongod em uma das caixas for desativado ou precisarmos mover o nó primário para outro sistema por alguma razão, nosso aplicativo não precisa ser reconfigurado.

O keepalived.conf é bem simples, existem 2 VRRP_scripts, um para verificar se o mongod está sendo executado e o outro que deve executar um script bash que verifica se a instância do mongod local é o nó primário.

keepalived.conf

!Configuration File for keepalived

# Global definitions
    global_defs {
        notification_email {
            [email protected]
    }
        notification_email_from [email protected]
        smtp_server smtprelay.penton.com
        smtp_connect_timeout 30
}

# Check to see if mongod is running
vrrp_script chk_mongod {
        script "killall -0 mongod"      # verify the pid exists
        interval 2                      # check every 2 seconds
        # weight 2                        # add 2 points if OK
}

# Check to see if this node is the primary
vrrp_script chk_mongod_primary {
    script "/usr/local/bin/chk_mongo_primary.sh"
    interval 2
    # weight 2
}

# Virtual interface configuration
vrrp_instance VI_1 {
    state MASTER
    interface eth0                  #interface to monitor
    virtual_router_id 51
    priority 101                    # 101 on mater, 100 on backup

    virtual_ipaddress {
            192.168.122.99
    }

    track_script {
            chk_mongod
            chk_mongo_primary
    }
}

Se eu desligar o serviço mongod em um nó, o IP flutuante mudará para outra caixa, como eu esperaria ver a saída como esta em / var / log / messages

Jul 17 16:23:34 mongodbtest01 Keepalived_vrrp[30304]: VRRP_Script(chk_mongod) failed
Jul 17 16:23:35 mongodbtest01 Keepalived_vrrp[30304]: VRRP_Instance(VI_1) Entering FAULT STATE
Jul 17 16:23:35 mongodbtest01 Keepalived_vrrp[30304]: VRRP_Instance(VI_1) removing protocol VIPs.
Jul 17 16:23:35 mongodbtest01 Keepalived_vrrp[30304]: VRRP_Instance(VI_1) Now in FAULT state
Jul 17 16:23:35 mongodbtest01 Keepalived_healthcheckers[30303]: Netlink reflector reports IP 192.168.122.99 removed

Se eu trouxer o mongod de volta, o IP voltará para essa caixa (já que tem prioridade).

Jul 17 16:27:42 mongodbtest01 Keepalived_vrrp[30304]: VRRP_Script(chk_mongod) succeeded
Jul 17 16:27:43 mongodbtest01 Keepalived_vrrp[30304]: VRRP_Instance(VI_1) prio is higher than received advert
Jul 17 16:27:43 mongodbtest01 Keepalived_vrrp[30304]: VRRP_Instance(VI_1) Transition to MASTER STATE
Jul 17 16:27:44 mongodbtest01 Keepalived_vrrp[30304]: VRRP_Instance(VI_1) Entering MASTER STATE
Jul 17 16:27:44 mongodbtest01 Keepalived_vrrp[30304]: VRRP_Instance(VI_1) setting protocol VIPs.
Jul 17 16:27:44 mongodbtest01 Keepalived_vrrp[30304]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.122.99

Observe o VRRP_Script (chk_mongod) em cada saída de log quando o mongod é desativado e retorna. Se, no entanto, eu reconfigurar o conjunto de réplicas de modo que esse nó não seja mais primário, nunca verei que o meu VRRP_Script chamado chk_mongod_primary é executado com êxito ou falha. Eu testei o script a partir da linha de comando e ele retorna o resultado esperado a cada vez, mas nunca parece ser executado por collectd.

Isto é o que /usr/local/bin/chk_mongo_primary.sh se parece com:

#!/bin/bash
    # Check to see if this node is master
    result=$(mongo --eval "printjson(db.isMaster().ismaster)" 2>&1)
    m_status='echo $result | cut -d' ' -f 8'

    if [ "$m_status" == "true" ] ;
    then
            echo "I am primary"
            exit 0
    else
            echo "I am secondary"
            exit 1
    fi

Eu tentei várias coisas e olhei para outras configurações de keepalive para ver se eu poderia descobrir onde estou indo errado, mas isso me deixou perplexo.

Alguém pode fornecer pistas sobre onde estou indo errado?

Obrigado antecipadamente.

    

Answer 1

Isso está resolvido, o problema era um nome de script com dedos gordos na seção track_script do arquivo conf. Isso foi resolvido executando keepalived --dump-conf, que analisou o arquivo de configuração e gerou os resultados. Eu segui / var / log / messages e encontrei um erro referente a um script de trilha ausente.