Dynamische, statische en archieftoegangslagen voor blobgegevens

Gegevens die in de cloud zijn opgeslagen, groeien exponentieel. Als u de kosten voor uw groeiende opslagbehoeften wilt beheren, kan het handig zijn om uw gegevens te ordenen op basis van hoe vaak ze worden geopend en hoe lang ze worden bewaard. Azure storage offers different access tiers so that you can store your blob data in the most cost-effective manner based on how it's being used. Azure Storage-toegangslagen zijn onder andere:

  • Dynamische laag : een onlinelaag die is geoptimaliseerd voor het opslaan van gegevens die regelmatig worden geopend of gewijzigd. De dynamische 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 statische laag heeft lagere opslagkosten en hogere toegangskosten in vergelijking met de dynamische laag.
  • Archieflaag : een offlinelaag die is geoptimaliseerd voor het opslaan van gegevens die zelden worden geopend en die flexibele latentievereisten hebben, in de orde 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 capaciteit over twee of meer lagen te verdelen.

Notitie

Het instellen van de toegangslaag is alleen toegestaan voor blok-blobs. Ze worden niet ondersteund voor toevoeg- en pagina-blobs.

Onlinetoegangslagen

Wanneer uw gegevens zijn opgeslagen in een onlinetoegangslaag (dynamisch of statisch), hebben gebruikers er onmiddellijk toegang toe. De dynamische laag is de beste keuze voor gegevens die actief worden gebruikt. De statische laag is ideaal voor gegevens die minder vaak worden geopend, maar die wel 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 statische-toegangslaag.

Gebruiksscenario's voor de statische toegangslaag zijn onder andere:

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

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

Gegevens in de statische laag hebben een iets lagere beschikbaarheid, maar bieden dezelfde hoge duurzaamheid, latentie bij ophalen en doorvoer als de dynamische laag. Voor gegevens in de statische laag kunnen iets lagere beschikbaarheid en hogere toegangskosten acceptabel zijn voor lagere totale opslagkosten in vergelijking met de dynamische laag. Zie Dienstovereenkomst voor Storage voor meer informatie.

Een blob in de statische laag in een v2-account voor algemeen gebruik is onderworpen aan een boete voor vroegtijdige verwijdering als deze vóór 30 dagen is verwijderd of verplaatst naar een andere laag. Deze kosten zijn evenredig verdeeld. Als een blob bijvoorbeeld wordt verplaatst naar de statische laag en na 21 dagen wordt verwijderd, worden kosten voor vroegtijdige verwijdering in rekening gebracht die gelijk zijn aan 9 (30 min 21) dagen voor het opslaan van die blob in de statische laag.

De dynamische en statische 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 en statische lagen. Voorbeelden van gebruiksscenario's voor de archieftoegangslaag zijn:

  • Langetermijnback-up, secundaire back-up en gegevenssets voor archivering
  • Oorspronkelijke (onbewerkte) gegevens die behouden moeten blijven, zelfs nadat deze zijn verwerkt tot uiteindelijke bruikbare vorm
  • Nalevings- en archiveringsgegevens die lang moeten worden opgeslagen en bijna nooit 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 wordt verplaatst naar de archieflaag en vervolgens na 45 dagen wordt verwijderd of verplaatst naar de dynamische laag, worden 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.

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 rehydrateeren naar een onlinelaag, dynamisch of statisch. Het kan tot 15 uur duren voordat gegevens in de archieflaag zijn gerehydrateerd, afhankelijk van de prioriteit die u opgeeft voor de reactivatiebewerking. Zie Overzicht van rehydratatie van blobs vanuit de archieflaag voor meer informatie over blobrehydratatie.

De metagegevens van een gearchiveerde blob blijven beschikbaar voor leestoegang, zodat u de blob en de eigenschappen, metagegevens en indextags kunt vermelden. Metagegevens voor een blob in de archieflaag zijn alleen-lezen, terwijl blob-indextags kunnen worden gelezen of geschreven. Opslagkosten voor metagegevens van gearchiveerde blobs worden in rekening gebracht op cool-laagtarieven. 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 of statische laag. Omdat rehydratatiebewerkingen kostbaar en tijdrovend kunnen zijn, raadt Microsoft u aan de redundantieconfiguratie van een opslagaccount dat gearchiveerde blobs bevat, niet te wijzigen.

Het migreren van een opslagaccount van LRS naar GRS wordt ondersteund zolang er geen blobs naar de archieflaag zijn verplaatst terwijl het account is geconfigureerd voor LRS. Een account kan worden teruggezet naar GRS als de update minder dan 30 dagen nadat het account LRS werd, wordt uitgevoerd en er geen blobs zijn verplaatst naar de archieflaag terwijl het account was ingesteld op LRS.

Standaardinstelling voor toegangslaag voor accounts

