Avamar: La griglia entra in modalità amministratore a causa di differenze nelle partizioni di dati e nei file sparse

Tutte le attività di destinazione dei backup e delle repliche hanno esito negativo.

L'Avamar Server è in modalità amministratore.

La capacità è inferiore a diskreadonly valore.

Il numero di stripe su tutte le partizioni dati è simile:

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

L'output del seguente comando indica che la griglia è in modalità amministratore a causa di un problema chiamato diskbeat:
(diskbeat è l'attività che ha modificato la modalità di accesso al server)

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 colonna df mostra una grande discrepanza tra le partizioni dati:

Esempio:

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 

In questo output, /data04 viene utilizzato per il 41%, mentre per le altre partizioni di dati viene utilizzato il 18%-19%.

Questa differenza di dimensioni tra le partizioni dati supera il freespaceunbalance valore.
(freespaceunbalance è la differenza massima di capacità tra le partizioni dati)

Ulteriori indagini mostrano:

Il checkpoint (cp) L'overhead è simile tra le partizioni dati, ma la dimensione CUR è inferiore in una o più partizioni:

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 

Esiste una grande differenza tra le dimensioni apparenti della partizione CUR (dimensioni visualizzate dalle applicazioni) e l'utilizzo del disco CUR (quantità di spazio effettivo occupata dai file):

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/cur

Una o più partizioni di dati hanno più file sparse rispetto alle altre partizioni di dati.

Un file sparse è un tipo di file che tenta di utilizzare lo spazio del file system in modo più efficiente quando i blocchi allocati al file sono per lo più vuoti.
(Ad esempio: I blocchi che contengono solo zeri o nulla non vengono effettivamente archiviati su disco.

Scrive invece brevi informazioni (metadati) che rappresentano i blocchi vuoti sul disco.

Questo problema è in genere associato a un elevato tasso di modifiche, che causa un notevole aumento del sovraccarico dei checkpoint.

1. Eseguire i comandi seguenti:

status.dpn 

avmaint nodelist --xmlperline=99 | grep activityaccess 

df -h 

cps -blk

du -sh --apparent-size /data??/cur

du -sh /data??/cur 

2. Creare una Service Request con il team di supporto Dell Technologies Avamar, facendo riferimento a questo articolo e fornendo l'output raccolto sopra.