Стандарты на облака

Рано или поздно существующие отдельные облака объединятся, и тогда наряду с атмосферой, биосферой и другими сферами на Земле появится еще одна оболочка, полностью созданная человеком, — информационная; мы получим некую вариацию на темы ноосферы, социосферы или биотехносферы. Отличие в том, что эта сфера развивается гораздо быстрее остальных, и в том, что ее развитие идет не путем тех или иных эволюционных мутаций, а при непосредственном воздействии ученых и инженеров. На первом этапе была создана коммуникационная среда Интернет, а сейчас в виде облаков к ней добавляются вычислительные ресурсы и системы хранения данных. Пока нет каких-либо международных координирующих структур, а отдельные попытки в деле поиска консенсуса между участниками процесса выливаются в создание различных некоммерческих организаций, пытающихся каким-то образом регулировать процессы формирования облаков. Так, в конце октября 2010 года был объявлен альянс 50 крупнейших мировых компаний Open Data Center Alliance с целью поиска консенсуса при выработке приемлемой для всех модели облаков.

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

Во-первых, еще не ясно, какой из возможных подходов к архитектуре облаков возобладает, кто станет законодателем моды. В любом случае в основе всякой архитектуры лежит фундаментальная или прикладная наука, далее на этой основе строятся соответствующие технологии, а вот то, что выстраивается на верхнем уровне, зависит от принятого создателями архитектурного стиля. В отличие от нижних двух уровней, здесь результат  менее детерминирован и велик элемент субъективизма. В одних случаях создатели подчиняются требованиям рынка, а в других действуют в согласии со своими индивидуальными представлениями. Вот почему для обозначения двух полярных подходов к архитектуре артефактов стали использовать термины marketecture (м-архитектура — производное от marketing и architecture) и tarchitecture (т-архитектура — производное от technique и architecture). В чистом виде ни то, ни другое не дает хороших результатов, нужен компромисс. В компьютерном мире, как и в других архитектурах, можно найти образцы с разными пропорциями двух подходов. Крайний случай м-архитектуры — торжество гегемонии процессоров х86, заданное рынком (кто бы мог предположить в процессоре Intel 8066 такой потенциал?), а Unix – не менее яркий пример обратного.

Во-вторых, все еще не ясно, по какому пути пойдет дальнейшее технологическое развитие облаков: возобладают ли проприетарные решения крупных производителей или будущее будет за открытыми системами. Скорее всего, сложится нечто вроде биполярной системы, где на одном конце будет "новая Microsoft", а на другом — "новый Unix". В пользу этого мнения свидетельствует процесс активного поглощения средних и даже крупных компаний гигантами: Oracle приобрела Sun Microsystems и задумывается об AMD; потеряли самостоятельность ведущие производители инструментов бизнес-аналитики; в 2010 году наметилась такая же тенденция и с производителями систем хранения. Велика вероятность раздела отрасли между ограниченным числом крупных компаний, и нет ничего удивительного, что начались разговоры о проблеме "большого облака» (Big Cloud), так ее назвали по аналогии с «большой нефтью» (Big Oil) и «большим табаком» (Big Tobacco). Техническая возможность концентрации облачных ресурсов к этому вполне располагает, и, возможно, прав был Скотт Макнили, когда говорил, что в мире будет не более семи глобальных облаков. Взять ту же IBM, которая не случайно избавилась от бизнеса ПК и теперь готовится стать крупнейшим поставщиком десктопов по модели DaaS (Desktop as a Service). Однако  лет 30-40 назад монополизации компьютерного рынка помешала децентрализация вычислений (мини-ЭВМ, ПК) и в не малой степени модель открытых систем OSI (Open Systems Interconnection), не лишенная недостатков, но определившая всю нынешнюю отраслевую структуру и открывшая дорогу на рынок множеству конкурирующих компаний. Если бы не OSI и не ПК, то все разнообразие современного компьютерного рынка, быть может, ограничивалось бы мэйнфреймами.

Операционная система для облаков

