Национальный стандарт республики казахстан



страница4/33
Дата20.11.2016
Размер4.62 Mb.
Просмотров6904
Скачиваний0
1   2   3   4   5   6   7   8   9   ...   33

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

Ключевые слова

Описание

должны обязательно

требуется




Безоговорочно требуется действие, описанных с любым из этих ключевых слов.

не будут

не должны

Действия, описанные с любой из этих ключевых слов, безоговорочно запрещены.

следует

рекомендуется

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

не следует

не рекомендуется

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

Можно

Необязательно

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









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

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

Обращение хранения облака происходит из-за некоторых из тех же самых признаков, которые определяют другие облачные сервисы: платите, когда идете, иллюзия бесконечной способности (эластичность) и простота использования/управления. Поэтому важно, чтобы любой интерфейс для хранения облака поддержал эти признаки, допуская использование множество деловых случаев.
5.2 Что такое хранение в облако?
Использование термина "облако" в описании этих новых моделей явилось результатом рисунков которые, как правило, использовали облако в качестве символа для сети. Облако представляет сетевое соединение “любой-любому» абстрактным способом. В этой абстракции сетевое соединение в облаке представлено без беспокойства - как он сделан, чтобы получалось.

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

Таким образом, облако хранения - просто доставка виртуализированного хранения по требованию. Формальный термин, который использован для этого, является Хранения данных как сервис (DaaS).
5.3 Хранения данных как сервис
Резюмируя хранение данных позади сервисного ряда интерфейсов и поставляя его по требованию, широкий диапазон фактических предложений и внедрений возможен. Единственный тип хранения, которое исключено из этого определения, является то, которое поставлено в приращениях фиксированной способности вместо основного по требованию.

Важной частью любого предложения хранения данных как сервис (DaaS) является поддержка устаревших клиентов. Поддержка снабжена существующими стандартными протоколами, такими как ИСМИК (и другие) для блока и CIF/nfs или WebDAV для хранения сети файла, как показано на рисунке 1.



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

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

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

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

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


Рисунок 2 - Интерфейсы хранения для хранения объекта данных клиента
5.4 Управление данными для хранения в облако
Многое из первоначальных предложений облака хранения сосредоточено, на своего рода, «лучшее из возможного» качества обслуживания хранения и игнорирования большинства других типов информационных услуг. Однако для удовлетворения потребностей корпоративных приложений с хранением облака, существует возрастающая необходимость предлагать лучшее качество обслуживания и развертывания дополнительных информационных служб.

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

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

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

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

Данные системы метаданных интерпретируются облаком, предлагающим как требования к данным, которые управляют операцией основных информационных служб для тех данных. Это может относиться к скоплению объектов данных в контейнере или к отдельным объектам данных, если предложение поддерживает этот уровень степени детализации. Для получения дополнительной информации о поддержке данные системы метаданных см. 16.4.
5.5 Данные и контейнерное управление
Нет никаких причин, что управляющие данные и управляющие контейнеры должны предусматривать различные интерфейсы. Поэтому, использование метаданных расширяется от применения к отдельным элементам данных, также к обращению к контейнерам данных. Таким образом, любые данные, помещенные в контейнер, наследуют метаданные системы данных контейнера, в который это было помещено. Создавая новый контейнер в пределах существующего контейнера, новый контейнер так же унаследовал бы параметры настройки метаданных, метаданных системы данных своего родителя.

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

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

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

Для основанных на файле интерфейсов, которые поддерживают расширенные атрибуты (например, CIF, NFSv4), эти расширенные атрибуты могут использоваться, для указания данных системы метаданных, для переопределения указанный для контейнера.
5.6 Модель ссылки для интерфейсов хранения в облако
Эталонная модель Хранения Облака показано на рисунке 3.
Клиенты, действующие в роли использования интерфейса хранения данных

Рисунок 3 - Эталонная модель хранения облака


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

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

  • разрешить клиентам обнаруживать возможности, доступные в предложении хранения облака;

  • управление контейнерами и данными, размещенных в них; и

  • позволить метаданным быть связанными с контейнерами и объектами, которые они содержат.

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

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

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

Этот международный стандарт использует УСПОКОИТЕЛЬНЫЕ принципы в дизайне интерфейса, где возможно (см. ОТДЫХ).

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

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

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

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

  • определить, как учетные данные пользователя сопоставляются принципами, используемые в списоке контроля доступом (СКД),

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

  • разрешите делегацию внешних пользовательских систем разрешения (например, LDAP или Активный Справочник).

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

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

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

Например, в 5.10, этот международный стандарт государства, "Каждая система хранения облака должна позволить ID объекту доступ к хранящимся объектам". Это требование должно быть понято в контексте, что доступ ID объекта утвержден на присутствии cdmi_object_access_by_ID способности.
5.8 Модель объекта для CDMI
Модель для CDMI показана на рисунке 4.



Рисунок 4 - Модель объекта CDMI
Пять типов определенных ресурсов показаны в Таблице 3. Тип содержимого в любой конкретной операции для каждого конкретного типа ресурса.
Таблица 3 - Типы ресурсов в модели

Тип ресурса

Описание

Ссылка

Объекты данных

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

См. пункт 8.

Контейнерные объекты

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

См. пункт 9.

Объекты домена

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

См. пункт 10.

Объекты очереди

Объекты очереди хранят ноль или ценность движения и получают доступ способом метода "первым пришел - первым вышел".

См. пункт 11.

Объекты способности

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

См. пункт 12.

Каталог: sites -> default -> files
files -> Методические рекомендации по проведению Дня Знаний, посвященного Году кино в РФ
files -> Блестящие будущие возможности в сфере икт для нового поколения женщин
files -> Ларцева А. 1 Перевод имен собственных на примере книги ховарда рейнголда
files -> Занятие №18 Здравствуйте, участники программ личностного развития для детей!
files -> Программа кружка «Юный журналист»
files -> Шелакина А. А. Студентка 2 курса атп 921 ппк сгту имени Гагарина Ю. А
files -> Культурного и природного наследия имени д. С. Лихачева
files -> Участники регионального отборочного Чемпионата профессионального мастерства по методике WorldSkills «WorldSkills Russia Иркутск 2016» по компетенции: 21 PlasteringandDrywallSystems – Сухое строительство и штукатурные работы 25 27
files -> Семинар «использование квест- технологии в обучении английскому языку»


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   ...   33


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал