Структура политики управления жизненным циклом хранилища BLOB-объектов Azure

2025-06-13

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

В этой статье описываются элементы политики управления жизненным циклом. Примеры политики см. в следующих статьях:

Подсказка

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

Правила

Политика управления жизненным циклом представляет собой набор правил, оформленный в виде документа JSON. В примере JSON ниже показано полное определение правил:

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}

Имя параметра	Тип параметра	Примечания.
Правила	Массив объектов правил	Для каждой политики должно существовать хотя бы одно правило. В политике можно определить до 100 правил.

Каждое правило в политике имеет несколько параметров, описанных в следующей таблице:

Имя параметра	Тип	Примечания.	Обязательно
имя	Струна	Имя правила может содержать до 256 буквенно-цифровых символов. Название правила чувствительно к регистру. Имя должно быть уникальным в пределах политики.	Да
включена	Булев	Необязательное логическое значение, позволяющее временно отключить правило. Значение по умолчанию — true.	нет
тип	Значение перечисления	Текущий допустимый тип — `Lifecycle`.	Да
определение	Объект, который определяет правило жизненного цикла	Каждое определение состоит из набора фильтров и набора действий.	Да

Фильтры

Фильтры ограничивают действия подмножеством объектов Blob в учетной записи хранения. С помощью фильтра можно указать, какие блобы включить. Фильтр не позволяет указать, какие объекты BLOB следует исключить. Если определено несколько фильтров, логический И применяется ко всем фильтрам. В следующей таблице содержатся описания всех параметров.

Имя фильтра	Тип	Описание	Обязательно
BLOBTypes	Массив предопределенных значений перечислимого типа	Тип объекта блоба (blockblob или appendBlob)	Да
совпадениеПрефиксов	Массив строк	Эти строки являются префиксами для сопоставления.	нет
blobIndexMatch	Массив значений словаря	Эти значения состоят из ключа тега индекса BLOB и условий соответствия значений.	нет

Фильтр сопоставления префикса

Если применить фильтр prefixMatch , каждое правило может определять до 10 префиксов с учетом регистра. Строка префикса должно начинаться с имени контейнера. Например, если вы хотите сопоставить все объекты в пути https://myaccount.blob.core.windows.net/sample-container/blob1/..., укажите prefixMatch как .

Этот фильтр будет соответствовать всем блобам в sample-container, где имена начинаются с blob1. Если вы не определяете префиксное соответствие, правило применяется ко всем блобам в учетной записи хранения. Префиксные строки не поддерживают сопоставление с подстановочными знаками. Такие символы, как * и ? рассматриваются как строковые литералы.

Фильтр сопоставления индекса BLOB-объектов

Если применить фильтр blobIndexMatch , каждое правило может определить до 10 условий тега индекса BLOB-объектов. Например, если вы хотите сопоставить все блобы с Project = Contoso под https://myaccount.blob.core.windows.net/, то фильтр blobIndexMatch - это {"name": "Project","op": "==","value": "Contoso"}. Если вы не определяете значение фильтра blobIndexMatch , правило применяется ко всем BLOB-объектам в учетной записи хранения.

Действия

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

