Avamar: Mřížka přejde do režimu správce kvůli rozdílům v datových oddílech a zhuštěných souborech

Summary: Tento článek řeší problém, kdy se počet zhuštěných souborů liší mezi datovými oddíly, což způsobuje, že mřížka přejde do režimu správce.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

Všechny aktivity zálohování a cílů replikace selhávají.

Server Avamar je v režimu správce.

Kapacita je nižší než diskreadonly hodnota.

Počet prokládání na všech datových oddílech je podobný:

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
 

Výstup následujícího příkazu indikuje, že mřížka je v režimu správce kvůli něčemu, co se nazývá diskbeat:
(diskbeat je aktivita, která změnila režim přístupu k serveru)

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

Skript df příkaz ukazuje velký rozdíl mezi datovými oddíly:

Příklad:

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

V tomto výstupu /data04 se používá 41 %, zatímco ostatní datové oddíly se používají 18 % až 19 %.

Tento rozdíl ve velikosti mezi datovými oddíly překračuje freespaceunbalance hodnota.
(freespaceunbalance je rozdíl maximální kapacity mezi datovými oddíly)

 

Další vyšetřování ukazuje:

Kontrolní bod (cp) Režie je podobná napříč datovými oddíly, ale velikost cur je nižší na jednom nebo více oddílech:

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
 

Existuje velký rozdíl mezi zdánlivou velikostí oddílu CUR (velikost zobrazená aplikacemi) a využitím disku CUR (kolik skutečného místa soubory zabírají):

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

Cause

Jeden nebo více datových oddílů obsahuje více zhuštěných souborů než ostatní datové oddíly.

Zhuštěný soubor je typ souboru, který se pokouší efektivněji využívat prostor v systému souborů, když jsou bloky přidělené souboru většinou prázdné.
(Například: Bloky, které obsahují pouze nuly nebo nic, nejsou ve skutečnosti uloženy na disku.)

Místo toho zapisuje na disk stručné informace (metadata) představující prázdné bloky.

 

Tento problém je obvykle spojen s vysokou rychlostí změn, což způsobuje dramatické zvýšení režie kontrolních bodů.

Resolution

1. Zadejte následující příkazy:

status.dpn 
avmaint nodelist --xmlperline=99 | grep activityaccess 
df -h 
cps -blk
du -sh --apparent-size /data??/cur
du -sh /data??/cur
 

2. Vytvořte servisní požadavek u týmu podpory Dell Technologies Avamar s odkazem na tento článek a poskytnutím výše shromážděného výstupu.

Affected Products

Avamar, Avamar Server
Article Properties
Article Number: 000036449
Article Type: Solution
Last Modified: 17 Jun 2025
Version:  6
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.