Processus de récupération d’espace Avamar - Partie 2 : Croquer

Qu’est-ce que le « crunching » dans Avamar ?

Garbage Collection identifie les données qui ne sont plus référencées par les sauvegardes.
Le descripteur d’en-tête de fragment est modifié pour indiquer quels fragments doivent être supprimés. Les bandes de données, qui contiennent ces fragments, ne sont pas modifiées.
La suppression de ces fragments se produit en tant qu’effet secondaire de l’opération de traitement.

Le calcul est une opération de maintenance d’Avamar qui modifie les bandes collectées par garbage afin de rendre contiguës l’espace libre au sein de ces bandes. 
En manipulant les bandes pour que leur espace libre soit contigu, Avamar réutilise efficacement l’espace pour les données de sauvegarde entrantes.

Pensez aux calculs de la même manière que la défragmentation classique des disques durs. 
Les données doivent être déplacées d’un endroit à un autre afin que les conteneurs de données puissent être réutilisés plus efficacement.

Les utilitaires de défragmentation de disque déplacent les éléments connexes des données vers les parties adjacentes d’un disque dur rotatif pour accélérer les temps d’accès séquentiels.
Toutefois, le calcul déplace les données vers le bas de la bande afin de créer de l’espace pour les nouveaux fragments entrants.

Analogie:

Imaginez un bus avec une porte d’entrée avant et aucune porte de sortie. Les personnes (fragments) entrent dans le bus à l’aide de la porte avant. 
Il s’agit d’un bus spécial dans lequel les gens ne peuvent s’éloigner qu’à l’aide de la technologie Star Ace « Beam me up Scotty ». 
Le bus démarre complètement. 
Une fois que plusieurs personnes ont été dématérialisées, le bus a de l’espace pour plus de passagers.
Personne d’autre ne peut s’adapter tant que la crowd n’a pas été déplacée hors de l’entrée. C’est-à-dire « inséré » à l’arrière du bus pour faire de l’espace près de la porte avant.

Pourquoi le calcul est important :

Nous discutons de ce qui se passe lorsque les données de sauvegarde sont écrites sur Avamar. Cela explique pourquoi le calcul est important.

Pour préparer l’acceptation des données de sauvegarde, Avamar sélectionne la bande sur chaque nœud de données qui dispose de l’espace libre le plus contigu. La bande est marquée comme étant la bande active. 
Toutes les nouvelles données de sauvegarde entrantes sont ajoutées à la bande active. 
Lorsque la bande devient pleine, la bande suivante, la bande la moins complète, est marquée comme la bande active.

Imaginez un système où les calculs sont insuffisants.
Une bande « torsaquée » (récupérée à la mémoire, mais qui n’a pas encore fait l’objet de traitements) peut être relativement vide. 
Cette bande relativement vide ne serait pas sélectionnée en tant que bande active s’il existe une autre bande qui a plus d’espace libre contigu. 

Dans le schéma ci-dessous, les deux bandes du schéma ont été collectées en garbage, mais seule la bande de données 2 a été corrigée,

Même si la bande de données 1 est plus utile, la bande 2 dispose d’un espace contigu plus utile. 
Avamar sélectionne la bande 2 en tant que bande active. 

À mesure que l’utilisation du stockage Avamar augmente, la bande active est choisie à partir d’un pool de bandes de plus en plus complètes.

Si le calcul est en retard, la réutilisation des bandes est inefficace. 
Des bandes supplémentaires sont nécessaires pour capturer les données entrantes pendant une journée moyenne, même si cette quantité de données n’est pas modifiée. 
L’utilisation de bandes supplémentaires pour capturer les données entraîne une surcharge de point de contrôle plus élevée que si les bandes étaient réutilisées plus efficacement.

Pour cette raison, assurez-vous toujours qu’Avamar a la possibilité d’effectuer des calculs suffisants régulièrement.

Comment fonctionne le traitement des données ? 

Lorsque le système effectue des calculs sur une bande, il :-

• Lit les données du fichier de bande du répertoire cur dans la mémoire.
• Détermine les fragments référencés par l’en-tête de fragment.
• Réécrit le fichier de bande et l’en-tête de fragment sur le disque. Le fichier de bande est renseigné uniquement avec les éléments référencés par l’en-tête de fragment.

La modification du fichier de bande rompt son lien dur, augmentant ainsi l’utilisation du système de fichiers. 
À partir d’Avamar version 5.0 et ultérieure, les bandes restent à leur taille maximale après le traitement. Cela permet d’éviter la fragmentation du système de fichiers au fil du temps.

