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

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

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

Из статьи вы узнаете, как устроены алгоритмы и методы балансировки, какие существуют точки отказа, в чем разница между Load balancer и прокси.

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

Балансировка нагрузки — метод распределения сетевого трафика и задач между сетевыми устройствами.

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

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

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

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

Балансировка применима к следующему оборудованию:

• кластер,
• прокси-сервер,
• брандмауэр,
• коммутатор,
• система DPI,
• DNS-сервер,
• сетевой адаптер.

Для чего нужен балансировщик нагрузки

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

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

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

Также балансировщик обеспечит более плавное масштабирование инфраструктуры: при горизонтальном росте — добавлении нового сервера в кластер — он быстро и аккуратно загрузит новое «звено» инфраструктуры.

Другая важная функция балансировщика — защита от DDoS-атак. Ее обеспечивает задержка ответа, когда фоновые серверы не видят клиента до подтверждения по TCP. Балансировщик нагрузки Selectel проводит исходящий трафик через специальные алгоритмы, которые фильтруют TCP ACK/FIN/RST-атаки до 99,9%.

Примеры точек отказа

• Выход в интернет и обеспечение доступа пользователей к сервису: IP-адрес и сетевое оборудование, через которое проходит трафик до целевых серверов.
• Физические серверы или виртуальные машины, на которых развернут сервис. Они резервируются для предотвращения падения системы.
• Сам балансировщик. Оборудование, которое настроено под балансировщик, тоже может стать слабым звеном. Поэтому компании, для которых отказоустойчивость критична, резервируют и балансировщики.

Готовый универсальный балансировщик нагрузки от Selectel зарезервирован из «коробки» в дата-центрах в Санкт-Петербурге и Москве. Для каждого дата-центра используется своя подсеть. Ошибки в одном сегменте не влияют на другой. Подробнее о работе балансировщика читайте по ссылке.

Отказоустойчивый балансировщик нагрузки

Уровни балансировки на модели OSI

Open System Interconnection (OSI) — модель стека взаимодействия сетевых протоколов. По модели OSI сетевые устройства выстраиваются в отличные по функционалу уровни. Балансировка происходит на уровнях L4 и L7.

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

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

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

L4. Транспортный уровень обслуживает связь между конечными устройствами. Главные функции L4 — минимизировать задержку передачи данных и добиться целостности доставленной информации. В зависимости от протокола на транспортном уровне пакеты данных делятся по двум принципам.

Сегментирование (протокол TCP) — деление пакета на части при превышении пропускной способности сети. Деление на датаграммы (протокол UDP) — метод, при котором появляется автономная часть пакета с заголовками и адресами назначения. Датаграммы независимо доходят до конечного адресата.

Транспортный уровень — связующее звено между двумя группами:

• Media layers, или уровни среды. L1 — L3. На них информация передается между сетевыми устройствами.
• Host layers, или уровни хоста. L4 — L7. Работают непосредственно на стационарных компьютерах или мобильных устройствах.

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

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

L6. Уровень представления выполняет шифрование и преобразование данных в понятный для сервера и пользователя вид.

L7. Прикладной уровень обслуживает взаимодействие пользователей и сети. Верхний уровень обеспечивает доступ к сетевым службам. Работающий на L7 протокол HTTP идентифицирует клиентские сеансы и на основе файлов cookie обеспечивает доставку запросов пользователя на один сервер.

Верхний уровень модели OSI взаимодействует с предыдущими уровнями: проверяет трафик L4, отправляет отчеты об ошибках и запросы к уровню L6, передает служебную информацию.

Методы балансировки

Проверка доступности. Балансировщик мониторит статусы серверов и перенаправляет соединения в случае падения одного из них. Существует несколько параметров оценки состояния сервера:

• ответы на проверяющие запросы, интервал настраивается в секундах,
• время ожидания сети,
• ожидаемые коды ответа для протоколов проверки HTTP и HTTPS,
• порог успеха/неуспеха — количество отправленных подряд запросов, после которых сервер продолжает работу или приостанавливается.

Настройка соединений. Проходят по схеме: входящий запрос → балансировщик → сервер. Задаваемые настройки:

• ограничение количества соединений,
• таймаут соединения определяет время ожидания ответа,
• таймаут неактивности — время, когда подключение считается активным, даже если данные не передаются,
• TCP-таймаут — время ожидания передачи данных для инспекции по установленному соединению.

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

Алгоритм планирования

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

BGP Anycast

Преимущество этого протокола маршрутизации — один IP-адрес для нескольких серверов. При любом запросе может ответить наименее загруженный сервер. Таким образом минимизируются задержки при получении трафика. Данный протокол поддерживает гибкое выведение и добавление новых серверов. BGP Anycast используют в Selectel.

Round Robin

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

Least connections

Алгоритм, учитывающий количество подключений к серверу. Каждый поступивший запрос отправляется серверу с наименьшим количеством активных подключений. Уязвимое место — необходимость балансировки между несколькими Frontend-серверами. Когда пользователь устанавливает соединение с Frontend-сервером, все запросы будут отправляться именно на него. При соблюдении алгоритма Least connections другой Frontend-сервер может быть менее нагружен, и пользователь подключится к нему — ему придется заново авторизоваться.

Впрочем, данную проблему решает Sticky Sessions. Функция алгоритма состоит в том, что сервер, обработавший запрос, закрепляется для сессии пользователя. Сессия начнется на другом сервере, только если первоначальный сервер будет недоступен.

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

Обратные прокси-серверы и балансировщики работают как посредники в коммуникации между клиентами и серверами. Термины «балансировщик« и «прокси-сервер» часто используют как взаимозаменяемые. Так, например, ​​отказоустойчивый балансировщик нагрузки Selectel — это обратный прокси-сервер (reverse proxy), который распределяет трафик между различными услугами компании, находящимися в разных регионах и зонах доступности.

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

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

Преимущества облачного балансировщика

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

1. Быстрое развертывание балансировщика в новой конфигурации. В Selectel это можно сделать за несколько минут в интерфейсе панели управления.
2. «Железные» балансировщики могут не выдержать нагрузку и выйти из строя. Облачные Load balancer в этом плане более выносливы. Кроме того, их легче вертикально масштабировать.
3. Облачные балансировщики дешевле. Так, оплата балансировщиков в Selectel производится по модели pay-as-you-go (оплата за потребленные мощности). Решение можно подключить на время «жаркого» периода для бизнеса и отключить, когда потребность в балансировке перестанет быть острой.

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

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

Так выглядит создание правил балансировщика в панели управления Selectel.

В облачных балансировщиках доступны различные комбинации протоколов, которые имеют дело с нагрузкой L4 и нагрузкой L7-уровней.

• TCP–TCP — классическая L4-балансировка,
• TCP–PROXY — информация о клиенте не теряется и передается в отдельном заголовке соединения,
• UDP–UDP — UDP-протокол быстрее, чем TCP, но менее надежен,
• HTTP–HTTP — L7-балансировка,
• HTTPS–HTTP — L7-балансировка с шифрованием и терминацией SSL-сертификата на балансировщике.

Заключение

На этом мы закончим обзор балансировщиков нагрузки. Мы рассмотрели современные подходы балансировки сетевой нагрузки, изучили функционал Load balancer и алгоритмы балансировки.

