CC BY
78
УПРАВЛЕНИЕ, ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА И ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
УДК 004.75
А.Н. Привалов, д-р техн. наук, проф., зав. кафедрой, (4872) 35-20-09, [email protected] (Россия, Тула, ТГПУ им. Л.Н. Толстого), А.К. Клепиков, асп., 8-915-680-36-62, [email protected], (Россия, Тула, ТГПУ им. Л.Н. Толстого)
МОДЕЛЬ РАСПРЕДЕЛЕНИЯ РЕСУРСОВ ПРИ "ОБЛАЧНЫХ" ВЫЧИСЛЕНИЯХ
Рассмотрены варианты использования "облачных" технологий в автоматизированных обучающих системах. Приведен вариант построения автоматизированной обучающей системы на основе "облачных" технологий.
Ключевые слова: автоматизированная обучающая система, "облачные" технологии, распределение ресурсов.
В настоящий момент "облачные" системы всё чаще применяются в бизнесе и технике. Это обусловлено простотой использования и относительно малыми расходами на содержание системы. Подобные системы могут применяться и в учебном процессе. "Облачные" технологии могут стать полезным и оправданным дополнением к автоматизированным обучающим системам (АОС) и к высоконагруженным системам электронного обучения. Услуга предоставления "облачных" вычислений построена на двух важных принципах:
вычислительные ресурсы выделяются по потребности; вычислительные ресурсы оплачиваются по потреблению. Вместо предоставления клиенту пакета ресурсов, часть из которых всегда простаивает, аренда ресурсов предлагает систему оплаты по фактическому потреблению. Благодаря этому, все ненужные, избыточные ресур-
151
сы не предоставляются, не учитываются и обеспечивают более эффективное использование средств.
Для того чтобы реализовать подобную инфраструктуру между облаком и клиентскими компьютерами, нужна модель взаимодействия. В подобной модели будет произведено распределение задач между клиентскими и серверными структурами. Что позволит наиболее эффективно использовать "облачные" ресурсы, в связке с ресурсами локальной сети и отдельными клиентами.
Облачные" технологии позволяют снять нагрузку с серверной системы и в большей степени задействовать интернет канал для обмена данными с "облачной" вычислительной системой. И тут возможно три варианта построения частных вычислительных сетей, не привязанных к географическому положению.
Вариант 1: все вычислительные мощности находятся внутри облака, доступ к данным возможен с помощью клиентского программного обеспечения, либо с помощью браузера и web-интерфейс АОС.
Вариант 2: часть вычислительных мощностей находится внутри частной локальной сети учебного заведения, что позволяет использовать АОС в случае обрыва интернет соединения. При этом "облачные" сервера выполняют роль мощных помощников, на которые возлагаются лишь сложные задачи. Круг таких задач четко определен, как определены и ситуации обращения к "облачным" серверам.
Вариант 3: Использование балансировщика нагрузки в локальной сети, который в случае критической нагрузки на внутренние локальные сервера, перекладывает часть выполняемых вычислений на "облачные" сервера.
Облачные" сервера также находятся в интранет сети и доступ к ним возможен лишь при наличии интернет соединения. Поэтому схема внутренней локальной сети университета не претерпевает изменений после принятия решения использования вычислительной мощности "облачных" серверов.
АОС может выполнять значительные трудоемкие задачи и поэтому в соответствии с клиент-серверной технологией серверную часть рекомендуется вынести в облако. При таком подходе АОС сможет позволить реализовать на своей платформе виртуальные физические лаборатории и т.п. ресурсоемкие приложения.
Рассмотрим систему, которая предлагает пользователю ознакомиться с теоретическим материалом по определенной теме, а затем выполнить различные наборы практических заданий. Задания на разработку и реализацию виртуальной физической модели сопряжены с большими нагрузками на вычислительный сервер, что может привести к его полной остановке. В случае пиковых нагрузок и мультипользовательском использовании
виртуальных физических лабораторий нагрузка на сервер возрастет еще более существенно. "Облачные" технологии в таком случае могут помочь оптимально распределить ресурсы для производимых вычислений и предоставить ресурсы по требованию.
Применение клиент-серверной архитектуры при создании приложений приводит к созданию клиентской и серверной части, как это показано на рис. 1.
Рис.1. Передача данных в ходе взаимодействия клиент - сервер
На рис. 2:
Front-End - публичная часть проекта, обеспечивающая прием запросов от пользователей, трансляцию запросов к Back-End и выдачу непосредственного содержимого пользователю.
Back-End - исполнительная часть системы, которая обеспечивает выполнение серверных скриптов, формирование контентных страниц и работу бизнес-логики приложения.
В свою очередь Back-End и Front-End очень насыщенны и состоят из множества структурных элементов.
Рассмотрим АОС, предназначенную для обучения программированию, которая позволяет обучающемуся самому изучать теоретический материал и выполнять практические работы без участия педагога. Принципы данной системы следующие.
1. Предоставить учащемуся возможность ознакомления с теоретическим материалом;
2. Предоставить условия задач для решений;
3. Принять от пользователя решения задач и проверить правильность;
4. Сделать записи в системном журнале касаемо действий, выполняемых пользователями в системе.
5. Предоставить пользователю возможность выбора дальнейших
действий в системе.
При реализации такой модели встает вопрос о распределении ресурсов между локальными серверами, клиентскими машинами и "облачными" серверами. Нельзя одной моделью охватить весь класс подобных задач, поэтому дальнейшая речь будет идти о создании модели для распределения ресурсов при использовании АОС модульного типа в рамках 2-го варианта построений вычислительных сетей из классификации выше. "Облачные" среды обладают следующими атрибутами: сервисной моделью, определяющей тип и характеристики сервисов, которые облако будет предоставлять потребителю,
высокой автоматизацией процесса предоставления сервиса по запросу потребителя и возможностью самообслуживания потребителя в рамках предоставляемого сервиса,
возможностью динамического масштабирования объема предоставляемой услуги, например, увеличения количества процессорной мощности, предоставляемой потребителю для обработки пиковых нагрузок,
эластичностью и разделяемостью, то есть уметь перераспределять имеющиеся ресурсы между потребителями и давать возможность прозрачного для потребителей расширения пула доступных ресурсов, возможностью учета потребления ресурсов.
Не затрагивая вопросы эффективности функционирования самого облака, рассмотрим способ взаимодействия с облаком, который и должен описываться моделью взаимодействия. Общая структура предлагаемой модели показана на рис. 2.
Рис. 2. Взаимодействие модулей "облачной" АОС
Обучаемый с помощью клиентской части для АОС получает доступ к ядру АОС и всем её возможностям, которые сосредоточены на главном
154
сервере - совокупности программного обеспечения запущенном на облаке. Программное обеспечение "Преподаватель-клиент" необходимо для того, чтобы администрировать главный сервер. Однако в клиентскую часть преподавательской машины входят и другие функции, такие как:
Получение актуальных записей из баз данных главного сервера. Актуальность проявляется в том факте, что клиент загружает лишь требуемые на данный момент данные из баз. Таким образом, у клиента всегда сохранены лишь самые новые результаты обучения. Результаты обучения по завершенным и слабо востребованным курсам всегда находятся лишь на сервере и могут быть получены по запросу. Это решение позволяет просматривать результаты обучения в ситуации отсутствии связи с главным сервером,
Получение актуальных записей из журналов статистики, отражающих ход взаимодействия клиентов с сервером.
По своей сути все процессы в "облачных" сетях запущены в виртуальных машинах, которые используют лишь требуемые ресурсы компьютерных систем. Поэтому все балансировку нагрузки между компьютерами в сети берет на себя провайдер. Арендатор "облачных" систем вправе устанавливать различное программное обеспечение и развертывать необходимые информационные серверы. Для рассматриваемой АОС это будет информационная конфигурация, представленная на рис. 3.
Рис.3. Структура сервисного программного обеспечения облака
Сервисное программное обеспечение "облачного" сервера может выглядеть как 3-уровневая модульная структура:
2-й уровень. Distributor_module - модуль распределитель. Позволяет определить по входящим данным, какие действия требует пользователь от сервера, на основе анализа происходит подключение того или иного мо-
155
дуля на первом уровне,
1-й уровень. Implementation_module - набор модулей, позволяющих выполнять заданные действия по манипуляции с данными, производить трудоемкие вычисления по средствам функций ядра приложения нулевого уровня,
Нулевой уровень. Core - ядро приложения, которое включает в себя низкоуровневые (относительно приложения) операции, которые позволяют производить трудоемкие вычисления. Через обращение к данным функциям строятся высокоуровневые абстракции данных в первом уровне.
Distributor module Уровень получения данных от интерфейса
2-й уровень пользователя и подключения модулей первого
уровня
Implementation module ...... AAAAAAAAAAAAAf 1-й уровень Уровень реализации поставленной задачи и манипуляции с шаблонами данных
Core Нул ев ой ур ов ень Ядро системы содержащее базовые функции для 1 'А ЧАЛААЛАЛААЛАЛАА 1 1 1 1 1 ^ 1 11 поддержания работоспособности АОС
Рис. 4. Модульная структура "облачной" части АОС
Используя уровень реализации можно задать необходимые шаблоны хранения данных на сервере, что в дальнейшем позволит раздельно изменять направленность приложения и методы управления данными, что обеспечивает гибкость в процессе работы с новым для системы типом информации.
Таким образом, выстраивая "облачную" АОС по вышеприведенной модели можно достичь следующих показателей:
повышение быстродействия АОС за счет использования мощных вычислительных систем,
высокой степени производительности клиентских приложений за счет вывода ресурсоемких приложений в область облака,
высокой степени защищенности данных от потери за счет репликации данных в облаке,
полного снижения нагрузки на серверы локальной сети учебного заведения.
Список литературы
1. Каштанов В. А., Медведев А. И. Теория надежности сложных систем. Санкт-Петербург: ФИЗМАТЛИТ, 2010. 608 с.
2. Липаев В.В., Распределение ресурсов в вычислительных системах. М.: Статистика, 1979. 246 с.
3. Gillam, Lee Cloud Computing: Principles, Systems and Applications. NY: Springer, 2010. 518 с.
A.N. Privalov, A.K. Klepikov
MODEL FOR RESOURCE ALLOCATION "CLOUD" COMPUTING
Consider using "cloud" technologies in the automated training systems. An option of building an automated learning system based on the "cloud" technologies.
Key words: automated learning system, the "cloud" technology, the allocation of resources.
Получено 07.03.12
УДК 519.168
А.Н. Привалов, д-р техн. наук, проф, зав. кафедрой, [email protected] (Россия, Тула, ТГПУ им. Л.Н. Толстого), Ю.И. Богатырёва, канд. пед. наук, доц., (4872) 35-20-09, [email protected] (Россия, Тула, ТГПУ им. Л.Н. Толстого)
ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ТРЕНАЖЁРНОЙ СИСТЕМЫ НА ОСНОВЕ СТАНДАРТНЫХ МОДУЛЕЙ
Рассмотрена проблема разработки специального программного обеспечения тренажёрных систем на основе унифицированных программных модулей. Сформулированы модели оптимизации специального программного обеспечения по критерию минимума избыточности программных модулей. Сформулированы математические модели унификации программных модулей
Ключевые слова: тренажёрная система, программное обеспечение, унифицированный программный модуль, синтез типовых модулей.
В общем случае тренажерная система (ТС) включает в себя ряд взаимодействующих тренажеров, имеющих структуру, приведенную на рис. 1.
