Avamar: Kapasiteetin hallinnan käsitteet ja koulutus

Lisätietoja Data Domainiin liittyvistä kapasiteetinhallintaongelmista on Avamar- ja Data Domain -järjestelmien integrointioppaan kohdassa Tallennustilan palauttaminen täydessä Data Domain -järjestelmässä.

Toimintaympäristöösi liittyvät oppaat löydät täältä: Avamar-dokumentaation etsiminen Dellin tukisivustosta.

• Tee yhteenveto /data*-osioihin tallennetuista tietotyypeistä.
• Ota käyttöön käsite "Käyttöjärjestelmän (OS) kapasiteetti" ja vertaa sitä käsitteeseen "Käyttäjäkapasiteetti" (joskus kutsutaan "GSAN kapasiteetti.")
• Selitä, miksi Avamaria ei pidä käyttää lähellä käyttäjän kapasiteettirajaa.
• Luettele tekijät, jotka vaikuttavat tarkistuspisteen yleiskustannuksiin.
• Kuvaile, miten dataosion käyttöä valvotaan.
• Kuvaile oireita, joita ilmenee, jos käyttöjärjestelmän kapasiteetti riistäytyy hallinnasta.
• Luettele tyypilliset syyt MSG_ERR_DISKFULL Viesti.
• Kuvaile palautusmenetelmät, joita käytetään, kun käyttöjärjestelmän suuri kapasiteetti vaikuttaa järjestelmän normaaliin toimintaan.
• Kuvaile oireita, joita ilmenee, jos käyttäjän kapasiteetti ylittää käyttäjän kapasiteettirajan.
• Keskustele siitä, miten voit palautua suuren käyttäjäkapasiteetin tilanteesta.

Tässä artikkelissa oletetaan, että lukija tuntee Avamarin operatiivisten parhaiden käytäntöjen oppaan kohdan Kapasiteetin hallinta.

Toimintaympäristöösi liittyvät oppaat löytyvät täältä: Avamar-dokumentaation etsiminen Dellin tukisivustosta.

Yleisiä ongelmia, jotka vaikuttavat korkeaan käyttöjärjestelmän kapasiteettiin tai ovat sen oireita, ovat:

• Tarkistuspisteen validointi (hfscheck) on epäonnistunut.
• Roskien keräys epäonnistuu ja raportit MSG_ERR_DISKFULL.
• Tarkistuspisteen luonti epäonnistui.

• Varmuuskopiointi epäonnistuu.
• Saapuvat replikointityöt epäonnistuvat.
• Administrator-käyttöliittymässä järjestelmä on Admin-tilassa varmuuskopiointi-ikkunan aikana.

Tässä artikkelissa käsitellään Avamar Capacity Management -käsitteitä ja -koulutusta.

Miten tiedot tallennetaan Avamar grid -järjestelmään?

Avamar-kapasiteetin hallinta koskee kaikkien Avamar-datasolmujen /data*-osioissa olevia tietoja.

• varmuuskopiot, joiden päällekkäisyys on poistettu
• RAIN-pariteettitiedot
• Tarkistuspisteen yläpuolella olevat tiedot

Sekä RAIN-pariteetti- että tarkistuspistetiedot ovat vikasietoisuustasoja, jotka ovat Avamarin käytettävissä RAIDin ja replikoinnin lisäksi.

Tieto-osioissa tarvitaan myös vapaata tilaa, jotta ylläpitotehtävät, kuten roskien kerääminen (GC) ja asynkroninen raitojen murskaus, toimivat oikein.

Alla on graafinen esitys Avamar-tallennussolmujen dataosioiden fyysisestä tallennustilasta.

Miten tiedot tallennetaan tieto-osioihin?

Yllä olevassa kaaviossa on yksinkertainen esitys siitä, miten tilaa käytetään dataosioissa.

Vasemmalla oleva arvo 100 % tarkoittaa tieto-osioissa käyttöjärjestelmän käytettävissä olevaa fyysisen tilan kokonaismäärää.

