Le Tiering BlueXP vous aide à relever les défis liés à la croissance rapide des données, ce qui vous offre plusieurs avantages :

De fait, toutes les données considérées comme inactives sur des systèmes de stockage primaire et secondaire sont particulièrement bien transférées vers le cloud. Sur les systèmes primaires, ces données peuvent inclure des instantanés, des enregistrements historiques et des projets finis. Sur les systèmes secondaires, cela inclut tous les volumes qui contiennent des copies de données primaires effectuées à des fins de reprise d'activité et de sauvegarde.

Oui, vous pouvez transférer les données de volumes NAS vers un cloud public ou vers des clouds privés, tels que StorageGRID. Lors du Tiering des données accessibles par les protocoles SAN, NetApp recommande l'utilisation de clouds privés, car les protocoles SAN sont plus sensibles aux problèmes de connectivité que NAS.

Les données inactives sont délimitées : « blocs de volume (métadonnées exclus) qui n'ont pas été utilisés pendant un certain temps ». Le « temps » est déterminé par un attribut de stratégie de hiérarchisation nommé refroidissement-jours.

Oui, les fonctionnalités d'efficacité du stockage au niveau des volumes ONTAP, telles que la compression, la déduplication et la compaction, sont conservées lors du déplacement des données vers le Tier cloud.

FabricPool est la technologie de Tiering ONTAP qui peut être autogérée via l'interface de ligne de commande ONTAP et System Manager, ou gérée en tant que service via le Tiering BlueXP. Le Tiering BlueXP transforme FabricPool en service géré doté de processus d'automatisation avancés, sur ONTAP et dans le cloud, offrant ainsi une meilleure visibilité et un meilleur contrôle sur le Tiering dans les déploiements hybrides et multicloud.

Non Les métadonnées du volume ne sont jamais hiérarchisées depuis le Tier de performance, c'est pourquoi les données stockées dans le stockage objet sont inaccessibles.

Toutefois, le Tiering BlueXP peut être utilisé pour réaliser des sauvegardes et des reprises d'activité économiques en le permettant sur des systèmes secondaires et des volumes de destination SnapMirror (volumes DP), de procéder au Tiering de toutes les données (métadonnées exclues), ce qui réduit l'empreinte et le TCO de votre data Center.

Le Tiering BlueXP est activé au niveau du volume en associant une règle de hiérarchisation à chaque volume. L'identification des données inactives est effectuée au niveau des blocs.

La règle de hiérarchisation associée au volume mécanisme qui contrôle les blocs qui sont hiérarchisés et quand. Cette règle définit le type de blocs de données (snapshots, données utilisateur ou les deux) et la période de refroidissement. Voir "Règles de Tiering des volumes" pour plus d'informations.

Le Tiering BlueXP n'a aucun effet sur la capacité du volume, mais sur l'utilisation du Tier de performance de l'agrégat.

Oui, le Tiering BlueXP active le reporting des données inactives sur chaque agrégat. Ce paramètre nous permet d'identifier la quantité de données inactives pouvant être envoyées vers un stockage objet à faible coût.

L'IDR commence à afficher les informations une fois la période de refroidissement configurée terminée. Avec ONTAP 9.7 et les versions antérieures, l'IDR a connu une période de refroidissement non réglable de 31 jours. À partir de ONTAP 9.8, la période de refroidissement de l'IDR peut être configurée jusqu'à 183 jours.

Lors du Tiering des données inactives dans le cloud public :

"Voir le détail des prix".

Le Tiering des données inactives vers un système NetApp StorageGRID (cloud privé) est gratuit.

Oui. Le Tiering BlueXP vous permet d'utiliser une licence BYOL, un abonnement PAYGO ou une combinaison des deux.

Si vous atteignez la limite de capacité BYOL, le Tiering des nouvelles données inactives s'arrête. Toutes les données précédemment hiérarchisées restent accessibles. Vous pouvez donc les récupérer et les utiliser. Lorsqu'elles sont récupérées, elles sont replacées dans le Tier de performance du cloud.

Toutefois, si vous avez souscrit un abonnement PAYGO Marketplace à BlueXP - Deploy & Manage Cloud Data Services, les nouvelles données inactives continueront d'être hiérarchisées vers le stockage objet et vous payez ces frais à l'utilisation.

