Avamar: Konsepter og opplæring for kapasitetsstyring

Når det gjelder kapasitetsstyringsproblemer knyttet til Data Domain, kan du se delen "Gjenvinne lagring på et fullstendig Data Domain-system" i veiledningen for systemintegrering av Avamar og Data Domain. Du finner veiledningene som er relevante for driftsmiljøet ditt, i Slik finner du Avamar-dokumentasjon på Dell Support-området.

Mål for denne artikkelen:

• Oppsummer datatypene som er lagret i /data*-partisjonene.
• Introduser begrepet "operativsystemkapasitet" og sammenlign dette med begrepet "brukerkapasitet" (noen ganger kalt "GSAN-kapasitet.")
• Forklar hvorfor Avamar ikke bør kjøres i nærheten av brukerkapasitetsgrensen.
• Oppgi faktorene som bidrar til kontrollpunktets overhead.
• Beskriv hvordan du overvåker bruken av datapartisjonen.
• Beskriv symptomene som oppleves hvis kapasiteten i operativsystemet kommer ut av kontroll.
• Oppgi typiske årsaker til MSG_ERR_DISKFULL Melding.
• Skissere gjenopprettingsmetodene som brukes der høy operativsystemkapasitet påvirker normal systemdrift.
• Beskriv symptomene som oppleves hvis brukerkapasiteten overskrider grensen for brukerkapasitet.
• Diskutere hvordan du gjenoppretter fra en situasjon med høy brukerkapasitet.

Denne artikkelen forutsetter at leseren er kjent med delen "Administrere kapasitet" i veiledningen om anbefalte fremgangsmåter for Avamar. Du finner veiledningene som er relevante for driftsmiljøet ditt, i Slik finner du Avamar-dokumentasjon på Dell Support-området. Vanlige problemer som påvirker, eller er symptomer, på for høy "operativsystemkapasitet" symptomer er:

• Kontrollpunktvalidering (HFS-kontroll) mislykkes.
• Søppelhenting mislykkes i å kjøre og rapporter med en MSG_ERR_DISKFULL.
• Kunne ikke opprette kontrollpunkt.

Her er noen vanlige symptomer som er nært forbundet med for høy "brukerkapasitet":

• Sikkerhetskopieringen mislykkes.
• Innkommende replikeringsjobber mislykkes.
• Administratorgrensesnittet viser at systemet er i "Admin"-modus under sikkerhetskopiperioden.

Se delen Løsning.

Hvordan lagres data på Avamar-rutenettet?

Avamar-kapasitetsadministrasjon gjelder dataene som befinner seg i /data*-partisjonene til alle Avamar-datanoder. Dette består av:

• Dedupliserte sikkerhetskopidata
• RAIN-paritetsdata
• Overhead-data for sjekkpunkt

Både RAIN-paritets- og kontrollpunktdata er redundanslag som er tilgjengelige for Avamar i tillegg til RAID og replikering.

Ledig plass i datapartisjonene er også nødvendig for at vedlikeholdsoppgaver som søppelinnsamling og asynkron stripeknusing skal fungere riktig.

Nedenfor finner du en grafisk fremstilling av den fysiske lagringsplassen som er tilgjengelig i datapartisjonene på Avamar-lagringsnodene.

Hvordan lagres data i datapartisjonene?

I diagrammet ovenfor ser vi en enkel fremstilling av hvordan plassen brukes i datapartisjonene.

100 %-verdien til venstre er definert som den totale mengden fysisk plass som er tilgjengelig for operativsystemet i datapartisjonene.

Hvis noen av datapartisjonene bruker mer enn 85 % av den totale plassen, kan ikke søppelrydding kjøres.

Markøren for 100 % brukerkapasitet (skrivebeskyttet grense) angir at opptil 65 % av den totale plassen i datapartisjonen er tilgjengelig for lagring av dedupliserte data. Plassen under denne markøren for 100 % brukerkapasitet tilsvarer verdien for serverutnyttelse som er synlig i administratorgrensesnittet. Hvis mengden dedupliserte data som er lagret på en datapartisjon på en hvilken som helst node, når 65 %, blir Avamar-systemet skrivebeskyttet og avviser ytterligere sikkerhetskopierte data.

Vi kan nå forstå at brukeren fra Avamar Administrator-brukergrensesnittet har oversikt over plassen som sikkerhetskopiene har brukt, men de har ikke oversikt over plassen som forbrukes i datapartisjonene i operativsystemet.

Hvorfor et Avamar-system ikke bør kjøres i nærheten av "User Capacity"-grensen.

