自動管理資料生命週期以最佳化成本

發行項
03/20/2024

資料集具有唯一的生命週期。在早期的生命週期中，使用者經常會存取某些資料。但資料存取需求經常會隨著資料存在的時間越來越久而大幅降低。有些資料在雲端維持閒置，而且儲存後就很少存取。有些資料集會在建立後幾天或幾個月過期，而其他資料集在其生命週期內會積極地讀取及修改。 Azure Blob 儲存體生命週期管理提供規則型原則，可讓您用來將 Blob 資料轉換為適當的存取層，或在數據生命週期結束時過期數據。

注意

每更新一次上次存取時間會以「其他交易」的形式收費，而每個物件最多每 24 小時收費一次，即使一天存取 1000 次也是如此。這與讀取交易費用不同。

透過生命週期管理原則，您可以：

在存取 blob 時，立刻將 blob 從非經常性存取轉換為經常性存取，藉此最佳化效能。
如果物件已有一段時間未進行存取或修改，可將目前版本的 Blob、之前版本的 Blob 或 Blob 快照集轉換為非經常性儲存層，藉此將成本最佳化。
在其生命週期結束時刪除目前版本 Blob、之前版本 Blob 或 Blob 快照集。
將規則套用至整個記憶體帳戶、選取容器，或使用名稱前置詞或 Blob 索引卷標作為篩選條件的 Blob 子集。

假設在生命週期初期階段經常存取資料，但在兩周後只會偶爾存取的情況。第一個月過後，即很少存取該資料集。在此情節中，經常性儲存體最適合早期階段。非經常性儲存體最適合偶爾的存取。封存儲存體是資料在經過一個月之後的最佳層選項。藉由根據生命週期管理原則規則，將資料移至適當的儲存層，您可以為需求設計最便宜的解決方案。

生命週期管理原則支援一般用途 v2、高階區塊 Blob 和 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 天 (七年) 後刪除 Blob
在建立後 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"
          ]
        }
      }
    }
  ]
}

注意

生命週期管理原則中的 baseBlob 元素是指目前版本 Blob。 version 元素是指先前版本。

規則篩選

篩選條件會將規則動作限制在儲存體帳戶的 Blob 子集中。如果定義一個以上的篩選條件，則邏輯 AND 會在所有篩選器上執行。您可以使用篩選條件來指定要納入的 Blob。篩選條件無法指定要排除的 Blob。

篩選條件包括：

篩選名稱	篩選類型	備註	是必要的
blobTypes	預先定義列舉值的陣列。	目前的版本支援 `blockBlob` 和 `appendBlob`。僅支援 `appendBlob`刪除動作;不支援設定層。	Yes
prefixMatch	要比對前置詞的字串陣列。每個規則最多可以定義 10 個區分大小寫的前置詞。前置詞字串必須以容器名稱開頭。例如，如果您想要比對下 `https://myaccount.blob.core.windows.net/sample-container/blob1/...`的所有 Blob，請將 prefixMatch 指定為 `sample-container/blob1`。此篩選會比對名稱以 blob1 開頭的 sample-container 中的所有 Blob。 .	如果您未定義 prefixMatch，規則會套用至記憶體帳戶內的所有 Blob。前置詞字串不支援萬用字元比對。系統會將 `*` 和 `?` 這類字元視為字串常值。	No
blobIndexMatch	字典值的陣列，其中包含要比對的 Blob 索引標記索引鍵和值條件。每個規則最多可以定義 10 個 Blob 索引標記條件。例如，如果您想要比對規則的 `https://myaccount.blob.core.windows.net/` 下所有含 `Project = Contoso` 的 Blob，則 blobIndexMatch 會是 `{"name": "Project","op": "==","value": "Contoso"}`。	如果未定義 blobIndexMatchBlob，則規則就會套用至儲存帳戶內的所有 Blob。	No

若要深入了解 Blob 索引功能以及已知的問題和限制，請參閱使用 Blob 索引來管理和尋找 Azure Blob 儲存體上的資料。

