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

Циклический алгоритм (Round Robin)

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

Взвешенный циклический алгоритм (Weighted Round Robin)

Этот алгоритм решает недостатки простого алгоритма кругового обслуживания (round-robin): входящие запросы распределяются по порядку между серверами кластера, но учитываются веса, заранее назначенные каждому серверу. Администратор просто определяет вес каждого сервера исходя из его вычислительной мощности. Например, самому мощному серверу A назначается вес 100, а наименее мощному серверу — вес 50. Это означает, что прежде чем сервер B получит свой первый запрос, сервер A получит 2 последовательных запроса, и так далее.

Наименьшее количество соединений

Ни один из двух вышеперечисленных методов не учитывает, что система не может определить, сколько соединений поддерживается в данный момент времени. Поэтому может случиться так, что сервер B получает меньше соединений, чем сервер A, но уже перегружен, потому что пользователи на сервере B дольше удерживают свои соединения открытыми. То есть количество соединений, т. е. нагрузка на сервер, накапливается. Этой потенциальной проблемы можно избежать с помощью алгоритма «Наименьшее количество соединений» (Least Connection): входящие запросы распределяются в соответствии с количеством соединений, открытых в данный момент на каждом сервере. То есть сервер с наименьшим числом активных соединений автоматически получает следующий входящий запрос. Основной принцип тот же, что и у простого кругового алгоритма: все серверы с виртуальными службами должны иметь сходную ресурсную ёмкость. Стоит отметить, что в конфигурациях с низким трафиком трафик на каждом сервере не одинаков, и первый сервер будет предпочтительнее. Это связано с тем, что если все серверы идентичны, первый сервер получает приоритет; до тех пор, пока на первом сервере есть непрерывный активный трафик, иначе первым всегда будет выбираться первый сервер.

Время медленного старта для алгоритма наименьшего количества соединений

Для методов планирования «наименьшее число соединений» и «взвешенное наименьшее число соединений», когда сервер только что добавлен в производственную среду, для него можно настроить период времени. В течение этого периода число соединений ограничено и увеличивается медленно. Это обеспечивает серверу «переходное время», чтобы гарантировать, что он не будет перегружен сразу после запуска из-за слишком большого числа назначенных соединений. Это значение задаётся в интерфейсе конфигурации L7.

Взвешенное наименьшее число соединений

Если серверы имеют разные ресурсные возможности, метод «Взвешенное наименьшее число соединений» подходит больше. Число активных соединений, определяемое весами, настроенными администратором с учётом состояния серверов, обычно обеспечивает очень сбалансированное использование серверов, поскольку сочетает преимущества как наименьшего числа соединений, так и взвешивания. Как правило, это очень справедливый метод распределения, потому что он использует отношение числа соединений к весу сервера; сервер с наименьшим отношением в кластере автоматически получает следующий запрос. Однако обратите внимание: при использовании этого метода в условиях низкого трафика учитывайте предостережения из метода «Наименьшее число соединений».

Адаптивная балансировка на основе агента

В дополнение к вышеперечисленным методам, балансировщик нагрузки содержит адаптивную логику для периодического мониторинга состояния серверов и весов этих серверов. Для очень мощного метода «Agent Based Adaptive Balancing» балансировщик нагрузки периодически проверяет нагрузку всех серверов следующим образом: каждый сервер должен предоставить файл, содержащий число от 0 до 99, которое указывает фактическую нагрузку этого сервера (0 = простаивает, 99 = перегружен, 101 = отказал, 102 = отключен администратором), и сервер получает этот файл через HTTP GET; в то же время для серверов в кластере предоставление собственной нагрузки в виде двоичного файла также является одной из задач сервера. Однако нет ограничений на то, как серверы вычисляют собственную нагрузку. Исходя из общей нагрузки серверов, можно выбрать две стратегии: при нормальной работе алгоритм планирования вычисляет весовое соотношение на основе отношения между собранным значением нагрузки сервера и количеством соединений, назначенных этому серверу. Следовательно, если сервер перегружен, его вес будет прозрачно скорректирован системой. Как и в методе взвешенного кругового планирования, неправильные распределения могут быть зафиксированы, чтобы разным серверам можно было эффективно назначать разные веса. Однако в среде с очень низким трафиком значения нагрузки, сообщаемые серверами, не образуют репрезентативную выборку; распределение нагрузки на основе этих значений приведет к потере управления и колебаниям команд. Поэтому в этом случае более разумно рассчитывать распределение нагрузки на основе статических весовых коэффициентов. Когда нагрузка всех серверов ниже нижнего предела, заданного администратором, балансировщик нагрузки автоматически переключается на взвешенное круговое планирование запросов; если нагрузка превышает нижний предел, заданный администратором, балансировщик нагрузки возвращается в адаптивный режим.

Фиксированное взвешивание

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

Взвешенный отклик

Планирование трафика осуществляется посредством взвешенного кругового обслуживания. Веса, используемые при взвешенном круговом обслуживании, рассчитываются на основе времени отклика проверок доступности серверов. Во время каждой проверки доступности замеряется время, чтобы зафиксировать, сколько времени потребовалось для успешного ответа. Однако обратите внимание, что этот метод предполагает, что проверки Heartbeat серверов основаны на скорости машины, но это предположение не всегда может быть верным. Суммарное время отклика всех серверов в виртуальном сервисе складывается, и это значение используется для расчёта веса отдельного физического сервера; это значение веса рассчитывается примерно каждые 15 секунд.

Хеш исходного IP-адреса

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

Источник: http://www.codeceo.com/article/balanced-algorithm.html