Я установил оставайся живым на двух межсетевых экранах для обеспечения аварийного переключения. Я не уверен, что следующие конфигурации верны (см. Конфигурации ниже).
Иногда у меня возникают проблемы с доступом к веб-сайтам, защищенным брандмауэрами. Я подозреваю, что когда оставайся живым работает на обоих брандмауэрах, в течение примерно одной минуты веб-сайты остаются недоступными ... затем соединение с веб-сайтами восстанавливается.
В чем может быть проблема? Неужели оставайся живым состояние переключения (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).