Параметры фермы HAProxy SSL

Кайл,

Если вам нужна только отработка отказа для части SSL, а не балансировка нагрузки, вот что я предлагаю. Вы устанавливаете haproxy + keepalived + stunnel (пропатченный) на два узла. Keepalived владеет адресом службы и проверяет наличие процессов stunnel и haproxy, чтобы вычислить его вес, чтобы узел в наилучшей форме стал ведущим. Stunnel принимает трафик на порт 443 и локально перенаправляет его на haproxy на любой порт, который вам нравится. Чтобы haproxy регистрировал IP-адрес клиента, вам понадобится патч x-forwarded-for для stunnel (вы можете найти его на моем сайте). Затем вы скажете haproxy, чтобы он регистрировал заголовок x-forwarded-for.

Однако есть ограничение. Если вы поддерживаете HTTP keep-alive, то stunnel добавит заголовок x-forwarded-for только один раз, что немного проблематично. В Exceliance мы начали работу над патчем для пересылки параметров подключения от stunnel к haproxy вместо того, чтобы играть с x-forwarded-for. Таким образом, haproxy считает, что он получает соединение от реального клиента. Если вам интересно, скажите мне, мы отправим его вам, когда он будет готов.

Хорошо, я вижу это довольно поздно, но как насчет:

      VLAN1         VLAN2

INET -- | -- [SSL] -- | -- [HTTP Load Balancer]
        |             |
        | -- [SSL] -- | -- [WEB01]
        |             |
        | -- [SSL] -- | -- [WEB02]
                      |
                      | -- [WEB03] etc

В словах:

• Простой циклический перебор DNS для публикации Икс IP-адреса для службы,
• С интерфейсными SSL-прокси (Apache, nginx), отвечающими напрямую на эти IP-адреса. (Необязательно, но рекомендуется, с чем-то вроде VRRP, CARP или Linux-HA, чтобы обеспечить высокую доступность для этих IP-адресов.)
• Все SSL-прокси отправляют свои запросы однорукому балансировщику нагрузки (для простоты настройки, единая точка управления LB / сеансом),
• И, наконец, LB отправляет запрос на серверы веб-приложений.

Выскакивает пара вещей:

• HAProxy и SSL-прокси (nginx) довольно близки по функциям и модели использования в этой архитектуре. Есть ли другие требования к простой балансировке нагрузки HTTP (ограничение скорости упоминалось в другом месте)? Если нет, то было бы проще пропустить HAProxy и использовать только один тип веб-сервера для всей обработки SSL и LB (например, nginx).
• Циклический перебор DNS, вероятно, «достаточно хорош» для простого распределения нагрузки по 2-3 SSL-прокси. Но если не нравится, то можно использовать механизмы L4.

Получите журнал HTTP, в котором указаны фактические IP-адреса клиентов.

Предполагая, что первое устройство уровня HTTP добавляет заголовок X-FORWARDED-FOR, и вы используете что-то вроде чего-то вроде этот или F5's Плагины IIS, это должно работать.