Avamar: Operativsystemkapasitet (OS) (oppløsningsbane)

Hvordan håndtere eller feilsøke problemer med operativsystemkapasitet på Avamar.

Denne artikkelen om løsningsbanen er utformet for å løse eller feilsøke problemer med operativsystemkapasiteten på Avamar.


Hvis du vil ha innledende konsepter og forståelse av OS-kapasitet, kan du se opplæringsartikkelen Avamar: Konsepter og opplæring

for kapasitetsstyringSom oppsummert fra opplæringsartikkelen, bør det kreves en rimelig forståelse av følgende emner for å fortsette med resten av denne artikkelen:

• En grunnleggende forståelse av sjekkpunkter (cp), sjekkpunktvalidering (hfscheck), og søppelsamling (GC), og betydningen av hver enkelt
• Forskjellen mellom GSAN (aka "User Capacity" og OS Capacity)
• Overhead-data for sjekkpunkt
• Hvis noen av datapartisjonene er mer enn 89 % av den totale fysiske OS-kapasiteten, kan ikke søppelrydding kjøres.
• Jo nærmere et Avamar-rutenett er 100 % brukerkapasitet, jo mindre OS-kapasitet er tilgjengelig for administrasjonskostnader for sjekkpunkter.
• Faktorer som bidrar til kontrollpunktoverhead, inkludert asynkron knusing og antall lagrede sjekkpunkter, HFSCheck og kontrollpunktvalidering, viktighet og så videre.
• Slik finner du kapasitetsnivåene for operativsystemet
• Grunnleggende tiltak for å redusere OS-kapasiteten

Det er ofte enklest å betrakte OS-kapasiteten som størrelsen på GSAN data (mer spesifikt plassen som er tildelt for disse dataene) og administrasjonskostnadene som genereres av Avamar-sjekkpunkter. Jo større antall sjekkpunkter og jo høyere endringsfrekvens, desto høyere sjekkpunkt overhead.

Virkninger av høy OS-kapasitet kan omfatte:

• Feil ved søppelrydding: GC mislykkes med MSG_ERR_DISKFULL hvis OS-kapasiteten stiger over 89 %
• Feil ved sikkerhetskopiering eller replikering: Sikkerhetskopiering eller innkommende replikering kan mislykkes med MSG_ERR_STRIPECREATE hvis OS-kapasiteten stiger over 90 %. (Dette er bare hvis en ny datastripe må opprettes. Hvis en ny stripe ikke er nødvendig, kan det hende at sikkerhetskopiering og replikering likevel kjøres.)
• Feil på kontrollpunkt: Et sjekkpunkt mislykkes med MSG_ERR_DISKFULL hvis kapasiteten i operativsystemet stiger over 96 %

Som det ovennevnte kan indikere, er OS-kapasitet ofte den første typen Avamar-kapasitet som må håndteres når andre Avamar-kapasiteter også er høye. Det minste kan ikke søppelrydding kjøres når OS-kapasiteten når visse nivåer, selv når GSAN Eller brukerkapasiteten er også høy.

Generelt anses OS-kapasiteten som høy når GC mislykkes med MSG_ERR_DISKFULL hvis OS-kapasiteten stiger over 89%. Hvis operativsystemkapasiteten i det hele tatt er mindre enn 89 %, påvirkes ingen vedlikeholdsjobber. 

Avamar OS-kapasiteten kan øke på grunn av en kombinasjon av følgende årsaker:

• Høy endringsfrekvens for sikkerhetskopieringsdata, og legger til "for mye for fort"
• Høy GSAN eller "Brukerkapasitet" som gir mindre plass til OS-kapasitet og noen ganger til og med kan resultere i høyere endringsfrekvenser
• Kontrollpunktet fullføres ikke, noe som resulterer i statusen "MSG_ERR_DISKFULL" som vist i utdataene.
• En kontrollpunktvalidering (hfscheck) har feilet eller ikke kjørt nylig, slik at eldste sjekkpunkter ikke kan rulle av eller fjernes
• Kontrollpunkter ruller ikke av av andre grunner, inkludert for høye innstillinger for oppbevaring av sjekkpunkter

