Avamar: Käyttöjärjestelmän kapasiteetti (ratkaisupolku)

Käyttöjärjestelmän kapasiteettiongelmien käsitteleminen tai vianmääritys Avamarissa.

Tämä ratkaisupolkuartikkeli on tarkoitettu Avamarin käyttöjärjestelmän kapasiteettiongelmien ratkaisemiseen tai vianmääritykseen.


Alustavia käsitteitä ja käyttöjärjestelmän kapasiteetin tuntemusta on koulutusartikkelissa Avamar: Kapasiteetin hallinnan käsitteet ja koulutus

Kuten koulutusartikkelista on yhteenveto, tämän artikkelin muiden osien jatkaminen edellyttää kohtuullista ymmärrystä seuraavista aiheista:

• Perustiedot tarkistuspisteistä (cp), tarkistuspisteiden validoinnista (hfscheck)ja roskien keräys (GC) sekä kunkin merkitys
• Ero välillä GSAN (eli "käyttäjäkapasiteetti" ja käyttöjärjestelmän kapasiteetti)
• Tarkistuspisteen yläpuolella olevat tiedot
• Jos jokin tieto-osioista on yli 89 % käyttöjärjestelmän fyysisen kapasiteetin kokonaiskapasiteetista, roskien keräystä ei voi suorittaa.
• Mitä lähempänä Avamar-ruudukko on 100-prosenttista käyttäjäkapasiteettia, sitä vähemmän käyttöjärjestelmän kapasiteettia on käytettävissä tarkistuspisteiden yleiskustannuksille.
• tarkastuspisteiden yleiskustannuksiin vaikuttavat tekijät, mukaan lukien asynkroninen rutistus, tallennettujen tarkistuspisteiden lukumäärä, HFSCheck ja tarkistuspisteen validoinnin tärkeys ja niin edelleen.
• Käyttöjärjestelmän kapasiteettitasojen selvittäminen
• Perustoimet käyttöjärjestelmän kapasiteetin vähentämiseksi

Usein on helpointa pitää käyttöjärjestelmän kapasiteettia GSAN tiedot (tarkemmin sanottuna näille tiedoille varattu tila) ja Avamar-tarkistuspisteiden tuottamat yleiskustannukset. Mitä suurempi tarkistuspisteiden määrä ja mitä suurempi muutosnopeus, sitä suurempi tarkistuspisteen yleiskustannus.

Käyttöjärjestelmän suuren kapasiteetin vaikutuksia voivat olla esimerkiksi seuraavat:

• Roskien keräämisen epäonnistuminen: GC epäonnistuu MSG_ERR_DISKFULL jos käyttöjärjestelmän kapasiteetti nousee yli 89 prosenttiin
• Varmuuskopiointi- tai replikointivirhe: Varmuuskopiointi tai replikointi voi epäonnistua MSG_ERR_STRIPECREATE jos käyttöjärjestelmän kapasiteetti nousee yli 90 prosenttiin. (Tämä tapahtuu vain, jos on luotava uusi tietojuova. Jos uutta raitaa ei tarvita, varmuuskopiointi ja replikointi voivat silti onnistua.)
• Tarkistuspisteen virhe: Tarkistuspiste epäonnistuu MSG_ERR_DISKFULL jos käyttöjärjestelmän kapasiteetti nousee yli 96 prosenttiin

Kuten edellä on mainittu, käyttöjärjestelmän kapasiteetti on usein ensimmäinen Avamar-kapasiteettityyppi, kun myös muut Avamar-kapasiteetit ovat suuria. Ainakaan roskien keräystä ei voi suorittaa, kun käyttöjärjestelmän kapasiteetti saavuttaa tietyn tason, vaikka GSAN tai käyttäjäkapasiteetti on myös korkea.

Yleensä käyttöjärjestelmän kapasiteettia pidetään korkeana, kun GC epäonnistuu MSG_ERR_DISKFULL jos käyttöjärjestelmän kapasiteetti nousee yli 89%. Jos käyttöjärjestelmän kapasiteetti on lainkaan alle 89 %, se ei vaikuta huoltotöihin. 

Avamarin käyttöjärjestelmän kapasiteettia voidaan lisätä seuraavista syistä:

• Suuri varmuuskopiotietojen muutosnopeus, lisäys "liikaa liian nopeasti"
• High GSAN tai "User Capacity", joka jättää vähemmän tilaa käyttöjärjestelmän kapasiteetille ja voi joskus jopa johtaa suurempiin muutosnopeuksiin
• Tarkistuspisteen suorittaminen epäonnistui, mikä johtaa MSG_ERR_DISKFULL-tilaan, kuten tuloksessa näkyy.
• Tarkistuspisteen vahvistus (hfscheck) on epäonnistunut tai sitä ei ole suoritettu äskettäin, joten vanhimpia tarkistuspisteitä ei voi rullata pois tai poistaa
• Tarkistuspisteet eivät poistu muista syistä, mukaan lukien tarkistuspisteiden säilytysasetukset liian korkeat

