Файл: Облачные сервисы ( Основные характеристики и тенденции развития облачных технологий ).pdf

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

Архитектура и структура облачного сервиса.

Место разрабатываемого облачного сервиса в цепочке предоставления параллельного приложения (на примере ПК «Пирамида») как сервиса демонстрирует рис. 2.

Рис. 2. Архитектура облачного сервиса

Пользователь облачного сервиса через веб-интерфейс получает доступ к представлению SaaS. Представление SaaS обеспечивает хранение и обработку пользовательских данных, а также предоставляет интерфейс СУППЗ.

Разработка облачного сервиса подразумевает работу над тремя его составляющими:

- клиентская часть;

- серверная часть;

- интерфейс взаимодействия клиентской и серверной частей.

На рис. 3 обозначены основные структурные элементы облачного сервиса.

Рис. 3. Структура облачного сервиса

Взаимодействие клиентской и серверной частей сервиса было выстроено в соответствии с архитектурой RESTful. Преимущества, такого подхода, были обоснованы в различных источниках^[17], и в настоящее время применение архитектуры RESTful и программного интерфейса REST API де-факто является стандартом веб-программирования. REST API подразумевает унифицированный доступ к данным с некоторым ограниченным набором действий над ними. Данные, которыми обмениваются клиент и сервер, организуются в единый формат JSON.

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

- контроллер аутентификации, необходимый для обеспечения авторизованного доступа к облачному сервису;

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

- контроллер шаблонов, предназначенный для создания, хранения и изменения пользователями шаблонов своих заданий;

- контроллер заданий, необходимый для управления пользовательскими заданиями;

- контроллеры SSH-соединений и SSH-действий, необходимые для организации связи облачного сервиса с вычислительными установками под управлением СУППЗ.

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

В составе серверной части выделяются модуль аутентификации, осуществляющий управление пользователями, и контроллер SSH-соединений для управления соединениями с СУППЗ. Информация о текущей конфигурации облачного сервиса, о пользователях и доступных ВУ под управлением СУППЗ сохраняется в специальной базе данных (БД) облачного сервиса. Контроллеры REST API серверной части в ответ на запрос пользователя, в зависимости от характера поступившего запроса, либо производят обращение к БД, либо вызывают соответствующее действие контроллера SSH-соединений. Ответ на запрос преобразуется котроллером REST API в формат JSON и отправляется клиенту.

Выбор решений для построения облачного сервиса.

Для построения облачного сервиса в соответствии со структурой, представленной на рис. 3, необходимо выбрать следующие решения:

- веб-сервер;

- каркас серверного веб-приложения (Web Application Framework, WAF);

- систему управления базой данных (СУБД);

- средство поддержки SSH-соединений в веб-приложении;

- шаблон проектирования клиентской части.

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

- решение должно обеспечивать высокую скорость разработки;

- решение должно быть свободно распространяемым и функционировать в среде Linux;

- решение должно поддерживать схему «модель-представление- контроллер» (Model-View-Controller, MVC)^[18], согласно которой модель приложения, пользовательский интерфейс и взаимодействие с пользователем разделяются на три отдельных компонента таким образом, чтобы модификация одного из компонентов оказывала минимальное воздействие на остальные;

- решение должно быть широка распространённым и иметь хорошую документальную и инструментальную поддержку;

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

Кроме этого, выбираемые решения должны поддерживать совместную работу друг с другом.

Схема взаимодействия выбранных решений для построения облачного сервиса представлена на рис. 4.

В качестве веб-сервера и СУБД были выбраны Apache и MySQL соответственно, как полностью соответствующие приведённым требованиям.

Рис. 4. Выбранные решения для построения облачного сервиса

Каркас серверного веб-приложения, помимо соответствия перечисленным общим требованиям, должен:

- соответствовать архитектуре RESTful;

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

Анализ интернет-публикаций и мнений экспертов-разработчиков показал, что выдвинутым требованиям в полной мере удовлетворяют два распространённых решения - Django и Ruby on Rails (RoR). Отмечается, что при одинаково широкой распространённости обоих решений каркас Ruby on Rails более подходит для осуществления быстрой разработки, носящей исследовательский характер, а также содержит больше решений, готовых к использованию в новых проектах.^[19] По этой причине логика серверной части облачного сервиса была реализована с использованием каркаса RoR. Взаимодействие RoR-приложения c вебсервером Apache было обеспечено за счёт применения Ruby-библиотеки Passenger.

Модуль механизма аутентификации основан на Ruby-библиотеке Devise. Библиотека позволяет разрабатывать собственные системы аутентификации, используя современные алгоритмы авторизации и взаимодействия с пользователем.

