Condividi tramite


Comprendere i modelli di fatturazione di Azure Files

Il costo di una distribuzione di File di Azure è determinato da quattro fattori chiave:

  • Modello di fatturazione: File di Azure supporta tre diversi modelli di fatturazione che modellano la struttura dei costi di una distribuzione di File di Azure:

    • Modello v2 con provisioning: modello di fatturazione con provisioning in cui è possibile effettuare separatamente il provisioning dello spazio di archiviazione, delle operazioni di I/O al secondo e della velocità effettiva. Si paga in base a ciò che si fornisce, indipendentemente dalla quantità effettivamente utilizzata. È consigliabile usare il modello v2 di cui è stato effettuato il provisioning per tutte le nuove distribuzioni di File di Azure.
    • Provisioning v1: modello di fatturazione con provisioning in cui si effettua il provisioning della quantità di archiviazione necessaria, mentre le operazioni di I/O al secondo e la velocità effettiva sono determinate dalla quantità di spazio di archiviazione di cui si effettua il provisioning. È consigliabile usare il modello v2 di cui è stato effettuato il provisioning, a meno che non si disponga di un motivo specifico per usare il modello v1 di cui è stato effettuato il provisioning.
    • Pagamento in base al consumo: modello di fatturazione basato sull'utilizzo in cui il costo viene determinato in base alla quantità di utilizzo della condivisione file, sotto forma di costi di archiviazione, transazioni e trasferimento dei dati usati. È consigliabile usare il modello v2 di cui è stato effettuato il provisioning, a meno che non si disponga di un motivo specifico per usare il modello con pagamento in base al consumo.
  • Livello multimediale: File di Azure supporta due livelli multimediali diversi di archiviazione, SSD e HDD. In questo modo è possibile personalizzare le condivisioni file in base ai requisiti di prestazioni e prezzo dello scenario.

    • SSD (Premium): le condivisioni file ospitate in unità SSD offrono prestazioni elevate coerenti e bassa latenza, con latenza in millisecondi a cifra singola per la maggior parte delle operazioni di I/O.
    • HDD (standard): le condivisioni file ospitate in unità disco rigido (HDD) offrono un'archiviazione conveniente per uso generico.
  • Ridondanza: File di Azure supporta quattro diverse opzioni di ridondanza che consentono di controllare il numero di copie dei dati archiviati e la posizione in cui vengono inserite all'interno dell'infrastruttura di Azure. Le opzioni più resilienti offrono maggiore durabilità e disponibilità, ma a un costo più elevato:

    • Locale: l'archiviazione con ridondanza locale mantiene tre copie dei dati all'interno di un singolo data center in un'area.
    • Zona: l'archiviazione con ridondanza zonale (ZRS) memorizza tre copie dei tuoi dati in data center indipendenti (zone di disponibilità) all'interno di un'area.
    • Geo: l'archiviazione con ridondanza geografica archivia tre copie dei dati nell'area primaria e replica in modo asincrono in un'area abbinata, per un totale di sei copie. Disponibile solo nell'archiviazione HDD.
    • GeoZone: l'archiviazione con ridondanza della zona geografica (GZRS) combina la ridondanza della zona nella regione primaria con la replica asincrona in una regione secondaria. Disponibile solo nell'archiviazione HDD.
  • Modello di risorsa: File di Azure supporta due diversi tipi di risorse, elementi gestibili creati e configurati all'interno delle sottoscrizioni e dei gruppi di risorse di Azure. Ogni tipo di risorsa supporta opzioni del modello di fatturazione leggermente diverse, che a loro volta influiscono sia sul costo che sulla struttura dei costi:

    • Gli account di archiviazione rappresentano un pool condiviso di archiviazione, operazioni di I/O al secondo e velocità effettiva in cui è possibile distribuire condivisioni file classiche o altre risorse di archiviazione, a seconda del tipo di account di archiviazione. Gli account di archiviazione supportano tutti i modelli di fatturazione, i livelli multimediali e le opzioni di ridondanza. Tutte le risorse di archiviazione distribuite in un account di archiviazione condividono i limiti applicabili a tale account. Le condivisioni file classiche supportano sia i protocolli SMB che NFS, anche se NFS è supportato solo nell'archiviazione SSD. Gli account di archiviazione vengono offerti dal Microsoft.Storage provider di risorse.

    • Le condivisioni file (anteprima) sono un nuovo tipo di risorsa di primo livello che semplifica la distribuzione di File di Azure eliminando l'account di archiviazione. Le condivisioni file supportano solo il modello v2 con provisioning consigliato e supportano solo il livello supporti SSD con il protocollo del file system NFS. Le condivisioni file vengono offerte dal Microsoft.FileShares provider di risorse.

Per informazioni sui prezzi di File di Azure, vedere la pagina prezzi di File di Azure.

Questo video offre una panoramica completa delle differenze tra i diversi modelli di fatturazione di Azure Files, tra cui pagamento in base al consumo, versione v1 e versione v2.

Questo video illustra in dettaglio il modello di fatturazione v2 con provisioning di Azure Files, offrendo istruzioni di configurazione e consigli per ridurre il costo totale di proprietà.

Unità di archiviazione

File di Azure usa le unità di misura base 2 per rappresentare la capacità di archiviazione: KiB, MiB, GiB e TiB.

Acronimo Definition Unità
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

Le unità di misura base 2 vengono comunemente usate dalla maggior parte dei sistemi operativi e degli strumenti per misurare le quantità di archiviazione. Tuttavia, spesso sono erroneamente etichettate come unità base-10, che potrebbero essere più familiari con: KB, MB, GB e TB. Il motivo comune per cui i sistemi operativi come Windows etichettano erroneamente le unità di archiviazione è che molti sistemi operativi hanno iniziato a usare questi acronimi prima di essere standardizzati dalla International Electrotechnical Commission (IEC), International Bureau of Weights and Measures (BIPM) e dall'US National Institute of Standards and Technology (NIST).

La tabella seguente mostra come i sistemi operativi comuni misurano e etichettano l'archiviazione.

Sistema operativo Sistema di misurazione Applicazione di etichette
Windows Base 2 Etichetta costantemente in modo errato come base 10.
Distribuzioni Linux In genere base-2, alcuni software usano base-10 L'etichettatura incoerente, l'allineamento tra misurazione e etichettatura dipende dal pacchetto software.
sistema operativo macOS, iOS e iPad Base 10 Etichetta costantemente come base 10.

Rivolgersi al fornitore del sistema operativo se il sistema operativo non è elencato.

Elenco di controllo del costo totale di proprietà della condivisione di file

Se stai eseguendo la migrazione a Azure Files dall'ambiente locale o stai confrontando Azure Files con altre soluzioni di archiviazione cloud, considera i fattori seguenti per assicurare un confronto equo pari a pari.

  • Come si paga per l'archiviazione, le operazioni di I/O al secondo e la larghezza di banda? La maggior parte delle soluzioni cloud dispone di modelli allineati ai principi dell'archiviazione con provisioning, ad esempio determinismo dei prezzi e semplicità, o di archiviazione con pagamento in base al consumo, che consente di ottimizzare i costi solo in base all'utilizzo effettivo. I modelli di fatturazione con provisioning possono variare in base alle dimensioni minime della condivisione con provisioning, all'unità di provisioning e alla possibilità di aumentare e ridurre il provisioning.

  • Esistono metodi per ottimizzare i costi di archiviazione? È possibile usare le prenotazioni di File di Azure per ottenere un massimo di 36% sconto sull'archiviazione. Altre soluzioni possono usare strategie come la deduplicazione o la compressione per ottimizzare facoltativamente l'efficienza di archiviazione. Tuttavia, queste strategie di ottimizzazione dell'archiviazione spesso presentano costi non monetari, ad esempio la riduzione delle prestazioni. Le prenotazioni di Azure Files non hanno effetti collaterali sulle prestazioni.

  • Come si ottiene la resilienza e la ridondanza dell'archiviazione? Con File di Azure, la resilienza e la ridondanza dell'archiviazione sono incluse nell'offerta del prodotto. Tutti i livelli e i livelli di ridondanza assicurano che i dati siano a disponibilità elevata e che siano accessibili almeno tre copie dei dati. Quando si valutano altre opzioni di archiviazione file, determinare se la resilienza e la ridondanza dell'archiviazione sono incorporate oppure se è necessario assemblarle da soli.

  • Cosa è necessario gestire? File di Azure è una soluzione completamente gestita. Altre soluzioni potrebbero richiedere aggiornamenti del sistema operativo o gestire risorse virtuali, ad esempio macchine virtuali, dischi e indirizzi IP di rete.

  • Quali sono i costi dei prodotti a valore aggiunto? File di Azure supporta le integrazioni con più servizi a valore aggiunto di prima e di terze parti. I servizi a valore aggiunto, ad esempio Backup di Azure, Sincronizzazione file di Azure e Microsoft Defender per Archiviazione, offrono funzionalità di backup, replica e memorizzazione nella cache e sicurezza per File di Azure. Le soluzioni a valore aggiunto, sia in locale che nel cloud, hanno le proprie licenze e i costi dei prodotti, ma sono spesso considerati parte del costo totale di proprietà per l'archiviazione file.

Modello con provisioning v2

Il modello v2 con provisioning per File di Azure abbina la prevedibilità del costo totale di proprietà con flessibilità, consentendo di creare una condivisione file che soddisfi i requisiti di archiviazione e prestazioni esatti. Quando si crea una nuova condivisione file v2 con provisioning, si specifica la quantità di spazio di archiviazione, IOPS e velocità effettiva necessarie per la condivisione file. L'importo di ogni quantità di cui si effettua il provisioning determina la fattura totale.

La quantità di spazio di archiviazione, IOPS e velocità effettiva forniti rappresenta i limiti garantiti per l'utilizzo della condivisione file. Ad esempio, se si effettua il provisioning di una condivisione della capacità di 2 TiB e si caricano 2 TiB di dati nella condivisione, la condivisione sarà piena. Non sarà possibile aggiungere altri dati a meno che non si aumentino le dimensioni della condivisione o non si eliminino alcuni dati. Il bursting delle operazioni di I/O al secondo basato sul credito offre una maggiore flessibilità di utilizzo, in base al principio del massimo impegno, finché restano crediti.

La quantità di spazio di archiviazione, di operazioni di I/O al secondo (IOPS) e di velocità effettiva fornita può essere ridimensionata in modo dinamico al variare delle esigenze. Tuttavia, è possibile diminuire una quantità fornita solo dopo che sono trascorse 24 ore dall'ultimo aumento della quantità. Le modifiche all'archiviazione, alle operazioni di I/O al secondo e alla velocità effettiva sono effettive entro pochi minuti dalla modifica del provisioning.

Per impostazione predefinita, quando si crea una nuova condivisione file usando il modello v2 con provisioning, viene fornita una raccomandazione per il numero di operazioni di I/O al secondo e la velocità effettiva necessaria. Viene calcolato in base alla quantità di spazio di archiviazione da te specificato. Queste raccomandazioni si basano sull'utilizzo tipico dei clienti per la quantità di spazio di archiviazione allocato per il livello multimediale scelto. Tuttavia, è possibile che il carico di lavoro richieda più o meno operazioni di I/O al secondo e velocità effettiva rispetto alla "condivisione file tipica". In questo caso, facoltativamente, è possibile effettuare il provisioning di più o meno operazioni di I/O al secondo e velocità effettiva, a seconda dei requisiti delle singole condivisioni file.

Disponibilità del modello con provisioning v2

Il modello v2 con provisioning è disponibile per le combinazioni seguenti di livello supporti, ridondanza e protocollo di condivisione file:

Livello supporti Ridondanza Protocollo di condivisione file Condivisioni file classiche (Microsoft.Storage) Condivisione di file (Microsoft.FileShares)
SSD (unità a stato solido) Local Piccole e Medie Imprese (PMI) Sì No
SSD (unità a stato solido) Zona Piccole e Medie Imprese (PMI) Sì No
SSD (unità a stato solido) Local NFS Sì Sì
SSD (unità a stato solido) Zona NFS Sì Sì
HDD Local Piccole e Medie Imprese (PMI) Sì No
HDD Zona Piccole e Medie Imprese (PMI) Sì No
HDD Geo Piccole e Medie Imprese (PMI) Sì No
HDD GeoZone Piccole e Medie Imprese (PMI) Sì No
HDD Local NFS No No
HDD Zona NFS No No
HDD Geo NFS No No
HDD GeoZone NFS No No

Attualmente, il modello v2 con provisioning è disponibile a livello generale in un sottoinsieme limitato di aree geografiche:

  • Tutte le aree del cloud pubblico di Azure.
  • Tutte le aree cloud di Azure US Government.

Nota

Non tutte le aree supportano tutti i livelli multimediali e le opzioni di ridondanza.

Dettagli del provisioning del modello con provisioning v2

Quando si crea una condivisione file con provisioning v2, si specifica la capacità di provisioning per la condivisione file in termini di archiviazione, operazioni di I/O al secondo e velocità effettiva. Le condivisioni file sono limitate in base agli attributi seguenti:

Elemento Valore SSD Valore HDD
Unità di provisioning archiviazione 1 GiB 1 GiB
Unità di allocazione IOPS 1 I/O al secondo 1 I/O al secondo
Unità di provisioning velocità effettiva 1 MiB/sec 1 MiB/sec
Spazio di archiviazione minimo con provisioning 32 GiB 32 GiB
Numero minimo di operazioni di I/O al secondo con provisioning 3.000 operazioni di I/O al secondo 500 operazioni di I/O al secondo
Velocità effettiva minima con provisioning 100 MiB/sec 60 MiB/sec
Spazio di archiviazione massimo fornito 256 TiB (262.144 GiB) 256 TiB (262.144 GiB)
Numero massimo di operazioni di I/O al secondo con provisioning 102.400 operazioni di I/O al secondo 50.000 IOPS
Velocità effettiva massima con provisioning 10.340 MiB/sec 5.120 MiB/sec

Per impostazione predefinita, è consigliabile effettuare il provisioning delle operazioni di I/O al secondo e della velocità effettiva in base allo spazio di archiviazione di cui è stato effettuato il provisioning. Queste formule di raccomandazione si basano sull'utilizzo tipico dei clienti per la quantità di archiviazione di cui è stato effettuato il provisioning per tale livello multimediale in File di Azure:

Nome della formula Formula SSD Formula HDD
Raccomandazione IOPS MIN(MAX(3000 + CEILING(1 * ProvisionedStorageGiB), 3000), 102400) MIN(MAX(1000 + CEILING(0.2 * ProvisionedStorageGiB), 500), 50000)
Raccomandazione sulla capacità di trasmissione MIN(MAX(100 + CEILING(0.1 * ProvisionedStorageGiB), 100), 10340) MIN(MAX(60 + CEILING(0.02 * ProvisionedStorageGiB), 60), 5120)

A seconda dei requisiti delle singole condivisioni file, è possibile che siano necessarie più o meno operazioni di I/O al secondo o una maggiore capacità di velocità effettiva rispetto a quanto raccomandato. Facoltativamente, è possibile eseguire l'override di queste raccomandazioni con i propri valori in base alle esigenze.

Bursting per il modello con provisioning v2

Il bursting di operazioni di I/O al secondo basato sul credito offre una maggiore flessibilità rispetto all'utilizzo delle operazioni di I/O al secondo. Questa flessibilità viene usata al meglio come buffer rispetto ai picchi imprevisti di I/O. Per i modelli di I/O stabiliti, è consigliabile effettuare il provisioning per i picchi di I/O.

I crediti di IOPS burst si accumulano ogni volta che il traffico per la condivisione file è inferiore agli IOPS provisionati (baseline). Ogni volta che l'utilizzo di operazioni di I/O al secondo di una condivisione file supera la quantità di cui è stato effettuato il provisioning e sono disponibili crediti burst per operazioni di I/O al secondo, la condivisione file può aumentare fino al limite massimo di operazioni di I/O al secondo consentito. Le condivisioni file possono continuare a scoppiare finché sono presenti crediti rimanenti, in base al numero di crediti burst accumulati. Ogni operazione I/O oltre gli IOPS forniti utilizza un credito. Una volta utilizzati tutti i crediti, la condivisione torna alle operazioni di I/O al secondo di cui è stato effettuato il provisioning. Le operazioni di I/O al secondo sulla condivisione file non devono fare niente di speciale per usare il bursting. Il bursting funziona in base al principio del massimo impegno.

I crediti di condivisione hanno tre stati:

  • Accumulo, quando la condivisione file usa meno operazioni di I/O al secondo di quelle di cui è stato effettuato il provisioning.
  • Diminuzione, quando la condivisione file usa più operazioni di I/O al secondo di quelle di cui è stato effettuato il provisioning ed è in modalità burst.
  • Costante, quando la condivisione file usa esattamente le operazioni di I/O al secondo di cui è stato effettuato il provisioning e non sono presenti crediti accumulati o usati.

Una nuova condivisione file parte dal numero massimo di crediti nel bucket di burst. I crediti burst non si accumulano se le operazioni di I/O al secondo della condivisione sono inferiori al limite di provisioning a causa della limitazione delle richieste da parte del server. Le formule seguenti vengono utilizzate per determinare il limite di burst di IOPS e il numero di crediti possibili per una condivisione di file.

Elemento Formula SSD Formula HDD
Limite burst per operazioni di I/O al secondo MIN(MAX(3 * ProvisionedIOPS, 10000), 102400) MIN(MAX(3 * ProvisionedIOPS, 5000), 50000)
Crediti burst per operazioni di I/O al secondo (BurstLimit - ProvisionedIOPS) * 3600 (BurstLimit - ProvisionedIOPS) * 3600

La tabella seguente illustra alcuni esempi di queste formule per vari importi di IOPS predisposti.

Operazioni di I/O al secondo con provisioning Limite di operazioni di I/O al secondo del burst SSD Crediti burst SSD Limite burst per operazioni di I/O al secondo HDD Crediti burst HDD
500 -- -- Fino a 5.000 16,200,000
1.000 -- -- Fino a 5.000 14,400,000
3,000 Fino a 10.000 25,200,000 Fino a 9.000 21,600,000
5.000 Fino a 15.000 36.000.000 Fino a 15.000 36.000.000
10.000 Fino a 30.000 72,000,000 Fino a 30.000 72,000,000
25.000 Fino a 75.000 180,000,000 Fino a 50.000 90.000.000
50.000 Fino a 102.400 188,640,000 Fino a 50.000 0
75.000 Fino a 102.400 98,640,000 -- --
102.400 Fino a 102.400 0 -- --

Modelli di risorse v2 con provisioning

Il modello di fatturazione con provisioning v2 è disponibile per entrambi i tipi di risorse utilizzati da Azure Files. È possibile creare una condivisione file v2 con provisioning come condivisione file classica all'interno di un account di archiviazione (Microsoft.Storage) o direttamente come condivisione file di primo livello (Microsoft.FileShares).

Condivisioni file v2 classiche con provisioning (Microsoft.Storage)

Per creare una condivisione file classica usando il modello v2 di cui è stato effettuato il provisioning, l'account di archiviazione deve usare una delle combinazioni di impostazioni seguenti:

Tipo di account di archiviazione SKU dell'account di archiviazione Tipo di condivisione file classica disponibile
Archiviazione di file PremiumV2_LRS Condivisioni file SSD v2 classiche con provisioning e ridondanza locale specificata.
Archiviazione di file PremiumV2_ZRS Condivisioni file SSD v2 classiche con provisioning e ridondanza della zona specificata.
Archiviazione di file StandardV2_LRS Condivisioni file HDD v2 classiche con provisioning e ridondanza locale specificata.
Archiviazione di file StandardV2_ZRS Condivisioni file HDD v2 classiche con provisioning e ridondanza della zona specificata.
Archiviazione di file StandardV2_GRS Condivisioni file HDD v2 classiche con ridondanza geografica specificata.
Archiviazione di file StandardV2_GZRS Condivisioni file HDD v2 classiche con ridondanza geografica della zona specificata.

Per ulteriori informazioni su come creare una condivisione file classica utilizzando il modello v2 provvisto, vedere Creare una condivisione file classica.

Le condivisioni file classiche create nello stesso account di archiviazione condividono i limiti dell'account di archiviazione per lo spazio di archiviazione, le operazioni di I/O al secondo e la velocità effettiva:

Attribute Valore SSD Valore HDD Strategia di imposizione
Provisioning massimo archiviazione per account di archiviazione 256 TiB (262.144 GiB) 4 PiB (4.194.304) In fase di provisioning.
Provisioning massimo operazioni di I/O al secondo per account di archiviazione 102.400 operazioni di I/O al secondo 50.000 IOPS In fase di provisioning.
Larghezza di banda massima fornita per ogni account di archiviazione 10.340 MiB/sec 5.120 MiB/sec In fase di provisioning.
Numero massimo di condivisioni file classiche per account di archiviazione 50 condivisioni classiche di file 50 condivisioni classiche di file In fase di provisioning.

