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

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

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

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

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

Примечание

Функции, описанные в этой статье, также доступны для учетных записей с иерархическим пространством имен. Сведения об ограничениях см. в статье Функции Хранилища BLOB-объектов, доступные в Azure Data Lake Storage 2-го поколения.

Примечание

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

Доступность и расценки

Функция управления жизненным циклом доступна во всех регионах Azure для учетных записей общего назначения v2 (GPv2), учетных записей хранения BLOB-объектов, учетных записей хранения блочных BLOB-объектов класса Premium и учетных записей Azure Data Lake Storage 2-го поколения. В портал Azure можно обновить существующую учетную запись общего назначения (GPv1) до учетной записи GPv2. Дополнительные сведения об учетных записях хранения см. в статье Общие сведения об учетной записи хранения.

Функция управления жизненным циклом не взимается. Клиентам выставляются счета за обычные операции для вызовов API уровня большого двоичного объекта . Операция удаления бесплатна. Дополнительные сведения см. на странице цен на блочные BLOB-объекты.

Добавление или удаление политики

Добавить, изменить или удалить политику можно с помощью любого из следующих методов.

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

Примечание

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

В этой статье показано, как управлять политикой с помощью портала и методов PowerShell.

Существует два способа добавления политики с помощью портал Azure.

Представление списка портал Azure

  1. Войдите на портал Azure.

  2. В портал Azure найдите и выберите свою учетную запись хранения.

  3. В разделе Служба BLOB-объектов выберите Управление жизненным циклом , чтобы просмотреть или изменить правила.

  4. Перейдите на вкладку представление списка .

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

    Управление жизненным циклом Добавление страницы сведений о правиле в портал Azure

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

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

    Параметр Последний доступ доступен в предварительной версии в следующих регионах:

    • Центральная Франция
    • Восточная Канада
    • Центральная Канада

    Важно!

    Предварительная версия отслеживания времени последнего доступа предназначена только для использования в рабочей среде. Соглашения об уровне обслуживания (SLA) для рабочих сред сейчас недоступны.

    Чтобы использовать Последний доступ к параметру, на странице Управление жизненным циклом в портал Azure выберите отслеживание доступа включено . Дополнительные сведения о последнем доступном параметре см. в разделе Перемещение данных на основе даты последнего доступа (Предварительная версия).

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

    Страница "набор фильтров управления жизненным циклом" в портал Azure

  8. Нажмите кнопку Добавить , чтобы добавить новую политику.

Представление кода портал Azure

  1. Войдите на портал Azure.

  2. В портал Azure найдите и выберите свою учетную запись хранения.

  3. В разделе Служба BLOB-объектов выберите Управление жизненным циклом , чтобы просмотреть или изменить политику.

  4. Следующий JSON является примером политики, которую можно вставлять на вкладку представление кода .

    {
      "rules": [
        {
          "enabled": true,
          "name": "move-to-cool",
          "type": "Lifecycle",
          "definition": {
            "actions": {
              "baseBlob": {
                "tierToCool": {
                  "daysAfterModificationGreaterThan": 30
                }
              }
            },
            "filters": {
              "blobTypes": [
                "blockBlob"
              ],
              "prefixMatch": [
                "mylifecyclecontainer/log"
              ]
            }
          }
        }
      ]
    }
    
  5. Щелкните Сохранить.

  6. Дополнительные сведения об этом примере JSON см. в разделах Политика и правила .

Политика

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

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

Политика — это набор правил.

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

Каждое правило в политике имеет несколько параметров:

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

Правила

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

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

В следующем примере правила выполняется фильтрация учетной записи для выполнения действий с объектами, которые существуют внутри container1 и начинаются с foo .

Примечание

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

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

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

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

