Я создал кластер с Corosync / Pacemaker. В кластере я настроил два ресурса, виртуальный IP и Squid. В кластере 2 узла работают на Debian 8.
crm_status
отображается, оба узла в сети, и все работает нормально.
В целях тестирования я остановил первый узел. CRM показывает, что ресурсы переместились на второй узел, но когда я использую виртуальный IP-адрес в браузере клиента, я не получаю ответа. В большинстве случаев требуется около 10 минут, прежде чем клиент сможет просматривать виртуальный IP-адрес через 2-й узел.
Я думаю (надеюсь), что это небольшая ошибка в конфигурации, но на данный момент я не знаю, где найти сбой. Вот мой конфиг:
Узлы
Node 1 Node 2
eth0 10.0.0.234 eth0 10.0.0.235
eth1 x.x.x.134 eth1 x.x.x.135
Virtual IP: 10.0.0.233
Corosync
totem {
version: 2
cluster_name: SQUID
token: 3000
token_retransmits_before_loss_const: 10
clear_node_high_bit: yes
crypto_cipher: aes256
crypto_hash: sha1
interface {
ringnumber: 0
bindnetaddr: x.x.x.0
mcastaddr: 239.255.1.1
mcastport: 5405
ttl: 1
}
}
logging {
fileline: off
to_stderr: no
to_logfile: no
to_syslog: yes
syslog_facility: daemon
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
expected_votes: 2
two_node: 1
}
Кардиостимулятор
primitive SQUID-IP IPaddr2 \
params ip=10.0.0.233 cidr_netmask=24 nic=eth0 \
op monitor interval=30s \
meta target-role=Started
primitive SQUID-Service Squid \
params squid_exe="/usr/sbin/squid3" squid_conf="/etc/squid3/squid.conf" squid_pidfile="/run/squid3.pid" squid_port=3128 squid_stop_timeout=10 debug_mode=v debug_log="/var/log/cluster.log" \
op start interval=0 timeout=60s \
op stop interval=0 timeout=120s \
op monitor interval=10s timeout=30s \
meta target-role=Started
colocation lb-loc inf: SQUID-IP SQUID-Service
order lb-ord inf: SQUID-IP SQUID-Service
property cib-bootstrap-options: \
have-watchdog=false \
dc-version=1.1.15-e174ec8 \
cluster-infrastructure=corosync \
cluster-name=Squid \
stonith-enabled=no \
no-quorum-policy=ignore
rsc_defaults rsc-options: \
resource-stickiness=200
Кальмар
#Networks
acl net_client src 192.168.1.0/24
acl net_cus src 10.0.200.0/24
#ACLs
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
#Rules
http_access deny !Safe_ports
http_access allow net_client
http_access allow net_cus
#http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny all
#Proxy Port
http_port 3128
#Cache Size
cache_mem 512 MB
#Cache Directory
cache_dir ufs /var/spool/squid3 100 16 256
#PID File
pid_filename /var/run/squid3.pid
#Cache Log
cache_log /var/log/squid3/cache.log
#Leave coredumps in the first cache dir
coredump_dir /var/spool/squid3
# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
#Notification Address
cache_mgr my@address.com
Проблема заключалась в интервале ARP-кеширования / обновления на промежуточном межсетевом экране. После перенастройки аварийное переключение работает должным образом.