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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

Следующий пример правила фильтрует учетную запись для выполнения действий с объектами, которые существуют внутри 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 поддерживается только удаление, уровень набора не поддерживается. Да
prefixMatch Массив строк, по которым выполняется сопоставление префиксов. Каждое правило может определять до 10 префиксов (с учетом регистра). Строка префикса должно начинаться с имени контейнера. Например, если вы хотите применить правило ко всем большим двоичным объектам по адресу https://myaccount.blob.core.windows.net/sample-container/blob1/..., prefixMatch будет иметь значение sample-container/blob1. Если не определить параметр prefixMatch, правило будет применятся ко всем BLOB-объектам в учетной записи хранения. Нет
blobIndexMatch Массив значений словаря, состоящий из ключа тега индекса BLOB-объекта и условий значений, которые необходимо сопоставить. Каждое правило может определять до 10 условий тега индекса BLOB-объектов. Например, если вы хотите сопоставить все большие двоичные объекты с Project = Contoso по адресу https://myaccount.blob.core.windows.net/ для правила, blobIndexMatch будет иметь значение{"name": "Project","op": "==","value": "Contoso"}. Если не определить параметр blobIndexMatch, правило будет применятся ко всем BLOB-объектам в учетной записи хранения. Нет

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

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

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

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

Действие Текущая версия Моментальный снимок Предыдущие версии
tierToCool Поддерживается для объекта blockBlob Поддерживается Поддерживается
enableAutoTierToHotFromCool Поддерживается для объекта blockBlob Не поддерживается Не поддерживается
tierToArchive Поддерживается для объекта blockBlob Поддерживается Поддерживается
delete1 Поддерживается для blockBlob и appendBlob Поддерживается Поддерживается

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

Примечание

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

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

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

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

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

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

В следующем примере показано перемещение блочных 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 не являются операциями доступа и, следовательно, не обновляют время последнего доступа.

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

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

{
  "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"
          ]
        }
      }
    }
  ]
}

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

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

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

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

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

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

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

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

ВОПРОСЫ И ОТВЕТЫ

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

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

Сколько времени займет выполнения действий при обновлении существующей политики?

Обновленная политика вступит в силу в течение 24 часов. После вступления политики в силу для выполнения действий может потребоваться до 24 часов. Таким образом, выполнение действий политики может занять до 48 часов. Если обновление предназначено для отключения или удаления правила и использовалось свойство enableAutoTierToHotFromCool, данные все равно будут автоматически перенесены на горячий уровень доступа. Например, задайте правило, включающее свойство enableAutoTierToHotFromCool на основе времени последнего обращения. Если правило отключено или удалено, а BLOB-объект находится на холодном уровне при обращении к нему, он будет перемещен обратно на горячий уровень доступа, так как такой подход применяется при доступе за рамками управления жизненным циклом. BLOB-объект после этого не будет перенесен обратно на холодный уровень, если правило управления жизненным циклом отключено или удалено. Единственный способ предотвратить применение autoTierToHotFromCool — отключить отслеживание времени последнего обращения.

Я восстановил заархивированный большой двоичный объект. Как мне предотвратить его временное возвращение на архивный уровень хранилища?

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

  • Добавьте условие daysAfterLastTierChangeGreaterThan в действие tierToArchive политики. Это условие применяется только к времени последнего изменения. См. статью Использование политик управления жизненным циклом для архивации BLOB-объектов.

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

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

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

Поле соответствия префикса большого двоичного объекта политики — это полный или частичный путь к большому двоичному объекту, используемый для сопоставления больших двоичных объектов, к которым должны применяться действия политики. Путь должен начинаться с имени контейнера. Если соответствующий префикс не указан, политика будет применена ко всем BLOB-объектам в учетной записи хранения. Формат соответствующей префиксу строки: [container name]/[blob name].

Помните о следующем в отношении соответствующей префиксу строке:

  • Соответствующая префиксу строка, например container1/, применяется ко всем большим двоичным объектам в контейнере с именем container1. Соответствующая префиксу строка container1 без символа косой черты в конце (/) применяется ко всем большим двоичным объектам во всех контейнерах, где имя контейнера начинается со строки container1. Префикс будет соответствовать контейнерам с именем container11, container1234, container1ab и т. д.
  • Соответствующая префиксу строка container1/sub1/ применяется ко всем большим двоичным объектам в контейнере с именем container1, которые начинаются со строки sub1/. Например, этот префикс будет соответствовать большим двоичным объектам container1/sub1/test.txt и container1/sub1/sub2/test.txt.
  • В имени большого двоичного объекта можно использовать символ звездочки *. Если этот символ применяется в префиксе, последний будет соответствовать большим двоичным объектам со звездочкой в имени. Звездочка не выполняет роль подстановочного знака.
  • В имени большого двоичного объекта можно использовать вопросительный знак ?. Если знак вопроса применяется в префиксе, последний будет соответствовать большим двоичным объектам с вопросительным знаком в имени. Знак вопроса не выполняет роль подстановочного знака.
  • В сопоставлении префиксов учитывается только положительное логическое сравнение (=). Отрицательное логическое сравнение (!=) игнорируется.

Есть ли способ определить время, в течение которого будет выполняться политика?

К сожалению, невозможно отслеживать время выполнения политики, так как это фоновый процесс планирования. Однако платформа будет выполнять политику один раз в день.

Дальнейшие действия