Dépannage des taux de déduplication et de compression médiocres des fichiers sur les restaurations Data Domain (DDR)

Les restaurations Data Domain (DDR) sont conçues pour contenir de grandes quantités de données logiques (précompressées) à l’aide d’un espace disque physique (postcompressé) minimal. Pour ce faire, procédez comme suit :

• Déduplication des données acquises pour supprimer les fragments de données en double qui sont déjà stockés sur le disque sur le DDR, ne laissant que des données uniques
• Compression des données uniques avant que ces données ne sont physiquement écrites sur le disque.

Le taux de compression global des données qu’un DDR peut ingérer varie en raison de plusieurs facteurs tels que :

• Cas d’utilisation
• Types de données acquis
• Configuration de l’application de sauvegarde

Lorsqu’elles sont configurées de manière optimale, les DDR atteignent généralement un taux de compression global de 10 à 20 (et peuvent parfois afficher des taux plus élevés). À l’inverse, cependant, dans certains environnements, le taux de compression global peut être inférieur à ce qui peut entraîner :

• Le DDR pour épuiser rapidement sa capacité utile
• Impact sur les performances de sauvegarde, de restauration ou de réplication
• Une défaillance de la DDR pour répondre aux attentes du client

Cet article est destiné à aborder les sujets suivants :

• Brève présentation de la déduplication et de la compression des données sur un DDR
• Comment déterminer le taux de compression global pour le système et les fichiers individuels
• Facteurs pouvant entraîner une dégradation du taux de compression global

Comment un Data Domain Restorer ingère-t-il de nouvelles données ?

• L’application de sauvegarde envoie des données (c’est-à-dit des fichiers) à la DDR.
• La DDR divise ces fichiers en fragments d’une taille de 4 à 12 Ko, chaque fragment étant considéré comme un « segment ».
• Le DDR génère une « empreinte » unique (similaire à une somme de contrôle) pour chaque segment en fonction des données contenues dans le segment.
• Les empreintes digitales des segments nouvellement arrivés sont vérifiées sur les index de disque du DDR afin de déterminer si le DDR contient déjà un segment avec la même empreinte digitale.
• Si le DDR contient déjà un segment avec la même empreinte digitale, le segment correspondant dans les données nouvellement arrivées est un doublon et peut être supprimé (qui est dédupliqué).
• Une fois que tous les segments en double ont été supprimés des données nouvellement arrivées, seuls les segments uniques ou nouveaux restent.
• Ces segments uniques ou nouveaux sont regroupés en « zones de compression » de 128 Ko, puis compressés (à l’aide de l’algorithme lz par défaut).
• Les zones de compression compressées sont compressées dans des unités de stockage de 4,5 Mo appelées « conteneurs », qui sont ensuite écrites sur le disque dur.

Comment la DDR effectue-t-elle le suivi des segments qui composent un certain fichier ?

En plus de la déduplication/compression des données nouvellement arrivées, la DDR crée également une « arborescence de segments » pour chaque fichier acquis. Il s’agit essentiellement d’une liste d’empreintes digitales de segment qui composent ce fichier. Si le DDR doit lire ultérieurement le fichier, il doit :

• Déterminez l’emplacement de l’arborescence des segments de fichiers.
• Lisez l’arborescence des segments pour obtenir la liste de toutes les empreintes de segment qui composent la région du fichier en cours de lecture.
• Utilisez sur les index de disque pour déterminer l’emplacement physique (conteneur) des données sur le disque.
• Lisez les données des segments physiques à partir des conteneurs sous-jacents sur le disque.
• Utilisez les données des segments physiques pour reconstruire le fichier.

Les arborescences de segments de fichiers sont également stockées dans des conteneurs de 4,5 Mo sur disque et représentent la majorité des « métadonnées » de chaque fichier (décrites plus loin dans cet article).

Comment déterminer le taux de compression global sur un DDR ?

L’utilisation globale d’un DDR (et taux de compression) peut être observée à l’aide de la commande « filesys show space ». Par exemple :

Active Tier :
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data : pre-comp - 115367.8 - - -
/data : post-comp 6794 2 6242,4 551,8 92 % 202,5
/ddvar 49,2 9,1 37,6 20 % -


---------------- -------- -------- --------- ---- -------------- Dans ce cas, nous constatons que :

