Cloud Tiering répond aux défis liés à la croissance rapide des données, en vous offrant des avantages tels que :

Essentiellement, toutes les données considérées comme inactives sur les systèmes de stockage primaires et secondaires constituent une bonne cible à déplacer vers le cloud. Sur les systèmes primaires, ces données peuvent inclure des instantanés, des enregistrements historiques et des projets terminés. Sur les systèmes secondaires, cela inclut tous les volumes qui contiennent des copies de données primaires réalisées à des fins de reprise après sinistre et de sauvegarde.

Oui, vous pouvez hiérarchiser les données des volumes NAS vers le cloud public ou vers des clouds privés, comme StorageGRID. Lorsque vous hiérarchisez les données accessibles via les protocoles SAN, NetApp recommande d'utiliser des clouds privés, car les protocoles SAN sont plus sensibles aux problèmes de connectivité que les NAS.

La définition de ce que l'on peut également appeler des données froides est : « blocs de volumes (métadonnées exclues) qui n'ont pas été consultés depuis un certain temps ». La « quantité de temps » est déterminée par un attribut de politique de hiérarchisation nommé cooling-days.

Oui, les performances de stockage au niveau du volume ONTAP telles que la compression, la déduplication et le compactage sont préservées lors du déplacement des données vers le niveau cloud.

FabricPool est la technologie de hiérarchisation ONTAP qui peut être autogérée via l'interface de ligne de commande ONTAP et le gestionnaire de système, ou gérée en tant que service via Cloud Tiering. Cloud Tiering transforme FabricPool en un service géré avec des processus d'automatisation avancés, à la fois sur ONTAP et dans le cloud, offrant une meilleure visibilité et un meilleur contrôle sur la hiérarchisation dans les déploiements hybrides et multicloud.

Non. Étant donné que les métadonnées du volume ne sont jamais hiérarchisées en fonction du niveau de performance, les données stockées dans le stockage d'objets ne sont pas accessibles directement.

Cependant, la hiérarchisation du cloud peut être utilisée pour obtenir une sauvegarde et une reprise après sinistre rentables en l'activant sur les systèmes secondaires et les volumes de destination SnapMirror (volumes DP), pour hiérarchiser toutes les données (métadonnées exclues), réduisant ainsi l'empreinte de votre centre de données et le coût total de possession.

La hiérarchisation du cloud est activée au niveau du volume en associant une politique de hiérarchisation à chaque volume. L’identification des données froides est effectuée au niveau du bloc.

La politique de hiérarchisation associée au volume est le mécanisme qui contrôle quels blocs sont hiérarchisés et quand. La politique définit le type de blocs de données (instantanés, données utilisateur ou les deux) et la période de refroidissement. Voir"Politiques de hiérarchisation des volumes" pour plus de détails.

La hiérarchisation du cloud n'a aucun effet sur la capacité du volume, mais plutôt sur l'utilisation du niveau de performance de l'agrégat.

Oui, Cloud Tiering permet la création de rapports de données inactives (IDR) sur chaque agrégat. Ce paramètre nous permet d’identifier la quantité de données inactives qui peuvent être hiérarchisées vers un stockage d’objets à faible coût.

L'IDR commence à afficher des informations une fois la période de refroidissement configurée écoulée. En utilisant ONTAP 9.7 et les versions antérieures, IDR avait une période de refroidissement non réglable de 31 jours. À partir d' ONTAP 9.8, la période de refroidissement IDR peut être configurée jusqu'à 183 jours.

Lors de la hiérarchisation des données froides vers le cloud public :

"Voir les détails des tarifs" .

Lors de la hiérarchisation des données froides vers un système NetApp StorageGRID (cloud privé), il n'y a aucun coût.

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

Si vous atteignez la limite de capacité BYOL ou si votre licence BYOL expire, la hiérarchisation des nouvelles données froides s'arrête. Toutes les données précédemment hiérarchisées restent accessibles, ce qui signifie que vous pouvez récupérer et utiliser ces données. Une fois récupérées, ces données sont déplacées vers le niveau de performance à partir du cloud.

