Lease Blob (Blob de Concessão)

  • Artigo

A Lease Blob operação cria e gere um bloqueio num blob para operações de escrita e eliminação. A duração do bloqueio pode ser de 15 a 60 segundos ou pode ser infinita. Nas versões anteriores a 2012-02-12, a duração do bloqueio é de 60 segundos.

Importante

A partir da versão 2012-02-12, alguns comportamentos da Lease Blob operação diferem das versões anteriores. Por exemplo, em versões anteriores, pode renovar uma concessão depois de a lançar. A partir da versão 2012-02-12, este pedido de concessão falha, mas as chamadas que utilizam versões mais antigas ainda Lease Blob têm êxito. Para obter uma lista das alterações ao comportamento desta operação, consulte a secção "Observações" mais à frente neste artigo.

Pode chamar a Lease Blob operação num dos seguintes modos:

  • Acquire, para pedir uma nova concessão.

  • Renew, para renovar uma concessão existente.

  • Change, para alterar o ID de uma concessão existente.

  • Release, para libertar a concessão se já não for necessária, para que outro cliente possa adquirir imediatamente uma concessão no blob.

  • Break, para terminar a concessão, mas certifique-se de que outro cliente não pode adquirir uma nova concessão até que o período de concessão atual expire.

Pedir

Pode construir o pedido da Lease Blob seguinte forma. É recomendado HTTPS. Substitua myaccount pelo nome da sua conta de armazenamento.

URI do pedido do método PUT Versão HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=lease HTTP/1.1

URI do serviço de armazenamento emulado

Quando fizer um pedido relativamente ao serviço de armazenamento emulado, especifique o nome do anfitrião do emulador e Armazenamento de Blobs do Azure porta como 127.0.0.1:10000, seguido do nome da conta de armazenamento emulada.

URI do pedido do método PUT Versão HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=lease HTTP/1.0

HTTP/1.1

Para obter mais informações, veja Use Azurite emulator for local Azure Storage development (Utilizar o emulador do Azurite para o desenvolvimento do Armazenamento do Azure local).

Parâmetros do URI

Pode especificar o seguinte parâmetro adicional no URI do pedido.

Parâmetro Description
timeout Opcional. O timeout parâmetro é expresso em segundos. Para obter mais informações, veja Setting timeouts for Blob Storage operations (Definir tempos limite para operações de Armazenamento de Blobs).

Cabeçalhos do pedido

A tabela seguinte descreve os cabeçalhos de pedido obrigatórios e opcionais.

Cabeçalho do pedido Description
Authorization Obrigatório. Especifica o esquema de autorização, o nome da conta e a assinatura. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure.
Date ou x-ms-date Obrigatório. Especifica a Hora Universal Coordenada (UTC) do pedido. Para obter mais informações, veja Autorizar pedidos para o Armazenamento do Azure.
x-ms-version Opcional. Especifica a versão da operação a utilizar para este pedido. Para obter mais informações, veja Controlo de versões dos serviços de Armazenamento do Azure.
x-ms-lease-id: <ID> Necessário para renovar, alterar ou libertar a concessão.

Pode especificar o valor de x-ms-lease-id em qualquer formato de cadeia GUID válido. Consulte o Guid Constructor (Cadeia) para obter uma lista de formatos válidos.
x-ms-lease-action: <acquire ¦ renew ¦ change ¦ release ¦ break> acquire: pede uma nova concessão. Se o blob não tiver uma concessão ativa, o Armazenamento de Blobs cria uma concessão no blob e devolve um novo ID de concessão. Se o blob tiver uma concessão ativa, só pode pedir uma nova concessão com o ID de concessão ativo. No entanto, pode especificar um novo x-ms-lease-duration, incluindo um negativo (-1) para uma concessão que nunca expira.

renew: renova a concessão. Pode renovar a concessão se o ID de concessão especificado no pedido corresponder ao associado ao blob. Tenha em atenção que a concessão pode ser renovada mesmo que tenha expirado, desde que o blob não tenha sido modificado ou arrendado novamente desde a expiração dessa concessão. Quando renova uma concessão, o relógio de duração da concessão é reposto.

change: Versão 2012-02-12 e posterior. Altera o ID de concessão de uma concessão ativa. A change tem de incluir o ID de concessão atual no x-ms-lease-ide um novo ID de concessão no x-ms-proposed-lease-id.

release: liberta a concessão. Pode libertar a concessão se o ID de concessão especificado no pedido corresponder ao associado ao blob. A libertação da concessão permite que outro cliente adquira imediatamente a concessão do blob, assim que a versão estiver concluída.

