Avamar: Ett replikerande par visar olika nivåer av kapacitetsanvändning. Hur man undersöker orsakerna.

Orsaker och möjliga orsaker till skillnaderna mellan värdena för serveranvändning:

Logiska eller fysiska skillnader mellan rutnäten:

• Ett annat antal datanoder i käll- och målrutnäten.
• Datanoderna i varje rutnät har olika diskkonfigurationer.
• Tillräckligt balanserad fördelning av stripes över datanoderna i varje system (inom 2 %)
• Lagrings- och paritetskraven skiljer sig åt mellan Avamar-versioner. En skillnad i användning kan observeras om käll- och målprogramvaruversionerna skiljer sig åt.
• Den skrivskyddade nivån för Avamar-serverdisken kan skilja sig åt mellan de två rutnäten.   
• Ett rutnät kan konfigureras för RAIN-paritet, medan det andra kanske inte är det.

Replikeringskonfiguration:

• Säkerhetskopior som replikeras till målsystemet kan ha en annan kvarhållningsprincip jämfört med källan. Granska expiredelta-flaggan för mer information. Alternativt kanske de replikerade säkerhetskopiorna bara omfattar ett visst tidsintervall. Till exempel de senaste 4 veckornas säkerhetskopieringar från källan.
• Replikering kan konfigureras för att replikera endast en delmängd av klienterna från källsystemet till målsystemet. Kontrollera om inställningarna "inkludera" eller "exkludera" används.
• Klienter och deras associerade säkerhetskopior kan ha tagits bort från källsystemet. Om du tar bort en klient eller säkerhetskopior vid källan tas inte samma säkerhetskopior bort från målsystemet. Säkerhetskopiorna finns kvar på målet tills de upphör att gälla enligt kvarhållningsinställningarna.
• Kvarhållningsprinciper kan ändras för säkerhetskopior eller klienter i källsystemet. Ändringen av kvarhållningsprinciperna påverkar endast nya säkerhetskopior. Nya säkerhetskopior replikeras till målet och följer den uppdaterade kvarhållningsprincipen. Säkerhetskopior som redan finns på målet behåller den kvarhållningsprincip som tillämpades på dem när de replikerades.

Tidigare kapacitetshanteringsaktivitet:

• Det är inte ovanligt att kunder märker att ett av Avamar-replikeringsparsystemen närmar sig sin kapacitet och agerar då för att minska kapaciteten. Kom ihåg att ett Avamar-replikeringspar består av två oberoende hanterade system. Om åtgärder utförs på ett system måste de också utföras på det andra. 
• Om säkerhetskopior tas bort eller kvarhållningar minskas i källsystemet måste identiska ändringar göras på målet. Det bästa sättet att hantera kapacitet på det här sättet är med skriptet modify-snapups. Detta kan köras på båda Avamar-servrarna med samma alternativ för säkerhetskopiering eller borttagning.  

Olika stripe-struktur (till exempel fler paritetsstripes i ett system):

• Eftersom två Avamar-system är oberoende av varandra kan de ha olika randstrukturer. Flernodssystem kan uppvisa skillnader på grund av att de använder paritetsstripes för att skydda data. Beroende på kapacitetshistoriken innehåller två flernodssystem samma säkerhetskopior, men det ena kan ha ett högre antal paritetsstripes än det andra.
• Precis som med vanliga stripes finns en paritetsstripe alltid kvar i systemet när den har skapats. Till skillnad från vanliga stripes tar den alltid upp en bestämd mängd utrymme på Avamar-servern. Detta gäller även om deras säkra stripes för paritetsgrupp inte innehåller några data. Skräpinsamling har ingen effekt på det här beteendet.
• Ett replikeringsmålsystem är indirekt skyddat från större kapacitetsproblem på en replikeringskälla. Situationen kan dock uppstå på båda datorerna om en av dem hanteras dåligt ur ett kapacitetsperspektiv.
• Relaterad artikel: Avamar visar upp till ~30 % användning även efter att alla säkerhetskopior har tagits bort och skräp samlats in

Säkerhetskopior som fortfarande MC_DELETED:

• Ett sällsynt scenario att känna till är när en klient tas bort på källan men dess säkerhetskopior behålls. Detta kan resultera i att källan har en högre användning än målet där säkerhetskopiorna förväntas upphöra att gälla naturligt. Om du använder skriptet dump_root_hashes.rb med alternativet backupcompare kan du söka efter det här scenariot.

Data på målsystemet från icke-replikerade säkerhetskopior:

• Om systemet replikeras i *endast en riktning* kontrollerar du på målet att det inte finns några klienter utanför /REPLICATE och MC_SYSTEM.

Andra beteenden:

• Replikeringsjobb kanske inte slutförs på ett tillförlitligt sätt. Data som skickas till målet kan "släpa efter" källan med flera dagar.
• Båda systemen innehåller samma mängd deduplicerade data, men mängden paritetskostnader för var och en av dem är olika. Detta inträffar i följande scenario: 
  • Ett Avamar-källsystem är nästan fullt. 
  • Många säkerhetskopior tas bort från källsystemet för att sänka dess kapacitetsnivå. 
  • Replikering av deduplicerade data sker sedan från källa till mål. 
  • Mängden deduplicerade data är densamma i båda systemen.
  • Källsystemet lagrar initialt mer paritetskostnader än målet.
• Replikeringen kopierar inte fysiska stripes från käll- till målrutnätet. I stället kan målrutnätet bestämma var remsor och datasegment lagras.
• Ibland kan Avamar-målsystem lagra data mer effektivt än ett källrutnät där data ursprungligen säkerhetskopierades.

Förstå replikeringsmiljön:

• Anteckna det fullständiga värdnamnet för Avamar-källrutnätet.
• Granska replikeringskonfigurationen för de berörda systemen för att förstå vilka system som replikerar vilka data och var. 
  • Det kan vara till hjälp att rita en schematisk bild av miljön om det är något mer komplicerat än replikering från en Avamar-server till en annan.
• Om källan integreras med Data Domain (DD) kan du ta reda på om kundens problem gäller säkerhetskopior som replikeras mellan DD-enheter.
• Anteckna det fullständiga värdnamnet för Avamar-målrutnätet och eventuella associerade DD-enheter som tar emot replikerade säkerhetskopior.

Kontrollera nätets allmänna hälsa och situation:

• Kör det proaktiva kontrollskriptet i båda rutnäten och hämta en kopia av hc_results.txt och granska för att förstå den övergripande situationen med systemet. 

Hur stor är kapacitetsskillnaden?

• Kunden ska tillhandahålla en skärmbild som visar vad de tittar på som får dem att tro att det finns en skillnad i kapacitetsförbrukning mellan källa och mål.
• Vi anser inte att det finns anledning till oro om kapacitetsskillnaden är mindre än 5 procent.
• Kontrollera Avamar-administratörsgränssnittet för att förstå nivåerna på Avamar-serverns kapacitet och (om Data Domain är integrerat) metadatakapaciteten.
• Var medveten om hur visningen av användargränssnittskapacitet fungerar (beskrivs i Avamar-instrumentpanelen i v7.2 och senare visar Metadataanvändning i stället för Avamar-användning).
• Kör följande kommando på båda systemen. Serveranvändningsvärdet ger ett övergripande värde för Avamar-serverns (men inte Data Domain) kapacitetsnivåer:

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

Kontrollera att maskinvaran är densamma på båda rutnäten:

• Det är bara meningsfullt att jämföra kapacitetsskillnader för "lika" system. 
• Med hjälp av proaktiva kontrollutdata kontrollerar du vilken typ av noder som finns i systemet.
• Följande kommando visar ett övergripande antal, storlek och utrymmesförbrukning på de fysiska noderna:

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• Dessa utdata gör det enkelt att bestämma antalet och storleken på noderna i systemet. De är (23,3 / 3 = ~7,8 TB). 
• Antalet och storleken på hårddiskpartitionerna på varje nod måste bekräfta detta.

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• Kontrollera följande med den här informationen:

Kontrollera mjukvaruversion och konfiguration:

• Med hjälp av utdata från kommandot status.dpn jämför du vilken version av Avamar som körs på varje system.
• För flernodssystem, bekräfta att båda är konfigurerade med RAIN-paritet per Avamar – Så här avgör du om en server är RAIN eller icke-RAIN
• Kontrollera och jämför de två systemens kapacitetsrelaterade Avamar-serverkonfigurationsparametrar. Till exempel:

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

Kontrollera randbalanseringen:

• Kontrollera status.dpn-utdata och notera det totala antalet stripes på varje datanod. Antalet ränder anges inom hakparenteser (till exempel onl:xxx). 
• Det bör vara mindre än 2 % skillnad mellan det totala antalet stripes på varje datanod.

