Mengoptimalkan biaya dengan mengelola siklus hidup data secara otomatis

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. Manajemen siklus hidup Azure Storage menawarkan kebijakan berbasis aturan yang dapat Anda gunakan untuk mentransisikan data Anda ke tingkat penyimpanan terbaik dan menghentikan data di akhir siklus hidupnya.

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. Dalam skenario ini, kebijakan manajemen siklus hidup dapat memindahkan objek dari panas ke dingin, dari panas ke arsip, atau dari dingin ke arsip.
  • Hapus versi blob saat ini, versi blob sebelumnya, atau snapshot blob di akhir siklus hidupnya.
  • Tentukan aturan yang akan dijalankan sekali per hari di tingkat akun penyimpanan.
  • Menerapkan aturan ke kontainer atau subset blob, menggunakan awalan atau tag indeks blob sebagai filter.

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.

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.

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 Diperlukan
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. True
enabled Boolean Boolean opsional untuk mengizinkan aturan dinonaktifkan sementara. Nilai default adalah benar jika belum diatur. FALSE
type Sebuah nilai enum Jenis yang valid saat ini adalah Lifecycle. True
definition Sebuah objek yang mendefinisikan aturan siklus hidup Setiap definisi terdiri dari set filter dan set tindakan. True

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.

Filter mencakup:

Nama filter Jenis filter Catatan Diperlukan
blobTypes Sebuah larik dari nilai enum yang telah ditentukan sebelumnya. Rilis saat ini mendukung blockBlob dan appendBlob. Hanya penghapusan yang didukung untuk appendBlob, set tingkat yang tidak didukung. Ya
prefixMatch 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 https://myaccount.blob.core.windows.net/sample-container/blob1/... bawah untuk aturan, prefixMatch adalah sample-container/blob1. Jika Anda tidak menentukan prefixMatch, aturan tersebut berlaku untuk semua blob dalam akun penyimpanan. Tidak
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. Tidak

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.

Tindakan Versi Saat Ini Snapshot Versi Sebelumnya
tierToDingin Dukungan untuk blockBlob Didukung Didukung
enableAutoTierToHotDariCool Dukungan untuk blockBlob Tidak didukung Tidak didukung
tierToArchieve Dukungan untuk blockBlob Didukung Didukung
hapus1 Dukungan untuk blockBlob dan appendBlob Didukung Didukung

1 Saat diterapkan ke akun dengan namespace hierarki diaktifkan, tindakan hapus akan menghapus direktori kosong. Jika direktori tidak kosong, maka tindakan hapus akan menghapus objek yang memenuhi kondisi kebijakan dalam siklus 24 jam pertama. Jika tindakan tersebut menghasilkan direktori kosong yang juga memenuhi kondisi kebijakan, direktori tersebut akan dihapus dalam siklus 24 jam berikutnya, dan sebagainya.

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 Syarat untuk tindakan pada blob versi sebelumnya atau snapshot blob
daysAfterLastAksesWaktuGreaterThan 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.

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.

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.

{
  "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 meng-upload blob Anda langsung ke tingkat arsip agar lebih efisien. 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"
          ]
        }
      }
    }
  ]
}

Dukungan fitur

Dukungan untuk fitur ini mungkin terpengaruh dengan mengaktifkan Data Lake Storage Gen2, protokol Network File System (NFS) 3.0, atau SSH File Transfer Protocol (SFTP).

Jika Anda telah mengaktifkan salah satu kemampuan ini, lihat Dukungan fitur Blob Storage di akun Azure Storage untuk menilai dukungan untuk fitur ini.

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.

Untuk informasi selengkapnya tentang harga, lihat Harga Blok Blob .

FAQ

Saya membuat kebijakan baru. Mengapa tindakan tidak segera berjalan?

Platform mengeksekusi kebijakan siklus hidup sekali sehari. Setelah Anda mengonfigurasi kebijakan, diperlukan waktu hingga 24 jam agar beberapa tindakan dapat dieksekusi untuk pertama kalinya.

Jika saya memperbarui kebijakan yang ada, berapa lama waktu yang diperlukan agar tindakan dieksekusi?

