Ange blobnivå

Åtgärden Set Blob Tier anger åtkomstnivån på en blob. Åtgärden tillåts på en sidblob i ett Premium Storage-konto och på en blockblob i en bloblagring eller ett v2-konto för generell användning. En premium-sidblobnivå (P4/P6/P10/P15/P20/P30/P40/P50/P60) avgör den tillåtna storleken, IOPS och bandbredden för blobben. En blockblobnivå avgör Hot/Cool/Cold/Archive lagringstyp. Den här åtgärden uppdaterar inte blobens ETag.

Detaljerad information om blockblobnivånivåer finns i lagringsnivåer för frekvent, lågfrekvent lagring och arkivlagring.

Begäran

Du kan skapa Set Blob Tier begäran enligt följande. Vi rekommenderar att du använder HTTPS. Ersätt myaccount- med namnet på ditt lagringskonto och ersätt myblob- med blobnamnet som nivån ska ändras för.

Metod	Begärande-URI	HTTP-version
PUT	https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=tier	HTTP/1.1

URI-parametrar

Du kan ange följande ytterligare parametrar på begärande-URI:n:

Parameter	Beskrivning
snapshot	Valfri. Parametern ögonblicksbild är ett ogenomskinlig DateTime värde som, när det finns, anger blobögonblicksbilden för att ange en nivå på. Mer information om hur du arbetar med blobögonblicksbilder finns i Skapa en ögonblicksbild av en blob
versionid	Valfritt för version 2019-12-12 och senare. Parametern versionid är en ogenomskinlig DateTime värde som när den finns anger vilken version av bloben som ska anges på en nivå.
timeout	Valfri. Parametern timeout uttrycks i sekunder. Mer information finns i Ange tidsgränser för Blob Storage-åtgärder.

Begärandehuvuden

De obligatoriska och valfria begäranderubrikerna beskrivs i följande tabell:

Begärandehuvud	Beskrivning
Authorization	Krävs. Anger auktoriseringsschema, lagringskontonamn och signatur. Mer information finns i Auktorisera begäranden till Azure Storage.
Date eller x-ms-date	Krävs. Anger UTC (Coordinated Universal Time) för begäran. Mer information finns i Auktorisera begäranden till Azure Storage.
x-ms-access-tier	Krävs. Anger vilken nivå som ska anges på bloben. En lista över tillåtna premium-sidblobnivåer finns i Premium Storage med höga prestanda och hanterade diskar för virtuella datorer. För bloblagring eller v2-konto för generell användning är giltiga värden Hot, Cool, Coldoch Archive. Obs!Cold-nivån stöds för version 2021-12-02 och senare. Detaljerad information om standardnivånivåer för blobkonton finns i lagringsnivåer för frekvent, lågfrekvent lagring och arkivlagring.
x-ms-version	Krävs för alla auktoriserade begäranden. Anger vilken version av åtgärden som ska användas för den här begäran. Mer information finns i Versionshantering för Azure Storage Services-.
x-ms-client-request-id	Valfri. Tillhandahåller ett klientgenererat, täckande värde med en gräns på 1 kB som registreras i analysloggarna när loggning av lagringsanalys är aktiverad. Att använda det här huvudet rekommenderas starkt för att korrelera aktiviteter på klientsidan med begäranden som tas emot av servern. Mer information finns i Om lagringsanalysloggning.
x-ms-rehydrate-priority	Valfri. Anger med vilken prioritet en arkiverad blob ska extraheras. Stöds i version 2019-02-02 och senare för blockblobar. Giltiga värden är High/Standard. Prioriteten kan bara anges på en blob en gång för versioner före 2020-06-12. Den här rubriken ignoreras vid efterföljande begäranden. Standardprioritetsinställningen är Standard. Från och med version 2020-06-12 kan återfuktningsprioriteten uppdateras efter att den tidigare angetts. Prioritetsinställningen kan ändras från Standard till High genom att anropa Ange blobnivå med det här huvudet inställt på High och inställningen x-ms-access-tier till samma värde som tidigare angetts. Det går inte att sänka prioritetsinställningen från High till Standard.

Den här åtgärden stöder också användning av villkorsstyrda huvuden för att nivåindela bloben endast om ett angivet villkor uppfylls. Mer information finns i Ange villkorsstyrda rubriker för Blob Storage-åtgärder.

Begärandetext

Ingen.

Svar

Svaret innehåller en HTTP-statuskod och en uppsättning svarshuvuden.

Statuskod

En lyckad åtgärd returnerar statuskod 200 (OK) om den nya nivån börjar gälla omedelbart eller statuskoden 202 (accepterad) om övergången till den nya nivån väntar.

För premiumlagringskonton returnerar sidblobåtgärden statuskod 200 (OK).