Per eseguire correttamente una distribuzione di File di Azure con il modello di fatturazione v2 con provisioning nelle condivisioni file classiche, è necessario considerare le seguenti dimensioni della pianificazione delle capacità:

  • Quanto spazio di archiviazione, quante operazioni di I/O al secondo e velocità effettiva con provisioning sono necessari per ogni condivisione file classica? In che modo questi requisiti cambiano nel tempo?
    Poiché gli account di archiviazione hanno limiti condivisi, quando si allocano condivisioni file classiche agli account di archiviazione, è necessario considerare le esigenze di ogni condivisione file classica sia ora che nel tempo. La logica di provisioning per il modello v2 con provisioning impedisce di assegnare più spazio di archiviazione, operazioni di I/O al secondo o velocità effettiva di quanto supportato dall'account di archiviazione. Se un numero sufficiente di condivisioni file classiche viene inserito in un singolo account di archiviazione in modo che una di queste dimensioni sia massima, le condivisioni file classiche esistenti non possono aumentare senza prima eseguire la migrazione a un account di archiviazione diverso. Per ridurre questo rischio, pianifica spazio sufficiente in ogni account di archiviazione in modo da poter mantenere le mappature delle condivisioni file classiche agli account di archiviazione per almeno 3-5 anni.

  • Avete requisiti speciali riguardo al monitoraggio della fattura per ciascuna condivisione file classica per risalire a singoli progetti, reparti o clienti?
    In Azure, la granularità più bassa per cui è possibile visualizzare la fatturazione è la risorsa, ovvero se si inseriscono due condivisioni file classiche nello stesso account di archiviazione, non è possibile tenere traccia dei costi in singoli progetti, reparti o clienti. Per risolvere questo problema, raggruppare le condivisioni file classiche in account di archiviazione in base al modo in cui devono essere monitorate dal punto di vista della fatturazione.

  • Quanti account di archiviazione sono disponibili nella sottoscrizione per l'area di destinazione?
    Un fattore di complicazione aggiuntivo è il numero di account di archiviazione che è possibile avere per ogni sottoscrizione per area. Per altre informazioni, vedere Microsoft.Storage Limiti del piano di controllo . A seconda del numero di account di archiviazione necessari, potrebbe essere necessario usare sottoscrizioni aggiuntive per ottenere account di archiviazione aggiuntivi.

Condivisioni file v2 con provisioning (Microsoft.FileShares)

La creazione di condivisioni file utilizzando il modello di gestione Microsoft.FileShares rende notevolmente più facile il deployment di Azure Files:

  • Non è necessario considerare le esigenze correnti e future di ogni condivisione file per decidere dove distribuire la condivisione file.
    Il provisioning di ogni condivisione file è indipendente dal provisioning di ogni altra condivisione file. L'unica considerazione sull'aumento della condivisione file sono i limiti della condivisione file, come indicato in Dettagli del provisioning del modello v2.

  • La fattura per ogni condivisione file viene rilevata in modo indipendente.
    Poiché le condivisioni file sono risorse di primo livello, è possibile tenere traccia della fattura per ogni condivisione file indipendentemente da ogni altra condivisione file. È anche possibile usare i tag per semplificare il raggruppamento delle risorse per tenere traccia dei costi per progetti, reparti o clienti.

  • Anche se le condivisioni file hanno ancora un limite per ogni sottoscrizione per area, il limite di condivisioni file è molto superiore al limite degli account di archiviazione.
    Per altre informazioni, vedere Microsoft.FileShares Limiti del piano di controllo.

Snapshot per il modello con provisioning v2

File di Azure supporta gli snapshot, che sono simili alle copie shadow del volume nei file server Windows. Per altre informazioni sugli snapshot di condivisione, vedere Panoramica degli snapshot per File di Azure.

Gli snapshot sono sempre differenziali rispetto alla condivisione attiva e l'uno dall'altro. Nel modello di fatturazione v2 previsto, se la differenza totale di tutti gli snapshot rientra nello spazio di archiviazione eccedente della condivisione file, non comporta alcun costo aggiuntivo per l'archiviazione degli snapshot. Se la somma tra le dimensioni dei dati della condivisione attiva più i dati dello snapshot differenziale è superiore all'archiviazione di cui è stato effettuato il provisioning per la condivisione, la capacità usata in eccesso degli snapshot viene fatturata in base al contatore Utilizzo snapshot overflow. La formula per determinare la quantità di overflow è: MAX((LiveShareUsedGiB + SnapshotDifferentialUsedGiB) - ProvisionedStorageGiB, 0)

Alcuni servizi a valore aggiunto per Azure Files usano le istantanee come parte della loro proposta di valore. Per altre informazioni, vedere Servizi a valore aggiunto per File di Azure.

Eliminazione temporanea per il modello con provisioning v2

Quando l'eliminazione temporanea è abilitata, le condivisioni file eliminate vengono fatturate in base alla capacità di archiviazione usata durante il periodo di conservazione. L'archiviazione, le operazioni di I/O al secondo e la velocità effettiva di una condivisione eliminata continuano a essere conteggiate nei limiti di capacità dell'account di archiviazione fino a quando la condivisione non viene eliminata definitivamente, garantendo che possa essere ripristinata. Tuttavia, queste risorse non vengono fatturate. Per informazioni dettagliate sull'abilitazione dell'eliminazione temporanea, vedere Come abilitare l'eliminazione temporanea nelle condivisioni file di Azure.

Contatori di fatturazione per il modello con provisioning v2

Le condivisioni file di cui è stato effettuato il provisioning con il modello di fatturazione v2 sottoposto a provisioning vengono fatturate in base ai contatori di fatturazione seguenti:

  • Archiviazione con provisioning: quantità di spazio di archiviazione di cui è stato effettuato il provisioning in GiB.
  • Operazioni di I/O al secondo con provisioning: quantità di operazioni di I/O al secondo di cui è stato effettuato il provisioning.
  • Velocità effettiva con provisioning in MiBPS: quantità di velocità effettiva di cui è stato effettuato il provisioning in MiB/sec.
  • Utilizzo dello snapshot di overflow: qualsiasi quantità di utilizzo differenziale degli snapshot in GiB che non rientra nella capacità di archiviazione con provisioning. Per altre informazioni, vedere Snapshot v2 di cui è stato effettuato il provisioning.
  • Utilizzo eliminazione temporanea: capacità di archiviazione usata in GiB per le condivisioni file eliminate temporaneamente. Per altre informazioni, vedere l'articolo relativo all'eliminazione temporanea della versione 2 di cui è stato effettuato il provisioning.

Le unità di consumo rispetto ai contatori di fatturazione v2 di cui è stato effettuato il provisioning vengono generate ogni ora. Ad esempio, per una condivisione con 1.024 GiB di spazio assegnato, dovresti vedere:

  • 1.024 unità per il contatore Archiviazione con provisioning per una singola ora.
  • 24.576 unità per il contatore Archiviazione con provisioning se aggregate per un giorno.
  • Numero variabile di unità se aggregato per un mese a seconda del numero di giorni nel mese:
    • Mese di 28 giorni (febbraio normale): 688.128 unità nel contatore Archiviazione con provisioning.
    • Mese di 29 giorni (febbraio di anno bisestile): 712.704 unità nel contatore Archiviazione con provisioning.
    • Mese di 30 giorni: 737.280 unità nel contatore Archiviazione con provisioning.
    • Mese di 31 giorni: 761.856 unità nel contatore Archiviazione con provisioning.

Migrazioni per il modello con provisioning v2

Il processo di migrazione delle condivisioni file SMB di Azure da un modello di pagamento a consumo al modello di fatturazione v2 preconfigurato varia a seconda che si utilizzi o meno la Sincronizzazione file di Azure.

Modello con provisioning v1

Il metodo con provisioning v1 fornisce archiviazione, operazioni di I/O al secondo e velocità effettiva in rapporto fisso tra loro, in modo analogo a come si acquista l'archiviazione in una soluzione di archiviazione locale. Quando si crea una nuova condivisione di file v1 classica con provisioning, si specifica la quantità di spazio di archiviazione necessaria per la condivisione, mentre IOPS e throughput sono valori calcolati. Il modello v1 di Azure Files di cui è stato effettuato il provisioning è disponibile solo per il livello SSD.

La quantità di spazio di archiviazione di cui si effettua il provisioning determina i limiti di archiviazione, IOPS e velocità effettiva garantiti dell'utilizzo della condivisione file classica. Ad esempio, se si esegue il provisioning di una condivisione da 2 TiB e si caricano 2 TiB di dati nella condivisione file classica, tale condivisione file sarà completamente piena. Non sarà possibile aggiungere altri dati a meno che non si aumentino le dimensioni della condivisione file classica o non si eliminino alcuni dati. Il bursting delle operazioni di I/O al secondo basato sul credito offre una maggiore flessibilità di utilizzo, in base al principio del massimo impegno, finché restano crediti.

A differenza dell'acquisto di spazio archiviazione locale, le condivisioni file v1 classiche con provisioning possono essere ridimensionate in modo dinamico in base alle esigenze. Tuttavia, è possibile ridurre solo lo spazio di archiviazione di cui è stato effettuato il provisioning dopo 24 ore dall'aumento dell'ultimo spazio di archiviazione. Le modifiche all'archiviazione, alle operazioni di I/O al secondo e alla velocità effettiva sono effettive entro pochi minuti dalla modifica del provisioning.

È possibile ridurre le dimensioni della condivisione di cui viene effettuato il provisioning al di sotto dei GiB utilizzati. In tal caso, i dati non andranno persi, ma le dimensioni usate vengono comunque fatturate. Si riceveranno le prestazioni della condivisione di cui è stato effettuato il provisioning, non le dimensioni usate.

Disponibilità del modello con provisioning v1

Il modello v1 con provisioning è disponibile per le combinazioni seguenti di livello supporti, ridondanza e protocollo di condivisione file:

Livello supporti Ridondanza Protocollo di condivisione file Condivisioni file classiche (Microsoft.Storage) Condivisione di file (Microsoft.FileShares)
SSD (unità a stato solido) Local Piccole e Medie Imprese (PMI) Sì No
SSD (unità a stato solido) Zona Piccole e Medie Imprese (PMI) Sì No
SSD (unità a stato solido) Local NFS Sì No
SSD (unità a stato solido) Zona NFS Sì No
HDD Local Piccole e Medie Imprese (PMI) No No
HDD Zona Piccole e Medie Imprese (PMI) No No
HDD Geo Piccole e Medie Imprese (PMI) No No
HDD GeoZone Piccole e Medie Imprese (PMI) No No
HDD Local NFS No No
HDD Zona NFS No No
HDD Geo NFS No No
HDD GeoZone NFS No No

Le condivisioni file SSD classiche che usano il modello v1 con provisioning sono disponibili a livello generale nella maggior parte delle aree di Azure. Per altre informazioni, vedere Prodotti di Azure in base all'area.

Dettagli di provisioning del modello con provisioning v1

Quando si crea una condivisione file classica v1 effettuata tramite provisioning, si specifica la quantità di spazio di archiviazione richiesto per la condivisione. Ogni GiB di cui si effettua il provisioning consente di aumentare le operazioni di I/O al secondo e la velocità effettiva in un rapporto fisso. Le condivisioni di file classiche con provisioning v1 sono limitate in base agli attributi seguenti.

Elemento Value
Unità di provisioning archiviazione 1 GiB
Spazio di archiviazione minimo con provisioning 100 GiB
IOPS provisionate minime (calcolate) 3.100 IOPS
Velocità minima configurata (calcolata) 110 MiB/sec
Spazio di archiviazione massimo fornito 100 TiB (102.400 GiB)
Numero massimo di operazioni di I/O al secondo con provisioning (calcolato) 102.400 operazioni di I/O al secondo
Massima capacità provisionata (calcolata) 10.340 MiB/sec

Le formule seguenti determinano la quantità di operazioni di I/O al secondo e velocità effettiva di cui è stato effettuato il provisioning nella condivisione:

Elemento Formula
Operazioni di I/O al secondo con provisioning calcolate (di base) MIN(3000 + 1 * ProvisionedStorageGiB, 102400)
Velocità effettiva con provisioning calcolata (MiB/sec) 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)