Балансировщики нагрузки — обязательный элемент сложной инфраструктуры, которая состоит из нескольких серверов и требует «умных» подходов к управлению трафиком.

Обзор балансировщиков нагрузки для *nix

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

Из чего выбирать?

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

Кроме того, системы балансировки нагрузки могут перенаправлять трафик клиентов на избранный сервер несколькими способами. Самые популярные: трансляция сетевых адресов (Network Address Translation) и отсылка через шлюз TCP (TCP gateway). В первом случае балансировщик на лету подменяет в пакете IP-адреса, чем скрывает IP сервера от клиента и наоборот. Если же IP клиента нужно конечному приложению для статистики или любых других операций, его обычно сохраняют в HTTP-заголовке X-Forwarded-for. При использовании другого протокола следует убедиться, что подобная возможность реализована. В случае TCP gateway балансировщик умеет управлять трафиком на L4 (транспортном) уровне и даже на уровне приложения (L7). Для этого он устанавливает соединение и смотрит внутрь пакета. Обычно клиент и приложение обмениваются информацией через балансировщик. Но в последнее время становится все более популярной конфигурация сервера с прямым возвратом (Direct Server Return, DSR) когда ответ от сервера идет к клиенту напрямую, а не через устройство балансировки. Использование DSR уменьшает нагрузку на балансировщик, но не позволяет использовать куки и расшифровывать SSL. Данный способ на порядок быстрее, чем использование NAT-балансировки, и позволяет сервисам видеть реальные IP-адреса клиентов.

Также в системах можно встретить разные методы балансировки. Разберемся с назначением некоторых из них. В настройках продуктов они могут иметь отличные названия или свои особенности в реализации, но часто их суть одна.
Самый простой — Round Robin DNS, это специальный DNS-сервер, содержащий несколько А-записей и их вес (опционально) и выдающий при запросе клиентов различные IP-адреса. Минусы очевидны. Он абсолютно не владеет информацией о текущей загрузке и состоянии бэкендов, не учитывает предыдущие подключения клиентов (немного сглаживает ситуацию DNS-кеш).

Есть аналогичный по названию алгоритм, но реализованный средствами самого балансировщика — Round Robin. Все клиенты равномерно распределяются по бэкендам, и обычно какие-либо другие параметры не учитываются. Алгоритм распределения по весу (Round Robin Weighted) учитывает значение параметра Weight, указанного для каждого сервера. Проставив больший вес для более мощного сервера, мы сможем направить к нему больше клиентов. Несколько иначе действует распределение по приоритету. В этом алгоритме работает только сервер с большим приоритетом, остальные подключаются, как правило, только в случае его отказа. Этот вариант позволяет строить кластер с одним активным узлом, например когда второй сервер выполняет другую роль и только подстраховывает первый. Еще один вариант — Least Connection (Least Session) — соединение принимает сервер, обслуживающий наименьшее количество соединений (сессий), но соединения могут быть разные (пользователь активен или пассивен) и, соответственно, давать разную нагрузку на сервер. А вот алгоритм Least Bandwidth учитывает действительную загрузку сети.

Hash sticky client — клиент привязывается к одному серверу, для этого в специальную таблицу помещается хеш-строка, указывающая на его IP. Возможны варианты. Клиент всегда идет к одному серверу, а в случае его выхода подключение невозможно. Или, когда не отвечает «родной», он соединяется с другими системами.

Доступность бэкендов определяется двумя: активный (keepalives, балансировщик сам опрашивает серверы) и пассивный (In-Band, контролируются текущие соединения, ответы сервиса).

BalanceNG

Проект номер один в списке — BalanceNG, является развитием Open Source решения Balance, но распространятся уже под двойной лицензией (коммерческой и бесплатной Free Basic License). В бесплатной версии можно подключать один виртуальный сервер и два узла, чего с учетом возможностей достаточно, чтобы без проблем справиться со средней, а иногда и большой нагрузкой. Представляет собой решение для балансировки IP-нагрузки, поддерживающее IPv6, предлагает несколько методов управления выбора бэкенда (Round Robin, Random, Weighted Random, Least Session, Least Bandwidth, Hash, Agent и Randomized Agent).

В продукте использован оригинальный движок, работающий на Layer 2 (Ethernet), балансировка ведется на основе IP-адреса клиента, без привязки к портам работать может с любым сервисом. Поддерживает DNS GSLB (Global Server Load-Balancing) и конфигурацию сервера с прямым возвратом Direct Server Return (DSR), когда ответ от сервера идет к клиенту напрямую, а не через устройство балансировки. Содержит настраиваемый агент проверки UDP, поддерживает VRRP для установки высокодоступных конфигураций на многих узлах. Встроенные механизмы позволяют произвести захват и сохранение пакетов при помощи pcap для дальнейшего исследования. Предусмотрено несколько вариантов проверки работоспособности конечных систем: агент, ping, TCP Open, скрипт и другие инструменты вроде wget.

Возможно резервирование балансировщика с репликацией NAT-состояний между основным и резервным узлами, клиент при переподключении подсоединяется к тому же серверу. Для сохранения сессии используется IP-адрес клиента и порт назначения. Поддерживается Linux bonding. Все таблицы хранятся в ОЗУ, но требования невелики, для 4 миллионов сессий достаточно 512 Мб памяти.
Может работать в Linux (с использованием сокета API PF_PACKET) и SPARC/Intel Solaris (Streams/DLPI API). Для установки предлагаются rpm (Red Hat RHEL 6 / CentOS) и deb (Debian/Ubuntu) пакеты и тарбал для остальных дистрибутивов. Также доступен готовый образ для виртуальной машины (на базе Ubuntu 8.04), что позволяет быстро развернуть нужную функциональность. Во время закачки будут показаны все пароли для входа. Агент (bngagent) поставляется с открытым исходным кодом и поддерживает Linux, Solaris, OS X, HP-UX и другие.
Какой-либо интерфейс для настройки не предусмотрен, все установки производятся при помощи конфигурационного файла /etc/bng.conf. В принципе, сложным его назвать нельзя, особенно учитывая, что на сайте проекта доступно более десятка готовых примеров, часто нужно лишь выбрать наиболее подходящий и отредактировать под себя.

Конфигурационный файл BalanceNG

Рекомендуем почитать:

Xakep #280. Джейл-2022

HAProxy

HAProxy — балансировщик нагрузки и прокси-сервер уровня приложений Layer7 для TCP и HTTP. Проект начинался как очень простой HTTP-прокси Webroute, но постепенно оброс новыми возможностями. Особенностью HAProxy является использование для регулирования соединений cookie и контента, он встраивает cookie и проверяет содержимое пакета при подключении. Анализ пакетов на Layer7 позволяет фильтровать несанкционированный трафик и протоколы. Проверяя HTTP-запрос при помощи регулярных выражений, можно задать любые правила для выбора сервера, например реализуя ACL и геолокацию. В случае необходимости обработки IP-клиента на конечном сервере можем сохранить его в X-Forwarded-for. Движок стабилен, безопасен, оптимизирован, в результате HAProxy способен одновременно обрабатывать большое количество подключений (20 тысяч в секунду и более).
Обработкой всех подключений занимается один процесс, за счет оптимизации и планировщика обеспечивающий большое количество одновременных соединений на очень высоких скоростях. Такие системы не слишком хорошо масштабируются на многопроцессорных системах, но не болеют блокировками и ограничениями памяти. Но здесь мы не увидим продвинутых функций вроде поддержки SSL и keep-alive — по утверждению разработчиков, они усложняют и «утяжеляют» процесс. Отказоустойчивость HAProxy-сервера достигается через использование демона keepalived, проверяющего его работоспособность, синхронизация с резервным сервером (протокол VRRP) обеспечивает дублирование.

