Delen via


Bloblaag instellen

De Set Blob Tier-bewerking stelt de toegangslaag in op een blob. De bewerking is toegestaan op een pagina-blob in een Premium-opslagaccount en op een blok-blob in een blobopslag- of v2-account voor algemeen gebruik. De laag van een Premium-paginablob (P4/P6/P10/P15/P20/P30/P40/P50/P60) bepaalt de toegestane grootte, IOPS en bandbreedte van de blob. De laag van een blok-blob bepaalt Hot/Cool/Cold/Archive opslagtype. Met deze bewerking wordt de ETag van de blob niet bijgewerkt.

Zie dynamische, statische en archiefopslaglagenvoor gedetailleerde informatie over lagen op blok-blobniveau.

Verzoek

U kunt de Set Blob Tier aanvraag als volgt samenstellen. U wordt aangeraden HTTPS te gebruiken. Vervang myaccount door de naam van uw opslagaccount en vervang myblob door de blobnaam waarvoor de laag moet worden gewijzigd.

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

URI-parameters

U kunt de volgende aanvullende parameters opgeven voor de aanvraag-URI:

Parameter Beschrijving
snapshot Facultatief. De parameter momentopname is een ondoorzichtige DateTime waarde die, wanneer aanwezig, de blob-momentopname opgeeft waarop een laag moet worden ingesteld. Zie Een momentopname van een blob maken voor meer informatie over het werken met blobmomentopnamen
versionid Optioneel voor versie 2019-12-12 en hoger. De versionid parameter is een ondoorzichtige DateTime waarde die, indien aanwezig, de versie van de blob specificeert waarop een laag moet worden ingesteld.
timeout Facultatief. De parameter timeout wordt uitgedrukt in seconden. Zie Time-outs instellen voor Blob Storage-bewerkingenvoor meer informatie.

Aanvraagheaders

De vereiste en optionele aanvraagheaders worden beschreven in de volgende tabel:

Aanvraagheader Beschrijving
Authorization Vereist. Hiermee geeft u het autorisatieschema, de naam van het opslagaccount en de handtekening op. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie.
Date of x-ms-date Vereist. Hiermee geeft u de Coordinated Universal Time (UTC) voor de aanvraag. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie.
x-ms-access-tier Vereist. Geeft de laag aan die moet worden ingesteld voor de blob. Zie Premium Storage en beheerde schijven voor VM'svoor een lijst met toegestane Premium-pagina-bloblagen. Voor blobopslag- of algemeen gebruik v2-account zijn geldige waarden Hot, Cool, Colden Archive. Opmerking:Cold laag wordt ondersteund voor versie 2021-12-02 en hoger. Zie opslaglagen dynamisch, statisch en archiefopslagvoor gedetailleerde informatie over opslaglagen op blob-niveau standard.
x-ms-version Vereist voor alle geautoriseerde aanvragen. Hiermee geeft u de versie van de bewerking die moet worden gebruikt voor deze aanvraag. Zie Versiebeheer voor azure Storage Servicesvoor meer informatie.
x-ms-client-request-id Facultatief. Biedt een door de client gegenereerde, ondoorzichtige waarde met een tekenlimiet van 1 kB die wordt vastgelegd in de analyselogboeken wanneer logboekregistratie van opslaganalyse is ingeschakeld. Het gebruik van deze header wordt ten zeerste aanbevolen voor het correleren van activiteiten aan de clientzijde met aanvragen die door de server zijn ontvangen. Zie Over logboekregistratie van Storage Analyticsvoor meer informatie.
x-ms-rehydrate-priority Facultatief. Geeft de prioriteit aan waarmee een gearchiveerde blob moet worden gerehydrateerd. Ondersteund op versie 2019-02-02 en hoger voor blok-blobs. Geldige waarden worden High/Standard. De prioriteit kan slechts eenmaal worden ingesteld op een blob voor versies vóór 2020-06-12; deze header wordt genegeerd voor volgende aanvragen. De standaardprioriteitsinstelling is Standard.

