Load balancer

Что такое балансировка нагрузки?

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

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

Балансировщик нагрузки (Load Balancer, LB) — это решение этой задачи. Работа балансировщика нагрузки заключается в том, чтобы справедливо разделить все запросы клиентов между пулом доступных серверов. Балансировщики нагрузки выполняют эту задачу, чтобы избежать перегрузки или отказа серверов.

Слой балансировки нагрузки является первой точкой контакта в дата-центре после межсетевого экрана. Балансировщик нагрузки может не требоваться, если сервис обрабатывает всего несколько сотен или даже тысяч запросов в секунду. Однако для увеличения количества клиентских запросов балансировщики нагрузки предоставляют следующие возможности:

• Масштабируемость - Scalability: Добавляя серверы, можно бесшовно увеличивать пропускную способность приложения/сервиса. Балансировщики нагрузки делают такое увеличение или уменьшение масштабов прозрачным для конечных пользователей.
• Доступность - Availability: Даже если некоторые серверы выходят из строя или сталкиваются с неисправностью, система остается доступной. Одна из задач балансировщиков нагрузки — скрывать сбои серверов.
• Производительность - Performance: Балансировщики нагрузки могут перенаправлять запросы на серверы с меньшей нагрузкой, чтобы пользователь мог получить более быстрое время отклика. Это не только улучшает производительность, но и повышает эффективность использования ресурсов.

Вот абстрактное представление того, как работают балансировщики нагрузки:

Размещение балансировщиков нагрузки

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

Рассмотрим три известных группы серверов: веб-серверы, серверы приложений и серверы баз данных. Чтобы распределить нагрузку трафика между доступными серверами, балансировщики нагрузки можно использовать между экземплярами серверов этих трех служб следующим образом:

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

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

Услуги, предоставляемые балансировщиками нагрузки

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

• Проверка работоспособности (Health checking): Балансировщики нагрузки используют протокол heartbeat для мониторинга состояния и надежности конечных серверов. Еще одно преимущество проверки работоспособности — улучшенный пользовательский опыт.
  Протокол Heartbeat — это способ выявления сбоев в распределенных системах. Используя этот протокол, каждый узел в кластере периодически сообщает о своем состоянии службе мониторинга.
• Завершение TLS (TLS termination): Балансировщики нагрузки снижают нагрузку на конечные серверы, обрабатывая завершение TLS с клиентом.
• Прогнозная аналитика (Predictive analytics): Балансировщики нагрузки могут предсказывать шаблоны трафика через аналитику, выполненную по трафику, проходящему через них, или используя статистику трафика, полученную с течением времени.
• Сокращение вмешательства человека (Reduced human intervention): Благодаря автоматизации балансировщиков нагрузки требуется меньше усилий по администрированию системы для устранения сбоев.
• Обнаружение служб (Service discovery): Одно из преимуществ балансировщиков нагрузки заключается в том, что запросы клиентов перенаправляются на соответствующие хостинг-серверы путем запроса реестра служб.
• Безопасность (Security): Балансировщики нагрузки могут также повысить безопасность, смягчая атаки, такие как атаки типа "отказ в обслуживании" (Denial of Service, DoS) на различных уровнях модели OSI (уровни 3, 4 и 7).

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

---

Вопрос для оценки понимания

What if load balancers fail? Are they not a single point of failure (SPOF)?

Load balancers are usually deployed in pairs as a means of disaster recovery. If one load balancer fails, and there’s nothing to failover to, the overall service will go down. Generally, to maintain high availability, enterprises use clusters of load balancers that use heartbeat communication to check the health of load balancers at all times. On failure of primary LB, the backup can take over. But, if the entire cluster fails, manual rerouting can also be performed in case of emergencies.

---

Global and Local Load Balancing

Введение

Могло показаться, что балансировка нагрузки выполняется только в пределах дата-центра. Однако балансировка нагрузки требуется как на глобальном, так и на локальном уровнях. Давайте рассмотрим функции каждой из этих двух форм балансировки:

• Global server load balancing (GSLB): GSLB включает распределение трафика между несколькими географическими регионами.
• Local load balancing: Это относится к балансировке нагрузки, достигаемой внутри дата-центра. Этот тип балансировки нагрузки фокусируется на повышении эффективности и улучшении использования ресурсов хостинг-серверов в дата-центре.

Давайте разберем каждую из этих двух техник ниже.

Global Server Load Balancing (GSLB)

GSLB обеспечивает интеллектуальное перенаправление глобального трафика на дата-центр. Например, в случае сбоя питания или сети в одном из дата-центров весь трафик необходимо перенаправить в другой дата-центр. GSLB принимает решения о перенаправлении на основе географического расположения пользователей, количества хостинг-серверов в различных местах, состояния дата-центров и так далее.

В следующем уроке мы также узнаем, как GSLB предлагает автоматический переход на резервную зону (zonal failover). Сервис GSLB может быть установлен на территории компании или получен через Load Balancing as a Service (LBaaS).

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

Теперь мы обсудим, как система доменных имен (DNS) может выполнять GSLB.

Балансировка нагрузки в DNS

Мы уже знаем, что DNS может отвечать несколькими IP-адресами на один DNS-запрос. В уроке о DNS мы обсуждали, что балансировку нагрузки можно выполнять через DNS, рассматривая вывод команды nslookup. DNS использует простой метод перестановки списка IP-адресов в ответ на каждый DNS-запрос. Таким образом, разные пользователи получают список IP-адресов в разном порядке, что приводит к тому, что пользователи обращаются к разным серверам для обработки своих запросов. Таким образом, DNS распределяет нагрузку запросов между разными дата-центрами. Это и есть выполнение глобальной балансировки нагрузки (GSLB). В частности, DNS использует метод round-robin для выполнения балансировки нагрузки, как показано ниже:

На изображении показан процесс, который включает два ключевых шага:

1. Запрос к DNS для получения IP-адреса: Когда пользователь (например, кто-то из пользователей ISP 4) хочет получить доступ к определенному веб-сайту, его устройство сначала отправляет запрос к DNS-серверу. Этот запрос представляет собой запрос на определение IP-адреса для доменного имени, которое пользователь ввел в браузере (например, "example.com"). DNS-инфраструктура отвечает на этот запрос, предоставляя IP-адрес сервера, который обслуживает этот домен.

2. Перенаправление запроса к серверу (дата-центру): После того как устройство пользователя получило IP-адрес от DNS, оно использует этот IP-адрес для отправки HTTP-запроса непосредственно на сервер (или дата-центр), который расположен по этому IP-адресу. Запрос попадает в дата-центр, где расположен веб-сайт, и сервер в этом дата-центре отвечает пользователю, предоставляя запрашиваемый контент (например, веб-страницу).

Таким образом, на схеме показано, как DNS-инфраструктура помогает пользователю получить правильный IP-адрес, а затем пользователь отправляет запрос непосредственно на сервер в дата-центре, чтобы получить доступ к контенту.

Как показано выше, алгоритм round-robin (циклическое распределение) в DNS направляет клиентов в дата-центры в строгом круговом порядке. Однако у round-robin есть следующие ограничения:

1. Различное количество пользователей у разных ISP (интернет-провайдеров): Интернет-провайдеры, обслуживающие большее количество клиентов, будут предоставлять тем же самым IP-адресам (которые они закэшировали) большому числу пользователей. Это может привести к неравномерному распределению нагрузки на конечные серверы.

2. Игнорирование сбоев конечных серверов: Поскольку алгоритм round-robin не учитывает сбои серверов, он продолжает распределять IP-адреса сломанных серверов до тех пор, пока не истечет время жизни (TTL) закэшированных записей. В результате этого, доступность сервиса может ухудшиться из-за балансировки нагрузки на уровне DNS.

Несмотря на свои ограничения, round-robin все еще широко используется многими провайдерами DNS. Кроме того, DNS использует короткие значения TTL для закэшированных записей, чтобы эффективно балансировать нагрузку между различными дата-центрами.

