Delen via

Toegangsniveaus voor blobgegevens

Gegevens die in de cloud zijn opgeslagen, groeien in een exponentieel tempo. Als u de kosten voor uw groeiende opslagbehoeften wilt beheren, kan het handig zijn om uw gegevens te organiseren op basis van hoe vaak deze worden geopend en hoe lang deze worden bewaard. Azure Storage biedt verschillende toegangslagen, zodat u uw blobgegevens op de meest rendabele manier kunt opslaan op basis van hoe deze worden gebruikt. Azure Storage-toegangsniveaus omvatten:

  • Hot tier - een online laag die is geoptimaliseerd voor het opslaan van gegevens die vaak worden geopend of gewijzigd. De hete laag heeft de hoogste opslagkosten, maar de laagste toegangskosten.
  • Statische laag : een onlinelaag die is geoptimaliseerd voor het opslaan van gegevens die niet vaak worden geopend of gewijzigd. Gegevens in de statische laag moeten minimaal 30 dagen worden opgeslagen. De koele laag heeft lagere opslagkosten en hogere toegangskosten in vergelijking met de hete laag.
  • Koude laag : een onlinelaag die is geoptimaliseerd voor het opslaan van gegevens die zelden worden geopend of gewijzigd, maar waarvoor nog steeds snel ophalen is vereist. Gegevens in de koude laag moeten minimaal 90 dagen worden opgeslagen. De koude laag heeft lagere opslagkosten en hogere toegangskosten dan de statische laag.
  • Archieflaag: een offlinelaag die is geoptimaliseerd voor het opslaan van gegevens die zelden worden geopend en die flexibele latentievereisten heeft, in de volgorde van uren. Gegevens in de archieflaag moeten minimaal 180 dagen worden opgeslagen.

Limieten voor Azure-opslagcapaciteit worden ingesteld op accountniveau in plaats van op basis van de toegangslaag. U kunt ervoor kiezen om uw capaciteitsgebruik in één laag te maximaliseren of om de capaciteit over twee of meer lagen te verdelen.

Notitie

Het instellen van de toegangslaag is alleen toegestaan op Block Blobs. Worden niet ondersteund voor Append en pagina-blobs.

Online toegangsniveaus

Wanneer uw gegevens worden opgeslagen in een onlinetoegangslaag (dynamisch, statisch of koud), hebben gebruikers er onmiddellijk toegang toe. De dynamische laag is de beste keuze voor gegevens die actief worden gebruikt. De statische of koude laag is ideaal voor gegevens die minder vaak worden geopend, maar die nog steeds beschikbaar moeten zijn voor lezen en schrijven.

Voorbeelden van gebruiksscenario's voor de dynamische laag zijn:

  • Gegevens die actief worden gebruikt of gegevens die u verwacht, vereisen frequente lees- en schrijfbewerkingen.
  • Gegevens die worden voorbereid voor verwerking en uiteindelijk migratie naar de koele toegangslaag.

Gebruiksscenario's voor de koele en koude toegangsniveaus omvatten:

  • Kortetermijnback-up van gegevens en herstel na noodgevallen.
  • Oudere gegevenssets die niet vaak worden gebruikt, maar die naar verwachting beschikbaar zijn voor directe toegang.
  • Grote gegevenssets die op een kosteneffectieve manier moeten worden opgeslagen terwijl andere gegevens worden verzameld voor verwerking.

Zie De toegangslaag van een blob instellen voor informatie over het verplaatsen van een blob naar de dynamische, statische of koude laag.

Gegevens in de statische en koude lagen hebben iets lagere beschikbaarheid, maar bieden dezelfde hoge duurzaamheid, ophaallatentie en doorvoerkenmerken als de dynamische laag. Voor gegevens in de statische of koude lagen kunnen iets lagere beschikbaarheids- en hogere toegangskosten acceptabel zijn voor lagere totale opslagkosten, in vergelijking met de dynamische laag. Zie Dienstovereenkomst voor Storage voor meer informatie.

