Blob Sewa

Artikel
05/15/2024

Operasi ini Lease Blob membuat dan mengelola kunci pada blob untuk operasi tulis dan hapus. Durasi penguncian bisa 15 hingga 60 detik, atau bisa tak terbatas. Dalam versi sebelum 2012-02-12, durasi kunci adalah 60 detik.

Penting

Mulai versi 2012-02-12, beberapa perilaku Lease Blob operasi berbeda dari versi sebelumnya. Misalnya, di versi sebelumnya, Anda dapat memperbarui sewa setelah merilisnya. Mulai versi 2012-02-12, permintaan sewa ini gagal, tetapi panggilan yang menggunakan versi Lease Blob lama masih berhasil. Untuk daftar perubahan perilaku operasi ini, lihat bagian "Keterangan" nanti di artikel ini.

Anda dapat memanggil Lease Blob operasi dalam salah satu mode berikut:

Acquire, untuk meminta sewa baru.
Renew, untuk memperbarui sewa yang ada.
Change, untuk mengubah ID sewa yang ada.
Release, untuk membebaskan sewa jika tidak lagi diperlukan, sehingga klien lain dapat segera memperoleh sewa terhadap blob.
Break, untuk mengakhiri sewa, tetapi pastikan bahwa klien lain tidak dapat memperoleh sewa baru sampai periode sewa saat ini telah kedaluwarsa.

Minta

Anda dapat membuat Lease Blob permintaan sebagai berikut. HTTPS disarankan. Ganti myaccount dengan nama akun penyimpanan Anda.

URI permintaan metode PUT	Versi HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=lease`	HTTP/1.1

URI layanan penyimpanan yang ditimulasikan

Saat Anda membuat permintaan terhadap layanan penyimpanan yang ditimulasi, tentukan nama host emulator dan port Azure Blob Storage sebagai 127.0.0.1:10000, diikuti dengan nama akun penyimpanan yang ditimulasi.

URI permintaan metode PUT	Versi HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=lease`	HTTP/1.0 HTTP/1.1

Untuk informasi selengkapnya, lihat Menggunakan emulator Azurite untuk pengembangan Azure Storage lokal.

Parameter URI

Anda dapat menentukan parameter tambahan berikut pada URI permintaan.

Parameter	Deskripsi
`timeout`	Opsional. Parameter `timeout` dinyatakan dalam hitung detik. Untuk informasi selengkapnya, lihat Mengatur batas waktu untuk operasi Blob Storage.

Header permintaan

Tabel berikut ini menjelaskan header permintaan yang diperlukan dan opsional.

