Restaurateur Data Domain et rétention à long terme dans le Cloud : Questions fréquentes

Cet article répond aux questions fréquentes sur la configuration et l’utilisation des restaurateurs Data Domain (DDR) et de la rétention à long terme (LTR) ou de la fonctionnalité Cloud.
 

Qu’est-ce que la LTR ?

• Une nouvelle fonctionnalité appelée LTR a été introduite à partir de Data Domain Operating System (DDOS) 6.0.
• La LTR permet à certains modèles de DDR de migrer un sous-ensemble de fichiers ou de données vers un stockage en mode objet ou dans le Cloud, appelé niveau Cloud, à partir d’un éventail de fournisseurs de Cloud publics ou privés pris en charge.
• Pour migrer physiquement des fichiers ou des données vers le stockage en mode objet, un processus de déplacement des données est exécuté sur le DDR.
• Pour libérer physiquement des données redondantes du niveau Cloud, un processus de nettoyage du niveau Cloud est exécuté sur le DDR.
• LTR est une fonctionnalité sous licence et nécessite un CLOUDTIER_CAPACITY license.
• LTR nécessite un stockage local pour les métadonnées de niveau Cloud.

LTR est disponible pour quels systèmes DDR ?
Cela dépend de la version de DDOS installée et du type de modèle du système. La plupart des modèles doivent remplir au préalable certaines exigences matérielles pour que la LTR puisse être configurée. Voir le guide d’installation du matériel pour les modèles spécifiques ainsi que le guide d’administration DDOS pour connaître les exigences.

Quelle licence est requise pour la LTR ?

• Étant donné que la LTR est considérée comme une nouvelle fonctionnalité à partir de DDOS 6.x et versions ultérieures, une licence électronique est requise. 
• Le type de licence électronique requise est appelé une CLOUDTIER_CAPACITY license. Un exemple de CLOUDTIER_CAPACITY license se présente comme suit :

Capacity licenses:
##   Feature              Shelf Model   Capacity     Mode        Expiration Date
--   ------------------   -----------   ----------   ---------   ---------------
1    CLOUDTIER-CAPACITY   n/a           136.42 TiB   permanent   n/a
--   ------------------   -----------   ----------   ---------   ---------------

Comment fonctionnent les différents niveaux ?

• Les DDR normaux (sans licence LTR) ont un seul niveau appelé niveau actif.
• Le niveau actif est le niveau de stockage traditionnel sur tous les DDR « standard ».
• Les systèmes LTR disposent d’un deuxième niveau de stockage appelé niveau Cloud.

La taille maximale de chaque niveau est dictée par les limites prises en charge pour la configuration matérielle donnée et la version de DDOS. Voir le guide d’administration DDOS et le guide du matériel du modèle spécifique concerné.

Vous trouverez ci-dessous un exemple de configuration LTR à deux niveaux, un actif et un Cloud :   

Active Tier:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   --------   --------   ---------   ----   --------------
/data: pre-comp           -    36674.6           -      -                -
/data: post-comp    65460.3      585.4     64874.8     1%              0.1
/ddvar                 29.5       24.7         3.3    88%                -
/ddvar/core            31.5        1.1        28.8     4%                -
----------------   --------   --------   ---------   ----   --------------

Cloud Tier
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -       33.1           -      -               -
/data: post-comp      912.2       42.3       869.9     5%             4.1
----------------   --------   --------   ---------   ----   -------------

Total:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -    36674.6           -      -               -
/data: post-comp    65460.3      585.4     64874.8     1%             0.1
/ddvar                 29.5       24.7         3.3    88%               -
/ddvar/core            31.5        1.1        28.8     4%               -
----------------   --------   --------   ---------   ----   -------------

Comment un niveau Cloud est-il structuré ?

• Un niveau Cloud se compose des éléments suivants :   
  • Métadonnées conservées localement, stockées sur un boîtier si un DDR physique est utilisé, ou sur une LUN ou un appareil si DDVE est utilisé.
  • Fournisseurs de stockage en mode objet
• Les deux éléments ci-dessus sont combinés dans une unité Cloud.
• Si plusieurs unités Cloud sont configurées, elles peuvent partager les métadonnées stockées localement.
• Deux unités Cloud maximum peuvent être configurées par système. Chaque unité Cloud peut être approvisionnée à partir d’un fournisseur de stockage en mode objet différent.
• Chaque unité Cloud peut être aussi grande que la taille maximale prise en charge du niveau actif pour le modèle de DDR donné. Voir le guide d’administration DDOS pour plus d’informations.

Que se passe-t-il au cours d’un cycle de vie de sauvegarde classique lorsque la LTR est configurée ?

