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

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

Решения для балансировки сетевой нагрузки только на первый взгляд выглядят одинаково. На самом деле в процессе участвует множество технологий и алгоритмов, поэтому найти два одинаковых продукта невозможно. Неочевидными особенностями может быть поддержка определенных протоколов (например, только 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. В принципе, сложным его назвать нельзя, особенно учитывая, что на сайте проекта доступно более десятка готовых примеров, часто нужно лишь выбрать наиболее подходящий и отредактировать под себя.

HAProxy

Работает на нескольких архитектурах 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.

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.

, Amaliya , fireball , Goudron .
Перевод впервые был опубликован на сайте Хабрахабр

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

Рисунок 1.18: Балансировщик нагрузки

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

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

Рисунок 1.19: Множественные балансировщики нагрузки

Как и прокси, некоторые балансировщики нагрузки могут также направлять запросы по-разному, в зависимости от типа запроса. Они также известны как реверсивные (обратные) прокси.

Управление данными, специфичными для определенного сеанса пользователя, является одной из проблем при использовании балансировщиков нагрузок. На сайте электронной коммерции, когда у Вас есть только один клиент, очень просто позволить пользователям помещать вещи в свою корзину и сохранять ее содержимое между визитами (это важно, так как вероятность продажи товара значительно возрастает, если по возвращении пользователя на сайт, продукт все еще находится в его корзине). Однако если пользователь направлен к одному узлу для первого сеанса, и затем к другому узлу во время его следующего посещения, то могут возникать несоответствия, так как новый узел может не иметь данных относительно содержимого корзины этого пользователя. (Разве вы не расстроитесь, если поместите упаковку напитка Mountain Dew в Вашу корзину, и, когда вернетесь, ее там уже не будет?) Одно из решений может состоять в том, чтобы сделать сеансы <липкими>, так чтобы пользователь был всегда направлен к тому же узлу. Однако использование в своих интересах некоторых функций надежности, таких как автоматическая отказоустойчивость, будет существенно затруднено. В этом случае корзина пользователя всегда будет иметь содержание, но если их липкий узел станет недоступным, то будет необходим особый подход, и предположение о содержании корзины не будет больше верно (хотя, стоит надеяться, что это предположение не будет встроено в приложение). Конечно, данную проблему можно решить при помощи других стратегий и инструментов, как описанных в этой главе, таких как службы, так и многих других (как кэши браузера, cookie и перезапись URL).

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

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

Очереди

Рисунок 1.20: Синхронный запрос

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

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

Рисунок 1.21: Использование очередей для управления запросами

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

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

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

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

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

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

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

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

• сетевому;
• транспортному;
• прикладному.

Рассмотрим эти уровни более подробно.

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

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

Иногда балансировку на транспортном уровне сложно отличить от балансировки на сетевом уровне. Рассмотрим следующее правило для сетевого фильтра pf в BSD-системах: так, например, формально тут идет речь про балансировку трафика на конкретном порту TCP (пример для сетевого фильтра pf в BSD-системах):

Web_servers = "{ 10.0.0.10, 10.0.0.11, 10.0.0.13 }" match in on $ext_if proto tcp to port 80 rdr-to $web_servers round-robin sticky-address

Речь в нём идет о балансировке трафика на конкретном порту TCP.

Рассмотрим теперь другой пример:

Pass in on $int_if from $lan_net \ route-to { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) }\ round-robin

В этом правиле речь о балансировке исходящего трафика на сетевом уровне. В нём не указано ни конкретного порта, ни конкретного протокола.

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

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

Балансировка на прикладном уровне

В качестве ещё одного примера инструмента балансировки на прикладном уровне можно привести pgpool — промежуточный слой между клиентом и сервером СУБД PostgreSQL. С его помощью можно распределять запросы оп серверам баз данных в зависимости от их содержания,: например, запросы на чтение будут передаваться на один сервер, а запросы на запись — на другой. Подробнее о pgpool и специфике работы с ним можно почитать в этой статье).

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

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

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

Очень желательно также, чтобы алгоритм балансировки обладал следующими свойствами:

• предсказуемость : нужно чётко понимать, в каких ситуациях и при каких нагрузках алгоритм будет эффективным для решения поставленных задач;
;
• масштабирумость : алгоритм должен сохранять работоспособность при увеличении нагрузки.

Round Robin

Самой распространёной имплементацией этого алгоритма является, конечно же, метод балансировки Round Robin DNS. Как известно, любой DNS-сервер хранит пару «имя хоста — IP-адрес» для каждой машины в определённом домене. Этот список может выглядеть, например, так:

Example.com xxx.xxx.xxx.2 www.example.com xxx.xxx.xxx.3

С каждым именем из списка можно ассоциировать несколько IP-адресов:

Example.com xxx.xxx.xxx.2 www.example.com xxx.xxx.xxx.3 www.example.com xxx.xxx.xxx.4 www.example.com xxx.xxx.xxx.5 www.example.com xxx.xxx.xxx.6

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

Least Connections

Рассмотрим практический пример. Имеется два сервера — обозначим их условно как А и Б. К серверу А подключено меньше пользователей, чем к серверу Б. При этом сервер А оказывается более перегруженным. Как это возможно? Ответ достаточно прост: подключения к серверу А поддерживаются в течение более долгого времени по сравнению с подключениями к серверу Б.

Описанную проблему можно решить с помощью алгоритма, известного под названием 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

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

Sticky Sessions

Upstream backend { ip_hash; server backend1.example.com; server backend2.example.com; server backend3.example.com; server backend4.example.com; }

Начиная с версии 1.2.2 в Nginx для каждого сервера можно указывать вес.

Применение этого метода сопряжено с некоторыми проблемами. Проблемы с привязкой сессий могут возникнуть, если клиент использует динамический IP. В ситуации, когда большое количество запросов проходит через один прокси-сервер, балансировку вряд ли можно назвать эффективной и справедливой. Описанные проблемы, однако, можно решить, используя cookies. В коммерческой версии Nginx имеется специальный модуль sticky, который как раз использует cookies для балансировки. Есть у него и бесплатные аналоги — например, nginx-sticky-module .
Можно использовать метод sticky-sessions и в HAProxy — подробнее об этом можно прочитать, например,

Заключение

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

Теги:

• load balancing
• селектел
• selectel

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

Типы серверов, которые должны быть сбалансированы:

серверные кластеры;

межсетевые экраны;

серверы инспектирования содержания (такие как AntiVirus- или AntiSpam- серверы).

Обычно системы балансировки загрузки серверов используют возможности уровня L4 (UDP/TCP). При этом контролируется доступность сервера по IP-адресу и номеру порта и принимается решение: какому из доступных серверов следует переслать запрос. Наиболее часто для выбора сервера используется карусельный алгоритм (round-robin). В этом варианте предполагается, что все запросы создают одинаковую загрузку и длительность исполнения. В более продвинутых вариантах алгоритма используется уровень занятости сервера и число активных соединений.

Раньше возможности балансировки нагрузки встраивались в саму прикладную программу или операционную систему. Современные системы балансировки нагрузки должны удовлетворять следующим требованиям:

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

ускорять выполнение приложений в несколько раз;

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

Здесь важно учитывать, что доступность IP-адреса и порта еще не гарантирует доступа к приложению.

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

Довольно существенные преимущества может предоставить система GSLB (Global Server Load Balancing), которая способна решать задачу балансировки для произвольно расположенных ферм серверов с учетом их удаленности от клиента. Эта система может поддерживать несколько разных алгоритмов распределения нагрузки и обеспечивать оптимальное обслуживание клиентов, разбросанных по всему миру. Для администраторов система дает возможность формирования гибкой политики управления ресурсами.

Одним из способов ускорения обслуживания является кэширование. В случае хорошо сконфигурированного кэша доля запросов, удовлетворяемых кэшем, может достигать 40%. При этом ускорение обслуживания может быть улучшено в 30 раз.

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

Управление балансировкой нагрузки можно совместить с функцией прикладного межсетевого экрана (70% успешных вторжений использует уязвимости приложений) и с использованием SSL по VPN-туннелю. SSL – Secure Sockets Layer – криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером.

Для достижения максимальной пропускной способности и отказоустойчивости межсетевые экраны позволяют распределить или сбалансировать нагрузку, используя все имеющиеся каналы Интернета (серверов) одновременно. Например, можно избежать такой ситуации, когда передаваемые по сети пакеты идут через одного провайдера, в то время как выход в Интернет через другого провайдера простаивает без дела. Или распределить сервисы и направить трафик через все имеющиеся Интернет-каналы. Возможна настройка балансировки нагрузки, если соединения с провайдерами осуществляются с разными типами подключения (Static IP, PPPoE, PPTP/L2TP), а также – для балансировки трафика, проходящего через VPN-туннели, установленные на разных физических интерфейсах.

Рис. 4.12. Балансировка нагрузки по нескольким маршрутам

В межсетевых экранах D-Link серии NetDefend предусмотрена функция, предназначенная для балансировки сетевой нагрузки по разным маршрутам – Route Load Balancing (RLB ) , возможности которой обеспечивают:

балансировку трафика между интерфейсами на основе политик;

балансировку нагрузки трафика при одновременном множественном доступе в Интернет, пользуясь услугами двух и более провайдеров;

балансировку трафика, проходящего через VPN-туннели, установленные на разных физических интерфейсах.

