Avamar : La grille passe en mode admin en raison de différences dans les partitions de données et les fichiers épars
Summary: Cet article traite d’un problème dans lequel le nombre de fichiers sparse diffère entre les partitions de données, ce qui entraîne le passage de la grille en mode administrateur.
Symptoms
Toutes les activités de sauvegarde et de destination de réplication échouent.
L’instance d’Avamar Server est en mode administrateur.
La capacité est inférieure à la diskreadonly valeur.
Le nombre de bandes sur toutes les partitions de données est similaire :
status.dpn
Thu Jul 16 09:41:28 CEST 2015 [avamar.emc.com] Thu Jul 16 07:41:27 2020 UTC (Initialized Thu Jan 16 16:42:42 2014 UTC)
Node IP Address Version State Runlevel Srvr+Root+User Dis Suspend Load UsedMB Errlen %Full Percent Full and Stripe Status by Disk
0.0 10.10.10.10 7.1.1-145 ONLINE fullaccess mhpu+0hpu+0000 1 false 0.03 35759 80935381 1.6% 1%(onl:1414) 1%(onl:1418) 1%(onl:1408) 1%(onl:1414) 1%(onl:1414) 1%(onl:1412)
Srvr+Root+User Modes = migrate + hfswriteable + persistwriteable + useraccntwriteable
System ID: 1434729928@00:50:56:8A:24:53
All reported states=(ONLINE), runlevels=(fullaccess), modes=(mhpu+0hpu+0000)
System-Status: ok
Access-Status: admin
No checkpoint yet
No GC yet
No hfscheck yet
Maintenance windows scheduler capacity profile is active.
The backup window is currently running.
Next backup window start time: Thu Jul 16 20:00:00 2020 CEST
Next maintenance window start time: Thu Jul 16 12:00:00 2020 CEST
La sortie de la commande suivante indique que la grille est en mode admin en raison d’un élément appelé diskbeat:
(diskbeat est l’activité qui a modifié le mode d’accès au serveur)
avmaint nodelist --xmlperline=99 | grep activityaccess
<activityaccessmodes adminuser="mhpu+0hpu+0hpu" checkpoint="mhpu+0hpu+0hpu" conversion="mhpu+0hpu+0hpu" diskbeat="mhpu+0hpu+0000" garbagecollect="mhpu+0hpu+0hpu"
heartbeat="mhpu+0hpu+0hpu" hfscheckserver="mhpu+0hpu+0hpu" hfscheckexecute="mhpu+0hpu+0hpu" nodebeat="mhpu+0hpu+0hpu" runlevel="mhpu+0hpu+0hpu"
testintegrity="mhpu+0hpu+0hpu" removehashes="mhpu+0hpu+0hpu" rebuildstripe="mhpu+0hpu+0hpu" diskfull="mhpu+0hpu+0hpu" hashrefcheck="mhpu+0hpu+0hpu"/>
La commande df affiche une grande divergence entre les partitions de données :
Exemple :
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 7.9G 6.2G 1.4G 82% /
udev 18G 288K 18G 1% /dev
tmpfs 18G 0 18G 0% /dev/shm
/dev/sda1 130M 62M 61M 51% /boot
/dev/sda7 1.5G 227M 1.2G 17% /var
/dev/sda9 77G 50G 23G 70% /space
/dev/sdb1 1.0T 190G 835G 19% /data01
/dev/sdc1 1.0T 183G 842G 18% /data02
/dev/sdd1 1.0T 185G 839G 19% /data03
/dev/sde1 1.0T 416G 608G 41% /data04
/dev/sdf1 1.0T 190G 835G 19% /data05
/dev/sdg1 1.0T 187G 838G 19% /data06
Dans cette sortie, /data04 est utilisé à 41 %, alors que les autres partitions de données sont utilisées entre 18 % et 19 %.
Cette différence de taille entre les partitions de données dépasse la freespaceunbalance valeur.
(freespaceunbalance est la différence de capacité maximale entre les partitions de données)
Une enquête plus approfondie montre que :
Le point de contrôle (cp) La surcharge est similaire sur toutes les partitions de données, mais la taille cur est inférieure sur une ou plusieurs partitions :
cps -blk
Checkpoint usage by partition:
188.020 /data01/cur
181.944 /data02/cur
186.020 /data03/cur
435.234 /data04/cur
190.617 /data05/cur
187.797 /data06/cur
0.540 /data01/cp.20200716082941
0.542 /data02/cp.20200716082941
0.548 /data03/cp.20200716082941
0.038 /data04/cp.20200716082941
0.523 /data05/cp.20200716082941
0.493 /data06/cp.20200716082941
0.759 /data01/cp.20200716080454
0.777 /data02/cp.20200716080454
0.781 /data03/cp.20200716080454
0.336 /data04/cp.20200716080454
0.751 /data05/cp.20200716080454
0.721 /data06/cp.20200716080454
GB used %use Total checkpoint usage by node:
6593.815 Total blocks on node Thu Jul 16 10:41:56 2020
5198.045 78.83 Total blocks available
1369.633 20.77 cur Thu Jul 16 10:33:14 2020
2.683 0.04 cp.20200716082941 Thu Jul 16 10:32:42 2020
4.125 0.06 cp.20200716080454 Thu Jul 16 10:14:15 2020
1376.440 20.87 Total blocks used by dpn
Il existe une grande différence entre la taille apparente de la partition CUR (taille vue par les applications) et l’utilisation du disque CUR (espace réel occupé par les fichiers) :
du -sh --apparent-size /data??/cur
458G /data01/cur
456G /data02/cur
456G /data03/cur
455G /data04/cur
457G /data05/cur
456G /data06/cur
du -sh /data??/cur
176G /data01/cur
170G /data02/cur
174G /data03/cur
406G /data04/cur
178G /data05/cur
175G /data06/curCause
Une ou plusieurs partitions de données ont plus de fichiers sparse que les autres partitions de données.
Un fichier sparse est un type de fichier qui tente d’utiliser l’espace du système de fichiers plus efficacement lorsque les blocs alloués au fichier sont pour la plupart vides.
(Par exemple : Les blocs qui ne contiennent que des zéros ou rien ne sont réellement stockés sur le disque.)
Au lieu de cela, il écrit de brèves informations (métadonnées) représentant les blocs vides sur le disque.
Ce problème est généralement associé à un taux de modification élevé, ce qui entraîne une augmentation considérable de la surcharge des points de contrôle.
Resolution
1. Exécutez les commandes suivantes :
status.dpn
avmaint nodelist --xmlperline=99 | grep activityaccess
df -h
cps -blk
du -sh --apparent-size /data??/cur
du -sh /data??/cur
2. Créez une demande de service auprès de l’équipe de support Dell Technologies Avamar, en vous référant à cet article et en fournissant les résultats collectés ci-dessus.