Avamar : une paire de réplication présente des niveaux d’utilisation de capacité différents. Procédure de recherche des causes.

Causes et raisons possibles des différences entre les valeurs « Utilisation du serveur » :

Différences logiques ou physiques entre les grilles :

• Un nombre de nœuds de données différent entre les grilles source et cible.
• Les nœuds de données de chaque grille ont des configurations de disque différentes.
• Répartition équilibrée des bandes sur les nœuds de données de chaque système (à 2 % près).
• Les exigences en matière de stockage et de parité diffèrent selon les versions d’Avamar. Une différence d’utilisation peut être observée si la source et la cible n’utilisent pas les mêmes versions de logiciel.
• Le niveau de lecture seule du disque d’Avamar Server peut être différent entre les deux grilles.   
• Une grille peut être configurée pour la parité RAIN, l’autre non.

Configuration de la réplication :

• Les sauvegardes répliquées sur le système cible peuvent suivre une politique de rétention différente de celle de la source. Vérifiez la balise expiredelta pour plus d’informations. Par ailleurs, il est possible que les sauvegardes répliquées ne couvrent qu’une période donnée. Par exemple, les quatre dernières semaines de sauvegarde à partir de la source.
• La réplication peut être configurée pour répliquer uniquement un sous-ensemble de clients du système source vers le système cible. Vérifiez si les paramètres « include » ou « exclude » sont utilisés.
• Les clients et leurs sauvegardes associées ont peut-être été supprimés du système source. La suppression d’un client ou de sauvegardes sur la source n’entraîne pas la suppression des mêmes sauvegardes sur le système cible. Les sauvegardes restent sur le système cible jusqu’à leur expiration, selon leurs paramètres de rétention.
• Les politiques de rétention peuvent être modifiées pour des sauvegardes ou des clients sur le système source. La modification des politiques de rétention s’applique uniquement aux nouvelles sauvegardes. Les nouvelles sauvegardes sont répliquées vers la cible dans le respect de la politique de rétention mise à jour. Les sauvegardes déjà présentes sur la cible continuent de suivre la politique de rétention qui leur a été appliquée lors de leur réplication.

Activité précédente de gestion de la capacité :

• Il n’est pas rare que les clients remarquent que l’un des systèmes de la paire de réplication Avamar approche de sa capacité maximale et qu’ils agissent pour réduire cette capacité. N’oubliez pas qu’une paire de réplication Avamar se compose de deux systèmes gérés indépendamment. Si des actions sont effectuées sur un système, elles doivent également l’être sur l’autre. 
• Si des sauvegardes sont supprimées ou que les périodes de rétention sont réduites sur le système source, des modifications identiques doivent être apportées au système cible. Pour respecter cela, la meilleure façon de gérer la capacité est d’utiliser le script modify-snapups. Il peut être exécuté sur les deux serveurs Avamar Server avec les mêmes options de modification ou de suppression des sauvegardes.  

Structure de bandes différente (par exemple, plus de bandes de parité sur l’un des systèmes) :

• Puisqu’ils fonctionnent de manière indépendante, deux systèmes Avamar peuvent se retrouver avec des structures de bandes différentes. Les systèmes à plusieurs nœuds peuvent présenter des différences en raison de leur utilisation de bandes de parité pour protéger les données. Selon leur historique de capacité, deux systèmes à plusieurs nœuds peuvent contenir les mêmes sauvegardes, mais l’un peut avoir un nombre de bandes de parité plus élevé que l’autre.
• Comme pour les bandes standard, une bande de parité reste toujours sur le système une fois créée. Contrairement aux bandes standard, elle occupe toujours une quantité d’espace fixe sur Avamar Server. Cela, même si les bandes de sécurité de son groupe de parité ne contiennent aucune donnée. Le nettoyage de la mémoire n’a aucun effet sur ce comportement.
• Un système cible de réplication est indirectement protégé contre les problèmes de capacité majeurs sur une source de réplication. Toutefois, ce type de situation peut se produire sur l’une ou l’autre des machines si la capacité de l’une d’entre elles est mal gérée.
• Article associé : Avamar indique une utilisation d’environ 30 % même après la suppression de toutes les sauvegardes et le nettoyage de la mémoire.

Sauvegardes toujours présentes dans MC_DELETED :

• Un cas rare à connaître est la conservation des sauvegardes d’un client, alors que celui-ci a été supprimé de la source. Cette situation peut entraîner une utilisation plus élevée sur la source que sur la cible, où les sauvegardes devraient expirer naturellement. L’utilisation du script dump_root_hashes.rb avec l’option backupcompare permet de détecter ce scénario.

