Data Domain : La taille nettoyable est une estimation

Il existe souvent une confusion quant à la valeur « Gio nettoyables » présentée sur un système Data Domain et des attentes incorrectes quant à la quantité d’espace qui sera récupérée lors de l’exécution du nettoyage.

Le nombre de « Gio nettoyables » donné est purement une estimation, et il n’est pas possible d’obtenir une valeur précise de la quantité d’espace qui sera récupérée en exécutant le nettoyage, en raison des choix technologiques effectués lors du développement du système de fichiers Data Domain.

Voici une explication succincte des raisons pour lesquelles les estimations de l’espace nettoyable peuvent différer considérablement de l’espace réellement récupéré. Il existe cependant d’autres facteurs qui ne sont pas pris en compte ici, et qui peuvent faire en sorte que l’estimation et la quantité d’espace disque réellement libérée lors de l’exécution du nettoyage diffèrent considérablement
 

Lorsque des données sont ingérées par le système Data Domain, la valeur après compression est calculée et stockée sous forme de données statiques pour chaque fichier. La valeur « Nettoyable » correspond simplement à la somme de la valeur après compression de tous les fichiers supprimés depuis la dernière exécution du nettoyage DD.
 

La valeur Nettoyable devient inexacte si les segments de fichiers pour les fichiers supprimés ont été utilisés pour la déduplication des données dans d’autres fichiers qui n’ont pas été supprimés. Tant qu’il existe un seul fichier faisant référence à un segment unique existant, le processus de nettoyage DD ne prend pas en compte ces segments pour être récupérés. Ainsi, même si la post-compression d’un fichier a été ajoutée dans le compteur « Cleanable GiB » comme si tous ses segments uniques étaient sur le point d’être éliminés, certains (ou plusieurs) peuvent ne pas l’être parce qu’ils sont réutilisés par d’autres fichiers.
 

Voici un exemple plus détaillé illustrant cet effet :

Supposons que vous ayez 5 fichiers, ajoutés un par un à un à un système Data Domain, sans aucune autre donnée précédemment dessus.

Étant donné que les premiers fichiers de 100 Go contenaient toutes des données uniques, son taux de compression est de 1x (en supposant que le premier fichier n’avait aucune redondance dans le fichier lui-même). Les fichiers 2e à 5e ont pu être dédupliqués par rapport aux données du premier fichier et à chacun des fichiers plus anciens au fur et à mesure de leur ajout, chacun gagnant en plus de déduplication en raison de l’augmentation des fichiers sur lesquels la déduplication.

File 1: precomp: 100 GB postcomp: 100 GB compression ratio: 1x
File 2: precomp: 100 GB postcomp:  50 GB compression ratio: 2x
File 3: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 4: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 5: precomp: 100 GB postcomp:   1 GB compression ratio: 100x

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         500           -      -                -
/backup: post-comp      1000         201         799    20%                0
----------------   ---------   ---------   ---------   ----   --------------

Exemple 1. Statut après suppression des 3 premiers fichiers de /backup :
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         200           -      -                -
/backup: post-comp      1000         201         799    20%              175
----------------   ---------   ---------   ---------   ----   --------------

Si vous exécutez le nettoyage après cela, vous pourrez peut-être récupérer 125 points au lieu des 175 nettoyables complets. Cela est dû au fait que les 2 derniers fichiers partagent des segments avec les fichiers 1 à 3.  Le nettoyage ne permettra pas de récupérer les 50 Go d’espace restants, car ces segments sont toujours utilisés par les fichiers 3 à 5.
 

Exemple 2 : En utilisant le même point de départ que pour l’exemple 1, supposons que le fichier 1 a été supprimé, puis qu’une fastcopy est effectuée sur l’ensemble du dossier /backup (c’est-à-dire les 5 fichiers), puis que les fichiers 2 à 4 sont supprimés. 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         201         799    20%              200
----------------   ---------   ---------   ---------   ----   --------------

Le chiffre de « taille Gio » pour la pré-compression provient de (500-100)=400*2=800, ce qui donne 500 pour les 5 fichiers d’origine, la soustraction de 100 pour la suppression du fichier 1 donne 400 Gio.  Ensuite, 400 Gio multipliés par 2 en raison de la copie rapide sur les 4 fichiers restants.

Notez que l’espace post-compression utilisé est toujours le même, car une copie de fichier n’ajoute qu’une infime quantité d’espace, constituée des pointeurs de métadonnées vers les données d’origine. L’utilisation de l’espace n’a pas changé malgré la suppression du fichier 1, car un « démarrage propre du système de fichiers » n’a pas été exécuté (pour lancer le nettoyage). 
 

Après le nettoyage, nous verrons :
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         176         824    18%                0
----------------   ---------   ---------   ---------   ----   --------------