Non, ce n'est pas le cas.

Oui. Toutes les lectures effectuées à partir du cloud public sont soumises à des frais de sortie.

Pour évaluer les frais d'hébergement de vos données par un fournisseur de cloud, utilisez les outils de calcul : "AWS", "Azure" et "Google Cloud".

Oui. Fait "Tarification Amazon S3", "Tarification Blob par bloc", et "Tarifs du stockage cloud" pour connaître les frais supplémentaires engagés pour la lecture/récupération des données.

Pour obtenir une estimation, il vous suffit d'ajouter votre cluster ONTAP à BlueXP et de l'inspecter à la page clusters de Tiering BlueXP. Cliquez sur calculer les économies potentielles de hiérarchisation pour que le cluster lance "Calculateur de TCO du Tiering BlueXP" pour voir combien d'argent vous pouvez économiser.

Le Tiering BlueXP prend en charge ONTAP version 9.2 et supérieure.

Le Tiering BlueXP est pris en charge avec les clusters AFF, FAS et ONTAP Select à un seul nœud et haute disponibilité. Les clusters des configurations FabricPool Mirror et MetroCluster sont également pris en charge.

Oui, à partir de ONTAP 9.8, vous pouvez classer les données à partir des volumes hébergés sur des agrégats HDD.

Oui. Le Tiering BlueXP peut être configuré pour hiérarchiser les volumes hébergés sur n'importe quel agrégat. La configuration de Tiering des données n'est pas pertinente en fonction du type de contrôleur utilisé, que le cluster soit hétérogène ou non.

Si vous disposez de systèmes Cloud Volumes ONTAP, vous les trouverez sur la page clusters de Tiering BlueXP pour obtenir une vue complète du Tiering des données dans votre infrastructure de cloud hybride. Cependant, les systèmes Cloud Volumes ONTAP sont en lecture seule à partir du Tiering BlueXP. Vous ne pouvez pas configurer le Tiering des données sur Cloud Volumes ONTAP à partir du Tiering BlueXP. "Vous avez configuré le Tiering des systèmes Cloud Volumes ONTAP à partir de l'environnement de travail dans BlueXP".

Cela dépend de l'endroit où vous procédez au Tiering des données inactives. Pour en savoir plus, consultez les liens suivants :

Le Tiering BlueXP prend en charge plusieurs fournisseurs de stockage objet :

Oui, c'est possible. Une fois le Tiering configuré, vous avez la possibilité d'ajouter un nouveau compartiment/conteneur ou de sélectionner un compartiment/conteneur existant.

Le Tiering BlueXP prend en charge le Tiering des données vers les classes de stockage Standard, Standard-Infrequent Access, One zone-Infrequent Access, Intelligent Tiering et Glacier Instant Retrieval. Voir "Classes de stockage S3 prises en charge" pour en savoir plus.

La principale raison pour laquelle Amazon S3 Glacier flexible et S3 Glacier Deep Archive ne sont pas pris en charge est que le Tiering BlueXP est conçu comme une solution de Tiering haute performance. Les données doivent donc être disponibles en continu et rapidement accessibles pour être récupérées. Avec les fonctionnalités flexibles de S3 Glacier et d'archivage profond S3 Glacier, la récupération des données peut durer entre quelques minutes et 48 heures.

Oui. La configuration du stockage objet compatible S3 via l'interface de Tiering est prise en charge pour les clusters qui utilisent ONTAP 9.8 et versions ultérieures. "Pour en savoir plus, cliquez ici".

Le Tiering BlueXP prend en charge le Tiering des données vers les tiers d'accès Hot ou Cool pour vos données inactives. Voir "Tiers d'accès Azure Blob pris en charge" pour en savoir plus.

Le Tiering BlueXP prend en charge le Tiering des données vers les classes de stockage Standard, Nearline, Coldline et Archive. Voir "Classes de stockage Google Cloud prises en charge" pour en savoir plus.