Vanaf versie 2020-06-12 kan de rehydratatieprioriteit worden bijgewerkt nadat deze eerder is ingesteld. De prioriteitsinstelling kan worden gewijzigd van Standard in High door Blob-laag instellen aan te roepen met deze header ingesteld op High en x-ms-access-tier in te stellen op dezelfde waarde als eerder ingesteld. De prioriteitsinstelling kan niet worden verlaagd van High naar Standard.

Deze bewerking ondersteunt ook het gebruik van voorwaardelijke headers om de blob alleen te tieren als aan een opgegeven voorwaarde wordt voldaan. Zie Voorwaardelijke headers opgeven voor Blob Storage-bewerkingenvoor meer informatie.

Aanvraagbody

Geen.

Antwoord

Het antwoord bevat een HTTP-statuscode en een set antwoordheaders.

Statuscode

Een geslaagde bewerking retourneert statuscode 200 (OK) als de nieuwe laag onmiddellijk van kracht wordt, of statuscode 202 (Geaccepteerd) als de overgang naar de nieuwe laag in behandeling is.

Voor Premium-opslagaccounts retourneert de pagina-blobbewerking statuscode 200 (OK).

Voor blok-blobs worden de HTTP-statuscodes die worden geretourneerd, op basis van de huidige en aangevraagde lagen van de blob, beschreven in de volgende tabel:

Rang Instellen op dynamische laag Instellen op statische laag Ingesteld op koude laag Instellen op archieflaag
Blob in dynamische laag 200 200 200 200
Blob in statische laag 200 200 200 200
Blob in koude laag 200 200 200 200
Blob in archieflaag 202 202 202 200
Blob in archieflaag, rehydrateren naar dynamisch 202 409 409 409
Blob in archieflaag, rehydrateren naar statisch 409 202 409 409
Blob in archieflaag, rehydrateren naar koude 409 409 202 409

Zie Status en foutcodesvoor meer informatie over statuscodes.

Antwoordheaders

Het antwoord voor deze bewerking bevat de volgende headers. Het antwoord kan ook aanvullende standaard HTTP-headers bevatten. Alle standaardheaders voldoen aan de HTTP/1.1-protocolspecificatie.

Antwoordheader Beschrijving
x-ms-request-id Identificeer de aanvraag die is gemaakt en kan worden gebruikt om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossenvoor meer informatie.
x-ms-version De Blob Storage-versie die is gebruikt om de aanvraag uit te voeren. Deze header wordt geretourneerd voor aanvragen die zijn gedaan op basis van versie 2009-09-19 en hoger.
x-ms-client-request-id Kan worden gebruikt om problemen met aanvragen en bijbehorende antwoorden op te lossen. De waarde van deze header is gelijk aan de waarde van de x-ms-client-request-id header als deze aanwezig is in de aanvraag en de waarde niet meer dan 1024 zichtbare ASCII-tekens bevat. Als de x-ms-client-request-id header niet aanwezig is in de aanvraag, is deze niet aanwezig in het antwoord.

Machtiging

Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. U kunt de Set Blob Tier bewerking autoriseren zoals hieronder wordt beschreven.

Belangrijk

Microsoft raadt aan om Microsoft Entra ID met beheerde identiteiten te gebruiken om aanvragen voor Azure Storage te autoriseren. Microsoft Entra ID biedt superieure beveiliging en gebruiksgemak in vergelijking met autorisatie van gedeelde sleutels.

Azure Storage ondersteunt het gebruik van Microsoft Entra ID om aanvragen voor blobgegevens te autoriseren. Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipaal. De beveiligingsprincipaal kan een door een gebruiker, groep, toepassingsservice-principal of door Azure beheerde identiteit zijn. De beveiligingsprincipaal wordt geverifieerd door de Microsoft Entra-id om een OAuth 2.0-token te retourneren. Het token kan vervolgens worden gebruikt om een aanvraag te autoriseren voor de Blob-service.

