Avamar: Das Raster wechselt aufgrund von Unterschieden bei den Datenpartitionen in den Administratormodus. Dateien mit geringer Datendichte

Alle Backups und Replikationszielaktivitäten schlagen fehl.

Der Avamar -Server befindet sich im Adminmodus.

Die Kapazität liegt unter der diskreadonly Wert.

Die Anzahl der Stripes auf allen Datenpartitionen ist ähnlich:

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

Die Ausgabe des folgenden Befehls weist darauf hin, dass sich das Raster aufgrund von etwas namens diskbeat:
(diskbeat ist die Aktivität, die den Serverzugriffsmodus geändert hat)

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

Die Spalte df zeigt eine große Diskrepanz zwischen den Datenpartitionen an:

Beispiel:

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 dieser Ausgabe wird /data04 zu 41 % verwendet, während die anderen Datenpartitionen zu 18 % bis 19 % verwendet werden.

Dieser Größenunterschied zwischen den Datenpartitionen überschreitet die freespaceunbalance Wert.
(freespaceunbalance ist die maximale Kapazitätsdifferenz zwischen Datenpartitionen)

Weitere Untersuchungen zeigen:

Der Kontrollpunkt (cp) Der Overhead ist auf allen Datenpartitionen ähnlich, aber die CUR-Größe ist auf einer oder mehreren Partitionen niedriger:

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 

Es gibt einen großen Unterschied zwischen der scheinbaren Größe der CUR-Partition (Größe, die von Anwendungen gesehen wird) und der CUR-Festplattennutzung (wie viel Speicherplatz tatsächlich von den Dateien belegt wird):

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

Eine oder mehrere Datenpartitionen verfügen über mehr Dateien mit geringer Datendichte als die anderen Datenpartitionen.

Eine Datei mit geringer Datendichte ist ein Dateityp, der versucht, Speicherplatz im Dateisystem effizienter zu nutzen, wenn die der Datei zugewiesenen Blöcke größtenteils leer sind.
(Zum Beispiel: Blöcke, die nur Nullen oder nichts enthalten, werden nicht auf der Festplatte gespeichert.)

Stattdessen werden kurze Informationen (Metadaten), die die leeren Blöcke darstellen, auf die Festplatte geschrieben.

Dieses Problem ist in der Regel mit einer hohen Änderungsrate verbunden, die zu einem dramatischen Anstieg des Kontrollpunkt-Overheads führt.

1. Führen Sie die folgenden Befehle aus:

status.dpn 

avmaint nodelist --xmlperline=99 | grep activityaccess 

df -h 

cps -blk

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

du -sh /data??/cur 

2. Erstellen Sie einen Service-Request beim Dell Technologies Avamar-Supportteam, beziehen Sie sich auf diesen Artikel und stellen Sie die oben erfasste Ausgabe bereit.