CC BY
86
Труды ИСП РАН, том 27, вып. 5, 2015 г.
Балансировка нагрузки в системе Unihub на основе предсказания поведения пользователей
Д.А. Грушин <[email protected]>
Н.Н Кузюрин <[email protected]>
ИСП РАН, 109004, Россия, г. Москва, ул. А. Солженицына, дом 25
Аннотация. Разработанная в ИСП РАН программная система Unihub является облачной вычислительной системой типа SaaS и предоставляет пользователям возможность удаленной работы через Web-браузер с интерактивными графическими Linux-приложениями, запускаемыми в изолированных Docker контейнерах. Контейнеры имеют динамические требования к вычислительным ресурсам. Обычный способ размещения, при котором контейнеры распределяются равномерно по всем имеющимся в распоряжении серверам, приводит к неравномерной загрузке системы: некоторые сервера перегружены, а некоторые простаивают. В данной работе мы предлагаем собирать данные о поведении пользователей и характере работы различных приложений с целью прогнозирования создаваемой контейнерами нагрузки. Наши наблюдения показывают, что полученная информация позволяет равномернее загрузить имеющееся в распоряжении оборудование и увеличить предельную производительность системы в целом.
Ключевые слова: облачные системы типа SaaS. система Unihub. прогнозирование поведения пользователей
1. Введение
Одной из основных тенденций развития информационных технологий в настоящее время является массовое внедрение "облачных" вычислений. Важнейшим преимуществом для пользователей облачной инфраструктуры является возможность отказаться от необходимости самостоятельно содержать дорогостоящее вычислительное оборудование. За счет использования технологий виртуализации, одним набором физического оборудования, облако способно удовлетворить различные требования большого числа пользователей. Облако также дает возможность "масштабирования с помощью кредитной карты" (ориг. "scale by credit card") - что означает незамедлительное предоставление по требованию дополнительных ресурсов на некоторое время за плату. При этом, потребности пользователя ограничиваются только его финансовыми возможностями, в отличие от физических ограничений при добавлении узлов в кластер или накладных расходов на содержание неиспользуемых ресур-
23
Trudy ISP RAN [The Proceedings of ISPRAS], vol. 27, issue 5, 2015.
сов. Системы управления облачными инфраструктурами дают новые возможности для администраторов, так как включают в себя механизмы для мониторинга и управления огромными массивами физических серверов. Различают несколько моделей облачных вычислений:
1. Программное обеспечение как услуга (SaaS, англ. Software-as-a-Service) — модель, в которой пользователю предоставляется возможность использования программного обеспечения, работающего в облачной инфраструктуре и доступного из различных клиентских устройств, например, из браузера.
2. Платформа как услуга (PaaS, англ. Platform-as-a-Service) — модель, когда пользователь использует облачную инфраструктуру для размещения базового программного обеспечения для последующего размещения на нем новых или существующих приложений. В состав таких платформ входят инструментальные средства создания, тестирования и выполнения прикладного программного обеспечения — системы управления базами данных, среды исполнения языков программирования и др., предоставляемые облачным провайдером.
3. Инфраструктура как услуга (IaaS, англ. IaaS or Infrastructure-as-а-8епчсе)предоставляется как возможность использования облачной инфраструктуры для самостоятельного управления ресурсами обработки, хранения, сетями и другими фундаментальными вычислительными ресурсами. Например, потребитель может устанавливать и запускать произвольное программное обеспечение, которое может включать в себя операционные системы и прикладное программное обеспечение. Потребитель может контролировать операционные системы, виртуальные системы хранения данных и установленные приложения, а также набор доступных сервисов (например, межсетевой экран, DNS).
Разработанная в ИСП РАН программная система Unihub [10] является облачной вычислительной системой типа SaaS и предоставляет пользователям возможность удаленной работы через Web-браузер с интерактивными графическими Linux-приложениями.
Популярность подобных систем, предоставляющих доступ к удаленным рабочим столам посредством тонкого клиента, в настоящее время сильно выросла. Это произошло благодаря повсеместному внедрению облачных вычислений и доступности скоростного Интернет доступа [3]. При выполнении приложений в виртуальных рабочих столах на удаленных серверах, пользователи получают доступ к любому приложению из любого места и с любого устройства. Такая модель использования вычислительных ресурсов создает новую задачу оптимизации распределения нагрузки.
Этому направлению в настоящее время уделяется большое внимание (см. например [13-15]). В системе Unihub все задачи интерактивные, с 24
Труды ИСП РАН, том 27, вып. 5, 2015 г.
динамическими требованиями к ресурсам. При появлении задачи планировщик не может знать когда она завершится и сколько ресурсов она будет потреблять в определенный момент времени. Если поместить несколько столов на один сервер, и приложения при этом начнут активно использовать процессор, то пользователи сразу заметят замедление работы, что нежелательно. Эта ситуация в точности соответствует работе нескольких приложений на одном компьютере - если вы запускаете много тяжеловесных приложений, то процессор делится между ними, и все приложения работают заметно медленнее.
Для оптимизации размещения рабочих столов планировщику необходима дополнительная информация. Источником такой информации может служить, например, история загрузки серверов за последнее время, количество запущенных приложений на каждом сервере, и т.д. Мы предлагаем собирать и хранить информацию о загрузке серверов вместе со статистикой запусков задачи и поведения пользователей в системе для оптимизации принятия решений планировщиком.
2. Управление вычислительными ресурсами в системе Unihub
Unihub запускает приложения в Docker контейнерах [11], которые могут размещаться в виртуальных машинах или на серверах (далее будем использовать термин сервер для обозначения обоих случаев).
Контейнеры изолируют несколько экземпляров операционной системы Linux на одном сервере друг от друга и позволяют ограничивать процессорное время, память и другие ресурсы, потребляемые отдельным экземпляром.
Каждый контейнер содержит работающий процесс графического рабочего стола Xorg. Внутри рабочего стола пользователь может одновременно работать с несколькими графическими приложениями. В то время, когда рабочие столы продолжают постоянно работать на серверах Unihub, пользователь может отключаться и подключаться к системе в любое время и с любого совместимого устройства.
Работающие на сервере контейнеры контролируются Docker агентом. По умолчанию, если несколько контейнеров работают на одном сервере, то процессорное время разделяется между ними поровну. Однако, если другие контейнеры бездействуют, то один контейнер может использовать процессор полностью. Docker не дает возможности жестко ограничить использование процессора одним контейнером, например, в размере 1/5, зато позволяет привязать контейнер к определенному процессорному ядру на все время работы контейнера.
Рассмотрим схему управления вычислительными ресурсами в системе Unihub.
25
Trudy ISP RAN [The Proceedings of ISPRAS], vol. 27, issue 5, 2015.
а и 2 о К. 8-с! m * ф £ Я rtj Т О S £ Й* Й*
кшя Не£Ш Ви
Uinihub. Docker
ft
£
I
I
о
На первом уровне вычислительным оборудованием управляет OpenStack. Он предоставляет вышестоящему уровню вычислительные серверы: как виртуальные машины, так и bare metal серверы.1 Распределение серверов происходит на этапе инициализации системы, и управляется администратором. В дальнейшем распределении задач пользователей планировщик OpenStack не принимает участия.
На втором уровне планировщик системы Unihub создает и распределяет Docker контейнеры с рабочими столами пользователей по серверам. Контейнер использует квоты (ограничения) на количество разрешенной памяти и процессорного времени. Зная характеристики сервера и требования контейнеров, планировщик решает какое количество контейнеров следует разместить на данном сервере.
В системе Unihub все задачи интерактивные, с динамическими требованиями к ресурсам. При появлении задачи планировщик не может знать когда она завершится и сколько ресурсов она будет потреблять в определенный момент времени. Это означает, что, если мы поместим несколько контейнеров на один сервер, и контейнеры при этом начнут ак-
1 bare metal сервер - это вычислительная система, в которой виртуальная машина устанавливается непосредственно на оборудование, а не поверх гостевой операционной системы.
26
Труды ИСП РАН, том 27, вып. 5, 2015 г.
тивно использовать процессор, то пользователи сразу заметят замедле-ние работы своих приложений,2 что нежелательно.
Исходя из этого, представляется логичным распределять контейнеры равномерно по всем имеющимся в распоряжении узлам. Таким образом, замедление работы должно будет происходить при общей перегрузке системы - превышении некоторого количества одновременно работающих пользователей. В таких ситуациях говорят о достижении предельной производительности системы и необходимости наращивания оборудования.
Однако, очевидно, что пользователи используют рабочие столы по-разному. Характер нагрузки, создаваемой двумя произвольными контейнерами будет различаться. Это означает, что, разместив одинаковое количество контейнеров на каждом сервере, возникнет ситуация при которой некоторые сервера будут перегружены, а некоторые будут простаивать.
В данной ситуации, оптимальным решением является миграция работающего контейнера на менее загруженный сервер. В последней версии Docker возможность миграции контейнера появилась [12], однако все еще находится на стадии разработки.
Если миграция невозможна, и контейнер должен быть размещен только один раз и работать до конца на одном узле, необходимо следить за тем, чтобы предсказать нагрузку и распределить ее по серверам равномерно. Это значит, планировщику необходима дополнительная информация. Источником такой информации может служить, например, история загрузки серверов за последние несколько минут, количество запущенных приложений на каждом сервере, и т.д. Мы предлагаем использовать статистику запусков задачи и поведения пользователей в системе для оптимизации принятия решений о размещении контейнеров.
Рассмотрим пример работы контейнера в системе Unihub.
1. Пользователь авторизуется в системе.
2. Некоторое время пользователь работает с информационными материалами и не запускает приложений.
3. Пользователь запускает приложение X и некоторое время активно использует его.
4. Пользователь прекратил работать с приложением, но не закрыл его. Приложение работает, но не создает нагрузки.
5. Пользователь вышел из системы.
Учитывая то, что пользователи регулярно пользуются системой, данная модель поведения будет с некоторыми вариациями повторятся. Эта информация может быть использована планировщиком. Например, как только пользователь зашел в систему, планировщик уже может предсказать его дальнейшие действия. При создании контейнера планировщик
2 QoE - quality of experience, качество восприятия.
27
Trudy ISP RAN [The Proceedings of ISPRAS], vol. 27, issue 5, 2015.
также будет обладать информацией о статистике использования данного приложения как текущим, так и другими пользователями. Очевидно, редко используемые контейнеры можно группировать плотнее и изолировать их от более активных контейнеров, тем самым не вызывая заметных пользователям замедлений в работе приложений.
Использование данных о поведении пользователей в распределенных вычислительных системах неоднократно рассматривалось разными авторами, например, для оптимизации потребления энергии [6], для задачи размещения данных [5], оптимизации расписаний в Grid [7], снижения латентности тонких клиентов [8], запуска виртуальных машин [4] и др. Во всех работах подтверждается периодичность, характерная для создаваемой пользователями нагрузки. В системе Unihub мы также провели анализ поведения пользователей и выяснили, что больше половины постоянных пользователей работают с системой по расписанию. Можно выделить несколько групп пользователей, работающих одновременно с разной периодичностью.
2.1 Сбор данных и размещение контейнеров
Рассмотрим пример графика создаваемой контейнером нагрузки.
С момента создания контейнера на некотором промежутке времени измеряется загрузка процессора. Мы предлагаем вычислять три величины: L - средняя загрузка на всем интервале, В - средняя продолжительность интервала высокой загрузки, I - средняя продолжительность интервала бездействия (низкой загрузки). В качестве промежутка времени предлагается использовать сессию пользователя.
Вместе с указанными величинами сохраняется дополнительная информация:
1. идентификатор пользователя,
2. дата и время,
3. запущенные приложения в других контейнерах пользователя,
4. характеристики контейнера (квота, образ),
5. идр.
Располагая собранными данными, планировщику необходимо при размещении нового контейнера определить предполагаемый характер его нагрузки. Существует несколько способов решения данной задачи. Наи-
28
Труды ИСП РАН, том 27, вып. 5, 2015 г.
более часто применяемыми на практике являются способы, основанные на машинном обучении [2]. В данной работе мы применили один из методов основанных на машинном обучении - instance-based learning (IBL), который иногда называется memory-based learning [1].
Данный метод работает следующим образом. В базе данных хранится информация об "опытах". В нашем случае это информация, связанная с историей загрузки контейнера. Опыт состоит из входных и выходных объектов. Входные объекты описывают условия, при которых опыт проводился, а выходные - то, что произошло при этих условиях. Каждый объект, как правило, состоит из имени и значения, где значением может быть простой тип: целое число, число с плавающей точкой, или строка. Запросом к базе является массив входных объектов, по которым мы хотим получить соответствующий опыт.
HimiLer
Близость двух опытов определяется функцией расстояния (distance function). Существует много вариантов вычисления данной функции [9]. Заключительным этапом формирования прогноза является построение массива полученных из базы близких опытов и доверительного интервала.
Получая таким образом значения L,B,I - предполагаемой средней загрузки и интервалов высокой и низкой активности, для размещения контейнера выбирается сервер, для всех контейнеров которого сумма значений предполагаемой средней загрузки в заданном интервале времени не превышала бы значения заданной константной величины L_max (например 0,8), и у которых отношение длины среднего интервала бездействия к средней длине интервала сильной загрузки (I/В) минимально.
В случае, когда планировщик не может определить предполагаемые значения загрузки для данного контейнера, размещение происходит на наименее загруженный за последнее время сервер.
Данные о принятом планировщиком решении также сохраняются. Если в процессе работы сервера величина загрузки превышает предполагаемую, то параметр L_max корректируется. Таким образом, планировщик
29
Trudy ISP RAN [The Proceedings of ISPRAS], vol. 27, issue 5, 2015.
будет обладать возможность адаптироваться к различным потокам задач.
2.2 Эксперименты
Для сравнения поведения указанных стратегий проводилось моделирование на основе собранной информации из работающей системы Unihub. Мы использовали ранее разработанную в ИСП РАН систему Gridme с некоторыми необходимыми изменениями для моделирования облачных систем.
Для сравнения была выбрана базовая стратегия - размещение контейнеров равным количеством по всем доступным серверам, при котором загрузка сервера не учитывается.
Второй стратегией мы выбрали размещение на наименее загруженный за последние сутки сервер.
Третья стратегия - размещение с учетом собранной дополнительной информации о загрузке контейнеров.
Эксперименты подтвердили, что дисбаланс при использовании базовой стратегии наступает очень быстро. Единственным плюсом базовой стратегии является простота реализации.
Стратегия размещения на наименее загруженный за последние сутки сервер показала лучший результат по отношению к базовой. Вероятность возникновения дисбаланса меньше, и зависит от периода времени за который суммируется загрузка сервера. Наилучшие результаты были показаны при значении интервала в 3 суток. Дальнейшее увеличение интервала приводило к ухудшению результатов.
Стратегия размещения с учетом собранной дополнительной информации показала лучший результат. В среднем, по сравнению с базовой стратегией удалось увеличить количество одновременно работающих контейнеров без ухудшения QoE на 12%.
3. Заключение
Система Unihub является облачной вычислительной системой типа SaaS, предоставляющей доступ к интерактивным приложениям. Основной характеристикой такой системы может являться величина QoE - качество восприятия. В настоящее время данный термин становится все более популярным. Довольно много исследований ведется по созданию новых методов определения качества восприятия пользователями того или иного сервиса или услуги, однако точных стандартизованных методик по определению QoE, описывающих все случаи, пока не существует. Для системы Unihub величину QoE определяет отсутствие видимого замедления в работе приложений пользователя.
В системе Unihub пользователь, заходя через Web-браузер с любого совместимого устройства, может запустить несколько рабочих столов. Рабочий стол - это графическое окружение Linux, изолированное внутри
30
Труды ИСП РАН, том 27, вып. 5, 2015 г.
Docker контейнера. В то время, как рабочие столы постоянно работают на серверах Unihub, пользователь может отключаться и подключаться к системе в любое время.
Такая модель характеризуется динамической нагрузкой. Учитывая, в настоящее время, невозможность миграции работающих контейнеров, основной задачей планировщика является равномерное распределение нагрузки по серверам. В случае дисбаланса значение QoE будет уменьшаться.
В данной работе мы предложили собирать и использовать информацию о характере активности пользователей для оптимизации размещения контейнеров. Наблюдения показали, что для создаваемой пользователями нагрузки характерна периодичность - больше половины постоянных пользователей работают с системой по расписанию, причем по этому показателю всех пользователей можно разделить на несколько групп. Результаты моделирования предложенных алгоритмов показали, что использование информации о поведении пользователей позволяет поднять плотность упаковки контейнеров на одном сервере без значительных, заметных пользователю потерь производительности приложений. В сравнении с базовой стратегией (размещение контейнеров равным количеством по всем доступным серверам) удалось увеличить плотность упаковки контейнеров в среднем на 12%.
Мы планируем в дальнейшей работе исследовать степень влияния различных параметров на точность предсказания создаваемой контейнером загрузки. Необходимо также изучить устойчивость предсказания и, следовательно, эффективность балансировки, к резкому изменению поведения пользователей, например, при добавлении в систему большой группы новых пользователей.
Список литературы
[1] . Atkeson С., Moore A., Schaal S. Locally weighted learning. Artificial Intelli-
gence Review. 1997. № 1-5 (11). C. 11-73.
[2] . Blum A. On-line algorithms in machine learning Springer, 1996. 306-325 c.
[3] . Deboosere L. [и др.]. Cloud-based desktop services for thin clients. Internet
Computing, IEEE. 2012. № 6 (16). C. 60-67.
[4] . Jiang Y. [и др.]. ASAP: A self-adaptive prediction system for instant cloud re-
source demand provisioning 2011. 1104-1109 c.
[5] . Kavulya S. [и др.]. An analysis of traces from a production mapReduce cluster
2010. 94-103 c.
[6] . Nguyen T.-D. [и др.]. Prediction-based energy policy for mobile virtual desktop
infrastructure in a cloud environment. Inf. Sci. 2015. № C (319). C. 132-151.
[7] . Smith W. Prediction services for distributed computing 2007. 1-10 c.
[8] . Suznjevic M., Skorin-Kapov L., Humar I. User behavior detection based on sta-
tistical traffic analysis for thin client services Advances in intelligent systems and computing. Под ред. A. Rocha [и др.]., Springer International Publishing, 2014. 247-256 c.
31
Trudy ISP RAN [The Proceedings of ISPRAS], vol. 27, issue 5, 2015.
[9]. Wilson D.R., Martinez T.R. Improved heterogeneous distance functions. J. Artif. Int. Res. 1997. № 1 (6). C. 1-34.
[10] . Unihub: Технологическая платформа программы университетский кластер.
http://unihub.ru.
[11] . Docker: An open platform for distributed applications for developers and
sysadmins, http://www.docker.com.
[12] . CRIU: A project to implement checkpoint/restore functionality for linux in
userspace. http://criu.org/Docker.
[13] . Mohammadi F., Jamali S., Bekvari M., Survey on Job Scheduling algorithms in
Cloud Computing, Int. Journal of Emergency Trends of Technology in Computer Science, 2014, v. 3, Issue 2, C. 151-154.
[14] . Tian W., Zhao E., Zhong V., Xu M., Jing C., A dynamic and integrated load-
balancing scheduling algorithm for cloud datacenters, Cloud computing and Intelligence Systems (CCIS), 2011, IEEE Int. Conference 15-17 September 2011, C. 311-315.
[15] . Duy T.V.T., Sato Y., Inogushi Y., Performance evaluation of a green scheduling
algorithm for energy savings in cloud computing, Parallel and Distributed Processing, Workshops and PhD forum, Atlanta, 19-23 April 2010, C. 1-8.
32
Труды ИСП РАН, том 27, вып. 5, 2015 г.
Load balancing in Unihub SaaS system based on user behavior prediction
D.A. Grushin <[email protected]>
N.N. Kuzyurin <[email protected]>
ISP RAS,
25 Alexander Solzhenitsyn Str., Moscow, 109004, Russian Federation
Abstract. In ISP RAS cloud computing system SaaS Unihub was developed. It provides the possibility for users to work by Web-browser with interactive graphic Linux-applications, working in isolated Docker containers. Containers have dynamical demands to computational resources. Usual way of placement when containers are distributed uniformly among all servers can lead to bad result: some servers have too many applications but other are almost empty. In this paper we propose to collect information about users behavior and investigate how different applications work in order to predict containers load-balancing. Our observations show that such information can provide more uniform load-balancing and improve the whole system performance.
Keywords: cloud computing SaaS systems, Unihub system. Users behavior prediction
References
[1] . Atkeson C., Moore A., Schaal S. Locally weighted learning. Artificial Intelli-
gence Review. 1997. № 1-5 (11). С. 11-73.
[2] . Blum A. On-line algorithms in machine learning Springer, 1996. 306-325 c.
[3] . Deboosere L. [и др.]. Cloud-based desktop services for thin clients. Internet
Computing, IEEE. 2012. № 6 (16). C. 60-67.
[4] . Jiang Y. [и др.]. ASAP: A self-adaptive prediction system for instant cloud re-
source demand provisioning 2011. 1104-1109 c.
[5] . Kavulya S. [и др.]. An analysis of traces from a production mapReduce cluster
2010.C. 94-103.
[6] . Nguyen T.-D. [и др.]. Prediction-based energy policy for mobile virtual desktop
infrastructure in a cloud environment. Inf. Sci. 2015. N° C (319). C. 132-151.
[7] . Smith W. Prediction services for distributed computing 2007. C. 1-10.
[8] . Suznjevic M., Skorin-Kapov L., Humar I. User behavior detection based on sta-
tistical traffic analysis for thin client services Advances in intelligent systems and computing. Springer International Publishing, 2014. C. 247-256.
[9] . Wilson D.R., Martinez T.R. Improved heterogeneous distance functions. J. Artif.
Int. Res. 1997. № 1 (6). C. 1-34.
[10] . Unihub: Technological platform for university cluster program, http://unihub.ru.
[11] . Docker: An open platform for distributed applications for developers and
sysadmins, http://www.docker.com.
33
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 5, 2015.
[12] . CRIU: A project to implement checkpoint/restore functionality for linux in
userspace. http://criu.org/Docker.
[13] . Mohammadi F., Jamali S., Bekvari M., Survey on Job Scheduling algorithms in
Cloud Computing, Int. Journal of Emergency Trends of Technology in Computer Science, 2014, v. 3, Issue 2, C. 151-154.
[14] . Tian W., Zhao E., Zhong V., Xu M., Jing C., A dynamic and integrated load-
balancing scheduling algorithm for cloud datacenters, Cloud computing and Intelligence Systems (CCIS), 2011, IEEE Int. Conferencel5-17 September 2011, C. 311-315.
[15] . Duy T.V.T., Sato Y., Inogushi Y., Performance evaluation of a green scheduling
algorithm for energy savings in cloud computing, Parallel and Distributed Processing, Workshops and PhD forum, Atlanta, 19-23 April 2010, C. 1-8.
34