Предоставляет логирование соединений и разнообразные отчеты (статистика выводится на отдельном порту). Ориентирован в первую очередь на веб-сайты, но используется и в других сценариях, например в качестве балансировщика для multi-master серверов MySQL. Поддерживается фильтрация пользователей и подключение к тому же серверу (для RDP и HTTP), аутентификация HTTP.

Веб-интерфейс Snapt для настройки HAProxy

HAProxy в качестве балансировщика используется в нескольких компаниях из списка Fortune 500: Amazon RDS, GitHub, Stack Overflow, Server Fault, Twitter…
Возможности расширяются при помощи аддонов, их полный список есть на сайте. Все настройки производятся при помощи конфигурационного файла (на сайте есть примеры). Кроме того, известны два интерфейса сторонних разработчиков: коммерческий веб Snapt и свободный HATop.

Работает на нескольких архитектурах x86, x86_64, Alpha, SPARC, MIPS, PARISC. Официально поддерживает Linux 2.6.32+ (рекомендуется для максимальной производительности) и 2.4, Solaris 8–10, FreeBSD, OpenBSD. Установка и настройка тривиальны, хотя пакет в репозиториях не присутствует. Проект предлагает исходный код под лицензией GPL v2 и готовые бинарники под Linux/x86 Glibc 2.2 и Solaris8/Sparc.

Статистика HAProxy

Pound — прокси и балансировка HTTP и HTTPS

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

Балансировка производится по состоянию сессии и другим параметрам (URL, аутентификации, cookies, HTTP headers). Полная поддержка WebDAV. В отличие от HAProxy обрабатывает SSL. Разработан в IT-компании, занимающейся безопасностью, что также сказалось на возможностях продукта. Особенностью является наличие базовых функций Web Application Firewall, Pound умеет контролировать корректность заголовков HTTP и HTTPS, отбрасывая неправильные. По умолчанию пропускаются все запросы, но можно создать шаблоны URL и тип запросов (стандартные, расширенные, RPC и WebDAV), которые будут проверяться на соответствие. По результатам выбирается конечный сервер или соединение блокируется. Дизайн изначально предусматривает минимальное вмешательство в трафик (например, встраивание cookie), но может прописывать X-Forwarded-for для передачи на бэкенд сервера IP-адреса пользователя.

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

Из специфики — возможна не только отправка соединения к бэкенду, но и редирект на другой URL.

Pound не требует много ресурсов, примечательно, что кроме как за считыванием SSL-сертификатов демон не обращается к харду. Может быть запущен в chroot и использовать setuid/setgid. Каких-либо встроенных механизмов отказоустойчивости нет. Проверка работоспособности бэкендов производится всегда по HTTP.

На процессоре уровня Pentium D позволяет достичь примерно 600–800 HTTP- и 200–300 HTTPS-соединений в секунду. Поэтому конек Pound — небольшие проекты с упором на доступность, безопасность и больший контроль над трафиком. Для более высокой нагрузки сами разработчики Pound рекомендуют воспользоваться другими решениями.

Установка и настройка не представляют больших сложностей, хотя и производятся при помощи конфигурационных файлов (документация очень подробная). Официально был протестирован на Linux, Solaris и OpenBSD. Проект предлагает только исходные тексты, в репозиториях SUSE, Debian и Ubuntu можно найти готовые пакеты, кроме этого, на сайте есть ссылки для Red Hat и готового дистрибутива, собранного на базе FreeBSD.

В конфигурационном файле Pound разобраться легко

Crossroads

Crossroads обеспечивает балансировку нагрузки к любым TCP-сервисам, поэтому подходит не только для HTTP(S), но и для SMTP, SSH, баз данных и других. В обычном варианте он просто гарантирует подключение к бэкенду, не вникая во внутренности, и обеспечивает в этом режиме максимальную производительность. Один сервер может обслуживать несколько сайтов с разными бэкендами и протоколами. Но есть специальный режим HTTP mode, при котором обрабатываются и при необходимости меняются заголовки сеанса. Это обеспечивает возможность перенаправления пользователя на тот же сервер (session stickiness) и сохранение IP клиента в X-Forwarded-For. Сам по себе HTTP mode и особенно модификация пакета влияет на производительность (потери до 30%).

По умолчанию клиент перенаправляется на сервер, принимающий меньше подключений, но при необходимости алгоритм легко изменить на Round Robin, Least-Connections и First Available или определяться внешней программой или скриптом. Клиентов можно закреплять за определенным сервером (Hash sticky client), жестко или с возможностью подключения к другому серверу, если «свой» не отвечает. При возобновлении работы бэкенда он автоматически включается в работу. Возможно управление доступом к Crossroads на основе IP-адреса (allow и deny).
В версии 2.х все подключения обслуживает один процесс, работающий в пространстве пользователя, это положительно сказалось на скорости работы и на управлении. Может работать как stand-alone демон или запускаться через inetd. Удобно, что все настройки и команды можно отдавать на лету (при помощи утилиты xr), изменение параметров не требует перезапуска Crossroads. Например, настроим балансировку для двух веб-сайтов и серверов MySQL.

Статистика выводится при помощи веб-интерфейса, порт которого задается вместе с ключом -W (–web-interface). Также с его помощью можно изменить три параметра: максимальное количество соединений для Crossroads и для бэкендов, вес бэкендов.

Для удобства все их записывают в отдельный файл, который и указывают при загрузке, или используют специальный конфигурационный файл в формате XML (/etc/xrctl.xml, в поставке несколько готовых примеров).

Может быть запущен на любой POSIX-системе — Linux, OS X, Solaris. Проект предлагает исходные тексты (сборка проблем не вызывает), готовые пакеты доступны в репозиториях основных дистрибутивов.

В поставке Crossroads несколько готовых конфигурационных файлов

Zen Load Balancer

Решение, несколько отличающееся от остальных участников обзора. Разработчики справедливо решили, что под балансировку выделяется отдельный сервер, а поэтому лучше сразу предоставить готовый дистрибутив, чтобы упростить развертывание, повысить производительность и безопасность. Основой Zen Load Balancer является оптимизированная и урезанная версия Debian 6. Поддерживается балансировка на Layer 4 для протоколов TCP, UDP и на Layer 7 для HTTP/HTTPS. Специальный режим L4xNAT позволяет настроить балансировку на транспортном уровне без учета номеров портов (фактически без привязки к сервису), в этом случае Zen просто пропускает через себя весь трафик, распределяя его по серверам. Есть у Zen и фишка — режим DATALINK. В этом случае Zen выступает в качестве шлюза по умолчанию, обеспечивая равномерную нагрузку на канал и резервирование при подключении к нескольким провайдерам (балансировка на Layer 3).