För blockblobar beskrivs DE HTTP-statuskoder som returneras baserat på blobens aktuella och begärda nivåer i följande tabell:

Nivå	Ange till frekvent nivå	Ange till lågfrekvent nivå	Ange till kall nivå	Ange till arkivnivå
Blob i frekvent nivå	200	200	200	200
Blob i lågfrekvent nivå	200	200	200	200
Blob i kall nivå	200	200	200	200
Blob på arkivnivå	202	202	202	200
Blob på arkivnivå, som återställs till frekvent	202	409	409	409
Blob på arkivnivå, återställer till lågfrekvent	409	202	409	409
Blob på arkivnivå, uttorka till kall	409	409	202	409

Mer information om statuskoder finns i Status och felkoder.

Svarshuvuden

Svaret för den här åtgärden innehåller följande rubriker. Svaret kan också innehålla ytterligare standard-HTTP-huvuden. Alla standardhuvuden överensstämmer med HTTP/1.1-protokollspecifikationen.

Svarsrubrik	Beskrivning
x-ms-request-id	Identifierar unikt den begäran som gjordes och kan användas för att felsöka begäran. Mer information finns i Felsöka API-åtgärder.
x-ms-version	Blob Storage-versionen som användes för att köra begäran. Det här huvudet returneras för begäranden mot version 2009-09-19 och senare.
x-ms-client-request-id	Kan användas för att felsöka begäranden och motsvarande svar. Värdet för det här huvudet är lika med värdet för x-ms-client-request-id-huvudet om det finns i begäran och värdet inte innehåller fler än 1 024 synliga ASCII-tecken. Om den x-ms-client-request-id rubriken inte finns i begäran visas den inte i svaret.

Tillstånd

Auktorisering krävs när du anropar en dataåtkomståtgärd i Azure Storage. Du kan auktorisera åtgärden Set Blob Tier enligt beskrivningen nedan.

Viktig

Microsoft rekommenderar att du använder Microsoft Entra-ID med hanterade identiteter för att auktorisera begäranden till Azure Storage. Microsoft Entra-ID ger överlägsen säkerhet och användarvänlighet jämfört med auktorisering av delad nyckel.

Microsoft Entra ID (rekommenderas)

Azure Storage stöder användning av Microsoft Entra-ID för att auktorisera begäranden till blobdata. Med Microsoft Entra-ID kan du använda rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att bevilja behörigheter till ett säkerhetsobjekt. Säkerhetsobjektet kan vara en användare, grupp, huvudnamn för programtjänsten eller en hanterad Azure-identitet. Säkerhetsobjektet autentiseras av Microsoft Entra-ID för att returnera en OAuth 2.0-token. Token kan sedan användas för att auktorisera en begäran mot Blob-tjänsten.

Mer information om auktorisering med Microsoft Entra-ID finns i Auktorisera åtkomst till blobar med hjälp av Microsoft Entra-ID.

Behörigheter

Nedan visas den RBAC-åtgärd som krävs för att en Microsoft Entra-användare, grupp, hanterad identitet eller tjänstens huvudnamn ska anropa den Set Blob Tier åtgärden och den minst privilegierade inbyggda Azure RBAC-rollen som innehåller den här åtgärden:

• Azure RBAC-åtgärd:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
• Minst privilegierad inbyggd roll:Storage Blob Data Contributor

Mer information om hur du tilldelar roller med Hjälp av Azure RBAC finns i Tilldela en Azure-roll för åtkomst till blobdata.

signaturer för delad åtkomst (SAS)

En signatur för delad åtkomst (SAS) ger säker delegerad åtkomst till resurser i ett lagringskonto. Med en SAS har du detaljerad kontroll över hur en klient kan komma åt data. Du kan ange vilken resurs klienten kan komma åt, vilka behörigheter de har till dessa resurser och hur länge SAS är giltigt.

Åtgärden Set Blob Tier stöder tre typer av signaturer för delad åtkomst: sas-för användardelegering, -tjänsten SASoch kontot SAS.

Som bästa säkerhet rekommenderar vi att du använder Microsoft Entra-autentiseringsuppgifter i stället för lagringskontonyckeln, vilket är enklare att kompromettera. Om din programdesign kräver signaturer för delad åtkomst använder du Microsoft Entra-autentiseringsuppgifter för att skapa en SAS för användardelegering när det är möjligt.

När åtkomst till delad nyckel inte tillåts för lagringskontot tillåts inte en SAS-token för tjänsten eller en SAS-kontotoken för en begäran till Blob Storage. Mer information finns i Förstå hur nekande av delad nyckel påverkar SAS-token.

SAS för användardelegering

En SAS för användardelegering skyddas med Microsoft Entra-autentiseringsuppgifter och även av de behörigheter som angetts för SAS.

