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

Медленное переключение при отказе в кластере кальмаров

Я создал кластер с 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-кеширования / обновления на промежуточном межсетевом экране. После перенастройки аварийное переключение работает должным образом.