Blob-laag instellen

Met Set Blob Tier de bewerking wordt de toegangslaag ingesteld 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-pagina-blob (P4/P15//P30P40/P50///P60P6P10/P20) bepaalt de toegestane grootte, IOPS en bandbreedte van de blob. De laag van een blok-blob bepaalt HotColdArchive/Cool//het opslagtype. Met deze bewerking wordt de ETag van de blob niet bijgewerkt.

Zie Dynamische, statische en archiefopslaglagen voor gedetailleerde informatie over lagen op blok-blobniveau.

Aanvraag

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	Optioneel. De parameter momentopname is een ondoorzichtige DateTime waarde die, indien aanwezig, de blob-momentopname aangeeft 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 aangeeft waarop een laag moet worden ingesteld.
timeout	Optioneel. De timeout parameter wordt uitgedrukt in seconden. Zie Time-outs instellen voor Blob Storage-bewerkingen voor 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 voor Azure Storage autoriseren voor meer informatie.
Date of x-ms-date	Vereist. Geef de Coordinated Universal Time (UTC) op voor de aanvraag. Zie Aanvragen voor Azure Storage autoriseren voor meer informatie.
x-ms-access-tier	Vereist. Geeft de laag aan die moet worden ingesteld voor de blob. Zie High-performance Premium Storage and managed disks for VM's (High-performance Premium Storage and managed disks for VM's) voor een lijst met toegestane bloblagen voor premium-pagina's. Voor blobopslag of een v2-account voor algemeen gebruik zijn Hotgeldige waarden , Cool, Colden Archive. Opmerking:Cold laag wordt ondersteund voor versie 2021-12-02 en hoger. Zie Dynamische, statische en archiefopslaglagen voor gedetailleerde informatie over opslaglagen op blobniveau van standard-blobaccounts.
x-ms-version	Vereist voor alle geautoriseerde aanvragen. Hiermee geeft u de versie van de bewerking te gebruiken voor deze aanvraag. Zie Versiebeheer voor de Azure Storage-services voor meer informatie.
x-ms-client-request-id	Optioneel. 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 clientzijde met aanvragen die door de server worden ontvangen. Zie Over Opslaganalyse logboekregistratie voor meer informatie.
x-ms-rehydrate-priority	Optioneel. Geeft de prioriteit aan waarmee een gearchiveerde blob moet worden gerehydrateerd. Ondersteund op versie 2019-02-02 en hoger voor blok-blobs. Geldige waarden zijn High/Standard. De prioriteit kan slechts eenmaal worden ingesteld voor een blob voor versies vóór 2020-06-12; deze header wordt genegeerd bij volgende aanvragen. De standaardinstelling voor prioriteit is Standard. Vanaf versie 2020-06-12 kan de reactivatieprioriteit worden bijgewerkt nadat deze eerder is ingesteld. De prioriteitsinstelling kan worden gewijzigd van Standard naar High door Blob-laag instellen aan te roepen met deze header ingesteld op High en x-ms-access-tier instelling 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-bewerkingen voor 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 Storage-accounts 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:

Laag	Instellen op dynamische laag	Instellen op statische laag	Instellen 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, reactiveren naar dynamisch	202	409	409	409
Blob in archieflaag, reactiveren naar statisch	409	202	409	409
Blob in archieflaag, reactiveren naar koud	409	409	202	409

Zie Status- en foutcodes voor meer informatie over statuscodes.

Antwoordheaders

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

Antwoordheader	Description
x-ms-request-id	Identificeert op unieke wijze de aanvraag die is gedaan en kan worden gebruikt om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossen voor 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.

Autorisatie

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.

Microsoft Entra ID

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 beveiligingsprincipal. De beveiligingsprincipal kan een gebruiker, groep, toepassingsservice-principal of door Azure beheerde identiteit zijn. De beveiligingsprincipal wordt geverifieerd door Microsoft Entra ID om een OAuth 2.0-token te retourneren. Het token kan vervolgens worden gebruikt om een aanvraag voor de Blob-service te autoriseren.

Zie Toegang tot blobs autoriseren met behulp van Microsoft Entra ID voor 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 of service-principal om de Set Blob Tier bewerking aan te roepen, en de ingebouwde Azure RBAC-rol met de minste bevoegdheden die deze actie omvat:

• Azure RBAC-actie:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
• Ingebouwde rol met minimale bevoegdheden:Inzender voor opslagblobgegevens

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

Shared Access Signatures (SAS)

Een Shared Access Signature (SAS) biedt beveiligde gedelegeerde toegang tot resources in een opslagaccount. Met een SAS hebt u gedetailleerde controle over hoe een client toegang heeft tot gegevens. U kunt opgeven tot welke resource de client toegang heeft, welke machtigingen ze hebben voor deze resources en hoe lang de SAS geldig is.

De Set Blob Tier bewerking ondersteunt drie typen handtekeningen voor gedeelde toegang: SAS voor gebruikersdelegatie, service-SAS en account-SAS.