Несомненно, серьезным претендентом на создание программного обеспечения для «большого облака» является VMware. Об этом свидетельствует техническая политика, демонстрируемая этой компанией на протяжении последних нескольких лет. Компания готовится к тому, что в новом мире больше не будет гегемонии классических операционных систем типа Windows или Linux — им будет отводиться роль тонкой прослойки, выполняющей рудиментарные функции. В облаках место нынешних ОС, по версии VMware, займет глобальная операционная система VDC-OS (Virtual Datacenter Operating System), сфера влияния которой распространяется на все виды облаков. В 2008 году, став во главе VMware, Пол Мариц сделал ставку на VDC-OS, сравнив задачу создания операционной системы для облаков с изобретением Генри Фордом сборочного конвейера. Основная идея VDC-OS заключается в сборке всех компонентов — серверов, средств хранения, сетевого оборудования — в один унифицированный ресурс, позволяющий превратить совокупность технических элементов, находящихся в ЦОД, в один большой компьютер, а далее вступает в действие схема распределения его ресурсов. Развитие такой схемы началось в 60-е годы с разделения времени (time sharing) — тогда единственным разделяемым ресурсом было время центрального процессора. Затем появились file sharing, network sharing и др. В облаках все ресурсы разделяемы, а под управлением VDC-OS они могут выделяться любому запрашивающему их приложению. То есть получается один, очень большой и хорошо масштабируемый "мэйнфрейм".

Такую аналогию с мэйнфреймом развил директор VMware по маркетингу продуктов Богомил Балкански: "В нынешних условиях работа в ЦОД требует от администраторов больших трудозатрат. Мы хотим избавить их от необходимости использовать ручные инструменты, оставив только необходимые кнопки. Чтобы запустить приложение, администратору будет достаточно задать необходимый уровень обслуживания (готовность, безопасность, масштабируемость), а затем поддерживающая инфраструктура получит возможность выполнять это приложение в согласии с заданными требованиями". Мариц предпочитает называть новую архитектуру программным мэйнфреймом, описывая ее как некий программный фундамент для частного или для глобального облака.

С момента объявления VDC-OS рассматривалась как концепция, позволяющая по-новому взглянуть на стек существовавших на тот момент и будущих продуктов VMware. К 2010 году термин VDC-OS стали использовать реже — сейчас чаще говорят о трехуровневой инфраструктуре. Нижний уровень образует облачная инфраструктура и средства ее управления (Cloud Infrastucture and Management), средний представлен новой платформой для приложений (New Application Platform), верхний — новые средства для доступа, предназначенные конечным пользователям (New End User Access). Составляющие стек продукты были анонсированы на VMworld 2010: VMware vCloud Director — модель доставки и потребления ИТ-сервисов в гибридных облаках, VMware vShield — безопасность, VMware vCloud Datacenter Services — поддержка ЦОД. В октябре 2010 года к этому набору прибавился VMware vCloud Request Manager, увеличивающий возможности управления гибридными облаками, и CapacityIQ 1.5, расширяющий возможности аналитики систем хранения. Было объявлено также бета-тестирование решения для малого и среднего бизнеса VMware Go Pro. Средний уровень (уровень поддержки приложений), реализует продукт VMware vFabric, сочетающий функционал конструкции для разработки Spring Java с такими платформенными сервисами, как облегченный сервер приложений, управление глобальными данными, балансировка нагрузки и управление приложениями. Было объявлено также о выпуске модели данных VMware vFabric GemFire 6.5 для облачных приложений. На верхнем уровне (поддержка пользователей) размещаются: законченное решение для виртуализации десктопов VMware View 4.5, технология виртуализации приложений VMware ThinApp 4.6, средство для обеспечения безопасности, специализированная виртуальная машина Zimbra Collaboration Suite Appliance, поддерживающая корпоративную почту и удаленное взаимодействие сотрудников, а также система инфраструктурных сервисов для поддержки виртуальных десктопов VMware Desktop Infrastructure Service.

В данном стеке поддерживается только один открытый стандарт Open Virtualization Format, распространяющийся на упаковку и распространение виртуальных машин и отчасти на то, как приложения выполняются на этих виртуальных машинах. Стандарт OVF был предложен рабочей группой Distributed Management Task Force в сентябре 2008 года от лица нескольких компаний в составе Dell, HP, IBM, Microsoft, VMware и тогда еще существовавшей XenSource. Первая рабочая версия OVF Specification V1.0.0 была выпущена в январе 2010 года. VMware предлагает утилиту OVF Tool, позволяющую импортировать и экспортировать пакеты OVF при работе с продуктами, входящими в описанный стек.

Инициатива OpenStack