A seconda dei requisiti della singola condivisione file classica, è possibile che siano necessarie più operazioni di I/O al secondo o una velocità effettiva maggiore rispetto alle formule di provisioning specificate. In questo caso, è necessario effettuare il provisioning di più risorse di archiviazione per ottenere le operazioni di I/O al secondo o la velocità effettiva necessarie.

Bursting per il modello con provisioning v1

Il modello con provisioning v1 supporta due tipi di bursting: bursting basato sul credito, incluso gratuitamente come parte del provisioning, e bursting a pagamento, che è una funzionalità avanzata che può essere abilitata facoltativamente per supportare la fatturazione basata sull'utilizzo ogni volta che le operazioni di I/O al secondo e la velocità effettiva sono superiori all'importo di cui è stato effettuato il provisioning.

Bursting basato sul credito per il modello con provisioning v1

Il bursting di operazioni di I/O al secondo basato sul credito offre una maggiore flessibilità rispetto all'utilizzo delle operazioni di I/O al secondo. Questa flessibilità viene usata al meglio come buffer rispetto ai picchi imprevisti di I/O. Per i modelli di I/O stabiliti, è consigliabile effettuare il provisioning per i picchi di I/O.

I crediti di IOPS in modalità burst si accumulano ogni volta che il traffico per la condivisione file classica è inferiore agli IOPS di base (baseline). Ogni volta che l'utilizzo di operazioni di I/O al secondo di una condivisione file classica supera la quantità di cui è stato effettuato il provisioning e sono disponibili crediti burst per le operazioni di I/O al secondo, la condivisione file classica può aumentare temporaneamente fino al limite massimo di operazioni di I/O al secondo consentito. Le condivisioni file classiche possono continuare ad aumentare temporaneamente finché sono disponibili crediti rimanenti, in base al numero di crediti burst accumulati. Ogni operazione I/O oltre gli IOPS forniti utilizza un credito. Una volta che sono stati utilizzati tutti i crediti, la condivisione file classica torna alle operazioni di I/O al secondo di cui è stato effettuato il provisioning. Le operazioni di I/O al secondo nella condivisione file classica non richiedono operazioni specifiche per l'uso del bursting. Il bursting funziona in base al principio del massimo impegno.

I crediti di condivisione hanno tre stati:

  • Accumulo: quando la condivisione file usa meno operazioni di I/O al secondo di quelle di cui è stato effettuato il provisioning.
  • Diminuzione, quando la condivisione file classica utilizza più operazioni di I/O al secondo rispetto a quello previsto e si trova in modalità burst.
  • Costante, quando la condivisione file classica utilizza esattamente gli IOPS previsti e non ci sono crediti né accumulati né utilizzati.

Una nuova condivisione file classica parte dal numero massimo di crediti nel bucket di burst. I crediti burst non si accumulano se le operazioni di I/O al secondo della condivisione sono inferiori al limite di provisioning a causa della limitazione delle richieste da parte del server. Le seguenti formule vengono utilizzate per determinare il limite di IOPS in burst e il numero di crediti possibili per una condivisione file tradizionale.

Elemento Formula
Limite di burst MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400)
Crediti burst (BurstLimit - BaselineIOPS) * 3600

La tabella seguente illustra alcuni esempi di queste formule per le dimensioni preconfigurate.

Capacità (GiB) IOPS di base Operazioni di I/O al secondo in modalità burst Crediti burst Velocità effettiva (MiB/sec)
100 3,100 Fino a 10.000 24,840,000 110
500 3.500 Fino a 10.000 23,400,000 150
1.024 4,024 Fino a 10.000 21,513,600 203
5120 8.120 Fino a 15.360 26,064,000 613
10.240 13,240 Fino a 30.720 62,928,000 1,125
33,792 36,792 Fino a 102.400 227,548,800 3.480
51.200 54,200 Fino a 102.400 164,880,000 5.220
102.400 102.400 Fino a 102.400 0 10,340

Bursting a pagamento per il modello con provisioning v1

Il bursting a pagamento è una funzionalità avanzata del modello con provisioning v1, progettata per supportare i clienti che non vogliono mai subire limitazioni. Il bursting a pagamento aggiunge una fatturazione aggiuntiva basata sull'utilizzo per qualsiasi quantità di operazioni di I/O al secondo o velocità effettiva al di sopra dell'archiviazione di cui è stato effettuato il provisioning. Questo comportamento è distinto dal bursting basato sul credito, incluso gratuitamente nell'ambito dell'archiviazione con provisioning. Anche se il bursting a pagamento può aggiungere una straordinaria flessibilità al modo in cui si effettua il provisioning della condivisione file classica, può anche causare una fatturazione imprevista se usata in modo non corretto.

Analogamente al bursting basato sul credito, il bursting a pagamento non sostituisce l'allocazione della quantità corretta di IOPS e larghezza di banda. Invece, offre ulteriore protezione contro la limitazione se si verifica una domanda imprevista. Se si ha un livello coerente di operazioni di I/O al secondo o di utilizzo della velocità effettiva, è più economico effettuare il provisioning di operazioni di I/O al secondo e velocità effettiva sufficienti (tramite il provisioning dell'archiviazione) per coprire la domanda, invece di basarsi sul bursting a pagamento.

Il bursting a pagamento è disabilitato per impostazione predefinita, ma è possibile abilitarlo seguendo le istruzioni per modificare le caratteristiche dei costi e delle prestazioni di una condivisione file classica V1 provisionata (solo PowerShell e CLI). Se il bursting a pagamento è abilitato, è consigliabile monitorare attentamente l'utilizzo delle operazioni di I/O al secondo e della velocità effettiva usando le metriche seguenti disponibili tramite Monitoraggio di Azure:

  • Provisioning di operazioni di I/O al secondo della condivisione file
  • Larghezza di banda provisionata per condivisione file MiB/s (velocità effettiva)
  • Transazioni per numero massimo di operazioni di I/O al secondo
  • Larghezza di banda per MiB/sec massimi (velocità effettiva)
  • Crediti burst per operazioni di I/O al secondo (bursting basato sul credito)
  • I/O burst a pagamento (I/O)
  • Larghezza di banda bursting a pagamento

Modelli di risorse v1 con provisioning

È possibile creare una condivisione file v1 con provisioning solo come condivisione file classica all'interno di un account di archiviazione (Microsoft.Storage).

Condivisioni file v1 classiche con provisioning (Microsoft.Storage)

Per creare una condivisione file classica usando il modello v1 di cui è stato effettuato il provisioning, l'account di archiviazione deve usare una delle combinazioni di impostazioni seguenti:

Tipo di account di archiviazione SKU dell'account di archiviazione Tipo di condivisione file disponibile
Archiviazione di file Archiviazione con ridondanza locale Premium Condivisioni file SSD v1 con provisioning e ridondanza locale specificata.
Archiviazione di file Archiviazione con ridondanza della zona Premium Condivisioni file SSD v1 con provisioning e ridondanza della zona (ZRS) specificata.

Per altre informazioni su come creare una condivisione file classica usando il modello v1 provisionato, vedere Creare una condivisione file classica.

Le condivisioni file classiche create nello stesso account di archiviazione condividono i limiti dell'account di archiviazione per lo spazio di archiviazione, le operazioni di I/O al secondo e la velocità effettiva:

Attribute Valore SSD Strategia di imposizione
Provisioning massimo archiviazione per account di archiviazione 100 TiB (102.400 GiB) In fase di provisioning
Numero massimo di operazioni di I/O al secondo usate per ogni account di archiviazione 102.400 operazioni di I/O al secondo È possibile effettuare il provisioning di più di 102.400 operazioni di I/O al secondo, ma l'utilizzo superiore a questo limite è limitato.
Velocità massima utilizzata di trasferimento dati per account di archiviazione 10.340 MiB/sec È possibile effettuare il provisioning di più di 10.340 MiB/sec, ma l'utilizzo al di sopra di questo limite è limitato.
Numero massimo di condivisioni file classiche per account di archiviazione 1.024 condivisioni file classiche Questo limite viene applicato implicitamente dalla memorizzazione massima fornita per un account di archiviazione.

Per eseguire correttamente una distribuzione di File di Azure con il modello di fatturazione v1 con provisioning nelle condivisioni file classiche, è necessario considerare le seguenti dimensioni della pianificazione delle capacità:

  • Quanto spazio di archiviazione, quante operazioni di I/O al secondo e velocità effettiva con provisioning sono necessari per ogni condivisione file classica? In che modo questi requisiti cambiano nel tempo?
    A causa dei limiti dell'account di archiviazione condiviso, quando si allocano condivisioni file classiche agli account di archiviazione, è necessario considerare le esigenze di ogni condivisione file classica sia ora che nel tempo. La logica di provisioning per il modello v1 con provisioning impedisce di assegnare più spazio di archiviazione di quanto supportato dall'account di archiviazione. Sebbene sia consentito progettare più IOPS e maggiore velocità effettiva rispetto a quanto fornisce l'account di archiviazione, non è possibile superare i limiti dell'account di archiviazione per quanto riguarda IOPS e velocità effettiva. Per evitare limitazioni impreviste, non effettuare il provisioning di più operazioni di I/O al secondo o velocità effettiva di quanto supportato dall'account di archiviazione.

    Inoltre, l'inserimento di troppe condivisioni file classiche in un account di archiviazione può limitare la crescita futura. Una volta che un account di archiviazione è pieno, non è possibile espandere le condivisioni file classiche esistenti senza prima eseguire la migrazione di alcuni a un altro account di archiviazione. Per ridurre questo rischio, pianificare abbastanza margine di spazio negli account di archiviazione in modo da poter gestire le mappature delle condivisioni file classiche agli account di archiviazione per almeno 3-5 anni.

  • Avete requisiti speciali riguardo al monitoraggio della fattura per ciascuna condivisione file classica per risalire a singoli progetti, reparti o clienti?
    In Azure, la granularità più bassa per cui è possibile visualizzare la fatturazione è la risorsa, ovvero se si inseriscono due condivisioni file classiche nello stesso account di archiviazione, non è possibile tenere traccia dei costi in singoli progetti, reparti o clienti. Per risolvere questo problema, raggruppare le condivisioni file classiche in account di archiviazione in base al modo in cui devono essere monitorate dal punto di vista della fatturazione.

  • Quanti account di archiviazione sono disponibili nella sottoscrizione per l'area di destinazione?
    Un fattore di complicazione aggiuntivo è il numero di account di archiviazione che è possibile avere per ogni sottoscrizione per area. Per altre informazioni, vedere Microsoft.Storage Limiti del piano di controllo . A seconda del numero di account di archiviazione necessari, potrebbe essere necessario usare sottoscrizioni aggiuntive per ottenere account di archiviazione aggiuntivi.

Snapshot per il modello con provisioning v1

File di Azure supporta gli snapshot, che sono simili alle copie shadow del volume nei file server Windows. Per altre informazioni sugli snapshot di condivisione, vedere Panoramica degli snapshot per File di Azure.

