Failover lento no cluster do Squid

1

Eu criei um cluster com o Corosync / Pacemaker. No cluster eu configurei dois recursos, um IP virtual e um Squid. Existem 2 nós no cluster trabalhando no Debian 8.

crm_status é exibido, os dois nós estão on-line e tudo funciona bem.

Para fins de teste, parei o nó um. O CRM mostra que os recursos migraram para o segundo nó, mas quando uso o IP virtual em um navegador de clientes, não obtenho resposta. Na maioria das vezes, leva cerca de 10 minutos, até que o cliente possa navegar com o IP virtual pelo segundo nó.

Eu acho que (espero) é uma pequena configuração errada, mas neste momento eu não sei onde localizar o fracasso. Aqui está minha configuração:

Nós

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
}

Marcapasso

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

Lula

#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 [email protected]
    
por Cpt.Captain 09.05.2017 / 16:10

1 resposta

0

O problema era o intervalo de atualização / cache ARP em um firewall intermediário. Depois de reconfigurar o failover, funcione conforme pretendido.

    
por 10.05.2017 / 12:22