BlueXP Tiering affronta le sfide legate alla rapida crescita dei dati, offrendo vantaggi come:

In sostanza, tutti i dati considerati inattivi sui sistemi di storage primario e secondario sono un buon obiettivo per il passaggio al cloud. Nei sistemi primari, tali dati possono includere snapshot, record storici e progetti finiti. Nei sistemi secondari, sono inclusi tutti i volumi che contengono copie dei dati primari effettuate per scopi di DR e backup.

Sì, puoi eseguire il tiering dei dati dai volumi NAS al cloud pubblico o ai cloud privati, come StorageGRID. Quando si esegue il tiering dei dati a cui si accede tramite protocolli SAN, NetApp consiglia di utilizzare cloud privati perché i protocolli SAN sono più sensibili ai problemi di connettività rispetto a NAS.

La definizione di ciò che si può anche fare riferimento ai dati cold è: "Blocchi di volume (metadati esclusi) a cui non è stato effettuato l'accesso per un certo periodo di tempo". La "quantità di tempo" è determinata da un attributo di policy di tiering denominato Cooling-days.

Sì, le efficienze dello storage a livello di volume di ONTAP, come compressione, deduplica e compattazione, vengono preservate quando si spostano i dati nel Tier cloud.

FabricPool è la tecnologia di tiering ONTAP che può essere gestita in autonomia tramite l'interfaccia CLI e il gestore di sistema di ONTAP oppure gestita come servizio tramite il tiering BlueXP. BlueXP Tiering trasforma FabricPool in un servizio gestito con processi di automazione avanzati, sia su ONTAP che nel cloud, fornendo maggiore visibilità e controllo sul tiering nelle implementazioni ibride e multi-cloud.

No Poiché i metadati del volume non vengono mai suddivisi in Tier dal Tier di performance, non è possibile accedere direttamente ai dati memorizzati nello storage a oggetti.

Tuttavia, il tiering BlueXP può essere utilizzato per ottenere backup e DR convenienti abilitando l'IT sui sistemi secondari e sui volumi di destinazione SnapMirror (volumi DP), per eseguire il tiering di tutti i dati (esclusi i metadati), riducendo così l'impatto del data center e il TCO.

Il tiering BlueXP viene attivato a livello di volume associando un criterio di tiering a ciascun volume. L'identificazione dei dati cold viene eseguita a livello di blocco.

La policy di tiering associata al volume è il meccanismo che controlla quali blocchi sono a livelli e quando. Il criterio definisce il tipo di blocchi di dati (snapshot, dati utente o entrambi) e il periodo di raffreddamento. Vedere "Policy di tiering dei volumi" per ulteriori informazioni.

Il tiering BlueXP non ha alcun effetto sulla capacità del volume, ma piuttosto sull'utilizzo del Tier di performance dell'aggregato.

Sì, il tiering BlueXP attiva la funzione IDR (Inactive Data Reporting) su ciascun aggregato. Questa impostazione consente di identificare la quantità di dati inattivi che possono essere suddivisi in livelli per lo storage a oggetti a basso costo.

L'IDR inizia a mostrare le informazioni una volta trascorso il periodo di raffreddamento configurato. Utilizzando ONTAP 9.7 e versioni precedenti, IDR aveva un periodo di raffreddamento non regolabile di 31 giorni. A partire da ONTAP 9.8, il periodo di raffreddamento IDR può essere configurato fino a 183 giorni.

Quando si esegue il tiering dei dati cold nel cloud pubblico:

"Consulta i dettagli sui prezzi".

Quando si esegue il tiering dei dati cold su un sistema NetApp StorageGRID (cloud privato), non è previsto alcun costo.

Sì. BlueXP Tiering consente di utilizzare una licenza BYOL, UN abbonamento PAYGO o una combinazione di entrambi.

Se si raggiunge il limite di capacità BYOL, il tiering dei nuovi dati cold si interrompe. Tutti i dati su più livelli in precedenza rimangono accessibili, il che significa che è possibile recuperare e utilizzare questi dati. Una volta recuperati, questi dati vengono spostati di nuovo nel Tier di performance dal cloud.

Tuttavia, se disponi di un abbonamento al marketplace PAYGO per BlueXP - Deploy & Manage Cloud Data Services, i nuovi dati cold continueranno a essere suddivisi in livelli per lo storage a oggetti e pagherai per ciascun utilizzo.

No, non lo fa.

Sì. Tutte le letture del cloud pubblico sono soggette a costi di uscita.

Il modo migliore per stimare quanto un cloud provider addebiterà per l'hosting dei tuoi dati è utilizzare i calcolatori: "AWS", "Azure" e. "Google Cloud".

Sì. Controllare "Prezzi Amazon S3", "Prezzo a blocchi", e. "Prezzi del cloud storage" per ulteriori prezzi sostenuti per la lettura/recupero dei dati.

Per ottenere una stima, è sufficiente aggiungere il cluster ONTAP a BlueXP e ispezionarlo attraverso la pagina dei cluster di tiering BlueXP. Fare clic su Calculate potenziali risparmi di tiering per avviare il cluster "Calcolatore del TCO di BlueXP Tiering" per vedere quanto denaro puoi risparmiare.

BlueXP Tiering supporta ONTAP versione 9.2 e successive.

BlueXP Tiering è supportato con cluster AFF, FAS e ONTAP Select a nodo singolo e ad alta disponibilità. Sono supportati anche i cluster nelle configurazioni mirror FabricPool e nelle configurazioni MetroCluster.

Sì, a partire da ONTAP 9.8 è possibile eseguire il tiering dei dati dai volumi ospitati su aggregati di dischi rigidi.

Sì. BlueXP Tiering può essere configurato per tiering volumi ospitati su qualsiasi aggregato. La configurazione del tiering dei dati è irrilevante per il tipo di controller utilizzato e se il cluster è eterogeneo o meno.

Se disponi di sistemi Cloud Volumes ONTAP, troverai i sistemi nella pagina dei cluster di tiering BlueXP, in modo da ottenere una vista completa del tiering dei dati nella tua infrastruttura di cloud ibrido. Tuttavia, i sistemi Cloud Volumes ONTAP sono di sola lettura dal tiering BlueXP. Non è possibile impostare il tiering dei dati su Cloud Volumes ONTAP dal tiering BlueXP. "È possibile impostare il tiering per i sistemi Cloud Volumes ONTAP dall'ambiente di lavoro in BlueXP".

Dipende dalla posizione in cui si suddividere i dati cold. Per ulteriori informazioni, fare riferimento ai seguenti collegamenti:

BlueXP Tiering supporta i seguenti provider di storage a oggetti:

Sì, è possibile. Quando si imposta il tiering dei dati, è possibile aggiungere un nuovo bucket/container o selezionare un bucket/container esistente.

BlueXP Tiering supporta il tiering dei dati per le classi di storage Standard, Standard-infrequent Access, One zone-infrequent Access, Intelligent Tiering e Glacier Instant Retrieval. Vedere "Classi di storage S3 supportate" per ulteriori dettagli.

Il motivo principale per cui Amazon S3 Glacier Flexible e S3 Glacier Deep Archive non sono supportati è che il tiering BlueXP è progettato come una soluzione di tiering dalle performance elevate, pertanto i dati devono essere continuamente disponibili e rapidamente accessibili per il recupero. Con S3 Glacier Flexible e S3 Glacier Deep Archive, il recupero dei dati può durare da pochi minuti a 48 ore.

Sì, la configurazione dello storage a oggetti compatibile con S3 tramite l'interfaccia utente di tiering è supportata per i cluster che utilizzano ONTAP 9.8 e versioni successive. "Consulta i dettagli qui".

BlueXP Tiering supporta il tiering dei dati ai livelli di accesso hot o Cool per i dati inattivi. Vedere "Livelli di accesso supportati da Azure Blob" per ulteriori dettagli.

BlueXP Tiering supporta il tiering dei dati per le classi di storage Standard, Nearline, Coldline e Archive. Vedere "Classi di storage Google Cloud supportate" per ulteriori dettagli.