Еще один пример корпоративной атаки на облака демонстрирует известный провайдер облачных сервисов, компания Rackspace, которая совместно с NASA выступила с инициативой открытия кодов OpenStack, направленной на создание альтернативы таким решениям, как Amazon Elastic Compute Cloud и VDC-OS. Уже известно о двух составных частях OpenStack. За работу с системами хранения отвечает OpenStack Object Storage, а вычислительная составляющая будет построена на технологиях Rackspace Cloud Servers и Nebula.

Цель OpenStack — предоставление организациям возможности создания облака, используя свободное ПО и стандартное аппаратное обеспечение. В этой инициативе есть очевидное лукавство: те, кто пойдет по предложенному пути, действительно смогут сэкономить на ПО при создании своих частных облаков, но эти облака будут построены на архитектурных принципах от Rackspace, что же в таком случае их ожидает, если вдруг возникнет желание построить гибридное облако?

Стандарты

Отсутствие единообразия отпугивает потенциальных клиентов от облаков не меньше, чем проблемы с безопасностью, однако на практике процессу стандартизации уделяется сейчас мало внимания, и как следствие возникают ситуации, подобные ситуации, созданной компанией Coghead. Начало ее деятельности было весьма многообещающим, в 2007 году Coghead запустила бесплатные сервисы, а позже к ним добавились и коммерческие сервисы, распространяемые по подписке?. В результате компания стала одним из первых провайдеров, реализовавших модель «платформа как сервис» (Platform as a Service, PaaS), благодаря чему приобрела заметную известность. Предлагаемые Coghead сервисы попадали в категорию webware — так теперь называют ПО, которое выполняется в облаке без какой-либо установки на пользовательских рабочих местах. Целевой аудиторией Coghead были бизнес-пользователи, имеющие представление о разработке приложений: опираясь на сервисы, они могли создавать нужные им приложения в режиме буксировки без какого-либо кодирования. Модули, полученные в результате таких манипуляций (они получили название coglets), давали пользователями реальную возможность работать с данными, хранимыми в СУБД. К сожалению, сегодня об этой быстро сложившейся и при том эффективной экосистеме приходится говорить исключительно в прошедшем времени: в начале 2009 года Coghead была куплена SAP, а на ее сайте появилось объявление: «Дорогие и высокочтимые пользователи, мы гордимся имевшейся у нас возможностью предлагать вам современную технологию Platform as a Service и поддерживать разработанное вами ПО, но, к сожалению, в силу сложившихся экономических обстоятельств Coghead прекращает свою деятельность...» Стандарта нет, альтернативы нет — что делать пользователям, вложившимся в проприетарные "коглеты"? В такую ловушку может попасть любой, привязавшийся к технологиям одного провайдера.

Унифицированные сервисы по типу связующего ПО (например, Unified Cloud Interface Project) могут подстраховать потребителей услуг, но стандарты все же более универсальны. Их нынешнее отсутствие не есть чья-то злая воля — это объективная ситуация, подоплека которой кроется в существенно большей сложности стандартизации в облаках, чем это может показаться на первый взгляд.

В идеале стандарты должны распространяться на все уровни стека облачных сервисов (см. рисунок): IaaS, PaaS, SaaS и DaaS, причем чем выше уровень, тем сложнее задача стандартизации. Структуру этого стека, ставшего стандартом де-факто, приняли сейчас все производители, но это вовсе не значит, что между продуктами разных поставщиков есть хоть какая-то совместимость. В других индустриях также имеются своего рода стеки, например от железнодорожной колеи до вагона в целом, а стандарты распространяются обычно на нижние инфраструктурные уровни (ширина колеи, параметры сцепных устройств и т. д.). Обычно подъем стандартов по стеку технологий осуществляется до тех пор, пока в роли пользователя на верхних уровнях не выступит человек, но и там, где есть человек, могут действовать, скажем, эргономические стандарты. Отличие информационных систем в том, что здесь на всех уровнях стека остается межмашинное общение и оно хотя бы теоретически предполагает распространение технологических стандартов по всем уровням. Повторимся, стандартизация — не единственный способ достижения унификации и совместимости; например, можно использовать различного рода брокеры-переходники по типу адаптеров для подключения к электрической сети в разных странах. Конкретный выбор оптимального решения напрямую зависит от цены вопроса.

