Avamar GSAN- tai käyttäjäkapasiteetin ratkaisupolku

Alustavia käsitteitä ja tietoja käyttöjärjestelmän kapasiteetista on kohdassa Avamar: Kapasiteetin yleiskoulutus – ratkaisupolku

Se on usein helpoin harkita GSAN Kapasiteetti työasemien varmuuskopioinnin tilana ja käyttönä.

• Perustiedot deduplikoinnista
• Perustiedot tarkistuspisteestä, tarkistuspisteen validoinnista (hfscheck) ja roskien keräys sekä kunkin merkitys.
• Ero välillä GSAN (tai käyttäjä) Kapasiteetti ja käyttöjärjestelmän kapasiteetti
• Muutosnopeus
• Vakaa tila

• Varmuuskopiointi- tai replikointivirhe, kun ruudukon käyttötilaksi on vaihdettu admin-tila

  • Asiakkaan varmuuskopiointityö voi epäonnistua ja näyttöön voi tulla seuraavankaltainen viesti:  "avtar Info <5314>: Command failed (1 error, exit code 10028: Operation failed because target server is full)"
• Varmuuskopioinnin ajoituksen automaattinen poistaminen käytöstä (kunnes joku kuittaa ja tyhjentää sen)

• 80 % – kapasiteettivaroitus
• 95 % – kuntotarkastuksen raja on saavutettu (tämä voi joskus poistaa varmuuskopioinnin ajoitustoiminnon käytöstä, ainakin kunnes se kuitataan manuaalisesti)
• 100 % – Palvelimen vain luku -raja on saavutettu (ruudukko siirtyy järjestelmänvalvojan tilaan)

1. Avamarin tarvitsee vain tallentaa ja tallentaa pienet muutokset ja erot kunkin asiakasohjelman varmuuskopiointityön välillä, koska deduplikointi on poistettu. Kun uusia varmuuskopioita (tai saapuvia replikointia) suoritetaan, se voi lisätä uusia tietoja ja lisätä Avamarin kapasiteetin tai käyttöasteen arvoa. 
2. Tietyn ajan kuluttua varmuuskopiot vanhentuvat määritetyn säilytyksen ja vanhentumisen mukaan, eikä niitä löydy Avamar-järjestelmästä palautettaviksi. 
3. Kun Avamarin Garbage Collection (GC) -ylläpitotyö suoritetaan, se löytää kaikki yksittäiset tiedon osat tai osat, joita ei enää tarvita näiden vanhentuneiden varmuuskopioiden vuoksi. GC varmistaa, että muut nykyiset varmuuskopiot eivät jaa samoja tietoja (deduplikoinnin vuoksi), ja poistaa tai vapauttaa sitten ne tieto-osat, joita ei enää tarvita Avamar-palvelimen kapasiteetin tai käytön vähentämiseen.

Kun päivittäin lisättävien saapuvien tietojen määrä on suunnilleen sama kuin päivittäin puhdistettavan datan määrä, tätä kutsutaan vakaaksi tilaksi. Tämä on jokaisen asennetun Avamar-sähköverkon tavoite.

Ennen uuden Avamar-ruudukon käyttöönottoa ja määritystä tehdään yleiset asennusta edeltävät mitoituslaskelmat, joilla määritetään varmuuskopiotietojen tallentamiseen tarvittava kapasiteetti. Nämä laskelmat perustuvat asiakkaiden säilytysvaatimuksiin ja varmuuskopioitavien tietojen määrään. Se arvioi myös, kuinka suuri osa näistä tiedoista voisi keskimäärin deduplikoitua ja niin edelleen.

1. Roskienkeräys ei ole jatkuvasti käynnissä
2. Roskien keräys toimii hitaasti tai liian vähän aikaa
3. Tieto-optimointia koskevat arviot ennen Avamarin sähköverkon asennusta eivät olleet riittävän tarkkoja
4. Muut tiedot kuin ne, jotka on laskettu ennen Avamarin sähköverkon asennusta, varmuuskopioidaan tähän Avamar-palvelimeen.
5. Muut syyt

Sen varmistaminen, että kaikki alla olevat vianmääritysvaiheet koskevat ympäristöä:

Vaihe 1. Tiedonkeruu:

Varmista, että Avamarin sähköverkossa ei ole muita kapasiteettiin kuulumattomia ongelmia. Jos on, ne saattavat vaatia huomiota ENNEN vianmäärityskapasiteetin tarkistamista.

Näitä ovat esimerkiksi laitteistovirheet, tietojen eheysongelmat (mukaan lukien offline-solmut), offline-raidoitukset, tarkistuspisteiden vahvistusvirheet ja epäonnistuneet ylläpitotoimet. Jos jokin näistä aiheuttaa ongelmia, kapasiteetin vianmääritys on lopetettava ja muut ongelmat on ratkaistava. Kun muut ongelmat on ratkaistu, kapasiteettia voidaan tarkastella uudelleen.

Kuntotarkastus on suoritettava (Avamar: proactive_check.pl kuntotarkistuksen komentosarjan suorittaminen Avamar Serverissä, mutta vähintään status.dpn Komento voi antaa nopean yleiskatsauksen ja vahvistuksen useimmista samoista ongelmista. Katso Avamar: Status.dpn-komennon tuloksen ymmärtäminen

Lisätietoja on seuraavassa artikkelissa: Avamar: Avamar troubleshooting hierarchy -lähestymistavan käyttäminen oikein.

Jos apua tarvitaan kapasiteettiin puuttumiseen liittyvien ongelmien ratkaisemiseksi, luo palvelupyyntö Dell Technologiesin Avamar-tukitiimille.

Vaihe 2. Kapasiteettitietojen kerääminen: 

Seuraavassa on kaikki Avamarin kapasiteettiongelmien vianmääritykseen tarvittavat tiedot: Avamar: Tietojen kerääminen kapasiteettiongelmien vianmääritystä varten

Ainakin status.dpn Avamar Administration -käyttöliittymän komennossa tai arvossa näkyy GSAN kapasiteetti.

Vaihe 3. Tarkista, onko käyttöjärjestelmän kapasiteetti täynnä:

Seuraava komento auttaa näyttämään kunkin levyosion käyttöjärjestelmän kapasiteetin nykyisen arvon. Jos jokin arvoista on saavuttanut tai ylittänyt 85%, kuten toisessa näytelähdössä, sitä pidetään korkeana käyttöjärjestelmäkapasiteettina:

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

Näytteen tuotokset:

nodetag="0.2"
        fs-percent-full="56.6"
        fs-percent-full="54.7"
        fs-percent-full="54.4"
        fs-percent-full="54.6"
        fs-percent-full="54.7"
        fs-percent-full="54.7"
      nodetag="0.1"
        fs-percent-full="56.2"
        fs-percent-full="54.6"
        fs-percent-full="54.6"
        fs-percent-full="54.8"
        fs-percent-full="54.8"
        fs-percent-full="54.5"
      nodetag="0.0"
        fs-percent-full="56.2"
        fs-percent-full="54.7"
        fs-percent-full="54.8"
        fs-percent-full="54.7"
        fs-percent-full="54.6"
        fs-percent-full="54.6"

nodetag="0.2"
        fs-percent-full="94.5"
        fs-percent-full="94.4"
        fs-percent-full="94.2"
        fs-percent-full="94.1"
        fs-percent-full="94.0"
        fs-percent-full="94.0"
      nodetag="0.1"
        fs-percent-full="94.5"
        fs-percent-full="94.3"
        fs-percent-full="94.1"
        fs-percent-full="93.6"
        fs-percent-full="94.0"
        fs-percent-full="93.9"
      nodetag="0.0"
        fs-percent-full="94.4"
        fs-percent-full="94.4"
        fs-percent-full="94.0"
        fs-percent-full="94.1"
        fs-percent-full="92.7"
        fs-percent-full="92.5"

Vain jos käyttöjärjestelmän kapasiteetti on alle 85 %, GSAN Kapasiteetin vianmääritys jatkuu. 

Vaihe 4. Kapasiteettiin kuulumattomat ongelmat, jotka voidaan joskus ymmärtää väärin kapasiteetiksi:

On mahdollista, että asiakasvarmuuskopioinnit eivät epäonnistu kapasiteettisyistä vaan kiintiösyistä. Nämä voidaan joskus ymmärtää väärin kapasiteetiksi.

Tämä tilanne voidaan vahvistaa status.dpn -komento tai jokin muu kerätty tulos, joka näyttää pienemmän kapasiteetin.

On myös mahdollista, että asiakasohjelmien varmuuskopioinnit ovat epäonnistuneet tai niitä ei ole suoritettu muiden syiden vuoksi Non-GSAN Kapasiteettiin liittyvät syyt. Kerättyjen tietojen pitäisi vahvistaa tämä, tai niiden pitäisi näkyä myös Avamar Administration -käyttöliittymässä.

• Avamar: Metatietojen kapasiteetin ratkaisupolku
• Data Domain: Suuri kapasiteetti Avamar-integroinnin ratkaisupolusta

Jos GSAN Kapasiteetti on suuri ja nämä muut kapasiteetit ovat myös suuria. Vianmääritys voidaan suorittaa missä tahansa järjestyksessä (paitsi käyttöjärjestelmän kapasiteetti, jonka on aina oltava ensimmäinen).

Vaihe 5. Raitatasapaino ja käyttöjärjestelmän levytasapaino:

Avamarin "raidat" ovat säilötiedostoja, joihin varmuuskopiotiedot on tallennettu datasolmuissa (lukuun ottamatta yhden solmun Avamar-ruudukkoa).

Odotuksena on, että raidat ovat "tasapainossa" tai jakautuneet tasaisesti ruudukon eri levyille ja solmuille, mutta joskus ne voivat muuttua epätasapainoisiksi.

Avamarissa suurin solmu tai levyosio on Avamarin kapasiteettia rajoittava tekijä.

Tämä on tarkoituksellista, joten mikään levyistä tai solmuista ei luo enempää raitoja kuin ne pystyvät käsittelemään (tai sallivat), joten tasapainoiset raidat ovat tärkeitä kapasiteetin kannalta.

Kun esimerkiksi lisätään datasolmuja Avamar-ruudukon laajennusta varten, on suoritettava tasapainotus, jotta raidat jakautuvat tasaisesti uusiin solmuihin, jotta Avamarin kokonaiskapasiteettiprosentti pienenee.

Toinen tasapainotyyppi, joka vaatii ymmärrystä, on käyttöjärjestelmän levytasapaino. Tämä koskee vain saman solmun dataosioita, ei useiden solmujen osioita. 

Jos samassa datasolmussa yksi osio on paljon suurempi tai pienempi kuin SAMAN solmun toinen osio, raja voidaan ylittää nimeltä "freespaceunbalance". Vaikka tämä on yleensä käyttöjärjestelmässä eikä GSAN Kapasiteetti, se voidaan raportoida muodossa GSAN Kapasiteettiongelma.

Vaihe 6. Tarkista, onko roskienkeräys valmis: 

Saat tietoja roskien keräämisestä suorittamalla seuraavan komennon:

dumpmaintlogs --types=gc --days=30 | grep "4201\|2402"

Ihannetapauksessa tulos osoittaa, että kaasuteknologia on suoritettu viimeisten 30 päivän aikana:

2025/10/07-12:00:35.24911 {0.1} <4201> completed garbage collection
2025/10/08-12:00:34.61185 {0.1} <4201> completed garbage collection
2025/10/09-12:00:35.14874 {0.1} <4201> completed garbage collection
2025/10/10-12:00:34.67986 {0.1} <4201> completed garbage collection
2025/10/11-12:00:34.73284 {0.1} <4201> completed garbage collection
2025/10/12-12:00:33.23205 {0.1} <4201> completed garbage collection
2025/10/13-12:00:33.41448 {0.1} <4201> completed garbage collection
2025/10/14-12:00:35.70726 {0.1} <4201> completed garbage collection
2025/10/15-12:00:35.08316 {0.1} <4201> completed garbage collection
2025/10/16-12:00:34.82681 {0.1} <4201> completed garbage collection
2025/10/17-12:00:35.29262 {0.1} <4201> completed garbage collection
2025/10/18-12:00:35.24618 {0.1} <4201> completed garbage collection
2025/10/19-12:00:34.56531 {0.1} <4201> completed garbage collection
2025/10/20-19:06:45.15574 {0.1} <4201> completed garbage collection
2025/10/21-12:00:34.21062 {0.1} <4201> completed garbage collection
2025/10/22-12:00:35.29770 {0.1} <4201> completed garbage collection
2025/10/23-12:00:36.13041 {0.1} <4201> completed garbage collection
2025/10/24-12:00:35.52502 {0.1} <4201> completed garbage collection
2025/10/25-12:00:35.93730 {0.1} <4201> completed garbage collection
2025/10/26-12:00:35.55037 {0.1} <4201> completed garbage collection
2025/10/27-12:00:36.12049 {0.1} <4201> completed garbage collection
2025/10/28-12:00:35.75633 {0.1} <4201> completed garbage collection
2025/10/29-12:00:34.85499 {0.1} <4201> completed garbage collection
2025/10/30-12:00:34.96325 {0.2} <4201> completed garbage collection
2025/10/31-12:00:35.39840 {0.0} <4201> completed garbage collection
2025/11/01-12:00:35.11248 {0.0} <4201> completed garbage collection
2025/11/02-13:00:34.39202 {0.0} <4201> completed garbage collection
2025/11/03-13:00:34.70587 {0.0} <4201> completed garbage collection
2025/11/04-13:00:34.18799 {0.0} <4201> completed garbage collection
2025/11/05-13:00:34.44950 {0.0} <4201> completed garbage collection

GC-virheilmoituksia voivat olla muun muassa seuraavat:

2025/11/04-13:00:01.62234 {0.1} <4202> failed garbage collection with error MSG_ERR_DDR_ERROR

2025/11/01-12:35:06.62868 {0.2} <4202> failed garbage collection with error MSG_ERR_BACKUPSINPROGRESS

2025/10/13-12:20:07.35498 {0.7} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER

2025/10/27-12:07:44.35485 {0.0} <4202> failed garbage collection with error MSG_ERR_DISKFULL

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_MISC

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_TIMEOUT

2025/11/02-13:16:39.72027 {0.1} <4202> failed garbage collection with error MSG_ERR_GARBAGECOLLECT

Jos GC on epäonnistunut, korjaa se ensin käyttämällä seuraavaa artikkelia viitteenä: Avamar: Roskienkeruun (GC) vikojen vianmääritys (ratkaisupolku)
(Jos ongelmia on jo ratkaistu, siirry seuraavaan vaiheeseen.)

Vaihe 7. Onko GC käynnissä tarpeeksi kauan?

a. Tarkista GC:n enimmäisaika suorittamalla seuraava komento:

dumpmaintlogs --types=gc --days=30 | grep gcflags 

Esimerkkitulos:

2025/10/07-12:00:20.05509 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/08-12:00:20.09141 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/09-12:00:20.42307 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/10/10-12:00:20.47775 {0.1} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
...
2025/11/02-13:00:19.76100 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/03-13:00:19.92093 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/04-13:00:19.42781 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>
2025/11/05-13:00:19.74984 {0.0} <gcflags gccount="0" gcmincount="0" kill="0" limitadjust="5" maxpass="0" maxtime="14400" refcheck="true" throttlelevel="0" usehistory="false" orphansfirst="false"/>

Ota huomioon maxtime arvo, joka tässä esimerkissä on 14400 (sekuntia).
(Arvo 0 tarkoittaa rajoittamatonta)

b. Suorita seuraava komento määrittääksesi, kuinka kauan GC on käynnissä ja kuinka monta "läpäisyä" suoritetaan:
(Läpäisyt liittyvät tallennettujen varmuuskopiotietojen kerroksiin. Ajattele GSAN Kapasiteetti kuin sipulikerrokset. Ulommat kerrokset on kuorittava pois tai poistettava ennen kuin sisäkerrokset näkyvät. Jokainen sola on kerros GSAN tallennetut tiedot.)

dumpmaintlogs --types=gc --days=30 | grep passes | cut -d ' ' -f1,14-20

Esimerkkitulos:

2025/10/07-12:00:35.24463 passes="24" start-time="1758283220" elapsed-time="250" end-time="1758283235"/>
2025/10/08-12:00:34.60779 passes="3" start-time="1758369620" elapsed-time="70" end-time="1758369627"/>
2025/10/09-12:00:35.14232 megabytes-recovered="1" passes="4" start-time="1758456020" elapsed-time="85" end-time="1758456028"/>
2025/10/10-12:00:34.67590 passes="3" start-time="1758542420" elapsed-time="72" end-time="1758542427"/>
...
2025/11/02-13:00:34.38348 megabytes-recovered="2" passes="18" start-time="1762088419" elapsed-time="89" end-time="1762088427"/>
2025/11/03-13:00:34.69743 passes="18" start-time="1762174819" elapsed-time="9" end-time="1762174828"/>
2025/11/04-13:00:34.17943 megabytes-recovered="8" passes="22" start-time="1762261219" elapsed-time="134" end-time="1762261228"/>
2025/11/05-13:00:34.44187 megabytes-recovered="2" passes="16" start-time="1762347619" elapsed-time="119" end-time="1762347628"/>

Ota huomioon passien määrä ja elapsed-time (sekuntia).

c. Olettaen, että maxtime on nollasta poikkeava, lasketaan 2/3 maxtimeja vertaa sitä kuluneeseen aikaan.
(Yllä olevassa esimerkissä 2/3 luvusta 14400 on 9600, ja kaikki kuluneen ajan lähdöt ovat selvästi tämän luvun alapuolella.)

Erilaiset ongelmat voivat saada GC: n toimimaan hitaasti tai ei skannaa kaikkea. Tämä voi johtua siitä, että aiemmin ei ole ollut tarpeeksi aikaa suorittaa merkittävää aikaa tai päiviä, virheellisistä määrityksistä, virheistä ja muusta.

Jos on huolta maxtimetai kulkukertojen määrä, luo palvelupyyntö Dell Technologiesin Avamar-tukitiimille asian tutkimista varten.

Vaihe 8. Jos se epäili, että GC ei poistanut tarpeeksi tai odotettuja tietoja:

Jos vahvistetaan, että GC on käynnissä tarpeeksi kauan, on mahdollista, että tietoja ei kerätä syistä, jotka eivät ole roskankeräyksen hallinnassa. Tämä on luettelo dokumentoiduista syistä, jotka tulisi yleensä tarkistaa:

a. Varmista, että varmuuskopiot on määritetty vanhentumaan vähintään myöhemmin tai säännöllisesti. Jos vanhentuvia varmuuskopioita ei ole usein, GC: llä ei ole paljon työtä.

b. Tämän artikkelin avulla voit etsiä "Top Change Rate" -asiakkaat: Avamar: Kapasiteetin hallinta capacity.sh komentosarjan avulla. (Tarkista sekä "% OF TOTAL" ja "CHGRATE".)

c. Tarkista ohitetut hajautukset Avamarin mukaan: Avamar Garbage Collection raportoi ohitetuista tiivisteistä, joita ei voi puhdistaa. Jos näitä esiintyy, mutta harvinaisia, tämä on normaalia ja tämä voidaan ohittaa.

d. On olemassa lippu tai vaihtoehto, joka pakottaa Avamar-palvelimen säilyttämään viimeisimmän ja uusimman varmuuskopion jokaisesta asiakkaasta. Sitä käytetään turvallisuussyistä, jotta asiakkaan kaikki varmuuskopiot eivät ole vahingossa vanhentuneet. Tämä voi kuitenkin aiheuttaa muita ongelmia tietojen puhdistamisessa ja roskien keräämisessä. Dell Technologiesin Avamar-tukitiimi voi tarkistaa, onko tämä käytössä.

e. Jos varmuuskopiot on äskettäin vaihdettu GSAN DD-taustajärjestelmään tai tapahtui vahingossa GSAN varmuuskopio, mutta GSAN Asiakas ei vähene. Luo palvelupyyntö Dell Technologiesin Avamar-tukitiimille asian selvittämiseksi.

Vaihe 9. Avamar-ruudukko on alimitoitettu lisättävien tai nykyisten tietojen määrään nähden:

Kun kaikki muut suuren kapasiteetin ratkaisut ja mahdolliset syyt on tarkistettu eikä kyseessä ole määritysongelma tai tietoihin liittyvä ongelma:

Tämä tarkoittaa, että tiedot on ehkä poistettava tai on tutkittava erilaisia vaihtoehtoja, kuten tiettyjen asiakkaiden siirtämistä toisiin Avamar-ruudukoihin, uusien datasolmujen lisäämistä jne.

Vaihe 10. Kuittaa kaikki kapasiteettitapahtumat ja jatka tarvittaessa varmuuskopiointiajoituksen käyttöä:

a. Kun kapasiteettiongelmat on ratkaistu, kuittaa kaikki kapasiteettiin liittyvät tapahtumat Avamar-hallintakäyttöliittymässä.

b. Jatka varmuuskopiointiajoituksen soveltamista:

dpnctl start sched

Lisätietoja muista Avamar Kapasiteettiin liittyvistä kysymyksistä, koulutuksesta, vianmäärityksestä ja monesta muusta asiasta on kohdassa: Avamar: Kapasiteetin vianmääritys, ongelmat ja kysymykset – koko kapasiteetti (ratkaisupolku)

• Tämä toimenpide itsessään voi "peittää" ja piilottaa todelliset ongelmat, jolloin ne ilmestyvät uudelleen muutaman päivän tai viikon kuluttua uudelleen, mikä aiheuttaa tämän manuaalisen työn hukkaan heitettyä aikaa.
• Lisäksi manuaalinen GC ei ehkä toimi yhtä tehokkaasti, koska se on loppumassa aikataulusta.
  • Joskus se voi pahentaa muita asioita. Lisätietoja on seuraavalla englanninkielisellä sivulla: Avamar: Tietoja manuaalisen roskien keräämisen käytöstä

• Tätä muutosta tai toimenpidettä ei yleensä suoriteta, eikä sitä tule ottaa oletusarvoisesti huomioon. Avamar L2 -insinöörin tai asiantuntijan (SME) on hyväksyttävä tämä muutos.
• Valitettavasti tällaiset toimet voivat usein vahingoittaa Avamar-sähköverkkoa pysyvästi monin eri tavoin, mikä voidaan ratkaista vain lisäämällä tallennussolmuja tai ottamalla ne uudelleen käyttöön.

Huomaa, että kumpaakaan yllä luetelluista toimista ei suoriteta, koska tukitiimi haluaa auttaa ratkaisemaan kapasiteettiongelmat hyödyllisimmällä tavalla.