Informazioni sul modello di costo di Azure NetApp Files

Per gestire le spese per Azure NetApp Files, è necessario comprendere il modello di costo, tra cui capacità effettiva, prezzi e concetti di fatturazione.

Panoramica

Azure NetApp Files calcola il prezzo dell'archiviazione in base alla capacità e alle prestazioni di provisioning. Si alloca la capacità tramite pool di capacità e la si utilizza tramite volumi. Le prestazioni vengono fornite come capacità effettiva proporzionale alla capacità di provisioning (livelli di servizio Standard, Premium e Ultra) oppure come capacità effettiva di provisioning indipendentemente dalla capacità (livello di servizio Flessibile). Il servizio misura tutti i consumi su base oraria e fattura mensilmente, quindi può rispondere rapidamente ai ridimensionamenti dinamici e alle modifiche dinamiche del livello di servizio.

Questo articolo descrive il modello di fatturazione, la relazione tra capacità e prestazioni, le funzionalità che hanno un prezzo effettivo inferiore e le funzionalità del componente aggiuntivo a pagamento, ad esempio Azure NetApp Files backup e replica tra aree (CRR) che introducono componenti di fatturazione aggiuntivi. Comprende anche esempi svolti che illustrano come queste funzionalità si combinano per migliorare la capacità effettiva e il prezzo effettivo.

Nozioni fondamentali sulla fatturazione

Pool di capacità: fatturazione della capacità di provisioning

Azure NetApp Files fattura in base a una combinazione di velocità effettiva e capacità di archiviazione di provisioning, non per la quantità di dati archiviati. Si acquistano capacità e throughput tramite i pool di capacità, che costituiscono le principali unità di fatturazione. Si allocano volumi da questi pool. Vengono addebitati costi in base al livello di servizio per le dimensioni di provisioning del pool, indipendentemente dalla quantità di capacità allocata ai volumi.

Poiché la fatturazione segue il provisioning, le decisioni iniziali di dimensionamento e le modifiche dinamiche nel tempo determinano direttamente il costo. È necessario ridimensionare i volumi e i pool di capacità in modo che corrispondano alla capacità e alle prestazioni richieste dal carico di lavoro. Considerare continuamente le modifiche dinamiche per adattarsi al giusto equilibrio tra capacità, prestazioni e costi.

Misurazione oraria, fatturazione mensile

Il servizio misura l'allocazione del pool di capacità ogni ora. Ogni ora, il servizio registra le dimensioni del pool, il livello di servizio e, per il livello di servizio Flessibile, la capacità effettiva di provisioning a tale ora. La fattura mensile di Azure si basa sulle rilevazioni orarie.

La misurazione oraria è la base dell'ottimizzazione dei costi in Azure NetApp Files. Qualsiasi modifica che viene applicata durante un periodo di fatturazione, ovvero il ridimensionamento di un pool o un volume, la modifica di un livello di servizio o la modifica della velocità effettiva a livello di servizio flessibile, si riflette nella misurazione oraria successiva. È possibile adattare continuamente volumi di dimensioni, pool di capacità e carichi di lavoro senza forzare impegni a lungo termine nel pool di capacità sottostante.

Pool di capacità e volumi

Come accennato in precedenza, i pool di capacità sono le unità principali per il provisioning e la fatturazione. I volumi sono le unità per il consumo.

Regole di dimensionamento

• Pool di capacità: Un pool di capacità ha una dimensione minima di 1 TiB. È possibile ridimensionarlo con incrementi di 1 TiB fino alla dimensione massima del pool di capacità pari a 2.048 TiB. È anche possibile dimensionarlo con decrementi di 1 TiB fino a raggiungere la capacità allocata ai volumi nel pool di capacità.
• Volumi: È possibile ridimensionare un volume regolare da 50 GiB a 100 TiB. I volumi di grandi dimensioni supportano fino a 2 PiB, o 7,2 PiB per i volumi molto grandi con accesso a freddo abilitato.
• Un volume ha sia una quota di capacità che una quota di velocità effettiva. Auto QoS imposta automaticamente la quota di throughput in funzione della quota di capacità. QoS manuale imposta la quota di velocità effettiva in modo indipendente. La quota di capacità viene sottratta dalla capacità allocata del pool principale. La somma delle quote di capacità dei volumi in un pool non può superare la dimensione del pool stesso. Questa regola vale allo stesso modo per la capacità effettiva di provisioning rispetto alla quota di capacità effettiva.

