Avamar: Operativsystemets (OS) kapacitet (lösningssökväg)

Hantera eller felsöka problem med OS-kapacitet på Avamar.

Den här artikeln om lösningssökväg är utformad för att ta itu med eller felsöka problem med operativsystemskapacitet på Avamar.


Inledande begrepp och förståelse för OS-kapacitet finns i utbildningsartikeln Avamar: Koncept och utbildning

för kapacitetshanteringSom sammanfattas i träningsartikeln bör en rimlig förståelse av följande ämnen krävas för att fortsätta med resten av den här artikeln:

• En grundläggande förståelse för kontrollpunkter (cp), validering av kontrollpunkter (hfscheck)och skräpinsamling (GC), och vikten av varje
• Skillnaden mellan GSAN (även kallat "användarkapacitet" och OS-kapacitet)
• Omkostnadsdata för kontrollpunkter
• Om någon av datapartitionerna är mer än 89 % av det totala fysiska OS-kapacitetsutrymmet kan skräpinsamlingen inte köras.
• Ju närmare ett Avamar-rutnät är 100 % användarkapacitet, desto mindre OS-kapacitet är tillgänglig för kontrollstationskostnader.
• Faktorer som bidrar till kontrollpunktens omkostnader, inklusive asynkron crunching, antal lagrade kontrollpunkter, HFSCheck och kontrollpunktsvalidering och så vidare.
• Så här hittar du OS-kapacitetsnivåerna
• Grundläggande åtgärder för att minska operativsystemkapaciteten

Det är ofta enklast att betrakta OS-kapaciteten som storleken på GSAN data (mer specifikt det utrymme som allokerats för dessa data) och de omkostnader som genereras av Avamar-kontrollpunkter. Ju fler kontrollpunkter och ju högre ändringshastighet, desto högre är kontrollpunktskostnaderna.

Effekter av hög OS-kapacitet kan omfatta:

• Skräpinsamlingsfel: GC misslyckas med MSG_ERR_DISKFULL om OS-kapaciteten stiger över 89 %
• Säkerhetskopierings- eller replikeringsfel: Säkerhetskopieringar eller inkommande replikering kan misslyckas med MSG_ERR_STRIPECREATE om OS-kapaciteten överstiger 90 %. (Detta gäller endast om en ny datastripe måste skapas. Om en ny stripe inte behövs kan säkerhetskopiering och replikering fortfarande köras utan problem.)
• Checkpoint-fel: En kontrollpunkt misslyckas med MSG_ERR_DISKFULL om OS-kapaciteten stiger över 96 %

Som ovanstående kanske indikerar är OS-kapaciteten ofta den första typen av Avamar-kapacitet som hanteras när även andra Avamar-kapaciteter är höga. Skräpinsamling kan åtminstone inte köras när OS-kapaciteten når vissa nivåer, även om GSAN eller användarkapaciteten är också hög.

I allmänhet anses OS-kapaciteten vara hög när GC misslyckas med MSG_ERR_DISKFULL om OS-kapaciteten stiger över 89 %. Om OS-kapaciteten är mindre än 89 % påverkas inga underhållsjobb. 

Avamar OS-kapaciteten kan öka beroende på en kombination av följande orsaker:

• Hög ändringsfrekvens för säkerhetskopierade data, lägger till "för mycket för snabbt"
• Hög GSAN eller "användarkapacitet" som lämnar mindre utrymme för operativsystemkapacitet och ibland till och med kan resultera i högre ändringshastigheter
• Kontrollpunkten kan inte slutföras, vilket resulterar i statusen "MSG_ERR_DISKFULL" som visas i utdata.
• En validering av kontrollpunkt (hfscheck) har misslyckats eller inte körts nyligen, så att de äldsta kontrollpunkterna inte kan rullas av eller tas bort
• Kontrollpunkter som inte avfyras av andra orsaker, inklusive för höga kvarhållningsinställningar för kontrollpunkter

Hög OS-kapacitet på andra diskpartitioner kan uppstå av olika orsaker, inklusive felaktig dataplacering, att loggfiler blir för stora och så vidare.

• Avamar-kontrollpunkterna är en skrivskyddad ögonblicksbild och länk till realtidsdata. Eftersom detta skapas med länkar kommer en kontrollpunkt att använda noll extra diskutrymme omedelbart efter att den har skapats. Om det inte finns några ändringar i livedata använder kontrollpunkten inte ytterligare utrymme.
• Detta ändras när livedata ändras medan kontrollpunkten förblir densamma. Då finns det en originalkopia av data i kontrollpunkten och den uppdaterade live-kopian av ändrade data. Detta är helt avsiktligt och avsiktligt. Det är därför det finns reserverat OS-kapacitetsutrymme.
• Men om mängden eller ändringshastigheten ökar drastiskt och plötsligt kan detta orsaka en ovanlig topp i operativsystemets kapacitetsstorlek och anses vara "för mycket för snabbt"
• Informationen capacity.sh verktyget skulle visa detta som orsaken när utdata jämförs över flera dagar.

Om underhållsjobb, inklusive skräpinsamling, misslyckas från hög Avamar OS-kapacitet gör du så här:

1. Samla in all Avamar-kapacitetsinformation för att skapa en bild av situationen: Avamar: Hur du samlar in den information som krävs för att felsöka kapacitetsproblem.

2. Gå sedan igenom hur hög OS-kapaciteten är och vilka åtgärder som kan krävas. I artikeln om datainsamling hittar du detta med hjälp av följande kommando: 

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

Så Avamar fungerar är att det HÖGSTA värdet för fs-percent-full som visas är den begränsande faktorn för den aktuella OS-kapaciteten. Beroende på nodtypsgenerering och storlek kan antalet datapartitioner som lagrar säkerhetskopierings- och kontrollpunktsdata variera. Som sett från Linux-operativsystemet kan dessa vara diskar eller partitioner som "/data0*", där "*" kan vara en enda siffra. Antalet datapartitioner beror på nodtyp, maskinvarugenerering och storlek (och kan inte ändras).

3. Granska antalet kontrollpunkter som hittats och hur nyligen de har verifierats från kommandot:

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. Kontrollera om kontrollpunktsåtgärder misslyckas från "MSG_ERR_DISKFULL" genom att köra följande kommando:

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

Om kontrollpunkterna har slutförts visas utdata som liknar följande:

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

Om det misslyckas på grund av MSG_ERR_DISKFULL visas dessa utdata:

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. Bestäm ändringshastigheten:

capacity.sh  

Exempel 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

Ibland om den höga förändringstakten eller "för mycket för snabbt"-situationen återkommer, kan detta lindras genom att sänka den totala GSAN eller användarkapacitet. Med en lägre GSAN kapacitet, det finns lite mer utrymme för OS-kapacitetsoverhead, vilket även resulterar i färre ändringar av datalagringsbehållare. Om du behöver hjälp med det här scenariot öppnar du en tjänstebegäran med Dell Technologies Avamar-supportteam, annars fortsätter du från steg 7.

7. Problem med hög OS-kapacitet på andra diskpartitioner har olika orsaker, men lösningarna kräver teknisk support. Öppna en tjänstebegäran med Dell Technologies Avamar-supportteam, annars fortsätter du från steg 7.

När OS-kapaciteten har åtgärdats GSAN kapacitet eller annan Avamar-kapacitet kan granskas. Se Felsökning, problem och frågor om Avamar-kapacitet – all kapacitet (lösningssökväg)