Назад | Перейти на главную страницу

HAProxy, похоже, балансирует нагрузку, а не следует правилам ACL

Я наблюдаю очень странное поведение 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 заголовок.