Quand les problèmes se produisent-ils ?

Traitement asynchrone : La valeur par défaut et la méthode préférée d’exécution du calcul.

Le traitement asynchrone s’exécute pendant la dernière partie de la « fenêtre d’interruption », après l’expiration du nettoyage de la mémoire, et uniquement dans les circonstances suivantes.

• Si le paramètre asynccrunching est défini sur true.
• S’il existe des bandes inscriptibles*.
• Et si nous n’avons pas atteint notre objectif de calcul ou notre limite quotidienne*.
• ET si le système est inactif* (aucune sauvegarde ou autre maintenance en cours).
• Si le système est accessible en écriture et que disknoflush n’a pas été atteint.

Le traitement asynchrone est une opération préventive. 
Il utilise du temps et des ressources dédiés pour préparer les bandes en avance sur la fenêtre de sauvegarde. 
Reportez-vous au diagramme ci-joint « black-window.jpg » qui illustre cela.

Quelle est la quantité de travail réalisée par le traitement des données ?

La préparation préalable des bandes à utiliser pendant la fenêtre de coupure permet à Avamar d’acquérir des données aussi rapidement que possible pendant le planning de sauvegarde. 
Le fait de faire des calculs modifie le contenu d’une bande. De nombreux calculs provoquent de grandes différences avec les données stockées dans le répertoire « cur ». 
Cela se traduit par une augmentation de la surcharge des points de contrôle et une consommation plus élevée d’espace dans les données/ partitions des nœuds de données.

Avamar prévoit le nombre de bandes qui doivent être préparées afin de prendre en charge la quantité de données entrantes prévues pour le jour suivant. 
Les calculs sont basés sur la moyenne mobile des jours N précédents (où N est jusqu’à 10 ou 14, par exemple). 
Ce mécanisme d’auto-réglage permet à Avamar d’analyser juste suffisamment de bandes pour que les sauvegardes s’exécutent de manière optimale sans entraîner de surcharge de point de contrôle inutile. 

Nous pouvons maintenant comprendre que si le taux de modification du système augmente soudainement, Avamar met plusieurs jours à adopter progressivement une limite de calcul accrue.

Si le traitement asynchrone ne prépare pas suffisamment de bandes, cela est pris en charge par le traitement synchrone.

Calcul synchrone :

Si le calcul asynchrone n’est pas en mesure de pré-préparer suffisamment de bandes, ou si le paramètre asynchrone est défini sur false, le calcul s’exécute de manière synchrone avec les sauvegardes. 
Également appelé « traitement à la demande », ce mode de traitement s’exécute en cas de besoin et fonctionne sur une bande, si la bande est torsaquée et prête à devenir la bande active d’un nœud.

L’exécution synchrone des calculs avec les sauvegardes augmente la concurrence pour les ressources d’E/S de disque. 
Sur les systèmes occupés, les procédures de sauvegarde peuvent prendre plus de temps. 

Nous pouvons choisir de définir Avamar pour qu’il effectue uniquement des calculs synchrones dans les situations où un système subit une surcharge de point de contrôle élevée. Si cela est fait, informez le client pourquoi nous pensons qu’il est nécessaire et expliquez le compromis.

A Récapitulatif des deux modes de traitement :

le traitement asynchrone :

• Le paramètre du serveur Avamar est asynccrunching=true.
• Performances de sauvegarde plus élevées en cas d’ingestion normale de données au cours d’une journée normale.
• Surcharge de point de contrôle plus élevée.
• Mode de fonctionnement par défaut.
• Peut être désactivé pour réduire la surcharge des points de contrôle dans les situations de haute capacité du système d’exploitation.

Calcul synchrone :

• Le paramètre du serveur Avamar est asynccrunching=false
• S’exécute en fonction des besoins
• Réduction des exigences relatives à la surcharge des points de contrôle
• Durées de sauvegarde potentiellement plus longues
• Pas le mode de fonctionnement par défaut

Qu’est-ce qui peut empêcher le traitement asynchrone ?

 Le paramètre de configuration asynchrone est false.

• Les sauvegardes sont en cours
• La limite quotidienne a été atteinte
• Le serveur est en lecture seule
• Le niveau d’exécution du serveur est inférieur à « admin »
• La conversion de bande est en cours
• La limite disknoflush a été atteinte
• Le serveur Avamar sur lequel il est appliqué exécute l’instance hfscheck (parfois appelée CGSAN).
• La vérification HFS démarre