Inzicht in de facturering van Azure Files

Dit artikel helpt u inzicht te hebben in de verschillende factureringsmodellen voor Azure Files, zodat u de kosten kunt beheren en de totale eigendomskosten kunt bepalen. Zie Azure Files prijzen voor prijsinformatie.

De kosten van een Azure Files-implementatie bepalen

Vier belangrijke factoren bepalen de kosten van een Azure Files-implementatie: factureringsmodel, medialaag, redundantieoptie en resourcemodel.

Facturatiemodel

Azure Files ondersteunt drie verschillende factureringsmodellen: geprovisioneerd v2, geprovisioneerd v1 en betalen naar gebruik.

• Ingericht v2: Een ingericht factureringsmodel waar u opslag, IOPS en doorvoer afzonderlijk kunt inrichten. U betaalt op basis van wat u inricht, ongeacht hoeveel u daadwerkelijk gebruikt. Gebruik het ingerichte v2-model voor alle nieuwe Azure Files-implementaties.
• Ingericht v1: Een ingericht factureringsmodel waarin u de hoeveelheid opslagruimte inricht die u nodig hebt, terwijl IOPS en doorvoer worden bepaald door de hoeveelheid opslagruimte die u inricht. Gebruik het ingerichte v2-model, tenzij u een specifieke reden hebt om het ingerichte v1-model te gebruiken.
• Betalen per gebruik: een factureringsmodel op basis van gebruik waarin de kosten worden bepaald op basis van hoeveel u de bestandsshare gebruikt, in de vorm van gebruikte opslag, transactie en kosten voor gegevensoverdracht. Gebruik het ingerichte v2-model, tenzij u een specifieke reden hebt om het betalen-naar-gebruik-model te gebruiken.

Medialeigang

Azure Files ondersteunt twee verschillende medialagen van opslag: SSD (Solid State Drives) en harde schijven (HDD). Met deze ondersteuning kunt u uw bestandsshares aanpassen aan de prestatie- en prijsvereisten van uw scenario.

• SSD (premium): bestandsshares die worden gehost op SSD bieden consistente hoge prestaties en lage latentie, met latentie van één milliseconden voor de meeste IO-bewerkingen.
• HDD (standaard): bestandsshares die worden gehost op HDD bieden rendabele opslag voor algemeen gebruik.

Opties voor redundantie

Azure Files ondersteunt vier verschillende redundantieopties die u kunt gebruiken om te bepalen hoeveel kopieën van uw gegevens worden opgeslagen en waar deze kopieën in de infrastructuur van Azure worden geplaatst. Tolerantere opties bieden meer duurzaamheid en beschikbaarheid, maar hebben hogere kosten:

• Lokaal redundante opslag (LRS) bewaart drie kopieën van uw gegevens in één datacenter in één regio.
• Met zone-redundante opslag (ZRS) worden drie kopieën van uw gegevens opgeslagen in onafhankelijke datacenters (beschikbaarheidszones) binnen een regio.
• Met geografisch redundante opslag (GRS) worden drie kopieën van de gegevens in de primaire regio opgeslagen en asynchroon gerepliceerd naar een gekoppelde regio, voor in totaal zes exemplaren. Alleen beschikbaar op HDD-opslag.
• Geografisch zone-redundante opslag (GZRS) combineert zoneredundantie in de primaire regio met asynchrone replicatie naar een secundaire regio. Alleen beschikbaar op HDD-opslag.

Hulpbronmodel

Azure Files ondersteunt twee verschillende resourcetypen op het hoogste niveau. Dit zijn items die u in uw Azure abonnementen en resourcegroepen maakt en beheert. Elk resourcetype ondersteunt enigszins verschillende opties voor het factureringsmodel, wat op zijn beurt van invloed is op zowel kosten- als kostenstructuur:

• Opslagaccounts vertegenwoordigen een gedeelde opslaggroep, IOPS en doorvoer waarin u klassieke bestandsshares of andere opslagbronnen kunt implementeren, afhankelijk van het type opslagaccount. Opslagaccounts ondersteunen alle factureringsmodellen, medialagen en redundantieopties. Alle opslagbronnen die u in een opslagaccount implementeert, delen de limieten die van toepassing zijn op dat opslagaccount. Klassieke bestandsshares ondersteunen zowel de SMB- als NFS-protocollen, hoewel NFS alleen wordt ondersteund op SSD-opslag. De Microsoft.Storage-resourceprovider biedt opslagaccounts en u maakt klassieke bestandsshares binnen die opslagaccounts.

• Bestandsshares zijn een nieuw resourcetype op het hoogste niveau dat de implementatie van Azure-bestandsshares vereenvoudigt, doordat u geen opslagaccount meer hoeft te maken. Bestandsshares ondersteunen alleen het aanbevolen ingerichte v2-model en ondersteunen alleen de SSD-medialaag met het NFS-bestandssysteemprotocol. De Microsoft.FileShares resourceprovider biedt bestandsshares als resource van het hoogste niveau.

Opslageenheden

Azure Files maakt gebruik van de maateenheden base-2 om de opslagcapaciteit te vertegenwoordigen: KiB, MiB, GiB en TiB.

De meeste besturingssystemen en hulpprogramma's gebruiken de maateenheden basis 2 om opslaghoeveelheden te meten. Deze eenheden worden echter vaak verkeerd gelabeld als de basis-10 eenheden, die u mogelijk beter kent: KB, MB, GB en TB. Veel besturingssystemen duiden de opslageenheden onjuist aan, omdat zij deze acroniemen al gebruikten voordat de International Electrotechnical Commission (IEC), het International Bureau of Weights and Measures (BIPM) en het US National Institute of Standards and Technology (NIST) deze hadden gestandaardiseerd.

In de volgende tabel ziet u hoe algemene besturingssystemen opslag meten en labelen:

Als uw besturingssysteem niet wordt vermeld, neemt u contact op met de leverancier van het besturingssysteem.

Controlelijst voor totale eigendomskosten voor bestandsshares

Als u van on-premises naar Azure Files migreert of Azure Files vergelijkt met andere cloudopslag, moet u rekening houden met de volgende factoren om een eerlijke en gelijkwaardige vergelijking te garanderen:

• Hoe betaalt u voor opslag, IOPS en bandbreedte? De meeste cloudoplossingen hebben modellen die zijn afgestemd op de principes van ingerichte opslag, zoals prijsdeterminisme en eenvoud, of opslag met betalen per gebruik, die kosten kan optimaliseren door alleen kosten in rekening te brengen voor wat u daadwerkelijk gebruikt. Voorzieningsfactureringsmodellen kunnen verschillen op basis van de minimale voorzieningsdeelsgrootte, de provisioneringseenheid en de mogelijkheid om de voorziening te vergroten en te verkleinen.

• Zijn er methoden om de opslagkosten te optimaliseren? U kunt Azure Files-reserveringen gebruiken om maximaal 36% korting op opslag te krijgen. Andere oplossingen kunnen gebruikmaken van strategieën zoals ontdubbeling of compressie om de opslagefficiëntie optioneel te optimaliseren. Deze strategieën voor opslagoptimalisatie hebben echter vaak niet-monetaire kosten, zoals het verminderen van de prestaties. Azure Files-reserveringen hebben geen neveneffecten op prestaties.

• Hoe bereikt u opslagtolerantie en redundantie? Met Azure Files worden tolerantie en redundantie van opslag opgenomen in het productaanbod. Alle lagen en redundantieniveaus zorgen ervoor dat gegevens maximaal beschikbaar zijn en ten minste drie kopieën van uw gegevens toegankelijk zijn. Overweeg bij het overwegen van andere opties voor bestandsopslag of opslagtolerantie en redundantie is ingebouwd, of iets dat u zelf moet samenstellen.

• Wat moet u beheren? Azure Files is een volledig beheerde oplossing. Andere oplossingen vereisen mogelijk besturingssysteemupdates of het beheren van virtuele resources, zoals VM's, schijven en netwerk-IP-adressen.

• Wat zijn de kosten van toegevoegde waardeproducten? Azure Files biedt ondersteuning voor integraties met meerdere eerst- en externe services met toegevoegde waarde. Services met toegevoegde waarde, zoals Azure Backup, Azure File Sync en Microsoft Defender for Storage, bieden back-ups, replicatie en caching en beveiligingsfunctionaliteit voor Azure Files. Oplossingen met toegevoegde waarde, on-premises of in de cloud, hebben hun eigen licentie- en productkosten, maar worden vaak beschouwd als onderdeel van de totale eigendomskosten voor bestandsopslag.

Geprovisioneerd v2-model

Het ingerichte v2-model voor Azure Files combineert voorspelbaarheid van de totale eigendomskosten met flexibiliteit, waardoor u een bestandsshare kunt creëren die aan uw exacte opslag- en prestatievereisten voldoet. Wanneer u een nieuwe ingerichte v2-bestandsshare maakt, geeft u op hoeveel opslagruimte, IOPS en doorvoer uw bestandsshare nodig heeft. Het aantal van elke hoeveelheid die u bestelt, bepaalt uw totale factuur.

De hoeveelheid opslag, IOPS en doorvoer die u inricht, zijn de gegarandeerde limieten voor het gebruik van uw bestandsshare. Als u bijvoorbeeld een 2 TiB-share inricht en 2 TiB aan gegevens uploadt naar uw share, is uw share vol. U kunt geen meer gegevens toevoegen, tenzij u de grootte van uw share vergroot of een deel van de gegevens verwijdert. IOPS-bursting op basis van tegoed zorgt voor extra flexibiliteit in gebruik, op een best-effort basis, zolang er tegoeden zijn.

U kunt de hoeveelheid opslagruimte, IOPS en doorvoer die u inricht, dynamisch omhoog of omlaag schalen naarmate uw behoeften veranderen. U kunt echter alleen een ingerichte hoeveelheid verlagen nadat 24 uur is verstreken sinds de laatste toename van de hoeveelheid. Wijzigingen in opslag, IOPS en doorvoer worden binnen enkele minuten na een inrichtingswijziging doorgevoerd.

