Я пытаюсь выполнить настройку haproxy с одним внешним VIP-сервером и двумя внутренними веб-серверами. Я хочу, чтобы бэкэнд был активным / пассивным, чтобы все запросы отправлялись на сервер №1, если сервер №1 не отключен, а затем отправлялись на сервер №2. Когда сервер №1 оживает, оставайтесь на сервере №2, пока сервер №2 не выйдет из строя.
Я следовал приведенному ниже руководству, используя приставные таблицы для реализации, и он работал, но теперь, похоже, он остановился, и я не знаю почему. Когда я выхожу из строя сервер, он правильно отправляется в резервную копию, но когда отказавший сервер возвращается в оперативный режим, он отправляет трафик на только что исправленный сервер вместо того, чтобы оставаться на резервной копии.
https://www.haproxy.com/blog/emulating-activepassing-application-clustering-with-haproxy/
сервер. Это означает, что если вы хотите разделить клиента ...
Я использую HAProxy 1.8.17. Вот очищенная копия haproxy.cfg. Любые идеи??
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
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
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
tune.ssl.default-dh-param 2048
# turn on stats unix socket
stats socket /var/lib/haproxy/stats mode 600 level admin
stats timeout 2m
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000
#---------------------------------------------------------------------
# Load Balancer Stick-Table Sync
#---------------------------------------------------------------------
peers lb_peers
peer lb1 10.255.0.4:9969
peer lb2 10.255.0.5:9969
#---------------------------------------------------------------------
# Stats interface
#---------------------------------------------------------------------
listen stats
bind 10.255.0.3:8080
mode http
log global
maxconn 10
timeout client 100s
timeout server 100s
timeout connect 100s
timeout queue 100s
stats enable
stats hide-version
stats refresh 30s
stats show-node
stats auth <REMOVED>
stats uri /haproxy?stats
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend solarwinds_http_fe
mode http
bind 10.255.0.3:80
http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
default_backend solarwinds_be
frontend solarwinds_https_fe
mode http
bind 10.255.0.3:443 ssl crt /etc/ssl/solarwinds/solarwinds.pem
http-request set-header X-Forwarded-Proto https if { ssl_fc }
default_backend solarwinds_be
#---------------------------------------------------------------------
# Active/Passive backend
#---------------------------------------------------------------------
backend solarwinds_be
stick-table type ip size 1 nopurge peers lb_peers
stick on dst
redirect scheme https if !{ ssl_fc }
option httpchk HEAD /Orion/Login.aspx HTTP/1.1\r\nHost:\ <REMOVED>
server bru-monweb01 10.255.0.6:80 check fall 3 fastinter 5s downinter 5s rise 6
server bru-monweb02 10.255.0.7:80 check fall 3 fastinter 5s downinter 5s rise 6 backup
Я не использовал одноранговые узлы и столкнулся с той же проблемой на Haproxy 1.9.7. Я исправил это, изменив строку из запись в блоге который не привязан к IP-адресу назначения, а является целым числом в своем примере MySQL:
backend mybackend
stick-table type integer size 1k nopurge
stick on int(1)
# the rest of the backend definition
Изменение вместо указания size так как 1, Я использовал 1k.
Здесь есть руководство:
https://www.haproxy.com/blog/introduction-to-haproxy-stick-tables/
Пример конфигурации:
backend mysql
mode tcp
stick-table type integer size 1 expire 1d
stick on int(1)
server primary 192.168.122.60:3306 check on-marked-down shutdown-sessions
server backup 192.168.122.61:3306 check backup on-marked-down shutdown-sessions
В этой конфигурации мы храним только одну запись в таблице стикеров, где ключ равен 1, а значение - server_id активного сервера. Теперь, если основной сервер выйдет из строя, server_id резервного сервера перезапишет значение в таблице флешек, и все запросы будут продолжать поступать в резервную копию, даже если мастер снова вернется в оперативный режим. Это можно отменить, переключив узел резервного копирования в режим обслуживания или с помощью API среды выполнения, когда вы будете готовы возобновить нормальную работу кластера.