Avamar: Et replikerende par viser ulike nivåer av kapasitetsbruk. Hvordan undersøke årsakene.

Årsaker og mulige årsaker til forskjellene mellom verdiene for serverutnyttelse:

Logiske eller fysiske forskjeller mellom rutenettene:

• Et annet antall datanoder på kilde- og målrutenettene.
• Datanodene i hvert rutenett har forskjellige diskkonfigurasjoner.
• Tilstrekkelig balansert fordeling av striper på tvers av datanodene i hvert system (innen 2 %)
• Krav til lagring og paritet varierer mellom Avamar-versjoner. En forskjell i bruken kan observeres hvis kilde- og målprogramvareversjoner er forskjellige.
• Skrivebeskyttet nivå for Avamar-serverdisk kan variere mellom de to rutenettene.   
• Ett rutenett kan konfigureres for RAIN-paritet, der det andre ikke kan.

Konfigurasjon av replikering:

• Sikkerhetskopier som replikeres til målsystemet, kan ha en annen oppbevaringspolicy sammenlignet med kilden. Se gjennom expiredelta-flagget hvis du vil ha mer informasjon. Det kan også hende at de replikerte sikkerhetskopiene bare dekker en bestemt tidsperiode. For eksempel de siste 4 ukene med sikkerhetskopier fra kilden.
• Replikering kan konfigureres til å replikere bare et delsett av klienter fra kildesystemet til målsystemet. Kontroller om du bruker innstillingene "include" eller "exclude".
• Klienter og tilhørende sikkerhetskopier kan ha blitt slettet fra kildesystemet. Sletting av en klient eller sikkerhetskopier på kilden fjerner ikke de samme sikkerhetskopiene fra målsystemet. Sikkerhetskopiene forblir på målet til de utløper i henhold til oppbevaringsinnstillingene.
• Oppbevaringspolicyer kan endres for sikkerhetskopier eller klienter på kildesystemet. Endringen i oppbevaringspolicyer påvirker bare nye sikkerhetskopier. Nye sikkerhetskopier replikeres til målet og overholder den oppdaterte retningslinjen for oppbevaring. Sikkerhetskopier som allerede eksisterer på målet, beholder oppbevaringspolicyen som ble brukt på dem da de ble replikert.

Tidligere aktivitet for kapasitetsstyring:

• Det er ikke uvanlig at kunder legger merke til at et av Avamar-replikeringsparsystemene nærmer seg kapasiteten og deretter reduserer kapasiteten. Husk – et Avamar-replikeringspar består av to uavhengig administrerte systemer. Hvis handlinger utføres på ett system, må de også utføres på det andre. 
• Hvis sikkerhetskopier slettes eller oppbevaring reduseres på kildesystemet, må identiske endringer gjøres på målet. Den beste måten å administrere kapasitet på denne måten er med modify-snapups-skriptet. Dette kan kjøres på begge Avamar-serverne med samme alternativer for endring eller sletting av sikkerhetskopiering.  

Ulike stripestrukturer (for eksempel flere paritetsstriper på ett system):

• Siden de er uavhengige av hverandre, kan to Avamar-systemer ende opp med ulike stripestrukturer. Multinode-systemer kan vise forskjeller på grunn av deres bruk av paritetsstriper for å beskytte data. Avhengig av kapasitetshistorikken inneholder to systemer med flere noder de samme sikkerhetskopiene, men det ene kan ha et høyere antall paritetsstriper enn det andre.
• I likhet med vanlige striper forblir det alltid en paritetsstripe på systemet når den er opprettet. I motsetning til vanlige striper bruker den alltid en fast mengde plass i Avamar-serveren. Dette gjelder selv om deres sikre striper for paritetsgrupper ikke inneholder data. Søppelsamling har ingen innvirkning på denne oppførselen.
• Et replikasjonsmålsystem er indirekte beskyttet mot store kapasitetsproblemer på en replikeringskilde. Situasjonen kan imidlertid oppstå på begge maskinene hvis en av dem er dårlig styrt fra et kapasitetsperspektiv.
• Relatert artikkel: Avamar viser opptil ~30 % bruk selv etter at alle sikkerhetskopier er slettet og søppel er samlet inn

Sikkerhetskopier som fortsatt er i MC_DELETED:

• Et sjeldent scenario å være klar over er hvor en klient slettes på kilden, men sikkerhetskopiene beholdes. Dette kan føre til at kilden får en høyere utnyttelse enn målet der sikkerhetskopiene forventes å utløpe naturlig. Bruk av dump_root_hashes.rb-skriptet med alternativet backupcompare bidrar til å se etter dette scenariet.