Kebijakan yang diperbarui membutuhkan waktu hingga 24 jam untuk diberlakukan. Setelah kebijakan berlaku, bisa membutuhkan waktu hingga 24 jam agar tindakan dieksekusi. Oleh karena itu, tindakan kebijakan dapat membutuhkan waktu hingga 48 jam untuk menyelesaikannya. Jika pembaruan adalah untuk menonaktifkan atau menghapus aturan, dan enableAutoTierToHotFromCool digunakan, tingkatan otomatis ke Tingkat hot masih akan terjadi. Misalnya, tetapkan aturan termasuk enableAutoTierToHotFromCool berdasarkan akses terakhir. Jika aturan dinonaktifkan/dihapus, dan blob saat ini cool dan kemudian diakses, blob akan kembali ke Hot seperti yang diterapkan pada akses di luar manajemen siklus hidup. Blob kemudian tidak akan berpindah dari Hot ke Cool mengingat aturan manajemen siklus hidup dinonaktifkan/dihapus. Satu-satunya cara untuk mencegah autoTierToHotFromCool adalah dengan menonaktifkan pelacakan waktu akses terakhir.

Saya merehidrasi blob yang diarsipkan. Bagaimana cara mencegahnya dipindahkan kembali ke tingkat Arsip untuk sementara waktu?

Jika ada kebijakan manajemen siklus hidup yang berlaku untuk akun penyimpanan, rehidrasi blob dengan mengubah tingkatannya dapat menghasilkan skenario di mana kebijakan siklus hidup memindahkan blob kembali ke tingkat Arsip. Ini dapat terjadi jika waktu terakhir kali dimodifikasi, pembuatan, atau akses terakhir kali berada di luar ambang yang ditetapkan untuk kebijakan. Ada tiga cara untuk mencegah hal ini terjadi:

  • Tambahkan syarat daysAfterLastTierChangeGreaterThan ke tindakan tierToArchive kebijakan. Syarat ini hanya berlaku untuk waktu dimodifikasi terakhir kali. Lihat Menggunakan kebijakan manajemen siklus hidup untuk mengarsipkan blob.

  • Nonaktifkan aturan yang memengaruhi blob ini untuk sementara untuk mencegahnya diarsipkan lagi. Aktifkan kembali aturan ketika blob dapat dipindahkan kembali ke tingkat arsip dengan aman.

  • Jika blob perlu tetap berada di tingkat panas atau dingin secara permanen, salin blob ke lokasi lain di mana kebijakan pengelolaan siklus hidup tidak berlaku.

String kecocokan prefiks blob tidak menerapkan kebijakan ke blob yang diharapkan

Bidang pencocokan awalan blob dari kebijakan adalah jalur blob penuh atau sebagian, yang digunakan untuk mencocokkan blob yang Anda inginkan untuk diterapkan oleh tindakan kebijakan. Jalur harus dimulai dengan nama kontainer. Jika tidak ada kecocokan awalan yang ditentukan, kebijakan akan berlaku untuk semua blob di akun penyimpanan. Format string pencocokan prefiks adalah [container name]/[blob name].

Selalu ingat poin-poin tentang string pencocokan prefiks berikut:

  • String pencocokan prefiks seperti container1/ berlaku untuk semua blob dalam kontainer bernama container1. String pencocokan prefiks container1, tanpa karakter garis miring maju(/), berlaku untuk semua blob di semua kontainer di mana nama kontainer dimulai dengan container1. Prefiks akan cocok dengan kontainer bernama container11, container1234, container1ab, dan seterusnya.
  • String pencocokan prefiks container1/sub1/ berlaku untuk semua blob dalam kontainer bernama container1 yang dimulai dengan string sub1/. Misalnya, prefiks akan cocok dengan blob bernama container1/sub1/test.txt atau container1/sub1/sub2/test.txt.
  • Karakter dengan tanda bintang * merupakan karakter yang valid untuk nama blob. Jika karakter dengan tanda bintang digunakan dalam prefiks, maka prefiks akan cocok dengan blob yang memiliki tanda bintang dalam namanya. Tanda bintang tidak berfungsi sebagai wildcard.
  • Karakter dengan tanda tanya ? merupakan karakter yang valid untuk nama blob. Jika karakter dengan tanda tanya digunakan dalam prefiks, maka prefiks akan cocok dengan blob yang memiliki tanda tanya dalam namanya. Tanda tanya tidak berfungsi sebagai wildcard.
  • Pencocokan prefiks hanya mempertimbangkan perbandingan logis positif (=). Perbandingan logis negatif (!=) diabaikan.

Apakah ada cara untuk mengidentifikasi waktu di mana kebijakan akan dijalankan?

Sayangnya, tidak ada cara untuk melacak waktu di mana kebijakan akan dijalankan, karena ini adalah proses penjadwalan latar belakang. Namun, platform akan menjalankan kebijakan sekali setiap harinya.

Langkah berikutnya