Contabilità della capacità e della velocità effettiva

Per un volume, si misura il consumo di capacità rispetto alla quota in base alla capacità logica, la somma dei dati del file system attivi e dei dati snapshot. Il pool di capacità stesso viene fatturato in base alle dimensioni di provisioning, indipendentemente dalla capacità di volume allocata o dalla quantità di dati scritti all'interno del volume nel pool di capacità di hosting.

Si tiene conto della capacità effettiva a livello di volume rispetto alla quota di capacità effettiva del pool di capacità. Con QoS automatico, la quota viene ridimensionata in modo lineare con l'allocazione della capacità del volume. Con QoS manuale, la quota viene impostata in modo indipendente. In un pool a livello di servizio Flessibile, la somma delle quote di capacità effettiva di volume non può superare la capacità effettiva di provisioning nel pool. La capacità effettiva allocata del pool determina la voce della fattura relativa alla capacità effettiva.

Come viene effettuato il provisioning e fatturata la capacità effettiva

Si esegue il provisioning della capacità effettiva in Azure NetApp Files tramite il livello di servizio del pool di capacità. Sono disponibili due modelli.

Livelli di servizio lineari: Standard, Premium, Ultra

I livelli di servizio Standard, Premium e Ultra offrono capacità effettiva in proporzione fissa alla capacità di provisioning. Ogni TiB della capacità del pool include un'allocazione di velocità effettiva definita, quindi la velocità effettiva totale viene ridimensionata in modo lineare con le dimensioni del pool. Si paga una tariffa unica per GiB-ora che varia in base al livello di servizio: Standard ha la tariffa più bassa e il throughput per TiB più basso, mentre Ultra ha la tariffa e il throughput più alti in assoluto.

Questi livelli di servizio soddisfano i carichi di lavoro in cui le prestazioni necessarie vengono ridimensionate con le dimensioni del set di dati e la semplicità operativa di una singola dimensione basata sulla capacità è preferibile.

Livello di servizio flessibile

Il livello di servizio flessibile separa la velocità effettiva dalla capacità. Si effettua il provisioning di un pool di capacità a livello di servizio Flessibile con una capacità scelta e una capacità effettiva scelta separatamente. Il pool include un'allocazione della velocità effettiva di base di 128 MiB/s ed è possibile aggiungere un'altra velocità effettiva in incrementi di 1 MiB/s senza modificare la capacità del pool (con un massimo di 640 MiB/s per TiB).

La fatturazione per un pool di livello di servizio flessibile ha due componenti: un addebito per GiB/ora per la capacità provisionata, più un addebito per MiB/s-ora per il throughput provisionato al di sopra del livello di base. È possibile regolare la capacità e la velocità effettiva in modo indipendente in qualsiasi momento e la misurazione oraria successiva acquisisce i valori aggiornati.

Il livello di servizio flessibile si adatta ai carichi di lavoro in cui il rapporto tra velocità effettiva e capacità non è allineato ai rapporti fissi dei livelli di servizio lineari, ad esempio un set di dati di piccole dimensioni che richiede una velocità effettiva elevata o un set di dati di grandi dimensioni che richiede solo una velocità effettiva modesta.

Selezione di un livello di servizio

• Standard, Premium, Ultra: usare quando i requisiti di velocità effettiva aumentano in modo prevedibile con il volume di dati e una singola dimensione di capacità semplifica le operazioni.
• Flessibile: da usare quando i requisiti di capacità e throughput variano indipendentemente, quando il sovradimensionamento di una dimensione per ottenere l’altra sarebbe uno spreco, o quando capacità e prestazioni devono essere ottimizzate separatamente nell’arco del ciclo di vita del carico di lavoro.

Consumo di capacità

Capacità logica e fisica

La capacità logica è la quantità di dati presentati nei dati del file system attivo, oltre ai dati differenziali archiviati negli snapshot. La capacità fisica è la quantità di spazio di archiviazione occupato nel sistema.