• Données précompressées ou logiques conservées sur DDR : 115 367,8 Go
• Espace postcompressé ou physique utilisé sur DDR : 6 242,4 Go
• Le taux de compression global est de 115 367,8 /6 242,4 = 18,48 x

La sortie de la commande « filesys show compression » confirme les données conservées, l’espace utilisé et le taux de compression. Par exemple :

                   Facteur
de facteur de pré-compression post-compression global-rém local-rém total-rém
(Gio) (Gio) facteur (réduction %)
---------------- -------- --------- ----------- ---------- -------------
Currently Used :*   115367.8 6242.4 - - 18,5x (94,6) <=== NOTE
écrite :                                                                          
  7 derniers jours 42214,7 1 863,2 x 11,0 x 2,1 x 22,7 x (95,6)
  Les dernières 24 heures 4 924,8 274,0 8,8 x 2,0 x 18,0 x (94,4)
---------------- -------- --------- ----------- ---------- -------------

Les chiffres d’utilisation totale sur la DDR sont calculés comme suit :

• Nombre total de données précompressées : Somme de la taille précompressée (logique) de tous les fichiers détenus par la DDR.
• Total des données postcompressées : Le nombre de conteneurs en cours d’utilisation sur le disque est multiplié par 4,5 Mo (la taille d’un seul conteneur).
• Taille totale postcompressée : Nombre maximal de « conteneurs » créés en fonction de l’espace disque disponible sur le système.

Des statistiques sur le nombre maximal de conteneurs utilisés sont disponibles dans les autosupports. Par exemple :

ensemble de conteneurs 73fcacadea763b48 :b66f6a65133e6c73 :
...
    attrs.psize = 4718592 <=== Taille du conteneur en octets
...
    attrs.max_containers = 1546057 <=== Maximum possible conteneurs
attrs.free_containers = 125562 <=== Currently free containers
attrs.used_containers = 1420495 <=== Currently in use containers
...

Découvrez les détails suivants :
 
Comment déterminer les taux de déduplication et de compression d’un fichier, d’un répertoire ou d’une arborescence de répertoires individuels ?

Lorsqu’un fichier est acquis, le DDR enregistre les statistiques relatives au fichier, notamment :

• Octets précompressés (logiques)
• Taille des segments uniques après la déduplication
• Taille des segments uniques après la déduplication et la compression
• Taille des métadonnées du fichier (arborescence de segments, et ainsi de suite)

Il est possible de vider certaines de ces statistiques à l’aide de la commande « filesys show compression [path] », par exemple pour signaler les statistiques d’un seul fichier :

SE@DDVE60_JF## filesys show compression /data/col1/backup/testfile
Total files : 1;  octets/storage_used : 2.9
Octets d’origine :        3 242 460 364
compressés globalement :        1 113 584 070
compressés localement :        1 130 871 915
métadonnées :            4 772 672

Pour générer des statistiques sur l’ensemble d’une arborescence de répertoires :

SE@DDVE60_JF## filesys show compression /data/col1/backup
Total files : 3;  octets/storage_used : 1.4
Octets d’origine :        7 554 284 280
compressés globalement :        5 425 407 986
compressés localement :        5 510 685 100
métadonnées :           23 263 692

Notez toutefois qu’il existe quelques restrictions concernant l’utilisation de ces statistiques :

• Les statistiques sont générées au moment de l’acquisition des fichiers ou des données, et ne sont pas mises à jour. En raison du fonctionnement d’une DDR, l’acquisition de nouveaux fichiers ou la suppression de fichiers faisant référence aux mêmes données, et ainsi de suite, peuvent modifier la façon dont un fichier se déduplique au fil du temps, ce qui entraîne l’expiration de ces statistiques.
• En outre, certains cas d’utilisation sur la DDR (tels que fastcopy d’un fichier, puis la suppression du fichier d’origine) peuvent entraîner ces statistiques deviennent trompeuses ou incorrectes.

Par conséquent, ces chiffres doivent être considérés comme des estimations uniquement.

Les octets précompressés ne sont pas nécessairement la taille précompressée/logique du fichier. Au lieu de cela, il s’agit du nombre total d’octets écrits dans un fichier au cours de sa durée de vie. Par conséquent, dans certains environnements, les fichiers existants sont couramment écrasés (par exemple, ceux qui utilisent la fonctionnalité de bibliothèque de bandes virtuelles), cette figure peut être supérieure à la taille logique des fichiers correspondants.