Примечание: DNS — это не единственный способ глобальной балансировки нагрузки (GSLB). Контроллеры доставки приложений (ADCs) и облачные средства балансировки нагрузки (обсуждаются позже) представляют собой более эффективные методы реализации GSLB.

Контроллеры доставки приложений (ADCs)

Контроллеры доставки приложений (ADCs) являются частью сети доставки приложений (ADN). Их можно рассматривать как надмножество балансировщиков нагрузки (LBs), предлагающих различные услуги, включая балансировку нагрузки. Основная задача ADCs — это ускорение веб-приложений для снижения нагрузки на серверный кластер. Некоторые известные сервисы, работающие на уровнях 3-7 модели OSI, включают кэширование, SSL-отгрузку, прокси/реверс-прокси услуги, оптимизацию IP-трафика и многое другое. ADCs также реализуют глобальную балансировку нагрузки (GSLB).

Необходимость в локальных балансировщиках нагрузки

DNS играет важную роль в балансировке нагрузки, однако он страдает от следующих ограничений:

1. Малый размер DNS-пакета (512 байт): Этот размер недостаточен для включения всех возможных IP-адресов серверов.
2. Ограниченный контроль над поведением клиента: Клиенты могут произвольно выбирать IP-адрес из полученного набора. Некоторые из полученных IP-адресов могут принадлежать загруженным дата-центрам.
3. Клиенты не могут определить ближайший адрес для установления соединения: Хотя можно реализовать решения на основе геолокации DNS и anycasting, они не являются тривиальными.
4. Медленное восстановление в случае сбоев: Из-за механизма кэширования, особенно когда значения TTL (времени жизни записи) велики, восстановление через DNS может быть медленным.

Для решения некоторых из вышеупомянутых проблем нам нужен еще один уровень балансировки нагрузки в виде локального балансировщика нагрузки (local LB). В следующем уроке мы обсудим различные детали о локальных балансировщиках нагрузки.

Что такое локальная балансировка нагрузки?

Локальные балансировщики нагрузки находятся внутри дата-центра. Они работают как обратный прокси и стараются максимально эффективно распределять входящие запросы среди пула доступных серверов. Входящие запросы клиентов бесшовно подключаются к LB, который использует виртуальный IP-адрес (VIP).

Can DNS be considered a global server load balancer (GSLB)?
Yes, there are actually two ways of doing global traffic management (GTM):

GTM through ADCs: Some ADCs implement GSLB. In that case, ADCs have a real-time view of the hosting servers and forward requests based on the health and capacity of the data center.
GTM through DNS: DNS does GSLB by analyzing the IP location of the client. For each user requesting IP for a domain name (for example, www.educative.io), DNS-based GSLB forwards the IP address of the data center geographically closer to the requesting IP location.

Advanced Details of Load Balancers

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

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

Round-robin Scheduling (Циклическое распределение)

В этом алгоритме каждый запрос последовательно перенаправляется на сервер из пула по кругу.

Weighted Round-robin (Взвешенное циклическое распределение)

Если некоторые серверы имеют большую способность обслуживать клиентские запросы, предпочтительно использовать взвешенный алгоритм round-robin. В этом алгоритме каждому узлу присваивается вес. Балансировщики нагрузки перенаправляют запросы клиентов в соответствии с весом узла. Чем выше вес, тем больше запросов направляется на этот узел.

Least Connections (Минимум соединений)

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

Least Response Time (Минимальное время отклика)

В сервисах, чувствительных к производительности, требуются такие алгоритмы, как least response time. Этот алгоритм гарантирует, что запросы клиентов будут направлены на сервер с минимальным временем отклика.

IP Hash (Хэширование IP)

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

URL Hash (Хэширование URL)

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

Существуют и другие алгоритмы, такие как random (случайное распределение) или weighted least connections (взвешенное минимальное количество соединений).

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

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

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

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

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

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

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

Таблица статических и динамических алгоритмов балансировки нагрузки

Категория	Алгоритм	Описание
Статические алгоритмы	Round-robin scheduling	Каждый запрос последовательно направляется на сервер из пула, повторяясь по кругу.
	Weighted round-robin	Серверы с большей мощностью получают больше запросов благодаря весам, назначаемым каждому серверу.
	IP hash	Маршрутизация запросов основана на хэшировании IP-адресов клиентов, что позволяет всегда направлять запросы от одного IP-адреса на один сервер.
	URL hash	Запросы, поступающие с определенных URL, направляются на конкретные серверы, используя хэширование URL для маршрутизации.
Динамические алгоритмы	Least connections	Новые запросы направляются на серверы с наименьшим количеством активных соединений, учитывая текущее состояние серверов.
	Least response time	Запросы направляются на серверы с наименьшим временем отклика, что улучшает производительность системы.
	Weighted least connections	Запросы распределяются с учетом как количества соединений на сервере, так и веса, который показывает его мощность.
	Dynamic Round-robin	Расширенная версия Round-robin, которая учитывает текущее состояние серверов при распределении запросов.

Статические и динамические алгоритмы отвечают за распределение входящих запросов между серверами в зависимости от выбранной стратегии балансировки нагрузки. Вот их основные функции:

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

• Распределение запросов по заранее определенной схеме: Статические алгоритмы распределяют запросы на основе фиксированной логики, которая не учитывает текущее состояние серверов.
• Простота и легкость реализации: Они обычно проще в реализации, поскольку не требуют мониторинга состояния серверов.
• Меньшая гибкость: Поскольку статические алгоритмы не адаптируются к изменяющимся условиям (например, загрузке серверов), они могут не быть оптимальными в условиях динамически изменяющихся нагрузок.

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

• Распределение запросов с учетом текущего состояния серверов: Динамические алгоритмы учитывают текущее состояние серверов (например, количество активных соединений или время отклика) при принятии решений о распределении запросов.
• Гибкость и адаптивность: Эти алгоритмы способны более эффективно распределять нагрузку в условиях изменяющихся условий, обеспечивая лучшую производительность и устойчивость системы.
• Сложность: Динамические алгоритмы сложнее в реализации, так как требуют постоянного мониторинга и обмена информацией между серверами для принятия решений.

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

Stateful и Stateless балансировщики нагрузки

Хотя статические и динамические алгоритмы должны учитывать состояние хостинг-серверов, необходимо поддерживать состояние, чтобы удерживать информацию о сессиях различных клиентов с хостинг-серверами.

Если информация о сессиях не хранится на нижнем уровне (распределённый кеш или база данных), балансировщики нагрузки используются для хранения информации о сессиях. Ниже описаны два способа управления сессиями через балансировщики нагрузки:

Stateful Load Balancing

Как следует из названия, stateful load balancing (с сохранением состояния) включает в себя поддержание состояния сессий, установленных между клиентами и хостинг-серверами. Stateful балансировщик нагрузки включает информацию о состоянии в свой алгоритм для выполнения балансировки нагрузки.

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

Stateful Load Balancing управляет состоянием сессии между клиентом и сервером, но это не обязательно означает, что состояние сессии записывается в базу данных. В контексте stateful load balancing состояние сессии обычно хранится на самом балансировщике нагрузки или распределяется между несколькими балансировщиками.**

Как работает Stateful Load Balancing:

1. Сохранение сессии: Stateful Load Balancing отслеживает активные сессии между клиентом и сервером. Это означает, что каждый раз, когда клиент отправляет запрос, балансировщик знает, к какому серверу этот запрос должен быть направлен, основываясь на предыдущих запросах в рамках той же сессии.

2. Связь клиента с сервером: Сессия привязывается к конкретному серверу, и все запросы в рамках одной сессии направляются на один и тот же сервер. Это полезно, когда сессия требует поддержания непрерывного состояния (например, корзина покупок в интернет-магазине).

3. Завершение сессии: Сессия заканчивается, когда клиент отключается или когда балансировщик решает завершить сессию, например, после определенного периода бездействия.

Stateless Load Balancing