Zie Toegang tot blobs autoriseren met behulp van Microsoft Entra IDvoor meer informatie over autorisatie met Behulp van Microsoft Entra ID.

Machtigingen

Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra-gebruiker, groep, beheerde identiteit of service-principal om de Set Blob Tier-bewerking aan te roepen, en de minst bevoorrechte ingebouwde Azure RBAC-rol die deze actie omvat:

Zie Een Azure-rol toewijzen voor toegang tot blobgegevensvoor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.

Opmerkingen

Het instellen van de laag van een blob voor pagina-blobs in Premium-accounts heeft de volgende beperkingen:

  • De nieuwe bloblaag kan niet lager zijn dan de bestaande laag.
  • De nieuwe bloblaag moet geschikt zijn voor de inhoudslengte van de blob. Zie Premium Storage en beheerde schijven voor VM'svoor een lijst met lagen en de toegestane inhoudslengte.

Het instellen van de laag van de blok-blob op een Blob Storage- of v2-account voor algemeen gebruik heeft de volgende beperkingen:

  • Het instellen van een laag op een momentopname is toegestaan vanaf REST-versie 2019-12-12.
  • Momentopnamen die zijn gelaagd naar archive kunnen niet opnieuw worden gerehydrateerd in de momentopname. De momentopname kan dus niet worden teruggezet naar een hot of cool laag. De enige manier om de gegevens op te halen uit een archive momentopname of versie is het kopiëren naar een nieuwe blob.
  • Als de versie een hoofd-blob is, kan deze opnieuw worden gerehydrateerd naar hot of cool.
  • Momentopnamen of versies met een archive status mogen niet worden gepromoveerd naar de hoofdmap.
  • Wanneer versiebeheer is ingeschakeld, resulteert het verwijderen van een hoofd-blob wanneer deze zich in een rehydrate-pending-status bevindt, tot de annulering van de rehydratatie en de versie een archive status heeft.
  • Als een blob wordt overschreven wanneer deze de status rehydrate-pending en voorlopig verwijderd heeft, wordt de rehydratatie geannuleerd en heeft de versie van de voorlopig verwijderde momentopname een archive status.

De lijst met ondersteunde lagen wordt niet beperkt door de aanvraagversie en nieuwe lagen kunnen in de toekomst worden toegevoegd.

Voor blobs die gebruikmaken van door de klant geleverde versleuteling, wordt Set Blob Tier ondersteund voor versie 2023-08-03 en hoger. Voor versies vóór 2023-08-03 retourneert Set Blob Tier statuscode 409 voor blobs die gebruikmaken van door de klant geleverde versleuteling.

Notitie

Zie dynamische, statische en archiefopslaglagenvoor gedetailleerde informatie over lagen op blok-blobniveau.

Facturering

Prijsaanvragen kunnen afkomstig zijn van clients die Blob Storage-API's gebruiken, rechtstreeks via de Blob Storage REST API of vanuit een Azure Storage-clientbibliotheek. Deze aanvragen maken kosten per transactie. Het type transactie is van invloed op de manier waarop het account in rekening wordt gebracht. Leestransacties worden bijvoorbeeld opgebouwd tot een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor Set Blob Tier aanvragen op basis van het type opslagaccount:

Operatie Type opslagaccount Factureringscategorie
Bloblaag instellen (laag omlaag) Premium blok-blob
Standaard algemeen gebruik v2
Schrijfbewerkingen
Blob-laag instellen (laag omhoog) Premium blok-blob
Standaard algemeen gebruik v2
Leesbewerkingen

Zie Prijzen voor Azure Blob Storagevoor meer informatie over prijzen voor de opgegeven factureringscategorie.

Zie ook

aanvragen autoriseren voor Azure Storage
status en foutcodes
Blob Storage-foutcodes
time-outs instellen voor Blob Storage-bewerkingen