Avamar : Étapes de validation des échecs de nettoyage de la mémoire sur Avamar

Qu’est-ce que le nettoyage de mémoire ?

Le nettoyage de la mémoire (GC) est le processus de suppression des fragments inutilisés des sauvegardes qui ont expiré. Cela libère de la capacité sur l’instance d’Avamar Server.

Par défaut, le nettoyage de la mémoire s’exécute une fois par jour au début de la fenêtre de maintenance.

Symptômes de défaillance courants :

• MSG_ERR_DDR_ERROR
• MSG_ERR_DISKFULL
• MSG_ERR_MISC
• MSG_ERR_TRYAGAINLATER
• MSG_ERR_BADTIMESYNC

Causes courantes des défaillances du GC :

• Il existe de nombreux problèmes sous-jacents qui peuvent provoquer l’échec de GC avec MSG_ERR_DDR_ERROR. Voici quelques-unes de ces raisons :
  • Erreurs de réseau ou de connectivité
  • Problèmes liés au système de fichiers Data Domain
  • L’appliance Data Domain est saturée
  • Un mot de passe utilisateur DD Boost incorrect ou expiré
  • Il y a trop de points de contrôle (Avamar) ou de snapshots (Data Domain). Il est généralement associé à hfscheck Les défaillances ne permettent pas de « supprimer » les anciens points de contrôle et snapshots.

• À partir d’Avamar v.7, les sauvegardes peuvent s’exécuter en même temps que le nettoyage de la mémoire.
• Parfois, un processus appelé « fractionnement par bande d’index » se produit lorsque de nouvelles données sont ajoutées à partir des sauvegardes.
• Étant donné que ce processus de « fractionnement de bande d’index » ne peut pas s’exécuter pendant que le nettoyage de la mémoire est en cours d’exécution, l’une des erreurs ci-dessus s’affiche.
  • Les bandes d’index sur une grille ont tendance à se diviser à peu près à la même période de temps les unes par rapport aux autres sur les différents nœuds.
  • Parfois, cela peut prendre quelques jours.
  • Avamar fonctionne normalement. La solution de contournement consiste à ne pas exécuter de sauvegardes pendant le GC.

• Il s’agit d’un problème rare qui se produit uniquement sur les réseaux à plusieurs nœuds. L’erreur se produit lorsque l’heure n’est pas synchronisée entre un ou plusieurs nœuds de données Avamar et le nœud utilitaire.
• Il est probable que toutes les tâches de maintenance (GC, point de contrôle et hfscheck) signalent la même erreur. 

Détermination de l’état du nettoyage de la mémoire le plus récent :

Vous pouvez afficher des informations sur le nettoyage de la mémoire le plus récent à l’aide de l’interface de ligne de commande, de l’AUI ou de l’interface utilisateur du serveur MCS (Management Console Server).

À partir de la CLI :

• Ouvrez une session SSH (par exemple putty) sur Avamar Server et connectez-vous en tant qu’administrateur. Exécutez les commandes suivantes :

status.dpn
avmaint gcstatus

• Les exemples suivants illustrent un nettoyage de la mémoire réussi :

Last GC: finished Tue Jul  9 00:00:23 2024 after 00m 03s >> recovered 199.88 KB (OK)
Last GC: finished Wed Jun  5 09:20:46 2024 after 00m 12s >> recovered 0.00 KB (OK)

• Si l’état indique autre chose que (OK), il existe un problème potentiel avec le nettoyage de la mémoire :

Last GC: finished Mon Jun 17 09:02:41 2024 after 01m 51s >> recovered 14.98 MB (MSG_ERR_DDR_ERROR)
Last GC: finished Thu Jun 13 07:06:54 2024 after 03m 41s >> recovered 0.00 KB (MSG_ERR_DISKFULL)
Last GC: finished Mon Jun 10 19:04:58 2024 after 01m 01s >> recovered 0 KB (MSG_ERR_MISC)
Last GC: finished Thu Jun  16:21:12 2024 after 00m 25s >> recovered 0 KB (MSG_ERR_BADTIMESYNC)

De l’AUI :

• Vérifiez l’état du dernier nettoyage de la mémoire. Si l’état indique autre chose que (OK), il existe un problème potentiel de nettoyage de la mémoire.

À partir de l’interface utilisateur du serveur MCS :

• Si le « dernier nettoyage de la mémoire » a un « x » rouge comme indiqué ci-dessus, il existe un problème potentiel de nettoyage de la mémoire et une analyse plus approfondie est nécessaire.

Si le nettoyage de la mémoire continue d’échouer en raison d’un problème réel (tel que validé à l’aide des étapes ci-dessus), sélectionnez les options appropriées dans le formulaire de réponse aux alertes pour transférer la demande de service à un agent du support.

Accuser réception des erreurs une fois le problème résolu :

À partir de la CLI :

1. Recherchez les événements non acquittés en exécutant :

mccli event show --unack

2. Acquittez le code unique en saisissant l’ID unique ou tous les codes d’erreur :

mccli event show --id-

De l’AUI :

1. Connectez-vous à l’AUI et affichez le tableau de bord : 

2. Cliquez sur le point d’exclamation pour afficher l’écran suivant :

3. Cliquez sur Unacknowledged events et l’écran affiche quelque chose de similaire à ce qui suit :

4. Sélectionnez l’événement (comme illustré ci-dessus), puis cliquez sur Acknowledge.

Déterminer depuis combien de temps le GC est défaillant :

Le moyen le plus simple de déterminer la durée d’échec du GC consiste à utiliser la CLI (bien que ces informations soient également disponibles dans l’interface utilisateur AUI et MCS)

La commande suivante affiche tous les échecs de nettoyage de la mémoire des 30 derniers jours :

dumpmaintlogs --types=gc --days=30 |grep "failed garbage collection"

2024/05/27-16:32:18.55893 {0.0} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR
2024/05/28-16:32:37.92920 {0.0} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR
2024/05/29-16:31:51.62962 {0.0} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR
2024/05/30-16:31:55.18969 {0.0} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR
2024/06/20-01:19:09.97961 {0.0} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR