Cloud Tiering affronta le sfide che derivano dalla rapida crescita dei dati, offrendoti vantaggi quali:

In sostanza, tutti i dati considerati inattivi sui sistemi di archiviazione primari e secondari rappresentano un buon obiettivo da spostare nel cloud. Nei sistemi primari, tali dati possono includere snapshot, registrazioni storiche e progetti completati. Nei sistemi secondari, ciò include tutti i volumi che contengono copie di dati primari realizzate per scopi di ripristino di emergenza e backup.

Sì, è possibile suddividere i dati dai volumi NAS al cloud pubblico o ai cloud privati, come StorageGRID. Quando si suddividono in livelli i 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 ai NAS.

La definizione di ciò che può essere definito anche cold data è: "blocchi di volume (metadati esclusi) a cui non si è avuto accesso per un certo periodo di tempo". La “quantità di tempo” è determinata da un attributo della politica di suddivisione in livelli denominato cooling-days.

Sì, le efficienze di archiviazione a livello di volume ONTAP , come compressione, deduplicazione e compattazione, vengono preservate quando si spostano i dati al livello cloud.

FabricPool è la tecnologia di tiering ONTAP che può essere autogestita tramite ONTAP CLI e System Manager oppure gestita come servizio tramite Cloud Tiering. Cloud Tiering trasforma FabricPool in un servizio gestito con processi di automazione avanzati, sia su ONTAP che nel cloud, offrendo maggiore visibilità e controllo sul tiering nelle distribuzioni ibride e multi-cloud.

No. Poiché i metadati del volume non vengono mai suddivisi in livelli a partire dal livello delle prestazioni, non è possibile accedere direttamente ai dati archiviati nell'archiviazione degli oggetti.

Tuttavia, Cloud Tiering può essere utilizzato per ottenere backup e DR convenienti abilitandolo su sistemi secondari e volumi di destinazione SnapMirror (volumi DP), per suddividere in livelli tutti i dati (metadati esclusi), riducendo così l'ingombro del data center e il TCO.

Il Cloud Tiering viene abilitato a livello di volume associando una policy di tiering a ciascun volume. L'identificazione dei dati a freddo avviene a livello di blocco.

La politica di suddivisione in livelli associata al volume è il meccanismo che controlla quali blocchi vengono suddivisi in livelli e quando. La policy definisce il tipo di blocchi di dati (snapshot, dati utente o entrambi) e il periodo di raffreddamento. Vedere"Criteri di suddivisione in livelli del volume" per i dettagli.

Il Cloud Tiering non ha alcun effetto sulla capacità del volume, bensì sull'utilizzo del livello di prestazioni dell'aggregato.

Sì, Cloud Tiering abilita la segnalazione dei dati inattivi (IDR) su ogni aggregato. Questa impostazione ci consente di identificare la quantità di dati inattivi che possono essere suddivisi in livelli di archiviazione di oggetti a basso costo.

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 trasferiscono i dati inattivi al cloud pubblico:

"Vedi i dettagli dei prezzi" .

Il trasferimento di dati inattivi a un sistema NetApp StorageGRID (cloud privato) non comporta alcun costo.

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

Se si raggiunge il limite di capacità BYOL o se la licenza BYOL scade, la suddivisione in livelli dei nuovi dati inattivi si interrompe. Tutti i dati precedentemente suddivisi in livelli rimangono accessibili, il che significa che è possibile recuperarli e utilizzarli. Una volta recuperati, questi dati vengono spostati nuovamente dal cloud al livello di prestazioni.

Tuttavia, se si dispone di un abbonamento al marketplace PAYGO per BlueXP - Deploy & Manage Cloud Data Services, i nuovi dati inattivi continueranno a essere suddivisi in livelli nell'archiviazione degli oggetti e si pagheranno tali costi in base all'utilizzo.

No, non lo è.

Sì. Tutte le letture dal cloud pubblico sono soggette a tariffe di uscita.

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

Sì. Controllo "Prezzi di Amazon S3" , "Prezzi dei blocchi Blob" , E "Prezzi dell'archiviazione cloud" per i costi aggiuntivi sostenuti per la lettura/recupero dei dati.

Per ottenere una stima, aggiungi il tuo cluster ONTAP alla console NetApp e ispezionalo tramite la pagina Cloud Tiering Clusters. Selezionare Calcola potenziali risparmi di tiering per il cluster per avviare il "Calcolatore TCO del cloud tiering" per vedere quanti soldi puoi risparmiare.

Se utilizzata in ambienti MetroCluster , la licenza a livelli totali viene applicata all'utilizzo di entrambi i cluster. Ad esempio, se si dispone di una licenza per 100 TiB di tiering, la capacità di tiering utilizzata da ciascun cluster contribuisce alla capacità totale di 100 TiB.

Cloud Tiering supporta ONTAP versione 9.2 e successive.

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

Sì, a partire da ONTAP 9.8 è possibile suddividere in livelli i dati provenienti da volumi ospitati su aggregati HDD.

Sì. Cloud Tiering può essere configurato per suddividere in livelli i volumi ospitati su qualsiasi aggregato. La configurazione del tiering dei dati è irrilevante rispetto al tipo di controller utilizzato e al fatto che il cluster sia eterogeneo o meno.

Se disponi di sistemi Cloud Volumes ONTAP , li troverai nella pagina Cloud Tiering Clusters, così avrai una visione completa della suddivisione in livelli dei dati nella tua infrastruttura cloud ibrida. Tuttavia, i sistemi Cloud Volumes ONTAP sono di sola lettura da Cloud Tiering. Non è possibile impostare il tiering dei dati su Cloud Volumes ONTAP da Cloud Tiering. "È possibile impostare il tiering per i sistemi Cloud Volumes ONTAP dal sistema ONTAP nella console NetApp" .

Dipende da dove si suddividono i dati inattivi. Per maggiori dettagli fare riferimento ai seguenti link:

Cloud Tiering supporta i seguenti provider di archiviazione di oggetti:

Sì, puoi. Quando si imposta la suddivisione in livelli dei dati, è possibile scegliere se aggiungere un nuovo bucket/contenitore o selezionarne uno esistente.

Cloud Tiering supporta la suddivisione in livelli dei dati nelle classi di archiviazione Standard, Standard-Infrequent Access, One Zone-Infrequent Access, Intelligent Tiering e Glacier Instant Retrieval. Vedere"Classi di archiviazione S3 supportate" per maggiori dettagli.

Il motivo principale per cui Amazon S3 Glacier Flexible e S3 Glacier Deep Archive non sono supportati è che Cloud Tiering è progettato come una soluzione di tiering ad alte prestazioni, pertanto i dati devono essere costantemente 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 dell'archiviazione di oggetti compatibile con S3 tramite l'interfaccia utente di Tiering è supportata per i cluster che utilizzano ONTAP 9.8 e versioni successive. "Vedi i dettagli qui" .

Cloud Tiering supporta il data tiering nei livelli di accesso Hot o Cool per i dati inattivi. Vedere"Livelli di accesso supportati ad Azure Blob" per maggiori dettagli.

Cloud Tiering supporta la suddivisione in livelli dei dati nelle classi di archiviazione Standard, Nearline, Coldline e Archive. Vedere"Classi di archiviazione Google Cloud supportate" per maggiori dettagli.

Sì. È possibile abilitare la gestione del ciclo di vita in modo che Cloud Tiering trasferisca i dati dalla classe di archiviazione/livello di accesso predefinito a un livello più conveniente dopo un certo numero di giorni. La regola del ciclo di vita viene applicata a tutti gli oggetti nel bucket selezionato per Amazon S3 e Google Cloud Storage e a tutti i contenitori nell'account di archiviazione selezionato per Azure Blob.

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

È possibile collegare fino a due bucket per aggregato ai fini del mirroring, in cui i dati inattivi vengono suddivisi in livelli sincronizzati in entrambi i bucket. I bucket possono provenire da diversi fornitori e da diverse località. A partire da agosto 2022, sarà possibile utilizzare la pagina Configurazione avanzata per collegare due archivi di oggetti a un singolo aggregato.

Sì. La migliore pratica generale è quella di collegare un singolo bucket a più aggregati. Tuttavia, quando si utilizza il cloud pubblico, esiste una limitazione massima di IOPS per i servizi di archiviazione di oggetti, pertanto è necessario prendere in considerazione più bucket.

Quando si migra un volume da un cluster a un altro, tutti i dati inattivi vengono letti dal livello cloud. La posizione di scrittura sul cluster di destinazione dipende dall'abilitazione della suddivisione in livelli e dal tipo di criterio di suddivisione in livelli utilizzato sui volumi di origine e di destinazione.

Se l'aggregato di destinazione non ha un livello cloud associato, i dati vengono letti dal livello cloud dell'aggregato di origine e scritti interamente nel livello locale dell'aggregato di destinazione. Se l'aggregato di destinazione ha un livello cloud collegato, i dati vengono letti dal livello cloud dell'aggregato di origine e prima scritti nel livello locale dell'aggregato di destinazione, per facilitare un passaggio rapido. Successivamente, in base alla politica di suddivisione in livelli utilizzata, viene scritto nel livello cloud.

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

La riscrittura viene generalmente eseguita sulle letture e dipende dal tipo di policy di suddivisione in livelli. Prima di ONTAP 9.8, la riscrittura dell'intero volume poteva essere effettuata con un'operazione di spostamento del volume. A partire da ONTAP 9.8, l'interfaccia utente di Tiering offre le opzioni per Ripristinare tutti i dati o Ripristinare il file system attivo. "Scopri come riportare i dati al livello di prestazioni" .

No. Durante la procedura di "scambio di teste", l'unica cosa che cambia è la proprietà dell'aggregato. In questo caso, verrà modificato il controller senza alcun trasferimento di dati.

No. Gli oggetti creati e distribuiti sul cloud non contengono un singolo file, ma fino a 1.024 blocchi da 4 KB provenienti da più file. I metadati di un volume rimangono sempre nel livello locale.

L'agente Console è un software in esecuzione su un'istanza di elaborazione all'interno del tuo account cloud o in locale, che consente alla console NetApp di gestire in modo sicuro le risorse cloud. Per utilizzare il servizio Cloud Tiering, è necessario distribuire un agente.

Sì. Il software dell'agente può essere scaricato e installato manualmente su un host Linux nella tua rete. "Scopri come installare l'agente nei tuoi locali" .

Sì. È necessario disporre di un account prima di poter definire l'archiviazione degli oggetti che si desidera utilizzare. È inoltre necessario un account presso un provider di archiviazione cloud quando si configura l'agente nel cloud su una VPC o una VNet.

In caso di guasto di un agente, viene compromessa solo la visibilità negli ambienti a livelli. Tutti i dati sono accessibili e i dati freddi appena identificati vengono automaticamente suddivisi in livelli nell'archiviazione degli oggetti.

Esistono quattro politiche di suddivisione in livelli:

"Scopri di più sulle politiche di suddivisione in livelli" .

Poiché la suddivisione in livelli dei dati viene eseguita a livello di blocco, un blocco di dati viene considerato freddo dopo che non è stato utilizzato per un certo periodo di tempo, definito dall'attributo minimum-cooling-days della policy di suddivisione in livelli. L'intervallo applicabile è di 2-63 giorni con ONTAP 9.7 e versioni precedenti, oppure di 2-183 giorni a partire da ONTAP 9.8.

Il periodo di raffreddamento predefinito per la policy Cold Snapshot è di 2 giorni, mentre il periodo di raffreddamento predefinito per Cold User Data e Snapshot è di 31 giorni. Il parametro cooling-days non è applicabile alla politica All Tiering.

Durante il backup completo vengono letti tutti i dati freddi. Il recupero dei dati dipende dalla politica di suddivisione in livelli utilizzata. Quando si utilizzano i criteri Tutti i dati utente e snapshot non utilizzati, i dati non utilizzati non vengono riscritti nel livello di prestazioni. Quando si utilizza il criterio Cold Snapshots, solo nel caso in cui per il backup venga utilizzato un vecchio snapshot, verranno recuperati i relativi blocchi cold.

No. Tuttavia, puoi scegliere quali volumi sono idonei per la suddivisione in livelli, il tipo di dati da suddividere in livelli e il relativo periodo di raffreddamento. Ciò avviene associando una politica di suddivisione in livelli a quel volume.

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

Quando si reimposta una policy di tiering non avviene alcuna reidratazione, ma ciò impedirà che nuovi blocchi freddi vengano spostati nel livello cloud.

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

Non associare una policy di suddivisione in livelli al volume contenente tali dati.

I metadati di un volume vengono sempre archiviati localmente, sul livello delle prestazioni, e non vengono mai trasferiti sul cloud.

Per maggiori dettagli, vedere:

Oltre al Cloud Tiering, "Active IQ Unified Manager" E "consulente digitale" può essere utilizzato per il monitoraggio e la rendicontazione.

In caso di guasto della rete, il livello di prestazioni locale rimane online e i dati attivi restano accessibili. Tuttavia, i blocchi che sono già stati spostati nel livello cloud saranno inaccessibili e le applicazioni riceveranno un messaggio di errore quando proveranno ad accedere a tali dati. Una volta ripristinata la connettività, tutti i dati saranno accessibili senza problemi.

La latenza di lettura della tecnologia di tiering FabricPool sottostante dipende dalla connettività al livello cloud. Sebbene il tiering funzioni su qualsiasi larghezza di banda, si consiglia di posizionare i LIF intercluster su porte da 10 Gbps per garantire prestazioni adeguate. Non ci sono raccomandazioni o limitazioni di larghezza di banda per l'agente.

Inoltre, è possibile limitare la quantità di larghezza di banda di rete utilizzata durante il trasferimento di dati inattivi dal volume all'archiviazione degli oggetti. L'impostazione Velocità di trasferimento massima è disponibile durante la configurazione del cluster per la suddivisione in livelli e, successivamente, dalla pagina Clusters.

Sì. I livelli cloud non possono garantire la stessa latenza del livello locale, poiché la latenza dipende dalla connettività. Per stimare la latenza e la produttività di un archivio oggetti, Cloud Tiering fornisce un Cloud Performance Test (basato sul profiler dell'archivio oggetti ONTAP ) che può essere utilizzato dopo aver collegato l'archivio oggetti e prima di impostare il tiering.

La crittografia AES-256-GCM viene mantenuta sia sui livelli performance che cloud. La crittografia TLS 1.2 viene utilizzata per crittografare i dati in transito durante lo spostamento tra i livelli e per crittografare la comunicazione tra l'agente e sia il cluster ONTAP che l'archivio oggetti.

Sì. Un LIF intercluster deve essere configurato su una porta Ethernet, su ciascun nodo all'interno di una coppia HA che ospita volumi con dati che si intende trasferire nel cloud. Per ulteriori informazioni, consultare la sezione Requisiti del provider cloud presso cui si intende suddividere i dati.