Поделиться через

Политики управления жизненным циклом, которые переносят объекты Blob между уровнями

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

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

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

В следующем примере показано перемещение блочных 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 }
          }
        }
      }
    }
  ]
}

Замечание

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

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

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

Подсказка

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

Включение правила с enableAutoTierToHotFromCool применяется только к объектам, которые понижаются в иерархии с этим правилом. Свойство enableAutoTierToHotFromCool нельзя включить для BLOB, которые уже находятся на холодном уровне. Таким образом, уровень доступа 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 дней после последнего изменения.

Это важно

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

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

Замечание

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

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

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

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

Замечание

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

См. также