Нижние уровни (DaaS и IaaS) можно унифицировать уже сейчас, а вот как быть с двумя верхними, пока сказать сложно, и здесь дискуссия в разгаре. Особую остроту ей придает общий интерес к гибридным облакам, состоящим из публичных и частных, — без должного обеспечения стандартами ни о каком массовом переходе в гибридные облака говорить не приходится, хотя необходимые для этого технологии существуют?. VMware предлагает набор продуктов, реализующих функциональность каждого из трех уровней (основная их часть была анонсирована на VMworld 2010).

Проблема стандартизации в облаках актуальна, причем относится к числу наиболее трудных, она даже сложнее, чем проблема безопасности. Практика показала, что логически несложно обосновать стандартизацию простых вещей, имеющих привычные измерения — калибр патрона, размеры гаечных ключей и т. д. Но чем сложнее сущности, тем труднее их унифицировать, особенно в период их быстрого развития. Как же уложить облака в прокрустово ложе заданных регламентов?

Классификация подходов к стандартизации

Можно выделить два направления в стандартизации для IaaS: первое распространяется на внутреннее устройство облаков, а второе — на внешние интерфейсы к ним. Первое есть не что иное, как формат для описания виртуальных ресурсов внутри шаблонов виртуальной машины, а второе — программный интерфейс для работы с ней. Компании, ставшие первыми провайдерами IaaS, были вынуждены работать, опираясь на собственные стандарты. Все началось с Amazon Machine Image, — специальной виртуальной машины (virtual appliance) для создания виртуальных машин в облаке Amazon Elastic Compute Cloud. AMI, основное средство для развертывания сервисов в среде EC2, включает в себя предназначенную только для чтения файловую систему, образ операционной системы (Linux, Unix или Windows) и дополнительное ПО. AMI бывают трех типов: общедоступные (Public), оплаченные по подписке (Paid) и распределенные (Shared), то есть частные AMI, доступные разрешенным пользователям EC2.

В ответ на эту инициативу Amazon в 2007 году группа компаний (среди них были в том числе HP, IBM, Microsoft и VMware) предложила альтернативный открытый стандарт OVF и передала его в координирующую организацию DMTF (Distributed Management Task Force). Стандарт OVF представляет собой схему для XML-описания одной или группы виртуальных машин, его идеология близка модели Common Information Model (CIM). OVF может применяться для создания таких инструментов, которые бы выражали пользовательские требования к используемым ими виртуальным машинам. Описания OVF помещаются в контейнер или конверт (Envelope), включающий в себя описания внешних данных (References), а основные метаданные хранятся в соответствующих разделах: сетей — в NetworkSection, дисков – в DiskSection, данных о разворачивании — в DeploymentOptionSection, данных об остальном виртуальном оборудовании — в VirtualHardwareSection.

После создания виртуальных машин возникает потребность в управлении ими — загрузке и выгрузке, контроле и конфигурировании готовых шаблонов, а чтобы сделать все это без излишних сложностей, необходим соответствующий интерфейс. Пример собственного решения Cloud Servers API предложила компания Rackspace. Ее интерфейс позволяет осуществлять управление виртуальными машинами с любых устройств, а до его появления приходилось использовать тяжеловесный инструмент Rackspace Cloud Control Panel. Компания VMware разработала свой собственный интерфейс vCloud API и передала его в DMTF для принятия в качестве отрытого стандарта. Open Grid Forum весной 2010 года опубликовал открытый стандарт Open Cloud Computing Interface (OCCI), а другие компании, такие как Eucalyptus, эмулируют ставший стандартом де-факто интерфейс Amazon Web Services.

Несколько стандартов могут быть интегрированы в один с использованием libvirt — свободной кроссплатформенной библиотеки средств управления виртуализацией. В Googlе разрабатывается Unified Cloud Interface Project — брокер, согласующий различные API.

Подытоживая сказанное о двух направлениях стандартизации IaaS, повторим: первое сводится к установлению отношений между VM, гипервизорами и аппаратным обеспечением, а второе — к вызову инструментов для управления из тех или иных приложений. Таким образом, видно, что даже на уровне IaaS все непросто, что же тогда говорить об уровнях PaaS и SaaS — здесь различные платформы используют данные различных форматов, например Windows Azure использует данные в форматах СУБД и контейнеры .Net, что исключает совместимость с Google AppEngine, и наоборот. Единственный способ добиться совместимости состоит в применении универсальных конструкций типа расширения Python в AppEngine.