• 100 %:n käyttäjäkapasiteettimerkintä (vain luku -rajoitus) ilmaisee, että jopa 65 % dataosion kokonaistilasta on käytettävissä deduplikoitujen tietojen tallentamiseen.
• Tämän 100 %:n käyttäjän kapasiteettimerkin alapuolella oleva tila vastaa järjestelmänvalvojan käyttöliittymässä näkyvää palvelimen käyttöarvoa.

Jos minkä tahansa solmun johonkin dataosioon tallennettujen tietojen kaksoiskappaleiden määrä nousee 65 prosenttiin, Avamar siirtyy vain luku -tilaan eikä sen tarvitse enää varmuuskopioida.

Edellä esitetyn perusteella voidaan todeta, että Avamar Administrator -käyttöliittymässä käyttäjä näkee varmuuskopioinnin kuluttaman tilan, mutta ei näe käyttöjärjestelmän dataosioissa käytettyä tilaa.

Miksi Avamar-järjestelmää ei saa käyttää lähellä käyttäjän kapasiteettirajaa:

User Capacity -arvon ja tarkistuspisteen kuormituksen suhde on sellainen, että kun järjestelmä täyttyy yhä enemmän, pienetkin varmuuskopiotietojen määrän lisäykset voivat lisätä tarkistuspisteen kuormitusta merkittävästi.

Täydellinen keskustelu siitä, miksi näin on, ei kuulu tämän artikkelin soveltamisalaan, mutta tärkeä asia on muistaa: Mitälähempänä Avamar-järjestelmä on 100-prosenttista käyttäjäkapasiteettia, sitä vähemmän käyttöjärjestelmän kapasiteettia on käytettävissä tarkistuspisteiden yleiskustannuksiin.

Täydessä järjestelmässä tarkistuspisteen yleiskustannukset on edellä olevan kaavion mukaisesti rajoitettu 20 %:iin dataosioiden kokonaiskäyttötilasta.

• Järjestelmässä on oltava vähän päivittäisiä muuttuneita tietoja (enintään 1 %)
• Kapasiteetin on oltava vakaassa tilassa (kuten Avamar Operational Best Practices Guide -oppaan kohdassa Kapasiteetin hallinta on kuvattu). Toimintaympäristöösi liittyvät oppaat löydät täältä: Avamar-dokumentaation etsiminen Dellin tukisivustosta.
• ylläpitotoimien on onnistuttava joka päivä.

Jos jokin näistä väitteistä muuttuu todeksi epätodeksi, tarkistuspisteen yleiskustannusten voidaan odottaa nousevan vähitellen tai yhtäkkiä nousevan ja aiheuttavan vakavia operatiivisia ongelmia.

Tarkistuspisteen kuormitukseen vaikuttavia tekijöitä:

• Raitojen asynkroninen rutistus (oletuksena käytössä)
• Järjestelmään tallennettujen tarkistuspisteiden määrä
• Tarkistuspisteen vahvistus ei onnistu joka päivä.
• Kuinka tyhjiä raidat ovat, kun Avamar-palvelin käyttää niitä uudelleen (muuttuu vakavammaksi palvelimen käytön kasvaessa)
• Varmuuskopioinnin päivittäinen muutosnopeus

Järjestelmänvalvoja pystyy hallinnoimaan näitä tekijöitä jonkin verran. Asynkronisen murskauksen määritys on tarkoitettu vain tueksi, mutta järjestelmänvalvojat voivat poistaa ylimääräiset tarkistuspisteet, tutkia tarkistuspisteiden vikoja ja vaikuttaa palvelimen käyttöön ja päivittäiseen tiedonsiirtonopeuteen.

Tieto-osion käytön seuranta:

Oikea tapa valvoa käyttöjärjestelmän dataosion käyttöä on käyttää seuraavaa Avamar-komentoa Avamar Utility Node -sovelluksessa:

avmaint nodelist | grep fs-percent        

Esimerkki tuloksesta:

fs-percent-full="7.8"
fs-percent-full="6.3"
fs-percent-full="6.4"
fs-percent-full="6.4"
fs-percent-full="7.6"
fs-percent-full="6.2"
fs-percent-full="6.1"
fs-percent-full="6.6"
fs-percent-full="7.8"
fs-percent-full="6.4"
fs-percent-full="6.5"
fs-percent-full="6.8"

• • Tulos antaa oikean kuvan käyttöjärjestelmän kapasiteetin käytöstä.
  • Ruudukossa, jossa datasolmut käyttävät tiedostovarantoa, Linux df Komennolla ei ole merkitystä, koska raidat on varattu valmiiksi tiedostovarannossa ja monet raidat eivät ehkä ole käytössä.

Mitä tapahtuu, jos käyttöjärjestelmän kapasiteetin käyttöaste ei pysy hallinnassa?

Käyttäjän näkökulmasta ensimmäinen merkki siitä, että dataosion käyttö on hallitsematonta, tapahtuu, kun se nousee yli 89%.

Roskien keräys ei enää onnistu, ja se epäonnistuu MSG_ERR_DISKFULL Virhesanoma.

Tässä tapahtuu usein väärinkäsityksiä: Käyttäjä tulkitsee usein MSG_ERR_DISKFULL -viesti, joka tarkoittaa, että järjestelmässä ei ole enää tilaa varmuuskopioille.

Tämä tulkinta ei ole oikea, mutta yleensä käyttäjä tarkistaa palvelimen käyttöarvon Avamar Administrator -käyttöliittymästä ja pitää arvoa hyväksyttävänä, esimerkiksi 60 %.

Käyttäjä voi yrittää poistaa varmuuskopioita Avamar-käyttöliittymän varmuuskopioinnin hallintakäyttöliittymästä. Vaikka käyttäjän kapasiteettitaso olisi korkea, varmuuskopioiden poistaminen ei helpottaisi tilannetta, koska roskien keräys ei pysty suorittamaan ja poistamaan vanhentuneita tietopaloja järjestelmästä.

Jos järjestelmässä on sekä suuren käyttöjärjestelmän kapasiteettiongelma että suuri käyttäjäkapasiteetti, keskity ensin ratkaisemaan suuren käyttöjärjestelmän kapasiteettiongelma. 

Jos käyttöjärjestelmän kapasiteetin käytettävyys on suuri, järjestelmän tarkistuspisteiden luomiseen tarvittava tila saattaa olla vähissä.

Mikä aiheuttaa MSG_ERR_DISKFULL-ilmoituksen?

• Tarkistuspisteen validointi (hfscheck) on epäonnistunut toistuvasti.
• An hfscheck Epäonnistumisella on monia mahdollisia perussyitä (äkillinen peruutus, ohjelmistovika ja niin edelleen).
• Järjestelmä on liian täynnä ja sen päivittäinen tiedonsiirtonopeus on suuri.
• järjestelmä tarvitsee lisää tietosolmuja tietojen muuttumistahdin käsittelemiseen ja tietojen säilytykseen
• järjestelmä on määritetty varmuuskopioimaan enemmän tietoja tai useampia työasemia kuin mihin sen koko riittää
• Liian monia tarkistuspisteitä tallennetaan (Avamar tallentaa oletusarvoisesti kaksi tarkistuspistettä, joista toinen on tarkistettu).
• Järjestelmänvalvoja loi ylimääräisiä tarkistuspisteitä.
• ylläpitotoimia on tehty hiljattain, mutta oletusarvoisia tarkistuspisteiden säilytyksiä ei palautettu.

Seuraavassa artikkelissa on tietoja MSG_ERR_DISKFULL Skenaario: Avamar: Ylläpitotehtävät epäonnistuvat MSG_ERR_DISKFULL vuoksi, koska yhden tai useamman data-osion käyttöjärjestelmän kapasiteetti on yli 89 prosenttia

Toimet, joilla tutkitaan ja autetaan vähentämään käyttöjärjestelmän suurta kapasiteettia:

1. Määritä, milloin viimeinen hfscheck Valmis. Tämä voidaan tehdä joko Avamar Administrator -sovelluksella tai Avamar Utility Node -sovelluksen komentorivillä:

• Avamar Java Administrator -käyttöliittymässä:
  • Siirry Server > Checkpoint Management -välilehteen
  • Tarkista viimeisin Checkpoint Validation -sarakkeessa näkyvä päiväys ja aika. Sen pitäisi olla enintään 24 tuntia vanha.

--Tai--

• Avamar Utility Node -komentorivin käyttäminen:
  • Suorita komento: cplist.

admin@utilitynode:~/>: cplist

cp.20110114111419 Fri Jan 14 11:14:19 2011   valid rol ---  nodes   3/3 stripes   1131
cp.20110114194457 Fri Jan 14 19:44:57 2011   valid --- ---  nodes   3/3 stripes   1131

• • • • Viimeisin tässä lueteltu vahvistettu tarkistuspiste on päivätty 14. tammikuuta klo 11.14.
      • Se tunnistetaan lipusta heti "voimassa" -merkin jälkeen.
      • Järjestelmään asetettujen tarkistuspisteiden vahvistustyyppien mukaan lippu voi olla rol tai hfs.
      • Tämä on esimerkki rol (liikkuva) hfscheck.

Jos uusimman tarkistetun tarkistuspisteen aika on yli 24 tuntia vanha, selvitä syy. Tämä voi johtua joko siitä, että HFScheck ei käynnistynyt tai koska se epäonnistui.

2. Vahvista, onko HFScheck Suoritettiin tai jos se epäonnistui:

Suorita Avamar Utility Node -solmussa status.dpn komento ja etsi rivi, joka alkaa "Viimeinen hfscheck".

Esimerkki:

Last hfscheck: finished Sat Jan 15, 11:07:17 2011 after 06m 41s >> checked 528 of 528 stripes (OK)

Merkitse muistiin, milloin se päättyi ja mikä tila oli (tila näkyy yllä olevalla rivillä OK).

Jos hfscheck Työpaikat ovat epäonnistuneet, tämä olisi tutkittava välittömästi.

Jos hfscheck ei ole suoritettu viime aikoina, varmista, että huollon ajoitus on otettu käyttöön komennolla "dpnctl status maint" Avamar Utility Node -solmussa: .

admin@utilitynode:~/>: dpnctl status maint

Identity added: /home/admin/.ssh/dpnid (/home/admin/.ssh/admin_key)
dpnctl: INFO: Maintenance windows scheduler status: enabled.

• Jos Windowsin ylläpitotoimintojen ajoitus on poissa käytöstä, poistettu käytöstä tai keskeytetty, ota se käyttöön komennolla dpnctl start maint
• Vaihtoehtoisesti ota uusi tarkistuspiste ja suorita hfschecktai odota, että seuraava ajoitetun ylläpidon aikaväli on valmis.

Kerran hfscheck on suoritettu onnistuneesti (ongelmien korjaamisen tai huoltoaikataulun uudelleenkäynnistyksen jälkeen), vanhin tarkistuspiste "rullataan" pois päältä ja käyttöjärjestelmän kapasiteetin pitäisi laskea huomattavasti.

• Jos käyttöjärjestelmän kapasiteetti on edelleen liian suuri ja roskien keräys epäonnistuu edelleen MSG_ERR_DISKFULL viestillä ja pyydä apua Dellin tekniseltä tuelta.
• Muussa tapauksessa, jos käyttöjärjestelmän kapasiteetti on tarpeeksi alhainen roskien keräämisen suorittamiseen, vähennä "User Capacity" -kohtaa ja pienennä "palvelimen käyttöaste" -lukua.

Toimet suuren käyttäjäkapasiteetin lievittämiseksi:

Avamar-järjestelmänvalvoja pystyy vaikuttamaan User Capacity -tasoihin helpommin ja suoremmin kuin käyttöjärjestelmän kapasiteetin käyttöasteeseen.

1. Varmista, että roskien keräys on käynnissä joka päivä ja että varmuuskopiot eivät keskeytä sitä.

Tämä on tärkein kohta, koska jopa riittävän kokoinen järjestelmä kokee nopeasti suuren käyttäjäkapasiteetin, jos roskien keräys ei toimi säännöllisesti tai luotettavasti.

