Avamar GSAN- eller brukerkapasitetsløsningsbane

Hvis du vil ha innledende konsepter og forståelse av operativsystemkapasitet (OS), kan du se Avamar: Generell opplæring for kapasitet – oppløsningsbane

Det er ofte enklest å vurdere GSAN Kapasitet som plass og utnyttelse for sikkerhetskopiering av klienter.

• Grunnleggende forståelse av deduplisering
• Grunnleggende forståelse av sjekkpunkt, sjekkpunktvalidering (hfscheck), og søppelsamlingen, og betydningen av hver.
• Forskjellen mellom GSAN (eller bruker) Kapasitet og operativsystemkapasitet
• Endringshastighet
• Fast tilstand

• Sikkerhetskopierings- eller replikeringsfeil når rutenetttilgangstilstanden er endret til "admin mode"

  • En sikkerhetskopieringsjobb for klient kan mislykkes med en melding som ligner på følgende:  »avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• Den automatiske deaktiveringen av sikkerhetskopieringsplanleggeren (til noen bekrefter det og fjerner den)

• 80 % – kapasitetsadvarsel
• 95 % – Helsekontrollgrensen er nådd (dette kan noen ganger deaktivere sikkerhetskopieringsplanleggeren, i det minste til den bekreftes manuelt)
• 100 % – Grensen for skrivebeskyttet beskyttelse for serveren er nådd (rutenettet går inn i administratormodus)

1. Avamar trenger bare å lagre og lagre de mindre endringene og forskjellene mellom hver sikkerhetskopieringsjobb for klient på grunn av deduplisering. Etter hvert som nye sikkerhetskopier (eller innkommende replikering) kjører, kan den legge til nye data og øke Avamar-kapasiteten eller utnyttelsesverdien. 
2. Etter en viss tid utløper sikkerhetskopier basert på konfigurert oppbevaring og utløp, og finnes ikke i Avamar-rutenettet som er tilgjengelige for gjenoppretting. 
3. Når Avamar-vedlikeholdsjobben kalt Garbage Collection (GC) kjører, finner den alle de unike delene eller bitene av data som ikke lenger er nødvendige på grunn av disse utløpte sikkerhetskopiene. GC kontrollerer at ingen andre gjeldende sikkerhetskopier deler de samme dataene (på grunn av deduplisering), og deretter fjernes eller frigjøres de databitene som ikke lenger er nødvendige for å redusere Avamar-serverkapasiteten eller -utnyttelsen.

Når mengden daglige innkommende data som legges til, er omtrent den samme som mengden daglige data som renses, kalles dette "Steady State". Dette er målet for hvert eneste Avamar-rutenett som installeres.

Før et nytt Avamar-rutenett konfigureres og konfigureres, utføres generelle beregninger av dimensjonering før installasjon for å fastslå kapasiteten som kreves for å lagre de sikkerhetskopierte dataene. Disse beregningene er basert på kundenes oppbevaringskrav og hvor mye data som skal sikkerhetskopieres. Den anslår også hvor mye av disse dataene som kan deduplisere i gjennomsnitt og så videre.

1. Søppelrydding kjører ikke konsekvent
2. Søppelinnsamlingsytelsen er treg eller ikke lenge nok
3. Dedupliseringsestimater før installasjon av Avamar-nettet var ikke nøyaktige nok
4. Andre data enn det som ble beregnet før Avamar-rutenettinstallasjonen, sikkerhetskopieres til denne Avamar-serveren.
5. Andre grunner

Kontroller at hvert feilsøkingstrinn nedenfor gjelder for miljøet:

Trinn 1. Innsamling av data:

Kontroller at det ikke er andre problemer uten kapasitet med Avamar-rutenettet. Hvis det er det, kan de kreve oppmerksomhet FØR feilsøkingskapasitet.

Dette inkluderer maskinvarefeil, problemer med dataintegritet (inkludert frakoblede noder), frakoblede striper, valideringsfeil ved kontrollpunkt eller sviktende vedlikeholdsjobber. Hvis noe av dette er et problem, må kapasitetsfeilsøking stoppes og andre problemer løses. Når andre problemer er løst, kan du gå tilbake til kapasiteten.