Имя фильтра Тип фильтра Примечания Обязательный
blobTypes Массив предустановленных значений перечисления. Текущий выпуск поддерживает blockBlob и appendBlob . Поддерживается только удаление, но appendBlob Set Tier не поддерживается. Да
prefixMatch Массив строк для сопоставления префиксов. Каждое правило может определять до 10 префиксов. Строка префикса должно начинаться с имени контейнера. Например, если нужно сопоставить все большие двоичные объекты в https://myaccount.blob.core.windows.net/container1/foo/... правиле, префиксматч имеет значение container1/foo . Если не определить Префиксматч, правило применяется ко всем BLOB-объектам в учетной записи хранения. Нет
блобиндексматч Массив значений словаря, состоящий из ключа тега индекса больших двоичных объектов и условий значения для сопоставления. Каждое правило может определять до 10 условий тега индекса больших двоичных объектов. Например, если вы хотите сопоставить все большие двоичные объекты Project = Contoso с https://myaccount.blob.core.windows.net/ для правила, блобиндексматч имеет значение {"name": "Project","op": "==","value": "Contoso"} . Если не определить Блобиндексматч, правило применяется ко всем BLOB-объектам в учетной записи хранения. Нет

Примечание

Индекс больших двоичных объектов доступен в общедоступной предварительной версии и доступен в регионах " Центральная Канада", " Восточная Канада", " Франция Central" и " Франция ". Дополнительные сведения об этой функции, а также известных проблемах и ограничениях см. в статье Управление данными в хранилище BLOB-объектов Azure и их поиск с помощью индекса больших двоичных объектов (предварительная версия).

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

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

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

Действие Базовый BLOB-объект Моментальный снимок Версия
tierToCool Поддерживается для объекта blockBlob Поддерживается Поддерживается
енаблеаутотиертохотфромкул Поддерживается для объекта blockBlob Не поддерживается Не поддерживается
tierToArchive Поддерживается для объекта blockBlob Поддерживается Поддерживается
удалить Поддерживается для blockBlob и appendBlob Поддерживается Поддерживается

Примечание

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

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

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

Примеры

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

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

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

{
  "rules": [
    {
      "name": "agingRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "container1/foo", "container2/bar" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

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

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

Параметр Последний доступ доступен в предварительной версии в следующих регионах:

  • Центральная Франция
  • Восточная Канада
  • Центральная Канада

Важно!

Предварительная версия отслеживания времени последнего доступа предназначена только для использования в рабочей среде. Соглашения об уровне обслуживания (SLA) для рабочих сред сейчас недоступны.

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

Как работает отслеживание времени последнего доступа

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

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

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

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

Поддержка учетных записей хранения

Отслеживание времени последнего доступа доступно для следующих типов учетных записей хранения:

  • Учетные записи хранения общего назначения версии 2
  • Блокировать учетные записи хранения BLOB-объектов
  • Учетные записи хранения BLOB-объектов

Если ваша учетная запись хранения является учетной записью общего назначения v1, используйте портал Azure для обновления до учетной записи общего назначения версии 2.

Теперь поддерживаются учетные записи хранения с иерархическим пространством имен, доступные для использования с Azure Data Lake Storage 2-го поколения.

Цены и выставление счетов

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

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

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

Примечание

Рекомендуется передать большие двоичные объекты непосредственно на уровне архива, чтобы повысить эффективность. Вы можете использовать заголовок x-MS-Access-уровня для PutBlob или PutBlockList с оставшейся версией 2018-11-09 и более поздней или нашей последней клиентской библиотекой хранилища BLOB-объектов.

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

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

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

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

Удаление данных с помощью тегов индекса больших двоичных объектов

Некоторые данные должны быть просрочены только в том случае, если они явно помечены для удаления. Политику управления жизненным циклом можно настроить для истечения срока действия данных, помеченных атрибутами ключ/значение индекса больших двоичных объектов. В следующем примере показана политика, которая удаляет все блочные BLOB-объекты, помеченные Project = Contoso . Дополнительные сведения об индексе больших двоичных объектов см. в статье Управление данными в хранилище 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"
          ]
        }
      }
    }
  ]
}

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

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

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

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

Обновленная политика вступает в силу до 24 часов. Когда политика вступит в силу, выполнение действий может занять до 24 часов. Поэтому выполнение действий политики может занять до 48 часов.

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

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

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

Узнайте, как восстанавливать данные после случайного удаления:

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