• Toutes les données sont initialement écrites sur le niveau actif où elles commencent à vieillir.
• Les données de courte durée qui atteignent leur période de rétention arrivent à expiration/sont supprimées comme sur un DDR normal.
• Toutefois, un sous-ensemble de données nécessitant une rétention à long terme est migré vers le niveau Cloud.
• Le système de fichiers conserve un espace de nommage unique sur tous les niveaux. Ainsi, lorsqu’un fichier migre vers le Cloud, l’espace de nommage ne change pas et, par conséquent, est raisonnablement transparent pour l’utilisateur ou l’application de sauvegarde.
• Lorsqu’un fichier qui a déjà été migré vers le niveau Cloud atteint sa période de rétention, il arrive à expiration/est supprimé comme n’importe quel autre fichier.
• L’espace qu’un fichier utilisait dans le niveau Cloud n’est pas récupéré immédiatement. Un nettoyage du niveau Cloud doit être exécuté.

Comment les données sont-elles dédupliquées entre les niveaux ?

• Chaque unité Cloud est un volume autonome, ce qui signifie qu’il s’agit d’une unité de déduplication autonome.
• Par conséquent, les données écrites sur chaque unité Cloud ne peuvent être dédupliquées que par rapport aux données de la même unité Cloud.

Qu’est-ce que l’heure de placement (parfois appelé ptime) ?

• Différents horodatages sont associés aux fichiers et répertoires.
• Par exemple, un fichier ou un répertoire a une heure de création, une heure de dernier accès et une heure de modification.
• DDOS a amélioré cette fonctionnalité pour inclure également une heure de placement. L’heure de placement correspond à la date et à l’heure auxquelles le fichier a migré du niveau actif vers le niveau Cloud.
• En fonction de la version de DDOS, l’heure de placement peut être observée lorsque l’on examine sur quel niveau un fichier se trouve. Si le fichier a migré vers le niveau Cloud, l’heure de placement est indiquée, par exemple :  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-4        cloudunit2           Tue Sep 5 10:17:00 2017
/data/col1/mtree1/random-data-file-5        cloudunit2           Tue Sep 12 15:52:23 2017
/data/col1/mtree1/random-data-file-6        cloudunit2           Tue Sep 13 09:42:55 2017

• ptime est le dernier champ de la sortie ci-dessus, bien qu’il n’affiche pas d’en-tête de champ.

Comment les données passent-elles du niveau actif au niveau Cloud ?

• Un processus appelé déplacement des données est responsable de l’examen des fichiers contenus dans une structure MTree qui se trouve dans le niveau actif.
• Le déplacement des données commence par créer un snapshot de toutes les structures MTree configurées pour le déplacement des données.
• L’heure de modification de chaque fichier enregistre la dernière fois où un fichier a été écrit.
• Si un fichier a précédemment migré vers le niveau Cloud, un champ d’heure supplémentaire appelé heure de placement est défini. L’heure de placement stocke la date et l’heure auxquelles le fichier a migré vers le niveau Cloud. Si l’heure de placement est définie, elle est utilisée à la place de l’heure de modification. Cela permet d’éviter qu’un fichier ne soit continuellement migré vers le niveau Cloud si un fichier est rappelé (car le rappel d’un fichier ne modifie pas son heure de modification).
• Les snapshots créés ci-dessus sont parcourus par le déplacement des données.
• Si le fichier examiné a atteint une valeur de seuil définie, telle que définie par la politique de déplacement des données pour la structure MTree concernée, le fichier est examiné pour déterminer quelles données contenues dans ce fichier doivent migrer du niveau actif vers le niveau Cloud. Une politique de déplacement des données est définie par structure MTree.
• Les segments uniques du fichier sélectionné sont écrits ou copiés dans le niveau Cloud. 
• Une fois que les segments uniques ont été copiés, le fichier est vérifié en le lisant à nouveau pour s’assurer que la migration a réussi.
• Une fois le fichier vérifié, les métadonnées sont mises à jour pour indiquer que le fichier réside désormais sur le niveau Cloud.
• L’exécution du processus de déplacement des données peut être planifiée à une certaine fréquence ou peut être lancée manuellement.

Lorsque le déplacement des données est lancé, quelles sont les différentes étapes et quelles actions sont effectuées à chaque étape ?

• Trois phases sont associées au déplacement des données : la phase de copie, la phase de vérification et la phase d’installation.
• La phase de copie est chargée d’identifier les segments qui doivent être copiés dans le Cloud, puis de migrer ces segments vers le Cloud.
• Une fois la phase de copie démarrée, il s’agit d’un Cloud ou d’un stockage en mode objet, qui est utilisé pour copier les segments identifiés du niveau actif vers le niveau Cloud.
• La phase de vérification permet de s’assurer que les segments d’un fichier ont bien été migrés vers le Cloud.
• La phase d’installation est chargée de mettre à jour les métadonnées, relatives au fichier qui a été migré, afin de montrer qu’il réside désormais sur le Cloud ou sur le stockage en mode objet.
• Chaque fichier doit terminer les trois phases pour que le déplacement des données soit considéré comme réussi pour ce fichier. Par conséquent, jusqu’à ce que la phase d’installation d’un fichier soit terminée, le fichier reste dans le niveau actif.

Quelles politiques de déplacement des données sont disponibles ?

• Les politiques de déplacement des données peuvent être l’une des suivantes :   
  • Seuil d’âge : Si l’heure de placement ou de modification d’un fichier est supérieure à la fourchette d’âge définie, il est sélectionné pour la migration vers le niveau Cloud.
  • Fouchette d’âge : Si l’heure de placement ou de modification d’un fichier se situe dans une plage donnée, il est sélectionné pour la migration vers le niveau Cloud.
  • Définie par l’application : L’application de sauvegarde indique si un fichier doit être sélectionné pour la migration vers le niveau Cloud.
• Les politiques s’excluent mutuellement, c’est-à-dire qu’une structure MTree ne peut avoir qu’une seule politique définie à la fois.

Comment peut-on définir une politique de déplacement des données sur une structure MTree ?

• La commande ci-dessous peut être utilisée. Par exemple :   

data-movement policy set <policy name> <policy type values> totier cloud cloud-unit <cloud unit name> mtrees <mtree list>

sysadmin@dd4500 # data-movement policy set age-threshold 14 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set age-range min-age 14 max-age 100 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set app-managed to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1

Quelles politiques de déplacement des données sont déjà configurées ?

• La commande ci-dessous fournit la liste des structures MTree auxquelles des politiques de déplacement des données sont attribuées. Par exemple :   

data-movement policy show

sysadmin@dd4500 # data-movement policy show
Mtree               Target(Tier/Unit Name)   Policy      Value      
-----------------   ----------------------   ---------   -----------
/data/col1/mtree1   Cloud/cloudunit1         age-range   14-100 days
-----------------   ----------------------   ---------   -----------

Comment fonctionne une politique de déplacement des données gérée par une application ?

• La politique de déplacement des données pour la structure MTree concernée est définie comme étant gérée par application. Cette opération est effectuée manuellement ou l’application de sauvegarde effectue cette opération à l’aide de l’interface API REST Data Domain.
• L’application de sauvegarde doit prendre en charge la LTR.
• L’application de sauvegarde doit utiliser DD Boost, et la version de DD Boost doit être compatible LTR.
• À l’aide de la bibliothèque/API DD Boost, l’application de sauvegarde définit l’heure de placement du fichier qui doit être migré vers le niveau Cloud sur une valeur spéciale indiquant que la prochaine exécution du déplacement des données sera exécutée, le fichier sera migré vers le Cloud.
• Lors du déplacement des données sur le système Data Domain, l’heure de placement est vérifiée et, si elle est définie sur la valeur spéciale comme mentionné ci-dessus, le fichier est migré vers le Cloud.

Comment le déplacement des données peut-il être mis en route manuellement ?

• La commande ci-dessous peut être utilisée, par exemple :   

data-movement start

sysadmin@dd4500 # data-movement start
Data-movement started.

Comment surveiller le déplacement des données ?

• La commande ci-dessous peut être utilisée pour vérifier l’état du déplacement des données. Par exemple :   

data-movement status

sysadmin@dd4500 # data-movement status
Data-movement to cloud tier:
----------------------------
Data-movement is initializing..

Data-movement recall:
---------------------
No recall operations found. 

• Si le déplacement des données est en cours d’exécution, la commande ci-dessous peut être utilisée, par exemple :   

data-movement watch 

sysadmin@dd4500 # data-movement watch
Data-movement: phase 1 of 3 (copying)
   92% complete; time: phase  0:08:04, total  0:08:14
      Copied (post-comp): 3.35 GiB, (pre-comp): 3.29 GiB,B,
      Files copied: 7, Files verified: 3, Files installed: 3

Comment arrêter le déplacement des données ?

• La commande ci-dessous peut être utilisée. Par exemple :   

data-movement stop 

sysadmin@dd4500 # data-movement stop
Data-movement stop initiated. Run the status command to check its status.

Si plusieurs unités Cloud existent, le déplacement des données peut-il s’effectuer en parallèle vers les deux unités Cloud ?

