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

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

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

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

В чем может быть проблема? Неужели оставайся живым состояние переключения (MASTER или SLAVE) постоянно?

Firewall-2 работает в состоянии MASTER. Когда Keepalived запускается firewall-1 он переходит в состояние BACKUP.

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

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

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

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

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

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

tcpdump -i <interface> ‘ip proto 112’

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