Gli snapshot e i cloni a breve termine consentono la capacità logica di superare la capacità fisica, perché i blocchi di dati comuni vengono condivisi anziché duplicati.

Allocazione della capacità e consumo di snapshot

Gli snapshot consumano capacità della quota del volume padre e pertanto non vengono allocati né fatturati separatamente. Gli snapshot sono differenziali a livello di blocco: il consumo fisico del volume è uguale solo ai blocchi in uno o più snapshot più i blocchi modificati nel file system attivo.

Esempio: un volume da 100 TiB ha uno spazio utilizzato attivamente dal file system di 80 TiB e due snapshot che contengono 10 TiB di dati differenziali. Il consumo logico del volume è costituito da 80 TiB di dati attivi e da due snapshot che presentano ciascuno un'ulteriore visualizzazione point-in-time completa di 80 TiB, per un totale di una visualizzazione logica di 240 TiB. Il consumo fisico allocato rispetto alla quota del volume, tuttavia, è solo 90 TiB - non 240 TiB.

Come regola generale di pianificazione, un buffer di capacità del 20% è sufficiente per conservare almeno una settimana di snapshot per molti carichi di lavoro. La capacità effettiva degli snapshot dipende dal periodo di conservazione degli snapshot e dal tasso giornaliero di modifica a livello di blocco.

Allocazione della capacità e consumo di cloni a breve termine

I cloni a breve termine sono simili agli snapshot in quanto inizialmente condividono blocchi non modificati con il volume padre, ma differiscono in due modi importanti: un clone a breve termine è scrivibile e viene creato con la propria quota di volume e l'allocazione delle prestazioni. I blocchi condivisi ereditati dallo snapshot di origine non richiedono una seconda copia completa del set di dati. La quota del clone funge invece da buffer di scrittura per i blocchi che divergono dopo la creazione. Nei pool QoS automatici la velocità effettiva del clone viene determinata dalla quota assegnata al clone; nei pool QoS manuali, la velocità effettiva viene assegnata in modo indipendente. Di conseguenza, il dimensionamento di un clone a breve termine non consiste nel duplicare l'intera dimensione logica del volume padre, bensì nell'allocare capacità e prestazioni sufficienti per l'insieme dei dati soggetti a scrittura previsto nel corso del ciclo di vita del clone.

Contabilizzazione delle quote in un pool di capacità

Si consideri un pool di capacità con provisioning pari a 12 TiB, che contiene tre volumi:

• Volume A: 5 TiB di quota, 4,5 TiB utilizzati (4 TiB attivi, 500 GiB di snapshot); 500 GiB liberi.
• Volume B: 3 TiB quota, 2,5 TiB utilizzato (2,5 TiB attivo); 500 GiB gratis.
• Volume C: quota di 2 TiB, completamente esaurita (1,5 TiB attivi, 500 GiB di buffer di cloni a breve termine).

Il pool viene fatturato per i 12 TiB di provisioning. Di questo, 10 TiB viene allocato alle quote di volume, 9 TiB viene utilizzato e 8 TiB è in uso attivo. 1 TiB rimane libero entro le quote e il rimanente 2 TiB non è allocato.

Questo diagramma mostra come un pool di capacità da 12 TiB è suddiviso tra tre volumi più la capacità di riserva non allocata, con una ripartizione in spazio allocato, consumato, libero e non allocato.

I cinque livelli di capacità

Informazioni sull'ombreggiatura dei colori

Suddivisione per volume

In sintesi: del pool da 12 TiB, 9 TiB sono occupati, 1 TiB è libero entro i limiti di quota e 2 TiB rimangono non allocati: in totale, circa 3 TiB di margine residuo prima che il pool si riempia.

Dimensionamento ottimale dinamico

Poiché Azure NetApp Files è a consumo orario, supporta capacità, capacità effettiva e bilanciamento dei costi continui tramite tre regolazioni dinamiche. Ogni rettifica ha effetto sul limite di fatturazione orario successivo.

Ridimensionamento della capacità dinamica