Data på målsystemet fra ikke-replikerte sikkerhetskopier:

• Hvis systemet replikerer i *bare én retning*, kontrollerer du målet at det ikke finnes noen klienter utenfor /REPLICATE og MC_SYSTEM.

Annen atferd:

• Replikeringsjobber er kanskje ikke fullført på en pålitelig måte. Data sendt til målet kan "henge etter" kilden med flere dager.
• Begge systemene inneholder samme mengde dedupliserte data, men mengden paritetskostnader på hver av dem er forskjellig. Dette skjer i følgende situasjon: 
  • Et Avamar-kildesystem er nesten fullt. 
  • Mange sikkerhetskopier slettes fra kildesystemet for å senke kapasitetsnivået. 
  • Replikering av de dedupliserte dataene skjer deretter fra kilde til mål. 
  • Mengden dedupliserte data er den samme på begge systemene.
  • Kildesystemet lagrer i utgangspunktet mer paritetskostnader enn målet.
• Replikering kopierer ikke fysiske striper fra kilde til målrutenett. I stedet får målrutenettet lov til å bestemme seg selv hvor strimler og biter av data lagres.
• Noen ganger kan målrettede Avamar-systemer lagre data mer effektivt enn et kilderutenett der dataene opprinnelig sikkerhetskopieres.

Forstå replikeringsmiljøet:

• Legg merke til det fullstendige vertsnavnet for Avamar-rutenettet.
• Undersøk replikeringskonfigurasjonen til de berørte systemene for å forstå hvilke systemer som replikerer hvilke data og hvor. 
  • Det kan hjelpe å tegne et skjema over miljøet hvis det er noe mer komplisert enn replikering fra én Avamar-server til en annen.
• Hvis kilden integreres med Data Domain (DD), kan du finne ut om kundens bekymring gjelder sikkerhetskopier som er replikert mellom DD-enheter.
• Noter deg det fullstendige vertsnavnet til Avamar-rutenettet og eventuelle tilknyttede DD-enheter som mottar replikerte sikkerhetskopier.

Sjekk den generelle helsen og situasjonen til rutenettet:

• Kjør det proaktive kontrollskriptet på begge rutenettene, og få en kopi av hc_results.txt og gjennomgå for å forstå den generelle situasjonen med systemet. 

Hvor stor er kapasitetsforskjellen?

• Kunden bør sende inn et skjermbilde som viser hva de ser på, noe som får dem til å tro at det er en forskjell i kapasitetsforbruk mellom kilde og mål.
• Vi anser det ikke som grunn til alarm dersom kapasitetsforskjellen er mindre enn 5 %.
• Kontroller brukergrensesnittet for Avamar-administrator for å forstå nivåene av Avamar-serverkapasitet og (hvis Data Domain er integrert) metadatakapasitet.
• Vær oppmerksom på hvordan visningen av brukergrensesnittkapasiteten fungerer (omtalt på Avamar-grensesnittinstrumentbordet i v7.2 og senere viser metadatautnyttelse i stedet for Avamar-utnyttelse).
• Kjør følgende kommando på begge systemene. Verdien for serverutnyttelse gir en samlet verdi for Avamar-kapasitetsnivåer (men ikke Data Domain):

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

Server utilization               3.7%

Kontroller at maskinvaren er den samme i begge rutenettene:

• Det gir bare mening å sammenligne kapasitetsforskjeller for "like" systemer. 
• Ved hjelp av den proaktive kontrollutgangen noterer du hvilken type noder som finnes i systemet.
• Følgende kommando viser et samlet antall, størrelse og plassforbruk på de fysiske nodene:

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

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

• Denne utgangen gjør det enkelt å bestemme antall og størrelse på nodene i systemet. De er (23,3 / 3 = ~ 7,8 TB). 
• Antallet og størrelsen på harddiskpartisjonene på hver node må bekrefte 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

• Kontroller følgende med denne informasjonen:

Kontroller programvareversjonen og konfigurasjonen:

• Bruk utdataene fra status.dpn-kommandoen til å sammenligne Avamar-versjonen som kjører på hvert system.
• For systemer med flere noder bekrefter du at begge er konfigurert med RAIN-paritet per Avamar – Slik fastslår du om en server er RAIN eller Non-RAIN
• Kontroller og sammenlign de to systemenes kapasitetsrelaterte Avamar-serverkonfigurasjonsparametere. Eksempel:

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"

Sjekk stripebalansering:

• Kontroller status.dpn-utdataene, og noter totalt antall striper på hver datanode. Antall striper er angitt i parentes (for eksempel onl:xxx). 
• Det skal være mindre enn 2 % forskjell mellom det totale antallet striper på hver datanode.

