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

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

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

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

Примечание.

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

Сетевые уровни доступа

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

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

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

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

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

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

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

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

Примечание.

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

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

Архивный уровень хранилища

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

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

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

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

Примечание.

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

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

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

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

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

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

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

Минимальный размер оплачиваемого объекта на более холодных уровнях

Для учетных записей хранения, использующих Хранилище BLOB-объектов Azure или Azure Data Lake Storage, минимальный размер оплачиваемого объекта 128 KiB применяется к объектам, хранящимся в cool, cold и archive уровней доступа. Объекты в этих уровнях, которые меньше 128 КиБ, оплачиваются по тарифу как объекты размером 128 КиБ для соответствующего уровня. Выставление счетов использует существующие счетчики учета емкости (данные хранятся), а выставление счетов за транзакции остается без изменений.

Это поведение выставления счетов будет представлено на двух этапах:

  • 1 июля 2026 г. Поведение выставления счетов применяется ко всем новым учетным записям хранения, созданным на этой дате или после нее. Для существующих учетных записей хранения нет изменений.
  • 1 июля 2027 г. Поведение выставления счетов применяется ко всем учетным записям хранения.

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

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

Для поддержки этого изменения метрики Blob Capacity на портале Azure будут представлены новые типы BLOB-объектов: BlockBlobSmall и Azure Azure Data Lake Storage Small.

Примечание.

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

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

Параметр уровня доступа к учетной записи по умолчанию

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

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

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

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

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

Примечание.

Уровень архива не поддерживается в качестве уровня доступа по умолчанию для учетной записи хранения.

Настройка или изменение уровня для объектов BLOB

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

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

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

    Примечание.

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

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

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

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

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

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

Управление жизненным циклом BLOB

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

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

Действия хранилища

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

Сводка параметров уровней доступа

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

Горячий уровень Холодный уровень хранения Холодная категория Архивный уровень
Доступность 99,9 % 99 % 99 % 99 %
Доступность
(RA-GRS читает)
99,99 % 99,9 % 99,9 % 99,9 %
Плата за использование Выше стоимость хранения, ниже расходы на доступ и транзакции Ниже стоимость хранения, выше расходы на доступ и транзакции Ниже стоимость хранения, выше расходы на доступ и транзакции Минимальная стоимость хранения, очень высокие расходы на доступ и транзакции
Минимальный рекомендуемый период хранения данных Не применимо 30 дней1 90 дней 1 180 дней
Задержка
(время до получения первого байта)
Миллисекунды Миллисекунды Миллисекунды Часы2
Поддерживаемые конфигурации резервирования Все Все Все Только LRS, GRS и RA-GRS3

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

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

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

Цены и выставление счетов

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

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

Затраты на емкость хранилища

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

Затраты на доступ к данным

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

Плата за транзакции

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

Затраты на передачу данных при георепликации

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

Стоимость передачи исходящих данных

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

Изменение уровня доступа по умолчанию в учетной записи

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

Изменение уровня доступа BLOB-объекта

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

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

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

Расходы на запись (операция + доступ) Расходы на чтение (операция + доступ)
От горячего к прохладному
От горячего к холодному
Как архивировать
Прохладно до холодного
Здорово сохранить в архиве
Архивирование на холодное хранение
Архивировать в холодное хранилище
Архивировать для охлаждения
Архивировать на горячее хранилище
От холодного до прохладного
от холодного к горячему
От прохладного до горячего

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

Холодный уровень

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

Окружающая среда Минимальная версия
REST API 2021-12-02
.NET 12.15.0
Java 12.21.0
Python 12.15.0
JavaScript 12.13.0
PowerShell (Az.Storage) 5.8.0
Azure CLI 2.50.0
AzCopy 10.18.1
Обозреватель службы хранилища Azure 1.29.0

Поддержка функций

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

Следующие шаги