Балансировка в облаках

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

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

Рис. 1. Принципы балансировки нагрузки: а) балансировка с пропуском трафика через одно устройство балансировки; б) балансировка средствами кластера; в) балансировка без пропуска трафика через одно устройство балансировки

Трафик через одно устройство

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

В методе преобразования сетевых адресов (Network Address Translation, NAT) система балансировки направляет полученный от клиента пакет назначенному серверу лишь после того, как заменит в пакете адрес получателя IP-адресом назначенного сервера и изменит IP-адрес отправителя на свой. Это позволяет скрывать от клиентов IP-адреса веб-серверов, так что они могут использовать любые IP-адреса, в том числе и частные. При этом веб-серверы не обязательно должны входить в один и тот же сегмент сети — достаточно, чтобы они могли взаимодействовать с использованием протокола IP. Данный метод применяется только для балансировки тех запросов, где не требуется создание сессий между пользователем и сервером, существующих продолжительное время, поскольку для каждого пользователя требуется выделить индивидуальный IP-адрес на внутреннем интерфейсе системы балансирования на все время сессии.

Отличием метода NAPT (Network Address Port Translation) является то, что система балансирования изменяет в заголовке уже не только IP-адреса, как в NAT, но и номера портов транспортного уровня. Это позволяет для каждого вновь поступившего запроса от нового уникального пользователя уже не выделять индивидуальный IP-адрес на внутреннем интерфейсе системы балансирования для сессии, а выделять уникальный номер порта транспортного уровня. Данный механизм балансировки можно реализовать на универсальных аппаратных платформах, на программных компонентах входящих в стандартные поставки современных операционных систем (natd в BSD, iptables в составе дистрибутивов Linux, RRAS в составе серверных сборок Windows и т. д.).

Примерами продуктов, в которых реализован подход NAPT, являются устройства XTM Firewall Appliance компании WatchGuard, универсальные маршрутизаторы Cisco 1900, межсетевой экран D-Link DFL-860 и т. п. Все они при поступлении запросов на внешний адрес выполняют трансляцию заголовка и перенаправляют запрос на один из внутренних адресов, которые присвоены серверам. На период установленной сессии на устройстве в таблице хранится соответствие внешнего IP-адреса, внешнего порта транспортного уровня, локального IP-адреса и локального порта. Устройства не анализируют возможности серверов, время отклика, доступность серверов и т. п. Они способны выполнять балансировку по алгоритмам последовательного перебора или на основании количества открытых сессий TCP на каждый из серверов. Чаще всего данная функциональность служит дополнением к основным функциям маршрутизатора или межсетевого экрана.

Балансировку с использованием трансляции заголовков на уровнях выше транспортного также называют проксированием. Прокси-сервер, меняя поля заголовков транспортного и уровня приложений, перенаправляет запрос на серверы, на которых расположены запрашиваемые ресурсы. В ряде случаев он может предоставить запрашиваемый ресурс вообще без подключения к какому-либо серверу. При этом прокси-сервер «кэширует» ответы от удаленных серверов и предоставляет сохраненную информацию в ответ на все последующие запросы. Прокси-сервер может распределять нагрузку между несколькими веб-серверами, которые могут обслуживать различные области приложения. В таком случае у прокси-сервера может возникнуть потребность в переформировании адресов каждой веб-страницы (преобразование имен ресурсов, доступных снаружи, в имена, доступные во внутренней сети). Прокси-сервер, который передает запросы и ответы в неизменном виде, обычно называется шлюзом или иногда туннелирующим прокси. Проксирование применяется в проектах mod_backhand для сервера Apache и в сервере nginx . При поступлении HTTP-запросов сервер перенаправляет их на заранее сконфигурированные серверы с одинаковыми ресурсами. В параметрах конфигурации можно задавать веса сконфигурированным серверам, допустимое время отклика и допустимое количество неуспешных запросов. Примером программного решения, использующего методологию проксирования запросов TCP/HTTP с более продвинутыми функциями управления перенаправлениями запросов, является HAProxy , позволяющий также выполнять балансировку приложений. HAProxy работает на платформах Linux, Free BSD и Solaris. На его базе выпускаются также аппаратно-программные платформы, предназначенные только для балансировки нагрузки.

Возможности систем балансировки на базе программных продуктов в части обеспечения сквозной производительности определяются потенциалом универсальных аппаратных платформ, на которых они функционируют. Так, для HAProxy была продемонстрирована возможность функционирования на скоростях до 10 Гбит/с и 40 тыс. одновременных сессий (без контроля системой балансировки времени обработки запросов серверами приложений). На базе HAProxy разрабатываются сервисы балансировки нагрузки Loadbalancer.org, которые используются совместно с облачными сервисами Amazon.