Blobs worden onderworpen aan een vroegtijdige verwijderingsstraf als ze worden verwijderd, overschreven of verplaatst naar een andere laag voordat het minimale aantal dagen dat door de laag is vereist, zijn overgegaan. Een blob in de statische laag in een v2-account voor algemeen gebruik is bijvoorbeeld onderworpen aan een vroegtijdige verwijderingsstraf als deze wordt verwijderd of verplaatst naar een andere laag voordat 30 dagen is verstreken. Voor een blob in de koude laag geldt de verwijderingsstraf als deze wordt verwijderd of verplaatst naar een andere laag voordat 90 dagen is verstreken. Deze kosten zijn evenredig verdeeld. Als een blob bijvoorbeeld wordt verplaatst naar de statische laag en vervolgens na 21 dagen wordt verwijderd, worden er kosten in rekening gebracht voor vroegtijdige verwijdering die gelijk is aan 9 (30 min 21) dagen voor het opslaan van die blob in de statische laag. Er worden ook kosten voor vroegtijdige verwijdering in rekening gebracht als het hele object opnieuw wordt geschreven via een bewerking (bijvoorbeeld Put Blob, Put Block List of Copy Blob) binnen het opgegeven tijdvenster. Deze kosten worden naar rato berekend op basis van de prijs van de gegevensopslag van de bijbehorende laag. Als u een gearchiveerde blob na 120 dagen verwijdert, wordt dit object 180 dagen in rekening gebracht.

Notitie

In een account waarvoor voorlopig verwijderen is ingeschakeld, wordt een blob beschouwd als verwijderd nadat deze is verwijderd en de bewaarperiode verloopt. Tot die periode is verstreken, wordt de blob alleen voorlopig verwijderd en is deze niet onderworpen aan de boete voor vroegtijdige verwijdering.

De dynamische, statische en koude lagen ondersteunen alle redundantieconfiguraties. Zie Azure Storage-redundantie voor meer informatie over opties voor gegevensredundantie in Azure Storage.

Archieftoegangslaag

De archieflaag is een offlinelaag voor het opslaan van gegevens die zelden worden geopend. De archieftoegangslaag heeft de laagste opslagkosten. Deze laag heeft echter hogere kosten voor het ophalen van gegevens met een hogere latentie in vergelijking met de dynamische, statische en koude lagen. Voorbeelden van gebruiksscenario's voor de archieftoegangslaag zijn:

  • Langetermijnback-up, secundaire back-up en gegevenssets voor archivering
  • Oorspronkelijke (onbewerkte) gegevens die moeten worden bewaard, zelfs nadat deze zijn verwerkt in de uiteindelijke bruikbare vorm
  • Nalevings- en archiveringsgegevens die lange tijd moeten worden opgeslagen en die nauwelijks worden geopend

Zie Een blob archiveren voor meer informatie over het verplaatsen van een blob naar de archieflaag.

Gegevens moeten ten minste 180 dagen in de archieflaag blijven anders worden kosten in rekening gebracht voor vroegtijdige verwijdering. Als een blob bijvoorbeeld naar de archieflaag wordt verplaatst en daarna na 45 dagen wordt verwijderd of naar de dynamische laag wordt verplaatst, worden er kosten voor vroegtijdige verwijdering in rekening gebracht die gelijk zijn aan 135 (180 min 45) dagen voor het opslaan van die blob in de archieflaag.

Notitie

In een account waarvoor voorlopig verwijderen is ingeschakeld, wordt een blob beschouwd als verwijderd nadat deze is verwijderd en de bewaarperiode verloopt. Tot die periode is verstreken, wordt de blob alleen voorlopig verwijderd en is deze niet onderworpen aan de boete voor vroegtijdige verwijdering.

Hoewel een blob zich in de archieflaag bevindt, kan deze niet worden gelezen of gewijzigd. Als u een blob in de archieflaag wilt lezen of downloaden, moet u deze eerst reactiveren naar een onlinelaag, dynamisch, statisch of koud. Het kan tot 15 uur duren voordat gegevens in de archieflaag opnieuw worden gehydrateerd, afhankelijk van de prioriteit die u opgeeft voor de rehydratatiebewerking. Voor meer informatie over rehydratatie van blobs kunt u het Overzicht van rehydratatie van blobs vanuit de archieflaag raadplegen.

De metagegevens van een gearchiveerde blob blijven beschikbaar voor leestoegang, zodat u de blob en de eigenschappen, metagegevens en indextags kunt weergeven. Metagegevens voor een blob in de archieflaag hebben het kenmerk Alleen-lezen, terwijl blob-indextags kunnen worden gelezen of geschreven. De opslagkosten voor metagegevens van gearchiveerde blobs worden in rekening gebracht op koelniveautarieven. Momentopnamen worden niet ondersteund voor gearchiveerde blobs.

De volgende bewerkingen worden ondersteund voor blobs in de archieflaag:

Alleen opslagaccounts die zijn geconfigureerd voor LRS, GRS of RA-GRS ondersteunen het verplaatsen van blobs naar de archieflaag. De archieflaag wordt niet ondersteund voor ZRS-, GZRS- of RA-GZRS-accounts. Zie Azure Storage-redundantie voor meer informatie over redundantieconfiguraties voor Azure Storage.

Als u de redundantieconfiguratie wilt wijzigen voor een opslagaccount dat blobs in de archieflaag bevat, moet u eerst alle gearchiveerde blobs reactiveren naar de dynamische, statische of koude laag. Omdat rehydratatiebewerkingen kostbaar en tijdrovend kunnen zijn, raadt Microsoft u aan om te voorkomen dat u de redundantieconfiguratie van een opslagaccount met gearchiveerde blobs wijzigt.

Het migreren van een opslagaccount van LRS naar GRS wordt ondersteund zolang er geen blobs zijn verplaatst naar de archieflaag terwijl het account is geconfigureerd voor LRS. Een account kan worden teruggezet naar GRS als de update is uitgevoerd minder dan 14 dagen vanaf het moment waarop het account LRS werd. Daarnaast mogen er geen blobs naar de archieflaag zijn verplaatst terwijl het account is ingesteld op LRS.

Standaardinstelling voor toegangslaag van account

Opslagaccounts hebben een standaardinstelling voor toegangslagen die de onlinelaag aangeeft waarin een nieuwe blob wordt gemaakt. De standaardinstelling voor het toegangsniveau kan worden ingesteld als warm, koel of koud. Gebruikers kunnen de standaardinstelling voor een afzonderlijke blob overschrijven bij het uploaden van de blob of het wijzigen van de laag.

De standaardtoegangslaag voor een nieuw v2-opslagaccount voor algemeen gebruik is standaard ingesteld op de dynamische laag. U kunt de instelling voor de standaardtoegangslaag wijzigen wanneer u een opslagaccount maakt of nadat het is gemaakt. Als u deze instelling niet wijzigt in het opslagaccount of de laag expliciet instelt bij het uploaden van een blob, wordt standaard een nieuwe blob geüpload naar de dynamische laag.

Een blob die niet expliciet een laag toegewezen heeft gekregen, bepaalt zijn laag op basis van de standaardinstelling voor toegangslaag van het account. Als de toegangslaag van een blob wordt afgeleid van de instelling voor de standaardaccounttoegangslaag, wordt de toegangslaag weergegeven als Warm (afgeleid), Koel (afgeleid) of Koud (afgeleid).

Het wijzigen van de standaardinstelling voor toegangslagen voor een opslagaccount is van toepassing op alle blobs in het account waarvoor een toegangslaag niet expliciet is ingesteld. Als u de standaardinstelling voor toegangslagen instelt op een koeler laag in een v2-account voor algemeen gebruik, worden er kosten in rekening gebracht voor schrijfbewerkingen (per 10.000) voor alle blobs waarvoor de toegangslaag wordt afgeleid. Er worden kosten in rekening gebracht voor zowel leesbewerkingen (per 10.000) als datagegevensopvragingen (per GB) wanneer u overschakelt naar een warmer niveau in een v2-account voor algemeen gebruik.

Wanneer u een verouderd Blob Storage-account maakt, moet u de instelling voor de standaardtoegangslaag opgeven als dynamisch of statisch tijdens het maken. Er worden geen kosten in rekening gebracht voor het wijzigen van de instelling van de standaardaccounttoegangslaag in een koeler laag in een verouderd Blob Storage-account. Er worden kosten in rekening gebracht voor zowel leesoperaties (per 10.000) als gegevensophaling (per GB) als u schakelt naar een warmere laag in een Blob Storage-account. Microsoft raadt het gebruik van v2-opslagaccounts voor algemeen gebruik aan in plaats van Blob Storage-accounts, indien mogelijk.

Notitie

De archieflaag wordt niet ondersteund als de standaardtoegangslaag voor een opslagaccount.

De laag van een blob instellen of wijzigen

Als u de laag van een blob expliciet wilt instellen wanneer u deze maakt, geeft u de laag op wanneer u de blob uploadt.

Nadat een blob is gemaakt, kunt u de laag op een van de volgende manieren wijzigen:

  • Door de instellen van de Blob-laag aan te roepen, rechtstreeks of via een levenscyclusbeheer-beleid. Het aanroepen van De Blob-laag instellen is doorgaans de beste optie wanneer u de laag van een blob wijzigt van een warmere laag in een koeler laag.

    Notitie

    U kunt een gearchiveerde blob niet rehydrateren naar een online niveau met behulp van levenscyclusbeheerbeleid.

  • Door de kopieer-blobbewerking aan te roepen om een blob van de ene laag naar de andere te kopiëren. Het aanroepen van een copy-blob wordt aanbevolen voor de meeste scenario's waarbij u een blob rehydrateert van de archieflaag naar een onlinelaag of een blob verplaatst van statisch of koud naar dynamisch. Door een blob te kopiëren, kunt u de boete voor vroegtijdige verwijdering voorkomen als het vereiste opslaginterval voor de bron-blob nog niet is verstreken. Het kopiëren van een blob resulteert echter in capaciteitskosten voor twee blobs, de bron-blob en de doel-blob.

Het wijzigen van het niveau van een blob van een warmer niveau naar een koeler niveau is onmiddellijk, net als het veranderen van koel naar warm. Het reactiveren van een blob van de archieflaag naar een onlinelaag, zoals de dynamische, statische of koude laag, kan tot 15 uur duren.

Houd rekening met de volgende punten bij het wijzigen van de laag van een blob:

  • U kunt Bloblaag instellen niet gebruiken om een blob te archiveren die gebruikmaakt van een encryptiebereik. U kunt Set Blob-laag alleen gebruiken om tussen online toegangsniveaus te schakelen. Zie Versleutelingsbereiken voor Blob Storage voor meer informatie over versleutelingsbereiken.

  • Als een blob expliciet wordt verplaatst naar de statische of koude laag en vervolgens naar de archieflaag wordt verplaatst, worden de kosten voor vroegtijdige verwijdering van toepassing.

  • Als een blob expliciet wordt verplaatst naar de statische of koude laag en vervolgens naar de archieflaag wordt verplaatst, worden de kosten voor vroegtijdige verwijdering van toepassing.

Levenscyclusbeheer voor blobs

Het levenscyclusbeheer van Blob Storage biedt een beleid op basis van regels dat u kunt gebruiken om uw gegevens over te zetten naar de gewenste toegangslaag wanneer aan de opgegeven voorwaarden wordt voldaan. U kunt levenscyclusbeheer ook gebruiken om gegevens te laten verlopen aan het einde van de levensduur. Zie Kosten optimaliseren door azure Blob Storage-toegangslagen te automatiseren voor meer informatie.