Sì. Puoi abilitare il Lifecycle management in modo che il tiering di BlueXP sposti i dati dalla classe di storage/Tier di accesso predefinito a un Tier più conveniente dopo un determinato numero di giorni. La regola del ciclo di vita viene applicata a tutti gli oggetti nel bucket selezionato per lo storage Amazon S3 e Google Cloud e a tutti i container nell'account di storage selezionato per BLOB di Azure.

In una configurazione tipica è presente un archivio di oggetti per l'intero cluster. A partire da agosto 2022, è possibile utilizzare la pagina Advanced Setup per aggiungere ulteriori archivi di oggetti per un cluster e quindi associare diversi archivi di oggetti a diversi aggregati oppure collegare 2 archivi di oggetti a un aggregato per il mirroring.

È possibile collegare fino a due bucket per aggregato allo scopo di eseguire il mirroring, in cui i dati cold vengono associati in maniera sincrona a entrambi i bucket. I bucket possono provenire da diversi provider e da diverse posizioni. A partire da agosto 2022, è possibile utilizzare la pagina Advanced Setup per allegare due archivi di oggetti a un singolo aggregato.

Sì. La Best practice generale consiste nel collegare un singolo bucket a più aggregati. Tuttavia, quando si utilizza il cloud pubblico esiste un limite massimo di IOPS per i servizi di storage a oggetti, pertanto è necessario prendere in considerazione più bucket.

Durante la migrazione di un volume da un cluster a un altro, tutti i dati cold vengono letti dal livello cloud. La posizione di scrittura sul cluster di destinazione dipende dall'attivazione del tiering e dal tipo di policy di tiering utilizzata sui volumi di origine e di destinazione.

Se l'aggregato di destinazione non dispone di un Tier cloud collegato, i dati vengono letti dal Tier cloud dell'aggregato di origine e scritti interamente nel Tier locale dell'aggregato di destinazione. Se l'aggregato di destinazione ha un Tier cloud collegato, i dati vengono letti dal Tier cloud dell'aggregato di origine e scritti per primi nel Tier locale dell'aggregato di destinazione, per facilitare un cutover rapido. In seguito, in base alla policy di tiering utilizzata, viene scritta nel Tier cloud.

A partire da ONTAP 9.6, se l'aggregato di destinazione utilizza lo stesso livello cloud dell'aggregato di origine, i dati cold non tornano al livello locale.

La riscrittura viene generalmente eseguita in lettura e dipende dal tipo di policy di tiering. Prima di ONTAP 9.8, la scrittura dell'intero volume può essere eseguita con un'operazione di spostamento del volume. A partire da ONTAP 9.8, l'interfaccia utente di tiering dispone di opzioni per riportare tutti i dati o riportare il file system attivo. "Scopri come riportare i dati al livello di performance".

No Durante la procedura di "head swap", l'unica cosa che cambia è la proprietà dell'aggregato. In questo caso, verrà modificato nel nuovo controller senza alcun spostamento dei dati.

No Gli oggetti costruiti e suddivisi in Tier nel cloud non contengono un singolo file, ma fino a 1,024 blocchi da 4 KB da più file. I metadati di un volume rimangono sempre nel Tier locale.

Il connettore è un software in esecuzione su un'istanza di calcolo all'interno del tuo account cloud o on-premise, che consente a BlueXP di gestire in modo sicuro le risorse cloud. Per utilizzare il servizio di tiering BlueXP, è necessario implementare un connettore.

Sì. Il software del connettore può essere scaricato e installato manualmente su un host Linux nella rete. "Scopri come installare il connettore nella tua sede".

Sì. È necessario disporre di un account prima di poter definire lo storage a oggetti che si desidera utilizzare. Per configurare il connettore nel cloud su un VPC o VNET, è necessario anche un account con un provider di cloud storage.

In caso di guasto di un connettore, viene influenzata solo la visibilità negli ambienti a più livelli. Tutti i dati sono accessibili e i dati cold identificati di recente vengono automaticamente suddivisi in livelli per lo storage a oggetti.

Esistono quattro policy di tiering:

"Scopri di più sulle policy di tiering".

