Когда мощности сервера уже не хватает, встает вопрос, каким путем идти дальше. Апгрейд часто не дает пропорционального прироста и к тому же не обеспечивает требуемой отказоустойчивости. Поэтому самым верным шагом будет установка второго сервера, который возьмет на себя часть нагрузки. Остается выбрать приложение, которое будет обеспечивать балансировку.
Из чего выбирать?
Решения для балансировки сетевой нагрузки только на первый взгляд выглядят одинаково. На самом деле в процессе участвует множество технологий и алгоритмов, поэтому найти два одинаковых продукта невозможно. Неочевидными особенностями может быть поддержка определенных протоколов (например, только 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
HAProxy — балансировщик нагрузки и прокси-сервер уровня приложений Layer7 для TCP и HTTP. Проект начинался как очень простой HTTP-прокси Webroute, но постепенно оброс новыми возможностями. Особенностью HAProxy является использование для регулирования соединений cookie и контента, он встраивает cookie и проверяет содержимое пакета при подключении. Анализ пакетов на Layer7 позволяет фильтровать несанкционированный трафик и протоколы. Проверяя HTTP-запрос при помощи регулярных выражений, можно задать любые правила для выбора сервера, например реализуя ACL и геолокацию. В случае необходимости обработки IP-клиента на конечном сервере можем сохранить его в X-Forwarded-for. Движок стабилен, безопасен, оптимизирован, в результате HAProxy способен одновременно обрабатывать большое количество подключений (20 тысяч в секунду и более).
Обработкой всех подключений занимается один процесс, за счет оптимизации и планировщика обеспечивающий большое количество одновременных соединений на очень высоких скоростях. Такие системы не слишком хорошо масштабируются на многопроцессорных системах, но не болеют блокировками и ограничениями памяти. Но здесь мы не увидим продвинутых функций вроде поддержки SSL и keep-alive — по утверждению разработчиков, они усложняют и «утяжеляют» процесс. Отказоустойчивость HAProxy-сервера достигается через использование демона keepalived, проверяющего его работоспособность, синхронизация с резервным сервером (протокол VRRP) обеспечивает дублирование.
Предоставляет логирование соединений и разнообразные отчеты (статистика выводится на отдельном порту). Ориентирован в первую очередь на веб-сайты, но используется и в других сценариях, например в качестве балансировщика для multi-master серверов MySQL. Поддерживается фильтрация пользователей и подключение к тому же серверу (для RDP и HTTP), аутентификация HTTP.
HAProxy в качестве балансировщика используется в нескольких компаниях из списка Fortune 500: Amazon RDS, GitHub, Stack Overflow, Server Fault, Twitter…
Возможности расширяются при помощи аддонов, их полный список есть на сайте. Все настройки производятся при помощи конфигурационного файла (на сайте есть примеры). Кроме того, известны два интерфейса сторонних разработчиков: коммерческий веб Snapt и свободный HATop.
Работает на нескольких архитектурах x86, x86_64, Alpha, SPARC, MIPS, PARISC. Официально поддерживает Linux 2.6.32+ (рекомендуется для максимальной производительности) и 2.4, Solaris 8–10, FreeBSD, OpenBSD. Установка и настройка тривиальны, хотя пакет в репозиториях не присутствует. Проект предлагает исходный код под лицензией GPL v2 и готовые бинарники под Linux/x86 Glibc 2.2 и Solaris8/Sparc.
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.
Crossroads
Crossroads обеспечивает балансировку нагрузки к любым TCP-сервисам, поэтому подходит не только для HTTP(S), но и для SMTP, SSH, баз данных и других. В обычном варианте он просто гарантирует подключение к бэкенду, не вникая во внутренности, и обеспечивает в этом режиме максимальную производительность. Один сервер может обслуживать несколько сайтов с разными бэкендами и протоколами. Но есть специальный режим HTTP mode, при котором обрабатываются и при необходимости меняются заголовки сеанса. Это обеспечивает возможность перенаправления пользователя на тот же сервер (session stickiness) и сохранение IP клиента в X-Forwarded-For. Сам по себе HTTP mode и особенно модификация пакета влияет на производительность (потери до 30%).
По умолчанию клиент перенаправляется на сервер, принимающий меньше подключений, но при необходимости алгоритм легко изменить на Round Robin, Least-Connections и First Available или определяться внешней программой или скриптом. Клиентов можно закреплять за определенным сервером (Hash sticky client), жестко или с возможностью подключения к другому серверу, если «свой» не отвечает. При возобновлении работы бэкенда он автоматически включается в работу. Возможно управление доступом к Crossroads на основе IP-адреса (allow и deny).
В версии 2.х все подключения обслуживает один процесс, работающий в пространстве пользователя, это положительно сказалось на скорости работы и на управлении. Может работать как stand-alone демон или запускаться через inetd. Удобно, что все настройки и команды можно отдавать на лету (при помощи утилиты xr), изменение параметров не требует перезапуска Crossroads. Например, настроим балансировку для двух веб-сайтов и серверов MySQL.
# /usr/sbin/xr --verbose -S --server http:0:80 --host-match www.host1.com --backend 192.168.1.10:80 --backend 192.168.1.20:80 --host-match www.host2.com --backend 192.168.2.10:80 --backend 192.168.2.20:80 2>&1 >> /var/log/xr.log
# /usr/sbin/xr --verbose --server tcp:0:3306 --backend 192.168.1.1:3306 --backend 192.168.1.2:3306 2>&1 >> /var/log/xr.log &
Статистика выводится при помощи веб-интерфейса, порт которого задается вместе с ключом -W (–web-interface). Также с его помощью можно изменить три параметра: максимальное количество соединений для Crossroads и для бэкендов, вес бэкендов.
Для удобства все их записывают в отдельный файл, который и указывают при загрузке, или используют специальный конфигурационный файл в формате XML (/etc/xrctl.xml, в поставке несколько готовых примеров).
Может быть запущен на любой POSIX-системе — Linux, OS X, Solaris. Проект предлагает исходные тексты (сборка проблем не вызывает), готовые пакеты доступны в репозиториях основных дистрибутивов.
Zen Load Balancer
Решение, несколько отличающееся от остальных участников обзора. Разработчики справедливо решили, что под балансировку выделяется отдельный сервер, а поэтому лучше сразу предоставить готовый дистрибутив, чтобы упростить развертывание, повысить производительность и безопасность. Основой Zen Load Balancer является оптимизированная и урезанная версия Debian 6. Поддерживается балансировка на Layer 4 для протоколов TCP, UDP и на Layer 7 для HTTP/HTTPS. Специальный режим L4xNAT позволяет настроить балансировку на транспортном уровне без учета номеров портов (фактически без привязки к сервису), в этом случае Zen просто пропускает через себя весь трафик, распределяя его по серверам. Есть у Zen и фишка — режим DATALINK. В этом случае Zen выступает в качестве шлюза по умолчанию, обеспечивая равномерную нагрузку на канал и резервирование при подключении к нескольким провайдерам (балансировка на Layer 3).
Реализовано несколько алгоритмов выбора бэкенда: Round Robin, по весу (Weight), по приоритету (Priority) или подключение к определенному серверу (Hash sticky client). Возможен возврат пользователя в открытую сессию, он определяется несколькими способами (по IP-адресу, сookie, запрашиваемому URL, по заголовку HTTP). Предусмотрено сохранение IP в X-Forwarded-for.
Технология FarmGuardian позволяет определять доступность сервисов при помощи специального скрипта и распределять по ним подключения. Zen может выполнять функцию SSL-прокси, шифруя поток к клиенту, на участке Zen — бэкенд данные идут в открытом виде. Поддерживается VLAN.
Из других особенностей можно назвать простую систему резервирования и восстановления конфигурации, работу нескольких балансировщиков в кластере, систему мониторинга и вывода различной статистики, в том числе и в виде наглядных графиков.
И главное — все настройки производятся при помощи веб-интерфейса (по умолчанию на HTTPS/444, логин/пароль — admin/admin). Предлагается две версии. Бесплатная только в x86-варианте и без технической поддержки. Ее возможностей вполне хватает для большинства сетей среднего размера. Платная версия предоставляется уже в x64-сборке. Развернуть готовую систему очень просто, на сайте доступна вся необходимая информация по настройкам (на английском).
Заключение
Как видим, выбирать есть из чего. Каждый продукт имеет свои сильные и слабые стороны, зная которые легко определиться, какой из них подходит для определенной ситуации. Так, HAProxy подкупает производительностью, BalanceNG — функциональностью, простотой в настройках. Pound отличается возможностью разборки HTTP, а Crossroads — гибкостью. Если все же нужен веб-интерфейс, то альтернативы Zen Load Balancer нет, ну если только не хочется платить за Snapt для HAProxy.
Облачные сервисы для балансировки нагрузки
С ростом популярности облачных сервисов все больше систем размещаются на внешних площадках, образуя гибридные облака. Большинство разработчиков предлагает ко всему прочему и возможность балансировки нагрузки, это очень удобно, так как не требует от клиента установки дополнительного оборудования и готово к применению почти сразу. Хотя возможностей по управлению такой способ дает, как правило, меньше. Все основные игроки уже предложили свои решения. Например, Amazon Route 53, являющийся частью Amazon Web Services и предоставляющий балансировку при помощи Round Robin DNS. Стоимость услуги небольшая и составляет один доллар в месяц, плюс 0,50 доллара за первый миллион запросов и 0,25 за каждый следующий. Предусмотрен удобный API для редактирования, добавления и удаления записей.
Также нужная функциональность доступна в специализированных облачных продуктах — WAF или решениях для защиты от DDoS. Например, сервис Akamai Global Traffic Management Akamai.
