Он отлично работает до тех пор, пока удаленный сервер не станет на какое-то время недоступен. В этом случае сервер отключается в журналах и больше не запускается. Конфиг довольно прост:
defaults
retries 3
timeout connect 5000
timeout client 3600000
timeout server 3600000
log global
option log-health-checks
listen amazon_ses
bind 127.0.0.2:1234
mode tcp
no option http-server-close
default_backend bk_amazon_ses
backend bk_amazon_ses
mode tcp
no option http-server-close
server amazon email-smtp.us-west-2.amazonaws.com:587 check inter 30s fall 120 rise 1
Вот журналы, когда возникает проблема:
Jul 3 06:45:35 jupiter haproxy[40331]: Health check for server bk_amazon_ses/amazon failed, reason: Layer4 timeout, check duration: 30004ms, status: 119/120 UP.
Jul 3 06:46:35 jupiter haproxy[40331]: Health check for server bk_amazon_ses/amazon failed, reason: Layer4 timeout, check duration: 30003ms, status: 118/120 UP.
Jul 3 06:47:35 jupiter haproxy[40331]: Health check for server bk_amazon_ses/amazon failed, reason: Layer4 timeout, check duration: 30002ms, status: 117/120 UP.
...
Jul 3 08:44:36 jupiter haproxy[40331]: Health check for server bk_amazon_ses/amazon failed, reason: Layer4 timeout, check duration: 30000ms, st
atus: 0/1 DOWN.
Jul 3 08:44:36 jupiter haproxy[40331]: Server bk_amazon_ses/amazon is DOWN. 0 active and 0 backup servers left. 0 sessions active, 0 requeued,
0 remaining in queue.
Jul 3 08:44:36 jupiter haproxy[40331]: backend bk_amazon_ses has no server available!`
И это все. Ничего, кроме ручной перезагрузки сервера (перезагрузка сервиса haproxy на FreeBSD) возвращает сервер к жизни. Я также попытался удалить контрольную часть и то, что за ней следует - все равно происходит то же самое. Нельзя настроить haproxy так, чтобы он пытался бесконечно долго не отмечать сервер как ВЫКЛЮЧЕННЫЙ? Спасибо.
Вы пробовали использовать меньшие таймауты? Также используя что-то вроде этого? \
server amazon email-smtp.us-west-2.amazonaws.com:587 check inter 5s fall 3 rise 2
Также попробуйте добавить эти параметры в свой бэкэнд:
mode tcp
option tcplog
option log-health-checks
а затем еще раз проверьте свои журналы haproxy, посмотрите, получите ли вы дополнительную информацию.
Вы также можете попробовать вручную из коробки haproxy подключиться к этому серверу через порт 587 и посмотреть, сможете ли вы подключиться, когда haproxy сообщает, что он не работает? Если вы не можете подключиться через telnet, то для haproxy вполне нормально сообщить об этом.
Есть ли ограничение скорости, брандмауэр или любая другая подобная конфигурация на вашем SMTP-сервере, которая может заблокировать сервер haproxy?