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.
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 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.
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 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.
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. 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), Statisch (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 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.
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 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.
U kunt een gearchiveerde blob niet reactiveren naar een onlinelaag met behulp van beleid voor levenscyclusbeheer. 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.
| Dynamische laag | Statische 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 | N.v.t. | 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 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.
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. Zie Overzicht van rehydratatie van blobs 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 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.
| Schrijfkosten (bewerking en toegang) | Leeskosten (bewerking en toegang) |
|---|---|
| Dynamisch naar statisch Warm naar koud Dynamisch naar archief Koel naar koud Statisch om te archiveren Koud om te archiveren |
Archiveren naar koude Archiveren om af te koelen Archiveren naar dynamisch Koud om af te koelen Koud tot warm Statisch tot dynamisch |
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
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.