Share via

Meer informatie over factureringsmodellen voor Azure Files

  • Artikel

Azure Files ondersteunt twee verschillende medialagen van opslag, SSD en HDD, waarmee u uw bestandsshares kunt aanpassen aan de prestatie- en prijsvereisten van uw scenario:

  • SSD (Premium): bestandsshares die worden gehost op SSD's (Solid State Drives) bieden consistente hoge prestaties en lage latentie, binnen milliseconden met één cijfer voor de meeste IO-bewerkingen.
  • HDD (standaard): bestandsshares hosten op harde schijven (HDD's) bieden rendabele opslag voor algemeen gebruik.

Azure Files heeft meerdere prijsmodellen, waaronder ingerichte en betalen per gebruik-opties:

  • Ingerichte factureringsmodellen: In een ingericht factureringsmodel zijn de primaire kosten van de bestandsshare gebaseerd op de hoeveelheid opslag, IOPS (invoer- en uitvoerbewerkingen per seconde) en doorvoer die u inricht wanneer u uw bestandsshare maakt of bijwerkt, ongeacht hoeveel u gebruikt. Azure Files heeft twee verschillende ingerichte modellen ingericht v2 en ingericht v1.

    • Ingericht v2: In het ingerichte v2-model hebt u de mogelijkheid om opslag, IOPS en doorvoer afzonderlijk in te richten, hoewel we u een aanbeveling bieden om u te helpen bij de eerste keer inrichten.
    • Ingericht v1: In het ingerichte v1-model richt u de hoeveelheid opslagruimte in die u nodig hebt voor de share, terwijl IOPS en doorvoer worden bepaald op basis van de hoeveelheid opslagruimte die u inricht. Het ingerichte v1-model voor Azure Files is alleen beschikbaar voor SSD-bestandsshares.

  • Factureringsmodel voor betalen per gebruik: In een model voor betalen per gebruik zijn de kosten van de bestandsshare gebaseerd op hoeveel u de share gebruikt, in de vorm van gebruikte opslag, transactie- en gegevensoverdrachtskosten. Het model betalen per gebruik voor Azure Files is alleen beschikbaar voor HDD-bestandsshares. U wordt aangeraden het ingerichte v2-model te gebruiken voor nieuwe HDD-bestandsshareimplementaties.

In dit artikel worden de factureringsmodellen voor Azure Files uitgelegd, zodat u inzicht krijgt in uw maandelijkse Azure Files-factuur. Zie de pagina met prijzen van Azure Files voor informatie over prijzen van Azure Files.

Van toepassing op

Beheermodel Factureringsmodel Medialaag Redundantie SMB NFS
Microsoft.Storage Ingericht v2 HDD (standaard) Lokaal (LRS) Ja Nr.
Microsoft.Storage Ingericht v2 HDD (standaard) Zone (ZRS) Ja Nr.
Microsoft.Storage Ingericht v2 HDD (standaard) Geo (GRS) Ja Nr.
Microsoft.Storage Ingericht v2 HDD (standaard) GeoZone (GZRS) Ja Nr.
Microsoft.Storage Ingericht v1 SSD (premium) Lokaal (LRS) Ja Ja
Microsoft.Storage Ingericht v1 SSD (premium) Zone (ZRS) Ja Ja
Microsoft.Storage Betalen per gebruik HDD (standaard) Lokaal (LRS) Ja Nr.
Microsoft.Storage Betalen per gebruik HDD (standaard) Zone (ZRS) Ja Nr.
Microsoft.Storage Betalen per gebruik HDD (standaard) Geo (GRS) Ja Nr.
Microsoft.Storage Betalen per gebruik HDD (standaard) GeoZone (GZRS) Ja Nr.

Opslageenheden

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

Acroniem Definitie Eenheid
KiB 1024 bytes kibibyte
Mib 1.024 KiB (1.048.576 bytes) mebibyte
GiB 1024 MiB (1.073.741.824 bytes) gibibyte
TiB 1024 GiB (1.099.511.627.776 bytes) tebibyte

Hoewel de maateenheidseenheden basis 2 vaak worden gebruikt door de meeste besturingssystemen en hulpprogramma's voor het meten van opslaghoeveelheden, worden ze vaak verkeerd gelabeld als basis-10 eenheden, die u mogelijk beter kent: KB, MB, GB en TB. Hoewel de redenen voor het verkeerd labelen variëren, is de algemene reden waarom besturingssystemen zoals Windows de opslageenheden verkeerd labelen omdat veel besturingssystemen deze acroniemen begonnen te gebruiken voordat ze werden gestandaardiseerd door de IEC (International Electrotechnical Commission), BIPM (International Bureau of Weights and Measures) en NIST (US National Institute of Standards and Technology).

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

Besturingssysteem Meetsysteem Labels
Windows Basis-2 Consistent verkeerd gelabeld als base-10.
Linux-distributies Meestal base-2, sommige software maakt gebruik van base-10 Inconsistent labelen, uitlijning tussen meting en labeling is afhankelijk van het softwarepakket.
macOS, iOS en iPad OS Basis-10 Consistent labels als basis-10.

Neem contact op met de leverancier van uw besturingssysteem als uw besturingssysteem niet wordt vermeld.

Controlelijst voor totale eigendomskosten voor bestandsshares

Als u van on-premises naar Azure Files migreert of Azure Files vergelijkt met andere cloudopslagoplossingen, moet u rekening houden met de volgende factoren om een eerlijke vergelijking tussen apples en apples 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. Van bijzonder belang voor ingerichte modellen zijn minimale ingerichte sharegrootte, de inrichtingseenheid en de mogelijkheid om de inrichting te vergroten en verlagen.

  • Zijn er methoden om de opslagkosten te optimaliseren? U kunt Azure Files-reserveringen gebruiken voor een korting van maximaal 36% op opslag. 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? Met Azure Files is de basiseenheid voor beheer een opslagaccount. Voor andere oplossingen is mogelijk extra beheer vereist, zoals updates van besturingssystemen of beheer 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.

Ingericht v2-model

Het ingerichte v2-model voor Azure Files-paren voorspelbaarheid van de totale eigendomskosten met flexibiliteit, zodat u een bestandsshare kunt maken die voldoet aan uw exacte opslag- en prestatievereisten. Wanneer u een nieuwe ingerichte v2-bestandsshare maakt, geeft u op hoeveel opslagruimte, IOPS en doorvoer uw bestandsshare nodig heeft. Het bedrag van elke hoeveelheid die u inricht, 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 en kunt u niet meer gegevens toevoegen, tenzij u de grootte van uw share vergroot of een deel van de gegevens verwijdert. IOPS-bursting op basis van tegoed biedt extra flexibiliteit bij gebruik, op basis van best effort, terwijl het tegoed behouden blijft.

De hoeveelheid opslagruimte, IOPS en doorvoer die u inricht, kan dynamisch omhoog of omlaag worden geschaald 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, wordt standaard een aanbeveling geboden voor het aantal IOPS en hoeveel doorvoer u nodig hebt op basis van de hoeveelheid ingerichte opslag die u opgeeft. Hoewel deze aanbevelingen zijn gebaseerd op typisch klantgebruik voor die hoeveelheid ingerichte opslag voor die medialaag in Azure Files, kan het zijn dat uw workload meer of minder IOPS en doorvoer vereist dan de 'typische bestandsshare', en u kunt desgewenst meer of minder IOPS en doorvoer inrichten, afhankelijk van de vereisten voor uw afzonderlijke bestandsshares.

Ingerichte v2-beschikbaarheid

Het ingerichte v2-model wordt geleverd voor bestandsshares in opslagaccounts met het type FileStorage-opslagaccount . Op dit moment zijn de volgende subset van opslagaccount-SKU's beschikbaar:

Opslagaccounttype Opslagaccount-SKU Type bestandsshare beschikbaar
FileStorage StandardV2_LRS HDD ingericht v2-bestandsshares met de opgegeven lokale redundantie (LRS).
FileStorage StandardV2_ZRS HDD ingericht v2-bestandsshares met de zoneredundantie (ZRS) opgegeven.
FileStorage StandardV2_GRS HDD ingericht v2-bestandsshares met de opgegeven Geo-redundantie (GRS).
FileStorage StandardV2_GZRS HDD ingerichte v2-bestandsshares met de opgegeven GeoZone-redundantie (GZRS).

Deze SKU's zijn momenteel algemeen beschikbaar in een beperkte subset van regio's:

  • Frankrijk - centraal
  • Frankrijk - zuid
  • Australië - oost
  • Australië - zuidoost
  • Azië - oost
  • Azië - zuidoost
  • VS - west 2
  • VS - west-centraal
  • Europa -west
  • Europa - noord

Details van ingerichte v2-inrichting

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

Artikel HDD-waarde
Inrichtingseenheid voor opslag 1 GiB
Inrichtingseenheid voor IOPS 1 IO per seconde
Inrichtingseenheid voor doorvoer 1 MiB per seconde
Minimaal ingerichte opslag per bestandsshare 32 GiB
Minimaal ingerichte IOPS per bestandsshare 500 IOP's
Minimale ingerichte doorvoer per bestandsshare 60 MiB per seconde
Maximale ingerichte opslag per bestandsshare 256 TiB (262.144 GiB)
Maximaal ingerichte IOPS per bestandsshare 50.000 IOPS
Maximale ingerichte doorvoer per bestandsshare 5.120 MiB per seconde
Maximaal ingerichte opslag per opslagaccount 4 PiB (4.194.304 GiB)
Maximaal ingerichte IOPS per opslagaccount 50.000 IOPS
Maximale ingerichte doorvoer per opslagaccount 5.120 MiB per seconde
Maximum aantal bestandsshares per opslagaccount 50 bestandsshares

Standaard wordt IOPS en doorvoerinrichting aanbevolen 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:

Formulenaam HDD-formule
IOPS-aanbeveling MIN(MAX(1000 + CEILING(0.2 * ProvisionedStorageGiB), 500), 50000)
Aanbeveling voor doorvoer MIN(MAX(60 + CEILING(0.02 * ProvisionedStorageGiB), 60), 5120)

Afhankelijk van de vereisten voor uw afzonderlijke bestandsshares, is het mogelijk dat u meer of minder IOPS of doorvoer nodig hebt dan onze aanbevelingen en deze aanbevelingen desgewenst met uw eigen waarden kunt overschrijven.

Ingerichte v2-bursting

IOPS-bursting op basis van krediet biedt extra flexibiliteit bij IOPS-gebruik. Deze flexibiliteit wordt het beste gebruikt als buffer tegen onverwachte IO-pieken. Voor vastgestelde I/O-patronen raden we u aan om io-pieken in te richten.

Burst IOPS-tegoed wordt verzameld wanneer verkeer voor uw bestandsshare lager is dan 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 bursten zolang er nog tegoeden zijn, maar dit is gebaseerd op het aantal opgebouwde burst-tegoeden. Elke IO buiten de ingerichte IOPS verbruikt één tegoed. Zodra alle tegoeden zijn verbruikt, keert de share terug naar de ingerichte IOPS. IOPS voor de bestandsshare hoeft niets speciaals te doen om bursting te gebruiken. Bursting werkt op basis van best effort.

Sharetegoed heeft drie statussen:

  • Als 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 bestandsshare exact gebruikmaakt van de ingerichte IOPS en er geen tegoed is opgebouwd of gebruikt.

Een nieuwe bestandsshare begint met het volledige aantal tegoeden in de burst-bucket. Burst-tegoeden worden niet opgebouwd als de share-IOPS onder de ingerichte limiet vallen vanwege beperking 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:

Artikel HDD-formule
IOPS-limiet voor burst MIN(MAX(3 * ProvisionedIOPS, 5000), 50000)
Burst IOPS-tegoed (BurstLimit - ProvisionedIOPS) * 3600

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

Ingerichte IOPS IOPS-limiet voor HDD-burst HDD-bursttegoed
500 Tot 5.000 16,200,000
1.000 Tot 5.000 14,400,000
3.000 Tot 9.000 21,600,000
5.000 Tot 15.000 36,000,000
10,000 Tot 30.000 72,000,000
25,000 Tot 50.000 90,000,000
50,000 Tot 50.000 0

Ingerichte v2-momentopnamen

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

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 livesharegegevens plus de differentiële momentopnamegegevens groter is dan de ingerichte opslag van de share, wordt de overtollige gebruikte capaciteit van de momentopnamen gefactureerd op basis van de meter Gebruik van overloopmomentopnamen. 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.

Ingericht v2 voorlopig verwijderen

Verwijderde bestandsshares in opslagaccounts waarvoor voorlopig verwijderen is ingeschakeld, worden gefactureerd op basis van de gebruikte opslagcapaciteit van de verwijderde share voor de duur van de periode voor voorlopig verwijderen. Om ervoor te zorgen dat een verwijderde bestandsshare altijd kan worden hersteld, worden de ingerichte opslag, IOPS en doorvoer van de share geteld tegen de limieten van het opslagaccount totdat de bestandsshare is opgeschoond, maar worden deze niet gefactureerd. Zie Voorlopig verwijderen inschakelen voor Azure-bestandsshares voor meer informatie over voorlopig verwijderen.

Ingerichte v2-factureringsmeters

Bestandsshares die zijn ingericht met het ingerichte v2-factureringsmodel, worden gefactureerd op basis van de volgende vijf factureringsmeters:

  • Ingerichte opslag: de hoeveelheid opslagruimte die is ingericht 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 ingerichte v2-momentopnamen voor meer informatie.
  • Voorlopig verwijderd gebruik: gebruikte opslagcapaciteit in GiB voor voorlopig verwijderde bestandsshares. Zie ingericht v2 voorlopig verwijderen voor meer informatie.

Het verbruik ten opzichte van de ingerichte v2-factureringsmeters wordt elk uur verzonden in termen van uureenheden. Voor een share met 1024 GiB ingericht, ziet u bijvoorbeeld:

  • 1024 eenheden ten opzichte van de ingerichte opslagmeter gedurende één uur.
  • 24.576 eenheden ten opzichte van 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:
    • Maand van 28 dagen (normaal februari): 688.128 eenheden ten opzichte van de ingerichte opslagmeter .
    • Maand van 29 dagen (schrikkeljaar februari): 712.704 eenheden ten opzichte van de ingerichte opslagmeter .
    • Maand van 30 dagen: 737.280 eenheden ten opzichte van de ingerichte opslagmeter .
    • Maand van 31 dagen: 761.856 eenheden ten opzichte van de ingerichte opslagmeter .

Ingericht 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-bestandsshare maakt, geeft u op hoeveel opslagruimte uw share nodig heeft en worden de IOPS en doorvoer berekend. Het ingerichte v1-model voor Azure Files is alleen beschikbaar voor SSD-bestandsshares.

De hoeveelheid opslagruimte die u inricht, bepaalt de gegarandeerde opslag-, IOPS- en doorvoerlimieten van 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 en kunt u niet meer gegevens toevoegen, tenzij u de grootte van uw share vergroot of een deel van de gegevens verwijdert. IOPS-bursting op basis van tegoed biedt extra flexibiliteit bij gebruik, op basis van best effort, terwijl het tegoed behouden blijft.

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

Het is mogelijk om de grootte van uw ingerichte share onder uw gebruikte GiB te verkleinen. Als u dit wel doet, verliest u geen gegevens, maar wordt u nog steeds gefactureerd voor de gebruikte grootte en ontvangt u de prestaties van de ingerichte share, niet de gebruikte grootte.

Ingerichte v1-beschikbaarheid

Het ingerichte v1-model wordt geleverd voor SSD-bestandsshares in opslagaccounts met het type FileStorage-opslagaccount :

Opslagaccounttype Opslagaccount-SKU Type bestandsshare beschikbaar
FileStorage Premium_LRS Met SSD ingerichte v1-bestandsshare met de opgegeven lokale redundantie (LRS).
FileStorage Premium_ZRS Ssd ingerichte v1-bestandsshare met de zoneredundantie (ZRS) opgegeven.

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.

Inrichtingsdetails van ingericht v1

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

Artikel Weergegeven als
Inrichtingseenheid voor opslag 1 GiB
Minimaal ingerichte opslag per bestandsshare 100 GiB
Maximale ingerichte opslag per bestandsshare 100 TiB (102.400 GiB)
Maximaal ingerichte opslag per opslagaccount 100 TiB (102.400 GiB)

De hoeveelheid IOPS en doorvoer die is ingericht voor de share, wordt bepaald door de volgende formules:

Artikel Formule
Berekende ingerichte IOPS (basislijn) MIN(3000 + 1 * ProvisionedStorageGiB, 102400)
Berekende ingerichte doorvoer (MiB per seconde) 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)

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