Gli snapshot sono sempre differenziali rispetto alla condivisione attiva e l'uno dall'altro. Nel modello di fatturazione con provisioning v1, le dimensioni differenziali totali vengono addebitate sulla base di un contatore dell'utilizzo, indipendentemente dalla quantità di archiviazione con provisioning inutilizzata. Il contatore dell'archiviazione snapshot usata ha un prezzo ridotto rispetto al prezzo dell'archiviazione con provisioning.

Eliminazione temporanea per il modello con provisioning v1

Le condivisioni file classiche eliminate negli account di archiviazione con eliminazione temporanea abilitata vengono fatturate in base alla capacità di archiviazione usata della condivisione eliminata per il periodo di conservazione definito. La capacità di archiviazione usata eliminata temporaneamente viene emessa rispetto al contatore di archiviazione snapshot usata. Per altre informazioni sull'eliminazione temporanea, vedere Come abilitare l'eliminazione temporanea nelle condivisioni file di Azure.

Contatori di fatturazione per il modello con provisioning v1

Le condivisioni file con provisioning che usano il modello di fatturazione v1 con provisioning vengono fatturate in base ai due contatori seguenti:

  • Provisioning Premium: quantità di spazio di archiviazione di cui è stato effettuato il provisioning in GiB.
  • Snapshot Premium: quantità di snapshot usati e capacità eliminata temporaneamente usata.

Il consumo rispetto ai contatori di fatturazione v1 assegnati viene calcolato ogni ora in base alle unità mensili. Ad esempio, per una condivisione con 1.024 GiB di spazio assegnato, dovresti vedere:

  • Numero variabile di unità per un'ora singola a seconda del numero di giorni nel mese:
    • Mese di 28 giorni (febbraio normale): 1.5238 unità nel contatore Premium con provisioning.
    • Mese di 29 giorni (febbraio di anno bisestile): 1.4713 unità nel contatore Premium con provisioning.
    • Mese di 30 giorni: 1.4222 unità nel contatore Premium con provisioning.
    • Mese di 31 giorni: 1.3763 unità nel contatore Premium con provisioning.
  • Numero variabile di unità se aggregato per un giorno a seconda del numero di giorni nel mese:
    • Mese di 28 giorni (febbraio normale): 36.5714 unità nel contatore Premium con provisioning.
    • Mese di 29 giorni (febbraio di anno bisestile): 35.3103 unità nel contatore Premium con provisioning.
    • Mese di 30 giorni: 34.1333 unità nel contatore Premium con provisioning.
    • Mese di 31 giorni: 33.0323 unità nel contatore Premium con provisioning.
  • 1,024 unità nel contatore Premium con provisioning se aggregate per un mese.

Modello di pagamento in base al consumo

Nel modello di pagamento in base al consumo, si viene addebitati per l'uso di spazio di archiviazione, non per quanto spazio è stato assegnato. A livello generale, si paga un costo per la quantità di dati logici archiviati e vengono addebitati anche i costi per le transazioni in base all'utilizzo di tali dati. La fatturazione con pagamento in base al consumo può essere difficile da pianificare come parte di un processo di budget, perché si paga in base al consumo dell'utente finale. È quindi consigliabile usare il modello v2 di cui è stato effettuato il provisioning per le nuove distribuzioni di condivisioni file classiche. Il modello con pagamento in base al consumo è disponibile solo per l'archiviazione HDD.

Disponibilità con pagamento in base al consumo

Il modello con pagamento in base al consumo è disponibile per le combinazioni seguenti di livello multimediale, ridondanza e protocollo di condivisione file:

Livello supporti Ridondanza Protocollo di condivisione file Condivisioni file classiche (Microsoft.Storage) Condivisione di file (Microsoft.FileShares)
SSD (unità a stato solido) Local Piccole e Medie Imprese (PMI) No No
SSD (unità a stato solido) Zona Piccole e Medie Imprese (PMI) No No
SSD (unità a stato solido) Local NFS No No
SSD (unità a stato solido) Zona NFS No No
HDD Local Piccole e Medie Imprese (PMI) Sì No
HDD Zona Piccole e Medie Imprese (PMI) Sì No
HDD Geo Piccole e Medie Imprese (PMI) Sì No
HDD GeoZone Piccole e Medie Imprese (PMI) Sì No
HDD Local NFS No No
HDD Zona NFS No No
HDD Geo NFS No No
HDD GeoZone NFS No No

Le condivisioni file classiche HDD che usano il modello con pagamento in base al consumo sono disponibili a livello generale in tutte le aree di Azure.

Differenze nei livelli di accesso

Quando si crea una condivisione file classica in un account di archiviazione con pagamento in base al consumo, è possibile scegliere tra i seguenti livelli di accesso: ottimizzato per le transazioni, a caldo e a freddo. Tutti e tre i livelli di accesso vengono archiviati nello stesso hardware di archiviazione. La differenza principale per questi tre livelli di accesso è costituita dai prezzi di archiviazione dei dati inattivi, che sono inferiori nei livelli più freddi, e dai prezzi delle transazioni, che sono più elevati negli stessi livelli più freddi. Ciò significa:

  • Il livello ottimizzato per le transazioni, come suggerisce il nome, ottimizza il prezzo per i carichi di lavoro con un numero di operazioni di I/O al secondo (transazioni) elevato. A questo livello sono associati i prezzi più alti per l'archiviazione dei dati inattivi, ma i prezzi più bassi per le transazioni.
  • Hot è per i carichi di lavoro attivi che non comportano un numero elevato di transazioni. Ha un prezzo leggermente inferiore per l'archiviazione dei dati inattivi, ma prezzi delle transazioni leggermente più elevati rispetto al livello ottimizzato per le transazioni. Si consideri il mezzo tra i livelli ottimizzati per le transazioni e i livelli ad accesso sporadico.
  • Cool ottimizza il prezzo per i carichi di lavoro con attività non elevate, offrendo il prezzo di archiviazione più basso per i dati a riposo, ma i prezzi delle transazioni più alti.

La selezione del livello di accesso appropriato per il caso d'uso consente di ridurre notevolmente i costi. Se si inserisce un carico di lavoro a cui si accede raramente nel livello di accesso ottimizzato per le transazioni, si paga quasi nulla per le poche volte in un mese che si effettuano transazioni rispetto alla condivisione file classica. Tuttavia, si paga un importo elevato per i costi di archiviazione dei dati. Se si spostasse la stessa condivisione nel livello ad accesso sporadico, si continuerebbe a pagare quasi nulla per i costi di transazione, semplicemente perché le transazioni per questo carico di lavoro sono poco frequenti. Tuttavia, il livello di accesso sporadico ha un prezzo di archiviazione dei dati più economico.

Analogamente, se si inserisce un carico di lavoro a accesso frequente nel livello di accesso sporadico, si paga molto di più nei costi delle transazioni, ma meno per i costi di archiviazione dei dati. Ciò può causare una situazione in cui l'aumento dei costi dei prezzi delle transazioni supera i risparmi derivanti dal prezzo di archiviazione dei dati ridotto e potrebbe essere necessario pagare di più per l'accesso sporadico rispetto a quanto si sarebbe pagato per la transazione ottimizzata. Per alcuni livelli di utilizzo, è possibile che il livello ad accesso frequente sia il più conveniente, e che il livello ad accesso sporadico sia più costoso rispetto a quello ottimizzato per le transazioni.

Il carico di lavoro e il livello di attività determinano il livello di accesso più conveniente per la condivisione file classica con pagamento in base al consumo. In pratica, il modo migliore per scegliere il livello di accesso più conveniente prevede l'analisi del consumo effettivo delle risorse della condivisione (dati archiviati, transazioni di scrittura e così via). Per le condivisioni file classiche con pagamento in base al consumo, è consigliabile iniziare nel livello ottimizzato per le transazioni durante la migrazione iniziale in File di Azure e quindi scegliere il livello di accesso corretto in base all'utilizzo al termine della migrazione. L'utilizzo delle transazioni durante la migrazione in genere non è indicativo del normale utilizzo delle transazioni.

Che cosa sono le transazioni?

Quando si monta una condivisione file classica usando il modello con pagamento in base al consumo in un computer con SMB, la condivisione file classica viene esposta nel computer come se fosse una risorsa di archiviazione locale. Ciò significa che applicazioni, script e altri programmi nel computer possono accedere ai file e alle cartelle nella condivisione file classica senza dover sapere che sono archiviati in Azure.

Quando si legge o si scrive in un file, l'applicazione usata esegue una serie di chiamate API all'API del file system fornita dal sistema operativo. Il sistema operativo interpreta quindi queste chiamate nelle transazioni del protocollo SMB, che vengono inviate tramite la rete a Azure Files per l'elaborazione da parte di quest'ultimo. Un'attività semplice che l'utente finale percepisce come una singola operazione, ad esempio la lettura di un file dall'inizio alla fine, potrebbe essere convertita in più transazioni SMB gestite da File di Azure.

In linea di principio, le condivisioni file classiche utilizzano un modello di fatturazione in base al consumo. Le transazioni SMB e FileREST effettuate da applicazioni e script rappresentano l'utilizzo della condivisione file classica e vengono visualizzate come parte della fattura. Lo stesso concetto si applica ai servizi cloud a valore aggiunto che è possibile aggiungere alla condivisione, ad esempio Sincronizzazione file di Azure o Backup di Azure.

Le transazioni vengono raggruppate in cinque diverse categorie di transazioni che hanno prezzi diversi in base al loro impatto sulla condivisione file classica. Queste categorie sono: scrittura, elenco, lettura, altro ed eliminazione.

La tabella seguente illustra la categorizzazione di ogni transazione:

Contenitore delle transazioni Operazioni di gestione Operazioni sui dati
Transazioni di scrittura
  • CreateShare
  • SetFileServiceProperties
  • SetShareMetadata
  • SetShareProperties
  • SetShareAcl
  • SnapshotShare
  • RestoreShare
  • CopyFile
  • Create
  • CreateDirectory
  • CreateFile
  • PutRange
  • PutRangeFromURL
  • SetDirectoryMetadata
  • SetFileMetadata
  • SetFileProperties
  • SetInfo
  • Write
  • PutFilePermission
  • Flush
  • SetDirectoryProperties
Elencare le transazioni
  • ListShares
  • ListFileRanges
  • ListFiles
  • ListHandles
Lettura delle transazioni
  • GetFileServiceProperties
  • GetShareAcl
  • GetShareMetadata
  • GetShareProperties
  • GetShareStats
  • FilePreflightRequest
  • GetDirectoryMetadata
  • GetDirectoryProperties
  • GetFile
  • GetFileCopyInformation
  • GetFileMetadata
  • GetFileProperties
  • QueryDirectory
  • QueryInfo
  • Read
  • GetFilePermission
Altre transazioni/protocolli
  • AcquireShareLease
  • BreakShareLease
  • ReleaseShareLease
  • RenewShareLease
  • ChangeShareLease
  • AbortCopyFile
  • Cancel
  • ChangeNotify
  • Close
  • Echo
  • Ioctl
  • Lock
  • Logoff
  • Negotiate
  • OplockBreak
  • SessionSetup
  • TreeConnect
  • TreeDisconnect
  • CloseHandles
  • AcquireFileLease
  • BreakFileLease
  • ChangeFileLease
  • ReleaseFileLease
