Avamar: Capaciteit van besturingssysteem (OS) (resolutiepad)

Problemen met de capaciteit van het besturingssysteem op Avamar aanpakken of oplossen.

Dit artikel over het Oplossingspad is bedoeld voor het aanpakken of oplossen van capaciteitsproblemen met het besturingssysteem op Avamar.


Voor de eerste concepten en een goed begrip van de capaciteit van het besturingssysteem, zie het trainingsartikel Avamar: Concepten en training

voor capaciteitsbeheerZoals samengevat in het trainingsartikel, is een redelijk begrip van de volgende onderwerpen vereist om verder te gaan met de rest van dit artikel:

• Een basiskennis van checkpoints (cp), checkpointvalidatie (hfscheck)en Garbage Collection (GC), en het belang van elk
• Het verschil tussen GSAN (ook bekend als "User Capacity" en OS Capacity)
• Overheadgegevens van controlepunten
• Als een van de datapartities meer dan 89% van de totale fysieke OS-capaciteitsruimte bedraagt, kan garbage collection niet worden uitgevoerd.
• Hoe dichter een Avamar raster bij 100% gebruikerscapaciteit ligt, hoe minder besturingssysteemcapaciteit er beschikbaar is voor checkpoint-overhead.
• Factoren die bijdragen aan de overhead van controlepunten, waaronder asynchroon kraken, aantal opgeslagen controlestations, HFSCheck en het belang van checkpointvalidatie, enzovoort.
• De capaciteitsniveaus van het besturingssysteem vinden
• Basisacties om de capaciteit van het besturingssysteem te verminderen

Het is vaak het gemakkelijkst om de capaciteit van het besturingssysteem te beschouwen als de grootte van de GSAN data (meer specifiek de ruimte die voor deze data is toegewezen) en de overhead die wordt gegenereerd door Avamar-controlepunten. Hoe hoger het aantal controlestations en hoe hoger het wijzigingspercentage, hoe hoger de overhead van het controlestation.

Een hoge capaciteit van het besturingssysteem kan de volgende gevolgen hebben:

• Fout in garbage collection: GC mislukt met MSG_ERR_DISKFULL als de capaciteit van het besturingssysteem boven de 89% uitkomt
• Back-up- of replicatiefout: Back-ups of inkomende replicatie kunnen mislukken met MSG_ERR_STRIPECREATE als de capaciteit van het besturingssysteem boven de 90% uitkomt. (Dit is alleen als er een nieuwe datastripe moet worden gemaakt. Als een nieuwe strip niet nodig is, kunnen back-ups en replicatie nog steeds worden uitgevoerd.)
• Checkpoint-fout: Een controlepunt mislukt met MSG_ERR_DISKFULL als de capaciteit van het besturingssysteem hoger is dan 96%

Zoals het bovenstaande kan aangeven, is OS-capaciteit vaak het eerste type Avamar-capaciteit dat moet worden aangepakt wanneer andere Avamar-capaciteiten ook hoog zijn. Garbage Collection kan in ieder geval niet worden uitgevoerd wanneer de capaciteit van het besturingssysteem bepaalde niveaus bereikt, zelfs wanneer het GSAN Of de gebruikerscapaciteit is ook hoog.

Over het algemeen wordt de capaciteit van het besturingssysteem als hoog beschouwd wanneer GC mislukt met MSG_ERR_DISKFULL als de capaciteit van het besturingssysteem hoger is dan 89%. Als de capaciteit van het besturingssysteem helemaal niet minder dan 89% is, worden er geen onderhoudstaken beïnvloed. 

De capaciteit van Avamar OS kan toenemen als gevolg van een combinatie van de volgende redenen:

• Hoge wijzigingssnelheid van back-updata, met toevoeging van "te veel en te snel"
• Hoog GSAN of "User Capacity" waardoor er minder ruimte overblijft voor OS-capaciteit en soms zelfs hogere wijzigingspercentages kunnen leiden
• Checkpoint kan niet worden voltooid, wat resulteert in de status "MSG_ERR_DISKFULL", zoals te zien is in de uitvoer.
• Een Checkpoint-validatie (hfscheck) is mislukt of onlangs niet uitgevoerd, zodat de oudste controlestations niet kunnen worden weggerold of verwijderd
• Checkpoints worden niet uitgevoerd om andere redenen, waaronder te hoge retentie-instellingen voor checkpoints

