Dela via


Förstå faktureringsmodeller för Azure Files

Azure Files stöder två olika medienivåer för lagring, SSD och HDD. På så sätt kan du anpassa dina filresurser efter prestanda- och priskraven i ditt scenario:

  • SSD (premium): filresurser som finns på solid state-enheter (SSD) ger konsekventa höga prestanda och låg svarstid inom ensiffriga millisekunder för de flesta I/O-åtgärder.
  • HDD (standard): filresurser som finns på hårddiskar (HDD) ger kostnadseffektiv lagring för generell användning.

Azure Files har flera prismodeller, inklusive förutbestämda och "betala per användning"-alternativ.

  • Etablerade faktureringsmodeller: I en etablerad faktureringsmodell baseras de primära kostnaderna för filresursen på mängden lagring, IOPS (indata- och utdataåtgärder per sekund) och dataflödet du etablerar när du skapar eller uppdaterar filresursen. Du betalar baserat på vad du tillhandahåller, oavsett hur mycket du faktiskt använder. Azure Files har två olika etablerade modeller: etablerade v2 och etablerade v1.

    • Etablerad v2: I den etablerade v2-modellen för Azure Files har du möjlighet att separat etablera lagring, IOPS och dataflöde, även om vi ger en rekommendation för dig att hjälpa dig med etablering första gången.
    • Etablerad v1: I den etablerade v1-modellen för Azure Files etablerar du den mängd lagringsutrymme som du behöver för resursen, medan IOPS och dataflöde bestäms baserat på hur mycket lagringsutrymme du etablerar. Den etablerade v1-modellen för Azure Files är endast tillgänglig för SSD-filresurser.
  • Faktureringsmodell för användningsbaserad betalning: I en betala per användning-modell baseras kostnaden för filresursen på hur mycket du använder resursen i form av förbrukade lagrings-, transaktions- och dataöverföringskostnader. Modellen betala per användning är endast tillgänglig för HDD-fildelningar. Vi rekommenderar att du använder den etablerade v2-modellen för nya distributioner av HDD-filresurser.

Den här artikeln förklarar hur faktureringsmodellerna för Azure Files fungerar, så att du bättre kan förstå din månatliga Azure Files-faktura. Prisinformation för Azure Files finns på sidan med priser för Azure Files.

Den här videon ger en omfattande översikt över skillnaderna mellan olika Azure Files-faktureringsmodeller, inklusive betala per användning, etablerad v1 och etablerad v2.

Den här videon fördjupar sig i faktureringsmodellen azure files provisioned v2 och erbjuder installationsanvisningar och rekommendationer för att minska den totala ägandekostnaden.

Gäller för

Hanteringsmodell Faktureringsmodell Medienivå Redundans Små och medelstora företag NFS (Network File System)
Microsoft.Storage, lagringstjänster Tillhandahållen v2 HDD (standard) Lokal (LRS) Ja Nej
Microsoft.Storage, lagringstjänster Tillhandahållen v2 HDD (standard) Zon (ZRS) Ja Nej
Microsoft.Storage, lagringstjänster Tillhandahållen v2 HDD (standard) Geo (GRS) Ja Nej
Microsoft.Storage, lagringstjänster Tillhandahållen v2 HDD (standard) GeoZone (GZRS) Ja Nej
Microsoft.Storage, lagringstjänster Tillhandahållen v1 SSD (premie) Lokal (LRS) Ja Ja
Microsoft.Storage, lagringstjänster Tillhandahållen v1 SSD (premie) Zon (ZRS) Ja Ja
Microsoft.Storage, lagringstjänster Betala efter hand HDD (standard) Lokal (LRS) Ja Nej
Microsoft.Storage, lagringstjänster Betala efter hand HDD (standard) Zon (ZRS) Ja Nej
Microsoft.Storage, lagringstjänster Betala efter hand HDD (standard) Geo (GRS) Ja Nej
Microsoft.Storage, lagringstjänster Betala efter hand HDD (standard) GeoZone (GZRS) Ja Nej

Lagringsenheter

Azure Files använder måttenheterna base-2 för att representera lagringskapaciteten: KiB, MiB, GiB och TiB.

Akronym Definition Enhet
KiB 1 024 byte kibibyte
Mib 1 024 KiB (1 048 576 byte) mebibyte
Gib 1 024 MiB (1 073 741 824 byte) gibibyte
Tib 1 024 GiB (1 099 511 627 776 byte) tebibyte

Måttenheterna base-2 används ofta av de flesta operativsystem och verktyg för att mäta lagringskvantiteter. De är dock ofta felmärkta som base-10-enheter, som du kanske är mer bekant med: KB, MB, GB och TB. Den vanligaste orsaken till att operativsystem som Windows felmärkt lagringsenheterna är att många operativsystem började använda dessa förkortningar innan de standardiserades av International Electrotechnical Commission (IEC), International Bureau of Weights and Measures (BIPM) och US National Institute of Standards and Technology (NIST).

Följande tabell visar hur vanliga operativsystem mäter och etiketterar lagring:

Operativsystem Mätsystem Märkning
Windows Bas-2 Misstolkar konsekvent som basen 10.
Linux-distributioner Vanligtvis är det bas 2, men vissa program använder bas 10. Inkonsekvent etikettering, justering mellan mätning och etikettering beror på programvarupaketet.
macOS, iOS och iPad OS Bas-10 Etiketteras konsekvent som base-10.

Kontakta operativsystemets leverantör om operativsystemet inte finns med i listan.

Checklista för total ägandekostnad för fildelning

Om du migrerar till Azure Files från en lokal plats eller jämför Azure Files med andra molnlagringslösningar bör du överväga följande faktorer för att säkerställa en rättvis jämförelse mellan äpplen och äpplen:

  • Hur betalar du för lagring, IOPS och bandbredd? De flesta molnlösningar har modeller som överensstämmer med principerna för antingen etablerad lagring, till exempel prisbestämning och enkelhet, eller betala per användning-lagring, vilket kan optimera kostnaderna genom att bara debitera dig för det du faktiskt använder. Allokerade faktureringsmodeller kan variera beroende på minsta allokerade resursstorlek, allokeringsenhet och möjligheten att öka och minska resurstilldelningen.

  • Finns det några metoder för att optimera lagringskostnaderna? Du kan använda Azure Files-reservationer för att få upp till 36% rabatt på lagring. Andra lösningar kan använda strategier som deduplicering eller komprimering för att optimera lagringseffektiviteten. Dessa strategier för lagringsoptimering har dock ofta icke-monetära kostnader, till exempel att minska prestanda. Azure Files-reservationer har inga sidoeffekter på prestanda.

  • Hur uppnår du lagringsmotståndskraft och överskottskapacitet? Med Azure Files ingår lagringsåterhämtning och redundans i produkterbjudandet. Alla nivåer och redundansnivåer säkerställer att data är mycket tillgängliga och att minst tre kopior av dina data är tillgängliga. När du överväger andra lagringsalternativ bör du överväga om lagringsresiliens och redundans är inbyggt eller något du måste konfigurera själv.

  • Vad behöver du hantera? Azure Files är en fullständigt hanterad lösning. Andra lösningar kan kräva uppdateringar av operativsystemet eller hantering av virtuella resurser, till exempel virtuella datorer, diskar och nätverks-IP-adresser.

  • Vilka är kostnaderna för mervärdesprodukter? Azure Files stöder integreringar med flera mervärdestjänster från första och tredje part. Mervärdestjänster som Azure Backup, Azure File Sync och Microsoft Defender for Storage tillhandahåller säkerhetskopiering, replikering och cachelagring samt säkerhetsfunktioner för Azure Files. Mervärdeslösningar, oavsett om de är lokala eller i molnet, har egna licens- och produktkostnader, men betraktas ofta som en del av den totala ägandekostnaden för fillagring.