Реализовано несколько алгоритмов выбора бэкенда: Round Robin, по весу (Weight), по приоритету (Priority) или подключение к определенному серверу (Hash sticky client). Возможен возврат пользователя в открытую сессию, он определяется несколькими способами (по IP-адресу, сookie, запрашиваемому URL, по заголовку HTTP). Предусмотрено сохранение IP в X-Forwarded-for.

Технология FarmGuardian позволяет определять доступность сервисов при помощи специального скрипта и распределять по ним подключения. Zen может выполнять функцию SSL-прокси, шифруя поток к клиенту, на участке Zen — бэкенд данные идут в открытом виде. Поддерживается VLAN.

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

И главное — все настройки производятся при помощи веб-интерфейса (по умолчанию на HTTPS/444, логин/пароль — admin/admin). Предлагается две версии. Бесплатная только в x86-варианте и без технической поддержки. Ее возможностей вполне хватает для большинства сетей среднего размера. Платная версия предоставляется уже в x64-сборке. Развернуть готовую систему очень просто, на сайте доступна вся необходимая информация по настройкам (на английском).

Все настройки Zen Load Balancer производятся через веб-интерфейс

Заключение

Как видим, выбирать есть из чего. Каждый продукт имеет свои сильные и слабые стороны, зная которые легко определиться, какой из них подходит для определенной ситуации. Так, HAProxy подкупает производительностью, BalanceNG — функциональностью, простотой в настройках. Pound отличается возможностью разборки HTTP, а Crossroads — гибкостью. Если все же нужен веб-интерфейс, то альтернативы Zen Load Balancer нет, ну если только не хочется платить за Snapt для HAProxy.

Облачные сервисы для балансировки нагрузки

С ростом популярности облачных сервисов все больше систем размещаются на внешних площадках, образуя гибридные облака. Большинство разработчиков предлагает ко всему прочему и возможность балансировки нагрузки, это очень удобно, так как не требует от клиента установки дополнительного оборудования и готово к применению почти сразу. Хотя возможностей по управлению такой способ дает, как правило, меньше. Все основные игроки уже предложили свои решения. Например, Amazon Route 53, являющийся частью Amazon Web Services и предоставляющий балансировку при помощи Round Robin DNS. Стоимость услуги небольшая и составляет один доллар в месяц, плюс 0,50 доллара за первый миллион запросов и 0,25 за каждый следующий. Предусмотрен удобный API для редактирования, добавления и удаления записей.
Также нужная функциональность доступна в специализированных облачных продуктах — WAF или решениях для защиты от DDoS. Например, сервис Akamai Global Traffic Management Akamai.

Введение в современную балансировку сетевой нагрузки и проксирование

Не так давно я услышал, что существует недостаток вступительных образовательных материалов о современной балансировке сетевой нагрузки и проксировании. И я подумал: как это возможно? Балансировка нагрузки — одна из основных концепций, необходимых для построения надежных распределенных систем. Разумеется, должна быть доступна качественная информация. К сожалению, это не так. Я искал и обнаружил, что материалы действительно поверхностны. В статье Википедии балансировка нагрузки и прокси-серверы содержатся обзоры некоторых понятий, но не полное разъяснение объекта, особенно в том, что касается современных микросервисных архитектур. Поиск в Google по запросу балансировки нагрузки также не предоставил мне хороших и понятных материалов.

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

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

Wikipedia определяет балансировку нагрузки как:

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

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

Обзор балансировки сетевой нагрузки

Рисунок показывает высокоуровневый обзор балансировки сетевой нагрузки. Некоторое количество клиентов запрашивает ресурсы из некоторого количества бэкендов. Балансировщик нагрузки находится между клиентами и внутренними компонентами и на высоком уровне выполняет несколько важных задач:

• Обнаружение служб: Какие бэкенды доступны в системе? Каковы их адреса (например, как должен работать балансировщик нагрузки)?
• Проверка работоспособности: Какие бэкенды в настоящее время здоровы и доступны для приема запросов?
• Балансировка нагрузки: Какой алгоритм следует использовать для балансировки отдельных запросов по здоровым бэкендам?

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

• Именование абстракции: Нет необходимости в том чтобы каждый клиент знал о каждом бэкенде (service discovery). Клиент может обращаться к балансировщику нагрузки через предопределенный механизм, а затем действие разрешения имен можно делегировать в балансировщик нагрузки. Предопределенные механизмы включают встроенные библиотеки и хорошо известные DNS/IP/port и будут обсуждаться более подробно ниже.
• Отказоустойчивость: Благодаря проверке работоспособности и различным алгоритмическим методам балансировщик нагрузки может эффективно маршрутизировать вокруг неработоспособного или перегруженного бэкенда. Это означает, что администратор может спокойно, без спешки устранить проблему на нездоровом узле.
• Стоимость и производительность: Распределенные системные сети редко бывают однородными. Наиболее вероятно, что система будет охватывать несколько сетевых зон и регионов. Интеллектуальная балансировка нагрузки может максимально увеличить трафик запросов в зонах, что увеличивает производительность (меньше латентности) и снижает общую стоимость системы (меньше полосы пропускания и прокладки оптоволокна, требуемого между зонами).

Балансировка нагрузки vs прокси-сервер

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

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

L4 (connection/session) балансировка нагрузки

В масштабах отрасли сегодня решения по балансировке нагрузки часто разделяются на две категории: L4 и L7. Они относятся к уровням 4 и 7 модели OSI. Модель OSI представляет очень плохое приближение к сложности решений балансировки нагрузки, которые включают традиционные протоколы уровня 4, такие как TCP и UDP, но часто заканчиваются включением битов и частей протоколов на разных уровнях OSI. Возникает вопрос: если балансировщик нагрузки L4 TCP также поддерживает терминирование TLS, является ли он теперь балансировщиком нагрузки L7?

Базовая балансировка нагрузки TCP L4

Рисунок показывает традиционный балансировщик нагрузки L4 TCP. В этом случае клиент устанавливает TCP-соединение с балансировщиком нагрузки. Балансировщик нагрузки завершает соединение (т.е. отвечает непосредственно на SYN), выбирает бэкенд и устанавливает новое TCP-соединение с бэкендом (т.е. отправляет новый SYN). Детали диаграммы не важны и будут подробно обсуждаться ниже — в разделе, посвященном балансировке нагрузки L4.

Основной вывод этого раздела: заключается в том, что балансировщик нагрузки L4 обычно работает только на уровне соединения/сеанса L4 TCP/UDP. Таким образом, балансировщик нагрузки грубо перетасовывает байты взад и вперед и гарантирует, что байты с того же сеанса завершаются на одном и том же бэкенде. Балансировщик L4 не знает о каких-либо деталях байтов приложения, которые перетасовывает. Байтами могут быть HTTP, Redis, MongoDB или любой другой протокол приложения.

L7 (приложение) балансировка нагрузки

Балансировка нагрузки L4 проста и по-прежнему широко используется. Каковы недостатки балансировки нагрузки L4, которые гарантируют инвестиции в балансировку нагрузки L7 (приложение)? В качестве примера возьмем следующий конкретный случай L4:

• Два клиента gRPC/HTTP2 хотят поговорить с бэкендом, поэтому подключаются через балансировщик нагрузки L4.
• Балансировщик нагрузки L4 делает одно исходящее TCP-соединение для каждого входящего TCP-соединения, что приводит к двум входящим и двум исходящим соединениям.
• Однако клиент A отправляет по 1 запрос в минуту (RPM), а клиент B отправляет 50 запросов в секунду (RPS) по его соединению.

