☰

Как создать избыточные балансировщики нагрузки?

tag-icon • tag-icon nginx load-balancing redundancy load-balance
Как создать избыточные балансировщики нагрузки?

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

Я понимаю, что проверки работоспособности DNS могут быть полезны, но ведь существуют серьезные проблемы с задержками, не так ли?

Это предполагает, что вы не используете сторонние сервисы, такие как AWS ELB или что-то подобное. Что делать, если вы просто используете, скажем, Nginx?

решение1

Есть несколько способов достичь HA (высокой доступности) балансировщика нагрузки - или в этом отношении любой службы. Предположим, у вас есть две машины с IP-адресами:

  • 192.168.100.101
  • 192.168.100.102

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

Теперь вы можете выбрать службу HA, которая будет заботиться об автоматическом отказоустойчивом/возвратном отказе IP-адреса. Некоторые из самых простых служб для unix — это (u)carp и keepalived, некоторые из более сложных — например, RedHat Cluster Suite или Pacemaker.

Давайте возьмем keepalived в качестве примера — две службы keepalived — каждая из которых работает на своем собственном ящике — и они общаются друг с другом. Такое общение часто называют heartbeat.

|   VIP   |                           |         |
|  Box A  | ------v^-----------v^---- |  Box B  |
|   IP1   |                           |   IP2   |

Если один из keepalived перестает отвечать (либо служба отключается по какой-либо причине, либо ящик отключается или зависает) - keepalived на другом ящике заметит пропущенные сигналы и предположит, что другой узел мертв, и предпримет действия по отказу. В нашем случае это действие будет заключаться в подъеме плавающего IP.

                                      |   VIP   |
    ------------------ -------------- |  Box B  |
                                      |   IP2   |

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

Еще одна ловушка этой настройки — split brain — когда оба ящика находятся в сети, но связь разорвана, и оба ящика выдают один и тот же IP. Это часто решается с помощью какого-либо механизма ограждения (резервирование SCSI, перезапуск IPMI, отключение питания smart PDU, ...) или нечетного количества узлов, требующих, чтобы большинство членов кластера были активны для запуска службы.

|   VIP   |                           |   VIP   |
|  Box A  |                           |  Box B  |
|   IP1   |                           |   IP2   |

Более сложное программное обеспечение для управления кластером (такое как Pacemaker) может перемещать целые службы (например, останавливать их на одном узле и запускать на другом) — таким образом можно достичь высокой доступности для таких служб, как базы данных.

Другой возможный способ - если вы управляете маршрутизаторами рядом с вашими балансировщиками нагрузки, - использовать ECMP. Этот подход также позволяет вам горизонтально масштабировать балансировщики нагрузки. Это работает, когда каждый из ваших двух блоков связывается по BGP с вашим маршрутизатором(ами). Каждый блок должен рекламировать виртуальный IP (192.168.100.100), а маршрутизатор будет балансировать нагрузку трафика через ECMP. Если машина выходит из строя, она прекращает рекламировать VIP, что, в свою очередь, останавливает отправку трафика маршрутизаторами на нее. Единственное, о чем вам нужно позаботиться в этой настройке, - это прекратить рекламировать IP, если сам балансировщик нагрузки выходит из строя.

решение2

Использование Nginx в качестве балансировщика нагрузки позволит вам следовать перенаправлению, подробно описанному в этой статье, изменив конфигурацию для обнаружения тайм-аута отсутствия ответа:

nginx автоматическая балансировка нагрузки при отказе

Теоретически, если у вас среда высокой доступности, несколько балансировщиков нагрузки, объединенных в кластер, должны обеспечить поддержание работы сервиса в случае отказа одного из них.

Надеюсь это поможет.

решение3

Аппаратные балансировщики нагрузки поддерживают настройки "активный/пассивный" или "активный/активный" в течение многих лет, в обоих случаях они затем настраиваются параллельно с точки зрения уровня 1/2... активный/пассивный использует механизмы мониторинга/поддержки активности, как описано, активный/активный может быть реализован множеством способов. Чтобы выглядеть как один IP на фронтенде, два или более балансировщиков могут, пока они все/оба находятся в сети, делать что-то вроде:

  • выборочно отвечать на запросы ARP к общему IP-адресу на основе MAC-адреса или IP-адреса источника, когда клиенты находятся в одной сети
  • договариваются друг с другом, кто обрабатывает трафик данного нового TCP-соединения
  • позволять дублированному или ошибочному трафику уровней 3-7 происходить безрассудно и полагаться на стеки TCP клиента/маршрутизатора, чтобы разобраться с этим

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

на стороне бэкэнда:

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

Связанный контент