Что такое Azure Load Balancer?
Балансировка нагрузки обозначает процесс равномерного распределения нагрузки (входящего сетевого трафика) в группе серверных ресурсов или серверов.
Служба Azure Load Balancer работает на уровне 4 модели OSI (Open Systems Interconnection). Она служит единственной точкой взаимодействия с клиентами. Load Balancer распределяет входящие потоки, поступающие на внешний интерфейс подсистемы балансировки нагрузки, в экземпляры серверных пулов. Эти потоки соответствуют настроенным правилам балансировки нагрузки и пробам работоспособности. В серверный пул могут входить Виртуальные машины Azure или экземпляры масштабируемого набора виртуальных машин.
Общедоступный Load Balancer обеспечивает исходящие подключения для виртуальных машин в виртуальной сети. Эти подключения выполняются путем преобразования их частных IP-адресов в общедоступные. Общедоступные Load Balancer используются для балансировки трафика, направленного из Интернета к виртуальным машинам.
Внутренний (или частный) Load Balancer используется там, где частные IP-адреса необходимы только в интерфейсной части. Внутренние Load Balancer используются для балансировки трафика внутри виртуальной сети. В гибридном сценарии ко внешнему интерфейсу Load Balancer можно подключиться из локальной сети.
Рисунок. Балансировка многоуровневых приложений с помощью общедоступных и внутренних Load Balancer
Дополнительные сведения об отдельных компонентах Load Balancer см. в статье Компоненты Azure Load Balancer.
Azure предоставляет набор полностью управляемых решений балансировки нагрузки для пользовательских сценариев.
В комплексных сценариях может быть целесообразно объединить эти решения. Сравнение параметров балансировки нагрузки Azure см. в статье Overview of load-balancing options in Azure (Общие сведения о параметрах балансировки нагрузки в Azure).
Зачем нужен Azure Load Balancer?
C помощью Azure Load Balancer можно масштабировать приложения и создавать службы с высоким уровнем доступности. Load Balancer поддерживает сценарии как входящих так и исходящих подключений. Load Balancer обеспечивает низкую задержку и высокую пропускную способность, а также увеличение масштаба до миллионов потоков для всех приложений, которые используют протоколы TCP и UDP.
Основные сценарии, которые можно выполнить с помощью подсистемы Azure Load Balancer (цен. категория «Стандартный»):
Балансировка нагрузки внутреннего и внешнего трафика на виртуальных машинах Azure.
Повышение доступности за счет распределения ресурсов в пределах зон и между ними.
Настройка исходящего подключения для виртуальных машин Azure.
Использование проб работоспособности для мониторинга ресурсов с балансировкой нагрузки.
Перемещение внутренних и внешних ресурсов Load Balancer в регионах Azure.
Обеспечение безопасности по умолчанию
Служба Load Balancer (цен. категория «Стандартный») построена на основе модели безопасности сети «Никому не доверяй».
Load Balancer (цен. категория «Стандартный») защищен по умолчанию и является частью вашей виртуальной сети. Это виртуальная сеть является частной и изолированной сетью.
Load Balancer (цен. категории «Стандартный») и стандартные общедоступные IP-адреса закрыты для входящих подключений, если их не открыть с помощью групп безопасности сети. Группы безопасности сети используются для явного разрешения допустимого трафика. Если у вас нет NSG в подсети или сетевого интерфейса ресурса виртуальной машины, трафик не может достичь этого ресурса. Дополнительные сведения о группах безопасности сети и способах их применения в вашем сценарии см. в статье Группы безопасности сети.
В Load Balancer (цен. категория «Базовый») по умолчанию открыт доступ к Интернету.
Load Balancer не хранит данные клиентов.
Цены и соглашение об уровне обслуживания
Сведения о ценах на Load Balancer (цен. категория «Стандартный») см. на странице цен Load Balancer. Load Balancer (цен. категория «Базовый») предоставляется бесплатно. См. соглашение об уровне обслуживания для Load Balancer. Load Balancer (цен. категория «Базовый») не имеет соглашения об уровне обслуживания (SLA).
Новые возможности
Подпишитесь на RSS-канал и просматривайте последние обновления компонентов для Azure Load Balancer на странице Обновления Azure.
Дальнейшие действия
Дополнительные сведения об ограничениях и компонентах Azure Load Balancer см. в статьях Компоненты Azure Load Balancer и Концепции Azure Load Balancer.
NSX Advanced Load Balancer – умный автомасштабируемый балансировщик нагрузки. Часть 1: архитектура и особенности
В этом посте я хочу рассказать о системе балансировки нагрузки VMware NSX Advanced Load Balancer (by Avi Networks), или NSX ALB. Чуть больше года назад компания VMware купила компанию Avi Networks, и тогда же система балансировки сменила название с Avi Vantage на NSX ALB, но старое название Avi также сохранилось. С тех пор происходит интеграция балансировщика с продуктами VMware, в первую очередь, NSX. Но при этом остается возможность его автономного использования.
В сети почти нет систематизированной информации про NSX ALB на русском языке, только документация от вендора на английском. Поэтому в первой части я обобщил разрозненные источники и сделал обзор продукта: рассказал про особенности, архитектуру и логику работы, в том числе для географически разнесенных площадок. Во второй части я описал, как развернуть и настроить систему. Надеюсь, обе статьи будут полезны тем, кто ищет балансировщик для работы в облачных средах и хочет быстро оценить возможности NSX ALB.
Особенности и возможности
NSX ALB – программно определяемый балансировщик нагрузки (Software Defined Load Balancer, SDLB) уровня Enterprise. Это нетипично для систем балансировки такого уровня, где обычно используются аппаратные балансировщики. Такой подход к построению системы дает NSX ALB легкую управляемость и горизонтальную и вертикальную масштабируемость.
Какие возможности предоставляет NSX ALB:
В реальном времени собираются данные об одновременно открытых соединениях, времени цикла приема-передачи (RTT), пропускной способности, ошибках, задержках ответа, задержках установления связи SSL, типах ответов и т.д. Вся информация в одном месте:
В блоке Log Analytics справа собирается статистика по основным параметрам соединения. Можно навести мышь на нужный раздел и быстро ознакомиться.
Кроме того, в NSX ALB есть:
Архитектура и схема работы NSX ALB
Схема работы NSX ALB построена на стандартных принципах для большинства SDLB. Серверы, предоставляющие сервис для балансировки, объединяются в пулы (pools). Над пулами администратор системы создает виртуальные сервисы (Virtual Services, VS). Они содержат параметры балансируемого сервиса, например: тип приложения, алгоритм балансировки, настройки подключения. Также VS предоставляют клиентам внешний виртуальный IP-адрес (Virtual IP, VIP) для доступа к балансируемому сервису.
Посмотрим подробнее, как выглядит архитектура:
Ключевой элемент системы – контроллер (Avi Controller). Он отвечает за автоматическое наращивание мощности и централизованно управляет VS. Можно развернуть в инфраструктуре одиночный контроллер или отказоустойчивый кластер контроллеров.
В отказоустойчивом варианте кластер контроллеров состоит из 3 узлов. Один из узлов становится ведущим (leader), остальные ведомыми (follower). Все 3 узла активны и распределяют нагрузку между собой. Основные сценарии работы кластера контроллеров:
Контроллер может оценивать нагрузку и добавлять новые SE или удалять не загруженные. За счет такой архитектуры NSX ALB может масштабироваться как горизонтально – увеличивая число SE, так и вертикально – наращивая мощности каждой SE.
Чем больше сервисов балансирует SE, тем больше сетевых интерфейсов задействуется. На подробной схеме ниже мы видим 2 типа сетей:
Для каждого VS нужно определить параметры SE, на которых будет размещаться сервис. Эти параметры задаются в группе SE (SE Group). При создании VS мы выбираем группу SE: можно указать группу по умолчанию (Default Group) или создать новую группу, если для VS нужны особые настройки виртуальной машины.
От выбранной группы будет зависеть, как будут размещаться новые VS. Например, если в системе уже развернуты SE дефолтной группы и на этих SE еще есть ресурсы, то новый VS с указанной дефолтной группой разместится на них. Если же мы укажем для VS новую группу, под него будут развернуты новые SE c другими параметрами.
На уровне группы SE задаем следующие настройки размещения VS:
Пропускная способность в расчете на 1 vCPU составляет примерно 40 тысяч подключений/с и в среднем – 4 ГБ/с. Этот показатель отличается для разных уровней балансировки и используемого протокола: на L4 он больше, на L7 меньше, из-за необходимости анализа трафика, при SSL – значительно меньше, из-за необходимости шифрования.
Архитектура и схема работы для географически разнесенных серверов
В обычном виртуальном сервисе мы можем добавлять серверы в пул только из одного облака. Даже если мы добавим на контроллере несколько облаков одновременно, мы не сможем совместить серверы из разных облаков в рамках одного VS. Эту задачу решает сервис глобальной балансировки GSLB. Он позволяет балансировать географически разнесенные серверы, находящиеся в разных облаках.
В рамках одного глобального сервиса можно одновременно использовать и приватные, и публичные облака. Вот случаи, когда может понадобиться GSLB:
Схема работы вкратце: балансировку производит локальный сервис DNS, развернутый внутри NSX ALB. Клиент отправляет запрос подключения к сервису по FQDN-имени. DNS отдает клиенту виртуальный IP локального VS в наиболее оптимальном облаке. Наиболее оптимальное облако сервис выбирает на основе алгоритма балансировки, данных о доступности локальных VS на Health Monitor и географического положения клиента. Можно задавать разные алгоритмы балансировки – как на уровне глобального сервиса, так и на уровне GSLB.
Как видно из схемы GSLB, в ее основе лежат элементы предыдущей схемы: пулы серверов, над ними локальные виртуальные сервисы (VS) с локальными виртуальными IP (VIP) и служебные виртуальные машины (SE). При построении GSLB появляются новые элементы.
Глобальный сервис (global VS) – сервис, балансируемый между географически разнесенными серверами или приватными и публичными облаками.
GSLB-сайт (GSLB Site) включает контроллер и управляемые им SE, расположенные в одном облаке. Для каждого сайта можно задать геолокацию по широте и долготе. Так GSLB сможет выбирать пул серверов по удаленности от клиента.
Сайты GSLB на основе системы NSX ALB делятся на ведущие (leader) и ведомые (follower). Как и в случае с контроллерами, такая схема обеспечивает отказоустойчивость сервиса GSLB.
Ведущий сайт принимает решения по балансировке, обрабатывает подключения и осуществляет мониторинг. Изменить конфигурацию GSLB можно только с контроллера ведущего сайта.
Ведомые сайты могут быть активными и пассивными.
Глобальный пул (global pool) отличается от локального пула, который содержит локальные серверы. В глобальном пуле можно объединить географически разнесенные виртуальные сервисы с разных сайтов. Другими словами, глобальный пул содержит локальные VS, которые заведены на уровне GSLB-сайтов.
Балансировка подключений между серверами глобального пула производится:
Пример балансировки между глобальными пулами. Вот как глобальный VS будет распределять подключения в этой схеме:
Пул GslbPool_3 имеет приоритет 10 и будет предпочтительнее для клиентских подключений. Из этих подключений 40% нагрузки будет поступать на VS-B3 и 60% на VS-B4. Если GslbPool_3 станет недоступен, все клиентские подключения полностью перейдут на GslbPool_2, а нагрузка между VS-B3 и VS-B4 распределится равномерно.
Локальные DNS содержат записи с FQDN-именами балансируемых через него сервисов.
GSLB DNS – режим работы локального DNS VS, который используется для балансировки подключений между GSLB-сайтами.
Локальный DNS VS начинает выполнять роль GSLB DNS, когда мы выбираем его в качестве DNS-сервиса для поднятого GSLB. Такой DNS VS должен быть развернут на всех сайтах, включенных в глобальные пулы.
GSLB добавляет записи с FQDN-именами глобальных сервисов в каждый из локальных DNS. NSX ALB вносит в эту запись виртуальные IP локальных VS со всех сайтов, включенных в пул глобального VS. Эти дополнительные VIP добавляются автоматически с добавлением в пул новых локальных VS. Данные в записях обновляются по мере накопления информации о загрузке сервиса, доступности серверов и удаленности клиентов от сайтов. Когда новый клиент подключается по FQDN, один из локальных DNS выдает VIP-адрес локального VS, учитывая эти накопленные актуальные данные.
Как развернуть и настроить систему NSX ALB, а также поднять в ней сервис GSLB, я описал во второй части этой статьи.
Балансировка нагрузки с помощью AWS ELB
Всем привет! Уже сегодня стартует курс «AWS для разработчиков», в связи с чем мы провели соответствующий тематический вебинар, посвященный обзору ELB. Мы рассмотрели виды балансировщиков и создали несколько инстансов EC2 с балансировщиком. А также изучили другие примеры использования.
Прослушав вебинар, вы будете:
Введение
Что такое Elastic Load Balancer, можно увидеть на диаграмме ниже, где представлен простейший пример:
Load Balancer принимает реквесты и распределяет их по инстансам. У нас есть один отдельный инстанс, есть Lambda-функции и есть AutoScaling-группа (группа серверов).
Типы AWS ELB
1. Рассмотрим основные типы:
Classic Load Balancer. Самый первый балансировщик от AWS, работает как на 4-м, так и на 7-м уровне OSI, поддерживаются HTTP, HTTPS, TCP и SSL. Он обеспечивает базовую балансировку нагрузки между несколькими инстансами Amazon EC2 и работает как на уровне запросов, так и на уровне соединения. Давайте его откроем (выделен серым):
Этот балансер считается устаревшим, поэтому рекомендуется к использованию лишь в отдельных случаях. Например, для приложений, которые были построены в сети EC2‑Classic. В принципе, нам никто не мешает его создать:
2. Network Load Balancer. Подходит для высокой нагрузки, работает на 4-м уровне OSI (можно использовать в EKS и ECS), поддерживаются TCP, UDP и TLS.
Network Load Balancer направляет трафик на целевые объекты в Amazon VPC и способен обрабатывать миллионы запросов в секунду при сверхнизких задержках. Кроме того, он оптимизирован для обработки моделей трафика с внезапной и изменяющейся нагрузкой.
3. Application Load Balancer. Работает на 7-м уровне, имеет поддержку Lambda, поддерживает правила на уровне заголовков и путей, поддерживаются HTTP и HTTPS.
Обеспечивает расширенную маршрутизацию запросов, ориентированную на доставку приложений, построенных на базе современных архитектур, в том числе микросервисы и контейнеры. Направляет трафик на целевые объекты в Amazon VPC, опираясь на содержимое запроса.
Для многих пользователей, Application Load Balancer первым делом заменил Classic Load Balancer, ведь TCP не так распространен в отличие от HTTP.
Создадим его тоже, в результате чего у нас уже будут два балансировщика нагрузки:
Компоненты Load Balance
Общие компоненты Load Balance (присущи всем балансировщикам):
Потом указываем S3Bucket — объектное хранилище Amazon:
Пример для Classic Load Balancer:
А вот в Application Load Balancer мы видим и немного другой интерфейс, и в целом другую логику:
Компоненты Load Balancer v2 (ALB и NLB)
Теперь подробнее рассмотрим балансировщики 2-й версии Application Load Balancer и Network Load Balancer. У этих балансировщиков есть свои компонентные особенности. Например, появилось такое понятие, как Target Groups — инстансы (и функции). Благодаря этому компоненту, у нас появилась возможность указывать, на какой из Target Groups мы хотим направлять трафик.
Говоря простым языком, в Target Groups мы указываем инстансы, куда будет приходить трафик. Если в том же Classic Load Balancer вы просто сразу подключаете интенсы к балансировщику, то в Application Load Balancer вы сначала:
Следующий компонент — Listener rules (правила для маршрутизации). Это уже касается только Application Load Balancer. Если в Network Load Balancer вы просто создаете Listener, и он шлет трафик на конкретную Target-группу, то в Application Load Balancer всё веселее и удобнее.
Теперь скажем пару слов про следующий компонент — Elastic IP (статические адреса для NLB). Если правила для маршрутизации Listener rules касались только Application Load Balancer, то Elastic IP касается только Network Load Balancer.
Создадим Network Load Balancer:
И как раз в процессе создания мы увидим, что нам дается возможность выбрать Elastic IP:
Elastic IP предоставляет единственный IP-адрес, который можно связать с разными экземплярами EC2 во времени. Если экземпляр EC2 имеет Elastic IP-адрес и этот экземпляр завершен или остановлен, можно немедленно связать новый экземпляр EC2 с адресом Elastic IP. При этом ваше текущее приложение не прекратит работу, так как приложения видят всё тот же IP-адрес, даже если реальный EC2 изменился.
Вот еще один юз-кейс на тему того, зачем нужен Elastic IP. Смотрите, мы видим 3 IP-адреса, но они не навсегда здесь останутся:
Amazon меняет их с течением времени, может делать это каждые 60 секунд (но на практике, конечно, реже). Значит, IP-адреса могут поменяться. А в случае с Network Load Balancer вы как раз можете привязать айпишник и указывать его в ваших правилах, политиках и т. п.
Делаем выводы
ELB обеспечивает автоматическое распределение входящего трафика по нескольким целевым объектам (контейнеры, инстансы Amazon EC2, IP‑адреса и функции Lambda). ELB способен распределять трафик с меняющейся нагрузкой как в одной зоне доступности, так и между несколькими зонами доступности. Пользователь может выбрать из трёх типов балансировщиков, обеспечивающих и высокую доступность, и автомасштабирование, и неплохую защиту. Всё это важно для обеспечения отказоустойчивости ваших приложений.
Балансировка нагрузки: основные алгоритмы и методы
Вопрос о планировании нагрузки следует решать ещё на ранней стадии развития любого веб-проекта. «Падение» сервера (а оно всегда происходит неожиданно, в самый неподходящий момент) чревато весьма серьёзными последствиями — как моральными, так и материальными. Первоначально проблемы недостаточной производительности сервера в связи ростом нагрузок можно решать путем наращивания мощности сервера, или же оптимизацией используемых алгоритмов, программных кодов и так далее. Но рано или поздно наступает момент, когда и эти меры оказываются недостаточными.
Приходится прибегать к кластеризации: несколько серверов объединяются в кластер; нагрузка между ними распределяется при помощи комплекса специальных методов, называемых балансировкой. Помимо решения проблемы высоких нагрузок кластеризация помогает также обеспечить резервирование серверов друг на друга.
Эффективность кластеризации напрямую зависит от того, как распределяется (балансируется) нагрузка между элементами кластера.
Балансировка нагрузки может осуществляться при помощи как аппаратных, так и программных инструментов. Об основных методах и алгоритмах и балансировки мы бы хотели рассказать в этой статье.
Уровни балансировки
Процедура балансировки осуществляется при помощи целого комплекса алгоритмов и методов, соответствующим следующим уровням модели OSI:
Рассмотрим эти уровни более подробно.
Балансировка на сетевом уровне
Балансировка на сетевом уровне предполагает решение следующей задачи: нужно сделать так, чтобы за один конкретный IP-адрес сервера отвечали разные физические машины. Такая балансировка может осуществляться с помощью множества разнообразных способов.
Балансировка на транспортном уровне
Этот вид балансировки является самым простым: клиент обращается к балансировщику, тот перенаправляет запрос одному из серверов, который и будет его обрабатывать. Выбор сервера, на котором будет обрабатываться запрос, может осуществляться в соответствии с самыми разными алгоритмами (об этом ещё пойдёт речь ниже): путём простого кругового перебора, путём выбора наименее загруженного сервера из пула и т.п.
Иногда балансировку на транспортном уровне сложно отличить от балансировки на сетевом уровне. Рассмотрим следующее правило для сетевого фильтра pf в BSD-системах: так, например, формально тут идет речь про балансировку трафика на конкретном порту TCP (пример для сетевого фильтра pf в BSD-системах):
Речь в нём идет о балансировке трафика на конкретном порту TCP.
Рассмотрим теперь другой пример:
В этом правиле речь о балансировке исходящего трафика на сетевом уровне. В нём не указано ни конкретного порта, ни конкретного протокола.
Различие между уровнями балансировки можно объяснить следующим образом. К сетевому уровню относятся решения, которые не терминируют на себе пользовательские сессии. Они просто перенаправляют трафик и не работают в проксирующем режиме.
На сетевом уровне балансировщик просто решает, на какой сервер передавать пакеты. Сессию с клиентом осуществляет сервер.
На транспортном уровене общение с клиентом замыкается на балансировщике, который работает как прокси. Он взаимодействует с серверами от своего имени, передавая информацию о клиенте в дополнительных данных и заголовках. Таким образом работает, например, популярный программный балансировщик HAProxy.
Балансировка на прикладном уровне
При балансировке на прикладном уровне балансировщик работает в режиме «умного прокси». Он анализирует клиентские запросы и перенаправляет их на разные серверы в зависимости от характера запрашиваемого контента. Так работает, например, веб-сервер Nginx, распределяя запросы между фронтендом и бэкендом. За балансировку в Nginx отвечает модуль Upstream. Более подробно об особенностях балансировки Nginx на основе различных алгоритмов можно прочитать, например, здесь.
В качестве ещё одного примера инструмента балансировки на прикладном уровне можно привести pgpool — промежуточный слой между клиентом и сервером СУБД PostgreSQL. С его помощью можно распределять запросы оп серверам баз данных в зависимости от их содержания,: например, запросы на чтение будут передаваться на один сервер, а запросы на запись — на другой. Подробнее о pgpool и специфике работы с ним можно почитать в этой статье).
Алгоритмы и методы балансировки
Существует много различных алгоритмов и методов балансировки нагрузки. Выбирая конкретный алгоритм, нужно исходить, во-первых, из специфики конкретного проекта, а во-вторых — из целей. которые мы планируем достичь.
В числе целей, для достижения которых используется балансировка, нужно выделить следующие:
Очень желательно также, чтобы алгоритм балансировки обладал следующими свойствами:
Round Robin
Round Robin, или алгоритм кругового обслуживания, представляет собой перебор по круговому циклу: первый запрос передаётся одному серверу, затем следующий запрос передаётся другому и так до достижения последнего сервера, а затем всё начинается сначала.
Самой распространёной имплементацией этого алгоритма является, конечно же, метод балансировки Round Robin DNS. Как известно, любой DNS-сервер хранит пару «имя хоста — IP-адрес» для каждой машины в определённом домене. Этот список может выглядеть, например, так:
С каждым именем из списка можно ассоциировать несколько IP-адресов:
DNS-сервер проходит по всем записям таблицы и отдаёт на каждый новый запрос следующий IP-адрес: например, на первый запрос — xxx.xxx.xxx.2, на второй — ххх.ххх.ххх.3, и так далее. В результате все серверы в кластере получают одинаковое количество запросов.
В числе несомненных плюсов этого алгоритма следует назвать, во-первых, независимость от протокола высокого уровня. Для работы по алгоритму Round Robin используется любой протокол, в котором обращение к серверу идёт по имени.
Балансировка на основе алгоритма Round Robin никак не зависит от нагрузки на сервер: кэширующие DNS-серверы помогут справиться с любым наплывом клиентов.
Использование алгоритма Round Robin не требует связи между серверами, поэтому он может использоваться как для локальной, так и для глобальной балансировки,.
Наконец, решения на базе алгоритма Round Robin отличаются низкой стоимостью: чтобы они начали работать, достаточно просто добавить несколько записей в DNS.
Алгоритм Round Robin имеет и целый ряд существенных недостатков недостатков. Чтобы распределение нагрузки по этому алгоритму отвечало упомянутым выше критериями справедливости и эффективности, нужно, чтобы у каждого сервера был в наличии одинаковый набор ресурсов. При выполнении всех операций также должно быть задействовано одинаковое количество ресурсов. В реальной практике эти условия в большинстве случаев оказываются невыполнимыми.
Также при балансировке по алгоритму Round Robin совершенно не учитывается загруженность того или иного сервера в составе кластера. Представим себе следующую гипотетическую ситуацию: один из узлов загружен на 100%, в то время как другие — всего на 10 — 15%. Алгоритм Round Robin возможности возникновения такой ситуации не учитывает в принципе, поэтому перегруженный узел все равно будет получать запросы. Ни о какой справедливости, эффективности и предсказуемости в таком случае не может быть и речи.
В силу описанных выше обстоятельств сфера применения алгоритма Round Robin весьма ограничена.
Weighted Round Robin
Это — усовершенствованная версия алгоритма Round Robin. Суть усовершенствований заключается в следующем: каждому серверу присваивается весовой коэффициент в соответствии с его производительностью и мощностью. Это помогает распределять нагрузку более гибко: серверы с большим весом обрабатывают больше запросов. Однако всех проблем с отказоустойчивостью это отнюдь не решает. Более эффективную балансировку обеспечивают другие методы, в которых при планировании и распределении нагрузки учитывается большее количество параметров.
Least Connections
В предыдущем разделе мы перечислили основные недостатки алгоритма Round Robin. Назовём ещё один: в нём совершенно не учитывается количество активных на данный момент подключений.
Рассмотрим практический пример. Имеется два сервера — обозначим их условно как А и Б. К серверу А подключено меньше пользователей, чем к серверу Б. При этом сервер А оказывается более перегруженным. Как это возможно? Ответ достаточно прост: подключения к серверу А поддерживаются в течение более долгого времени по сравнению с подключениями к серверу Б.
Описанную проблему можно решить с помощью алгоритма, известного под названием least connections (сокращённо — leastconn). Он учитывает количество подключений, поддерживаемых серверами в текущий момент времени. Каждый следующий вопрос передаётся серверу с наименьшим количеством активных подключений.
Существует усовершенствованный вариант этого алгоритма, предназначенный в первую очередь для использования в кластерах, состоящих из серверов с разными техническими характеристиками и разной производительностью. Он называется Weighted Least Connections и учитывает при распределении нагрузки не только количество активных подключений, но и весовой коэффициент серверов.
В числе других усовершенствованных вариантов алгоритма Least Connections следует прежде всего выделить Locality-Based Least Connection Scheduling и Locality-Based Least Connection Scheduling with Replication Scheduling.
Первый метод был создан специально для кэширующих прокси-серверов. Его суть заключается в следующем: наибольшее количество запросов передаётся серверам с наименьшим количеством активных подключений. За каждым из клиентских серверов закрепляется группа клиентских IP. Запросы с этих IP направляются на «родной» сервер, если он не загружен полностью. В противном случае запрос будет перенаправлен на другой сервер (он должен быть загружен менее чем наполовину).
В алгоритме Locality-Based Least Connection Scheduling with Replication Scheduling каждый IP-адрес или группа IP-адресов закрепляется не за отдельным сервером, а за целой группой серверов. Запрос передаётся наименее загруженному серверу из группы. Если же все серверы из «родной» группы перегружены, то будет зарезервирован новый сервер. Этот новый сервер будет добавлен к группе, обслуживающей IP, с которого был отправлен запрос. В свою очередь наиболее загруженный сервер из этой группы будет удалён — это позволяет избежать избыточной репликации.
Destination Hash Scheduling и Source Hash Scheduling
Алгоритм Destination Hash Scheduling был создан для работы с кластером кэширующих прокси-серверов, но он часто используется и в других случаях. В этом алгоритме сервер, обрабатывающий запрос, выбирается из статической таблицы по IP-адресу получателя.
Алгоритм Source Hash Scheduling основывается на тех же самых принципах, что и предыдущий, только сервер, который будет обрабатывать запрос, выбирается из таблицы по IP-адресу отправителя.
Sticky Sessions
Sticky Sessions — алгоритм распределения входящих запросов, при котором соединения передаются на один и тот же сервер группы. Он используется, например, в веб-сервере Nginx. Сессии пользователя могут быть закреплены за конкретным сервером с помощью метода IP hash (подробную информацию о нём см. в официальной документации). С помощью этого метода запросы распределяются по серверам на основе IP-aдреса клиента. Как указано в документации (см. ссылку выше), «метод гарантирует, что запросы одного и того же клиента будет передаваться на один и тот же сервер». Если закреплённый за конкретным адресом сервер недоступен, запрос будет перенаправлен на другой сервер. Пример фрагмента конфигурационного файла:
Начиная с версии 1.2.2 в Nginx для каждого сервера можно указывать вес.
Применение этого метода сопряжено с некоторыми проблемами. Проблемы с привязкой сессий могут возникнуть, если клиент использует динамический IP. В ситуации, когда большое количество запросов проходит через один прокси-сервер, балансировку вряд ли можно назвать эффективной и справедливой. Описанные проблемы, однако, можно решить, используя cookies. В коммерческой версии Nginx имеется специальный модуль sticky, который как раз использует cookies для балансировки. Есть у него и бесплатные аналоги — например, nginx-sticky-module.
Можно использовать метод sticky-sessions и в HAProxy — подробнее об этом можно прочитать, например, здесь.
Заключение
Эта статья по сути представляет собой введение в проблематику балансировки нагрузки. Обсуждение этой темы мы продолжим и в дальнейших публикациях. Если у вас есть вопросы, замечания и дополнения — добро пожаловать в комментарии. Будем также признательны, если вы поделитесь нетривиальными практическими примерами организации балансировки нагрузки для различных проектов.
Читателей, которые по тем или иным причинам не могут оставлять комментарии здесь, приглашаем в наш блог.
