Panoramica sul tiering dei dati
Suggerisci modifiche
PDF
Riduci i costi di storage abilitando il tiering automatizzato dei dati inattivi su storage a oggetti a basso costo. I dati attivi rimangono in SSD o HDD ad alte prestazioni, mentre i dati inattivi vengono suddivisi in livelli per lo storage a oggetti a basso costo. In questo modo è possibile recuperare spazio sullo storage primario e ridurre lo storage secondario.
Il tiering dei dati è basato sulla tecnologia FabricPool. Cloud Volumes ONTAP offre tiering dei dati per tutti i cluster Cloud Volumes ONTAP senza una licenza aggiuntiva. Quando abiliti il tiering dei dati, sono previsti costi per il tiering dei dati nello storage a oggetti. Fare riferimento alla documentazione del cloud provider per i dettagli sui costi dello storage a oggetti.
Tiering dei dati in AWS
Quando si abilita il tiering dei dati in AWS, Cloud Volumes ONTAP utilizza EBS come Tier di performance per i dati hot e AWS S3 come Tier di capacità per i dati inattivi.
- Tier di performance
-
Il livello di performance può essere SSD General Purpose (gp3 o gp2) o SSD IOPS con provisioning (io1).
Si sconsiglia di eseguire il tiering dei dati sullo storage a oggetti quando si utilizzano HDD ottimizzati per il throughput (st1).
- Tier di capacità
-
Un sistema Cloud Volumes ONTAP esegue il Tier dei dati inattivi in un singolo bucket S3.
BlueXP crea un singolo bucket S3 per ogni ambiente di lavoro e lo nomina fabric-pool-cluster unique identifier. Non viene creato un bucket S3 diverso per ciascun volume.
Quando BlueXP crea il bucket S3, utilizza le seguenti impostazioni predefinite:
-
Classe di storage: Standard
-
Crittografia predefinita: Disattivata
-
Blocca accesso pubblico: Blocca tutti gli accessi pubblici
-
Proprietà dell'oggetto: ACL attivati
-
Versione bucket: Disattivata
-
Blocco oggetto: Disattivato
-
- Classi di storage
-
La classe di storage predefinita per i dati Tiered in AWS è Standard. Standard è ideale per i dati ad accesso frequente memorizzati in più zone di disponibilità.
Se non si prevede di accedere ai dati inattivi, è possibile ridurre i costi di storage cambiando la classe di storage in una delle seguenti opzioni: Intelligent Tiering, One-zone infrequent Access, Standard-infrequent Access o S3 Glacier Instant Retrieval. Quando si modifica la classe di storage, i dati inattivi vengono avviati nella classe di storage Standard e vengono passati alla classe di storage selezionata, se non si accede ai dati dopo 30 giorni.
I costi di accesso sono più elevati se si accede ai dati, quindi è necessario tenerne conto prima di modificare la classe di storage. "Documentazione su Amazon S3: Scopri di più sulle classi storage di Amazon S3".
È possibile selezionare una classe di archiviazione quando si crea l'ambiente di lavoro e modificarla in qualsiasi momento. Per istruzioni sulla modifica della classe di archiviazione, fare riferimento alla "Tiering dei dati inattivi su storage a oggetti a basso costo".
La classe di storage per il tiering dei dati è estesa a tutto il sistema, non per volume.
Tiering dei dati in Azure
Quando abiliti il tiering dei dati in Azure, Cloud Volumes ONTAP utilizza i dischi gestiti da Azure come Tier di performance per i dati hot e lo storage Blob Azure come Tier di capacità per i dati inattivi.
- Tier di performance
-
Il Tier di performance può essere SSD o HDD.
- Tier di capacità
-
Un sistema Cloud Volumes ONTAP esegue il tiering dei dati inattivi in un singolo contenitore Blob.
BlueXP crea un nuovo account storage con un container per ogni ambiente di lavoro Cloud Volumes ONTAP. Il nome dell'account di storage è casuale. Non viene creato un container diverso per ogni volume.
BlueXP crea l'account storage con le seguenti impostazioni:
-
Tier di accesso: Hot
-
Performance: Standard
-
Ridondanza: Storage ridondante in locale (LRS)
-
Account: StorageV2 (General Purpose v2)
-
Richiedi trasferimento sicuro per le operazioni API REST: Abilitato
-
Access key account storage: Enabled (accesso chiave account storage)
-
Versione minima TLS: Versione 1.2
-
Crittografia dell'infrastruttura: Disattivata
-
- Tier di accesso allo storage
-
Il Tier di accesso allo storage predefinito per i dati a più livelli in Azure è il hot Tier. Il Tier hot è ideale per i dati con accesso frequente nel Tier di capacità.
Se non hai intenzione di accedere ai dati inattivi nel Tier di capacità, puoi scegliere il Tier di storage cool, in cui i dati inattivi vengono conservati per un minimo di 30 giorni. Puoi anche optare per il livello cold, in cui i dati inattivi vengono archiviati per un minimo di 90 giorni. In base ai tuoi requisiti di storage e alle tue considerazioni sui costi, puoi scegliere il Tier più adatto alle tue esigenze. Quando modifichi il Tier di storage in cool o cold, i dati del Tier di capacità inattivo vengono spostati direttamente nel Tier di storage cold o cold. I Tier "cool" e "cold" offrono costi di storage inferiori rispetto al Tier "hot", ma prevedono costi di accesso più elevati. Prima di modificare il Tier storage, è necessario tenerne conto. Fare riferimento alla "Documentazione di Microsoft Azure: Scopri di più sui Tier di accesso allo storage BLOB di Azure".
È possibile selezionare un Tier di storage quando si crea l'ambiente di lavoro e modificarlo in un secondo momento. Per ulteriori informazioni sulla modifica del livello di archiviazione, fare riferimento alla "Tiering dei dati inattivi su storage a oggetti a basso costo".
Il Tier di accesso allo storage per il tiering dei dati è esteso a tutto il sistema, non per volume.
Tiering dei dati in Google Cloud
Quando abiliti il tiering dei dati in Google Cloud, Cloud Volumes ONTAP utilizza i dischi persistenti come Tier di performance per i dati hot e un bucket di storage cloud come Tier di capacità per i dati inattivi.
- Tier di performance
-
Il Tier di performance può essere costituito da dischi persistenti SSD, dischi persistenti bilanciati o dischi persistenti standard.
- Tier di capacità
-
Un sistema Cloud Volumes ONTAP esegue il Tier dei dati inattivi in un singolo bucket di storage cloud di Google.
BlueXP crea un bucket per ogni ambiente di lavoro e lo nomina fabric-pool-cluster unique identifier. Non viene creato un bucket diverso per ogni volume.
Quando BlueXP crea il bucket, utilizza le seguenti impostazioni predefinite:
-
Tipo di ubicazione: Regione
-
Classe di storage: Standard
-
Accesso pubblico: Soggetto a ACL a oggetti
-
Controllo degli accessi: Granulare
-
Protezione: Nessuna
-
Crittografia dei dati: Chiave gestita da Google
-
- Classi di storage
-
La classe di storage predefinita per i dati a più livelli è la classe Standard Storage. Se l'accesso ai dati non è frequente, puoi ridurre i costi di storage passando a Nearline Storage o Coldline Storage. Quando si modifica la classe di archiviazione, i dati inattivi successivi vengono spostati direttamente nella classe selezionata.
Tutti i dati inattivi esistenti manterranno la classe di archiviazione predefinita quando si modifica la classe di archiviazione. Per modificare la classe di archiviazione per i dati inattivi esistenti, è necessario eseguire la designazione manualmente. I costi di accesso sono più elevati se si accede ai dati, quindi tenere in considerazione questo aspetto prima di modificare la classe di storage. Per ulteriori informazioni, fare riferimento a "Documentazione di Google Cloud: Classi di storage".
È possibile selezionare un Tier di storage quando si crea l'ambiente di lavoro e modificarlo in un secondo momento. Per informazioni dettagliate sulla modifica della classe di archiviazione, fare riferimento alla "Tiering dei dati inattivi su storage a oggetti a basso costo".
La classe di storage per il tiering dei dati è estesa a tutto il sistema, non per volume.
Tiering dei dati e limiti di capacità
Se si abilita il tiering dei dati, il limite di capacità di un sistema rimane invariato. Il limite viene distribuito tra il Tier di performance e il Tier di capacità.
Policy di tiering dei volumi
Per attivare il tiering dei dati, è necessario selezionare una policy di tiering dei volumi quando si crea, modifica o replica un volume. È possibile selezionare un criterio diverso per ciascun volume.
Alcuni criteri di tiering hanno un periodo di raffreddamento minimo associato, che imposta il tempo in cui i dati dell'utente in un volume devono rimanere inattivi per essere considerati "freddi" e spostati al livello di capacità. Il periodo di raffreddamento inizia quando i dati vengono scritti nell'aggregato.
|
È possibile modificare il periodo di raffreddamento minimo e la soglia aggregata predefinita del 50% (ulteriori informazioni su quelle riportate di seguito). "Scopri come modificare il periodo di raffreddamento" e. "scopri come modificare la soglia". |
BlueXP consente di scegliere tra le seguenti policy di tiering dei volumi quando si crea o si modifica un volume:
- Solo Snapshot
-
Dopo che un aggregato ha raggiunto la capacità del 50%, Cloud Volumes ONTAP esegue il Tier dei dati cold user delle copie Snapshot non associate al file system attivo al Tier di capacità. Il periodo di raffreddamento è di circa 2 giorni.
In lettura, i blocchi di dati cold sul Tier di capacità diventano hot e vengono spostati sul Tier di performance.
- Tutto
-
Tutti i dati (non inclusi i metadati) vengono immediatamente contrassegnati come cold e tiered per lo storage a oggetti il più presto possibile. Non è necessario attendere 48 ore affinché i nuovi blocchi di un volume si raffreddino. Tenere presente che i blocchi situati nel volume prima dell'impostazione del criterio All richiedono 48 ore per diventare freddi.
In caso di lettura, i blocchi di dati cold nel Tier cloud restano freddi e non vengono riscritti nel Tier di performance. Questo criterio è disponibile a partire da ONTAP 9.6.
- Automatico
-
Dopo che un aggregato ha raggiunto la capacità del 50%, Cloud Volumes ONTAP esegue il Tier dei blocchi di dati cold in un volume fino a raggiungere un livello di capacità. I dati cold non includono solo le copie Snapshot, ma anche i dati cold user dal file system attivo. Il periodo di raffreddamento è di circa 31 giorni.
Questo criterio è supportato a partire da Cloud Volumes ONTAP 9.4.
Se letti in modo casuale, i blocchi di dati cold nel Tier di capacità diventano hot e passano al Tier di performance. Se letti in base a letture sequenziali, come quelle associate a scansioni di indice e antivirus, i blocchi di dati cold rimangono freddi e non passano al livello di performance.
- Nessuno
-
Mantiene i dati di un volume nel Tier di performance, evitando che vengano spostati nel Tier di capacità.
Quando si replica un volume, è possibile scegliere se eseguire il Tier dei dati sullo storage a oggetti. In tal caso, BlueXP applica il criterio Backup al volume di protezione dei dati. A partire da Cloud Volumes ONTAP 9.6, la policy di tiering all sostituisce la policy di backup.
La disattivazione di Cloud Volumes ONTAP influisce sul periodo di raffreddamento
I blocchi di dati vengono raffreddati mediante scansioni di raffreddamento. Durante questo processo, i blocchi che non sono stati utilizzati hanno spostato la temperatura del blocco (raffreddato) al valore successivo più basso. Il tempo di raffreddamento predefinito dipende dalla policy di tiering del volume:
-
Auto: 31 giorni
-
Solo snapshot: 2 giorni
Affinché la scansione di raffreddamento funzioni, è necessario che Cloud Volumes ONTAP sia in esecuzione. Se Cloud Volumes ONTAP è disattivato, anche il raffreddamento si interrompe. Di conseguenza, è possibile ottenere tempi di raffreddamento più lunghi.
|
|
Quando Cloud Volumes ONTAP è disattivato, la temperatura di ciascun blocco viene mantenuta fino al riavvio del sistema. Ad esempio, se la temperatura di un blocco è 5 quando si spegne il sistema, la temperatura rimane 5 quando si riaccende il sistema. |
Impostazione del tiering dei dati
Per istruzioni e un elenco delle configurazioni supportate, fare riferimento a "Tiering dei dati inattivi su storage a oggetti a basso costo".