L’acquisition de données de « mauvaise qualité » peut-elle entraîner une dégradation du taux de compression global ?

Oui : pour qu’un DDR atteigne un bon taux de compression global des données acquises, il doit être en mesure de dédupliquer et de compresser ces données. Il existe différents types de données qui peuvent empêcher cela, comme indiqué ci-dessous :

données précompressées/pré-chiffrées :

il s’agit de types de données qui sont compressés ou chiffrés sur le système client ou par l’application de sauvegarde. Cela peut également inclure des fichiers spécifiques à l’application qui sont compressés ou chiffrés par conception (par exemple, des fichiers multimédias) et des fichiers de base de données qui sont compressés, chiffrés ou intégrés des objets binaires tels que des fichiers multimédias.

En raison de la façon dont l’algorithme de compression ou de chiffrement fonctionne, une modification relativement faible des données sous-jacentes d’un fichier entraîne des modifications à l’échelle du fichier. Par exemple, un client peut contenir un fichier chiffré de 100 Mo au sein duquel 10 Ko sont modifiés. En règle générale, le fichier qui en résulte est identique avant et après la modification, à l’exception de la section 10 Ko qui a été modifiée. Lorsque le chiffrement est utilisé, même si seulement 10 Ko de données non chiffrées ont changé avant et après la modification, l’algorithme de chiffrement entraîne la modification de l’intégralité du contenu du fichier.

Lorsque ces données sont régulièrement modifiées et envoyées régulièrement à un DDR, cet effet d’entraînement fait que chaque génération de fichier est différente des générations précédentes du même fichier. Par conséquent, chaque génération contient un ensemble unique de segments (et d’empreintes digitales de segment), ce qui indique un taux de déduplication médiocre.

Notez également qu’au lieu de fichiers précompressés, il est peu probable que l’algorithme lz soit en mesure de compresser davantage les données du segment constitutif afin que les données ne puissent pas être compressées avant d’être écrites sur le disque.

En règle générale, la précompression/le pré-chiffrement entraîne les causes suivantes :

• Données pré-chiffrées : Taux de déduplication médiocre mais taux de compression acceptable
• Données précompressées : Taux de déduplication médiocre et taux de compression médiocre

Lorsque les mêmes données précompressées/pré-chiffrées (qui ne sont pas modifiées) sont acquises par un DDR plusieurs fois, le taux de déduplication des données s’améliore, car, malgré l’utilisation d’algorithmes de compression ou de chiffrement, un ensemble similaire de segments (et d’empreintes digitales de segment) est observé lors de chaque sauvegarde.

Dans la mesure du possible, les données envoyées à un DDR ne doivent pas être chiffrées ou compressées. Cela peut nécessiter la désactivation du chiffrement ou de la compression sur le client final ou dans l’application de sauvegarde correspondante.

Pour obtenir de l’aide sur la vérification, la modification des paramètres de chiffrement ou de compression au sein d’une sauvegarde, d’une application client ou d’un système d’exploitation, contactez le fournisseur de support approprié.

Fichiers multimédias :

Certains types de fichiers contiennent des données précompressées ou pré-chiffrées par conception. Par exemple :

• Fichiers PDF
• Certains fichiers audio (mp3, wma, ogg, etc.)
• Fichiers vidéo (avi, mkv, etc.)
• Fichiers image (png, bmp, jpeg, etc.)
• Fichiers spécifiques à l’application (Microsoft Office, Open Office, Libre Office, etc.)

Les données contenues dans les fichiers sont compressées ou chiffrées par le codec du fichier et, par conséquent, entraînent les mêmes problèmes lors de l’acquisition sur un DDR, comme décrit ci-dessus pour les données précompressées ou préencryptées.

Fichiers dont l’unicité est élevée :

L’obtention d’un bon taux de déduplication dépend du fait que la DDR voit le même ensemble de segments (et d’empreintes digitales de segment) plusieurs fois. Toutefois, certains types de données contiennent uniquement des données transactionnelles uniques qui, par conception, contiennent des données « uniques ».

Si ces fichiers sont envoyés à un DDR, chaque génération de sauvegarde contient un ensemble unique de segments ou d’empreintes digitales de segment. Par conséquent, le taux de déduplication est dégradé.