В предыдущем сценарии бэкенд, выбранный для обработки клиента A, будет обрабатывать нагрузку примерно в 3000x раз меньше, чем бэкенд, выбранный для обработки клиента B! Эта серьезная проблема, как правило, в первую очередь нарушает цель балансировки нагрузки. Также обратите внимание, что эта проблема возникает для любого протокола мультиплексирования. (Мультиплексирование означает отправку одновременных запросов приложений по одному соединению L4, а keep-alive означает команду не закрывать соединение, когда нет активных запросов). Все современные протоколы развиваются как для мультиплексирования, так и для поддержания жизнеспособности по соображениям эффективности (как правило, соединения, которые шифруются с использованием TLS, создавать дорого). Поэтому с течением времени сопротивление балансировки нагрузки L4 становится более выраженным. Эта проблема устраняется балансировщиком нагрузки L7.

HTTP/2 балансировка нагрузки L7

Рисунок показывает балансировщик нагрузки L7 HTTP/2. В этом случае клиент делает одно соединение HTTP/2 TCP с балансировщиком нагрузки. Затем балансировщик выполняет два внутренних подключения. Когда клиент отправляет два потока HTTP/2 в балансировщик нагрузки, поток 1 отправляется на бэкенд 1, в то время как поток 2 отправляется на бэкенд 2. Таким образом, даже мультиплексирование клиентов, которые имеют значительно разные нагрузки на запросы, будет эффективно балансироваться по внутренним компонентам. Вот почему балансировка нагрузки L7 так важна для современных протоколов. (Балансировка нагрузки L7 дает также множество дополнительных преимуществ из-за возможности проверки трафика приложений, но более подробно это будет рассмотрено ниже).

Балансировка нагрузки L7 и модель OSI

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

• Дополнительная безопасность транспортного уровня (TLS). Обратите внимание: люди до сих пор спорят о том, в какой OSI-уровень входит TLS. Ради этой дискуссии мы рассмотрим TLS L7.
• Физический протокол HTTP (HTTP/1 или HTTP/2).
• Логический HTTP-протокол (headers, body data, и trailers).
• Протокол обмена сообщениями (gRPC, REST, и т.д.).

Усовершенствованный балансировщик нагрузки L7 может предлагать функции, связанные с каждым из вышеперечисленных подслоев. Еще один балансировщик L7 может иметь только небольшой набор функций, которые помещают его в категорию L7. Короче говоря, ландшафт балансировки нагрузки L7 значительно сложнее с точки зрения сравнения функций, чем категория L4. (И, конечно, этот раздел только что затронул HTTP: Redis, Kafka, MongoDB и т.д. — всё это примеры протоколов приложений L7, которые выигрывают от балансировки нагрузки L7).

Функции балансировки нагрузки

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

Обнаружение службы

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

• Статичный файл конфигурации.
• DNS. , Etcd, Consul, и т.д.
• Envoy’s универсальный data plane API.

Проверка работоспособности

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

• Активная: Балансировщик нагрузки периодически отправляет ping (например, HTTP-запрос конечной точке /healthcheck) на бэкенд и использует это для оценки работоспособности.
• Пассивная: Балансировщик нагрузки определяет состояние здоровья из основного потока данных. Например, балансировщик нагрузки L4 может решить, что бэкенд нездоровый, если в строке было три ошибки соединения. Балансировщик нагрузки L7 может решить, что бэкенд нездоровый, если в строке было три кода ответа HTTP 503.

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

