Уровни доступа к данным BLOB-объектов

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

• Горячий уровень — сетевой уровень, оптимизированный для хранения часто используемых или изменяемых данных. Горячий уровень имеет самые высокие затраты на хранение, но самые низкие затраты на доступ.
• Холодный уровень — сетевой уровень, оптимизированный для хранения редко используемых или изменяемых данных. Данные на холодном уровне должны храниться не менее 30 дней. Уровень "холодный" имеет более низкие затраты на хранение и более высокие затраты на доступ по сравнению с горячим уровнем.
• Холодный уровень — сетевой уровень, оптимизированный для хранения данных, которые редко обращаются или изменяются, но по-прежнему требуют быстрого извлечения. Данные на холодном уровне должны храниться не менее 90 дней. На холодном уровне хранилища данные хранить дешевле, зато доступ к ним стоит дороже по сравнению с горячим уровнем.
• Архивный уровень — автономный уровень, оптимизированный для хранения данных, которые используются редко и имеют нестрогие требования к задержке (порядка нескольких часов). Данные на уровне архива должны храниться не менее 180 дней.

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

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

Примеры сценариев использования для горячего уровня:

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

Ниже приведены сценарии использования для холодных и холодных уровней доступа:

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

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

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

Большие блобы (бинарные большие объекты) подвергаются штрафу за раннее удаление, если они удаляются, перезаписываются или перемещаются на другой уровень прежде чем пройдет минимальное количество дней, необходимое для уровня. Например, объект blob на холодном уровне в версии 2 учетной записи общего назначения подвергается штрафу за удаление до истечения срока, если он удален или перемещен на другой уровень до истечения 30 дней. Для объекта на холодном уровне штраф за удаление применяется, если он удалён или перемещён на другой уровень до истечения 90 дней. Эта плата пропорциональна. Например, если большой двоичный объект перемещается на холодный уровень, а затем удаляется через 21 дней, вы будете взимать плату за досрочное удаление, эквивалентную 9 (30 минус 21) дней хранения этого большого двоичного объекта на холодном уровне. Плата за досрочное удаление также возникает, если весь объект в течение указанного периода времени перезаписывается с помощью любой операции (т. е. Put Blob, Put Block List или Copy Blob). Эта плата взимается по цене хранилища данных соответствующего уровня, т. е. удаление архивного блоба через 120 дней приведет к тому, что объект будет оплачиваться в течение 180 дней.

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

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

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

Чтобы узнать, как переместить большой двоичный объект на архивный уровень, см . статью "Архивировать большой двоичный объект".

Данные должны оставаться на архивном уровне не менее 180 дней. За их досрочное удаление будет взиматься плата. Например, если большой двоичный объект перемещается на архивный уровень, а затем удаляется или перемещается на горячий уровень через 45 дней, плата за раннее удаление будет взиматься, эквивалентная 135 (180 минус 45) дней хранения этого большого двоичного объекта на уровне архива.

Хотя блоб находится на уровне архива, его нельзя считывать или изменять. Чтобы прочитать или скачать объект BLOB на архивном уровне, необходимо сначала восстановить его на уровне онлайн, горячем, прохладном или холодном. Данные на уровне архива могут занять до 15 часов для восстановления в зависимости от приоритета, указанного для операции восстановления. Дополнительные сведения о восстановлении BLOB-объектов из архивного уровня см. в разделе «Обзор восстановления BLOB-объектов».

Метаданные архивированного BLOB-объекта остаются доступными для чтения, так что вы можете перечислить сам объект и его свойства, метаданные и теги индекса. Метаданные для большого двоичного объекта на уровне архива доступны только для чтения, а теги индекса BLOB-объектов можно читать или записывать. Затраты на хранение метаданных архивных BLOB-объектов будут взыскиваться по тарифам уровня "Cool". Снапшоты не поддерживаются для архивных BLOB-объектов.

Следующие операции поддерживаются для больших двоичных объектов на уровне архива:

• Копирование БОЛЬШОго двоичного объекта
• Удаление BLOB-объекта
• Отмена удаления BLOB
• Поиск BLOB-объектов по тегам
• Получение метаданных BLOB-объекта
• Получение свойств объекта Blob
• Получение тегов BLOB
• Список объектов
• Установка тегов BLOB
• Установить уровень блоба

Только учетные записи хранения, настроенные для LRS, GRS или RA-GRS, позволяют перемещать блобы на архивный уровень. Уровень архива не поддерживается для учетных записей ZRS, GZRS или RA-GZRS. Дополнительные сведения о конфигурациях избыточности для Azure Storage см. в статье Избыточность хранилища Azure.

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

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

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

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

Любой BLOB-объект, которому уровень доступа не присвоен явным образом, определяет его из параметра уровня доступа учетной записи по умолчанию. Если уровень доступа BLOB выводится из параметра уровня доступа учетной записи по умолчанию, то портал Azure отображает уровень доступа как "Горячий" (выводимый), "Прохладный" (выводимый) или "Холодный" (выводимый).

Изменение настройки уровня доступа по умолчанию для учетной записи хранения применяется ко всем BLOB-объектам в этой учетной записи, для которых уровень доступа не был установлен эксплицитно. Если вы измените параметр уровня доступа по умолчанию на более холодный уровень в учетной записи общего назначения версии 2, то взимается плата за запись (на 10 000) для всех объектов, для которых уровень доступа указан. Плата взимается за операции чтения (за каждые 10 000) и извлечение данных (за ГБ), если переключиться на более теплый тариф в учетной записи общего назначения версии 2.

При создании устаревшей учетной записи Blob Storage необходимо указать параметр уровня доступа по умолчанию как горячий или холодный при создании. За изменение настройки уровня доступа для учетной записи по умолчанию на более холодный уровень в устаревшей учетной записи Blob Storage плата не взимается. Взимается плата за операции чтения (на каждые 10 000) и извлечение данных (за ГБ), если переместить данные на более теплый уровень в учетной записи хранилища Blob. Майкрософт рекомендует, по возможности, использовать счета общего назначения версии 2 вместо BLOB-хранилищ.

Чтобы явно задать уровень доступа для BLOB при его создании, укажите этот уровень при загрузке BLOB.

После создания BLOB-объекта вы можете изменить его уровень одним из следующих способов:

• Вызвать операцию установки уровня BLOB-объекта (непосредственно или с помощью политики управления жизненным циклом). Вызов Установить уровень BLOB обычно является лучшим вариантом при изменении уровня BLOB-объекта с более тёплого на более холодный.

  Примечание

  Нельзя использовать политики управления жизненным циклом для восстановления архивного BLOB на онлайн-уровень хранения.

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

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

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

• Вы не можете использовать Set Blob Tier для архивации blob, который использует область шифрования. Для перемещения между уровнями доступа через Интернет можно использовать только набор уровней BLOB-объектов . Дополнительные сведения об областях шифрования см. в разделе Области шифрования для хранилища BLOB-объектов.

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

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

Нельзя использовать политики управления жизненным циклом для восстановления архивного BLOB на онлайн-уровень хранения. Данные, хранящиеся в учетной записи хранения BLOB-объектов уровня «Premium», не могут быть переведены на горячий, холодный или архивный уровень, используя Задание уровня BLOB-объекта или управление жизненным циклом хранилища BLOB-объектов Azure. Чтобы переместить данные, необходимо синхронно копировать BLOB из учетной записи хранения блобов на горячий уровень в другой учетной записи с помощью Put Block From URL API или версии AzCopy, поддерживающей этот API. API Put Block From URL синхронно копирует данные на сервере, то есть вызов завершается только после того, как все данные перемещены из исходного расположения сервера в расположение назначения.

Хотя управление жизненным циклом помогает перемещать данные между уровнями в одной учетной записи, вы можете использовать задачу хранения для выполнения этой задачи в масштабе нескольких учетных записей. Задача хранения — это ресурс, доступный в Azure Storage Actions; бессерверная структура, которую можно использовать для выполнения общих операций с данными для миллионов объектов в нескольких учетных записях хранения. Дополнительные сведения см. в материале «Что такое Azure Storage Actions?».

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

¹ Объекты на холодном уровне в учетных записях общего назначения версии 2 имеют минимальную длительность хранения в течение 30 дней. Объекты в холодном уровне в учетных записях общего назначения версии 2 имеют минимальную длительность хранения 90 дней. Для учетных записей хранения BLOB-объектов не существует минимальной продолжительности хранения для прохладного или холодного уровня.

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

³ Дополнительные сведения об избыточности в службе хранилища Azure см. в разделе Избыточность в службе хранилища Azure.

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

Дополнительные сведения о ценах на блочные BLOB-объекты см. в разделе Цены на блочные BLOB-объекты.

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

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

Плата за транзакцию распространяется на все уровни и увеличивается по мере понижения уровня.

Эта плата применяется только к учетным записям с настроенной георепликацией, включая GRS, RA-GRS и GZRS. При передаче данных георепликации взимается плата за гигабайт данных.

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

При изменении уровня доступа в аккаунте взимается плата за изменение уровня для всех BLOB-объектов, для которых еще не установлен конкретный уровень. Дополнительные сведения см. в следующем разделе Изменение уровня доступа BLOB-объекта.

Изменяя уровень BLOB, необходимо учитывать следующее влияние на выставление счетов:

• Когда объект передается или перемещается между уровнями, плата начисляется по соответствующему тарифу в момент передачи или изменения уровня.
• При перемещении большого двоичного объекта на более холодный уровень операция учитывается как операция записи на целевой уровень, где применяются тарифы записи операций (на 10 000) и записи данных в ГБ целевого уровня.
• При перемещении большого двоичного объекта на более теплый уровень операция оплачивается как чтение из исходного уровня, где применяется операция чтения (на 10 000) и сбор данных (за ГБ). Плата за раннее удаление любого BLOB, перенесенного из тёплого, холодного или архивного уровня, также может взиматься.
• Хотя BLOB восстанавливается с архивного уровня, его данные выставляются как архивные до тех пор, пока данные не будут восстановлены, а уровень BLOB не изменится на горячий или прохладный.

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

Изменение уровня доступа для объекта BLOB при включенном версионировании или если у объекта BLOB есть моментальные снимки может привести к дополнительным расходам. Сведения о больших двоичных объектах с включенным управлением версиями см. в разделе Цены и выставление счетов в документации по управлению версиями больших двоичных объектов. Сведения о больших двоичных объектах с моментальными снимками см. в разделе Цены и выставление счетов в документации по моментальным снимкам больших двоичных объектов.

Для холодного уровня требуются следующие минимальные версии REST, пакетов SDK и средств.

На поддержку данной функции может повлиять включение протокола Data Lake Storage 2-го поколения, протокола сетевой файловой системы (NFS) 3.0 или протокола SFTP. Если вы включили любую из этих возможностей, см. Поддержка функций Blob-хранения в учетных записях хранения Azure, чтобы оценить поддержку этой функции.

• Настройка уровня доступа блоба
• Архивировать блоб
• Оптимизация затрат путем автоматического управления жизненным циклом данных
• Рекомендации по использованию уровней доступа к BLOB