Veri yaşam döngüsünü otomatik olarak yöneterek maliyetleri iyileştirme

Veri kümelerinin benzersiz yaşam döngüleri vardır. Yaşam döngüsünün başlarında, insanlar bazı verilere sık sık erişer. Ancak erişim ihtiyacı genellikle veriler yaşlanırken önemli ölçüde azalır. Bazı veriler bulutta boşta kalır ve depolandıktan sonra nadiren erişilir. Bazı veri kümelerinin süresi oluşturulduktan günler veya aylar sonra dolarken, diğer veri kümeleri yaşam süreleri boyunca etkin bir şekilde okunur ve değiştirilir. Azure Depolama yaşam döngüsü yönetimi, blob verilerini uygun erişim katmanlarına geçirmek veya veri yaşam döngüsünün sonunda verilerin süre sonunu belirlemek için kullanabileceğiniz kural tabanlı bir ilke sunar.

Dekont

Her son erişim zamanı güncelleştirmesi, günde 1000 kez erişilmiş olsa bile nesne başına en fazla 24 saatte bir "başka bir işlem" olarak ücretlendirilir. Bu, okuma işlemleri ücretlerinden ayrıdır.

Yaşam döngüsü yönetimi ilkesiyle şunları yapabilirsiniz:

  • Performansı iyileştirmek için blobları seyrek erişimden erişildiğinde hemen sık erişimliye geçirme.
  • Maliyeti iyileştirmek için bir blobun geçerli sürümlerini, blobun önceki sürümlerini veya blob anlık görüntülerini bir süre boyunca bu nesnelere erişilmemiş veya değiştirilmemişse daha serin bir depolama katmanına geçirin.
  • Blobun geçerli sürümlerini, blobun önceki sürümlerini veya blob anlık görüntülerini yaşam döngülerinin sonunda silin.
  • Depolama hesabı düzeyinde günde bir kez çalıştırılacak kuralları tanımlayın.
  • Filtre olarak ad ön eklerini veya blob dizin etiketlerini kullanarak kapsayıcılara veya blobların bir alt kümesine kurallar uygulayın.

Verilere yaşam döngüsünün ilk aşamalarında, ancak yalnızca iki hafta sonra sıklıkla erişildiği bir senaryo düşünün. İlk ayın ötesinde veri kümesine nadiren erişilir. Bu senaryoda, sık erişimli depolama ilk aşamalarda en iyisidir. Seyrek erişimli depolama, ara sıra erişim için en uygun olandır. Arşiv depolama, veriler bir aydan fazla yaşlandıktan sonra en iyi katman seçeneğidir. Yaşam döngüsü yönetimi ilkesi kurallarıyla verileri yaşına göre uygun depolama katmanına taşıyarak, ihtiyaçlarınız için en düşük maliyetli çözümü tasarlayabilirsiniz.

Genel amaçlı v2, premium blok blobu ve Blob Depolama hesaplarında blok blobları ve ekleme blobları için yaşam döngüsü yönetimi ilkeleri desteklenir. Yaşam döngüsü yönetimi veya $web kapsayıcıları gibi sistem kapsayıcılarını $logs etkilemez.

Önemli

Bir veri kümesinin okunabilir olması gerekiyorsa, blobları arşiv katmanına taşımak için bir ilke ayarlamayın. Arşiv katmanındaki bloblar, zaman alan ve pahalı olabilecek bir işlem olan ilk kez yeniden doldurulmadıkça okunamaz. Daha fazla bilgi için bkz . Arşiv katmanından blob yeniden doldurmaya genel bakış. Bir veri kümesinin sık okunması gerekiyorsa, blobları seyrek erişimli veya soğuk katmanlara taşımak için bir ilke ayarlamayın, bu da işlem maliyetlerinin daha yüksek olmasına neden olabilir.

Yaşam döngüsü yönetimi ilkesi tanımı

Yaşam döngüsü yönetimi ilkesi, bir JSON belgesindeki kurallar koleksiyonudur. Aşağıdaki örnek JSON tam bir kural tanımını gösterir:

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

