通过自动执行 Azure Blob 存储访问层来优化成本

数据集具有独特的生命周期。 在生命周期的早期,人们经常访问某些数据。 但随着数据的老化,访问需求急剧下降。 有些数据在云中保持空闲状态,并且在存储后很少被访问。 有些数据在创建后的数日或者数月即会过期,还有一些数据集在其整个生存期会频繁受到读取和修改。 Azure Blob 存储生命周期管理为 GPv2 和 Blob 存储帐户提供丰富的基于规则的策略。 可使用该策略将数据转移到适当的访问层,或在数据的生命周期结束时使数据过期。

生命周期管理策略允许:

  • 立即将所访问的 Blob 从冷层转移到热层,以便针对性能进行优化
  • 将一段时间内未访问或修改的 Blob、Blob 版本和 Blob 快照转移到较冷的存储层(从热到冷、从热到存档,或者从冷到存档),以便针对成本进行优化
  • 在 Blob、Blob 版本和 Blob 快照的生命周期结束时将其删除
  • 在存储帐户级别定义每天运行一次的规则
  • 将规则应用到容器或 Blob 子集(使用名称前缀作为筛选器)

假设某个数据集在生命周期的早期阶段频繁被访问,两周后只是偶尔被访问。 一个月以后,该数据集很少被访问。 在这种场景下,早期阶段最适合使用热存储。 在偶尔访问阶段最适合使用冷存储。 在一个月后数据陈旧时,存档存储便是最佳的层选项。 通过根据数据陈旧程度调整存储层,可根据需求设计出最具性价比的存储选项。 若要实现这种过渡,可以使用生命周期管理策略规则将陈旧数据转移到较冷的存储层。

备注

本文中所述的功能现在可用于具有分层命名空间的帐户。 若要查看限制,请参阅 Azure Data Lake Storage Gen2 中可用的 Blob 存储功能一文。

备注

如果需要数据保持可读性(例如,在 StorSimple 使用数据时这样做),请勿设置将 Blob 移到存档层的策略。

可用性和定价

生命周期管理功能在所有 Azure 区域中适用于常规用途 v2 (GPv2) 帐户、Blob 存储帐户、高级块 Blob 存储帐户和 Azure Data Lake Storage Gen2 帐户。 在 Azure 门户中,可将现有的常规用途 (GPv1) 帐户升级为 GPv2 帐户。 有关存储帐户的详细信息,请参阅 Azure 存储帐户概述

生命周期管理功能是免费的。 客户需要支付设置 Blob 层 API 调用的常规操作费用。 删除操作是免费的。 有关定价的详细信息,请参阅块 Blob 定价

添加或删除策略

可以使用以下任一方法来添加、编辑或删除策略:

可以完整读取或写入策略。 不支持部分更新。

备注

如果为存储帐户启用了防火墙规则,生命周期管理请求可能会被阻止。 可以通过为受信任的 Azure 服务提供例外来取消阻止这些请求。 有关详细信息,请参阅配置防火墙和虚拟网络中的“例外”部分。

本文介绍如何使用门户和 PowerShell 方法管理策略。

可以在 Azure 门户中通过两种方式添加策略。

Azure 门户列表视图

  1. 登录到 Azure 门户

  2. 在 Azure 门户中,搜索并选择你的存储帐户。

  3. 在“Blob 服务”下,选择“生命周期管理”以查看或更改规则 。

  4. 选择“列表视图”选项卡。

  5. 选择“添加规则”,然后填写“操作集”窗体字段。 在以下示例中,如果 Blob 有 30 天未修改,它们将转移到冷存储。

    Azure 门户中的生命周期管理操作集页

  6. 选择“筛选器集”添加可选的筛选器。 然后,选择“浏览”以指定作为筛选依据的容器和文件夹。

    Azure 门户中的生命周期管理筛选器集页

  7. 选择“查看 + 添加”以查看策略设置。

  8. 选择“添加”以添加新策略。

Azure 门户代码视图

  1. 登录到 Azure 门户

  2. 在 Azure 门户中,搜索并选择你的存储帐户。

  3. 在“Blob 服务”下,选择“生命周期管理”以查看或更改策略 。

  4. 以下 JSON 是可粘贴到“代码视图”选项卡中的策略示例。

    {
      "rules": [
        {
          "name": "ruleFoo",
          "enabled": true,
          "type": "Lifecycle",
          "definition": {
            "filters": {
              "blobTypes": [ "blockBlob" ],
              "prefixMatch": [ "container1/foo" ]
            },
            "actions": {
              "baseBlob": {
                "tierToCool": { "daysAfterModificationGreaterThan": 30 },
                "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
                "delete": { "daysAfterModificationGreaterThan": 2555 }
              },
              "snapshot": {
                "delete": { "daysAfterCreationGreaterThan": 90 }
              }
            }
          }
        }
      ]
    }
    
  5. 选择“保存” 。

  6. 有关此 JSON 示例的详细信息,请参阅策略规则部分。

策略

生命周期管理策略是 JSON 文档中的规则集合:

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

策略是规则的集合:

参数名称 参数类型 注释
rules 规则对象的数组 一个策略至少需要包含一个规则。 最多可在一个策略中定义 100 个规则。

策略中的每个规则具有多个参数:

参数名称 参数类型 注释 必须
name String 规则名称最多只能包含 256 个字母数字字符。 规则名称区分大小写。 该名称必须在策略中唯一。 True
enabled 布尔 一个允许暂时禁用规则的可选布尔值。 如果未设置,则默认值为 true。 False
type 枚举值 当前的有效类型为 Lifecycle True
definition 定义生命周期规则的对象 每个定义均由筛选器集和操作集组成。 True

