你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

通过自动管理数据生命周期优化成本

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

注意

每次“上次访问时间”更新都会作为“其他事务”被收取费用,24 小时内最多对每个对象收取一次费用,即使它在一天内被访问了 1000 次。 这与读取事务费用是分开的。

利用生命周期管理策略,可以实现以下操作:

  • 即时将所访问的 Blob 从冷层转移到热层,以便优化性能。
  • 将一段时间内未访问或修改的 Blob 当前版本、Blob 旧版本和 Blob 快照转移到较冷的存储层,以便优化成本。 在这种情况下,生命周期管理策略可以将对象从“热层”移动到“冷层”、从“热层”移动到“存档层”或从“冷层”移动到“存档层”。
  • 在其周期结束时,删除 blob 当前版本、blob 旧版本或 blob 快照。
  • 在存储帐户级别定义每天运行一次的规则。
  • 将规则应用于容器或 Blob 子集(使用名称前缀或 Blob 索引标记作为筛选器)。

假设某个数据集在生命周期的早期阶段频繁被访问,而两周后只是偶尔被访问。 一个月以后,该数据集很少被访问。 在这种场景下,早期阶段最适合使用热存储。 在偶尔访问阶段最适合使用冷存储。 在一个月后数据陈旧时,存档存储便是最佳的层选项。 借助生命周期管理策略规则,根据数据存在时间将其移动到适当的存储层,即可根据需要设计成本最低的解决方案。

生命周期管理策略支持块 Blob,并可在常规用途 v2、高级块 Blob 和 Blob 存储帐户中追加 Blob。 生命周期管理不会影响诸如 $logs$web 之类的系统容器。

重要

如需将数据集设置为可读,则请不要设置将 Blob 移动到存档层的策略。 除非 Blob 是首个解除冻结对象,否则无法读取存档层中的 Blob,且这一过程可能既耗时又昂贵。 有关详细信息,请参阅存档层中的 blob 解除冻结概述

生命周期管理策略定义

生命周期管理策略是 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

生命周期管理规则定义

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

示例规则

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

  • 在上次修改后的 30 天后,将 Blob 分层到冷层
  • 在上次修改后的 90 天后,将 Blob 分层到存档层
  • 在上次修改后的 2,555 天(7 年)后,删除 Blob
  • 在创建 90 天后删除以前的 Blob 版本
{
  "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 预定义枚举值的数组。 当前版本支持 blockBlobappendBlobappendBlob 仅支持删除,不支持设置层级。
prefixMatch 要匹配的前缀字符串数组。 每个规则最多可定义 10 个区分大小写的前缀。 前缀字符串必须以容器名称开头。 例如,如果要为某个规则匹配 https://myaccount.blob.core.windows.net/sample-container/blob1/... 下的所有 Blob,则 prefixMatch 为 sample-container/blob1 如果未定义 prefixMatch,规则将应用到存储帐户中的所有 Blob。
blobIndexMatch 由要匹配的 Blob 索引标记键和值条件组成的字典值数组。 每个规则最多可以定义 10 个 Blob 索引标记条件。 例如,对于某个规则,如果要匹配 https://myaccount.blob.core.windows.net/Project = Contoso 的所有 Blob,则 blobIndexMatch 为 {"name": "Project","op": "==","value": "Contoso"} 如果未定义 blobIndexMatch,则规则将应用于存储帐户中的所有 Blob。

若要详细了解 Blob 索引功能以及已知问题和限制,请参阅通过 Blob 索引管理和查找 Azure Blob 存储上的数据

规则操作

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

生命周期管理支持对 Blob 当前版本的分层和删除操作,并支持早期 Blob 版本和 Blob 快照。 为每条规则至少定义一个操作。

注意

高级块 blob 存储帐户尚不支持分层。 对于所有其他帐户,仅允许在块 blob 上进行分层,而不允许在追加和页 blob 上分层。

操作 当前版本 快照 早期版本
tierToCool blockBlob 支持 支持 支持
enableAutoTierToHotFromCool blockBlob 支持 不支持 不支持
tierToArchive blockBlob 支持 支持 支持
delete1 支持 blockBlobappendBlob 支持 支持

1 当应用于已启用分层命名空间的帐户时,delete 操作将删除空目录。 如果目录不为空,则 delete 操作会在第一个 24 小时周期内删除满足策略条件的对象。 如果该操作产生的空目录也满足策略条件,则该目录将在下一个 24 小时周期内被删除,依此类推。

注意

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

运行条件基于期限。 为了跟踪陈旧程度,当前版本使用上次修改时间或上次访问时间,旧版本使用版本创建时间,blob 快照使用快照创建时间。

操作运行条件 条件值 说明
daysAfterModificationGreaterThan 指示陈旧程度(天)的整数值 对 blob 的当前版本执行操作的条件
daysAfterCreationGreaterThan 指示陈旧程度(天)的整数值 对 Blob 旧版本或 Blob 快照执行操作的条件
daysAfterLastAccessTimeGreaterThan 指示陈旧程度(天)的整数值 启用访问跟踪时 Blob 当前版本的条件
daysAfterLastTierChangeGreaterThan 整数值,指示自上次 blob 层更改时间后的天数 此条件仅适用于 tierToArchive 操作,并且只能与 daysAfterModificationGreaterThan 条件一起使用。

生命周期策略示例

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

将陈旧的数据移到冷层

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

{
  "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 数据的分层和保留。 若要了解如何启用“上次访问时间跟踪”,请参阅启用访问时间跟踪(可选)

启用上次访问时间跟踪后,在读取或写入 Blob 时会更新名为 LastAccessTime 的 Blob 属性。 获取 Blob 操作被视为访问操作。 获取 Blob 属性获取 Blob 元数据获取 Blob 标记不是访问操作,因此不会更新上次访问时间。

为了尽量减少对读取访问延迟的影响,只有最近 24 小时的第一次读取会更新最后访问时间。 同一个 24 小时期间内的后续读取不会更新上次访问时间。 如果 Blob 在两次读取之间被修改,则上次访问时间是两个值中的较新值。

在以下示例中,如果 Blob 在 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"
      ]
    }
  }
}

