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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

    Примечание.

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

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

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

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

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

Управление жизненным циклом большого двоичного объекта

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

Примечание.

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

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

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

Горячий уровень доступа Холодный уровень доступа Холодный уровень Архивный уровень доступа
Доступность 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-объектов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расходы на запись (операция + доступ) Расходы на чтение (операция + доступ)
Горячее, чтобы прохладить
Горячее к холодному
Горячее архивирование
Прохладно до холодного
Прохладно архивировать
Холодный архив
Архив для холодного
Архив для охлаждения
Архив в горячий
Холодный, чтобы прохладить
Холодно к горячему
Прохладно до горячего

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

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

Холодный уровень теперь общедоступен во всех общественных и Azure для государственных организаций регионах, кроме Центральной Польши и Центрального Катара.

Известные проблемы и ограничения

  • Канал изменений еще не совместим с холодным уровнем.
  • Объект реплика tion еще не совместим с холодным уровнем.
  • Для уровня доступа по умолчанию для учетной записи задать холодный уровень нельзя.

Обязательные версии REST, пакетов SDK и средств

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

Поддерживаемые компоненты

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

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