Høy OS-kapasitet på andre diskpartisjoner kan oppstå av ulike årsaker, inkludert feil dataplassering, at loggfilene blir for store, og så videre.

• Hvis du vil ha en rask bakgrunn, er Avamar-sjekkpunkter et skrivebeskyttet øyeblikksbilde og en kobling til dataene i sanntid. Siden dette opprettes med koblinger, vil et kontrollpunkt bruke null ekstra diskplass umiddelbart etter at det er opprettet. Hvis det ikke er noen endringer i sanntidsdataene, bruker ikke sjekkpunktet ekstra plass.
• Dette endres etter hvert som sanntidsdataene endres mens kontrollpunktet forblir det samme. På det tidspunktet er det en original kopi av dataene i sjekkpunktet og den oppdaterte live-kopien av de endrede dataene. Dette er helt av design og tilsiktet. Dette er grunnen til at det er reservert OS-kapasitetsplass.
• Hvis imidlertid mengden eller hastigheten på endringsdata øker drastisk og plutselig, kan dette føre til en uvanlig økning i OS-kapasitetsstørrelsen og betraktes som "for mye for fort"
• Informasjonen i capacity.sh verktøyet vil vise dette som årsak når man sammenligner utdataene over flere dager.

Hvis vedlikeholdsjobber, inkludert søppelhenting, svikter fra høy Avamar OS-kapasitet, følger du denne fremgangsmåten:

1. Samle inn all informasjon om Avamar-kapasitet for å tegne et bilde av situasjonen: Avamar: Slik samler du inn informasjonen som kreves for å feilsøke kapasitetsproblemer.

2. Gå deretter gjennom hvor høy kapasiteten i operativsystemet er, og hvilke tiltak som kan være nødvendige. Fra datainnsamlingsartikkelen finner du dette ved hjelp av følgende kommando: 

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

Måten Avamar fungerer på, er at den HØYESTE verdien for fs-percent-full som vises, er den begrensende faktoren for gjeldende operativsystemkapasitet. Avhengig av nodetype, generering og størrelse, kan antall datapartisjoner som lagrer sikkerhetskopi- og kontrollpunktdata, variere. Som vist fra Linux-operativsystemet, kan dette være disker eller partisjoner som "/data0*", der "*" kan være et enkelt siffer. Antall datapartisjoner avhenger av nodetype, maskinvaregenerering og størrelse (og kan ikke endres).

3. Se gjennom antall kontrollpunkter som er funnet, og hvor nylig de er validert fra kommandoen:

cplist

cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980

4. Kontroller om kontrollpunktoperasjoner mislykkes fra "MSG_ERR_DISKFULL" ved å kjøre følgende kommando:

dumpmaintlogs --types=cp --days=4 | grep "\<430"

Hvis kontrollpunktene er fullført, vises utdata som ligner på følgende:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

Hvis feilen mislykkes på grunn av MSG_ERR_DISKFULL, vises disse utdataene:

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance

6. Bestem endringshastigheten:

capacity.sh  

Eksempel på utdata:

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

Noen ganger hvis den høye endringsfrekvensen eller "for mye for fort" situasjonen gjentar seg, kan dette lindres ved å senke den generelle GSAN eller brukerkapasitet. Med en lavere GSAN kapasitet, er det litt mer plass til OS Capacity overhead og resulterer også i færre endringer i datalagringsbeholderen også. Hvis du trenger hjelp med dette scenariet, åpner du en serviceforespørsel med Dell Technologies Avamar-støtteteamet, ellers fortsetter du fra trinn 7.

7. Problemer med høy OS-kapasitet på andre diskpartisjoner har ulike årsaker, men løsningene krever teknisk støtte. Åpne en serviceforespørsel med Dell Technologies Avamar-støtteteamet, ellers fortsetter du fra trinn 7.

Når OS-kapasiteten er adressert, GSAN Du kan gjennomgå kapasitet eller andre Avamar-kapasiteter. Se Avamar-kapasitetsfeilsøking, problemer og spørsmål – All kapasitet (løsningsbane)