Données sur le système cible à partir de sauvegardes non répliquées :

• Si le système effectue la réplication dans *une seule direction*, vérifiez sur la cible qu’aucun client n’existe en dehors de /REPLICATE et MC_SYSTEM.

Autres comportements :

• Les tâches de réplication peuvent ne pas s’exécuter de manière fiable. Les données envoyées à la cible peuvent accuser un retard de plusieurs jours par rapport à la source.
• Les deux systèmes contiennent la même quantité de données dédupliquées, mais la surcharge de parité sur chacun d’eux est différente. Ce problème se produit dans la situation suivante : 
  • Un système source Avamar est presque plein. 
  • De nombreuses sauvegardes sont supprimées du système source pour réduire son niveau de capacité. 
  • La réplication des données dédupliquées s’effectue ensuite de la source vers la cible. 
  • La quantité de données dédupliquées est la même sur les deux systèmes.
  • Le système source stocke initialement une surcharge de parité supérieure à celle de la cible.
• La réplication ne copie pas les bandes physiques de la source vers la grille cible. Au lieu de cela, la grille cible est autorisée à déterminer elle-même où les bandes et les fragments de données sont stockés.
• Dans certains cas, les systèmes cibles Avamar peuvent stocker des données plus efficacement qu’une grille source où les données sont initialement sauvegardées.

Comprendre l’environnement de réplication :

• Prenez note du nom d’hôte complet de la grille Avamar source.
• Examinez la configuration de réplication des systèmes concernés pour comprendre quels systèmes répliquent quelles données et vers où. 
  • Si l’environnement est plus complexe que la réplication d’une seule instance Avamar Server vers une autre, il peut être utile de dessiner un schéma.
• Si la source s’intègre à Data Domain (DD), déterminez si la préoccupation du client concerne les sauvegardes répliquées entre les appareils DD.
• Notez le nom d’hôte complet de la grille Avamar cible et de tous les appareils DD associés qui reçoivent des sauvegardes répliquées.

Vérifiez l’intégrité générale et la situation de la grille :

• Exécutez le script de contrôle proactif sur les deux grilles, récupérez une copie du fichier hc_results.txt et examinez-le pour comprendre la situation globale du système. 

De quelle gravité est le différentiel de capacité ?

• Le client doit fournir une capture d’écran qui montre ce qu’il observe et qui l’amène à penser qu’il y a une différence de consommation de capacité entre la source et la cible.
• Nous ne jugeons pas nécessaire de s’alarmer si l’écart de capacité est inférieur à 5 %.
• Sur l’interface utilisateur d’Avamar Administrator, examinez les différents niveaux de capacité des serveurs Avamar ainsi que la capacité de stockage des métadonnées si le système est intégré à Data Domain.
• Assurez-vous de bien comprendre comment l’interface utilisateur affiche la capacité (voir la discussion dans Le tableau de bord de l’interface utilisateur Avamar version 7.2 et ultérieures affiche l’utilisation des métadonnées à la place de l’utilisation d’Avamar).
• Exécutez la commande suivante sur les deux systèmes. L’indicateur d’utilisation du serveur donne une valeur globale des niveaux de capacité d’Avamar Server (mais pas de Data Domain) :

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

Vérifiez que le matériel est identique sur les deux grilles :

• Il n’est pertinent de comparer les différences de capacité qu’entre des systèmes similaires. 
• À partir des résultats de la vérification proactive, notez le type de nœuds présents dans le système.
• La commande suivante indique le nombre total de nœuds physiques, leur taille et l’espace qu’ils occupent :

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• Cette sortie permet de déterminer facilement le nombre et la taille des nœuds dans le système : 23,3/3 = ~7,8 To. 
• Le nombre et la taille des partitions de disque dur sur chaque nœud doivent corroborer ces informations.

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• À partir de ces informations, vérifiez les points suivants :

Vérifiez la version et la configuration du logiciel :

• À partir de la sortie de la commande status.dpn, comparez la version d’Avamar exécutée sur chaque système.
• Pour les systèmes à plusieurs nœuds, confirmez que les deux sont configurés avec la parité RAIN conformément à l’article Avamar : Comment déterminer si un serveur est RAIN ou non RAIN.
• Vérifiez et comparez les paramètres de configuration du serveur Avamar liés à la capacité des deux systèmes. Par exemple :

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

Vérifiez l’équilibrage des bandes :

• Vérifiez la sortie status.dpn et notez le nombre total de bandes sur chaque nœud de données. Le nombre de bandes est indiqué entre parenthèses (par exemple, onl:xxx). 
• La différence entre le nombre total de bandes sur chaque nœud de données doit être inférieure à 2 %.  