Opslagaccounts hebben een standaardinstelling voor toegangslagen die de onlinelaag aangeeft waarin een nieuwe blob wordt gemaakt. De standaardinstelling voor de toegangslaag kan worden ingesteld op dynamisch of statisch. Gebruikers kunnen de standaardinstelling voor een afzonderlijke blob overschrijven wanneer ze de blob uploaden of de laag ervan wijzigen.

De standaardtoegangslaag voor een nieuw algemeen v2-opslagaccount is standaard ingesteld op de dynamische laag. U kunt de standaardinstelling voor de toegangslaag wijzigen wanneer u een opslagaccount maakt of nadat dit 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 waaraan geen expliciet toegewezen laag is toegewezen, leid de laag af van de standaardinstelling voor toegangslaag voor accounts. Als de toegangslaag van een blob wordt afgeleid van de instelling voor de standaardtoegangslaag voor accounts, wordt de toegangslaag in de Azure Portal weergegeven als Dynamisch (afgeleid) of Statisch (afgeleid).

Het wijzigen van de standaardinstelling voor toegangslagen voor een opslagaccount is van toepassing op alle blobs in het account waarvoor geen toegangslaag expliciet is ingesteld. Als u de standaardinstelling voor de toegangslaag wijzigt van dynamisch naar statisch 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 het ophalen van gegevens (per GB) als u wisselt van statisch naar dynamisch in een v2-account voor algemeen gebruik.

Wanneer u een verouderd Blob Storage-account maakt, moet u de standaardinstelling voor de toegangslaag opgeven als dynamisch of statisch tijdens het maken. Er zijn geen kosten verbonden aan het wijzigen van de standaardinstelling voor toegangslagen voor accounts van dynamisch in statisch in een verouderd Blob Storage-account. Er worden kosten in rekening gebracht voor zowel leesbewerkingen (per 10.000) als het ophalen van gegevens (per GB) als u wisselt van statisch naar dynamisch in een Blob Storage-account. Microsoft raadt aan om indien mogelijk v2-opslagaccounts voor algemeen gebruik te gebruiken in plaats van Blob Storage-accounts.

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 bewerking Blob-laag instellen rechtstreeks of via een levenscyclusbeheerbeleid aan te roepen. Het aanroepen van Blob-laag instellen is doorgaans de beste optie wanneer u de laag van een blob wijzigt van een dynamischere naar een koelere laag.
  • Door de bewerking Blob kopiëren aan te roepen om een blob van de ene laag naar de andere te kopiëren. Het aanroepen van Blob kopiëren wordt aanbevolen voor de meeste scenario's waarin u een blob van de archieflaag naar een onlinelaag reactiveert of een blob verplaatst van statisch 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 de laag van een blob van dynamisch naar statisch of archief gaat direct, net als het wijzigen van statisch naar dynamisch. Het reactiveren van een blob van de archieflaag naar de dynamische of statische laag kan maximaal 15 uur duren.

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

  • U kunt Blob-laag instellen niet aanroepen voor een blob die gebruikmaakt van een versleutelingsbereik. Zie Versleutelingsbereiken voor blobopslag voor meer informatie over versleutelingsbereiken.
  • Als de laag van een blob wordt afgeleid als statisch op basis van de standaardtoegangslaag van het opslagaccount en de blob wordt verplaatst naar de archieflaag, worden er geen kosten in rekening gebracht voor vroegtijdige verwijdering.
  • Als een blob expliciet wordt verplaatst naar de statische laag en vervolgens naar de archieflaag wordt verplaatst, zijn de kosten voor vroegtijdige verwijdering van toepassing.

De volgende tabel bevat een overzicht van de methoden die u kunt gebruiken om blobs tussen verschillende lagen te verplaatsen.

Oorsprong/bestemming Dynamische laag Statische laag Archieflaag
Dynamische laag N.v.t. Wijzig de laag van een blob van dynamisch naar statisch met Blob-laag instellen of Blob kopiëren. Meer informatie...

Verplaats blobs naar de statische laag met een levenscyclusbeheerbeleid. Learn more...
Wijzig de laag van een blob van dynamisch in archief met Blob-laag instellen of Blob kopiëren. Learn more...

Archiveer blobs met een levenscyclusbeheerbeleid. Learn more...
Statische laag Wijzig de laag van een blob van statisch in dynamisch met Blob-laag instellen of Blob kopiëren. Learn more...

Verplaats blobs naar de dynamische laag met een levenscyclusbeheerbeleid. Learn more...
N.v.t. Wijzig de laag van een blob van statisch in archief met Blob-laag instellen of Blob kopiëren. Learn more...

Archive blobs with a lifecycle management policy. Learn more...
Archieflaag Rehydrateer naar de dynamische laag met Blob-laag instellen of Blob kopiëren. Learn more... Rehydrateer de statische laag met Blob-laag instellen of Blob kopiëren. Learn more... N.v.t.