È possibile ridimensionare pool di capacità e volumi sul posto senza tempi di inattività. Quando i requisiti di capacità cambiano, modificare il pool di conseguenza. La fatturazione viene aggiornata in base alla nuova dimensione con provisioning in corrispondenza della successiva rilevazione oraria del contatore. Questa funzionalità consente di dimensionare i carichi di lavoro con brevi periodi di picco per tali periodi, invece di sottoporli a provisioning al livello di picco per l'intero mese.

Modifica dinamica a livello di servizio

È possibile modificare un volume tra pool di livello di servizio Standard, Premium e Ultra per modificare la velocità effettiva disponibile. La fatturazione segue il livello di servizio in vigore a ogni ora, quindi un carico di lavoro che richiede prestazioni Ultra solo durante una finestra batch periodica può tornare a Standard o Premium tra le finestre.

Regolazione dinamica della velocità effettiva (livello di servizio flessibile)

I pool di capacità a livello di servizio flessibili supportano la regolazione indipendente della velocità effettiva. È possibile aumentare la velocità effettiva prima di una fase ad alte prestazioni e ridurla in seguito, senza ridimensionare la capacità. È possibile aumentare la capacità prima di una fase di crescita dei dati e ridurla in seguito, senza modificare la velocità effettiva.

Funzionalità predefinite di ottimizzazione dei costi

Azure NetApp Files include funzionalità che riducono i costi di archiviazione riducendo la tariffa pagata per GiB/h, riducendo la capacità di cui è necessario effettuare il provisioning o allineando le risorse di cui è stato effettuato il provisioning alla domanda effettiva. Queste funzionalità sono indipendenti e composte quando vengono usate insieme.

Archiviazione con accesso sporadico (suddivisione in livelli dei dati trasparente)

L'archiviazione Azure NetApp Files con funzionalità di accesso sporadico sposta i blocchi di dati a cui si accede raramente da un pool di capacità a un Archiviazione di Azure a costi inferiori. Un periodo di inattività (compreso tra 2 e 183 giorni) definisce per quanto tempo un blocco deve rimanere invariato prima che venga disattivato. Le letture dei dati a livelli sono trasparenti e i blocchi interessati vengono riportati nel livello ad accesso frequente di Azure NetApp Files, a seconda dello schema di accesso.

Ogni livello di servizio supporta l'archiviazione con accesso sporadico. Il profilo delle prestazioni dei blocchi attivi rimane invariato. Per l'archiviazione con accesso sporadico, i dati nel livello ad accesso sporadico vengono fatturati separatamente, non vengono conteggiati ai fini del provisioning del pool di capacità ad accesso frequente e non sono coperti dalla capacità riservata.

Capacità riservata

La capacità riservata rappresenta l’impegno per una quantità specifica di capacità di Azure NetApp Files. La prenotazione applica uno sconto alla tariffa per GiB della capacità all'interno della prenotazione. Si pagano tariffe con pagamento in base al consumo per l'utilizzo oltre la prenotazione.

È possibile combinare le prenotazioni tra i livelli di servizio, ma non si sovrapmettono con accordi di sconto di livello superiore, ad esempio MACC.

In Azure NetApp Files l'archiviazione con prenotazioni di accesso sporadico copre la capacità di provisioning nel pool di capacità. Non si applicano ai dati che risiedono nel livello ad accesso sporadico, che è già fatturato alla tariffa inferiore del livello di accesso sporadico.

Snapshot e cloni a breve termine efficienti in termini di spazio

Gli snapshot sono di sola lettura e i cloni a breve termine sono copie virtuali temporizzate di lettura/scrittura di un volume. Poiché vengono archiviati solo i blocchi modificati, la capacità fisica utilizzata dagli snapshot e dai cloni a breve termine è in genere una piccola frazione delle dimensioni allocate del volume.

Gli snapshot e i cloni a breve termine riducono i costi in due modi. Prima di tutto, eliminano la necessità di effettuare il provisioning di volumi separati per conservare copie cronologiche per il ripristino a breve termine o creare copie complete del volume per scenari di test e sviluppo di cicli brevi. In secondo luogo, aumentano la capacità logica rappresentata da una determinata quantità di capacità di cui è stato effettuato il provisioning, riducendo a sua volta il costo per GiB dei dati fisici archiviati effettivi.

Gli snapshot sono il meccanismo principale per il ripristino rapido dei dati in Azure NetApp Files. Non sostituiscono i backup. Per la conservazione a lungo termine, la protezione contro l'eliminazione accidentale del volume e la resilienza agli errori, associare gli snapshot al backup di Azure NetApp Files.

Gli snapshot aumentano la capacità effettiva condividendo blocchi di dati non modificati con il volume attivo.

Un clone a breve termine è un volume scrivibile creato da uno snapshot. Il clone condivide blocchi comuni con il relativo padre e utilizza l'archiviazione fisica solo per blocchi nuovi o modificati all'interno del volume clone ed è indipendente dal volume padre.

I cloni temporanei eliminano la necessità di eseguire il provisioning di copie complete per carichi di lavoro di sviluppo, test, analisi o indagini forensi quando il dataset di origine è di grandi dimensioni, ma il volume previsto di dati da scrivere è ridotto. Nello strumento di stima è possibile approssimare questa esigenza usando la frequenza di modifica giornaliera dello snapshot per lo spazio del buffer di scrittura clone.

Ad esempio, se gli snapshot usano una frequenza di modifica giornaliera del 3% e lo spazio stimato del buffer di scrittura è del 5%, lo strumento di stima può usare una frequenza di modifica combinata dell'8%. Questo approccio consente di modellare la capacità correlata al clone senza ridimensionare il clone come seconda copia completa.

Esempio di stima dei cloni a breve termine illustrativo. Utilizzare insieme il tasso di modifica dello snapshot e il buffer di scrittura dei cloni per stimare la capacità a breve termine dei cloni nello strumento di stima.

Un clone a breve termine utilizza l'archiviazione fisica solo per i blocchi che differiscono dal padre.

Livello di servizio flessibile come leva per l'efficienza dei costi

Quando i requisiti di throughput e i requisiti di capacità non corrispondono alle proporzioni fisse dei livelli di servizio lineari, il livello di servizio flessibile rimuove dall'addebito la dimensione sovradimensionata. Questo vantaggio è più evidente per i carichi di lavoro ad alto throughput e bassa capacità e per i carichi di lavoro ad alta capacità e basso throughput, come le copie per il disaster recovery e gli archivi.

Si consideri un carico di lavoro di esempio che richiede solo 1 TiB di capacità con un throughput di 512 MiB/s e si osservi la differenza rispetto a un pool di capacità con livello di servizio Ultra e livello di servizio flessibile. Questa differenza è un esempio dei costi di un carico di lavoro a throughput elevato e capacità ridotta.

Risparmio esemplificativo: 39%

Viceversa, si consideri un carico di lavoro di esempio che richiede 550 TiB di capacità con un throughput di soli 128 MiB/s e si osservi la differenza tra un pool di capacità sottoposto a provisioning con il livello di servizio Standard e quello flessibile. Questa differenza è un esempio dei costi di un carico di lavoro con throughput basso e capacità elevata.

Risparmi illustrativi: 25%

Questa differenza è un esempio dei costi di un carico di lavoro con throughput basso e capacità elevata.

I pool di capacità a livello di servizio flessibili supportano l'accesso sporadico, gli snapshot, i cloni a breve termine, la replica e il backup. Nessuna di queste capacità è esclusiva del livello di servizio flessibile.

Funzionalità dei componenti aggiuntivi fatturate

Oltre all'unità di fatturazione principale del pool di capacità, Azure NetApp Files offre funzionalità aggiuntive a pagamento. Ogni funzionalità viene fatturata separatamente dal provisioning del pool di capacità e genera voci distinte nella fattura mensile.

Backup di Azure NetApp Files

Il backup di Azure NetApp Files archivia le istantanee del volume nell'archiviazione di Azure all'esterno del volume, garantendo la conservazione a lungo termine e la protezione dall'eliminazione accidentale del volume. La fatturazione del backup si compone di due elementi: una tariffa per GiB al mese per lo spazio di archiviazione del vault di backup utilizzato (dopo la prima baseline completa vengono archiviati solo i blocchi modificati) e una tariffa per GiB per le operazioni di ripristino. Poiché solo i blocchi differenziali vengono conservati dopo la baseline iniziale, l'aumento dell'archiviazione di backup continua tiene traccia della frequenza di modifica dello snapshot anziché delle dimensioni logiche complete a livello di file.

Replica tra più aree

La replica tra aree replica in modo asincrono un volume di origine in un volume di destinazione in un'altra area Azure per il ripristino di emergenza. Il volume di destinazione viene predisposto in un pool di capacità nell'area geografica di destinazione e viene fatturato alla tariffa standard del pool. Inoltre, il trasferimento dei dati replicati tra regioni è misurato e fatturato in base a una tariffa di trasferimento per GiB. Le pianificazioni di replica (10 minuti, orarie, giornaliere) e i tassi di modifica influiscono sulla quantità di dati modificati trasferiti, ma non sul costo della capacità di destinazione, che dipende dalla dimensione provisionata del pool di destinazione. Per ottimizzare i costi dei dati di disaster recovery inattivi, è possibile configurare un volume di destinazione con livello di servizio Flexible con il throughput di base di 128 MiB/s, riducendo al minimo i costi mentre la replica non serve il traffico di produzione.

Capacità effettiva e concetti di prezzo effettivo

Capacità effettiva

La capacità effettiva è la quantità totale di dati logici accessibili in relazione alla capacità di provisioning. Gli snapshot aumentano la capacità effettiva mantenendo le viste temporizzate e i cloni a breve termine estendono tale vantaggio fornendo copie virtuali scrivibili che usano solo blocchi differenziali.

Esempio: un volume da 50 TiB interamente utilizzato, con quattro snapshot che accumulano 5 TiB di spazio snapshot, offre 250 TiB di capacità logica (il file system attivo più quattro copie point-in-time), mentre la capacità di provisioning e quella consumata sono pari a (soli) 55 TiB.

Prezzo effettivo

Il concetto di prezzo effettivo è il costo per GiB di dati logici dopo aver contabilizzato la suddivisione in livelli, le prenotazioni, i guadagni effettivi della capacità e qualsiasi sconto negoziato.

Queste funzionalità riducono il prezzo effettivo in due modi: riducono il costo complessivo pagato e/o aumentano la quantità di dati utilizzabili che si ottengono dalla stessa capacità di cui è stato effettuato il provisioning. Le prenotazioni e l'accesso sporadico permettono di ridurre i costi, mentre gli snapshot, i cloni a breve termine e il dimensionamento corretto del livello di servizio flessibile consentono di ottenere più valore dalla capacità di provisioning.

Il prezzo effettivo riflette gli sconti e i guadagni di capacità basati sulle capacità applicati alla tariffa di listino.

Esempi di modellazione dei costi

I prezzi negli esempi usano tariffe rappresentative e dipendono dall'area geografica. Per informazioni sulle tariffe correnti nell'area geografica, vedere la pagina dei prezzi Azure NetApp Files.

Esempio 1: ridimensionamento della capacità dinamica

Un carico di lavoro usa un pool di capacità Premium con il profilo mensile seguente: 24 ore a 10 TiB, 96 ore a 24 TiB, 24 ore a 5 TiB, 480 ore a 6 TiB e il resto a 0 TiB. Paghi $0,000403 per GiB-ora di capacità.

Risparmio: $ 4.892,64 al mese (69%)

Esempio 2: Modifica dinamica a livello di servizio

La capacità è costante a 24 TiB. I requisiti di prestazioni variano: 384 ore a Standard ($ 0,000202 per GiB-hour), 120 ore in Premium ($ 0,000403), 168 ore su Ultra ($ 0,000538) e 48 ore indietro a Standard.

Risparmio: $ 3.970,38 al mese (42%)

Esempio 3: Archiviazione con accesso sporadico e prenotazioni

Un'organizzazione ha 550 TiB di dati di condivisione file in un pool di capacità Standard. Il prezzo di listino è $0,147 per GiB-month. Si stima che l’80% dei dati (440 TiB) venga spostato nel livello ad accesso sporadico a $ 0,059 per GiB/mese. 110 TiB rimane nel livello ad accesso frequente. Una prenotazione di 1 anno del livello di servizio Standard da 100 TiB (sconto del 18%) copre una parte dell'accesso frequente.

Il prezzo effettivo scende da $ 0,147 a $ 0,073 per GiB-month (circa 50% inferiore alla base).