break: interrompe a concessão, se o blob tiver uma concessão ativa. Depois de uma concessão ser interrompida, não pode ser renovada. Qualquer pedido autorizado pode interromper a concessão; o pedido não é necessário para especificar um ID de concessão correspondente. Quando uma concessão é interrompida, o período de interrupção da concessão é permitido decorrido, durante o qual break e release são as únicas operações de concessão que pode realizar no blob. Quando uma concessão é quebrada com êxito, a resposta indica o intervalo em segundos até que uma nova concessão possa ser adquirida.

Uma concessão que tenha sido interrompida também pode ser libertada, caso em que outro cliente pode adquirir imediatamente a concessão no blob.
x-ms-lease-break-period: N Opcional. Versão 2012-02-12 e posterior. Para uma break operação, esta é a duração proposta de segundos que a concessão deve continuar antes de ser interrompida, entre 0 e 60 segundos. Este período de interrupção só é utilizado se for mais curto do que o tempo restante na concessão. Se for mais longo, é utilizado o tempo restante na concessão. Uma nova concessão não estará disponível antes de o período de interrupção expirar, mas a concessão pode ser mantida por mais tempo do que o período de interrupção. Se este cabeçalho não aparecer com uma break operação, uma concessão de duração fixa é interrompida após o período de concessão restante e uma concessão infinita quebra imediatamente.
x-ms-lease-duration: -1 ¦ n seconds Versão 2012-02-12 e posterior. Só permitido e necessário numa acquire operação. Especifica a duração da concessão, em segundos ou negativa (-1) para uma concessão que nunca expira. Uma concessão não infinita pode ser entre 15 e 60 segundos. Uma duração de concessão não pode ser alterada com renew ou change.
x-ms-proposed-lease-id: <ID> Versão 2012-02-12 e posterior. Opcional para acquiree necessário para change. ID de concessão proposto, num formato de cadeia GUID. O Armazenamento de Blobs devolve 400 (Invalid request) se o ID de concessão proposto não estiver no formato correto. Consulte o Guid Constructor (Cadeia) para obter uma lista de formatos válidos.
Origin Opcional. Especifica a origem a partir da qual o pedido é emitido. A presença deste cabeçalho resulta em cabeçalhos de partilha de recursos de várias origens (CORS) na resposta. Veja Suporte do CORS para obter detalhes sobre os Serviços de armazenamento .
x-ms-client-request-id Opcional. Fornece um valor opaco gerado pelo cliente com um limite de carateres de 1 kibibyte (KiB) que é registado nos registos quando o registo é configurado. Recomendamos vivamente que utilize este cabeçalho para correlacionar as atividades do lado do cliente com os pedidos que o servidor recebe. Para obter mais informações, veja Monitorizar Armazenamento de Blobs do Azure.

Esta operação também suporta a utilização de cabeçalhos condicionais para executar a operação, apenas se for cumprida uma condição especificada. Para obter mais informações, veja Especificar cabeçalhos condicionais para operações de Armazenamento de Blobs.

Corpo do pedido

Nenhum.

Pedido de exemplo

O seguinte pedido de exemplo mostra como adquirir uma concessão:

  
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=

Resposta

A resposta inclui um código de estado HTTP e um conjunto de cabeçalhos de resposta.

Código de estado

Os códigos de estado de êxito devolvidos para as operações de concessão são os seguintes:

  • Acquire: uma operação bem-sucedida devolve o código de estado 201 (Criado).

  • Renew: uma operação bem-sucedida devolve o código de estado 200 (OK).

  • Change: uma operação bem-sucedida devolve o código de estado 200 (OK).

  • Release: uma operação bem-sucedida devolve o código de estado 200 (OK).

  • Break: uma operação bem-sucedida devolve o código de estado 202 (Aceite).

Para obter informações sobre códigos de estado, veja Códigos de estado e de erro.

Cabeçalhos de resposta

A resposta para esta operação inclui os seguintes cabeçalhos. A resposta também pode incluir cabeçalhos HTTP padrão adicionais. Todos os cabeçalhos padrão estão em conformidade com a especificação do protocolo HTTP/1.1.

Syntax Descrição
ETag Contém um valor que pode utilizar para realizar operações condicionalmente. Veja Especificar cabeçalhos condicionais para operações de Armazenamento de Blobs para obter mais informações.

Este cabeçalho é devolvido para pedidos feitos na versão 2013-08-15 e posterior e o ETag valor está entre aspas.

A Lease Blob operação não modifica esta propriedade.
Last-Modified A data/hora em que o blob foi modificado pela última vez. Para obter mais informações, veja Representação dos valores de data/hora nos cabeçalhos.

Qualquer operação de escrita no blob, incluindo atualizações nos metadados ou propriedades do blob, altera a hora da última modificação do blob. A Lease Blob operação não modifica esta propriedade.
x-ms-lease-id: <id> Quando pede uma concessão, o Armazenamento de Blobs devolve um ID de concessão exclusivo. Enquanto a concessão estiver ativa, tem de incluir o ID de concessão com qualquer pedido para escrever no blob ou para renovar, alterar ou libertar a concessão.

Uma operação de renovação bem-sucedida também devolve o ID de concessão da concessão ativa.
x-ms-lease-time: seconds Tempo aproximado restante no período de concessão, em segundos. Este cabeçalho é devolvido apenas para um pedido bem-sucedido para interromper a concessão. Se a quebra for imediata, 0 será devolvida.
x-ms-request-id Este cabeçalho identifica exclusivamente o pedido que foi feito e pode ser utilizado para resolver o pedido. Para obter mais informações, veja Resolver problemas de operações da API.
x-ms-version Indica a versão do Armazenamento de Blobs utilizada para executar o pedido. Este cabeçalho é devolvido para pedidos feitos na versão 2009-09-19 e posterior.
Date Um valor de data/hora UTC que indica a hora em que a resposta foi iniciada. O serviço gera este valor.
Access-Control-Allow-Origin Devolvido se o pedido incluir um Origin cabeçalho e CORS estiver ativado com uma regra correspondente. Este cabeçalho devolve o valor do cabeçalho do pedido de origem em caso de correspondência.
Access-Control-Expose-Headers Devolvido se o pedido incluir um Origin cabeçalho e CORS estiver ativado com uma regra correspondente. Devolve a lista de cabeçalhos de resposta que devem ser expostos ao cliente ou emissor do pedido.
Access-Control-Allow-Credentials Devolvido se o pedido incluir um Origin cabeçalho e CORS estiver ativado com uma regra correspondente que não permita todas as origens. Este cabeçalho está definido como true.
x-ms-client-request-id Pode utilizar este cabeçalho para resolver problemas de pedidos e respostas correspondentes. O valor deste cabeçalho é igual ao valor do x-ms-client-request-id cabeçalho, se estiver presente no pedido. O valor é, no máximo, 1024 carateres ASCII visíveis. Se o x-ms-client-request-id cabeçalho não estiver presente no pedido, não estará presente na resposta.

Corpo da resposta

Nenhum.

Resposta de amostra

Segue-se uma resposta de exemplo para um pedido de aquisição de uma concessão:

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>

Autorização

A autorização é necessária ao chamar qualquer operação de acesso a dados no Armazenamento do Azure. Pode autorizar a Lease Blob operação conforme descrito abaixo.

O Armazenamento do Azure suporta a utilização de Microsoft Entra ID para autorizar pedidos para dados de blobs. Com Microsoft Entra ID, pode utilizar o controlo de acesso baseado em funções do Azure (RBAC do Azure) para conceder permissões a um principal de segurança. O principal de segurança pode ser um utilizador, grupo, principal de serviço de aplicação ou identidade gerida do Azure. O principal de segurança é autenticado por Microsoft Entra ID para devolver um token OAuth 2.0. Em seguida, o token pode ser utilizado para autorizar um pedido contra o serviço Blob.

Para saber mais sobre a autorização através de Microsoft Entra ID, veja Autorizar o acesso a blobs com Microsoft Entra ID.

Permissões

Abaixo estão listadas as ações RBAC necessárias para que um utilizador, grupo ou principal de serviço Microsoft Entra chame a Lease Blob operação e a função RBAC do Azure com menos privilégios que inclua esta ação:

Para saber mais sobre como atribuir funções com o RBAC do Azure, veja Atribuir uma função do Azure para acesso a dados de blobs.

Observações

Uma concessão num blob fornece acesso exclusivo de escrita e eliminação ao blob. Para escrever num blob com uma concessão ativa, um cliente tem de incluir o ID de concessão ativo com o pedido de escrita. A concessão é concedida durante a duração especificada quando a concessão é adquirida. Esta duração pode ser entre 15 e 60 segundos ou uma duração infinita.

Quando um cliente adquire uma concessão, é devolvido um ID de concessão. O Armazenamento de Blobs gera um ID de concessão se não for especificado no pedido de aquisição. O cliente pode utilizar este ID de concessão para renovar a concessão, alterar o ID de concessão ou libertar a concessão.

Quando uma concessão está ativa, o ID de concessão tem de ser incluído no pedido para qualquer uma das seguintes operações:

Se o ID de concessão não estiver incluído, estas operações falham num blob concedido, com 412 – Precondition failed.

As seguintes operações são bem-sucedidas num blob concedido, sem incluir o ID de concessão:

Não é necessário incluir o ID de concessão para GET operações num blob que tenha uma concessão ativa. No entanto, todas as GET operações suportam um parâmetro de concessão condicional, em que a operação apenas prossegue se o ID de concessão incluído no pedido for válido.

Todas as operações de contentor são permitidas num contentor que inclui blobs com uma concessão ativa, incluindo Eliminar Contentor. Por conseguinte, um contentor pode ser eliminado mesmo que os blobs no mesmo tenham concessões ativas. Utilize a operação Lease Container (Contentor de Concessão ) para controlar os direitos de eliminação de um contentor.

Estados de concessão

O diagrama seguinte mostra os cinco estados de uma concessão e os comandos ou eventos que causam alterações ao estado da concessão.

Diagrama que mostra os estados de concessão de blobs e os acionadores de alteração de estado.

Uma concessão pode estar num destes estados, com base no facto de a concessão estar bloqueada ou desbloqueada, e se a concessão é renovável nesse estado. As ações de concessão mostradas no diagrama anterior causam transições de estado.

Estado da renovação Concessão bloqueada Concessão desbloqueada
Concessão renovável Arrendado Fora do prazo
Concessão não renovável A quebrar Quebrada, Disponível

  • Available: a concessão está desbloqueada e pode ser adquirida. Ação permitida: acquire.

  • Leased: a concessão está bloqueada. Ações permitidas: acquire (apenas o mesmo ID de concessão), renew, change, releasee break.

  • Expired: a duração da concessão expirou. Ações permitidas: acquire, renew, releasee break.

  • Breaking: A concessão foi interrompida, mas a concessão continuará bloqueada até o período de interrupção expirar. Ações permitidas: release e break.

  • Broken: A concessão foi interrompida e o período de interrupção expirou. Ações permitidas: acquire, releasee break.

Após a expiração de uma concessão, o ID de concessão é mantido pelo Armazenamento de Blobs até que o blob seja modificado ou arrendado novamente. Um cliente pode tentar renovar ou libertar a concessão com o respetivo ID de concessão expirado. Se a operação for bem-sucedida, significa que o blob não foi alterado desde que o ID de concessão foi válido pela última vez.

Se o cliente tentar renovar ou libertar uma concessão com o ID de concessão anterior e o pedido falhar, o blob foi modificado ou concedido novamente, uma vez que a concessão do cliente estava ativa pela última vez. Em seguida, o cliente tem de adquirir uma nova concessão no blob.

Se uma concessão expirar em vez de ser explicitamente libertada, um cliente poderá ter de aguardar até um minuto para que uma nova concessão possa ser adquirida para o blob. No entanto, o cliente pode renovar a concessão com o ID de concessão imediatamente, se o blob não tiver sido modificado.

Tenha em atenção que não é possível conceder uma concessão para um instantâneo de blob, porque os instantâneos são só de leitura. Pedir uma concessão num instantâneo resulta no código de estado 400 (Pedido Incorreto).

A propriedade do Last-Modified-Time blob não é atualizada por chamadas para Lease Blob.

As tabelas seguintes mostram os resultados das ações em blobs com concessões em vários estados de concessão. As letras (A), (B) e (C) representam IDs de concessão e (X) representam um ID de concessão gerado pelo Armazenamento de Blobs.

Resultados das tentativas de utilização em blobs por estado de concessão

Ação Disponível Concedido (A) Interrupção (A) Quebrada (A) Expirado (A)
Escrever com (A) Falha (412) Leased (A), write succeeds Breaking (A), write succeeds Falha (412) Falha (412)
Escrever com (B) Falha (412) Falha (409) Falha (412) Falha (412) Falha (412)
Escrita, sem concessão especificada Disponível, a escrita é bem-sucedida Falha (412) Falha (412) Disponível, escrita com êxito Disponível, escrita com êxito
Ler com (A) Falha (412) Concessão (A), leitura com êxito Breaking (A), read succeeds (Breaking (A), read succeeds (Breaking (A), read succeeds Falha (412) Falha (412)
Ler com (B) Falha (412) Falha (409) Falha (409) Falha (412) Falha (412)
Leitura, sem concessão especificada Disponível, leitura com êxito Concessão (A), leitura com êxito Breaking (A), read succeeds (Breaking (A), read succeeds (Breaking (A), read succeeds Broken (A), read succeeds (Broken (A), read succeeds (Broken (A), read succeeds Expirado (A), a leitura é bem-sucedida

Resultados das operações de concessão em blobs por estado de concessão

Ação Disponível Arrendado (A) Breaking (A) Quebrado (A) Expirado (A)
Acquire, nenhum ID de concessão proposto Arrendado (X) Falha (409) Falha (409) Arrendado (X) Arrendado (X)
Acquire (A) Arrendado (A) Concessão (A), nova duração Falha (409) Arrendado (A) Arrendado (A)
Acquire (B) Arrendado (B) Falha (409) Falha (409) Arrendado (B) Arrendado (B)
Break, ponto=0 Falha (409) Quebrado (A) Quebrado (A) Quebrado (A) Quebrado (A)
Break, ponto>0 Falha (409) Breaking (A) Breaking (A) Quebrado (A) Quebrado (A)
Change, (A) para (B) Falha (409) Arrendado (B) Falha (409) Falha (409) Falha (409)
Change, (B) para (A) Falha (409) Arrendado (A) Falha (409) Falha (409) Falha (409)
Change, (B) para (C) Falha (409) Falha (409) Falha (409) Falha (409) Falha (409)
Renew (A) Falha (409) Concessão (A), reposição do relógio de expiração Falha (409) Falha (409) Leased(A), se o blob não tiver sido modificado.

Falha (409) se o blob tiver sido modificado.
Renew (B) Falha (409) Falha (409) Falha (409) Falha (409) Falha (409)
Release (A) Falha (409) Disponível Disponível Disponível Disponível
Release (B) Falha (409) Falha (409) Falha (409) Falha (409) Falha (409)
A duração expira Disponível Expirado (A) Quebrado (A) Quebrado (A) Expirado (A)

Alterações ao Blob de Concessão introduzidas na versão 2012-02-12

A lista seguinte especifica as alterações ao Lease Blob comportamento introduzidas na versão 2012-02-12.

  • Uma chamada para Lease Blob adquirir uma concessão tem agora de incluir um cabeçalho de duração da concessão. Se tentar adquirir uma concessão sem especificar uma duração de concessão, o serviço devolve 400 Bad Request – Missing required header.

  • Já não pode renovar uma concessão depois de a lançar. Se tentar fazê-lo, o serviço devolve 409 Conflict – The lease ID specified did not match the lease ID for the blob. As aplicações que chamaram lançamento e, em seguida, chamaram renovação, têm agora de guardar a ETag da chamada de lançamento. Em seguida, as aplicações têm de chamar a aquisição, com um If-Match cabeçalho condicional, para adquirir a concessão apenas quando o blob não for alterado.

  • Já não pode interromper uma concessão depois de a lançar. Se tentar fazê-lo, o serviço devolve 409 Conflict – There is currently no lease on the blob.

  • Agora, pode interromper uma concessão de quebra ou interrupção, o que torna as operações de interrupção idempotentes. Em versões anteriores, isto falhou com 409 Conflict – The lease has already been broken and cannot be broken again. Esta alteração permite-lhe encurtar a duração de uma interrupção. Se interromper uma concessão que esteja no estado de interrupção e incluir uma duração mais curta do que o período de interrupção restante, será utilizada a duração mais curta.

Faturação

Os pedidos de preços podem ter origem em clientes que utilizam APIs de Armazenamento de Blobs, diretamente através da API REST do Armazenamento de Blobs ou a partir de uma biblioteca de cliente do Armazenamento do Azure. Estes pedidos acumulam custos por transação. O tipo de transação afeta a forma como a conta é cobrada. Por exemplo, as transações de leitura acumulam-se numa categoria de faturação diferente das transações de escrita. A tabela seguinte mostra a categoria de faturação dos Lease Blob pedidos com base no tipo de conta de armazenamento:

Operação Tipo de conta de armazenamento Categoria de faturação
Blob de Concessão (adquirir, lançar, renovar) Blob de bloco premium
Standard para fins gerais v2		 Outras operações
Blob de Concessão (adquirir, lançar, renovar) Standard para fins gerais v1 Operações de leitura
Blob de Concessão (quebra, alteração) Blob de bloco premium
Standard para fins gerais v2		 Outras operações
Blob de Concessão (quebra, alteração) Standard para fins gerais v1 Operações de escrita

Ver também

new-blob-lease-features-infinite-leases-smaller-lease-times-and-more.aspx)
Autorizar pedidos para o Armazenamento do Azure
Códigos de estado e de erro
Códigos de erro do Armazenamento de Blobs
Contentor de Concessão