Det skal kjøres en tilstandskontroll (Avamar: Slik kjører du proactive_check.pl-tilstandskontrollskriptet på en Avamar-server, men minst status.dpn Kommandoen kan gi en rask oversikt og bekreftelse på de fleste av de samme problemene. Se Avamar: Slik forstår du utdataene som genereres av status.dpn-kommandoen

Se følgende artikkel hvis du vil ha mer informasjon: Avamar: Slik bruker du tilnærmelsen "Avamar troubleshooting hierarchy" på riktig måte.

Hvis det er nødvendig med assistanse for å løse problemer som ikke er kapasitetsproblemer, oppretter du en serviceforespørsel med Dell Technologies Avamar-støtteteamet.

Trinn 2. Innsamling av kapasitetsinformasjon: 

Se følgende for all nødvendig informasjon som kreves for å feilsøke Avamar-kapasitetsproblemer: Avamar: Slik samler du inn informasjonen for å feilsøke kapasitetsproblemer

I det minste er status.dpn -kommandoen eller -verdiene i Avamar-administrasjonsgrensesnittet viser GSAN kapasitet.

Trinn 3. Kontroller om kapasiteten i operativsystemet er full:

Følgende kommando hjelper deg med å vise gjeldende verdi for OS-kapasiteten for hver diskpartisjon. Hvis noen av verdiene har nådd eller overskredet 85%, som i den andre prøveutgangen, regnes det som høy OS-kapasitet:

avmaint nodelist | egrep 'nodetag|fs-percent-full'

Eksempel på utganger:

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"

nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"

Bare hvis OS-kapasiteten er under 85 %, skal GSAN Feilsøking av kapasitet fortsetter. 

Trinn 4. Problemer med manglende kapasitet som noen ganger kan misforstås som kapasitet:

Det er mulig at sikkerhetskopier av klienter mislykkes, ikke av kapasitetsgrunner, men i stedet er "kvote"-årsaker. Disse kan noen ganger misforstås som kapasitet.

Denne situasjonen kan bekreftes av status.dpn kommando eller noen av de andre innsamlede utdataene som viser lavere kapasitet.

Det er også mulig at klientsikkerhetskopier mislyktes eller ikke kjøres på grunn av andre Non-GSAN Kapasitetsgrunner. Den innsamlede informasjonen skal bekrefte dette, eller den kan også vises i administrasjonsgrensesnittet for Avamar.

• Avamar: Oppløsningsbane for metadatakapasitet
• Data Domain: Høy kapasitet fra Avamar-integreringsbane

Hvis GSAN Kapasiteten er høy, og disse andre kapasitetene er også høye, feilsøking kan utføres i hvilken som helst rekkefølge (unntatt OS-kapasitet som alltid må være først).

Trinn 5. Stripebalanse og OS-diskbalanse:

"Striper" på Avamar er beholderfilene som sikkerhetskopierte data lagres i på datanodene (bortsett fra Avamar-rutenett med én node).

Forventningen er at stripene er "balansert" eller jevnt fordelt over de forskjellige diskene og nodene i rutenettet, men noen ganger kan de bli ubalanserte.

Den største node- eller diskpartisjonen er den begrensende faktoren når det gjelder Avamar-kapasitet som er designet for Avamar.

Dette er tilsiktet, så ingen av diskene eller nodene lager flere striper enn de kan håndtere (eller tillatt), derfor er det viktig for kapasiteten å ha balanserte striper.

Når du for eksempel legger til flere datanoder for Avamar-rutenettutvidelse, må du kjøre balansering for å fordele stripene jevnt til de nye nodene for å redusere den totale Avamar-kapasitetsprosenten.

En annen type balanse som krever forståelse er OS Diskbalanse. Dette er bare begrenset til datapartisjoner på samme node, ikke partisjoner på flere noder. 

Hvis på samme datanode er en partisjon mye større eller mindre enn en annen partisjon av den SAMME noden, kan en grense overskrides kalt "freespaceunbalance». Selv om dette vanligvis er på operativsystemet og ikke GSAN Kapasitet, kan den rapporteres som en GSAN Kapasitetsproblem.

Trinn 6. Sjekk om søppelhentingen er ferdig: 

Kjør følgende kommando for å få informasjon om søppelrydding:

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"

Ideelt sett vil utgangen vise at GC har fullført de siste 30 dagene:

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection

GC-feilmeldinger kan inkludere, men ikke være begrenset til, følgende:

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR

2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS

2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER

2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT

Hvis GC har mislyktes, adresser dette først ved å bruke følgende artikkel som referanse: Avamar: Feilsøke feil ved søppelrydding (GC) (oppløsningsbane)
(Hvis problemene allerede er løst, går du til neste trinn.)

Trinn 7. Kjører GC lenge nok?

en. Kjør følgende kommando for å sjekke maksimal tid tillatt for GC:

dumpmaintlogs --types=gc --days=30 | grep gcflags 

Eksempel på utdata:

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>

Noter deg maxtime verdi, som i dette eksemplet er 14400 (sekunder).
(En verdi på 0 betyr ubegrenset)

b. Kjør følgende kommando for å finne ut hvor lenge GC kjører, og hvor mange "passerer" fullføre:
(Pass har å gjøre med lagene i de lagrede sikkerhetskopidataene. Tenk på GSAN Kapasitet som lag på en løk. De ytre lagene må trekkes tilbake eller fjernes før de indre lagene sees. Hvert pass er et lag av GSAN lagrede data.)

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20

Eksempel på utdata:

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

Legg merke til antall passeringer og elapsed-time (sekunder).

c. Forutsatt at maxtime er ikke-null, beregner 2/3 av maxtime, og sammenlign den med tiden som har gått.
(I eksemplet ovenfor er 2/3 av 14400 9600, og alle utganger er godt under dette tallet.)

Ulike problemer kan føre til at GC kjører sakte, eller ikke skanner alt. Dette kan inkludere at du ikke har hatt nok tid til å kjøre i betydelig tid eller dager tidligere, feil konfigurasjon, feil konfigurasjon og mer.

Hvis det er bekymringer om maxtime, eller antall passeringer, oppretter du en serviceforespørsel med Dell Technologies Avamar-støtteteamet for å undersøke nærmere.

Trinn 8. Hvis det mistenkes at GC ikke fjernet nok eller de forventede dataene:

Hvis det bekreftes at GC kjører lenge nok, er det mulig at data ikke samles inn av grunner utenfor søppelinnsamlingskontrollen. Dette er en liste over de dokumenterte årsakene som generelt bør kontrolleres:

en. Kontroller at sikkerhetskopier er konfigurert til minst å utløpe etter hvert eller regelmessig. Hvis det ikke er hyppige utløpssikkerhetskopier, vil GC ikke ha mye arbeid å gjøre.

b. Bruk denne artikkelen til å finne "Top Change Rate"-klientene: Avamar: Slik administrerer du kapasiteten med det capacity.sh skriptet. (Gjennomgå både "% OF TOTAL" og "CHGRATE".)

c. Se etter utelatte hasher per Avamar: Avamar Garbage Collection rapporterer "hoppe-hashes" som ikke kan ryddes opp. Hvis disse forekommer, men sjeldne, er dette normalt, og dette kan hoppes over.

d. Det finnes et flagg eller alternativ som tvinger Avamar-serveren til å beholde den siste og nyeste sikkerhetskopien fra hver klient. Dette brukes for sikkerhetsformål, slik at en klient ikke har hver sikkerhetskopi ved et uhell utløpt. Dette kan imidlertid forårsake andre problemer når det gjelder dataopprydding og søppelinnsamling. Dell Technologies Avamar-støtteteamet kan bekrefte om dette er aktivert.

e. Hvis sikkerhetskopier nylig ble byttet fra GSAN til DD-backend eller det oppstod et uhell GSAN sikkerhetskopien, men GSAN Kapasiteten reduseres ikke. Opprett en serviceforespørsel med Dell Technologies Avamar-støtteteamet for å undersøke nærmere.

Trinn 9. Avamar-rutenettet er underdimensjonert for mengden gjeldende eller forventede data som skal legges til:

Når alle andre løsninger og mulige årsaker er vurdert for høy kapasitet, og dette ikke er et konfigurasjonsproblem eller problem med utilsiktede data:

Dette betyr at data kan kreve sletting, eller alternativer utforskes, for eksempel overføring av bestemte klienter til andre Avamar-rutenett, legge til nye datanoder og så videre.

Trinn 10. Bekrefte eventuelle kapasitetshendelser, og gjenoppta sikkerhetskopieringsplanleggeren om nødvendig:

en. Når kapasitetsproblemer er løst, må du bekrefte alle kapasitetsrelaterte hendelser i Avamar-administrasjonsgrensesnittet.

b. Gjenoppta sikkerhetskopieringsplanleggeren:

dpnctl start sched

Hvis du vil ha andre spørsmål om Avamar-kapasitet, opplæring, feilsøking og mye mer, kan du se: Avamar: Feilsøking av kapasitet, problemer og spørsmål – All kapasitet (løsningsbane)

• Denne handlingen i seg selv kan "maskere" og skjule de virkelige problemene, og bare få dem til å dukke opp igjen om noen dager eller uker senere, noe som fører til at denne manuelle jobben blir bortkastet tid.
• I tillegg kan det hende at den manuelle GC ikke kjører så effektivt som den går tom for planen.
  • Noen ganger kan det gjøre andre problemer verre. Hvis du vil ha mer informasjon, kan du se: Avamar: Om bruk av manuell søppelrydding

• Denne endringen eller handlingen utføres vanligvis ikke og bør ikke vurderes som standard. En Avamar L2-tekniker eller fagekspert (SME) må godkjenne denne endringen.
• Dessverre kan slike handlinger ofte forårsake permanent skade på et Avamar-rutenett på ulike måter som bare kan løses ved å legge til ekstra lagringsnoder eller omdisponere.

Forstå at ingen av handlingene som er oppført ovenfor, utføres fordi kundestøtteteamet ønsker å bidra til å løse kapasitetsproblemene på den mest fordelaktige måten.