Интероперабельность в облачных вычислениях

Размещено на http://www.allbest.ru/

Физический институт им. П.Н.Лебедева РАН, Российский новый университет, ИРЭ им. В.А.Котельникова РАН

ИНТЕРОПЕРАБЕЛЬНОСТЬ В ОБЛАЧНЫХ ВЫЧИСЛЕНИЯХ

Е.Е. Журавлев, С.В. Иванов, А.А. Каменщиков,

А.Я. Олейников, Е.И. Разинкин, К.А. Рубан



Аннотация

Представлен обзор на тему интероперабельности в области облачных вычислений. Рассмотрено понятие интероперабельности, кратко описан единый подход к решению проблемы интероперабельности для систем широкого класса. Дано определение облачных вычислений, приведена классификация облаков и проведено их сравнение с Грид. Показаны особенности проблемы интероперабельности в облаках при их применении в таких областях как: здравоохранение, образование, наука, коммерция, военное дело. Приведены рекомендации по решению проблемы интероперабельности в облачных вычислениях.

Ключевые слова: облака, облачные вычисления, грид, интероперабельность, стандартизация.



Abstract

An overview on the topic of interoperability in the cloud is represented. The concept of interoperability is considered, briefly described the common approach to solving problems of interoperability for wide class of systems. Definition of cloud computing, the classification of clouds and their comparison with the Grid are given. The features of the problems of interoperability in the clouds are shown when in case of their application in such areas as health, education, science, commerce, military. Recommendations on solving the problem of interoperability in the cloud are given.

Keywords: cloud, cloud computing, grid, interoperability, standardization.



Оглавление

Введение

1. Проблема интероперабельности

1.1 Определение интероперабельности

1.2 Интероперабельность как одно из основных свойств открытых систем

1.3 Уровни интероперабельности

1.4 Области существования проблемы

1.5 Единый подход к проблеме интероперабельности для ИС широкого класса

2. Основы облачных вычислений

2.1 Существо облачных вычислений

2.2 Истоки и место облачных вычислений в ИТ

2.3 Классификация облаков

2.3.1 По моделям услуг

2.3.2 По моделям доступа

2.3.3 По уровням интероперабельности

2.4 Достоинства и недостатки принятия облачных технологий

2.5 Сравнение облачных вычислений и Грид

3. Особенности проблемы интероперабельности в облачных вычислениях

3.1 Примеры решения проблемы интероперабельности в облачных вычислениях

3.1.1 Здравоохранение

3.1.2 Образование

3.1.3 Наука

3.1.4 Коммерция

3.1.5 Военное дело

3.2 Работы по стандартам интероперабельности в облачных вычислениях

3.3 Технологии и стандарты

4. Рекомендации по решению проблемы интероперабельности в облачных вычислениях

4.1 Концепция (Framework)

4.2 Архитектура

4.3 Проблемно-ориентированная модель

4.4 Профиль интероперабельности.

5. Заключение

Термины и определения

Список литературы



Введение

интероперабельность информационный система открытый

Начиная с 1993 года в Институте радиотехники и электроники им. В.А.Котельникова РАН ведутся систематизированные работы по открытым системам. Как известно, существо открытых систем состоит в использовании стандартных интерфейсов для взаимодействия разнородных компонентов. Основным достижением следует считать разработку т.н. технологии открытых систем, которая описана в значительном числе публикаций и монографии и запатентована. Накоплен опыт применения этой технологии в ряде областей. Известно также, что открытая система обладает тремя свойствами: переносимостью, масштабируемостью и интероперабельностью. В последние годы во всем мире особое значение придают именно интероперабельности. Это обусловлено тем, что происходит переход от «технической интероперабельности» к «семантической», т.е. смысловой интероперабельности. Возникла т.н. «проблема интероперабельности». В соответствии с этой мировой тенденцией, авторы также работают над этой проблемой, Нами показано, в частности, что проблема интероперабельности охватывает практически все классы информационных систем, в том числе информационные системы разного назначения (наука, образование, здравоохранение, государственное управление), вообще все компоненты информационного общества, а также информационные системы всех масштабов - от наносистем до распределённых сверхбольших систем (System of Systems). На основании обобщения зарубежного и своего многолетнего опыта нами предложен единый подход к обеспечению интероперабельности для информационных систем широкого класса, зафиксированный в ГОСТ Р.

В последнее время, как известно, весьма интенсивно развиваются т.н. «облачные вычисления» («облака»). Облачные вычисления представляют собой в общем случае распределенную сугубо гетерогенную среду, для которой проблема интероперабельности весьма актуальна.

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

Статья состоит из четырех разделов. В разделе 1 описывается существо проблемы интероперабельности независимо от класса системы. В разделе 2 описываются основы облачных вычислений. Поскольку облачные вычисления весьма родственны с Грид, в этом разделе показаны их общие и отличающиеся черты. В разделе 3 рассматриваются особенности проблемы интероперабельности в области облачных вычислений и примеры решения проблемы для различных областей. Наконец, в разделе 4 даны рекомендации по решению проблемы интероперабельности в облачных вычислениях на основе единого подхода. Ввиду того, что область облачных вычислений развивается очень быстро и терминология не установилась, в конце статьи приведены основные термины и определения.