Forholdet mellom høy "user capacity" og kontrollpunktbelastning er slik at etterhvert som et system blir fullere, kan selv små økninger i sikkerhetskopidata føre til store økninger i kontrollpunktbelastningen. En full diskusjon om hvorfor dette er tilfelle er utenfor omfanget av denne artikkelen, men det viktige å huske er:

• Jo nærmere et Avamar-system er 100 % brukerkapasitet, jo mindre operativsystemkapasitet er tilgjengelig for kontrollpunktkostnader.

På et fullt system, som vi kan se i diagrammet ovenfor, er kontrollpunktets overhead begrenset til 20% av den totale operativsystemplassen i datapartisjonene.

For at et Avamar-system skal kjøre pålitelig på høye nivåer av "brukerkapasitet", må det oppfylle følgende kriterier:

• Systemet må ha en lav frekvens av daglig endrede data (ikke høyere enn 1%.)
• Kapasiteten må være i stabil tilstand (som beskrevet i delen "Administrere kapasitet" i veiledningen for anbefalte fremgangsmåter for Avamar). Veiledningene som er relevante for ditt driftsmiljø, finner du her: Slik finner du Avamar-dokumentasjon på Dell Support-nettstedet.
• Vedlikeholdsoppgaver skal fullføres hver dag.

Hvis noen av disse utsagnene går fra sanne til falske, kan kontrollpunktets overhead forventes å gradvis stige eller plutselig øke og forårsake alvorlige driftsproblemer.

Faktorer som bidrar til kontrollpunktbelastning:

Følgende faktorer kan føre til at kontrollpunktbelastningen øker.

• Asynkron knusing av striper (aktivert som standard)
• Antall sjekkpunkter som er lagret på systemet
• Kontrollpunktvalideringen fullføres ikke hver dag.
• Hvor tomme stripene blir når Avamar-serveren bruker dem på nytt (blir mer alvorlig med høyere serverutnyttelse)
• Den daglige endringsfrekvensen for sikkerhetskopiering<

En systemadministrator kan kontrollere disse faktorene til en viss grad. Konfigurering av asynkron knusing er kun for støtte, men administratorer kan fjerne overflødige sjekkpunkter, undersøke sjekkpunktfeil og påvirke serverutnyttelse og daglig dataendringshastighet.

Slik overvåker du datapartisjonsutnyttelse:

Den riktige måten å overvåke bruken av operativsystemets datapartisjon på, er å bruke følgende Avamar-kommando fra Avamar-verktøynoden.

For eksempel:

admin@utilitynode:~/>: avmaint nodelist | grep fs-percent
        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"

Disse utdataene gir deg en nøyaktig avlesning av kapasitetsbruken til operativsystemet. På et rutenett der datanoder bruker en filpool, Linux df Kommandoen gir ikke mening fordi stripene er forhåndsallokert i filutvalget, og mange av stripene er kanskje ikke i bruk.

Hva skjer hvis kapasitetsbruken til operativsystemet kommer ut av kontroll?

Fra en brukers synspunkt oppstår den første indikasjonen på at datapartisjonsutnyttelsen er ute av kontroll når den stiger over 85%.

Søppelrydding er ikke lenger i stand til å kjøre og mislykkes med en MSG_ERR_DISKFULL Feilmelding.

Det er her misforståelser ofte oppstår.
Brukeren tolker ofte MSG_ERR_DISKFULL -melding som betyr at systemet ikke lenger har plass til sikkerhetskopiering.

Denne tolkningen er ikke riktig. Men brukeren kontrollerer vanligvis verdien for serverutnyttelse i Avamar Administrator-brukergrensesnittet og synes verdien er akseptabel, for eksempel 60 %.

Brukeren kan prøve å slette sikkerhetskopier fra Avamar-grensesnittet for sikkerhetskopiering. Selv om brukerkapasitetsnivået var høyt, ville sletting av sikkerhetskopier ikke lette situasjonen siden søppelrydding ikke kan kjøres, og fjerne utløpte biter av data fra systemet.

• Hvis et system opplever både et høyt problem med operativsystemets kapasitet og høy brukerkapasitet, fokuserer du på å løse problemet med høy operativsystemkapasitet først.

I tilfeller med høy utnyttelse av operativsystemets kapasitet kan systemet gå tom for plass til å opprette kontrollpunkter.

Hva er årsaken til meldingen MSG_ERR_DISKFULL?

Den vanligste årsaken er for høy kontrollpunktbelastning. Følgende er vanlige årsaker til høy kontrollpunktbelastning:

• Validering av kontrollpunkt (HFScheck) har mislyktes gjentatte ganger.
• HFScheck Feil har mange mulige årsaker (plutselig kansellering, programvarefeil og så videre).
• Systemet kjører for fullt og har en høy daglig dataendringshastighet.
• Systemet trenger flere datanoder for å håndtere hyppigheten av dataendringer og lagre dataene.
• Systemet er konfigurert for å sikkerhetskopiere flere data eller klienter enn det er beregnet for.
• For mange kontrollpunkter blir lagret (Avamar lagrer to kontrollpunkter som standard, og ett av disse er validert).
• Systemadministratoren opprettet overflødige sjekkpunkter.
• Det ble nylig utført vedlikehold, men standardoppbevaringen av kontrollpunkt ble ikke gjeninnført.

Se følgende artikkel for å få hjelp til å løse problemet MSR_ERR_DISKFULL situation: Avamar maintenance tasks fail with "MSG_ERR_DISKFULL" due to data partition operating system capacity >89%.

Tiltak for å undersøke og bidra til å redusere høy operativsystemkapasitet.

1. Når den siste HFScheck ferdig

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

 

2. Bekreft om HFScheck kjørte eller om det mislyktes.

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

admin@utilitynode:~/>: dpnctl status
Identity added: /home/admin/.ssh/dpnid (/home/admin/.ssh/dpnid)
dpnctl: INFO: gsan status: ready
dpnctl: INFO: MCS status: up.
dpnctl: INFO: EMS status: up.
dpnctl: INFO: Backup scheduler status: up.
dpnctl: INFO: dtlt status: up.
dpnctl: INFO: Maintenance windows scheduler status: enabled.
dpnctl: INFO: Maintenance cron jobs status: enabled.
dpnctl: INFO: Unattended startup status: disabled.

Hvis vedlikeholdsvindusplanleggeren er "deaktivert", aktiverer du den med kommandoen dpnctl start maint.

Når HFScheck er fullført og det eldste sjekkpunktet er "rullet av" systemet, bør operativsystemets kapasitet reduseres betraktelig.

Hvis kapasiteten i operativsystemet fortsatt er for høy, og søppelryddingen fortsatt mislykkes med MSG_ERR_DISKFULL-meldingen, kan det hende at Dell-kundestøtte trenger hjelp.

Ellers, hvis operativsystemets kapasitet er lav nok til å tillate søppelrydding, kan du jobbe med å senke "Brukerkapasitet" og bringe tallet "serverutnyttelse" ned.

 

Tiltak for å lindre høy brukerkapasitet:

I motsetning til operativsystemkapasitet blir brukerkapasitetsnivåene raskere og mer direkte påvirket av Avamar-systemadministratoren.

1. Forsikre deg om at søppelsamlingen kjører hver dag, og at den ikke blir avbrutt av sikkerhetskopier.

Dette er det mest avgjørende punktet, da selv et tilstrekkelig stort system raskt opplever høy brukerkapasitet hvis søppelinnsamling ikke kjører regelmessig eller pålitelig.

Som vist tidligere, bekreft at vedlikeholdsvinduet er aktivert, og bruk capacity.sh - og sched.sh-skriptene for å bekrefte at søppeltømming kjører, at det fjerner data.

Før Avamar v7.x kunne ikke sikkerhetskopieringer kjøres under begrensningsvinduet for søppelhenting.

Funksjonen Hash-refererte biterskart som ble introdusert med Avamar v7.x-funksjonen, gjør det mulig å sikkerhetskopiere under vedlikeholdsaktiviteten for søppelhenting. Denne funksjonen krever at disse "kartene" må ha minst 5 minutter med "stille" tid per dag der ingen sikkerhetskopier kjøres slik at de kan tilbakestilles.

Du får tilgang til innhold om denne funksjonen ved å bruke koblingen til artikkelen Avamar: Fra Avamar v7 rapporterer Garbage Collection "hoppet over hasher" som ikke kan ryddes opp på grunn av "Hash Referenced Bit Maps" når dataene er i bruk.

2. Slutt å legge til nye klienter i rutenettet.

Når et Avamar-system nærmer seg kapasiteten, bør vi umiddelbart slutte å legge til nye klienter for å forhindre at situasjonen forverres.

Hvis du har et annet Avamar-rutenett som kjører på et lavere nivå av serverutnyttelse, bør du vurdere å legge til nye klienter i rutenettet i stedet for serveren som blir full.

3. Finn ut hvilke klienter som bruker mest lagringsplass.

For å løse et kapasitetsproblem bør vi identifisere hvilke klienter som er ansvarlige for å legge til mest mulig data i Avamar-systemet.

Det capacity.sh skriptet (kjøres fra kommandolinjen Avamar Utility Node) kan også brukes til å identifisere hvilke klienter som har høyest endringsfrekvens.

Dell-registrerte brukere får tilgang til innholdet ved hjelp av koblingen til artikkelen Avamar: Slik administrerer du kapasiteten med det capacity.sh skriptet hvis du vil ha mer informasjon om hvordan du bruker det capacity.sh skriptet.