Notez que même si 200 Go ont été déclarés nettoyables, seuls 25 Go ont été réellement nettoyés. Le nombre de « Gio nettoyables » indiquait 200, car la taille de fichier « post-compression » des fichiers 1 à 4 totalisait jusqu’à 200 Go.  Seul le « Fichier 1 », qui faisait 100 Go, mais dont 75 Go étaient encore utilisés par les 4 autres fichiers (pour cause de déduplication) a été supprimé.  

Cela peut sembler étrange, puisque les fichiers « Fichier 2 » à « Fichier 4 » ont également été supprimés, mais rappelez-vous que bien que le système affiche les « Fichiers 2 » à « Fichier 4 » comme supprimés, les segments de données réels de ces fichiers n’ont pas pu être supprimés car ces fichiers ont été copiés rapidement dans un autre dossier.   Ce n’est qu’une fois que toutes les versions fastcopy ont également été supprimées que l’espace peut être entièrement récupéré par nettoyage.

Étant donné que les Gio nettoyables ne sont qu’une « estimation » et peuvent ne pas être exacts, ils peuvent même parfois refléter une taille importante ou identique à celle de la capacité physique de Data Domain.

Cela peut entraîner une confusion quant à savoir s’il faut autoriser l’exécution du nettoyage DDFS planifié ou s’exécuter manuellement si l’utilisation de l’espace DDFS est proche de 100 % en raison du fait que Gio nettoyable affiche une valeur proche ou identique à celle de « /data : post-comp ».

Pour disposer d’un moyen plus efficace et plus fiable d’estimer la quantité d’espace disque propre lors de l’exécution, à partir de DDOS 7.7.x, il est désormais possible de déterminer à partir de l’interface de ligne de commande l’espace nettoyable total réel que le prochain GC sur le niveau actif pourra récupérer. Voici un récapitulatif de l’interface de ligne de commande :
 

# filesys cleanable-space calculate
Cleanable space calculation started. Use 'filesys cleanable-space watch' to monitor progress.

Le processus effectue le même processus qu’un GC classique, en passant par les phases 1 à 4, mais en sautant la phase 5 (copie), qui est celle qui copierait efficacement les conteneurs de transfert pour récupérer l’espace disque mort. En tant que tel, il faudra autant de temps qu’un GC régulier pour terminer les phases propres 1 à 4 pour renvoyer une valeur, ce n’est donc pas quelque chose à exécuter régulièrement pour avoir une estimation mise à jour, mais seulement lorsque cela est nécessaire. En d’autres termes, « filesys cleanable-space calculate » exécutera GC dans le niveau actif en ignorant simplement la partie dans laquelle il récupère de l’espace.

Le processus peut être surveillé de la manière suivante :
 

# filesys cleanable-space watch
Beginning 'filesys cleanable-space calculation' monitoring.  Use Control-C to stop monitoring.

Cleaning: phase 1 of 4 (pre-merge)
  100.0% complete, 96233 GiB free; time: phase  0:02:07, total  0:02:07

Cleaning: phase 2 of 4 (pre-analysis)
  100.0% complete, 96233 GiB free; time: phase  0:06:51, total  0:08:59

Cleaning: phase 3 of 4 (pre-enumeration)
  100.0% complete, 96233 GiB free; time: phase  0:00:20, total  0:09:20

Cleaning: phase 4 of 4 (pre-select)
  100.0% complete, 96233 GiB free; time: phase  0:00:25, total  0:09:46

Une fois terminé, on peut accéder au résultat de mesure nettoyable :

# filesys cleanable-space status

Cleanable space on active tier is 94649698202 bytes. Last calculated on 2023/08/25 03:29:51
Cleanable space calculation finished at 2023/08/25 03:29:51.

Ici, dans l’exemple de test ci-dessus, si le DD GC doit être exécuté maintenant, cela libère 94649698202 octets. C’est 88,1 Gio alors qu’au moment du calcul, l’estimation rapportée par « df » dans le laboratoire DD utilisé était de 41,9 Gio. Bien entendu, au fur et à mesure que des modifications sont apportées au système de fichiers (nouvelles sauvegardes, suppressions, création et expiration de snapshots, etc.), le calcul est annulé.

Si nécessaire, pour arrêter le processus ci-dessus, la commande ci-dessous peut être utilisée :

# filesys cleanable-space stop

The 'filesys cleanable-space stop' command stops calculating cleanable space in the system.
Are you sure? (yes|no) [no]: yes

ok, proceeding.

# filesys cleanable-space status
Cleanable space on active tier is 2607064 bytes. Last calculated on 2021/06/27 23:23:05
Cleanable space calculation started at 2021/06/27 23:27:58 and was aborted at 2021/06/27 23:28:19.
Cleaning was aborted by user.

Notez que cette CLI s’applique uniquement au niveau actif DD. Il n’existe pas de processus équivalent pour calculer la capacité nettoyable d’une unité de Cloud DD, qui possède sa propre estimation, sous réserve des mêmes incertitudes que celles décrites ci-dessus.