• Non. En fait, le déplacement des données ne peut transférer les données que vers une seule unité Cloud à la fois.

Comment la LTR est-elle configurée ?

• Il s’agit d’une présentation générale. Consultez le processus détaillé dans le guide d’administration DDOS.
• Ajoutez la mention appropriée CLOUDTIER_CAPACITY license.
• Définissez la phrase secrète du système si ce n’est pas déjà fait.
• Activez la fonctionnalité Cloud.
• Ajoutez le stockage de métadonnées pour le niveau Cloud.
• Configurez un profil Cloud ou un profil pour le fournisseur de stockage en mode objet ou Cloud approprié.
• Ajoutez une unité Cloud.
• Configurez une politique de déplacement des données pour la ou les structures MTree qui nécessitent un stockage de données dans le Cloud.
• Commencez à déplacer manuellement des données ou attendez qu’un déplacement des données automatique ou planifié démarre.

Une unité Cloud peut-elle être supprimée ? Si oui, comment ?

• Attention : Toutes les données stockées sur l’unité Cloud sont détruites, les données sont donc irrécupérables. Par conséquent, procédez avec prudence.
• Voir la section de ce document de la base de connaissances intitulée « Comment un utilisateur peut-il déterminer le niveau sur lequel se trouve un fichier ? » pour savoir quels fichiers se trouvent sur l’unité Cloud qui va être supprimée.
• Ces fichiers doivent être supprimés s’ils ne sont plus nécessaires ou rappelés au niveau actif s’ils doivent être conservés.
• Si des fichiers doivent être conservés, assurez-vous que tous les fichiers sont rappelés avant de continuer.
• Il ne doit pas rester de fichiers supprimés sur l’unité Cloud.
• Réinitialisez toutes les politiques de déplacement des données pour la ou les structures MTree qui utilisent cette unité Cloud.
• Désactivez le système de fichiers.
• Supprimez l’unité Cloud. L’unité Cloud est alors définie dans un état DELETE_PENDING, qui est conforme à la conception.
• Activez le système de fichiers.
• Une fois le système de fichiers démarré, il commence à supprimer de manière asynchrone tous les objets du Cloud ou du fournisseur de stockage en mode objet utilisés par cette unité Cloud. Une fois tous les objets supprimés, les compartiments utilisés par cette unité Cloud le sont également. En présence de nombreux objets, l’unité Cloud peut rester à l’état DELETE_PENDING pendant une période prolongée.
• Une fois que tous les objets et compartiments ont bien été supprimés, l’unité Cloud disparaît de la liste des unités Cloud.

Que se passe-t-il si une unité Cloud ne parvient pas à être supprimée parce que le stockage en mode objet n’est plus disponible ou qu’il y a un problème de connectivité ?

• Contactez le support Dell pour obtenir de l’aide supplémentaire.

La LTR et la rétention prolongée (ER) peuvent-elles être configurées sur le même système ?

• Non. ER et LTR sont des fonctionnalités qui s’excluent mutuellement.

Comment les données sont-elles libérées ou nettoyées du niveau Cloud ?

• Cela fonctionne de manière similaire aux fichiers se trouvent sur le niveau actif.
• Lorsqu’un fichier atteint sa période de rétention, il est supprimé de l’espace de nommage du système de fichiers.
• L’exécution du nettoyage du niveau Cloud est planifiée. Par défaut, le nettoyage du niveau Cloud est exécuté toutes les quatre sessions de nettoyage du niveau actif.
• Pour que le nettoyage du niveau Cloud s’exécute, l’unité Cloud nettoyée doit contenir au moins 1 % de données superflues ou nettoyables pour se lancer. En effet, tout trafic réseau Cloud peut être facturé. Le DDR tente donc de limiter le trafic réseau dans la mesure du possible.
• Le niveau Cloud s’exécute avec une régulation de nettoyage de 50 % par défaut.
• La planification du nettoyage du niveau Cloud et la régulation du nettoyage peuvent être modifiées.
• Le nettoyage des niveaux actif et Cloud ne peut pas être exécuté en parallèle.
• Si le nettoyage automatique ou planifié du niveau Cloud est en cours d’exécution, il est préempté par le nettoyage du niveau actif.
• Si un nettoyage manuel du niveau Cloud est lancé, le nettoyage du niveau actif ne peut pas démarrer tant que le nettoyage du niveau Cloud n’est pas terminé.
• Si un niveau Cloud comporte deux unités Cloud, une seule unité Cloud est nettoyée par nettoyage planifié ou automatique du niveau Cloud. Les unités Cloud sont exploitées à tour de rôle, du point de vue du nettoyage du niveau Cloud. Lorsqu’il existe deux unités Cloud, il est nécessaire de spécifier l’unité Cloud à nettoyer lors de l’exécution à partir de la ligne de commande (cloud clean start <nom-unité>)
• Si un nettoyage du niveau Cloud ne démarre pas sur une unité Cloud, par exemple, si l’unité Cloud actuelle ne dispose pas de suffisamment de données nettoyables pour que cela soit jugé utile, le système tente automatiquement de nettoyer l’unité Cloud suivante.
• Pour plus d’informations sur le nettoyage du niveau Cloud, reportez-vous à l’article Data Domain suivant : présentation de la rétention à long terme, du nettoyage du niveau Cloud et du nettoyage de la mémoire sur les restaurateurs Data Domain (DDR)

