Définir un niveau d’objet blob

  • Article

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 stockage d’objets blob ou un compte v2 à usage général. Le niveau d’un objet blob de pages Premium (P4/P15//P30P40/P50///P60P6P10/P20) détermine la taille, les IOPS et la bande passante autorisés de l’objet blob. Le niveau d’un objet blob de blocs détermine le HotColdArchive/Cool//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 des objets blob de blocs, consultez Niveaux de stockage chaud, froid et archive.

Requête

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

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

Paramètres URI

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

Paramètre Description
snapshot facultatif. Le paramètre instantané est une valeur opaque DateTime qui, lorsqu’elle est présente, spécifie l’objet blob instantané sur laquelle définir un niveau. Pour plus d’informations sur l’utilisation des instantanés d’objets blob, consultez Create un instantané d’un objet blob
versionid Facultatif pour les versions 2019-12-12 et ultérieures. Le versionid paramètre est une valeur opaque DateTime qui, lorsqu’elle est présente, spécifie la version de l’objet blob sur laquelle définir un niveau.
timeout facultatif. 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 requêtes auprès du Stockage Azure.
Date ou x-ms-date Obligatoire. Spécifie la date/heure en temps universel coordonné (UTC) pour la requête. Pour plus d’informations, consultez Autoriser les requêtes auprès du 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 à usage général, les valeurs valides sont Hot, Cool, Coldet Archive. Note:Cold le niveau est pris en charge pour la version 2021-12-02 et ultérieure. Pour plus d’informations sur la hiérarchisation au niveau de l’objet 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 demande. Pour plus d’informations, consultez Gestion de version pour les services de stockage Azure.
x-ms-client-request-id facultatif. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 Ko qui est enregistrée dans les journaux d’analyse lorsque la journalisation de l’analytique de stockage est activée. L’utilisation de cet en-tête est fortement recommandée pour la mise en corrélation des activités côté client avec les requêtes reçues par le serveur. Pour plus d’informations, consultez À propos de Storage Analytics journalisation.
x-ms-rehydrate-priority facultatif. Indique la priorité avec laquelle réalimenter un objet blob archivé. Pris 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é ne peut être définie sur un objet blob qu’une seule fois pour les versions antérieures au 12-06-2020 ; cet en-tête sera ignoré lors des 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 High sur et en définissant x-ms-access-tier sur la même valeur que précédemment définie. 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érarchisation de 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.

response

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 status code 200 (OK) si le nouveau niveau prend effet immédiatement, ou status code 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 status code 200 (OK).

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

Niveau Défini sur le niveau chaud Défini sur le niveau froid Défini sur le niveau froid Défini sur le niveau archive
Blob au niveau chaud 200 200 200 200
Blob au niveau froid 200 200 200 200
Blob dans le niveau froid 200 200 200 200
Blob au niveau archive 202 202 202 200
Blob au niveau archive, réalimentation à chaud 202 409 409 409
Blob au niveau archive, réalimentation au refroidissement 409 202 409 409
Blob au niveau archive, réalimentation à froid 409 409 202 409

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

En-têtes de réponse

La réponse de l'opération inclut les en-têtes suivants. La réponse peut aussi inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du 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 la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API.
x-ms-version Version de Stockage Blob utilisée pour exécuter la demande. Cet en-tête est renvoyé pour les demandes effectuées avec la version 2009-09-19 ou une version ultérieure.
x-ms-client-request-id Peut être utilisé pour résoudre les problèmes liés aux demandes et aux 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 demande, il ne sera pas présent dans la réponse.

Autorisation

Une 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 Set Blob Tier comme décrit ci-dessous.

Important

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

Le Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les demandes de données blob. Avec Microsoft Entra ID, 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 Microsoft Entra ID pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une requête auprès du service BLOB.

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

Autorisations

Vous trouverez ci-dessous l’action RBAC nécessaire pour qu’un utilisateur, un groupe, une identité managée ou un principal de service Microsoft Entra appelle l’opérationSet Blob Tier, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

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.

Remarques

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

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

  • La définition d’un niveau sur un instantané est autorisée à partir de la version REST 2019-12-12.
  • Les instantanés qui sont hiérarchisé à archive ne peuvent pas être réalimentés dans le instantané. Autrement dit, le instantané ne peut pas être ramené à un hot niveau ou .cool La seule façon de récupérer les données d’un archive instantané ou d’une version consiste à les copier dans un nouvel objet blob.
  • Si la version est un objet blob racine, elle peut être réalimentée dans hot ou cool.
  • Les instantanés ou versions dans un archive état ne sont pas autorisés à être promus en 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éactivation en attente entraîne l’annulation de la réactivation, et la version est dans un archive état.
  • Si un objet blob est remplacé alors qu’il est dans un état de réactivation en attente et de suppression réversible, cela entraîne l’annulation de la réactivation, et la version de la instantané supprimée de manière réversible est dans un archive état.

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.

Notes

Pour plus d’informations sur la hiérarchisation au niveau des objets blob de blocs , consultez Niveaux de stockage chaud, froid et archive.

Facturation

Les demandes de tarification peuvent provenir de clients qui utilisent les API Stockage Blob, soit directement via l’API REST Stockage Blob, soit à 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 d’écriture. Le tableau suivant montre la catégorie de facturation pour Set Blob Tier les demandes en fonction du type de compte de stockage :

Opération Type de compte de stockage Catégorie de facturation
Définir le niveau de l’objet blob (niveau inférieur) Objet blob de blocs Premium
Usage général v2 Standard		 Opérations d’écriture
Définir le niveau de l’objet blob (niveau supérieur) Objet blob de blocs Premium
Usage général v2 Standard		 Lire les opérations

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

Voir aussi

Autoriser les demandes dans le Stockage Azure
Codes d’état et d’erreur
Codes d’erreur stockage Blob
Définir des délais d’attente pour les opérations de stockage Blob