Ingerichte v1-bursting

IOPS-bursting op basis van krediet biedt extra flexibiliteit bij IOPS-gebruik. Deze flexibiliteit wordt het beste gebruikt als buffer tegen onverwachte IO-pieken. Voor vastgestelde I/O-patronen raden we u aan om io-pieken in te richten.

Burst IOPS-tegoed wordt verzameld wanneer verkeer voor uw bestandsshare lager is dan 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 bursten zolang er nog tegoeden zijn, maar dit is gebaseerd op het aantal opgebouwde burst-tegoeden. Elke IO buiten de ingerichte IOPS verbruikt één tegoed. Zodra alle tegoeden zijn verbruikt, keert de share terug naar de ingerichte IOPS. IOPS voor de bestandsshare hoeft niets speciaals te doen om bursting te gebruiken. Bursting werkt op basis van best effort.

Sharetegoed heeft drie statussen:

  • Als 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 bestandsshare exact gebruikmaakt van de ingerichte IOPS en er geen tegoed is opgebouwd of gebruikt.

Een nieuwe bestandsshare begint met het volledige aantal tegoeden in de burst-bucket. Burst-tegoeden worden niet opgebouwd als de share-IOPS onder de ingerichte limiet vallen vanwege beperking 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:

Artikel Formule
Burst-limiet MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400)
Burst-tegoed (BurstLimit - BaselineIOPS) * 3600

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

