FabricPool volume politiques de hiérarchisation
Suggérer des modifications
PDF
FabricPool Les politiques de hiérarchisation des volumes déterminent quelles données d'un volume sont éligibles à la hiérarchisation, et le paramètre de nombre minimum de jours de refroidissement pour la hiérarchisation détermine quand les données sont considérées comme inactives et éligibles à la hiérarchisation.
|
Les listes de contrôle d'accès (ACL), les structures de répertoires et les métadonnées ne sont jamais hiérarchisées et restent toujours sur le niveau local. |
Une analyse quotidienne en arrière-plan recherche les blocs inactifs. Lorsque suffisamment de blocs de 4 Ko provenant du même volume ont été collectés, ils sont concaténés en un objet de 4 Mo et déplacés vers le niveau cloud conformément à la politique de hiérarchisation des volumes.
Comprendre le fonctionnement des politiques de hiérarchisation vous aidera à choisir la politique la mieux adaptée à vos besoins en matière de gestion du stockage.
Options de politique de hiérarchisation des volumes
Par défaut, les volumes utilisent la stratégie de hiérarchisation de volumes « Aucun ». L'exception concerne les volumes FlexVol nouvellement créés sur les agrégats FabricPool, qui utilisent la stratégie de hiérarchisation de volumes « Instantané uniquement ».
Vous pouvez utiliser volume object-store tiering show la commande pour afficher l'état de la hiérarchisation d'un volume FabricPool. Pour en savoir plus, volume object-store tiering show consultez le "Référence de commande ONTAP".
La règle de Tiering FabricPool est spécifiée au niveau du volume. Quatre options sont disponibles :
Instantané uniquement
La `snapshot-only`politique de hiérarchisation transfère vers un autre niveau les données d’instantané qui ne sont plus associées au système de fichier actif. Par défaut, il faut deux jours d’inactivité avant qu’un instantané soit éligible au transfert vers un autre niveau. La plupart des plannings de protection des données sont horaires ou quotidiens et lisent les données localement avant leur transfert vers un autre niveau.
Vous pouvez modifier la valeur par défaut de la période minimale de refroidissement pour la hiérarchisation avec le paramètre -tiering-minimum-cooling-days au niveau de privilège avancé des commandes volume create et volume modify. Les valeurs valides sont de 2 à 183 jours avec ONTAP 9.8 et versions ultérieures. Si vous utilisez une version d'ONTAP antérieure à 9.8, les valeurs valides sont de 2 à 63 jours.
Lors de la lecture, les blocs froids associés aux copies instantanées restent froids et ne sont pas réécrits sur le niveau local.
Automatique
La auto politique de hiérarchisation place toutes les données froides du volume — à la fois les instantanés et le système de fichier actif — dans le niveau cloud. La période de refroidissement minimale par défaut est de 31 jours et s'applique à l'ensemble du volume, pour le système de fichier actif comme pour les instantanés.
Vous pouvez modifier le paramètre par défaut de la période de refroidissement minimum par niveaux avec l' -tiering-minimum-cooling-days paramètre au niveau de privilège avancé de l' volume create et volume modify commandes. Les valeurs valides sont de 2 à 183 jours.
Lorsqu'ils sont lus de manière aléatoire, les blocs froids d'un volume dont la politique de hiérarchisation est définie sur Auto sont rendus chauds et réécrits dans le niveau local.
Lors d'une lecture séquentielle, les blocs froids d'un volume dont la stratégie de hiérarchisation est définie sur « Auto » restent froids et demeurent sur le niveau cloud. Ils ne sont pas réécrits sur le niveau local.
Tout
La all politique de hiérarchisation marque immédiatement toutes les données du volume comme inactives et commence à les transférer vers le niveau cloud dès que possible. Il n'est pas nécessaire d'attendre 48 heures pour que les nouveaux blocs d'un volume utilisant la all politique de hiérarchisation deviennent inactifs.
La période de refroidissement minimale du Tiering ne s'applique pas, car les données sont déplacées vers le Tier cloud dès l'exécution de l'analyse du Tiering. Vous ne pouvez pas modifier ce paramètre.
Lorsqu'un volume dont la politique de hiérarchisation est définie sur « Tous » contient des blocs froids lus, ces blocs restent froids et demeurent sur le niveau cloud. Ils ne sont pas réécrits sur le niveau local.
|
|
Le Le stockage objet n'est pas transactionnel comme le stockage fichier ou le stockage bloc. Modifier des fichiers stockés sous forme d'objets dans des volumes utilisant la stratégie de hiérarchisation « Tous » peut entraîner la création de nouveaux objets, la fragmentation des objets existants, une baisse des performances de lecture et une augmentation des inefficacités de stockage. |
Aucune
La `none`politique de hiérarchisation maintient les données d'un volume dans le niveau de performance et ne hiérarchise pas les données.
Définition de la règle de hiérarchisation sur none empêche le nouveau tiering. Les données de volume qui ont déjà été déplacées vers le Tier cloud restent dans le Tier cloud jusqu'à ce qu'elles deviennent actives, et sont automatiquement déplacées vers le Tier local.
Le Tiering n'applique pas la période de refroidissement minimale, car les données ne sont jamais déplacées vers le Tier cloud et vous ne pouvez pas modifier le paramètre.
En cas de blocs inactifs dans un volume dont la règle de Tiering est définie sur none ils sont lus, ils sont brûlants et écrits sur le niveau local.
Le volume show la sortie de la commande affiche la politique de tiering d'un volume. Un volume qui n'a encore jamais été utilisé avec FabricPool présente la none règle de hiérarchisation dans la sortie.
|
|
Dans une relation SVM DR, les volumes source et de destination n'ont pas besoin d'utiliser d'agrégats FabricPool, mais ils doivent utiliser la même règle de Tiering. |
Que se passe-t-il lorsque vous modifiez une politique de hiérarchisation des volumes
Vous pouvez modifier la règle de hiérarchisation d'un volume en effectuant une volume modify fonctionnement. Vous devez savoir en quoi la modification de la règle de Tiering peut affecter le temps nécessaire aux données inactives et déplacées vers le Tier cloud.
-
Modification de la règle de hiérarchisation à partir de
snapshot-onlyounoneàautoDans ce cas, ONTAP envoie des blocs de données utilisateur dans le système de fichiers actif qui sont déjà inactifs vers le Tier cloud, même si ces blocs de données ne sont pas encore éligibles pour le Tier cloud. -
Si la règle de Tiering est modifiée
allà partir d'une autre règle, ONTAP déplace dès que possible tous les blocs utilisateurs du système de fichiers actif et des snapshots dans le cloud. Avant ONTAP 9.8, les blocs devaient attendre l'analyse de hiérarchisation suivante.Le déplacement des blocs vers le Tier de performance n'est pas autorisé.
-
Modification de la règle de hiérarchisation à partir de
autoàsnapshot-onlyounonen'entraîne pas la migration vers le tier de performance des blocs de système de fichiers actifs qui sont déjà déplacés vers le tier cloud.Les lectures de volume sont nécessaires pour que les données puissent être retransférées vers le Tier de performance.
-
Chaque fois que vous modifiez la règle de Tiering sur un volume, la période de refroidissement minimum de Tiering est redéfinie sur la valeur par défaut de la règle.
Que arrive-t-il à la règle de Tiering lorsque vous déplacez un volume
-
Sauf si vous spécifiez explicitement une règle de Tiering, un volume conserve sa règle de Tiering d'origine lorsqu'il est déplacé dans un agrégat compatible FabricPool ou en dehors.
Toutefois, la règle de Tiering s'applique uniquement lorsque le volume se trouve dans un agrégat compatible FabricPool.
-
Valeur existante du
-tiering-minimum-cooling-daysparamètre d'un volume déplacé avec le volume sauf si vous spécifiez une règle de tiering différente pour la destination.Si vous spécifiez une autre règle de Tiering, le volume utilise la période de refroidissement minimale par défaut de Tiering pour cette règle. C'est le cas si la destination est FabricPool ou non.
-
Vous pouvez déplacer un volume entre agrégats et modifier simultanément la règle de Tiering.
-
Vous devez accorder une attention particulière lorsqu'un
volume movel'opération implique leautorègle de hiérarchisation.Si la source et la destination sont des agrégats compatibles FabricPool, le tableau suivant résume le résultat d'un
volume moveopération qui implique des changements de stratégie liés àauto:Lorsque vous déplacez un volume doté d'une règle de Tiering :
Et vous modifiez la règle de Tiering en effectuant la transition vers :
Puis, après le déplacement du volume…
allautoToutes les données sont transférées vers le Tier de performance.
snapshot-only,none, ouautoautoLes blocs de données sont déplacés vers le même niveau de destination que ceux précédemment stockés sur la source.
autoouallsnapshot-onlyToutes les données sont transférées vers le Tier de performance.
autoallToutes les données utilisateur sont déplacées vers le niveau cloud.
snapshot-only,autoouallnoneToutes les données sont conservées sur le Tier de performance.
Que arrive-t-il à la règle de Tiering lorsque vous clonez un volume
-
Depuis ONTAP 9.8, le volume clone hérite toujours de la règle de Tiering et de la politique d'extraction du cloud du volume parent.
Dans les versions antérieures à ONTAP 9.8, un clone hérite de la règle de Tiering du parent, sauf lorsque le clone possède le
allrègle de hiérarchisation. -
Si le volume parent a le
neverla politique de récupération du cloud, son volume clone doit avoir l'une ou l'autreneverrécupération cloud ouallla règle de tiering et la politique de récupération de cloud correspondantedefault. -
La politique de récupération du cloud du volume parent ne peut pas être changée en
neverà moins que tous ses volumes de clones ne disposent d'une politique de récupération cloudnever.
Lors du clonage de volumes, tenez compte des bonnes pratiques suivantes :
-
Le
-tiering-policyoption ettiering-minimum-cooling-daysl'option de clonage contrôle uniquement le comportement de hiérarchisation des blocs uniques au clone. Par conséquent, nous recommandons d'utiliser les paramètres de Tiering sur la FlexVol parent qui déplacent la même quantité de données ou déplacent moins de données que n'importe quel clone -
La politique de récupération cloud de l'FlexVol parent doit déplacer la même quantité de données ou déplacer plus de données que la politique de récupération de l'un des clones
Fonctionnement des règles de Tiering avec la migration vers le cloud
La récupération des données dans le cloud FabricPool est contrôlée par des règles de Tiering qui déterminent la récupération des données depuis le Tier cloud vers le Tier de performance selon le modèle de lecture. Les modèles de lecture peuvent être séquentiels ou aléatoires.
Le tableau ci-dessous répertorie les politiques de Tiering ainsi que les règles de récupération des données cloud pour chaque règle.
Règle de hiérarchisation |
Comportement de récupération |
Aucune |
Lectures séquentielles et aléatoires |
snapshot uniquement |
Lectures séquentielles et aléatoires |
automatique |
Lectures aléatoires |
tous |
Aucune récupération des données |
Depuis ONTAP 9.8, vous gardez le contrôle de la migration vers le cloud cloud-retrieval-policy l'option remplace le comportement par défaut de migration ou de récupération dans le cloud contrôlé par la règle de tiering.
Le tableau suivant répertorie les politiques de récupération du cloud prises en charge et leur comportement de récupération.
Politique de récupération cloud |
Comportement de récupération |
valeur par défaut |
La règle de Tiering décide des données à récupérer et ne modifie pas la récupération des données cloud par « deDefault », |
en lecture |
Toutes les données client lues sont extraites du Tier cloud au Tier de performance. |
jamais |
Aucune donnée client n'est tirée du Tier cloud vers le Tier de performance |
promouvoir |
|
Pour en savoir plus sur les commandes décrites dans cette procédure"Référence de commande ONTAP", reportez-vous à la .