Avamar : Partitions, bandes et échecs de vérification hfs suspendus sur Avamar

1. Le message d’erreur suivant peut s’afficher dans l’interface utilisateur d’Avamar Administrator Server. Le message peut générer une demande de service Dial Home (SR) :

Symptom Code: 22632, Desc: A server disk has become suspended.

2. Messages WARN liés à perfbeat thread sont signalés sur les nœuds de stockage de données dans le /data01/cur/gsan.log:

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66
WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended
WARN: <1084> changing disk 0 on node 0.3 to suspended state

3. La commande status.dpn La sortie indique que des bandes sont suspendues sur un disque :
(Cette sortie n’est produite que lorsque « WARN <1084> » se produit.)

Par exemple :

0.8 10.10.10.10 7.3.1-125 ONLINE fullaccess mhpu+0hpu+0hpu 1 false 7.36 16350564 3401334 56.0% 66%(onl:1,SUS:2374) 50%(onl:2439) 50%(onl:2433) 

Cette sortie indique qu’il existe 2 374 bandes suspendues.

4. La commande hfscheck échoue si une partition est suspendue alors que l’attribut hfscheck est en cours d’exécution. Exemple d’erreur de /data01/hfscheck/err.log ou /data01/cur/err.log are: 

ERROR: <0001> indexstripe::hfschecksweepbody stripe=0.0-1209 proxy=0.0-1209 indexelem([hash=ee9b2fe66b4bd472e28c4f41c5097dbeaba7131a stripe=0.1-DF8 offset=1285]) goodowner=true goodelem=false

Périodiquement, toutes les cinq minutes par défaut, le gsan « teste » le I/O en effectuant de petites lectures à partir des partitions de données.

Il vérifie si les performances de lecture sont inférieures de 10 % à celles des performances normales.

Dans l’exemple ci-dessous, le message indique que, sur le nœud particulier qui a généré le message d’avertissement, les performances de lecture moyennes sur un nombre prolongé d’essais hfscheck est d’environ 54,03 Mo/seconde. Toutefois, lors de ce test particulier, les performances réelles étaient de 0,57 Mo/seconde, ce qui est inférieur à la « limite » de 10 % de la valeur moyenne, soit 5,4 029 Mo/seconde.

Event Summary = perfbeat::outoftolerance mask=[hfscheck] average=54.03 limit=5.4029 mbpersec=0.57

À l’origine, l’objectif de ce test était de fournir un avertissement indiquant qu’il y avait un problème avec le I/O ce qui ralentit excessivement les performances de lecture. 

Dans ce cas, une vitesse inférieure à 10 % du disque « moyen » I/O performance.

La commande perftriallimit Spécifie le nombre de tests consécutifs de lecture de disque qui doivent être hors tolérance avant perfbeat Soupçonne qu’un disque est dégradé.

La commande perfinterval (300 s ou 5 minutes par défaut) spécifie la durée d’attente entre chaque perftriallimit test.

Lorsque perfbeat soupçonne qu’un disque est dégradé, il indique au gsan pour atteindre un état froid (arrêter toute activité liée au disque). 

Il attend au maximum 20 minutes (câblé) que le gsan pour atteindre cet état avant de ne pas suspendre le disque.

Si l’état froid est atteint, alors perfbeat Effectue perfcoldtriallimit (4 par défaut) Plus de tests de lecture espacés perfcoldinterval (par défaut à 30) secondes d’intervalle.

Ce n’est que si tous ces tests indiquent que le disque est toujours dégradé qu’il est suspendu.

Raisons possibles pour les disques suspendus :

• Lorsque vous essayez d’atteindre un état froid, le gsan attend toujours au moins une minute (câblé). Il attend également tous les disques gsan en attente I/O activités connexes pour terminer ou suspendre leur fonctionnement. Toutefois, une fois l’état à froid atteint, le système d’exploitation peut toujours exécuter des opérations sur le disque I/O, par exemple en vidant son cache. Cette activité de vidage est l’une des raisons pour lesquelles les disques sont suspendus inutilement. Avec des quantités de mémoire plus importantes, il peut y avoir beaucoup plus de données de cache à vider.

• Une autre explication possible est que les informations de l’historique des performances ne permettent pas de prédire avec précision les performances de lecture de disque attendues au cours de diverses gsan parce que l' gsan's Le comportement a changé trop rapidement pour que l’historique puisse être reflété (l’historique est une moyenne des mesures de performances des 10 derniers jours).

