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

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

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

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

Процедура балансировки осуществляется при помощи целого комплекса алгоритмов и методов, соответствующим следующим уровням модели 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

Добавить метки | |

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

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

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

То есть пользователь подключается непосредственно к веб-серверу (к вашему домену, 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-адрес перемещается между серверами бэкэнда.

балансировка нагрузки спаренных двигателей - — [А.С.Гольдберг. Англо русский энергетический словарь. 2006 г.] Тематики энергетика в целом EN twin engine load balancing … Справочник технического переводчика

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

Балансировка - Список значений слова или словосочетания со ссылками на соответствующие статьи. Если вы попали сюда из … Википедия

ГОСТ 19534-74: Балансировка вращающихся тел. Термины - Терминология ГОСТ 19534 74: Балансировка вращающихся тел. Термины оригинал документа: 2. n опорный ротор D. n Lagerrotor Е. n support rotor Single support rotor F. Rotor a n support Ротор, имеющий n опор Определения термина из разных документов:… … Словарь-справочник терминов нормативно-технической документации

Brocade Communications Systems - Brocade, Inc. Тип Публичная компания Листинг на бирже NASDAQ: BRCD Год основания … Википедия

Kerio winroute firewall - Тип межсетевой экран Разработчик Kerio Technologies ОС Windows Версия 6.7 (1 августа 2009) Лицензия … Википедия

Kerio Control - Тип межсетевой экран Разработчик Kerio Technologies Операционная система Windows Последняя версия 7.4.0 (30 октября 2012) Лицензия проприетарная Сайт … Википедия

Нагрузочное тестирование - (англ. Load Testing) определение или сбор показателей производительности и времени отклика программно технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе … Википедия

Тестирование производительности - В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия

Облачные вычисления - (англ. cloud computing), в информатике это модель обеспечения повсеместного и удобного сетевого доступа по требованию к общему пулу (англ. pool) конфигурируемых вычислительных ресурсов (например, сетям передачи данных,… … Википедия

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

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

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

Примитивные методы

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

Round robin DNS (циклический перебор)

Пожалуй, самый распространенный метод. Основан на том, что спецификация DNS позволяет создавать несколько одинаковых А-записей с отличными IP-адресами. Например, можно завести две записи для узла srv-01.company.com с различными IP-адресами принадлежащих, разным серверам. Дополнительно, должна быть включена специальная опция (Round robin) на DNS-сервере. В результате, при каждом новом запросе записи srv-01.company.com будут отдаваться разные IP-адреса, что приведет к равномерному распределению подключений между узлами.
Но, при всей легкости и дешевизне данного решения, имеется ряд ограничений. Во первых, нет никаких методов проверки доступности узлов. То есть, сервер может выйти из строя, но DNS все равно будет отдавать его IP-адрес клиентам. Во вторых, не учитывается число текущих сессий на том или ином узле. Может получиться ситуация, когда на одном из серверов, открытых сессий значительно больше чем на остальных, при этом подключения все равно будут распределяться равномерно. Ну и в-третьих, DNS не учитывает к какому серверу был подключен пользователь в прошлый раз. Возможно, что при каждом новом подключении, например, к терминалу или к веб-серверу, будет открываться новая сессия на другом узле, что может быть не желательно.
Отдельно, в этом пункте хочется выделить сервисы типа Amazon Route 53 . Это облачный DNS-хостинг позволяющий кроме стандартных функций, указывать «вес» одинаковых А-записей, что позволяет распределять входящие запросы более гибко. Кроме этого, возможна интеграция с облачным балансировщиком нагрузки Elastic Load Balancing доступным в Amazon Web Services, что позволяет добиться еще более тонкой балансировки.

Так же, к примитивным методам можно отнести балансирование вручную

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

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

Это самый универсальный и распространенный механизм. Одинаково применим для TCP и UDP протоколов, а соответственно им можно распределять трафик практически любого сервиса. На этом уровне во входящих пакетах проверяется лишь IP-адрес и номер порта назначения. В случае совпадения с одним из правил, трафик будет попросту перенаправлен на указанные сервера, с помощью механизма sNAT в установленном порядке. Содержимое пакетов не проверяется. Так же нет никаких особых техник проверки доступности вычислительных узлов. Выполняется простая проверка доступности адреса и порта. В случае если порт открыт, сервер считается доступным и к нему продолжают отправляться запросы.
По такому механизму работает большинство популярных программных и аппаратных балансировщиков, в том числе Network Load Balancing (NLB) используемый в Windows Server. Так же, к этой категории можно отнести популярные нынче облачные сервисы типа Elastic Load Balancing от Amazon, упомянутый выше.

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

Динамично развивающийся вид распределения нагрузки на уровне приложений. Такие балансировщики еще называют контроллерами доставки приложений. Ориентированы на работу с высокоуровневыми протоколами. В основном HTTP\HTTPS. Здесь, как и в случае с предыдущим видом описываются правила. При установке соединения на некотором порту, пакеты перенаправляются на указанные адреса и порты вычислительных узлов. Но, при выборе конкретного сервера для ретрансляции на него трафика, учитывается тип клиента, URL, содержимое cookie, запрашиваемый контент и некоторые другие параметры. Кроме этого, проверка доступности сервиса на вычислительных узлах, проверяется значительно интеллектуальнее. Например, может запрашиваться некоторый URL и проверяться его содержимое.
Еще одной отличительной чертой этого типа от L4 является то, что сервера в кластере могут быть не идентичными. Например, одни узлы могут поставлять статические данные типа фото и видео а другие серверы доставляют контент с помощью скриптов, HTML и CSS. В таком случае, могут быть созданы правила для каждого типа контента с особыми алгоритмами перенаправления трафика на различные группы серверов. В этой категории, так же существует еще один класс профильных балансировщиков, типа Citrix NetScaler . Это решение специализируется на распределении нагрузки и повышении производительности продуктов Citrix (XenApp, XenDesktop), а так же веб-приложений. Кроме продвинутой балансировки он умеет выполнять компрессию контента, мощное кэширование, обеспечивает шифрование, а так же анализ трафика и его фильтрацию. Это лишь небольшая часть его возможностей, которые заслуживают отдельной статьи.

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

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

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