U kunt een gearchiveerde blob niet rehydrateren naar een online niveau met behulp van levenscyclusbeheerbeleid. Gegevens die zijn opgeslagen in een Premium-account voor blok-blobopslag, kunnen niet worden gelaagd naar dynamisch, statisch, koud of archief met behulp van De bloblaag instellen of het beheer van de levenscyclus van Azure Blob Storage. Als u gegevens wilt verplaatsen, moet u blobs synchroon kopiëren van het blok-blobopslagaccount naar de dynamische laag in een ander account met behulp van de Put Block From URL-API of een versie van AzCopy die deze API ondersteunt. Met de PUT Block From URL-API worden gegevens synchroon gekopieerd op de server, wat betekent dat de aanroep slechts wordt voltooid zodra alle gegevens van de oorspronkelijke serverlocatie naar de doellocatie worden verplaatst.

Opslagacties

Hoewel levenscyclusbeheer u helpt bij het verplaatsen van gegevens tussen lagen in één account, kunt u een opslagtaak gebruiken om deze taak op schaal uit te voeren voor meerdere accounts. Een opslagtaak is een resource die beschikbaar is in Azure Storage Actions; een serverloos framework dat u kunt gebruiken om algemene gegevensbewerkingen uit te voeren op miljoenen objecten in meerdere opslagaccounts. Zie Wat is Azure Storage Actions?voor meer informatie.

Overzicht van opties voor toegangslaag

De volgende tabel bevat een overzicht van de functies van de dynamische, statische, koude en archieftoegangslagen.

Hot-laag Koele laag Koude laag Archieflaag
Beschikbaarheid 99,9% 99% 99% 99%
Beschikbaarheid
(RA-GRS-leesbewerkingen)		 99,99% 99,9% 99,9% 99,9%
Gebruikskosten Hogere opslagkosten, maar lagere toegangs- en transactiekosten Lagere opslagkosten, maar hogere toegangs- en transactiekosten Lagere opslagkosten, maar hogere toegangs- en transactiekosten Laagste opslagkosten, maar hoogste toegang en transactiekosten
Minimale aanbevolen bewaarperiode voor gegevens Niet van toepassing. 30 dagen1 90 dagen1 180 dagen
Latentie
(Tijd tot eerste byte)		 Milliseconden Milliseconden Milliseconden Uren2
Ondersteunde redundantieconfiguraties Alle Alle Alle Alleen LRS, GRS en RA-GRS3

1 Objecten in de koele laag op v2-accounts voor algemeen gebruik hebben een minimale retentieduur van 30 dagen. Objecten in de koude laag voor v2-accounts voor algemeen gebruik hebben een minimale retentieduur van 90 dagen. Voor Blob Storage-accounts is er geen minimale retentieduur voor de statische of koude laag.

2 Wanneer u een blob rehydrateert vanuit de archieflaag, kunt u een standaard- of hoge rehydratatieprioriteitsoptie kiezen. Elk biedt verschillende latenties en kosten voor het ophalen. Voor meer informatie, zie Overzicht van rehydratatie van blobs vanuit de archieflaag.

3 Zie Azure Storage-redundantie voor meer informatie over redundantieconfiguraties in Azure Storage.

Prijsstelling en facturering

Alle opslagaccounts gebruiken een prijsmodel voor blok-blobopslag die is gebaseerd op de laag van een blob. Houd rekening met de factureringsoverwegingen die in de volgende secties worden beschreven.

Voor meer informatie over prijzen voor blokblobs, zie blokblobs-prijzen.

Kosten voor opslagcapaciteit

Naast de hoeveelheid gegevens die is opgeslagen, variëren de kosten voor het opslaan van gegevens, afhankelijk van de toegangslaag. De capaciteitskosten per gigabyte nemen af naarmate de laag koeler wordt.

Kosten voor gegevenstoegang

Kosten voor gegevenstoegang nemen toe naarmate de laag koeler wordt. Voor gegevens in de koele, koude en archieftoegangslaag worden kosten in rekening gebracht voor gegevensleesacties per gigabyte.

Transactiekosten

Er worden kosten per transactie in rekening gebracht voor alle lagen en worden verhoogd naarmate de laag koeler wordt.

Kosten voor overdracht van geo-replicatiegegevens

