Avamar: La cuadrícula entra en modo de administrador debido a las diferencias en las particiones de datos y los archivos dispersos
Summary: En este artículo, se aborda un problema en el que la cantidad de archivos dispersos difiere entre las particiones de datos, lo que hace que la cuadrícula entre en modo de administrador. ...
Symptoms
Se produjo un error en todos los respaldos y las actividades de destino de replicación.
El Avamar Server está en modo admin.
La capacidad está por debajo del diskreadonly valor.
La cantidad de fracciones en todas las particiones de datos es similar:
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
El resultado del siguiente comando indica que la cuadrícula está en modo de administrador debido a algo llamado diskbeat:
(diskbeat es la actividad que cambió el modo de acceso al servidor)
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 variable df muestra una gran discrepancia entre las particiones de datos:
Ejemplo:
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
En esta salida, /data04 se utiliza un 41 %, mientras que las otras particiones de datos se utilizan entre un 18 % y un 19 %.
Esta diferencia de tamaño entre las particiones de datos supera los freespaceunbalance valor.
(freespaceunbalance es la diferencia de capacidad máxima entre las particiones de datos)
Una investigación más detallada muestra lo siguiente:
El punto de control (cp) La sobrecarga es similar en todas las particiones de datos, pero el tamaño de cur es menor en una o más particiones:
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
Hay una gran diferencia entre el tamaño aparente de la partición CUR (tamaño que ven las aplicaciones) y el uso del disco CUR (la cantidad de espacio real que ocupan los archivos):
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
Una o más particiones de datos tienen más archivos dispersos que las otras particiones de datos.
Un archivo disperso es un tipo de archivo que intenta utilizar el espacio del sistema de archivos de manera más eficiente cuando los bloques asignados al archivo están casi vacíos.
(Por ejemplo: Los bloques que solo contienen ceros o nada no se almacenan realmente en el disco).
En su lugar, escribe información breve (metadatos) que representa los bloques vacíos en el disco.
Por lo general, este problema se asocia con una alta tasa de cambio, lo que provoca un aumento drástico de la sobrecarga de puntos de control.
Resolution
1. Ejecute los siguientes comandos:
status.dpn
avmaint nodelist --xmlperline=99 | grep activityaccess
df -h
cps -blk
du -sh --apparent-size /data??/cur
du -sh /data??/cur
2. Cree una solicitud de servicio con el equipo de soporte de Avamar de Dell Technologies, haga referencia a este artículo y proporcione el resultado recopilado anteriormente.