Avamar: Operativsystemkapacitet (OS) (løsningssti)

Sådan håndterer eller foretager du fejlfinding af problemer med OS-kapaciteten på Avamar.

Denne artikel om løsningssti er beregnet til at løse eller foretage fejlfinding af problemer med OS-kapacitet på Avamar.


For indledende koncepter og forståelse af OS-kapacitet, se træningsartiklen Avamar: Kapacitetsstyringskoncepter og træning

Som opsummeret fra undervisningsartiklen bør der kræves en rimelig forståelse af følgende emner for at fortsætte med resten af denne artikel:

• En grundlæggende forståelse af kontrolpunkter (cp), validering af kontrolpunkter (hfscheck), og Garbage Collection (GC), og vigtigheden af hver
• Forskellen mellem GSAN (også kaldet "Brugerkapacitet" og OS-kapacitet)
• Faste data for kontrolpunkter
• Hvis nogen af datapartitionerne udgør mere end 89 % af den samlede fysiske OS-kapacitet, kan affaldsindsamlingen ikke køre.
• Jo tættere et Avamar-net er på 100 % brugerkapacitet, jo mindre OS-kapacitet er der til rådighed til kontrolpunktets omkostninger.
• Faktorer, der bidrager til kontrolpunktets overhead, herunder asynkron knusning, antal lagrede kontrolpunkter, HFSCheck og kontrolpunktets valideringsvigtighed osv.
• Sådan finder du operativsystemkapacitetsniveauerne
• Grundlæggende handlinger til afhjælpning af OS-kapacitet

Det er ofte nemmest at betragte OS-kapacitet som størrelsen på GSAN data (mere specifikt den plads, der er afsat til disse data) og de faste omkostninger, der genereres af Avamar-kontrolpunkter. Jo større antallet af kontrolpunkter er, og jo højere ændringshastighed, jo højere er kontrolpunktets faste omkostninger.

Påvirkninger af høj OS-kapacitet kan omfatte:

• Fejl i affaldsindsamling: GC mislykkes med MSG_ERR_DISKFULL hvis OS-kapaciteten stiger til over 89 %
• Sikkerhedskopierings- eller replikeringsfejl: Sikkerhedskopieringer eller indgående replikering kan mislykkes med MSG_ERR_STRIPECREATE, hvis OS-kapaciteten overstiger 90 %. (Dette er kun, hvis der skal oprettes en ny datastribe. Hvis der ikke er behov for en ny stribe, kan sikkerhedskopiering og replikering stadig køre korrekt.)
• Fejl ved kontrolpunkt: Et kontrolpunkt mislykkes med MSG_ERR_DISKFULL, hvis OS-kapaciteten stiger til over 96 %

Som ovenstående kan indikere, er OS-kapacitet ofte den første type Avamar-kapacitet, der skal håndteres, når andre Avamar-kapaciteter også er høje. I det mindste kan Garbage Collection ikke køres, når OS-kapaciteten når bestemte niveauer, selv når GSAN eller brugerkapaciteten er også høj.

Generelt anses OS-kapaciteten for høj, når GC fejler med MSG_ERR_DISKFULL, hvis OS-kapaciteten stiger til over 89 %. Hvis OS-kapaciteten overhovedet er mindre end 89 %, påvirkes ingen vedligeholdelsesjob. 

Avamar OS-kapaciteten kan øges af enhver kombination af følgende årsager:

• Høj ændringshastighed for sikkerhedskopieringsdata, tilføjelse af "for meget for hurtigt"
• Høj GSAN eller "Brugerkapacitet", som giver mindre plads til OS-kapacitet og nogle gange endda kan resultere i højere ændringshastigheder
• Kontrolpunktet fuldføres ikke korrekt, hvilket resulterer i status "MSG_ERR_DISKFULL", som det ses i outputtet.
• Validering af et kontrolpunkt (hfscheck) har svigtet eller ikke kørt for nylig, så ældste kontrolpunkter ikke kan rulles af eller fjernes
• Kontrolpunkter ruller ikke af andre årsager, herunder for høje indstillinger for opbevaring af kontrolpunkter

