Оптимизация затрат путем автоматического управления жизненным циклом данных

  • Статья

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

Примечание.

Каждое последнее обновление времени доступа взимается как "другая транзакция" не более одного раза каждые 24 часа на объект, даже если он обращается к 1000 раз в день. Это отличается от расходов на чтение транзакций.

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

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

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

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

Внимание

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

Определение политики управления жизненным циклом

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

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

Политика — это набор правил, как показано в следующей таблице:

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

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

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

Определение правила управления жизненным циклом

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

Пример правила

Следующий пример правила фильтрует учетную запись для выполнения действий с объектами, которые существуют внутри sample-container и начинаются с blob1.

  • установить для BLOB-объекта холодный уровень доступа через 30 дней после последнего изменения;
  • установить для BLOB-объекта архивный уровень доступа через 90 дней после последнего изменения;
  • удалить BLOB-объект спустя 2555 дней (7 лет) после последнего изменения;
  • Удаление предыдущих версий через 90 дней после создания
{
  "rules": [
    {
      "enabled": true,
      "name": "sample-rule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "delete": {
              "daysAfterCreationGreaterThan": 90
            }
          },
          "baseBlob": {
            "tierToCool": {
              "daysAfterModificationGreaterThan": 30
            },
            "tierToArchive": {
              "daysAfterModificationGreaterThan": 90,
              "daysAfterLastTierChangeGreaterThan": 7
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "sample-container/blob1"
          ]
        }
      }
    }
  ]
}

Примечание.

Элемент baseBlob в политике управления жизненным циклом ссылается на текущую версию BLOB-объекта. Элемент version указывает предыдущую версию.

Фильтры правила

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

Доступны следующие фильтры:

Имя фильтра Тип фильтра Примечания. Обязательно
blobTypes Массив предустановленных значений перечисления. Текущий выпуск поддерживает blockBlob и appendBlob. Поддерживается appendBlobтолько действие delete ; Уровень set не поддерживается. Да
prefixMatch Массив строк, по которым выполняется сопоставление префиксов. Каждое правило может определять до 10 префиксов (с учетом регистра). Строка префикса должно начинаться с имени контейнера. Например, если вы хотите сопоставить все большие двоичные объекты в разделе https://myaccount.blob.core.windows.net/sample-container/blob1/..., укажите префиксMatch как sample-container/blob1. Этот фильтр будет соответствовать всем blob-объектам в примере контейнера , имена которых начинаются с BLOB-объектов1.

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

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

Действия правила

Действия применяются к отфильтрованным BLOB-объектам при соблюдении условия выполнения.

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

Примечание.

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

Действие Текущая версия Снимок Предыдущие версии
tierToCool Поддерживается для объекта blockBlob Поддерживается Поддерживается
tierToCold Поддерживается для объекта blockBlob Поддерживается Поддерживается
enableAutoTierToHotFromCool1 Поддерживается для объекта blockBlob Не поддерживается Не поддерживается
tierToArchive4 Поддерживается для объекта blockBlob Поддерживается Поддерживается
удаление2,3 Поддерживается для blockBlob и appendBlob Поддерживается Поддерживается

1 Действие enableAutoTierToHotFromCool доступно только при использовании с условием daysAfterLastAccessTimeGreaterThan выполнения. Это условие описано в следующей таблице.

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

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

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

Примечание.

Если для одного BLOB-объекта определено более одного действия, управление жизненным циклом применяет к нему более дешевое из этих действий. Например, действие delete дешевле, чем действие tierToArchive; а действие tierToArchive дешевле, чем действие tierToCool.

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

Условие выполнения действия Значение условия Description
daysAfterModificationGreaterThan Целочисленное значение, указывающее возраст в днях Условие для действий с текущей версией большого двоичного объекта
daysAfterCreationGreaterThan Целочисленное значение, указывающее возраст в днях Условие действий для текущей или предыдущей версии большого двоичного объекта или моментального снимка БОЛЬШОго двоичного объекта
daysAfterLastAccessTimeGreaterThan1 Целочисленное значение, указывающее возраст в днях Условие для текущей версии BLOB-объекта, если включено отслеживание доступа
daysAfterLastTierChangeGreaterThan Целочисленное значение, которое обозначает период в днях, прошедший после последнего изменения уровня BLOB-объекта. Это условие применяется только к действиям tierToArchive и может использоваться только с условием daysAfterModificationGreaterThan.

1 Если отслеживание времени последнего доступа не включено, daysAfterLastAccessTimeGreaterThan использует дату включения политики жизненного цикла вместо LastAccessTime свойства большого двоичного объекта. Эта дата также используется, если LastAccessTime свойство имеет значение NULL. Дополнительные сведения об использовании отслеживания времени последнего доступа см. в разделе "Перемещение данных на основе времени последнего доступа".

Запуски политики жизненного цикла

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

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

Событие завершения политики жизненного цикла

Событие LifecyclePolicyCompleted активируется при выполнении действий, определенных политикой управления жизненным циклом. Ниже приведен фрагмент JSON с примером события LifecyclePolicyCompleted.