Cependant, si vous disposez d'un abonnement PAYGO au marché BlueXP - Déployer et gérer les services de données cloud, les nouvelles données froides continueront d'être hiérarchisées vers le stockage d'objets et vous paierez ces frais à l'utilisation.

Non, ce n'est pas le cas.

Oui. Toutes les lectures provenant du cloud public sont soumises à des frais de sortie.

La meilleure façon d'estimer combien un fournisseur de cloud facturera pour l'hébergement de vos données est d'utiliser ses calculatrices : "AWS" , "Azuré" et "Google Cloud" .

Oui. Vérifier "Tarifs Amazon S3" , "Tarification des blocs blob" , et "Tarification du stockage cloud" pour les tarifs supplémentaires liés à la lecture/récupération des données.

Pour obtenir une estimation, ajoutez votre cluster ONTAP à la console NetApp et inspectez-le via la page Clusters de hiérarchisation du cloud. Sélectionnez Calculer les économies potentielles de hiérarchisation pour le cluster pour lancer le "Calculateur de coût total de possession (TCO) de la hiérarchisation du cloud" pour voir combien d’argent vous pouvez économiser.

Lorsqu'il est utilisé dans des environnements MetroCluster , la licence de hiérarchisation totale est appliquée à l'utilisation des deux clusters. Par exemple, si vous disposez d'une licence pour 100 Tio de hiérarchisation, la capacité de hiérarchisation utilisée de chaque cluster contribue à la capacité totale de 100 Tio.

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

La hiérarchisation du cloud est prise en charge avec les clusters AFF, FAS et ONTAP Select à nœud unique et à haute disponibilité. Les clusters dans les configurations FabricPool Mirror et MetroCluster sont également pris en charge.

Oui, à partir d' ONTAP 9.8, vous pouvez hiérarchiser les données à partir de volumes hébergés sur des agrégats de disques durs.

Oui. Cloud Tiering peut être configuré pour hiérarchiser les volumes hébergés sur n'importe quel agrégat. La configuration de la hiérarchisation des données n'a aucune importance selon le type de contrôleur utilisé et si le cluster est hétérogène ou non.

Si vous disposez de systèmes Cloud Volumes ONTAP , vous les trouverez sur la page Cloud Tiering Clusters afin d'obtenir une vue complète de la hiérarchisation des données dans votre infrastructure de cloud hybride. Cependant, les systèmes Cloud Volumes ONTAP sont en lecture seule à partir de Cloud Tiering. Vous ne pouvez pas configurer la hiérarchisation des données sur Cloud Volumes ONTAP à partir de Cloud Tiering. "Vous configurez la hiérarchisation pour les systèmes Cloud Volumes ONTAP à partir du système ONTAP dans la console NetApp" .

Cela dépend de l’endroit où vous classez les données froides. Consultez les liens suivants pour plus de détails :

Cloud Tiering prend en charge les fournisseurs de stockage d'objets suivants :

Oui, tu peux. Lorsque vous configurez la hiérarchisation des données, vous avez le choix d'ajouter un nouveau bucket/conteneur ou de sélectionner un bucket/conteneur existant.

Cloud Tiering prend en charge la hiérarchisation 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 plus de détails.

La principale raison pour laquelle Amazon S3 Glacier Flexible et S3 Glacier Deep Archive ne sont pas pris en charge est que Cloud Tiering est conçu comme une solution de hiérarchisation hautes performances. Les données doivent donc être disponibles en permanence et rapidement accessibles pour la récupération. Avec S3 Glacier Flexible et S3 Glacier Deep Archive, la récupération des données peut durer entre quelques minutes et 48 heures.

Oui, la configuration du stockage d’objets compatible S3 via l’interface utilisateur de hiérarchisation est prise en charge pour les clusters utilisant ONTAP 9.8 et versions ultérieures. "Voir les détails ici" .

Cloud Tiering prend en charge la hiérarchisation des données vers les niveaux d'accès Hot ou Cool pour vos données inactives. Voir"Niveaux d'accès Azure Blob pris en charge" pour plus de détails.