Примерами специализированных аппаратно-программных решений, выполняющих балансировку с использованием трансляции заголовков сетевого, транспортного и уровня приложений, являются Brocade Server Iron ADX, xBalancer компании Net Optics, Cisco ACE 4700 Application Control Engine, Equalizer E650GX компании Coyote Point и ряд других продуктов. Такие системы постоянно контролируют время ответа серверов, нагрузку на которые они распределяют, и анализируют количество запросов, которые были им отправлены. Данные сведения используются для последующего выравнивания загрузки серверных платформ. Дополнительно на эти устройства возможно вынесение функций формирования защищенного соединения SSL и сжатия данных, что позволяет значительно снизить нагрузку на серверы приложений. Такие решения обладают более высокой производительностью с сохранением всей функциональности. В частности, для Server Iron ADX заявленная сквозная производительность может достигать 70 Гбит/с, 16 млн сессий в секунду. При этом сохраняется вся функциональность по контролю за установленными сессиями на отдельные серверы. Большинство облачных платформ, предоставляющих сервисы SaaS, используют подобные аппаратно-программные решения для балансировки нагрузки внутри ЦОД совместно с решениями для балансировки нагрузки между ЦОД. В частности, Brocade Server Iron ADX используется в облачных сервисах Google, Yahoo, Apple, в программных продуктах корпоративного уровня, приложениях IBM, HP, Microsoft и т.д.

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

Кластер

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

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

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

Подобным образом работают механизмы балансировки сетевой нагрузки в кластерах Windows Server 2008 R2, Oracle Solaris Cluster, Open HA Cluster и Linux Virtual Server.

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

Балансировка без единого устройства

Данный вариант балансировки организуется путем отправки первоначального запроса от пользователя (например, запроса IP-адреса для установления соединения либо первого запроса на установление HTTP-сессии) на выделенный сервер-балансировщик. После получения запроса балансировщик указывает, с каким сервером приложений из инфраструктуры облака продолжать работу (возвращая соответствующий IP-адрес либо перенаправляя его средствами HTTP Redirect). Последующее взаимодействие происходит без участия балансировщика.

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

Реже используется балансировка средствами HTTP Redirect. Решения, использующие данный подход, позволяют задавать в конфигурации сервера, выполняющего балансировку, группу IP-адресов серверов приложений. Для каждого из них может быть задан в качестве параметра вес, позволяющий определить долю HTTP-запросов, которые отправляются на каждый из серверов приложений. Примером решений, использующих средства балансировки с применением механизмов HTTP Redirect, являются модули Mod_backhand для серверов Apache, а также Citrix NetScaler, оптимизирующий доставку веб-приложений.

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

Вместе с тем надежность распределенного приложения, созданного с помощью круговой DNS или средств HTTP Redirect, достаточно низкая: если один или более серверов, на которых содержится копия приложения, выходит из строя или останавливается на профилактику, то часть запросов «падает в пустоту». Отсутствие обратной связи не позволяет исключить сервер приложений из списка, на который перенаправляются пользователи. Кроме того, существующие решения балансировки нагрузки без пропуска трафика через одно устройство всего лишь делят запросы между всеми платформами, входящими в состав распределенного сервера, равномерно или пропорционально заранее заданным весам. Если же эти платформы имеют различные вычислительные ресурсы, различный набор установленных приложений, то статическое распределение запросов может привести к тому, что часть платформ окажется перегружена, а другие, наоборот, будут простаивать. И даже если все компьютеры в составе распределенного сервера абсолютно одинаковы, это не значит, что они будут обрабатывать запросы с одинаковой скоростью, ведь одному пользователю может понадобиться открыть статическую веб-страницу, а другой запустит на выполнение скрипты, требующие больших системных ресурсов. Кроме того, известно, что при повышении времени отклика от загруженного сервера пользователи частыми нажатиями на Refresh в своих браузерах начинают посылать обвальное количество запросов, моментально перегружающих машину.

Альтернативное решение

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

Таблица 1. Сравнительные характеристики существующих методов балансировки

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

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

Задачу оптимального распределения вычислительной нагрузки на концептуальном уровне можно сравнить с задачей наполнения поилок — нескольких бочек с разными геометрическими характеристиками водой, которая поступает через трубу с вентилями. Один раз в секунду дно бочек открывается, и вся вода из них попадает в поилки. Вода же, которая переливается через края бочек, уходит в землю бесцельно. Для исключения перелива необходимо выбрать такие регулирующие значения вентилей, чтобы вода в бочках держалась на одинаковом уровне. При увеличении потока воды уровень воды во всех бочках на момент сброса должен увеличиться на одинаковую величину, чтобы не допустить перелива воды ни в одной из бочек (необработанные запросы). Именно это позволит достигнуть максимального объема полезно употребленной воды (максимальное значение числа обработанных операций в многоузловых системах). Данный процесс можно представить на графике зависимости числа обработанных запросов от числа поступивших для системы, состоящей из двух узлов А и Б. При оптимальном распределении нагрузки — 1/3 запросов на А и 2/3 запросов на Б (рис. 2, а) — величина предельного суммарного числа обработанных запросов, при котором не происходит сброс, вдвое выше, чем для варианта, представленого на рис. 2, б (1/3 запросов приходится на Б и 2/3 запросов на А). Причина — быстрое достижение предела возможностей узла А и деградация производительности всей системы.

