Le snapshot-only tiering-policy s'applique uniquement aux blocs qui ne sont pas partagés avec le système de fichiers actif. Elle entraîne essentiellement une hiérarchisation des sauvegardes de bases de données. Les blocs deviennent candidats au Tiering après la création d'une copie Snapshot et l'écrasement du bloc, ce qui entraîne l'affichage d'un bloc uniquement dans la copie Snapshot. Le délai avant un snapshot-only le bloc est considéré comme froid est contrôlé par le tiering-minimum-cooling-days réglage du volume. La plage à partir de ONTAP 9.8 est de 2 à 183 jours.

De nombreux jeux de données ont des taux de modification faibles, ce qui permet de réduire au minimum les économies réalisées grâce à cette règle. Par exemple, un taux de modification hebdomadaire d'une base de données type observée sur ONTAP est inférieur à 5 %. Les journaux d'archivage de base de données peuvent occuper un espace important, mais ils continuent généralement d'exister dans le système de fichiers actif et ne sont donc pas candidats à la hiérarchisation dans le cadre de cette règle.

Le auto la règle de tiering étend le tiering aux blocs spécifiques de snapshot et aux blocs dans le système de fichiers actif. Le délai avant qu'un bloc soit considéré comme froid est contrôlé par le tiering-minimum-cooling-days réglage du volume. La plage à partir de ONTAP 9.8 est de 2 à 183 jours.

Cette approche permet d'activer des options de hiérarchisation qui ne sont pas disponibles avec le snapshot-only politique. Par exemple, une règle de protection des données peut nécessiter la conservation de 90 jours de certains fichiers journaux. Si vous définissez une période de refroidissement de 3 jours, tous les fichiers journaux de plus de 3 jours doivent être placés hors de la couche de performances. Cela libère un espace considérable sur le Tier de performance tout en vous permettant de consulter et de gérer l'ensemble des 90 jours de données.

Le none la règle de tiering empêche tout bloc supplémentaire d'être hiérarchisé de la couche de stockage, mais toutes les données qui se trouvent toujours dans le tier de capacité restent dans le tier de capacité jusqu'à ce qu'elles soient lues. Si le bloc est ensuite lu, il est retiré et placé sur le Tier de performance.

La principale raison d'utiliser le none la règle de tiering consiste à empêcher les blocs d'être hiérarchisés, mais elle peut s'avérer utile pour modifier les règles au fil du temps. Par exemple, imaginons qu'un dataset spécifique soit beaucoup hiérarchisé vers la couche de capacité, mais qu'un besoin inattendu de fonctionnalités de performance complètes se produit. La règle peut être modifiée pour éviter tout Tiering supplémentaire et confirmer que tous les blocs lus en cas d'augmentation des E/S restent dans le Tier de performance.

Le all la règle de tiering remplace la backup Politique à partir de ONTAP 9.6. Le backup Règle appliquée uniquement aux volumes de protection des données, c'est-à-dire une destination SnapMirror ou NetApp SnapVault. Le all les règles fonctionnent de même, mais ne se limitent pas aux volumes de protection des données.

Avec cette règle, les blocs sont immédiatement considérés comme « cool » et peuvent être immédiatement hiérarchisés jusqu'à la couche de capacité.

Cette règle est particulièrement appropriée pour les sauvegardes à long terme. Il peut également être utilisé comme une forme de gestion hiérarchique du stockage (HSM). Auparavant, HSM était couramment utilisé pour classer les blocs de données d'un fichier sur bande tout en gardant le fichier lui-même visible sur le système de fichiers. Un volume FabricPool avec all cette stratégie vous permet de stocker des fichiers dans un espace visible et gérable, tout en ne consommant quasiment aucun espace sur le niveau de stockage local.