引入数据后对其进行存档

某些数据在云中处于空闲状态,并且很少(如果有)被访问。 以下生命周期策略已配置为在引入数据后立即对其进行存档。 此示例将容器中名为 archivecontainer 的块 Blob 转换为存档层。 通过在上次修改时间后 0 天对 blob 执行操作来完成转换。

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

注意

Microsoft 建议直接将 Blob 上传到存档层,以提高效率。 可以在 放置 Blob放置块列表操作内的“x-ms-access-tier”标头中指定存档层。 REST 版本 2018-11-09 及更高版本,或最新的 Blob 存储客户端库支持“x-ms-access-tier”标头。

基于陈旧程度使数据过期

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

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

删除带 Blob 索引标记的数据

某些数据只有在明确标记为删除时才会过期。 你可以配置生命周期管理策略,使标记有 Blob 索引键/值属性的数据过期。 以下示例中演示的策略会删除标有 Project = Contoso 的所有块 Blob。 若要详细了解 Blob 索引,请参阅通过 Blob 索引管理和查找 Azure Blob 存储上的数据

{
    "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 Gen2、网络文件系统 (NFS) 3.0 协议或 SSH 文件传输协议 (SFTP) 可能会影响对此功能的支持。

如果已启用这些功能中的某一项,请参阅 Azure 存储帐户中的 Blob 存储功能支持,以评估对此功能的支持。

区域可用性和定价

生命周期管理功能在所有 Azure 区域中均可用。

生命周期管理策略不收取费用。 不过客户需要支付设置 Blob 层 API 调用的标准操作成本费用, 而删除操作亦不会收取费用。 但是,其他 Azure 服务和实用程序(例如 Microsoft Defender for Storage)可能会对通过生命周期策略管理的操作收费。

需要在其他操作类别下支付每次 Blob 的“上次访问时间”更新所需的费用。

有关定价的详细信息,请参阅块 Blob 定价

常见问题

我已经创建了一个新策略。 为什么操作不会立即运行?

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

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

已更新的策略最多需要 24 小时才能生效。 策略生效后,最多可能需要 24 小时才能执行操作。 因此,策略操作最多可能需要 48 小时才能完成。 如果更新是禁用或删除规则,并且使用了 enableAutoTierToHotFromCool,则仍将发生自动分层到热层的情况。 例如,根据上次访问设置一个包含 enableAutoTierToHotFromCool 的规则。 如果规则处于禁用/删除状态,并且 blob 当前处于冷状态并随后被访问,则该 blob 将会移回热层,因为该规则是对生命周期管理外部的访问而应用的。 如果生命周期管理规则被禁用/删除,则 Blob 不会从热层移动到冷层。 阻止 autoTierToHotFromCool 的唯一方法就是关闭上次访问时间跟踪。

我解除了存档 Blob 的冻结。 如何防止它暂时性地移回到存档层?

如果存在对存储帐户有效的生命周期管理策略,则通过更改 blob 的层来解除 blob 的冻结可能会导致生命周期策略将 blob 移回存档层的情况。 如果上次修改时间、创建时间或上次访问时间超出为策略设置的阈值,则可能会发生这种情况。 有三种方法可以阻止这种情况发生:

  • daysAfterLastTierChangeGreaterThan 条件添加到策略的 tierToArchive 操作。 此条件仅适用于上次修改时间。 请参阅使用生命周期管理策略存档 Blob

  • 暂时禁用影响此 Blob 的规则可防止该 Blob 再次存档。 可以安全地将 Blob 移回到存档层时,重新启用该规则即可。

  • 如果 blob 需要永久保留在热访问层或冷访问层中,请将 blob 复制到生命周期管理策略未生效的另一个位置。

Blob 前缀匹配字符串未将策略应用于预期的 Blob

策略的 Blob 前缀匹配字段是完整或部分 Blob 路径,用于匹配要将策略操作应用到的 Blob。 路径必须以容器名称开头。 如果未指定前缀匹配,则策略将应用到存储帐户中的所有 Blob。 前缀匹配字符串的格式为 [container name]/[blob name]

对于前缀匹配字符串,请注意以下几点:

  • 前缀匹配字符串(如 container1/) 适用于名为 container1 的容器中的所有 blob。 container1 的前缀匹配字符串(不带尾部正斜杠字符 (/))适用于容器名称以字符串 container1 开头的所有容器中的所有 blob。 此前缀将匹配名为 container11、container1234、container1ab 之类的容器。
  • container1/sub1/ 前缀匹配字符串适用于名为 container1 的容器中以字符串 sub1/ 开头的所有 blob。 例如,前缀将匹配名为 container1/sub1/test.txt 或 container1/sub1/sub2/test.txt 的 blob。
  • 星号字符 * 是 blob 名称中的有效字符。 如果在前缀中使用星号字符,则前缀将匹配名称中带有星号的 blob。 星号不会起到通配符的作用。
  • 问号字符 ? 是 blob 名称中的有效字符。 如果在前缀中使用问号字符,则前缀将匹配名称中带有问号的 blob。 问号不会起到通配符的作用。
  • 前缀匹配只考虑正 (=) 逻辑比较。 会忽略否定 (!=) 逻辑比较。

是否有办法确定策略将执行的时间?

很抱歉,无法跟踪策略将执行的时间,因为它是一个后台计划过程。 但是,平台将每天运行一次策略。

后续步骤