Assurez-vous que le nettoyage de la mémoire a fonctionné correctement sur les deux systèmes :

• Si le nettoyage de la mémoire ne s’exécute pas de manière cohérente et efficace, il ne supprimera pas les données expirées. Le système signale une utilisation de la capacité plus élevée que prévu. 
  • Pour plus d’informations, reportez-vous à l’article « Chemin de résolution du nettoyage de la mémoire » dans les remarques restreintes.  

Confirmez que la réplication se termine correctement.

• Vérifiez que toutes les tâches de réplication depuis la source jusqu’à la cible soient achevées avec succès. Si ce n’est pas le cas, il se peut qu’il reste des données à répliquer de la source vers la cible.  

Vérifiez la configuration de réplication :

• Dans l’interface utilisateur, l’interface de ligne de commande ou les journaux, vérifiez la présence d’une des balises suivantes dans la configuration de la réplication :  

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

Vérifiez les taux d’acquisition et de suppression des données des deux systèmes :

• Exécutez proactive_check.pl --capacity sur les deux systèmes et comparez les taux d’acquisition des systèmes source et cible.
• Si la cible est exclusivement un système cible et reçoit TOUTES les sauvegardes de la source, son taux d’acquisition doit suivre de près le taux d’acquisition de la source.
• Les colonnes Avamar NEW ou DDR NEW indiquent la quantité de nouvelles données ajoutées à ces systèmes.
• De plus, examinez attentivement les colonnes « removed », « mins » et « pass » pour comprendre le comportement du nettoyage de la mémoire sur les deux systèmes.
• Ces informations donnent une vue claire de ce qui se passe sur les deux systèmes.
• Pour plus d’informations sur l’interprétation de la sortie, voir Avamar : Gestion de la capacité avec le script capacity.sh  

Videz une liste des sauvegardes existantes sur chaque système :

• Le script dump_root_hashes.rb est un utilitaire qui permet de comparer le nombre de sauvegardes stockées sur des systèmes Avamar source et cible. et ce, même si les sauvegardes sont hébergées sur une solution de stockage Data Domain.   
• Voir Avamar : Avamar : Utilisation du script dump_root_hashes.rb pour générer une liste de clients et de sauvegardes pour plus d’informations sur le téléchargement de l’utilitaire et des cas d’utilisation, y compris la comparaison du contenu de deux systèmes Avamar.
  • Exécutez l’outil. Vérifiez les incohérences dans le nombre de sauvegardes sur tous les clients. Soyez attentif aux différences de +/-2.  
• Comme indiqué dans la section Causes, une gestion asymétrique de la capacité entraîne des différences entre les deux systèmes. Vérifiez la sortie pour déterminer si cela pourrait être le cas.
• Par ailleurs :
  • Vérifiez la cible des données sur le système cible pour les sauvegardes non répliquées.
  • Recherchez dans la source les données qui n’ont pas été répliquées vers la cible.  

Vérifiez si les structures des bandes sont différentes (par exemple, plus de bandes de parité sur l’un des systèmes) :

• puisqu’ils fonctionnent de manière indépendante, les deux systèmes Avamar peuvent avoir des structures de bandes différentes. Les systèmes à plusieurs nœuds peuvent présenter des différences en raison de leur utilisation de bandes de parité pour protéger les données. Selon leur historique de capacité, deux systèmes à plusieurs nœuds peuvent contenir les mêmes sauvegardes, mais l’un peut avoir un nombre de bandes de parité plus élevé que l’autre.  
• Comme pour les bandes standard, une bande de parité reste sur le système une fois créée. Contrairement aux bandes standard, elle occupe toujours une quantité d’espace fixe sur Avamar Server. Cela, même si les bandes de sécurité de son groupe de parité ne contiennent aucune donnée. Le nettoyage de la mémoire n’a aucun effet sur ce comportement.
• Un système cible de réplication est indirectement protégé contre les problèmes de capacité majeurs sur une source de réplication. Toutefois, ce type de situation peut se produire sur l’une ou l’autre des machines si la capacité de l’une d’entre elles est mal gérée.
• Article associé :  Avamar indique une utilisation d’environ 30 % même après la suppression de toutes les sauvegardes et le nettoyage de la mémoire.  

Sauvegardes toujours présentes dans MC_DELETED :

• Un cas rare à connaître est la conservation des sauvegardes d’un client, alors que celui-ci a été supprimé de la source. Cette situation entraîne une utilisation plus élevée sur la source que sur la cible, où les sauvegardes devraient expirer naturellement. L’utilisation du script dump_root_hashes.rb avec l’option backupcompare devrait permettre de détecter ce scénario.