Freigeben über

Lease Container

  • Artikel

Der Lease Container-Vorgang richtet für einen Container eine Sperre für Löschvorgänge ein und verwaltet diese. Die Sperrdauer kann 15 bis 60 Sekunden betragen oder unendlich sein.

Sie können den Lease Container Vorgang in einem der folgenden Modi aufrufen:

  • Acquire, um eine neue Lease anzufordern.

  • Renew, um eine vorhandene Lease zu verlängern.

  • Change, um die ID einer vorhandenen Lease zu ändern.

  • Release, um die Lease freizugeben, wenn sie nicht mehr benötigt wird, damit ein anderer Client sofort eine Lease für den Container erwerben kann.

  • Break, um die Lease zu beenden, aber sicherstellen, dass ein anderer Client erst eine neue Lease erwerben kann, wenn der aktuelle Leasezeitraum abgelaufen ist.

Hinweis

Der Lease Container-Vorgang ist in Version 2012-02-12 und höheren Versionen verfügbar.

Anforderung

Sie können die Lease Container Anforderung wie folgt erstellen. HTTPS wird empfohlen. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos.

Methode Anforderungs-URI HTTP-Version
PUT https://myaccount.blob.core.windows.net/mycontainer?comp=lease&restype=container HTTP/1.1

Geben Sie zum Angeben des Stammcontainers $root als Containernamen ein.

Emulierter Speicherdienst-URI

Wenn Sie eine Anforderung für den emulierten Speicherdienst stellen, geben Sie den Hostnamen des Emulators und Azure Blob Storage Port als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos.

Methode Anforderungs-URI HTTP-Version
PUT http://127.0.0.1:10000/mycontainer?comp=lease&restype=container HTTP/1.0

HTTP/1.1

Weitere Informationen finden Sie unter Verwenden des Azurite-Emulators für die lokale Azure Storage-Entwicklung.

URI-Parameter

Sie können den folgenden zusätzlichen Parameter für den Anforderungs-URI angeben.

Parameter BESCHREIBUNG
timeout Optional. Der timeout-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgänge.

Anforderungsheader

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

