Data Domain - Questions fréquentes sur la compression

S’APPLIQUE À

• Tous les DDR
• Toutes les versions

Compression : Questions fréquentes :

Idéalement, cela est vrai. En pratique, la sauvegarde complète utilise un peu plus d’espace que la sauvegarde incrémentielle pour les raisons suivantes. Ces raisons expliquent également pourquoi une sauvegarde complète sans aucune modification des données consomme quand même une quantité positive d’espace.

• Les métadonnées occupent environ 0,5 % de la taille logique de la sauvegarde. Supposons que la taille logique de la sauvegarde complète soit de 100 Go et que celle de la sauvegarde incrémentielle soit de 2 Go. Supposons également que la sauvegarde incrémentielle compresse les données à 1 Go. La sauvegarde complète nécessite alors un minimum de 1,5 Go d’espace disque.
• Le moteur de compression DD réécrira certains segments de données en doublons pour améliorer les performances. Plus la localisation des données liées aux changements est médiocre, plus le nombre de doublons écrits sera important. Les doublons sont ensuite récupérés par « filesys cleaning ». J’ai remarqué qu’environ 2 % de la taille logique étaient réécrits en double. En supposant ce niveau de doublons, la sauvegarde complète peut prendre 1 Go (données compressés) + 0,5 Go (métadonnées) + 2 Go (doublons) = 3,5 Go. La quantité de doublons écrits peut être contrôlée via un paramètre système, mais nous ne réglons généralement pas ce paramètre sur le terrain.
• La segmentation des données peut varier légèrement d’une sauvegarde à l’autre en fonction de l’ordre dans lequel le client NFS envoie les données. Cet ordre n’est pas déterministe. En général, l’algorithme de segmentation tolère les décalages et la réorganisation. Cependant, il crée également des segments « forcés », qui sont sujets à des décalages et à des réorganisations. En général, environ 0,2 % des segments sont forcés, ce qui signifie qu’une bien plus grande quantité d’espace est utilisée.

« filesys show space » fournit le taux de compression en fonction de la taille logique des données stockées et de l’espace disque utilisé au moment de l’exécution de la commande.

« filesys show compression » fournit le taux de compression en fonction de la façon dont chaque fichier a été compressé au moment de sa création.

« filesys show compression » est principalement utilisé pour la prise en charge et le débogage. En présence de suppressions de fichiers, la commande « filesys show compression » surestime le taux de compression.

Par exemple, on suppose que la première sauvegarde complète obtient une compression x2. Une sauvegarde complète ultérieure sans aucune modification des données obtient une compression x200. La première sauvegarde complète est supprimée. « filesys show space » affiche un taux de compression x2. La commande « show compression » affichera désormais un rapport de compression x200 car le seul fichier qui existe maintenant a obtenu une compression x200 lors de sa création.

Dans l’exemple donné ci-dessus, après la seconde sauvegarde, « filesys show space » montre un ratio cumulé d’à peu près x4. Le ratio cumulé s’améliorerait de manière asymptotique jusqu’à 200 fois en continuant à effectuer d’autres sauvegardes sans suppression.

Il existe d’autres différences mineures :

•  Comme elle ne tient pas compte des pertes au niveau du conteneur, la commande « filesys show compression » a tendance à surestimer encore le taux de compression
•  La commande « filesys show compression » ne prend pas en compte la suppression des doublons par compression globale, ce qui entraîne une sous-estimation du taux de compression
•  « filesys show compression » peut fournir des informations par fichier ou par répertoire, tandis que « filesys show space » est limité à l’ensemble du système
•  « filesys show compression » fournit la répartition entre la compression globale et locale, tandis que « filesys show space » ne le fait pas

Références :

• Pourquoi les taux de compression sont-ils différents pour « filesys show space » et « vtl tape show summary » ?

Le taux de compression indiqué dans « vtl tape show summary » est supposé correspondre à « filesys show compression /backup/vtc ».

Plus généralement, cette commande VTL peut recevoir un filtre facultatif pour sélectionner un sous-ensemble de cartouches de bande, et la compression est censée correspondre à « filesys show compression » sur ce sous-ensemble de cartouches.

Toutefois, en raison d’un bug dans le code de l’interface utilisateur VTL, la compression affichée dans « vtl tape show summary » est erronée. Il s’agit d’un problème connu qui est résolu dans la version 4.5.0.0.
 

• Pourquoi la commande « filesys show compression last 24 hours » ne correspond-elle pas aux attentes pour la VTL ?

Pour la VTL, la sortie de commandes telles que « filesys show compression last 24 hours » ne répond souvent pas aux attentes fondées sur d’autres sources telles que « system show performance ».

Ce problème se produit en raison d’une particularité de « filesys show compression » (fsc). En général, « filesys show compression » affiche les statistiques cumulatives dans les fichiers sélectionnés. Le qualificateur « last 24 hours » sélectionne les fichiers qui ont été mis à jour au cours des dernières 24 heures. Les statistiques continuent de s’accumuler depuis que le fichier a été créé ou tronqué à une taille nulle. En conséquence, si un fichier a été ajouté au cours des dernières 24 heures, « filesys show compression last 24 hours » affichera ses statistiques cumulées avant la dernière période de 24 heures.

Dans les environnements non VTL, les fichiers de sauvegarde ne sont écrits qu’une seule fois, de sorte qu’il n’y a pas beaucoup d’écart entre les fichiers mis à jour et les fichiers créés. Avec la VTL, les sauvegardes peuvent être ajoutées aux fichiers de bande existants. Par exemple, prenons une bande d’une capacité de 100 Go remplie jusqu’à 50 Go. Si 10 Go de données sont ajoutés à cette bande au cours des dernières 24 heures, « filesys show compression last 24 hours » indique que la quantité d’octets d’origine du fichier écrits est égale à 60 Go.
 

• Comment le taux de compression cumulé est-il calculé ?

Les taux de compression individuels ne s’additionnent pas de manière linéaire.

Supposons que la compression sur la première sauvegarde complète est de x2 et celle sur la deuxième sauvegarde complète est de x20. La compression cumulée n’est pas (2+20)/2 ou x11, mais 2/(1/2+1/20) ou x3,64.

En général, les taux de compression inférieurs ont plus d’impact que les taux de compression supérieurs sur le taux de compression cumulé.

Supposons que la énième sauvegarde présente une taille logique si et un taux de compression ci. Dans ce cas particulier, on peut déterminer le taux de compression cumulée pour k sauvegardes en procédant ainsi :

C = (taille logique totale)/(espace total utilisé)
taille logique totale = S1 + s2 + .. + sk
espace total utilisé = s1/c1 + s2/c2 + ... + sk/ck

Souvent, les tailles logiques sont à peu près les mêmes. Dans ce cas, le calcul ci-dessus se simplifie comme suit :

Par exemple, si la première sauvegarde complète est compressée par 3, que chaque sauvegarde complète suivante est compressée par 30 et que la période de rétention est de 30 jours, l’utilisateur voit une compression cumulée de 30/(1/3+29/30), soit une compression x23.
 

• Comment fonctionne la compression Data Domain ?

Cette question est abordée en détail dans un autre article de la base de connaissances, « Data Domain : Comprendre la compression Data Domain
 

• Le Data Domain prend-il en charge le multiplexage ? ​​​​​​​

Les données multiplexées à partir de l’application de sauvegarde entraînent une déduplication globale très médiocre. Pour plus d’informations, voir l’article connexe Data Domain : Multiplexage dans le logiciel de sauvegarde « Multiplexing in Backup Software Is Not Supported ». 
 

• Avec une réplication de répertoire 1 à 1, pourquoi le réplica affiche-t-il une meilleure compression globale ?

En général, cela est dû à des variations dans le niveau des segments dupliqués écrits sur le système :

• Les données stockées à la source ont été dédupliquées une fois, par rapport aux données précédentes stockées à la source.
• Les données envoyées sur le réseau ont été dédupliquées une fois, par rapport aux données stockées sur le réplica.
• Les données stockées sur la réplique ont été dédupliquées deux fois, une première fois lorsque les données ont été envoyées sur le câble, et une seconde fois lorsque les données reçues sont écrites sur le réplica.

Le processus de déduplication laisse quelques doublons, et donc les données qui ont été dédupliquées plusieurs fois ont moins de doublons. Les données stockées à la source et envoyées sur le réseau sont dédupliquées une seule fois. Elles sont donc à peu près identiques, en supposant que les données stockées à la source sont similaires à celles stockées sur le réplica. Les données stockées sur le réplica sont dédupliquées deux fois, de sorte qu’elles sont mieux compressées.

Le nettoyage du système de fichiers supprime la plupart des doublons. Ainsi, après avoir effectué un nettoyage sur la source et le réplica, la quantité de données stockée devrait être approximativement égale.

• Quelle est la modification de la compression lors de l’utilisation des paramètres de compression locaux lz, gzfast et gz ?

Définir la compression pour l’option filesys sur {none | lz | gzfast | gz}
 

Avertissement : Avant de modifier le type de compression locale, le système de fichiers doit être arrêté. Il peut ensuite être redémarré immédiatement après que l’option de compression a été définie.

En général, l’ordre de compression est le suivant :

La différence est à peu près la suivante :

• lz à gzfast permet une compression environ 15 % supérieure et consomme deux fois plus de ressources processeur
• Lz à gz permet une compression environ 30 % supérieure et consomme cinq fois plus de ressources processeur
• gzfast à gz permet une compression environ 10 à 15 % supérieure

Veuillez noter que la modification de la compression locale affecte d’abord les nouvelles données écrites dans le Data Domain Restorer après la modification. Les anciennes données conservent leur format de compression précédent jusqu’au cycle de nettoyage suivant. Lors du cycle de nettoyage suivant, toutes les anciennes données seront copiées vers le nouveau format de compression. Cela entraîne une exécution beaucoup plus longue du nettoyage et une augmentation des ressources processeur nécessaires.

Si le système du client manque déjà de ressources processeur, en particulier si le client effectue simultanément une sauvegarde et une réplication, cela peut ralentir son opération de sauvegarde et/ou de réplication. Le client peut vouloir planifier explicitement une période spécifique pour effectuer cette conversion.

Références base de connaissance :

• Résolution des problèmes de migration
• Data Domain : Comprendre la compression Data Domain