Ubuntu-stock ldirectord не обрабатывает зависшие соединения с реальными серверами, или я неправильно его настроил?

Я использую его для балансировки и удаления отказавших экземпляров из кластера http / https, но заметил, что когда соединения с реальным сервером зависают, ldirectord никогда не отмечает их как неактивные, хотя он будет немедленно, если соединение отклонено или не может быть установлено, например, завершение работы экземпляра или остановка nginx.

В данном случае это небольшая проблема, потому что серверы являются облачными экземплярами, которые иногда полностью зависают и используют стек сервера приложений, который иногда запускает бесконечный цикл до перезапуска; Оба случая приводят к зависанию соединений.

Вот пример /etc/ha.d conf:

negotiatetimeout = 1
checkinterval = 1
quiescent = yes
fallback = 127.0.0.1
emailalert = "foo@example.com"

virtual = <vip 1>:80
    protocol = tcp
    scheduler = wlc
    real = <real ip 1>:80 ipip 5
    real = <real ip 2>:80 ipip 5
    [more reals]
    checktype = negotiate
    request = "/node-status"
    receive = "OK"

virtual = <vip 2>:443
    protocol = tcp
    scheduler = wlc
    real = <real ip 1>:443 ipip 5
    real = <real ip 2>:443 ipip 5
    [more reals]
    checktype = negotiate
    request = "/node-status"
    receive = "OK"

Один балансировщик - Ubuntu 10.10, другой - 10.04.2, ldirectord на обоих - 1,186 га.

Обратите внимание, этот поток 2002 года подразумевает, что ldirectord тогда не ловил зависшие соединения: http://archive.linuxvirtualserver.org/html/lvs-users/2002-05/msg00163.html

ОБНОВИТЬ

Обратите внимание, что указанные выше времена агрессивны, пока я пытаюсь решить эту проблему, обычно они выше и включают количество отказов, но я видел проблему как с настройками выше, так и ниже:

negotiatetimeout = 2
checkinterval = 2
failurecount = 5

Кроме того, в файлах журнала ldirectord нет записей, ведущих к или во время одного из этих «сбоев» на реальном сервере. Но если служба http или сам экземпляр выключен, когда он "завис", отображение ipvsadm и файлы журнала немедленно правильно показывают, что IP-адрес становится неактивным.

И когда я говорю «сервер завис», я имею в виду, что весь (облачный) экземпляр не отвечает, все попытки подключения в конечном итоге истекают по таймауту (ping, ssh, http, что угодно), и консоль тоже.

К сожалению, я не нашел первопричину любой из проблем (зависание сервера и бесконечный цикл стека), которые переводят сервер в такое состояние, поэтому я не могу (пока) воспроизвести ситуацию по запросу.