Балансировка нагрузки в распределенных системах. Балансировка нагрузки: основные алгоритмы и методы

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

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

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

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

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

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

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

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

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

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

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

Очереди

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

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

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

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

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

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

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

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

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

| |

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

Инфраструктура без балансировки нагрузки выглядит так:

Пользователь → Интернет → Веб-сервер → Сервер баз данных

То есть пользователь подключается непосредственно к веб-серверу (к вашему домену, yourdomain.com). И если этот единственный веб-сервер прекращает работу, пользователь не сможет попасть на сайт. Кроме того, если множество пользователей одновременно попытается открыть сайт, сервер может попросту не справиться с нагрузкой: сайт будет загружаться очень медленно или же пользователь вовсе не сможет открыть его.

Устранить единую точку отказа можно с помощью балансировщика нагрузки и дополнительного веб-сервера на бэкэнде.

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

Пользователь
↓
Интернет
↓
Балансировщик нагрузки
↓ ↓
Веб-сервер 1 Веб-сервер 2
(реплицируемые серверы)

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

Какой трафик обрабатывает балансировщик нагрузки?

Администраторы балансировщиков создают правила для четырех основных типов трафика:

• HTTP: стандартная балансировка HTTP распределяет запросы согласно еханизмам HTTP. Балансировщик устанавливает заголовки X-Forwarded-For, X-Forwarded-Proto и X-Forwarded-Port, чтобы передать серверу бэкэнда информацию исходного запроса.
• HTTPS: балансировка HTTPS работает почти так же, как HTTP, но с поддержкой шифрования. Шифрование данных обрабатывается одним из двух способов: с помощью ретрансляции SSL (поддерживает шифрование вплоть до бэкэнда) или SSL-терминации (дешифровку данных выполняет балансировщик, после чего трафик отправляется на бэкэнд в незашифрованном виде).
• TCP: приложения, которые не используют HTTP или HTTPS, могут распределять трафик TCP. Например, можно разделить трафик кластера базы данных.
• UDP: совсем недавно некоторые балансировщики нагрузки добавили поддержку основных интернет-протоколов, которые используют UDP (например, DNS и syslogd).

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

Как балансировщик выбирает сервер на бэкэнде?

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

Проверка состояния сервера

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

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

1. Согласно алгоритму Round Robin (или алгоритм кругового обслуживания) серверы получают трафик последовательно. Балансировщик выбирает первый сервер в списке и передаёт ему первый запрос, второй сервер получит второй запрос и т.д.
2. Балансировщик выбирает для обслуживания трафика наименее загруженный сервер (то есть сервер с наименьшим количеством подключений на текущий момент). Такой алгоритм особенно полезен, если для обслуживания трафика нужны длинные сессии.
3. Балансировщик нагрузки выбирает сервер на основе хэша исходного IP запроса (например, на основе IP-адреса посетителя). При этом все запросы конкретного пользователя будут обслуживаться одним и тем же сервером бэкэнда.

Обработка состояния

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

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

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

Пользователь
↓
Интернет
↓ ↓
Балансировщик 1 Балансировщик 2

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

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

Изначально балансировщики позиционировались как специализированные устройства, предназначенные для замены/развития существующего в то время решения задачи балансирования web-сервисов при помощи технологии DNS (Domain Name Service) по методу Round-Robin. Без использования балансировщиков DNS-сервис разрешал имя хоста только в один IP-адрес, а в случае их применения - в один из нескольких IP-адресов из заданного списка. При повышении требований к производительности вычислительного комплекса администратор мог просто установить в системе дополнительный сервер и добавить его IP-адрес в список балансирования.

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

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

Вторая проблема состояла в том, что доступность приложений, TCP/UDP-портов или самих серверов никак не отслеживалась. Если сервер балансирования выходил из строя, DNS-сервер все равно продолжал направлять на него запросы клиентов. В итоге пользователи получали сообщение «сервер не доступен». Если вышедший из строя сервер (или несколько машин) выводился администратором из списка балансирования вручную, клиенты все равно продолжали пытаться осуществлять доступ к нему по его IP-адресу. В настоящее время эта проблема частично решается уменьшением значения параметра TTL в DNS-ответе. Но в случае если на DNS-сервере или рабочей станции клиента установлено игнорирование значений параметра TTL или соответствующая DNS-запись настроена статически, проблема потери доступа остается актуальной. И методы ее решения на сегодня отсутствуют.

Первым коммерческим продуктом, обеспечивающим балансирование нагрузки между IP-серверами, стало устройство Cisco LocalDirector, разработанное в июле 1996 года. Первые балансировщики (в том числе Cisco LocalDirector) были призваны не только снять проблемы балансирования нагрузки по DNS, по большому счету, они предназначались для управления мультисерверной инфраструктурой, в том числе для ее корректного масштабирования.

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

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

Современные балансировщики нагрузки позволяют производить контроль, распределение и изменение трафика приложений, основываясь на значениях заголовков L2-L7 сетевой модели OSI. По сути балансировщики нагрузки распознают приложения и обеспечивают их «доставку» пользователям, поэтому последнее время их стали называть контроллерами доставки приложений (Application Delivery Controller).

Глобально или локально?

Системы балансирования нагрузки делятся на два типа: глобальный и локальный. Локальное балансирование нагрузки предназначено для распределения клиентских запросов между группой серверов, расположенных в пределах одной площадки. В данном случае балансировщики выступают в качестве промежуточного звена между клиентами и серверами в течение всего времени их взаимодействия. При локальном балансировании распределение клиентских запросов между серверами выполняется на основании значений заголовков L3-L7 устанавливаемого подключения.

Глобальное балансирование предназначено для распределения клиентских запросов между площадками. В данном случае системы не участвуют в передаче клиент-серверного трафика, а только перенаправляют клиентов на ту или иную площадку. При глобальном балансировании нагрузки распределение клиентских запросов между площадками выполняется при помощи механизмов DNS, HTTP redirect и т.п.

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

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

• почтовые системы;
• web-системы (отдельные web-серверы и Frontend-сегменты сложных прикладных систем);
• системы DNS;
• системы контроля доступа (Firewall).

СИСТЕМЫ БАЛАНСИРОВАНИЯ НАГРУЗКИ ДЕЛЯТСЯ НА ДВА ТИПА: ГЛОБАЛЬНЫЙ И ЛОКАЛЬНЫЙ

Глобальное балансирование нагрузки используется преимущественно контент-провайдерами для осуществления сервисов по резервированию между географически распределенными площадками. Данный тип системы чаще всего реализуется на основе технологий DNS и HTTP redirect. Недостатком глобального балансирования нагрузки является достаточно длительное время восстановления сервисов (от пары до десятков секунд) в случае выхода из строя отрезка сети или целой площадки. К тому же возможны ситуации, когда клиентские системы игнорируют значение DNS TTL, что приводит к простою доступа к сервисам вплоть до 24 часов.

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

Дополнительные возможности

Балансировщики нагрузки обладают дополнительными функциональными возможностями. К наиболее востребованным относятся SSL-offloading, сжатие передаваемых данных HTTP и мультиплексирование TCP-соединений.

дает возможность минимизировать нагрузку на серверное оборудования ЦОД за счет переноса SSL-шифрования/дешифрования на балансировщики со встроенными аппаратными ускорителями. Этот функционал обычно используется в вычислительных комплексах, где требуется организовать безопасный доступ к сервисам для удаленных клиентов.

Сжатие передаваемых данных HTTP позволяет минимизировать объем передаваемого HTTP-трафика между серверами ЦОД и рабочими станциями удаленных пользователей, тем самым ускоряя работу прикладных систем. Наиболее распространенными протоколами сжатия являются gzip и deflate. Функция сжатия передаваемых данных HTTP поддерживается любым современным браузером. Схожую задачу решают специализированные устройства - аппаратные или программные оптимизаторы трафика. В отличие от балансировщиков их необходимо устанавливать как на стороне клиента, так и на стороне сервера. С другой стороны, в оптимизаторах трафика используется другой принцип работы (на базе кэширования), и есть возможность оптимизировать работу большого числа протоколов, а не только HTTP.

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

Функционал изменения заголовков L3-L7 и защиты от DoS/SYN-атак используется преимущественно в сегменте контент-провайдеров в корпоративном сегменте. Изменение заголовков L3-L7 позволяет заказчикам более гибко обрабатывать трафик приложений, контролируя доступ клиентов к сервисам. Защита от DoS-атак в соответствии с предустановленными сигнатурами предотвращает передачу вредоносного трафика серверному оборудованию. Защита от SYN-атак предупреждает перегрузку серверного оборудования «зависшими» подключениями за счет их принудительного разрыва (если нет подтверждения соединения с клиентской стороны).

Функционал перенаправления клиентских запросов на Cache-серверы применяется преимущественно в сегменте операторов связи. Он позволяет уменьшить трафик, передаваемый в сети сторонних операторов связи (соответственно уменьшается плата за peering), за счет перенаправления запросов пользователей на локальные Caсhe-серверы.

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