• Une autre explication possible est qu’il pourrait y avoir un problème, comme le fait de ne pas attendre que tout le monde gsan disque I/O activités permettant de terminer ou de suspendre leur opération avant d’atteindre un état froid.

De plus, les recherches ont montré qu’au cours de la hfscheck »indexsweep" (lorsque tous les hachages des bandes d’index sont lus, puis effectuent des écritures aléatoires massives sur de nombreux fichiers de journal de référence des données (DRL), le test a été effectué I/O Les performances diminuent pendant une période importante.

Sur Avamar Data Store Gen4, Gen4s et Gen4T, les opérations d’écriture ont été prioritaires par rapport aux opérations de lecture et l’importance de tester les performances de lecture du I/O est beaucoup plus faible. De plus, certains disques (comme Seagate Megalodon utiliser) utilisent des techniques différentes qui peuvent brouiller les tests effectués par celui de l' perfbeat fil.

Informations :

Il y a généralement trois messages d’avertissement différents qui s’affichent dans le gsan Journaux:

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66

L’avertissement <0968> indique qu’il y avait un individu gsan I/O test qui était lent.

Vous pouvez ignorer ce message en toute sécurité :

WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended

L’avertissement <1051> indique qu’il y a eu suffisamment de lectures lentes pour que le gsan a été envisagé de mettre la partition de données à l’état suspendu, mais a décidé de ne pas le faire. C’est ce que MSG_ERR_UNNECESSARY indique.

Vous pouvez ignorer ce message en toute sécurité :

WARN: <1084> changing disk 0 on node 0.3 to suspended state

L’avertissement <1084> indique que gsan a mis la partition de données en « état suspendu ».

Ce message ne doit pas être ignoré.

Résolution :

Si les bandes sont mises en état de suspension, suivez les instructions suivantes pour examiner et corriger les scénarios suivants :

Procédez comme suit pour identifier l’emplacement de la partition suspendue :

1. Connectez-vous à Avamar Utility Node en tant qu’administrateur.

2. Élévation au niveau du privilège root.

3. Chargez les clés racine par Avamar : Connexion à un serveur Avamar et chargement de différentes clés.

4. Exécutez la commande suivante pour identifier l’emplacement de la partition suspendue :

mapall --noerror 'grep -i "suspended" /data01/cur/err.log'

5. Passez en revue les scénarios en rapport avec les résultats ci-dessus :

• • Aucune action n’est requise. Les bandes sont automatiquement remises en ligne. Il est fort probable que hfscheck étaient en cours d’exécution. 

• • Si les bandes reviennent automatiquement en ligne, il est fort probable que le nettoyage de la mémoire ou hfscheck étaient en cours d’exécution.
  • IMPORTANT : Cela peut être le signe d’un problème de disque ou d’un problème sous-jacent.
  • Bien que le disque n’ait pas encore échoué, il doit tout de même être vérifié en suivant les étapes ci-dessous :

1. Déterminez les disques physiques associés au disque qu’Avamar a suspendu. Des problèmes de disque physique au sein d’un disque virtuel suspendu seraient la cause première d’une suspension :

avsysreport pdisk vdisk=x 

Où x est le numéro du disque virtuel (partition de données) qui a été suspendu. Par exemple, si la première partition de données affiche des bandes suspendues, interrogez vdis=0.

2. Vérifiez qu’il n’y a pas de panne de disque, de pannes prévues ou d’autres erreurs au niveau du disque physique.

3. Vérifiez qu’il n’y a pas d’erreurs SCSI sur les disques physiques qui représentent le disque virtuel sur le nœud en question (déterminé à l’étape 1). 

grep -i "MRMON\|scsi|Adaptec" /var/log/messages

4. Les disques virtuels en mode d’écriture immédiate peuvent entraîner des suspensions de disque en raison d’un I/O. Vérifiez la politique d’écriture sur le contrôleur :

mapall --noerror --all+ 'avsysreport vdisk | grep "Write Policy"'  

Si des problèmes sont détectés aux étapes 2 à 4, ouvrez une demande de service auprès du support Dell Technologies Avamar pour une procédure d’enquête plus approfondie.

Scénario # 3 : Vérifier la valeur par défaut perftriallimit Paramètres:

1. Vérifiez que le perftriallimit est défini sur 0 :

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. Si la demande perftriallimit est autre chose que zéro :

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"