Toegangslagen voor Azure Blob Storage - hot, cool en archief

Azure Storage biedt verschillende toegangslagen, zodat u blobobjectgegevens op de meest rendabele manier kunt opslaan. Beschikbare toegangslagen zijn onder andere:

  • Hot: geoptimaliseerd voor het opslaan van gegevens die regelmatig worden gebruikt.
  • Cool: geoptimaliseerd voor het opslaan van gegevens die niet regelmatig worden gebruikt en die ten minste 30 dagen worden opgeslagen.
  • Archief: geoptimaliseerd voor het opslaan van gegevens die zelden worden gebruikt en die ten minste 180 dagen worden opgeslagen met flexibele latentievereisten, in volgorde van uren.

De volgende overwegingen zijn van toepassing op de verschillende toegangslagen:

  • De toegangslaag kan tijdens of na het uploaden worden ingesteld op een blob.
  • Alleen de statische- en dynamische-toegangslagen kunnen op accountniveau worden ingesteld. De archieftoegangslaag kan alleen worden ingesteld op blobniveau.
  • Gegevens in de cool-toegangslaag hebben een iets lagere beschikbaarheid, maar hebben nog steeds een hoge duurzaamheid, ophaallatentie en doorvoerkenmerken die vergelijkbaar zijn met hot-gegevens. Voor 'cool' gegevens zijn iets lagere beschikbaarheid en hogere toegangskosten acceptabel voor lagere totale opslagkosten in vergelijking met hot data. Zie Dienstovereenkomst voor Storage voor meer informatie.
  • Gegevens in de archieftoegangslaag worden offline opgeslagen. De archieflaag biedt de laagste opslagkosten, maar ook de hoogste toegangskosten en latentie.
  • De lagen 'hot' en 'cool' ondersteunen alle redundantieopties. De archieflaag ondersteunt alleen LRS, GRS en RA-GRS.
  • Limieten voor gegevensopslag worden ingesteld op accountniveau en niet per toegangslaag. U kunt ervoor kiezen om al uw limieten in één laag of voor alle drie de lagen te gebruiken.

Gegevens die zijn opgeslagen in de cloud, groeien exponentieel. Voor een effectief beheer van de kosten voor uw groeiende opslagbehoeften is het vanwege kostenoptimalisatie een goed idee om de gegevens te ordenen op basis van kenmerken als toegangsfrequentie en geplande bewaarperiode. Gegevens die in de cloud zijn opgeslagen, kunnen verschillen vertonen naar gelang de manier waarop ze gedurende hun levensduur worden gegenereerd, verwerkt en geopend. Sommige gegevens worden tijdens hun hele levensduur actief geopend en gewijzigd. Andere gegevens worden in het begin van hun levensduur regelmatig geopend, terwijl dit naarmate de tijd verstrijkt, aanzienlijk minder vaak gebeurt. Sommige gegevens verblijven inactief in de cloud en worden zelden of nooit geopend nadat ze zijn opgeslagen.

Elk van deze scenario's voor gegevenstoegang profiteert van een andere toegangslaag die is geoptimaliseerd voor een bepaald toegangspatroon. Met de hot-, cool- en archive-toegangslaag wordt Azure Blob Storage aan deze behoefte aan gedifferentieerde toegangslagen met afzonderlijke prijsmodellen.

De volgende hulpprogramma's en clientbibliotheken ondersteunen allemaal opslaglagen op blob-niveau en archiefopslag.

  • Azure Portal
  • PowerShell
  • Azure CLI-hulpprogramma's
  • .NET-clientbibliotheek
  • Java-clientbibliotheek
  • Python-clientbibliotheek
  • Node.js-clientbibliotheek

Notitie

De functies die in dit artikel worden beschreven, zijn ook beschikbaar voor accounts met een hiërarchische naamruimte. Zie Blob Storage-functies die beschikbaar zijn in Azure Data Lake Storage Gen2 voor een overzicht van de beperkingen.

Storage-accounts die ondersteuning bieden voor opslaglagen

