Avamar v7 et versions ultérieures : garbage collection signale des « hachages ignorés » qui ne peuvent pas être nettoyés en raison de « Mappages de bits référencés de hachage » lorsque les données sont en cours d’utilisation

La fonction Hash Referenced Bit Maps est une fonctionnalité introduite avec avamar v7.x qui permet d’effectuer des sauvegardes lors de l’activité de maintenance de garbage collection (GC). 

Avant cette fonction, le nettoyage de la mémoire ne pouvait pas s’exécuter simultanément en raison de la possibilité de conflits de données. 

Au cours de la phase de nettoyage de la mémoire, la nouvelle fonctionnalité conserve des informations en mémoire sur les données qui sont ajoutées ou modifiées (une « carte des hachages référencés »). Garbage Collection vérifie ces informations pour savoir quels hachages (et les données qu’ils référencent) ne doivent pas être supprimés.  

L’une des exigences de cette fonctionnalité est que ces « mappages » nécessitent au moins 5 minutes de temps « silencieux » pendant lesquels aucune sauvegarde ne se produit afin qu’elles puissent être réinitialisées. Une fois cette réinitialisation effectuée, les données qui y ont été verrouillées peuvent être analysées au cours du cycle de garbage collection suivant, tant qu’elles restent inchangées.

Ce temps silencieux doit être pris en compte lors de la conception du planning de sauvegarde et de maintenance Avamar quotidien. 
L’incapacité des mappages à réinitialiser peut empêcher la récupération d’espace de nettoyer les données expirées.
Si la carte de hachage référencée n’a pas la possibilité de se réinitialiser, les données susceptibles d’être éligibles au retrait par garbage ne sont pas traitées et l’utilisation de la capacité peut augmenter. Si la carte ne parvient pas à se réinitialiser sur une période prolongée, le journal de nettoyage de la mémoire peut afficher une quantité croissante de « hachages ignorés ».

Les sauvegardes ont expiré, mais le nettoyage de la mémoire n’a pas restauré toutes les données éligibles à la suppression, car certaines des données étaient en cours d’utilisation à l’époque.

Pour vérifier cela, exécutez la commande ci-dessous :
la commande vide le journal de maintenance de garbage collection pendant 7 jours et l’analyse pour l’afficher.

• Combien de hachages ont été ignorés,
• Quantité de données supprimées
• Nombre de réussites de nettoyage de la mémoire
• Durée d’exécution du nettoyage de la mémoire

dumpmaintlogs --types=gc --days=7 | grep passes | cut -d ' ' -f1,10,14,15,17

2014/02/11-11:03:23.01310 skipped-hashes="3118" megabytes-recovered="120" passes="10" elapsed-time="134"
2014/02/12-11:05:33.78790 skipped-hashes="4051" megabytes-recovered="88" passes="10" elapsed-time="264"
2014/02/12-16:18:16.79236 skipped-hashes="5098" megabytes-recovered="199" passes="16" elapsed-time="268"
2014/02/12-16:28:20.35698 skipped-hashes="5099" megabytes-recovered="0" passes="1" elapsed-time="97"
2014/02/12-17:14:22.88473 skipped-hashes="5452" megabytes-recovered="26" passes="20" elapsed-time="162"
2014/02/12-20:46:06.80518 skipped-hashes="6789" megabytes-recovered="83" passes="21" elapsed-time="184"
2014/02/12-21:09:30.70374 skipped-hashes="89139" megabytes-recovered="9432" passes="26" elapsed-time="536"
2014/02/12-23:30:13.07016 skipped-hashes="96510" megabytes-recovered="604" passes="21" elapsed-time="210"
2014/02/12-23:34:15.11324 skipped-hashes="96511" megabytes-recovered="1" passes="3" elapsed-time="99"
2014/02/13-13:41:02.20624 skipped-hashes="97301" megabytes-recovered="0" passes="1" elapsed-time="81"
2014/02/14-11:03:45.31704 skipped-hashes="98220" megabytes-recovered="131" passes="2" elapsed-time="157"
2014/02/14-16:49:14.94905 skipped-hashes="98220" megabytes-recovered="67" passes="2" elapsed-time="105"
2014/02/14-21:15:27.77268 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="106"
2014/02/14-21:25:51.71154 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="101"
2014/02/14-22:07:19.81136 skipped-hashes="98229" megabytes-recovered="0" passes="1" elapsed-time="125"
2014/02/14-22:15:21.50825 skipped-hashes="98275" megabytes-recovered="1" passes="5" elapsed-time="115"
2014/02/14-22:27:13.88500 skipped-hashes="98278" megabytes-recovered="0" passes="1" elapsed-time="98"
2014/02/14-23:58:47.70116 skipped-hashes="102294" megabytes-recovered="1" passes="4" elapsed-time="110"
2014/02/15-11:02:29.45054 skipped-hashes="102538" megabytes-recovered="0" passes="1" elapsed-time="82"
2014/02/16-00:56:27.25596 skipped-hashes="0" megabytes-recovered="900395" passes="59" elapsed-time="17417"
2014/02/17-11:32:42.66479 skipped-hashes="0" megabytes-recovered="57540" passes="28" elapsed-time="1890"