Een hoge capaciteit van het besturingssysteem op andere schijfpartities kan verschillende oorzaken hebben, zoals onjuiste plaatsing van gegevens, te grote logbestanden, enz.

• Voor een snelle achtergrond: Avamar-controlestations zijn een alleen-lezen snapshot en een koppeling met de live data. Aangezien dit wordt gemaakt met koppelingen, zal een checkpoint direct na het maken nul extra schijfruimte in beslag nemen. Als er geen wijzigingen zijn in de live gegevens, neemt het controlestation geen extra ruimte in beslag.
• Dit verandert als de live-data wordt gewijzigd terwijl het controlepunt hetzelfde blijft. Op dat moment is er een originele kopie van de gegevens in het controlepunt en de bijgewerkte live kopie van de gewijzigde gegevens. Dit is volledig ontworpen en opzettelijk. Daarom is er gereserveerde opslagruimte voor de besturingssysteemcapaciteit.
• Als de hoeveelheid of snelheid van wijzigingsdata echter drastisch en plotseling toeneemt, kan dit een ongebruikelijke piek in de grootte van de OS-capaciteit veroorzaken en als te veel en te snel worden beschouwd
• De capacity.sh Tool zou dit als oorzaak laten zien bij het vergelijken van de output over meerdere dagen.

Als onderhoudstaken, waaronder garbage collection, mislukken vanwege een hoge Avamar OS-capaciteit, volgt u deze stappen:

1. Verzamel alle informatie over de Avamar-capaciteit om een beeld te schetsen van de situatie: Avamar: De informatie verzamelen die nodig is om capaciteitsproblemen op te lossen.

2. Bekijk vervolgens hoe hoog de capaciteit van het besturingssysteem is en welke acties mogelijk vereist zijn. In het artikel over gegevensverzameling kunt u dit vinden met de volgende opdracht: 

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

Hoe Avamar werkt, is dat de HOOGSTE waarde voor fs-procent-vol de weergegeven beperkende factor is voor de huidige capaciteit van het besturingssysteem. Afhankelijk van de generatie en grootte van het knooppunttype kan het aantal datapartities dat back-up- en checkpointdata opslaat variëren. Vanuit het Linux-besturingssysteem kunnen dit schijven of partities zijn, zoals "/data0*", waarbij "*" een enkel cijfer kan zijn. Het aantal datapartities is afhankelijk van het knooppunttype, de hardwaregeneratie en de grootte (en kan niet worden gewijzigd).

3. Bekijk het aantal gevonden controlestations en hoe recent ze zijn gevalideerd met de opdracht:

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. Controleer of checkpointbewerkingen mislukken vanaf "MSG_ERR_DISKFULL" door de volgende opdracht uit te voeren:

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

Als de controlepunten zijn voltooid, ziet u een uitvoer die vergelijkbaar is met het volgende:

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

Als dit is mislukt vanwege MSG_ERR_DISKFULL, wordt deze uitvoer weergegeven:

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. Bepaal het wijzigingspercentage:

capacity.sh  

Voorbeelduitvoer:

  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

Soms, als de hoge veranderingssnelheid of de "te veel te snel"-situatie zich herhaalt, kan dit worden verlicht door de totale GSAN of gebruikerscapaciteit. Met een lagere GSAN capaciteit, is er iets meer ruimte voor overhead van OS-capaciteit en resulteert dit ook in minder wijzigingen in datastoragecontainers. Open voor hulp bij dit scenario een serviceaanvraag bij het Dell Technologies Avamar Support-team, anders gaat u verder vanaf stap 7.

7. Problemen met hoge capaciteit van het besturingssysteem op andere schijfpartities hebben verschillende oorzaken, maar de oplossingen vereisen technische ondersteuning. Open een serviceaanvraag bij het Dell Technologies Avamar supportteam, of ga anders verder vanaf stap 7.

Zodra de capaciteit van het besturingssysteem is aangepakt, GSAN capaciteit of andere Avamar-capaciteiten kunnen worden beoordeeld. Zie Oplossingen voor Avamar-capaciteitsproblemen, problemen en vragen - Alle capaciteit (oplossingspad)