Mengoptimalkan biaya dengan mengelola siklus hidup data secara otomatis
Manajemen siklus hidup Azure Blob Storage menawarkan kebijakan berbasis aturan yang dapat Anda gunakan untuk transisi data blob ke tingkat akses yang sesuai atau untuk kedaluwarsa data di akhir siklus hidup data.
Dengan kebijakan manajemen siklus hidup Anda dapat:
- Blob bertransisi dari dingin ke panas seketika jika diakses untuk mengoptimalkan performa.
- Pindahkan blob versi saat ini, blob versi sebelumnya, atau snapshot blob ke tingkat penyimpanan yang lebih dingin jika objek tersebut belum diakses atau diubah dalam jangka waktu tertentu, untuk mengoptimalkan biaya.
- Hapus versi blob saat ini, versi blob sebelumnya, atau snapshot blob di akhir siklus hidupnya.
- Terapkan aturan ke seluruh akun penyimpanan, untuk memilih kontainer, atau ke subset blob menggunakan awalan nama atau tag indeks blob sebagai filter.
Tip
Meskipun manajemen siklus hidup membantu Anda memindahkan data antar tingkatan dalam satu akun, Anda dapat menggunakan tugas penyimpanan untuk menyelesaikan tugas ini dalam skala besar di beberapa akun. Tugas penyimpanan adalah sumber daya yang tersedia di Azure Storage Actions; kerangka kerja tanpa server yang dapat Anda gunakan untuk melakukan operasi data umum pada jutaan objek di beberapa akun penyimpanan. Untuk mempelajari selengkapnya, lihat Apa itu Tindakan Azure Storage?.
Kebijakan manajemen siklus hidup didukung untuk blob blok dan blob tambahan dalam v2 tujuan umum, blob blok premium, dan akun Azure Blob Storage. Manajemen siklus hidup tidak memengaruhi sistem kontainer seperti kontainer $logs atau $web.
Penting
Jika himpunan data perlu dibaca, jangan menetapkan kebijakan untuk memindahkan blob ke tingkat arsip. Blob di tingkat arsip tidak dapat dibaca kecuali pertama kali direhidrasi, sebuah proses yang mungkin memerlukan waktu dan biaya. Untuk informasi selengkapnya, lihat Ringkasan rehidrasi blob dari tingkat arsip. Jika himpunan data perlu sering dibaca, jangan atur kebijakan untuk memindahkan blob ke tingkat dingin atau dingin karena ini dapat mengakibatkan biaya transaksi yang lebih tinggi.
Mengoptimalkan biaya dengan mengelola siklus hidup data
Set data memiliki siklus hidup yang unik. Di awal siklus hidup, orang mengakses beberapa data sering. Tetapi kebutuhan untuk akses kerap turun drastis seiring bertambahnya usia data. Beberapa data tetap idle di cloud dan jarang diakses setelah disimpan. Beberapa data kedaluwarsa berhari-hari atau berbulan-bulan setelah pembuatan, sementara himpunan data lainnya secara aktif dibaca dan dimodifikasi selama masa aktifnya.
Pertimbangkan skenario ketika data sering diakses selama tahap awal siklus hidup, tetapi hanya sekali-sekali setelah dua minggu. Di luar bulan pertama, set data jarang diakses. Di skenario ini, penyimpanan panas adalah yang terbaik selama tahap awal. Penyimpanan dingin paling tepat untuk akses sesekali. Penyimpanan tingkat arsip adalah opsi tingkat terbaik setelah usia data lebih dari sebulan. Dengan memindahkan data ke tingkat penyimpanan yang sesuai berdasarkan usianya dengan aturan kebijakan manajemen siklus hidup, Anda dapat mendesain solusi paling murah untuk kebutuhan Anda.
Definisi kebijakan manajemen siklus hidup
Kebijakan manajemen siklus hidup adalah kumpulan aturan di dokumen JSON. Contoh JSON berikut menampilkan definisi aturan lengkap:
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
Kebijakan adalah kumpulan aturan, seperti yang dijelaskan dalam tabel berikut:
| Nama Parameter | Jenis parameter | Catatan |
|---|---|---|
rules |
Sebuah larik objek aturan | Setidaknya satu aturan diperlukan dalam sebuah kebijakan. Anda dapat mendefinisikan hingga 100 aturan dalam kebijakan. |
Setiap aturan dalam kebijakan memiliki beberapa parameter, yang dijelaskan dalam tabel berikut:
| Nama Parameter | Jenis parameter | Catatan | Wajib |
|---|---|---|---|
name |
String | Nama aturan dapat menyertakan hingga 256 karakter alfanumerik peka huruf besar/kecil. Nama aturannya peka huruf besar/kecil. Itu harus unik dalam sebuah kebijakan. | Benar |
enabled |
Boolean | Boolean opsional untuk mengizinkan aturan dinonaktifkan sementara. Nilai default adalah benar jika belum diatur. | Salah |
type |
Sebuah nilai enum | Jenis yang valid saat ini adalah Lifecycle. |
Benar |
definition |
Sebuah objek yang mendefinisikan aturan siklus hidup | Setiap definisi terdiri dari set filter dan set tindakan. | Benar |
Definisi aturan manajemen siklus hidup
Setiap definisi aturan menyertakan set filter dan set tindakan. Set filter membatasi tindakan aturan ke set objek tertentu dalam nama kontainer atau objek. Set tindakan menerapkan tindakan tingkatan atau penghapusan ke set objek yang difilter.
Aturan sampel
Contoh aturan berikut memfilter akun untuk menjalankan tindakan pada objek yang ada di dalam sample-container dan dimulai dengan blob1.
- Blob tingkat untuk mendinginkan tingkat 30 hari setelah modifikasi terakhir
- Blob tingkat untuk mengarsipkan tingkat 90 hari setelah modifikasi terakhir
- Hapus blob 2.555 hari (tujuh tahun) setelah modifikasi terakhir
- Hapus versi blob sebelumnya 90 hari setelah pembuatan
{
"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"
]
}
}
}
]
}
Catatan
Elemen baseBlob dalam kebijakan manajemen siklus hidup mengacu pada blob versi saat ini. Elemen versi mengacu pada versi sebelumnya.
Filter aturan
Filter membatasi tindakan aturan ke subkumpulan blob dalam akun penyimpanan. Jika lebih dari satu filter didefinisikan, logika AND berjalan di semua filter. Anda dapat menggunakan filter untuk menentukan blob mana yang akan disertakan. Filter tidak menyediakan cara untuk menentukan blob mana yang akan dikecualikan.
Filter mencakup:
| Nama filter | Jenis filter | Catatan | Diperlukan |
|---|---|---|---|
| blobJenis | Sebuah larik dari nilai enum yang telah ditentukan sebelumnya. | Rilis saat ini mendukung blockBlob dan appendBlob. Hanya tindakan Hapus yang didukung untuk appendBlob; Atur Tingkat tidak didukung. |
Ya |
| awalanMatch | Larik hingga 10 string agar prefiks dicocokkan. Setiap aturan dapat mendefinisikan hingga 10 prefiks yang peka huruf besar/kecil. Untai awalan harus dimulai dengan nama kontainer. Misalnya, jika Anda ingin mencocokkan semua blob di bawah https://myaccount.blob.core.windows.net/sample-container/blob1/..., tentukan prefixMatch sebagai sample-container/blob1. Filter ini akan cocok dengan semua blob dalam kontainer sampel yang namanya dimulai dengan blob1.. |
Jika Anda tidak menentukan prefixMatch, aturan berlaku untuk semua blob dalam akun penyimpanan. String awalan tidak mendukung pencocokan kartubebas. Karakter seperti * dan ? diperlakukan sebagai literal string. |
No |
| blobIndeksMatch | Larik nilai kamus yang terdiri dari kunci tag Indeks blob dan kondisi nilai yang akan dicocokkan. Setiap aturan dapat mendefinisikan hingga 10 kondisi tag indeks blob. Misalnya, jika Anda ingin mencocokkan semua blob denganProject = Contoso di bawah https://myaccount.blob.core.windows.net/untuk aturan, blobIndexMatch adalah {"name": "Project","op": "==","value": "Contoso"}. |
Jika Anda tidak mendefinisikan blobIndexMatch, aturan tersebut berlaku untuk semua blob dalam akun penyimpanan. | No |
Untuk mempelajari selengkapnya tentang fitur indeks blob ini bersama dengan masalah dan batasan yang diketahui, lihat Kelola dan temukan data tentang Azure Blob Storage dengan indeks blob.
Tindakan-tindakan aturan
Tindakan diterapkan ke blob yang difilter saat kondisi jalankan terpenuhi.
Manajemen siklus hidup mendukung tingkatan dan penghapusan blob versi saat ini, blob versi sebelumnya, dan snapshot blob. Tentukan minimal satu tindakan untuk setiap aturan.
Catatan
Tingkatan belum didukung di akun penyimpanan blob blok premium. Untuk semua akun lain, penjenjangan hanya diizinkan pada blob blok dan bukan untuk blob penambahan dan halaman.
| Perbuatan | Versi Saat Ini | Snapshot | Versi Sebelumnya |
|---|---|---|---|
| tierToDingin | Dukungan untuk blockBlob |
Didukung | Didukung |
| tierToCold | Dukungan untuk blockBlob |
Didukung | Didukung |
| enableAutoTierToHotFromCool1 | Dukungan untuk blockBlob |
Tidak didukung | Tidak didukung |
| tierToArchive4 | Dukungan untuk blockBlob |
Didukung | Didukung |
| hapus2,3 | Dukungan untuk blockBlob dan appendBlob |
Didukung | Didukung |
1 Tindakan enableAutoTierToHotFromCool hanya tersedia saat digunakan dengan daysAfterLastAccessTimeGreaterThan kondisi eksekusi. Kondisi tersebut dijelaskan dalam tabel berikutnya.
2 Saat diterapkan ke akun dengan namespace hierarki diaktifkan, tindakan hapus akan menghapus direktori kosong. Jika direktori tidak kosong, tindakan hapus akan menghapus objek yang memenuhi kondisi kebijakan dalam siklus eksekusi kebijakan siklus hidup pertama. Jika tindakan tersebut menghasilkan direktori kosong yang juga memenuhi kondisi kebijakan, maka direktori tersebut akan dihapus dalam siklus eksekusi berikutnya, dan sebagainya.
3 Kebijakan manajemen siklus hidup tidak akan menghapus versi blob saat ini hingga versi atau rekam jepret sebelumnya yang terkait dengan blob tersebut telah dihapus. Jika blob di akun penyimpanan Anda memiliki versi atau rekam jepret sebelumnya, maka Anda harus menyertakan versi dan rekam jepret sebelumnya saat menentukan tindakan penghapusan sebagai bagian dari kebijakan.
4 Hanya akun penyimpanan yang dikonfigurasi untuk LRS, GRS, atau RA-GRS yang mendukung pemindahan blob ke tingkat arsip. Tingkat arsip tidak didukung untuk akun ZRS, GZRS, atau RA-GZRS. Tindakan ini dicantumkan berdasarkan redundansi yang dikonfigurasi untuk akun tersebut.
Catatan
Jika Anda mendefinisikan lebih dari satu tindakan pada blob yang sama, manajemen siklus hidup menerapkan tindakan paling murah ke blob. Misalnya, tindakan delete lebih murah daripada tindakan tierToArchive. Tindakan tierToArchive adalah lebih murah daripada tierToCool tindakan.
Kondisi eksekusi berdasarkan pada usia. Versi saat ini menggunakan waktu terakhir diubah atau waktu terakhir akses, versi sebelumnya menggunakan waktu pembuatan versi, dan snapshot blob menggunakan waktu pembuatan snapshot untuk melacak usia.
| Kondisi eksekusi tindakan | Nilai kondisi | Deskripsi |
|---|---|---|
| daysAfterModifikasiGreaterThan | Nilai bilangan bulat yang menunjukkan usia dalam hari | Syarat untuk tindakan pada blob versi saat ini |
| daysAfterKreasiGreaterThan | Nilai bilangan bulat yang menunjukkan usia dalam hari | Kondisi untuk tindakan pada versi saat ini atau versi blob sebelumnya atau rekam jepret blob |
| daysAfterLastAccessTimeGreaterThan1 | Nilai bilangan bulat yang menunjukkan usia dalam hari | Syarat untuk blob versi saat ini ketika pelacakan akses diaktifkan |
| daysAfterLastTierChangeGreaterThan | Nilai bilangan bulat yang menunjukkan jangka waktu dalam hari sejak waktu perubahan tingkat blob terakhir | Syarat ini hanya berlaku untuk tindakan tierToArchive dan hanya dapat digunakan dengan syarat daysAfterModificationGreaterThan. |
1 Jika pelacakan waktu akses terakhir tidak diaktifkan, daysAfterLastAccessTimeGreaterThan menggunakan tanggal kebijakan siklus hidup diaktifkan alih-alih LastAccessTime properti blob. Tanggal ini juga digunakan ketika LastAccessTime properti adalah nilai null. Untuk informasi selengkapnya tentang menggunakan pelacakan waktu akses terakhir, lihat Memindahkan data berdasarkan waktu terakhir yang diakses.
Kebijakan siklus hidup berjalan
Platform mengeksekusi kebijakan siklus hidup sekali sehari. Saat Anda mengonfigurasi atau mengedit kebijakan siklus hidup., diperlukan waktu hingga 24 jam agar perubahan diterapkan dan agar eksekusi pertama dimulai. Waktu yang diambil untuk tindakan kebijakan selesai tergantung pada jumlah blob yang dievaluasi dan dioperasikan.
Jika Anda menonaktifkan kebijakan, maka tidak ada kebijakan baru yang dijalankan yang akan dijadwalkan, tetapi jika eksekusi sudah berlangsung, eksekusi tersebut akan berlanjut hingga selesai dan Anda ditagih untuk tindakan apa pun yang diperlukan untuk menyelesaikan eksekusi. Lihat Ketersediaan dan harga regional.
Peristiwa kebijakan siklus hidup yang selesai
Peristiwa LifecyclePolicyCompleted dibuat saat tindakan yang ditentukan oleh kebijakan manajemen siklus hidup dilakukan. Json berikut menampilkan contoh kejadian 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"
}
Tabel berikut menjelaskan skema kejadian LifecyclePolicyCompleted.
| Bidang | Jenis | Deskripsi |
|---|---|---|
| scheduleTime | string | Waktu kebijakan siklus hidup dijadwalkan |
| deleteSummary | byte vektor<> | Ringkasan hasil blob yang dijadwalkan untuk operasi penghapusan |
| tierToCoolSummary | byte vektor<> | Ringkasan hasil blob yang dijadwalkan untuk operasi tingkat ke dingin |
| tierToArchiveSummary | byte vektor<> | Ringkasan hasil blob yang dijadwalkan untuk operasi tingkat ke arsip |
Contoh kebijakan siklus hidup
Contoh berikut menunjukkan cara mengatasi skenario yang umum dengan aturan kebijakan siklus hidup.
Pindahkan data penuaan ke tingkat yang lebih dingin
Contoh ini menunjukkan cara transisi blok blob prefixed dengan sample-container/blob1 atau container2/blob2. Blob transisi kebijakan yang belum dimodifikasi dalam lebih dari 30 hari ke penyimpanan dingin, dan blob tidak dimodifikasi dalam 90 hari ke tingkat arsip:
{
"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 }
}
}
}
}
]
}
Pindahkan data berdasarkan waktu terakhir diakses
Anda dapat mengaktifkan pelacakan waktu akses terakhir untuk menyimpan catatan kapan blob Anda terakhir dibaca atau ditulis dan sebagai filter untuk mengelola jenjang dan retensi data blob Anda. Untuk mempelajari cara mengaktifkan pelacakan akses, lihat Mengaktifkan pelacakan waktu akses secara opsional.
Ketika pelacakan waktu akses terakhir diaktifkan, properti blob LastAccessTime yang disebut diperbarui saat blob dibaca atau ditulis. Operasi Dapatkan Blob dianggap sebagai operasi akses. Mendapatkan Properti Blob, Mendapatkan Blob Metadata, dan Mendapatkan Tag Blob tidak mengakses operasi, dan karena itu jangan memperbarui waktu akses terakhir.
Jika pelacakan waktu akses terakhir diaktifkan, manajemen siklus hidup menggunakan LastAccessTime untuk menentukan apakah hari kondisi eksekusiAfterLastAccessTimeGreaterThan terpenuhi. Manajemen siklus hidup menggunakan tanggal kebijakan siklus hidup diaktifkan alih-alih LastAccessTime dalam kasus berikut:
Nilai
LastAccessTimeproperti blob adalah nilai null.Catatan
Properti
lastAccessedOnblob null jika blob belum diakses sejak pelacakan waktu akses terakhir diaktifkan.Pelacakan waktu akses terakhir tidak diaktifkan.
Untuk meminimalkan dampak pada latensi akses baca, baca pertama saja dari 24 jam terakhir yang memperbarui waktu akses terakhir. Pembacaan berikutnya dalam periode 24 jam yang sama tidak memperbarui waktu akses terakhir. Jika blob dimodifikasi di antara pembacaan, waktu akses terakhir adalah yang lebih baru dari dua nilai.
Dalam contoh berikut, blob dipindahkan ke penyimpanan dingin jika belum dimodifikasi selama 30 hari. Properti enableAutoTierToHotFromCool ini adalah nilai Boolean yang menunjukkan apakah blob harus secara otomatis diurutkan dari dingin kembali ke panas jika diakses lagi setelah ditingkatkan menjadi dingin.
Tip
Jika blob dipindahkan ke tingkat dingin, dan kemudian secara otomatis dipindahkan kembali sebelum 30 hari berlalu, biaya penghapusan awal akan dikenakan. Sebelum Anda mengatur enablAutoTierToHotFromCool properti, pastikan untuk menganalisis pola akses data Anda sehingga Anda dapat mengurangi biaya yang tidak terduga.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
Arsipkan data setelah menelan
Beberapa data tetap menganggur di cloud dan jarang diakses. Kebijakan siklus hidup berikut dikonfigurasikan untuk mengarsipkan data tak lama setelah tertelan. Contoh transisi ini memblokir blob blok dalam kontainer bernama archivecontainer ke tingkat arsip. Transisi dicapai dengan bertindak pada blob 0 hari sejak terakhir kali dimodifikasi.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
Catatan
Microsoft menyarankan agar Anda mengunggah blob langsung ke tingkat arsip untuk efisiensi yang lebih besar. Anda dapat menetapkan tingkat arsip di header x-ms-access-tier pada operasi Tempatkan Blob atau Tempatkan Daftar Blok. Header x-ms-access-tier didukung oleh versi REST 2018-11-09 dan yang lebih baru atau perpustakaan klien penyimpanan blob terbaru.
Data kedaluwarsa didasarkan pada usia
Beberapa data diperkirakan akan kedaluwarsa beberapa hari atau bulan setelah pembuatan. Anda dapat mengonfigurasi kebijakan manajemen siklus hidup untuk data kedaluwarsa dengan penghapusan berdasarkan usia data. Contoh berikut menunjukkan kebijakan yang menghapus semua blob blok yang belum diubah dalam 365 hari terakhir.
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
Hapus data dengan tag indeks blob
Beberapa data sebaiknya hanya kedaluwarsa jika ditandai secara eksplisit untuk dihapus. Anda dapat mengonfigurasi kebijakan manajemen siklus hidup untuk kedaluwarsa data yang ditandai dengan atribut kunci/nilai indeks blob. Contoh berikut menunjukkan kebijakan yang menghapus semua blob blok ditandai dengan Project = Contoso. Untuk mempelajari selengkapnya tentang indeks blob, lihat Mengelola dan menemukan data di Azure Blob Storage dengan indeks blob.
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
Mengelola versi sebelumnya
Untuk data yang dimodifikasi dan diakses secara teratur selama masa pakainya, Anda dapat mengaktifkan versi penyimpanan blob untuk secara otomatis mempertahankan versi objek sebelumnya. Anda dapat membuat kebijakan untuk meningkatkan atau menghapus versi sebelumnya. Usia versi ditentukan dengan mengevaluasi waktu penciptaan versi. Aturan kebijakan ini meningkatkan versi sebelumnya dalam kontainer activedata yang merupakan 90 hari atau lebih setelah pembuatan versi ke tingkat yang dingin, dan menghapus versi sebelumnya yang merupakan 365 hari atau lebih.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
Ketersediaan wilayah dan harga
Fitur manajemen siklus hidup tersedia di semua wilayah Azure.
Kebijakan manajemen siklus hidup tidak dipungut biaya. Pelanggan ditagihkan biaya operasi standar untuk panggilan API Tetapkan Tingkat Blob. Operasi penghapusan gratis. Namun, layanan dan utilitas Azure lainnya seperti Microsoft Defender untuk Storage dapat dikenakan biaya untuk operasi yang dikelola melalui kebijakan siklus hidup.
Setiap pembaruan untuk waktu akses terakhir blob ditagihkan di bawah kategori operasi lainnya. Setiap pembaruan waktu akses terakhir dibebankan sebagai "transaksi lain" paling banyak setiap 24 jam sekali per objek bahkan jika diakses 1000 kali dalam sehari. Ini terpisah dari biaya transaksi baca.
Untuk informasi selengkapnya tentang harga, lihat Harga Blok Blob .
Masalah dan batasan yang diketahui
Tingkatan belum didukung di akun penyimpanan blob blok premium. Untuk semua akun lain, penjenjangan hanya diizinkan pada blob blok dan bukan untuk blob penambahan dan halaman.
Kebijakan manajemen siklus hidup harus dibaca atau dituliskan secara lengkap. Pembaruan sebagian tidak didukung.
Setiap aturan dapat memiliki hingga 10 prefiks peka huruf besar/kecil dan hingga 10 kondisi tag indeks blob.
Jika Anda mengaktifkan aturan firewall untuk akun penyimpanan Anda, permintaan manajemen siklus hidup dapat diblokir. Anda dapat membuka blokir permintaan ini dengan menyediakan pengecualian untuk layanan Microsoft tepercaya. Untuk informasi selengkapnya, lihat bagian Pengecualian dalam Mengonfigurasi firewall dan jaringan virtual.
Kebijakan manajemen siklus hidup tidak dapat mengubah tingkat blob yang menggunakan cakupan enkripsi.
Tindakan penghapusan kebijakan manajemen siklus hidup tidak akan berfungsi dengan blob apa pun dalam kontainer yang tidak dapat diubah. Dengan kebijakan yang tidak dapat diubah, objek dapat dibuat dan dibaca, tetapi tidak dimodifikasi atau dihapus. Untuk informasi selengkapnya, lihat Menyimpan data blob bisnis kritis dengan penyimpanan imutabel.
Pertanyaan Umum (FAQ)
Lihat Tanya Jawab Umum manajemen siklus hidup.