Sjekk at søppeltømmingen har gått som den skal på begge systemene:

• Hvis søppelhenting ikke kjører konsekvent og effektivt, vil det ikke fjerne utløpte data. Systemet rapporterer høyere kapasitetsbruk enn forventet. 
  • Se artikkelen GC Resolution Path i de begrensede merknadene for informasjon.

Bekreft at replikeringen er fullført:

• Sikre at alle replikeringsoppgaver fra kilde til mål fullføres. Hvis dette ikke har skjedd, kan det være at det fortsatt er data som skal replikeres fra kilde til mål.

Kontroller replikeringskonfigurasjonen:

• Kontroller replikeringskonfigurasjonen (i brukergrensesnittet, CLI eller loggene) for ett av følgende flagg:

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

--expiredelta

--retention-types

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

Kontroller graden for inntak og datafjerning for begge systemene:

• Kjør proactive_check.pl-kapasiteten på begge systemene og sammenlign inntaksratene for både kilde- og målsystemer.
• Hvis målet er et rent målsystem og mottar ALLE sikkerhetskopier fra kilden, bør inntakshastigheten nøye følge inntakshastigheten til kilden.
• Kolonnene Avamar NEW eller DDR NEW viser hvor mye nye data som legges til i disse systemene.
• Vær også oppmerksom på kolonnene "fjernet", "mins" og "pass" for å forstå søppelinnsamlingsadferd på begge systemene.
• Denne informasjonen gir en klar oversikt over hva som skjer på begge systemene.
• Hvis du vil ha mer informasjon om tolkning av utdataene, kan du se Avamar: Slik administrerer du kapasiteten med det capacity.sh skriptet

Dump en liste over sikkerhetskopier som finnes på hvert system:

• dump_root_hashes.rb-skriptet er et verktøy som hjelper deg med å sammenligne forskjellen i sikkerhetskopier som er lagret mellom en Avamar-kilde og et målsystem. Dette skjer selv om sikkerhetskopiene driftes på Data Domain-lagring.   
• Se Avamar: Avamar: Slik bruker du dump_root_hashes.rb-skriptet til å generere en liste over klienter og sikkerhetskopier for informasjon om nedlasting av verktøyet og brukstilfeller, inkludert sammenligning av innholdet i to Avamar-systemer.
  • Kjør verktøyet. Se etter inkonsekvenser i antall sikkerhetskopier på alle klientene. Vær oppmerksom på forskjeller på +/-2).  
• Som diskutert i delen Årsaker, resulterer asymmetrisk kapasitetsstyring i forskjeller mellom de to systemene. Se gjennom utdataene for å finne ut om dette kan være scenariet.
• Også:
  • Kontroller målet for data på målsystemet fra ikke-replikerte sikkerhetskopier.
  • Kontroller kilden for data som ikke ble replikert til målet.

Se etter ulike stripestrukturer (for eksempel flere paritetsstriper på ett system):

• Siden de er uavhengige av hverandre, kan de to Avamar-systemene ha ulike stripestrukturer. Multinode-systemer kan vise forskjeller på grunn av deres bruk av paritetsstriper for å beskytte data. Avhengig av kapasitetshistorikken inneholder to systemer med flere noder de samme sikkerhetskopiene, men det ene kan ha et høyere antall paritetsstriper enn det andre.  
• I likhet med vanlige striper forblir en paritetsstripe på systemet når den er opprettet. I motsetning til vanlige striper bruker den alltid en fast mengde plass i Avamar, selv om de sikre stripene for paritetsgruppen ikke inneholder data. Søppelsamling har ingen innvirkning på denne oppførselen.
• Et replikasjonsmålsystem er indirekte beskyttet mot store kapasitetsproblemer på en replikeringskilde. Situasjonen kan imidlertid oppstå på begge maskinene hvis en av dem er dårlig styrt fra et kapasitetsperspektiv.
• Relatert artikkel:  Avamar viser opptil ~30 % bruk selv etter at alle sikkerhetskopier er slettet og søppel er samlet inn

Sikkerhetskopier som fortsatt er i MC_DELETED:

• Et sjeldent scenario å være klar over er hvor en klient ble slettet på kilden, men sikkerhetskopiene ble beholdt. Dette resulterer i at kilden har en høyere utnyttelse enn målet der sikkerhetskopiene forventes å utløpe naturlig. Bruk av dump_root_hashes.rb-skriptet med alternativet backupcompare bør hjelpe deg med å se etter dette scenariet.