Eliminare transazioni
  • DeleteShare
  • ClearRange
  • DeleteDirectory
  • DeleteFile

Nota

NFSv4.1 è disponibile solo per le condivisioni file SSD che utilizzano i modelli di fatturazione v2 o v1 con provisioning. I bucket delle transazioni non influiscono sulla fatturazione per le condivisioni file di cui è stato effettuato il provisioning.

Passaggio tra livelli di accesso

Anche se è possibile modificare il livello di accesso di una condivisione file classica usando il modello con pagamento in base al consumo, la procedura consigliata per ottimizzare i costi dopo la migrazione iniziale consiste nel selezionare il livello di accesso ottimale più costoso e rimanere in tale posizione, a meno che il modello di accesso non cambi. Ciò è dovuto al fatto che la modifica del livello di accesso di una condivisione file classica comporta costi aggiuntivi come indicato di seguito:

  • Transazioni: quando si sposta una condivisione da un livello di accesso più frequente a un livello di accesso più sporadico, si comporta l'addebito delle transazioni di scrittura del livello di accesso più sporadico per ogni file nella condivisione file classica. Lo spostamento di una condivisione file classica da un livello di accesso più freddo a un livello di accesso più caldo comporta l'addebito delle transazioni di lettura del livello di accesso più freddo per ogni file nella condivisione file classica.

  • Recupero dati: se si passa dal livello di accesso sporadico a quello ottimizzato per le transazioni o ad accesso frequente, viene addebitato un addebito per il recupero dei dati in base alle dimensioni dei dati spostati. Solo il livello di accesso sporadico ha un addebito per il recupero dei dati.

La tabella seguente illustra la suddivisione dei costi dei livelli di accesso in movimento:

Livello di accesso Ottimizzazione delle transazioni (destinazione) Accesso frequente (destinazione) Fantastico (destinazione)
Ottimizzato per le transazioni (origine) --
  • Una transazione di scrittura ad accesso frequente per ogni file.
  • Una transazione di scrittura ad accesso sporadico per ogni file.
