Назад | Перейти на главную страницу

keepalived: 2-й VRRP_Script никогда не запускается

Я пытаюсь реализовать keepalived на 3-х ящиках mongodb, идея состоит в том, что если mongod на одном из ящиков выходит из строя или нам нужно переместить основной узел в другую систему, по какой-то причине наше приложение не нужно перенастраивать.

Keepalived.conf довольно прост, есть 2 VRRP_scripts, один для проверки работы mongod, а другой предназначен для выполнения сценария bash, который проверяет, является ли локальный экземпляр mongod основным узлом.

keepalived.conf

!Configuration File for keepalived

# Global definitions
    global_defs {
        notification_email {
            myemail@myserver.com
    }
        notification_email_from mongodbtest@myserver.com
        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
    }
}

Если я отключу службу mongod на узле, плавающий IP-адрес перейдет в другое поле, как и ожидалось, я увижу такой вывод в / 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

Если я верну mongod обратно, IP вернется в этот ящик (так как он имеет приоритет).

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

Обратите внимание на VRRP_Script (chk_mongod) в каждом выводе журнала, когда mongod отключается и возвращается обратно. Однако, если я перенастрою набор реплик так, что этот узел больше не является основным, я никогда не увижу, что мой VRRP_Script с именем chk_mongod_primary работает успешно или не работает. Я протестировал сценарий из командной строки, и он каждый раз возвращает ожидаемый результат, но, похоже, он никогда не выполняется с помощью collectd.

Вот как выглядит /usr/local/bin/chk_mongo_primary.sh:

#!/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

Я пробовал разные вещи и смотрел другие конфигурации keepalived, чтобы понять, смогу ли я выяснить, где я делаю ошибку, но это меня озадачило.

Может ли кто-нибудь подсказать, где я ошибаюсь?

Заранее спасибо.

Это решено, проблема заключалась в жирном имени скрипта в разделе track_script файла conf. Это было решено с помощью команды keepalived --dump-conf, которая проанализировала файл конфигурации и выдала результаты. Я просмотрел / var / log / messages и обнаружил ошибку, связанную с отсутствием скрипта трека.