Om du anropar Set Blob Tier-åtgärden med hjälp av en SAS-token som delegerats till en container eller blobresurs krävs Skriv (w) behörighet som en del av SAS-token för användardelegering.

Mer information om SAS för användardelegering finns i Skapa en SAS-för användardelegering.

Tjänst-SAS

En tjänst-SAS skyddas med lagringskontonyckeln. En tjänst-SAS delegerar åtkomst till en resurs i en enda Azure Storage-tjänst, till exempel bloblagring.

För att anropa Set Blob Tier-åtgärden med hjälp av en SAS-token som delegerats till en container eller blobresurs krävs behörigheten Write (w) som en del av tjänstens SAS-token.

Mer information om TJÄNSTEN SAS finns i Skapa en tjänst SAS.

Konto-SAS

Ett SAS-konto skyddas med lagringskontonyckeln. Ett KONTO SAS delegerar åtkomst till resurser i en eller flera av lagringstjänsterna. Alla åtgärder som är tillgängliga via en tjänst eller sas för användardelegering är också tillgängliga via ett konto-SAS.

Följande tabell anger den signerade resurstypen och de signerade behörigheter som ska anges när åtkomst delegeras:

Operation	Signerad tjänst	Signerad resurstyp	Signerad behörighet
Ange blobnivå	Blob (b)	Objekt (o)	Skriva (w)

Mer information om sas-kontot finns i Skapa ett KONTO SAS-.

Delad nyckel

Åtgärden Set Blob Tier stöder auktorisering av delad nyckel. Auktorisering med kontonycklar rekommenderas inte för de flesta scenarier eftersom det är mindre säkert.

Microsoft rekommenderar att du inte tillåter auktorisering av delad nyckel för lagringskontot när det är möjligt. Mer information finns i Förhindra auktorisering med delad nyckel.

Anmärkningar

Inställningen av en blobnivå för sidblobbar i Premium-konton har följande begränsningar:

• Den nya blobnivån får inte vara lägre än den befintliga.
• Den nya blobnivån ska kunna hantera blobens innehållslängd. En lista över nivåer och deras tillåtna innehållslängd finns i Premium-lagring med höga prestanda och hanterade diskar för virtuella datorer.

Inställningen av blockblobens nivå på ett Blob Storage- eller generell användning v2-konto har följande begränsningar:

• Det är tillåtet att ange en nivå på en ögonblicksbild från och med REST version 2019-12-12.
• Ögonblicksbilder som är nivåindelade till archive kan inte extraheras tillbaka till ögonblicksbilden. Ögonblicksbilden kan alltså inte återställas till en hot eller cool nivå. Det enda sättet att hämta data från en archive ögonblicksbild eller version är att kopiera dem till en ny blob.
• Om versionen är en rotblob kan den extraheras tillbaka till hot eller cool.
• Ögonblicksbilder eller versioner i ett archive tillstånd kan inte befordras till rot.
• När versionshantering är aktiverat kommer borttagningen av en rotblob när den är i ett tillstånd som väntar på rehydrat att resultera i att återfuktningen avbryts och att versionen är i ett archive tillstånd.
• Om en blob skrivs över när den är i ett tillstånd med väntande och mjuk borttagning kommer den att leda till att återfuktningen avbryts, och versionen av den mjukt borttagna ögonblicksbilden är i ett archive tillstånd.

Listan över nivåer som stöds begränsas inte av begärandeversionen och nya nivåer kan läggas till i framtiden.

För blobar som använder kundbaserad kryptering stöds Set Blob Tier för version 2023-08-03 och senare. För versioner före 2023-08-03 returnerar Set Blob Tier statuskod 409 för blobar som använder kryptering från kunden.

Not

Detaljerad information om blockblobnivånivåer finns i lagringsnivåer för frekvent, lågfrekvent lagring och arkivlagring.

Fakturering

Prisbegäranden kan komma från klienter som använder Blob Storage-API:er, antingen direkt via BLOB Storage REST API eller från ett Azure Storage-klientbibliotek. Dessa begäranden ackumulerar avgifter per transaktion. Typen av transaktion påverkar hur kontot debiteras. Lästransaktioner ackumuleras till exempel till en annan faktureringskategori än skrivtransaktioner. I följande tabell visas faktureringskategorin för Set Blob Tier begäranden baserat på lagringskontotypen:

Operation	Typ av lagringskonto	Faktureringskategori
Ange blobnivå (nednivå)	Premium-blockblob Standard generell användning v2	Skrivåtgärder
Ange blobnivå (nivå upp)	Premium-blockblob Standard generell användning v2	Läsåtgärder

Mer information om priser för den angivna faktureringskategorin finns i Prissättning för Azure Blob Storage.

Se även

Auktorisera begäranden till Azure Storage
Status- och felkoder
Blob Storage-felkoder
Ange tidsgränser för Blob Storage-åtgärder