Рис. 2. Зависимость числа обработанных запросов от числа поступивших запросов

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

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

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

При этом все сложности взаимодействия с реальным оборудованием ложатся на плечи агента, который, в свою очередь, предоставляет стандартный интерфейс доступа к данным оборудования. Таким образом, платформа мониторинга по SNMP может общаться с агентами, созданными разными производителями оборудования и ПО. При помощи протокола SNMP информацию о системе можно получить через базу управляющей информации (Management Information Base, MIB), представляющей собой совокупность объектов, доступных для операций записи/чтения для каждого конкретного клиента, в зависимости от структуры и предназначения клиента. Наиболее широко применяется база Internet MIB, которую можно представить в виде дерева, описывающего структуру хранения данных. На каждой ветке могут находиться определенные данные или же происходить дальнейшее ветвление. Ветви дерева поименованы, например iso, org, dod, internet, mgmt, mib-2. Последовательность имен ветвей, которые требуется пройти для получения доступа к данным, формирует путь по дереву. Также путь к данным по дереву MIB может быть задан в виде уникального числового идентификатора OID, который использует идентификатор ветви на каждом ветвлении. Все требуемые для мониторинга аппаратных платформ параметры расположены в ветке. iso.org.dod.internet.mgmt.mib-2.host.

Для определения пропорций оптимальной балансировки нагрузки, используемых в системе балансирования, в УрФУ разработали алгоритм, в котором каждый узел получает значения загрузки процессора либо отдельных ядер за последнюю минуту. Данные значения располагаются в ветке. iso.org.dod.internet.mgmt.mib-2.host.hrDevice.hrProcessorTable.hrProcessorEntry.hrProcessorLoad. Предполагая, что число обработанных в предыдущий период запросов пропорционально загрузке процессора по всем узлам, и зная долю запросов, которые были обработаны узлом в предыдущий период, можно вычислить долю обработанных запросов в расчете на один процент использования процессора. Эта величина позволяет сделать вывод о существующих пропорциях в вычислительной мощности аппаратных платформ. А определив эти пропорции, их нужно использовать для последующей балансировки.

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

В рамках идущего в УрФУ проекта разрабатывается программный модуль-балансировщик, запускаемый в качестве сервиса на DNS-сервере с поддержкой BIND (рис. 3). В качестве исходных данных модуль балансировки получает имя зоны, для которой требуется выполнить балансировку. После старта выполняется опрос DNS- сервера с целью получения актуального списка IP-адресов, которые указаны в качестве носителей ресурсов для данной зоны, а также текущих правил распределения запросов. Задается интервал, достаточный для принятия решения о влиянии установленных пропорций распределения на степень загруженности серверной платформы (по умолчанию — 10 минут). Затем производится SNMP-опрос с целью получения актуальных сведений о загрузке серверной платформы.

Рис. 3. Использование сведений о загруженности для балансировки

Вычислив пропорции в производительности узлов в соответствии с ранее приведенным алгоритмом, балансировщик формирует новый файл конфигурации зоны. В данном файле содержится последовательный список IP-адресов узлов, который будет использовать DNS-сервер при цикличном переборе. Пропорции распределения нагрузки задаются частотой расположения IP-адреса узла в этом списке. После этого выполняются действия по перезагрузке файла зоны в DNS-сервере. При последующей работе балансировщик выполняет периодический SNMP-опрос серверов и при наличии событий, требующих изменения пропорций в распределении нагрузки, производит действия по их вычислению, формированию нового файла зоны и его перезагрузке. Такими событиями считаются отсутствие SNMP-ответа (признак нарушения работы сервера) либо дисбаланс в загрузке процессора более 10%. При отсутствии подобных событий файл в зоне не обновляется.

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

***

Ближе всего к данной работе находятся системы Global Server Load-Balancing , однако они ориентированы на функциональность в области географической балансировки между ЦОД, а не между серверами приложений.

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

Владислав Носков ( vynoskov@gmail.com ) — старший преподаватель, Кирилл Криницын, Александр Пономарев — студенты Уральского федерального университета (Екатеринбург).