Capaciteit (GiB) IOPS-basislijn Burst IOPS Burst-tegoed Doorvoer (inkomend en uitgaand verkeer) (MiB/sec)
100 3,100 Tot 10.000 24,840,000 110
500 3500 Tot 10.000 23,400,000 150
1024 4,024 Tot 10.000 21,513,600 203
5,120 8120 Tot 15.360 26,064,000 613
10,240 13,240 Tot 30.720 62,928,000 1,125
33,792 36,792 Tot 102.400 227,548,800 3,480
51,200 54,200 Tot 102.400 164,880,000 5220
102,400 102,400 Tot 102.400 0 10,340

Effectieve prestaties van bestandsshares zijn onderhevig aan netwerklimieten van computers, beschikbare netwerkbandbreedte, I/O-grootten en parallelle uitvoering, onder vele andere factoren. Als u optimaal wilt profiteren van parallelle uitvoering, raden we u aan SMB meerdere kanalen in te schakelen op SSD-bestandsshares. Raadpleeg de handleiding voor het oplossen van problemen met SMB-prestaties en prestaties voor enkele veelvoorkomende prestatieproblemen en tijdelijke oplossingen.

Ingerichte v1-momentopnamen

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

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.

Ingericht v1 voorlopig verwijderen

Verwijderde bestandsshares in opslagaccounts waarvoor voorlopig verwijderen is ingeschakeld, worden gefactureerd op basis van de gebruikte opslagcapaciteit van de verwijderde share voor de duur van de periode voor voorlopig verwijderen. De voorlopig verwijderde gebruiksopslagcapaciteit wordt verzonden op basis van de gebruikte opslagmeter voor momentopnamen. Zie Voorlopig verwijderen inschakelen voor Azure-bestandsshares voor meer informatie over voorlopig verwijderen.

Ingerichte v1-factureringsmeters

Bestandsshares die zijn ingericht met het ingerichte v1-factureringsmodel, worden gefactureerd op de volgende twee meters:

  • Premium ingericht: de hoeveelheid opslagruimte die is ingericht in GiB.
  • Premium-momentopnamen: de hoeveelheid gebruikte momentopnamen en de gebruikte voorlopig verwijderde capaciteit.

Het verbruik ten opzichte van de ingerichte v1-factureringsmeters wordt elk uur verzonden in termen van maandelijkse eenheden. Voor een share met 1024 GiB ingericht, ziet u bijvoorbeeld:

  • 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 ingerichte Premium-meter.
    • Maand van 29 dagen (schrikkeljaar februari): 1.4713 eenheden ten opzichte van de ingerichte Premium-meter.
    • Maand van 30 dagen: 1.4222 eenheden ten opzichte van de ingerichte Premium-meter.
    • Maand van 31 dagen: 1.3763 eenheden ten opzichte van de ingerichte Premium-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 ingerichte Premium-meter.
    • Maand van 29 dagen (schrikkeljaar februari): 35.3103 eenheden ten opzichte van de ingerichte Premium-meter.
    • Maand van 30 dagen: 34.1333 eenheden ten opzichte van de ingerichte Premium-meter.
    • Maand van 31 dagen: 33.0323 eenheden ten opzichte van de ingerichte Premium-meter.
  • 1024 eenheden ten opzichte van de ingerichte Premium-meter, indien geaggregeerd voor een maand.

Model voor betalen per gebruik

In het model betalen per gebruik wordt het bedrag dat u betaalt bepaald door hoeveel u gebruikt, in plaats van op basis van een ingericht bedrag. 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. Factureringsmodel voor betalen per gebruik kan lastig zijn om te plannen als onderdeel van een budgetteringsproces, omdat het model wordt aangestuurd door het verbruik van eindgebruikers. Daarom raden we u aan het ingerichte v2-model te gebruiken voor nieuwe bestandsshareimplementaties. Het model betalen per gebruik is alleen beschikbaar voor HDD-bestandsshares.

Beschikbaarheid van betalen per gebruik

Het pay-as-you-go-model wordt geleverd voor HDD-bestandsshares in opslagaccounts met het type StorageV2 - of Storage-opslagaccount :