Voici quelques exemples de fichiers :

• Logs des transactions de base de données (par exemple, les logs d’archive Oracle).
• Fichiers log des transactions Microsoft Exchange

La première sauvegarde d’un « nouveau » client vers un DDR peut également provoquer ce problème (étant donné que les données n’ont pas été détectées auparavant par le DDR, les segments ou empreintes de segment correspondants dans la sauvegarde sont donc uniques). Au fil du temps, cependant, à mesure que les générations futures de la même sauvegarde sont envoyées à la DDR, le taux de déduplication des sauvegardes s’améliore à mesure que moins de segments de chaque nouvelle sauvegarde sont uniques. Pour cette raison, on s’attend à ce que le taux global de déduplication ou de compression sur un DDR nouvellement installé recevant principalement de nouvelles sauvegardes soit dégradé, mais s’améliore au fil du temps.

Fichiers de petite taille :

Les petits fichiers entraînent divers problèmes lorsqu’ils sont écrits dans une DDR. Celles-ci incluent :

• Bloat de métadonnées : le DDR commence à contenir une quantité plus élevée que prévu de métadonnées de fichier par rapport aux données physiques.
• Utilisation médiocre des conteneurs : par conception (en raison de la mise en page des segments informés du flux Data Domain ou de l’architecture SISL , au-delà du périmètre de ce document), un conteneur de 4,5 Mo sur disque ne contient que les données d’un seul fichier. Par conséquent, la sauvegarde d’un seul fichier de 10 Ko, par exemple, entraîne l’écriture d’au moins un conteneur complet de 4,5 Mo pour ce fichier. Cela peut signifier que, pour ces fichiers, le DDR utilise beaucoup plus d’espace postcompressé (physique) que la quantité correspondante de données précompressées (logiques) sauvegardées, ce qui entraîne un taux de compression global négatif.
• Taux de déduplication médiocre : les fichiers dont la taille est inférieure à 4 Ko (taille de segment minimale prise en charge sur un DDR) se composent d’un seul segment rembourré à 4 Ko. Ces segments ne sont pas dédupliqués, mais sont écrits directement sur le disque. Cela peut entraîner le DDR à contenir plusieurs copies du même segment (considérés comme des segments dupliqués).
• Mauvaises performances de sauvegarde, de restauration ou de nettoyage : il existe de grands temps système lors de la sauvegarde, de la restauration ou du nettoyage lors du passage d’un fichier à l’autre (car le contexte des métadonnées utilisées doit être commuté).

Découvrez les détails suivants :

• L’impact sur les performances de nettoyage lors de l’utilisation de petits fichiers a été atténué, dans une certaine mesure, par l’introduction du nettoyage physique ou de la récupération d’espace dans DDOS 5.5 et versions ultérieures.
• Le nettoyage tente d’annuler le mauvais taux d’utilisation des conteneurs en agrégeant les données des conteneurs à faible utilisation dans des conteneurs plus étroitement emballés au cours de la phase de copie.
• Le nettoyage tente de supprimer un nombre excessif de segments dupliqués au cours de la phase de copie.

Malgré les éléments ci-dessus, l’utilisation d’un grand nombre de petits fichiers ou de charges applicatives composées principalement de petits fichiers doit être évitée. Il est préférable de combiner un grand nombre de petits fichiers dans une seule archive non compressée/non chiffrée avant la sauvegarde que d’envoyer les petits fichiers au DDR dans leur état natif. Par exemple, il est préférable de sauvegarder un seul fichier de 10 Go contenant 1048576 fichiers individuels de 10 Ko que tous les fichiers 1048576 individuellement.

Multiplexage excessif par les applications de sauvegarde :

Les applications de sauvegarde peuvent être configurées pour effectuer le multiplexage des données entre les flux envoyés au périphérique de sauvegarde. Il s’agit des données des flux d’entrée (autrement dit, des clients différents) qui sont envoyées dans un seul flux vers le périphérique de sauvegarde. Cette fonctionnalité est principalement utilisée lors de l’écriture sur des unités de bande physiques comme suit :

