Avamar: Et replikeringspar viser forskellige niveauer af kapacitetsforbrug. Sådan undersøges årsagerne.

Årsager og mulige årsager til forskellene mellem værdierne for "serverudnyttelse":

Logiske eller fysiske forskelle mellem gitterene:

• Et andet antal datanoder på kilde- og målgitrene.
• Datanoderne i hvert gitter har forskellige diskkonfigurationer.
• Tilstrækkelig afbalanceret fordeling af striber på tværs af datanoderne i hvert system (inden for 2 %)
• Kravene til storage og paritet varierer mellem Avamar-versionerne. Der kan observeres en forskel i brugen, hvis kilde- og målsoftwareversionerne er forskellige.
• Avamar-serverens skrivebeskyttede niveau kan variere mellem de to gitre.   
• Det ene gitter kan konfigureres til RAIN-paritet, hvor det andet ikke kan.

Replikeringskonfiguration:

• Sikkerhedskopier, der replikeres til destinationssystemet, kan have en anden opbevaringspolitik sammenlignet med kilden. Gennemgå expiredelta-flaget for at få flere oplysninger. Alternativt dækker de replikerede sikkerhedskopier muligvis kun et bestemt tidsrum. For eksempel de sidste 4 ugers sikkerhedskopier fra kilden.
• Replikering kan konfigureres til kun at replikere et undersæt af klienter fra kildesystemet til destinationssystemet. Kontrollér, om indstillingerne "include" eller "exclude" bruges.
• Klienter og deres tilknyttede sikkerhedskopier kan være blevet slettet fra kildesystemet. Sletning af en klient eller af sikkerhedskopier på kilden fjerner ikke de samme sikkerhedskopier fra målsystemet. Sikkerhedskopierne forbliver på destinationen, indtil de udløber i henhold til deres opbevaringsindstillinger.
• Opbevaringspolitikker kan ændres for sikkerhedskopier eller klienter på kildesystemet. Ændringen i opbevaringspolitikker påvirker kun nye sikkerhedskopier. Nye sikkerhedskopier replikeres til destinationen og overholder den opdaterede opbevaringspolitik. Sikkerhedskopier, der allerede findes på destinationen, bevarer den opbevaringspolitik, der blev anvendt på dem, da de blev replikeret.

Tidligere kapacitetsstyringsaktivitet:

• Det er ikke usædvanligt, at kunderne bemærker, at et af Avamar-replikeringsparsystemerne nærmer sig kapaciteten og derefter handler for at reducere kapaciteten. Husk – et Avamar-replikeringspar består af to uafhængigt administrerede systemer. Hvis handlinger udføres på et system, skal de også udføres på det andet. 
• Hvis sikkerhedskopier slettes, eller tilbageholdelser reduceres på kildesystemet, skal der foretages identiske ændringer på destinationen. Den bedste måde at administrere kapaciteten på denne måde er med scriptet modify-snapups. Den kan køres på begge Avamar-servere med de samme muligheder for sikkerhedskopiering, ændring eller sletning.  

Forskellig stribestruktur (f.eks. flere paritetsstriber på ét system):

• Da to Avamar-systemer er uafhængige, kan de ende med forskellige stribestrukturer. Systemer med flere noder kan udvise forskelle på grund af deres brug af paritetsstriber til beskyttelse af data. Afhængigt af deres kapacitetshistorik indeholder to systemer med flere noder de samme sikkerhedskopier, men det ene kan have et højere antal paritetsstriber end det andet.
• Ligesom almindelige striber forbliver der altid en paritetsstribe på systemet, når den først er oprettet. I modsætning til almindelige striber bruger den altid en fast mængde plads på Avamar-serveren. Dette er tilfældet, selvom deres paritetsgruppe safe-stripes ikke indeholder data. Affaldsindsamling har ingen effekt på denne adfærd.
• Et replikeringsdestinationssystem er indirekte beskyttet mod større kapacitetsproblemer på en replikeringskilde. Situationen kan dog opstå på begge maskiner, hvis en af dem styres dårligt ud fra et kapacitetsperspektiv.
• Relateret artikel: Avamar viser op til ~ 30% brug, selv efter at alle sikkerhedskopier er blevet slettet og affald indsamlet

Sikkerhedskopier stadig i MC_DELETED:

• Et sjældent scenarie at være opmærksom på er, hvor en klient slettes på kilden, men dens sikkerhedskopier bevares. Dette kan resultere i, at kilden har en højere udnyttelse end målet, hvor sikkerhedskopierne forventes at udløbe naturligt. Brug af scriptet dump_root_hashes.rb med indstillingen backupcompare hjælper med at kontrollere dette scenarie.