После того как мы обсудили теоретические аспекты внедрения балансировщиков нагрузки, предлагаю рассмотреть несколько реальных кейсов. Мы имеем опыт работы с разными моделями балансировщиков нагрузки: Cisco CSS/CSM, Cisco ACE, Brocade ADX, Radware Alteon (ранее Nortel), Radware OnDemand. Я хотел бы привести наиболее интересные примеры внедрения систем балансирования нагрузки на основе решений Cisco и Brocade.

Балансирование нагрузки между WEB-серверами с SSL-offloading
У одного из наших заказчиков - «ВымпелКом» («Украинские радиосистемы») - существовал ряд предпосылок для внедрения балансировщиков нагрузки. В компании было два независимых web-сервера, обеспечивавших работу абонентских сервисных приложений, при этом переключение нагрузки между web-серверами в случае выхода из строя одного из них производилось вручную. На активный web-сервер приходилась большая нагрузка (в том числе от SSL-шифрования/дешифрования).

Мы предложили решение на базе балансировщиков Cisco CSS11500. В результате их внедрение позволило включить оба web-сервера в активную обработку данных, тем самым увеличив производительность системы. SSL-шифрование и дешифрование перенесены с web-серверов на балансировщики нагрузки, благодаря чему высвободились дополнительные ресурсы web-серверов. Балансировщики нагрузки внедрены в существующую систему практически без изменения конфигурации сети (за исключением изменения правил NAT на граничном оборудовании для доступа в интернет).

Балансирование нагрузки между серверами системы Siebel CRM
Другой проект мы выполнили в «М.Видео». Там основными причинами внедрения балансировщиков нагрузки были наличие нескольких web-серверов и серверов приложений и необходимость надежного двухуровневого взаимодействия: «клиенты-web-серверы» и «web-серверы-серверы приложений». Компании требовался контроль доступности серверного оборудования по отдельным URL.

В проекте также использовались балансировщики Cisco CSS11500. Все web-серверы и серверы приложений были включены в активный процесс обработки данных, балансирование выполнялось на двух уровнях, а проверка доступности серверного оборудования - на основании контрольных URL.

Балансирование нагрузки между web-серверами социальной сети
Крупный контент-провайдер (социальная сеть) имел ряд важных предпосылок для внедрения балансировщиков нагрузки. Среди них наличие нескольких web-серверов, обрабатывающих огромные потоки данных (большое количество соединений и передаваемых данных), необходимость балансирования нагрузки на седьмом уровне модели OSI с изменением HTTP-заголовков и глобального балансирования нагрузки по весам между несколькими VIP локального балансирования. Помимо этого, компании требовалось контролировать доступность серверного оборудования по отдельным URL и ограничивать количество подключений к каждому из web-серверов.

Решение на базе балансировщиков Brocade ADX10000 позволило компании успешно решить вышеперечисленные задачи. Благодаря внедрению балансировщиков все web-серверы и серверы приложений были включены в активную обработку данных, проверка доступности серверного оборудования стала выполняться на основании контрольных URL. Балансировщики были включены в сеть в режиме One-Arm (запросы клиентов и ответы серверов поступали на одни и те же интерфейсы), что позволило не менять настройки серверного и сетевого оборудования.

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

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

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

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

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

Процедура балансировки осуществляется при помощи целого комплекса алгоритмов и методов, соответствующим следующим уровням модели OSI:

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

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

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

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

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

Этот вид балансировки является самым простым: клиент обращается к балансировщику, тот перенаправляет запрос одному из серверов, который и будет его обрабатывать. Выбор сервера, на котором будет обрабатываться запрос, может осуществляться в соответствии с самыми разными алгоритмами (об этом ещё пойдёт речь ниже): путём простого кругового перебора, путём выбора наименее загруженного сервера из пула и т.п.

Иногда балансировку на транспортном уровне сложно отличить от балансировки на сетевом уровне. Рассмотрим следующее правило для сетевого фильтра 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.

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

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

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

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

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

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

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

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

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

Round Robin

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

Это — усовершенствованная версия алгоритма 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дреса клиента. Как указано в документации (см. ссылку выше), «метод гарантирует, что запросы одного и того же клиента будет передаваться на один и тот же сервер». Если закреплённый за конкретным адресом сервер недоступен, запрос будет перенаправлен на другой сервер. Пример фрагмента конфигурационного файла:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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