• Un périphérique de bande physique ne peut prendre en charge qu’un seul flux d’écriture entrant.
• L’application de sauvegarde doit maintenir un débit suffisant pour le périphérique de bande afin d’empêcher le démarrage, l’arrêt ou le rembobinage de la bande (également connu sous le nom de shoe-shoe). Cela est plus facile si le flux acheminé vers le périphérique de bande contient des données lues à partir de plusieurs clients.

Toutefois, dans le cas d’un DDR, un seul fichier de la DDR contient des données provenant de plusieurs clients entrelacés dans des tailles de fragments ou d’ordre arbitraires. Cela peut entraîner un taux de déduplication dégradé, car la DDR peut ne pas être en mesure de remarquer avec précision les segments en double de chaque génération de sauvegarde de clients donnés. En général, plus la granularité du multiplexage est faible, plus le taux d’impact sur la déduplication est faible.

En outre, les performances de restauration peuvent être médiocres, car pour restaurer des données de certains clients, la DDR doit lire de nombreux fichiers ou conteneurs lorsque la plupart des données contenues dans les fichiers ou les conteneurs sont superflues en ce qui concerne les sauvegardes d’autres clients.

Les applications de sauvegarde ne doivent pas utiliser le multiplexage lors de l’écriture sur un DDR, car les DDR prennent en charge un nombre de flux entrants plus élevé que les unités de bande physiques, chaque flux étant en mesure d’écrire à une vitesse variable. Par conséquent, le multiplexage par les applications de sauvegarde doit être désactivé. Si les performances de sauvegarde sont affectées après la désactivation du multiplexage, procédez comme suit :

• Les applications de sauvegarde utilisant CIFS, NFS ou OST (DDBoost) doivent augmenter leur nombre de flux d’écriture (afin que davantage de fichiers puissent être écrits en parallèle sur la DDR).
• Les environnements utilisant la VTL doivent ajouter des disques supplémentaires à la DDR, car chaque disque permet la prise en charge d’un flux d’écriture parallèle supplémentaire.

Si une assistance est requise pour désactiver le multiplexage ou si vous souhaitez discuter de la configuration de multiplexage recommandée pour une application de sauvegarde spécifique, contactez votre fournisseur de support contractuel.

Applications de sauvegarde insérant un nombre excessif de marqueurs de bande :

Certaines applications de sauvegarde peuvent insérer des structures de données répétées dans un flux de sauvegarde appelé « marqueurs ». Les marqueurs ne représentent pas les données physiques au sein de la sauvegarde, mais sont utilisés en tant que système d’indexation ou de positionnement par l’application de sauvegarde.

Dans certains cas, l’inclusion de marqueurs dans un flux de sauvegarde peut dégrader le taux de déduplication, par exemple :

• Lors de la première génération d’une sauvegarde, il y avait 12 Ko de données contiguës, ce qui a été reconnu par la DDR en tant que segment unique.
• Toutefois, dans la deuxième génération de la sauvegarde, les mêmes 12 Ko de données sont divisés par l’inclusion d’un marqueur de sauvegarde qui peut être représenté par 6 Ko de données, marqueur de sauvegarde, 6 Ko de données.
• Par conséquent, les segments créés lors de la deuxième génération de la sauvegarde ne correspondent pas à ceux générés lors de la première génération de la sauvegarde. Par conséquent, ils ne sont pas dédupliqués correctement.

Plus les marqueurs sont bien espacés, plus l’impact sur le taux de déduplication est faible (par exemple, une application de sauvegarde insérant des marqueurs tous les 32 Ko entraîne plus de problèmes qu’une application de sauvegarde insérant des marqueurs tous les 1 Mo).

Pour éviter ce problème, la DDR utilise la technologie de reconnaissance des marqueurs qui permet d’effectuer les opérations suivantes :

• Sauvegardez les marqueurs à supprimer de manière transparente du flux de sauvegarde lors de l’acquisition de la sauvegarde.
• Sauvegarder les marqueurs à réinsérer dans le flux de sauvegarde lors de la restauration de la sauvegarde

Cela permet d’éviter la fragmentation des données ou des segments par marqueurs de sauvegarde et améliore le taux de déduplication des sauvegardes correspondantes.

Toutefois, pour tirer pleinement parti de cette technologie, il est important que le DDR puisse reconnaître correctement les marqueurs insérés dans les flux de sauvegarde. La DDR recherche des marqueurs en fonction du paramètre de l’option « marker type », par exemple :