Konfigurerad v2-modell

Den etablerade v2-modellen för Azure Files parar förutsägbarheten för den totala ägandekostnaden med flexibilitet, så att du kan skapa en filresurs som uppfyller dina exakta lagrings- och prestandakrav. När du skapar en ny etablerad v2-filresurs anger du hur mycket lagringsutrymme, IOPS och dataflöde som filresursen behöver. Antalet av varje kvantitet som du tilldelar avgör din totala räkning.

Mängden lagringsutrymme, IOPS och dataflöde som du etablerar är de garanterade gränserna för filresursens användning. Om du till exempel etablerar en 2 TiB-resurs och laddar upp 2 TiB data till din resurs blir din resurs full. Du kommer inte att kunna lägga till mer data om du inte ökar storleken på din delning eller tar bort en del av datan. Kreditbaserad IOPS-bursting ger ökad flexibilitet kring användning, i den mån det är möjligt, medan krediterna finns kvar.

Mängden lagringsutrymme, IOPS och dataflöde som du etablerar kan skalas upp eller ned dynamiskt när dina behov ändras. Du kan dock bara minska en etablerad kvantitet efter att 24 timmar har förflutit sedan den senaste kvantitetsökningen. Ändringar i lagring, IOPS och dataflöde gäller inom några minuter efter en etableringsändring.

När du skapar en ny filresurs med hjälp av den etablerade v2-modellen ger vi som standard en rekommendation för hur många IOPS och hur mycket dataflöde du behöver. Detta beräknas baserat på mängden etablerad lagring som du anger. Dessa rekommendationer baseras på typisk kundanvändning för den mängden etablerad lagring för den medienivå du väljer. Du kan dock upptäcka att din arbetsbelastning kräver mer eller mindre IOPS och dataflöde än den "typiska filresursen". I det här fallet kan du etablera mer eller mindre IOPS och dataflöde, beroende på dina individuella filresurskrav.

Tillhandahållen v2-tillgänglighet

Den etablerade v2-modellen tillhandahålls för filresurser i lagringskonton med typen FileStorage-lagringskonto . För närvarande är följande SKU:er för lagringskonto tillgängliga:

typ av lagringskonto SKU för lagringskontot Typ av tillgänglig fildelning
Filförvaring StandardV2_LRS HDD tillhandahållna v2-fildelningar med lokal redundans (LRS) angiven.
Filförvaring StandardV2_ZRS HDD provisionerade v2-fillagringar med zonredundansen (ZRS) angiven.
Filförvaring StandardV2_GRS HDD-provisionerade v2-fildelningar med angiven geo-redundans (GRS).
Filförvaring StandardV2_GZRS HDD-beräknade v2-fildelningar med specifikationen GeoZone (GZRS) redundans.

För närvarande är dessa SKU:er allmänt tillgängliga i en begränsad delmängd av regioner:

  • Alla offentliga Azure-molnregioner.
  • Alla Azure US Government cloud-regioner.

Konfigurerad v2-konfigurationsdetaljer

När du skapar en etablerad v2-filresurs anger du den etablerade kapaciteten för filresursen när det gäller lagring, IOPS och dataflöde. Fildelningar är begränsade baserat på följande attribut:

Objekt HDD-värde
Lagringsetableringsenhet 1 GiB
IOPS-etableringsenhet 1 I/O per sekund
Enhet för tilldelning av genomströmning 1 MiB/sek
Minsta etablerade lagring per fildelningsresurs 32 GiB
Minsta etablerade IOPS per filresurs 500 IOPS
Minsta tilldelade dataflöde per fildelning 60 MiB/s
Maximalt etablerat lagringsutrymme per filresurs 256 TiB (262 144 GiB)
Maximalt tilldelad IOPS per fildelningstjänst 50 000 IOPS
Maximal konfigurerad dataflöde per fildelningsresurs 5 120 MiB/sek
Maximalt etablerat lagringsutrymme per lagringskonto 4 PiB (4 194 304 GiB)
Maximalt etablerat IOPS per lagringskonto 50 000 IOPS
Maximalt etablerat dataflöde per lagringskonto 5 120 MiB/sek
Maximalt antal fildelningar per lagringskonto 50 fildelningar

Som standard rekommenderade vi etablering av IOPS och dataflöde baserat på den etablerade lagring som du anger. Dessa rekommendationsformler baseras på typisk kundanvändning för den mängden etablerad lagring för medienivån i Azure Files:

Formelnamn HDD-formel
IOPS-rekommendation MIN(MAX(1000 + CEILING(0.2 * ProvisionedStorageGiB), 500), 50000)
Rekommendation för genomströmning MIN(MAX(60 + CEILING(0.02 * ProvisionedStorageGiB), 60), 5120)

Beroende på dina individuella filresurskrav kan du upptäcka att du behöver mer eller mindre IOPS eller dataflöde än våra rekommendationer. Du kan också åsidosätta dessa rekommendationer med dina egna värden efter behov.

Provisionerad v2-bursting

Kreditbaserad IOPS-bursting ger ökad flexibilitet kring IOPS-användning. Den här flexibiliteten används bäst som buffert mot oväntade I/O-toppar. För etablerade I/O-mönster rekommenderar vi etablering för I/O-toppar.

Burst IOPS-krediter ackumuleras när trafiken för filresursen är mindre än etablerad (baslinje) IOPS. När en filresurss IOPS-användning överskrider den etablerade IOPS och det finns tillgängliga burst-IOPS-krediter kan filresursen överskrida gränsen för högsta tillåtna burst-IOPS. Filresurser kan fortsätta att utökas så länge det finns krediter kvar, baserat på antalet upplupna burstkrediter. Varje I/O utöver etablerad IOPS förbrukar en kredit. När alla krediter har förbrukats återgår andelen till de provisionerade IOPS. IOPS mot fildelningen behöver inte göra något speciellt för att använda bursting. Bursting fungerar efter bästa förmåga.

Aktiekrediter har tre stater.

  • Ackumuleras när fildelningen använder mindre än de tilldelade IOPS.
  • Nedgång sker när filresursen använder mer än etablerade IOPS och är i sprängläge.
  • Konstant, när filresursen använder exakt den etablerade IOPS och det antingen inte finns några krediter som ackumuleras eller används.

En ny filresurs börjar med det fullständiga antalet krediter i sin burst-bucket. Burst-krediter ackumuleras inte om andel IOPS ligger under den tilldelade gränsen på grund av serverns begränsning. Följande formler används för att fastställa gränsen för burst-IOPS och antalet krediter som är möjliga för en filresurs:

Objekt HDD-formel
Burst-IOPS-gräns MIN(MAX(3 * ProvisionedIOPS, 5000), 50000)
Burst-IOPS-krediter (BurstLimit - ProvisionedIOPS) * 3600

I följande tabell visas några exempel på dessa formler för olika etablerade IOPS-belopp:

Etablerad IOPS Gräns för burst-IOPS för HDD HDD-burstkrediter
500 Upp till 5 000 16,200,000
1 000 Upp till 5 000 14,400,000
3 000 Upp till 9 000 21,600,000
5 000 Upp till 15 000 36,000,000
10 000 Upp till 30 000 72,000,000
25,000 Upp till 50 000 90,000,000
50,000 Upp till 50 000 0

Tilldelade v2-ögonblicksbilder

Azure Files stöder ögonblicksbilder som liknar skuggkopior av volymer (VSS) på Windows File Server. Mer information om ögonblicksbilder för delning finns i Översikt över ögonblicksbilder för Azure Files.

Ögonblicksbilder är alltid differentiella från den aktuella delningen och från varandra. Om den totala differentiella storleken för alla ögonblicksbilder passar inom det överskjutande etablerade lagringsutrymmet för filresursen i den etablerade v2-faktureringsmodellen, finns det ingen extra kostnad för ögonblicksbildlagring. Om storleken på livdelningsdata plus differentialsblidsdata är större än det tilldelade lagringsutrymmet för delningen, debiteras överskriden kapacitet från ögonblicksbilder mot mätaren för överflödig användning av ögonblicksbilder. Formeln för att fastställa mängden spill är: MAX((LiveShareUsedGiB + SnapshotDifferentialUsedGiB) - ProvisionedStorageGiB, 0)

Vissa mervärdestjänster för Azure Files använder ögonblicksbilder som en del av deras värdeförslag. Mer information finns i mervärdestjänster för Azure Files.

Provisionerad mjuk radering av v2

Borttagna filresurser i lagringskonton med mjuk borttagning aktiverat debiteras baserat på den borttagna resursens använda lagringskapacitet för den definierade kvarhållningsperioden. För att säkerställa att en borttagen filresurs alltid kan återställas, räknas den etablerade lagringen, IOPS och dataflödet för filresursens kapacitet mot lagringskontots gränser tills filresursen slutligt tas bort. De faktureras dock inte. Mer information om mjuk borttagning finns i Aktivera mjuk borttagning på Azure-filresurser.

Tillhandahållna v2-faktureringsmätare

Fildelningar som provisioneras med hjälp av den provisionerade v2-faktureringsmodellen faktureras mot följande faktureringsmätare:

  • Etablerad lagring: Mängden lagringsutrymme som har etablerats i GiB.
  • Etablerad IOPS: Mängden IOPS (IO/s) som etablerats.
  • Etablerat dataflöde MiBPS: Mängden dataflöde som etablerats i MiB/s.
  • Överflödsanvändning av ögonblicksbilder: All användning av differentiella ögonblicksbilder i GiB som inte passar in i den konfigurerade lagringskapaciteten. Mer information finns i tillhandahållna v2-snapshots.
  • Soft-Deleted Användning: Använd lagringskapacitet i GiB för mjukt borttagna fildelningsresurser. Mer information finns i tillhandahållen v2 mjuk radering.

Förbrukningsenheter mot de etablerade v2-faktureringsmätarena genereras per timme. För en del med 1 024 GiB tilldelad bör du till exempel se:

  • 1 024 enheter mot den etablerade lagringsmätaren under en enskild timme.
  • 24 576 enheter mot den provisionerade lagringsmätaren om de aggregeras för en dag.
  • Ett variabelt antal enheter om det aggregeras under en månad beroende på antalet dagar i månaden:
    • 28 dagars månad (normal februari): 688 128 enheter mot mätaren för allokerad lagring.
    • 29 dagars månad (skottår februari): 712 704 enheter mot den tilldelade lagringsmätaren .
    • 30 dagar i månaden: 737 280 enheter mot Provisioned Storage-mätaren.
    • En månad med 31 dagar: 761 856 enheter mot Provisionerad lagring.

Tillhandahållna v2-migreringar

Processen för att migrera dina SMB Azure-filresurser från en betala per användning-modell till den etablerade v2-faktureringsmodellen varierar beroende på om du använder Azure File Sync.

Tillhandahållen v1-modell

Den etablerade v1-metoden tillhandahåller lagring, IOPS och dataflöde i ett fast förhållande till varandra, ungefär som hur lagring köps i en lokal lagringslösning. När du skapar en ny tilldelad v1-fillagring anger du hur mycket lagringsutrymme din delning behöver, och IOPS och dataflöde är beräknade värden. Den etablerade v1-modellen för Azure Files är endast tillgänglig för SSD-filresurser.

Mängden lagringsutrymme som du etablerar avgör den garanterade lagrings-, IOPS- och dataflödesgränsen för filresursens användning. Om du till exempel etablerar en 2 TiB-resurs och laddar upp 2 TiB data till din resurs blir din resurs full. Du kommer inte att kunna lägga till mer data om du inte ökar storleken på din andel eller tar bort någon av datan. Kreditbaserad IOPS-bursting ger ökad flexibilitet kring användning, i den mån det är möjligt, medan krediterna finns kvar.

Till skillnad från att köpa lagring lokalt kan etablerade v1-filresurser skalas upp eller ned dynamiskt när dina behov ändras. Du kan dock bara minska den etablerade lagringen efter att 24 timmar har gått sedan den senaste lagringsökningen. Ändringar i lagring, IOPS och dataflöde gäller inom några minuter efter en etableringsändring.

Det går att minska storleken på din allokerade minnesdel till under din använda GiB. Om du gör det förlorar du inte data, men du debiteras fortfarande för den storlek som används. Du får prestanda för den etablerade resursen, inte den storlek som används.

Tillhandahållen v1-tillgänglighet

Den tillgängliga v1-modellen tillhandahålls för SSD-fildelningar i lagringskonton av typen FileStorage.

typ av lagringskonto SKU för lagringskontot Typ av tillgänglig fildelning
Filförvaring Premium_LRS SSD-förberedd v1-fildelning med angiven lokal redundans (LRS).
Filförvaring Premium_ZRS SSD-ansluten v1-fillagring med angiven zonredundans (ZRS).

SSD-fildelningar med den tillhandahållna v1-modellen är allmänt tillgängliga i de flesta Azure-regioner. Mer information finns i Azure-produkter efter region.

Tillhandahållen v1-tillhandahållandedetaljer

När du skapar en etablerad v1-filresurs anger du hur mycket lagringsutrymme din resurs behöver. Varje GiB som du provisionerar ger dig mer IOPS och genomströmning i ett fast förhållande. Fildelningar är begränsade baserat på följande attribut:

Objekt Värde
Lagringsetableringsenhet 1 GiB
Minsta etablerade lagring per fildelningsresurs 100 GiB
Maximalt etablerat lagringsutrymme per filresurs 100 TiB (102 400 GiB)
Maximalt etablerat lagringsutrymme per lagringskonto 100 TiB (102 400 GiB)

Följande formler avgör hur mycket IOPS och dataflöde som tillhandahålls på delningen.

Objekt Formel
Beräknad tilldelad (baslinje) IOPS MIN(3000 + 1 * ProvisionedStorageGiB, 102400)
Beräknat etablerat dataflöde (MiB/s) 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)

Beroende på dina individuella filresurskrav kan du upptäcka att du behöver mer IOPS eller dataflöde än vad som anges i våra etableringsformler. I det här fallet måste du etablera mer lagringsutrymme för att få det nödvändiga IOPS- eller dataflödet.

Tilldelad v1-bursting

Den etablerade v1-modellen har stöd för två typer av bursting: kreditbaserad bursting, som ingår kostnadsfritt som en del av etableringen och betald bursting, vilket är en avancerad funktion som du kan aktivera om du vill för att stödja användningsbaserad fakturering när IOPS och dataflödet överskrider det etablerade beloppet.

Provisionerad v1-kreditbaserad bursting

Kreditbaserad IOPS-bursting ger ökad flexibilitet kring IOPS-användning. Den här flexibiliteten används bäst som buffert mot oväntade I/O-toppar. För etablerade I/O-mönster rekommenderar vi etablering för I/O-toppar.

