ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

Информационные технологии

интерфейс управления

ОБЛАЧНЫМИ ДАННЫМИ (CDMI)

ISO/IEC 17826:2012 Information technology Cloud Data Management Interface (CDMI)

(IDT)

Издание официальное

Москва

Стандартинформ

2015

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО «ИАВЦ») на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2015 г. № 467-ст

4    Настоящий стандарт идентичен международному стандарту ИСО/МЭК 17826:2012 «Информационные технологии. Интерфейс управления облачными данными (CDMI)» (ISO/IEC 17826:2012 «Information technology - Cloud Data Management Interface (CDMI)»).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок - в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2015

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

ГОСТ Р ИСО/МЭК 17826-2015

5 Обзор облачного хранения

5.1    Введение

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

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

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

5.2    Что такое облачное хранение?

Использование термина «облако» связано с тем, что эти новые модели произошли от графического представления архитектур, использующих облако как символ сети. Облако абстрактно обозначает связь любого компьютера сети с любым другим компьютером. В этой абстракции сетевое соединение в облаке не определяет, как именно оно устанавливается.

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

Таким образом, облачное хранение есть предоставление по запросу виртуализированного хранилища. Для обозначения этого используется формальный термин «Хранение данных как служба» (Data storage as a Service, DaaS).

5.3    Хранение данных как служба

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

Важная часть реализации любой системы DaaS - поддержка унаследованных клиентов. Эта поддержка включена в действующие стандартные протоколы, такие как iSCSI (и другие) для блочного и CIFS/NFS или WebDAV для файлового и сетевого хранения, как показано на рисунке 1.

Рисунок 1 - Существующие стандарты интерфейсов хранилищ данных

5

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

Управление таким хранилищем в случае стандартных интерфейсов хранения данных обычно осуществляется через API или (чаще) через пользовательский интерфейс администратора в браузере по выделенному каналу связи. Этот интерфейс по выделенному каналу связи может использоваться для запуска других служб данных (например, создания моментального снимка состояния или клонирования).

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

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

Рисунок 2 - Интерфейсы хранилища для данных клиента объектного хранилища

5.4 Управление данными для облачного хранения

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

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

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

ГОСТ Р ИСО/МЭК 17826-2015

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

Метаданные системы хранения формируются/интерпретируются реализацией облака и низкоуровневыми функциями хранилища (например, статистика изменения и доступа, управление доступом). Подробнее о поддержке метаданных системы хранения см. 16.3.

Метаданные системы данных интерпретируются реализацией облака как требования к данным, которые управляют операциями соответствующих служб данных. Это может относиться к объединению данных в контейнере или к индивидуальным объектам данных, если реализация поддерживает такую детализацию. Подробнее о поддержке метаданных системы данных см. 16.4.

5.5 Управление данными и контейнерами

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

Поэтому использование метаданных расширяется от применения к индивидуальным элементам данных на контейнеры данных. Таким образом, любые данные, помещенные в контейнер, наследуют метаданные системы данных контейнера, в который они помещаются. При создании нового контейнера внутри существующего контейнера, новый контейнер наследует настройки метаданных родительского контейнера. После создания элемента данных, отдельные метаданные системы данных могут быть перекрыты метаданными, заданными на уровне контейнера или индивидуального элемента данных.

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

Эталонная модель облачного хранилища показана на рисунке 3. Клиенты, выступающие в роли пользователей интерфейса хранения данных
Управление облачным хранилищем может быть самостоятельным или частью общего управления облачными вычислениями Клиенты, выступающие в роли управляющих данными и/или хранением
Клиент управления данными/хранилищем Информационные 1-1 сервисы (в будущем) Рисунок 3 - Эталонная модель облачного хранилища

5.6 Эталонная модель интерфейсов облачного хранения

Клиенты могут находиться внутри облачного хранилища (т. е. предоставлять облаку хранение    Клиент

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

потребление) или вне    хранилища

облака (то есть только потреблять ресурсы)

7

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

Службы данных применяются к индивидуальным элементам данных в соответствии с метаданными системы данных. Метаданные определяют требования к данным на основании индивидуальных элементов или групп элементов (контейнеров).

5.7 Интерфейс управления облачными данными

Интерфейс управления облачными данными (CDMI™), показанный на рисунке 3, может использоваться для создания, доступа, изменения или удаления объектов в облаке. Функции CDMI позволяют:

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

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

-    устанавливать метаданные для контейнеров и объектов данных в них.

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

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

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

Настоящий стандарт использует принципы REST в разработке интерфейса, насколько это возможно (см. [REST]).

CDMI определяет как средства для управления данными, так и средства для сохранения и получения данных. Средства, которыми осуществляется сохранение и получение данных, обозначаются как путь к данным. Средства управления данными обозначаются как путь к управлению. CDMI описывает как путь к данным, так и путь к управлению.

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

Метаданные контейнера используются для конфигурирования требований к данным хранилища, предъявляемых контейнером посредством экспортируемых протоколы (например, блочный или файловый протокол). Для реализаций, основанных на файловой системе для блочного хранения данных (например, iSCSI), контейнер CDMI предоставляет полезную абстракцию для представления метаданных системы данных для данных и структур, управляющих экспортированными протоколами.

Реализация облака может также поддерживать домены, позволяющие сопоставлять административные права владения хранимым объектам. Домены (наряду с другими возможностями) позволяют стандарту:

-    определять соответствие пользовательских полномочий принципалами из списков контроля доступа (ACL);

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

-    делегировать авторизацию пользователей внешней системе авторизации пользователей (например, LDAP или Active Directory).

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

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

ГОСТ Р ИСО/МЭК 17826-2015

Например, в 5.10, настоящий стандарт указывает, что «каждая облачная система хранения должна обеспечивать доступ к хранимым объектам по Ю». Данное требование должно пониматься в контексте, что у функции доступа к ID объекта есть предусловие - наличие опции cdmi_object_access_by_ID.