{
    "topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosoresourcegroup/providers/Microsoft.Storage/storageAccounts/contosostorageaccount",
    "subject": "BlobDataManagement/LifeCycleManagement/SummaryReport",
    "eventType": "Microsoft.Storage.LifecyclePolicyCompleted",
    "eventTime": "2022-05-26T00:00:40.1880331",    
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "data": {
        "scheduleTime": "2022/05/24 22:57:29.3260160",
        "deleteSummary": {
            "totalObjectsCount": 16,
            "successCount": 14,
            "errorList": ""
        },
        "tierToCoolSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        },
        "tierToArchiveSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        }
    },
    "dataVersion": "1",
    "metadataVersion": "1"
}

Схема события LifecyclePolicyCompleted описана в таблице ниже.

Поле Тип Описание
scheduleTime строка Время планирования политики жизненного цикла
deleteSummary векторный<байт> Сводка результатов больших двоичных объектов, запланированных для операции удаления
tierToCoolSummary векторный<байт> Сводка результатов больших двоичных объектов, запланированных для операции "уровень — холодный"
tierToArchiveSummary векторный<байт> Сводка результатов больших двоичных объектов, запланированных для операции "уровень — архив"

Примеры политик управления жизненным циклом

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

Перемещение старых данных на более холодный уровень

В следующем примере показано перемещение блочных BLOB-объектов с префиксом имени sample-container/blob1 или container2/blob2. Эта политика перемещает BLOB-объекты, которые не изменялись более 30 дней, на холодный уровень, а которые не изменялись в течение 90 дней — на архивный уровень:

{
  "rules": [
    {
      "name": "agingRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

Перемещение данных на основе времени последнего доступа

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

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

Если включено отслеживание времени последнего доступа, управление жизненным циклом используется LastAccessTime для определения соответствия условию выполнения daysAfterLastAccessTimeGreaterThan . Управление жизненным циклом использует дату включения политики жизненного цикла вместо LastAccessTime следующих случаев:

  • Значение LastAccessTime свойства большого двоичного объекта — значение NULL.

    Примечание.

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

  • Отслеживание времени последнего доступа не включено.

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

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

Совет

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

{
  "enabled": true,
  "name": "last-accessed-thirty-days-ago",
  "type": "Lifecycle",
  "definition": {
    "actions": {
      "baseBlob": {
        "enableAutoTierToHotFromCool": true,
        "tierToCool": {
          "daysAfterLastAccessTimeGreaterThan": 30
        }
      }
    },
    "filters": {
      "blobTypes": [
        "blockBlob"
      ],
      "prefixMatch": [
        "mylifecyclecontainer/log"
      ]
    }
  }
}

Архивирование данных после приема

Некоторые данные хранятся в облаке почти без использования. Следующая политика жизненного цикла настроена для архивирования данных вскоре после их приема. Этот пример перемещает BLOB-объекты в пределах контейнера archivecontainer на архивный уровень хранилища. Перемещение осуществляется путем воздействия на большие двоичные объекты через 0 дней после последнего изменения.

{
  "rules": [
    {
      "name": "archiveRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "archivecontainer" ]
        },
        "actions": {
          "baseBlob": {
              "tierToArchive": { 
                "daysAfterModificationGreaterThan": 0
              }
          }
        }
      }
    }
  ]
}

Примечание.

Корпорация Майкрософт рекомендует отправлять большие двоичные объекты непосредственно на архивный уровень для повышения эффективности. Вы можете указать уровень архива в заголовке x-ms-access-tier в операции Put Blob или Put Block List. Заголовок x-ms-access-tier поддерживается в REST версии 2018-11-09 и более поздней, а также в наших последних версиях клиентских библиотек хранилища BLOB-объектов.

Устаревание данных на основе возраста

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

{
  "rules": [
    {
      "name": "expirationRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ]
        },
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

Удаление данных с тегами индекса BLOB-объектов

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

{
    "rules": [
        {
            "enabled": true,
            "name": "DeleteContosoData",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "delete": {
                            "daysAfterModificationGreaterThan": 0
                        }
                    }
                },
                "filters": {
                    "blobIndexMatch": [
                        {
                            "name": "Project",
                            "op": "==",
                            "value": "Contoso"
                        }
                    ],
                    "blobTypes": [
                        "blockBlob"
                    ]
                }
            }
        }
    ]
}

Управление предыдущими версиями

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

{
  "rules": [
    {
      "enabled": true,
      "name": "versionrule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 90
            },
            "delete": {
              "daysAfterCreationGreaterThan": 365
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "activedata/"
          ]
        }
      }
    }
  ]
}

Доступность и цены в регионах

Функция управления жизненным циклом доступна во всех регионах Azure.

Политики управления жизненным циклом бесплатны. Клиенты оплачивают только обычную стоимость вызовов API Set Blob Tier для установки уровня BLOB-объектов. Операции удаления бесплатны. Однако другие службы и служебные программы Azure, например, Microsoft Defender для служба хранилища, могут взимать плату за операции, управляемые с помощью политики жизненного цикла.

Каждое обновление времени последнего доступа к BLOB-объекту оплачивается по категории другие операции.

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

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

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

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

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

  • Если вы настроили для учетной записи хранения правила брандмауэра, запросы на управление жизненным циклом могут быть заблокированы. Их можно разблокировать, предоставив исключения для доверенных служб Майкрософт. Дополнительные сведения см. в разделе об исключениях статьи Настройка брандмауэров и виртуальных сетей.

  • Политика управления жизненным циклом не может изменить уровень BLOB-объекта, использующего область шифрования.

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

Вопросы и ответы

Ознакомьтесь с часто задаваемыми вопросами по управлению жизненным циклом.

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