Opslagaccounttype Opslagaccount-SKU Type bestandsshare beschikbaar
StorageV2 of Storage Standard_LRS HDD pay-as-you-go-bestandsshare met de lokale redundantie (LRS) opgegeven.
StorageV2 of Storage Standard_ZRS HDD-bestandsshare voor betalen per gebruik met de zoneredundantie (ZRS) opgegeven.
StorageV2 of Storage Standard_GRS HDD pay-as-you-go-bestandsshare met de opgegeven Geo-redundantie (GRS).
StorageV2 of Storage Standard_GZRS HDD pay-as-you-go-bestandsshare met de GeoZone (GZRS) redundantie opgegeven.

HDD-bestandsshares met het model betalen per gebruik zijn algemeen beschikbaar in alle Azure-regio's.

Verschillen in toegangslagen

Wanneer u een HDD-bestandsshare maakt, kiest u tussen de volgende toegangslagen: geoptimaliseerd voor transacties, dynamisch en statisch. Alle drie de toegangslagen worden op dezelfde opslaghardware opgeslagen. Het belangrijkste verschil voor deze drie toegangslagen is hun opslagprijzen voor data-at-rest, die lager zijn in koelerlagen en de transactieprijzen, die hoger zijn in de koelerlagen. Dit houdt in:

  • Transactie geoptimaliseerd, zoals de naam al aangeeft, optimaliseert de prijs voor hoge IOPS-workloads (transaction). Voor transactie geoptimaliseerd heeft de hoogste opslagprijs voor gegevens at-rest, maar de laagste transactieprijs.
  • Dynamisch is voor actieve workloads die geen groot aantal transacties omvatten. Het heeft een iets lagere opslagprijs voor data-at-rest, maar iets hogere transactieprijzen in vergelijking met geoptimaliseerde transacties. U kunt het beschouwen als de middelste grond tussen de geoptimaliseerde en statische lagen van de transactie.
  • Cool optimaliseert de prijs voor workloads die geen hoge activiteit hebben en biedt de laagste opslagprijs voor data-at-rest, maar de hoogste transactieprijzen.

Als u een zelden geopende workload in de voor transactie geoptimaliseerde toegangslaag plaatst, betaalt u bijna niets voor de paar keer in een maand dat u transacties uitvoert op basis van uw share. U betaalt echter een hoge hoeveelheid voor de kosten voor gegevensopslag. Als u dezelfde share naar de statische toegangslaag hebt verplaatst, betaalt u nog steeds bijna niets voor de transactiekosten, omdat u zelden transacties voor deze workload maakt. De statische toegangslaag heeft echter een veel goedkopere prijs voor gegevensopslag. Als u de juiste toegangslaag voor uw use-case selecteert, kunt u uw kosten aanzienlijk verlagen.

Als u een workload met hoge toegang in de statische toegangslaag plaatst, betaalt u veel meer transactiekosten, maar minder voor kosten voor gegevensopslag. Dit kan leiden tot een situatie waarbij de verhoogde kosten van de transactieprijzen groter zijn dan de besparingen van de verlaagde prijs voor gegevensopslag, waardoor u meer geld kunt betalen aan cool dan u zou hebben op geoptimaliseerde transacties. Voor sommige gebruiksniveaus is het mogelijk dat de dynamische toegangslaag de meest rendabele is en de statische toegangslaag duurder is dan geoptimaliseerd voor transacties.

Uw workload- en activiteitsniveau bepalen de meest kostenefficiënte toegangslaag voor uw betalen per gebruik-bestandsshare. In de praktijk is het 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 bestandsshares met betalen per gebruik raden we u aan om te beginnen in de laag die is geoptimaliseerd voor transacties tijdens de eerste migratie naar Azure Files en vervolgens de juiste toegangslaag te kiezen 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 Azure-bestandsshare koppelt op een computer met behulp van SMB, wordt de Azure-bestandsshare weergegeven 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 Azure-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 taak die de eindgebruiker als één bewerking beschouwt, zoals het lezen van een bestand van begin tot eind, kan worden omgezet in meerdere SMB-transacties die worden geleverd door Azure Files.

Het factureringsmodel voor betalen per gebruik dat door standaardbestandsshares wordt gebruikt, wordt in principe gefactureerd op basis van gebruik. SMB- en FileREST-transacties die zijn gemaakt door toepassingen en scripts vertegenwoordigen het gebruik van uw 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 Azure-bestandsshare. Deze categorieën zijn: schrijven, vermelden, lezen, andere en verwijderen.

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

Transactiebucket Beheerbewerkingen Gegevensbewerkingen
Schrijftransacties
  • CreateShare
  • SetFileServiceProperties
  • SetShareMetadata
  • SetShareProperties
  • SetShareAcl
  • SnapshotShare
  • RestoreShare
  • CopyFile
  • Create
  • CreateDirectory
  • CreateFile
  • PutRange
  • PutRangeFromURL
  • SetDirectoryMetadata
  • SetFileMetadata
  • SetFileProperties
  • SetInfo
  • Write
  • PutFilePermission
  • Flush
  • SetDirectoryProperties
Lijsttransacties
  • ListShares
  • ListFileRanges
  • ListFiles
  • ListHandles
Leestransacties
  • GetFileServiceProperties
  • GetShareAcl
  • GetShareMetadata
  • GetShareProperties
  • GetShareStats
  • FilePreflightRequest
  • GetDirectoryMetadata
  • GetDirectoryProperties
  • GetFile
  • GetFileCopyInformation
  • GetFileMetadata
  • GetFileProperties
  • QueryDirectory
  • QueryInfo
  • Read
  • GetFilePermission