5.8 Объектная модель для CDMI

Модель для CDMI показана на рисунке 4

Рисунок 4 - Модель объекта CDMI

В таблице 3 перечислены пять типов ресурсов. Содержание каждой конкретной операции зависит от типа ресурса.

Таблица 3 - Типы ресурсов в модели

Тип ресурса Описание Ссылка Объекты данных Объекты данных служат для хранения значений и предоставляют функциональность аналогичную файлам в файловой системе. См. раздел. 8 Объекты- контейнеры Контейнер имеет неотрицательное количество дочерних объектов, но не хранит значений. Их функциональность аналогична папкам файловой системы. См. раздел 9 Объекты- домены Домены выражают административные группы пользователей для их аутентификации и учета использования ресурсов. См. раздел 10 Объекты- очереди Очереди хранят неотрицательное число значений, доступ к которым осуществляется по принципу "первый пришел - первый ушел". См. раздел 11 Объекты опций Объекты опций описывают функциональность, реализованную сервером CDMI и используются клиентом для обнаружения поддерживаемой функциональности См. раздел 12

Для операций хранения данных клиенту интерфейса достаточно информации о контейнерах и объектах данных. Реализации путей к данным должны поддерживать хотя бы один уровень контейнеров (см. 5.5). С использованием объектной модели CDMI (см. рисунок 4) клиент может отослать запрос PUT через CDMI (см. 5.6) с URI нового контейнера и создать новый контейнер с определенным именем. Метаданные контейнера опциональны и выражаются набором пар имя-значение. После создания контейнера клиент может отправить запрос PUT для создания объекта данных внутри нового контейнера. Последующий запрос GET выбирает объект данных, включая поле значения.

Определены также объекты очереди (см. рисунок 4) со специальными свойствами для упорядоченного, в дисциплине FIFO, создания и удаления значений. Подробнее см. в разделе 11.

CDMI определяет два пространства имен, которые могут использоваться для доступа к хранимым объектам: плоское пространство идентификаторов объектов и иерархическое пространство имен-путей. Поддержка доступа к объекту по ID выражается глобальной опцией cdmi_object_access_by_ID, а поддержка иерархических путей определяется опцией контейнера cdmi_create_dataobject, находящейся в корневом или вложенном контейнере.

Объекты создаются по ID выполнением команды HTTP POST с определенным URI, обозначаемым как /cdmi_objectid/ (см. 9.8). После создания клиенты могут объект командой PUT с указанием ID объекта, присвоенный сервером CDMI, используя /cdmi_objectid/ URI (см. 8.6). Этот URI используется также для извлечения и удаления объектов по ID.

9

Объекты создаются по имени выполнением HTTP PUT с указанием URI пути (см. 8.2). После создания, объекты можно модифицировать, выполняя команды PUT с указанием пути к объекту, заданному клиентом (см. 8.6). То же самый URI используется для извлечения и удаления объектов.

CDMI определяет механизмы, позволяющие сопоставить путь в иерархическом пространстве объекту, имеющему лишь Ю, а также позволяющие удалить путь, оставив только ID, у объекта, имеющего и путь, и ID. Это осуществляется с использованием модификатора перемещения для операций PUT или POST, как показано на рисунок 5.

