ГОСТ Р ИСО/МЭК 17826-2015
Различие между приобретением обычного устройства и облачного хранилища состоит не в функ
циональных интерфейсах, а в том, что в последнем случае хранилище предоставляется по запросу.
Пользователь платит либо за то, чем фактически пользуется, либо за то. что запросил для использова
ния. В случае блочного хранилища размер запрошенного объема измеряется в виртуальных томах или
номерах логического устройства (LUN). В случае файловых протоколов, единицей измерения является
файл. В любом случае, действительный объем хранилища может быть тонко зарезервирован и опла
чен исходя из действительного использования. Для дальнейшего снижения фактически используемого
объема могут использоваться такие службы данных, такие как сжатие или удаление дубликатов.
Управление таким хранилищем в случае стандартных интерфейсов хранения данных обычно осу
ществляется через API или (чаще) через пользовательский интерфейс администратора в браузере по
выделенному каналу связи. Этот интерфейс по выделенному каналу связи может использоваться для
запуска других службданных (например, создания моментального снимка состояния или клонирования).
В рамках такой модели фактическое хранилище, доступ к которому реализуется посредством ин
терфейса по выделенному каналу связи, абстрагируется концепцией контейнера. Контейнер - не толь
ко полезная абстракция места хранения, он также служит для группировки хранимых данных и точкой
управления для применения служб данных к такой группе.
Каждый объект данных создается, получается, обновляется и уничтожается как отдельный ре
сурс. В этом интерфейсе контейнер, если он используется, служит для удобства, группируя объекты
данных. Ничто не препятствует создавать иерархические контейнеры, хотя каждая конкретная реали
зация может поддерживать лишь единственный уровень (см. рисунок 2).
Клмнт
обикш ш
ярешлиц*
Рисунок 2 - Интерфейсы хранилища для данных клиента объектного хранилища
5.4 Управление данными для облачного хранения
Многие из первых реализаций облачного хранилища фокусировались на хранении данных с мини
мальными гарантиями качества хранения и игнорировали большинство других типов службданных. Одна
ко, учитывая нужды корпоративных приложений, использующих облачное хранение, существует необхо
димость совершенствовать качество предоставления услуг и внедрять дополнительные службы данных.
Облачное хранение может потерять свои преимущества абстрактности и простоты, если появят
ся новые службы данных, требующие сложного управления. Клиенты облачных хранилищ, вероятно,
будут не согласны тратить время на дополнительные операции (например, настраивать через специ
ализированные интерфейсы резервное копирование по расписанию, разворачивать службу данных ин
дивидуально для каждого элемента данных).
Поддержка метаданных в интерфейсе облачного хранилища и указание, как система хранения
и ее метаданные интерпретируются для соблюдения требований к данным, могут сохранить простоту
облачного хранения и при этом реализовать необходимые для корпоративных приложений функции.
6