İlke, aşağıdaki tabloda açıklandığı gibi bir kural koleksiyonudur:

Parametre adı Parametre türü Notlar
rules Kural nesneleri dizisi İlkede en az bir kural gereklidir. Bir ilkede en fazla 100 kural tanımlayabilirsiniz.

İlkedeki her kuralın aşağıdaki tabloda açıklanan çeşitli parametreleri vardır:

Parametre adı Parametre türü Notlar Zorunlu
name String Kural adı en fazla 256 alfasayısal karakter içerebilir. Kural adı büyük/küçük harfe duyarlıdır. İlke içinde benzersiz olmalıdır. Doğru
enabled Boolean Kuralın geçici olarak devre dışı bırakılmasına izin vermek için isteğe bağlı boole değeri. Ayarlanmadıysa varsayılan değer true olur. False
type Sabit listesi değeri Geçerli geçerli tür: Lifecycle. Doğru
definition Yaşam döngüsü kuralını tanımlayan nesne Her tanım bir filtre kümesinden ve bir eylem kümesinden oluşur. Doğru

Yaşam döngüsü yönetimi kuralı tanımı

İlke içindeki her kural tanımı bir filtre kümesi ve bir eylem kümesi içerir. Filtre kümesi , kural eylemlerini kapsayıcı veya nesne adları içindeki belirli bir nesne kümesiyle sınırlar. Eylem kümesi katman veya silme eylemlerini filtrelenmiş nesne kümesine uygular.

Örnek kural

Aşağıdaki örnek kural, içinde sample-container bulunan ve ile blob1başlayan nesnelerde eylemleri çalıştırmak için hesabı filtreler.

  • Son değişikliğin ardından 30 gün sonra seyrek erişim katmanına katman blobu
  • Katman blobu son değişiklikden 90 gün sonra arşiv katmanına
  • Son değişiklik sonrasında blobu 2.555 gün (yedi yıl) silme
  • Oluşturma işleminden 90 gün sonra önceki sürümleri silme
{
  "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"
          ]
        }
      }
    }
  ]
}

Dekont

Yaşam döngüsü yönetim ilkesindeki baseBlob öğesi, blobun geçerli sürümüne başvurur. version öğesi önceki bir sürüme başvurur.

Kural filtreleri

Filtreler, kural eylemlerini depolama hesabındaki blobların bir alt kümesiyle sınırlar. Birden fazla filtre tanımlanmışsa, mantıksal AND bir tüm filtrelerde çalışır. Hangi blobların dahilleneceğini belirtmek için filtre kullanabilirsiniz. Filtre, dışlanması gereken blobları belirtmek için hiçbir araç sağlamaz.

Filtreler şunlardır:

Filtre adı Filtre türü Notlar Gerekli
blobTypes Önceden tanımlanmış sabit listesi değerleri dizisi. Geçerli sürüm ve appendBlob'yi desteklerblockBlob. için yalnızca silme desteklenir appendBlob, küme katmanı desteklenmez. Evet
prefixMatch Ön eklerin eşleştirileceği dize dizisi. Her kural en fazla 10 büyük/küçük harfe duyarlı ön ek tanımlayabilir. Ön ek dizesi bir kapsayıcı adıyla başlamalıdır. Örneğin, bir kural için altındaki https://myaccount.blob.core.windows.net/sample-container/blob1/... tüm blobları eşleştirmek istiyorsanız, prefixMatch olur sample-container/blob1.

Kapsayıcı veya blob adıyla tam olarak eşleştirmek için, sondaki eğik çizgiyi ('/'), örneğinsample-container/ veya sample-container/blob1/ekleyin. Kapsayıcı veya blob adı desenini eşleştirmek için, sondaki eğik çizgiyi (ör.sample-container veya sample-container/blob1) atla.
prefixMatch tanımlamazsanız, kural depolama hesabındaki tüm bloblara uygulanır. Ön ek dizeleri joker karakter eşleştirmeyi desteklemez. ve gibi *? karakterler dize değişmez değerleri olarak değerlendirilir. No
blobIndexMatch Blob dizin etiketi anahtarından ve eşleştirilecek değer koşullarından oluşan sözlük değerleri dizisi. Her kural en fazla 10 blob dizini etiketi koşulu tanımlayabilir. Örneğin, bir kural için altındaki https://myaccount.blob.core.windows.net/ tüm blobları ile Project = Contoso eşleştirmek istiyorsanız, blobIndexMatch şeklindedir{"name": "Project","op": "==","value": "Contoso"}. blobIndexMatch tanımlamazsanız, kural depolama hesabındaki tüm bloblar için geçerlidir. No

Blob dizini özelliği hakkında bilinen sorunlar ve sınırlamalarla birlikte daha fazla bilgi edinmek için bkz. Blob diziniyle Azure Blob Depolama verilerini yönetme ve bulma.

Kural eylemleri

Eylemler, çalıştırma koşulu karşılandığında filtrelenmiş bloblara uygulanır.

Yaşam döngüsü yönetimi geçerli sürümlerin, önceki sürümlerin ve blob anlık görüntülerinin katmanlanması ve silinmesini destekler. Her kural için en az bir eylem tanımlayın.

Dekont

Katmanlama, premium blok blob depolama hesabında henüz desteklenmiyor. Diğer tüm hesaplar için katmanlama işlemine yalnızca blok bloblarında izin verilir, ekleme ve sayfa blobları için izin verilmez.

Eylem Geçerli Sürüm Anlık Görüntü Önceki Sürümler
tierToCool Için desteklenir blockBlob Desteklenir Desteklenir
tierToCold Için desteklenir blockBlob Desteklenir Desteklenir
enableAutoTierToHotFromCool1 Için desteklenir blockBlob Desteklenmez Desteklenmez
tierToArchive4 Için desteklenir blockBlob Desteklenir Desteklenir
silme2,3 ve için blockBlob desteklenir appendBlob Desteklenir Desteklenir

1 Eylem enableAutoTierToHotFromCool yalnızca çalıştırma koşuluyla daysAfterLastAccessTimeGreaterThan kullanıldığında kullanılabilir. Bu koşul bir sonraki tabloda açıklanmıştır.

2 Hiyerarşik ad alanı etkinleştirilmiş bir hesaba uygulandığında, silme eylemi boş dizinleri kaldırır. Dizin boş değilse, silme eylemi ilk yaşam döngüsü ilkesi yürütme döngüsü içindeki ilke koşullarına uyan nesneleri kaldırır. Bu eylem, ilke koşullarını da karşılayan boş bir dizinle sonuçlanırsa, bu dizin sonraki yürütme döngüsü içinde kaldırılır ve bu şekilde devam eder.

3 Yaşam döngüsü yönetimi ilkesi, blobla ilişkili önceki sürümler veya anlık görüntüler silinene kadar blobun geçerli sürümünü silmez. Depolama hesabınızdaki blobların önceki sürümleri veya anlık görüntüleri varsa, ilkenin bir parçası olarak silme eylemi belirtirken önceki sürümleri ve anlık görüntüleri eklemeniz gerekir.

4 Yalnızca LRS, GRS veya RA-GRS için yapılandırılmış depolama hesapları blobları arşiv katmanına taşımayı destekler. Arşiv katmanı ZRS, GZRS veya RA-GZRS hesapları için desteklenmez. Bu eylem, hesap için yapılandırılan yedekliliğe göre listelenir.

Dekont

Aynı blob üzerinde birden fazla eylem tanımlarsanız, yaşam döngüsü yönetimi bloba en düşük maliyetli eylemi uygular. Örneğin, eylem eyleminden delete daha tierToArchiveucuzdur. Eylem tierToArchive , eylemden tierToCooldaha ucuzdur.

Çalıştırma koşulları yaşa bağlıdır. Geçerli sürümler son değiştirme zamanını veya son erişim saatini, önceki sürümler sürüm oluşturma zamanını, blob anlık görüntüleri ise yaşı izlemek için anlık görüntü oluşturma süresini kullanır.

Eylem çalıştırma koşulu Koşul değeri Açıklama
daysAfterModificationGreaterThan Gün içindeki yaşı gösteren tamsayı değeri Blobun geçerli sürümündeki eylemlerin koşulu
daysAfterCreationGreaterThan Gün içindeki yaşı gösteren tamsayı değeri Bir blobun veya blob anlık görüntüsünün geçerli sürümündeki veya önceki sürümündeki eylemlerin koşulu
daysAfterLastAccessTimeGreaterThan1 Gün içindeki yaşı gösteren tamsayı değeri Erişim izleme etkinleştirildiğinde blobun geçerli sürümünün koşulu
daysAfterLastTierChangeGreaterThan Son blob katmanı değiştirme zamanından sonraki günlerin yaşını gösteren tamsayı değeri Bu koşul yalnızca eylemler için tierToArchive geçerlidir ve yalnızca koşulla daysAfterModificationGreaterThan kullanılabilir.

1 Son erişim zamanı izleme etkin değilse daysAfterLastAccessTimeGreaterThan, blobun özelliği yerine LastAccessTime yaşam döngüsü ilkesinin etkinleştirildiği tarihi kullanır. Bu tarih, özellik null bir değer olduğunda LastAccessTime da kullanılır. Son erişim zamanı izlemesini kullanma hakkında daha fazla bilgi için bkz . Verileri son erişim zamanına göre taşıma.

Yaşam döngüsü ilkesi çalıştırmaları

Platform, yaşam döngüsü ilkesini günde bir kez çalıştırır. Bir yaşam döngüsü ilkesini yapılandırdığınızda veya düzenlediğinizde değişikliklerin geçerli olması ve ilk yürütmenin başlatılması 24 saate kadar sürebilir. İlke eylemlerinin tamamlanması için geçen süre, değerlendirilen ve çalıştırılan blob sayısına bağlıdır.

Bir ilkeyi devre dışı bırakırsanız, yeni ilke çalıştırmaları zamanlanmaz, ancak bir çalıştırma zaten devam ederse, bu çalıştırma tamamlanana kadar devam eder ve çalıştırmayı tamamlamak için gereken tüm eylemler için faturalandırılırsınız. Bkz. Bölgesel kullanılabilirlik ve fiyatlandırma.

Yaşam döngüsü ilkesi tamamlandı olayı

Yaşam döngüsü yönetimi ilkesi tarafından tanımlanan eylemler gerçekleştirildiğinde LifecyclePolicyCompleted olayı oluşturulur. Aşağıdaki json örneği LifecyclePolicyCompleted bir olayı gösterir.

{
    "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"
}

Aşağıdaki tabloda olayın şeması LifecyclePolicyCompleted açıklanmaktadır.

Alan Tür Açıklama
scheduleTime Dize Yaşam döngüsü ilkesinin zamanlandığı zaman
deleteSummary vektör<bayt> Silme işlemi için zamanlanan blobların sonuç özeti
tierToCoolSummary vektör<bayt> Katmandan seyrek erişimli işleme zamanlanan blobların sonuç özeti
tierToArchiveSummary vektör<bayt> Katmandan arşive işlem için zamanlanan blobların sonuç özeti

Yaşam döngüsü ilkeleri örnekleri

Aşağıdaki örneklerde, yaşam döngüsü ilkesi kurallarıyla yaygın senaryoların nasıl ele alınıyor olduğu gösterilmektedir.

Eskiyen verileri daha serin bir katmana taşıma

Bu örnekte veya container2/blob2ön ekli blok bloblarının nasıl geçirilir sample-container/blob1 gösterilmektedir. İlke, 30 günden fazla süredir değiştirilmemiş blobları seyrek erişimli depolamaya ve 90 gün içinde değiştirilmeyen blobları arşiv katmanına geçirmektedir:

{
  "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 }
          }
        }
      }
    }
  ]
}

Son erişim zamanı temelinde verileri taşıma

Blobunuzun en son ne zaman okunduğuna veya yazıldığından ve blob verilerinizin katmanlanması ve elde tutulmasını yönetmek için filtre olarak kaydını tutmak için son erişim süresi izlemeyi etkinleştirebilirsiniz. Son erişim zamanı izlemeyi etkinleştirmeyi öğrenmek için bkz . İsteğe bağlı olarak erişim süresi izlemeyi etkinleştirme.

Son erişim zamanı izleme etkinleştirildiğinde, blob okunduğunda veya yazıldığında adlı LastAccessTime blob özelliği güncelleştirilir. Blob Alma işlemi erişim işlemi olarak kabul edilir. Blob Özelliklerini Alma, Blob Meta Verilerini Alma ve Blob Etiketlerini Alma işlemleri erişim işlemleri değildir ve bu nedenle son erişim zamanını güncelleştirmez.

Son erişim zamanı izleme etkinleştirildiyse, yaşam döngüsü yönetimi daysAfterLastAccessTimeGreaterThan çalıştırma koşulunun karşılanıp karşılanmadığını belirlemek için kullanırLastAccessTime. Yaşam döngüsü yönetimi, aşağıdaki durumlarda değil LastAccessTime yaşam döngüsü ilkesinin etkinleştirildiği tarihi kullanır:

  • Blobun LastAccessTime özelliğinin değeri null değerdir.

    Dekont

    Son LastAccessTime erişim zamanı izleme etkinleştirildikten sonra bir bloba erişilmemişse blobun özelliği null olur.

  • Son erişim zamanı izleme etkin değil.

Okuma erişimi gecikmesi üzerindeki etkisini en aza indirmek için son 24 saatin yalnızca ilk okuması son erişim saatini güncelleştirir. Aynı 24 saatlik dönemdeki sonraki okumalar son erişim saatini güncelleştirmez. Okumalar arasında bir blob değiştirilirse, son erişim zamanı iki değerin daha yeni olmasıdır.

Aşağıdaki örnekte bloblar 30 gündür erişilmemişse seyrek erişimli depolama alanına taşınır. enableAutoTierToHotFromCool özelliği, seyrek erişimli olarak katmanlandıktan sonra yeniden erişilirse bloba seyrek erişimden sık erişime kadar otomatik olarak katmanlanıp katmanlanmayacağını gösteren bir Boole değeridir.

Bahşiş

Blob seyrek erişim katmanına taşınır ve 30 gün geçmeden otomatik olarak geri taşınırsa erken silme ücreti alınır. Özelliği ayarlamadan enablAutoTierToHotFromCool önce, beklenmeyen ücretleri azaltabilmek için verilerinizin erişim desenlerini analiz etmeye dikkat edin.

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

Alındıktan sonra verileri arşivle

Bazı veriler bulutta boşta kalır ve nadiren erişilir. Aşağıdaki yaşam döngüsü ilkesi, veri alındıktan kısa süre sonra arşivlenmek üzere yapılandırılır. Bu örnek, adlı archivecontainer kapsayıcıdaki blok bloblarını arşiv katmanına geçirmektedir. Geçiş, son değiştirme saatinden 0 gün sonra bloblar üzerinde hareket ederek gerçekleştirilir.

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

Dekont

Microsoft, daha fazla verimlilik için bloblarınızı doğrudan arşiv katmanına yüklemenizi önerir. Arşiv katmanını Blobu Yerleştir veya Blok Listesini Koy işlemindeki x-ms-access-tier üst bilgisinde belirtebilirsiniz. x-ms-access-tier üst bilgisi REST sürüm 2018-11-09 ve daha yeni veya en son blob depolama istemci kitaplıklarıyla desteklenir.

Yaşa göre verilerin süresinin dolması

Bazı verilerin süresi oluşturulduktan günler veya aylar sonra dolması beklenir. Bir yaşam döngüsü yönetim ilkesini, veri yaşına göre silerek verilerin süresinin dolmasına yönelik olarak yapılandırabilirsiniz. Aşağıdaki örnekte, son 365 gün içinde değiştirilmemiş tüm blok bloblarını silen bir ilke gösterilmektedir.

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

Blob dizini etiketleriyle verileri silme

