Совместимые облака
реклама
Проект Изображение Государственного Герба Республики Казахстан НАЦИОНАЛЬНЫЙ СТАНДАРТ РЕСПУБЛИКИ КАЗАХСТАН СОВМЕСТИМЫЕ ОБЛАКА СТ РК DSP-IS0101 - 20__ (DSP-IS0101-2009 Interoperable Clouds, IDT) Настоящий проект стандарта не подлежит применению до его утверждения Комитет технического регулирования и метрологии Министерства по инвестициям и развитию Республики Казахстан (Госстандарт) Астана 1 Предисловие 1 ПОДГОТОВЛЕН И ВНЕСЕН Техническим Комитетом по стандартизации №34 «Информационные технологии» на базе АО «Национальный инфокоммуникационный холдинг «Зерде» 2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Председателя Комитета технического регулирования и метрологии Министерства по инвестициям и развитию Республики Казахстан №_____ от ____________ 3 Настоящий стандарт идентичен к региональному стандарту DSPIS0101 Interoperable Clouds (Совместимые облака) Перевод с английского языка (en). Степень соответствия – идентичная, (IDT). 4 В настоящем стандарте реализованы нормы законов Республики Казахстан «О техническом регулировании» от 09 ноября 2004 года № 603-II, «Об информатизации» от 11 января 2007 года № 217 и «О языках в Республике Казахстан» от 11 июля 1997 года № 151-I. 5 СРОК ПЕРВОЙ ПРОВЕРКИ ПЕРИОДИЧНОСТЬ ПРОВЕРКИ 20__ год 5 лет 6 ВВЕДЕН ВПЕРВЫЕ Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Нормативные документы по стандартизации», а текст изменений и поправок – в ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты» Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Комитета технического регулирования и метрологии Министерства по инвестициям и развитию Республики Казахстан. 2 Совместимые облака 1. Облачные вычисления Облачные вычисления это подход к предоставлению IT-услуг, который дает большую гибкость и снижение затрат для потребителей, особенно касательно первоначальных расходов. Такой подход влияет не только на используемые способы обработки данных, но также на технологии и процессы, которые используются для построения и управления IT в рамках предприятий и у поставщиков услуг. Облачные вычисления, помимо больших возможностей и перспектив, являются источниками риска и сложностей в управлении. Часто задаваемые вопросы, применяющие в облачных вычислениях: Как интегрировать компьютер, сеть и сервис хранения от одного или нескольких поставщиков облачных сервисов в моем бизнесе и в IT процессах? Как управлять безопасностью и риском непрерывности бизнеса через нескольких провайдеров облачных сервисов? Как управлять жизненным циклом обслуживания в распределенной среде из нескольких поставщиков в целях удовлетворения соглашения об уровне предоставления услуги (SLA) с моими клиентами? Как я могу поддерживать эффективное управление и аудит процессов в интегрированных центрах обработки данных и облачных провайдеров? Как принять или перейти на нового поставщика облачных услуг? На рисунке 1 показаны данные проблемы в среде облачных вычислений. Рисунок 1 - Проблемы внедрения облачных вычислений 3 DMTF сформировали Open Cloud Standards Incubator (инкубатор открытых облачных стандартов) для оценки воздействия облачных вычислений на менеджмент и стандарты виртуализации, а также для выработки рекомендаций для расширений для лучшего соответствия требованиям облачных сред. Некоторые изменения могут повлиять на стандарты DMTF, в то время как другие потребуют координации с другими группами стандартов и индустрии. Цель состоит в том, чтобы помочь индустрии в решении проблем, которые влияют на совместимость, переносимость и безопасность среды облачных вычислений. 2 Представление Определение термина облачных вычислений - включая частные и публичные облака, IaaS (Инфраструктура как услуга), PaaS (Платформа как услуга) - взяты из работ Национального Института стандартов и технологий (США) [1]. В частности, NIST определяет облачные вычисления как "модель обеспечения повсеместного и удобного сетевого доступа по требованию к общему пулу конфигурируемых вычислительных ресурсов (например, сетям передачи данных, серверам, устройствам хранения данных, приложениям и сервисам — как вместе, так и по отдельности), которые могут быть оперативно предоставлены и освобождены с минимальными эксплуатационными затратами и/или обращениями к провайдеру." NIST определяет четыре модели развертывания облака: Публичные облака (инфраструктура, предназначенная для свободного использования широкой публикой или большими промышленными/индустриальными группами); Частные облака (инфраструктура, предназначенная для использования одной организацией); Общественные облака (вид инфраструктуры, предназначенный для использования конкретным сообществом потребителей из организаций, имеющих общие задачи (например, миссии, требований безопасности, политики, и соответствия различным требованиям); Гибридные облака (это комбинация из двух или более различных облачных инфраструктур (частных, публичных или общественных)); Среды, рассматриваемые открытым инкубатором облачных стандартов включают в себя все эти модели развертывания. Основное внимание инкубатора уделяется аспектам управления модели IaaS (Инфраструктура как услуга), с некоторой работой с участием PaaS (Платформа как услуга). Эти аспекты включают в себя соглашение об уровне услуг (SLA), качество обслуживания (QoS), переносимость нагрузки, автоматизированное снабжение и учет и биллинг. Фундаментальные возможности IaaS делают доступным к потребителям облачных сервисов. Примеры услуг: вычислительные системы, 4 емкие хранилища, и сети которые соответствуют обусловленным ограничениям безопасности и производительности. Примеры потребителей облачных услуг: центры обработки данных предприятий, малый бизнес и другие облака. Многие существующие и возникающие/появляющиеся стандарты будет иметь важное значение в области облачных вычислений. Некоторые из них, например, стандарты связанные с обеспечением безопасности, обычно применяются в распределенных вычислительных средах. Другие применяются непосредственно к технологиям виртуализации, которые как ожидается, будут важными строительными блоками в облачных реализациях. (Динамическая инфраструктура, возможная благодаря технологиям виртуализации хорошо сочетается по требованию с динамичным свойством облаков.) Примеры стандартов включают в себя управление и соблюдение соглашения об уровне услуг (SLA), федеративную идентификацию и аутентификацию, а также совместимость и переносимость облака. На рисунке 2 показана область применения и преимущества Открытого Инкубатора Облачных Стандартов и преимущества расширения стандартов управления и виртуализации. Рисунок 2 – Область применения и преимущества открытого инкубатора облачных стандартов Открытый Инкубатор Облачных Стандартов рассматривает следующие аспекты жизненного цикла облачного сервиса: Описание облачных сервисов в шаблоне; Развертывание облачных сервисов в облако; 5 Предложение услуг потребителям; Вступление потребителей в договоры для предложение; Операции поставщика и управление экземплярами услуг; Удаление предлагаемых услуг. Если возможно, то существующие стандарты (или расширения к ним) будут интегрированы в рекомендуемое решение. Примеры области стандартизации включают управление ресурсами протоколов, артефакты данных, упаковка форматов, а также механизмы безопасности для обеспечения операционной совместимости. Данный справочный документ/официальная документация анализирует отношения между поставщиком облачных услуг и потребителем с точки зрения прецедентов/сценариев использования, жизненного цикла сервисов и эталонной архитектуры для удовлетворения потребностей интерфейса между поставщиком и потребителем. 3 Сценарии использования Учитывая множество конкурирующих предложений по интерфейсам для облаков и раннюю стадию развития отрасли, для пользователей важно использовать стандарты интерфейсов для обеспечения гибкости для будущих расширений и во избежание замыкания на одном поставщике. При поддержке ключевых игроков в отрасли, этот аспект портативности имеет первичное значение, которую предлагает облачная инфраструктура, основанная на стандартах. В этом разделе описываются три сценария, которые показывают, как потребители и поставщики облака могут взаимодействовать, используя совместимость облачных стандартов. Эти сценарии являются только примерами, так как существуют множество других возможностей. Первый сценарий (смотреть раздел 6.1) показывает, как на основе стандартов обеспечивается гибкость для бизнеса с новым поставщиком без чрезмерных усилий и затрат; Второй сценарий (смотреть раздел 6.2), описывает некоторые из способов, благодаря которым несколько облачных провайдеров могут работать вместе, в целях удовлетворения потребностей потребителей облачных сервисов; Третий сценарий (смотреть раздел 6.3) описывает, как различные потребители с различными потребностями могут вступать в различные контрактные договоренности с поставщиками облачных услуг для хранения данных. 3.1 Облачная переносимость Следующий сценарий служить примером того, как растущая компания может использовать стандартный облачный интерфейс, который соответствует ее стадии роста и к обработке требовании для расширения 6 использования услуг облачных вычислений через нескольких провайдеров облачных сервисов. XYZ Corp является сервисной компанией, которая начинала как небольшая, но пережила взрывной рост. Чтобы минимизировать свои затраты, XYZ Corp начали с небольшого центра обработки данных и решили положиться на поставщика облачных сервисов предлагающих услуги IaaS. Компания слышала о CloudCoA, компания, которая обеспечивает надежные облачные IT-сервисы по низкой цене. Хотя существовали и другие поставщики облачных услуг, CloudCoA имела преимущество быть основанной на стандартах DMTF. XYZ Corp понравилось гибкость поставщика, подход к делу, и они решили использовать CloudCoA для дополнительных IT услуг, которые могут понадобиться в будущем. К счастью для XYZ Corp, их бизнес рос очень быстро, и IT-потребности компании начали расти в чрезвычайных масштабах и объемах. Хотя CloudCoA изначально был в состоянии справиться с ростом, потребности XYZ Corp вскоре превзошли возможности, которыми располагают CloudCoA. Кроме роста главной компании, значительный рост бизнеса в Европейском Союзе побудил XYZ Corp открыть филиал в Германии. Хотя CloudCoA может обеспечить IT-услугами с достаточными возможностями и производительностью в США, регулирующие и нормативные ограничения вынуждают XYZ Corp искать поставщиков облачных услуг в странах членах Европейского Союза. Поскольку все IT-процессы в XYZ Corp были основаны на основе стандартизированных облачных сервисов, компания обнаружила множество поставщиков, с которыми можно подписать соглашение. Они заключили контракт с двумя новыми поставщиками, CloudCoB и CloudCoC, с целью заполнения пробелов и добавления резервных мощностей для будущего роста. Для филиала в Германии, XYZ Corp выбрали компанию CloudCoC, которые обеспечивают хорошие услуги в области. Единственное усилием, необходимым компании для повторного использования их IT-приложений, скриптов и процессов компанией CloudCoC было установление деловых отношений с CloudCoC и пользование их услугами, без каких-либо существенных нарушений IT-услуг. В главной компании решили увеличить объем услуг от CloudCoA с помощью CloudCoB. С помощью простых изменений в своих ITприложениях и скриптах, компания смогла использовать услуги CloudCoB для всех новых дел, при этом продолжая использовать CloudCoA для существующих учетных записей. На рисунке 3 показано, как стандартные интерфейсы помогли ITоперациям XYZ Corp развиваться с течением времени, чтобы соответствовать росту бизнеса. 7 Рисунок 3 – Стандарты упрощают корпоративную ИТ эволюцию и помогают избежать замыкания на одном поставщике 3.2 Объединение облачных провайдеров На рисунке 4 показан промышленный центр обработки данных в роли потребителя облачных услуг, получающий вычислительные мощности из облака (Cloud 1). Сценарием использования для данного центра обработки данных является тестирование нового приложения. Такие тесты требуют большую производительность, однако эти тесты случаются на нерегулярной основе, и поддержание достаточных вычислительных ресурсов для этих тестов в центре обработки данных будет дорогостоящим. Аутсорсинг вычислительных ресурсов в облаке является хорошим способом для достижения требуемой высокой производительностью по приемлемой стоимости. Центр обработки данных взаимодействует с каталогом услуг Cloud 1 для запроса: Вида услуги; Деталей его конфигурации; Деталей соглашения об уровне услуг, таких как мощность, доступность и производительность; Других ограничений, таких как сетевая безопасность. При правильном запросе сервис менеджер/диспетчер услуг предоставляет интерфейс, используемый для управления развернутой службой, в том числе информацию для доступа. Затем центр обработки данных может взаимодействовать непосредственно с выделенными виртуальными машинами (VMs). На рисунке 4 это взаимодействие представлено в виде пунктирной линии между центром обработки данных и виртуальной машиной. Рисунок неизбежно не включает такие детали, как 8 виртуальные образы, развертывающиеся на гипервизорах виртуальных машин. Рисунок 4 также показывает следующие примеры того, как центр обработки данных может взаимодействовать более чем с одним поставщиком облачных услуг: Cloud 2 обеспечивает дополнительной вычислительной мощностью Cloud 1 когда запросы по нагрузке превышают собственные возможности Cloud 1. Если запросы центра обработки данных превышают его мощность, Cloud 1 запрашивает мощность посредством каталога услуг Cloud 2. После предоставления необходимой мощности, диспетчер услуг Cloud 2 предоставляет информацию для доступа к виртуальной машине, с которой диспетчер услуг Cloud 1 связывает центр обработки данных. В этой модели объединения, центр обработки данных может быть не осведомлен о том, что используемая вычислительная мощность размещается в Cloud 2 вместо Cloud 1. Потребитель облачных услуг, такой как данный центр обработки данных, может запрашивать и получать услуги из нескольких облаков. В этом примере центр обработки данных запрашивает услуги с Cloud 1 и с Cloud 3. Это может происходить по различным причинам. Cloud 3 может поддерживать различные типы вычислительных услуг или различные параметры соглашения об уровне услуг в сравнении Cloud 1. Возможно только Cloud 3 предоставляет услуги по хранению данных. Или же, вполне вероятно, центр обработки данных хочет иметь два источника на один и тот же вид услуги, чтобы минимизировать риски. В этих случаях Cloud 1 и Cloud 3 не взаимодействуют друг с другом и вполне возможно не знают о существовании друг друга. Облачный посредник это облако, который предоставляет услуги потребителям, но не может размещать собственные ресурсы. В данном примере, посредник объединяет ресурсы из Cloud 1 и Cloud 2, делая их доступными и понятными для потребителей. Как и в первом примере объединения, потребители взаимодействуют только с посредником при запросе услуги, даже несмотря на то, что оказанные услуги предоставляются из других облаков. 9 Рисунок 4 – Сценарии развертывания облака 3.3 Адаптация услуг под меняющиеся требования Cloud Data Retention Service Co. (CDRSC) предоставляет услуги управления облачным сохранением данных, которые она предлагает публично. CDRSC хранит документы которые она получает. Клиенты CDRSC заключают договор и соглашение об уровне услуг, который гарантирует следующие условия: Данные надежно защищены и доступны только через авторизованный запрос; После получения авторизованного запроса либо от потребителя, либо от управляющего или законного начальство, документы оперативно и конфиденциально доставляются запросившему; При истечении срока хранения, документы будут быстро и безвозвратно уничтожены. CDRSC предлагает сервис по многопользовательской облачной системе хранения данных, который используются потребителями с различными требованиями (например, малые, средние и крупные предприятия, как показано на рисунке 5). CDRSC строго придерживается контракта который она предлагает своим потребителям, согласно которому она ручается за не смешивание и разделение данных потребителей. Договор на оказание услуг также дает документальную гарантию на наличие 10 необходимых мер безопасности для предотвращения потенциальной утечки данных, вызванной злоумышленниками или конкурентами/противниками. Кроме того, многочисленные требования защиты могут быть указаны в договоре на обслуживание единственным/одним клиентом. Например, компания может выбрать для хранения, как открытые/публичные данные, так и конфиденциальные данные с помощью облачных систем хранения данных службы CDRSC. Уровень защиты и политики хранения для двух типов данных различен, и CDRSC должны поддерживать такие политики. Рисунок 5 – Сценарий использования многопользовательской облачной системы хранения данных Кроме того, CDRSC по контракту обязаны подчиняться регулирующим органам. Например, некоторые из документов, хранящихся на CDRSC способствуют финансовой отчетности их клиентов, корпорации LargeCo, которая должна соответствовать правилам закона Сарбейнза-Оксли. Документы которые существенным образом способствуют финансовым отчетам LargeCo должны храниться в строгом и прозрачном соответствии с Законом Сарбейнза-Оксли, предотвращения несанкционированные изменения или уничтожения документов, или утечку информации, которая могла бы способствовать инсайдерской торговле и другим форм мошенничества. LargeCo платит CDRSC за гарантию того, что LargeCo и его аудиторы и регуляторы соответствует Закону Сарбейнза - Оксли в области хранения критических финансовых документов. 4 Жизненный цикл облачных сервисов В модели Открытого Инкубатора Облачных Стандартов, потребители облака заключают договор с поставщиками облачных услуг на 11 предоставление услуг. Облачный сервис имеет множество различных состояний жизненного цикла. Рисунок 6 описывает состояние отдельных услуг в жизненном цикла услуг и сценарии/варианты использования, связанные с каждым состоянием. Рисунок 6 – Жизненный цикл облачных услуг и варианты/сценарии использования После создания компонентов сервиса, разработчик начинает процесс, который делает ее доступной для потребителей путем создания шаблона, который определяет содержание и интерфейс сервиса. Сервис может быть простым вроде единственной виртуальной машины или же сложным как многоуровневое приложение, упакованное с использованием открытого стандарта для хранения и распространения виртуальных машин [OVF-1]. Шаблон затем настраивается провайдером для предоставления услуг для потребления одному или нескольким потребителям. Предложение является элементом/единицей измерения, которую потребитель запрашивает путем заключения контракта с поставщиком на это предложение. Обеспечение/снабжение от провайдера это экземпляр услуги соответствующий ограничениям, определенным в предложении и в шаблоне, которую потребитель согласно контракту. После прекращения контракта, поставщик возвращает себе экземпляр и его вспомогательные ресурсы. В таблице 1 приводится пример состояний жизненного цикла и иллюстрируется деятельность, связанная со сценариями использования данных состояний. Таблица 1 - Пример сценариев состояния жизненного цикла и связанных с ними деятельности Состояние Пример деятельности жизненного цикла 12 Создание шаблона сервиса Публикация шаблона сервиса Создание предложений Установка взаимоотношений Заключение контракта/договора ProviderCo предлагает инфраструктуру как услугу (IaaS) через интернет-ресурс. Решено предлагать шаблон сервиса который включает в себя сервер с двумя или четырьмя процессорами, 6 или 8 ГБ оперативной памяти и 100 ГБ дискового пространства. Потребителю предлагается на выбор проприетарная и открытая операционная система, HTTP серверы и менеджеры баз данных. Кроме того, ProviderCo предлагает увеличение хранение данных в 100 Гб. Компания создала 12 шаблонов для различных вариантов. Их бизнес-планом является продажа стандартизированных вычислительных блоков и единиц хранения на одномесячной основе. Компания публикует эти шаблоны, с договорной информацией, такой как стоимость и ценовая политика, в виде предложений в их онлайн каталоге услуг. Клиенты ProviderCo заказывают единицы хранения и вычисления, и запрашивают их предоставление на основе опубликованного шаблона. Хотя потребители должны платить за все что они заказали, они получают скидку на те единицы, которые были заказаны, но не предоставлены. ConsumerCo является недавно созданной производственной компанией с быстро растущей клиентской базой. ConsumerCo имеет упрочившийся IT-департамент и центр обработки данных, предназначенный для 50 серверов который и в настоящее время не имеет достаточных мощностей. Управление ConsumerCo решило увеличить использование онлайн заказов со своими поставщиками и клиентами, но они не хотят вкладывать средства в расширение своего центра обработки данных.Таким образом, они решили получать единицы хранения, сетевые и вычислительные ресурсы из публичного облака, чтобы связать эти онлайн ресурсы веб сервиса с уже имеющимися в их центрах обработки данных. Первый шаг ConsumerCo в том, чтобы установить взаимоотношения с ProviderCo, поставщиком инфраструктуры как услуги (IaaS). Бизнес-менеджер ConsumerCo связывает IT департамент с порталом облачных услуг ProviderCo, открывает аккаунт/счет для ConsumerCo с помощью интерфейса каталога услуг, и регистрирует три роли ConsumerCo как уполномоченных запрашивать ресурсы из ProviderCo в рамках аккаунта/счета ConsumerCo с помощью интерфейса менеджера безопасности. Администратор с компании ConsumerCo был отвественен за проектирование и развертывание онлайн системы управления заказами с крупнейшим поставщиком ConsumerCo. Администратор решает, что ему нужно до трех серверов, каждый с 4-мя процессорами, высокоскоростная оперативная память объемом 8 Гб и до 500 Гб дискового пространства. Он использует интерфейсы менеджера безопасности и сервиса для взаимодействия с ProviderCo, проходит аутентификацию по установленной роли и запрашивает ресурсы. ProviderCo предлагает ConsumerCo контракт, с которым Администратор соглашается. Администратор запрашивает, чтобы все ресурсы быть 13 Обеспечение ресурсами Развертывание виртуального образа Изменение объема/мощности ресурсов Отчетность по договору Составление счета по договору Обновление контракта Управление взаимоотношениями Прекращение контракта предоставлены немедленно. В то же время, он указывает шаблон услуги/сервиса, который определяет тип операционной системы, некоторое развернутое программное обеспечение и хранилище данных. Развертывание образа происходит при предоставлении ресурсов. Используя на портале интерфейс менеджера конфигурации, Администратор получает доступ к серверам и настраивает их использовать сети и ресурсы для хранения/хранилище из ProviderCo и подключается к системе управления запасами/инвентарем в центре обработки данных в ConsumerCo. Затем он добавляет онлайн сервис к системе управления соглашением об уровне предоставления услуг (SLA) ConsumerCo. Используя интерфейс сервис контроля, система управления SLA ConsumerCo следит за работой веб-службы на основе SLA, в том числе отслеживая использование процессора и неисправности страниц памяти. Система управления запрашивает деактивацию двух серверов используя интерфейс менеджера изменений, при низком уровне использования системы в сравнении с ожидаемой.Позже, при обнаружения повышения нагрузки, система управления делает запрос на включение дополнительного сервера. В конце первого месяца, бизнес-менеджер ConsumerCo запрашивает отчет по договору/контракту от ProviderCo. Он получает отчет через интерфейс сервис менеджера, который показывает первоначальное развертывание и последующее разъединение/деактивацию и возобновление подачи ресурсов. Отчет показывает, что система обычно использует два сервера в течение дня и только один сервер ночью. В течение недели перед концом квартала, все три сервер зачастую были активны в течение дня. Позже он получает счет за пять предусмотренных вычислительных блоков и пять предусмотренных единиц хранения, на $ 5,00 за терабайт в день и $ 0,13 в час за работу процессора. Управление ConsumerCo из-за увеличения компании решает расширить объем их первоначального договора. Бизнесменеджер ConsumerCo связывается с ProviderCo и увеличивает аккаунт/счет на дополнительных 25 вычислительных блоков и 25 единиц хранения. Он также добавляет три дополнительных инженера на аккаунт/счет, в результате чего в общей сложности получается шесть уполномоченных ролей, которые могут запросить контракты и настройки ресурсов. Рынок для продуктов ConsumerCo терпит крах. Администратор расторгает договор с ProviderCo, что освобождает серверы и связанные с ними хранилища. Бизнесменеджер ConsumerCo прекращает взаимоотношения с ProviderCo, которые удаляют роли доступа и направляет окончательный счет в ConsumerCo. 5 Эталонная архитектура облачных сервисов 14 Седьмой раздел рассказал о жизненном цикле, приведя в пример некоторые функциональные интерфейсы, которые потребители должны установить с поставщиками облачных сервисов. В данном разделе представлена концептуальная эталонная архитектура облачных сервисов (рисунок 7), который описывает такие ключевые компоненты, как действующие лица/стороны, интерфейсы, артефакты данных и профили, а также взаимосвязь между этими компонентами. Рисунок 7 – Эталонная архитектура облачных сервисов 5.1 Действующие стороны Архитектура имеет три основные действующие стороны: поставщик/провайдер облачных услуг, потребитель облачных услуг и разработчик облачных услуг. Организация может одновременно играть роли в любой комбинации из этих действующих сторон. Поставщик/провайдер облачных услуг делает услуги доступными для потребителей облачных сервисов по договорной стоимости и уровню обслуживания. Эти услуги могут быть любого типа и сложности. Поставщик управляет технической инфраструктурой, необходимой для предоставления услуг и обеспечивает выдачу накладной и другие отчеты для потребителей. Потребитель облачных услуг представляет организацию или частные лица (частное лицо), которые заключают договор на оказание услуг с провайдерами облачных сервисов, а затем использовать эти услуги. Потребителем облачных услуг может быть другое облако, которое является поставщиком для других потребителей. Потребитель ответственен за выбор соответствующих услуг, за оплату, а также за администрирование 15 необходимое для использования этих услуг, такое как управление, учетными записями пользователей. Разработчик облачных услуг разрабатывает и реализует компоненты сервиса. Разработчик описывает услуги в шаблоне сервиса. Разработчик взаимодействует с поставщиком облачных услуг для развертывания компонентов сервиса, на основе описанных в шаблонах, которые поставщик может настроить, прежде чем устанавливать их в качестве предлагаемых услуг. 5.2 Интерфейсы и артефакты данных Интерфейс провайдера/поставщика определяет, как разработчик и потребитель взаимодействует с поставщиком. Эта архитектура различает конечные точки служб, которые принимают (и отвечают) сообщения через протокол, основанный на какой-либо схеме обмена сообщениями (функциональные интерфейсы) и элементов данных и операций, которые может поддерживать интерфейс (артефакты данных). Интерфейс включает в себя как функциональные интерфейсы и так артефакты данных. Функциональные интерфейсы, такие как каталог услуг и менеджер сервиса, являются программными интерфейсами (например, API(Интерфейс программирования приложений)). Через эти интерфейсы, разработчики и потребители взаимодействуют с провайдерами для запроса, развертывания, администрирования и использования услуг. Примеры возможных функциональных интерфейсов: Каталог услуг, с помощью которого услуги предлагаются, запрашиваются и управляются; Менеджер безопасности, с помощью которого управляются аспекты облака связанные с безопасностью; Менеджер сервиса, с помощью которого экземпляры развернутых услуг управляются и модифицируются. Артефакты данных обмениваются через функциональные интерфейсы. В данном контексте определение артефактов данных описывает семантическое содержание и специфический формат. Примеры типов артефактов данных включают запросы на обслуживание/услуги, соглашения об уровне предоставления услуги (SLA) и другие договоры, шаблоны услуг, предлагаемые услуги и образы содержащие приложения. Например, настраиваемые шаблоны контракта, который включает в себя запрос потребителя, соглашение об уровне предоставления услуги, и необходимые требования безопасности для поддержки интерфейса каталога услуг. Соглашения об уровне предоставления услуги, требования безопасности и спецификация ресурсов используются для построения предложений. 5.3 Профили DMTF 16 Профили DMTF нормативные специализации или расширения интерфейсов и артефактов или их комбинации, которые могут быть полезны в решении некоторых ситуаций, представляющиеся интересными для менеджеров безопасности или управляющим по составлению счета/накладной по контракту. Профили можно использовать для упрощения взаимодействия и для потенциально сложных определений и переговоров/согласований, нужных для запросов, управления и использования услуг. Профиль может также уточнить использование определенных стандартов, которые являются полезными в целевой среде профиля и сценариях использования. Профиль представляет собой вид интерфейса поставщика. 6 Следующие шаги В этом разделе описываются ожидаемые результаты и альянсы/союзы Открытого Инкубатора Облачных Стандартов. 6.1 Ожидаемые результаты Рисунок 8 описывает рамки/сферу инкубатора и ожидаемые результаты. Ожидаемые результаты Фазы 1 - эталонная архитектура, систематика, сценарии/варианты использования, приоритеты, представление от поставщиков, и существующие стандарты и инициативы - будут проанализированы, для доставки/выпуска одного или нескольких информационных документов спецификации интерфейсов поставщика облачных услуг, которые будет основой для развития будущего облачного стандарта. Эти документы будут описывать функциональные интерфейсы, протоколы, операции, обеспечение безопасностью и артефактов данных.Ожидаемые результаты Фазы 2 - рекомендации для каждого стандарта, который будет включать пробелы и дублирование, а также абстрактные сценарии использования (сценарии использования, которые описывают один или более ситуации бизнеса), применимые к суб-домену каждого стандарта. 17 Рисунок 8 – Процессы и ожидаемые результаты Открытого Инкубатора Облачных Стандартов 6.2 Альянсы/союзы DMTF дорожит работой с аффилированными организациями промышленности такими как Open Grid Forum, Cloud Security Alliance, Tele Management Forum (TMF), Storage Networking Industry Association (SNIA), и Национальным Институтом стандартов и технологий (NIST). DMTF также установила официальные синергетические отношения с другими органами по стандартизации. Целью этих партнерств является обеспечение взаимной выгоды организациям и DMTF. Альянсы играют важную роль в оказании помощи DMTF, для обеспечения единого представления инициатив по управлению. Например, SNIA выпустила спецификацию интерфейса для облачных систем хранения данных. Открытый Инкубатор Облачных Стандартов будет не только использовать эти работы, но и сотрудничать с SNIA для обеспечения единых стандартов. Инкубатор планирует использовать существующие стандарты DMTF в том числе открытый стандарт для хранения и распространения виртуальных машин (OVF), типовую информационную модель (CIM), объединение баз данных управления конфигурации (CMDBf), упрощение языковой политики CIM (CIM-SPL), профили виртуализации DMTF, а также стандарты от аффилированных промышленных групп. 18 Рисунок 9 – Альянсы Поскольку цель инкубатора заключается в разработке информации о технических характеристиках на управление совместимыми облаками, объем работ довольно большой. Сценарии использования, эталонная архитектура, жизненный цикл описанные в этом справочном документе будут обязательно распространяется на тематические области за рамками DMTF. Таким образом, ожидается, что альянсы DMTF (рисунок 9) будут использованы для создания решений по управлению совместимыми облаками. Разработка стандарта является по своей сути процессом сотрудничества. Команда инкубатора ожидает, что сотрудничество позволит использовать данный опыт не только в среди компаний, представленных в Открытом Инкубаторе Облачных Стандартов, но и в обществе в целом. 19 Библиография [1] NIST Definition of Cloud Computing, http://csrc.nist.gov/groups/SNS/cloud-computing/cloud- def-v15.doc [2] DMTF DSP0243, Open Virtualization Format Specification 1.0, http://www.dmtf.org/standards/published_documents/DSP0243_1.0.pdf 20