Stateless load balancing (балансировка нагрузки без сохранения состояния) не поддерживает состояние и, следовательно, является более быстрым и легковесным. Stateless балансировщики нагрузки используют consistent hashing (консистентное хэширование) для принятия решений о маршрутизации. Однако, если инфраструктура изменяется (например, добавляется новый сервер приложения), stateless балансировщики нагрузки могут быть не столь устойчивыми, как stateful, потому что одного только консистентного хэширования может быть недостаточно для маршрутизации запроса к правильному серверу приложения. Поэтому, несмотря на использование консистентного хэширования, может потребоваться локальное состояние.

Stateless Load Balancing не сохраняет информацию о предыдущих запросах и сессиях клиента. Каждый запрос обрабатывается независимо от других, без сохранения состояния. Это делает такой подход проще и масштабируемее, но менее гибким в некоторых сценариях.

Как работает Stateless Load Balancing:

1. Отсутствие сохранения состояния: В отличие от stateful подхода, stateless load balancer не запоминает, какой сервер обслуживал предыдущие запросы клиента. Каждый новый запрос рассматривается как абсолютно независимый.

2. Распределение запросов: Запросы распределяются между серверами на основе предопределенного алгоритма (например, round-robin, least connections, или consistent hashing), но без учета предыдущих взаимодействий.

3. Consistent Hashing: Один из методов, используемых в stateless load balancing. Этот алгоритм распределяет запросы таким образом, что один и тот же клиентский IP-адрес всегда направляется на один и тот же сервер, что помогает сохранить некоторую предсказуемость в распределении запросов.

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

Преимущества и недостатки:

• Преимущества:

  • Простота и легкость масштабирования.
  • Устойчивость к отказам, так как нет зависимости от сохраненного состояния.

• Недостатки:

  • Не подходит для приложений, которые требуют сохранения состояния между запросами (например, e-commerce корзины).
  • Может потребоваться дополнительная логика на уровне приложений для управления состоянием.

Правила записи сессий в базу данных и их связь с балансировщиками нагрузки

Stateful Load Balancing и сессии

Stateful Load Balancing сохраняет информацию о сессиях между клиентом и сервером. Это позволяет балансировщику нагрузки учитывать состояние при распределении последующих запросов клиента к тому же серверу, с которым он уже взаимодействовал.

Как происходит сохранение сессий:

• Хранение состояния сессий: Когда клиент устанавливает сессию с сервером, информация о сессии (например, идентификатор сессии, данные пользователя) сохраняется в базе данных или другом устойчивом хранилище.
• Обслуживание запросов: При поступлении нового запроса от того же клиента, балансировщик нагрузки использует сохраненное состояние, чтобы направить запрос к тому же серверу, с которым клиент уже взаимодействовал.
• Завершение сессии: Когда клиент завершает работу с приложением (например, выходит из системы), сессия обычно закрывается, и сохраненные данные могут быть удалены из базы данных.

Используемые подходы:

• Сессионные базы данных: Специализированные базы данных для хранения информации о сессиях. Эти данные могут быть централизованными (в одной базе данных) или распределёнными по нескольким серверам.
• Кеширование сессий: В некоторых случаях данные сессий могут кешироваться для более быстрого доступа, а затем синхронизироваться с базой данных.

Stateless Load Balancing и сессии

Stateless Load Balancing не сохраняет информацию о сессиях на уровне балансировщика. Однако запись сессий в базу данных также возможна и при использовании Stateless Load Balancing.

Как это работает:

• Сохранение сессий на стороне сервера: В этом случае данные сессий могут храниться непосредственно на серверах приложений или в централизованной базе данных.
• Использование хранилищ сессий: Например, сессионные данные могут сохраняться в Redis или Memcached, что позволяет серверам быстро восстанавливать сессии по идентификатору сессии, даже если запросы обрабатываются разными серверами.

Примеры:

• Redis и Memcached часто используются для хранения сессионных данных в распределённых системах, что позволяет сохранять состояние при высокой производительности.

---

Вопрос для оценки понимания

Having familiarized yourself with load balancers, consider a scenario where you deploy a website that serves static content, such as text and images. Would you choose a stateful or stateless load balancer, and why?

---

Types of Load Balancers

В зависимости от требований, балансировка нагрузки может выполняться на транспортном и прикладном уровнях модели OSI (open systems interconnection).