SE@DDVE60_JF## filesys option show
Option Value
-------------------------------- --------
...
Type de marqueur automatique
...


-------------------------------- --------En général, ce paramètre doit être défini sur « auto », car cela permet à la DDR de correspondre automatiquement aux types de marqueurs les plus courants. Si le système ingère des données à partir d’une seule application de sauvegarde qui insère des marqueurs, il peut y avoir un avantage en matière de performances en spécifiant un type de marqueur spécifique : #

filesys option set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 | fdr1 | hpdp1 | besr1 | ssrt1 | ism1 | bti1| none}

Voir cela :

• Tout avantage pour les performances de la sélection d’un type de marqueur spécifique est susceptible d’être minime.
• La sélection d’un type de marqueur incorrect peut entraîner une dégradation significative des performances de sauvegarde ou de restauration et du taux de déduplication.

Par conséquent, Data Domain recommande généralement de laisser le type de marqueur défini sur « auto ». Pour plus d’informations sur la modification du type de marqueur, contactez votre fournisseur de support contractuel.

Pour les systèmes qui ingèrent des données à partir d’applications qui utilisent des marqueurs de sauvegarde, mais qui ne sont pas reconnus par la technologie de gestion automatisée des marqueurs (comme les produits du logiciel BridgeHead), contactez votre fournisseur de support contractuel qui peut ensuite travailler avec le support Data Domain pour déterminer les paramètres requis sur la DDR pour détecter le marqueur non standard.

Indications de données de « mauvaise qualité » reçues par un DDR :

Le tableau suivant répertorie les taux de déduplication et de compression attendus pour les différents types de données répertoriés ci-dessus. Cette liste n’est pas exhaustive et il peut y avoir des variations dans les chiffres exacts qui sont visibles sur un système donné en raison de la charge applicative ou des données acquises par la DDR :
 

Compression globale	Compression locale	Cause probable
Faible (1x - 4x)	Faible (1 x - 1,5 x)	Données précompressées ou chiffrées
Faible (1x - 2x)	Élevé (>x 2)	Données uniques mais compressibles, telles que les logs d’archivage de base de données
Faible (2x - 5x)	Élevé (>x 1,5)	Marqueurs non détectés, taux de modification des données élevé ou multiplexage de flux.
Élevé (>x 10)	Faible (<x 1,5)	Sauvegardes des mêmes données compressées ou chiffrées. C’est rare.

Y a-t-il certains facteurs sur un DDR qui peuvent avoir un impact sur le taux de déduplication global ?

Oui : plusieurs facteurs peuvent entraîner la conservation des données anciennes/superflous sur un disque sur un DDR, ce qui entraîne une augmentation de l’espace disque postcompressé (physique) et une baisse du taux de compression global. Ces facteurs sont abordés ci-dessous.

Échec de l’exécution régulière du nettoyage du système de fichiers :

Le nettoyage du système de fichiers est le seul moyen de supprimer physiquement les données anciennes/superflous sur le disque qui ne sont plus référencées par les fichiers de la DDR. Par conséquent, un utilisateur peut supprimer plusieurs fichiers du système (ce qui entraîne une baisse de l’utilisation précompressée) mais pas s’exécuter proprement (ce qui laisse une utilisation postcompressée/physique élevée). Cela entraînerait une baisse du taux de compression global.

Data Domain recommande de planifier l’exécution du nettoyage à intervalles réguliers comme suit :

• DDR normal : Une fois par semaine
• DDR utilisant extended retention : Une fois toutes les deux semaines

Le nettoyage ne doit pas être exécuté plus d’une fois par semaine, car cela peut entraîner des problèmes de fragmentation des données sur le disque qui se manifeste par des performances de restauration/réplication médiocres.

Nombre excessif d’anciens snapshots sur le système :

Les DDR peuvent créer des snapshots mtree qui représentent le contenu d’une structure mtree au moment de la création du snapshot. Notez toutefois que le fait de laisser d’anciens snapshots sur un système peut entraîner une augmentation de l’utilisation postcompressée/physique, entraînant une baisse du taux de compression global. Par exemple :