Anforderungsheader BESCHREIBUNG
Authorization Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Date oder x-ms-date Erforderlich. Gibt die koordinierte Weltzeit (Coordinated Universal Time, UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Optional. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
x-ms-lease-id: <ID> Erforderlich, um die Lease zu verlängern, zu ändern oder freizugeben.

Sie können den Wert von x-ms-lease-id in einem beliebigen gültigen GUID-Zeichenfolgenformat angeben. Eine Liste gültiger Formate finden Sie unter Guid-Konstruktor (String).
x-ms-lease-action: <acquire ¦ renew ¦ change ¦ release ¦ break> acquire: Fordert eine neue Lease an. Wenn der Container keine aktive Lease aufweist, erstellt Blob Storage eine Lease für den Container und gibt eine neue Lease-ID zurück. Wenn der Container über eine aktive Lease verfügt, können Sie nur mithilfe der aktiven Lease-ID eine neue Lease anfordern. Sie können jedoch einen neuen x-ms-lease durationangeben, einschließlich einer negativen (-1) für eine Lease, die nie abläuft.

renew: Verlängert die Lease. Sie können die Lease verlängern, wenn die in der Anforderung angegebene Lease-ID der dem Container zugeordneten entspricht. Beachten Sie, dass die Lease auch dann verlängert werden kann, wenn sie abgelaufen ist, solange der Container seit Ablauf dieser Lease nicht erneut geleast wurde. Beim Verlängern einer Lease wird die Leasedauer zurückgesetzt.

change: Ändert die Lease-ID einer aktiven Lease. Ein change muss die aktuelle Lease-ID in x-ms-lease-idund eine neue Lease-ID in x-ms-proposed-lease-identhalten.

release: Gibt die Lease frei. Sie können die Lease freigeben, wenn die in der Anforderung angegebene Lease-ID der dem Container zugeordneten entspricht. Durch das Freigeben der Lease kann ein anderer Client sofort die Lease für den Container erwerben, sobald das Release abgeschlossen ist.

break: Unterbricht die Lease, wenn der Container über eine aktive Lease verfügt. Nachdem ein Lease unterbrochen wurde, kann sie nicht mehr verlängert werden. Jede autorisierte Anforderung kann die Lease unterbrechen. Die Anforderung ist nicht erforderlich, um eine übereinstimmende Lease-ID anzugeben. Wenn eine Lease unterbrochen wird, darf der Leaseunterbrechungszeitraum verstreichen. Während dieser Zeit können Sie nur Vorgänge für den Container ausführen break und release leasen. Wenn eine Lease erfolgreich unterbrochen wurde, gibt die Antwort das Intervall in Sekunden an, bis eine neue Lease abgerufen werden kann.

Eine Lease, die unterbrochen wurde, kann auch freigegeben werden. Ein Client kann eine freigegebene Containerlease sofort abrufen.
x-ms-lease-break-period: N Optional. Bei einem break Vorgang ist dieser Header die vorgeschlagene Dauer, die die Lease fortsetzen soll, bevor sie unterbrochen wird, zwischen 0 und 60 Sekunden. Dieser Pausenzeitraum wird nur verwendet, wenn er kürzer ist als die verbleibende Zeit für die Lease. Ist er länger, wird die verbleibende Zeit für die Lease verwendet. Eine neue Lease ist nicht verfügbar, bevor der Pausenzeitraum abgelaufen ist, aber die Lease kann länger als der Pausenzeitraum aufbewahrt werden. Wenn dieser Header bei einem break Vorgang nicht angezeigt wird, wird eine Lease mit fester Dauer nach Ablauf des verbleibenden Leasezeitraums unterbrochen, und eine unendliche Lease bricht sofort.
x-ms-lease-duration: -1 ¦ n seconds Erforderlich für acquire. Gibt die Dauer der Lease in Sekunden oder als minus eins (-1) für eine nie ablaufende Lease an. Die Dauer einer nicht unendlichen Lease kann zwischen 15 und 60 Sekunden liegen. Eine Leasedauer kann nicht mit renew oder changegeändert werden.
x-ms-proposed-lease-id: <ID> Optional für acquireund erforderlich für change. Vorgeschlagene Lease-ID in einem GUID-Zeichenfolgenformat. Blob Storage gibt zurück 400 (Invalid request) , wenn die vorgeschlagene Lease-ID nicht im richtigen Format vorliegt. Eine Liste gültiger Formate finden Sie unter Guid-Konstruktor (String).
Origin Optional. Gibt die Ursprungsdomäne an, von der die Anforderung ausgegeben wird. Wenn dieser Header vorhanden ist, werden CORS (Cross-Origin Resource Sharing)-Header für die Antwort erzeugt. Weitere Informationen finden Sie unter CORS-Unterstützung für die Speicherdienste .
x-ms-client-request-id Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (KiB) bereit, der beim Konfigurieren der Protokollierung in den Protokollen aufgezeichnet wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter Überwachen Azure Blob Storage.

Dieser Vorgang unterstützt auch die Verwendung bedingter Header zum Ausführen des Vorgangs nur, wenn eine angegebene Bedingung erfüllt ist. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob Storage-Vorgänge.

Anforderungstext

Keine.

Beispiel für eine Anforderung

Die folgende Beispielanforderung zeigt, wie eine Lease abgerufen wird:

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=lease HTTP/1.1  
  
Request Headers:  
x-ms-version: 2012-02-12  
x-ms-lease-action: acquire  
x-ms-lease-duration: -1  
x-ms-proposed-lease-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-date: Thu, 26 Jan 2012 23:30:18 GMT  
Authorization: SharedKey testaccount1:esSKMOYdK4o+nGTuTyeOLBI+xqnqi6aBmiW4XI699+o=

Antwort

Die Antwort enthält den HTTP-Statuscode und einen Satz von Antwortheadern.

Statuscode

Die für Leasevorgänge zurückgegebenen Codes für den Erfolgsstatus lauten wie folgt:

  • Acquire: Bei einem erfolgreichen Vorgang wird der Statuscode 201 (Erstellt) zurückgegeben.

  • Renew: Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben.

  • Change: Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben.

  • Release: Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben.

  • Break: Ein erfolgreicher Vorgang gibt den Statuscode 202 (Akzeptiert) zurück.

Informationen zu status Codes finden Sie unter Status- und Fehlercodes.

Antwortheader

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort kann auch zusätzliche HTTP-Standardheader enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Syntax BESCHREIBUNG
ETag Die ETag für den Container. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2013-08-15 und höher ausgeführt werden, und der ETag Wert wird in Anführungszeichen angegeben. Lease Container Vorgänge, die für Version 2013-08-15 und höher vorgenommen werden, ändern diese Eigenschaft nicht, aber frühere Versionen ändern dies.
Last-Modified Wird für Anforderungen zurückgegeben, die für Version 2013-08-15 und höher ausgeführt wurden. Gibt das Datum und die Uhrzeit der letzten Änderung des Containers zurück. Weitere Informationen finden Sie unter Darstellung von Datums-/Uhrzeitwerten in Headern.

Jeder Vorgang, der den Container oder seine Eigenschaften oder Metadaten ändert, aktualisiert den Zeitpunkt der letzten Änderung. Dies schließt das Festlegen der Berechtigungen für den Container ein. Vorgänge für Blobs wirken sich nicht auf den Zeitpunkt der letzten Änderung des Containers aus. Lease Container Vorgänge, die für Version 2013-08-15 und höher vorgenommen werden, ändern diese Eigenschaft nicht, aber frühere Versionen ändern dies.
x-ms-lease-id: <id> Wenn Sie eine Lease anfordern, gibt Blob Storage eine eindeutige Lease-ID zurück. Während die Lease aktiv ist, müssen Sie die Lease-ID bei jeder Anforderung zum Löschen des Containers sowie bei jeder Anforderung zum Verlängern, Ändern oder Freigeben der Lease einschließen.

Bei einem erfolgreichen Verlängerungsvorgang wird auch die Lease-ID für die aktive Lease zurückgegeben.
x-ms-lease-time: seconds Die geschätzte verbleibende Zeit der Leasedauer in Sekunden. Dieser Header wird nur bei einer erfolgreichen Anforderung zur Unterbrechung der Lease zurückgegeben. Wenn die Unterbrechung sofort erfolgt, wird 0 zurückgegeben.
x-ms-request-id Dieser Header identifiziert die durchgeführte Anforderung eindeutig und kann für die Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
x-ms-version Gibt die Version von Blob Storage an, die zum Ausführen der Anforderung verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher erfolgen.
Date Ein UTC-Datums-/Uhrzeitwert, der den Zeitpunkt angibt, zu dem die Antwort initiiert wurde. Der Dienst generiert diesen Wert.
Access-Control-Allow-Origin Wird zurückgegeben, wenn die Anforderung einen Origin Header enthält und CORS mit einer Abgleichsregel aktiviert ist. Dieser Header gibt den Wert des Origin-Anforderungsheaders im Falle einer Übereinstimmung zurück.
Access-Control-Expose-Headers Wird zurückgegeben, wenn die Anforderung einen Origin Header enthält und CORS mit einer Abgleichsregel aktiviert ist. Gibt die Liste der Antwortheader zurück, die gegenüber dem Client oder Aussteller der Anforderung verfügbar gemacht werden sollen.
Access-Control-Allow-Credentials Wird zurückgegeben, wenn die Anforderung einen Origin Header enthält und CORS mit einer Abgleichsregel aktiviert ist, die nicht alle Ursprünge zulässt. Dieser Header wird auf truefestgelegt.
x-ms-client-request-id Sie können diesen Header verwenden, um Probleme mit Anforderungen und entsprechenden Antworten zu beheben. Der Wert dieses Headers ist gleich dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist. Der Wert beträgt höchstens 1.024 sichtbare ASCII-Zeichen. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist er in der Antwort nicht vorhanden.

Antworttext

Keine.

Beispiel für eine Antwort

Im Folgenden finden Sie eine Beispielantwort für eine Anforderung zum Abrufen einer Lease:

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: 2012-02-12  
x-ms-lease-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
Date: Thu, 26 Jan 2012 23:30:18 GMT

Authorization

Eine Autorisierung ist erforderlich, wenn Sie einen Datenzugriffsvorgang in Azure Storage aufrufen. Sie können den Lease Container Vorgang wie in den folgenden Abschnitten beschrieben autorisieren.

Wichtig

Microsoft empfiehlt die Verwendung von Microsoft Entra ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Microsoft Entra ID bietet im Vergleich zur Autorisierung mit gemeinsam genutzten Schlüsseln eine höhere Sicherheit und Benutzerfreundlichkeit.

Azure Storage unterstützt die Verwendung von Microsoft Entra ID zum Autorisieren von Anforderungen für Blobdaten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) verwenden, um einem Sicherheitsprinzipal Berechtigungen zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Azure-Identität sein. Der Sicherheitsprinzipal wird von Microsoft Entra ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann dann verwendet werden, um eine Anforderung für Blob Storage zu autorisieren.