Meminta kop	Deskripsi
`Authorization`	Wajib diisi. Menentukan skema otorisasi, nama akun, dan tanda tangan. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage.
`Date` atau `x-ms-date`	Wajib diisi. Menentukan Waktu Universal Terkoordinasi (UTC) untuk permintaan tersebut. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage.
`x-ms-version`	Opsional. Menentukan versi operasi yang akan digunakan untuk permintaan ini. Untuk informasi selengkapnya, lihat Penerapan versi untuk layanan Azure Storage.
`x-ms-lease-id: <ID>`	Diperlukan untuk memperbarui, mengubah, atau melepaskan sewa. Anda dapat menentukan nilai `x-ms-lease-id` dalam format string GUID yang valid. Lihat Konstruktor Guid (String) untuk daftar format yang valid.
`x-ms-lease-action: <acquire ¦ renew ¦ change ¦ release ¦ break>`	`acquire`: Meminta sewa baru. Jika blob tidak memiliki sewa aktif, Blob Storage membuat sewa pada blob, dan mengembalikan ID sewa baru. Jika blob memiliki sewa aktif, Anda hanya dapat meminta sewa baru dengan menggunakan ID sewa aktif. Namun, Anda dapat menentukan yang baru `x-ms-lease-duration`, termasuk yang negatif (-1) untuk sewa yang tidak pernah kedaluwarsa. `renew`: Memperbarui sewa. Anda dapat memperbarui sewa jika ID sewa yang ditentukan pada permintaan cocok dengan yang terkait dengan blob. Perhatikan bahwa sewa dapat diperpanjang bahkan jika telah kedaluwarsa, selama blob belum dimodifikasi atau disewakan lagi sejak kedaluwarsa sewa tersebut. Saat Anda memperbarui sewa, jam durasi sewa direset. `change`: Versi 2012-02-12 dan yang lebih baru. Mengubah ID sewa sewa aktif. `change` harus menyertakan ID sewa saat ini di `x-ms-lease-id`, dan ID sewa baru di `x-ms-proposed-lease-id`. `release`: Merilis sewa. Anda dapat merilis sewa jika ID sewa yang ditentukan pada permintaan cocok dengan yang terkait dengan blob. Melepaskan sewa memungkinkan klien lain untuk segera memperoleh sewa untuk blob, segera setelah rilis selesai. `break`: Memutuskan sewa, jika blob memiliki sewa aktif. Setelah sewa rusak, sewa tidak dapat diperpanjang. Setiap permintaan yang diotorisasi dapat memutus sewa; permintaan tidak diperlukan untuk menentukan ID sewa yang cocok. Ketika sewa rusak, periode istirahat sewa diizinkan untuk berlalu, selama waktu `break` tersebut dan `release` merupakan satu-satunya operasi sewa yang dapat Anda lakukan pada blob. Ketika sewa berhasil rusak, respons menunjukkan interval dalam hitungan detik sampai sewa baru dapat diperoleh. Sewa yang telah rusak juga dapat dirilis, dalam hal ini klien lain dapat segera memperoleh sewa pada blob.
`x-ms-lease-break-period: N`	Pilihan. Versi 2012-02-12 dan yang lebih baru. `break` Untuk operasi, ini adalah durasi detik yang diusulkan bahwa sewa harus dilanjutkan sebelum rusak, antara 0 dan 60 detik. Periode istirahat ini hanya digunakan jika lebih pendek dari waktu yang tersisa pada sewa. Jika lebih lama, waktu yang tersisa pada sewa digunakan. Sewa baru tidak akan tersedia sebelum periode istirahat berakhir, tetapi sewa dapat ditahan lebih lama dari periode istirahat. Jika header ini tidak muncul dengan `break` operasi, sewa durasi tetap berhenti setelah periode sewa yang tersisa berlalu, dan sewa tak terbatas segera berhenti.
`x-ms-lease-duration: -1 ¦ n seconds`	Versi 2012-02-12 dan yang lebih baru. Hanya diizinkan dan diperlukan pada `acquire` operasi. Menentukan durasi sewa, dalam detik, atau negatif satu (-1) untuk sewa yang tidak pernah kedaluwarsa. Sewa yang tidak terbatas bisa antara 15 dan 60 detik. Durasi sewa tidak dapat diubah dengan menggunakan `renew` atau `change`.
`x-ms-proposed-lease-id: <ID>`	Versi 2012-02-12 dan yang lebih baru. Opsional untuk `acquire`, dan diperlukan untuk `change`. ID sewa yang diusulkan, dalam format string GUID. Blob Storage mengembalikan `400 (Invalid request)` jika ID sewa yang diusulkan tidak dalam format yang benar. Lihat Konstruktor Guid (String) untuk daftar format yang valid.
`Origin`	Pilihan. Menentukan asal dari mana permintaan dikeluarkan. Kehadiran header ini menghasilkan header berbagi sumber daya lintas asal (CORS) pada respons. Lihat dukungan CORS untuk layanan Penyimpanan untuk detailnya.
`x-ms-client-request-id`	Pilihan. Menyediakan nilai buram yang dihasilkan klien dengan batas karakter 1 kibibyte (KiB) yang dicatat dalam log saat pengelogan dikonfigurasi. Kami sangat menyarankan Anda menggunakan header ini untuk menghubungkan aktivitas sisi klien dengan permintaan yang diterima server. Untuk informasi selengkapnya, lihat Memantau Azure Blob Storage.

Operasi ini juga mendukung penggunaan header kondisional untuk menjalankan operasi, hanya jika kondisi tertentu terpenuhi. Untuk informasi selengkapnya, lihat Menentukan header kondisional untuk operasi Blob Storage.

Isi permintaan

Tidak ada.

Permintaan sampel