PUT /name, {"move”: 7cdmi_objectid/<object ID>/”}

Рисунок 5 - Диаграмма переходов объекта: добавление имени и удаление имени 5.9 Метаданные CDMI

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

Метаданные HTTP - это метаданные, связанные с использованием протокола HTTP (например, Content-Length, Content-Type и др.). Метаданные HTTP не связаны сданным международным стандартом, но их необходимо обсудить для объяснения, как CDMI использует стандарт HTTP.

Метаданные системы данных CDMI, пользовательские метаданные и метаданные системы хранения определятся в форме пар имя-значение. Метаданные системы данных, определенные производителем, должны начинаться с обращенного доменного имени производителя.

Метаданные системы данных - это метаданные, определяемые клиентом CDMI, они входят в состав объекта. Метаданные системы данных абстрактно определяют требования к данным, связанные со службами данных, предоставляемыми облачным хранилищем.

Пользовательские метаданные состоят из определенных клиентом строк, массивов и объектов в нотации JSON, сохраненных в поле метаданных. Пространство имен для пользовательских метаданных является самоуправляемым (например, использует обращенное имя домена), причем имена пользовательских метаданных не должны начинаться с префикса «cdmi_».

Метаданные системы хранения - это метаданные, сгенерированные службами хранения системы (например, время создания или размер) для предоставления необходимой информации клиенту CDMI.

Матрица создания и использования метаданных системы хранения приведена в табл 4.

Таблица 4 - Создание-использование метаданных системы хранения

Тип метаданных Созданные пользователем Созданные системой Используемые пользователем Пользовательские метаданные Метаданные системы хранения Используемые системой Метаданные системы данных N/A

5.10 ID объекта

Каждому объекту, хранимому в CDMI-совместимой системе, в момент создания ставится в соответствие глобально-уникальный идентификатор объекта (ID). ID объекта CDMI - это строка, на которую накладываются требования, обеспечивающие ее правильное создание и уникальность. Каждая реализация CDMI способна создавать уникальные идентификаторы, не конфликтуя с другими реализациями.

Каждая облачная система хранения должна предоставлять доступ к хранимым объектам по ID посредством добавления ID объекта к URI корневого контейнера. Если объект данных «MyDataObject. txt» имеет ID «00006FFD001001CCE3B2B4F602032653», следующая пара URI дает доступ к одному и тому же объекту данных:

http://cloud.example.com/root/MyDataObject.txt

http://cloud.example.com/root/cdmi_objectid/00006FFD001001CCE3B2B4F602032653

ГОСТ Р ИСО/МЭК 17826-2015

Если поддерживается работа с контейнерами, они также должны быть доступными по ГО объекта. Если контейнер «MyContaineD> имеет ГО объекта «00006FFD0010AA33D8CEF9711E0835CA», следующие пары URI дают доступ к одному и тому же объекту данных: http://cloud.example.com/MyContainer/

http://cloud.example.com/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA/

http://cloud.example.com/MyContainer/MyDataObject.txt

http://doud.example.eom/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA/MyDataObject.bct

5.11 Формат идентификатора объекта CDMI

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

0 1 2 3 4 5 6 7 8 9 10 38 39 Зарезервировано (ноль) Номер организации Зарезервировано (ноль) Длина CRC Непрозрачные данные

Рисунок 6 - Формат ID объекта

Поля, показанные на рисунке 6, определены следующим образом:

-    Зарезервированные байты должны быть нулевыми.

Поле номера организации - это код, присвоенный организации, чья реализация создает ГО объекта, в спецификации SNMP, в сетевом порядке байтов. См. RFC 2578 и http://www.iana.org/assignments/ enterprise-numbers. Код 0 зарезервирован.

Байт со смещением 5 должен содержать длину ГО в байтах.

Поле CRC должно содержать двухбайтовый (16-битный) CRC в сетевом порядке байтов. Это поле позволяет контролировать целостность ГО объекта. Поле CRC должно заполняться выполнением алгоритма (см. [CRC]) по всем байтам ГО объекта, определенным полем Длина, при обнуленном поле CRC. Вычисление CRC определяется набором параметров:

-    Name : «CRC-16»,

-    Width : 16,

-    Poly : 0x8005,

-    Init: 0x0000,

-    Refln : True,

-    RefOut: True,

-    XorOut: 0x0000, и

-    Check: 0xBB3D.

Эта функция возвращает 16-битный CRC по полиному 0x8005, обращенным входом и обращенным результатом. Алгоритм вычисления CRC-16 определен в [CRC],

-    Непрозрачные данные ГО каждого объекта должны быть уникальными в пределах одного номера организации.

Исходный формат объекта ГО - бинарный. При необходимости, например при включении в URI или строки JSON, текстовое представление ГО объекта должно кодироваться на основе правил base 16, описанных в [RFC 4648] и не должно учитывать регистр.

5.12 Безопасность

В контексте CDMI безопасность относится к защитным мерам, применяемым при управлении и доступе к данным и хранилищу. В частности, система безопасности должна решать следующие задачи:

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

-    предоставление механизма, позволяющего CDMI клиентам и серверам доказывать свою идентичность;

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

11

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

-    предоставление механизмов защиты данных в фоновом режиме;

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

-    предоставление механизма для определения набора опций безопасности конкретной реализации.

Меры безопасности, включенные в CDMI, можно описать как:

-    безопасная передача;

-    аутентификация пользователей и сущностей;

-    авторизация и контроль доступа;

-    целостность данных;

-    очистка данных и среды;

-    удерживание данных;

-    защита от вредоносных действий;

-    шифрование данных в фоновом режиме;

-    опции безопасности.

За исключением безопасности передачи и опций безопасности, которые обязательны для реализации, остальные меры безопасности существенно зависят от конкретной реализации.

Если безопасность является важной задачей, CDMI клиент должен начинать работу с серии поисков опций безопасности (см. подпункт 12.1.1) для определения точной природы возможных мер безопасности. Основываясь на значениях опций и оценке рисков, принимается решение о том, может ли использоваться данный сервер CDMI. Это особенно важно, если в облаке будет храниться ценные данные или данные ограниченного доступа, и требуется определенная защита (шифрование) или особая обработка данных (например, опция записи и просмотра всех выполняемых действий).

HTTP является обязательным механизмом передачи данных, a HTTP над TLS (то есть, HTTPS) является механизмом, используемым для безопасного взаимодействия между клиентами и сервером CDMI. Для обеспечения безопасности и совместимости, все реализации CDMI должны поддерживать протокол безопасности транспортного уровня (Transport Layer Security, TLS) как описано в приложении А, но его использование клиентами и сервером CDMI опционально.

5.13 Необходимая поддержка HTTP

5.13.1    Требования поддержки RFC 2616

Совместимая реализация CDMI должна также включать реализацию RFC2616 (см. [RFC 2616]) (т.е., HTTP 1.1). Перечисленные ниже примеры описывают некоторые части RFC 2616, которые должны поддерживаться, но этот список не является исчерпывающим.

5.13.2    Согласование типа содержимого

Для операций CDMI используются типы медиа CDMI объектов, определенные в [RFC 6208].

Клиент может опционально предоставлять заголовок HTTP Accept согласно 14.1 RFC 2616. Если клиент требует, чтобы в ответе содержался определенный тип медиа CDMI, соответствующий тип должен быть указан в заголовке Accept. Иначе, заголовок может содержать «*/*» или список типов, или быть опущен.

Если в сообщении-запросе присутствует тело, клиент должен включать заголовок Content-Type согласно пункту 14.17 RFC 2616. Если в таком случае клиент не предоставляет заголовок Content-Type содержимого или тип медиа в заголовке Content-Type не соответствует существующему типу ресурса, сервер должен вернуть код состояния HTTP 400 Bad Request.

Если в сообщении-ответе присутствует тело, сервер должен предоставить заголовок Content-Type.

Настоящий стандарт допускает дальнейшие согласования типа содержимого (например, в 9.3 отсутствие заголовка Content-Type несет особую информацию).

5.13.3    Поддержка диапазона

Сервер должен поддерживать заголовки HTTP Range и ответы с частичным содержимым (см. 14.16 RFC 2616).

5.13.4    Экранирование в URI

Ко всем строкам, использованным в URI, должно применяться экранирование зарезервированных символов знаком процента (%), определенное в RFC 3986. Это касается имен полей, предоставленных пользователем, имен метаданных, имен объектов, имен контейнеров и имен доменов, использованных в URI.

12

ГОСТ Р ИСО/МЭК 17826-2015

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

Пример - Клиент, получающий метаданные объекта «@user» из контейнера «@MyContainer», должен выполнить следующий запрос:

GET /%40MyContainer/?objectName;metadata:%40user НТТР/1.1 Host: cloud.example.com Accept: application/cdmi-container X- CDMI-Specifica tion- Version: 1.0.2 В ответ должно быть получено:

НТТР/1.1 200 ОК

Content-Type: application/cdmi-container X-CDMI-Specification-Version: 1.0.2 {

«objectName»: «@MyContainer»,

«metadata»: {

«@user»: «test»

}

}

5.13.5 Использование URI

Формат и синтаксис URI определяются RFC 3986.

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

Все URI в данном международном являются относительными (relative) URI, заданными относительно корневых URI, если не сказано иное. Таким образом, в качестве алгоритма разрешения URI используется алгоритм из пункта 5.2 RFC 3986.

В таблице 5 приведено разрешение относительного URI по корневому URI.

Таблица 5 - Разрешение относительного URI по корневому URI

Корневой URI + Относительный URI => Разрешенный URI http://cloud.example.com/ cdmi object/testObject http://cloud.example.com/cdmi_object/testObject http://cloud.example.com/ /cd miobject/testObject http://cloud.example.com/cdmi_object/testObject http://cloud.example.com/p1/ cdmiobject/testObject http://cloud.example.com/p1/cdmi_object/testObject http://cloud.example.com/p1/ /cdmi_object/testObject http://cloud.example.com/cdmi_object/testObject http://cloud.example.com/p1/p2/ cdmi_object/testObject http://cloud.example.com/p1/p2/cdmi_object/testObject http://cloud.example.com/p1/p2/ /cdmi_object/testObject http://cloud.example.com/cdmi_object/testObject

Настоящий стандарт не накладывает ограничений на корневые и относительные URI. Все примеры, приведенные в таблицу 5, допустимы, используя корневой URI http://cloud.example.com/ и возвращая ссылки на абсолютные пути, как показано во второй строке таблицу 5.

5.13.6 Зарезервированные символы

Имена объектов данных CDMI, контейнеров, очередей, доменов и объектов опций не могут содержать символы «/» и «?», так как они зарезервированы как разделители.

5.14 Представление времени

Если не указано иное, все значения даты/времени даются согласно расширенному представлению ИСО 8601:2004 (YYYY-MM-DDThh:mm:ss.ssssssZ). Должна быть указана полная точность, разделитель долей секунды «.» (точка), должен быть включен индикатор пояса UTC Z UTC, и все отметки времени должны быть в часовом поясе UTC. Представление YYYY-MM-DDT24:00:00.000000Z не следует использовать, вместо этого следует использовать представление YYYY-MM-DDT00:00:00.000000Z.

Если не указано иное, все интервалы даты/времени должны быть в формате начальная дата/ конечная дата в соответствии со стандартом ISO 8601:2004 (YYYY-MM-DDThh:mm:ss.ssssssZ/YYYY-MM-DDThh:mm:ss.ssssssZ). Конечная дата должна быть не раньше начальной даты. Должна быть указана полная точность, разделитель долей секунды «.» (точка), должен быть включен индикатор пояса UTC Z UTC, и все отметки времени должны быть в часовом поясе UTC. Представление YYYY-MM-DDT24:00:00.000000Z не следует использовать, вместо этого следует использовать представление YYYY-MM-DDT00:00:00.000000Z.

13

5.15 Обратная совместимость

5.15.1    Кодировка значений для передачи

Стандарт CDMI версии 1.0.1 ввел концепцию кодировки значений для передачи, чтобы обеспечить опции хранения и получения произвольных бинарных данных через операции с типом содержимого CDMI. Объекты данных, созданные клиентами CDM11.0 посредством операций стипом содержимого CDMI, должны использовать кодировку «utf-8», а объекты, созданные другими операциями, должны использовать кодировку «base64».

Значения полей объектов данных в кодировке base64 не должны быть доступны клиентам CDMI

1.0 через операции с типом содержимого CDMI. Попытка чтения значения таких объектов должна возвращать таким клиентам пустой результат («»). Клиенты CDMI 1.0 могут выявить такую ситуацию: в этом случае метаданные cdmi_size не равно 0, а значение поля пустое.

5.15.2    Опции экспорта контейнера

CDMI версии 1.0.2 упорядочивает имена опций, которые использует клиентом для определения, может ли контейнер экспортироваться через различные протоколы. Следующие имена опций экспорта контейнера более недействительны:

-    cdmi_cifs_export,

-    cdmi_nfs_export,

-    cdmi_iscsi_export,

-    cdmi_occi_export.

6 Обычные операции

6.1    Обзор

Все примеры, приведенные в настоящем стандарте, не являются нормативными.

Данный раздел включает примеры следующих типизованных операций CDMI:

-    определение опций провайдера облачного хранилища (см. 6.2),

-    создание нового контейнера (см. 6.3),

-    создание нового объекта данных (см. 6.4),

-    получение списка содержимого контейнера (см. 6.5),

-    чтение содержимого объекта данных (см. 6.6),

-    чтение только значения объекта данных (см. 6.7),

-    удаление объекта данных (см. 6.8).

6.2    Определение опций провайдера облачного хранения

Пример - Выполнение GET к URI, по которому сервер публикует перечень опций:

GET /cdmicapabilities/ НТТР/1.1 Host: cloud.example.com Accept: application/cdmi-capability X-CDMI-Specification-Version: 1.0.2 Будет получен следующий ответ.

НТТР/1.1 200 ОК

Content-Type: application/cdmi-capability X-CDMI-Specification-Version: 1.0.2 {

«objectType»: «application/cdmi-capability»,

«objectID» : «00007E7F0010CEC234AD9E3EBFE9531D»,

«objectName»: «cdmi capabilities/»,

«parentURI»:«/»,

«parentID»: «00007E7F0010DCECC805FB6D195DDBCB»,

«capabilities»: {

«cdmi_domains»: «true»,

«cdmi_export_nfs»: «true»,

«cdmi_export_webdav»: «true»,

«cdmi_export_iscsi»: «true»,

«cdmijqueues»: «true»,

ГОСТ Р ИСО/МЭК 17826-2015

Содержание

1    Область применения....................................................................................................................................1

2    Нормативные ссылки....................................................................................................................................1

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

4    Соглашения...................................................................................................................................................3

4.1    Формат интерфейса...............................................................................................................................3

4.2    Типографские соглашения....................................................................................................................4

4.3    Требования к телу сообщений запросов и ответов.............................................................................4

4.4    Требования к ключевым словам...........................................................................................................4

5    Обзор облачного хранения..........................................................................................................................5

5.1    Введение.................................................................................................................................................5

5.2    Что такое облачное хранение?.............................................................................................................5

5.3    Хранение данных как служба................................................................................................................5

5.4    Управление данными для облачного хранения...................................................................................6

5.5    Управление данными и контейнерами.................................................................................................7

5.6    Эталонная модель интерфейсов облачного хранения.......................................................................7

5.7    Интерфейс управления облачными данными.....................................................................................8

5.8    Объектная модель для CDMI................................................................................................................9

5.9    Метаданные CDMI................................................................................................................................10

5.10    ID объекта...........................................................................................................................................10

5.11    Формат идентификатора объекта CDMI...........................................................................................11

5.12    Безопасность......................................................................................................................................11

5.13    Необходимая поддержка HTTP.........................................................................................................12

5.14    Представление времени....................................................................................................................13

5.15    Обратная совместимость..................................................................................................................14

6    Обычные операции.....................................................................................................................................14

6.1    Обзор.....................................................................................................................................................14

6.2    Определение опций провайдера облачного хранения.....................................................................14

6.3    Создание нового контейнера..............................................................................................................15

6.4    Создание объекта данных в контейнере............................................................................................15

6.5    Список содержимого контейнера........................................................................................................16

6.6    Чтение содержимого объекта данных................................................................................................16

6.7    Чтение только значения объекта данных...........................................................................................17

6.8    Удаление объекта данных...................................................................................................................17

7    Стандарт интерфейса................................................................................................................................17

7.1    Коды состояния HTTP..........................................................................................................................17

7.2    Ссылки на объект.................................................................................................................................18

8    Операции с ресурсами объекта данных...................................................................................................18

8.1    Обзор.....................................................................................................................................................18

8.2 Создание объекта данных с использованием типа содержимого CDMI..........................................20

8.3 Создание объекта данных с использованием типа содержимого, отличного от CDMI..................25

8.4    Чтение объекта данных с использованием типа содержимого CDMI..............................................26

8.5    Чтение объекта данных с использованием типа содержимого, отличного от CDMI.......................30

8.6    Изменение объекта данных с использованием типа содержимого CDMI.......................................32

«cdminotification»: «true»,

«cdmi query»: «true»,

«cdmimetadatamaxsize»: «4096», «cdmimetadatamaxitems»: «1024»,

«cdmi size»: «true»,

«cdmi list children»: «true»,

«cdmi read metadata» : «true»,

«cdmi modify metadata» : «true»,

«cdmi create container»: «true»,

«cdmi delete container»: «true»

},

«childrenrange» : «0-3»,

«children»: [

«domain/»,

«container/»,

«dataobject/»,

«queue/»

]

}

6.3 Создание нового контейнера

Пример - Выполнение PUT с URI нового контейнера: PUT /MyContainer/HTTP/1.1 Host: cloud.example.com Accept: application/cdmi-container Content-Type: application/cdmi-container X- CDMI-Specifica tion- Version: 1.0.2 {

«metadata»: {

}

}

Будет получен следующий ответ.

НТТР/1.1 201 Created Content-Type: application/cdmi-container X- CDMI-Specifica tion- Version: 1.0.2 {

«objectType»: «application/cdmi-container»,

«objectID» : «00007E7F00102E230ED82694DAA975D2», «objectName»: «MyContainer/»,

«parentURI» :«/»,

«parentID» : «00007E7F0010128E42D87EE34F5A6560», «domainURI» : «/cdmi domains/MyDomain/», «capabilitiesURI»: «/cdmi capabilities/container/», «completionStatus»: «Complete»,

«metadata»: {

«cdmi size»: «0»

},

«childrenrange» :«»,

«children»: [

]

}

6.4 Создание объекта данных в контейнере

Пример - Выполнение PUT с URI нового объекта данных: PUT /MyContainer/MyDataObject.txt НТТР/1.1 Host: cloud.example.com Accept: application/cdmi-object Content-Type: application/cdmi-object X- CDMI-Specifica tion- Version: 1.0.2 {

8.7    Изменение объекта данных с использованием типа содержимого, отличного от CDMI................36

8.8    Удаление объекта данных с использованием типа содержимого CDMI..........................................37

8.9    Удаление объекта данных с использованием типа содержимого, отличного от CDMI..................38

9    Операции с ресурсами вида объект-контейнер.......................................................................................39

9.1    Обзор.....................................................................................................................................................39

9.2    Создание объекта-контейнера с использованием типа содержимого CDMI...................................41

9.3    Создание объекта-контейнера с использованием типа содержимого, отличного от CDMI...........45

9.4    Чтение объекта-контейнера с использованием типа содержимого CDMI.......................................46

9.5    Изменение объекта-контейнера с использованием типа содержимого CDMI................................50

9.6    Удаление объекта-контейнера с использованием типа содержимого CDMI...................................54

9.7    Удаление объекта-контейнера с использованием типа содержимого, отличного от CDMI...........55

9.8    Создание (POST) нового объекта данных с использованием типа содержимого CDMI................56

9.9    Создание (POST) нового объекта данных с использованием типа содержимого,

отличного от CDMI.....................................................................................................................................62

9.10    Создание (POST) нового объекта-очереди с использованием типа содержимого CDMI.............63

10    Операции с ресурсами объекта-домена.................................................................................................67

10.1    Обзор...................................................................................................................................................67

10.2    Создание объекта-домена с использованием типа содержимого CDMI.......................................73

10.3    Чтение объекта-домена с использованием типа содержимого CDMI............................................76

10.4    Изменение объекта-домена с использованием типа содержимого CDMI.....................................78

10.5    Удаление объекта-домена с использованием типа содержимого CDMI.......................................80

11    Операции с ресурсами объекта-очереди................................................................................................81

11.1    Обзор...................................................................................................................................................81

11.2    Создание объекта-очереди с использованием типа содержимого CDMI......................................82

11.3    Чтение объекта-очереди с использованием типа содержимого CDMI...........................................86

11.4    Изменение объекта-очереди с использованием типа содержимого CDMI....................................91

11.5    Удаление объекта-очереди с использованием типа содержимого CDMI......................................93

11.6    Добавление элемента в очередь с использованием типа содержимого CDMI.............................94

11.7    Удаление значения объекта-очереди с использованием типа    содержимого CDMI......................97

12    Операции с ресурсами объекта-опции...................................................................................................98

12.1    Обзор...................................................................................................................................................98

12.2    Чтение опций объекта с использованием типа содержимого CDMI............................................106

13    Экспортируемые протоколы...................................................................................................................109

13.1    Обзор.................................................................................................................................................109

13.2    Структура экспортируемого протокола............................................................................................111

13.3    Обнаружение и подключение контейнеров через сторонние протоколы....................................115

13.4    Экспортный протокол NFS...............................................................................................................115

13.5    Экспортный протокол CIFS..............................................................................................................117

13.6    Экспортный протокол OCCI.............................................................................................................117

13.7    Модификация экспорта iSCSI.........................................................................................................118

13.8    Экспортный протокол WebDAV.......................................................................................................119

14    Снимки состояния...................................................................................................................................119

15    Сериализация/ десериализация...........................................................................................................120

15.1 Обзор.................................................................................................................................................120

ГОСТ Р ИСО/МЭК 17826-2015

15.2    Экспорт сериализованных данных.................................................................................................120

15.3    Импорт сериализованных данных..................................................................................................121

16    Метаданные............................................................................................................................................123

16.1    Управление доступом......................................................................................................................123

16.2    Поддержка пользовательских метаданных....................................................................................129

16.3    Поддержка метаданных системы хранения...................................................................................129

16.4    Поддержка метаданных системы данных......................................................................................129

16.5    Поддержка метаданных, предоставленных системой данных.....................................................133

17    Управление отложенным удалением и удержанием...........................................................................134

17.1    Введение...........................................................................................................................................134

17.2    Управление отложенным удалением..............................................................................................134

17.3    Отложенное удаление CDMI...........................................................................................................135

17.4    Удержание CDMI..............................................................................................................................135

17.5    Автоудаление CDMI.........................................................................................................................137

17.6    Замечания о безопасности отложенного удаления.......................................................................137

18    Спецификация условий запросов.........................................................................................................137

18.1    Введение...........................................................................................................................................137

18.2    Примеры...........................................................................................................................................138

18.3    Выражения для запросов................................................................................................................139

19    Спецификация результатов..................................................................................................................142

19.1    Введение...........................................................................................................................................142

19.2    Примеры...........................................................................................................................................142

20    Ведение журналов событий...................................................................................................................143

20.1    Обзор.................................................................................................................................................143

20.2    Ведение журналов событий объекта..............................................................................................144

20.3    Ведение журналов событий безопасности....................................................................................144

20.4    Ведение журналов событий управления данными.......................................................................144

20.5    Очереди журналов событий...........................................................................................................144

20.6    Замечания о безопасности при ведении журналов событий........................................................146

21    Очереди уведомлений............................................................................................................................146

22    Очереди запросов..................................................................................................................................149

22.1    Обзор.................................................................................................................................................149

22.2    Расширение запроса CDMI.............................................................................................................150

Приложение А (обязательное) Безопасность передачи...........................................................................151

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам Российской    Федерации..........................................................155

Библиография..............................................................................................................................................155

V

Введение

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

Настоящий стандарт состоит из следующих разделов:

Определяет основные задачи данного документа Перечисляет ссылки на нормативные документы, связанные сданным документом

Устанавливает терминологию, используемую в данном документе Определяет формат описания интерфейсов и типографические соглашения, принятые в данном документе

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

Определяет стандартные операции с ресурсами объектов-контейнеров

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

Определяет стандартные операции с ресурсами объектов очередей

Определяет стандартные операции с ресурсами объектов-опций

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

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

Описывает стандартизированные механизмы определения подмножеств содержимого объекта CDMI

Описывает функции ведения журналов событий CDMI для функций объектов, событий безопасности, событий управления данными и очередей

Описывает, как клиенты CDMI могут эффективно обнаружить изменения системы

Описывает, как клиенты CDMI могут эффективно обнаружить, какое содержание соответствует заданному набору критериев запроса метаданных или критерию поиска по всем полям метаданных Определяет требования к обеспечению безопасной передачи данных по протоколу HTTP для передачи CDMI сообщений Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов национальным стандартам Российской Федерации

VI

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии ИНТЕРФЕЙС УПРАВЛЕНИЯ ОБЛАЧНЫМИ ДАННЫМИ (CDMI)

Information technology. Cloud Data Management Interface (CDMI)

Дата введения — 2016—06—01

1    Область применения

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

2    Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Предоставленные спецификации, не относящиеся к документам ИСО/МЭК, МЭК, ИСО и ITU, применимы лишь в контексте настоящего стандарта. Ссылка на эти документы не предоставляет им нового статуса в системе ИСО/МЭК. В частности, это не дает цитированным ссылкам статуса международного стандарта.

ИСО 3166 Коды для представления названий стран и единиц их административно-территориального деления (части 1, 2 и 3) (ISO 3166, Codes for the representation of names of countries and their subdivisions)

ИСО 4217:2008 Коды для представления валют и фондов (ISO 4217:2008, Codes for the representation of currencies and funds)

ИСО 8601:2004 Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени (ISO 8601:2004, Data elements and interchange formats - Information interchange - Representation of dates and times)

ИСО/МЭК 9594-8:2008 Информационные технологии. Взаимосвязь открытых систем. Директория. Часть 8. Структура сертификата на открытый ключ и атрибуты (ISO/IEC 9594-8:2008, Information technology-Open Systems Interconnection-The Directory: Publickey and attribute certificate frameworks)

ИСО/МЭК 14776-414 Информационные технологии. Интерфейс для малых вычислительных систем (SCSI). Часть 414. Структурная модель 4 (SAM-4) (ISO/IEC 14776-414, SCSI Architecture Model - 4 (SAM-4))

IEEE Std 1003.1, 2004, POSIX ERE Открытая группа, основные спецификации, Вып. 6 (IEEE Std 1003.1, 2004, POSIX ERE, The Open Group, Base Specifications Issue 6) - http://www.unix.org/version3/ ieee_std.html

RFC 2045 Многоцелевые расширения почты для интернета (MIME) Часть 1. Формат тела письма в интернете (RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies) - http://www.ietf.org/rfc/rfc2045.txt

RFC 2119 Ключевые слова для обозначения уровня требований в RFC (RFC 2119, Key Words for Use in RFCs to Indicate Requirement Levels) - http://tools.ietf.org/html/rfc2119

RFC 2246 Протокол TLS версии 1.0 (RFC 2246, The TLS Protocol Version 1.0) - http://www.ietf.org/ rfc/rfc2246.txt

RFC 2578 Структура управляющей информации, версия 2 (RFC 2578, Structure of Management Information Version 2, SMIv2) - http://www.ietf.org/rfc/rfc2578.txt

RFC 2616 Протокол передачи гипертекста 1.1 (RFC 2616, Hypertext Transfer Protocol - HTTP/1.1) -http://www. ietf. о rg/rfc/rfc2616 .txt

RFC 2617 Аутентификация HTTP: Базовая аутентификация доступа и аутентификация доступа с использованием дайджеста (RFC 2617, HTTP Authentication: Basic and Digest Access Authentication) -http://www. ietf. о rg/rfc/rfc2617 .txt

Издание официальное

RFC 3280 Профиль инфраструктуры открытых ключей Х.509 Интернета: сертификат и список отозванных сертификатов (RFC 3280, Internet Х.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) - http://www.ietf.org/rfc/rfc3280.txt

RFC 3530 Протокол сетевой файловой системы версии 4 (RFC 3530, Network File System (NFS) Version 4 Protocol) - http://www.ietf.org/rfc/rfc3530.txt

RFC 3720 Интерфейс для малых вычислительных систем в интернете (RFC 3720, Internet Small Computer Systems Interface, iSCSI) - http://www.ietf.org/rfc/rfc3720.txt

RFC 3986 Универсальный идентификатор ресурса: общий синтаксис (RFC 3986, Uniform Resource Identifier (URI): Generic Syntax) - http://www.ietf.org/rfc/rfc3986.txt

RFC 4346 Протокол безопасности транспортного уровня, версия 1.1 (RFC 4346, The Transport Layer Security (TLS) Protocol Version 1.1)- http://www.ietf.org/rfc/rfc4346.txt

RFC 4627 Тип медиа application/JSON для объектной нотации JavaScript (RFC 4627, The Application/ JSON Media Type for JavaScript Object Notation (JSON)) - http://www.ietf.org/rfc/rfc4627.txt

RFC 4648 Кодировки данных Basel6, Base32, и Base64 (RFC 4648, The Basel 6, Base32, and Base64 Data Encodings) http://www.ietf.org/rfc/rfc4648.txt

RFC 4918 Расширения HTTP для авторства и версионирования в сети Интернет (RFC 4918, HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)) - http://www.ietf.org/rfc/rfc4918.txt

RFC 5246 Протокол безопасности транспортного уровня, версия 1.2 (RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2) - http://www.ietf.org/rfc/rfc5246.txt

RFC 6208 Типы медиа для интерфейса управления облачными данными (RFC 6208, Cloud Data Management Interface (CDMI) Media Types) - http://www.ietf.org/rfc/rfc6208.txt

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

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1    список управления доступом (Access Control List) ACL: Постоянный список, состоящий из записей управления доступом (Access Control Entries, АСЕ), который перечисляет права доступа принципалов (пользователей и групп) к ресурсам.

3.2    CDMI™: Интерфейс управления облачными данными.

3.3    CIFS: Единая файловая система для Интернета.

3.4    облачное хранение (cloud storage): См. «Хранение данных как служба».

3.5    CRC: Циклический избыточный код.

3.6    CRUD: Создать, получить, изменить, удалить (create, retrieve, update, delete).

3.7    хранение данных как служба (data storage as a Service) DaaS: Организация сетевых служб виртуализированного хранения и доступа к данным, основанная на требовании заданного уровня службы, что снимает границы масштабируемости; является самообеспечивающимся или не требующем обеспечения и оплачивается в зависимости потребления.

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

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

3.9    целостность в конечном итоге (eventual consistency): Поведение транзактной системы, не предоставляющее гарантию связности в каждый момент времени, что улучшает доступность системы и ее устойчивость к распадению сети.

3.10    HTTP: Протокол передачи гипертекста.

3.11    инфраструктура как служба (Infrastructure as a Service) laaS: Предоставление по сети соответствующим образом сконфигурированного виртуального вычислительного окружения, основанное на запрошенном уровне услуг.

Примечание —Обычно laaS является самообеспечивающейся или не требующей обеспечения и оплачивается в зависимости потребления.

3.12    iSCSI: Интерфейс для малых вычислительных систем в интернете (см. RFC 3720).

3.13    LUN: Номер логического устройства (см. ИСО/МЭК 14776-414).

3.14    MIME: Многоцелевые расширения для почты в интернете (см. RFC 2045).

3.15    NFS: Сетевая файловая система (см. RFC 3530).

2

ГОСТ Р ИСО/МЭК 17826-2015

3.16    объект (object): Сущность, имеющая идентификатор объекта (Ю), уникальный URI, и обладающая состоянием.

Примечание — Существуют следующие типы объектов CDMI: объекты данных, контейнеры, опции, домены, очереди.

3.17    идентификатор объекта (object identifier): Глобально-уникальное значение, соотнесенное с объектом в момент его создания.

3.18    OCCI: Интерфейс открытых облачных вычислений (Open Cloud Computing Interface) (см. спецификацию OCCI).

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

Примечание — Обычно PaaS основана на laaS, является самообеспечивающейся или не требующей обеспечения и оплачивается в зависимости фактического использования.

3.20    POSIX: Интерфейс переносимой операционной системы (Portable Operating System Interface) (см. IEEE Std 1003.1).

3.21    частное облако (private cloud): Предоставление SaaS, PaaS, laaS, и/или DaaS ограниченному числу пользователей, обычно принадлежащих к одной и той же организации.

Примечание — Частные облака создаются в целях безопасности.

3.22    общественное облако (public cloud): Предоставление SaaS, PaaS, laaS, и/или DaaS потенциально неограниченному количеству пользователей.

3.23    передача репрезентативного состояния (Representational State Transfer) REST: Особый набор принципов определения, адресации и взаимодействия с ресурсами, адресуемыми посредством URI (см. [REST]).

3.24    RPO: Целевая точка восстановления (recovery point objective).

3.25    RTO: Целевое время восстановления (recovery time objective).

3.26    уровень службы (service level): Целевые показатели производительности службы.

3.27    программы как служба (Software as a Service) SaaS: Предоставление по сети доступ к приложению по запросу.

3.28    тонкое резервирование (thin provisioning): Технология распределения физической емкости тома или файловой системы по мере записи данных приложением вместо предварительного резервирования.

3.29    универсальный идентификатор ресурса (Uniform Resource Identifier) URI: Короткая последовательность символов, идентифицирующая абстрактный или физический ресурс (см. RFC 3986).

3.30    виртуализация (virtualization): Представление ресурсов, как если бы они были физическими, тогда как на самом деле они отделены от базовых физических ресурсов.

3.31    WebDAV: Набор расширений и дополнений к протоколу HTTP, поддерживающих совместную работу пользователей над редактированием файлов и управление файлами на удаленных вебсерверах (см. RFC 4918).

3.32    ХАМ: Расширяемый метод доступа (extensible Access Method) (см. INCITS 464-2010).

4 Соглашения

4.1 Формат интерфейса

Каждое описание интерфейса состоит из девяти компонентов, описанных в таблице 1.

Таблица 1- Формат интерфейса

Компонент Описание Краткий обзор Семантика GET, PUT, POST и DELETE Отсроченное завершение создания В случае длительных операций описывает поведение, если операция не завершается немедленно Опции Описание поддерживаемых операций Заголовки запроса Заголовки запроса, например, Accept, Authorization, Content-Length, ContentType, X-CDMI-Specification-Version Тело сообщения-запроса Описание содержимого тела сообщения-запроса

Окончание таблицы 1

Компонент Описание Заголовки ответа Заголовки ответа, например, Content-Length, Content-Type Тело сообщения-ответа Описание содержимого тела сообщения-ответа Статус ответа Список кодов состояния HTTP Пример Пример операции

4.2    Типографские соглашения

Все исходные тексты программ и сообщений показаны следующим шрифтом:

Пример -

PUT /MyContainer/MyDataObjecttxt НТТР/1.1 Host: cloud.example.com Accept: application/cdmi-object Content-Type: application/cdmi-object X-CDMI-Specification-Version: 1.0.2 {

«mimetype»: «text/plain»,

«metadata»: {

h

«value» : «This is the Value of this Data Objecb>

}

4.3    Требования к телу сообщений запросов и ответов

В таблицах, представляющих тела запросов и ответов, колонка «Требования» содержит одно из трех значений:

-    обязательное. Значение, описанное в данной строке, должно быть указано.

-    условное. Если выполнены условия, указанные в ячейке «Описание» данной строки (слева от ячейки «Требования») то значение, описанное в данной строке, должно быть указано. В противном случае, оно может быть указано, если это не запрещено в Описании (в этом случае оно должно отсутствовать);

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

4.4    Требования к ключевым словам

В данном международном стандарте, ключевые слова, указанные в табл. 2, должны интерпретироваться как указано в RFC 2119.

Таблица 2 - Требования к ключевым словам

Ключевые слова Описание Должно, требуется (shell, must, required) Действие, описанное одним из этих слов, безоговорочно требуется Не должно, не может (shall not, must not) Действие, описанное одним из этих слов, безоговорочно запрещено Следует, рекомендуется (should, recommended) В некоторых обстоятельствах возможно игнорировать действие, описанное одним из этих ключевых слов, но основания для этого должны быть полностью взвешены и осознанны He следует, не рекомендуется (should not, not recommended) В некоторых обстоятельствах возможно выполнить действие, описанное одним из этих ключевых слов, но основания для этого должны быть полностью взвешены и осознанны Может, опционально (may, optional) Действие, описанное одним из этих ключевых слов, полностью опционально. Одни разработчики могут включать данное действие, потому что оно требуется определенному сегменту пользователей или может расширить возможности продукта. Другие разработчики могут опустить ту же опцию. Реализация, которая не включает некоторую опцию, должна иметь возможность взаимодействовать с реализацией, включающей эту опцию. Аналогично, реализация, включающая некоторую опцию, должна иметь возможность взаимодействовать с реализацией, не включающей данную опцию (за исключением, разумеется, функциональности данной опции)