Gegevenslagen voor objectopslag tussen 'hot', 'cool' en 'archive' worden ondersteund in Blob Storage- en Algemeen v2-accounts (GPv2). Algemeen v1-accounts (GPv1) bieden geen ondersteuning voor opslaglagen. U kunt uw bestaande GPv1- of Blob Storage-accounts eenvoudig converteren naar GPv2-accounts via de Azure Portal. GPv2 biedt nieuwe prijzen en functies voor blobs, bestanden en wachtrijen. Sommige functies en prijsverlagingen worden alleen aangeboden in GPv2-accounts. Sommige workloads kunnen duurder zijn op GPv2 dan GPv1. Zie Overzicht van Azure-opslagaccount voor meer informatie.

Blob Storage en GPv2-accounts stellen het kenmerk Toegangslaag op accountniveau bloot. Met dit kenmerk kunt u de standaardtoegangslaag opgeven voor elke blob die deze niet expliciet op objectniveau heeft ingesteld. Voor objecten met de laag die expliciet is ingesteld, is de accountlaag niet van toepassing. De archieflaag kan alleen worden toegepast op objectniveau. U kunt op elk moment schakelen tussen toegangslagen.

Gebruik GPv2 in plaats van Blob Storage voor opslaglagen. GPv2 ondersteunt alle functies die Blob Storage accounts ondersteunen, plus nog veel meer. Prijzen tussen Blob Storage en GPv2 zijn bijna identiek, maar sommige nieuwe functies en prijsverlagingen zijn alleen beschikbaar voor GPv2-accounts.

De prijsstructuur tussen GPv1- en GPv2-accounts is verschillend en klanten moeten beide zorgvuldig evalueren alvorens te besluiten GPv2-accounts te gebruiken. U kunt een bestaand Blob Storage- of GPv1-account eenvoudig met één muisklik omzetten naar GPv2. Zie Overzicht van Azure-opslagaccount voor meer informatie.

Dynamische-toegangslaag

De dynamische-toegangslaag heeft hogere opslagkosten dan de statische-toegangslaag en de archieftoegangslaag, maar de laagste toegangskosten. Voorbeelden van gebruiksscenario's voor de dynamische-toegangslaag:

  • Gegevens die actief worden gebruikt of naar verwachting regelmatig worden gelezen en geschreven
  • Gegevens die zijn voorbereid voor verwerking en uiteindelijke migratie naar de cool-toegangslaag

Statische-toegangslaag

De statische-toegangslaag heeft lagere opslagkosten en hogere toegangskosten in vergelijking met dynamische opslag. Deze laag is bedoeld voor gegevens die ten minste dertig dagen in de Cold Storage verblijven. Voorbeelden van gebruiksscenario's voor de statische-toegangslaag:

  • Kortetermijnback-up en herstel na noodherstel
  • Oudere gegevens worden niet vaak gebruikt, maar zijn naar verwachting onmiddellijk beschikbaar wanneer ze worden gebruikt
  • Grote gegevenssets die rendabel moeten worden opgeslagen, terwijl er meer gegevens worden verzameld voor toekomstige verwerking

Archieftoegangslaag

De archieftoegangslaag heeft de laagste opslagkosten, maar hogere kosten voor het ophalen van gegevens in vergelijking met hot- en cool-lagen. Gegevens moeten ten minste 180 dagen in de archieflaag blijven of worden onderworpen aan kosten voor vroegtijdige verwijdering. Het ophalen van gegevens in de archieflaag kan enkele uren duren, afhankelijk van de opgegeven rehydratatieprioriteit. Voor kleine objecten kan een rehydratatie met hoge prioriteit het object in minder dan een uur uit het archief ophalen. Zie Blobgegevens uit de archieflaag rehydrateren voor meer informatie.

Wanneer een blob zich in archiefopslag, zijn de blobgegevens offline en kunnen ze niet worden gelezen of gewijzigd. Als u een blob in een archief wilt lezen of downloaden, moet u deze eerst rehydrateren naar een online laag. U kunt geen momentopnamen maken van een blob in archiefopslag. De blobmetagegevens blijven echter online en beschikbaar, zodat u de blob, de eigenschappen, metagegevens en blob-indextags kunt weergeven. Het instellen of wijzigen van de blobmetagegevens in een archief is niet toegestaan. U kunt de blobindextags echter instellen en wijzigen. Voor blobs in archief zijn de enige geldige bewerkingen Blob-eigenschappen krijgen,Blob-metagegevens downloaden, Blob-tagsinstellen, Blob-tagsop halen, Blobs zoeken op tags, Blobsweergeven, Blob-laaginstellen, Blobkopiëren en Blob verwijderen.