Comment lancer un nettoyage manuel du niveau Cloud ?

• La commande ci-dessous peut être utilisée. Par exemple :   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean start cloudunit2
Cloud tier cleaning started for cloud unit "cloudunit2". Use 'cloud clean watch' to monitor progress.

Comment surveiller le nettoyage du niveau Cloud ?

• La commande ci-dessous peut être utilisée pour vérifier si le nettoyage du Cloud est en cours d’exécution. Par exemple :   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean status
Previous cloud tier cleaning attempt was unsuccessful.
 Failure reason:
cloud unit "cloudunit2" did not have sufficient cleanable data.
Cloud tier cleaning finished at 2017/03/15 12:16:06.

• Si le nettoyage du Cloud est en cours d’exécution, vous pouvez le surveiller à l’aide de la commande ci-dessous :

cloud clean watch

Le nettoyage du niveau actif peut-il s’exécuter simultanément avec le nettoyage du niveau Cloud ?

• Non. Le nettoyage du niveau actif et le nettoyage du niveau Cloud utilisent tous deux les mêmes structures de données partagées internes communes qui nécessitent un accès exclusif.

Comment afficher ou modifier le planning de nettoyage de niveau Cloud ?

• La commande ci-dessous peut être utilisée pour afficher le planning de nettoyage du Cloud actuel. Par exemple :   

cloud clean frequency show

sysadmin@dd4500 # cloud clean frequency show
Cloud tier cleaning frequency is set to run after every 4 active tier cleaning cycles.

• La commande ci-dessous est utilisée pour modifier un planning. Par exemple :  

cloud clean frequency set <value>

sysadmin@dd4500 # cloud clean frequency set 3
Cloud tier cleaning frequency is set to run after every 3 active tier cleaning cycles.

Comment modifier ou afficher la régulation de nettoyage du niveau Cloud ?

• Par défaut, la régulation du nettoyage du niveau Cloud est fixée à 50 %. La commande ci-dessous peut être utilisée pour rétablir le pourcentage de régulation par défaut.

cloud clean throttle reset

• La commande ci-dessous peut être utilisée pour afficher la régulation actuelle du nettoyage du Cloud. Par exemple :   

cloud clean throttle show

sysadmin@dd4500 # cloud clean throttle show
Cloud tier cleaning throttle is set to 28 percent

• La commande ci-dessous peut être utilisée pour modifier la régulation de nettoyage. Par exemple :   

cloud clean throttle set <value> 

sysadmin@dd4500 # cloud clean throttle set 20
Cloud tier cleaning throttle set to 20 percent

Qu’est-ce que la régulation de nettoyage du niveau Cloud contrôle ?

• La régulation de nettoyage du niveau Cloud fonctionne de manière similaire à la régulation de nettoyage du niveau actif, en ce sens que la régulation limite les ressources d’E/S et de processeur que le nettoyage du niveau Cloud peut utiliser.
• Elle ne régule pas le transfert réseau.

Pourquoi le nettoyage du niveau Cloud ne libère/supprime-t-il pas autant d’objets que prévu ?

• Le nettoyage est toujours considéré comme une estimation. Voir les articles suivants de la base de connaissances qui décrivent les aspects relatifs à cette rubrique, car ils s’appliquent également aux données se trouvent sur le niveau Cloud :  

• En outre, vous trouverez d’autres détails spécifiques sur la mise en œuvre du niveau Cloud.
• Diverses méthodes ont été mises en œuvre pour limiter la quantité de trafic réseau vers un fournisseur de stockage Cloud ou en mode objet, car cela peut entraîner des coûts associés.
• Comme indiqué ci-dessus, un minimum de 1 % de perte de données est requis pour que le nettoyage puisse être exécuté.
• Lorsque le système de fichiers est parcouru pour rechercher des fichiers qui répondent à la politique de déplacement des données, seules les copies locales des métadonnées sont examinées.
• Tous les segments conservés sur le stockage Cloud ou en mode objet qui ne contiennent que des données utilisateur sont marqués pour la suppression asynchrone.
• Tous les segments contenant au moins un segment actif sont ignorés, car DDOS ne souhaite pas combiner de petites quantités de données en raison du trafic réseau impliqué.