规则

每个规则定义包括筛选器集和操作集。 筛选器集将规则操作限制为容器或对象名称中的某组对象。 操作集对筛选的对象集应用分层或删除操作。

示例规则

以下示例规则将筛选帐户,以针对 container1 中存在的、以 foo 开头的对象运行操作。

备注

  • 生命周期管理仅支持块 blob 类型。
  • 生命周期管理不会影响 $logs 和 $web 等系统容器。
  • 在上次修改后的 30 天后,将 Blob 分层到冷层
  • 在上次修改后的 90 天后,将 Blob 分层到存档层
  • 在上次修改后的 2,555 天(7 年)后,删除 Blob
  • 在创建快照后的 90 天后,删除 Blob 快照
{
  "rules": [
    {
      "name": "ruleFoo",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "container1/foo" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 },
            "delete": { "daysAfterModificationGreaterThan": 2555 }
          },
          "snapshot": {
            "delete": { "daysAfterCreationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

规则筛选器

筛选器将规则操作限制为存储帐户中的 Blob子集。 如果定义了多个筛选器,将对所有筛选器运行逻辑 AND

筛选器包括:

筛选器名称 筛选器类型 注释 是否必需
blobTypes 预定义枚举值的数组。 当前版本支持 blockBlob
prefixMatch 要匹配的前缀字符串数组。 每个规则最多可定义 10 个前缀。 前缀字符串必须以容器名称开头。 例如,如果要为某个规则匹配 https://myaccount.blob.core.chinacloudapi.cn/container1/foo/... 下的所有 Blob,则 prefixMatch 为 container1/foo 如果未定义 prefixMatch,规则将应用到存储帐户中的所有 Blob。

规则操作

满足运行条件时,操作将应用到筛选的 Blob。

生命周期管理支持 Blob 的分层和删除,以及 Blob 快照的删除。 在 Blob 或 Blob 快照中为每个规则至少定义一个操作。

操作 基本 Blob 快照
tierToCool 目前支持位于热层的 Blob 支持
tierToArchive 目前支持位于热层或冷层的 Blob 受支持
删除 支持 支持

备注

如果在同一 Blob 中定义了多个操作,生命周期管理将对该 Blob 应用开销最低的操作。 例如,操作 delete 的开销比 tierToArchive 更低。 操作 tierToArchive 的开销比 tierToCool 更低。

运行条件基于期限。 基本 Blob 使用上次修改时间来跟踪陈旧程度,Blob 快照使用快照创建时间来跟踪陈旧程度。

操作运行条件 条件值 说明
daysAfterModificationGreaterThan 指示陈旧程度(天)的整数值 基本 Blob 操作的条件
daysAfterCreationGreaterThan 指示陈旧程度(天)的整数值 Blob 快照操作的条件

示例

以下示例演示如何使用生命周期策略规则满足常见场景。

将陈旧的数据移到冷层

此示例演示如何转移前缀为 container1/foocontainer2/bar 的块 Blob。 该策略将 30 天以上未修改的 Blob 转移到冷存储,并将 90 天未修改的 Blob 转移到存档层:

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

引入数据后对其进行存档

某些数据在云中保持空闲状态,并且在存储后很少(如果有)被访问。 以下生命周期策略已配置为在引入数据后立即对其进行存档。 此示例将容器 archivecontainer 中的存储帐户中的块 Blob 转移到存档层。 转移是通过在上次修改后的 0 天内处理 Blob 实现的:

备注

建议将 blob 直接上传到存档层以提高效率。 可以将 PutBlobPutBlockList 的 x-ms-access-tier 标头用于 REST 版本 2018-11-09 和更新版本或我们的最新 Blob 存储客户端库。

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

基于陈旧程度使数据过期

某些数据预期在创建后的数日或数月内过期。 可以将生命周期管理策略配置为:根据数据陈旧程度删除数据,以使数据过期。 以下示例中演示的策略删除超过 365 天的所有块 Blob。

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

删除旧快照

对于在整个生存期内频繁修改和访问的数据,通常会使用快照来跟踪数据的旧版本。 可以创建一个策略,用于根据快照的陈旧程度删除旧快照。 可通过评估快照创建时间来确定快照的陈旧程度。 此策略规则删除容器 activedata 中自创建快照后达到或超过 90 天的块 Blob 快照。

{
  "rules": [
    {
      "name": "snapshotRule",
      "enabled": true,
      "type": "Lifecycle",
    "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "activedata" ]
        },
        "actions": {
          "snapshot": {
            "delete": { "daysAfterCreationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

常见问题

我创建了一个新策略,但操作为什么没有立即运行?

平台每天运行一次生命周期策略。 配置策略后,某些操作可能需要在长达 24 小时之后才能首次运行。

如果更新现有策略,运行操作需要多长时间?

已更新的策略最多需要 24 小时才能生效。 策略生效后,最多可能需要 24 小时才能执行操作。 因此,策略操作最多可能需要 48 小时才能完成。

我手动解冻了某个存档的 Blob,如何防止它暂时性地移回到存档层?

将 Blob 从一个访问层移到另一个访问层后,其上次修改时间不会更改。 如果手动将存档的 Blob 解冻到热层,生命周期管理引擎会将它移回到存档层。 暂时禁用影响此 Blob 的规则可防止该 Blob 再次存档。 可以安全地将 Blob 移回到存档层时,重新启用该规则即可。 如果需要将 Blob 永久保留在热层或冷层,也可以将其复制到另一个位置。

后续步骤

了解如何在意外删除数据后恢复数据: