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

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

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

• Transition current versions of a blob, previous versions of a blob, or blob snapshots to a cooler storage tier if these objects haven't been accessed or modified for a period of time, to optimize for cost.-
• Transition blobs back from cool to hot immediately when they're accessed.
• Delete current versions of a blob, previous versions of a blob, or blob snapshots at the end of their lifecycles.
• Применяйте правила ко всей учетной записи хранения, к выбранным контейнерам или подмножеству объектов BLOB, используя префиксы имен или теги индексации объектов BLOB в качестве фильтров.

Lifecycle management policies are supported for block blobs and append blobs in general-purpose v2, premium block blob, and Blob Storage accounts. Управление жизненным циклом не влияет на системные контейнеры, например, $logs и $web.

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

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

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

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

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

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

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

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

Характеристики политики жизненного цикла

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

An active policy processes objects periodically, and is interrupted if changes are made to the policy. Если вы отключите правило, новые запуски не будут запланированы, но если процесс уже запущен, он будет продолжаться до завершения, и вам будет выставлен счет за все операции, необходимые для завершения процесса. Если вы отключаете или удаляете все правила в политике, политика становится неактивной, и новые запуски не будут запланированы.

The time required for a run to complete depends on the number of blobs evaluated and operated on. The latency with which a blob is evaluated and operated on may be longer if the request rate for the storage account approaches the storage account limit. All requests made to storage account, including requests made by policy runs, accrue to the same limit on requests per second, and as that limit approaches, priority is given to requests made by workloads. Чтобы подать запрос на увеличение ограничений для учетной записи, обратитесь в службу поддержки Azure. Дополнительные сведения о характеристиках производительности управления жизненным циклом.

Сведения о ограничениях масштабирования по умолчанию см. в следующих статьях:

• Целевые показатели масштабируемости и производительности для хранилища BLOB-объектов
• Целевые показатели масштабируемости и производительности для учетных записей хранения ценовой категории "Стандартный"
• Цели масштабируемости для учетных записей блочного хранилища BLOB уровня "Премиум"

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

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

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

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

• Tier blob to cool tier 30 days after last modification
• Tier blob to archive tier 90 days after last modification
• Удалить BLOB спустя 2,555 дней (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"
          ]
        }
      }
    }
  ]
}

Rule filters

Filters limit rule actions to a subset of blobs within the storage account. Если определено несколько фильтров, для всех фильтров применяется логическая операция AND. You can use a filter to specify which blobs to include. Фильтр не позволяет указать, какие объекты BLOB следует исключить.

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

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

Rule actions

Actions are applied to the filtered blobs when the run condition is met.

Lifecycle management supports tiering and deletion of current versions, previous versions, and blob snapshots. Определите минимум одно действие для каждого правила.

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

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

³ Политика управления жизненным циклом не удаляет текущую версию объекта BLOB до тех пор, пока не будут удалены все предыдущие версии или снимки, связанные с этим объектом BLOB. If blobs in your storage account have previous versions or snapshots, then you must include previous versions and snapshots when you specify a delete action as part of the policy.

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

The run conditions are based on age. Current versions use the last modified time or last access time, previous versions use the version creation time, and blob snapshots use the snapshot creation time to track age.

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

Lifecycle policy completed event

Событие LifecyclePolicyCompleted активируется при выполнении действий, определенных политикой управления жизненным циклом. Раздел сводки отображается для каждого действия, включенного в определение политики. The following json shows an example LifecyclePolicyCompleted event for a policy. Поскольку определение политики включает в себя действия delete, tierToCool, tierToCold и tierToArchive, для каждого из них отображается сводный раздел.

{
    "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": ""
        },
        "tierToColdSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        },
        "tierToArchiveSummary": {
            "totalObjectsCount": 0,
            "successCount": 0,
            "errorList": ""
        }
    },
    "dataVersion": "1",
    "metadataVersion": "1"
}

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

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

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

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

В следующем примере показано перемещение блочных BLOB-объектов с префиксом имени sample-container/blob1 или container2/blob2. Эта политика перекладывает BLOB-объекты, которые не изменялись более 30 дней, на холодное хранилище, и BLOB-объекты, которые не изменялись 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-объектов. Дополнительные сведения о включении отслеживания времени последнего доступа см. в разделе Необязательное включение отслеживания времени доступа.

When last access time tracking is enabled, the blob property called LastAccessTime is updated when a blob is read or written. Get Blob and Put Blob operations are considered access operations. Get Blob Properties, Get Blob Metadata и Get Blob Tags не являются операциями доступа и, следовательно, не обновляют время последнего доступа.

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

• The value of the LastAccessTime property of the blob is a null value.

  Примечание.

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

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

Чтобы минимизировать влияние на задержку доступа к чтению, только первое чтение за последние 24 часа обновляет время последнего доступа. Subsequent reads in the same 24-hour period don't update the last access time. If a blob is modified between reads, the last access time is the more recent of the two values.

В следующем примере блобы перемещаются на холодное хранилище, если они не использовались в течение 30 дней. The enableAutoTierToHotFromCool property is a Boolean value that indicates whether a blob should automatically be tiered from cool back to hot if it's accessed again after being tiered to cool.

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

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

Некоторые данные хранятся в облаке почти без использования. Следующая политика жизненного цикла настроена для архивирования данных вскоре после их приема. This example transitions block blobs in a container named archivecontainer into an archive tier. The transition is accomplished by acting on blobs 0 days after last modified time.

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

Expire data based on age

Срок действия некоторых данных истекает через несколько дней или месяцев после создания. Вы можете настроить политику управления жизненным циклом, чтобы удалять устаревшие данные при достижении определенного возраста. The following example shows a policy that deletes all block blobs that haven't been modified in the last 365 days.

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

Delete data with blob index tags

Срок действия некоторых данных должен истекать, только в том случае, если они явным образом помечены для удаления. You can configure a lifecycle management policy to expire data that are tagged with blob index key/value attributes. В следующем примере представлена политика, которая удаляет все блочные 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. Операции удаления бесплатны. Однако другие службы и служебные программы Azure, такие как Microsoft Defender для хранилища, могут взимать плату за операции, управляемые политикой жизненного цикла.

Each update to a blob's last access time is billed under the other operations category. Каждое последнее обновление времени доступа рассматривается как "другая транзакция" не более одного раза каждые 24 часа для каждого объекта, даже если к нему обращаются тысячи раз в день. This is separate from read transactions charges.

For more information about pricing, see Block Blob pricing.

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

• Tiering is not yet supported in a premium block blob storage account. For all other accounts, tiering is allowed only on block blobs and not for append and page blobs.

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

• Each rule can have up to 10 case-sensitive prefixes and up to 10 blob index tag conditions.

• A lifecycle management policy can't be used to change the tier of a blob that uses an encryption scope to the archive tier.

• The delete action of a lifecycle management policy won't work with any blob in an immutable container. С помощью неизменяемой политики объекты можно создавать и читать, но не изменять или удалять. Дополнительные сведения см. в статье Хранение критически важных для бизнеса BLOB-данных с помощью неизменяемого хранилища.

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

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

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

• Настройка политики управления жизненным циклом
• Hot, Cool, and Archive access tiers for blob data
• Управление данными в хранилище BLOB-объектов Azure и их поиск с помощью индекса BLOB-объектов
• Best practices for using blob access tiers