• Une structure mtree contient de nombreux fichiers (l’utilisation précompressée est donc élevée).
• Un snapshot de la structure mtree est créé.
• De nombreux fichiers sont supprimés (ce qui entraîne une baisse de l’utilisation précompressée).
• Le nettoyage du système de fichiers est exécuté : notez toutefois que l’espace disque dur minimal est libéré, car une copie des fichiers supprimés reste dans le snapshot mtree, ce qui signifie que les données référencées par ces fichiers ne peuvent pas être supprimées du disque.
• Par conséquent, l’utilisation postcompressée/physique reste élevée

Data Domain recommande que si des snapshots mtree sont utilisés (par exemple, pour la restauration à partir d’une suppression accidentelle des données), ils sont gérés à l’aide de plannings de snapshots automatisés de sorte que les snapshots soient créés à intervalles réguliers avec une période d’expiration définie (durée avant la suppression automatique du snapshot). En outre, la période d’expiration doit être aussi courte que possible (toutefois, cela peut évidemment dépendre du cas d’utilisation des snapshots ou du niveau de protection que ces snapshots fournissent). Cela empêche l’accumulation d’anciens snapshots avec une longue période d’expiration.

Vous trouverez plus d’informations sur l’utilisation des snapshots et des plannings de snapshots dans l’article suivant : Data Domain - Gestion des planifications de snapshots

Décalage de réplication excessif :

La réplication Data Domain native utilise un log de réplication ou des snapshots mtree (en fonction du type de réplication) pour suivre les fichiers ou les données en attente de réplication vers un DDR distant. Le décalage de réplication est le concept du réplica qui suit les modifications apportées au DDR source. Cela peut se produire en raison de divers facteurs, notamment :

• Désactivation des contextes de réplication
• Bande passante réseau insuffisante entre les DDR
• Déconnexions fréquentes du réseau.

Un décalage de réplication important peut entraîner la poursuite du journal de réplication à contenir des références aux fichiers qui ont été supprimés sur le DDR source ou des snapshots mtree anciens ou obsolètes sur les DDR source et cible. Comme décrit ci-dessus, les données référencées par ces snapshots (ou le log de réplication) ne peuvent pas être physiquement supprimées du disque sur le DDR, même si les fichiers correspondants ont été supprimés du système. Cela peut entraîner une augmentation de l’utilisation postcompressée ou physique de la DDR, ce qui entraîne une dégradation du taux de déduplication.

Si les DDR sont victimes d’une utilisation élevée, et cela est censé être dû à un décalage de réplication, contactez votre fournisseur de support contractuel pour obtenir de l’aide.

Y a-t-il des modifications de configuration ou certains facteurs sur un DDR qui peuvent augmenter le taux de compression global ?

Oui : la suppression ou la résolution des problèmes abordés précédemment dans ce document devrait permettre à un DDR d’afficher un taux de compression global amélioré au fil du temps. Il existe également différents facteurs ou charges de travail sur un DDR, ce qui peut entraîner une augmentation du taux de déduplication. Il s’agit généralement des éléments suivants :

• Réduction de l’espace disque dur utilisé par les fichiers sur le DDR (par exemple, augmentation de l’agressivité de l’algorithme de compression utilisé par le DDR)
• Augmentation soudaine de la quantité de données précompressées (logiques) sur la DDR sans augmentation correspondante de l’utilisation postcompressée/physique

Modification de l’algorithme de compression :

Par défaut, les DDR compressent les données écrites sur le disque à l’aide de l’algorithme lz . Comme mentionné précédemment, lz est utilisé car il présente des surcharges relativement faibles en termes de CPU requis pour la compression ou la décompression, mais montre une efficacité raisonnable dans la réduction de la taille des données.

Il est possible d’augmenter l’agressivité de l’algorithme de compression afin d’économiser davantage sur l’utilisation postcompressée ou sur le disque dur (et donc d’améliorer le taux de compression global). Les algorithmes de compression pris en charge, par ordre d’efficacité (de faible à élevé), sont les suivants :

• Lz
• gzfast
• Gz

Une comparaison générale de chaque algorithme est la suivante :

• Lz par rapport à gzfast offre une compression environ 15 % supérieure et consomme 2 processeurs.
• Lz par rapport à gz offre environ 30 % d’amélioration de la compression et consomme 5 processeurs.
• gzfast par rapport à gz offre une meilleure compression d’environ 10 à 15 %.

Il est également possible de désactiver complètement la compression (spécifiez un algorithme none), mais cela n’est pas pris en charge pour une utilisation sur les systèmes clients et est destiné aux tests internes uniquement.