Voorbeeld 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 ze zijn verwerkt tot de uiteindelijke gebruiksbare vorm
  • Nalevings- en archiveringsgegevens die lange tijd moeten worden opgeslagen en nauwelijks worden gebruikt

Notitie

De archieflaag wordt niet ondersteund voor ZRS-, GZRS- of RA-GZRS-accounts. Migreren van LRS naar GRS wordt ondersteund zolang er geen blobs naar de archieflaag zijn verplaatst terwijl het account was ingesteld op LRS. Een account kan worden verplaatst naar GRS als de update minder dan 30 dagen wordt uitgevoerd vanaf het moment dat het account LRS werd en er geen blobs werden verplaatst naar de archieflaag terwijl het account was ingesteld op LRS.

Opslaglagen op accountniveau

Blobs in alle drie de toegangslagen kunnen naast elkaar bestaan binnen hetzelfde account. Elke blob die geen expliciet toegewezen laag heeft, stelt de laag af van de instelling toegangslaag van het account. Als de toegangslaag afkomstig is van het account, ziet u dat de blob-eigenschap Access Tier Inferred is ingesteld op 'true' en dat de blob-eigenschap Access Tier overeenkomt met de accountlaag. In de Azure Portal wordt de eigenschap Access Tier Inferred weergegeven met de blob-toegangslaag als Hot (afgeleid) of Cool (afgeleid).

Het wijzigen van de accounttoegangslaag is van toepassing op alle afgeleide objecten van de toegangslaag die zijn opgeslagen in het account en die geen expliciete laag hebben ingesteld. Als u de accountlaag van 'hot' naar 'cool' zet, worden er alleen voor schrijfbewerkingen (per 10.000) kosten in rekening gebracht voor alle blobs zonder een set-laag in GPv2-accounts. Er worden geen kosten in rekening voor deze wijziging in Blob Storage accounts. Er worden kosten in rekening gebracht voor zowel leesbewerkingen (per 10.000) als het ophalen van gegevens (per GB) als u in Blob Storage- of GPv2-accounts van 'cool' naar 'hot' schakelt.

Alleen hot- en cool-toegangslagen kunnen worden ingesteld als de standaardaccounttoegangslaag. Archive kan alleen op objectniveau worden ingesteld. Bij het uploaden van blobs kunt u de toegangslaag van uw keuze opgeven als hot, cool of archief, ongeacht de standaardaccountlaag. Met deze functionaliteit kunt u gegevens rechtstreeks naar de archieflaag schrijven om kostenbesparingen te realiseren vanaf het moment dat u gegevens in blobopslag maakt.

Laaginstelling op blobniveau

Met opslaglagen op blobniveau kunt u gegevens uploaden naar de toegangslaag van uw keuze met behulp van de bewerkingen Put Blob of Put Block List en de laag van uw gegevens op objectniveau wijzigen met behulp van de bewerking Bloblaag instellen of levenscyclusbeheerfunctie. U kunt gegevens uploaden naar de vereiste toegangslaag en vervolgens eenvoudig de blob-toegangslaag wijzigen in de hot-, cool- of archieflaag als gebruikspatronen veranderen, zonder dat u gegevens tussen accounts moet verplaatsen. Alle wijzigingsaanvragen voor lagen worden onmiddellijk doorgevoerd en de laagwijzigingen tussen 'hot' en 'cool' worden onmiddellijk doorgevoerd. Het rehydrateren van een blob vanuit de archieflaag kan enkele uren duren.

Het tijdstip waarop de laatste wijziging aan de blob-laag heeft plaatsgevonden, wordt weergegeven via de blob-eigenschap Access Tier Change Time. Wijzigingstijd toegangslaag is een eigenschap op blobniveau en wordt niet bijgewerkt wanneer de standaardaccountlaag wordt gewijzigd. Accounteigenschappen en blob-eigenschappen zijn gescheiden. Het zou enorm duur zijn om de wijzigingstijd van de toegangslaag voor elke blob in een opslagaccount bij te werken wanneer de standaardtoegangslaag van het account wordt gewijzigd.

Wanneer u een blob in de hot- of cool-laag overschrijft, neemt de zojuist gemaakte blob de laag over van de blob die is overschreven, tenzij de nieuwe blobtoegangslaag expliciet is ingesteld bij het maken. Als een blob zich in de archieflaag , kan deze niet worden overschreven, zodat het uploaden van dezelfde blob niet is toegestaan in dit scenario.