規則動作

符合執行條件時，將動作套用至篩選的 Blob。

生命週期管理支援分層以及目前版本、先前版本和 Blob 快照集的刪除。每個規則至少定義一個動作。

注意

進階區塊 Blob 儲存體帳戶目前不支援階層處理。對於所有其他帳戶，階層處理僅適用於區塊 Blob，而不適用於附加 Blob 和分頁 Blob。

動作	目前的版本	快照式	舊版本
tierToCool	支援 `blockBlob`	支援	支援
tierToCold	支援 `blockBlob`	支援	支援
enableAutoTierToHotFromCool¹	支援 `blockBlob`	不支援	不支援
tierToArchive⁴	支援 `blockBlob`	支援	支援
刪除 ^2,3	`blockBlob` 和 `appendBlob` 的支援	支援	支援

¹ 動作 enableAutoTierToHotFromCool 只能與執行條件 daysAfterLastAccessTimeGreaterThan 搭配使用。下一個表格會說明該條件。

² 套用至已啟用階層命名空間的帳戶時，刪除動作會移除空白目錄。如果目錄並非空白，則刪除動作會移除在第一個生命週期原則執行期間內符合原則條件的物件。如果該動作產生了同樣符合原則條件的空白目錄，則該目錄將會在下一個執行循環的週期內移除，依此類推。

³ 在已刪除與該 Blob 相關聯的任何舊版本或快照集之前，生命週期管理原則不會刪除 Blob 的目前版本。如果儲存體帳戶中的 Blob 有舊版或快照集，在您將刪除動作指定為原則的一部分時，必須納入舊版和快照集。

⁴ 只有對 LRS、GRS 或 RA-GRS 設定的儲存體帳戶才支援將 Blob 移至封存儲存層。 ZRS、GZRS 或 RA-GZRS 帳戶不支援封存存取層。系統會根據帳戶設定的備援列出此動作。

注意

如果您在同一個 Blob 上定義超過一個動作，生命週期管理會將成本最低的動作套用至 Blob。例如，動作 delete 的成本比動作 tierToArchive 更低。動作 tierToArchive 的成本比動作 tierToCool 更低。

執行條件是以年齡為基礎。目前版本使用上次修改時間或上次存取時間、先前版本使用版本建立時間，以及 Blob 快照集使用快照集建立時間來追蹤存在時間。

動作執行條件	條件值	描述
daysAfterModificationGreaterThan	指出保留時間的整數值 (天)	對目前版本 Blob 執行動作的條件
daysAfterCreationGreaterThan	指出保留時間的整數值 (天)	目前版本或舊版 Blob 或 Blob 快照集上動作的條件
daysAfterLastAccessTimeGreaterThan¹	指出保留時間的整數值 (天)	啟用存取追蹤時，Blob 目前版本的條件
daysAfterLastTierChangeGreaterThan	指出上次 Blob 層變更後的保留時間整數值 (天)	此條件僅適用於 `tierToArchive` 動作，且僅能搭配 `daysAfterModificationGreaterThan` 條件使用。

¹ 如果未啟用上次存取時間追蹤功能，daysAfterLastAccessTimeGreaterThan 會使用已啟用生命週期原則的日期，而不是 Blob 的 LastAccessTime 屬性。 LastAccessTime 屬性為 null 值時，也會使用此日期。如需使用上次存取時間追蹤的詳細資訊，請參閱根據上次存取時間的移動資料。

生命週期原則執行

平台會每天執行一次生命週期原則。設定或編輯生命週期原則時，最多可能需要 24 小時，變更才會生效並開始第一次執行。完成原則動作所花費的時間取決於評估及操作的 Blob 數目。

若停用某項原則，系統不會排程執行任何新原則，但如果執行正在進行中，該執行將會繼續，直到完成為止；而且，您必須支付完成該執行所需任何動作的費用。請參閱區域可用性和價格。

生命週期原則已完成事件 $部分機器翻譯$