Weitere Informationen zur Autorisierung mit Microsoft Entra ID finden Sie unter Autorisieren des Zugriffs auf Blobs mithilfe von Microsoft Entra ID.

Berechtigungen

Die folgenden RBAC-Aktionen sind erforderlich, damit ein Microsoft Entra Benutzer, eine Gruppe, eine verwaltete Identität oder ein Dienstprinzipal den Lease Container Vorgang aufrufen kann, und die integrierte Azure RBAC-Rolle mit den geringsten Berechtigungen, die diese Aktion enthält:

Weitere Informationen zum Zuweisen von Rollen mithilfe von Azure RBAC finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf Blobdaten.

Hinweise

Eine Lease für einen Container bietet exklusiven Löschzugriff auf den Container. Eine Containerlease steuert nur die Möglichkeit, den Container mithilfe des Vorgangs Container löschen zu löschen. Um einen Container mit einer aktiven Lease zu löschen, muss ein Client die ID der aktiven Lease bei der Löschanforderung angeben. Wenn die Lease-ID nicht enthalten ist, schlägt der Vorgang mit 412 (Vorbedingung fehlgeschlagen) fehl. Alle anderen Containervorgänge sind in einem geleasten Container erfolgreich, ohne die Lease-ID zu enthalten. Die Lease wird für die Dauer gewährt, die beim Erwerb der Lease angegeben wird, die zwischen 15 und 60 Sekunden oder eine unbegrenzte Dauer betragen kann.