Bazı verilerin süresi yalnızca silinmek üzere açıkça işaretlendiğinde sona ermelidir. Blob dizin anahtarı/değer öznitelikleriyle etiketlenmiş verilerin süresinin dolması için bir yaşam döngüsü yönetimi ilkesi yapılandırabilirsiniz. Aşağıdaki örnekte ile Project = Contosoetiketlenmiş tüm blok bloblarını silecek bir ilke gösterilmektedir. Blob dizini hakkında daha fazla bilgi edinmek için bkz. Blob diziniyle Azure Blob Depolama verilerini yönetme ve bulma.

{
    "rules": [
        {
            "enabled": true,
            "name": "DeleteContosoData",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "delete": {
                            "daysAfterModificationGreaterThan": 0
                        }
                    }
                },
                "filters": {
                    "blobIndexMatch": [
                        {
                            "name": "Project",
                            "op": "==",
                            "value": "Contoso"
                        }
                    ],
                    "blobTypes": [
                        "blockBlob"
                    ]
                }
            }
        }
    ]
}

Önceki sürümleri yönetme

Ömrü boyunca düzenli olarak değiştirilen ve erişilen veriler için, bir nesnenin önceki sürümlerini otomatik olarak korumak için blob depolama sürümü oluşturmayı etkinleştirebilirsiniz. Önceki sürümleri katman eklemek veya silmek için bir ilke oluşturabilirsiniz. Sürüm yaşı, sürüm oluşturma zamanı değerlendirilerek belirlenir. Bu ilke kuralı, kapsayıcı activedata içinde sürüm oluşturulduktan sonra 90 gün veya daha eski olan önceki sürümleri seyrek erişim katmanına taşır ve 365 gün veya daha eski olan önceki sürümleri siler.

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

Bölgesel kullanılabilirlik ve fiyatlandırma

Yaşam döngüsü yönetimi özelliği tüm Azure bölgelerinde kullanılabilir.

Yaşam döngüsü yönetimi ilkeleri ücretsizdir. Blob Katmanı API'sini Ayarla çağrıları için müşteriler standart işlem maliyetleri için faturalandırılır. Silme işlemleri ücretsizdir. Ancak Depolama için Microsoft Defender gibi diğer Azure hizmetleri ve yardımcı programları, yaşam döngüsü ilkesi aracılığıyla yönetilen işlemler için ücret alabilir.

Blob'un son erişim zamanına yapılan her güncelleştirme, diğer işlemler kategorisi altında faturalandırılır.

Fiyatlandırma hakkında daha fazla bilgi için bkz. Blok Blobu fiyatlandırması.

Bilinen sorunlar ve sınırlamalar

  • Katmanlama, premium blok blob depolama hesabında henüz desteklenmiyor. Diğer tüm hesaplar için katmanlama işlemine yalnızca blok bloblarında izin verilir, ekleme ve sayfa blobları için izin verilmez.

  • Yaşam döngüsü yönetimi ilkesinin tam olarak okunması veya yazılması gerekir. Kısmi güncelleştirmeler desteklenmez.

  • Her kuralın en çok 10 büyük/küçük harfe duyarlı ön eki ve en çok 10 blob dizini etiketi koşulu olabilir.

  • Depolama hesabınız için güvenlik duvarı kurallarını etkinleştirirseniz yaşam döngüsü yönetimi istekleri engellenebilir. Güvenilen Microsoft hizmetleri için özel durumlar sağlayarak bu isteklerin engellemesini kaldırabilirsiniz. Daha fazla bilgi için Güvenlik duvarlarını ve sanal ağları yapılandırma bölümündeki Özel Durumlar bölümüne bakın.

  • Yaşam döngüsü yönetimi ilkesi, şifreleme kapsamı kullanan bir blobun katmanını değiştiremez.

  • Yaşam döngüsü yönetimi ilkesinin silme eylemi sabit bir kapsayıcıdaki herhangi bir blobla çalışmaz. Sabit bir ilkeyle, nesneler oluşturulabilir ve okunabilir, ancak değiştirilemez veya silinemez. Daha fazla bilgi için bkz . İş açısından kritik blob verilerini sabit depolama ile depolama.

Sık sorulan sorular (SSS)

Bkz . Yaşam döngüsü yönetimi hakkında SSS.

Sonraki adımlar