Действие	Описание
TierToCool	Переведите блоб на холодный уровень доступа. Не поддерживается для добавочных BLOB-объектов, страничных BLOB-объектов или BLOB-объектов в учетной записи хранения блоков класса Premium.
TierToCold	Установите BLOB-объект на уровень холодного доступа. Не поддерживается для добавочных BLOB-объектов, страничных BLOB-объектов или BLOB-объектов в учетной записи хранения блоков класса Premium.
TierToArchive	Установите блоб на уровень доступа к архиву. Реидратация BLOB не обновляет свойства времени последнего изменения или последнего доступа. В результате это действие может переместить реидратированные объекты BLOB обратно на архивный уровень. Чтобы предотвратить это, добавьте `daysAfterLastTierChangeGreaterThan` условие в это действие. Это действие не поддерживается с добавляемыми BLOB-объектами, страничными BLOB-объектами или с BLOB-объектами в аккаунте хранилища BLOB-объектов класса Premium. Кроме того, не поддерживается с большими двоичными объектами, используюющими область шифрования или с большими двоичными объектами в учетных записях, настроенных для хранилища, избыточного между зонами (ZRS), геозоны, избыточного между зонами (GZRS) и геоизбыточного хранилища (RA-GZRS).
enableAutoTierToHotFromCool	Если объект BLOB установлен на холодный уровень, это действие автоматически перемещает его на горячий уровень при доступе к нему. Это действие доступно только при использовании с условием выполнения daysAfterLastAccessTimeGreaterThan . Это действие не влияет на большие двоичные объекты, которые были установлены на холодный уровень перед включением этого действия в правиле. Это действие перемещает объекты из холодного состояния в горячее только один раз в 30 дней. Эта защита применяется для защиты от нескольких штрафов за досрочное удаление, предъявленные учетной записи. Не поддерживается в предыдущих версиях или моментальных снимках.
Удалить	Удаляет блоб. Не поддерживается для Page BLOB-объектов или BLOB-объектов в неизменяемом контейнере.

Если вы определяете несколько действий в одном большом двоичном объекте, управление жизненным циклом применяет к большому двоичному объекту наименьшее затратное действие. Например, действие удаления дешевле, чем действие tierToArchive , а действие tierToArchive дешевле, чем действие tierToCool .

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

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

Удаление действия для больших двоичных объектов с версиями и моментальными снимками

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

Условия выполнения операций

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

Текущие версии используют время последнего изменения или последнего доступа, предыдущие версии используют время создания версии, а моментальные снимки BLOB используют время создания моментального снимка для отслеживания их возраста.

В следующей таблице описывается каждое условие выполнения действия.

Название условия	Тип	Описание
дниПослеИзмененияБольшеЧем	Целое число	Возраст через несколько дней после последнего изменения большого двоичного объекта. Применяется к действиям на текущую версию BLOB.
daysAfterCreationGreaterThan	Целое число	Возраст в днях после времени создания. Применяется к действиям с текущей версией объекта (blob), предыдущей версией объекта (blob) или моментальным снимком объекта (blob).
днейПослеПоследнегоДоступаБольшеЧем	Целое число	Возраст, измеряемый в днях с момента последнего доступа, или в некоторых случаях, с даты, когда политика была активирована. Дополнительные сведения см. в разделе отслеживания времени доступа ниже. Применяется к действиям в текущей версии блоба при включении отслеживания доступа.
днейПослеПоследнегоИзмененияУровняБольшеЧем	Целое число	Возраст за несколько дней после последнего изменения уровня BLOB-объектов. Минимальная продолжительность в днях, когда гидратированный большой двоичный объект хранится в горячих, прохладных или холодных уровнях, прежде чем они возвращаются на архивный уровень. Применяется только к действиям tierToArchive .

Отслеживание времени доступа

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

При включении отслеживания времени доступа при чтении или записи обновляется свойство объекта BLOB с именем LastAccessTime. Операции Get Blob и Put Blob являются операциями доступа и обновляют время доступа BLOB-объекта. Однако Get Blob Properties, Get Blob Metadata и Get Blob Tags не являются операциями доступа. Эти операции не будут обновлять время доступа BLOB.

Если условие выполнения daysAfterLastAccessTimeGreaterThan применяется к политике, то LastAccessTime используется для определения, соответствует ли это условие.

Если вы применяете условие выполнения daysAfterLastAccessTimeGreaterThan к политике, но не включили отслеживание времени доступа, то LastAccessTime не будет использовано. Вместо этого используется дата включения политики жизненного цикла. Фактически, дата включения политики жизненного цикла используется в любой ситуации, когда свойство блоба LastAccessTime равно null. Это может произойти, даже если вы включили отслеживание времени доступа в случаях, когда большой двоичный объект не был доступен после включения отслеживания.

Замечание

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

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