FabricPool policy di tiering dei volumi
Suggerisci modifiche
PDF
FabricPool le policy di tiering dei volumi determinano quali dati in un volume sono idonei al tiering e il parametro dei giorni minimi di raffreddamento per il tiering determina quando i dati sono considerati inattivi e idonei al tiering.
|
Gli elenchi di controllo degli accessi (ACL), le strutture delle directory e i metadati non vengono mai suddivisi in livelli e rimangono sempre sul livello locale. |
Una scansione giornaliera in background cerca blocchi freddi. Quando viene raccolto un numero sufficiente di blocchi da 4 KB dallo stesso volume, questi vengono concatenati in un oggetto da 4 MB e spostati nel livello cloud in base alla policy di tiering del volume.
Comprendere come funzionano le politiche di tiering ti aiuterà a scegliere la politica più adatta alle tue esigenze di gestione dello storage.
Opzioni della policy di tiering del volume
Per impostazione predefinita, i volumi utilizzano la policy di tiering dei volumi None. Fanno eccezione i volumi FlexVol appena creati sugli aggregati FabricPool, che utilizzano la policy di tiering dei volumi Snapshot-Only.
Puoi utilizzare volume object-store tiering show il comando per visualizzare lo stato del tiering di un volume FabricPool. Ulteriori informazioni su volume object-store tiering show nella "Riferimento al comando ONTAP".
Il criterio di tiering FabricPool viene specificato a livello di volume. Sono disponibili quattro opzioni:
Solo snapshot
La `snapshot-only`policy di tiering sposta su un altro tier i dati snapshot che non sono più associati al file system attivo. Per impostazione predefinita, sono necessari due giorni di inattività prima che uno snapshot sia idoneo per il tiering. La maggior parte delle pianificazioni di protezione dei dati è oraria o giornaliera e legge i dati localmente prima che vengano spostati su un altro tier.
Puoi modificare l'impostazione predefinita per il periodo minimo di raffreddamento del tiering con il parametro -tiering-minimum-cooling-days nel livello di privilegio avanzato dei comandi volume create e volume modify. I valori validi sono da 2 a 183 giorni usando ONTAP 9.8 e versioni successive. Se usi una versione di ONTAP precedente alla 9.8, i valori validi sono da 2 a 63 giorni.
Quando vengono letti, i blocchi cold associati alle copie snapshot rimangono cold e non vengono riscritti nel livello locale.
Auto
La `auto`policy di tiering sposta tutti i dati cold nel volume, sia gli snapshot che il file system attivo, nel cloud tier. Il periodo minimo di raffreddamento predefinito per il tiering è di 31 giorni e si applica all'intero volume, sia per il file system attivo che per gli snapshot.
È possibile modificare l'impostazione predefinita per il periodo di raffreddamento minimo di tiering con -tiering-minimum-cooling-days nel livello di privilegio avanzato di volume create e. volume modify comandi. I valori validi vanno da 2 a 183 giorni.
Quando leggi in modo casuale i blocchi freddi in un volume con una policy di tiering impostata su Auto, questi diventano caldi e vengono scritti di nuovo nel tier locale.
Quando letti in sequenza, i blocchi cold in un volume con una tiering policy impostata su Auto restano cold e rimangono sul cloud tier. Non vengono scritti di nuovo sul local tier.
Tutto
La all policy di tiering contrassegna immediatamente tutti i dati nel volume come freddi e inizia a spostarli nel cloud tier il prima possibile. Non devi aspettare 48 ore perché i nuovi blocchi in un volume che usa la all policy di tiering diventino freddi.
Il periodo di raffreddamento minimo del tiering non si applica perché i dati si spostano al livello cloud non appena viene eseguita la scansione del tiering e non è possibile modificare l'impostazione.
Quando i blocchi cold in un volume con una policy di tiering impostata su All vengono letti, rimangono cold e restano sul cloud tier. Non vengono scritti di nuovo sul local tier.
|
|
Il L'object storage non è transazionale come lo storage file o a blocchi. Apportare modifiche ai file archiviati come oggetti nei volumi utilizzando la policy di tiering "All" può comportare la creazione di nuovi oggetti, la frammentazione di oggetti esistenti, una riduzione delle prestazioni di lettura e l'aggiunta di inefficienze di storage. |
Nessuno
La `none`politica di tiering mantiene i dati di un volume nel livello di prestazioni e non esegue il tiering dei dati.
Impostazione del criterio di tiering su none impedisce il nuovo tiering. I dati del volume precedentemente spostati nel Tier cloud rimangono nel Tier cloud fino a quando non diventano hot e vengono automaticamente spostati di nuovo nel Tier locale.
Il periodo di raffreddamento minimo del tiering non si applica perché i dati non si spostano mai al livello cloud e non è possibile modificare l'impostazione.
Quando si blocca a freddo in un volume con una policy di tiering impostata su none vengono letti, vengono resi a caldo e scritti nel tier locale.
Il volume show l'output del comando mostra la policy di tiering di un volume. Un volume che non è mai stato utilizzato con FabricPool mostra none policy di tiering nell'output.
|
|
Se in una relazione di disaster recovery di SVM, i volumi di origine e destinazione non devono utilizzare gli aggregati FabricPool, ma devono utilizzare la stessa policy di tiering. |
Cosa succede quando modifichi una policy di tiering dei volumi
È possibile modificare la policy di tiering di un volume eseguendo una volume modify operazione. Devi comprendere come la modifica della policy di tiering possa influire sul tempo necessario per far diventare i dati più freddi e spostarli nel Tier cloud.
-
Modifica della policy di tiering da
snapshot-onlyoppurenonea.autoFa sì che ONTAP invii blocchi di dati utente nel file system attivo che sono già cold al livello cloud, anche se tali blocchi di dati utente non erano precedentemente idonei per il livello cloud. -
Modificando la policy di tiering in
allda un'altra policy, ONTAP sposta il prima possibile nel cloud tutti i blocchi degli utenti nel file system attivo e negli snapshot. Prima di ONTAP 9,8, i blocchi necessitavano di attendere l'esecuzione della scansione di tiering successiva.Non è consentito spostare nuovamente i blocchi nel Tier di performance.
-
Modifica della policy di tiering da
autoa.snapshot-onlyoppurenonenon fa sì che i blocchi di file system attivi già spostati nel tier cloud vengano spostati di nuovo nel tier di performance.Le letture dei volumi sono necessarie per riportare i dati al Tier di performance.
-
Ogni volta che si modifica il criterio di tiering su un volume, il periodo minimo di raffreddamento del tiering viene ripristinato al valore predefinito per il criterio.
Cosa accade alla policy di tiering quando si sposta un volume
-
A meno che non si specifichi esplicitamente un criterio di tiering diverso, un volume conserva la propria policy di tiering originale quando viene spostato all'interno e all'esterno di un aggregato abilitato a FabricPool.
Tuttavia, la policy di tiering ha effetto solo quando il volume si trova in un aggregato abilitato a FabricPool.
-
Il valore esistente di
-tiering-minimum-cooling-daysparametro per lo spostamento di un volume con il volume a meno che non si specifichi un criterio di tiering diverso per la destinazione.Se si specifica un criterio di tiering diverso, il volume utilizza il periodo di raffreddamento minimo di tiering predefinito per tale criterio. Questo è il caso se la destinazione è FabricPool o meno.
-
È possibile spostare un volume tra gli aggregati e contemporaneamente modificare la policy di tiering.
-
Prestare particolare attenzione quando un
volume movel'operazione comprendeautopolicy di tiering.Supponendo che sia l'origine che la destinazione siano aggregati abilitati per FabricPool, la seguente tabella riassume il risultato di a.
volume moveoperazione che comporta modifiche dei criteri correlate a.auto:Quando si sposta un volume con una policy di tiering di…
Inoltre, è possibile modificare la policy di tiering passando a…
Quindi, dopo lo spostamento del volume…
allautoTutti i dati vengono spostati nel Tier di performance.
snapshot-only,none, o.autoautoI blocchi di dati vengono spostati nello stesso livello della destinazione in cui si trovavano in precedenza nell'origine.
autooppureallsnapshot-onlyTutti i dati vengono spostati nel Tier di performance.
autoallTutti i dati degli utenti vengono spostati nel livello cloud.
snapshot-only,autooppureallnoneTutti i dati vengono conservati al livello di performance.
Cosa accade alla policy di tiering quando si clonano volumi
-
A partire da ONTAP 9.8, un volume clone eredita sempre sia la policy di tiering che la policy di recupero del cloud dal volume padre.
Nelle release precedenti a ONTAP 9.8, un clone eredita la policy di tiering dall'origine, tranne quando l'origine dispone di
allpolicy di tiering. -
Se il volume padre dispone di
nevercloud retrieval policy, il suo volume clone deve disporre dineverpolicy di recupero del cloud o diallpolicy di tiering e policy di recupero del cloud corrispondentidefault. -
Impossibile modificare la policy di recupero cloud del volume padre in
nevera meno che tutti i volumi cloni non dispongano di una policy di recupero cloudnever.
Quando si clonano i volumi, tenere presenti le seguenti Best practice:
-
Il
-tiering-policyopzione e.tiering-minimum-cooling-daysl'opzione del clone controlla solo il comportamento di tiering dei blocchi unici per il clone. Pertanto, si consiglia di utilizzare le impostazioni di tiering sul FlexVol padre che spostano la stessa quantità di dati o spostano una quantità inferiore di dati rispetto a uno qualsiasi dei cloni -
La policy di recupero del cloud sul FlexVol padre deve spostare la stessa quantità di dati o spostare più dati rispetto alla policy di recupero di uno qualsiasi dei cloni
Come funzionano le policy di tiering con la migrazione del cloud
Il recupero dei dati nel cloud di FabricPool è controllato da policy di tiering che determinano il recupero dei dati dal Tier cloud al Tier di performance in base al modello di lettura. I modelli di lettura possono essere sequenziali o casuali.
La tabella seguente elenca le policy di tiering e le regole di recupero dei dati cloud per ogni policy.
Policy di tiering |
Comportamento di recupero |
nessuno |
Letture sequenziali e casuali |
solo snapshot |
Letture sequenziali e casuali |
automatico |
Letture casuali |
tutto |
Nessun recupero dei dati |
A partire da ONTAP 9.8, il controllo della migrazione nel cloud cloud-retrieval-policy l'opzione sovrascrive il comportamento predefinito di migrazione o recupero del cloud controllato dalla policy di tiering.
La seguente tabella elenca le policy di recupero cloud supportate e il loro comportamento di recupero.
Policy di recupero del cloud |
Comportamento di recupero |
predefinito |
La policy di tiering decide quali dati devono essere ritirati, quindi non vi è alcuna modifica al recupero dei dati nel cloud con “default,” |
a lettura |
Tutti i dati letti dal client vengono estratti dal Tier cloud al Tier di performance. |
mai |
Nessun dato client-driven viene estratto dal Tier cloud al Tier di performance |
promuovi |
|
Per ulteriori informazioni sui comandi descritti in questa procedura, consultare la "Riferimento al comando ONTAP".