Notitie

Archiefopslag en laaginstelling op blobniveau ondersteunen alleen blok-blobs.

Levenscyclusbeheer van blobs

Levenscyclusbeheer voor Blob Storage biedt een uitgebreid, op regels gebaseerd beleid dat u kunt gebruiken om uw gegevens over te brengen naar de beste toegangslaag en om gegevens aan het einde van de levenscyclus te laten verlopen. Zie Kosten optimaliseren door de Azure Blob Storage te automatiseren voor meer informatie.

Notitie

Gegevens die zijn opgeslagen in een blok-blobopslagaccount (Premium-prestaties) kunnen momenteel niet worden gelaagd naar hot, cool of archive met behulp van Blob-laag instellen of Azure Blob Storage levenscyclusbeheer. Als u gegevens wilt verplaatsen, moet u blobs synchroon kopiëren van het blok-blobopslagaccount naar de hot access-laag in een ander account met behulp van de PUT Block From URL API of een versie van AzCopy die ondersteuning biedt voor deze API. De PUT Block From URL-API kopieert synchroon gegevens op de server, wat betekent dat de aanroep alleen wordt voltooid wanneer alle gegevens van de oorspronkelijke serverlocatie naar de doellocatie worden verplaatst.

Facturering van laaginstelling op blobniveau

Wanneer een blob wordt geüpload of verplaatst tussen lagen, wordt deze direct na het uploaden of wijzigen van de laag in rekening gebracht tegen het overeenkomstige tarief.

Wanneer een blob wordt verplaatst naar een lagere categorie (hot->cool, hot->archive of cool->archive), wordt de bewerking gefactureerd als een schrijfbewerking naar de doellaag, waarbij de kosten voor schrijfbewerkingen (per 10.000) en het schrijven van gegevens (per GB) van de doellaag van toepassing zijn.

Wanneer een blob wordt verplaatst naar een tier (archive->cool, archive->hot of cool->hot), wordt de bewerking gefactureerd als een leesbewerking van de bronlaag, waarbij de kosten voor de leesbewerking (per 10.000) en het ophalen van gegevens (per GB) van de bronlaag van toepassing zijn. Kosten voor vroegtijdige verwijdering voor elke blob die uit de cool- of archieflaag is verplaatst, kunnen ook van toepassing zijn. Het rehydrateren van gegevens uit de archieflaag kost tijd en er worden archiefprijzen in rekening gebracht totdat de gegevens online zijn hersteld en de bloblaag verandert in 'hot' of 'cool'.

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

Schrijfkosten (bewerking en toegang) Kosten voor lezen (bewerking en toegang)
Set Blob Tier (Blob-laag instellen) hot -> cool
hot -> archive
cool -> archive
archive -> cool
archive -> hot
cool -> hot

Vroege verwijdering voor Koud en Archief

Elke blob die wordt verplaatst naar de cool-laag (alleen GPv2-accounts) is onderworpen aan een cool vroege verwijderingsperiode van 30 dagen. Elke blob die naar de archieflaag wordt verplaatst, is onderworpen aan een periode van 180 dagen voor vroegtijdige verwijdering van een archief. Deze kosten zijn evenredig verdeeld. Als een blob bijvoorbeeld na 45 dagen wordt verplaatst naar archief en vervolgens wordt verwijderd of verplaatst naar de hot-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 een archief.

Er zijn enkele details bij het verplaatsen tussen de cool- en archieflaag:

  1. Als een blob wordt afgeleid als cool op basis van de standaardtoegangslaag van het opslagaccount en de blob wordt verplaatst naar archiveren, worden er geen kosten voor vroegtijdige verwijdering in rekening brengen.
  2. Als een blob expliciet wordt verplaatst naar de cool-laag en vervolgens wordt verplaatst naar archiveren, worden de kosten voor vroegtijdige verwijdering in rekening brengen.

Bereken de tijd voor vroegtijdige verwijdering met behulp van de blob-eigenschap Laatst gewijzigd, als er geen wijzigingen in de toegangslaag zijn aangebracht. Gebruik anders wanneer de toegangslaag voor het laatst is gewijzigd in 'cool' of 'archiveren' door de blob-eigenschap access-tier-change-time weer te geven. Zie Blob-eigenschappen verkrijgen voor meer informatie over blob-eigenschappen.

