Définir le niveau d’objet blob

L’opération Set Blob Tier définit le niveau d’accès sur un objet blob. L’opération est autorisée sur un objet blob de pages dans un compte de stockage Premium et sur un objet blob de blocs dans un compte de stockage d’objets blob ou v2 à usage général. Le niveau d’un objet blob de pages Premium (P4/P6/P10/P15/P20/P30/P40/P50/P60) détermine la taille, les IOPS et la bande passante autorisées de l’objet blob. Le niveau d’un objet blob de blocs détermine Hot/Cool/Cold/Archive type de stockage. Cette opération ne met pas à jour l’ETag de l’objet blob.

Pour plus d’informations sur la hiérarchisation au niveau de l’objet blob de blocs, consultez niveaux de stockage chaud, froid et archive.

Demander

Vous pouvez construire la requête Set Blob Tier comme suit. Nous vous recommandons d’utiliser HTTPS. Remplacez mon compte par le nom de votre compte de stockage, puis remplacez myblob par le nom de l’objet blob pour lequel le niveau doit être modifié.

Méthode	URI de requête	Version HTTP
PUT	https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=tier	HTTP/1.1

Paramètres d’URI

Vous pouvez spécifier les paramètres supplémentaires suivants sur l’URI de requête :

Paramètre	Description
snapshot	Optionnel. Le paramètre d’instantané est une valeur de DateTime opaque qui, lorsqu’il est présent, spécifie l’instantané d’objet blob sur lequel définir un niveau. Pour plus d’informations sur l’utilisation des instantanés d’objets blob, consultez Créer un instantané d’un objet blob
versionid	Facultatif pour la version 2019-12-12 et ultérieure. Le paramètre versionid est une valeur de DateTime opaque qui, lorsqu’il est présent, spécifie la version de l’objet blob sur laquelle définir un niveau.
timeout	Optionnel. Le paramètre timeout est exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’attente pour les opérations de stockage Blob.

En-têtes de requête

Les en-têtes de requête obligatoires et facultatifs sont décrits dans le tableau suivant :

En-tête de requête	Description
Authorization	Obligatoire. Spécifie le schéma d’autorisation, le nom du compte de stockage et la signature. Pour plus d’informations, consultez Autoriser les demandes vers le stockage Azure.
Date ou x-ms-date	Obligatoire. Spécifie le temps universel coordonné (UTC) de la requête. Pour plus d’informations, consultez Autoriser les demandes vers le stockage Azure.
x-ms-access-tier	Obligatoire. Indique le niveau à définir sur l’objet blob. Pour obtenir la liste des niveaux d’objets blob de pages Premium autorisés, consultez Stockage Premium hautes performances et disques managés pour les machines virtuelles. Pour le stockage d’objets blob ou le compte v2 universel, les valeurs valides sont Hot, Cool, Coldet Archive. Remarque :Cold niveau est pris en charge pour la version 2021-12-02 et ultérieure. Pour plus d’informations sur la hiérarchisation au niveau des objets blob de compte d’objets blob standard, consultez niveaux de stockage chaud, froid et archive.
x-ms-version	Obligatoire pour toutes les demandes autorisées. Spécifie la version de l’opération à utiliser pour cette requête. Pour plus d’informations, consultez Contrôle de version pour les services de stockage Azure.
x-ms-client-request-id	Optionnel. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kB enregistrée dans les journaux d’analyse lorsque la journalisation d’analytique de stockage est activée. L’utilisation de cet en-tête est vivement recommandée pour la corrélation des activités côté client avec les demandes reçues par le serveur. Pour plus d’informations, consultez à propos de la journalisation Storage Analytics.
x-ms-rehydrate-priority	Optionnel. Indique la priorité avec laquelle réalimenter un objet blob archivé. Prise en charge sur la version 2019-02-02 et ultérieure pour les objets blob de blocs. Les valeurs valides sont High/Standard. La priorité peut être définie sur un objet blob une seule fois pour les versions antérieures à 2020-06-12 ; cet en-tête est ignoré sur les demandes suivantes. Le paramètre de priorité par défaut est Standard. À compter de la version 2020-06-12, la priorité de réhydratation peut être mise à jour après avoir été définie précédemment. Le paramètre de priorité peut être modifié de Standard à High en appelant définir le niveau d’objet blob avec cet en-tête défini sur High et le paramètre x-ms-access-tier sur la même valeur que celle définie précédemment. Le paramètre de priorité ne peut pas être réduit de High à Standard.

Cette opération prend également en charge l’utilisation d’en-têtes conditionnels pour hiérarchiser l’objet blob uniquement si une condition spécifiée est remplie. Pour plus d’informations, consultez Spécifier des en-têtes conditionnels pour les opérations de stockage Blob.

Corps de la demande

Aucun.

Réponse

La réponse inclut un code d’état HTTP et un ensemble d’en-têtes de réponse.

Code d’état