Функция балансировки нагрузки в межсетевых экранах NetDefend активируется на основе таблицы маршрутизации путем создания объекта RLB Instance , в котором определены два параметра: таблица маршрутизации и RLB-алгоритм. С таблицей маршрутизации может быть связан только один объект Instance.

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

Есть возможность выбрать один из алгоритмов распределения нагрузки между Интернет-интерфейсами:

Алгоритм Round Robin распределяет нагрузку между интерфейсами WAN1 и WAN2 последовательно (поочередно). Каждый раз, когда возникает новая исходящая сессия с интерфейса LAN, выбирается интерфейс WAN1 или WAN2 для отправки пакетов. В дальнейшем, пакеты данной сессии будут использовать ранее определенный WAN-интерфейс. TCP-сессия открывается и закрывается на одном и том же WAN-интерфейсе.

Алгоритм Destination позволит избежать проблем с некоторыми протоколами при использовании балансировки, например FTP. Данный алгоритм работает аналогично алгоритму Round Robin, за исключением того, что все данные к удаленному хосту идут через тот интерфейс, через который соединение было установлено.

Значение Spillover определяет предельное значение нагрузки для основного WAN-порта (Routing → Route Load Balancing > Algoritm Setings ) . При достижении этой нагрузки за указанный период начнет использоваться второй WAN-порт (для новых сессий). Как только загрузка основного канала упадет, новые сессии будут открываться на нем.

Round Robin

Метрика каждого маршрута по умолчанию равна нулю. При использовании взаимосвязанных алгоритмов Round Robin и Destination можно устанавливать разные значения метрик, позволяющие создать приоритет выбора маршрутов. Маршруты с минимальным значением метрики будут выбираться чаще, чем маршруты с более высоким значением.

Если в сценарии с двумя Интернет-провайдерами (часто встречается выражение "ISP-провайдер", т.е. Internet Service Provider) требуется, чтобы большая часть трафика проходила через одно из ISP-подключений, то следует активировать RLB и назначить меньшее значение метрики для маршрута основного ISP-подключения (например, 90) относительно второго (например, 100).

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

Использование метрик маршрута с алгоритмом Spillover

При использовании алгоритма Spillover для каждого маршрута обязательно должна быть определена метрика. В этом случае система NetDefendOS всегда выбирает маршрут с самым низким значением метрики. Алгоритм не предназначен для работы с одинаковыми метрическими значениями маршрутов, поэтому администратору следует устанавливать различные значения метрик для всех маршрутов, к которым применяется алгоритм Spillover .

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

Можно создать несколько альтернативных маршрутов с различными метрическими значениями, для каждого из которых определена пороговая величина настроек алгоритма – Spillover Setting – для каждого интерфейса. Сначала выбирается маршрут с минимальной метрикой; после того как превышен допустимый порог настроек алгоритма, будет выбран следующий маршрут.

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

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

Балансировка нагрузки сети и НА-кластеризация (резервирование устройств) межсетевых экранов NetDefend

Высокий уровень сетевой отказоустойчивости достигается за счет использования двух межсетевых экранов NetDefend: основного устройства (master) и резервного устройства (slave). Основной и резервный межсетевые экраны взаимосвязаны и составляют логический HA-кластер.

Межсетевые экраны NetDefend не поддерживают балансировку нагрузки в НА-кластеризации устройств, т.е. распределение нагрузки между ними не обеспечиваетс , так как одно устройство всегда является активным (active), в то время как другое находится в режиме ожидания (passive).

Рис. 4.14. НА-кластеризация межсетевых экранов NetDefend

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

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

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

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

Балансировка вычислительной нагрузки

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

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

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

Статическая и динамическая балансировки

Следует различать статическую и динамическую балансировки.

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

Это объясняется тем, что:

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

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

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

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

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

Постановка задачи динамической балансировки

Цель балансировки загрузки может быть сформулирована следующим образом:

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

Представим распределенное приложение в виде графа. Пусть G p = {V, E} , V –множество вершин (задачи распределенного приложения), E – множество дуг графа – связи между задачами распределенного приложения. Пусть TM – множество моделей распределенных приложений, .

Задача балансировки ставится как задача отображения неизоморфных связных графов, B: TM -> NG , где TM – множество графов моделей, NG – множество графов – конфигураций компьютерной сети. Граф , определяется множеством вычислительных узлов C и множеством ребер Ed , обозначающих линии связи. Можно рассматривать NG как суперграф, содержащий все возможные (допустимые) графы G в качестве подграфов .

Таким образом, множество графов задач должны быть оптимальным образом отображено на множество графов вычислительной системы.

Методология практического решения задачи балансировки

Обычно практичное и полное решение задачи балансировки загрузки состоит из четырех шагов:

• Оценка загрузки вычислительных узлов.
• Инициация балансировки загрузки.
• Принятие решений о балансировке.
• Перемещение объектов.

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