Модуль взаимодействия с клиентской частью облачного сервиса состоит из набора RoR-контроллеров, предоставляющих REST API к ресурсам облачного сервиса. Для сущностей БД облачного сервиса такие контроллеры строятся автоматически при помощи объектного представления реляционной БД ActiveRecord.

Модуль взаимодействия с вычислительными установками по протоколу SSH основан на Ruby-библиотеке Net-SSH-shell.^[20]

Разработка клиентской части облачного сервиса предполагает использование стандартного стека веб-технологий: HTML5, JavaScript, CSS3. На сегодняшний день существует множество прекомпиляторов стандартного стека веб-технологий HTML, CSS, JavaScript, упрощающих разработку приложений различной специфики. С 2012 года мировыми лидерами веб-разработки активно используются шаблоны проектирования клиентской части веб-приложения. Такие шаблоны позволяют освободить разработчика от самостоятельного построения взаимодействия HTML-элементов страницы с JavaScript-логикой приложения. Код динамического веб-приложения, написанный без использования шаблонов проектирования, более чем наполовину состоит из функций взаимодействия страничных элементов с логикой приложения. Многие шаблоны проектирования позволяют структурировать изначально не имеющий стандартной структуры код JavaScript.

Здесь выбран шаблон проектирования Angularjs^[21] от корпорации Google. На сегодняшний день среди конкурирующих шаблонов проектирования Angularjs имеет наилучшую производительность, поддержку и документацию.

Модуль Angular-devise средствами одноименной JavaScript-библиотеки организует клиентские функции механизма аутентификации Devise.

В соответствии с шаблоном проектирования Angularjs, клиентская часть веб-приложения представляет собой одно или несколько одностраничных веб-приложений. Это означает, что все страницы и их контроллеры в пределах одного одностраничного приложения загружаются в браузер клиента в связке (либо одним файлом при предварительной конкатенации). В отличие от традиционной архитектуры клиентской части, одностраничное приложение является целостным и самостоятельным. По запросу клиента такое приложение загружается с веб-сервера в браузер один раз, а дальнейшая работа в нём (переход по страницам приложения, создание/удаление новых элементов страницы) сопровождается только асинхронным обменом данных (AJAX) с веб-сервером без перезагрузки страницы.

2.3. Проект облачного сервиса

В соответствии с технологией MVC структура серверного приложения облачного сервиса разбивается на модели, представления и контроллеры. Использование каркаса Ruby on Rails позволило автоматически сгенерировать (или использовать готовые) 80% необходимых контроллеров, 25% необходимых моделей и 20% необходимых представлений, что существенно ускорило процесс разработки.

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

Интерфейс пользователя спроектирован на трех страницах: «Шаблоны заданий», «Задания» и «Детали задания». Страницам соответствуют представления и их контроллеры (рис. 5), которые обмениваются данными через общее хранилище. Маршрутизатор содержит правила перехода по веб-страницам, пути и URL к представлениям и контроллерам.

Рис. 5. Структура приложения интерфейса пользователя

Через контроллер шаблонов осуществляется работа пользователя с шаблонами заданий, в том числе:

- загрузка шаблонов пользователя, сохранённых в БД серверной части облачного сервиса;

- отправка нового шаблона для сохранения в БД серверной части облачного сервиса;

- удаление шаблона из БД серверной части облачного сервиса;

- запуск параллельного задания по выбранному шаблону.

Контроллеры заданий и деталей задания выполняют следующие функции:

- загрузка заданий пользователя, сохранённых в БД серверной части облачного сервиса;

- остановка выполнения выбранного задания;

- удаление из очереди СУППЗ выбранного задания;

- удаление завершённого задания из БД серверной части облачного сервиса;

- синхронизация состояния данных клиентской и серверной частей облачного сервиса каждые 2 секунды.

Принцип построения приложения администратора (рис. 6) схож с принципом построения приложения пользователя, с точностью до изменения функций контроллеров.

Рис. 6. Структура приложения интерфейса администратора

Кондроллер пользователей выполняет следующие функции:

- загрузка зарегистрированных пользователей и доступных им соединений из БД серверной части облачного сервиса;

- загрузка соединений, сохранённых в БД серверной части облачного сервиса;

- сохранение в БД серверной части облачного сервиса обновлённой информации о доступных пользователям соединениях.

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

Со стороны клиента контроллер SSH-соединений осуществляет:

- загрузку соединений, сохранённых в БД серверной части облачного сервиса;

- отправку нового соединения для сохранения в БД серверной части облачного сервиса;

- удаление соединения из БД серверной части облачного сервиса;

- тестирование работоспособности соединения.

Управление заданиями осуществляется вызовом действий контроллеров серверной части облачного сервиса, отвечающих за SSH-соединения с вычислительными установками. REST API к этим действиям организует сервис SSH-действий.

Контроллер SSH-действий серверной части выполняет следующие действия:

- проверка работоспособности SSH-соединения;