Muiden levyosioiden suuri käyttöjärjestelmäkapasiteetti voi johtua useista syistä, kuten tietojen virheellisestä sijoittelusta, lokitiedostojen liian suurista jne.

• Avamar-tarkistuspisteet ovat vain luku -muotoinen tilannevedos ja linkki reaaliaikaisiin tietoihin. Koska tämä luodaan linkkien avulla, tarkistuspiste ei käytä ylimääräistä levytilaa heti luomisen jälkeen. Jos reaaliaikaisiin tietoihin ei tule muutoksia, tarkistuspiste ei käytä lisätilaa.
• Tämä muuttuu, kun reaaliaikaisia tietoja muokataan, kun tarkistuspiste pysyy samana. Tässä vaiheessa tarkistuspisteen tiedoista on alkuperäinen kopio ja muokattujen tietojen päivitetty reaaliaikainen kopio. Tämä on täysin suunniteltua ja tarkoituksellista. Siksi käyttöjärjestelmän kapasiteettitilaa on varattu.
• Jos muutostietojen määrä tai nopeus kuitenkin kasvaa voimakkaasti ja yhtäkkiä, tämä voi aiheuttaa harvinaisen piikin käyttöjärjestelmän kapasiteetin kokoon ja sitä voidaan pitää "liian paljon liian nopeasti"
• pikanäppäimellä capacity.sh Työkalu näyttää tämän syynä, kun verrataan useiden päivien tuloksia.

Jos ylläpitotyöt, kuten roskien keräys, epäonnistuvat Avamar-käyttöjärjestelmän suuren kapasiteetin vuoksi, toimi seuraavasti:

1. Kerää kaikki Avamarin kapasiteettitiedot, jotta saat tilanteesta kuvan: Avamar: Kapasiteettiongelmien vianmääritykseen tarvittavien tietojen kerääminen.

2. Tarkista seuraavaksi, kuinka suuri käyttöjärjestelmän kapasiteetti on ja mitä toimia voidaan tarvita. Tietojen keräämistä koskevasta artikkelista tämä löytyy seuraavalla komennolla: 

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

Avamar toimii siten, että fs-prosenttisesti täysi SUURIN arvo on käyttöjärjestelmän nykyistä kapasiteettia rajoittava tekijä. Varmuuskopio- ja tarkistuspistetietoja tallentavien dataosioiden määrä voi vaihdella solmun tyypin ja koon mukaan. Kuten Linux-käyttöjärjestelmässä nähdään, nämä voivat olla levyjä tai osioita, kuten "/data0*", joissa "*" voi olla yksi numero. Dataosioiden määrä riippuu solmun tyypistä, laitteiston sukupolvesta ja koosta (eikä sitä voi muuttaa).

3. Tarkista löydettyjen tarkistuspisteiden määrä ja se, kuinka äskettäin ne on vahvistettu komennolla:

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. Tarkista MSG_ERR_DISKFULL-kohdasta, epäonnistuvatko tarkistuspistetoiminnot, suorittamalla seuraava komento:

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

Jos tarkistuspisteiden suorittaminen onnistui, näkyviin tulee seuraavankaltainen tulos:

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

Jos MSG_ERR_DISKFULL epäonnistuu testissä, näet tuloksen:

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. Määritä muutosnopeus:

capacity.sh  

Esimerkki tuloksesta:

  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

Joskus, jos suuri muutosprosentti tai "liikaa liian nopeasti" -tilanne toistuu, sitä voidaan lievittää alentamalla yleistä GSAN tai käyttäjäkapasiteetti. Pienemmällä GSAN kapasiteetti, käyttöjärjestelmän kapasiteetin yleiskustannuksille on hieman enemmän tilaa, mikä johtaa myös vähemmän tallennussäiliöiden muutoksiin. Jos tarvitset apua tässä tapauksessa, tee palvelupyyntö Dell Technologiesin Avamar-tukitiimille. Muussa tapauksessa jatka vaiheesta 7.

7. Muiden levyosioiden suuriin käyttöjärjestelmäkapasiteetteihin on useita syitä, mutta ratkaisut vaativat teknistä tukea. Tee palvelupyyntö Dell Technologiesin Avamar-tukitiimille. Muussa tapauksessa jatka vaiheesta 7.

Kun käyttöjärjestelmän kapasiteetti on käsitelty, GSAN kapasiteetti tai muu Avamar-kapasiteetti voidaan tarkistaa. Katso Avamarin kapasiteetin vianmääritys, ongelmat ja kysymykset – Kaikki kapasiteetti (ratkaisupolku)