Wenn ein Client eine Lease abruft, wird eine Lease-ID zurückgegeben. Blob Storage generiert eine Lease-ID, wenn keine in der Abrufanforderung angegeben ist. Der Client kann diese Lease-ID verwenden, um die Lease zu verlängern, seine Lease-ID zu ändern oder die Lease freizugeben. Das folgende Diagramm zeigt die möglichen Zustände einer Lease und die Befehle oder Ereignisse, die zu Änderungen des Leasestatus führen.

Diagramm der Containerleasingzustände und Zustandsänderungstrigger.

Eine Lease kann sich in einem von fünf Bundesstaaten befinden, je nachdem, ob die Lease gesperrt oder entsperrt ist und ob die Lease in diesem Zustand erneuerbar ist. Die im vorherigen Diagramm gezeigten Leaseaktionen verursachen Zustandsübergänge.

Erneuerungs-status Gesperrte Lease Entsperrte Lease
Lease für erneuerbare Energien Geleast Abgelaufen
Nicht erneuerbare Lease Breaking Unterbrochen, verfügbar

  • Available: Die Lease wird entsperrt und kann abgerufen werden. Zulässige Aktion: acquire.

  • Leased: Die Lease wird gesperrt. Zulässige Aktionen: acquire (nur dieselbe Lease-ID), renew, change, release und break.

  • Expired: Die Leasedauer ist abgelaufen. Zulässige Aktionen: acquire, renew, release und break.

  • Breaking, wurde die Lease abgebrochen, aber die Lease wird weiterhin gesperrt, bis der Pausenzeitraum abgelaufen ist. Zulässige Aktionen: release und break.

  • Broken, die Lease wurde unterbrochen, und der Pausenzeitraum ist abgelaufen. Zulässige Aktionen: acquire, release und break.

Blob Storage behält die Lease-ID bei, nachdem eine Containerlease abgelaufen ist. Ein Client kann die Lease erneuern oder freigeben, indem er seine abgelaufene Lease-ID verwendet. Wenn der Client versucht, eine abgelaufene Lease mit der vorherigen Lease-ID zu erneuern oder freizugeben, und die Anforderung schlägt fehl, wurde der Container erneut geleast oder gelöscht, da die Lease des Clients zuletzt aktiv war.

Wenn eine Lease abläuft, anstatt explizit freigegeben zu werden, muss ein Client möglicherweise bis zu einer Minute warten, bevor eine neue Lease für den Container erworben werden kann. Der Client kann jedoch die Lease mit der abgelaufenen Lease-ID sofort verlängern.

Die Eigenschaft des Last-Modified-Time Containers wird nicht durch Aufrufe von Lease Containeraktualisiert.

In den folgenden Tabellen werden die Ergebnisse von Aktionen für Container mit Leases in verschiedenen Leasestatus aufgelistet. Die Buchstaben (A), (B) und (C) stellen Lease-IDs dar, und (X) stellt eine von Blob Storage generierte Lease-ID dar.

Ergebnisse der Nutzungsversuche für Container nach Leasestatus