Данная статья подготовлена при поддержке РФФИ (проект №12-07-00261-а) и Программы Президиума РАН № 14.

В работе над статьей принимали участие:

- Журавлев Е.Е. (1, 3.1.3);

- Иванов С.В. (2, 3.1, 3.2, 4);

- Каменщиков А.А. (3.1.1);

- Олейников А.Я. (Введение, 3.1.5, 4, Заключение);

- Разинкин Е.И. (3.1.4);

- Рубан К.А. (3.1.2).



1. Проблема интероперабельности

Проблема интероперабельности для систем широкого класса подробно обсуждалась нами в [1]. В [1] показаны истоки проблемы, актуальность для широкого класса систем, основные аспекты при её решении. В том числе в [1] показано, что проблема интероперабельности имеет место и для облачных вычислений, но подробно не обсуждалась.

1.1 Определение интероперабельности

В [1] показано, что существует множество определений понятия «интероперабельность», поскольку многие организации дают собственные определения, исходя из стоящих перед ними задач. Обычно считается, что следует пользоваться определениями, которые дают официальные организации по стандартизации в первую очередь ISO как обеспечивающие наиболее высокий уровень консенсуса. Такое определение, независимое от класса системы дано в документе ISO/IEC FDIS 24765:2009 «Интероперабельность - способность двух или более систем или компонентов к обмену информацией и к использованию информации, полученной в результате обмена». Именно слова о возможности использования и связаны с переходом к семантической интероперабельности.

1.2 Интероперабельность как одно из основных свойств открытых систем

Интероперабельность представляет собой одно из основных свойств открытых систем, поскольку из определения, приведенного в ISO/IEC TR 14252-96, следует, что открытая система обладает свойствами переносимости, масштабируемости и интероперабельности за счет использования стандартов на интерфейсы, сервисы и форматы данных.

Важным понятием открытых систем служит понятие профиля - согласованного набора стандартов.

Первоначально термин «интероперабельность» был введен в техническом смысле, и она достигалась за счет использования стандартных протоколов связи. В настоящее время термин «интероперабельность» получил расширенное значение, можно говорить о «семантической» (смысловой) интероперабельности, которая достигается за счет использования «семантических» стандартов [2].

В [1] показано, что к аспектам проблемы интероперабельности относятся:

- вопросы терминологии;

- виды и модели интероперабельности;

- измерение интероперабельности;

- выбор объектов стандартизации - ключевых интерфейсов;

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

- выработка единого подхода к обеспечению интероперабельности;

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

Обсуждение ряда названных аспектов применительно к облачным вычислениям и составляет существо данной работы.

1.3 Уровни интероперабельности

Переход от технической интероперабельности к семантической привел к тому, что разные организации, исходя из стоящих перед ними задач, строят модели интероперабельности с разным числом уровней [1]. Некоторые модели достигают 10 уровней. До последнего времени одним из главных барьеров для решения проблемы интероперабельности служило отсутствие общепринятой эталонной модели, зафиксированной в стандарте, подобно тому, как это имело место с общеизвестной 7-уровневой эталонной моделью взаимосвязи открытых систем (ГОСТ Р ИСО/МЭК 7498-1-99). Одно из назначений подобной модели - нахождение общего языка между разработчиками информационных систем и стандартов, поставщиками и пользователями информационных систем. В разработанном нами ГОСТ Р 55062-2012 мы постарались исправить указанный недостаток. В этом стандарте введена эталонная модель интероперабельности, которая содержит три уровня: технический, семантический, организационный (бизнес-процессов).

1.4 Области существования проблемы

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



Рис. 1 Классификация ИС по областям применения

Второй вид классификации - по масштабу (см. рис. 2). В последнее время необычайно активное развитие получают облака, которые также представляют гетерогенную среду и, следовательно, в них актуальна проблема интероперабельности [4]. Самой верхней «ступенькой на лесенке» следует считать сверхсложные системы (Systems of Systems) [5].



Рис. 2 Классификация ИС по масштабу

Кроме приведенных классификаций довольно естественно пользоваться классификацией технического комитета по информационным технологиям ТК22 [6]. Легко убедиться, что проблема интероперабельности присутствует в большинстве направлений работ ТК22. На этом основании в 2012 г. в рамках ТК22 специально создан подкомитет 206 «Интероперабельность».

О широте проблемы интероперабельности можно судить и по тому, что она актуальна и для систем искусственного интеллекта [7].

1.5 Единый подход к проблеме интероперабельности для ИС широкого класса

В [1] нами показано, что обеспечение интероперабельности для систем различных классов имеет общие черты и имеет свои особенности, поэтому, обобщая многочисленные работы других авторов в этой области, и собственный долголетний опыт, мы предложили единый подход к обеспечению интероперабельности для систем широкого класса. При этом следует отметить, что интенсивное применение ИКТ в различных организациях (предприятиях, исследовательских, образовательных, лечебных учреждениях, и др.) привело к обобщенному понятию «электронное предприятие» (е-enterprise). Соответственно, возникло понятие «интероперабельность предприятия» (Enterprise Interoperability).