Wanneer u een nieuwe bestandsshare maakt met behulp van het ingerichte v2-model, biedt het systeem standaard een aanbeveling voor het aantal IOPS en hoeveel doorvoer u nodig hebt. Deze aanbeveling wordt berekend op basis van de hoeveelheid ingerichte opslag die u opgeeft. Deze aanbevelingen zijn gebaseerd op typisch klantgebruik voor die hoeveelheid ingerichte opslag voor de medialaag die u kiest. Het kan echter zijn dat uw workload meer of minder IOPS en doorvoer vereist dan de 'typische bestandsshare'. In dit geval kunt u desgewenst meer of minder IOPS en doorvoer inrichten, afhankelijk van de vereisten voor uw afzonderlijke bestandsshares.

Voorziening van v2 beschikbaarheid

Het ingerichte v2-model is beschikbaar voor de volgende combinaties van medialaag, redundantie en protocol voor het delen van bestanden:

Medialeigang	Redundantie	Protocol voor het delen van bestanden	Klassieke bestandsdeling (Microsoft.Storage)	Gedeelde bestanden (Microsoft.FileShares)
Solid State Drive (SSD)	Local	KMO
Solid State Drive (SSD)	Zone	KMO
Solid State Drive (SSD)	Local	NFS (Netwerkbestandssysteem)
Solid State Drive (SSD)	Zone	NFS (Netwerkbestandssysteem)
HDD	Local	KMO
HDD	Zone	KMO
HDD	Geo	KMO
HDD	GeoZone	KMO
HDD	Local	NFS (Netwerkbestandssysteem)
HDD	Zone	NFS (Netwerkbestandssysteem)
HDD	Geo	NFS (Netwerkbestandssysteem)
HDD	GeoZone	NFS (Netwerkbestandssysteem)

Het ingerichte v2-model is algemeen beschikbaar in alle openbare Azure-cloudregio's en alle Azure US Government-cloudregio's. Niet alle regio's ondersteunen alle medialagen en redundantieopties.

Ingericht v2-voorziening

Wanneer u een ingerichte v2-bestandsshare maakt, geeft u de ingerichte capaciteit voor de bestandsshare op in termen van opslag, IOPS en doorvoer. Bestandsshares kennen limieten op basis van de volgende eigenschappen:

Standaard biedt Azure Files aanbevelingen voor IOPS en doorvoerinrichting op basis van de ingerichte opslag die u opgeeft. Deze aanbevelingsformules zijn gebaseerd op typisch klantgebruik voor die hoeveelheid ingerichte opslag voor die medialaag in Azure Files:

Afhankelijk van de vereisten voor uw afzonderlijke bestandsshares hebt u mogelijk meer of minder IOPS of doorvoer nodig dan de aanbevelingen. U kunt deze aanbevelingen desgewenst overschrijven met uw eigen waarden.

Geconfigureerde v2 IOPS en doorvoerbegrenzingen (limieten)

Het inrichten van veiligheidsmaatregelen helpt u te beschermen tegen onnodige kosten door IOPS en doorvoer evenredig te houden met uw ingerichte opslag, terwijl u de mogelijkheid kunt behouden om de standaard-IOPS- en doorvoeraanbevelingen te overschrijven. Elke dimensie wordt beperkt tot 5× de aanbevolen waarde voor de hoeveelheid opslagruimte die u inricht en u kunt deze beperken tot het minimum dat is toegestaan voor uw medialaag. Het systeem evalueert IOPS en doorvoerbeveiligingen onafhankelijk van hun respectieve aanbevelingsformules. Als een inrichtingsaanvraag een beveiligingsgrens overschrijdt, kunt u de geconfigureerde opslag vergroten om de limiet te verhogen en hogere IOPS of doorvoer te ontgrendelen.

Een 32 GiB SSD-share heeft bijvoorbeeld een aanbevolen IOPS van 3032, dus de maximale IOPS die u op die share kunt inrichten, is 5 × 3.032 = 15.160. Als u de geprovisioneerde opslag verhoogt, nemen de aanbevolen IOPS en doorvoercapaciteit toe, en daarmee ook de guardrail-limiet, wat betekent dat u meer IOPS of doorvoercapaciteit kunt provisioneren. Kaders zijn van toepassing op zowel SSD als HDD.

In de volgende tabel ziet u de maximale IOPS en doorvoer die u kunt inrichten voor verschillende ingerichte opslagbedragen:

Aandelen die vóór de introductie van veiligheidsmaatregelen zijn ingericht en de vijfvoudige limiet overschrijden, blijven normaal functioneren. Wanneer u een ingerichte hoeveelheid voor een dergelijke share wijzigt, kan de verhouding van ingerichte IOPS of doorvoer naar de aanbevolen waarde ongewijzigd blijven of afnemen, maar niet toenemen. Als een share momenteel bijvoorbeeld IOPS heeft ingesteld op 7× de aanbeveling, kunt u deze verlagen tot 6× maar niet verhogen naar 7,1×. Zodra de share 5× bereikt of lager is dan, is de standaardbescherming van toepassing.

Geconfigureerde v2-bursting

IOPS-bursting op basis van krediet biedt extra flexibiliteit bij IOPS-gebruik. Gebruik deze flexibiliteit als buffer tegen onverwachte IO-pieken. Voor bestaande IO-patronen houdt u rekening met IO-pieken.

Burst IOPS-tegoed wordt verzameld wanneer het verkeer voor uw bestandsdeling lager is dan de ingerichte IOPS (basislijn). Wanneer het IOPS-gebruik van een bestandsshare groter is dan de ingerichte IOPS en er beschikbaar IOPS-tegoeden voor bursts beschikbaar zijn, kan de bestandsshare maximaal de maximaal toegestane burst IOPS-limiet bereiken. Bestandsshares kunnen blijven pieken zolang er nog tegoeden over zijn, gebaseerd op het aantal opgebouwde piek-tegoeden. Elke IO buiten de voorziene IOPS verbruikt één tegoed. Zodra alle tegoeden zijn verbruikt, keert de share terug naar de ingerichte IOPS. IOPS voor de bestandsshare hoeven niets speciaals te doen om bursting te gebruiken. Bursting werkt op basis van best effort.

Deelkredieten hebben drie staten:

• Opbouwen wanneer de bestandsshare minder dan de ingerichte IOPS gebruikt.
• Aflopend, wanneer de bestandsshare meer gebruikt dan de ingerichte IOPS en in de burst-modus.
• Constant, wanneer de bestandsdeling precies de toegewezen IOPS gebruikt en er geen tegoeden zijn opgebouwd of verbruikt.

Een nieuwe bestandsshare begint met het volledige aantal tegoeden in de zogenaamde "burst-bucket". Burst-tegoeden worden niet opgebouwd als de share-IOPS onder de geprovisioneerde limiet vallen vanwege throttling door de server. De volgende formules worden gebruikt om de burst IOPS-limiet en het aantal tegoeden dat mogelijk is voor een bestandsshare te bepalen:

In de volgende tabel ziet u enkele voorbeelden van deze formules voor verschillende ingerichte IOPS-bedragen:

Ingerichte v2-resourcemodellen

Het ingerichte v2-factureringsmodel is beschikbaar voor beide resourcetypen die worden gebruikt door Azure Files. U kunt een ingerichte v2-bestandsshare maken als een klassieke bestandsshare binnen een opslagaccount (Microsoft.Storage) of rechtstreeks als bestandsshare op het hoogste niveau (Microsoft.FileShares).

Ingerichte v2 klassieke bestandsshares (Microsoft.Storage)

Als u een klassieke bestandsshare wilt maken met het ingerichte v2-model, moet uw opslagaccount een van de volgende combinaties van instellingen gebruiken:

Zie Een klassieke bestandsshare maken voor meer informatie over het maken van een klassieke bestandsshare met behulp van het ingerichte v2-model.

Klassieke bestandsdelingen die in dezelfde opslagaccount zijn gemaakt, delen de limieten voor opslag, IOPS en doorvoer van dat opslagaccount.

Als u Azure Files wilt implementeren met het ingerichte v2-factureringsmodel op klassieke bestandsshares, moet u rekening houden met de volgende dimensies van capaciteitsplanning:

• Hoeveel ingerichte opslag, IOPS en doorvoer hebt u nodig voor elke klassieke bestandsshare? Hoe veranderen deze vereisten na verloop van tijd?
  Omdat opslagaccounts gedeelde limieten hebben wanneer u klassieke bestandsshares toewijst aan opslagaccounts, moet u rekening houden met de behoeften van elke klassieke bestandsshare, zowel nu als na verloop van tijd. De inrichtingslogica voor het ingerichte v2-model voorkomt dat u meer opslag, IOPS of doorvoer inricht dan het opslagaccount ondersteunt. Als er voldoende klassieke bestandsshares in één opslagaccount worden geplaatst, zodat een van deze dimensies maximaal is, kunnen bestaande klassieke bestandsshares niet groeien zonder eerst naar een ander opslagaccount te migreren. Om dit risico te verminderen, moet u voldoende ruimte plannen in elk opslagaccount, zodat u de koppelingen van klassieke bestandsshares aan opslagaccounts ten minste 3 tot 5 jaar kunt behouden.

• Hebt u speciale vereisten met betrekking tot het bijhouden van de factuur voor elke klassieke bestandsdeling voor afzonderlijke projecten, afdelingen of klanten?
  In Azure is de laagste granulariteit waarvoor u facturering kunt zien de resource, wat betekent dat als u twee klassieke bestandsshares in hetzelfde opslagaccount plaatst, u de kosten niet eenvoudig kunt bijhouden naar afzonderlijke projecten, afdelingen of klanten. Om dit op te lossen, moet u klassieke bestandsshares groeperen in opslagaccounts op basis van hoe ze moeten worden bijgehouden vanuit factureringsperspectief.

• Hoeveel opslagaccounts zijn er beschikbaar in uw abonnement voor uw doelregio?
  Een extra complicerende factor is het aantal opslagaccounts dat u kunt hebben per regio per abonnement. Zie Microsoft.Storage limieten voor besturingsvlak voor meer informatie. Afhankelijk van het aantal opslagaccounts dat u nodig hebt, moet u mogelijk extra abonnementen gebruiken om extra opslagaccounts te maken.

Geconfigureerde v2-bestandsshares (Microsoft.FileShares)

Het maken van bestandsshares met behulp van het beheermodel maakt het Microsoft.FileShares implementeren van Azure Files aanzienlijk eenvoudiger:

• U hoeft niet na te denken over de huidige en toekomstige behoeften van elke bestandsshare om te bepalen waar die bestandsshare moet worden geïmplementeerd.
  De inrichting van elke bestandsshare is onafhankelijk van de inrichting van elke andere bestandsshare. De enige overweging over de groei van de bestandsshare zijn de limieten voor de bestandsshare, die worden beschreven in provisioned V2-inrichting.

• De factuur voor elke bestandsshare wordt onafhankelijk bijgehouden.
  Omdat bestandsshares die zijn gemaakt met de resourceprovider Microsoft.FileShares resources op het hoogste niveau zijn, kunt u de factuur voor elke bestandsshare onafhankelijk van elke andere bestandsshare bijhouden. U kunt tags ook gebruiken om de resources eenvoudig te groeperen om de kosten voor projecten, afdelingen of klanten bij te houden.

• Hoewel bestandsshares nog steeds een limiet per abonnement per regio hebben, is de limiet van bestandsshares veel hoger dan de limiet van opslagaccounts.
  Zie limieten voor besturingsvlak voor meer informatieMicrosoft.FileShares.

Geconfigureerde v2-momentopnamen

Azure Files ondersteunt momentopnamen, die vergelijkbaar zijn met volumeschaduwkopieën (VSS) op Windows File Server. Voor meer informatie over momentopnamen van shares, zie Overzicht van momentopnamen voor Azure Files.

Momentopnamen verschillen altijd van de liveshare en van elkaar. Als in het ingerichte v2-factureringsmodel de totale differentiële grootte van alle momentopnamen binnen de overtollige ingerichte opslagruimte van de bestandsshare past, zijn er geen extra kosten verbonden aan de opslag van momentopnamen. Als de grootte van de live share-gegevens plus de differentiële momentopnamegegevens groter is dan de toegewezen opslag van de share, wordt de overtollige gebruikte capaciteit van de momentopnamen gefactureerd op basis van de Overflow Snapshot Usage meter. De formule voor het bepalen van de hoeveelheid overloop is: MAX((LiveShareUsedGiB + SnapshotDifferentialUsedGiB) - ProvisionedStorageGiB, 0)

Sommige services met toegevoegde waarde voor Azure Files maken gebruik van momentopnamen als onderdeel van hun waardepropositie. Zie services met toegevoegde waarde voor Azure Files voor meer informatie.

"Geconfigureerd v2 soft delete"

Wanneer u voorlopig verwijderen inschakelt, factureert het systeem verwijderde bestandsshares op basis van hun gebruikte opslagcapaciteit tijdens de retentieperiode. nl-NL: De toegekende opslag, IOPS en doorvoer van een verwijderde share blijven meetellen voor de limieten van het opslagaccount totdat de share is verwijderd, om herstel mogelijk te maken. Het systeem brengt deze resources echter niet in rekening. Zie Soft delete inschakelen voor Azure-bestandsshares voor details over het inschakelen van soft delete.

Geconfigureerde v2-factureringsmeters

Bestandsshares die zijn toegewezen met het v2-factureringsmodel, worden gefactureerd aan de hand van de volgende kostenmeters:

• Geconfigureerde opslag: de hoeveelheid opslag die is geconfigureerd in GiB.
• Ingerichte IOPS: de hoeveelheid IOPS (IO/sec) die is ingericht.
• Ingerichte doorvoer MiBPS: de hoeveelheid doorvoer die is ingericht in MiB per seconde.
• Overloopmomentopnamegebruik: elke hoeveelheid differentiële momentopnamegebruik in GiB die niet binnen de ingerichte opslagcapaciteit past. Zie geprovisioneerde v2-momentopnamen voor meer informatie.
• Zacht verwijderd gebruik: gebruikte opslagcapaciteit in GiB voor zacht verwijderde bestandsdeling. Zie voorwaarde v2 soft-delete voor meer informatie.

Het systeem registreert elk uur verbruikseenheden voor de ingerichte v2-factureringsmeters. Bijvoorbeeld, voor een share die is ingericht met 1.024 GiB ziet u het volgende:

• 1.024 eenheden tegen de geprovisioneerde opslag meter voor een individueel uur.
• 24,576 eenheden tegenover de ingerichte opslagmeter, indien geaggregeerd voor een dag.
• Een variabel aantal eenheden indien geaggregeerd voor een maand, afhankelijk van het aantal dagen in de maand:
  • 28-daagse maand (normaal februari): 688.128 eenheden ten opzichte van de geconfigureerde opslagmeter.
  • Maand van 29 dagen (schrikkeljaar februari): 712.704 eenheden ten opzichte van de geprovisioneerde opslagmeter.
  • Maand van 30 dagen: 737.280 eenheden tegen de Provisioned Storage-meter.
  • Maand van 31 dagen: 761.856 eenheden tegen de geprovisioneerde opslagmeter.

Ingeplaatste v2-migraties

Het proces voor het migreren van uw SMB Azure-bestandsshares van een betalen per gebruik-model naar het ingerichte v2-factureringsmodel verschilt, afhankelijk van of u Azure File Sync gebruikt.

• Als u Azure Files zonder Azure File Sync gebruikt, raadpleegt u bestanden migreren van de ene SMB Azure-bestandsshare naar de andere.
• Indien u Azure File Sync gebruikt, raadpleeg Bestanden migreren van de ene Azure-bestandsshare naar de andere.

Geconfigureerd v1 model

De ingerichte v1-methode biedt opslag, IOPS en doorvoer in een vaste verhouding tot elkaar, vergelijkbaar met de manier waarop opslag wordt aangeschaft in een on-premises opslagoplossing. Wanneer u een nieuwe ingerichte v1 klassieke bestandsshare maakt, geeft u op hoeveel opslagruimte uw share nodig heeft en worden de IOPS- en doorvoerwaarden berekend. Het ingerichte v1-model voor Azure Files is alleen beschikbaar voor de SSD-medialaag.

De hoeveelheid opslagruimte die u inricht, bepaalt de gegarandeerde opslag-, IOPS- en doorvoerlimieten van het gebruik van uw klassieke bestandsshare. Als u bijvoorbeeld een 2 TiB-share inricht en 2 TiB aan gegevens uploadt naar uw klassieke bestandsshare, is deze vol. U kunt alleen meer gegevens toevoegen als u de grootte van de klassieke bestandsshare vergroot of een deel van de gegevens verwijdert. IOPS-bursting op basis van tegoed zorgt voor extra flexibiliteit in gebruik, op een best-effort basis, zolang er tegoeden zijn.

In tegenstelling tot het kopen van opslag on-premises, kunt u de ingerichte klassieke v1-bestandsshares dynamisch omhoog of omlaag schalen naarmate uw behoeften veranderen. U kunt de ingerichte opslag echter pas na 24 uur verlagen sinds de laatste opslagtoename. Wijzigingen in opslag, IOPS en doorvoer worden binnen een paar minuten na een inrichtingswijziging doorgevoerd.

U kunt de grootte van uw toegewezen bestandsshare verkleinen tot onder het aantal GiB dat u gebruikt. Als u dit wel doet, verliest u geen gegevens, maar wordt u nog steeds gefactureerd voor de gebruikte grootte. U krijgt de prestaties van de geconfigureerde share, niet van de gebruikte grootte.

Geconfigureerde v1-beschikbaarheid

Het ingerichte v1-model is beschikbaar voor de volgende combinaties van medialaag, redundantie en protocol voor het delen van bestanden:

Medialeigang	Redundantie	Protocol voor het delen van bestanden	Klassieke bestandsdeling (Microsoft.Storage)	Gedeelde bestanden (Microsoft.FileShares)
Solid State Drive (SSD)	Local	KMO
Solid State Drive (SSD)	Zone	KMO
Solid State Drive (SSD)	Local	NFS (Netwerkbestandssysteem)
Solid State Drive (SSD)	Zone	NFS (Netwerkbestandssysteem)
HDD	Local	KMO
HDD	Zone	KMO
HDD	Geo	KMO
HDD	GeoZone	KMO
HDD	Local	NFS (Netwerkbestandssysteem)
HDD	Zone	NFS (Netwerkbestandssysteem)
HDD	Geo	NFS (Netwerkbestandssysteem)
HDD	GeoZone	NFS (Netwerkbestandssysteem)

Klassieke SSD-bestandsshares met behulp van het ingerichte v1-model zijn algemeen beschikbaar in de meeste Azure-regio's. Zie Azure-producten per regio voor meer informatie.

Details van v1-voorziening

Wanneer u een ingerichte v1 klassieke bestandsshare maakt, geeft u op hoeveel opslagruimte uw share nodig heeft. Elke GiB die u configureert, geeft u recht op meer IOPS en doorvoer in een vaste verhouding. Ingerichte v1 klassieke bestandsdelingen zijn beperkt op basis van de volgende kenmerken:

De volgende formules bepalen de hoeveelheid IOPS en doorvoer die voor de share is ingericht:

Afhankelijk van de vereiste voor een afzonderlijke klassieke bestandsshare, is het mogelijk dat u meer IOPS of doorvoer nodig hebt dan de inrichtingsformules bieden. In dit geval moet u meer opslagruimte inrichten om de vereiste IOPS of doorvoer op te halen.

Ingerichte v1-burstcapaciteit

Het ingerichte v1-model ondersteunt twee typen bursting: op krediet gebaseerde bursting, die gratis is opgenomen als onderdeel van de inrichting en betaalde bursting. Dit is een geavanceerde functie die u optioneel kunt inschakelen om facturering op basis van gebruik te ondersteunen wanneer de IOPS en doorvoer het ingerichte bedrag overschrijden.

Geconfigureerd v1-bursting op kredietbasis

IOPS-bursting op basis van krediet biedt extra flexibiliteit bij IOPS-gebruik. Gebruik deze flexibiliteit als buffer tegen onverwachte IO-pieken. Voor bestaande IO-patronen houdt u rekening met IO-pieken.

Burst IOPS-tegoed wordt verzameld wanneer het verkeer voor uw klassieke file share lager is dan de geprovisioneerde IOPS (basislijn). Wanneer het IOPS-gebruik van een klassieke bestandsshare groter is dan de ingerichte IOPS en er beschikbare burst-IOPS-tegoeden beschikbaar zijn, kan de klassieke bestandsshare maximaal de maximaal toegestane burst IOPS-limiet bereiken. Klassieke bestandsshares kunnen blijven bursten zolang er nog tegoeden zijn, op basis van het aantal opgebouwde burst-tegoeden. Elke IO buiten de voorziene IOPS verbruikt één tegoed. Zodra alle tegoeden zijn verbruikt, keert de klassieke bestandsshare terug naar de ingerichte IOPS. IOPS voor de klassieke bestandsshare hoeft niets speciaals te doen om bursting te gebruiken. Bursting werkt op basis van best effort.

Deelkredieten hebben drie staten:

• Oplopend, wanneer de klassieke bestandsshare minder gebruikmaakt dan de ingerichte IOPS.
• Aflopend, wanneer de klassieke bestandsshare meer gebruikt dan de ingerichte IOPS en in de bursting-modus.
• Constant, wanneer de klassieke bestandsshare exact gebruikmaakt van de ingerichte IOPS en er geen tegoed is opgebouwd of gebruikt.

Een nieuwe klassieke bestandsshare begint met het volledige aantal tegoeden in de burst-bucket. Burst-tegoeden worden niet opgebouwd als de share-IOPS onder de geprovisioneerde limiet vallen vanwege throttling door de server. De volgende formules worden gebruikt om de burst IOPS-limiet en het aantal tegoeden dat mogelijk is voor een klassieke bestandsshare te bepalen:

In de volgende tabel ziet u enkele voorbeelden van deze formules voor de ingerichte grootten:

Betaalde v1 capaciteitsuitbreiding ingericht

Betaalde bursting is een geavanceerde functie van het voorgeconfigureerde v1-model, ontworpen om klanten te ondersteunen die nooit willen worden vertraagd. Betaalde burst-facturering voegt extra gebruiksfacturering toe voor IOPS of doorvoer boven de toegewezen opslag. Deze functie verschilt van creditgebaseerde bursting, dat gratis is inbegrepen als onderdeel van ingerichte opslagcapaciteit. Hoewel betaalde bursting krachtige flexibiliteit kan bieden voor het inrichten van uw klassieke bestandsshare, kan dit ook leiden tot onverwachte facturering als deze onjuist wordt gebruikt.

Net als bij bursting op basis van tegoed is betaalde bursting geen vervanging voor het inrichten van de juiste hoeveelheid IOPS en doorvoer. In plaats daarvan biedt het verdere bescherming tegen beperking als u onverwachte vraag krijgt. Als u een consistent IOPS- of doorvoergebruik hebt, is het goedkoper om voldoende IOPS en doorvoer (via opslaginrichting) in te richten om de vraag te dekken in plaats van te vertrouwen op betaalde bursting.

Bursting tegen betaling is standaard uitgeschakeld, maar u kunt dit inschakelen door de instructies te volgen voor het wijzigen van de kosten- en prestatiekenmerken van een geprovisioneerde klassieke v1-bestandsshare (alleen PowerShell en CLI). Als u betaalde bursting inschakelt, controleert u het IOPS- en doorvoergebruik met behulp van de volgende metrische gegevens die beschikbaar zijn via Azure Monitor:

• Geprovisioneerde IOPS voor bestandsdeling
• MiB/s voor geconfigureerde bandbreedte van bestandsdeling (doorvoer)
• Transacties per max. IOPS
• Bandbreedte per maximaal MiB/s (doorvoer)
• Burst-tegoed voor IOPS (bursting op basis van tegoed)
• Betaalde Bursting IOS (IOs)
• Betaalde piekbandbreedte

Voorziene v1-resourcemodellen

U kunt een aangemaakte v1-bestandsshare alleen maken als een klassieke bestandsshare binnen een opslagaccount (Microsoft.Storage).

Ingerichte v1 klassiek bestandsdeling (Microsoft.Storage)

Als u een klassieke bestandsshare wilt maken met het ingerichte v1-model, moet uw opslagaccount een van de volgende combinaties van instellingen gebruiken:

Zie Een klassieke bestandsshare maken voor meer informatie over het maken van een klassieke bestandsshare met behulp van het ingerichte v1-model.

Klassieke bestandsdelingen die in dezelfde opslagaccount zijn gemaakt, delen de limieten voor opslag, IOPS en doorvoer van dat opslagaccount.

Als u Azure Files correct wilt implementeren met het ingerichte v1-factureringsmodel op klassieke bestandsshares, moet u rekening houden met de volgende dimensies van capaciteitsplanning:

• Hoeveel ingerichte opslag, IOPS en doorvoer hebt u nodig voor elke klassieke bestandsshare? Hoe veranderen deze vereisten na verloop van tijd?
  Vanwege de gedeelde limieten van opslagaccounts moet u, wanneer u klassieke bestandsshares aan opslagaccounts toewijst, rekening houden met de behoeften van elke klassieke bestandsshare, zowel nu als in de loop van de tijd. De inrichtingslogica voor het ingerichte v1-model voorkomt dat u meer opslag inricht dan het opslagaccount ondersteunt. Hoewel u meer IOPS en doorvoer kunt inrichten dan het opslagaccount biedt, kunt u niet meer gebruiken dan de limieten van het opslagaccount voor IOPS en doorvoer. Om onverwachte beperking te voorkomen, moet u niet meer IOPS of doorvoer toewijzen dan het opslagaccount ondersteunt.

  Bovendien kan het plaatsen van te veel klassieke bestandsshares in een opslagaccount toekomstige groei beperken. Zodra een opslagaccount vol is, kunt u bestaande klassieke bestandsshares niet uitbreiden zonder eerst een aantal naar een ander opslagaccount te migreren. Om dit risico te beperken, moet u in uw opslagaccounts voldoende extra capaciteit aanhouden, zodat u de toewijzingen van klassieke bestandsshares aan opslagaccounts gedurende minstens drie tot vijf jaar kunt handhaven.

• Hebt u speciale vereisten met betrekking tot het bijhouden van de factuur voor elke klassieke bestandsdeling voor afzonderlijke projecten, afdelingen of klanten?
  In Azure is de laagste granulariteit waarvoor u facturering kunt zien de resource, wat betekent dat als u twee klassieke bestandsshares in hetzelfde opslagaccount plaatst, u de kosten niet eenvoudig kunt bijhouden naar afzonderlijke projecten, afdelingen of klanten. U kunt dit probleem oplossen door klassieke bestandsshares te groeperen in opslagaccounts op basis van hoe ze vanuit factureringsperspectief moeten worden bijgehouden.

• Hoeveel opslagaccounts zijn er beschikbaar in uw abonnement voor uw doelregio?
  Een extra complicerende factor is het aantal opslagaccounts dat u kunt hebben per regio per abonnement. Zie Microsoft.Storage limieten voor besturingsvlak voor meer informatie. Afhankelijk van het aantal opslagaccounts dat u nodig hebt, moet u mogelijk extra abonnementen gebruiken om extra opslagaccounts te bereiken.

Voorzien van v1-momentopnamen

Azure Files ondersteunt momentopnamen, die vergelijkbaar zijn met volumeschaduwkopieën (VSS) op Windows File Server. Voor meer informatie over momentopnamen van shares, zie Overzicht van momentopnamen voor Azure Files.

Momentopnamen verschillen altijd van de liveshare en van elkaar. In het ingerichte v1-factureringsmodel wordt de totale differentiële grootte gefactureerd op basis van een gebruiksmeter, ongeacht hoeveel ingerichte opslag niet wordt gebruikt. De gebruikte opslagmeter voor momentopnamen heeft een lagere prijs dan de ingerichte opslagprijs.

Voorzien van v1 soft delete

Verwijderde klassieke bestandsshares in opslagaccounts waarvoor voorlopig verwijderen is ingeschakeld, worden gefactureerd op basis van de gebruikte opslagcapaciteit van de verwijderde share voor de gedefinieerde bewaarperiode. De zacht verwijderde gebruiksopslagcapaciteit wordt tegenover de gebruikte opslagmeter voor momentopnamen geplaatst. Zie Voorlopig verwijderen inschakelen voor Azure-bestandsshares voor meer informatie over voorlopig verwijderen.

Geconfigureerde v1-facturatiemeters

Klassieke bestandsshares die zijn ingericht met het ingerichte v1-factureringsmodel, worden gefactureerd op basis van de volgende meters:

• Premium geconfigureerd: de hoeveelheid opslagruimte die is geconfigureerd in GiB.
• Premium-momentopnamen: het aantal gebruikte momentopnamen en de gebruikte tijdelijk verwijderde capaciteit.

Verbruik op basis van de ingerichte v1-factureringsmeters wordt elk uur verzonden in termen van maandelijkse eenheden. Bijvoorbeeld, voor een share die is ingericht met 1.024 GiB ziet u het volgende:

• Een variabel aantal eenheden voor een afzonderlijk uur, afhankelijk van het aantal dagen in de maand:
  • Maand van 28 dagen (normaal februari): 1,5238 eenheden ten opzichte van de voorgeconfigureerde Premium-meter.
  • Maand van 29 dagen (schrikkeljaar februari): 1.4713 eenheden ten opzichte van de Premium Provisioned-meter.
  • Maand van 30 dagen: 1.4222 eenheden tegen de geconfigureerde Premium-meter.
  • Maand van 31 dagen: 1.3763 eenheden ten opzichte van de Premium Geconfigureerde meter.
• Een variabel aantal eenheden indien geaggregeerd voor een dag, afhankelijk van het aantal dagen in de maand:
  • Maand van 28 dagen (normaal februari): 36.5714 eenheden bij de Premium Provisioned-meter.
  • Maand van 29 dagen (schrikkeljaar februari): 35,3103 eenheden ten opzichte van de Premium-geconfigureerde meter.
  • Maand van 30 dagen: 34.1333 eenheden voor de Premium Provisioned meter.
  • Maand van 31 dagen: 33,0323 eenheden tegen de Premium Provisioned-meter.
• 1.024 eenheden tegen de Premium-geprovisioneerde meter als ze voor een maand worden geaggregeerd.

Model voor betalen per gebruik

In het model betalen per gebruik wordt u gefactureerd voor hoeveel opslagruimte u gebruikt, niet hoeveel u inricht. Op hoog niveau betaalt u kosten voor de hoeveelheid logische gegevens die zijn opgeslagen en worden er ook kosten in rekening gebracht voor transacties op basis van uw gebruik van die gegevens. Facturering per gebruik kan lastig zijn om te plannen als onderdeel van een budgetteringsproces, omdat u betaalt op basis van verbruik door eindgebruikers. Gebruik het ingerichte v2-model voor nieuwe klassieke bestandsshareimplementaties. Het pay-as-you-go-model is alleen beschikbaar voor HDD-opslag.

Beschikbaarheid van pay-as-you-go

Het model voor betalen per gebruik is beschikbaar voor de volgende combinaties van medialaag, redundantie en protocol voor het delen van bestanden:

Medialeigang	Redundantie	Protocol voor het delen van bestanden	Klassieke bestandsdeling (Microsoft.Storage)	Gedeelde bestanden (Microsoft.FileShares)
Solid State Drive (SSD)	Local	KMO
Solid State Drive (SSD)	Zone	KMO
Solid State Drive (SSD)	Local	NFS (Netwerkbestandssysteem)
Solid State Drive (SSD)	Zone	NFS (Netwerkbestandssysteem)
HDD	Local	KMO
HDD	Zone	KMO
HDD	Geo	KMO
HDD	GeoZone	KMO
HDD	Local	NFS (Netwerkbestandssysteem)
HDD	Zone	NFS (Netwerkbestandssysteem)
HDD	Geo	NFS (Netwerkbestandssysteem)
HDD	GeoZone	NFS (Netwerkbestandssysteem)

Klassieke HDD-bestandsshares die gebruikmaken van het model betalen per gebruik zijn algemeen beschikbaar in alle Azure regio's.

Verschillen in toegangsniveaus

Wanneer u een klassieke bestandsshare maakt in een opslagaccount met betalen naar gebruik, kiest u uit de volgende toegangsniveaus: voor transacties geoptimaliseerd, hot en cool. Alle drie de toegangslagen gebruiken dezelfde opslaghardware. Het belangrijkste verschil tussen deze toegangslagen zijn de prijzen voor opslag van gegevens in rust, die lager zijn in koudere lagen, en de transactieprijzen, die hoger zijn in de koudere lagen. Deze prijsstructuur betekent:

• Transactie geoptimaliseerd, zoals de naam al aangeeft, optimaliseert de prijs voor transactieworkloads met hoge IOPS (input/output bewerkingen per seconde). Transactie-geoptimaliseerd heeft de hoogste opslagprijs voor gegevens in rust, maar de laagste transactieprijzen.
• Hot is bedoeld voor actieve workloads die geen groot aantal transacties omvatten. Het heeft een iets lagere prijs voor opgeslagen data, maar iets hogere transactieprijzen in vergelijking met transactie-optimalisatie. U kunt het beschouwen als de gulden middenweg tussen de voor transacties geoptimaliseerde en koele lagen.
• Cool optimaliseert de prijs voor workloads die geen hoge activiteit hebben en biedt de laagste opslagprijs voor stilstaande gegevens, maar daar tegenover staan wel de hoogste transactieprijzen.

Als u de juiste toegangslaag voor uw use-case selecteert, kunt u uw kosten aanzienlijk verlagen. Als u een zelden benaderde workload in de transactie-geoptimaliseerde toegangslaag plaatst, betaalt u bijna niets voor de paar keer per maand dat u transacties uitvoert op uw klassieke bestandsshare. U betaalt echter een hoge hoeveelheid voor de kosten voor gegevensopslag. Als u diezelfde bestandsshare naar de coole toegangslaag verplaatst, bent u nog steeds bijna niets kwijt aan transactiekosten, simpelweg omdat er voor deze workload maar zelden transacties plaatsvinden. De koele toegangslaag heeft een lagere prijs voor gegevensopslag.

Als u een workload met hoge toegang in de koele toegangslaag plaatst, betaalt u veel meer transactiekosten, maar minder voor gegevensopslagkosten. Deze prijsstructuur kan leiden tot een situatie waarbij de verhoogde kosten van de transactieprijzen groter zijn dan de besparingen van de verlaagde prijs voor gegevensopslag. U betaalt mogelijk meer voor cool dan u zou hebben betaald voor transacties die zijn geoptimaliseerd. Voor sommige gebruiksniveaus is het mogelijk dat de warme toegangslaag het meest kostenefficiënt is en dat de koele toegangslaag duurder is dan de voor transacties geoptimaliseerde laag.

Uw workload- en activiteitsniveau bepalen de meest kostenefficiënte toegangslaag voor uw klassieke bestandsshare met betalen per gebruik. In de praktijk is de beste manier om de meest rendabele toegangslaag te kiezen, waarbij wordt gekeken naar het werkelijke resourceverbruik van de share (gegevens opgeslagen, schrijftransacties, enzovoort). Voor klassieke bestandsshares met betalen per gebruik begint u tijdens de eerste migratie naar Azure Files in de transactie geoptimaliseerde laag en kiest u vervolgens de juiste toegangslaag op basis van gebruik nadat de migratie is voltooid. Transactiegebruik tijdens de migratie wijst doorgaans niet op normaal transactiegebruik.

Wat zijn transacties?

Wanneer u een klassieke SMB-bestandsshare koppelt die gebruikmaakt van het model betalen per gebruik, ziet u de klassieke bestandsshare op uw computer alsof deze lokale opslag is. Dit betekent dat toepassingen, scripts en andere programma's op uw computer toegang hebben tot de bestanden en mappen op de klassieke bestandsshare zonder dat ze hoeven te weten dat ze zijn opgeslagen in Azure.

Wanneer u een bestand leest of schrijft, voert de toepassing die u gebruikt een reeks API-aanroepen uit naar de bestandssysteem-API die door uw besturingssysteem wordt geleverd. Uw besturingssysteem interpreteert deze aanroepen vervolgens in SMB-protocoltransacties, die via de wire naar Azure Files worden verzonden om te voldoen. Een eenvoudige taak die de eindgebruiker beschouwt als één bewerking, zoals het lezen van een bestand van begin tot eind, kan worden omgezet in meerdere SMB-transacties die worden geleverd door Azure Files.

Klassieke bestandsshares die gebruikmaken van het pay-as-you-go-model worden gefactureerd op basis van gebruik. SMB- en FileREST-transacties die zijn gemaakt door toepassingen en scripts vertegenwoordigen het gebruik van uw klassieke bestandsshare en worden weergegeven als onderdeel van uw factuur. Hetzelfde concept is van toepassing op cloudservices met toegevoegde waarde die u aan uw share kunt toevoegen, zoals Azure File Sync of Azure Backup.

Transacties worden gegroepeerd in vijf verschillende transactiecategorieën die verschillende prijzen hebben op basis van hun invloed op de klassieke bestandsshare. Deze categorieën zijn: schrijven, vermelden, lezen, andere en verwijderen.

In de volgende tabel ziet u de categorisatie van elke transactie:

Schakelen tussen toegangsniveaus

Hoewel u de toegangslaag van een klassieke bestandsshare kunt wijzigen die gebruikmaakt van het model betalen per gebruik, kunt u de kosten het beste optimaliseren na de eerste migratie door de meest kostenoptimale toegangslaag te kiezen en daar te blijven, tenzij uw toegangspatroon verandert. Als u de toegangslaag van een klassieke bestandsshare wijzigt, leidt dit als volgt tot extra kosten:

• Transacties: Wanneer u een share verplaatst van een dynamischere toegangslaag naar een koelere toegangslaag, worden de kosten voor schrijftransacties van de statischere toegangslaag in rekening gebracht voor elk bestand in de klassieke bestandsshare. Als u een klassieke bestandsshare verplaatst van een koelere toegangslaag naar een hetere toegangslaag, worden de leestransactiekosten van de koelere toegangslaag voor elk bestand in de klassieke bestandsshare in rekening gebracht.

• Gegevens ophalen: als u van de koele toegangslaag naar de dynamische of transaction optimized-toegangslaag overstapt, worden kosten voor het ophalen van gegevens in rekening gebracht op basis van de grootte van de verplaatste gegevens. Alleen de koel toegangslaag heeft opvraagkosten voor het ophalen van gegevens.

De volgende tabel illustreert de kostenanalyse van het verschuiven van toegangsniveaus.