Als best practice voor beveiliging raden we u aan Microsoft Entra referenties te gebruiken in plaats van de opslagaccountsleutel, die gemakkelijker kan worden aangetast. Als voor uw toepassingsontwerp handtekeningen voor gedeelde toegang zijn vereist, gebruikt u indien mogelijk Microsoft Entra referenties om een SAS voor gebruikersdelegatie te maken.

Wanneer toegang tot gedeelde sleutel niet is toegestaan voor het opslagaccount, is een service-SAS-token of een ACCOUNT-SAS-token niet toegestaan op een aanvraag voor Blob Storage. Zie Begrijpen hoe het niet toewijzen van gedeelde sleutel van invloed is op SAS-tokens voor meer informatie.

SAS voor gebruikersdelegering

Een SAS voor gebruikersdelegatie wordt beveiligd met Microsoft Entra referenties en ook met de machtigingen die zijn opgegeven voor de SAS.

Voor het aanroepen van de Set Blob Tier bewerking met behulp van een SAS-token dat is gedelegeerd aan een container of blobresource, is de machtiging Schrijven (w) vereist als onderdeel van het SAS-token voor gebruikersdelegatie.

Zie Een SAS voor gebruikersdelegering maken voor meer informatie over de SAS voor gebruikersdelegatie.

Service-SAS

Een service-SAS wordt beveiligd met de sleutel van het opslagaccount. Een service-SAS delegeert toegang tot een resource in één Azure Storage-service, zoals blobopslag.

Voor het aanroepen van de Set Blob Tier bewerking met behulp van een SAS-token dat is gedelegeerd aan een container of blob-resource, is de machtiging Schrijven (w) vereist als onderdeel van het service-SAS-token.

Zie Een service-SAS maken voor meer informatie over de service-SAS.

Account-SAS

Een account-SAS wordt beveiligd met de sleutel van het opslagaccount. Een account-SAS delegeert toegang tot resources in een of meer van de opslagservices. Alle bewerkingen die beschikbaar zijn via een service- of gebruikersdelegatie-SAS zijn ook beschikbaar via een account-SAS.

In de volgende tabel ziet u het ondertekende resourcetype en de ondertekende machtigingen die moeten worden opgegeven bij het delegeren van toegang:

Bewerking	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Blob-laag instellen	Blob (b)	Object (o)	Schrijven (w)

Zie Een account-SAS maken voor meer informatie over de account-SAS.

Gedeelde sleutel

De Set Blob Tier bewerking ondersteunt autorisatie van gedeelde sleutels. Autoriseren met accountsleutels wordt niet aanbevolen voor de meeste scenario's, omdat dit minder veilig is.

Microsoft raadt aan om waar mogelijk de autorisatie van een gedeelde sleutel voor het opslagaccount niet toe te staan. Zie Autorisatie met gedeelde sleutel voorkomen voor meer informatie.

Opmerkingen

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

• De nieuwe bloblaag mag niet lager zijn dan de bestaande laag.
• De nieuwe bloblaag moet geschikt zijn voor de inhoudslengte van de blob. Zie Premium-opslag met hoge prestaties en beheerde schijven voor VM's voor 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 voor een momentopname is toegestaan vanaf REST-versie 2019-12-12.
• Momentopnamen die zijn gelaagd op archive , kunnen niet worden gerehydrateerd in de momentopname. Dat wil gezegd dat de momentopname niet kan worden teruggezet naar een hot - of cool -laag. De enige manier om de gegevens op te halen uit een archive momentopname of versie, is door deze naar een nieuwe blob te kopiëren.
• Als de versie een hoofd-blob is, kan deze worden gerehydrateerd naar hot of cool.
• Momentopnamen of versies met een archive status mogen niet worden gepromoveerd naar de hoofdmap.
• Wanneer versiebeheer is ingeschakeld, leidt het verwijderen van een hoofd-blob wanneer deze zich in een status bevindt die in behandeling is op rehydrateren, tot de annulering van de rehydratatie en heeft de versie een archive status.
• Als een blob wordt overschreven wanneer deze zich in een status bevindt die in behandeling is voor rehydraten en voorlopig verwijderd, resulteert dit in de annulering van de rehydratatie 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.

Notitie

Zie Dynamische, statische en archiefopslaglagen voor gedetailleerde informatie over lagen op blok-blobniveau.

Billing

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

Bewerking	Type opslagaccount	Factureringscategorie
Blob-laag (laag omlaag) instellen	Premium-blok-blob Standard v2 voor algemeen gebruik	Schrijfbewerkingen
Blob-laag instellen (laag omhoog)	Premium-blok-blob Standard v2 voor algemeen gebruik	Leesbewerkingen

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

Zie ook

Aanvragen voor Azure Storage autoriseren
Status en foutcodes
Blob Storage-foutcodes
Time-outs instellen voor Blob Storage-bewerkingen