Opties voor blok-blobopslag vergelijken

In de volgende tabel ziet u een vergelijking van de premium-prestatie blok-blobopslag en de hot-, cool- en archive-toegangslaag.

Premium-prestaties Hot-laag Cool-laag Archieflaag
Beschikbaarheid 99,9% 99,9% 99% Offline
Beschikbaarheid
(RA-GRS-leesbewerkingen)
N.v.t. 99,99% 99,9% Offline
Gebruikskosten Hogere opslagkosten, lagere toegang en transactiekosten Hogere opslagkosten, lagere toegangs- en transactiekosten Lagere opslagkosten, hogere toegang en transactiekosten Laagste opslagkosten, hoogste toegangs- en transactiekosten
Minimale opslagduur N.v.t. N.v.t. 30 dagen1 180 dagen
Latentie
(Tijd tot eerste byte)
Milliseconden van één cijfer milliseconden milliseconden uur2

1 Objecten in de cool-laag op GPv2-accounts hebben een minimale retentieduur van 30 dagen. Blob Storage accounts hebben geen minimale retentieduur voor de cool-laag.

2 Archive Storage ondersteunt momenteel twee rehydratatieprioriteiten, hoog en standaard, die verschillende ophaallatentie en kosten bieden. Zie Blobgegevens uit de archieflaag rehydrateren voor meer informatie.

Notitie

Blob Storage-accounts ondersteunen dezelfde prestatie- en schaalbaarheidsdoelen als v2-opslagaccounts voor algemeen gebruik. Zie Schaalbaarheids- en prestatiedoelen voor Blob Storage.

Prijzen en facturering

Alle opslagaccounts gebruiken een prijsmodel voor blok-blobopslag op basis van de laag van elke blob. Houd rekening met de volgende factureringsoverwegingen:

  • Opslagkosten: de kosten voor het opslaan van gegevens hangen niet alleen af van de hoeveelheid opgeslagen gegevens, maar ook van de gebruikte toegangslaag. De kosten per GB nemen af als de laag minder dynamisch ('cooler') wordt.

  • Kosten van gegevenstoegang: de kosten voor gegevenstoegang nemen toe als de laag minder dynamisch ('cooler') wordt. Voor gegevens in de cool- en archieftoegangslaag worden kosten in rekening gebracht per gigabyte aan gegevenstoegang voor leesgegevens.

  • Transactiekosten: er worden kosten per transactie in rekening brengen voor alle lagen die toenemen naarmate de laag minder goed wordt.

  • Kosten voor gegevensoverdracht met geo-replicatie: deze kosten gelden alleen voor accounts met geconfigureerde geo-replicatie, waaronder GRS en RA-GRS. Kosten voor gegevensoverdracht met geo-replicatie worden in rekening gebracht per GB.

  • Kosten voor uitgaande gegevensoverdracht: uitgaande gegevensoverdracht (gegevens die buiten een Azure-regio worden overgedragen) worden gefactureerd voor bandbreedtegebruik per GB, net zoals bij opslagaccounts voor algemeen gebruik.

  • De toegangslaag wijzigen: als u de toegangslaag van het account wijzigt, worden kosten voor het wijzigen van de laag in rekening gebracht voor alle blobs waar geen expliciete laag is ingesteld. Zie Laaginformatie op blobniveau voor meer informatie over het wijzigen van de toegangslaag voor één blob.

    Het wijzigen van de toegangslaag voor een blob wanneer versien is ingeschakeld of als de blob momentopnamen heeft, kan leiden tot extra kosten. Zie Prijzen en facturering in de documentatie over blobversies voor meer informatie over blobs met versie-uitvoering ingeschakeld. Zie Prijzen en facturering in de documentatie over blob-momentopnamen voor meer informatie over blobs met momentopnamen.

Notitie

Zie Prijzen van blok-blobs voor meer informatie over prijzen voor blok-blobs. Zie de pagina Prijsinformatie voor bandbreedte voor meer informatie over kosten voor uitgaande gegevensoverdracht.

Beschikbaarheid

Verschillende toegangslagen, samen met lagen op blobniveau, zijn beschikbaar in bepaalde regio's. Zie voor een volledige lijst Azure-producten beschikbaar per regio.

Volgende stappen

Meer informatie over het beheren van blobs en accounts in verschillende toegangslagen.