U kunt de toegangslaag van een klassieke bestandsshare maximaal vijf keer binnen een periode van 30 dagen wijzigen. De eerste dag van het venster van 30 dagen begint wanneer de eerste laag wordt gewijzigd. Wijzigingen tussen toegangsniveaus gebeuren direct. Wanneer u echter de toegangslaag van een share wijzigt, kunt u deze niet meer binnen 24 uur wijzigen, zelfs niet als u de eigenschap van de toegangslaag minder dan vijf keer in de afgelopen 30 dagen hebt gewijzigd.

Een toegangslaag kiezen

Ongeacht hoe u bestaande gegevens migreert naar Azure Files, moet u in eerste instantie de klassieke bestandsshare maken in de voor transactie geoptimaliseerde toegangslaag. Bij de migratie wordt een groot aantal transacties in rekening gebracht. Nadat uw migratie is voltooid en u enkele dagen of weken werkt met regelmatig gebruik, sluit u het aantal transacties aan in de prijscalculator om te bepalen welke toegangslaag het meest geschikt is voor uw workload.

Omdat opslagaccounts met betaling per gebruik alleen transactiegegevens weergeven op het niveau van het opslagaccount, is het een onvolmaakte wetenschap om te schatten welk toegangsniveau goedkoper is voor klassieke bestandsshares. Implementeer indien mogelijk slechts één klassieke bestandsshare in elk opslagaccount om volledige zichtbaarheid van facturering te garanderen.

Vorige transacties bekijken:

1. Ga naar uw opslagaccount in de Azure-portal.
2. Selecteer in het servicemenu onder Bewaking de optie Metrische gegevens.
3. Selecteer Bereik als de naam van uw opslagaccount, metrische naamruimte als 'Bestand', Metrische waarde als 'Transacties' en Aggregatie als 'Som'.
4. Kies Splitsing toepassen.
5. Selecteer waarden als 'API-naam'. Selecteer de gewenste limiet en sorteerbewerking.
6. Selecteer de gewenste periode.

Resourcemodellen voor betalen per gebruik

U kunt een betalen per gebruik-bestandsshare alleen maken als een klassieke bestandsshare binnen een opslagaccount (Microsoft.Storage).

Klassieke bestandsshares voor betalen per gebruik (Microsoft.Storage)

Als u een klassieke bestandsshare wilt maken met het model betalen per gebruik, moet uw opslagaccount een van de volgende combinaties van instellingen gebruiken:

Klassieke bestandsdelingen die in dezelfde opslagaccount zijn gemaakt, delen de limieten voor opslag, IOPS en doorvoer van dat opslagaccount.

Zie limieten voor het gegevensvlak van het opslagaccount voor meer informatie, waaronder welke regio's ondersteuning bieden voor verhoogde limieten voor IOPS en doorvoer.

Als u Azure Files correct wilt implementeren met het factureringsmodel voor betalen per gebruik op klassieke bestandsshares, moet u rekening houden met de volgende dimensies van capaciteitsplanning:

• Hoeveel gebruikte opslag, IOPS en doorvoer hebt u nodig voor elke klassieke bestandsshare? Hoe veranderen deze vereisten na verloop van tijd?
  Vanwege de gedeelde limieten van opslagaccounts moet u, wanneer u klassieke bestandsshares aan opslagaccounts toewijst, rekening houden met de behoeften van elke klassieke bestandsshare, zowel nu als in de loop van de tijd. In tegenstelling tot de ingerichte v2- en ingerichte v1-modellen biedt het model betalen per gebruik enkele beveiligingen om u te helpen de limieten van het opslagaccount te delen tussen klassieke bestandsshares in hetzelfde opslagaccount. Elke klassieke bestandsdeling in een pay-as-you-go opslagaccount kan maximaal de limieten voor grootte van de klassieke bestandsdeling omvatten en tot de limieten voor IOPS en doorvoer van het opslagaccount. Als u twee klassieke bestandsshares in hetzelfde opslagaccount voor betalen per gebruik plaatst, kan dit leiden tot IOPS- of doorvoerconflicten. Om onverwachte snelheidsbeperkingen te voorkomen, beperkt u het aantal klassieke bestandsshares dat u plaatst in een opslagaccount met betalingen naar gebruik.

• Hebt u speciale vereisten met betrekking tot het bijhouden van de factuur voor elke klassieke bestandsdeling voor afzonderlijke projecten, afdelingen of klanten?
  In Azure is de laagste granulariteit waarvoor u facturering kunt zien de resource, wat betekent dat als u twee klassieke bestandsshares in hetzelfde opslagaccount plaatst, u de kosten niet eenvoudig kunt bijhouden naar afzonderlijke projecten, afdelingen of klanten. U kunt dit probleem oplossen door klassieke bestandsshares te groeperen in opslagaccounts op basis van hoe ze vanuit factureringsperspectief moeten worden bijgehouden.

• Hoeveel opslagaccounts zijn er beschikbaar in uw abonnement voor uw doelregio?
  Een extra complicerende factor is het aantal opslagaccounts dat u kunt hebben per regio per abonnement. Zie Microsoft.Storage limieten voor besturingsvlak voor meer informatie. Afhankelijk van het aantal opslagaccounts dat u nodig hebt, moet u mogelijk extra abonnementen gebruiken om extra opslagaccounts te bereiken.

Momentopnamen op basis van betalen per gebruik

Azure Files ondersteunt momentopnamen, die vergelijkbaar zijn met volumeschaduwkopieën (VSS) op Windows File Server. Voor meer informatie over momentopnamen van shares, zie Overzicht van momentopnamen voor Azure Files.

Momentopnamen verschillen altijd van de liveshare en van elkaar. In het pay-as-you-go-factureringsmodel wordt de totale differentiële omvang meegerekend in de normale meter voor gebruikt opslagvolume. Dit betekent dat u geen afzonderlijk regelitem op uw factuur ziet dat momentopnamen vertegenwoordigt voor uw opslagaccount voor betalen per gebruik. Dit differentiële momentopnamegebruik telt ook mee voor reserveringen die u koopt voor klassieke bestandsshares met betalen per gebruik.

Zacht verwijderen op basis van verbruik

Verwijderde klassieke bestandsshares in opslagaccounts waarvoor voorlopig verwijderen is ingeschakeld, worden gefactureerd op basis van de gebruikte opslagcapaciteit voor de gedefinieerde bewaarperiode. De voorlopig verwijderde gebruikte opslagcapaciteit telt mee voor de normale gebruikte opslagmeter. Dit betekent dat u op uw factuur geen aparte factuurregel ziet voor voorlopig verwijderde klassieke bestandsshares van uw opslagaccount op basis van betalen per gebruik. Dit voorlopig verwijderde klassieke bestandssharegebruik telt ook mee voor reserveringen die u koopt voor klassieke bestandsshares met betalen per gebruik.

Meters voor afrekening per gebruik

Klassieke bestandsshares die zijn gemaakt met het factureringsmodel betalen na gebruik, worden gefactureerd op basis van de volgende meterstanden:

• Opgeslagen gegevens: de gebruikte opslag, waaronder de liveshares, differentiële momentopnamen en voorlopig verwijderde klassieke bestandsshares, in gibibytes (GiB).
• Metagegevens: de grootte van de metagegevens van het bestandssysteem die zijn gekoppeld aan bestanden en mappen, zoals toegangsbeheerlijsten (ACL's) en andere eigenschappen, in GiB. Deze factureringsmeter geldt alleen voor klassieke bestandsshares in de warme of koele toegangslagen.
• Schrijfbewerkingen: het aantal buckets voor schrijftransacties (één bucket = 10.000 transacties).
• Lijstbewerkingen: het aantal buckets voor lijsttransacties (één bucket = 10.000 transacties).
• Leesbewerkingen: het aantal buckets voor leestransacties (één bucket = 10.000 transacties).
• Andere bewerkingen / Protocolbewerkingen: het aantal andere transactiebuckets (één bucket = 10.000 transacties).
• Gegevens ophalen: de hoeveelheid gegevens die is gelezen uit de klassieke bestandsshare in GiB. Deze meter geldt alleen voor klassieke bestandsshares in de coole toegangslaag.
• Geo-Replication gegevensoverdracht: Als de klassieke bestandsdeling de Geo- of GeoZone-redundantie heeft, wordt de hoeveelheid aan gegevens die naar de klassieke bestandsdeling is geschreven, gerepliceerd naar de secundaire regio in GiB.

De factureringsmeters Opgeslagen gegevens en Metagegevens geven elk uur verbruikseenheden door, uitgedrukt in maandelijkse eenheden. U ziet bijvoorbeeld voor een share met 1.024 gebruikte GiB:

• Een variabel aantal eenheden voor een afzonderlijk uur, afhankelijk van het aantal dagen in de maand:
  • Maand van 28 dagen (normaal februari): 1,5238 eenheden ten opzichte van de data stored meter.
  • Maand van 29 dagen (schrikkeljaar februari): 1.4713 eenheden ten opzichte van de data stored meter.
  • Maand van 30 dagen: 1.4222 eenheden ten opzichte van de data stored meter.
  • Maand van 31 dagen: 1.3763 eenheden ten opzichte van de data stored meter.
• Een variabel aantal eenheden indien geaggregeerd voor een dag, afhankelijk van het aantal dagen in de maand:
  • Maand van 28 dagen (normaal februari): 36.5714 eenheden ten opzichte van de data stored meter.
  • Maand van 29 dagen (schrikkeljaar februari): 35.3103 eenheden ten opzichte van de data stored meter.
  • Maand van 30 dagen: 34.1333 eenheden ten opzichte van de data stored meter.
  • Maand van 31 dagen: 33.0323 eenheden ten opzichte van de data stored meter.
• 1024 eenheden ten opzichte van de data stored meter indien geaggregeerd voor een maand.

De andere meters (bijvoorbeeld Schrijfbewerkingen of Gegevens ophalen) geven het verbruik per uur door. Omdat aan deze meters geen specifiek tijdsbestek is gekoppeld, zijn er geen speciale eenheidstransformaties vereist.

Ingerichte grootte of quotum, logische grootte en fysieke grootte

Azure Files houdt drie afzonderlijke hoeveelheden bij met betrekking tot het delen van capaciteit:

• Ingerichte grootte of quotum: Met zowel ingerichte als betalen per gebruik-bestandsshares geeft u de maximale grootte op waarmee de bestandsshare kan groeien. In ingegeven bestandsshares wordt deze waarde de ingegeven grootte genoemd. U betaalt voor de ingerichte grootte, ongeacht hoeveel u daadwerkelijk gebruikt. In bestandsshares met betalen per gebruik wordt deze waarde quotum genoemd en is deze niet rechtstreeks van invloed op uw factuur. De aangewezen grootte is een vereist veld voor bestandsdeling. Als u voor bestandsshares met betalen naar gebruik geen geprovisioneerde grootte opgeeft, wordt de bestandsshare standaard ingesteld op de maximale waarde die het opslagaccount ondersteunt (100 TiB).

• Logische grootte: de logische grootte van een bestandsshare of bestand heeft betrekking op hoe groot het is zonder rekening te houden met hoe het daadwerkelijk wordt opgeslagen, zonder opslagoptimalisatie. De logische grootte van het bestand is hoeveel KiB, MiB of GiB via de kabel worden overgedragen als u het naar een andere locatie hebt gekopieerd. Bij zowel ingereserveerde bestandsshares als bestandsshares met betalen naar gebruik wordt de totale logische grootte van de bestandsshare gebruikt voor de handhaving van de ingereserveerde capaciteit of het quotum. In bestandsdeling met betalen per gebruik is de logische grootte de hoeveelheid die wordt gebruikt voor de facturering van het gebruik van data in rusttoestand. Het dialoogvenster Windows eigenschappen voor een bestand of map verwijst naar logische grootte als 'grootte' en Azure Files metrische gegevens verwijzen ernaar als 'inhoudslengte'.

• Fysieke grootte: de fysieke grootte van het bestand heeft betrekking op de grootte van het bestand als gecodeerd op schijf. De fysieke grootte kan worden uitgelijnd met de logische grootte van het bestand of kan kleiner zijn, afhankelijk van hoe het besturingssysteem het bestand schrijft. Een veelvoorkomende reden waarom de logische grootte en fysieke grootte anders moeten zijn, is door gebruik te maken van sparse-bestanden. De fysieke grootte van de bestanden in de gedeelde map wordt gebruikt voor facturering van momentopnamen, hoewel toegewezen bereiken worden gedeeld tussen momentopnamen als ze ongewijzigd zijn (verschillende opslag).

Services met toegevoegde waarde

Net als bij veel on-premises opslagoplossingen biedt Azure Files integratiepunten voor producten van de eerste en derde partij die kunnen worden geïntegreerd met bestandsshares die eigendom zijn van de klant. Hoewel deze oplossingen aanzienlijke extra waarde kunnen bieden voor Azure Files, moet u rekening houden met de extra kosten die deze services toevoegen aan de totale kosten van een Azure Files oplossing.

Kosten worden onderverdeeld in drie buckets:

• Licentiekosten voor de service met toegevoegde waarde. Licentiekosten kunnen de vorm hebben van vaste kosten per klant, eindgebruiker (ook wel hoofdkosten genoemd), bestandsshare of opslagaccount. Ze kunnen ook worden gebaseerd op eenheden van opslaggebruik, zoals vaste kosten voor elk 500 GiB-segment van gegevens in de bestandsshare.

• Transactiekosten voor de service met toegevoegde waarde. Sommige services met toegevoegde waarde hebben hun eigen concept van transacties boven op het Azure Files-factureringsmodel dat is geselecteerd. Deze transacties worden weergegeven op uw factuur onder de kosten van de toegevoegde service. Ze hebben echter rechtstreeks betrekking op de manier waarop u de dienst met toegevoegde waarde in combinatie met uw bestandsshare gebruikt.

• Azure Files kosten betreffende het gebruik van een service met toegevoegde waarde. Azure Files brengt klanten niet rechtstreeks kosten in rekening voor het toevoegen van services met toegevoegde waarde. Als onderdeel van het toevoegen van waarde aan de Azure bestandsshare, kan de toegevoegde waardeservice echter de kosten verhogen die u op uw Azure bestandsshare ziet. Deze toename is eenvoudig te zien bij bestandsshares volgens het betalen-per-gebruikmodel door transactiekosten. Als de service met toegevoegde waarde transacties uitvoert op basis van de bestandsshare namens u, worden ze weergegeven in uw Azure Files-transactiefactuur, ook al hebt u deze transacties zelf niet rechtstreeks uitgevoerd. Dit transactiemodel is ook van toepassing op ingerichte bestandsshares, hoewel dit mogelijk minder merkbaar is. Transacties op basis van ingerichte bestandsshares van toegevoegde waardeservices tellen mee op basis van uw ingerichte IOPS-nummers, wat betekent dat services met toegevoegde waarde mogelijk meer opslagruimte moeten inrichten om voldoende IOPS of doorvoer beschikbaar te maken voor uw workload.

Houd bij het berekenen van de totale eigendomskosten voor uw bestandsshare rekening met de kosten van Azure Files en van alle services die u wilt gebruiken met Azure Files.

Er bestaan veel diensten met toegevoegde waarde van eigen aanbieders en van derden. In dit document wordt een subset behandeld van de algemene services van derden die klanten gebruiken met Azure Files bestandsshares. Zie de pagina met prijzen voor die service voor meer informatie over services die hier niet worden vermeld.

Azure File Sync

Azure File Sync is een service met toegevoegde waarde voor Azure Files waarmee een of meer on-premises Windows-bestandsshares worden gesynchroniseerd met een Azure-bestandsshare. Omdat de Azure-bestandsshare in de cloud een volledige kopie heeft van de gegevens in een gesynchroniseerde bestandsshare die on-premises beschikbaar is, kunt u uw on-premises Windows-bestandsserver transformeren in een cache van de Azure-bestandsshare om uw on-premises footprint te verminderen. Zie Invoering voor Azure File Sync voor meer informatie.

Houd rekening met de totale eigendomskosten voor een oplossing die is geïmplementeerd met behulp van Azure File Sync, rekening met de volgende kostenaspecten:

• Kapitaal- en operationele kosten van Windows-bestandsservers met een of meer servereindpunten. Azure File Sync als replicatieoplossing is neutraal van waar de Windows-bestandsservers die worden gesynchroniseerd met Azure Files zijn; ze kunnen on-premises, in een virtuele Azure-machine of zelfs in een andere cloud worden gehost. De kosten voor synchronisatieservers die on-premises of in andere cloudproviders worden gehost, omvatten zowel kapitaal- als operationele kosten die niet worden bijgehouden als onderdeel van uw Azure-factuur, maar maken nog steeds deel uit van de totale eigendomskosten van de oplossing. Kapitaalkosten zijn de vooraf gemaakte hardwarekosten van uw oplossing. Operationele kosten zijn de lopende kosten van arbeid, elektriciteit, enz. U moet rekening houden met de hoeveelheid gegevens die u on-premises moet opslaan, het aantal CPU's en de hoeveelheid geheugen die uw Windows-bestandsservers nodig hebben om Azure File Sync-workloads te hosten en andere organisatiespecifieke kosten die u mogelijk hebt. Zie aanbevolen systeemresources voor meer informatie.

• Licentiekosten per server voor servers die zijn geregistreerd bij Azure File Sync. Als u Azure File Sync wilt gebruiken met een specifieke Windows-bestandsserver, moet u deze eerst registreren bij de Azure-resource van Azure File Sync, de opslagsynchronisatieservice. Elke server die u registreert na de eerste server heeft een vast maandelijks tarief. Hoewel deze vergoeding klein is, is het een onderdeel van uw factuur om rekening mee te houden. Als u de huidige prijs van de serverregistratiekosten voor uw gewenste regio wilt zien, raadpleegt u de sectie File Sync op de pagina met prijzen van Azure Files.

  • Kortingen. Vanaf januari 2026 ontvangen organisaties met Software Assurance (SA) en Servers met Azure Arc volledig korting op Azure File Sync-prijzen per server als ze Azure File Sync-agent versie 22 of hoger gebruiken, waardoor operationele kosten worden verlaagd. Klanten die een Azure File Sync-agent gebruiken die ouder zijn dan versie 22, ontvangen de korting niet.

• Kosten voor Azure Files. Azure File Sync verbruikt resources van uw Azure-bestandsshare. Sommige van deze resources, zoals opslagverbruik, zijn relatief duidelijk, terwijl andere resources, zoals transactie- en momentopnamegebruik, mogelijk niet zijn. Voor de meeste klanten raden we aan om HDD-ingerichte v2-bestandsdeling te gebruiken met Azure File Sync, hoewel Azure File Sync volledig wordt ondersteund op alle Azure Files-factureringsmodellen (SSD-ingerichte v2, SSD-ingerichte v1 of HDD betalen per gebruik).

  • Opslaggebruik. Azure File Sync repliceert eventuele wijzigingen die u aanbrengt in uw servereindpunt naar uw Azure-bestandsshare, waardoor opslag wordt verbruikt. Bij geconfigureerde bestandsshares verbruiken wijzigingen geconfigureerde ruimte, dus het is uw verantwoordelijkheid om de provisioning regelmatig te vergroten indien nodig om tegemoet te komen aan de groei van bestandsshares. Bij bestandsshares met betalen per gebruik zorgt het toevoegen of vergroten van de grootte van bestaande bestanden op servereindpunten ervoor dat de gebruikte opslagkosten toenemen omdat de wijzigingen worden gerepliceerd.

  • Momentopnamegebruik. Azure File Sync maakt momentopnamen op share- en bestandsniveau als onderdeel van normaal gebruik. Hoewel het gebruik van momentopnamen altijd differentieel is, kan dit op een merkbare manier bijdragen aan de totale Azure Files-factuur.

  • IOPS / doorvoergebruik: Azure File Sync stuurt IOPS en doorvoergebruik aan om de wijzigingen van uw servereindpunten naar uw Azure-bestandsshares te verplaatsen. Als u een geconfigureerde bestandsshare gebruikt, moet u het gebruik ervan controleren om ervoor te zorgen dat u voldoende IOPS en doorvoer hebt toegewezen, zodat er geen vertraging optreedt. Als u een betalen per gebruik-bestandsshare gebruikt, worden er kosten in rekening gebracht voor het IOPS-gebruik in de vorm van transacties. Over het algemeen zijn er twee soorten transacties om rekening mee te houden:

    • Transacties van klantverloop. Wanneer bestanden op servereindpunten veranderen, worden de wijzigingen geüpload naar de cloudshare, waardoor transacties worden gegenereerd. Wanneer cloud-tiering is ingeschakeld, worden er extra transacties gegenereerd voor het beheren van gelaagde bestanden, waaronder I/O-bewerkingen op gelaagde bestanden, naast de uitgiftekosten. Hoewel de hoeveelheid en het type transacties moeilijk te voorspellen zijn vanwege verloopsnelheden en cache-efficiëntie, kunt u uw vorige transactiepatronen gebruiken om toekomstige kosten te schatten als u denkt dat uw toekomstige gebruik vergelijkbaar is met uw huidige gebruik.

    • Transacties uit cloud-inventarisatie. Azure File Sync inventariseert de Azure-bestandsshare eenmaal per dag in de cloud om wijzigingen te detecteren die rechtstreeks zijn aangebracht in de share, zodat ze kunnen worden gesynchroniseerd met de servereindpunten. Met deze scan worden transacties gegenereerd die worden gefactureerd voor het opslagaccount met een tarief van één ListFiles transactie per directory per dag. U kunt dit nummer in de prijscalculator plaatsen om de scankosten te schatten.

    Aanbeveling

    Als u niet weet hoeveel mappen u hebt, bekijkt u het hulpprogramma TreeSize van JAM Software GmbH.

Azure Backup

Azure Backup biedt een serverloze back-upoplossing voor Azure Files die naadloos kan worden geïntegreerd met uw bestandsshares en met andere services met toegevoegde waarde, zoals Azure File Sync. Azure Backup voor Azure Files is een back-upoplossing op basis van momentopnamen die een planningsmechanisme biedt voor het automatisch maken van momentopnamen volgens een door de beheerder gedefinieerd schema. Het biedt ook een gebruiksvriendelijke interface voor het herstellen van verwijderde bestanden of mappen of de hele share naar een bepaald tijdstip. Voor meer informatie, zie Over de back-up van Azure-bestandsshares.

Houd rekening met de volgende factoren wanneer u rekening houdt met de kosten voor het gebruik van Azure Backup:

• Licentiekosten voor beveiligde exemplaren voor Azure-bestandssharegegevens. Azure Backup brengt kosten in rekening voor een beveiligd exemplaarlicentie per opslagaccount met een back-up van Azure-bestandsshares. Een beveiligd exemplaar wordt gedefinieerd als 250 GiB van Azure-bestandsshareopslag. Opslagaccounts met minder dan 250 GiB zijn onderhevig aan fractionele kosten voor beschermde instanties. Zie prijzen voor Azure Backup voor meer informatie. U moet Azure Files selecteren in de lijst met services die Azure Backup kan beveiligen.

• Kosten voor Azure Files. Azure Backup verhoogt de kosten van Azure Files op de volgende manieren:

  • Differentiële kosten van momentopnamen van Azure-bestandsshares. Azure Backup automatiseert het maken van momentopnamen van Azure-bestandsshares volgens een door de beheerder gedefinieerd schema. Momentopnamen zijn altijd differentieel van aard; de extra kosten zijn echter afhankelijk van hoe lang momentopnamen worden bewaard en de mate van wijzigingen op de bestandsshare gedurende die tijd. Deze factoren bepalen hoe verschillend de momentopname is van de live bestandsshare en daarom hoeveel extra gegevens worden opgeslagen door Azure Files.

  • Transactiekosten van herstelbewerkingen. Herstelbewerkingen van de momentopname naar de liveshare leiden tot transactiekosten. Voor bestandsshares met betalen naar gebruik worden leesbewerkingen vanuit momentopnamen en schrijfbewerkingen bij herstel gefactureerd als normale bestandssharetransacties. Voor ingerichte bestandsshares tellen deze bewerkingen mee voor de ingerichte IOPS voor de bestandsshare.

Microsoft Defender voor Storage

Microsoft Defender ondersteunt Azure Files als onderdeel van het Microsoft Defender for Storage-product. Microsoft Defender voor Storage detecteert ongebruikelijke en mogelijk schadelijke pogingen om uw Azure-bestandsshares te openen of misbruiken via SMB of FileREST. Microsoft Defender voor Storage is op abonnementsniveau ingeschakeld voor alle bestandsshares in de opslagaccounts van dat abonnement.

Microsoft Defender voor Storage biedt geen ondersteuning voor antivirusmogelijkheden voor Azure-bestandsshares.

De belangrijkste kosten van Microsoft Defender for Storage zijn een extra set transactiekosten die door het product worden geheven boven op de transacties die worden uitgevoerd op basis van de Azure-bestandsshare. Hoewel deze kosten zijn gebaseerd op de transacties die in Azure Files worden gemaakt, maken ze geen deel uit van de facturering voor Azure Files, maar maken ze deel uit van de prijzen van Microsoft Defender. Microsoft Defender for Storage brengt transactiekosten in rekening, zelfs op geconfigureerde bestandsshares, waarbij Azure Files transacties omvat als onderdeel van de IOPS-configuratie. Het huidige transactietarief vindt u op Microsoft Defender voor Cloud pagina met prijzen onder de tabelrij Microsoft Defender for Storage.

Voor transacties met zware bestandsshares worden aanzienlijke kosten in rekening gebracht met behulp van Microsoft Defender for Storage. Op basis van deze kosten wilt u zich mogelijk afmelden voor Microsoft Defender for Storage voor specifieke opslagaccounts. Zie Een opslagaccount uitsluiten van Microsoft Defender for Storage-beveiliging voor meer informatie.

Reserveringen

Azure Files ondersteunt reserveringen (ook wel gereserveerde instanties genoemd) voor de ingerichte v1- en betalen per gebruik-modellen. Met reserveringen kunt u korting krijgen op opslag door het gebruik van opslag vooraf in te stellen. Overweeg gereserveerde instanties aan te schaffen voor alle productieworkloads of ontwikkel- of testworkloads met een consistente capaciteit. Wanneer u een reservering aanschaft, geeft u de volgende dimensies op:

• Capaciteitsgrootte: Reserveringen kunnen voor 10 TiB of 100 TiB zijn, met grotere kortingen voor het kopen van een reservering met een hogere capaciteit. U kunt meerdere reserveringen kopen, inclusief reserveringen van verschillende capaciteitsgrootten om te voldoen aan uw workloadvereisten. Als uw productie-implementatie bijvoorbeeld 120 TiB van klassieke bestandsshares heeft, kunt u één 100 TiB-reservering en twee 10 TiB-reserveringen aanschaffen om te voldoen aan de totale opslagcapaciteitsvereisten.
• Termijn: U kunt reserveringen kopen voor een termijn van één of drie jaar, met grotere kortingen voor het aanschaffen van een langere reserveringsperiode.
• Laag: de laag van Azure Files met betrekking tot de reservering. Reserveringen zijn momenteel beschikbaar voor de factureringsmodellen voor SSD-geconfigureerde v1 (als 'premium') en HDD betalen per gebruik (alleen 'hete en koele' toegangslagen).
• Locatie: De Azure-regio voor de reservering. Reserveringen zijn beschikbaar in een subset van Azure-regio's.
• Redundantie: de opslagredundantie voor de reservering. Alle redundantieopties die Azure Files ondersteunt, waaronder LRS, ZRS, GRS en GZRS, ondersteunen reserveringen.
• Factureringsfrequentie: Geeft aan hoe vaak het account wordt gefactureerd voor de reservering. Opties zijn maandelijks of vooraf.

Wanneer u een reservering aanschaft, verbruikt uw bestaande opslaggebruik deze automatisch. Als u meer opslagruimte gebruikt dan u hebt gereserveerd, betaalt u de prijs van de lijst voor het saldo dat niet wordt gedekt door de reservering. Transactie-, bandbreedte-, gegevensoverdracht- en metagegevensopslagkosten worden niet opgenomen in de reservering.

Er zijn verschillen in hoe reserveringen werken met momentopnamen van bestandsshares voor betaling naar gebruik en ingerichte v1-bestandsshares. Als u momentopnamen maakt van klassieke bestandsshares met betalen naar gebruik, worden de verschillen tussen de momentopnamen meegerekend voor de reservering en gefactureerd als onderdeel van de normale meter voor gebruikte opslag. Als u echter momentopnamen maakt van geprovisioneerde klassieke v1-bestandsshares, worden die momentopnamen gefactureerd via een afzonderlijke meter en tellen ze niet mee voor de reservering.

Zie Optimiseer kosten voor Azure Files met reserveringen voor meer informatie over het aanschaffen van reserveringen.

Zie ook

• Prijzen voor Azure Files
• Voorbeelden van kostenramingen
• Een Azure Files-implementatie plannen
• Een Azure File Sync-implementatie plannen
• Een klassieke bestandsshare maken
• Maak een NFS-bestandsshare met behulp van Microsoft. FileShares