Andere/protocoltransacties
  • AcquireShareLease
  • BreakShareLease
  • ReleaseShareLease
  • RenewShareLease
  • ChangeShareLease
  • AbortCopyFile
  • Cancel
  • ChangeNotify
  • Close
  • Echo
  • Ioctl
  • Lock
  • Logoff
  • Negotiate
  • OplockBreak
  • SessionSetup
  • TreeConnect
  • TreeDisconnect
  • CloseHandles
  • AcquireFileLease
  • BreakFileLease
  • ChangeFileLease
  • ReleaseFileLease
Transacties verwijderen
  • DeleteShare
  • ClearRange
  • DeleteDirectory
  • DeleteFile

Notitie

NFS 4.1 is alleen beschikbaar voor SSD-bestandsshares, die gebruikmaken van een ingericht factureringsmodel. Transactiesbuckets hebben geen invloed op de facturering voor ingerichte bestandsshares.

Schakelen tussen toegangslagen

Hoewel u een bestandsshare voor betalen per gebruik tussen de drie toegangslagen kunt wijzigen, kunt u het beste de kosten optimaliseren nadat de eerste migratie is uitgevoerd om de meest kosten optimale toegangslaag te kiezen en daar te blijven, tenzij uw toegangspatroon verandert. Dit komt doordat het wijzigen van de toegangslaag van een standaardbestandsshare als volgt leidt 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 share. Als u een bestandsshare verplaatst van een koeler toegangslaag naar een dynamischere toegangslaag, worden de leestransactiekosten van de koelertoegangslaag in rekening gebracht voor elk bestand in de share.

  • Gegevens ophalen: als u overstapt van de statische-toegangslaag naar dynamisch of geoptimaliseerd voor transacties, worden kosten in rekening gebracht voor het ophalen van gegevens op basis van de grootte van gegevens die zijn verplaatst. Alleen de statische toegangslaag heeft kosten voor het ophalen van gegevens.

De volgende tabel illustreert de kostenanalyse van het verplaatsen van toegangslagen:

Toegangslaag Geoptimaliseerd voor transacties (doel) Dynamisch (bestemming) Statisch (bestemming)
Geoptimaliseerde transactie (bron) --
  • 1 dynamische schrijftransactie per bestand.
  • 1 statische schrijftransactie per bestand.