Poiché il tiering dei dati viene eseguito a livello di blocco, un blocco di dati viene considerato freddo dopo che non è stato effettuato l'accesso per un determinato periodo di tempo, definito dall'attributo Minimum-cooling-days della policy di tiering. L'intervallo applicabile è di 2-63 giorni con ONTAP 9.7 e versioni precedenti o di 2-183 giorni a partire da ONTAP 9.8.

Il periodo di raffreddamento predefinito per il criterio Cold Snapshot è di 2 giorni, mentre il periodo di raffreddamento predefinito per Cold User Data e Snapshot è di 31 giorni. Il parametro Cooling-days (giorni di raffreddamento) non è applicabile alla policy di tutti i livelli.

Durante il backup completo vengono letti tutti i dati cold. Il recupero dei dati dipende dalla policy di tiering utilizzata. Quando si utilizzano i criteri tutti e dati utente a freddo e Snapshot, i dati a freddo non vengono riscritti nel Tier di performance. Quando si utilizza il criterio Cold Snapshots, solo nel caso in cui venga utilizzato un vecchio snapshot per il backup verranno recuperati i blocchi a freddo.

No Tuttavia, è possibile scegliere quali volumi sono idonei per il tiering, il tipo di dati da tiering e il periodo di raffreddamento. A tale scopo, associare un criterio di tiering a tale volume.

No I volumi di protezione dei dati (DP) possono essere associati a una delle tre policy disponibili. Il tipo di policy utilizzata sui volumi di origine e destinazione (DP) determina la posizione di scrittura dei dati.

Non viene eseguita alcuna operazione di reidratazione quando si reimposta una policy di tiering, ma si impedisce che i nuovi blocchi freddi vengano spostati nel Tier cloud.

Sì. Il comportamento dopo la modifica dipende dalla nuova policy associata.

Non associare un criterio di tiering al volume contenente tali dati.

I metadati di un volume vengono sempre memorizzati localmente, sul Tier di performance — non viene mai tierato nel cloud.

Per ulteriori informazioni, consulta:

Oltre al tiering BlueXP, "Active IQ Unified Manager" e. "BlueXP Digital Advisor" può essere utilizzato per il monitoraggio e la creazione di report.

In caso di guasto alla rete, il Tier di performance locale rimane online e i dati hot rimangono accessibili. Tuttavia, i blocchi già spostati nel Tier cloud non saranno accessibili e le applicazioni riceveranno un messaggio di errore quando tentano di accedere a tali dati. Una volta ripristinata la connettività, tutti i dati saranno perfettamente accessibili.

La latenza di lettura della tecnologia di tiering FabricPool sottostante dipende dalla connettività al Tier cloud. Sebbene il tiering funzioni su qualsiasi larghezza di banda, si consiglia di posizionare le LIF di intercluster su porte a 10 Gbps per fornire performance adeguate. Non esistono raccomandazioni o limitazioni di larghezza di banda per il connettore.

Inoltre, è possibile ridurre la larghezza di banda della rete utilizzata durante il trasferimento di dati inattivi dal volume allo storage a oggetti. L'impostazione Maximum transfer rate è disponibile quando si configura il cluster per il tiering e successivamente dalla pagina Clusters.

Sì. I Tier cloud non possono fornire la stessa latenza del Tier locale poiché la latenza dipende dalla connettività. Per stimare la latenza e il throughput di un archivio di oggetti, il tiering BlueXP fornisce un test delle performance cloud (basato sul profiler dell'archivio di oggetti ONTAP) che può essere utilizzato dopo il collegamento dell'archivio di oggetti e prima della configurazione del tiering.

La crittografia AES-256-GCM viene mantenuta sia a livello di performance che di cloud. La crittografia TLS 1.2 viene utilizzata per crittografare i dati via cavo durante lo spostamento tra i Tier e per crittografare la comunicazione tra il connettore e il cluster ONTAP e l'archivio di oggetti.

Sì. È necessario configurare una LIF di intercluster su una porta ethernet, su ciascun nodo all'interno di una coppia ha che ospita volumi con dati che si intende raggruppare nel cloud. Per ulteriori informazioni, consulta la sezione requisiti per il cloud provider in cui intendi tierare i dati.