Что же касается SaaS, то здесь дела обстоят совсем плохо — стандартизация тут приводит к ограничению творческой составляющей и, следовательно, качества решения, но в то же время отсутствие совместимости может обернуться большими убытками. Известна пока единственная попытка разработки стандартов для SaaS — начавшая свое существование в 2010 году организация CloudAudit или A6 (Automated Audit Assertion Assessment and Assurance API).

В целом большинство известных работ по стандартизации облаков можно свести в матрицу (см. таблицу), из которой видно, что в некоторых областях стандартизация еще и не начиналась, а наиболее активно работы идут на нижних уровнях (IaaS и DaaS).

Силовой и общественный подход

Итак, на данный момент наиболее проработаны интерфейсы к сервисам IaaS, и здесь обнаруживаются два принципиально разных подхода. Один из них можно назвать силовым — это инициатива VMware vCloud, представляющая собой попытку насильственной установки стандарта де-факто на базе наиболее распространенных решений. Решения VMware поддерживают более 100 партнеров компании, и принятие vCloud API позволяет создать условия для совместимости приложений внутри колоссального по своим масштабам партнерского сообщества.

Альтернативный подход предпринят организацией OGF и представляет собой попытку некоторых производителей и академической среды, сформировавшейся вокруг grid, выработать единый взгляд на облака. Здесь было принято решение не идти от сделанного и фиксировать сложившееся статус-кво, а разработать концептуальную базу для стандартизации на всех уровнях стека -aaS. Результатом деятельности OGF стало создание рабочей группы и инициативы OCCI, направленной на согласование всех API, в том числе и Amazon AWS, GoGrid и Flexiscale. В первой редакции стандарт OCCI ориентирован только на API для IaaS, но его модульная конструкция позволяет в будущем продолжить разработку стандартов для PaaS и SaaS. В основу конструкции OCCI положен Representational State Transfer (REST), а соответствующую архитектуру называют Resource Oriented Architecture (ROA). Суть подхода REST, название которого переводится как «передача состояния представления", заключается в обеспечении доступа к ресурсам и сервисам, используя для этой цели идентификатор URI (Unified Resource Identifier), с помощью которого можно создавать, извлекать, изменять и удалять те или иные виртуальные ресурсы, объединяя и собирая из них виртуальные машины. Имея необходимый программный интерфейс, можно писать клиентское ПО, которое управляет выделенной клиенту областью в облаке. В этом состоит отличите от протоколов "конвертного типа» (envelope type) Atom и SOAP, основанных на XML, когда в конверт пакуется сообщение, содержащее также метаданные о том, как его следует интерпретировать.

При выполнении транзакций OCCI пользуется непосредственно «HTTP-глаголами» (HTTP-verbs), а не методом POST, как это сделано в SOAP и других протоколах WS-*. В OCCI определены операции GRUD (Create, Retrive, Update и Delete), выражаемые посредством глаголов. Данные передаются с использованием небольшого количества стандартных форматов (например HTML, XML, JSON). Протокол OCCI (как и HTTP) должен поддерживать кэширование, не зависит от сетевого слоя и не должен сохранять информацию о состоянии между парами «запрос-ответ». Утверждается, что такой подход обеспечивает масштабируемость, позволяя системе эволюционировать с новыми требованиями. Методология, опробованная на стандарте OCCI, позволяет сделать следующий шаг, на этот раз по направлению к стандартизации доступа к данным, а именно к созданию интерфейса SNIA Cloud Data Management Interface (CDMI).

Стандарт для облачных систем хранения

По данным IDC, темп развития облачных систем хранения будет выше, чем облачного компьютинга в целом, сейчас на него приходится 9% всех облачных услуг, а к 2013 году эта цифра возрастет до 14% и общий объем бизнеса превысит 6 млрд долл. Очевидно, что такой объем требует стандартизации, поэтому ассоциация SNIA образовала специальную группу Technical Working Group, в задачу которой входит исследование вопросов, связанных со стандартизацией. Сейчас в нее входит более 140 компаний, и первые результаты работы TWG были опубликованы в двух документах — Cloud Storage Use Cases и Reference Model. Основываясь на них, в сентябре 2009 года TWG выпустила предварительную версию v 0.8 стандарта CDMI, а в 2010 году — версию CDMI v 1.0. После этого члены SNIA вышли с инициативой Cloud Storage Initiative, цель которой в пропаганде стандарта и координации с другими участниками процесса стандартизации: OGF, OCCI, DMTF, Cloud Incubator и Cloud-Standards.org.

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