Burst IOPS-krediter ackumuleras när trafiken för filresursen är mindre än etablerad (baslinje) IOPS. När en filresurss IOPS-användning överskrider den etablerade IOPS och det finns tillgängliga burst-IOPS-krediter kan filresursen överskrida gränsen för högsta tillåtna burst-IOPS. Filresurser kan fortsätta att utökas så länge det finns krediter kvar, baserat på antalet upplupna burstkrediter. Varje I/O utöver etablerad IOPS förbrukar en kredit. När alla krediter har förbrukats återgår andelen till de provisionerade IOPS. IOPS mot fildelningen behöver inte göra något speciellt för att använda bursting. Bursting fungerar efter bästa förmåga.

Aktiekrediter har tre stater.

  • Ackumuleras när fildelningen använder mindre än de tilldelade IOPS.
  • Nedgång sker när filresursen använder mer än etablerade IOPS och är i sprängläge.
  • Konstant, när filresursen använder exakt den etablerade IOPS och det antingen inte finns några krediter som ackumuleras eller används.

En ny filresurs börjar med det fullständiga antalet krediter i sin burst-bucket. Burst-krediter ackumuleras inte om andel IOPS ligger under den tilldelade gränsen på grund av serverns begränsning. Följande formler används för att fastställa gränsen för burst-IOPS och antalet krediter som är möjliga för en filresurs:

Objekt Formel
Gräns för utbrott MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400)
Burstkrediter (BurstLimit - BaselineIOPS) * 3600

I följande tabell visas några exempel på dessa formler för de etablerade resursstorlekarna:

Kapacitet (GiB) Baslinje-IOPS Burst-IOPS Burst-krediter Dataflöde (ingress + utgående) (MiB/s)
100 3,100 Upp till 10 000 24,840,000 110
500 3 500 Upp till 10 000 23,400,000 150
1,024 4,024 Upp till 10 000 21,513,600 203
5,120 8 120 Upp till 15 360 26,064,000 613
10,240 13,240 Upp till 30 720 62,928,000 1,125
33,792 36,792 Upp till 102 400 227,548,800 3,480
51 200 54,200 Upp till 102 400 164,880,000 5 220
102,400 102,400 Upp till 102 400 0 10,340

Provisionerad v1 betalad burstkapacitet

Betald bursting är en avancerad funktion i den etablerade v1-modellen som är utformad för att stödja kunder som aldrig vill begränsas. Betald bursting lägger till extra användningsbaserad fakturering för alla IOPS- eller dataflöden ovanför den etablerade lagringen. Detta skiljer sig från kreditbaserad bursting som ingår kostnadsfritt som en del av tillhandahållen lagring. Betald bursting kan ge kraftfull flexibilitet i hur du etablerar din filresurs, men det kan också leda till oväntad fakturering om den används felaktigt.

Precis som kreditbaserad överbelastning är betald överbelastning inte en ersättning för att tillhandahålla rätt mängd IOPS och dataflöde. I stället ger det ytterligare skydd mot begränsning om du stöter på oväntad efterfrågan. Om du har en konsekvent nivå av IOPS- eller dataflödesanvändning är det billigare att etablera tillräckligt med IOPS och dataflöde (via lagringsetablering) för att täcka efterfrågan i stället för att förlita sig på betald bursting.

Betald bursting är inaktiverad som standard, men du kan aktivera den genom att följa anvisningarna för att ändra kostnads- och prestandaegenskaperna för en etablerad v1-filresurs (endast PowerShell och CLI). Om betald bursting är aktiverat rekommenderar vi att du noggrant övervakar IOPS- och dataflödesanvändningen med hjälp av följande mått som är tillgängliga via Azure Monitor:

  • Provisionerad IOPS för fildelning
  • Tilldelad Bandbredd för Fildelning MiB/s (genomströmning)
  • Transaktioner efter Max IOPS
  • Bandbredd baserat på Max MiB/s (dataflöde)
  • Burst-krediter för IOPS (kreditbaserad bursting)
  • Betalda Burstning IOS (I/O-gränssnitt)
  • Betald dynamisk bandbredd

Provisionerade v1-ögonblicksbilder

Azure Files stöder ögonblicksbilder som liknar skuggkopior av volymer (VSS) på Windows File Server. Mer information om ögonblicksbilder för delning finns i Översikt över ögonblicksbilder för Azure Files.

Ögonblicksbilder är alltid differentiella från den aktuella delningen och från varandra. I den etablerade v1-faktureringsmodellen debiteras den totala differentiella storleken mot en användningsmätare, oavsett hur mycket etablerad lagring som inte används. Den använda ögonblicksbildslagringsmätaren har ett lägre pris jämfört med det etablerade lagringspriset.

Konfigurerad mjuk borttagning av v1

Borttagna filresurser i lagringskonton med mjuk borttagning aktiverat debiteras baserat på den borttagna resursens använda lagringskapacitet för den definierade kvarhållningsperioden. Den temporärt borttagna användningslagringskapaciteten beräknas mot den använda ögonblicksbildlagringsmätaren. Mer information om mjuk borttagning finns i Aktivera mjuk borttagning på Azure-filresurser.

Konfigurerade v1-faktureringsmätare

Filresurser och delningar som tilldelas med den tilldelade v1-faktureringsmodellen faktureras mot följande mätare:

  • Premium Provisioned: Mängden lagringsutrymme som allokerats i GiB.
  • Premium-ögonblicksbilder: Antalet använda ögonblicksbilder och använd kapacitet för mjukborttagna objekt.

Förbrukning mot de tillhandahållna v1-faktureringsmätarna genereras per timme i termer av månatliga enheter. För en del med 1 024 GiB tilldelad bör du till exempel se:

  • Ett variabelt antal enheter för en enskild timme beroende på antalet dagar i månaden:
    • 28 dagars månad (normal februari): 1,5238 enheter mot Premium Provisioned-mätaren .
    • 29 dagars månad (skottår februari): 1,4713 enheter i jämförelse med Premium Provisioned-mätaren.
    • 30 dagars månad: 1.4222 enheter mot Premium Provisioned-mätaren.
    • En månad med 31 dagar: 1,3763 enheter mot Premium Provisioned-mätare.
  • Ett variabelt antal enheter om det aggregeras för en dag beroende på antalet dagar i månaden:
    • 28-dagarsmånad (normal februari): 36,5714 enheter mot Premium Provisioned-mätaren.
    • 29 dagars månad (februari i skottår): 35,3103 enheter mot mätaren för Premium Provisioned.
    • 30-dagarsmånad: 34,1333 enheter på Premium Provisioned-mätaren.
    • Månad med 31 dagar: 33,0323 enheter mot Premium Provisioned-mätaren.
  • 1 024 enheter för Premium Provisioned-mätaren om den sammanställs över en månad.

Betala efter användning

I 'betala efter användning'-modellen debiteras du för hur mycket lagringsutrymme du använder, inte hur mycket du reserverar. På en hög nivå betalar du en kostnad för mängden logiska data som lagras och du debiteras även för transaktioner baserat på din användning av dessa data. Fakturering per användning kan vara svår att planera för som en del av en budgeteringsprocess, eftersom du betalar baserat på slutanvändarens förbrukning. Vi rekommenderar därför att du använder den etablerade v2-modellen för nya filresursdistributioner. Modellen betala per användning är endast tillgänglig för HDD-fildelningar.

Tillgänglighet för betalning per användning

Modellen "betalning efter användning" tillhandahålls för HDD-fildelningar i lagringskonton av typen StorageV2 eller Storage.

typ av lagringskonto SKU för lagringskontot Typ av tillgänglig fildelning
StorageV2 eller Storage Standard_LRS HDD-fillagring med betala efter användning och den angivna lokala redundansen (LRS).
StorageV2 eller Storage Standard_ZRS HDD-filresurs med betalning efter användning med angiven ZRS-redundans.
StorageV2 eller Storage Standard_GRS HDD-fildelning med betalning per användning och specificerad geografisk redundans (GRS).
StorageV2 eller Storage Standard_GZRS HDD-fildelning betala efter användning med GeoZone (GZRS) redundans specificerad.

