Haproxy (v2.0.3) с Keepalived (v2.0.7) в CentOS 7.5 возвращает пустой ответ с ошибкой для выбранных приложений

Question

Мы запускаем haproxy на двух непроизводственных серверах, сбалансированных по keepalived для управления аварийным переключением.

Недавно мы обновили haproxy 1.5 до 2.0.3. В нашей непроизводственной среде у нас никогда не было решения высокой доступности, поэтому мы решили запустить keepalived, чтобы обнаружить сбой / остановку haproxy и применить VIP к серверу резервного копирования.

Когда мы применили эти обновления, все работало очень хорошо... пока мы не заметили что-то в добавлении новых сайтов в фунт. Когда keepalived перезапускается (не перезагружается) и с новыми сайтами позади фунта новые сайты, кажется, работают хорошо на неопределенное время... затем они начинают возвращать "err_empty_response". Кажется, ничего не исправляет, пока keepalived не будет перезапущен, затем они снова будут работать неопределенное время и затем начнут возвращать "err_empty_response".

Сайт по-прежнему размечен на странице статистики.

Болезненно то, что вызовы перестают попадать в файл haproxy.log, что заставляет меня думать, что проблема не в (только) haproxy.

Что мы пробовали:

• Разделение каждой среды на собственный виртуальный интерфейс в keepalived.conf
• Обновление привязки api на внутреннем сервере к работающему api (чтобы исключить код api как вариант)
• Создание новой привязки с сокращенным URL-адресом
• Уменьшение таймаутов (клиент, сервер)

keepalived.conf:

`! Configuration File for keepalived

global_defs {
   notification_email {
     [e-mail]
   }
   notification_email_from [e-mail]
   smtp_server blah.mail.protection.outlook.com.
   smtp_connect_timeout 30
   router_id LVS_NONPROD
}

# Script used to check if HAProxy is running
vrrp_script check_haproxy {
  script "pidof haproxy"
  interval 2
  weight 2
}

vrrp_instance VI_DEV {
  state MASTER
  interface ens160
  virtual_router_id 52
  priority 101
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass 1111
  }
  virtual_ipaddress {
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
  }

  track_script {
    check_haproxy
  }

}

vrrp_instance VI_TEST {
  state MASTER
  interface ens160
  virtual_router_id 53
  priority 101
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass 1111
  }
  virtual_ipaddress {
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
  }

  track_script {
    check_haproxy
  }

}

vrrp_instance VI_UAT {
  state MASTER
  interface ens160
  virtual_router_id 54
  priority 101
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass 1111
  }
  virtual_ipaddress {
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
  }

  track_script {
    check_haproxy
  }

}

vrrp_instance VI_STAGING {
  state MASTER
  interface ens160
  virtual_router_id 55
  priority 101
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass 1111
  }
  virtual_ipaddress {
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
  }

  track_script {
    check_haproxy
  }

}

vrrp_instance VI_SS {
  state MASTER
  interface ens160
  virtual_router_id 56
  priority 101
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass 1111
  }
  virtual_ipaddress {
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
    xxx.xxx.xxx.xxx
  }

  track_script {
    check_haproxy
  }

}

vrrp_instance VI_NS {
  state MASTER
  interface ens160
  virtual_router_id 57
  priority 101
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass 1111
  }
  virtual_ipaddress {
    xxx.xxx.xxx.xxx
  }

  track_script {
    check_haproxy
  }

}`

глобалы haproxy:

`global
# to have these messages end up in /var/log/haproxy.log you will
# need to:
#
# 1) configure syslog to accept network log events.  This is done
#    by adding the '-r' option to the SYSLOGD_OPTIONS in
#    /etc/sysconfig/syslog
#
# 2) configure local2 events to go to the /var/log/haproxy.log
#   file. A line like the following can be added to
#   /etc/sysconfig/syslog
#
#    local2.*                       /var/log/haproxy.log
#
log         127.0.0.1 local2 debug

tune.chksize 32768 #don't get me started...dev requirement because of antiquated requirement not coded away
tune.bufsize 32768 #refer to previous statement
tune.ssl.default-dh-param 2048
max-spread-checks 20000
tune.maxpollevents 10000

chroot      /var/lib/haproxy
pidfile     /var/run/haproxy.pid
maxconn     40000
user        haproxy
group       haproxy
daemon

# turn on stats unix socket
stats socket /var/lib/haproxy/stats`

по умолчанию:

`defaults
mode                    http
log                     global
option                  httplog
option                  log-health-checks
option                  dontlognull
option                  http-server-close
option                  redispatch
retries                 3
timeout http-request    10s
timeout queue           60000
timeout connect         10s
timeout client          60000
timeout server          60000
timeout http-keep-alive 30s
timeout check           30s
maxconn                 30000
errorfile 503 /etc/haproxy/errorfiles/503.http`

Answer 1

Ответ был немного глупым. Внутренний DNS для балансировщика нагрузки был неправильным, поэтому удаленное подключение к нему было невозможно, пока я не попытался подключиться к машине по ssh в период, когда веб-сайт выдавал эти ошибки. Оказывается, старый балансировщик нагрузки имел IP-адреса как часть сетевых скриптов (т.е. /etc/sysconfig/network-scripts/ifcfg-eth0:0-20).

Итак, новые экземпляры будут работать, когда я перезапущу keepalived, потому что он будет принимать IP-адреса, а старый экземпляр забирает их обратно (впоследствии вызывая сбой, потому что в старом экземпляре нет записи).

Я остановил haproxy на старом экземпляре, удалил файлы /etc/sysconfig/network-scripts/ifcfg-eth0:* со старого сервера, перезапустил keepalived на новом кластере, и все работает как надо.

Чувствую себя немного глупо прямо сейчас.