Dynamisch (bron)
  • 1 dynamische leestransactie per bestand.
    		 --
    • 1 statische schrijftransactie per bestand.
    Statisch (bron)
    • 1 statische leestransactie per bestand.
    • Gegevens ophalen per totaal gebruikte GiB.
    • 1 statische leestransactie per bestand.
    • Gegevens ophalen per totaal gebruikte GiB.
    		 --

    Hoewel er geen formele limiet is voor hoe vaak u de toegangslaag van uw bestandsshare kunt wijzigen, duurt het even voordat uw share wordt overgestapt op basis van de hoeveelheid gegevens in uw share. U kunt de toegangslaag van de share niet wijzigen terwijl de bestandsshare overgaat tussen toegangslagen. Het wijzigen van de toegangslaag van de bestandsshare heeft geen invloed op normale toegang tot bestandsshares.

    Een toegangslaag kiezen

    Ongeacht hoe u bestaande gegevens migreert naar Azure Files, raden we u aan de bestandsshare in de transactie geoptimaliseerde toegangslaag te maken vanwege het grote aantal transacties dat tijdens de migratie wordt gemaakt. Nadat uw migratie is voltooid en u een paar dagen of weken met regelmatig gebruik hebt uitgevoerd, kunt u het aantal transacties in de prijscalculator instellen om erachter te komen welke toegangslaag het meest geschikt is voor uw workload.

    Omdat bestandsshares met betalen per gebruik alleen transactiegegevens weergeven op het niveau van het opslagaccount, is het gebruik van de metrische opslaggegevens om te schatten welke toegangslaag goedkoper is op het niveau van de bestandsshare een onvolmaakte wetenschap. Indien mogelijk raden we u aan slechts één bestandsshare in elk opslagaccount te implementeren om volledige zichtbaarheid van de facturering te garanderen.

    Vorige transacties bekijken:

    1. Ga in het Navigeer 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. Selecteer Splitsen toepassen.
    5. Selecteer waarden als 'API-naam'. Selecteer de gewenste limiet en sorteerbewerking.
    6. Selecteer de gewenste periode.

    Notitie

    Zorg ervoor dat u transacties gedurende een bepaalde periode bekijkt om een beter beeld te krijgen van het gemiddelde aantal transacties. Zorg ervoor dat de gekozen periode niet overlapt met de eerste inrichting. Vermenigvuldig het gemiddelde aantal transacties gedurende deze periode om de geschatte transacties voor een hele maand op te halen.

    Momentopnamen van betalen per gebruik

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

    Momentopnamen verschillen altijd van de liveshare en van elkaar. In het factureringsmodel voor betalen per gebruik wordt de totale differentiële grootte gefactureerd op basis van de normale gebruikte opslagmeter. Dit betekent dat u geen afzonderlijk regelitem op uw factuur ziet dat momentopnamen vertegenwoordigt voor uw opslagaccount voor betalen per gebruik. Dit betekent ook dat het gebruik van differentiële momentopnamen telt voor reserveringen die zijn gekocht voor betalen per gebruik-bestandsshares.

    Voorlopig verwijderen van betalen per gebruik

    Verwijderde bestandsshares in opslagaccounts waarvoor voorlopig verwijderen is ingeschakeld, worden gefactureerd op basis van de gebruikte opslagcapaciteit van de verwijderde bestandsshare voor de duur van de periode voor voorlopig verwijderen. De voorlopig verwijderde gebruikte opslagcapaciteit wordt verzonden op basis van de normale gebruikte opslagmeter. Dit betekent dat u geen afzonderlijk regelitem op uw factuur ziet dat voorlopig verwijderde bestandsshares vertegenwoordigt voor uw opslagaccount voor betalen per gebruik. Dit betekent ook dat het gebruik van voorlopig verwijderde bestandsshares wordt geteld voor reserveringen die zijn gekocht voor betalen per gebruik-bestandsshares.

    Factureringsmeters voor betalen per gebruik

    Bestandsshares die zijn gemaakt met het factureringsmodel betalen per gebruik, worden gefactureerd op basis van de volgende meters:

    • Opgeslagen gegevens: de gebruikte opslag, waaronder de liveshares, differentiële momentopnamen en voorlopig verwijderde bestandsshares in 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 wordt alleen gebruikt voor bestandsshares in de dynamische of statische toegangslagen.
    • Schrijfbewerkingen: het aantal buckets voor schrijftransacties (1 bucket = 10.000 transacties).
    • Lijstbewerkingen: het aantal buckets voor lijsttransacties (1 bucket = 10.000 transacties).
    • Leesbewerkingen: het aantal buckets voor leestransacties (1 bucket = 10.000 transacties).
    • Andere Operations Protocol-bewerkingen / : het aantal andere transactiebuckets (1 bucket = 10.000 transacties).
    • Ophalen van gegevens: de hoeveelheid gegevens die uit de bestandsshare in GiB wordt gelezen. Deze meter wordt alleen gebruikt voor bestandsshares in de statische toegangslaag.
    • Geo-replicatiegegevensoverdracht: als de bestandsshare de geo- of geozoneredundantie heeft, wordt de hoeveelheid gegevens die naar de bestandsshare is geschreven, gerepliceerd naar de secundaire regio in GiB.

    Verbruik op basis van de factureringsmeters voor gegevens opgeslagen en metagegevens worden elk uur verzonden in termen van maandelijkse eenheden. Voor een share met 1024 gebruikt GiB ziet u bijvoorbeeld:

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

    Verbruik ten opzichte van de andere meters (bijvoorbeeld Schrijfbewerkingen of het ophalen van gegevens) worden elk uur verzonden, maar omdat ze niet worden verzonden in termen van een tijdsbestek, zijn er geen speciale eenheidstransformaties om rekening mee te houden.

    Ingericht/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 waarnaar de bestandsshare mag groeien. In ingerichte bestandsshares wordt deze waarde de ingerichte grootte genoemd. Het bedrag dat u inricht, is waarvoor u betaalt, ongeacht hoeveel u daadwerkelijk gebruikt. In bestandsshares met betalen per gebruik wordt deze waarde quotum genoemd en is dit niet rechtstreeks van invloed op uw factuur. De ingerichte grootte is een vereist veld voor ingerichte bestandsshares. Voor bestandsshares met betalen per gebruik, als de ingerichte grootte niet rechtstreeks is opgegeven, wordt de share standaard ingesteld op de maximale waarde die wordt ondersteund door het opslagaccount (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 deze daadwerkelijk wordt opgeslagen, waar opslagoptimalisaties kunnen worden toegepast. De logische grootte van het bestand is hoeveel KiB/MiB/GiB via de kabel wordt overgedragen als u het naar een andere locatie hebt gekopieerd. In zowel ingerichte als betalen per gebruik-bestandsshares wordt de totale logische grootte van de bestandsshare gebruikt voor afdwinging tegen ingerichte grootte/quotum. In bestandsshares met betalen per gebruik is de logische grootte de hoeveelheid die wordt gebruikt voor de facturering van het data-at-rest-gebruik. Logische grootte wordt 'grootte' genoemd in het dialoogvenster Windows-eigenschappen voor een bestand/map en als 'inhoudslengte' door metrische gegevens van Azure Files.

    • Fysieke grootte: de fysieke grootte van het bestand heeft betrekking op de grootte van het bestand als gecodeerd op schijf. Dit kan overeenkomen met de logische grootte van het bestand, of kleiner, afhankelijk van de wijze waarop het bestand is geschreven door het besturingssysteem. 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 share wordt gebruikt voor facturering van momentopnamen, hoewel toegewezen bereiken worden gedeeld tussen momentopnamen als ze ongewijzigd zijn (differentiële 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. Dit kan komen in de vorm van vaste kosten per klant, eindgebruiker (ook wel hoofdkosten genoemd), Azure-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 waardeservice; Ze hebben echter rechtstreeks betrekking op de wijze waarop u de service met toegevoegde waarde gebruikt met uw bestandsshare.

    • Azure Files kost voor 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, maar als onderdeel van het toevoegen van waarde aan de Azure-bestandsshare, kan de service met toegevoegde waarde de kosten verhogen die u op uw Azure-bestandsshare ziet. Dit is gemakkelijk te zien met bestandsshares voor betalen per gebruik, vanwege transactiekosten. Als de service met toegevoegde waarde transacties uitvoert op basis van de bestandsshare namens u, worden deze weergegeven in uw Azure Files-transactiefactuur, ook al hebt u deze transacties zelf niet rechtstreeks uitgevoerd. Dit geldt ook voor 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.

    Wanneer u de totale eigendomskosten voor uw bestandsshare wilt berekenen, moet u rekening houden met de kosten van Azure Files en alle services die u wilt gebruiken met Azure Files.

    Er zijn meerdere services met toegevoegde waarden en services van derden. In dit document wordt een subset behandeld van de algemene eigen services die klanten gebruiken met Azure-bestandsshares. Meer informatie over services die hier niet worden vermeld, vindt u op de pagina met prijzen voor die service.

    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. Lees inleiding tot Azure File Sync voor meer informatie.

    Wanneer u rekening houdt met de totale eigendomskosten voor een oplossing die is geïmplementeerd met Behulp van Azure File Sync, moet u rekening houden 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 worden gehost, in een Azure-VM of zelfs in een andere cloud. Tenzij u Azure File Sync gebruikt met een Windows-bestandsserver die wordt gehost in een Azure-VM, maakt het kapitaal (d.w.z. de vooraf gemaakte hardwarekosten van uw oplossing) en operationele kosten (d.w.z. kosten van arbeid, elektriciteit, enzovoort) geen deel uit van uw Azure-factuur, maar maakt nog steeds heel veel deel uit van uw totale eigendomskosten. 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 (zie aanbevolen systeembronnen voor meer informatie) en andere organisatiespecifieke kosten die u mogelijk hebt.

    • 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 nadat de eerste server een vast maandelijks bedrag heeft. Hoewel deze vergoeding erg 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.

    • Kosten voor Azure Files. Omdat Azure File Sync een synchronisatieoplossing is voor Azure Files, zorgt dit ervoor dat u Azure Files-resources gebruikt. 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 standaardbestandsshares te gebruiken met Azure File Sync, hoewel Azure File Sync indien gewenst volledig wordt ondersteund met Premium-bestandsshares.

      • Opslaggebruik. Azure File Sync repliceert alle wijzigingen die u hebt aangebracht in het pad op uw Windows-bestandsserver die is opgegeven op uw servereindpunt naar uw Azure-bestandsshare, waardoor opslag wordt verbruikt. Op standaardbestandsshares betekent dit dat het toevoegen of vergroten van de grootte van bestaande bestanden op servereindpunten leidt tot een toename van de opslagkosten, omdat de wijzigingen worden gerepliceerd. Bij Premium-bestandsshares worden er ingerichte ruimte verbruikt. Het is uw verantwoordelijkheid om de inrichting regelmatig te verhogen als dat nodig is om rekening te houden met de groei van bestandsshares.

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

      • Transacties van verloop. Wanneer bestanden op servereindpunten veranderen, worden de wijzigingen geüpload naar de cloudshare, waardoor transacties worden gegenereerd. Wanneer cloudlagen zijn ingeschakeld, worden er extra transacties gegenereerd voor het beheren van gelaagde bestanden, waaronder I/O op gelaagde bestanden, naast de kosten voor uitgaand verkeer. 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.

      Tip

      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/mappen of de hele share naar een bepaald tijdstip. Zie Back-up van Azure-bestandsshares voor meer informatie.

    Overweeg het volgende 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 een gebroken beveiligde instantiekosten. 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; De toegevoegde kosten zijn echter afhankelijk van de tijdsduur van momentopnamen en de hoeveelheid verloop van de bestandsshare gedurende die tijd. Dit bepaalt 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 veroorzaken transacties. Voor standaardbestandsshares betekent dit dat leesbewerkingen van momentopnamen/schrijfbewerkingen vanuit herstelbewerkingen als normale bestandssharetransacties worden gefactureerd. Voor ingerichte bestandsshares worden deze bewerkingen meegeteld 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 ingeschakeld op abonnementsniveau voor alle bestandsshares in opslagaccounts in 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 een transactietarief in rekening, zelfs op ingerichte bestandsshares, waarbij Azure Files transacties omvat als onderdeel van IOPS-inrichting. 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 vooraf gebruik te maken van opslag. Overweeg gereserveerde instanties te kopen voor elke productieworkload of ontwikkel-/testworkloads met consistente footprints. Wanneer u een reservering aanschaft, moet u de volgende dimensies opgeven:

    • Capaciteitsgrootte: Reserveringen kunnen voor 10 TiB of 100 TiB zijn, met aanzienlijke kortingen voor het kopen van een reservering met een hogere capaciteit. U kunt meerdere reserveringen aanschaffen, inclusief reserveringen van verschillende capaciteitsgrootten om te voldoen aan uw workloadvereisten. Als uw productie-implementatie bijvoorbeeld 120 TiB aan 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 jaar of drie jaar, met meer significante kortingen voor het kopen van een langere reserveringsperiode.
    • Laag: de laag van Azure Files voor de reservering. Reserveringen zijn momenteel beschikbaar voor de premiumlaag (SSD), hot (HDD) en cool (HDD).
    • Locatie: De Azure-regio voor de reservering. Reserveringen zijn beschikbaar in een subset van Azure-regio's.
    • Redundantie: de opslagredundantie voor de reservering. Reserveringen worden ondersteund voor alle redundantie die Azure Files ondersteunt, waaronder LRS, ZRS, GRS en GZRS.
    • Factureringsfrequentie: Geeft aan hoe vaak het account wordt gefactureerd voor de reservering. Opties zijn maandelijks of vooraf.

    Zodra u een reservering aanschaft, wordt deze automatisch verbruikt door uw bestaande opslaggebruik. Als u meer opslagruimte gebruikt dan u hebt gereserveerd, betaalt u een catalogusprijs 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 de manier waarop reserveringen werken met momentopnamen van Azure-bestandsshares voor betalen per gebruik en ingerichte v1-bestandsshares. Als u momentopnamen maakt van betalen per gebruik-bestandsshares, tellen de differentiële momentopnamen voor de reservering en worden ze gefactureerd als onderdeel van de normale gebruikte opslagmeter. Als u echter momentopnamen maakt van ingerichte v1-bestandsshares, worden de momentopnamen gefactureerd met behulp van een afzonderlijke meter en worden ze niet meegeteld voor de reservering.

    Zie Kosten optimaliseren voor Azure Files met reserveringen voor meer informatie over het aanschaffen van reserveringen.

    Zie ook