HDD-fildelningar med betala efter användning-modellen är tillgängliga i alla Azure-regioner.

Skillnader i åtkomstnivåer

När du skapar en HDD-filresursdelning väljer du mellan följande åtkomstnivåer: transaktionsoptimerad, het och kall. Alla tre åtkomstnivåerna lagras på exakt samma lagringsmaskinvara. Den största skillnaden för dessa tre åtkomstnivåer är deras lagringspriser för vilande data, som är lägre i lågfrekventa nivåer, och transaktionspriserna, som är högre på lågfrekventa nivåer. Detta innebär att:

  • Transaktionsoptimerad, som namnet antyder, optimerar priset för hög IOPS-transaktionsarbetsbelastning. Transaktionsoptimerad har den högsta lagringskostnaden för vilande data, men de lägsta transaktionspriserna.
  • Het är för aktiva arbeten som inte omfattar ett stort antal transaktioner. Den har ett något lägre lagringspris för vilande data, men något högre transaktionspriser jämfört med transaktionsoptimerade. Se det som en medelväg mellan transaktionsoptimerade och kyliga nivåer.
  • Cool optimerar priset för arbetsbelastningar som inte har hög aktivitet och erbjuder det lägsta lagringspriset för vilande data, men de högsta transaktionspriserna.

Genom att välja lämplig åtkomstnivå för ditt användningsfall kan du avsevärt minska dina kostnader. Om du placerar en arbetsbelastning som används sällan på den transaktionsoptimerade åtkomstnivån betalar du nästan ingenting för de få gånger under en månad som du gör transaktioner mot din resurs. Du betalar dock ett högt belopp för kostnaderna för datalagring. Om du flyttade samma resurs till lågfrekvent åtkomstnivå skulle du fortfarande betala nästan ingenting för transaktionskostnaderna, bara för att du sällan gör transaktioner för den här arbetsbelastningen. Den lågfrekventa åtkomstnivån har dock ett billigare datalagringspris.

På samma sätt betalar du mycket mer i transaktionskostnader, men mindre för kostnader för datalagring, om du placerar en arbetsbelastning med hög åtkomst på lågfrekvent åtkomstnivå. Detta kan leda till en situation där de ökade kostnaderna för transaktionspriser överskrider besparingarna från det minskade datalagringspriset, och du kan betala mer för kallt lagring än vad du skulle ha betalat för optimerad för transaktioner. För vissa användningsnivåer är det möjligt att den varma åtkomstnivån är den mest kostnadseffektiva och att den låga åtkomstnivån blir dyrare än den transaktionsoptimerade nivå.

Din arbetsbelastnings- och aktivitetsnivå avgör den mest kostnadseffektiva åtkomstnivån för din betala per användning-filresurs. I praktiken är det bästa sättet att välja den mest kostnadseffektiva åtkomstnivån att titta på resursens faktiska resursförbrukning (lagrade data, skrivtransaktioner osv.). För betala per användning-filresurser rekommenderar vi att du börjar på den transaktionsoptimerade nivån under den första migreringen till Azure Files och sedan väljer rätt åtkomstnivå baserat på användning när migreringen är klar. Transaktionsanvändning under migreringen är vanligtvis inte ett tecken på normal transaktionsanvändning.

Vad är transaktioner?

När du monterar en Azure-filresurs på en dator med SMB exponeras Azure-filresursen på datorn som om den vore lokal lagring. Det innebär att program, skript och andra program på datorn kan komma åt filer och mappar på Azure-filresursen utan att behöva veta att de lagras i Azure.

När du läser eller skriver till en fil utför programmet som du använder en serie API-anrop till filsystem-API:et som tillhandahålls av operativsystemet. Operativsystemet tolkar sedan dessa anrop till SMB-protokolltransaktioner som skickas via kabeln till Azure Files för att uppfylla. En enkel uppgift som slutanvändaren uppfattar som en enda åtgärd, till exempel att läsa en fil från början till slut, kan översättas till flera SMB-transaktioner som hanteras av Azure Files.

I princip debiterar pay-as-you-go-faktureringsmodellen som används av standard filresurser baserat på användning. SMB- och FileREST-transaktioner som görs av program och skript representerar användningen av din filresurs, och de visas som en del av din faktura. Samma koncept gäller för mervärdesmolntjänster som du kan lägga till i din resurs, till exempel Azure File Sync eller Azure Backup.

Transaktioner grupperas i fem olika transaktionskategorier som har olika priser baserat på deras inverkan på Azure-filresursen. Dessa kategorier är: skriva, lista, läsa, andra och ta bort.

I följande tabell visas kategoriseringen för varje transaktion:

Transaktionskategori Hanteringsåtgärder Dataåtgärder
Skriv transaktioner
  • CreateShare
  • SetFileServiceProperties
  • SetShareMetadata
  • SetShareProperties
  • SetShareAcl
  • SnapshotShare
  • RestoreShare
  • CopyFile
  • Create
  • CreateDirectory
  • CreateFile
  • PutRange
  • PutRangeFromURL
  • SetDirectoryMetadata
  • SetFileMetadata
  • SetFileProperties
  • SetInfo
  • Write
  • PutFilePermission
  • Flush
  • SetDirectoryProperties
Lista transaktioner
  • ListShares
  • ListFileRanges
  • ListFiles
  • ListHandles
Lästa transaktioner
  • GetFileServiceProperties
  • GetShareAcl
  • GetShareMetadata
  • GetShareProperties
  • GetShareStats
  • FilePreflightRequest
  • GetDirectoryMetadata
  • GetDirectoryProperties
  • GetFile
  • GetFileCopyInformation
  • GetFileMetadata
  • GetFileProperties
  • QueryDirectory
  • QueryInfo
  • Read
  • GetFilePermission
Andra och protokolltransaktioner
  • AcquireShareLease
  • BreakShareLease
  • ReleaseShareLease
  • RenewShareLease
  • ChangeShareLease
  • AbortCopyFile
  • Cancel
  • ChangeNotify
  • Close
  • Echo
  • Ioctl
  • Lock
  • Logoff
  • Negotiate
  • OplockBreak
  • SessionSetup
  • TreeConnect
  • TreeDisconnect
  • CloseHandles
  • AcquireFileLease
  • BreakFileLease
  • ChangeFileLease
  • ReleaseFileLease
Ta bort transaktioner
  • DeleteShare
  • ClearRange
  • DeleteDirectory
  • DeleteFile

Anteckning

NFSv4.1 är endast tillgängligt för SSD-fildelningar, som använder en provisionerad faktureringsmodell. Transaktionsbehållare påverkar inte faktureringen för allokerade filresurser.

Växla mellan åtkomstnivåer

Även om du kan ändra en betala per användning-filresurs mellan de tre åtkomstnivåerna är bästa praxis att optimera kostnaderna efter den inledande migreringen att välja den mest kostnadsoptimala åtkomstnivån som ska finnas i och stanna där om inte ditt åtkomstmönster ändras. Detta beror på att en ändring av åtkomstnivån för en standardfilresurs resulterar i extra kostnader på följande sätt:

  • Transaktioner: När du flyttar en resurs från en varmare åtkomstnivå till en lågfrekvent åtkomstnivå debiteras du den coolare åtkomstnivåns skrivtransaktionsavgift för varje fil i resursen. Om du flyttar en filresurs från en lågfrekvent åtkomstnivå till en varmare åtkomstnivå debiteras coolare åtkomstnivås lästransaktionsavgift för varje fil i resursen.

  • Datahämtning: Om du flyttar från lågfrekvent åtkomstnivå till frekvent eller transaktionsoptimerad debiteras du en datahämtningsavgift baserat på storleken på data som flyttas. Endast "cool" åtkomstnivån har en avgift för datahämtning.