Deze kosten zijn alleen van toepassing op accounts waarvoor geo-replicatie is geconfigureerd, waaronder GRS, RA-GRS en GZRS. Kosten voor gegevensoverdracht met geo-replicatie worden in rekening gebracht per GB.

Kosten voor uitgaande gegevensoverdracht

Uitgaande gegevensoverdrachten (gegevens die worden overgedragen uit een Azure-regio) brengen facturering in rekening voor bandbreedtegebruik per gigabyte. Zie de pagina Prijsinformatie voor bandbreedte voor meer informatie over uitgaande kosten voor gegevensoverdracht.

De standaardaccounttoegangslaag wijzigen

Als u de accounttoegangslaag wijzigt, worden er kosten voor laagwijziging in rekening gebracht voor alle blobs waarvoor nog geen laag expliciet is ingesteld. Zie de volgende sectie voor meer informatie, het wijzigen van de toegangslaag van een blob.

De toegangslaag van een blob wijzigen

Houd rekening met de volgende factureringseffecten bij het wijzigen van de laag van een blob:

  • Wanneer een blob wordt geüpload of verplaatst tussen lagen, worden deze direct bij het uploaden of wijzigen van de laag in rekening gebracht tegen het bijbehorende tarief.
  • Wanneer een blob wordt verplaatst naar een koeler laag, wordt de bewerking gefactureerd als een schrijfbewerking naar de doellaag, waarbij de schrijfbewerking (per 10.000) en de kosten voor het schrijven van gegevens (per GB) van de doellaag van toepassing zijn.
  • Wanneer een blob wordt verplaatst naar een warmere laag, wordt de bewerking gefactureerd als een leesbewerking uit de bronlaag, waarbij de leesbewerking (per 10.000) en de kosten voor het ophalen van gegevens (per GB) van de bronlaag van toepassing zijn. Kosten voor vroegtijdige verwijdering voor eventuele blobs die zijn verplaatst uit de statische, koude of archieflaag, kunnen ook van toepassing zijn.
  • Terwijl een blob wordt gerehydrateerd vanuit de archieflaag, worden de gegevens van die blob gefactureerd als gearchiveerde gegevens totdat de gegevens zijn hersteld en de laag van de blob verandert in dynamisch, statisch of koud.

De volgende tabel geeft een overzicht van hoe laagwijzigingen worden gefactureerd.

Schrijfkosten (bewerking en toegang) Leeskosten (bewerking en toegang)
Heet naar koel
Warm naar koud
Klaar om te archiveren
Koel tot koud
Leuk om te archiveren
Koud om te archiveren		 Archiveren naar koude opslag
Archiveren voor koeling
Archiveren naar direct beschikbaar
Koud om af te koelen
Koud tot warm
Koud tot warm

Als u de toegangslaag voor een blob wijzigt wanneer versiebeheer is ingeschakeld, of als de blob momentopnamen bevat, kunnen er meer kosten in rekening worden gebracht. Zie prijzen en facturering in de documentatie voor blobversiebeheer voor informatie over blobs waarvoor versiebeheer is ingeschakeld. Voor informatie over blobs met momentopnamen, zie Prijzen en facturering in de documentatie voor blob-momentopnamen.

Koude laag

Voor de koude laag zijn de volgende minimale versies van REST, SDK's en hulpprogramma's vereist

Omgeving Minimumversie
REST API 2021-21-02
.NET 12.15.0
Java 12.21.0
Python 12.15.0
JavaScript 12.13.0
PowerShell (Az.Storage) 5.8.0
Azure-CLI 2.50.0
AzCopy 10.18.1
Azure-opslagverkenner 1.29.0

Functieondersteuning

Ondersteuning voor deze functie kan worden beïnvloed door het inschakelen van Data Lake Storage Gen2, het NFS-protocol (Network File System) 3.0 of het SSH File Transfer Protocol (SFTP). Als u een van deze mogelijkheden hebt ingeschakeld, raadpleegt u de ondersteuning voor Blob Storage-functies in Azure Storage-accounts om ondersteuning voor deze functie te beoordelen.

Volgende stappen