Layer 4 Load Balancers

Layer 4 относится к балансировке нагрузки, которая выполняется на основе транспортных протоколов, таких как TCP и UDP. Эти типы балансировщиков нагрузки поддерживают соединение/сессию с клиентами и гарантируют, что одно и то же (TCP/UDP) соединение будет передано на один и тот же сервер. Хотя завершение TLS сессий обычно происходит на Layer 7 балансировщиках, некоторые балансировщики Layer 4 также поддерживают эту функцию.

Layer 7 Load Balancers

Layer 7 балансировщики нагрузки принимают решения о перенаправлении на основе данных прикладных протоколов. Они могут принимать решения, учитывая HTTP-заголовки, URL-адреса, cookies и другие данные, специфичные для приложений, например, идентификатор пользователя. Помимо выполнения завершения TLS, эти балансировщики могут брать на себя такие задачи, как ограничение скорости пользователей, HTTP-маршрутизация и переписывание заголовков.

Note: Layer 7 балансировщики более "умны" с точки зрения анализа данных, однако Layer 4 балансировщики быстрее в обработке запросов.

Load Balancer Deployment

Мы обсудили компромиссы балансировки нагрузки на разных уровнях OSI. Однако на практике одного уровня балансировщика недостаточно для крупного дата-центра. На самом деле, несколько уровней балансировщиков нагрузки координируются для принятия информированных решений о перенаправлении. Традиционный дата-центр может иметь трехуровневую схему балансировки нагрузки, как показано ниже:

Tier-0 и Tier-1 Load Balancers

Если рассматривать DNS как балансировщик нагрузки уровня Tier-0, то маршрутизаторы с Equal Cost Multipath (ECMP) можно считать балансировщиками уровня Tier-1. Из названия ECMP ясно, что этот уровень делит входящий трафик на основе IP или какого-то другого алгоритма, например, round-robin или взвешенного round-robin. Tier-1 LBs будут распределять нагрузку по разным путям к балансировщикам более высоких уровней.

Маршрутизаторы ECMP играют важную роль в горизонтальном масштабировании балансировщиков нагрузки более высокого уровня.

Tier-2 Load Balancers

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

Tier-2 Load Balancers можно считать связующим звеном между Tier-1 и Tier-3 LBs. Исключение балансировщиков Tier-2 может привести к ошибочным решениям о перенаправлении в случае сбоев или динамического масштабирования LBs.

Tier-3 Load Balancers

Layer 7 LBs предоставляют услуги на уровне Tier 3. Поскольку эти балансировщики находятся в прямом контакте с бэкенд-серверами, они осуществляют мониторинг состояния серверов на уровне HTTP. Этот уровень обеспечивает масштабируемость, равномерно распределяя запросы между набором здоровых бэкенд-серверов, и предоставляет высокую доступность, непосредственно контролируя состояние серверов. Этот уровень также снижает нагрузку на конечные серверы, обрабатывая низкоуровневые детали, такие как протоколы управления перегрузками TCP, обнаружение MTU пути (максимальной единицы передачи), различия в прикладных протоколах между клиентом и бэкенд-серверами и т. д. Идея заключается в том, чтобы оставить вычисления и обработку данных на серверах приложений, а балансировку нагрузки на простые задачи передать машинам общего назначения. В некоторых случаях Layer 7 LBs находятся на одном уровне с хостами сервиса.

Итог

Tier 1 балансирует нагрузку между самими балансировщиками нагрузки. Tier 2 обеспечивает плавный переход от Tier 1 к Tier 3 в случае сбоев, тогда как Tier 3 выполняет фактическую балансировку нагрузки между бэкенд-серверами. Каждый уровень выполняет и другие задачи, чтобы снизить нагрузку на конечные серверы.

Практический пример

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

Разбор иллюстрации шаг за шагом:

1. R1: Запрос R1 поступает через один из маршрутизаторов ECMP (балансировщики нагрузки уровня Tier-1).