Comment un utilisateur peut-il déterminer le niveau sur lequel se trouve un fichier ?

• Utilisez la commande ci-dessous pour obtenir un exemple de sortie générée par cette commande :  

filesys report generate file-location

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-1        Active
/data/col1/mtree1/random-data-file-2        Active
/data/col1/mtree1/random-data-file-4        cloudunit2
/data/col1/mtree1/random-data-file-5        cloudunit2
/data/col1/mtree1/random-data-file-6        cloudunit2

Un fichier peut-il être lu/consulté directement après sa migration vers le niveau Cloud ?

• Cela dépend de la version de DDOS utilisée et du fournisseur de Cloud :   

• Une restauration directe des fichiers est possible sans devoir rappeler un fichier au préalable. C’est ce qu’on appelle une « restauration directe » et elle est limitée à ECS en tant que fournisseur de Cloud ou en mode objet.
• Pour plus d’informations sur la restauration directe à partir d’Avamar, consultez le livre blancAvamar Granular or File Level Restore from Data Domain Cloud Tier.
• La fonctionnalité Avamar GLR/FLR (restauration directe) nécessite la combinaison minimale d’Avamar 18.1 ou DDOS 6.1 avec ECS comme fournisseur de Cloud. 

• Un fichier doit d’abord être rappelé. En d’autres termes, les données ont été migrées du niveau Cloud vers le niveau actif.
• Le fichier doit être rappelé du niveau Cloud vers le niveau actif à l’aide de la commande data-movement recall pour autoriser toute lecture à partir d’un fichier ou toute modification d’un fichier se trouvant sur le niveau Cloud.
• Toute tentative de lecture ou de modification d’un fichier se trouvant sur le niveau Cloud entraîne le renvoi d’une erreur d’E/S à la personne qui tente de lire le fichier, à savoir l’application de sauvegarde, si le fichier n’est pas rappelé au préalable.
• Certaines applications de sauvegarde compatibles avec le Cloud peuvent lancer des rappels de fichiers, sinon les fichiers doivent être rappelés manuellement.
• À partir de DDOS 7.7+ :
  • La restauration directe permet aux applications non intégrées de lire les fichiers directement à partir du niveau Cloud sans passer par le niveau actif.
  • Les principaux points à retenir lors du choix de la restauration directe incluent les suivants :
  • La restauration directe ne nécessite pas d’application intégrée et est transparente pour les applications non intégrées.
  • La lecture à partir du niveau Cloud ne nécessite pas de copier dans le niveau actif au préalable.
  • Des histogrammes et des statistiques sont disponibles pour suivre les lectures directes à partir du niveau Cloud.
  • La restauration directe est prise en charge uniquement pour les fournisseurs de Cloud AWS et ECS.
  • Les applications subissent une latence de niveau Cloud.
  • La lecture directe à partir du niveau Cloud n’est pas optimisée en bande passante.

Combien de fichiers peuvent être rappelés en parallèle ?

• DDOS 6.0 prend en charge quatre fichiers à mettre en file d’attente et à rappeler en parallèle.
• DDOS 6.1 prend en charge 1 000 fichiers à mettre en file d’attente et 4 fichiers à rappeler dans la file d’attente de rappel en parallèle.

D’après le guide d’administration Data Domain 7.9 :

• Les systèmes disposant de 256 Go de mémoire ou plus peuvent rappeler jusqu’à 16 fichiers à la fois.
• Les systèmes disposant de moins de 256 Go de mémoire peuvent rappeler jusqu’à huit fichiers à la fois.
• Les instances DDVE peuvent rappeler jusqu’à quatre fichiers à la fois.

Comment rappeler un fichier ?

• Un fichier peut être rappelé à l’aide de la commande ci-dessous. Par exemple :   

data-movement recall path <path-name> 

sysadmin@dd4500 # data-movement recall path /data/col1/mtree1/file1

Comment rappeler tous les fichiers d’une structure MTree ?

• En fonction de la version de DDOS, tous les fichiers dans le Cloud peuvent être rappelés en exécutant une seule commande, comme la suivante :   

sysadmin@dd4500 # data-movement recall mtree /data/col1/mtree1

• Pour plus d’informations, consultez le « Guide de référence des commandes Dell DDOS » correspondant à votre version de DDOS