Contoh permintaan berikut menunjukkan cara memperoleh sewa:

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=lease HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-lease-action: acquire  
x-ms-lease-duration: -1  
x-ms-proposed-lease-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-date: <date>  
Authorization: SharedKey testaccount1:esSKMOYdK4o+nGTuTyeOLBI+xqnqi6aBmiW4XI699+o=

Respons

Respons mencakup kode status HTTP dan sekumpulan header respons.

Kode status

Kode status keberhasilan yang dikembalikan untuk operasi sewa adalah sebagai berikut:

Acquire: Operasi yang berhasil mengembalikan kode status 201 (Dibuat).
Renew: Operasi yang berhasil mengembalikan kode status 200 (OK).
Change: Operasi yang berhasil mengembalikan kode status 200 (OK).
Release: Operasi yang berhasil mengembalikan kode status 200 (OK).
Break: Operasi yang berhasil mengembalikan kode status 202 (Diterima).

Untuk informasi tentang kode status, lihat Kode status dan kesalahan.

Header respons

Respons untuk operasi ini mencakup header berikut. Respons juga dapat mencakup header HTTP standar tambahan. Semua header standar sesuai dengan spesifikasi protokol HTTP/1.1.

Sintaks	Deskripsi
`ETag`	Berisi nilai yang dapat Anda gunakan untuk melakukan operasi secara kondisional. Lihat Menentukan header kondisional untuk operasi Blob Storage untuk informasi selengkapnya. Header ini dikembalikan untuk permintaan yang dibuat terhadap versi 2013-08-15 dan yang lebih baru, dan `ETag` nilainya ada dalam tanda kutip. Operasi `Lease Blob` tidak mengubah properti ini.
`Last-Modified`	Tanggal/waktu blob terakhir diubah. Untuk informasi selengkapnya, lihat Representasi nilai tanggal-waktu di header. Setiap operasi tulis pada blob, termasuk pembaruan pada metadata atau properti blob, mengubah waktu blob yang terakhir dimodifikasi. Operasi `Lease Blob` tidak mengubah properti ini.
`x-ms-lease-id: <id>`	Saat Anda meminta sewa, Blob Storage mengembalikan ID sewa unik. Saat sewa aktif, Anda harus menyertakan ID sewa dengan permintaan apa pun untuk menulis ke blob, atau untuk memperbarui, mengubah, atau melepaskan sewa. Operasi perpanjangan yang berhasil juga mengembalikan ID sewa untuk sewa aktif.
`x-ms-lease-time: seconds`	Perkiraan waktu yang tersisa dalam periode sewa, dalam detik. Header ini dikembalikan hanya untuk permintaan yang berhasil untuk memutuskan sewa. Jika istirahat segera dikembalikan `0` .
`x-ms-request-id`	Header ini secara unik mengidentifikasi permintaan yang dibuat, dan dapat digunakan untuk memecahkan masalah permintaan. Untuk informasi selengkapnya, lihat Pemecahan masalah operasi API.
`x-ms-version`	Menunjukkan versi Blob Storage yang digunakan untuk menjalankan permintaan. Header ini dikembalikan untuk permintaan yang dibuat terhadap versi 2009-09-19 dan yang lebih baru.
`Date`	Nilai tanggal/waktu UTC yang menunjukkan waktu di mana respons dimulai. Layanan menghasilkan nilai ini.
`Access-Control-Allow-Origin`	Dikembalikan jika permintaan menyertakan `Origin` header, dan CORS diaktifkan dengan aturan yang cocok. Header ini mengembalikan nilai header permintaan asal jika terjadi kecocokan.
`Access-Control-Expose-Headers`	Dikembalikan jika permintaan menyertakan `Origin` header, dan CORS diaktifkan dengan aturan yang cocok. Mengembalikan daftar header respons yang akan diekspos ke klien atau penerbit permintaan.
`Access-Control-Allow-Credentials`	Dikembalikan jika permintaan menyertakan `Origin` header, dan CORS diaktifkan dengan aturan yang cocok yang tidak mengizinkan semua asal. Header ini diatur ke `true`.
`x-ms-client-request-id`	Anda dapat menggunakan header ini untuk memecahkan masalah permintaan dan respons terkait. Nilai header ini sama dengan nilai `x-ms-client-request-id` header, jika ada dalam permintaan. Nilainya paling banyak 1.024 karakter ASCII yang terlihat. `x-ms-client-request-id` Jika header tidak ada dalam permintaan, header tidak akan ada dalam respons.