Selon le tableau ci-dessus, plus l’algorithme de compression est agressif, plus le nombre de CPU requis lors de la compression ou de la décompression des données est élevé. Pour cette raison, les modifications apportées à un algorithme plus agressif ne doivent être apportées que sur les systèmes qui sont légèrement chargés dans des charges applicatives normales. La modification de l’algorithme sur les systèmes fortement chargés peut entraîner une dégradation extrême des performances de sauvegarde ou de restauration et un fonctionnement inattendu ou des redémarrages possibles du système de fichiers (entraînant une panne de la DDR).

Pour plus d’informations sur la modification du type de compression, reportez-vous à l’article suivant : Impact sur les performances du nettoyage et du système Data Domain de la conversion en compression

GZEn raison de l’impact potentiel de la modification de l’algorithme de compression, il est recommandé aux clients intéressés de le faire de contacter leur fournisseur de support contractuel pour discuter plus en détail de la modification avant de continuer.

Utilisation de fastCopy du système de fichiers :

Les DDR permettent d’utiliser la commande « file system fastcopy » pour copier rapidement un fichier (ou une arborescence de répertoires). Cette fonctionnalité crée un fichier en clonant les métadonnées d’un fichier existant (ou d’un groupe de fichiers) afin que, bien que les nouveaux fichiers ne soient pas physiquement connectés au fichier d’origine, ils référencent exactement les mêmes données sur le disque que le fichier d’origine. Cela signifie que, quelle que soit la taille du fichier d’origine, le nouveau fichier consomme peu d’espace sur le disque (car il se déduplique parfaitement par rapport aux données existantes).

Le résultat de ce comportement est que lorsque fastcopy du système de fichiers est utilisé, la taille (logique) précompressée des données sur le DDR augmente rapidement, mais l’utilisation postcompressée/physique de la DDR reste statique.

Par exemple, la DDR suivante a une utilisation comme suit (indiquant un taux de compression global d’environ 1,8x) :

Niveau actif :
taille de ressource Gio Utilisé GiB Utilisation Gio Utile% Gio nettoyable*
---------------- -------- -------- --------- ---- --------------
/données : pré-compression - 12.0 - - -
/données : post-compression 71.5 6.8 64.7 10 % 0.0
/ddvar 49.2 1.1 45,6 2 % -
/ddvar/core 158.5 0.2 150.2 0 % -
---------------- -------- -------- --------- ---- --------------

It contient un fichier volumineux (/data/col1/backup/testfile) :

!!! DDVE60_JF VOS DONNÉES SONT EN DANGER !!! # ls -al /data/col1/backup/testfile-rw-r
--- 1 root 3221225472 Jul 29 04 :20 /data/col1/backup/testfile

Le fichier est rapidementcopié plusieurs fois :

sysadmin@DDVE60_JF# filesys source fastcopy /data/col1/backup/testfile destination /data/col1/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data /col1/backup/testfile destination /data/col1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy3

Cela entraîne une augmentation de l’utilisation précompressée pour une faible modification de l’utilisation postcompressée :Niveau actif :

Taille des ressources Gio Utilisé Gio Utilisé GiB Utilisation% Gio nettoyable*
---------------- -------- -------- --------- ---- --------------
/données : avant compression - 21,0 - -
/données : post-rém 71,5 6,8 64,7 10 % 0,0

/ddvar 49,2 1,1 45,6 2 % -
/ddvar/core 158,5 0,2 150,2 0 % -
---------------- -------- -------- --------- ---- --------------

As, le DDR affiche désormais un taux de compression global d’environ 3,1x.

Comme mentionné ci-dessus, les statistiques de compression des copies montrent qu’elles se dédupliquent parfaitement :

sysadmin@DDVE60_JF# filesys show compression /data/col1/backup/testfile_copy1
Total de fichiers : 1;  octets/storage_used : 21331976.1
Octets d’origine :        3 242 460 364
compressés globalement :                    0
Compressé localement :                    0
Métadonnées :                  152

La fonctionnalité FastCopy ne peut pas être utilisée pour améliorer le taux de compression global en réduisant l’utilisation physique de la DDR, mais elle peut être à l’origine d’un taux de compression global élevé (en particulier dans les environnements qui utilisent intensivement FastCopy comme Avamar 6.x).