I följande tabell visas kostnadsuppdelningen för att flytta åtkomstnivåer:

Åtkomstnivå Transaktionsoptimerad (mål) Populär (destination) Lågfrekvent (mål)
Transaktionsoptimerad (källa) --
  • En snabbskrivningstransaktion per fil.
  • En lågfrekvent skrivtransaktion per fil.
Frekvent (källa)
  • En snabbläst transaktion per fil.
    --
    • En lågfrekvent skrivtransaktion per fil.
    Cool (källa)
    • En effektiv läsoperation per fil.
    • Datahämtning per totalt använda GiB.
    • En effektiv läsoperation per fil.
    • Datahämtning per totalt använda GiB.
    --

    Du kan ändra åtkomstnivån för en filresurs upp till fem gånger inom ett 30-dagarsfönster. Den första dagen i 30-dagarsfönstret börjar när ändringen på den första nivån sker. Ändringar mellan åtkomstnivåer sker direkt, men när du ändrar åtkomstnivån för en resurs kan du inte ändra den igen inom 24 timmar, även om du har ändrat åtkomstnivåegenskapen mindre än fem gånger under de senaste 30 dagarna.

    Välja en åtkomstnivå

    Oavsett hur du migrerar befintliga data till Azure Files rekommenderar vi att du först skapar filresursen på den transaktionsoptimerade åtkomstnivån. Detta beror på det stora antalet transaktioner som uppstår under migreringen. När migreringen är klar och du arbetar i några dagar eller veckor med regelbunden användning kan du ansluta dina transaktionsantal till priskalkylatorn för att avgöra vilken åtkomstnivå som passar bäst för din arbetsbelastning.

    Eftersom betala per användning-filresurser endast visar transaktionsinformation på lagringskontonivå är det en ofullkomlig vetenskap att använda lagringsmåtten för att uppskatta vilken åtkomstnivå som är billigare på filresursnivå. Om möjligt rekommenderar vi att du bara distribuerar en filresurs i varje lagringskonto för att säkerställa fullständig insyn i faktureringen.

    Så här ser du tidigare transaktioner:

    1. Navigera till ditt lagringskonto i Azure-portalen.
    2. I tjänstmenyn under Övervakning väljer du Mått.
    3. Välj Omfång som lagringskontonamn, Mätvariabelsnamnområde som "Fil", Mätvariabel som "Transaktioner" och Aggregation som "Summa".
    4. Välj Använd delning.
    5. Välj Värden som "API-namn". Välj önskad gräns och sortera.
    6. Välj önskad tidsperiod.

    Anteckning

    Se till att du visar transaktioner under en tillräckligt lång tidsperiod för att få en realistisk uppfattning om genomsnittligt antal transaktioner. Se till att den period du valt inte överlappar den inledande etableringsfasen. Multiplicera det genomsnittliga antalet transaktioner under den här tidsperioden för att hämta de uppskattade transaktionerna för en hel månad.

    Betala per användning-ögonblicksbilder

    Azure Files stöder ögonblicksbilder som liknar skuggkopior av volymer (VSS) på Windows File Server. Mer information om ögonblicksbilder för delning finns i Översikt över ögonblicksbilder för Azure Files.

    Ögonblicksbilder är alltid differentiella från den aktuella delningen och från varandra. I betalningsmodellen 'betala per användning' debiteras den totala skillnaden i storlek mot den vanliga mätaren för lagringsanvändning. Det innebär att du inte ser en separat post på din faktura för ögonblicksbilder för ditt lagringskonto med betalning per användning. Det innebär också att användning av differentiella ögonblicksbilder räknas mot reservationer som köps för fildelningar med betalning efter användning.

    Betala efter användning mjuk radering

    Borttagna filresurser i lagringskonton med mjuk borttagning aktiverat debiteras baserat på den borttagna filresursens använda lagringskapacitet för den definierade kvarhållningsperioden. Den mjukt borttagna använda lagringskapaciteten emitteras mot den normala använda lagringsmätaren. Det innebär att du inte ser en separat post på din faktura som representerar mjukborttagna fildelningar för ditt lagringskonto med betalning per användning. Det innebär också att användningen av mjukt borttagna fildelningar räknas mot reservationer som köps för fildelningar med betalning per användning.

    Mätare för betalning efter användning

    Filresurser som skapats med faktureringsmodellen "betala per användning" debiteras mot följande mätare:

    • Lagrade data: Den använda lagringen, inklusive livedelningar, differentiella ögonblicksbilder och fildelningar med mjuk borttagning i GiB.
    • Metadata: Storleken på filsystemets metadata som är associerade med filer och kataloger som åtkomstkontrollistor (ACL) och andra egenskaper i GiB. Den här faktureringsmätaren används endast för fildelningar på de varma eller kalla åtkomstnivåerna.
    • Skrivåtgärder: Antal hinkar för skrivtransaktioner (per hink = 10 000 transaktioner).
    • Liståtgärder: Antalet listtransaktions bucketar (en bucket = 10 000 transaktioner).
    • Läsåtgärder: Antalet lästa transaktionsbucketar (en bucket = 10 000 transaktioner).
    • Andra åtgärder / Protokollåtgärder: Antalet andra transaktions bucketar (en bucket = 10 000 transaktioner).
    • Datahämtning: Mängden data som lästs från filresursen i GiB. Den här mätaren används endast för filresurser på Cool-åtkomstnivån.
    • Geo-Replication Dataöverföring: Om fildelningen har geo- eller geozonredundans replikeras mängden data som skrivits till fildelningen till den sekundära regionen i GiB.

    Förbrukningsenheter för faktureringsmätarna lagrade data och metadata genereras per timme, uttryckt i månatliga enheter. För en resurs med 1 024 använda GiB bör du till exempel se:

    • Ett variabelt antal enheter för en enskild timme beroende på antalet dagar i månaden:
      • 28 dagars månad (normal februari): 1,5238 enheter mot den lagrade data mätaren.
      • 29 dagars månad (skottår februari): 1,4713 enheter mot mätaren för lagrad data.
      • 30 dagar i månaden: 1,4222 enheter mot den lagrade datamätaren .
      • Månad med 31 dagar: 1,3763 enheter mot datalagringsmätaren.
    • Ett variabelt antal enheter om det aggregeras för en dag beroende på antalet dagar i månaden:
      • 28 dagars månad (normal i februari): 36,5714 enheter mot mätaren för lagrad data.
      • 29 dagars månad (skottår februari): 35.3103 enheter på Data Stored-mätaren.
      • 30-dagars månad: 34,1333 enheter mot lagrad data-mätare.
      • 31 dagar i månads: 33,0323 enheter mot Data Stored-mätare.
    • 1 024 enheter mot datamängd lagrad-mätare om det aggregeras över en månad.

    Förbrukning mot de andra mätarna (t.ex. skrivåtgärder eller datahämtning) genereras per timme, men eftersom de inte genereras i termer av en tidsram har du inga särskilda enhetstransformeringar att känna till.

    Tilldelad/kvot, logisk storlek och fysisk storlek

    Azure Files spårar tre distinkta kvantiteter med avseende på resurskapacitet:

    • Etablerad storlek eller kvot: Med både etablerade och betala per användning-filresurser anger du den maximala storlek som filresursen får växa till. I kapacitetsallokerade filresurser kallas detta värde för den allokerade storleken. Oavsett vilket belopp du etablerar är det du betalar för, oavsett hur mycket du faktiskt använder. I fildelningar med betalning per användning kallas detta värde kvot och påverkar inte din faktura direkt. Provisionerad storlek är ett obligatoriskt fält för provisionerade fildelningar. För betala per användning-fildelningar, om den tilldelade storleken inte anges direkt, har fildelningen standardvärdet satt till det maximala värde som lagringskontot stöder (100 TiB).

    • Logisk storlek: Den logiska storleken på en filresurs eller fil relaterar till hur stor den är utan att tänka på hur den faktiskt lagras, utan någon lagringsoptimering. Den logiska storleken på filen är hur många KiB/MiB/GiB som skulle överföras via kabeln om du kopierade den till en annan plats. I både etablerade och betala per användning-filresurser används den totala logiska storleken för filresursen för tillämpning mot etablerad storlek/kvot. I fildelningar med betala per användning används den logiska storleken för att fakturera stillastående datanvändning. Logisk storlek kallas "storlek" i dialogrutan Windows-egenskaper för en fil/mapp och som "innehållslängd" efter Azure Files-mått.

    • Fysisk storlek: Den fysiska storleken på filen relaterar till storleken på filen som kodad på disken. Den fysiska storleken kan anpassas efter filens logiska storlek, eller så kan den vara mindre, beroende på hur filen har skrivits till av operativsystemet. En vanlig orsak till att den logiska storleken och den fysiska storleken skiljer sig är att använda glesa filer. Den fysiska storleken på filerna i resursen används för fakturering av ögonblicksbilder, även om allokerade intervall delas mellan ögonblicksbilder om de är oförändrade (differentiell lagring).

    Mervärdestjänster

    Precis som många lokala lagringslösningar tillhandahåller Azure Files integreringsplatser för produkter från första och tredje part som kan integreras med kundägda filresurser. Även om de här lösningarna kan ge ett betydande extra värde till Azure Files bör du överväga de extra kostnader som dessa tjänster lägger till den totala kostnaden för en Azure Files-lösning.

    Kostnaderna delas upp i tre bucketar:

    • Licensieringskostnader för mervärdestjänsten. Licenskostnader kan komma i form av en fast kostnad per kund, slutanvändare (kallas ibland "huvudkostnad"), Azure-filresurs eller lagringskonto. De kan också baseras på lagringsenheter, till exempel en fast kostnad för varje 500 GiB-segment av data i filresursen.

    • Transaktionskostnader för mervärdestjänsten. Vissa mervärdestjänster har ett eget koncept för transaktioner ovanpå den valda Azure Files-faktureringsmodellen. Dessa transaktioner visas på din faktura under mervärdestjänstens avgifter. De relaterar dock direkt till hur du använder mervärdestjänsten med din filresurs.

    • Azure Files kostar för att använda en mervärdestjänst. Azure Files debiterar inte kunder direkt för att lägga till mervärdestjänster, men som en del av att lägga till värde i Azure-filresursen kan mervärdestjänsten öka kostnaderna som du ser på din Azure-filresurs. Dessa kostnader är lätta att se med filresurser som betalas per användning på grund av transaktionsavgifter. Om mervärdestjänsten utför transaktioner mot filresursen för din räkning visas de i din Azure Files-transaktionsfaktura även om du inte gjorde transaktionerna direkt själv. Detta gäller även för tilldelade fildelningar, även om det kan vara mindre märkbart. Transaktioner mot etablerade filresurser från mervärdestjänster räknas mot dina etablerade IOPS-nummer, vilket innebär att mervärdestjänster kan kräva etablering av mer lagring för att ha tillräckligt med IOPS eller dataflöde tillgängligt för din arbetsbelastning.

    När du beräknar den totala ägandekostnaden för din filresurs bör du överväga kostnaderna för Azure Files och alla mervärdestjänster som du vill använda med Azure Files.

    Det finns flera mervärdestjänster från första och tredje part. Det här dokumentet beskriver en delmängd av de vanliga tjänster från första part som kunder använder med Azure-filresurser. Du kan läsa mer om tjänster som inte visas här genom att läsa prissidan för den tjänsten.

    Azure File Sync

    Azure File Sync är en mervärdestjänst för Azure Files som synkroniserar en eller flera lokala Windows-filresurser med en Azure-filresurs. Eftersom Azure-molnfilresursen har en fullständig kopia av data i en synkroniserad filresurs som är tillgänglig lokalt, kan du omvandla din lokala Windows-filserver till en cache av Azure-filresursen för att minska ditt lokala fotavtryck. Läs mer genom att läsa Introduktion till Azure File Sync.

    När du överväger den totala ägandekostnaden för en lösning som distribuerats med Azure File Sync bör du överväga följande kostnadsaspekter:

    • Kapital- och driftskostnader för Windows-filservrar med en eller flera serverslutpunkter. Azure File Sync som replikeringslösning är oberoende av var Windows-filservrarna som synkroniseras med Azure Files finns. de kan finnas lokalt, på en virtuell Azure-dator eller till och med i ett annat moln. Om du inte använder Azure File Sync med en Windows-filserver som finns på en virtuell Azure-dator, kommer kapitalkostnaderna (dvs. de initiala maskinvarukostnaderna för din lösning) och driftskostnaderna (dvs. kostnaden för arbete, el osv.) inte att vara en del av din Azure-faktura, men kommer fortfarande att vara en stor del av din totala ägandekostnad. Du bör tänka på hur mycket data du behöver cachelagrar lokalt, antalet processorer och mängden minne som dina Windows-filservrar behöver för att vara värd för Azure File Sync-arbetsbelastningar (se rekommenderade systemresurser för mer information) och andra organisationsspecifika kostnader som du kan ha.

    • Licensieringskostnad per server för servrar som registrerats med Azure File Sync. Om du vill använda Azure File Sync med en specifik Windows-filserver måste du först registrera den med Azure File Syncs Azure-resurs, Storage Sync Service. Varje server som du registrerar efter den första servern har en fast månadsavgift. Även om den här avgiften är mycket liten är den en del av din faktura att tänka på. Information om det aktuella priset för serverregistreringsavgiften för önskad region finns i avsnittet Filsynkronisering på prissättningssidan för Azure Files.

    • Kostnader för Azure Files. Eftersom Azure File Sync är en synkroniseringslösning för Azure Files gör det att du använder Azure Files-resurser. Vissa av dessa resurser, till exempel lagringsförbrukning, är relativt uppenbara, medan andra som transaktions- och ögonblicksbildsanvändning kanske inte är det. För de flesta kunder rekommenderar vi att du använder standardfilresurser med Azure File Sync, även om Azure File Sync stöds fullt ut med premiumfilresurser om så önskas.

      • Lagringsanvändning. Azure File Sync replikerar alla ändringar som du har gjort i filvägen på din Windows-filserver som angetts på serverslutpunkten till din Azure-filresursdelning och därmed förbrukas lagringsutrymmet. På standardfilresurser innebär det att om du lägger till eller ökar storleken på befintliga filer på serverslutpunkter ökar lagringskostnaderna eftersom ändringarna replikeras. På premiumfilresurser kommer ändringar att förbruka etablerat utrymme – det är ditt ansvar att regelbundet öka etableringen efter behov för att ta hänsyn till filresurstillväxten.

      • Användning av ögonblicksbilder. Azure File Sync tar ögonblicksbilder på resurs- och filnivå som en del av den regelbundna användningen. Även om användningen av ögonblicksbilder alltid är differentiell kan detta bidra på ett märkbart sätt till den totala Azure Files-fakturan.

      • Transaktioner från kundbortfall. När filerna ändras på serverslutpunkter laddas ändringarna upp till molnresursen, vilket genererar transaktioner. När molnnivåindelning är aktiverat genereras ytterligare transaktioner för hantering av nivåindelade filer, inklusive I/O som sker på nivåindelade filer, utöver utgående kostnader. Även om antalet och typen av transaktioner är svåra att förutsäga på grund av omsättningshastigheter och cacheeffektivitet kan du använda dina tidigare transaktionsmönster för att beräkna framtida kostnader om du tror att din framtida användning kommer att likna din aktuella användning.

      • Transaktioner från molnuppräkning. Azure File Sync räknar upp Azure-filresursen i molnet en gång per dag för att identifiera ändringar som har gjorts direkt i resursen så att de kan synkronisera ned till serverslutpunkterna. Den här genomsökningen genererar transaktioner som faktureras till lagringskontot med en hastighet av en ListFiles transaktion per katalog per dag. Du kan placera det här numret i priskalkylatorn för att beräkna genomsökningskostnaden.

      Tips

      Om du inte vet hur många mappar du har kan du titta på TreeSize-verktyget från JAM Software GmbH.

    Azure Backup

    Azure Backup tillhandahåller en serverlös säkerhetskopieringslösning för Azure Files som sömlöst integreras med dina filresurser och med andra mervärdestjänster som Azure File Sync. Azure Backup för Azure Files är en lösning för ögonblicksbildsbaserad säkerhetskopiering som tillhandahåller en schemaläggningsmekanism för att automatiskt ta ögonblicksbilder enligt ett administratörsdefinierat schema. Det ger också ett användarvänligt gränssnitt för att återställa borttagna filer/mappar eller hela resursen till en viss tidpunkt. Mer information finns i Om säkerhetskopiering av Azure-filresurser.

    Tänk på följande faktorer när du överväger kostnaderna för att använda Azure Backup:

    • Licensieringskostnad för skyddade instanser av data i Azure-fildelning. Azure Backup debiterar en licenskostnad för skyddad instans per lagringskonto som innehåller säkerhetskopierade Azure-filresurser. En skyddad instans definieras som 250 GiB för Azure-filresurslagring. Lagringskonton som innehåller mindre än 250 GiB omfattas av en fraktionell skyddad instanskostnad. Mer information finns i Priser för Azure Backup. Du måste välja Azure Files i listan över tjänster som Azure Backup kan skydda.

    • Kostnader för Azure Files. Azure Backup ökar kostnaderna för Azure Files på följande sätt:

      • Differentiella kostnader från skuggkopior av Azure-filresurser. Azure Backup automatiserar tagning av ögonblicksbilder av Azure-filresurser enligt ett administratörsdefinierat schema. Ögonblicksbilder är alltid differentiella. Den extra kostnaden som läggs till beror dock på hur lång tid ögonblicksbilder sparas och mängden omsättning på filresursen under den tiden. Dessa faktorer avgör hur ögonblicksbilden skiljer sig från den aktuella fildelningen och därför hur mycket extra data som lagras av Azure Files.

      • Transaktionskostnader från återställningsåtgärder. Återställningsåtgärder från ögonblicksbilden till direktdelningen medför transaktionskostnader. För standardfildelningar faktureras läsningar från snapshots och skrivningar vid återställning som normala filresurstransaktioner. För etablerade filresurser räknas dessa åtgärder mot den etablerade IOPS för filresursen.

    Microsoft Defender för Lagring

    Microsoft Defender stöder Azure Files som en del av produkten Microsoft Defender for Storage. Microsoft Defender för Storage identifierar ovanliga och potentiellt skadliga försök att komma åt eller utnyttja dina Azure-filresurser via SMB eller FileREST. Microsoft Defender för Storage är aktiverat för prenumerationsnivån för alla fildelningar inom lagringskonton i den prenumerationen.

    Microsoft Defender för Storage stöder inte antivirusfunktioner för Azure-filresurser.

    Den största kostnaden från Microsoft Defender för Storage är en extra uppsättning transaktionskostnader som produkten tar ut utöver de transaktioner som görs mot Azure-filresursen. Även om dessa kostnader baseras på de transaktioner som uppstår i Azure Files är de inte en del av faktureringen för Azure Files, utan ingår i Microsoft Defender-prissättningen. Microsoft Defender for Storage debiterar en transaktionsfrekvens även för etablerade filresurser, där Azure Files inkluderar transaktioner som en del av IOPS-etableringen. Den aktuella transaktionsfrekvensen finns på prissättningssidan för Microsoft Defender för molnet under tabellraden Microsoft Defender för lagring .

    Transaktionsintensiva fildelningar medför betydande kostnader med Microsoft Defender för lagring. Baserat på dessa kostnader kanske du vill välja bort Microsoft Defender för Storage för specifika lagringskonton. Mer information finns i Exkludera ett lagringskonto från Microsoft Defender för lagringsskydd.

    Reservationer

    Azure Files stöder reservationer (kallas även reserverade instanser) för de etablerade v1- och betala per användning-modellerna. Med reservationer kan du få rabatt på lagring genom att i förväg åta dig lagringsanvändning. Du bör överväga att köpa reserverade instanser för alla produktionsuppgifter eller utvecklings-/testuppgifter med konsekvent användning. När du köper en reservation måste du ange följande dimensioner:

    • Kapacitetsstorlek: Reservationer kan vara för antingen 10 TiB eller 100 TiB, med mer betydande rabatter för att köpa en reservation med högre kapacitet. Du kan köpa flera reservationer, inklusive reservationer av olika kapacitetsstorlekar för att uppfylla dina arbetsbelastningskrav. Om din produktionsdistribution till exempel har 120 TiB filresurser kan du köpa en 100 TiB-reservation och två 10 TiB-reservationer för att uppfylla de totala lagringskapacitetskraven.
    • Term: Du kan köpa reservationer för antingen ett år eller tre år, med mer betydande rabatter för att köpa en längre reservationsperiod.
    • Nivå: Nivån för Azure Files för reservationen. Reservationer är för närvarande tillgängliga för faktureringsmodellerna SSD tillhandahållna v1 som premium och HDD betala efter användning (endast heta och kalla åtkomstnivåer).
    • Plats: Azure-regionen för reservationen. Reservationer är tillgängliga i en delmängd av Azure-regioner.
    • Redundans: Lagringsredundans för reservationen. Reservationer stöds för alla redundanser som Stöds av Azure Files, inklusive LRS, ZRS, GRS och GZRS.
    • Faktureringsfrekvens: Anger hur ofta kontot debiteras för reservationen. Alternativen är månadsvis eller i förväg.

    När du har köpt en reservation förbrukas den automatiskt av din befintliga lagringsanvändning. Om du använder mer lagringsutrymme än du har reserverat betalar du listpris för det saldo som inte omfattas av reservationen. Avgifter för transaktions-, bandbredds-, dataöverförings- och metadatalagring ingår inte i reservationen.

    Det finns skillnader i hur reservationer fungerar med ögonblicksbilder av Azure-fildelningar för Paketpris och etablerade v1-fildelningar. Om du tar ögonblicksbilder av betala efter användning-fildelningar räknas ögonblicksbildernas differenser mot reservationen och faktureras som en del av den vanliga lagringsanvändningen. Men om du tar ögonblicksbilder av tilldelade v1-filresurser debiteras ögonblicksbilderna med en separat mätare och räknas inte mot Reservationen.

    Mer information om hur du köper reservationer finns i Optimera kostnader för Azure Files med reservationer.

    Se även