Oui. Vous pouvez activer la gestion du cycle de vie afin que le Tiering BlueXP transfère les données du Tier de classe de stockage/d'accès par défaut vers un Tier plus économique après un certain nombre de jours. La règle de cycle de vie s'applique à tous les objets du compartiment sélectionné pour le stockage Amazon S3 et Google Cloud, ainsi qu'à tous les conteneurs du compte de stockage sélectionné pour Azure Blob.

Dans une configuration typique, il existe un magasin d'objets pour l'ensemble du cluster. À partir d'août 2022, vous pouvez utiliser la page Advanced Setup pour ajouter des magasins d'objets supplémentaires pour un cluster, puis associer plusieurs magasins d'objets à d'autres agrégats, ou joindre deux magasins d'objets à un agrégat pour la mise en miroir.

Il est possible de connecter jusqu'à deux compartiments par agrégat à des fins de mise en miroir, où les données inactives sont réparties de manière synchrone sur les deux compartiments. Ces compartiments peuvent être de différents fournisseurs et emplacements. À partir d'août 2022, vous pouvez utiliser la page Advanced Setup pour attacher deux magasins d'objets à un seul agrégat.

Oui. La meilleure pratique générale est de connecter un compartiment unique à plusieurs agrégats. Toutefois, lorsque vous utilisez le cloud public, les IOPS sont maximales pour les services de stockage objet. Plusieurs compartiments doivent donc être pris en compte.

Lorsque vous migrez un volume d'un cluster vers un autre, toutes les données inactives sont lues à partir du Tier cloud. L'emplacement d'écriture sur le cluster de destination dépend de l'activation ou non de la hiérarchisation et du type de règle de Tiering utilisé sur les volumes source et de destination.

Si l'agrégat de destination ne dispose pas d'un niveau de cloud associé, les données sont lues à partir du Tier cloud de l'agrégat source et écrites intégralement sur le niveau local de l'agrégat de destination. Si l'agrégat de destination dispose d'un Tier cloud associé, les données sont lues depuis le Tier cloud de l'agrégat source et écrites d'abord sur le Tier local de l'agrégat de destination pour faciliter la mise en service rapide. Ensuite, elle est écrite sur le Tier cloud, en fonction de la règle de Tiering utilisée.

Depuis ONTAP 9.6, si l'agrégat de destination utilise le même Tier cloud que l'agrégat source, les données inactives ne sont pas retransférées vers le Tier local.

L'écriture différée est généralement effectuée sur les lectures et dépend du type de règle de hiérarchisation. Avant ONTAP 9.8, l'écriture du volume entier peut être effectuée avec une opération volume Move. À partir de ONTAP 9.8, l'interface utilisateur de Tiering dispose d'options permettant de ramener toutes les données ou rétablir le système de fichiers actif. "Découvrez comment retransférer les données vers un Tier de performance".

Non Pendant la procédure de « remplacement de tête », la seule chose qui change est la propriété de l'agrégat. Il sera alors remplacé par le nouveau contrôleur sans déplacer de données.

Non Les objets construits et hiérarchisés dans le cloud ne contiennent pas un seul fichier mais jusqu'à 1,024 blocs de 4 Ko à partir de plusieurs fichiers. Les métadonnées d'un volume restent toujours sur le niveau local.

Il s'agit d'un logiciel exécuté sur une instance de calcul dans votre compte cloud ou sur site, permettant ainsi à BlueXP de gérer les ressources cloud de manière sécurisée. Pour utiliser le service de Tiering BlueXP, vous devez déployer un connecteur.

Oui. Le logiciel Connector peut être téléchargé et installé manuellement sur un hôte Linux de votre réseau. "Découvrez comment installer le connecteur dans vos locaux".

Oui. Vous devez disposer d'un compte avant de pouvoir définir le stockage objet à utiliser. Un compte parmi un fournisseur de stockage cloud est également nécessaire pour configurer le connecteur dans le cloud sur un VPC ou vNet.

En cas de défaillance des connecteurs, seule la visibilité dans les environnements à plusieurs niveaux est affectée. Toutes les données sont accessibles et les données inactives nouvellement identifiées sont automatiquement transférées vers le stockage objet.

Il existe quatre règles de hiérarchisation :

"En savoir plus sur les règles de Tiering".