Comment surveiller une opération de rappel ?

• Une opération de rappel peut être surveillée à l’aide de la commande ci-dessous ou si un fichier spécifique est requis. Par exemple :   

data-movement status path all

data-movement status path /data/col1/mtree/file1

sysadmin@dd4500 # data-movement status path /data/col1/mtree1/file1
Data-movement recall:
---------------------
Data-movement for  /data/col1/mtree1/file1 : phase 2 of 3
(Verifying)
80% complete; time: phase XX:XX:XX total XX:XX:XX
Copied (post-comp): XX XX, (pre-comp) XX XX 

Renommer un fichier entraîne-t-il le rappel du fichier du niveau Cloud vers le niveau actif ?

• Non. Si un fichier est renommé, il reste sur son niveau actuel.

Quels fournisseurs de Cloud sont pris en charge ?

•  En fonction de la version de DDOS utilisée, DDOS prend en charge les fournisseurs de Cloud suivants :   
• Amazon Web Services (AWS).
• Microsoft Azure Cloud
• Dell Elastic Cloud Service (ECS)
• Virtustream
• Voir le guide d’administration DDOS pour plus d’informations.

Le chiffrement est-il pris en charge sur le niveau Cloud et doit-il faire l’objet d’une licence ?

• Oui, le chiffrement est pris en charge sur le niveau Cloud. Ceci ne nécessite pas de licence supplémentaire, contrairement au chiffrement de niveau actif.
• Il peut être configuré lorsque la fonctionnalité Cloud est activée ou modifiée par la suite. 
• Au moment de la rédaction de ce document, seul le gestionnaire de clés intégré est pris en charge pour le chiffrement de niveau Cloud et un seul algorithme de chiffrement peut être utilisé pour l’ensemble du système de LTR.

Quels compartiments sont créés dans la zone de stockage d’objets des fournisseurs de Cloud ?

• DDOS crée trois compartiments.
• Les compartiments se terminent par la chaîne suivante :

'-d0'

'-c0' 

'-m0'

• Le compartiment se terminant par la chaîne « -d0 » est utilisé pour les segments de données.
• Le compartiment se terminant par la chaîne « -c0 » est utilisé pour les données de configuration.
• Le compartiment se terminant par la chaîne « -m0 » est utilisé pour les métadonnées.
• Avant DDOS 6.1, bien que trois compartiments soient créés, seul le compartiment se terminant par « -d0 » est utilisé. Les trois compartiments sont toutefois indispensables. Assurez-vous qu’ils ne sont pas supprimés.

Est-il possible d’utiliser des noms de compartiments existants qui ont peut-être été créés précédemment ?

• Non, cela n’est pas possible.

En plus des exigences matérielles, existe-t-il d’autres exigences obligatoires avant de configurer la LTR ?

• Oui
• Si ECS est utilisé, un équilibreur de charge est obligatoire. Sans équilibreur de charge, Data Domain communique avec ECS sur un seul nœud et se déconnecte lorsque plusieurs demandes sont effectuées.
• Un réseau 1 Gbit entre le DDR et le fournisseur de Cloud

Des certificats sont-ils requis et, si oui, quels certificats doivent être utilisés ?

• Cela dépend du fournisseur en mode objet ou de Cloud utilisé, ainsi que de la configuration.
• AWS, Virtustream ou Azure requiert un certificat. Voir le guide d’administration DDOS pour plus d’informations.
• Si ECS est configuré à l’aide d’un point de terminaison http, aucun certificat n’est requis.
• Si ECS est configuré à l’aide d’un point de terminaison https, un certificat est requis. Un équilibreur de charge étant obligatoire, le certificat requis provient du système d’équilibrage de charge plutôt que du système ECS. Pour plus d’informations, contactez le fournisseur de votre équilibreur de charge.
• Lors de l’importation du certificat, il doit être au format PEM. Certains fournisseurs ne proposent pas le certificat au format PEM. Il doit donc être converti avant l’importation.

Quelles topologies de réplication sont prises en charge ?

• La réplication de la collecte n’est pas prise en charge.
• La réplication du répertoire est prise en charge, mais elle ne peut être utilisée que par la structure MTree « /data/col1/backup ». Toutefois, cette structure MTree ne prend pas en charge le déplacement des données.
• La réplication de structure MTree est entièrement prise en charge.
• La réplication MFR ou VSR est entièrement prise en charge.

Quels éléments doivent être pris en compte lors de la configuration/l’initialisation/la réinitialisation de la réplication sur un système sur lequel la LTR est déjà configurée ?

