Конфигурации Keepalived

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

Иногда у меня есть проблемы для достижения веб-сайтов, которые находятся позади брандмауэров. Я подозреваю, что, когда keepalived работает на обоих брандмауэрах, сроком на приблизительно одну минуту, веб-сайты остаются недостижимыми.. затем соединение с веб-сайтами восстанавливается.

Какова могла быть проблема? Может случиться так, что keepalived переключают состояние (ВЕДУЩЕЕ УСТРОЙСТВО или ВЕДОМОЕ УСТРОЙСТВО) постоянно?

Брандмауэр 2 выполнения в ОСНОВНОМ состоянии. Когда keepalived запускается на брандмауэре 1, он вскакивает в Состояние резервирования.

Есть ли команды или инструменты как ipvsadm проверять реальное состояние keepalived?

Конфигурация keepalived.conf на 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
        }
    }
..........
..........
..........

Конфигурация keepalived.confна брандмауэре 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
        }
    }
   ........
   ........
1
задан 1 August 2014 в 15:06
2 ответа

Я попытался использовать tcpdump -i 'ip proto 112' и обнаружил, что, если я не использую систему поддержки активности, этого не будет видно. Мне пришлось стать членом группы многоадресной рассылки с ip maddr add <адрес многоадресной рассылки> , прежде чем tcpdump сообщит о многоадресной рассылке. Если вы используете одноадресную рассылку, это не проблема.

После моего вопроса я нашел кое-что, что может быть полезно другим. Во-первых, мой опыт показывает, что keepalived запускается в состоянии MASTER независимо от конфигурации и переходит в «устойчивое состояние» за несколько секунд. Это очень важно, если вы пытаетесь запустить сценарии при изменении состояния, которое влияет на систему поддержки активности, вы можете обнаружить, что и notify_master, и сценарий notify _... в «устойчивом состоянии» работают одновременно и конфликтуют друг с другом.

Во-вторых, в более новых системах systemctl status keepalived может отображать состояние, если выполняется достаточно скоро после изменения состояния (а промежуточные события не «прокручивают» его). kill -USR1 создаст /tmp/keepalived.data, который сообщает о состоянии keepalived, и это надежно, если запускается после достижения "устойчивого состояния". Использование этого метода было моим решением проблемы столкновения скриптов - спите достаточно долго для достижения устойчивого состояния, а затем используйте kill ... с последующим изучением файла.

0
ответ дан 4 December 2019 в 08:34

Вы спрашивали о командах или инструментах для проверки реального состояния keepaived .
Вероятно, лучше всего использовать:

tcpdump -i <interface> ‘ip proto 112’

Вы должны видеть периодические сообщения от мастера для всех идентификаторов виртуальных маршрутизаторов (vrid in the trave).

0
ответ дан 4 December 2019 в 08:34

Теги

Похожие вопросы