Det er ofte funnet at de "sultne" klientene er de som sikkerhetskopierer SQL-databaser eller e-postservere, så vær spesielt oppmerksom på disse.

4. Revurder oppbevaringspolicyer.

Etter å ha identifisert klienter med høy endringsfrekvens, bør du vurdere oppbevaringspolicyene på nytt for å se om noen kan senkes for å redusere lagringskravene til et akseptabelt nivå.

5. Migrer klienter til et alternativt Avamar-system.

Hvis et annet Avamar-system er tilgjengelig, bør du vurdere muligheten for å migrere store eller høye endringshastighetsklienter fra systemer med høyere til lavere bruk ved hjelp av Avamar Client Manager-grensesnittet.

6. Slett gamle sikkerhetskopier.

Hvis brukerkapasitetsnivået er alvorlig (>90 %), kan det være nødvendig å sende ut gamle sikkerhetskopier via grensesnittet for sikkerhetskopiering eller med modify-snapups-verktøyet. 

Dell-brukere kan få tilgang til innholdet ved hjelp av koblingen til artikkelen Avamar Capacity Management: Slik sletter eller utløper du sikkerhetskopier i bulk med modify-snapups-verktøyet.

Sletting av sikkerhetskopier reduserer ikke umiddelbart serverutnyttelsesnivået. Det den gjør er å la søppelinnsamling begynne å fjerne dataene neste gang søppelinnsamlingen går. Sletting av gamle sikkerhetskopier er en kortsiktig løsning. Sikkerhetskopiene byttes ut i løpet av de kommende dagene. Hvis sikkerhetskopier slettes, er det viktig å også justere oppbevaringspolicyene.

7. Overvåk dataendring ved hjelp av capacity.sh.

Når sikkerhetskopier er slettet og oppbevaringspolicyer er endret, følger du nøye med på datamengden som endres på systemet ved hjelp av det capacity.sh skriptet. Du bør begynne å se at "fjernet" dataverdiøkning og "Netto endring" -verdien skal bli negativ. Etterhvert som de overflødige dataene fjernes fra systemet, begynner "Removed"-verdien å gå tilbake til mer normale nivåer. Fortsett å overvåke "Removed"-verdien.

Hvis nettoendringsverdien ikke blir negativ, sjekk søppelinnsamlingsloggen for å se hvor lenge søppelinnsamlingen kjører og hvor mye arbeid den oppnår innenfor vedlikeholdsvinduet.

Dell-brukere får tilgang til innholdet ved hjelp av koblingen til artikkelen Avamar: Slik administrerer du kapasiteten med det capacity.sh skriptet hvis du vil ha mer informasjon om hvordan du bruker det capacity.sh skriptet.

8. Utvide Avamar-systemet

Regelmessig høy bruk på Avamar-systemet skyldes naturlig og forventet datavekst. Mer plass må gjøres tilgjengelig for å fortsette sikkerhetskopieringen av produksjonen.

Hvordan dette kan gjøres, avhenger av typen Avamar-system.

• Systemer med én node og Avamar Virtual Edition-systemer (AVE)

Disse kan ikke utvides. Bestill et annet, større Avamar-system, og be Dell Professional Services om å utføre en systemmigrering fra et mindre til et større system. Professional Services kan aktiveres via Dell Account Manager.

Det nye systemet kan være en enkelt node, AVE eller et multinodesystem, hvis det gir mer lagringsplass enn kilden.

• Systemer med flere noder

Disse systemene kan utvides til opptil 16 datanoder. Kontakt Dells kundekontakt hvis du vil ha mer informasjon. Vanlige støttekanaler utfører ikke nodetillegg, så en serviceforespørsel bør ikke åpnes for å be om dette arbeidet.

• Integrere Data Domain

Integrering av et Data Domain-system som en serverdel-lagringsenhet er en nyttig måte å utvide kapasiteten som er tilgjengelig for klienter som sikkerhetskopierer til Avamar. Diskuter alternativer med kundekontakten din hos Dell.

Nyttige verktøy

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

Beste framgangsmåte:

• Prøv å hindre at bruksverdien til Avamar Server (brukerkapasiteten) overskrider 80 %.
• Lavere brukerkapasitet gir motstandsdyktighet mot uventede endringer i mengden data som legges til, og kan beskytte mot at systemet blir ubrukelig hvis uventede feil eller kortsiktige problemer med vedlikeholdsoppgaver.
• Et Avamar-system som kjører over 80 % brukerkapasitet, krever mer omhyggelig overvåking av systemadministratoren for å sikre at vedlikeholdsoppgavene fullføres uten problemer, og at systemet ikke blir skrivebeskyttet.