Я установил 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
}
}
........
........
Я попытался использовать tcpdump -i
и обнаружил, что, если я не использую систему поддержки активности, этого не будет видно. Мне пришлось стать членом группы многоадресной рассылки с ip maddr add <адрес многоадресной рассылки>
, прежде чем tcpdump сообщит о многоадресной рассылке. Если вы используете одноадресную рассылку, это не проблема.
После моего вопроса я нашел кое-что, что может быть полезно другим. Во-первых, мой опыт показывает, что keepalived запускается в состоянии MASTER независимо от конфигурации и переходит в «устойчивое состояние» за несколько секунд. Это очень важно, если вы пытаетесь запустить сценарии при изменении состояния, которое влияет на систему поддержки активности, вы можете обнаружить, что и notify_master, и сценарий notify _... в «устойчивом состоянии» работают одновременно и конфликтуют друг с другом.
Во-вторых, в более новых системах systemctl status keepalived
может отображать состояние, если выполняется достаточно скоро после изменения состояния (а промежуточные события не «прокручивают» его). kill -USR1
создаст /tmp/keepalived.data, который сообщает о состоянии keepalived, и это надежно, если запускается после достижения "устойчивого состояния". Использование этого метода было моим решением проблемы столкновения скриптов - спите достаточно долго для достижения устойчивого состояния, а затем используйте kill ...
с последующим изучением файла.
Вы спрашивали о командах или инструментах для проверки реального состояния keepaived
.
Вероятно, лучше всего использовать:
tcpdump -i <interface> ‘ip proto 112’
Вы должны видеть периодические сообщения от мастера для всех идентификаторов виртуальных маршрутизаторов (vrid in the trave).