Load Balancers. Часть 3.

Load Balancers. Часть 3.

https://t.me/faangmaster

Предыдущие части:

Часть 2: https://telegra.ph/Load-Balancers-Vvedenie-CHast-2-iz-3-05-16

Часть 1: https://telegra.ph/Load-Balancers-Vvedenie-CHast-1-iz-3-05-15

Consistent Hashing: https://telegra.ph/Consistent-Hashing-05-22

Алгоритмы балансировщиков нагрузки

Балансировщики нагрузки распределяют клиентские запросы в соответствии с некоторыми алгоритмами. Некоторые известные алгоритмы приведены ниже:

1) Round-robin: в этом алгоритме каждый запрос пересылается на сервер из реестра доступных серверов повторяющимся последовательным образом. Вначале запрос отправляется на первый сервер, потом на второй, и т.д. Когда список сервером закончится, то снова на первый.

2) Weighted round-robin: если некоторые серверы имеют более высокую производительность, то предпочтительно использовать weighted round-robin. В weighted round-robin каждому серверу присваивается вес. LB пересылают запросы клиентов в соответствии с весом сервера. Чем выше вес, тем больше количество запросов.

3) Least connections: в некоторых случаях, даже если все серверы имеют одинаковую производительность, неравномерная нагрузка на некоторые серверы все же возможна. Например, у некоторых клиентов может быть запрос, который требует больше времени для обслуживания. Или у некоторых клиентов могут быть последующие запросы по тому же соединению. В этом случае мы можем использовать такие алгоритмы, как наименьшее количество соединений, когда новые поступающие запросы назначаются серверам с меньшим количеством существующих соединений. LB сохраняют состояние количества и сопоставления существующих соединений в таком сценарии.

4) Least response time: в сервисах, чувствительных к производительности, требуются такие алгоритмы, как наименьшее время отклика. Этот алгоритм гарантирует, что для обслуживания клиентов запрашивается сервер с наименьшим временем отклика.

5) IP hash: некоторые приложения предоставляют пользователям разный уровень обслуживания в зависимости от их IP-адресов. В этом случае выполняется хеширование IP-адреса для назначения запросов пользователей серверам. В таком случае, запросы с одного и того же IP будут отправляться на один и тот же сервер.

6) URL hash: возможно, что некоторые службы в приложении предоставляются только определенными серверами. В этом случае клиент, запрашивающий услугу по URL-адресу, назначается определенному кластеру или набору серверов. В этих сценариях используется алгоритм хеширования URL-адресов.

Существуют и другие алгоритмы, такие как алгоритмы рандомизированных или взвешенных least connections.

Статические и динамические алгоритмы

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

1) Статические алгоритмы не учитывают изменение состояния серверов. Поэтому балансировка осуществляется на основе имеющихся знаний о конфигурации серверов.

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

Динамические алгоритмы отслеживают работоспособность серверов и перенаправляют запросы только на активные серверы.

На практике, динамические алгоритмы дают гораздо лучшие результаты, поскольку они знают состояние всех серверов.

Stateful and stateless LB

Stateful LB

Stateful LB позволяют поддерживать сессию между пользователем и сервером. Все запросы в рамках одной сессии будут отправлятся на один и тот же сервер.


Stateless LB

Stateless не поддерживают отправления сессий на один и тот же сервер. Они обычно используют Consistent Hashing для мапинга клиентов и серверов. Смотрите мою статью по Consistent Hashing: https://telegra.ph/Consistent-Hashing-05-22


Network and Application Level LBs

1) Network LB. Работают на уровне 4 модели OSI (Транспортный уровень). Это уровень работы TCP/UDP. Они позволяют устанавляивать и поддерживать TCP соединения и ганрантировать, что все коммуникации по установлению TCP соединения будут отправлятся на один и тот же сервер.

2) Application LB. Соответствуют уровню 7 модели OSI (Прикладной). Работает на уровне HTTP. Могут балансировать запросы на основе HTTP headers, cookies, URLs, userIds и т.д. Также обычно выполняют TLS Termination.

Совместная работа множества LB

На практике, в больших высоконагруженных сервисах используют комбинацию LB: ECMP (equal cost multipath), Network и Application LBs.

Можно считать, что DNS это балансировка нулевого уровня. Далее следуют ECMP балансировщики, которые раутят запросы используя, например round-robin, weighted round-robin или на основе IP. Это балансировка первого уровня. Далее следуют Network LB, которые гарантируют, что все запросы в рамках установления TCP соединения будут отправлены на один и тот же Application LB. Это достигается благодаря Consistent Hashing. Network LB в такой структуре можно считать LB второго уровня. И последний уровень это Application LB, которые шифруют и дешифруют трафик (TLS Termination), раутят уже дешифрованный трафик на сервера в соответствии с прикладным уровнем логики, например, на основе hash(URL).


Hardware and Software LB

Аппаратные балансировщики нагрузки (Hardware LB)

Балансировщики нагрузки были представлены в 1990-х годах как аппаратные устройства. Аппаратные балансировщики нагрузки работают как автономные устройства и стоят довольно дорого. Тем не менее, они имеют свои преимущества в производительности и могут обрабатывать множество одновременных пользователей. Настройка аппаратных решений проблематична, поскольку требует дополнительных человеческих ресурсов. Аппаратные LB могут иметь более высокие затраты на обслуживание и проблемы совместимости, что делает их менее гибкими.

Программные балансировщики нагрузки (Software LB)

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

Report Page