Проверка работоспособности HAProxy

В моей текущей настройке есть 2 HAProxy, настроенных с поддержкой активности для обеспечения высокой доступности, 2 прокси-сервера служат обратным прокси-сервером и балансировщиком нагрузки для виртуальных веб-сервисов. Я знаю, что HAProxy может проверять работоспособность своего бэкенда (я уже настроил это), но мой вопрос в другом.

В моей компании есть балансировщик нагрузки F5 Big-IP, который служит первой линией защиты и при необходимости перенаправляет запросы на мои HAProxy.

Мне нужно знать, есть ли способ позволить моему F5 Big-IP проверять работоспособность интерфейса HAProxy, чтобы при загрузке прокси никакие запросы не были потеряны.

Спасибо


frontend health-monitoring haproxy
person user3145921    schedule 07.05.2014    source источник

Ответы (3)


arrow_upward
12
arrow_downward

Раньше была опция mode health, но в последних версиях проще всего использовать monitor-uri для данного порта:

listen health_check_http_url
    bind :8888
    mode http
    monitor-uri /healthz
    option      dontlognull

Вы можете использовать monitor-uri во внешнем интерфейсе и также выбирать его с помощью ACL, но версия для переноса более понятна и понятна.

https://cbonte.github.io/haproxy-dconv/1.6/configuration.html#4.2-mode

https://cbonte.github.io/haproxy-dconv/1.6/configuration.html#4.2-monitor-uri

person Pau Ruŀlan Ferragut    schedule 03.08.2016

arrow_upward
4
arrow_downward

Из Справочного руководства по HAProxy:

Health-checking mode
--------------------
This mode provides a way for external components to check the proxy's health.
It is meant to be used with intelligent load-balancers which can use send/expect
scripts to check for all of their servers' availability. This one simply accepts
the connection, returns the word 'OK' and closes it. If the 'option httpchk' is
set, then the reply will be 'HTTP/1.0 200 OK' with no data, so that it can be
tested from a tool which supports HTTP health-checks. To enable it, simply
specify 'health' as the working mode :

Example :
---------
    # simple response : 'OK'
    listen health_check 0.0.0.0:60000
        mode health

    # HTTP response : 'HTTP/1.0 200 OK'
    listen http_health_check 0.0.0.0:60001
        mode health
        option httpchk
person guest666    schedule 09.05.2014
comment
В более поздней версии haproxy This mode is deprecated and should not be used anymore as it is possible to do the same and even better by combining TCP or HTTP modes with the "monitor" keyword. cbonte.github.io/haproxy-dconv /1.8/configuration.html#monitor - person nelaaro; 01.04.2019

arrow_upward
0
arrow_downward

Из документации HAProxy

Example:
frontend www
    mode http
    acl site_dead nbsrv(dynamic) lt 2
    acl site_dead nbsrv(static)  lt 2
    monitor-uri   /site_alive
    monitor fail  if site_dead

Ознакомьтесь со справочной документацией.

http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-monitor-uri

<uri>     is the exact URI which we want to intercept to return HAProxy's
          health status instead of forwarding the request.

When an HTTP request referencing <uri> will be received on a frontend,
HAProxy will not forward it nor log it, but instead will return either
"HTTP/1.0 200 OK" or "HTTP/1.0 503 Service unavailable", depending on failure
conditions defined with "monitor fail". This is normally enough for any
front-end HTTP probe to detect that the service is UP and running without
forwarding the request to a backend server. Note that the HTTP method, the
version and all headers are ignored, but the request must at least be valid
at the HTTP level. This keyword may only be used with an HTTP-mode frontend.

Monitor requests are processed very early. It is not possible to block nor
divert them using ACLs. They cannot be logged either, and it is the intended
purpose. They are only used to report HAProxy's health to an upper component,
nothing more. However, it is possible to add any number of conditions using
"monitor fail" and ACLs so that the result can be adjusted to whatever check
can be imagined (most often the number of available servers in a backend).
person nelaaro    schedule 01.04.2019