Accesso frequente (origine)
  • Una transazione di lettura rapida per ogni file.
    --
    • Una transazione di scrittura ad accesso sporadico per ogni file.
    Accesso sporadico (origine)
    • Una transazione di lettura ad accesso sporadico per ogni file.
    • Recupero dati per GiB totali utilizzati.
    • Una transazione di lettura ad accesso sporadico per ogni file.
    • Recupero dati per GiB totali utilizzati.
    --

    È possibile modificare il livello di accesso di una condivisione file classica fino a cinque volte all'interno di una finestra di 30 giorni. Il primo giorno della finestra di 30 giorni inizia quando si verifica la modifica del primo livello. Le modifiche tra i livelli di accesso si verificano immediatamente, tuttavia, dopo aver modificato il livello di accesso di una condivisione, non è possibile modificarlo di nuovo entro 24 ore, anche se la proprietà del livello di accesso è stata modificata meno di cinque volte negli ultimi 30 giorni.

    Scelta di un livello di accesso

    Indipendentemente dalla modalità di migrazione dei dati esistenti in File di Azure, è consigliabile creare inizialmente la condivisione file classica nel livello di accesso ottimizzato per le transazioni. Ciò è dovuto al numero elevato di transazioni eseguite durante la migrazione. Al termine della migrazione e al funzionamento per alcuni giorni o settimane con un utilizzo regolare, è possibile collegare i conteggi delle transazioni nel calcolatore dei prezzi per determinare quale livello di accesso è più adatto per il carico di lavoro.

    Poiché gli account di archiviazione con pagamento in base al consumo mostrano solo le informazioni sulle transazioni a livello di account di archiviazione, l'uso delle metriche di archiviazione per stimare il livello di accesso più economico a livello di condivisione file classica è una scienza imperfetta. Se possibile, è consigliabile distribuire una sola condivisione file classica in ogni account di archiviazione per garantire una visibilità completa sulla fatturazione.

    Per visualizzare le transazioni precedenti:

    1. Passare all'account di archiviazione nel portale di Azure.
    2. Nel menu del servizio, in Monitoraggio, selezionare Metriche.
    3. Selezionare Ambito come nome dell'account di archiviazione, Spazio dei nomi della metrica come "File", Metrica come "Transazioni" e Aggregazione come "Somma".
    4. Selezionare Applicare separazione.
    5. Selezionare Valori come "Nome API". Selezionare il limite e l'ordinamento desiderati.
    6. Selezionare il periodo di tempo desiderato.

    Nota

    Assicurarsi di visualizzare le transazioni in un lungo periodo di tempo per ottenere un'idea realistica del numero medio di transazioni. Assicuratevi che il periodo di tempo scelto non si sovrapponga al provisioning iniziale. Moltiplicare il numero medio di transazioni durante questo periodo di tempo per ottenere le transazioni stimate per un intero mese.

    Modelli di risorse con pagamento in base al consumo

    È possibile creare una condivisione file con pagamento in base al consumo solo come condivisione file classica all'interno di un account di archiviazione (Microsoft.Storage).

    Condivisioni file classiche con pagamento in base al consumo (Microsoft.Storage)

    Per creare una condivisione file classica usando il modello con pagamento in base al consumo, l'account di archiviazione deve usare una delle combinazioni di impostazioni seguenti:

    Tipo di account di archiviazione SKU dell'account di archiviazione Tipo di condivisione file disponibile
    StorageV2 Archiviazione con ridondanza locale Standard Condivisione file HDD con pagamento in base al consumo con ridondanza locale specificata.
    StorageV2 Archiviazione con ridondanza della zona Standard Condivisione file HDD con pagamento in base al consumo con ridondanza della zona specificata.
    StorageV2 Archiviazione con ridondanza geografica Standard Condivisione file HDD con pagamento in base al consumo con ridondanza geografica specificata.
    StorageV2 Archiviazione con ridondanza geografica della zona Standard Condivisione file HDD con pagamento in base al consumo con ridondanza geografica della zona specificata.
    StorageV2 Standard_RAGRS Condivisione file HDD con pagamento in base al consumo con ridondanza geografica specificata.
    StorageV2 Standard_RAGZRS Condivisione file HDD con pagamento in base al consumo con ridondanza geografica della zona specificata.

    Le condivisioni file classiche create nello stesso account di archiviazione condividono i limiti dell'account di archiviazione per lo spazio di archiviazione, le operazioni di I/O al secondo e la velocità effettiva:

    Attribute Valore HDD Strategia di imposizione
    Spazio di archiviazione massimo usato per ogni account di archiviazione 5 PiB (5.242.880) L'utilizzo è limitato.
    Numero massimo di operazioni di I/O al secondo usate per ogni account di archiviazione
    • Selezionare le aree: 40.000 operazioni di I/O al secondo
    • Impostazione predefinita: 20.000 operazioni di I/O al secondo
    L'utilizzo al di sopra del limite è limitato.
    Velocità massima utilizzata di trasferimento dati per account di archiviazione
    • Selezionare le aree:
      • Ingresso: 7.680 MiB/sec
      • Uscita: 25.600 MiB/sec
    • Impostazione predefinita:
      • Ingresso: 3.200 MiB/sec
      • Uscita: 6.400 MiB/sec
    L'utilizzo al di sopra del limite è limitato.
    Numero massimo di condivisioni file classiche per account di archiviazione Unlimited I limiti di archiviazione, IOPS e velocità effettiva sono destinati a essere un limite pratico al numero di condivisioni file classiche.

    Per altri dettagli, vedere Limiti del piano dati dell'account di archiviazione, incluse le aree geografiche che supportano l'aumento dei limiti per le operazioni di I/O al secondo (IOPS) e per la velocità effettiva.

    Per eseguire correttamente una distribuzione di File di Azure con il modello di fatturazione con pagamento in base al consumo nelle condivisioni file classiche, è necessario considerare le dimensioni seguenti della pianificazione della capacità:

    • Quanto spazio di archiviazione, operazioni di I/O al secondo e velocità effettiva usate è necessario per ogni condivisione file classica? In che modo questi requisiti cambiano nel tempo?
      A causa dei limiti dell'account di archiviazione condiviso, quando si allocano condivisioni file classiche agli account di archiviazione, è necessario considerare le esigenze di ogni condivisione file classica sia ora che nel tempo. A differenza dei modelli v2 e v1 con provisioning, il modello con pagamento in base al consumo offre poche protezioni per la condivisione dei limiti dell'account di archiviazione tra le condivisioni file classiche nello stesso account di archiviazione. Ogni condivisione file classica in un account di archiviazione con pagamento in base al consumo può estendersi fino ai limiti della condivisione file classica per le dimensioni della condivisione file e fino ai limiti dell'account di archiviazione per le operazioni di I/O al secondo e la velocità effettiva. L'inserimento di due condivisioni di file classiche nello stesso account di archiviazione con pagamento in base al consumo potrebbe causare contenzioso su IOPS o throughput. Per evitare limitazioni impreviste, limitare il numero di condivisioni file classiche inserite in un account di archiviazione con pagamento in base al consumo.

    • Avete requisiti speciali riguardo al monitoraggio della fattura per ciascuna condivisione file classica per risalire a singoli progetti, reparti o clienti?
      In Azure la granularità più bassa per cui è possibile visualizzare la fatturazione è la risorsa, ovvero se si inseriscono due condivisioni file classiche nello stesso account di archiviazione, non è possibile tenere traccia dei costi in singoli progetti, reparti o clienti. Per risolvere questo problema, raggruppare le condivisioni file classiche in account di archiviazione in base al modo in cui devono essere monitorate dal punto di vista della fatturazione.

    • Quanti account di archiviazione sono disponibili nella sottoscrizione per l'area di destinazione?
      Un fattore di complicazione aggiuntivo è il numero di account di archiviazione che è possibile avere per ogni sottoscrizione per area. Per altre informazioni, vedere Microsoft.Storage Limiti del piano di controllo . A seconda del numero di account di archiviazione necessari, potrebbe essere necessario usare sottoscrizioni aggiuntive per ottenere account di archiviazione aggiuntivi.

    Snapshot con pagamento in base al consumo

    File di Azure supporta gli snapshot, che sono simili alle copie shadow del volume nei file server Windows. Per altre informazioni sugli snapshot di condivisione, vedere Panoramica degli snapshot per File di Azure.

    Gli snapshot sono sempre differenziali rispetto alla condivisione attiva e l'uno dall'altro. Nel modello di fatturazione con pagamento in base al consumo, le dimensioni differenziali totali vengono fatturate rispetto al normale contatore dell'archiviazione usata. Ciò significa che non verrà visualizzata una voce separata nella fattura che rappresenta gli snapshot per l'account di archiviazione con pagamento in base al consumo. Ciò significa anche che l'utilizzo differenziale degli snapshot viene conteggiato per il calcolo delle prenotazioni acquistate per le condivisioni file classiche con pagamento in base al consumo.

    Eliminazione temporanea con pagamento in base al consumo

    Le condivisioni file classiche eliminate negli account di archiviazione con eliminazione temporanea abilitata vengono fatturate in base alla capacità di archiviazione usata per il periodo di conservazione definito. La capacità di archiviazione usata eliminata temporaneamente viene emessa in rapporto al normale contatore dell'archiviazione usata. Ciò significa che nella fattura non sarà presente una voce separata che rappresenta le condivisioni file classiche eliminate temporaneamente per l'account di archiviazione con pagamento in base al consumo. Significa anche che l'utilizzo delle condivisioni file classiche eliminate temporaneamente vengono conteggiate per il calcolo delle prenotazioni acquistate per le condivisioni file classiche con pagamento in base al consumo.

    Contatori di fatturazione con pagamento in base al consumo

    Le condivisioni file classiche create con il modello di fatturazione con pagamento in base al consumo vengono fatturate in base ai contatori seguenti:

    • Dati archiviati: lo spazio di archiviazione usato, incluse le condivisioni attive, gli snapshot differenziali e le condivisioni file classiche eliminate temporaneamente in GiB.
    • Metadati: dimensioni dei metadati del file system associati a file e directory, ad esempio elenchi di controllo di accesso (ACL) e altre proprietà in GiB. Questo contatore di fatturazione viene usato solo per le condivisioni file classiche nei livelli di accesso frequente o sporadico.
    • Operazioni di scrittura: numero di bucket di transazioni di scrittura (un bucket = 10.000 transazioni).
    • Operazioni elenco: numero di bucket di transazioni di elenco (un bucket = 10.000 transazioni).
    • Operazioni di lettura: numero di bucket di transazioni di lettura (un bucket = 10.000 transazioni).
    • Altre operazioni / Operazioni protocollo: numero di altri bucket di transazioni (un bucket = 10.000 transazioni).
    • Recupero dati: quantità di dati letti dalla condivisione file classica in GiB. Questo misuratore viene utilizzato solo per le condivisioni file classiche nel livello di accesso freddo.
    • Trasferimento dei dati di replica geografica: se la condivisione file classica include la ridondanza geografica o la ridondanza geografica della zona, la quantità di dati scritti nella condivisione file classica replicati nell'area secondaria in GiB.

    Le unità di consumo rispetto ai contatori di fatturazione dei dati archiviati e dei metadati vengono generate ogni ora in termini di unità mensili. Ad esempio, per una condivisione con 1.024 GiB usati, dovrebbe apparire:

    • Numero variabile di unità per un'ora singola a seconda del numero di giorni nel mese:
      • Mese di 28 giorni (febbraio normale): 1.5238 unità nel contatore Dati archiviati.
      • Mese di 29 giorni (febbraio di anno bisestile): 1.4713 unità nel contatore Dati archiviati.
      • Mese di 30 giorni: 1.4222 unità nel contatore Dati archiviati.
      • Mese di 31 giorni: 1.3763 unità nel contatore Dati archiviati.
    • Numero variabile di unità se aggregato per un giorno a seconda del numero di giorni nel mese:
      • Mese di 28 giorni (febbraio normale): 36.5714 unità nel contatore Dati archiviati.
      • Mese di 29 giorni (febbraio di anno bisestile): 35.3103 unità nel contatore Dati archiviati.
      • Mese di 30 giorni: 34.1333 unità nel contatore Dati archiviati.
      • Mese di 31 giorni: 33.0323 unità nel contatore Dati archiviati.
    • 1.024 unità nel contatore Dati archiviati se aggregate per un mese.

    Il consumo rispetto agli altri contatori (ad esempio operazioni di scrittura o recupero dati) viene generato ogni ora, ma poiché questi contatori non dispongono di un intervallo di tempo specifico associato, non hanno trasformazioni di unità speciali da tenere presente.

    Allocazione/quota, dimensioni logiche e dimensioni fisiche

    File di Azure tiene traccia di tre quantità diverse rispetto alla capacità di condivisione:

    • Dimensioni di provisioning o quota: con le condivisioni file con provisioning e con quelle con pagamento in base al consumo, è possibile specificare le dimensioni massime che la condivisione file può raggiungere. Nelle condivisioni file provisionate, questo valore è chiamato dimensione provisionata. Qualsiasi importo di cui si effettua il provisioning è quello che si paga, indipendentemente dalla quantità effettivamente usata. Nelle condivisioni file con pagamento in base al consumo, questo valore viene chiamato quota e non influisce direttamente sulla fattura. Le dimensioni di provisioning sono un campo obbligatorio per le condivisioni file di cui è viene effettuato il provisioning. Per le condivisioni file con pagamento in base al consumo, se le dimensioni di cui è stato effettuato il provisioning non vengono specificate direttamente, per impostazione predefinita la condivisione viene impostato sul valore massimo supportato dall'account di archiviazione (100 TiB).

    • Dimensioni logiche: le dimensioni logiche di una condivisione file o di un file si riferiscono alla dimensione in cui è effettivamente archiviata, senza alcuna ottimizzazione dell'archiviazione. La dimensione logica del file è il numero di KiB/MiB/GiB che verrebbero trasferiti in rete se copiati in una posizione diversa. Sia nelle condivisioni file con provisioning che in quelle con pagamento in base al consumo, le dimensioni logiche totali della condivisione file vengono usate per l'applicazione rispetto alle dimensioni o alla quota di cui è stato effettuato il provisioning. Nelle condivisioni file con pagamento in base al consumo, le dimensioni logiche corrispondono alla quantità usata per la fatturazione dell'utilizzo dei dati inattivi. Le dimensioni logiche vengono definite "dimensioni" nella finestra di dialogo delle proprietà di Windows per un file o una cartella e come "lunghezza del contenuto" in base alle metriche File di Azure.

    • Dimensioni fisiche: le dimensioni fisiche del file sono correlate alle dimensioni del file come codificate su disco. Le dimensioni fisiche potrebbero essere allineate alle dimensioni logiche del file o potrebbero essere inferiori, a seconda del modo in cui il file è stato scritto dal sistema operativo. Un motivo comune per cui le dimensioni logiche e le dimensioni fisiche sono diverse consiste nell'usare file di tipo sparse. Le dimensioni fisiche effettive dei file nella condivisione vengono usate per la fatturazione basata sugli snapshot, anche se gli intervalli di memoria allocati vengono condivisi tra gli snapshot se rimangono invariati (archiviazione differenziale).

    Servizi a valore aggiunto

    Come molte soluzioni di archiviazione locali, File di Azure fornisce punti di integrazione per prodotti di prima e di terze parti da integrare con condivisioni file di proprietà del cliente. Anche se queste soluzioni possono offrire un notevole valore aggiuntivo per File di Azure, è consigliabile considerare i costi aggiuntivi che questi servizi aggiungono al costo totale di una soluzione File di Azure.

    I costi vengono suddivisi in tre bucket:

    • Costi di licenza per il servizio a valore aggiunto. I costi di licenza possono essere costituiti da un costo fisso per cliente, un utente finale (talvolta definito "costo head"), una condivisione file o un account di archiviazione. Possono anche essere basati su unità di utilizzo dello spazio di archiviazione, ad esempio un costo fisso per ogni 500 GiB-blocchi di dati nella condivisione file.

    • Costi delle transazioni per il servizio a valore aggiunto. Alcuni servizi a valore aggiunto hanno il proprio concetto di transazioni oltre al modello di fatturazione File di Azure selezionato. Queste transazioni vengono visualizzate nella fattura con gli addebiti del servizio a valore aggiunto; Tuttavia, si riferiscono direttamente a come si usa il servizio aggiunto con la condivisione file.

    • Costi di File di Azure per l'uso di un servizio a valore aggiunto. File di Azure non addebita direttamente ai clienti l'aggiunta di servizi a valore aggiunto, ma come parte dell'aggiunta di valore alla condivisione file di Azure, il servizio a valore aggiunto potrebbe aumentare i costi visualizzati nella condivisione file di Azure. Questi costi sono facili da vedere con condivisioni file con pagamento in base al consumo, a causa degli addebiti delle transazioni. Se il servizio a valore aggiunto esegue transazioni sulla condivisione file per conto dell'utente, vengono visualizzate nella fattura delle transazioni di File di Azure anche se queste transazioni non sono state eseguite direttamente. Questo vale anche per le condivisioni file di cui è stato effettuato il provisioning, anche se potrebbe essere meno evidente. Le transazioni rispetto alle condivisioni file di cui è stato effettuato il provisioning da servizi con valore aggiunto vengono conteggiate rispetto ai numeri di operazioni di I/O al secondo di cui è stato effettuato il provisioning, vale a dire che i servizi a valore aggiunto potrebbero richiedere il provisioning di più risorse di archiviazione per disporre di operazioni di I/O al secondo o velocità effettiva sufficienti per il carico di lavoro.

    Quando si calcola il costo totale di proprietà per la condivisione file, è consigliabile prendere in considerazione i costi di File di Azure e di tutti i servizi a valore aggiunto da usare con File di Azure.

    Sono disponibili numerosi servizi di prima e terza parte a valore aggiunto. Questo documento illustra un subset dei servizi proprietari comuni usati dai clienti con condivisioni file di Azure. Per altre informazioni sui servizi non elencati qui, leggere la pagina dei prezzi per tale servizio.

    Sincronizzazione file di Azure

    Azure File Sync è un servizio a valore aggiunto per File di Azure che sincronizza una o più condivisioni file di Windows locali con una condivisione file di Azure. Poiché la condivisione file di Azure cloud include una copia completa dei dati in una condivisione file sincronizzata disponibile in locale, è possibile trasformare il file server Windows locale in una cache della condivisione file di Azure per ridurre il footprint locale. Per ulteriori informazioni, leggi Introduzione a Sincronizzazione file Azure.

    Quando si considera il costo totale di proprietà per una soluzione distribuita usando Sincronizzazione file di Azure, è consigliabile considerare gli aspetti dei costi seguenti:

    • Costi di capitale e operativi dei file server Windows con uno o più endpoint server. Sincronizzazione file di Azure come soluzione di replica è indipendente dalla posizione in cui si trovano i file server Windows sincronizzati con File di Azure; possono essere ospitati in locale, in una macchina virtuale di Azure o anche in un altro cloud. I costi per i server di sincronizzazione ospitati in locale o in altri provider di servizi cloud includono costi di capitale e operativi che non vengono monitorati come parte della fattura di Azure, ma fanno comunque parte del costo totale di proprietà della soluzione. Le spese in conto capitale sono i costi hardware iniziali della soluzione. Le spese operative sono i costi continui di manodopera, elettricità e così via. È consigliabile prendere in considerazione la quantità di dati che è necessario memorizzare nella cache in locale, il numero di CPU e la quantità di memoria necessari per i file server Windows per ospitare i carichi di lavoro di Sincronizzazione file di Azure e altri costi specifici dell'organizzazione. Per altre informazioni, vedere Risorse di sistema consigliate.

    • Costo delle licenze per server per i server registrati con Azure File Sync. Per usare Azure File Sync con un file server Windows specifico, è necessario prima registrarlo con la risorsa di Azure di Azure File Sync, il Servizio di sincronizzazione dell'archiviazione. Ogni server registrato dopo il primo server ha una tariffa mensile fissa. Anche se questa tariffa è piccola, è un componente della fattura da considerare. Per visualizzare il prezzo corrente della tariffa di registrazione del server per l'area desiderata, vedere la sezione Sincronizzazione file nella pagina dei prezzi di File di Azure.

    • Costi dei file di Azure. Sincronizzazione file di Azure usa risorse dalla condivisione file di Azure. Alcune di queste risorse, ad esempio il consumo di archiviazione, sono relativamente ovvie, mentre altre, ad esempio l'utilizzo delle transazioni e degli snapshot, potrebbero non essere. Per la maggior parte dei clienti, consigliamo di usare condivisioni file con provisioning v2 HDD con Sincronizzazione file di Azure, anche se questa funzionalità è completamente supportata in tutti i modelli di fatturazione di File di Azure (SSD con provisioning v2, SSD con provisioning v1 o HDD con pagamento in base al consumo).

      • Utilizzo dello spazio di archiviazione. Azure File Sync replica tutte le modifiche apportate al tuo endpoint server nella tua condivisione file su Azure, consumando spazio di archiviazione. Nelle condivisioni di file di cui è stato effettuato il provisioning, le modifiche utilizzano lo spazio provisionato, quindi è responsabilità dell'utente aumentare periodicamente il provisioning se necessario per tenere conto della crescita della condivisione di file. Nelle condivisioni file con pagamento in base al consumo, l'aggiunta o l'aumento delle dimensioni dei file esistenti negli endpoint server determina l'aumento dei costi di archiviazione usati perché le modifiche vengono replicate.

      • Utilizzo dello snapshot. Sincronizzazione file di Azure accetta gli snapshot a livello di condivisione e di file come parte del normale utilizzo. Anche se l'utilizzo degli snapshot è sempre differenziale, questo può contribuire in modo significativo alla fattura totale di Azure Files.

      • Utilizzo di operazioni di I/O al secondo/velocità effettiva: Sincronizzazione file di Azure gestisce l'utilizzo di operazioni di I/O al secondo e velocità effettiva per trasferire le modifiche dagli endpoint del server alla condivisione file di Azure. Se si utilizza una condivisione file di cui è stato effettuato il provisioning, è necessario monitorarne l'utilizzo per garantire di disporre di IOPS e larghezza di banda sufficienti, in modo da evitare limitazioni. Se si usa una condivisione file con pagamento in base al consumo, viene addebitato l'utilizzo delle operazioni di I/O al secondo sotto forma di transazioni. In genere, esistono due tipi di transazioni da considerare:

        • Transazioni dalla varianza. Man mano che i file cambiano negli endpoint server, le modifiche vengono caricate nella condivisione cloud, che genera transazioni. Quando è abilitata la suddivisione in livelli nel cloud, vengono generate transazioni aggiuntive per la gestione dei file suddivisi in livelli, tra cui le operazioni di I/O sui file a livelli, in aggiunta ai costi di uscita. Anche se la quantità e il tipo di transazioni sono difficili da prevedere a causa di tassi di varianza e efficienza della cache, è possibile usare i modelli di transazione precedenti per stimare i costi futuri se si ritiene che l'utilizzo futuro sarà simile all'utilizzo corrente.

        • Transazioni dall'enumerazione cloud. Sincronizzazione file di Azure enumera la condivisione file di Azure nel cloud una volta al giorno per individuare le modifiche apportate direttamente alla condivisione, in modo che possano essere sincronizzate con gli endpoint server. Questa analisi genera transazioni che vengono fatturate all'account di archiviazione con una tariffa di una transazione ListFiles per directory al giorno. È possibile inserire questo numero nel calcolatore prezzi per stimare il costo di analisi.

        Suggerimento

        Se non si conosce il numero di cartelle disponibili, consultare lo strumento TreeSize di JAM Software GmbH.

    Backup di Azure

    Backup di Azure offre una soluzione di backup serverless per File di Azure che si integra perfettamente con le condivisioni file e con altri servizi a valore aggiunto, ad esempio Sincronizzazione file di Azure. Backup di Azure per File di Azure è una soluzione di backup basata su snapshot che fornisce un meccanismo di pianificazione per l'acquisizione automatica di snapshot in base a una pianificazione definita dall'amministratore. Fornisce anche un'interfaccia intuitiva per ripristinare file/cartelle eliminati o l'intera condivisione in un determinato momento. Per altre informazioni, vedere Informazioni sul backup della condivisione file di Azure.

    Quando si valutano i costi dell'uso di Backup di Azure, considerare i fattori seguenti:

    • Costo di licenza dell'istanza protetta per i dati delle condivisioni file di Azure. Azure Backup addebita un costo di licenza per istanza protetta per ogni account di archiviazione contenente condivisioni file di Azure sottoposte a backup. Un'istanza protetta è definita come 250 GiB di spazio di archiviazione della condivisione file in Azure. Gli account di archiviazione contenenti meno di 250 GiB sono soggetti a un costo di istanza protetta frazionaria. Per altre informazioni, vedere Prezzi di Backup di Azure. È necessario selezionare File di Azure dall'elenco dei servizi che Backup di Azure può proteggere.

    • Costi dei file di Azure. Backup di Azure aumenta i costi di File di Azure nei modi seguenti:

      • Costi differenziali degli snapshot di condivisione file di Azure. Backup di Azure automatizza l'acquisizione di snapshot della condivisione file di Azure in base a una pianificazione definita dall'amministratore. Gli snapshot sono sempre differenziali; tuttavia, il costo aggiunto dipende dalla durata degli snapshot temporali mantenuti e dalla quantità di varianza nella condivisione file durante tale periodo. Questi fattori determinano la differenza tra lo snapshot e la condivisione file live e quindi la quantità di dati aggiuntivi archiviati da File di Azure.

      • Costi delle transazioni dalle operazioni di ripristino. Le operazioni di ripristino dallo snapshot alla live share comportano costi delle transazioni. Per le condivisioni di file standard, le letture dagli snapshot e le scritture dai ripristini vengono fatturate come normali transazioni di condivisione di file. Per le condivisioni file di cui è stato effettuato il provisioning, queste operazioni vengono conteggiate rispetto alle operazioni di I/O al secondo di cui è stato effettuato il provisioning per la condivisione file.

    Microsoft Defender per archiviazione

    Microsoft Defender supporta File di Azure come parte del prodotto Microsoft Defender for Storage. Microsoft Defender per Archiviazione rileva tentativi insoliti e potenzialmente dannosi di accedere o sfruttare le condivisioni file di Azure tramite SMB o FileREST. Microsoft Defender per Archiviazione è abilitato a livello di sottoscrizione per tutte le condivisioni file negli account di archiviazione in tale sottoscrizione.

    Microsoft Defender per Archiviazione non supporta le funzionalità antivirus per le condivisioni file di Azure.

    Il costo principale di Microsoft Defender per Archiviazione è un set aggiuntivo di costi delle transazioni che il prodotto applica sulle transazioni eseguite sulla condivisione file di Azure. Anche se questi costi sono basati sulle transazioni sostenute in File di Azure, non fanno parte della fatturazione per File di Azure, ma fanno parte dei prezzi di Microsoft Defender. Microsoft Defender per archiviazione addebita una tariffa delle transazioni anche nelle condivisioni file con provisioning, mentre File di Azure include le transazioni come parte del provisioning di operazioni di I/O al secondo. Il tasso delle transazioni corrente è disponibile nella pagina dei prezzi di Microsoft Defender for Cloud nella riga della tabella di Microsoft Defender for Storage.

    Le condivisioni di file ad alta intensità di transazioni comportano costi significativi usando Microsoft Defender per lo Storage. In base a questi costi, potrebbe essere necessario rifiutare esplicitamente Microsoft Defender per Archiviazione per account di archiviazione specifici. Per ulteriori informazioni, vedere Escludere un account di archiviazione dalle protezioni di Microsoft Defender per lo storage.

    Prenotazioni

    File di Azure supporta le prenotazioni (dette anche istanze riservate) per i modelli con provisioning v1 e con pagamento in base al consumo. Le prenotazioni consentono di ottenere uno sconto sull'archiviazione impegnandosi anticipatamente all'utilizzo dello spazio di archiviazione. È consigliabile considerare l'acquisto di istanze riservate per qualsiasi carico di lavoro di produzione o per workload di sviluppo/test con caratteristiche coerenti. Quando si acquista una prenotazione, è necessario specificare le dimensioni seguenti:

    • Dimensioni della capacità: le prenotazioni possono essere per 10 TiB o 100 TiB, con sconti più significativi per l'acquisto di una prenotazione di capacità superiore. È possibile acquistare più prenotazioni, incluse quelle con capacità diverse per soddisfare le esigenze di carico di lavoro. Ad esempio, se la distribuzione di produzione ha 120 TiB di condivisioni file classiche, è possibile acquistare una prenotazione da 100 TiB e due prenotazioni da 10 TiB per soddisfare i requisiti di capacità di archiviazione totali.
    • Termine: è possibile acquistare prenotazioni per un periodo di un anno o tre anni, con sconti più significativi per l'acquisto di un periodo di prenotazione più lungo.
    • Livello: Il livello del servizio Azure Files per la prenotazione. Le prenotazioni sono attualmente disponibili per i modelli di fatturazione con provisioning ssd v1 (come "Premium") e HDD con pagamento in base al consumo (solo livelli di accesso ad accesso frequente e sporadico).
    • Posizione: area di Azure per la prenotazione. Le prenotazioni sono disponibili in un subset di aree di Azure.
    • Ridondanza: ridondanza dello spazio di archiviazione per la prenotazione. Le prenotazioni sono supportate per tutte le ridondanze supportate da File di Azure, tra cui archiviazione con ridondanza locale, archiviazione con ridondanza della zona, archiviazione con ridondanza geografica e archiviazione con ridondanza geografica della zona.
    • Frequenza di fatturazione: indica la frequenza con cui viene fatturato l'account per la prenotazione. Le opzioni includono mensile o anticipata.

    Quando si acquista una prenotazione, verrà utilizzata automaticamente dall'utilizzo dello spazio di archiviazione esistente. Se si usa più spazio di archiviazione di quello riservato, si paga il prezzo di listino per il saldo non coperto dalla prenotazione. Gli addebiti per transazioni, larghezza di banda, trasferimento dei dati e archiviazione dei metadati non sono inclusi nella prenotazione.

    Le prenotazioni relative agli snapshot di condivisioni file funzionano in modo diverso per le condivisioni file con pagamento in base al consumo e con provisioning v1. Se si eseguono snapshot delle condivisioni file con pagamento in base al consumo, gli snapshot differenziali vengono conteggiati ai fini della prenotazione e vengono fatturati come parte del normale contatore dello spazio di archiviazione usato. Tuttavia, se si eseguono snapshot di condivisioni file v1 classiche con provisioning, gli snapshot vengono fatturati usando un contatore separato e non vengono conteggiati ai fini della prenotazione.

    Per altre informazioni su come acquistare prenotazioni, vedere Ottimizzare i costi per File di Azure con prenotazioni.

    Vedi anche