• Le système source prend un snapshot de la structure MTree (ce snapshot inclut les informations des fichiers sur les niveaux actif et Cloud).
• Le système source réplique le snapshot vers le niveau actif du système de destination.
• Seulement une fois que le snapshot a été entièrement répliqué, il est exposé sur le système de destination (à ce stade, les fichiers deviennent disponibles dans l’espace de nommage du système de fichiers des systèmes de destination).
• Ce n’est qu’après l’exposition des fichiers que le déplacement des données peut être exécuté sur la destination (en supposant qu’elle soit configurée pour la LTR).
• Par conséquent, si le niveau actif des destinations n’est pas assez grand pour contenir un snapshot complet de la source, le snapshot n’est jamais exposé et la réplication ne peut pas terminer l’initialisation.

Que faut-il prendre en compte lors de la configuration de la réplication MFR/VSR sur un système sur lequel la LTR est déjà configurée ?

• Si les données qui ont déjà été transférées vers le niveau Cloud sur un DDR source doivent être répliquées, elles sont automatiquement rappelées du fournisseur de Cloud vers le niveau actif avant de pouvoir être envoyées sur le réseau.
• Rappeler des fichiers du niveau Cloud vers le niveau actif peut entraîner des coûts ou des retards.

Pourquoi le résultat de la commande « file system show space » de Data Domain ne reflète-t-il pas la taille réelle du Cloud/stockage en mode objet ?

• En raison du fonctionnement inhérent du stockage dans le Cloud ou en mode objet, un système Data Domain n’a aucun moyen d’interroger la taille physique d’un appareil Cloud, car elle peut sembler infinie.
• DDOS a cependant dû développer un moyen d’afficher les statistiques d’utilisation/de déduplication actuelles du point de vue de DDOS.
• Par conséquent, l’une des deux approches suivantes est utilisée :

1. La taille du niveau Cloud dépend de CLOUDTIER_CAPACITY license
2. La taille du niveau de Cloud s’affiche sous la forme d’un multiple des tailles d’unités de niveau actif pour ce type de modèle, en fonction du nombre d’unités de Cloud configurées. Pour plus d’informations sur les tailles de niveau actif, voir le guide d’installation du matériel du modèle concerné.

Comment démarrer le système de fichiers si une unité Cloud est indisponible ?

• Assurez-vous que le système de fichiers est désactivé.
• Désactivez l’unité Cloud qui n’est pas disponible à l’aide de la commande ci-dessous :

cloud unit disable <cloud unit name>

• Activez le système de fichiers.

Si une unité Cloud est désactivée, comment l’activer ?

• Assurez-vous que le système de fichiers est désactivé.
• Activez l’unité Cloud à l’aide de la commande ci-dessous :

cloud unit enable <cloud unit name>

• Activez le système de fichiers.

Pourquoi existe-t-il toujours des fichiers dans le système de fichiers résidant sur une unité Cloud qui a été supprimée ?

•  Si les fichiers n’ont pas été supprimés d’une structure MTree avant la suppression d’une unité Cloud, les fichiers continuent d’exister dans l’espace de nommage du système de fichiers.
• Par conséquent, le rapport d’emplacement des fichiers indique que les fichiers font partie d’une unité Cloud supprimée. Par exemple :  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-3  Deleted cloud-unit
/data/col1/mtree1/random-data-file-4  Deleted cloud-unit

• Les fichiers sont toujours visibles dans l’espace de nommage du système de fichiers en accédant à un partage CIFS/NFS pour cette structure MTree.
• Toutefois, les fichiers ne sont pas lisibles, car l’unité Cloud dans laquelle ils se trouvaient a été supprimée.
• Par conséquent, la seule option consiste à supprimer ces fichiers, car les données qu’ils référençaient n’existent plus.

Est-il possible de modifier le point de terminaison ou les ports de protocole d’un fournisseur de Cloud ECS ou S3 Flexible après la création d’une unité Cloud ?

• Cela peut être nécessaire, par exemple si vous passez de http à https ou inversement, si vous migrez vers un nouvel équilibreur de charge.
• Au moment de la rédaction de ce document, un administrateur Data Domain n’a aucun moyen d’effectuer cette modification. Cette fonctionnalité est envisagée pour une version future de DDOS.
• Cela peut toutefois être effectué par le support technique ou l’ingénierie.
• Le système de fichiers doit être désactivé pour pouvoir apporter cette modification.
• Si cela est nécessaire, toute la configuration en dehors du système Data Domain est effectuée en premier, car une fois que cela est modifié, lorsque le système de fichiers est activé, il s’attend à pouvoir communiquer à l’aide du protocole ou du port mis à jour et à lire les compartiments ou les objets comme il le faisait précédemment.