Une opération réussie retourne le code d’état 200 (OK) si le nouveau niveau prend effet immédiatement ou si le code d’état 202 (accepté) si la transition vers le nouveau niveau est en attente.

Pour les comptes de stockage Premium, l’opération d’objet blob de pages retourne le code d’état 200 (OK).

Pour les objets blob de blocs, les codes d’état HTTP retournés, en fonction des niveaux actuels et demandés de l’objet blob, sont décrits dans le tableau suivant :

Niveau	Définir sur le niveau chaud	Définir le niveau froid	Définir sur le niveau froid	Définir sur le niveau Archive
Blob dans le niveau chaud	200	200	200	200
Objet blob dans le niveau froid	200	200	200	200
Objet blob dans le niveau froid	200	200	200	200
Objet blob dans le niveau Archive	202	202	202	200
Objet blob dans le niveau Archive, réhydratage à chaud	202	409	409	409
Blob dans le niveau Archive, réhydratage pour refroidir	409	202	409	409
Objet blob dans le niveau Archive, réhydratage à froid	409	409	202	409

Pour plus d’informations sur les codes d’état, consultez Les codes d’état et d’erreur.

En-têtes de réponse

La réponse de cette opération inclut les en-têtes suivants. La réponse peut également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification de protocole HTTP/1.1.

En-tête de réponse	Description
x-ms-request-id	Identifie de manière unique la demande qui a été effectuée et peut être utilisée pour résoudre les problèmes de la demande. Pour plus d’informations, consultez Résoudre les problèmes d’opérations d’API.
x-ms-version	Version de Stockage Blob utilisée pour exécuter la requête. Cet en-tête est retourné pour les requêtes effectuées sur la version 2009-09-19 et ultérieures.
x-ms-client-request-id	Peut être utilisé pour résoudre les demandes et les réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête x-ms-client-request-id s’il est présent dans la requête et que la valeur ne contient pas plus de 1 024 caractères ASCII visibles. Si l’en-tête x-ms-client-request-id n’est pas présent dans la requête, il ne sera pas présent dans la réponse.

Autorisation

L’autorisation est requise lors de l’appel d’une opération d’accès aux données dans stockage Azure. Vous pouvez autoriser l’opération de Set Blob Tier comme décrit ci-dessous.

Important

Microsoft recommande d’utiliser l’ID Microsoft Entra avec des identités managées pour autoriser les demandes adressées au stockage Azure. Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures par rapport à l’autorisation de clé partagée.

'ID Microsoft Entra (recommandé)

Stockage Azure prend en charge l’utilisation de l’ID Microsoft Entra pour autoriser les demandes aux données d’objet blob. Avec l’ID Microsoft Entra, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée Azure. Le principal de sécurité est authentifié par l’ID Microsoft Entra pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une demande auprès du service Blob.

Pour en savoir plus sur l’autorisation à l’aide de l’ID Microsoft Entra, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID.

Autorisations

Voici l’action RBAC nécessaire pour un utilisateur, un groupe, une identité managée ou un principal de service Microsoft Entra pour appeler l’opération de Set Blob Tier et le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

• action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/blobs/write
• rôle intégré moins privilégié :Contributeur aux données Blob de stockage

Pour en savoir plus sur l’attribution de rôles à l’aide d’Azure RBAC, consultez Attribuer un rôle Azure pour accéder aux données blob.

signatures d’accès partagé (SAP)

Une signature d’accès partagé (SAP) fournit un accès délégué sécurisé aux ressources d’un compte de stockage. Avec une SAP, vous avez un contrôle granulaire sur la façon dont un client peut accéder aux données. Vous pouvez spécifier la ressource à laquelle le client peut accéder, les autorisations dont il a besoin pour ces ressources et la durée pendant laquelle la SAP est valide.

L’opération de prend en charge trois types de signatures d’accès partagé : SAP de délégation d’utilisateur, sap sapde service et de compte .

Comme meilleure pratique de sécurité, nous vous recommandons d’utiliser les informations d’identification Microsoft Entra plutôt que la clé de compte de stockage, qui peut être plus facilement compromise. Si la conception de votre application nécessite des signatures d’accès partagé, utilisez les informations d’identification Microsoft Entra pour créer une SAP de délégation d’utilisateur, le cas échéant.

Lorsque l’accès à la clé partagée n’est pas autorisé pour le compte de stockage, un jeton SAP de service ou un jeton SAP de compte n’est pas autorisé sur une demande adressée au stockage Blob. Pour plus d’informations, consultez Comprendre comment le refus de la clé partagée affecte les jetons SAP.

SAP de délégation d’utilisateur

Une SAP de délégation d’utilisateur est sécurisée avec les informations d’identification Microsoft Entra et également par les autorisations spécifiées pour la SAP.

L’appel de l’opération de Set Blob Tier à l’aide d’un jeton SAP délégué à un conteneur ou à une ressource d’objet blob nécessite l’autorisation écriture (w) dans le cadre du jeton SAP de délégation d’utilisateur.