Да, балансировщики нагрузки должны фактически балансировать нагрузку! Учитывая набор здоровых бэкендов, как выбирается бэкенд, который будет обслуживать соединение или запрос? Алгоритмы балансировки нагрузки являются активной областью исследований и варьируются от упрощенных, таких как случайный выбор и циклический алгоритм, до более сложных алгоритмов, учитывающих переменную задержку и нагрузку на бэкенд. Один из самых популярных (учитывая его производительность и простоту) алгоритмов балансировки нагрузки известен как [power of 2 least request] (https://brooker.co.za/blog/2012/01/17/two-random.html).

Sticky sessions

В некоторых приложениях важно, чтобы запросы на один и тот же сеанс достигли одного и того же бэкенда. Это может быть связано с кешированием, временным сложным состоянием и т.д. Определение сеанса варьируется и может включать HTTP-файлы cookie, свойства клиентского соединения или какой-либо другой атрибут. У многих балансировщиков нагрузки L7 есть определенная поддержка липких сеансов. Отмечу, что липкость сеанса по своей сути является хрупкой (бэкенд-хостинг сеанса может умереть), поэтому будьте осторожны при разработке системы, которая опирается на них.

TLS-терминирование

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

Возможность наблюдения

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

Безопасность и предотвращение DoS

В частности, в топологии развертывания краев (см. ниже) балансировочные устройства часто реализуют различные функции безопасности, включая ограничение скорости, аутентификацию и смягчение DoS (например, маркирование и идентификацию IP-адреса, tarpitting и т.д.).

Конфигурация и плоскость управления

Балансировщики нагрузки нуждаются в настройке. В крупных развертываниях это может стать существенной задачей. Система, которая настраивает балансировщики нагрузки, известна как «плоскость управления» и широко варьируется в реализации. Для получения дополнительной информации по этой теме, пожалуйста, см. мое [сообщение о плоскости данных сетки обслуживания и плоскости управления] (https://medium.com/@mattklein123/service-mesh-data-plane-vs-control-plane-2774e720f7fc).

И еще многое другое

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

Типы топологий балансировки нагрузки

Теперь, когда я предоставил высокоуровневое описание балансировки нагрузки, разницу между балансировщиками нагрузки L4 и L7 и краткое описание функций балансировки нагрузки, перейду к различным топологиям распределенных систем, в которых развернуты балансировщики нагрузки. (Каждая из следующих топологий применима как для балансировщиков нагрузки L4, так и для L7).

Прокси по середине

Топология балансировки нагрузки прокси по середине

Топология прокси по середине, показанная на рисунке выше, вероятно, является наиболее известным способом получения балансировки нагрузки для большинства читателей. Эта категория включает аппаратные устройства от Cisco, Juniper, F5 и т.д.; облачные программные решения, такие как Amazon ALB и NLB и Сloud Load Balancer; и чистые программные решения, такие как HAProxy, NGINX и Envoy. Достоинства подобной топологии — простота применения для пользователей. В общем случае пользователи подключаются к балансировщику нагрузки через DNS и не должны беспокоиться ни о чем другом. Соглашением решения прокси по середине является тот факт, что прокси (даже в случае кластеризации) является единственной точкой отказа, а также узким местом масштабирования. Прокси по середине также часто является черным ящиком, что затрудняет работу. Является ли наблюдаемая проблема у клиента? В физической сети? В прокси по середине? В бэкенде? Ответить на эти вопросы может быть очень сложно.

Краевой прокси

Топология балансировки нагрузки краевого прокси

Топология краевого прокси, показанная на рисунке, на самом деле является лишь вариантом топологии прокси по середине, в которой балансировщик нагрузки доступен через Интернет. В этом случае балансировщик нагрузки обычно должен предоставлять дополнительные функции «шлюза API», такие как терминирование TLS, ограничение скорости, аутентификация и сложная маршрутизация трафика. Все плюсы и минусы краевого прокси-сервера такие же, как и прокси по середине. Клиентам обычно требуется доступ к системе через DNS с использованием произвольных сетевых библиотек, которые владелец сервиса не контролирует (создание встроенной клиентской библиотеки или топологий прокси-сервера sidecar, описанных в следующих разделах, нецелесообразно запускать непосредственно на клиенте). Кроме того, по соображениям безопасности желательно иметь один шлюз, через который весь интернет-трафик проходит через систему.

Встроенная клиентская библиотека

Балансировка нагрузки через встроенную клиентскую библиотеку

Чтобы избежать присущих топологии сервера прокси по середине проблем отказа и масштабирования, более сложные инфраструктуры переключились на то, чтобы встроить балансировщик нагрузки непосредственно в службы через библиотеку, как показано на рисунке. Библиотеки сильно различаются по поддерживаемым функциям, но некоторые из наиболее известных и многофункциональных в этой категории — Finagle, [Eureka/Ribbon/Hystrix](https: //netflix.github.io/) и gRPC (на основе внутренней системы Google, называемой Stubby). Основным достоинством решения на базе библиотеки является то, что он полностью распределяет всю функциональность балансировщика нагрузки каждому клиенту, тем самым устраняя описанные ранее проблемы отказа и масштабирования. Первичным решением библиотечного решения является то, что библиотека должна быть реализована на всех языках, которые использует организация. Распределенные архитектуры становятся все более «полиглотными» (многоязычными). В этой среде стоимость переоснащения чрезвычайно сложной сетевой библиотеки на разных языках может стать непомерно высокой. Наконец, развертывание обновлений библиотек в большой архитектуре обслуживания может быть чрезвычайно болезненным.

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

Прокси-сервер Sidecar

Балансировка нагрузки через прокси-сервер sidecar

Вариантом топологии балансировки нагрузки встроенной клиентской библиотеки является топология прокси-сервера sidecar, показанная на рисунке. В последние годы она была популяризирована как «служебная сетка». Идея прокси-сервера sidecar заключается в том, что ценой незначительного штрафа за латентность переходом на другой процесс все преимущества встроенного библиотечного подхода могут быть получены без программирования. Наиболее популярными балансировщиками нагрузки прокси-сервера sidecar на данный момент являются Envoy, NGINX, [HAProxy](https: //www.haproxy.com/) и Linkerd. Для более детального изучения подхода прокси-сервера sidecar см. мой пост в блоге о Envoy, а также мой пост [the service mesh data plane vs. control plane] (https://medium.com/@mattklein123/service-mesh-data-plane-vs-control-plane-2774e720f7fc).

Резюме и плюсы/минусы различных топологий балансировки нагрузки

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

Думаю, топология прокси-сервера sidecar (служебная сеть) постепенно заменяет все другие топологии для связи между сервисами. Точка топологии краевого прокси-сервера всегда будет необходима до того, как трафик войдет в служебную сетку.

Современное состояние в балансировке нагрузки L4

Балансировщики нагрузки L4 по-прежнему актуальны?

В этом сообщении уже обсуждалось, насколько значимы балансировщики L7 для современных протоколов. Теперь более подробно перейдем к функциям балансировки нагрузки L7. Означает ли это, что балансировщики нагрузки L4 больше не актуальны? Нет! Хотя, на мой взгляд, балансировщики нагрузки L7 в конечном счете полностью заменяют балансировщики нагрузки L4 для связи между сервисами, балансировщики нагрузки L4 по-прежнему крайне важны, потому что почти все современные крупные распределенные архитектуры используют двухуровневую архитектуру балансировки нагрузки L4 / L7 для интернет-трафика. Преимущества размещения выделенных балансировщиков нагрузки L4 до балансировщика нагрузки L7 при развертывании на краю:

• Поскольку балансировочные устройства L7 выполняют значительно более сложный анализ, преобразование и маршрутизацию трафика приложения, они могут обрабатывать меньшую часть нагрузки (измеренной в пакетах в секунду и байтах в секунду), чем оптимизированный балансировщик нагрузки L4. Этот факт, как правило, делает балансировщики нагрузки L4 лучшим местом для обработки определенных типов DoS-атак (например, SYN-флуда, общих атак на передачу пакетов и т.д.).
• Балансировщики нагрузки L7, как правило, более активно развиваются, развертываются чаще и имеют больше багов, чем балансировщики нагрузки L4. Наличие спереди балансировщика нагрузки L4, который может выполнять проверку работоспособности и слив во время развертывания балансировщика нагрузки L7, значительно проще, чем применение механизмов развертывания с современными балансирами нагрузки L4, которые обычно используют BGP и ECMP (подробнее об этом ниже). И, наконец, поскольку балансировщики L7 с большей вероятностью имеют ошибки из-за сложности их функциональности, наличие балансировщика нагрузки L4, который может маршрутизировать ошибки и аномалии, приводит к более стабильной общей системе.

В следующих разделах я опишу несколько различных конструкций для балансировщика нагрузки L4 для прокси по середине и краевого прокси. Следующие проекты, как правило, неприменимы к клиентской библиотеке и топологиям прокси-сервера sidecar.

TCP/UDP балансировщик нагрузки

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

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

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

• Их относительно просто реализовать.
• Прекращение соединения в непосредственной близости (низкая латентность) к клиенту имеет существенные последствия для производительности. В частности, если конечный балансировщик нагрузки можно разместить рядом с клиентами, которые используют сеть с потерями (например, сотовую), повторные передачи, скорее всего, будут происходить быстрее до того, как данные будут перемещены в надежный транзит по маршруту до конечного местоположения. Другими словами, этот тип балансировщика нагрузки может использоваться в сценарии Point of Presence (POP) для прерывания TCP-соединения.

Отказоустойчивость через пары высокой доступности

L4-отказоустойчивость через пары HA и отслеживание соединений

До сих пор мы рассматривали дизайн балансировщика нагрузки L4 изолированно. Для балансировки нагрузки Passthrough и DSR требуется некоторое отслеживание соединения и состояния в самом балансировщике нагрузки. Что делать, если балансировщик нагрузки умирает? Если один экземпляр балансировщика умирает, все проходящие через него соединения будут разорваны. В зависимости от приложения это может существенно повлиять на производительность.

Исторически балансировщики нагрузки L4 были аппаратными устройствами, приобретенными у типичных поставщиков (Cisco, Juniper, F5 и т.д.). Эти устройства чрезвычайно дороги и обрабатывают большой объем трафика. Чтобы избежать отказа одного балансировщика нагрузки, разрушающего все соединения и приводящего к существенному отключению приложений, балансировщики обычно развертывались в парах с высокой доступностью, как показано на рисунке. Типичная установка балансировки нагрузки HA имеет следующий дизайн:

• Пара пограничных маршрутизаторов HA обслуживает некоторое количество виртуальных IP-адресов (VIP). Эти пограничные маршрутизаторы объявляют VIP-клиентов, используя протокол пограничных шлюзов (BGP). Основной пограничный маршрутизатор имеет более высокий вес BGP, чем резервный, поэтому в рабочем состоянии он обслуживает весь трафик. (BGP — чрезвычайно сложный протокол, для целей этой статьи просто представляйте BGP как механизм, с помощью которого сетевые устройства сообщают, что они доступны для приема трафика с других сетевых устройств, и учитывайте, что каждая ссылка может иметь вес, который определяет приоритетность трафика).
• Аналогично, основной балансировщик нагрузки L4 объявляет себя граничным маршрутизатором с более высоким значением BGP, чем резервный, поэтому в рабочем состоянии он обслуживает весь трафик.
• Первичный балансировщик нагрузки перекрестно подключен к резерву и разделяет состояние отслеживания соединений. Таким образом, если первичный балансировщик умирает, резервный может взять на себя обработку всех активных подключений.
• Два пограничных маршрутизатора и два балансировщика нагрузки связаны друг с другом. Это означает, что если один из пограничных маршрутизаторов или один из балансировщиков нагрузки умирает или имеет собственные объявления маршрутов BGP по какой-либо другой причине, резервный может взять на себя обслуживание всего трафика.

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

• VIP должны быть правильно распределены по парам балансировки нагрузки HA с учетом использования мощности.
• Использование ресурсов системы невелико. 50% мощности находится в режиме ожидания. Учитывая, что аппаратные балансировщики нагрузки чрезвычайно дороги, это приводит к существенному количеству «простаивающих» денег.
• Современному дизайну распределенной системы нужна большая отказоустойчивость, чем могут обеспечить активный/резервный балансировщики. Например, система должна выдерживать множественные одновременные сбои и продолжать работать. Пара балансировщиков нагрузки HA подвержена общему сбою, если одновременно активизируются как активный, так и резервный балансировщик нагрузки.
• Собственные крупные аппаратные устройства от поставщиков чрезвычайно дороги и приводят к привязке к поставщику. Как правило, желательно заменить эти аппаратные устройства горизонтально масштабируемыми программными решениями, построенными с использованием обычных серверов.

Отказоустойчивость и масштабирование с помощью кластеров с распределенным консистентным хешированием

L4-отказоустойчивость и масштабирование с помощью кластерных балансировщиков нагрузки и консистентного хеширования

В предыдущем разделе была представлена ошибка отказоустойчивости балансировки нагрузки L4 через пары HA, а также указаны присущие этой конструкции проблемы. Начиная с середины 2000-х годов крупные интернет-инфраструктуры начали разрабатывать и развертывать новые массивно-параллельные системы балансировки нагрузки L4, как показано на рисунке. Целями этих систем являются:

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

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

• N пограничных маршрутизаторов объявляют все VIP Anycast с одинаковым весом BGP. Равнозначный multi-path-роутинг (ECMP) используется для обеспечения того, чтобы в общем случае все пакеты из одного потока поступали на один и тот же пограничный маршрутизатор. Поток, как правило, представляет собой кортеж источника IP/порта и IP-адреса назначения. (Короче говоря, ECMP — это способ распространения пакетов по набору одинаково взвешенных сетевых ссылок с использованием консистентного хеширования). Хотя сами пограничные маршрутизаторы не особо заботятся о том, какие пакеты поступают в поток, предпочтительно, чтобы все пакеты из потока пересекали один и тот же набор ссылок, чтобы избежать сбоев пакетов, которые ухудшают производительность.
• N машин для балансировки нагрузки L4 объявляют все VIP с одинаковым весом BGP к пограничным маршрутизаторам. Опять же, используя ECMP, пограничные маршрутизаторы обычно выбирают одну и ту же машину балансировки нагрузки для потока.
• Каждая машина балансировки нагрузки L4 обычно выполняет частичное отслеживание соединения, а затем использует консистентное хеширование, чтобы выбрать бэкенд для потока. GRE используется для инкапсуляции пакетов, отправленных из балансировщика нагрузки в бэкенд.
• Затем DSR используется для отправки пакетов непосредственно из бэкенда клиенту через пограничные маршрутизаторы.
• Консистентный алгоритм хеширования, используемый балансировщиком нагрузки L4, является областью активных исследований. Существуют компромиссы в первую очередь вокруг выравнивания нагрузки, минимизации задержки, минимизации сбоев во время изменений бэкенда и минимизации издержек памяти. Полное обсуждение этой темы выходит за рамки этой статьи.

Давайте посмотрим, как приведенный выше пример смягчает все недостатки подхода пары HA:

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

Вопросы, которые обычно задают об этой конструкции: — «почему пограничные маршрутизаторы не разговаривают напрямую с серверами через ECMP?», «зачем нам нужен балансировщик нагрузки?». Причины в первую очередь связаны с уменьшением эффективности DoS и операционной системой. Без балансировки нагрузки каждый бэкенд должен был бы участвовать в BGP и потребовалось бы значительно большее время для развертывания.

Все современные системы балансировки нагрузки L4 двигаются к этой конструкции (или к ее варианту). Двумя наиболее известными примерами являются Maglev из Google и [Балансировщик сетевой нагрузки (NLB)](http: //docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) от Amazon. В настоящее время нет балансировщика нагрузки OSS, который реализует этот проект, однако есть компания, которая планирует выпуск OSS в 2018 году. Я очень взволнован этим выпуском, поскольку современный балансировщик нагрузки L4 является решающим элементом отсутствия OSS в сетевом пространстве.

Текущее состояние балансировки нагрузки L7

The proxy wars in tech currently is *quite literally* the proxy wars.

Or the “war of the proxies”.

Nginx plus, HAProxy, linkerd, Envoy all quite literally killing it.

And proxy-as-a-service/routing-as-a-service SaaS vendors raising the bar as well. Very interesting times!
— Cindy Sridharan (@copyconstruct) November 28, 2017

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

Поддержка протокола

Современные балансировщики нагрузки L7 добавляют явную поддержку для многих разных протоколов. Чем большее отношение балансировщик нагрузки имеет к трафику приложения, тем более сложные вещи он может делать в отношении вывода наблюдаемости, расширенной балансировки нагрузки, маршрутизации и т.д. Например, на момент написания этой статьи Envoy явно поддерживает парсинг и маршрутизацию протокола L7 для HTTP/1, HTTP/2, gRPC, Redis, MongoDB и DynamoDB. В будущем, вероятно, появятся новые протоколы, включая MySQL и Kafka.

Динамическая конфигурация

Как описано выше, все более динамичный характер распределенных систем требует параллельных инвестиций в создание динамических и реактивных систем управления. Istio — один из примеров такой системы. Для получения дополнительной информации по этой теме см. мой пост service mesh data plane vs. control plane.

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

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

Наблюдаемость

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

Расширяемость

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

Отказоустойчивость

Немного выше я написал о L4-отказоустойчивости балансировки нагрузки. А что насчет отказоустойчивости балансировки нагрузки L7? Мы рассматриваем балансировщики нагрузки L7 как расходный материал и stateless. Использование программного обеспечения для балансировки позволяет L7 легко масштабироваться горизонтально. Кроме того, обработка и отслеживание состояния, которые выполняют балансировщики нагрузки L7, существенно сложнее, чем L4. Попытка построить HA-пару балансировщика нагрузки L7 технически возможна, но это будет тяжело реализовать.

Как в доменах балансировки нагрузки L4 и L7, отрасль в целом отходит от HA-пар к горизонтально масштабируемым системам, которые взаимодействуют через консистентное хеширование.

И еще

Балансировщики нагрузки L7 развиваются ошеломляющими темпами. Пример того, что предлагает Envoy, см. в разделе Обзор архитектуры.

Глобальная балансировка нагрузки и централизованная плоскость управления

Глобальная балансировка нагрузки

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

• Каждый прокси-сервер sidecar связывается с серверами в трех разных зонах (A, B и C).
• Как показано, 90% трафика отправляется в зону C, а 5% трафика отправляется в обе зоны A и B.
• Прокси-сервер sidecar и внутренние серверы сообщают о периодическом состоянии глобального балансировщика нагрузки. Это позволяет ему принимать решения, учитывающие задержки, затраты, нагрузку, текущие сбои и т.д.
• Глобальный балансировщик нагрузки периодически настраивает каждый прокси-сервер sidecar с текущей информацией о маршрутизации.

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

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

Чтобы сделать глобальную балансировку нагрузки возможной, балансировщик нагрузки, используемый в качестве data plane, должен обладать сложными возможностями динамической конфигурации. Для получения дополнительной информации по этой теме, пожалуйста, см. мой пост Envoy’s universal data plane API, а также service mesh data plane vs. control plane..

Эволюция от аппаратного до программного обеспечения

До сих пор этот пост только кратко упоминал аппаратное и программное обеспечение, прежде всего в контексте исторической пары балансировки нагрузки L4. Каковы отраслевые тенденции в этой области?

I’ve seen the new OSI stack of eight layers of software.
I think it’s more like this: pic.twitter.com/6K84IJYGAi
— Brian Glas (@infosecdad) July 21, 2017

Заключение и будущее балансировки нагрузки

Подводя итог, приведем ключевые выводы этой публикации:

• Балансировщики нагрузки являются ключевым компонентом в современных распределенных системах.
• Существуют два общих класса балансиров нагрузки: L4 и L7.
• Оба балансировщика нагрузки L4 и L7 актуальны в современных архитектурах.
• L4-балансировщики двигаются в направлении горизонтально масштабируемых распределенных консистентных решений хеширования.
• В связи с распространением динамических архитектур микросервиса сейчас активно инвестируются балансировщики L7.
• Глобальная балансировка нагрузки и разделение между control и data plane — это будущее балансировки нагрузки с инновационными и коммерческими возможностями.
• Индустрия агрессивно продвигается к аппаратным и программным продуктам OSS для сетевых решений. Я считаю, что традиционные поставщики балансировщиков нагрузки, такие как F5, будут сначала заменены программным обеспечением OSS и облачными поставщиками.

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

Балансировка нагрузки в информационных системах

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

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

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

Цели и варианты распределения нагрузки

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

Если говорить о целях, то наиболее часто это:

1. Удовлетворение запросов каждого пользователя. Системные ресурсы должны выделяться на обработку каждой заявки. Ситуации, когда обрабатывается один запрос, в то время как все остальные ожидают своей очереди должны быть исключены.
2. Высокая эффективность работы каждого сервера. Нагрузка между всеми серверами, входящими в кластер, должна распределяться максимально равномерно. Нельзя допускать ситуацию, когда одни аппаратные устройства загружены на полную, а другие – простаивают.
3. Минимизация времени обработки запроса и отклика. Время от момента получения заявки от пользователя и до выдачи ему результата должно быть оптимизировано.
4. Предсказуемость. Изначально следует понимать, когда и при работе с какими нагрузками выбранный алгоритм будет максимально эффективным.
5. Способность к масштабированию. При наращивании системы выбранные рабочие алгоритмы должны справляться с поставленными задачами.

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

На практике широкое применение получили следующие методы распределения:

1. Статическое.
2. Псевдодинамическое.
3. Динамическое.

Статическое распределение

Предполагает постоянную привязку определенного пользователя к конкретному серверу. Распределение зачастую осуществляется по двум критериям:

1. Количество пользователей. На примере это выглядит так. У вас 2000 пользователей и 2 сервера в наличии. Если оборудование идентичное, то нагрузка между ним распределяется равномерно: по 1000 пользователей на каждый. Причем пользователей, которые будут по списку в диапазоне от 1 до 1000 система автоматически будет направлять на один сервер, а с 1001 до 2000 – на другой. Если же аппаратные мощности разные, то нагрузку можно распределить в соответствии с их производительностью, как пример 60/40.
2. Географическое пребывание. Выполняется территориальное распределение. Те пользователи, которые находятся в пределах 500 км (как пример) от одного сервера будут направляться на него, а остальные – на другой.

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

Псевдодинамическое распределение

Продолжим рассматривать предыдущие примеры. Что будет, если активность пользователей 1-1000 из списка станет в какой-то момент времени ощутимо больше, чем из группы 1001-2000? Как будет работать система, если общее число пользователей повысится? Что произойдет, если с одной географической области будет направляться гораздо больше запросов, чем с другой? Активность пользователей также может зависеть от сезона, дня недели, времени суток и других параметров.

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

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

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

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

Динамическое распределение

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

Вариант программных балансировщиков – прокси серверы. Они мгновенно «оценивают» текущее состояние и перенаправляют пользователей к тому узлу, который сможет их обслужить в данный момент времени.

Уровни балансировки

Наряду с методами балансировки, существует и такое понятие, как уровни балансировки. Этот параметр определяет соответствие выбранных алгоритмов работы уровням OSI-модели, в частности:

1. Сетевому.
2. Транспортному.
3. Прикладному.

Особенности балансировки систем на сетевом уровне

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

• Использование DNS-сервера. В этом случае на имя одного домена выделяется несколько адресов. Поступающий пользовательский запрос будет распределяться между ними при помощи алгоритма Round Robin.
• Применение дополнительного маршрутизатора. Выполняется балансировка на IP-адресу.
• Создание NLB-кластера. Здесь серверы разделяются на те, которые принимают входящие запросы и те, которые будут заниматься вычислениями. Подобное решение на практике применяет корпорация Майкрософт.
• Размещение однотипных сервисов с идентичными адресами в разных интернет-регионах. Актуально при выполнении балансировки по территориальному признаку. На практике такой вариант применяют многие CDN. Также на ней работает и Anyсast DNS-технология.

Особенности балансировки систем на транспортном уровне

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

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

Особенности балансировки систем на прикладном уровне

В данном случае балансировщик также работает как прокси-сервер, но только «умный». Он воспринимает запросы, поступающие от пользователей, анализирует их и перенаправляет на те серверы, которые смогут дать исчерпывающий ответ. То есть здесь уже оценивается характер контента, который нужен клиенту. Яркий пример такого балансировщика – веб-сервер Nginx. В нем предусмотрен модуль Upstream, который и распределяет запросы между фронтендом и бэкендом.

На балансировщике такого типа работает и pgpool. Это своего рода промежуточное звено между клиентом и сервером. Он способен передавать к одной машине запросы на чтение, к другой – на запись.

Потенциальные риски при балансировке нагрузки

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

Хранение сессии.

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

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

Если ищите отличный и долговечный результат в балансировке нагрузки, общайтесь за услугами к специалистам компании «Xelent». Уже сегодня вы можете получить компетентные консультации по телефону или через форму обратной связи.