Cloud Tiering prend en charge la hiérarchisation des données vers les classes de stockage Standard, Nearline, Coldline et Archive. Voir"Classes de stockage Google Cloud prises en charge" pour plus de détails.

Oui. Vous pouvez activer la gestion du cycle de vie afin que Cloud Tiering transfère les données de la classe de stockage/niveau d'accès par défaut vers un niveau plus rentable après un certain nombre de jours. La règle de cycle de vie est appliquée à tous les objets du compartiment sélectionné pour le stockage Amazon S3 et Google Cloud, et à 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 Configuration avancée pour ajouter des magasins d'objets supplémentaires pour un cluster, puis attacher différents magasins d'objets à différents agrégats, ou attacher 2 magasins d'objets à un agrégat pour la mise en miroir.

Il est possible d'attacher jusqu'à deux buckets par agrégat à des fins de mise en miroir, où les données froides sont hiérarchisées de manière synchrone dans les deux buckets. Les seaux peuvent provenir de différents fournisseurs et de différents emplacements. À partir d'août 2022, vous pouvez utiliser la page Configuration avancée pour attacher deux magasins d'objets à un seul agrégat.

Oui. La meilleure pratique générale consiste à attacher un seul godet à plusieurs agrégats. Cependant, lors de l'utilisation du cloud public, il existe une limitation maximale d'IOPS pour les services de stockage d'objets. Par conséquent, plusieurs buckets doivent être pris en compte.

Lors de la migration d’un volume d’un cluster vers un autre, toutes les données froides sont lues à partir du niveau 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 stratégie de hiérarchisation utilisée sur les volumes source et de destination.

Si l'agrégat de destination n'a pas de niveau cloud attaché, les données sont lues à partir du niveau cloud de l'agrégat source et écrites entièrement sur le niveau local de l'agrégat de destination. Si l'agrégat de destination possède un niveau cloud attaché, les données sont lues à partir du niveau cloud de l'agrégat source et d'abord écrites sur le niveau local de l'agrégat de destination, afin de faciliter une commutation rapide. Plus tard, en fonction de la politique de hiérarchisation utilisée, il est écrit dans le niveau cloud.

À partir d' ONTAP 9.6, si l'agrégat de destination utilise le même niveau de cloud que l'agrégat source, les données froides ne reviennent pas au niveau local.

L'écriture différée est généralement effectuée lors des lectures et dépend du type de politique de hiérarchisation. Avant ONTAP 9.8, la réécriture de l'intégralité du volume pouvait être effectuée avec une opération volume move. À partir d' ONTAP 9.8, l'interface utilisateur de hiérarchisation propose des options permettant de Rétablir toutes les données ou de Rétablir le système de fichiers actif. "Découvrez comment déplacer les données vers le niveau de performance" .

Non. Pendant la procédure « d'échange de tête », la seule chose qui change est la propriété de l'agrégat. Dans ce cas, il sera transféré vers le nouveau contrôleur sans aucun déplacement 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 provenant de plusieurs fichiers. Les métadonnées d’un volume restent toujours au niveau local.

L'agent de console est un logiciel exécuté sur une instance de calcul au sein de votre compte cloud ou sur site, qui permet à la console NetApp de gérer en toute sécurité les ressources cloud. Pour utiliser le service Cloud Tiering, vous devez déployer un agent.

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

Oui. Vous devez disposer d'un compte avant de pouvoir définir le stockage d'objets que vous souhaitez utiliser. Un compte auprès d'un fournisseur de stockage cloud est également requis lors de la configuration de l'agent dans le cloud sur un VPC ou un VNet.

En cas de défaillance d'un agent, seule la visibilité sur les environnements hiérarchisés est impactée. Toutes les données sont accessibles et les données froides nouvellement identifiées sont automatiquement hiérarchisées vers le stockage d'objets.

Il existe quatre politiques de hiérarchisation :

"En savoir plus sur les politiques de hiérarchisation" .

Étant donné que la hiérarchisation des données est effectuée au niveau du bloc, un bloc de données est considéré comme froid après qu'il n'a pas été consulté pendant une certaine période, définie par l'attribut minimum-cooling-days de la politique de hiérarchisation. La plage applicable est de 2 à 63 jours avec ONTAP 9.7 et versions antérieures, ou de 2 à 183 jours à partir de ONTAP 9.8.

La période de refroidissement par défaut pour la politique Cold Snapshot est de 2 jours, tandis que la période de refroidissement par défaut pour les données utilisateur froides et les instantanés est de 31 jours. Le paramètre jours de refroidissement n'est pas applicable à la politique de hiérarchisation complète.

Lors de la sauvegarde complète, toutes les données froides sont lues. La récupération des données dépend de la politique de hiérarchisation utilisée. Lorsque vous utilisez les stratégies Données utilisateur toutes et froides et Instantanés, les données froides ne sont pas réécrites dans le niveau de performances. Lorsque vous utilisez la politique Cold Snapshots, ce n'est que dans le cas où un ancien snapshot est utilisé pour la sauvegarde que ses blocs froids seront récupérés.

Non. Cependant, vous pouvez choisir les volumes éligibles à la hiérarchisation, le type de données à hiérarchiser et leur période de refroidissement. Cela se fait en associant une politique de hiérarchisation à ce volume.

Non. Les volumes de protection des données (DP) peuvent être associés à l’une des trois politiques disponibles. Le type de politique utilisé sur les volumes source et de destination (DP) détermine l'emplacement d'écriture des données.

Aucune réhydratation n’a lieu lorsqu’une politique de hiérarchisation est réinitialisée, mais cela empêchera de nouveaux blocs froids d’être déplacés vers le niveau cloud.

Oui. Le comportement après le changement dépend de la nouvelle politique associée.

N'associez pas de politique de hiérarchisation au volume contenant ces données.

Les métadonnées d'un volume sont toujours stockées localement, au niveau des performances : elles ne sont jamais hiérarchisées vers le cloud.

Pour plus de détails, voir :

Outre le Cloud Tiering, "Active IQ Unified Manager" et "conseiller numérique" peut être utilisé pour la surveillance et le reporting.

En cas de panne du réseau, le niveau de performance local reste en ligne et les données chaudes restent accessibles. Cependant, les blocs qui ont déjà été déplacés vers le niveau cloud seront inaccessibles et les applications recevront un message d’erreur lorsqu’elles tenteront d’accéder à ces données. Une fois la connectivité rétablie, toutes les données seront parfaitement accessibles.

La latence de lecture de la technologie de hiérarchisation FabricPool sous-jacente dépend de la connectivité au niveau 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 fournir des performances adéquates. Il n'y a aucune recommandation ni limitation de bande passante pour l'agent.

De plus, vous pouvez limiter la quantité de bande passante réseau utilisée lors du transfert de données inactives du volume vers le stockage d'objets. Le paramètre Taux de transfert maximal est disponible lors de la configuration de votre cluster pour la hiérarchisation, puis à partir de la page Clusters.

Oui. Les niveaux cloud ne peuvent pas fournir la même latence que le niveau local, car la latence dépend de la connectivité. Pour estimer la latence et le débit d'un magasin d'objets, Cloud Tiering fournit un test de performances cloud (basé sur le profileur de magasin d'objets ONTAP ) qui peut être utilisé après la connexion du magasin d'objets et avant la configuration de la hiérarchisation.

Le cryptage AES-256-GCM est maintenu à la fois sur les niveaux de performance et de cloud. Le chiffrement TLS 1.2 est utilisé pour chiffrer les données sur le réseau lorsqu'elles se déplacent entre les niveaux et pour chiffrer la communication entre l'agent 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 HA qui héberge des volumes avec des données que vous prévoyez de hiérarchiser vers le cloud. Pour plus d’informations, consultez la section Exigences du fournisseur de cloud auprès duquel vous prévoyez de hiérarchiser les données.