Isi Respons

Tidak ada.

Respons sampel

Berikut ini adalah respons sampel untuk permintaan untuk memperoleh sewa:

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402  
x-ms-version: 2015-02-21  
x-ms-lease-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
Date: <date>

Authorization

Otorisasi diperlukan saat memanggil operasi akses data apa pun di Azure Storage. Anda dapat mengotorisasi operasi seperti yang Lease Blob dijelaskan di bawah ini.

Penting

Microsoft merekomendasikan penggunaan Microsoft Entra ID dengan identitas terkelola untuk mengotorisasi permintaan ke Azure Storage. Microsoft Entra ID memberikan keamanan yang unggul dan kemudahan penggunaan dibandingkan dengan otorisasi Kunci Bersama.

Azure Storage mendukung penggunaan Microsoft Entra ID untuk mengotorisasi permintaan ke data blob. Dengan Microsoft Entra ID, Anda dapat menggunakan kontrol akses berbasis peran Azure (Azure RBAC) untuk memberikan izin kepada prinsip keamanan. Perwakilan keamanan mungkin pengguna, grup, perwakilan layanan aplikasi, atau identitas terkelola Azure. Perwakilan keamanan diautentikasi oleh Microsoft Entra ID untuk mengembalikan token OAuth 2.0. Token kemudian dapat digunakan untuk mengotorisasi permintaan terhadap Blob service.

Untuk mempelajari selengkapnya tentang otorisasi menggunakan Microsoft Entra ID, lihat Mengotorisasi akses ke blob menggunakan Microsoft Entra ID.

Izin

Tercantum di bawah ini adalah tindakan RBAC yang diperlukan untuk pengguna, grup, identitas terkelola, atau perwakilan layanan Microsoft Entra untuk memanggil Lease Blob operasi, dan peran Azure RBAC bawaan yang paling tidak istimewa yang mencakup tindakan ini:

Tindakan Azure RBAC:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Peran bawaan dengan hak istimewa paling sedikit:Kontributor Data Blob Penyimpanan

Untuk mempelajari selengkapnya tentang menetapkan peran menggunakan Azure RBAC, lihat Menetapkan peran Azure untuk akses ke data blob.

Tanda tangan akses bersama (SAS) menyediakan akses yang didelegasikan dengan aman ke sumber daya di akun penyimpanan. Dengan SAS, Anda memiliki kontrol terperinci atas bagaimana klien dapat mengakses data. Anda dapat menentukan sumber daya apa yang dapat diakses klien, izin apa yang mereka miliki ke sumber daya tersebut, dan berapa lama SAS valid.

Operasi ini Lease Blob mendukung tiga jenis tanda tangan akses bersama: SAS delegasi pengguna, SAS layanan, dan SAS akun.

Sebagai praktik terbaik keamanan, kami sarankan Anda menggunakan kredensial Microsoft Entra daripada kunci akun penyimpanan, yang dapat lebih mudah disusupi. Jika desain aplikasi Anda memerlukan tanda tangan akses bersama, gunakan kredensial Microsoft Entra untuk membuat SAS delegasi pengguna, jika memungkinkan.

Ketika akses Kunci Bersama tidak diizinkan untuk akun penyimpanan, token SAS layanan atau token SAS akun tidak akan diizinkan berdasarkan permintaan ke Blob Storage. Untuk mempelajari selengkapnya, lihat Memahami bagaimana melarang Kunci Bersama memengaruhi token SAS.

Delegasi pengguna SAS

DELEGASI pengguna SAS diamankan dengan kredensial Microsoft Entra dan juga oleh izin yang ditentukan untuk SAS.

Memanggil Lease Blob operasi menggunakan token SAS yang didelegasikan ke kontainer atau sumber daya blob memerlukan izin Tulis (w) sebagai bagian dari token SAS delegasi pengguna.

Untuk mempelajari selengkapnya tentang delegasi pengguna SAS, lihat Create delegasi pengguna SAS.

Layanan SAS