Pour en savoir plus sur la SAP de délégation d’utilisateur, consultez Créer une SAP de délégation d’utilisateur.

SAP de service

Une SAP de service est sécurisée avec la clé de compte de stockage. Une SAP de service délègue l’accès à une ressource dans un seul service stockage Azure, tel que le stockage d’objets blob.

L’appel de l’opération de à l’aide d’un jeton SAP délégué à un conteneur ou à une ressource d’objet blob nécessite l’autorisation écriture (w) dans le cadre du jeton SAP de service.

Pour en savoir plus sur la SAP de service, consultez Créer une SAP de service.

SAP de compte

Une SAP de compte est sécurisée avec la clé de compte de stockage. Une SAP de compte délègue l’accès aux ressources dans un ou plusieurs des services de stockage. Toutes les opérations disponibles via une SAP de délégation de service ou d’utilisateur sont également disponibles via une SAP de compte.

Le tableau suivant indique le type de ressource signé et les autorisations signées à spécifier lors de la délégation de l’accès :

Opération	Service signé	Type de ressource signé	Autorisation signée
Définir le niveau d’objet blob	Blob (b)	Object (o)	Écriture (w)

Pour en savoir plus sur la SAP de compte, consultez Créer une SAP de compte.

L’opération de Set Blob Tier prend en charge d’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée pour la plupart des scénarios, car elle est moins sécurisée.

Microsoft recommande de refuser l’autorisation de clé partagée pour le compte de stockage si possible. Pour plus d’informations, consultez Empêcher l’autorisation avec lede clé partagée.

Remarques

La définition du niveau d’un objet blob pour les objets blob de pages dans les comptes Premium a les restrictions suivantes :

• Le nouveau niveau d’objet blob ne peut pas être inférieur à celui existant.
• Le nouveau niveau d’objet blob doit être en mesure de prendre en charge la longueur du contenu de l’objet blob. Pour obtenir la liste des niveaux et leur longueur de contenu autorisée, consultez stockage Premium hautes performances et disques managés pour les machines virtuelles.

La définition du niveau de l’objet blob de blocs sur un compte Stockage Blob ou v2 à usage général a les restrictions suivantes :

• La définition d’un niveau sur un instantané est autorisée à partir de REST version 2019-12-12.
• Les instantanés hiérarchisé à archive ne peuvent pas être réhydratés dans l’instantané. Autrement dit, l’instantané ne peut pas être ramené à un niveau hot ou cool. La seule façon de récupérer les données à partir d’une capture instantanée ou d’une version archive consiste à la copier dans un nouvel objet blob.
• Si la version est un objet blob racine, elle peut être réhydratée à hot ou cool.
• Les instantanés ou les versions dans un état archive ne sont pas autorisés à être promus vers la racine.
• Lorsque le contrôle de version est activé, la suppression d’un objet blob racine lorsqu’il se trouve dans un état de réhydraté entraîne l’annulation de la réhydratation et la version est dans un état archive.
• Si un objet blob est remplacé lorsqu’il est dans un état de réhydraté et supprimé de manière réversible, il entraîne l’annulation de la réhydratation et la version de l’instantané supprimé de manière réversible est dans un état archive.

La liste des niveaux pris en charge n’est pas limitée par la version de la demande, et de nouveaux niveaux peuvent être ajoutés ultérieurement.

Pour les objets blob qui utilisent le chiffrement fourni par le client, Set Blob Tier est pris en charge pour la version 2023-08-03 et ultérieure. Pour les versions antérieures à 2023-08-03, Set Blob Tier retourne le code d’état 409 pour les objets blob qui utilisent le chiffrement fourni par le client.

Note

Pour plus d’informations sur la hiérarchisation au niveau de l’objet blob de blocs, consultez niveaux de stockage chaud, froid et archive.

Facturation

Les demandes de tarification peuvent provenir de clients qui utilisent des API Stockage Blob, directement via l’API REST Stockage Blob ou à partir d’une bibliothèque cliente Stockage Azure. Ces demandes accumulent des frais par transaction. Le type de transaction affecte la façon dont le compte est facturé. Par exemple, les transactions de lecture s’accumulent dans une catégorie de facturation différente de celle des transactions en écriture. Le tableau suivant montre la catégorie de facturation pour les requêtes Set Blob Tier en fonction du type de compte de stockage :

Opération	Type de compte de stockage	Catégorie de facturation
Définir le niveau d’objet blob (niveau inférieur)	Objet blob de blocs Premium Standard v2 à usage général	Opérations d’écriture
Définir le niveau Blob (hiérarchiser)	Objet blob de blocs Premium Standard v2 à usage général	Opérations de lecture

Pour en savoir plus sur la tarification de la catégorie de facturation spécifiée, consultez tarification du Stockage Blob Azure.

Voir aussi

Autoriser les demandes adressées au stockage Azure
l’état et les codes d’erreur
codes d’erreur Stockage Blob
définir des délais d’attente pour les opérations de stockage d’objets blob