Data på målsystemet fra ikke-replikerede sikkerhedskopier:

• Hvis systemet replikerer i *kun én retning*, skal du kontrollere på målet, at der ikke findes nogen klienter uden for /REPLICATE og MC_SYSTEM.

Anden adfærd:

• Replikeringsjob er muligvis ikke udført pålideligt. Data, der sendes til målet, kan "halte bagefter" kilden med flere dage.
• Begge systemer indeholder den samme mængde deduplikerede data, men mængden af paritetsomkostninger på hver af dem er forskellig. Dette sker i følgende scenarie: 
  • Et Avamar-kildesystem er næsten fyldt. 
  • Mange sikkerhedskopier slettes fra kildesystemet for at sænke kapacitetsniveauet. 
  • Replikering af de deduplikerede data sker derefter fra kilde til mål. 
  • Mængden af deduplikerede data er den samme på begge systemer.
  • Kildesystemet gemmer oprindeligt mere paritetsomkostninger end målet.
• Replikering kopierer ikke fysiske striber fra kilde- til målgitter. I stedet får målgitteret lov til selv at bestemme, hvor strimler og klumper af data gemmes.
• Nogle gange kan Avamar-målsystemer gemme data mere effektivt end et kildegitter, hvor dataene oprindeligt blev sikkerhedskopieret.

Forstå replikeringsmiljøet:

• Bemærk det fulde værtsnavn på kildens Avamar-gitter.
• Undersøg replikeringskonfigurationen for de berørte systemer for at forstå, hvilke systemer der replikerer hvilke data og til hvor. 
  • Det kan hjælpe at tegne et skema over miljøet, hvis det er noget mere kompliceret end replikering fra en Avamar-server til en anden.
• Hvis kilden integreres med Data Domain (DD), skal du finde ud af, om kundens bekymring vedrører sikkerhedskopier, der replikeres mellem DD-enheder.
• Notér det fulde værtsnavn for Avamar-destinationsgitteret og eventuelle tilknyttede DD-enheder, der modtager replikerede sikkerhedskopier.

Kontroller nettets generelle tilstand og situation:

• Kør det proaktive kontrolscript på begge gitre, og få en kopi af hc_results.txt og gennemgå for at forstå den overordnede situation med systemet. 

Hvor alvorlig er kapacitetsforskellen?

• Kunden skal levere et skærmbillede, der viser, hvad de ser på, hvilket får dem til at tro, at der er en forskel i kapacitetsforbrug mellem kilde og mål.
• Vi mener ikke, at der er grund til alarm, hvis kapacitetsforskellen er mindre end 5%.
• Kontroller Avamar-administratorbrugergrænsefladen for at forstå niveauerne for Avamar-serverkapacitet og (hvis Data Domain er integreret) metadatakapacitet.
• Vær opmærksom på, hvordan kapacitetsskærmen for brugergrænsefladen fungerer (beskrevet i Avamar UI-dashboardet i v7.2 og nyere viser udnyttelse af metadata i stedet for Avamar-udnyttelse).
• Kør følgende kommando på begge systemer. Serverudnyttelsesværdien giver en samlet værdi af Avamar-serverens (men ikke Data Domain) kapacitetsniveauer:

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

Server utilization               3.7%

Kontroller, at hardwaren er den samme på begge gitre:

• Det giver kun mening at sammenligne kapacitetsforskelle for "lignende" systemer. 
• Brug det proaktive kontroloutput til at notere den type noder, der findes i systemet.
• Følgende kommando viser et samlet antal, størrelse og pladsforbrug på de fysiske noder:

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

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

• Dette output gør det nemt at bestemme antallet og størrelsen af noderne i systemet. De er (23, 3 / 3 = ~ 7, 8 TB). 
• Antallet og størrelsen af harddiskpartitionerne på hver node skal bekræfte dette.

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

• Med disse oplysninger skal du kontrollere følgende:

Kontrollér softwareversionen og konfigurationen:

• Brug outputtet fra status.dpn-kommandoen til at sammenligne den version af Avamar, der kører på hvert system.
• For systemer med flere noder skal du bekræfte, at begge er konfigureret med RAIN-paritet pr. Avamar – Sådan afgøres det, om en server er RAIN eller Non-RAIN
• Kontrollér og sammenlign de to systemers kapacitetsrelaterede Avamar-serverkonfigurationsparametre. F.eks.:

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"

Kontroller stribebalancering:

• Kontroller status.dpn-outputtet, og noter det samlede antal striber på hver datanode. Antallet af striber er angivet i parentes (f.eks. onl:xxx). 
• Der skal være mindre end 2 % forskel mellem det samlede antal striber på hver datanode.

