Несколько экземпляров Haproxy - сервисные бэкэнды не стабилизируются в течение 5 минут - PullRequest
Новая
       38

Несколько экземпляров Haproxy - сервисные бэкэнды не стабилизируются в течение 5 минут

0 голосов
/ 28 июня 2019

Проблема:
При использовании SRV-записей в Haproxy бэкэнды несколько раз идут вниз и вверх, но не стабилизируются в течение 5 минут

Архитектура:
Облачный провайдер: AWS
Запуск нескольких (3) контейнеров Haproxy в ECS с ELB для распределения трафика между ними.
Я настроил бэкэнд Haproxy для работы с записями SRV для обнаружения служб
Я динамически хочу добавить службы (бэкэнды) в Haparoxy, поэтому я использую шаблон конфигурации и перезагружаю сокет.
Каждый сервис имеет 2 бэкэнда

Сценарий перезагрузки выглядит следующим образом: он генерирует шаблон и перезагружается при изменении шаблона: # новые службы не были добавлены, поэтому я не думаю, что сценарий перезагрузки имеет какое-либо отношение к проблеме 

#!/bin/bash
mkdir -p /var/PROJECT/services/
aws s3 cp s3://$BUCKET/services/services.json /var/PROJECT/services/
python3 /var/PROJECT/docker/generateHaproxyConfig.py >> /var/log/haproxy-gen.log
if ! diff -q /etc/haproxy/haproxy.cfg.new /etc/haproxy/haproxy.cfg &>/dev/null; then
    mv /etc/haproxy/haproxy.cfg.new /etc/haproxy/haproxy.cfg
    mkdir -p /etc/haproxy/states
    for b in $(socat /var/run/haproxy/socket - <<< "show backend" | fgrep -v '#')
    do
        socat /var/run/haproxy/socket - <<< "show servers state $b" > /etc/haproxy/states/$b
    done
    /etc/init.d/haproxy reload
fi

В моем тесте у меня запущена служба (06:49:14), затем она остановлена ​​(~ 06: 50: 00), а затем запущена через несколько секунд.

В логах HA1 мы видим, что сделали следующее:
1) был в 06:49:14
2) был ВНИЗ в 06:50:16
3) backend1 был UP в 06:51:17 # он должен был иметь оба backends UP здесь и не более DOWNs
4) backend1 ушел вниз в 06:51:58 # это неожиданно!
5) backend1 снова работает в 06: 52: 09
6) backend2 работает в 06:56:10 # почему это заняло так много времени?

Другие контейнеры имели похожее поведение

Записи SRV DNS выглядят так:
_test-git._tcp.staging.qa. SRV 1 1 32773 6c733da247894543afe5d11828751a05._test-git._tcp.staging.qa.
_test-git._tcp.staging.qa. SRV 1 1 32773 ec40447095d345069daf9ff7c0b6bd8c._test-git._tcp.staging.qa.
6c733da247894543afe5d11828751a05._test-git._tcp.staging.qa. 172.18.2.194
ec40447095d345069daf9ff7c0b6bd8c._test-git._tcp.staging.qa. 172.18.1.171

Шаблон конфигурации Haproxy: 

global
    log /dev/log    local0 info
    #log /dev/log   local1 info
    #log /dev/log   local2 info
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    pidfile /run/haproxy.pid

    stats socket /var/run/haproxy/socket
    server-state-base /etc/haproxy/states
    # stats socket /var/run/hapee-lb.sock mode 666 level admin
    # stats socket ipv4@127.0.0.1:9999 level admin
    stats timeout 30s
    daemon

    spread-checks 4
    tune.maxrewrite 1024
    # tune.ssl.default-dh-param 2048

resolvers awsdns
    nameserver default {{settings.NAMESERVER}}
    resolve_retries       3
    timeout resolve       3s
    timeout retry         3s
    hold other           30s
    hold refused         30s
    hold nx              1s
    hold timeout         30s
    hold valid           10s
    hold obsolete        30s

defaults
    log     global
    mode http
    balance roundrobin

    load-server-state-from-file local

    option httplog
    option dontlognull
    # option forwardfor except 127.0.0.0/8

    option  dontlog-normal
    option socket-stats
    # option forceclose
    option forwardfor if-none
    # option httpclose
    # option forceclose
    # option http-server-close
    option  redispatch

    retries 3

    maxconn 500000
    timeout connect 5s
    timeout client  300s
    timeout server  1h
    timeout queue   30s
    # timeout http-request 5s
    # timeout http-keep-alive 15s

frontend www-http
    bind 0.0.0.0:80
    # reqadd X-Forwarded-Proto:\ http
    acl is_valid_base_domain hdr_end(host) -i PROJECT.io

    # acl servers_alive nbsrv(www-backend-%[req.hdr(host),lower,field(1,'.')]) ge 1
    # use_backend www-backend-%[req.hdr(host),lower,field(1,'.')]-redirect if is_valid_base_domain !servers_alive
    use_backend www-backend-%[req.hdr(host),lower,field(1,'.')] if is_valid_base_domain
    use_backend www-health if !is_valid_base_domain

    default_backend www-backend

frontend stats
    bind *:1936
    mode http
    option httpclose
    stats enable
    stats uri /
    stats show-legends
    #stats show-desc
    stats show-node
    stats refresh 2

{% for service in services %}

backend www-backend-{{service.name}}
    option httpchk GET /health.php
    http-check expect string 1
    acl servers_alive nbsrv(www-backend-{{service.name}}) ge 1
    http-request redirect code 302 location https://{{settings.REDIRECT_HOST}}/site/{{service.id}}/launch?s_r_path=%[path]&s_r=1&%[query] if ! servers_alive
    server-template {{service.name}} 2 _{{service.name}}._tcp.{{settings.SERVICE_DISCOVERY_DOMAIN_NAME}} resolvers awsdns resolve-prefer ipv4 resolve-opts allow-dup-ip check
{% endfor %}


backend www-backend
    # errorfile 502 /var/PROJECT/lb/statuses/200.http
    # errorfile 503 /var/PROJECT/lb/statuses/200.http

backend www-health
    acl is_valid_base_domain hdr_end(host) -i PROJECT.io
    errorfile 502 /var/PROJECT/lb/statuses/200.http
    errorfile 503 /var/PROJECT/lb/statuses/200.http

Контейнеры журналов Haproxy: https://gist.github.com/amitaymolko/5865e9fdef6bf47ffc2323c813edd40d

РЕДАКТИРОВАТЬ: обновленный конфиг haproxy

1 Ответ

0 голосов
/ 30 июня 2019

Мое первоначальное предположение было бы, что это проблема DNS, может быть, вы кешировали "NXDOMAIN"? Попробуйте уменьшить TTL для staging.qa

...