Layanan SAS diamankan dengan kunci akun penyimpanan. SAS layanan mendelegasikan akses ke sumber daya dalam satu layanan Azure Storage, seperti penyimpanan blob.

Memanggil Lease Blob operasi menggunakan token SAS yang didelegasikan ke kontainer atau sumber daya blob memerlukan izin Tulis (w) sebagai bagian dari token SAS layanan.

Untuk mempelajari selengkapnya tentang layanan SAS, lihat Create LAYANAN SAS.

Akun SAS

Akun SAS diamankan dengan kunci akun penyimpanan. Akun SAS delegasikan akses ke sumber daya di satu atau beberapa layanan penyimpanan. Semua operasi yang tersedia melalui layanan atau delegasi pengguna SAS juga tersedia melalui akun SAS.

Tabel berikut menunjukkan jenis sumber daya yang ditandatangani dan izin yang ditandatangani untuk ditentukan saat mendelegasikan akses:

Operasi	Layanan yang ditandatangani	Jenis sumber daya yang ditandatangani	Izin yang ditandatangani
Blob Sewa	Blob (b)	Objek (o)	Tulis (w)

Untuk mempelajari selengkapnya tentang akun SAS, lihat Create akun SAS.

Keterangan

Sewa pada blob menyediakan akses tulis dan hapus eksklusif ke blob. Untuk menulis ke blob dengan sewa aktif, klien harus menyertakan ID sewa aktif dengan permintaan tulis. Sewa diberikan selama durasi yang ditentukan ketika sewa diperoleh. Durasi ini bisa antara 15 dan 60 detik, atau durasi tak terbatas.

Ketika klien memperoleh sewa, ID sewa dikembalikan. Blob Storage menghasilkan ID sewa jika tidak ditentukan dalam permintaan peroleh. Klien dapat menggunakan ID sewa ini untuk memperbarui sewa, mengubah ID sewanya, atau melepaskan sewa.

Ketika sewa aktif, ID sewa harus disertakan dalam permintaan untuk salah satu operasi berikut:

Masukkan Blob
Set Metadata Blob
Set properti Blob
Menghapus blob
Put Blok
Masukkan Daftar Blokir
Put Halaman
Append Blok
Salin Blob (ID sewa yang diperlukan untuk blob tujuan)

Jika ID sewa tidak disertakan, operasi ini gagal pada blob sewaan, dengan 412 – Precondition failed.

Operasi berikut berhasil pada blob sewaan, tanpa menyertakan ID sewa:

Get Blob
Get Metadata Blob
Get Properti Blob
Dapatkan Daftar Blokir
Dapatkan Rentang Halaman
Mencantumkan blob
Salin Blob (Tidak ada ID sewa yang diperlukan untuk blob sumber.)
Blob Sewa (REST API) (Tidak ada ID sewa yang diperlukan untuk x-ms-lease-action: break.)

Tidak perlu menyertakan ID sewa untuk GET operasi pada blob yang memiliki sewa aktif. Namun, semua GET operasi mendukung parameter sewa kondisional, di mana operasi hanya dilanjutkan jika ID sewa yang disertakan dengan permintaan valid.

Semua operasi kontainer diizinkan pada kontainer yang menyertakan blob dengan sewa aktif, termasuk Hapus Kontainer. Oleh karena itu, kontainer dapat dihapus meskipun blob di dalamnya memiliki sewa aktif. Gunakan operasi Sewa Kontainer untuk mengontrol hak untuk menghapus kontainer.

Status sewa

Diagram berikut menunjukkan lima status sewa, dan perintah atau peristiwa yang menyebabkan perubahan status sewa.

Diagram yang menunjukkan status sewa blob, dan pemicu perubahan status.

Sewa dapat berada di salah satu status ini, berdasarkan apakah sewa dikunci atau tidak terkunci, dan apakah sewa dapat diperpanjang dalam keadaan tersebut. Tindakan sewa yang ditunjukkan dalam diagram sebelumnya menyebabkan transisi status.

Status perpanjangan	Sewa terkunci	Sewa tidak terkunci
Sewa yang dapat diperpanjang	Disewakan	Kedaluwarsa
Sewa yang tidak dapat diperpanjang	Melanggar	Rusak, Tersedia

