CC BY
10
А. Л. Коннов, кандидат технических наук, доцент кафедры системного анализа и управления, Оренбургский государственный университет e-mail: andrey_konnov@mail.ru
Л. В. Легашев, аспирант кафедры геометрии и компьютерных наук, Оренбургский государственный университет e-mail: silentgir@gmail.com
П. Н. Полежаев, преподаватель кафедры компьютерной безопасности и математического обеспечения информационных систем, Оренбургский государственный университет e-mail: newblackpit@mail.ru
Ю. А. Ушаков, кандидат технических наук, доцент кафедры системного анализа и управления, Оренбургский государственный университет e-mail: unpk@mail.ru
А. Е. Шухман, кандидат педагогических наук, заведующий кафедры геометрии и компьютерных наук, Оренбургский государственный университет e-mail: shukhman@gmail.com
МОДЕЛИРОВАНИЕ ОБЛАЧНЫХ НАУЧНО-ОБРАЗОВАТЕЛЬНЫХ
РЕСУРСНЫХ ЦЕНТРОВ
Исследования выполнены при поддержке Министерства образования и науки Российской Федерации
в рамках проекта № 14.B37.21.1881 ФЦП «Научные и научно-педагогические кадры инновационной России на 2009-2013 годы» и РФФИ (проекты №12-07-31089 и №13-07-97046)
В статье вводится понятие облачного научно-образовательного ресурсного центра, обеспечивающего экономичный доступ к вычислительным ресурсам и дорогостоящему программному обеспечению, представлена модель облачной системы ресурсного центра.
Ключевые слова: облачные вычисления, математическое моделирование, ресурсный центр.
1. Введение
Научные и образовательные организации в нашей стране часто работают в условиях недостаточного финансирования на закупку мощной вычислительной техники и дорогостоящего программного обеспечения (ПО), необходимого для решения научных и образовательных задач. Частично в настоящее время проблема решается с использованием открытого ПО, но, как правило, оно обладает ограниченным функционалом или не удовлетворяет приемлемому уровню качества.
Другой путь предоставления необходимых аппаратных и программных ресурсов связан с созданием научно-образовательных ресурсных центров. Каждый подобный центр строится на базе облачной вычислительной системы, разво-
рачиваемой в центре обработки данных (ЦОД). Облачная система реализует механизм DaaS (Desktop as a Service, рабочий стол в качестве сервиса), направленный на предоставление каждому пользователю виртуального окружения (виртуального рабочего стола) со всем необходимым для обучения или исследования программным обеспечением. Доступ к данному окружению осуществляется пользователями удаленно с использованием стационарных компьютеров организаций, домашних компьютеров или ноутбуков. Использование научно-образовательных ресурсных центров позволяет за счет применения технологий виртуализации, паравиртуализации или виртуализации на уровне операционной системы эффективно загружать физические вычислительные ресурсы серверов.
Преподаватель образовательного учреждения с помощью Web-интерфейса сможет создать виртуальный класс с указанием нужного количества экземпляров виртуальных машин, которые строятся на основе одного из существующих публичных дисковых образов или с нуля. Преподаватель также указывает все необходимое ПО для автоматической установки, а затем выбирает время проведения занятий в данном виртуальном классе.
Совместное использование несколькими учреждениями платного ПО и вычислительных ресурсов приводит к значительной экономии денежных средств, научные и образовательные учреждения платят только за фактическое время использования вычислительных ресурсов и ПО, им не нужно заботиться о покупке и установке пакетов обновлений.
Также снижается уровень требований к производительности компьютеров пользователей - для комфортной работы достаточно наличие компьютера бюджетного уровня с установленным браузером и каналом подключения к сети Интернет. Использование современных Web-технологий позволяет создать максимально простой и интуитивно понятный интерфейс работы с ресурсным центром, скрывающий особенности и детали его функционирования.
При этом необходима разработка методов и алгоритмов эффективной работы подобных научно-образовательных ресурсных центров, включая: алгоритмы планирования виртуальных машин и виртуальных окружений пользователей, методы маршрутизации сетевого трафика внутри ЦОД и алгоритмы создания виртуальных машин и виртуальных окружений с необходимым ПО. При разработке алгоритмов необходимо учитывать специфику виртуальных окружений, включая ограничения лицензий и необходимость запуска дополнительных виртуальных машин с серверами лицензий, а также использования информации о состоянии сети ЦОД.
Планировщик ресурсного центра должен учитывать ограничения платного ПО при планировании виртуальных машин: лимиты количества экземпляров ПО, одновременно работающих на виртуальных машинах в сети, наличие сервера лицензирования, наличие аппаратных ключей.
Важной проблемой для создания эффективных научно-образовательных ресурсных центров остается отсутствие эффективных средств
управления потоками данных в компьютерной сети. Как правило, применяются стандартные протоколы маршрутизации, такие, как RIP, OSPF, EIGRP и др., которые опираются на распределенные алгоритмы выбора маршрута, без учета логических путей передачи (потоков) данных, существующих на уровне потоков данных между образовательными, научными и инфраструктурными приложениями, выполняющимися внутри экземпляров виртуальных машин. Эту проблему можно решить за счет использования программно-конфигурируемых сетей (ПКС) и протокола OpenFlow [1].
Необходима разработка методов маршрутизации трафика внутри ЦОД, которые позволят заранее, с помощью проактивной схемы прокладывать пути передачи данных между экземплярами виртуальных машин, а также между экземплярами и граничными шлюзами, к которым подключаются пользователи ресурсного центра. Это даст возможность исключить задержку, связанную с установлением маршрута (характерную для классических протоколов) или с обработкой первого пакета (для реактивной схемы). Также данные методы позволят динамически перенастраивать пути передачи данных, в случае миграции экземпляров виртуальных машин.
Все перечисленное позволит значительно повысить эффективность функционирования научно-образовательных ресурсных центров. В этом заключается актуальность настоящего исследования.
Ранее нами уже была разработана структурная модель центра обработки данных [2, 3], в рамках данной статьи представлена модель облачной системы научно-образовательного ресурсного центра.
2. Модель облачной системы
На основе структурной модели ЦОД научно-образовательного ресурсного центра разработана модель облачной системы, функционирующей поверх ЦОД.
Основное ее отличие от структурной модели заключается в том, что вводятся виртуальные вычислительные узлы, представляющие собой экземпляры виртуальных машин, соединенных на каждом физическом вычислительном узле с помощью виртуального коммутатора. Согласно рисунку 1 в структуре физического вычислительного узла выделяются: виртуальные вычислительные узлы, ОС физического вычислительного узла и виртуальный коммутатор.
Изображенные линии обозначают сетевые соединения между одной или более парой портов соответствующих сетевых устройств. Все виртуальные вычислительные узлы подключены с помощью одного или нескольких виртуальных портов к виртуальному коммутатору. Сам физический вычислительный узел с помощью виртуального порта соединен с виртуальным коммутатором. Виртуальный коммутатор подключен к физическим портам физического вычислительного узла, через которые он связан с другими устройствами сети.
Виртуальный коммутатор __________ i
---- I
Соединения с I
другими |
устройствами |
сети
I____________________________________________j
Физический вычислительный узел
Рис. 1. Структура физического вычислительного узла в модели облачной системы
Виртуальный коммутатор в зависимости от используемого монитора виртуальных машин может представлять собой как коммутатор без поддержки OpenFlow, так и OpenFlow-коммутатор.
Модель облачной системы формализована в виде набора вида:
Cloud = (DataCenter', CloudSoftware(t)),
где DataCenter' представляет собой физический ЦОД, дополненный виртуальными устройствами:
DataCenter' = (Devices',Links',Flows' (t)).
DataCenter' - ориентированный мультиграф, его вершины — разбиение множеств Devices' = Devices u VirtualDevices. Здесь VirtualDevices - виртуальные сетевые устройства, они являются разбиением множеств, VirtualDevices = VNodes u VSwitches u VOFwitches где VNodes = { VNode} - множество виртуальных
вычислительных узлов, VSwitches={VSwitch} -множество виртуальных коммутаторов без поддержки OpenFlow, VOFSwitches = { VOFSwitch.}
- множество виртуальных коммутаторов с поддержкой OpenFlow.
Будем условно считать, что каждый физический узел, включая случаи отсутствия назначенных на него экземпляров виртуальных машин или наличия ровного одного экземпляра, содержит ровно один виртуальный коммутатор.
Множество сетевых связей Links' представляет собой Links' = Links u VirtualLinks, где VirtualLinks - виртуальные соединения.
Состояние компонентов программного обеспечения облачной системы включает следующие параметры и динамические характеристики:
CloudSoftware(t) = (VMs,Classrooms,Images, vHDDs, Flavors, Users, Programs), где VMs,={VM} - множество всех виртуальных машин, Classrooms={Classroom} - виртуальные классы, Images={Image } - дисковые образы виртуальных машин, vHDDs={vHDD}
- виртуальные жесткие диски для хранения персональных данных пользователей, Flavors ={Flavor} - типы конфигураций виртуальных машин, Users = {Users} - пользователи, = {Program} - набор платного и бесплатного ПО.
Виртуальная машина VM. характеризуется следующими параметрами:
VM= (Flavor,, Image,, vHDD,, State,(t)).
Здесь Flavor e Flavors - тип конфигурации виртуальной машины, Im agei e Im ages - ее дисковый образ, vHDD. e vHDDs - персональный жесткий диск пользователя, State (t) - состояние в момент t.
Каждый дисковый образ Image может быть описан в виде набора:
Image,=(InsPrograms,,d,(t)),
где Ins Pr ograms . с Pr ograms - набор установленного программного обеспечения (полностью или только отдельные модули), d(t) - текущий размер дискового образа, выделенный облаком.
Каждый виртуальный класс Classroom t представляет собой совокупность групп виртуальных машин, связанных между собой виртуальной сетью:
Виртуальный вычислительный узел 1
Виртуальный
вычислительный
узел N
ОС физического вычислительного
узла
Classroom. = (VMGroups .,Users .,Ad min),
где VMGroupsi = (VMGroupü,...,VMGroupiG )
- совокупность групп виртуальных машин,
Users. С Users - множество пользователей, которым разрешен доступ к виртуальному На-классу, Admin. е Users - его администратор. личие нескольких групп виртуальных машин позволяет создать отдельные группы для учеников/студентов и учителей/преподавателей. Группа VMGroup. = {VMjk}— с VMs
U j k~l!gij
состоит из виртуальных машин одного типа Flavor е Flavors построенных на базе одного j ^ дискового образа ImageVj е Images.
Тип конфигурации виртуальной машины может быть описан тройкой:
Flavor = (Ct,Mt, Dlmam, DvHDDt),
где C. - количество ее вычислительных ядер, M, D и D - соответственно размеры
1 ^Imagej vHDDi г Г
оперативной памяти, дискового образа и виртуального диска для персональных данных.
Любая программа может быть представлена набором ее модулей. Каждый программный модуль определяет совокупность файлов программ, библиотек, настроек, данных, ключей реестра и т.п., которые должны быть установлены на одну виртуальную машину. Если программа состоит из нескольких модулей, то они могут быть установлены на одной или нескольких виртуальных машинах. В последнем случае взаимодействие между ними осуществляется по сети.
Структура программы Program, с учетом лицензионных ограничений может быть представлена в виде взвешенного неориентированного графа ее программных модулей:
Program. = (Modules,.Relations,.MaxMLimit, MinRLimit, MaxRLimit)
Его вершинами являются отдельные модули Modules. = {Modulesj}, а ребрами - неориенти-
рованные связи Relations. ={{X, 7}} между некоторыми модулями X и Y. Заметим, что каждое неориентированное ребро {X, Y} является совокупностью из двух ориентированных дуг (X, Y) и (Y X).
Отображение MaxMLimit. : Modules. ^ N для
каждого программного модуля X g Modules. задает максимальное количество его экземпляров MaxLimit.(X), которые могут быть запущены/установлены в соответствии с лицензией. Если лицензия не ограничивает максимальное количество экземпляров, то MaxLimit(X) = œ.
Функции MinRLimit. : Relations, х Relations. ^ N и MaxLimit. : Relations, х Relations. ^ N
I I I
для каждой ориентированной связи (X, 7) задают соответственно минимальные и максимальные кратности, приписываемые к модулю X . Смысл минимальных кратностей ребра {X, 7} заключается в том, что совместная работа модулей X и Y возможна при условии, что в виртуальном классе будет минимум MinRLimit(X, Y) экземпляров модуля X и MinRLimit (Y, X) - модуля Y. Максимальные кратности ограничивают количество экземпляров соответствующих модулей в соответствии с лицензионными ограничениями.
3. Заключение
В рамках данной статьи представлена модель облачной системы научно-образовательного ресурсного ЦОД.
Данная модель позволяет формализовать современные облачные системы, включая OpenStack, OpenNebula, и адаптировать их для реализации научно-образовательных ресурсных центров, а также учитывать лицензионные ограничения установленного программного обеспечения. В будущем данная модель послужит основой для разработки симулятора ресурсного центра, с помощью которого планируется оценивать эффективность предлагаемых алгоритмических решений в области планирования виртуальных машин и виртуальных окружений, создания виртуальных окружений и управления маршрутизацией сетевого трафика в ПКС ЦОД ресурсного центра.
Литература
1. McKeown, N. Openflow: enabling innovation in campus networks / N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, J. Turner // ACM SIGCOMM Computer Communication Review. - 2008. -Vol. 38. - P. 69-74.
2. Полежаев, П. Н. Математическая модель распределенного вычислительного центра обработки данных с программно-конфигурируемыми сетями его сегментов / П. Н. Полежаев // Вестник «Оренбургского государственного университета». - 2013. - 5(154). - С. 198-204.
3. Ушаков, Ю. А. Математическое моделирование облачного вычислительного центра обработки данных с использованием OpenFlow / Ю. А. Ушаков, А. Л. Коннов, П. Н. Полежаев, А. Е. Шухман, В. Н. Тарасов // Вестник Оренбургского государственного университета. - 2012. -№ 9 - С. 150-155.