Analyse :

La sortie indique que le nombre de hachages ignorés augmente au fil du temps jusqu’à ce que la carte référencée de hachage soit réinitialisée le 16 février 2014.
Nous pouvons également voir la quantité de données nettoyées « mégaoctets récupérées » après la libération des hachages et la récupération d’espace pour les données expirées.

Solution immédiate

1. Assurez-vous que les cartes peuvent se réinitialiser et permettre la réexélation de garbage collection.
2. Assurez-vous qu’il n’y a pas de sessions avtar en cours d’exécution qui ajoutent des données au système (données de sauvegarde ou de réplication entrante). Utilisez le moniteur d’activité de l’interface utilisateur et recherchez les sessions bloquées affichées uniquement à l’aide de la commande « avmaint sessions --full ».
3. Arrêtez toutes les sauvegardes et les sessions de réplication entrantes.
4. Patientez au moins cinq minutes pour laisser suffisamment de temps à la réinitialisation des mappages de bits référencés de hachage.  
5. Lorsque le GC s’exécute à nouveau, vérifiez le journal de maintenance du GC pour confirmer que skipped-hashes=0

Si skipped-hashes n’a pas été réinitialisé à zéro, travaillez avec le support pour vérifier les étapes ci-dessus. Si les rapports de nettoyage de la mémoire MSG_ERR_TRYAGAINLATER, le support peut confirmer si cela est dû à l’activité de fractionnement de la bande d’index. 
 

Solution à long terme

Concevez les planifications de sauvegarde et de maintenance afin qu’il y ait un « inactif » standard disponible pour la réinitialisation du mappage de bits référencés de hachage.

En d’autres termes, les plannings de sauvegarde ne doivent pas être exécutés 24 h/24, 7 j/7. Créez un planning qui donne un court laps de temps lorsqu’aucune sauvegarde ou aucune donnée de réplication entrante n’est écrite sur le système. 

Remarques : 

• La seule fois où les mappages de bits référencés par hachage vérifient s’ils peuvent être réinitialisés, c’est juste après la fin d’une session avtar. Lorsqu’aucune session avtar n’est en cours, la carte ne se réinitialise que si :

• L’une des raisons pour lesquelles le nombre de hachages ignorés peut être temporairement élevé est due au fractionnement de la bande d’index. Cela se produit car les hachages déplacés vers la cible fractionnée sont protégés. Le fractionnement de la bande d’index se produit sur les systèmes qui continuent de croître ou sont en cours de remplissage avec des données. 
• La récupération d’espace peut également échouer avec MSG_ERR_TRYAGAINLATER lorsque les bandes d’index sont fractionées :  
• MCS peut ne pas nécessairement connaître toutes les sessions avtar qui se produisent sur le serveur Avamar.