Blobebene festlegen

Artikel
01/23/2025

Der vorgang Set Blob Tier legt die Zugriffsebene für ein BLOB fest. Der Vorgang ist in einem Seiten-BLOB in einem Premium-Speicherkonto und in einem Block-Blob in einem Blobspeicher oder einem allgemeinen v2-Konto zulässig. Die Ebene eines Premiumseiten-Blobs (P4/P6/P10/P15/P20/P30/P40/P50/P60) bestimmt die zulässige Größe, IOPS und Bandbreite des Blobs. Die Ebene eines Block-BLOB bestimmt Hot/Cool/Cold/Archive Speichertyp. Dieser Vorgang aktualisiert das ETag des BLOB nicht.

Ausführliche Informationen zu Block-Blob-Ebenen finden Sie unter Hot-, Cool- und Archivspeicherebenen.

Bitten

Sie können die Set Blob Tier Anforderung wie folgt erstellen. Es wird empfohlen, HTTPS zu verwenden. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos, und ersetzen Sie myblob durch den Blobnamen, für den die Ebene geändert werden soll.

Methode	Anforderungs-URI	HTTP-Version
`PUT`	`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=tier`	HTTP/1.1

URI-Parameter

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

Parameter	Beschreibung
`snapshot`	Wahlfrei. Der Snapshot-Parameter ist ein undurchsichtiger `DateTime` Wert, der, wenn vorhanden, die Blob-Momentaufnahme angibt, für die eine Ebene festgelegt werden soll. Weitere Informationen zum Arbeiten mit Blob-Momentaufnahmen finden Sie unter Erstellen einer Momentaufnahme eines Blob-
`versionid`	Optional für Version 2019-12-12 und höher. Der `versionid`-Parameter ist ein undurchsichtiger `DateTime` Wert, der, wenn vorhanden, die Version des BLOB angibt, für die eine Ebene festgelegt werden soll.
`timeout`	Wahlfrei. Der parameter `timeout` wird in Sekunden ausgedrückt. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgänge.

Anforderungsheader

Die erforderlichen und optionalen Anforderungsheader werden in der folgenden Tabelle beschrieben:

Anforderungsheader	Beschreibung
`Authorization`	Erforderlich. Gibt das Autorisierungsschema, den Speicherkontonamen 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 (UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
`x-ms-access-tier`	Erforderlich. Gibt die Ebene an, die für das Blob festgelegt werden soll. Eine Liste der zulässigen Premium-Seiten-BLOB-Ebenen finden Sie unter High-Performance Premium Storage und verwaltete Datenträger für VMs. Bei Blob-Speicher- oder allgemeinem v2-Konto sind gültige Werte `Hot`, `Cool`, `Cold`und `Archive`. Hinweis:`Cold` Ebene wird für Version 2021-12-02 und höher unterstützt. Ausführliche Informationen zur blob-Ebene auf Standard-BLOB-Ebene finden Sie unter Hot-, Cool- und Archivspeicherebenen.
`x-ms-version`	Erforderlich für alle autorisierten Anforderungen. Gibt die Version des Vorgangs an, der für diese Anforderung verwendet werden soll. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure Storage Services-.
`x-ms-client-request-id`	Wahlfrei. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Grenzwert von 1 kB Zeichen bereit, der in den Analyseprotokollen aufgezeichnet wird, wenn die Speicheranalyseprotokollierung aktiviert ist. Die Verwendung dieses Headers wird dringend empfohlen, um clientseitige Aktivitäten mit vom Server empfangenen Anforderungen zu korrelieren. Weitere Informationen finden Sie unter Zur Speicheranalyseprotokollierung.
`x-ms-rehydrate-priority`	Wahlfrei. Gibt die Priorität an, mit der ein archiviertes Blob rehydratiert werden soll. Unterstützt unter Version 2019-02-02 und höher für Block-Blobs. Gültige Werte sind `High`/`Standard`. Die Priorität kann für ein Blob nur einmal für Versionen vor 2020-06-12 festgelegt werden; dieser Header wird bei nachfolgenden Anforderungen ignoriert. Die Standardprioritätseinstellung ist `Standard`. Ab Version 2020-06-12 kann die Rehydrationspriorität aktualisiert werden, nachdem sie zuvor festgelegt wurde. Die Prioritätseinstellung kann von `Standard` in `High` geändert werden, indem sie Set Blob Tier aufrufen, wobei dieser Header auf `High` festgelegt ist und `x-ms-access-tier` auf denselben Wert festgelegt wird wie zuvor festgelegt. Die Prioritätseinstellung kann nicht von `High` auf `Standard`gesenkt werden.

Dieser Vorgang unterstützt auch die Verwendung von bedingten Headern, um das Blob nur zu stufen, wenn eine angegebene Bedingung erfüllt ist. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob Storage-Vorgänge.

Anforderungstext

Nichts.

Antwort

Die Antwort enthält einen HTTP-Statuscode und eine Reihe von Antwortheadern.

Statuscode

Ein erfolgreicher Vorgang gibt statuscode 200 (OK) zurück, wenn die neue Ebene sofort wirksam wird, oder Statuscode 202 (Akzeptiert), wenn der Übergang zur neuen Ebene aussteht.

Bei Premium-Speicherkonten gibt der Seiten-BLOB-Vorgang den Statuscode 200 (OK) zurück.

Für Block-Blobs werden die zurückgegebenen HTTP-Statuscodes basierend auf den aktuellen und angeforderten Ebenen des Blobs in der folgenden Tabelle beschrieben:

Rang	Auf heiße Ebene festlegen	Auf coole Ebene festlegen	Auf kalter Leiste festlegen	Auf Archivebene festlegen
Blob in der heißen Ebene	200	200	200	200
Blob in cooler Ebene	200	200	200	200
Blob in kalter Ebene	200	200	200	200
Blob in Archivebene	202	202	202	200
Blob in Archivebene, Rehydratisierung auf heiß	202	409	409	409
Blob in Archivebene, Rehydratisierung zum Kühlen	409	202	409	409
Blob in Archivebene, Rehydratisierung zu Kalt	409	409	202	409

Weitere Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.

Antwortheader

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

Antwortheader	Beschreibung
`x-ms-request-id`	Identifiziert eindeutig die Anforderung, die durchgeführt wurde, und kann zur Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
`x-ms-version`	Die Blob Storage-Version, die zum Ausführen der Anforderung verwendet wurde. Dieser Header wird für Anforderungen zurückgegeben, die mit Version 2009-09-19 und höher vorgenommen wurden.
`x-ms-client-request-id`	Kann verwendet werden, um Anfragen und entsprechende Antworten zu behandeln. Der Wert dieses Headers ist gleich dem Wert des `x-ms-client-request-id` Headers, wenn er in der Anforderung vorhanden ist und der Wert nicht mehr als 1.024 sichtbare ASCII-Zeichen enthält. Wenn der `x-ms-client-request-id`-Header in der Anforderung nicht vorhanden ist, ist er in der Antwort nicht vorhanden.

Ermächtigung

Die Autorisierung ist beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage erforderlich. Sie können den Set Blob Tier Vorgang wie unten beschrieben autorisieren.

Wichtig

Microsoft empfiehlt die Verwendung der Microsoft Entra-ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Die Microsoft Entra-ID bietet eine bessere Sicherheit und Benutzerfreundlichkeit im Vergleich zur Shared Key-Autorisierung.

Azure Storage unterstützt die Verwendung der Microsoft Entra-ID zum Autorisieren von Anforderungen an BLOB-Daten. Mit Der Microsoft Entra-ID können Sie azure role-based access control (Azure RBAC) verwenden, um Berechtigungen für einen Sicherheitsprinzipal zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine von Azure verwaltete Identität sein. Der Sicherheitsprinzipal wird von der Microsoft Entra-ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann dann verwendet werden, um eine Anforderung für den Blob-Dienst zu autorisieren.

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

Erlaubnisse

Nachfolgend sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra-Benutzer, eine Gruppe, eine verwaltete Identität oder einen Dienstprinzipal erforderlich ist, um den Set Blob Tier Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle, die diese Aktion enthält:

Azure RBAC-Aktion:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Rolle mit den geringsten Rechten:

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

Eine freigegebene Zugriffssignatur (SHARED Access Signature, SAS) bietet sicheren delegierten Zugriff auf Ressourcen in einem Speicherkonto. Mit einer SAS haben Sie präzise Kontrolle darüber, wie ein Client auf Daten zugreifen kann. Sie können angeben, auf welche Ressource der Client zugreifen kann, auf welche Berechtigungen sie für diese Ressourcen verfügen und wie lange die SAS gültig ist.

Der Set Blob Tier-Vorgang unterstützt drei Arten von freigegebenen Zugriffssignaturen: SAS-, Dienst-SAS-und Konto SAS.

Als bewährte Methode für die Sicherheit wird empfohlen, microsoft Entra-Anmeldeinformationen anstelle des Speicherkontoschlüssels zu verwenden, der einfacher kompromittiert werden kann. Wenn Für Ihr Anwendungsdesign freigegebene Zugriffssignaturen erforderlich sind, verwenden Sie microsoft Entra-Anmeldeinformationen, um nach Möglichkeit eine Benutzerdelegierungs-SAS zu erstellen.

Wenn der Zugriff auf gemeinsam genutzte Schlüssel für das Speicherkonto unzulässig ist, ist ein Dienst-SAS-Token oder ein Konto-SAS-Token für eine Anforderung an Blob Storage nicht zulässig. Weitere Informationen finden Sie unter Verstehen, wie sich die Teilung des freigegebenen Schlüssels auf SAS-Tokenauswirkt.

Sas der Benutzerdelegierung

Eine Benutzerdelegierungs-SAS ist mit Microsoft Entra-Anmeldeinformationen und auch durch die für die SAS angegebenen Berechtigungen gesichert.

Das Aufrufen des Set Blob Tier Vorgangs mit einem SAS-Token, das an einen Container oder eine BLOB-Ressource delegiert wird, erfordert die Write (w) Berechtigung als Teil des SAS-Tokens der Benutzerdelegierung.

Weitere Informationen zur SAS-Benutzerdelegierung finden Sie unter Erstellen einer Benutzerdelegierung SAS-.

Dienst-SAS

Ein Dienst-SAS ist mit dem Speicherkontoschlüssel gesichert. Ein Dienst-SAS delegiert den Zugriff auf eine Ressource in einem einzelnen Azure Storage-Dienst, z. B. Blob-Speicher.

Zum Aufrufen des Set Blob Tier Vorgangs mithilfe eines SAS-Tokens, das an einen Container oder eine BLOB-Ressource delegiert wird, ist die Write (w) Berechtigung als Teil des Dienst-SAS-Tokens erforderlich.

Weitere Informationen zum Dienst SAS finden Sie unter Erstellen eines Dienst-SAS-.

Konto SAS

Ein Konto-SAS ist mit dem Speicherkontoschlüssel gesichert. Ein Konto SAS delegiert den Zugriff auf Ressourcen in einem oder mehreren Speicherdiensten. Alle vorgänge, die über einen Dienst oder eine Benutzerdelegierung SAS verfügbar sind, stehen auch über ein Konto SAS zur Verfügung.

Die folgende Tabelle gibt den signierten Ressourcentyp und die signierten Berechtigungen an, die beim Delegieren des Zugriffs angegeben werden sollen:

Operation	Signierter Dienst	Signierter Ressourcentyp	Signierte Berechtigung
Blobebene festlegen	Blob (b)	Objekt (o)	Schreiben (w)

Weitere Informationen zum SAS-Konto finden Sie unter Erstellen eines Kontos sas.

Der Set Blob Tier-Vorgang unterstützt Gemeinsam genutzte Schlüsselautorisierung. Die Autorisierung mit Kontoschlüsseln wird für die meisten Szenarien nicht empfohlen, da sie weniger sicher ist.

Microsoft empfiehlt, die Autorisierung gemeinsam genutzter Schlüssel für das Speicherkonto nach Möglichkeit zu verbieten. Weitere Informationen finden Sie unter Verhindern der Autorisierung mit freigegebenem Schlüssel.

Bemerkungen

Das Festlegen der Ebene eines Blobs für Seitenblobs in Premium-Konten hat die folgenden Einschränkungen:

Die neue Blobebene darf nicht niedriger als die vorhandene sein.
Die neue BLOB-Ebene sollte in der Lage sein, die Inhaltslänge des Blobs aufzunehmen. Eine Liste der Ebenen und deren zulässige Inhaltslänge finden Sie unter Hochleistungsspeicher und verwaltete Datenträger für VMs.

Das Festlegen der Block-BLOB-Ebene für ein Blob Storage- oder allgemeines v2-Konto hat die folgenden Einschränkungen:

Das Festlegen einer Ebene für eine Momentaufnahme ist ab REST Version 2019-12-12 zulässig.
Momentaufnahmen, die auf archive gestuft sind, können nicht wieder in die Momentaufnahme hydratisiert werden. Das heißt, die Momentaufnahme kann nicht auf eine hot- oder cool-Ebene zurückgeführt werden. Die einzige Möglichkeit zum Abrufen der Daten aus einer archive Momentaufnahme oder -version besteht darin, sie in ein neues Blob zu kopieren.
Wenn es sich bei der Version um ein Stamm-BLOB handelt, kann sie wieder in hot oder coolrehydratisiert werden.
Momentaufnahmen oder Versionen in einem archive Zustand dürfen nicht in den Stamm höhergestuft werden.
Wenn die Versionsverwaltung aktiviert ist, führt das Löschen eines Stamm-Blobs, wenn es sich in einem rehydratischen ausstehenden Zustand befindet, zum Abbruch der Rehydratation und die Version in einem archive Zustand.
Wenn ein Blob überschrieben wird, wenn es sich in einem ausstehenden und vorläufig gelöschten Zustand befindet, führt es zum Abbruch der Rehydratation, und die Version der vorläufig gelöschten Momentaufnahme befindet sich in einem archive Zustand.

Die Liste der unterstützten Ebenen ist nicht durch die Anforderungsversion eingeschränkt, und neue Ebenen können in Zukunft hinzugefügt werden.

Für Blobs, die vom Kunden bereitgestellte Verschlüsselung verwenden, wird Set Blob Tier für Version 2023-08-03 und höher unterstützt. Für Versionen vor 2023-08-03 gibt Set Blob Tier Statuscode 409 für Blobs zurück, die vom Kunden bereitgestellte Verschlüsselung verwenden.

Anmerkung

Ausführliche Informationen zur Block-Blob-Ebenenebene finden Sie unter Hot-, Cool- und Archivspeicherebenen.

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. Diese Anforderungen anfallen Gebühren pro Transaktion. Der Transaktionstyp wirkt sich auf die Belastung des Kontos aus. Lesen Sie z. B. Transaktionen, die einer anderen Abrechnungskategorie als dem Schreiben von Transaktionen zugerechnet werden. Die folgende Tabelle zeigt die Abrechnungskategorie für Set Blob Tier Anforderungen basierend auf dem Speicherkontotyp:

Operation	Speicherkontotyp	Abrechnungskategorie
Blob-Ebene festlegen (Ebene nach unten)	Premium-Block-BLOB Standard general-purpose v2	Schreibvorgänge
Einrichten der BLOB-Ebene (Leiste nach oben)	Premium-Block-BLOB Standard general-purpose v2	Lesevorgänge

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

Siehe auch

Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes
Festlegen von Timeouts für Blob Storage-Vorgänge

Freigeben über