Høj OS-kapacitet på andre diskpartitioner kan opstå af forskellige årsager, herunder forkert dataplacering, logfiler, der bliver for store osv.

• For en hurtig baggrund er Avamar-kontrolpunkter et skrivebeskyttet øjebliksbillede og link til livedataene. Da dette oprettes med links, bruger et kontrolpunkt nul ekstra diskplads umiddelbart efter, at det er oprettet. Hvis der ikke er nogen ændringer i de levende data, bruger kontrolpunktet ikke ekstra plads.
• Dette ændres, når de dynamiske data ændres, mens kontrolpunktet forbliver det samme. På det tidspunkt er der en original kopi af dataene i kontrolpunktet og den opdaterede livekopi af de ændrede data. Dette er helt ved design og forsætligt. Derfor er der reserveret plads til OS-kapacitet.
• Men hvis mængden eller hastigheden af ændringsdata stiger drastisk og pludseligt, kan dette forårsage en usædvanlig stigning i OS-kapacitetsstørrelsen og betragtes som "for meget for hurtigt"
• Ikonet capacity.sh -værktøjet ville vise dette som årsagen, når man sammenligner output over flere dage.

Hvis vedligeholdelsesjob, herunder Garbage Collection, mislykkes fra høj Avamar OS-kapacitet, skal du følge disse trin:

1. Indsaml alle oplysninger om Avamar-kapacitet for at tegne et billede af situationen: Avamar: Sådan indsamler du de oplysninger, der er nødvendige for at foretage fejlfinding af kapacitetsproblemer.

2. Dernæst skal du gennemgå, hvor høj OS-kapaciteten er, og hvilke handlinger der kan være nødvendige. Fra dataindsamlingsartiklen kan dette findes ved hjælp af følgende kommando: 

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

Sådan fungerer Avamar er, at den HØJESTE værdi for fs-procent-fuld vist er den begrænsende faktor for den aktuelle OS-kapacitet. Afhængigt af nodetypegenerationen og -størrelsen kan antallet af datapartitioner, der lagrer sikkerhedskopierings- og kontrolpunktsdata, variere. Som det ses fra Linux-operativsystemet, kan disse være diske eller partitioner som "/data0*", hvor "*" kan være et enkelt ciffer. Antallet af datapartitioner afhænger af nodetypen, hardwaregenerationen og størrelsen (og kan ikke ændres).

3. Gennemgå antallet af fundne kontrolpunkter, og hvor nyligt de er blevet valideret 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 kontrolpunkthandlingerne mislykkes fra "MSG_ERR_DISKFULL" ved at køre følgende kommando:

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

Hvis kontrolpunkterne er fuldført korrekt, vises output, der ligner det 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 det mislykkes på grund af MSG_ERR_DISKFULL, ses dette output:

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 ændringshastigheden:

capacity.sh  

Eksempel på output:

  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

Nogle gange, hvis den høje ændringshastighed eller "for meget for hurtigt" situation gentager sig, kan dette afhjælpes ved at sænke den samlede GSAN eller brugerkapacitet. Med en lavere GSAN kapacitet, er der lidt mere plads til OS Capacity overhead og resulterer også i færre ændringer af datastoragebeholdere. Hvis du har brug for hjælp til dette scenarie, skal du åbne en serviceanmodning hos Dell Technologies Avamar-supportteamet, ellers skal du fortsætte fra trin 7.

7. Problemer med høj OS-kapacitet på andre diskpartitioner har forskellige årsager, men løsningerne kræver teknisk support. Åbn en serviceanmodning hos Dell Technologies Avamar-supportteamet, og fortsæt ellers fra trin 7.

Når OS-kapaciteten er adresseret, GSAN kapacitet eller andre Avamar-kapaciteter kan gennemses. Se Avamar Kapacitetsfejlfinding, problemer og spørgsmål – Al kapacitet (løsningssti)