Étant donné que le Tiering est réalisé au niveau des blocs, un bloc de données est considéré comme froid après l'absence d'accès pendant une certaine période, définie par l'attribut « minimum-refroidissement-jours » de la règle de Tiering. La plage applicable est de 2-63 jours avec ONTAP 9.7 et versions antérieures, ou 2-183 jours avec ONTAP 9.8.

La période de refroidissement par défaut de la règle Snapshot froid est de 2 jours, tandis que la période de refroidissement par défaut des données utilisateur inactives et des snapshots est de 31 jours. Le paramètre jours de refroidissement n'est pas applicable à la règle de hiérarchisation tous les niveaux.

Pendant la sauvegarde complète, toutes les données inactives sont lues. La récupération des données dépend de la règle de Tiering utilisée. Lorsque vous utilisez les règles Snapshot et toutes les données utilisateur inactives, les données inactives ne sont pas écrites à nouveau dans le Tier de performance. Lors de l'utilisation de la règle snapshots inactifs, les blocs à froid ne sont récupérés que si un ancien snapshot est utilisé pour la sauvegarde.

Non Vous pouvez cependant choisir les volumes qui peuvent bénéficier d'un Tiering, le type de données à placer et la période de refroidissement. Cette opération consiste à associer une règle de hiérarchisation à ce volume.

Non Des volumes de protection des données (DP) peuvent être associés à l'une des trois règles disponibles. Le type de règle utilisée sur les volumes source et de destination détermine l'emplacement d'écriture des données.

Aucune réhydratation n'a lieu lors de la réinitialisation d'une règle de Tiering, mais elle empêche la migration vers le Tier cloud de nouveaux blocs peu sollicités.

Oui. Le comportement après la modification dépend de la nouvelle stratégie associée.

N'associez pas une règle de Tiering au volume qui contient ces données.

Les métadonnées d'un volume sont toujours stockées localement, sur le Tier de performance.- elles ne sont jamais envoyées vers le cloud.

Pour plus de détails, voir :

Autre que le Tiering BlueXP, "Active IQ Unified Manager" et "Conseiller digital BlueXP" peut être utilisé pour la surveillance et la création de rapports.

En cas de défaillance réseau, le niveau de performance local reste en ligne et les données actives restent accessibles. Cependant, les blocs qui ont déjà été déplacés vers le Tier cloud seront inaccessibles. Les applications reçoivent un message d'erreur lors de la tentative d'accès à ces données. Une fois la connectivité rétablie, toutes les données sont accessibles de manière transparente.

La latence de lecture de la technologie de Tiering FabricPool sous-jacente dépend de la connectivité au Tier cloud. Bien que la hiérarchisation fonctionne sur n'importe quelle bande passante, il est recommandé de placer les LIF intercluster sur des ports 10 Gbit/s pour assurer des performances adéquates. Il n'y a pas de recommandations ni de limitations de bande passante pour le connecteur.

Vous pouvez en outre limiter la quantité de bande passante réseau utilisée lors du transfert des données inactives du volume vers le stockage objet. Le paramètre maximum Transfer Rate est disponible lors de la configuration de votre cluster pour la hiérarchisation, puis à partir de la page clusters.

Oui. Les tiers cloud ne peuvent pas offrir la même latence que le Tier local, car la latence dépend de la connectivité. Pour estimer la latence et le débit d'un magasin d'objets, le Tiering BlueXP propose un test des performances cloud (basé sur l'éditeur de profil de magasin d'objets ONTAP) qui peut être utilisé après la connexion du magasin d'objets et avant la configuration du Tiering.

Le chiffrement AES-256-GCM est géré à la fois sur les tiers de performance et dans le cloud. Le chiffrement TLS 1.2 est utilisé pour chiffrer les données sur le réseau lors de leur déplacement entre les tiers, et pour chiffrer les communications entre le connecteur et le cluster ONTAP et le magasin d'objets.

Oui. Un LIF intercluster doit être configuré sur un port ethernet, sur chaque nœud d'une paire haute disponibilité qui héberge les volumes avec les données que vous prévoyez de mettre en niveau vers le cloud. Pour en savoir plus, consultez la section exigences du fournisseur cloud dans lequel vous prévoyez de transférer des données.