Esempio 4: Istantanee

Un volume Premium da 110 TiB conserva tre snapshot giornalieri. La frequenza di modifica giornaliera è 3%. Il prezzo di listino Premium è di $ 0,294 per GiB-month.

Caso di base: volume Premium da 110 TiB senza snapshot.

Con gli snapshot giornalieri:

• Tre snapshot giornalieri con un tasso di modifica del 3% aggiungono circa 10 TiB di dati differenziali
• La capacità totale utilizzata è di circa 120 TiB
• Il footprint logico è di 440 TiB (il dataset attivo più tre viste recuperabili a un determinato momento nel tempo)
• Il prezzo effettivo scende a circa $0,080 per GiB di dati accessibili, ovvero al 73% circa del prezzo di listino per la stessa capacità recuperabile

Con istantanee giornaliere: capacità effettiva quadruplicata con un piccolo incremento dei costi fisici.

Esempio 5: cloni a breve termine

Un volume di origine da 50 TiB con livello di servizio Premium viene utilizzato per creare un clone a breve termine per test e analisi. Il set funzionante di scrittura previsto del clone è pari a 5 TiB. Il prezzo di listino Premium è di $ 0,294 per GiB-month.

Con un clone a breve termine:

• La capacità di provisioning è di 5 TiB anziché 50 TiB, dimensionata solo per il set funzionante di scrittura previsto di 5 TiB
• 5 TiB × 1024 GiB/TiB × $ 0,294 = $ 1,506 al mese, una riduzione di circa 90%

Riduzione approssimativa: 90%

Con un clone a breve termine, il set di dati di origine rimane condiviso mentre viene effettuato il provisioning della capacità solo per il set funzionante di scrittura previsto.

Esempio 6: Livello di servizio flessibile allineato al carico di lavoro

Quattro carichi di lavoro, ognuno confrontato tra un livello di servizio lineare di cui è stato effettuato il provisioning per soddisfare la velocità effettiva massima e una configurazione a livello di servizio flessibile ridimensionata in base ai requisiti effettivi di velocità effettiva e capacità.

In ogni caso, il livello di servizio flessibile rimuove dalla fattura la dimensione sovradimensionata. Se il carico di lavoro richiede una velocità effettiva elevata in un set di dati di piccole dimensioni, la capacità viene ridotta. Quando il carico di lavoro richiede una capacità elevata a velocità effettiva ridotta, la velocità effettiva viene ridotta alla baseline.

Combinazione dei concetti di capacità effettiva e di prezzo effettivo

Un dataset da 110 TiB utilizza tre snapshot giornaliere con un tasso di modifica giornaliero del 3% e un clone a breve termine dimensionato con un buffer di scrittura del 5% per test e analisi. L'80% del set di dati primario è idoneo all'archiviazione con accesso a bassa frequenza. Il livello ad accesso frequente rimane al livello di servizio Premium, con una prenotazione di 100 TiB che copre la maggior parte della capacità di provisioning. La copia per il ripristino di emergenza è ospitata nel livello di servizio Flexible con una baseline di 128 MiB/s per mantenere bassi i costi della replica quando è inattiva.

Base:

• Carico di lavoro primario: 110 TiB di archiviazione Premium.
• Copia scrivibile temporanea: provisionata come secondo volume Premium da 110 TiB.
• Destinazione del ripristino di emergenza: provisioning come volume Premium da 110 TiB nell'area di destinazione.
• Capacità Premium totale di provisioning: 330 TiB prima degli snapshot e dei costi di trasferimento per la replica.
• Costo di archiviazione mensile: circa $99.414 a $0,294 per GiB-month.
• Prezzo effettivo: rimane al prezzo di listino perché il provisioning di ogni copia aggiuntiva viene effettuato come duplicato quasi completo.

Capacità Premium di provisioning totale: 330 TiB | Costo di archiviazione mensile: circa $ 99.414

Con l'ottimizzazione combinata:

• Livello ad accesso frequente: 22 TiB Premium dopo la suddivisione in livelli; costo mensile circa $ 8.870.
• Livello ad accesso sporadico: 88 TiB in accesso sporadico; costo mensile di circa $ 5.304.
• Capacità riservata: la prenotazione di 100 TiB copre la maggior parte della capacità Premium del livello ad accesso frequente
• Snapshot: tre snapshot giornalieri con un tasso di variazione del 3% aggiungono circa 10 TiB di capacità differenziale.
• Footprint logico: aumenta da 110 TiB a circa 440 TiB.
• Capacità consumata: aumenta solo a circa 120 TiB.
• Clone a breve termine: buffer di scrittura del 5% anziché un secondo volume completo da 110 TiB; costo mensile di circa 1.506 $.
• Copia per il ripristino di emergenza: il livello di servizio flessibile con baseline di 128 MiB/s mantiene bassi i costi in caso di inattività.

Linea finale: il prezzo effettivo è inferiore perché il costo scende mentre la capacità utilizzabile sale.

Questo esempio mostra come le leve di costo si sommino anziché competere tra loro: lo storage con livello di accesso cool e la copertura tramite prenotazione riducono la tariffa pagata per la copia primaria, gli snapshot e i cloni a breve termine aumentano la quantità di dati logici rappresentata da una determinata quantità di capacità provisionata e il livello di servizio Flexible impedisce che il throughput del ripristino di emergenza, se sovradimensionato, faccia aumentare la fattura mensile. Il risultato è un prezzo effettivo materialmente inferiore per lo stesso patrimonio di dati protetti e testabili.

Sommario

Il modello di costo Azure NetApp Files si basa su tre proprietà chiave:

• Il provisioning determina la fatturazione. Il costo riflette la capacità di provisioning (e, per il livello di servizio Flessibile, la capacità effettiva di provisioning), non i dati archiviati.
• La misurazione è oraria. Il ridimensionamento dinamico, le modifiche dinamiche del livello di servizio e le regolazioni dinamiche del throughput flessibile hanno effetto entro un'ora e vengono riportati nella fattura mensile.
• Le capacità si sommano. L'accesso a freddo, la capacità riservata, gli snapshot, i cloni a breve termine e il livello di servizio flessibile agiscono su diverse componenti della struttura dei costi e possono essere combinati.

Dimensionare pool e volumi in base alla domanda effettiva, scegliendo il livello di servizio che corrisponde al rapporto tra capacità e velocità effettiva del carico di lavoro e la sovrapposizione delle funzionalità di ottimizzazione predefinite produce il prezzo effettivo più basso per un determinato requisito funzionale.

Capacità effettiva e prezzo effettivo forniscono la lente per comprendere il valore economico completo di Azure NetApp Files. La capacità effettiva descrive la quantità di dati logici che possono essere rappresentati o protetti da una determinata quantità di capacità di cui è stato effettuato il provisioning quando le funzionalità, ad esempio gli snapshot e i cloni a breve termine, riutilizzano blocchi non modificati anziché creare copie complete. Il prezzo effettivo esprime il costo risultante per GiB di dati utili dopo aver combinato tali miglioramenti di efficienza con suddivisione in livelli con costi inferiori, prenotazioni e provisioning allineato al carico di lavoro, ad esempio il livello di servizio Flessibile.

Insieme, questi concetti mostrano che il modello di costo Azure NetApp Files non riguarda solo il prezzo di listino della capacità di cui è stato effettuato il provisioning. Riguarda il modo in cui il servizio converte la capacità e la velocità di trasmissione fornite in dati utilizzabili, protetti e recuperabili, al minor costo possibile.

Passaggi successivi

• Pagina dei prezzi di Azure NetApp Files
• Livelli di servizio per Azure NetApp Files
• Limiti delle risorse per Azure NetApp Files
• Modello di costo per la replica tra aree
• Prenotazioni per Azure NetApp Files
• Accesso sporadico in Azure NetApp Files
• Come funzionano gli snapshot Azure NetApp Files
• Cloni di breve durata in Azure NetApp Files
• Azure NetApp Files backup
• Informazioni sulla quota del volume
• Monitorare la capacità di un volume
• Regolare la capacità del pool o di un volume
• Gestire la fatturazione usando i tag
• Domande frequenti sulla gestione della capacità
• Azure calcolatore prezzi per Azure NetApp Files
• strumenti Azure NetApp Files