Levenscyclusbeheer voor blobs

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 ook levenscyclusbeheer gebruiken om gegevens aan het einde van de levensduur te laten verlopen. Zie Kosten optimaliseren door Azure Blob Storage toegangslagen te automatiseren voor meer informatie.

Notitie

Gegevens die zijn opgeslagen in een premium blok-blobopslagaccount, kunnen niet worden gelaagd naar dynamisch, statisch of archief met behulp van Blob-laag instellen of met behulp van Azure Blob Storage levenscyclusbeheer. 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 API Put Block From URL of een versie van AzCopy die deze API ondersteunt. Met de API Put Block From URL worden gegevens synchroon gekopieerd op de server, wat betekent dat de aanroep alleen wordt voltooid zodra alle gegevens van de oorspronkelijke serverlocatie naar de doellocatie zijn verplaatst.

Overzicht van opties voor toegangslagen

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

Hot tier Cool tier Archive tier
Beschikbaarheid 99,9% 99% Offline
Beschikbaarheid
(RA-GRS-leesbewerkingen)
99,99% 99,9% Offline
Gebruikskosten Hogere opslagkosten, maar lagere toegangs- en transactiekosten Lagere opslagkosten, maar hogere toegangs- en transactiekosten Laagste opslagkosten, maar hoogste toegangs- en transactiekosten
Minimale aanbevolen bewaarperiode voor gegevens N.v.t. 30 dagen1 180 dagen
Latentie
(Tijd tot eerste byte)
Milliseconden Milliseconds Uur2
Ondersteunde redundantieconfiguraties Alles Alles Alleen LRS, GRS en RA-GRS3

1 Objecten in de statische laag op accounts voor algemeen gebruik v2 hebben een minimale bewaarperiode van 30 dagen. Voor Blob Storage-accounts geldt geen minimale bewaarperiode voor de statische laag.

2 Wanneer u een blob reactiveert vanuit de archieflaag, kunt u een standaardoptie of een hoge reactivatieprioriteit kiezen. Elk biedt verschillende ophaallatenties en -kosten. Zie Overzicht van rehydratatie van blob vanuit de archieflaag voor meer informatie.

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

Prijzen en facturering

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

Zie Prijzen voor blokblobs voor meer informatie over prijzen voor blok-blobs.

Kosten van 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

De kosten voor gegevenstoegang nemen toe naarmate de laag koeler wordt. Voor gegevens in de statische en archieftoegangslaag worden kosten per gigabyte in rekening gebracht voor gegevenstoegang voor leesbewerkingen.

Transactiekosten

Kosten per transactie zijn van toepassing op alle lagen en worden verhoogd naarmate de laag koeler wordt.

Kosten voor geo-replicatiegegevensoverdracht

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

Voor uitgaande gegevensoverdracht (gegevens die worden overgedragen uit een Azure-regio) wordt het bandbreedtegebruik per gigabyte gefactureerd. Zie de pagina Prijsinformatie voor bandbreedte voor meer informatie over kosten voor uitgaande gegevensoverdracht.

De standaardtoegangslaag voor accounts wijzigen

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

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, wordt deze direct na het uploaden of bij het wijzigen van de laag tegen het bijbehorende tarief in rekening gebracht.
  • Wanneer een blob wordt verplaatst naar een koelere laag, wordt de bewerking gefactureerd als een schrijfbewerking naar de doellaag, waarbij de kosten voor de schrijfbewerking (per 10.000) en 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 kosten voor het lezen (per 10.000) en het ophalen van gegevens (per GB) van de bronlaag van toepassing zijn. Kosten voor vroegtijdige verwijdering van een blob die is verplaatst uit de opslaglaag Cool of Archive 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 of statisch.

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

Kosten schrijven (bewerking + toegang) Kosten lezen (bewerking + toegang)
Bewerking bloblaag instellen Dynamisch naar koel
Dynamisch om te archiveren
Statisch om te archiveren
Archiveren naar statisch
Archiveren naar dynamisch
koel naar warm

Het wijzigen van de toegangslaag voor een blob wanneer versiebeheer is ingeschakeld of als de blob momentopnamen bevat, kan leiden tot meer kosten. Zie Prijzen en facturering in de documentatie voor blobversiebeheer voor informatie over blobs waarvoor versiebeheer is ingeschakeld. Zie Prijzen en facturering in de documentatie over blob-momentopnamen voor informatie over blobs met momentopnamen.

Functieondersteuning

Ondersteuning voor deze functie kan worden beïnvloed door het inschakelen van Data Lake Storage Gen2, het NFS 3.0-protocol (Network File System) of het SSH File Transfer Protocol (SFTP).

Als u een van deze mogelijkheden hebt ingeschakeld, raadpleegt u Ondersteuning van Blob Storage-functies in Azure Storage-accounts om de ondersteuning voor deze functie te evalueren.

Volgende stappen