Available: Sewa tidak terkunci dan dapat diperoleh. Tindakan yang diizinkan: acquire.
Leased: Sewa dikunci. Tindakan yang diizinkan: acquire (hanya ID sewa yang sama), renew, , releasechange, dan break.
Expired: Durasi sewa telah kedaluwarsa. Tindakan yang diizinkan: acquire, renew, release, dan break.
Breaking: Sewa telah rusak, tetapi sewa akan terus dikunci sampai periode istirahat telah kedaluwarsa. Tindakan yang diizinkan: release dan break.
Broken: Sewa telah rusak, dan periode istirahat telah kedaluwarsa. Tindakan yang diizinkan: acquire, release, dan break.

Setelah sewa kedaluwarsa, ID sewa dipertahankan oleh Blob Storage sampai blob dimodifikasi atau disewakan lagi. Klien dapat mencoba memperbarui atau merilis sewa dengan menggunakan ID sewa yang kedaluwarsa. Jika operasi berhasil, ini berarti bahwa blob belum diubah sejak ID sewa terakhir valid.

Jika klien mencoba memperbarui atau merilis sewa dengan ID sewa mereka sebelumnya, dan permintaan gagal, maka blob dimodifikasi atau disewakan lagi karena sewa klien terakhir aktif. Klien kemudian harus memperoleh sewa baru pada blob.

Jika sewa kedaluwarsa daripada dirilis secara eksplisit, klien mungkin perlu menunggu hingga satu menit sebelum sewa baru dapat diperoleh untuk blob. Namun, klien dapat segera memperbarui sewa dengan ID sewa mereka, jika blob belum dimodifikasi.

Perhatikan bahwa sewa tidak dapat diberikan untuk rekam jepret blob, karena rekam jepret bersifat baca-saja. Meminta sewa terhadap rekam jepret menghasilkan kode status 400 (Permintaan Buruk).

Properti blob Last-Modified-Time tidak diperbarui oleh panggilan ke Lease Blob.

Tabel berikut menunjukkan hasil tindakan pada blob dengan sewa di berbagai status sewa. Huruf (A), (B), dan (C) mewakili ID sewa, dan (X) mewakili ID sewa yang dihasilkan oleh Blob Storage.

Hasil upaya penggunaan pada blob berdasarkan status sewa

Tindakan	Tersedia	Sewaan (A)	Pemecahan (A)	Rusak (A)	Kedaluwarsa (A)
Tulis dengan (A)	Gagal (412)	Leased (A), tulis berhasil	Pemecahan (A), penulisan berhasil	Gagal (412)	Gagal (412)
Tulis dengan (B)	Gagal (412)	Gagal (409)	Gagal (412)	Gagal (412)	Gagal (412)
Tulis, tidak ada sewa yang ditentukan	Tersedia, penulisan berhasil	Gagal (412)	Gagal (412)	Tersedia, penulisan berhasil	Tersedia, penulisan berhasil
Baca dengan (A)	Gagal (412)	Sewa (A), baca berhasil	Melanggar (A), pembacaan berhasil	Gagal (412)	Gagal (412)
Baca dengan (B)	Gagal (412)	Gagal (409)	Gagal (409)	Gagal (412)	Gagal (412)
Baca, tidak ada sewa yang ditentukan	Tersedia, baca berhasil	Sewa (A), baca berhasil	Melanggar (A), pembacaan berhasil	Rusak (A), baca berhasil	Kedaluwarsa (A), baca berhasil

Hasil operasi sewa pada blob berdasarkan status sewa