Aktion Verfügbar Geleast (A) Unterbrechen (A) Unterbrochen (A) Abgelaufen (A)
Löschen mit (A) Fehler (412) Geleast (A), Löschvorgang erfolgreich Unterbrechen (A), Löschvorgang erfolgreich Fehler (412) Fehler (412)
Löschen mit (B) Fehler (412) Fehler (409) Fehler (412) Fehler (412) Fehler (412)
Löschen, keine Lease angegeben Verfügbar, Löschvorgang erfolgreich Fehler (412) Fehler (412) Verfügbar, Löschvorgang erfolgreich Verfügbar, Löschvorgang erfolgreich
Andere Vorgänge mit (A) Fehler (412) Geleast (A), Vorgang erfolgreich Unterbrechen (A), Vorgang erfolgreich Fehler (412) Fehler (412)
Andere Vorgänge mit (B) Fehler (412) Fehler (409) Fehler (409) Fehler (412) Fehler (412)
Vorgänge, keine Lease angegeben Verfügbar, Vorgang erfolgreich Geleast (A), Vorgang erfolgreich Unterbrechen (A), Vorgang erfolgreich Unterbrochen (A), Vorgang erfolgreich Abgelaufen (A), Vorgang erfolgreich

Ergebnisse von Leasevorgängen für Container nach Leasestatus

Aktion Verfügbar Geleast (A) Unterbrechen (A) Unterbrochen (A) Abgelaufen (A)
Acquire, keine vorgeschlagene Lease-ID Geleast (X) Fehler (409) Fehler (409) Geleast (X) Geleast (X)
Acquire (A) Geleast (A) Geleast (A), neue Dauer Fehler (409) Geleast (A) Geleast (A)
Acquire (B) Geleast (B) Fehler (409) Fehler (409) Geleast (B) Geleast (B)
Break, Zeitraum=0 Fehler (409) Unterbrochen (A) Unterbrochen (A) Unterbrochen (A) Unterbrochen (A)
Break, Punkt>0 Fehler (409) Unterbrechen (A) Unterbrechen (A) Unterbrochen (A) Unterbrochen (A)
Change, (A) in (B) Fehler (409) Geleast (B) Fehler (409) Fehler (409) Fehler (409)
Change, (B) in (A) Fehler (409) Geleast (A) Fehler (409) Fehler (409) Fehler (409)
Change, (B) in (C) Fehler (409) Fehler (409) Fehler (409) Fehler (409) Fehler (409)
Renew (A) Fehler (409) Geleast (A), Ablaufdauer zurückgesetzt Fehler (409) Fehler (409) Geleast (A)
Renew (B) Fehler (409) Fehler (409) Fehler (409) Fehler (409) Fehler (409)
Release (A) Fehler (409) Verfügbar Verfügbar Verfügbar Verfügbar
Release (B) Fehler (409) Fehler (409) Fehler (409) Fehler (409) Fehler (409)
Dauer läuft ab Verfügbar Abgelaufen (A) Unterbrochen (A) Unterbrochen (A) Abgelaufen (A)

Abrechnung

Preisanforderungen können von Clients stammen, die Blob Storage-APIs verwenden, entweder direkt über die Blob Storage-REST-API oder aus einer Azure Storage-Clientbibliothek. Für diese Anforderungen fallen Gebühren pro Transaktion an. Die Art der Transaktion wirkt sich auf die Abrechnung des Kontos aus. Beispielsweise werden Lesetransaktionen einer anderen Abrechnungskategorie zugeordnet als Schreibtransaktionen. Die folgende Tabelle zeigt die Abrechnungskategorie für Lease Container Anforderungen basierend auf dem Speicherkontotyp:

Vorgang Speicherkontotyp Abrechnungskategorie
Leasecontainer (erwerben, freigeben, erneuern) Premium, Blockblob
Standard „Allgemein v2“		 Weitere Vorgänge
Leasecontainer (erwerben, freigeben, erneuern) Standard „Allgemein v1“ Dient zum Lesen von Vorgängen.
Leasecontainer (Unterbrechung, Änderung) Premium, Blockblob
Standard „Allgemein v2“		 Weitere Vorgänge
Leasecontainer (Unterbrechung, Änderung) Standard „Allgemein v1“ Schreibvorgänge

Informationen zu den Preisen für die angegebene Abrechnungskategorie finden Sie unter Azure Blob Storage Preise.

Weitere Informationen

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes
Lease Blob