Kuten aiemmin, varmista, että huoltoikkuna on käytössä, ja käytä capacity.sh ja sched.sh Skriptit, joilla varmistetaan, että roskien keräys on käynnissä ja että tietoja poistetaan.

Ennen Avamar 7.x:ää varmuuskopioita ei voitu suorittaa roskien keräämisen rajoitusikkunan aikana.

Avamar v7.x -toiminnon mukana esitelty Hash Referenced Bit Maps -ominaisuus mahdollistaa varmuuskopioinnit GC:n ylläpitotoimien aikana. Tämä ominaisuus edellyttää, että näillä kartoilla on oltava vähintään 5 minuuttia "hiljaista" aikaa päivässä, jonka aikana varmuuskopioita ei suoriteta, jotta ne voidaan nollata.

Tätä ominaisuutta käsitellään Avamar-artikkelin linkin kautta: Avamar v7:ssä Garbage Collection raportoi ohitetuista hajautusarvoista, joita ei voi puhdistaa "Hash Referenced Bit Maps" -määritysten vuoksi, kun tiedot ovat käytössä.

2. Lopeta uusien asiakkaiden lisääminen ruudukkoon.

Kun Avamar-sähköverkko lähestyy kapasiteettia, lopeta uusien asiakkaiden lisääminen välittömästi, jotta tilanne ei pahene.

Jos toisen Avamar-ruudukon palvelimen käyttöaste on alhaisempi, harkitse uusien asiakkaiden lisäämistä kyseiseen järjestelmään täyttyvän palvelimen sijasta.

3. Katso, mitkä asiakkaat kuluttavat eniten tallennustilaa.

Kapasiteettiongelman ratkaisemiseksi selvitä, mitkä asiakkaat ovat vastuussa eniten tietojen lisäämisestä Avamar-järjestelmään.

pikanäppäimellä capacity.sh Komentosarjalla (suoritetaan Avamar Utility Node -komentoriviltä) voidaan myös tunnistaa, millä asiakkailla on suurin vaihtonopeus.

Katso Avamar: Kapasiteetin hallinta capacity.sh Komentosarja saadaksesi lisätietoja siitä, miten käyttää capacity.sh Kirjoitus.

Eniten tilaa käyttävät usein työasemat, jotka varmuuskopioivat SQL-tietokantoja tai sähköpostipalvelimia, joten tarkkaile niitä erityisesti.

4. Arvioi säilytyskäytännöt uudelleen.

Kun olet tunnistanut suuren muutosnopeuden, arvioi säilytyskäytännöt uudelleen nähdäksesi, voidaanko niitä alentaa tallennusvaatimusten vähentämiseksi hyväksyttävälle tasolle.

Jos järjestelmä on tarpeeksi vanha alkaakseen vanhentaa pisimpään säilytettyjä varmuuskopioita, odota säilytyskäytäntöjen vähentämisen jälkeen, että roskien keräämisen päivittäin poistamien tietojen määrä kasvaa. Seuraa tätä suuntausta capacity.sh.

Jos Avamar-järjestelmä ei ole vielä tarpeeksi vanha vanhentumiseen, säilytyskäytäntöjä on ehkä muutettava niin, että vanhimmat varmuuskopiot alkavat vanhentua.

Jos säilytyskäytäntöjä ei ole mahdollista vähentää sääntelyvaatimusten vuoksi, harkitse Avamar-järjestelmän laajentamista tai asiakkaiden siirtämistä toiseen, vähemmän käytettyyn Avamariin.

5. Asiakkaiden siirtäminen vaihtoehtoiseen Avamar-järjestelmään

Jos käytettävissä on toinen Avamar-järjestelmä, harkitse mahdollisuutta siirtää suuria tai suuren muutosnopeuden asiakkaita korkeamman tason järjestelmistä vähemmän käytettyihin järjestelmiin Avamar Client Manager -käyttöliittymän kautta.

6. Poista vanhoja varmuuskopioita.

Jos käyttäjän kapasiteettitaso on vaikea (>90 %), vanhat varmuuskopioinnit on ehkä vanhennettava varmuuskopioinnin hallintaliittymän kautta tai modify-snapups -työkalu. 

