CC BY
184
Труды ИСП РАН, том 27, вып. 6, 2015 г..
Расширение референтной модели облачной вычислительной среды в концепции крупномасштабных научных исследований1
А.В. Скаткое <AVSkatkov@sevsu.ru>
В.И. Шевченко <VlShevchenko@sevsu.ru>
Севастопольский государственный университет,
299053, Россия, г. Севастополь, ул. Университетская, дом 33
Аннотация. В условиях развития технологий облачных вычислений актуальной является задача разработки новых фундаментальных подходов и проработки методов прикладной реализации сервис-ориентированных облачных сред, обеспечивающих непрерывное развитие и поддержку крупномасштабных научных исследований. В статье дается краткий обзор облачных информационных технологий, рассмотрены основные модели предоставления услуг облачных вычислений. Исследованы архитектура и особенности реализации моделей облачных вычислений на основе референтной модели NIST. В работе на общесистемном уровне описаны состав, цели и функции акторов облачной вычислительной среды, ориентированных на выполнение и поддержку крупномасштабных научных исследований. Приведены схемы базовых сценариев взаимодействия акторов облачной инфраструктуры.
Ключевые слова: облачная вычислительная среда; адаптация; брокер облачных сервисов; уровень ИТ-сервиса; конвергентная инфраструктура.
1. Введение
Современное развитие информационных технологий, программного обеспечения и аппаратных средств позволяет организовывать сложные территориально-распределенные вычислительные системы для поддержки проведения крупномасштабных ресурсоемких фундаментальных и прикладных научных исследований. На сегодняшний день многие российские компании, научные организации и университеты используют облачные вычислительные среды с целью размещения своих научных и бизнес-приложений, что позволяет им избежать расходов на создание и поддержание
Работа выполнена при финансовой поддержке Российского фонда фундаментальных исследований по проекту № 15-29-07936
285
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
функционирования собственных центров обработки данных. Владельцы облачных вычислительных систем путем консолидации вычислительных ресурсов и систем хранения данных способны снизить совокупную стоимость владения ИТ-инфраструктурой за счет обслуживания значительного количества пользователей, а также использования эффективных технических средств планирования и балансировки нагрузки, управления пересылкой данных в сети, интеграции нескольких территориально разрозненных сегментов систем хранения данных [1].
Кроме того, все большее распространение получает модель научной кооперации и разделения труда [2], основанная на совместной работе территориально распределенных международных коллективов исследователей в рамках концепции «сервис-ориентированной науки» (Service-Oriented Science) [3]. В соответствии с данной концепцией сервис-ориентированный подход позволяет организовать распределенный доступ к разнородным научным ресурсам, автоматизировать процесс научных исследований и тем самым повысить их эффективность.
В настоящее время отсутствуют проработанные подходы к реализации сервис-ориентированных облачных сред для крупномасштабных научных исследований. Обусловлено это как относительной новизной данного направления, так и рядом технологических проблем, стоящих на пути реализации подобных сред. В частности - не достаточный уровень компетенций исследователей в области установки, конфигурации и дальнейшей поддержки гарантированного уровня ИТ-сервисов в облачной вычислительной среде. Необходимо снижение технологического барьера для потенциальных пользователей-исследователей облачных сервисов, что может быть достигнуто путем привлечения сторонних посреднических служб и реализации проблемно-ориентированных интерфейсных сред, скрывающих техническую сторону функционирования сервисов и сложность поддерживаемой вычислительной инфраструктуры.
В данной статье предложена референтная модель облачной вычислительной среды, базирующаяся на эталонной архитектуре NIST (National Institute of Standards and Technology) [4, 5], имеющая ряд дополнений с учетом специфики решения крупномасштабных научных задач. Авторами предлагается описание на общесистемном уровне процессов взаимодействия акторов облачного сервиса при проведении крупномасштабных научных исследований. Целью исследований является разработка методологических основ для построения системы поддержки принятия решений по управлению взаимодействием гетерогенных облачных агентов с целью повышения качества ИТ-сервисов при решении крупномасштабных научных задач.
В разделе 2 приведен обзор основных моделей предоставления услуг облачных вычислений и тенденции их развития. В разделе 3 даны необходимые определения, описаны основные акторы референтной модели облачной вычислительной среды, адаптируемой к специфике процессов научных исследований, приведены базовые сценарии взаимодействия акторов.
286
Труды ИСП РАН, том 27, вып. 6, 2015 г..
В заключении приведены направления дальнейших исследований в развитии концепций облачных вычислительных сред ориентированных на поведение и поддержку крупномасштабных научных исследований.
2. Обзор основных моделей предоставления услуг облачных вычислений
Согласно определению, предложенному в [6], облачные вычисления - это модель организации удаленного доступа по запросу к разделяемому набору конфигурируемых вычислительных ресурсов, которые могут быть быстро выделены и освобождены с минимальными расходами на управление или
взаимодействие с провайдером услуг.
В работах [6,7] описаны три основных модели обслуживания облачных сервисов:
• Программное обеспечение как сервис (Software as a Service, SaaS). Пользователю предоставляется возможность использования прикладного программного обеспечения провайдера, работающего в облачной инфраструктуре и доступного из различных клиентских устройств. Контроль и управление основной физической и виртуальной инфраструктурой облака осуществляется облачным провайдером.
• Платформа как сервис (Platform as a Service, PaaS). Пользователю предоставляется возможность использования облачной инфраструктуры с набором базового программного обеспечения для последующего размещения, разработки и тестирования на нем своих программных приложений. В состав таких платформ входят инструментальные средства создания, тестирования и выполнения прикладного программного обеспечения, предоставляемые облачным провайдером. Провайдер осуществляет контроль и управление физической и виртуальной инфраструктурой облака, за исключением приложений, разработанных и установленных пользователем.
• Инфраструктура как сервис (Infrastructure as a Service, IaaS). Пользователю предоставляется возможность использования облачной инфраструктуры для самостоятельного управления ресурсами обработки, хранения. Потребители развертывают собственное программное обеспечение, включая операционные системы и приложения на инфраструктуре провайдера. Пользователи могут контролировать операционные системы, виртуальные системы хранения данных и установленные приложения, а так же осуществляют ограниченный контроль набора доступных сервисов.
Схема основных вычислительных моделей приведена на рис. 1. Применение таких облачных технологий как PaaS и IaaS привело к возрастающему переносу данных в облачные хранилища, что в свою очередь, вызвало
287
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
необходимость решения задач интеграции композитных облачных приложений.
1* * ' ft ^
X X 2 со § I § О S о X Т 2 X 5? 1 3
2 £ ц § § S >>о S с 1 |
^ & и 4> S § §
X а 8 Си К с
^ if
PAAS
SAAS
Рис. 1. Схема основных вычислительных моделей облачной инфраструктуры
В исследовании [8] сформулированы ключевые особенности новой модели облачных сервисов - Integration Platform as Service (iPaaS). iPaaS объединяет множественные облачные сервисы с целью интеграции и управления любой комбинацией внутренних и внешних (т.е. облачных) приложений, SOA и облачных сервисов, процессов и данных внутри и вне организации. Решения iPaaS способны обеспечивать многообразие сценариев интеграции и предоставлять безопасные средства доступа к корпоративным платформам [9]. В работе [10] рассмотрен вариант модели предоставления облачных сервисных услуг - аналитика как сервис (Data Mining as a Service, DMaaS) -данные, анализируемые пользователем «трансформируются» в микрокубы на «облаке». Кроме того предлагается трансформация не только данных, введенных в таблицу, но и любых данных предприятия, которое в таком случае оплачивает трансформационные затраты и анализирует данные. На сегодняшний день концепция облачных вычислений предполагает оказание потребителям различных дополнительных видов облачных услуг: Storage-as-a-Service, Database-as-a-Service, Information-as-a-Service, Process-as-a-Service, Integration-as-a-Service, Testing-as-a-Service [11-13]:
• Storage-as-a-Service («хранение как сервис»). Услуга дает возможность сохранять данные во внешнем хранилище, в «облаке». Для пользователя внешнее удаленное хранилище будет выглядеть, как дополнительный логический диск или папка.
• Database-as-a-Service («база данных как сервис»). Модель, основана на модели SaaS, в рамках данной модели пользователю предоставляется база данных требуемой конфигурации.
• Information-as-a-Service («информация как сервис»). Дает возможность пользователю удаленно использовать любые виды информации, в режиме реального времени.
• Process-as-a-Service («управление процессом как сервис»). Представляет собой удаленный ресурс, который может связать воедино несколько ресурсов (таких как услуги или данные,
288
Труды ИСП РАН, том 27, вып. 6, 2015 г..
содержащиеся в пределах одного «облака» или других доступных «облаков»), для создания единого бизнес-процесса.
• Security-as-a-Service («безопасность как сервис»). Комплекс услуг по обеспечению безопасности, осуществляемое удаленно на базе системы, находящейся в собственности третьей стороны (одного или нескольких поставщиков услуги). Поставщик обеспечивает функции безопасности, основанные на разделяемых технологических услугах, которые потребляются в рамках модели «один ко многим» с оплатой по факту использования объема потребленных услуг. Данный вид услуги предоставляет возможность пользователям быстро развертывать программные продукты, позволяющие обеспечить безопасное использование Интернет-технологий, электронной переписки, локальной сети и т.п., что позволяет пользователям данного сервиса экономить на развертывании и поддержании своей собственной системы безопасности.
• Management/Govemace-as-a-Service («администрирование и управление как сервис»). Дает возможность пользователям управлять и задавать параметры работы одного или многих «облачных» сервисов. В основном это такие параметры, как топология сети, использование ресурсов, виртуализация.
• Testing-as-a-Service («тестирование как сервис»). Дает пользователям возможность тестирования локальных или «облачных» вычислительных систем с использованием тестового программного обеспечения из «облака» (при этом никакого специального оборудования или обеспечения пользователям не требуется). Соответствие дополнительных моделей облачных сервисов базовой трехзвенной архитектуре приведено на рис.2.
Management / Govemace as a Service
Tfl
я
ж
я
►»
•с
S
Database as a Service
Data Mining as a Service
Testing as a Service
Storage as a Service
Information as a Service
Process as a Service
. Infrastructure! a!s ia Service
я
ж
я ^
Рис. 2. Схема соответствия дополнительных моделей облачных сервисов базовой трехзвенной архитектуре по типам услуг
289
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
Тенденция развития облачных инфраструктур такова, что все вышеперечисленные типы моделей образуют новые виды сервисов, объединенные в обобщенную модель «Все как сервис» (Everything as a Service, EaaS) [14]. Идеологически близкими к этой модели являются модели XaaS (Anything as a Service - «какой-нибудь ресурс как сервис») [15] и *aaS (*as а Service - «любой ресурс как сервис»). В соответствии с моделью EaaS все ресурсы предполагаются реализуемыми в виде услуг. Предполагается также, что цены на различные облачные услуги неодинаковы, то есть час пользования каждой отдельной услугой имеет разную стоимость (тарифный план). Потенциальные объемы предоставления облачной услуги провайдером при имеющихся аппаратных и программных ресурсах в каждый конкретный момент формально не ограничены [16].
В рамках дальнейших исследований авторы статьи рассматривают модель EaaS, как наиболее полно адаптируемую к специфике крупномасштабных научных исследований.
3. Референтная модель облачной вычислительной среды
3.1 Основные понятия и определения
Согласно [17], референтная модель — концептуальная модель, формализующая рекомендованные практики ведения бизнеса в определенной области. Отличительными признаками референтной модели являются: отражение наилучших практик ведения бизнеса; универсальность применения (референтная модель представляет не отдельное предприятие, а класс предприятий); возможность повторного использования. Референтная модель является подвидом концептуальной модели, отражает основные характеристики определенного класса предприятий, может быть использована для проектирования множества информационных систем и включает: функциональную структуру; объектную модель предметной области; процессную модель; функциональную модель; набор потенциальных точек контроля; набор операционных показателей деятельности предприятия.
Для построения модели облачной вычислительной среды, адаптированной для крупномасштабных научных вычислений в рамках концепции «сервис-ориентированной науки» авторами предлагается использовать эталонную архитектуру NIST [4-6], открытый интерфейс облачных вычислений, разработанный рабочей группой Open Cloud Computing Initiative международной организации Open Grid Forum [18] и методологию ITSM (IT Service Management), описанную в библиотеке ITIL (IT Infrastructure Library) [19-21]. В работах [18,19] даны ряд определений, применимых в референтной модели облачной среды.
Ресурс - физический или виртуальный объект с ограниченной доступностью. Физические ресурсы представляют собой вычислительные, запоминающие и коммуникационные ресурсы. Виртуальные ресурсы это, как правило,
290
Труды ИСП РАН, том 27, вып. б, 2015 г..
сервисы, которые предоставляют прямо или косвенно доступ к физическим вычислительным ресурсам.
Сервис-провайдер - субъект, который организует доступ к необходимому ресурсу или позволяет выполнить действие на ресурсе. Сервисы в свою очередь могут быть сервисами низкого уровня, которые работают в основном на физических ресурсах или сервисами высокого уровня, которые работают с виртуальными ресурсами (т.е. с другими сервисами). Сервисы проявляют своё назначение посредством интерфейса сервиса.
Система - набор сервисов и ресурсов, интегрированных в единое целое. Система может быть создана путём интеграции нескольких систем. Системы высокого уровня образуются из систем низкого уровня методом агрегации. Порталы и научные входы - прикладная среда высокого уровня, которая ориентирована на упрощение работы конечного пользователя-исследователя. Соглашение об уровне предоставления услуги (Service Level Agreement, SLA) - формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и согласованный уровень качества предоставления данной услуги.
Процесс - это логически взаимосвязанная между собой последовательность работ (видов деятельности (activities)), направленная на достижение поставленной цели.
3.2 Акторы облачной вычислительной среды
В эталонной архитектуре облачных вычислений NIST (рис. 3) определен состав участников, деятельность и функции, которые могут быть реализованы в процессе разработки архитектур облачных вычислений, установлены базовые взаимоотношения между участниками облачных вычислений.
291
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
В предлагаемой авторами архитектуре выделено семь взаимодействующих акторов, выполняющих определенные функциональные задачи: Потребитель (П), Провайдер (Пр), Брокер (Б), Аудитор (А), Кризисный менеджер (КМ), Облачный композитный архитектор (ОКА), Регулятор (Р). В табл. 1 отражена связь функций акторов модели с соответствующими процессами поддержки ИТ-сервисов модели ITIL.
Табл. 1. Связь функций акторов модели облачной вычислительной среды с процессами управления ИТ-сервисами модели ITIL
Актор Service Desk / Управление взаимодействием с пользователем Предоставление услуг Поддержка услуг Управление безопасностью
Управление финансами Управление уровнем услуг Управление непрерывностью ИТ-услуг Управление доступностью Управление мощностями Управление релизами Управление инцидентами Управление проблемами Управление конфигурациями
П * * * *
Б * * * * * * *
Пр * * * * * * * * * * *
А * * * * * *
КМ * * * * * * *
ОКА * * *
Р * * *
Далее описываются основные характеристики акторов, с учетом прикладной специфики решения крупномасштабных научных задач. Концептуальная схема архитектуры облачных вычислений представлена на рис. 4.
Облачный Потребитель (далее Потребитель, Клиент или Пользователь) является представителем множества Потребителей - организаций (научных сообществ), взаимодействующих с техническими средствами Провайдера при посредничестве Брокера. Потребитель проводит научные исследования с использованием сервисов облачной среды, предоставляемых Провайдером. В рамках предлагаемой модели, в зависимости от сценария взаимодействия, Потребитель может быть рассмотрен как атомарная сущность, либо как иерархическая структура.
Облачные Потребители категоризируются по трем группам, в зависимости от используемой модели облачных сервисов: SaaS - в этом случае Потребитель использует приложения/сервисы для автоматизации научных исследований; PaaS - Потребитель разрабатывает, тестирует, развертывает и управляет собственными приложениями (мониторинговыми облачными средами, СППР) по обработке данных и может предоставлять результаты своих исследований 292
Труды ИСП РАН, том 27, вып. 6, 2015 г..
другим Потребителям, как сервисы; IaaS - в этом случае сервис Провайдера представляет собой своеобразную «социальную сеть» по проведению научных разработок и обработки данных. С точки зрения уровня полномочий Потребителя в проведении исследований быть произведена группировка по ролям: руководитель проекта, исследователь, инженер по сбору данных и т.п.
В качестве метрик оценки эффективности Потребителя с точки зрения управляющего Регулятора могут быть рассмотрены следующие показатели: уровень исследовательской компетенции; уровень технологической компетенции (степень владения технологией взаимодействия с облачным провайдером); уровень заинтересованности в результатах научных исследований (мотивированность).
Рис. 4. Концептуальная схема референтной архитектуры облачных вычислений
Облачный Провайдер (далее Провайдер) - лицо, организация или сущность, обеспечивает возможность пользования облачными услугами для Потребителя. Предоставляет услуги, включая уровень EaaS, в зависимости от действующего соглашения с Потребителем. В рамках рассматриваемой модели предполагаем, что Провайдер берет на себя функцию Облачного Оператора Связи, либо управление выбором Оператора Связи. Оператор
293
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
Связи, как отдельный субъект управления не рассматривается. Качество ИТ-сервисов, предоставляемых Провайдером оценивается по метрикам ITIL [20]. Облачный Брокер (далее Брокер). В классической модели - сущность, управляющая использованием, производительностью и предоставлением облачных услуг, а также устанавливающая отношения между Провайдерами и Потребителями. Поскольку сообщество пользователей-исследователей может обслуживаться одновременно несколькими провайдерами на основе модели «гибридного облака» задача установления взаимосвязи «потребитель-провайдер» усложняется. В предлагаемой модели Брокер действует от лица Регулятора, руководствуется его нормативными управляющими воздействиями и целевой функцией с учетом динамически меняющихся ресурсных требований Потребителя. Динамизм ресурсных требований Потребителя обусловлен спецификой решаемых научных задач и уровнем компетенций представителей Потребителя.
Регулятор - специфическая для рассматриваемого проекта сущность для отражения централизованного управления взаимодействием Потребителей с остальными сущностями модели, объединяющая с точки зрения процессов управления, множество Потребителей, Провайдеров и Брокеров и имеющая общесистемную целевую функцию управления крупномасштабными научными исследованиями. Осуществляет управление на основе анализа данных об эффективности использования информационно-вычислительных ресурсов, качестве ИТ-сервисов, уровне компетенции Потребителей, получаемых от Облачного Аудитора и Кризис-менеджера.
Облачный Аудитор - сущность, выполняющая независимую оценку облачных услуг, обслуживания информационных систем, производительности и безопасности реализации облака. С учетом специфики научных проектов, которые выполняются на основе ряда формальных правил, определяемых Регулятором, по распределению материальных, финансовых и информационных ресурсов, эта сущность будет осуществлять функции внешнего аудита Потребителей, Провайдеров и Брокеров и на основе анализа результатов аудита выделении наиболее критичных сущностей, с точки зрения выбранных Регулятором метрик качества.
Кризисный менеджер - класс специфических для рассматриваемого проекта сущностей, используемых в двух направлениях: ИТ-инфраструктура, научные исследования. Может применяться опционально, как альтернатива Аудитору, но с большими функциональными возможностями. Этот актор предназначен для использования в случае возникновения критических ситуаций в облачной инфраструктуре. Проводит анализ ИТ-инфраструктуры (уровня качества научных исследований) с целью выявления слабых и сильных мест и выработки мероприятий, позволяющих Регулятору вывести облачную инфраструктуру (или проводимое научное исследование) из кризиса с минимальными потерями. В условиях бюджетного финансирования ряда научных разработок внедрение такой сущности обосновано необходимостью
294
Труды ИСП РАН, том 27, вып. 6, 2015 г..
минимизации нецелевого расходования бюджетных средств и максимизации инновационного эффекта от инвестиций в научные исследования.
Облачный композитный архитектор (далее Архитектор) - новая специфическая для рассматриваемого проекта сущность. Это лицо или организация, отвечающая за разработку архитектуры композитного приложения и адаптацию его в облачной инфраструктуре для конкретного научного проекта, повышение уровня компетенций Потребителей с целью эффективной проведения исследований в разработанной композитной среде. Подробнее взаимодействие акторов в архитектуре облачных вычислений рассматривается на примере сценариев, с учетом сценариев изложенных в NIST.
3.3 Базовые сценарии взаимодействия акторов в архитектуре облачных вычислений
В предлагаемых сценариях акторы разбиты на группы, в зависимости от числа взаимодействующих сущностей: <1:1>, <1:N>,<M:N>. Рассмотрим последовательно сценарии взаимодействия акторов в архитектуре облачных вычислений, в порядке их усложнения.
Сценарий 1 (рис.5а): Потребитель запрашивает услугу (сервис) у Облачного Провайдера. Менаду Провайдером и Потребителем устанавливается соглашение об уровне обслуживания SLA. В случае изменения требований Потребителя к предоставляемым ИТ-сервисам или несоответствие предоставляемых Провайдером услуг метрикам SLA соглашение об уровне обслуживания пересматривается, либо Потребитель меняет Провайдера.
Задача Потребителя минимизировать расходы при максимальном уровне ИТ-сервиса. Задача Провайдера максимизировать доходы от обслуживания Потребителя и минимизировать выделяемые технические и технологические ресурсы при соблюдении гарантированного уровня SLA.
Сценарий 2 (рис. 56): Множество облачных Потребителей запрашивает услугу (сервис) у одного облачного Провайдера. Взаимодействия между отдельными Потребителями и Провайдером аналогичны Сценарию 1.
(
Облачный
потребитель
>
а)
<
Облачный
Провайдер
)1 Облачный ^ I потребитель W
б)
Рис.5. Схема сценариев 1(a) и 2(6)
i
Облачный
Провайдер
)
Перед Провайдером стоит задача эффективного распределения ресурсов и сервисов между множеством Потребителей в условиях реального времени, с учетом динамически меняющихся потребностей отдельных Потребителей. Сценарий 3 (рис. 6): Иерархически организованное множество Потребителей запрашивает сервис у Провайдера. Рассмотрим внутреннюю структуру
295
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
сущности Облачный Потребитель. Если в качестве Потребителя выступает атомарная сущность - физическое лицо, организация или подразделение, рассматриваемые как единый объект, то для таких сущностей применимы Сценарии 1 и 2. В случае, когда Потребитель имеет иерархическую структуру, то его атомарной сущностью является Пользователь, непосредственно взаимодействующий с ИТ-сервисами и техническими средствами Провайдера путем генерации первичных или вторичных данных, получения к ним доступа и инициации процессов по корректировке объема потребляемых ресурсов Провайдера. Однако, в этом сценарии Облачный Провайдер невидим Потребителю. Вместо прямого взаимодействия с Провайдером Потребители-пользователи делегируют полномочия взаимодействия с Провайдером одному Потребителю, осуществляющему руководство научным проектом. Потребители-пользователи формируют заявки на ресурсы и сервисы в зависимости от решаемых ими научных задач. На основе этих данных Потребитель-руководитель требования к соглашению об уровне обслуживания SLA с Облачным Провайдером.
'( ^
Облачный
потребитель- £-н потребитель- М ? Облачный
пользователь руководитель 1 Провайдер
L з)
Рис. 6. Схема сценария 3
Перед Потребителем-руководителем стоит задача эффективного распределения ресурсов и сервисов менаду множеством Потребителей-исполнителей в условиях минимизации затрат на услуги Провайдера. Взаимодействие менаду Потребителем-руководителем и Провайдером аналогично Сценарию 1.
Сценарий 4 (рис. 7): Множество Потребителей, имеющих иерархическую структуру, запрашивает сервис у одного облачного Провайдера.
Облачный
потребитель-
пользователь
Ы
Облачный
потребитель-
руководитель
М
Рис. 7. Схема сценария 4
Облачный
Провайдер
Данный сценарий является комбинацией Сценария 2 и Сценария 3.
Сценарий 5 (рис. 8): Потребитель запрашивает услугу у Облачного Брокера вместо прямого взаимодействия с Провайдером. Брокер может создать новый сервис, комбинируя набор сервисов или расширяя существующий сервис, в зависимости от требований Потребителя, за счет использования ресурсов и сервисов нескольких Провайдеров. В этом сценарии Провайдер невидим Облачному Потребителю.
296
Труды ИСП РАН, том 27, вып. 6, 2015 г..
1 1 1 Облачный 1 Облачный Облачный
потреоитель ^ Брокер Провайдер
Рис.8. Схема сценария 5
Задача Брокера максимизировать экономический эффект от посреднических услуг при взаимодействии Потребителя и Провайдера. Задача Потребителя минимизировать расходы на услуги Брокера при максимальном уровне сервиса. Задача Провайдера максимизировать доходы от взаимодействия с Брокером и минимизировать выделяемые технические и технологические ресурсы при соблюдении гарантированного уровня SLA.
Сценарий 6: Множество Потребителей запрашивает услугу у Облачного Брокера. Взаимодействия между отдельными Потребителями и Брокером, а так же между Брокером и Провайдером аналогичны Сценарию 5.
Задача Брокера максимизировать совокупный экономический эффект от посреднических услуг при взаимодействии с множеством Потребителей со множеством Провайдеров.
Сценарий 7 (рис.9): Иерархически организованное множество Потребителей запрашивает услугу у Облачного Брокера. Данный сценарий является комбинацией Сценария 3 и Сценария 5. В этом сценарии Провайдер и Брокер невидимы Потребителю-пользователю, Облачный Провайдер не видим так же Потребителю-руководителю.
Облачный N 1 Облачный , /
потребитель-
пользователь руководитель
Облачный
Брокер
>
JJ Облачный 1 Провайдер
Рис. 9. Схема сценария 7
Перед Потребителем-руководителем стоит задача эффективного распределения ресурсов и сервисов между множеством Потребителей-исполнителей в условиях минимизации затрат на посреднические услуги Брокера. Взаимодействие между Потребителем-руководителем и Потребителями-пользователями аналогично Сценарию 3. Взаимодействие Потребитель-руководитель — Брокер, Брокер — Провайдер аналогично Сценарию 5.
Сценарий 8: Множество Облачных Потребителей, имеющих иерархическую структуру, запрашивает услугу у одного Облачного Брокера. Предлагаемый сценарий является комбинацией Сценария 4 и Сценария 7. В данном сценарии Потребитель-пользователь не взаимодействует напрямую с сущностями Брокер и Провайдер. Задача Брокера максимизировать совокупный экономический эффект от посреднических услуг при взаимодействии с множеством Потребителей, имеющих иерархическую структуру, и множеством Провайдеров.
297
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
Сценарий 9 (рис. 10): Облачный Аудитор проводит независимую оценку обслуживания и безопасности реализации облачной услуги. В случае выявления Аудитором несоответствия предоставляемых Провайдером услуг метрикам SLA соглашение об уровне обслуживания между Потребителем и Провайдером пересматривается, либо Потребитель меняет Провайдера.
Облачный и ^ Облачный
потребитель 1. Мониторинг А Провайдер г 1 Jj
^^уровня SLA^^ 1 \/ 1 1
Облачный
аудитор
Рис. 10. Схема сценария 9
В задачи Аудитора входят только мониторинговые функции и их оценка в соответствии с эталонными значениями метрик качества ИТ-сервисов. Принятие управляющих решений осуществляется на стороне Потребителя. Сценарий 10 (рис. 11): Аудитор проводит независимую оценку обслуживания и безопасности реализации облачной услуги для иерархически организованного множества облачных Потребителей. На основе данных о качестве ИТ-сервисов, получаемых от Потребите лей-пользователей облачный Потребитель-Руководитель инициирует процедуру аудита ИТ-сервисов. Предлагаемый сценарий базируется на сценарии 9. Функции первичного мониторинга качества ИТ-сервисов могут быть делегированы Потребителям-пользователям, в этом случае данные о результатах мониторинга передаются через Потребителя-ру ко водителя Аудитору. Прямого взаимодействия между Аудитором и Потребителем-пользователем сценарий не предусматривает.
передаваемые через Потребителя Аудитору
Рис.11. Схема сценария 10
В задачи Аудитора входят обработка результатов первичного мониторинга и их оценка в соответствии с эталонным значениями метрик качества ИТ-
298
Труды ИСП РАН, том 27, вып. 6, 2015 г..
сервисов. Принятие управляющих решений осуществляется Потребителем-руководителем.
Сценарий 11 (рис. 12): Аудитор проводит независимую оценку обслуживания и безопасности реализации облачной услуги для множества иерархически организованных групп облачных Потребителей. Аудит группы облачных потребителей инициируется Регулятором, взаимодействия между Аудитором и Регулятором выделены в отдельном сценарии.
- данные о текущем состоянии уровня сервисов получаемые от Пользователей и передаваемые Аудитору
Рис.12. Схема сценария 11
В задачи Аудитора входят: обработка результатов первичного мониторинга; их оценка в соответствии с эталонными значениями метрик качества ИТ-сервисов; классификация ИТ-инфраструктур, поддерживаемых Провайдером по степени критичности и передача информации о наиболее критичных инфраструктурах Кризис-менеджеру. Кризис-менеджер на основе экспертных оценок и собственной базы знаний формирует набор рекомендаций по реинжинирингу критичных ИТ-инфраструктур для Провайдера.
Сценарий 12: Аудитор проводит независимую оценку качества проводимых исследований, проводимых множеством иерархически организованных групп облачных Потребителей. Аудит группы Потребителей инициируется Регулятором, взаимодействия менаду Аудитором и Регулятором выделены в отдельном сценарии. В предлагаемой схеме каждая из иерархически организованных групп Потребителей выполняет свой обособленный набор функциональных задач в рамках научных исследований.
В задачи Аудитора входят: обработка результатов первичного мониторинга; их оценка в соответствии с эталонными значениями метрик качества научных исследований; классификация групп облачных Потребителей-исполнителей, под управлением Потребителя-руководителя по степени критичности и передача информации о наиболее критичных инфраструктурах Потребителей Кризис-менеджеру. Кризис-менеджер на основе экспертных оценок и собственной базы знаний формирует набор рекомендаций по реинжинирингу бизнес-процессов задач научных исследований в критичных инфраструктурах Потребителей. На основе этих рекомендаций формируются сценарии взаимодействия для Регулятора и Композитного архитектора.
299
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
Сценарий 13 (рис. 13): Композитный Архитектор разрабатывает
оригинальную архитектуру композитного приложения для нового научного проекта Потребителя и адаптирует приложение к облачной инфраструктуре выбранного Провайдера.
Рис. 13. Схема сценария 13
Сценарий 14: Облачный Кризис-менеджер в случае отсутствия готовых решений по разрешению кризисных ситуаций при взаимодействии Потребителей и Провайдеров передает управление на более высокий уровень эскалации - Композитному Архитектору. Архитектор разрабатывает
оригинальную архитектуру композитного приложения для конкретного научного проекта Потребителя и адаптирует приложение к облачной инфраструктуре выбранного Провайдера. Предложенный сценарий
функционально расширяет сценарий 13.
Сценарий 15 (рис. 14): Регулятор получает данные от внешних систем мониторинга и Аудитора.
От инфраструктуры Потребителей: данные о состоянии проводимых научных исследований, включая текущие значения метрик оценки качества; данные о необходимых ИТ - сервисах; данные о расходовании бюджетов на научно-исследовательские работы (НИР). От Облачных Брокеров, посредством Аудитора или напрямую Регулятор получает данные: о текущих требованиях к ИТ-сервисам; о составе предоставляемых ИТ-сервисов конкретному
300
Труды ИСП РАН, том 27, вып. 6, 2015 г..
Потребителю; о группе Провайдеров, предоставляющих полный комплекс сервисов Потребителю. От Провайдеров Регулятор получает информацию об эффективности использования отдельным Пользователем предоставляемых ИТ-сервисов. Задача Регулятора - посредством встроенной системы поддержки принятия решений на основе полученных мониторинговых данных осуществлять эффективное управление всей облачной инфраструктурой.
4. Заключение
Анализ работ в области моделирования облачных сервисов с учетом специфики крупномасштабных научных задач показал, что на сегодняшний день актуальным является развитие направления поддержки ИТ-сервисов «Все как сервис» (EAAS). Вследствие чего существующие модели концептуального описания взаимодействия акторов облачной среды нуждаются в расширении с учетом специфики поставленных задач. В данной статье на общесистемном уровне описаны процессы взаимодействия акторов облачного сервиса при проведении крупномасштабных научных исследований. Исследована архитектура и особенности реализации модели облачных вычислений, основанной референтной модели NIST, но включающей дополнительных акторов: кризис-менеджер и облачный
композитный архитектор. Особенностью предлагаемой референтной модели является адаптация к специфике крупномасштабных научных задач, решаемых в распределенных средах на базе модели гибридного облака. В предлагаемой модели, в отличии от модели NIST, учитывается процессный подход к управлению взаимодействием акторов облачной среды на основе методологии ITSM. В работе приведены схемы базовых сценариев взаимодействия акторов облачной инфраструктуры, которые могут быть расширены и дополнены в зависимости от специфики функциональных задач. В дальнейшем планируется концептуальное описание отдельных актров предлагаемой референтной модели, включающее: параметры, наиболее полно характеризующие актора; целевые функции акторов. На базе этого разработка диаграмм концептуальных классов в нотации UML, позволяющей перевести описание сценариев поведения облачной вычислительной среды в единую инфологическую модель.
Список литературы
[1] . Miller R. Who Has the Most Web Servers? May 14,2009
fhttp://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-
servers/~)
[2] . Сухорослов О. Реализация и композиция проблемно-ориентированных сервисов в
среде MathCloud. Вестник ЮУрГУ, Серия «Математическое моделирование и программирование», вып. 8, №17 (234), 2011 г. стр. 101-112.
[3] . Foster! Service-Oriented Science. Science, 308 (5723), 2005. P. 814-817.
[4] . Liu F., Tong J., Mao J., Bohn R., Messina J., Badger L., Leaf D. NIST Cloud
Computing Reference Architecture. Recommendations of the National Institute of Standards and Technology. Cloud Computing Program Information Technology
301
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 September 2011 (http://www.nist.gov/customcf/get pdf.cfm?pub id=909505 )
[5] . Mell P., Grance T. The NIST Definition of CloudComputing. Recommendations of the
National Institute of Standards and Technology, 2010.
[6] . Hogan M., Liu F., Sokol A., Tong J. NIST Cloud Computing Standards Roadmap.
Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 July 2011 (http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909024)
[7] . Прудникова А., Садовникова T. Анализ облачных сервисов с точки зрения
информационной безопасности. T-Comm - Телекоммуникации и Транспорт, вып.7, 2012 г. стр. 153-156
[8] . Pazzini М., Benoit J. Lheureux. Integration Platform as a Service: Moving Intergation to
the Cloud. Gartner RAS Core Research Note G00210747, March 7, 2011 (https://www-304.ibm.com/industries/publicsector/fileserve?contentid=2507361
[9] . Еловиков А. Новые тенденции интеграции в облаке. Научный журнал КубГАУ,
№83(09), 2012 г. (http://ej.kubagro.ru/2012/09/pdiy36.pdf)
[10] . Афанасьев С. Облачные сервисы, онтологическое моделирование. Труды
СПИИРАН, вып. 4(23), 2012 г. стр. 392-399
[11] . Тим Джонс М. Cloud Computing и Linux Платформы и приложения для Cloud
Computing. Developer Works, 25.12.2008
(https: //www. ibm. com/ developerworks/ruAibrarv/l-cloud-computing/l-cloud-computing-
pdf.pdfl
[12] . Рогальский E. Облачные технологии и их роль в развитии электронного обучения.
Исследования наукограда, №1(7), 2014 г. стр. 42-49
[13] . Баженова И. Применение облачных технологий при дистанционном обучении
языкам программирования. Вестник Московского государственного лингвистического университета, №13 (699), 2014 г. стр. 45-52
[14] . Everything as a Service (EaaS). URL: http://www.csc.
com/business_drivers/offerings/78750-everything_as_a_service_eaas (дата обращения: 15.01.2014)
[15] . XaaS (anything as a service). URL:
http://searchcloudcomputing.techtarget.com/defmition/XaaS-anything-as-a-service (дата обращения: 15.01.2014)
[16] . Заложнев А., Чистов Д., Шуремов Е. Об одном подходе к реализации облачных
услуг на основе модели EAAS. Программные продукты и системы, №2 (106), 2014 г. стр. 188-192
[17] . Куприйчук А., Овчинников П. Референтная модель. Электронный журнал:
Управление предприятием, №3(14), март 2012 (httn://consulting.lc.ru/eioumalPdfs/ovchinnikov pSUn.pdf)
[18] . Jha S., Merzky A., Fox G. Using Clouds to Provide Grids Higher-Levels of Abstraction
and Explicit Support for Usage Modes. Open Grid Forum. GFD-I.150, 2009 (https://www.ogf.org/OGF Special Issue/cloud-grid-saga.pdf)
[19] . Ингланд P. Введение в реальный ITSM: пер. с англ. - М.: Лайвбук, 2010. 132 с.
[20] . Брукс П. Метрики для управления ИТ-услугами: пер. с англ. - М: Альпина Бизнес
Букс, 2008. 283 с.
[21] . Бон Я.В., Кеммерлинг Г., Пондаман Д. ИТ Сервис-менеджмент, введение . - М:
IT Expert, 2003. 215 с.
302
Труды ИСП РАН, том 27, вып. 6, 2015 г..
Expansion of reference model for the cloud computing environment in the concept of large-scale scientific researches
A. Skatkov < A VSkatkov@sevsu. ru >
V. Shevchenko < VIShevchenko(a)sevsu.ru>
Sevastopol State University, 33 University Str.,
Sevastopol, 299053, Russian Federation
Abstract. Actual problem of the development of new approaches to the implementation of fundamental service-oriented cloud environments to support large-scale scientific research is reviewed in the article. Review of modem technologies and models of cloud services, cloud computing is executed in the publication. The relevance of using the cloud service model "Everything As a Service" in distributed environments research is revealed. Architecture and features of realization of cloud computing, based on the reference model NIST were investigated. The structure of the reference model of a cloud computing environment for the scientific researchers is offered. The composition, objectives and functions of the actors of cloud infrastructure are described on the system level. In the model introduced new actors: the regulator, the crisis manager, the architect of composite applications. Actors interrelation of model of cloud computing environment with the business-processes of IT service management model is installed. Examples which illustrate basic scenarios of interaction of actors of cloud infrastructure, is given. On the basis of the reference model, which was proposed in the future, it is planned to develop a set of models, methods and algorithms that will allow to maintain a guaranteed level of IT services to the cloud, specializing in solving large-scale scientific problems. The work is supported by RFBR (grant 15-29-07936).
Keywords: cloud computing environment; adaptation; cloud broker; the level of IT services; convergent infrastructure.
References
[1] . Miller R. Who Has the Most Web Servers? May 14,2009
thtto://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-
servers/")
[2] . Sukhoroslov O. Realizatsiya i kompozitsiya problemno-orientirovannykh servisov v
srede MathCloud [Implementation and composition of domain-oriented services in the MathCloud environment], Vestnik YuUrGU, Seriya «Matematicheskoe modelirovanie i programmirovanie» [Bulletin of the South Ural State University. Series «Mathematical Modelling, Programming & Computer Software»] vol. 8, №17 (234), 2011, pp. 101-112. (in Russian)]
303
Trudy ISP RAN [The Proceedings of ISP RAS], vol. 27, issue 6, 2015.
[3] . Foster! Service-Oriented Science. Science, 308 (5723), 2005. P. 814-817.
[4] . Liu F., Tong I, Мао I, Bohn R., Messina J., Badger L., Leaf D. NIST Cloud
Computing Reference Architecture. Recommendations of the National Institute of Standards and Technology. Cloud Computing Program Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 September 2011 thttp://www.nist.gov/customcf/get pdf.cfm?pub 14=909505~)
[5] . Mell P., Grance T. The NIST Definition of CloudComputing. Recommendations of the
National Institute of Standards and Technology, 2010.
[6] . Hogan M., Liu F., Sokol A., Tong J. NIST Cloud Computing Standards Roadmap.
Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 July 2011 (http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909024)
[7] . Prudnikova A., Sadovnikova T. Analiz oblachnykh servisov s tochki zreniya
informatsionnoy bezopasnosti [Analysis of cloud services in terms of information security], T-Comm - Telekommunikatsii i Transport [T-Comm - Telecommunications and Transport], № 7, 2012, pp. 153-156. (In Russian)
[8] . Pazzini M., Lheureux Benoit J. Integration Platform as a Service: Moving Intergation to
the Cloud. Gartner RAS Core Research Note G00210747, March 7, 2011 thttps://www-304.ibm.com/industries/publicsector/fileserve?contentid=250736')
[9] . Elovikov A. Novye tendentsii integratsii v oblake [EMERGING TRENDS OF
INTEGRATION IN THE CLOUD], Nauchnyi zhumal KubGAU [Scientific Journal of KubSAU], №83(09), 2012 ihttp://ei.kubagro.ru/2012/09/pdf/36.pdf) (In Russian)
[10] . Afanasiev S. Oblachnye servisy, ontologicheskoe modelirovanie [CLOUD SERVICES,
ONTOLOGICAL MODELING OF TAXONOMY], Trudy SPIIRAN [SPRRAS Procedings], issue 4(23), 2012. pp. 392-399 (InRussian)
[11] . Tim Dzhons M. Cloud Computing i Linux Platformy i prilozheniya dlya Cloud
Computing [Cloud Computing and Linux. Platforms and Applications for Cloud Computing], IBM Developer Works, 25.12.2008
('https://www.ibm.com/dcvcloncrworks/ru/librarY71-cloud-computing/l-cloud-computing-pdf.ndO. (In Russian)
[12] . Rogalskiy E. Oblachnye tekhnologii i ikh rol v razvitii elektronnogo obucheniya [Role
of cloud technologies in the development of the e-learning]. Issledovaniya naukograda [The research of the science city], №1(7), 2014, pp. 42H9 (In Russian)
[13] . Bazhenova I. Primenenie oblachnykh tekhnologiy pri distantsionnom obuchenii
yazykam programmirovaniya [THE USE OF CLOUD TECHNOLOGY IN DISTANCE LEARNING PROGRAMMING LANGUAGE], Vestnik Moskovskogo gosudarstvennogo lingvisticheskogo universiteta [Bulletin of the MSLU], №13 (699), 2014, pp. 45-52. (In Russian)
[14] . Everything as a Service (EaaS). URL: http://www.csc.
com/business_drivers/ofFerings/78750-everything_as_a_service_eaas (дата обращения: 15.01.2014)
[15] . XaaS (anything as a service). URL:
http://searchcloudcomputing.techtarget.com/defmition/XaaS-anything-as-a-service (дата обращения: 15.01.2014)
[16] . Zalozhnev A., Chistov D., Shuremov E. Ob odnom podkhode к realizatsii oblachnykh
uslug na osnove modeli EAAS [EaaS model based approach to cloud services provision! Programmnye produkty i sistemy [Software & Systems! №2 (106), 2014, pp. 188-192. (InRussian)
304
Труды ИСП РАН, том 27, вып. 6, 2015 г..
[17] . Kupriychuk A., Ovchinnikov Р. Referentnaya model [Reference model], Elektronnyi
zhumal: Upravlenie predpriyatiem [Electronic Journal: Enterprise Managemen], №3(14), march 2012 (http://consulting.lc.ru/eioumalPdfs/ovchinnikov pSUn.pdf). (In
Russian)
[18] . Jha S., Merzky A., Fox G. Using Clouds to Provide Grids Higher-Levels of Abstraction
and Explicit Support for Usage Modes. Open Grid Fomm. GFD-I.150, 2009 (https://www.ogf.org/OGF Special Issue/cloud-grid-saga.pdf)
[19] . Ingland R. Vvedenie v realnyi ITSM [Introduction to real itsm]: per. s angl. - M.:
Laivbuk [Livebook], 2010. 132 p. (In Russian)
[20] . Bruks P. Metriki dlya upravleniya IT-uslugami [Metrics for IT Service Management]:
per. s angl. - M: Alpina Biznes Buks [Alpina business books], 2008. 283 p. (In Russian)
[21] . Bon Ya.V., Kemmerling G., Pondaman D. IT Servis-menedzhment, vvedenie [IT
Service Management, introduction], - M: IT Expert, 2003. 215 p. (In Russian)
305