Kontrollera att skräpinsamlingen har körts korrekt på båda systemen:

• Om skräpinsamlingen inte körs konsekvent och effektivt tas inte data som har upphört att gälla tas bort. Systemet rapporterar högre kapacitetsanvändning än förväntat. 
  • Mer information finns i artikeln Sökväg för GC-upplösning i de begränsade anteckningarna.

Bekräfta att replikeringen slutförs:

• Se till att alla replikeringsuppgifter från källa till mål har slutförts. Om detta inte har skett kan det vara så att det fortfarande finns data som ska replikeras från källa till mål.

Kontrollera replikeringskonfigurationen:

• Kontrollera replikeringskonfigurationen (i användargränssnittet, CLI eller loggarna) för någon av följande flaggor:

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

Kontrollera intags- och databorttagningshastigheten för båda systemen:

• Kör proactive_check.pl --capacity på båda systemen och jämför inmatningshastigheterna för både käll- och målsystem.
• Om målet bara är ett målsystem och tar emot ALLA säkerhetskopior från källan bör dess inmatningshastighet nära följa källans inmatningshastighet.
• Kolumnerna Avamar NEW eller DDR NEW visar hur mycket nya data som läggs till i dessa system.
• Var också uppmärksam på kolumnerna "removed", "mins" och "pass" för att förstå skräpinsamlingsbeteendet i båda systemen.
• Denna information ger en tydlig bild av vad som händer i båda systemen.
• Mer information om hur du tolkar utdata finns i Avamar: Så här hanterar du kapacitet med capacity.sh-skriptet

Dumpa en lista över säkerhetskopior som finns på varje system:

• Skriptet dump_root_hashes.rb är ett verktyg som hjälper till att jämföra skillnaden i säkerhetskopior som lagras mellan en Avamar-källa och ett målsystem. Detta gäller även om säkerhetskopiorna finns på Data Domain-lagring.   
• Se Avamar: Avamar: Så här använder du dump_root_hashes.rb-skriptet för att generera en lista över klienter och säkerhetskopior för information om hur du laddar ner verktyget och användningsfall, inklusive jämförelse av innehållet i två Avamar-system.
  • Kör verktyget. Kontrollera om det finns inkonsekvenser i antalet säkerhetskopior på alla klienter. Var uppmärksam på skillnader på +/-2).  
• Som beskrivs i avsnittet Orsaker resulterar asymmetrisk kapacitetshantering i skillnader mellan de två systemen. Granska utdata för att avgöra om detta kan vara scenariot.
• Också:
  • Kontrollera målet för data på målsystemet från icke-replikerade säkerhetskopior.
  • Kontrollera källan för data som inte replikerades till målet.

Kontrollera om det finns avvikande stripestrukturer (till exempel fler paritetsränder i ett system):

• Eftersom de två Avamar-systemen är oberoende av varandra kan de ha olika randstrukturer. Flernodssystem kan uppvisa skillnader på grund av att de använder paritetsstripes för att skydda data. Beroende på kapacitetshistoriken innehåller två flernodssystem samma säkerhetskopior, men det ena kan ha ett högre antal paritetsstripes än det andra.  
• Precis som med vanliga stripes finns en paritetsstripe kvar i systemet när den har skapats. Till skillnad från vanliga stripes förbrukar den alltid en fast mängd utrymme i Avamar, även om deras säkra stripes i paritetsgruppen inte innehåller några data. Skräpinsamling har ingen effekt på det här beteendet.
• Ett replikeringsmålsystem är indirekt skyddat från större kapacitetsproblem på en replikeringskälla. Situationen kan dock uppstå på båda datorerna om en av dem hanteras dåligt ur ett kapacitetsperspektiv.
• Relaterad artikel:  Avamar visar upp till ~30 % användning även efter att alla säkerhetskopior har tagits bort och skräp samlats in

Säkerhetskopior som fortfarande MC_DELETED:

• Ett sällsynt scenario att känna till är när en klient togs bort på källan men dess säkerhetskopior behölls. Detta resulterar i att källan har en högre användning än målet där säkerhetskopiorna förväntas upphöra att gälla naturligt. Om du använder skriptet dump_root_hashes.rb med alternativet backupcompare bör du söka efter det här scenariot.