Стандарт CDMI не существует вне более общей картины, поэтому необходимо сделать одно уточнение, а именно обозначить различие между облачным хранением (cloud storage) и облачными вычислениями (cloud computing). За хранением и обработкой данных в облаках стоят технологии виртуализации, однако эти технологии близки только по названиям, а принципы виртуализации разные и используются эти технологии в разных целях. Услуги сloud storage поддерживаются сетевой моделью хранения — данные хранятся в режиме онлайн и распределены по серверам, принадлежащим провайдерам. В качестве пользователей могут выступать не только серверы и приложения, образующие облака, но и реальные пользователи, например те, кто хочет делать резервную копию данных со своего компьютера или сохранять какую-то часть корпоративных данных, следуя нормативным требованиям. Вообще же область приложения cloud storage можно разделить на три основные части: создание резервных копий, архивирование и поддержка приложений. При выборе решений для каждой из них необходимо исходить из стоимости, емкости, времени хранения, величины задержки, уровня безопасности и секретности данных. Данные требования противоречат друг другу, поэтому одного универсального решения быть не может, но наилучшим решением будут гибридные облака, а это значит, что проблема стандартизации становится одной из важнейших.

Главная новизна и отличительная черта подхода к созданию API для доступа к облачным системам хранения, предложенная авторами CDMI, заключается в разделении двух потоков; в одном ресурсы предоставляются посредством функциональных интерфейсов, это поток данных, а во втором облачные ресурсы предоставляются с помощью интерфейсов для управления. Еще одна черта заключается в особенностях использования метаданных. В тех случаях когда приходится работать с большими объемами данных, метаданные являются удобным инструментом для установления соответствие между самими данными и требованиями к их использованию и интерпретации.

Стандарты OCCI и CDMI являются взаимодополняющими, они построены по общим принципам и ориентированы на близкие технологии. Пока их можно рассматривать как стартовые точки для будущего более широкого процесса стандартизации. Если будут построены системы, соответствующие этим стандартам, то они должны работать следующим образом:

• клиент создает контейнер CDMI Container, используя интерфейс CDMI, и экспортирует его в виде экспортного типа в OCCI, в ответ он получает идентификатор CDMI Container ObjectID;
• клиент создает виртуальную машину с помощью интерфейса OCCI и подключает к ней том хранения типа CDMI с использованием ObjectID, получая в ответ идентификатор OCCI Virtual Machine ID;
• клиент изменяет экспортно-импортную информацию в контейнере CDMI Container в соответствии с OCCI Virtual Machine ID и открывает доступ Virtual Machine в контейнер;
• клиент запускает в работу Virtual Machine, используя интерфейс OCCI.

***

Когда эта статья уже была готова, пришла новость, что и компания Oracle стремится предложить в качестве стандарта для частных облаков свою модель Cloud Resource Model API, которая изначально была разработана Sun Microsystems, а потом передана в DMTF. Этот API состоит из двух частей, в одной описывается взаимодействие между виртуальными машинами и системами хранения, а в другой — протокол взаимодействия с этими ресурсами. Модель построена на стандарте REST.

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

Таблица. Распределение ролей между участниками процесса стандартизации облаков

OMG (Object Management Group) — рабочая группа, занимающаяся разработкой и продвижением объектно-ориентированных технологий и стандартов. OGF (Open Grid Forum) — сообщество пользователей, разработчиков и производителей в области grid. DMTF (Distributed Management Task Force) — отраслевая рабочая группа, предлагающая и продвигающая стандарты для корпоративных информационных систем. SNIA (Storage Networking Industry Association) — отраслевая ассоциация, включающая производителей систем хранения данных. OASIS (Organization for the Advancement of Structured Information Standards) — консорциум, который управляет разработкой, конвергенцией и принятием промышленных стандартов электронной коммерции в рамках международного информационного сообщества. CSA (The Cloud Security Alliance) — недавно созданная организация, деятельность которой направлена на обеспечение безопасности в облаках.