Haproxy перед лаком или наоборот?

Я могу представить две установки:

Баланс нагрузки, затем кеш

                          +-- Cache server #1 (varnish) -- App server #1
                         /
Load Balancer (haproxy)-+---- Cache server #2 (varnish) -- App server #2
                         \
                          +-- Cache server #3 (varnish) -- App server #3

Кэш, затем баланс нагрузки

                                                       +-- App server #1
                                                      /
Cache Server (varnish) --- Load Balancer (haproxy) --+---- App server #2
                                                      \
                                                       +-- App server #3

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

Проблема со второй настройкой заключается в том, что может быть удар по производительности и две одиночные точки отказа (лак и haproxy) вместо одного (haproxy)?

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

Ответ 1

Я построил аналогичную установку несколько лет назад для загруженного веб-приложения (только я сделал это с Squid вместо Varnish), и это получилось хорошо.

Я бы рекомендовал использовать вашу первую настройку (HAProxy → Varnish) с двумя модификациями:

Добавьте дополнительный HAProxy-сервер, используя keepalived и общий виртуальный IP
Используйте алгоритм балансировки нагрузки balance uri для оптимизации просмотров кеша

Плюсы:

Душа спокойствия с избыточностью HAProxy (x2) и лаком (x3)
Лучшая эффективность эффективности использования лака с использованием параметра HAProxy URI для балансировки нагрузки
Лучшая производительность от кеш-серверов, так как им не нужно хранить столько в памяти
Недействительный кеш проще, поскольку один и тот же URI будет переходить на один и тот же сервер каждый раз

Минусы:

Балансировка URI работает хорошо, но если сервер кэша будет работать, ваши серверные серверы будут удалены, так как другие серверы кеширования, которые забирают слабину из обновленного хэш-кода балансировки URI, должны будут повторно извлекать кэшированные данные, Возможно, это не большой конфликт, но я должен был помнить об этой системе.

Ответ 2

Оба имеют плюсы и минусы. Подробнее в статье в блоге ниже, включая конфигурацию для HAProxy и Varnish: http://blog.exceliance.fr/2012/08/25/haproxy-varnish-and-the-single-hostname-website/

Батист

Ответ 3

Конечно, первый!

С HAProxy настроен для балансировки на основе URI. (Вы должны распространять свой сеанс пользователя приложения, если у вас есть режимы, отличные от IP-балансировки).

Особенно, если вам нужна конечная точка HTTPS, так как Varnish не говорит HTTPS.

Ответ 4

Почему бы не использовать 2 LB, первый LB может использовать опцию balance uri, второй LB может использовать стратегию по вашему выбору (рабочая нагрузка, круговая анимация)

          +-- Cache Server #1 --+                +-- App server #1
         /                       \              /
LB #1 --+                         + -- LB #2 --+---- App server #2
         \                       /              \
          +-- Cache Server #2 --+                +-- App server #3

Масштаб, где вам нужно, только сколько вам нужно. Если вы обнаружите, что не используете узлы Cache, просто удалите LB # 1 и поместите только один сервер кэша впереди.