Dell-käyttäjät pääsevät sisältöön Avamar-artikkelin linkin kautta: Kapasiteetin hallinta - Varmuuskopioiden poistaminen tai vanhentaminen eränä "modify-snapups" työkalu

Varmuuskopioiden poistaminen ei heti alenna palvelimen käyttöastetta. Sen avulla roskien kerääminen voi alkaa poistaa tietoja seuraavan kerran, kun roskien keräys suoritetaan. Vanhojen varmuuskopioiden poistaminen on lyhytaikainen kiertotapa. Varmuuskopiot vaihdetaan lähipäivinä. Jos varmuuskopioita poistetaan, myös säilytyskäytäntöjä on tärkeää säätää.

7. Tietojen muutoksen seuranta capacity.sh.

Kun varmuuskopiot on poistettu ja säilytyskäytäntöjä muutettu, seuraa järjestelmässä muuttuneiden tietojen määrää tarkasti capacity.sh Kirjoitus. "Poistetun" data-arvon pitäisi kasvaa ja "nettomuutoksen" arvon pitäisi muuttua negatiiviseksi. Lopulta Removed-arvon pitäisi palata normaalimmalle tasolle, kun ylimääräiset tiedot on poistettu järjestelmästä. Tarkkaile edelleen Removed-arvoa.

Jos nettomuutosarvo ei muutu negatiiviseksi, tarkista GC-lokista, kuinka kauan roskien keräys on käynnissä ja kuinka paljon työtä se saavuttaa huoltoikkunan sisällä.

Katso Avamar: Kapasiteetin hallinta capacity.sh Komentosarja, jossa on lisätietoja capacity.sh Kirjoitus.

8. Laajenna Avamar-järjestelmä:

Usein Avamarin sähköverkon korkea käyttöaste johtuu luonnollisesta ja odotetusta datan kasvusta. Tuotannon varmuuskopioinnin jatkamista varten on oltava käytettävissä enemmän tilaa.

• Yhden solmun ruudukot ja Avamar Virtual Edition (AVE):

  • Näitä ei voi laajentaa. Ota käyttöön toinen, suurempi Avamar-järjestelmä ja pyydä Dell Professional Servicesiä suorittamaan järjestelmän siirto pienemmästä järjestelmästä suurempaan järjestelmään.
    • Ammattilaispalveluihin voi osallistua Dellin asiakaspäällikön kautta.
  • Uusi järjestelmä voi olla yksittäinen solmu, AVE tai monisolmujärjestelmä, jos se tarjoaa enemmän tallennustilaa kuin lähde.
• Monisolmuiset ruudukot:

  • Nämä järjestelmät voidaan laajentaa jopa 16 datasolmuun.
    • Kysy lisätietoja Dellin Account Managerilta (Tavalliset tukikanavat eivät tee solmulisäyksiä, joten tätä työtä pyytävää palvelupyyntöä ei tule avata.)
• Data Domainin integrointi:
  • Data Domain -järjestelmän integrointi taustatallennuslaitteeksi on kätevä tapa laajentaa Avamariin varmuuskopioivien asiakkaiden käytettävissä olevaa kapasiteettia.
    • Keskustele vaihtoehdoista Dellin asiakaspäällikön kanssa.

Hyödyllisiä työkaluja

• status.dpn
• capacity.sh
• Avalanche
• DPN Summary Report
• replcnt.sh
• Avamar Client Manager

• Yritä estää Avamar Serverin käyttöasteen (User Capacity) arvoa nousemasta yli 80 prosenttiin.
• Pienempi käyttäjäkapasiteetti tarjoaa sietokykyä odottamattomia muutoksia vastaan lisätyn tiedon määrässä ja voi suojata järjestelmää käyttökelvottomaksi, jos ilmenee odottamattomia vikoja tai lyhytaikaisia ongelmia ylläpitotehtävissä.
• Avamar-järjestelmän, jonka käyttäjäkapasiteetti on yli 80 %, on oltava huolellisempi järjestelmänvalvojan toimesta sen varmistamiseksi, että ylläpitotoimet onnistuvat ja että järjestelmä ei ole vain luku -tilassa.