Tindakan	Tersedia	Sewaan (A)	Melanggar (A)	Rusak (A)	Kedaluwarsa (A)
`Acquire`, tidak ada ID sewa yang diusulkan	Sewaan (X)	Gagal (409)	Gagal (409)	Sewaan (X)	Sewaan (X)
`Acquire` (A)	Sewaan (A)	Sewa (A), durasi baru	Gagal (409)	Sewaan (A)	Sewaan (A)
`Acquire` (B)	Sewa (B)	Gagal (409)	Gagal (409)	Sewa (B)	Sewa (B)
`Break`, period=0	Gagal (409)	Rusak (A)	Rusak (A)	Rusak (A)	Rusak (A)
`Break`, periode>0	Gagal (409)	Melanggar (A)	Melanggar (A)	Rusak (A)	Rusak (A)
`Change`, (A) ke (B)	Gagal (409)	Sewa (B)	Gagal (409)	Gagal (409)	Gagal (409)
`Change`, (B) ke (A)	Gagal (409)	Sewaan (A)	Gagal (409)	Gagal (409)	Gagal (409)
`Change`, (B) ke (C)	Gagal (409)	Gagal (409)	Gagal (409)	Gagal (409)	Gagal (409)
`Renew` (A)	Gagal (409)	Reset jam sewaan (A), kedaluwarsa	Gagal (409)	Gagal (409)	Leased(A), jika blob belum dimodifikasi. Gagal (409) jika blob telah dimodifikasi.
`Renew` (B)	Gagal (409)	Gagal (409)	Gagal (409)	Gagal (409)	Gagal (409)
`Release` (A)	Gagal (409)	Tersedia	Tersedia	Tersedia	Tersedia
`Release` (B)	Gagal (409)	Gagal (409)	Gagal (409)	Gagal (409)	Gagal (409)
Durasi kedaluwarsa	Tersedia	Kedaluwarsa (A)	Rusak (A)	Rusak (A)	Kedaluwarsa (A)

Perubahan pada Lease Blob yang diperkenalkan dalam versi 2012-02-12

Daftar berikut menentukan perubahan Lease Blob perilaku yang diperkenalkan dalam versi 2012-02-12.

Panggilan ke untuk Lease Blob memperoleh sewa sekarang harus menyertakan header durasi sewa. Jika Anda mencoba memperoleh sewa tanpa menentukan durasi sewa, layanan akan mengembalikan 400 Bad Request – Missing required header.
Anda tidak dapat lagi memperbarui sewa setelah merilisnya. Jika Anda mencoba melakukannya, layanan akan mengembalikan 409 Conflict – The lease ID specified did not match the lease ID for the blob. Aplikasi yang disebut rilis, dan kemudian disebut perpanjang, sekarang harus menyimpan ETag dari panggilan rilis. Kemudian aplikasi harus memanggil acquire, dengan If-Match header kondisional, untuk memperoleh sewa hanya ketika blob tidak berubah.
Anda tidak dapat lagi memutus sewa setelah merilisnya. Jika Anda mencoba melakukannya, layanan akan mengembalikan 409 Conflict – There is currently no lease on the blob.
Anda sekarang dapat memutuskan sewa yang melanggar atau rusak, membuat operasi pemutusan idempotensi. Di versi sebelumnya, ini gagal dengan 409 Conflict – The lease has already been broken and cannot be broken again. Perubahan ini memungkinkan Anda untuk mempersingkat durasi istirahat. Jika Anda memutuskan sewa yang berada dalam status melanggar, dan menyertakan durasi yang lebih pendek daripada periode jeda yang tersisa, durasi Anda yang lebih pendek akan digunakan.

Billing

Permintaan harga dapat berasal dari klien yang menggunakan API Blob Storage, baik langsung melalui Blob Storage REST API, atau dari pustaka klien Azure Storage. Permintaan ini mengumpulkan biaya per transaksi. Jenis transaksi memengaruhi cara akun ditagih. Misalnya, transaksi baca bertambah ke kategori penagihan yang berbeda dari transaksi tulis. Tabel berikut ini memperlihatkan kategori penagihan untuk Lease Blob permintaan berdasarkan jenis akun penyimpanan:

Operasi	Jenis akun penyimpanan	Kategori penagihan
Lease Blob (memperoleh, merilis, memperbarui)	Objek besar biner blok premium Tujuan umum standar v2	Operasi lainnya
Lease Blob (memperoleh, merilis, memperbarui)	Tujuan umum standar v1	Membacakan operasi
Lease Blob (break, change)	Objek besar biner blok premium Tujuan umum standar v2	Operasi lainnya
Lease Blob (break, change)	Tujuan umum standar v1	Operasi tulis

Lihat juga

new-blob-lease-features-infinite-leases-smaller-lease-times-and-more.aspx)
Mengotorisasi permintaan ke Azure Storage
Status dan kode galat
Kode kesalahan Blob Storage
Menyewa Kontainer

Bagikan melalui