На этой основе в стандарте «ГОСТ Р 55062-2012 Информационные технологии Системы промышленной автоматизации и их интеграция. Интероперабельность. Основные положения» описывается единый подход к обеспечению интероперабельности для систем самого широкого класса. Хотя настоящий стандарт предназначен в первую очередь для систем промышленной автоматизации, он имеет гораздо более широкое назначение. На его основе могут создаваться интероперабельные системы самого широкого класса по масштабу и областям применения с учетом их особенностей, в том числе для облачных вычислений. Первостепенной задачей единого подхода служит введение на уровне стандарта эталонной модели интероперабельности, подобно хорошо известной 7-уровневой модели взаимосвязи открытых систем ISO 7498-1984 и эталонной модели среды открытых систем ISO/IEC 14252 -1996. Эта модель представлена на рисунке 3.

Рис. 3 Эталонная модель интероперабельности

Каждому уровню модели соответствуют свои стандарты. Для конкретных решений эталонная модель может уточняться. Единый подход к обеспечению интероперабельности систем всех классов содержит ряд последовательных этапов (см. Рис. 4).

Рис. 4 Основные этапы обеспечения интероперабельности



2. Основы облачных вычислений

2.1 Существо облачных вычислений

На данный момент существует множество трактовок термина облачные вычисления [8,9,10,11,12]. Мы будем ориентироваться на определение, данное Национальным Институтом стандартов и технологий США - NIST [12], которое, по всей видимости, будет принято и на уровне JTC1 ISO/IEC [13]:

«Облачные вычисления это модель предоставления повсеместного и удобного сетевого доступа по мере необходимости к общему пулу конфигурируемых вычислительных ресурсов (например, сетей, серверов, систем хранения, приложений и сервисов), которые могут быть быстро предоставлены и освобождены с минимальными усилиями по управлению или взаимодействием с провайдером услуг (сервис-провайдером)» [12].

Облачные вычисления основаны на традиционных технологиях, но до середины 2000-х годов сфера применения этих технологий оставалась ограниченной, а потенциал - нераскрытым

2.2 Истоки и место облачных вычислений в ИТ

Облачные технологии приобрели широкую известность лишь в 2007 году, несмотря на то, что они имеют довольно долгую историю [14]. С некоторой степенью условности, становление облачных технологий отражает рис. 5.



Рис. 5 Становление облачных технологий на временной шкале

Практически все технологии, которые сегодня входят в состав облачной парадигмы (см. рис. 6), существовали и раньше, однако, как отмечено в [15], по-настоящему массовыми облачные вычисления стали благодаря компании Amazon [14].

Рис. 6 Облачные вычисления - результат синтеза целого ряда технологий и подходов