2. Маршрутизация через ECMP: Маршрутизаторы ECMP перенаправляют R1 на один из трех доступных балансировщиков нагрузки уровня Tier-2, используя алгоритм round-robin. Балансировщики уровня Tier-2 хешируют IP-адрес источника (например, IPc) и перенаправляют пакет на следующий уровень балансировщиков нагрузки.

3. Tier-3 LBs: После получения пакета балансировщики уровня Tier-3 снимают шифрование TLS и читают данные HTTP(S). Наблюдая за запрашиваемым URL, балансировщик перенаправляет запрос на сервер, обрабатывающий запросы для слайдов.

4. R2: Запрос R2 проходит по тому же пути, но попадает на другой конечный сервер, так как запрашиваемый URL содержит документ, а не слайды. Балансировщики уровня Tier-3 предварительно настроены для перенаправления запросов на серверы приложений на основе данных приложения. Например, типичный сервер HAProxy может иметь следующую конфигурацию на уровне Tier-3 LBs.

mode HTTP                               //define which mode the LB will work on, TCP for tier-2 LBs
acl slidesApp path_end -i /presentation //define a category of applications if the path ends in /presentation
use_backend slidesServers if slidesApp  // use a set of backend servers if the request arrives for slidesApp
backend slidesServers                   // listing servers serving slidesApp
server slides1 192.168.12.1:80          //using slides1 server to serve slidesApp.

---

Вопрос для оценки понимания

After a request reaches a back-end server, should the response be routed back through each tier of the load balancers?

No, the server can send the response directly to the routers (tier-1 LBs) through tier-3 LBs, which can forward the response from the data center. Such a response is called direct routing (DR) or direct server return (DSR).

DR/DSR is typically used for non-HTTPS traffic because when TLS termination is involved, responses need to be encrypted before reaching the client, requiring them to pass back through the Layer 7 load balancer for encryption.

---

Реализация балансировщиков нагрузки

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

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

Аппаратные балансировщики нагрузки были впервые представлены в 1990-х годах как автономные устройства. Эти устройства работают как отдельные устройства и довольно дорогостоящи. Однако они имеют свои преимущества в производительности и способны обрабатывать большое количество одновременных пользователей. Конфигурация аппаратных решений проблематична, поскольку требует дополнительных человеческих ресурсов. Поэтому они не являются предпочтительными решениями даже для крупных предприятий, которые могут их себе позволить. Доступность может быть проблемой для аппаратных балансировщиков нагрузки, так как для обеспечения отказоустойчивости потребуется дополнительное оборудование. Кроме того, аппаратные балансировщики имеют высокие эксплуатационные расходы и проблемы с совместимостью, что делает их менее гибкими. Также стоит отметить, что у аппаратных балансировщиков есть зависимость от поставщиков (vendor lock-in).

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

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

Cloud Load Balancers (Облачные балансировщики нагрузки)

С появлением облачных вычислений была представлена услуга Load Balancers as a Service (LBaaS). В этом случае владельцы облачных решений предоставляют услуги балансировки нагрузки. Пользователи платят за использование в зависимости от объема или соглашения об уровне обслуживания (SLA) с поставщиком облачных услуг. Облачные балансировщики нагрузки могут не полностью заменять локальные балансировщики на месте, но они могут выполнять глобальное управление трафиком между разными зонами. Основные преимущества таких балансировщиков включают простоту использования, управления, учета затрат, гибкость в использовании, а также услуги по аудиту и мониторингу для улучшения бизнес-решений.

Пример облачных балансировщиков нагрузки для GSLB

Облачные балансировщики нагрузки могут эффективно предоставлять глобальные услуги балансировки нагрузки (GSLB), управляя трафиком между различными географическими регионами и зонами, как показано на следующем примере:

Примечание

Еще одним интересным вариантом реализации балансировщиков нагрузки является балансировка нагрузки на стороне клиента (Client-Side Load Balancing). Этот подход подходит для случаев, когда существует множество сервисов, каждый из которых имеет много экземпляров (например, балансировка нагрузки в Twitter). Однако наше внимание сосредоточено на традиционных балансировщиках нагрузки, так как большинство трехуровневых приложений используют их в своей архитектуре.

Заключение

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