Toegangslagen 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-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.
• 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.

Onlinetoegangslagen

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 statische-toegangslaag.

Gebruiksscenario's voor de statische en koude toegangslagen zijn onder andere:

• 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.

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 wordt verplaatst naar de archieflaag en na 45 dagen na 45 dagen naar de dynamische laag wordt verwijderd of verplaatst, worden kosten in rekening gebracht voor vroegtijdige verwijdering die gelijk is 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 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. Zie Overzicht van rehydratatie van blobs vanuit de archieflaag voor meer informatie over rehydratatie van blobs.

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 statische-laagtarieven. Momentopnamen worden niet ondersteund voor gearchiveerde blobs.

De volgende bewerkingen worden ondersteund voor blobs in de archieflaag:

• Blob kopiëren
• Blob verwijderen
• Blob verwijderen ongedaan maken
• Blobs zoeken op tags
• Blobmetagegevens ophalen
• Get Blob Properties (Blob-eigenschappen ophalen)
• Blobtags ophalen
• Lijst met blobs
• Blobtags instellen
• Set Blob Tier (Blob-laag instellen)

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 de redundantieconfiguratie van een opslagaccount met gearchiveerde blobs te wijzigen.

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 minder dan 30 dagen wordt uitgevoerd vanaf het moment dat het account LRS werd en er geen blobs naar de archieflaag zijn verplaatst terwijl het account is ingesteld op LRS.

Standaardinstelling voor accounttoegangslaag

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 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 over een expliciet toegewezen laag beschikt, bepaalt de laag van de laag van de standaardaccounttoegangslaag. Als de toegangslaag van een blob wordt afgeleid van de instelling voor de standaardaccounttoegangslaag, wordt de toegangslaag 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 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 u schakelt naar een warmere laag 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 leesbewerkingen (per 10.000) 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.

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 aan te roepen, rechtstreeks of via een levenscyclusbeheerbeleid . 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 reactiveren naar een onlinelaag met behulp van beleid voor levenscyclusbeheer.

• 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 de laag van een blob van een warmere laag naar een koeler is onmiddellijk, net als het veranderen van koud of statisch naar dynamisch. 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 Set Blob Tier niet aanroepen voor een blob die gebruikmaakt van een versleutelingsbereik. 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.

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.

Overzicht van opties voor toegangslaag

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

¹ Objecten in de statische 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.

² 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. Zie Overzicht van rehydratatie van blobs vanuit de archieflaag voor meer informatie.

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

Prijzen 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.

Zie Blok-blobprijzen voor meer informatie over prijzen voor blok-blobs.

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 statische, koude en archieftoegangslaag worden kosten in rekening gebracht voor gegevenstoegang per gigabyte voor leesbewerkingen.

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 bevat een overzicht van de kosten voor het factureren van laagwijzigingen.

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. Zie prijzen en facturering in de documentatie voor blob-momentopnamen voor informatie over blobs met momentopnamen.

Koude laag

Beperkingen en bekende problemen

• De standaardinstelling voor de toegangslaag van het account kan niet worden ingesteld op koude laag.

Vereiste versies van REST, SDK's en hulpprogramma's

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

• De toegangslaag van een blob instellen
• Een blob archiveren
• Kosten optimaliseren door de levenscyclus van gegevens automatisch te beheren
• Aanbevolen procedures voor het gebruik van blob-toegangslagen