Я наблюдаю очень странное поведение HAProxy. У меня есть следующая настройка, которая позволяет example.com/wiki перейти на один сервер, а example.com/ - на другой. Проблема в том, что похоже, что / wiki работает только половину времени, а / webserver работает только половину времени. При ближайшем рассмотрении кажется, что он переключается между двумя бэкэндами; возможно, их балансировка нагрузки вместо перехода к определенному бэкэнду на основе правил ACL!
Еще одна странность заключается в том, что и services-staging.example.com/greenoven, и staging.example.com перейдут в kumquat, хотя в правилах конкретно сказано, что только хост, размещающий сервисы, должен переходить к этому бэкэнду.
Что-то не так с моей конфигурацией HAProxy? Я неправильно использую acls или бэкенды?
global
log 127.0.0.1 local1 debug
maxconn 200000
chroot /var/lib/haproxy
user haproxy
group haproxy
daemon
#debug
#quiet
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
maxconn 200000
contimeout 5000
clitimeout 50000
srvtimeout 50000
stats uri /monitor
stats auth admin:GS01
stats refresh 5s
stats enable
frontend http-in
bind *:80
option forwardfor
#Staging Hosts
acl host_staging hdr(host) -i staging.example.com
acl host_staging_services hdr(host) -i staging-services.example.com
#Production Hosts
acl host_prod hdr(host) -i example.com www.example.com
acl host_prod_services hdr(host) -i services.urbanatla.com
#URL Paths
acl url_wiki url_beg /wiki
acl url_go url_beg /greenoven
acl url_arcgis url_beg /ArcGIS
#Staging Backends
use_backend pluto if host_staging_services url_arcgis
use_backend kumquat if host_staging_services url_go
use_backend kumquat if host_staging url_wiki
use_backend cumberland if host_staging
#Production Backends
use_backend saturn if host_prod_services url_arcgis
use_backend willow if host_prod_services url_go
use_backend willow if host_prod url_wiki
use_backend ganges if host_prod
backend kumquat
server kumquat kumquat.example.com:8080 maxconn 5000
backend cumberland
server cumberland cumberland.example.com:80 maxconn 5000
backend ganges
server ganges ganges.example.com:80 maxconn 5000
backend articdata
server articdata articdata.example.com:80 maxconn 5000
backend saturn
server saturn saturn.example.com:80 maxconn 5000
backend willow
server willow willow.example.com:8080 maxconn 5000
backend pluto
server pluto pluto.example.com:80 maxconn 5000
Похоже, он повторно использовал соединения, чего не следует делать при переключении контекста. Я добавил следующее:
option httpclose
за это сообщение: Почему я получаю ошибки в моей конфигурации переключения содержимого HAProxy?.
Все URL-адреса и домены теперь работают правильно.
Если вы читаете в хапрокси документация, вы можете найти этот абзац:
hdr(name) The HTTP header <name> will be looked up in each HTTP request.
Just as with the equivalent ACL 'hdr()' function, the header
name in parenthesis is not case sensitive. If the header is
absent or if it does not contain any value, the roundrobin
algorithm is applied instead.
Это может объяснить, почему haproxy выполняет балансировку нагрузки между серверами, которые не следуют спискам ACL. Чтобы убедиться, вам нужно убедиться, что вы действительно получаете запрос с host
заголовок.
Я думаю, вы можете использовать IP-адрес назначения, имя или URL-адрес вместо проверки host
заголовок.