Как видно из Рис.6, одной из наиболее существенных технологий, лежащих в основе облачных вычислений, являются технологии виртуализации. Виртуализация - это возможность запускать при помощи специального программного обеспечения (менеджера виртуальных машин, типичные примеры - VMWare Workstation,Parallels Workstation, Oracle VirtualBOX одну или несколько операционных систем, называемых гостевыми, внутри другой, называемой хост-системой, причём операционные системы могут быть различными (Например - Windows 7 из под Mac OS X или Windows XP из под Windows 7), либо запускать на одном компьютере несколько операционных систем одновременно при помощи специальной программы-гипервизора. (Примеры - VMWare ESXi, Xen, Microsoft Hyper-V)[16]. Впервые виртуализация была предложена в мейнфреймах IBM еще в середине 1960-х годов [17]. Однако после поворота технологий в сторону ПК и недорогих серверов, основанных на процессорной архитектуре x86, о виртуализации на долгое время забыли: это была одна из многих технологических привилегий тех пользователей, которые готовы были платить за мощности и возможности мейнфреймов.

Предпосылками к современным облачным вычислениям послужило также (см. рис. 6) развитие таких направлений ИТ-индустрии, как сервис-ориентированная архитектура (Service-Oriented Architecture, SOA), Грид-вычисления, предоставление приложений в режиме услуг (Application Service Provider, ASP) и др. Некоторые из этих терминов заключали в себе вполне конкретные технологии (например, Грид-вычисления), другие преимущественно употреблялись в маркетинговых целях (например, ASP). Облачные вычисления вобрали в себя много идей из предшествующих концепций и потому изначально они носят более разносторонний характер, чем существовавшие ранее концепции: облачные вычисления можно понимать и как техническую парадигму, и как маркетинговый термин, и как перспективное направление для НИОКР. По сути, в облачные вычисления вложены все те идеи, которые накапливались в ИТ-отрасли в течение предыдущих полутора десятилетий.

Есть и другие технологические факторы, которые имели принципиально важную роль для развития облачных вычислений. Повсеместное распространение высокоскоростных каналов интернет-связи сделало возможным интенсивный обмен данными с компьютерами, находящимися в облаке. Созревание технологий Web 2.0 позволило выполнять функционально насыщенные web-приложения непосредственно в окне web-браузера, а не запускать их на локальном компьютере или компьютере в локальной сети. В какой-то мере успеху облачных вычислений содействовало также развитие интернет-сервисов, которые предоставляют доступ к своим данным посредством программных интерфейсов (API). Приложение, которое собирает данные из интернета (например, из социальной сети Facebook) и обслуживает пользователей в интернете, должно осуществлять промежуточный этап - обработку данных - также в интернете, т.е. на облачной платформе.

У разных видов облачных сервисов разные предшественники. Все вышесказанное относится преимущественно к решениям класса SaaS (ниже будут подробнее рассмотрены разные классы облачных вычислений). Если мы посмотрим на технологии "платформа как сервис" (PaaS), то среди их предшественников нужно будет упомянуть технологии распределенных вычислений, используемые в инфраструктуре таких интернет-гигантов, как Google и Yahoo. В какой-то момент компания Google осознала, что эти технологии уже достаточно зрелы и хороши, чтобы их можно было сделать доступными для массового разработчика - и в результате появился инструментарий Google App Engine [18]. Компания Salesforce.com шла с другой стороны: предлагаемая ей онлайновая CRM-платформа разрабатывалась таким образом, чтобы предоставить заказчикам максимум возможностей для доработки и адаптации - и в какой-то момент выяснилось, что этих возможностей вполне достаточно для создания полностью независимых приложений. Так родилась PaaS-платформа Force.com [19].

Напомним, ещё один краеугольный камень облачных вычислений - ПО с открытым кодом, зрелость которого также наступила в 2000-е гг. В [15] указывается, что успех Amazon Web Services стал возможен исключительно благодаря свободным лицензиям, которые не связывают пользователя излишними ограничениями и не требуют лицензионных платежей за каждый процессор или за каждый экземпляр установленного ПО.

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

Еще раз подчеркнем, что концепция облачных вычислений получила популярность в 2007 году, благодаря быстрому развитию каналов связи и растущей в геометрической прогрессии потребности государства, бизнеса, так и частных пользователей «горизонтальном» масштабировании своих информационных систем [20].

2.3 Классификация облаков

Существует несколько способов классификации облаков: по моделям услуг [12], по моделям доступа [12], по уровням модели интероперабельности [21].

2.3.1 По моделям услуг

Программное обеспечение как услуга - Software as a Service (SaaS). Возможность предоставления потребителю в пользование приложений провайдера, работающих в облачной инфраструктуре. Приложения доступны из различных клиентских устройств или через интерфейсы тонких клиентов, такие как web-браузер (например, web-почта) или интерфейсы API. Потребитель при этом не управляет базовой инфраструктурой облака, в том числе сетями, серверами, операционными системами, системами хранения и даже индивидуальными настройками приложений, за исключением некоторых пользовательских настроек конфигурации приложения.

Примеры SaaS:

- Google Apps: электронная почта, календарь, документы, создание и управление сайтами [22]

- Microsoft Office 365: почта, календарь, Office Web Apps, web конференции и общий доступ к файлам [23]

- Salesforce: CRM программное приложение [19]

Платформа как услуга - Platform as a Service (PaaS). Возможность предоставления потребителю для развертывания в облачной инфраструктуре пользовательских (созданных или приобретенных) приложений, реализованных с помощью языков программирования, библиотек, служб и средств, поддерживаемых провайдером услуг. Потребитель при этом не управляет базовой инфраструктурой облака, в том числе сетями, серверами, операционными системами и системами хранения данных, но осуществляет контроль над развернутыми приложениями и, возможно, некоторыми параметрами конфигурации среды хостинга.

Примеры PaaS:

- Google App Engine: платформа для разработки и запуска Java, Python, and Go приложений на базе инфраструктуры Google's [18]

- Heroku: платформы для развёртывания Java, Ruby, Python, Clojure, node.js, and Scala приложений, которые могут быть расширены дополнительными ресурсами [24]

- Microsoft Windows Azure: службы хранения и вычисления по требованию, платформы для разработки и развертывания приложений на базе ОС Windows [25]

- Salesforce Force.com: платформа для создания и запуска приложений и компонентов, купленных в AppExchange или собственных приложений [26]

Инфраструктура как услуга - Infrastructure as a Service (IaaS). Возможность предоставления потребителю систем обработки, хранения, сетей и других фундаментальных вычислительных ресурсов для развертывания и запуска произвольного ПО, которое может включать в себя операционные системы и приложения. Потребитель при этом не управляет базовой инфраструктурой облака, но осуществляет контроль над операционными системами, системами хранения, развернутыми приложениями и, возможно, ограниченный контроль выбора сетевых компонентов (например, хост с сетевыми экранами).

Примеры IaaS:

- Amazon Elastic Compute Cloud (EC2): специальные виртуальные машины Amazon Machine Images (AMI), которые могут быть развернуты и работают на базе EC2 инфрастуктуры [27]

- Amazon Simple Storage Solution (S3): динамически масштабируемые ресурсы для хранения [28]

- Другие предложения Amazon's по хранению информации: Elastic Block Storage, обеспечивает разделы хранения блочного типа, используемые вместе с Amazon EC2; SimpleDB, не реляционное хранилище данных; Relational Data Store, реляционное хранилище

- Rackspace Cloud Servers: динамически масштабируемые ресурсы для вычисления, хранения и балансировки нагрузки [29]

На рис. 7 показано, как осуществляется взаимосвязь между названными моделями и с какими категориями пользователей по большей степени взаимодействует каждая модель.

Рис. 7 Взаимоотношения моделей предоставляемых услуг [30]

Из рисунка 7 следует, что IaaS может служить основой для PaaS, в свою очередь PaaS может играть ту же роль для SaaS. Между моделями отсутствует тесная связь (см. стрелочки): SaaS могут быть приняты через PaaS или могут перескочить PaaS и базироваться на верхушке «сырого» (raw) IaaS. Кроме того, IaaS может быть заменена традиционной инфраструктурой и слоями PaaS и SaaS, которые могли бы непосредственно зависеть от неё.

2.3.2 По моделям доступа

Если объединить характеристики облачной системы и методы пакетирования услуг, возникает вопрос относительно модели доступа к облаку (см. рис. 8), см. [12].

Частное облако (Private cloud). Облачная инфраструктура, подготовленная для эксклюзивного использования одной организацией, включающей несколько потребителей (например, бизнес-единиц). Такое облако может находиться в собственности, управлении и обслуживании у самой организации, у третьей стороны и располагаться как на территории предприятия, так и за его пределами.

Облако сообщества/коммунальное облако (Community cloud). Облачная инфраструктура, подготовленная для эксклюзивного использования конкретным сообществом потребителей, имеющих общие проблемы (например, миссии, требования безопасности, политики). Облако может находиться в собственности, управлении и обслуживании у одной или более организаций в сообществе, у третьей стороны и располагаться как на территории организаций, так и за их пределами.

Публичное облако (Public cloud). Облачная инфраструктура, подготовленная для открытого использования широкой публикой. Оно может находиться в собственности, управлении и обслуживании у деловых, научных и правительственных организаций в любых их комбинациях. Облако реализуется на территории облачного провайдера.

Гибридное облако (Hybrid cloud). Облачная инфраструктура представляет собой композицию из двух или более различных инфраструктур облаков (частные, общественные или публичные), имеющих уникальные объекты, но связанных между собой стандартизированными или собственными технологиями, которые позволяют переносить данные или приложения между компонентами (например, для балансировки нагрузки между облаками).

Рис. 8 Наглядное представление облачных моделей доступа [31]

2.3.3 По уровням интероперабельности

Основная причина того, что при облачных вычислениях возникает проблема интероперабельности, состоит в том, что, как правило, пользователь может захотеть сменить провайдера услуг [32], при этом он неизбежно столкнется со следующими препятствиями:

? Восстановление приложений и стека приложений в новом облаке.

? Установка сети в новом облаке, чтобы оказать приложению поддержку, которую оно имело в ее исходном облаке.

? Установка безопасности, чтобы соответствовать возможностям, обеспеченным исходным облаком.

? Управление приложением, работающим в новом облаке.

? Обработка перемещения данных и шифрования данных, пока они находятся в пути и когда они доходят до нового облака.

В [21] выделяются 3 уровня интероперабельности, совпадающие с уровнями эталонной модели (см. рис. 3). Технический, т.е. уровень, связанный с обменом данными, семантический уровень, связанный со смысловым содержанием обмениваемой информации и организационный уровень, связанный согласованием бизнес-процессов нескольких организаций. Таким образом, облака можно классифицировать по уровням модели интероперабельности. Технологии и стандарты, необходимые для обеспечения интероперабельности на каждом из уровней требуют коллективного обсуждения, стоит отметить, что возможно использовать список, предложенный в [33].

2.4 Достоинства и недостатки принятия облачных технологий.

Ниже перечислены основные достоинства и недостатки, которые влияют на применение облачных технологий в организациях [34]

Достоинства:

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

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

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

? надёжность - надежность облаков, особенно находящихся в специально оборудованных ЦОД, очень высокая, так как такие ЦОД имеют резервные источники питания, охрану, профессиональных работников, регулярное резервирование данных, высокую пропускную способность Интернет-канала, высокую устойчивость к DDOS атакам;

? большие вычислительные мощности - пользователь облачной системы может использовать все ее вычислительные способности, заплатив только за фактическое время использования.

Недостатки:

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

? постоянное соединение с сетью - для получения доступа к услугам облака необходимо постоянное соединение с сетью Интернет. Однако в наше время это не такой и большой недостаток, особенно с приходом технологий сотовой связи 3G и 4G;

? программное обеспечение и его кастомизация - есть ограничения по ПО, которое можно разворачивать на облаках и предоставлять его пользователю. Пользователь ПО имеет ограничения в используемом ПО и иногда не имеет возможности настроить его под свои собственные цели. Также некоторые поставщики ограничивают выбор языковых пакетов;

? сохранение конфиденциальности - конфиденциальность данных, хранимых на публичных облаках, в настоящее вызывает много споров, но в большинстве случаев эксперты сходятся в том, что не рекомендуется хранить наиболее ценные для компании документы на публичном облаке, так как в настоящее время нет технологии, которая бы гарантировала 100%ную конфиденциальность хранимых данных;

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

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

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

2.5 Сравнение облачных вычислений и Грид

Прежде чем говорить о сравнении технологий, следует привести определение Грид, данное в документе GFD 120 [35], разработанном наиболее авторитетной организацией по Грид-технологиям - Open Grid Forum:

«Грид - система, которая связана с интеграцией, виртуализацией и управлением услугами и ресурсами в распределенной, гетерогенной среде, которая поддерживает коллекции пользователей и ресурсов (виртуальных организаций) в традиционных административных и организационных доменах (реальных организаций)».

На сегодняшний день сравнению облачных вычислений и Грид посвящено множество статей и обзоров [36,37,38]. Ниже (см. таблицу 1) представлено одно из таких сравнений по ряду аспектов (бизнес модель, архитектура, управление ресурсами, модель программирования, модель приложений, модель безопасности), рассмотренное в [38].



Таблица 1

Сравнение облаков и Грид

Облака	Грид
Бизнес модель
Потребитель платит провайдеру по принципу «сколько используешь, столько и платишь». Модель основывается на экономии при росте масштабов использования, что позволяет управлять снижением цен для пользователей и увеличением прибыли поставщикам.	Модель ориентирована на проект, в котором у пользователей есть определенное число служебных единиц (например, часы центрального процессора), которые они могут потратить.
Архитектура
Существует ряд версий архитектуры облачных вычислений. Для сравнения с Грид мы рассмотрим следующую архитектуру: - структурный уровень - содержит необработанные аппаратные ресурсы, такие как вычислительные ресурсы, ресурсы хранения и сетевые ресурсы; - объединенный уровень - содержит ресурсы, которые абстрагировались/инкапсулировались так, чтобы они могли быть представлены верхнему уровню и пользователям как интегрированные ресурсы (компьютер/кластер, логическая файловая система, система баз данных); - уровень платформы - прибавляет набор специализированных инструментов, промежуточного ПО и служб поверх объединенных ресурсов, чтобы обеспечить платформу разработки и/или развертывания (среда web-хостинга, служба планирования); - прикладной уровень - содержит приложения, которые работали бы в облаке.	Рассмотрим 5-ти уровневую архитектуру: - структурный уровень - обеспечивается доступ к различным типам ресурсов, таких как: вычисление, хранение, сетевой ресурс и т.д.; - уровень связи - связи определяет базовую связь и протоколы аутентификации для простых и безопасных сетевых транзакций; - уровень ресурса - определяет протоколы для публикации, открытия, согласования, контроля, учета и оплаты совместного использования операций на отдельных ресурсах; - коллективный уровень - получает взаимодействия по наборам ресурсов, службы каталогов, допускает контроль и открытие ресурсов виртуальной организации (ВО); - прикладной уровень - включает любые пользовательские приложения, созданные поверх вышеупомянутых протоколов и API, и функционирует в средах ВО;
Управление ресурсами
Вычислительная модель
Ресурсы в облаке делятся между всеми пользователями в одно и то же время, в отличие от ресурсов, которыми управляет система массового обслуживания.	Большинство Грид используют запланированную вычислительную модель, в которой локальный менеджер ресурсов управляет вычислением ресурсов Грид-сайта и пользователи отправляют пакетные задания, чтобы запросить некоторые ресурсы в течение некоторого времени.
Данные
Предназначны для работы с информационно емкими приложениями. Используют виртуальные данные Работают по принцыпу общей файловой системы. Прогрессируют в использовании планировщиков задач, осведомленных данными.	Не предназначены для работы с информационно емкими приложениями. Данные разбиты на куски, которые реплецируются. Обработка данных происходит в том же месте где они находятся.
Виртуализация
Не полагаются на виртуализацию, т.к. каждый имеет отдельную организацию, поддерживающую полный контроль за ресурсами. Тем не менее были предприняты попытки использования виртуализации в Nimbus.	- необходимый компонент почти для каждого облака; - обеспечивает необходимую абстракцию так, что базовая структура (сырые данные, хранилище, сетевые ресурсы) могут быть объединены как пул ресурсов, а оверлейные ресурсы (например, службы хранения данных) могут быть созданы поверх них; - обеспечивает инкапсуляцию - приложения могут быть инкапсулированы таким образом, что они могут быть сконфигурированы, развернуты, запущены, перемещены, приостановлены, возобновлены, остановлены, и т.д.
Мониторинг
Мониторинг в Грид осуществлять проще т.к. имеется доверительная модель, в которой пользователи через делегирование их идентификационных данных могут получить доступ и просмотреть ресурсы на различных Грид-сайтах, а Грид-ресурсы не высоко абстрагированы и виртуализированы как в облаках.	Мониторинг усложняется, т.к. абстрактные/объединенные ресурсы обычно проходят через процесс виртуализации и другие уровни инкапсуляции. Мониторинг в облаках требует баланса между мониторингом бизнес-приложения, управлением сервером предприятия, мониторингом ВМ и обслуживанием оборудования, что является существенной проблемой, т.к. требует более широкого внедрения и развертывания.
Происхождение данных
Имеется несколько систем (Chimera,Swift, Kepler), однако как для Грид так и для облаков существуют проблемы масштабируемых запросов происхождения и безопасного доступа к происхождению.	Получение и управление происхождением данных в облаках проблематичо из-за проблем отслеживания производства данных по различным провайдерам услуг (с разными политиками видимости платформ) и по различным уровням абстракции программного и аппаратного обеспечения в одном провайдере.
Модель программирования
Несмотря на то, что Грид модель программирования не отличается от традиционных распределенных и параллельных сред (Message PassingInterface, MapReduce), она имеет определенные сложности из-за гетерогенности грид среды. Программы должны работать быстро, эффективно, завершаться правильно, быть надежными и отказоустойчивыми.	Мэшап (интернет-приложение, объединяющее данные из нескольких интерактивных источников) и скриптовые языки( javascript, PHP, Python и др.) заняли место в рабочей системе в мире облаков, т.к. они являются наилучшим способом взаимодействия служб и приложений различных провайдеров.
Модель приложений
Поддерживает много типов приложений начиная от высокопроизводительных вычислений и заканчивая вычислениями с высокой пропускной способностю.	Могут угодить набору приложений, подобному Грид, за исключением высокопроизводительных вычислений, для которых требуются быстрые сетевые интерфейсы с низким временем ожидания, чтобы достичь эффективного масштабирования для многих процессоров.
Модель безопасности
Строятся при условии, что ресурсы гетерогенны и динамичны и каждый Грид-сайт может иметь своего собственного администратора домена и автономию работы. Т.о. безопасность была спроектирована в фундаментальной инфраструктуре Грид. Ключевые вопросы, которые рассматриваются: единственный вход в систему открывает доступ к множеству Грид-сайтов, это упростит учет и контроль; делегирование - программе разрешен доступ к ресурсам от имени пользователя и она может делегировать права другим программам; конфиденциальность, целостность и сегрегация, ресурсы, принадлежащие одному пользователю, не могут быть доступны неавторизованным пользователям и могут быть подделаны во время передачи; скоординированное распределение ресурсов, резервирование, и совместное использование, учет и глобальных и локальных политик использования ресурсов.	Главным образом включают выделенные ЦОД, принадлежащие той же организации, и в каждом ЦОД аппаратные и программные конфигурации и поддерживающие платформы в целом более гомогенные по сравнению с тем же в Грид. Для перекрестного ЦОД и перекрестного домена администрирования может возникнуть проблема интероперабельности. Облачная инфраструктура обычно полагается на Веб-формы (по SSL), чтобы создать и управлять информацией учетной записи для конечных пользователей, и позволяет им сбрасывать свои пароли и получать новые через электронные письма в опасной и незашифрованной форме.

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

Как в Грид так и в облачных вычислениях имеет место вопрос интероперабельности, однако решением данной проблемы в Грид начали заниматься значительно раньше чем в облаках и уже были достигнуты определенные результаты [39,40].



3. Особенности проблемы интероперабельности в облачных вычислениях

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

3.1 Примеры решения проблемы интероперабельности в облачных вычислениях

3.1.1 Здравоохранение

Система здравоохранения относится к наиболее важным социальным системам, управление которыми, эффективность их функционирования определяются уровнем применения ИТ. Применение ИТ в системе здравоохранения привело к понятию «электронное здравоохранение» (e-health)(см. рис. 1). Одной из главных тенденций в этой области выступает интеграция информационных систем в здравоохранении (ИСЗ) различного назначения в единую систему, создание единого информационного пространства здравоохранения. При этом, ввиду того, что ИСЗ реализованы на различных программно-аппаратных платформах, возникает проблема интероперабельности. В ИРЭ им. В.А.Котельникова РАН проблемой интероперабельности в здравоохранении занимались достаточно давно, получены значительные результаты [41] и сейчас приступили к исследованию проблемы интероперабельности при использовании облачных вычислений в здравоохранении [42].

Министерство здравоохранения Российской Федерации реализует проект по созданию единой федеральной информационной системы для учета административно - хозяйственной деятельности в лечебно-профилактических учреждениях пилотных регионов [43]. Система должна быть построена на основе облачных технологий, и позволит подключаться по защищенному каналу к общему серверу для ведения учета и получения необходимой аналитической и статистической информации.

Выделяют два основных направления использования облачных технологий в электронном здравоохранении:

Personal Health Record - персональная медицинская карта, которой управляет сам пациент.

Electronic Health Record - электронная история болезни (ЭИБ), которой управляет медицинское учреждение.

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

В рамках второго направления данные ЭИБ хранятся на локальных серверах медицинского учреждения. Основным преимуществом этого направления является размещение данных в одном месте, что позволяет организовать доступ к этим данным. Увеличение доступа к данным и увеличение интероперабельности ведут к большей уязвимости данных. При этом более остро встает вопрос безопасности (см. рис. 9) [44].

Обычно обеспечиваются следующие правила для увеличения безопасности:

? аутентификация имеющих доступ организаций и пациентов;

? электронная подпись для всех документов, отправляемых в ЭИБ;

? кодирование данных ЭИБ перед отправкой в облако;

? авторизация для доступа к данным из ЭИБ.



Рис. 9 ЭИБ с применением облачных технологий

При этом остаются следующие актуальные вопросы, касающиеся:

? опасности хранения всех данных в облаке, и необходимости разграничения прав для доступа. Например, пользователи имеющие доступ к отчетам из биллинг-системы, не должны иметь возможность получить доступ к данным ЭИБ;

? опасности заражения компьютера пользователя вирусом и получения доступа к данным из ЭИБ третьими лицами;

? обновления программного аппаратного и программного обеспечения остается на стороне провайдера облака.

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



3.1.2 Образование

Методологию использования облачных технологий в образовании можно представить следующим образом (см. рис. 10):

Создание, хранение и использование образовательных ресурсов (контента).

Управление персональной карточкой обучаемого.

Рис. 10 Применение облачных технологий в образовательной среде

В представленной схеме необходимо особое внимание уделить блоку «контент» и блоку «персональные карточки обучаемых». В настоящее время для создания образовательного контента используются различные наборы технологий (html+javascript, pdf, пакеты ims, cgi, win32 application и т.д.), которые зачастую не позволяют применять полученные результаты в сторонних образовательных системах. Это влечет за собой ряд проблем, связанных с дублированием контента, дополнительными затратами на его адаптацию, существенным сокращением области применения, снижением уровня конкуренции на рынке образовательных ресурсов и т.д. Облачные технологии способны решить проблему доступности, а решение проблемы интероперабельности позволит достичь максимального эффекта от создаваемых ресурсов.

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

Особое значение при работе с облачными технологиями в образовании принимают вопросы безопасности данных. Для защиты персональных данных и авторских прав в профиль интероперабельности обязательно должны быть включены соответствующие стандарты и спецификации, такие как RFC 2661 (L2TP), RFC 2401-2412 (IP Security Protocol IETF), RFC 2246 (Transport Layer Security), RFC 2818 (Hypertext Transfer Protocol Secure) и т.д.

В настоящее время в России реализуется несколько проектов по использованию облачных технологий в образовании. Например, облачные технологии Microsoft: Office 365 и Azure предоставляют возможность дистанционно использовать весь спектр офисных приложений Microsoft для образовательных учреждений. В 2008 году Российской академией наук (ИСП РАН и МСЦ РАН), компаниями НР и «Синтерра» была учреждена программа «Университетский кластер», основная цель которой - повышение уровня компетенций в параллельных и распределенных вычислениях в образовательной и научно-исследовательской деятельности [45]. Национальный исследовательский Южно-Уральский государственный университет (ЮУрГУ), корпорация Intel и группа компаний РСК реализовали в средней образовательной школе №67 Челябинска совместный проект - внедрение инновационной образовательной платформы «Персональный виртуальный компьютер» (ПВК) на базе облачных вычислений [46].

3.1.3 Наука

Как известно, в настоящее время ни одна область научных исследований, будь то естественные науки или гуманитарные, не может эффективно развиваться без использования ИКТ. Следствием этого явилось понятие электронная наука (e-science) [1]. Поэтому естественно, что и облачные вычисления, как одно из наиболее быстро развивающихся направлений ИКТ, занимают все большее место в научных исследованиях. Научный фонд США (National Scientific Foundation - NSF) представил в Конгресс США доклад, в котором описаны перспективы использования облачных вычислений в научных исследованиях [47]. В докладе рассматриваются различные аспекты применения облачных вычислений в области e-science, в том числе вопросы обеспечения интероперабельности на базе использования стандартов, а также план действий.

Весьма большой интерес представляет также книга [48], посвященная e-science. В книге выделяются четыре стадии (парадигмы) в развитии науки (см. рис. 11)

Рис. 11 Стадии развития обработки научных данных [48]

- Эмпирическая стадия

- Теоретическая стадия

- Стадия применение компьютеров для моделирования

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

В [48] есть раздел, посвященный информационной инфраструктуре (архитектуре) e-science.

Что касается отечественной науки, то пока никаких документов о применении облачных вычислений в этой области нам найти не удалось. Следует подчеркнуть, что только в 2012 году и в РФФИ и Программе Президиума РАН появилась тематика облачных вычислений, т.е. пока ведутся фундаментальные исследования.

Тем не менее, перспективную на сегодня архитектуру в области e-science можно представить следующим образом.

Рис. 12 Перспективная архитектура в области e-science

Для отечественной науки представляется настоятельно необходимым начать систематическую работу по применению облаков, как основы научной инфраструктуры, в том числе выделить проблему интероперабельности и начать ее реализацию на основе упомянутого ГОСТ Р 55062-2012 [49].

3.1.4 Коммерция

Одной из быстро развивающихся областей применения ИКТ является сфера, получившая название электронная коммерция (e-commerce). Электронная коммерция -- это сфера экономики, которая включает в себя все финансовые и торговые транзакции, осуществляемые при помощи компьютерных сетей, и бизнес-процессы, связанные с проведением таких транзакций [50]. Электронная коммерция в настоящее время интенсивно развивается во всем мире. За рубежом по данным агентства Invesp.com, в 2011 году объем продаж в сфере электронной коммерции в мире составляет 680,6$ млрд долларов США. По прогнозам этого агентства, данная сумма будет только расти, и к 2015 году достигнет отметки в 1,5 трлн. долларов США [51].

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

В отчете исследовательской компании Gartner [52] говорится о том, что к 2013 году 90% всех интернет-магазинов будут использовать по крайней мере одну SaaS услугу. А 40% из них будут полностью базироваться на SaaS решениях, таких как insales.ru. Эти интернет-магазины будут использоваться в основном малым и средним бизнесом, тогда как большие компании будут использовать SaaS в качестве способа выйти на новые рынки. Несмотря на это, самые крупные игроки интернет-коммерции не будут использовать SaaS, желая сохранить свою уникальность, утверждает Gartner. Другая причина -- их сомнения насчет способности SaaS обеспечить электронную коммерцию в крупном масштабе.

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

Сейчас, целые отделы в больших корпорациях бесполезно тратят свое время, устанавливая свои магазины на Amazon EC2 и S3. Использование SaaS и здесь внесет свои коррективы: продавцу проще управлять магазином на базе SaaS. Не нужно разбираться, как управлять S3, EC2 или собственным хостингом. Напротив, тратя гораздо меньшую сумму денег и меньше времени, можно быстро получить работающий интернет-магазин.

...