執行生命週期管理原則所定義的動作時會產生 LifecyclePolicyCompleted 事件。下列 json 顯示範例 LifecyclePolicyCompleted 事件。

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

下表描述事件的架構 LifecyclePolicyCompleted。

欄位	類型	描述
scheduleTime	string	已排程生命週期原則的時間
deleteSummary	向量<位元組>	刪除作業排程的 Blob 結果摘要
tierToCoolSummary	向量<位元組>	非經常性存取層作業排程的 Blob 結果摘要
tierToArchiveSummary	向量<位元組>	封存存取層作業排程的 Blob 結果摘要

生命週期原則範例

下列範例示範如何解決生命週期原則規則的常見案例。

將過時資料移至較少存取的階層

此範例示範了如何轉換前置詞為 sample-container/blob1 或 container2/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 標籤不是存取作業，因此不會更新前一次的存取時間。

如果已啟用上次存取時間追蹤，生命週期管理會使用 LastAccessTime 來判斷是否符合執行條件 daysAfterLastAccessTimeGreaterThan。生命週期管理會使用已啟用生命週期原則的日期，而非下列案例中的 LastAccessTime：

Blob 的 LastAccessTime 屬性值是 null 值。

注意

如果 Blob 自上次啟用存取時間追蹤之後都未存取，則 Blob 的 lastAccessedOn 屬性為 null。
未啟用上次存取時間追蹤。

為了將讀取存取延遲的影響降到最低，只有過去 24 小時的第一次讀取會更新前一次的存取時間。在相同 24 小時期間內的後續讀取，不會更新前一次的存取時間。如果在讀取之間修改 Blob，則上次存取時間會是兩個值中的較新值。

在下列範例中，如果 30 天未存取 Blob，則會移至非經常性存取層儲存體。 enableAutoTierToHotFromCool 屬性是一個布林值，指出如果 Blob 在分層到非經常性存取之後再次被存取，是否應自動從非經常性存取層切換至經常性存取層。

提示

如果 Blob 移至非經常性存取層，然後在 30 天內自動移回，則須支付提早刪除費用。設定 enablAutoTierToHotFromCool 屬性之前，請務必分析資料的存取模式，以降低非預期的費用。

{
  "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 轉換為封存層。您可以在上次修改時間後不到一天對 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/"
          ]
        }
      }
    }
  ]
}

區域可用性和定價

生命週期管理功能可在所有 Azure 區域中使用。

生命週期管理原則是免費的。客戶需支付設定 Blob 層 API 呼叫的標準作業成本。刪除作業為免費。不過，像是適用於儲存體的 Microsoft Defender 等其他 Azure 服務和公用程式，可能會針對透過生命週期原則管理的作業進行收費。

每次對 Blob 的上次存取時間進行更新時，都會以其他作業類別為計費。

如需定價詳細資訊，請參閱區塊 Blob 定價。

已知問題與限制

進階區塊 Blob 儲存體帳戶目前不支援階層處理。對於所有其他帳戶，階層處理僅適用於區塊 Blob，而不適用於附加 Blob 和分頁 Blob。
生命週期管理原則必須完整讀取或寫入。不支援部分更新。
每個規則最多可以有 10 個區分大小寫的前置詞，以及最多 10 個 Blob 索引標記條件。
如果您啟用儲存體帳戶的防火牆規則，可能會封鎖生命週期管理要求。您可以藉由為受信任的 Microsoft 服務提供例外狀況來解除封鎖這些要求。如需詳細資訊，請參閱設定防火牆和虛擬網路中的＜例外狀況＞一節。
生命週期管理原則無法變更使用加密範圍的 Blob 層。
生命週期管理原則的刪除動作不適用於位於不可變容器中的任何 Blob。使用不可變原則時，可以建立和讀取物件，但無法加以修改或刪除。如需詳細資訊，請參閱使用不可變儲存體儲存業務關鍵 Blob 資料。

常見問題集 (FAQ)

請參閱生命週期管理常見問題。