Kontrollér, at affaldsindsamlingen har kørt korrekt på begge systemer:

• Hvis affaldsindsamlingen ikke kører konsekvent og effektivt, fjerner den ikke udløbne data. Systemet rapporterer om et højere kapacitetsforbrug end forventet. 
  • Se artiklen GC-opløsningssti i de begrænsede bemærkninger for at få flere oplysninger.

Bekræft, at replikeringen er fuldført:

• Kontrollér, at alle replikeringsopgaver fra kilde til mål er fuldført korrekt. Hvis dette ikke er sket, kan det være, at der stadig er data, der skal replikeres fra kilde til mål.

Kontrollér replikeringskonfigurationen:

• Kontroller replikeringskonfigurationen (i brugergrænsefladen, CLI eller logfiler) for et af følgende flag:

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

--expiredelta

--retention-types

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

Kontroller indtagelses- og datafjernelseshastighederne for begge systemer:

• Kør proactive_check.pl--kapacitet på begge systemer, og sammenlign indtagelseshastighederne for både kilde- og målsystemer.
• Hvis målet udelukkende er et målsystem og modtager ALLE sikkerhedskopier fra kilden, skal dets indtagelseshastighed nøje følge kildens indtagelseshastighed.
• Kolonnerne Avamar NEW eller DDR NEW viser, hvor mange nye data der føjes til disse systemer.
• Vær også meget opmærksom på kolonnerne "fjernet", "min" og "pass" for at forstå affaldsindsamlingsadfærd på begge systemer.
• Disse oplysninger giver et klart overblik over, hvad der sker på begge systemer.
• Du kan finde flere oplysninger om fortolkning af outputtet under Avamar: Sådan administreres kapaciteten med capacity.sh scriptet

Dump en liste over sikkerhedskopier, der findes på hvert system:

• Scriptet dump_root_hashes.rb er et hjælpeprogram, der hjælper med at sammenligne forskellen i sikkerhedskopier, der gemmes mellem en Avamar-kilde og et målsystem. Dette er selvom sikkerhedskopierne hostes på Data Domain-lager.   
• Se Avamar: Avamar: Sådan bruges scriptet dump_root_hashes.rb til at generere en liste over klienter og sikkerhedskopier for at få oplysninger om download af hjælpeprogrammet og brugsscenarier, herunder sammenligning af indholdet af to Avamar-systemer.
  • Kør værktøjet. Kontroller, om der er uoverensstemmelser i antallet af sikkerhedskopier på alle klienterne. Vær opmærksom på forskelle på +/-2).  
• Som diskuteret i afsnittet Årsager resulterer asymmetrisk kapacitetsstyring i forskelle mellem de to systemer. Gennemse outputtet for at afgøre, om dette kunne være scenariet.
• Også:
  • Kontrollér destinationen for data på målsystemet fra ikke-replikerede sikkerhedskopier.
  • Kontroller kilden for data, der ikke blev replikeret til målet.

Kontroller, om der er forskellige stribestrukturer (f.eks. flere paritetsstriber på ét system):

• Da de er uafhængige, kan de to Avamar-systemer have forskellige stribestrukturer. Systemer med flere noder kan udvise forskelle på grund af deres brug af paritetsstriber til beskyttelse af data. Afhængigt af deres kapacitetshistorik indeholder to systemer med flere noder de samme sikkerhedskopier, men det ene kan have et højere antal paritetsstriber end det andet.  
• Ligesom almindelige striber forbliver der en paritetsstribe på systemet, når den er oprettet. I modsætning til almindelige striber bruger den altid en fast mængde plads i Avamar, selvom deres paritetsgruppe-sikre striber ikke indeholder data. Affaldsindsamling har ingen effekt på denne adfærd.
• Et replikeringsdestinationssystem er indirekte beskyttet mod større kapacitetsproblemer på en replikeringskilde. Situationen kan dog opstå på begge maskiner, hvis en af dem styres dårligt ud fra et kapacitetsperspektiv.
• Relateret artikel:  Avamar viser op til ~ 30% brug, selv efter at alle sikkerhedskopier er blevet slettet og affald indsamlet

Sikkerhedskopier stadig i MC_DELETED:

• Et sjældent scenario at være opmærksom på er, hvor en klient blev slettet på kilden, men dens sikkerhedskopier blev bevaret. Dette resulterer i, at kilden har en højere udnyttelse end målet, hvor sikkerhedskopierne forventes at udløbe naturligt. Brug af dump_root_hashes.rb-scriptet med indstillingen backupcompare bør hjælpe med at kontrollere dette scenarie.