Avamar: Kapacitetsstyringskoncepter og træning

Hvis du har problemer med kapacitetsstyring i forbindelse med Data Domain, skal du se afsnittet "Genvinding af storage på et komplet Data Domain-system" i Avamar og Data Domain System Integration Guide. De vejledninger, der er relevante for dit operativsystem, findes i Sådan finder du Avamar-dokumentationen på Dells supportwebsted.

Formål med denne artikel:

• Opsummer de typer data, der er gemt i partitionerne /data*.
• Introducer begrebet "operativsystemkapacitet", og sammenlign dette med begrebet "brugerkapacitet" (kaldes undertiden "GSAN-kapacitet").
• Forklar, hvorfor Avamar ikke bør køres tæt på grænsen for brugerkapacitet.
• Angiv de faktorer, der bidrager til kontrolpunktets omkostninger.
• Beskriv, hvordan du overvåger udnyttelse af datapartitioner.
• Beskriv de symptomer, der opstår, hvis operativsystemets kapacitet kommer ud af kontrol.
• Angiv typiske årsager til MSG_ERR_DISKFULL Besked.
• Beskriv de genoprettelsesmetoder, der anvendes, hvor høj operativsystemkapacitet påvirker normal systemdrift.
• Beskriv de symptomer, der opstår, hvis brugerkapaciteten overskrider grænsen for brugerkapacitet.
• Diskuter, hvordan du gendanner efter en situation med høj brugerkapacitet.

Denne artikel forudsætter, at læseren er bekendt med afsnittet "Administration af kapacitet" i Avamars vejledning til bedste fremgangsmåder for drift. De vejledninger, der er relevante for dit operativsystem, findes i Sådan finder du Avamar-dokumentationen på Dells supportwebsted. Almindelige problemer, der påvirker eller er symptomer på for høje symptomer på "operativsystemkapacitet", er:

• Validering af kontrolpunkter (HFS Check) mislykkes.
• Affaldsindsamlingen kører ikke og rapporterer med en MSG_ERR_DISKFULL.
• Fejl ved oprettelse af kontrolpunkt.

Almindelige symptomer, der er tæt forbundet med for høj brugerkapacitet, er:

• Sikkerhedskopieringer mislykkes.
• Indgående replikeringsjob mislykkes.
• Administratorgrænsefladen viser, at systemet i administratortilstand under visningen af sikkerhedskopieringsvinduet.

Se løsningsafsnittet.

Hvordan gemmes data på Avamar-gitteret?

Avamar-kapacitetsstyring vedrører de data, der findes i partitionerne /data* i alle Avamar-datanoder. Dette består af:

• Deduplikerede sikkerhedskopierede data
• RAIN-paritetsdata
• Faste data for kontrolpunkter

Både RAIN-paritets- og kontrolpunktsdata er lag af redundans, der er tilgængelige for Avamar ud over RAID og replikering.

Der kræves også ledig plads i datapartitionerne, for at vedligeholdelsesopgaver som affaldsindsamling og asynkron stribeknusning kan køre korrekt.

Nedenfor finder du en grafisk fremstilling af den fysiske tilgængelige lagerplads i datapartitionerne på Avamar-lagernoderne.

Hvordan gemmes data i datapartitionerne?

I ovenstående diagram ser vi en simpel repræsentation af, hvordan rummet bruges i datapartitionerne.

100%-værdien til venstre defineres som den samlede mængde fysisk plads, der er tilgængelig for operativsystemet i datapartitionerne.

Hvis nogen af datapartitionerne bruger mere end 85% af den samlede plads, kan affaldsindsamling ikke køre.

Markøren 100 % brugerkapacitet (skrivebeskyttet grænse) angiver, at op til 65 % af den samlede plads på datapartitionen er tilgængelig til lagring af deduplikerede data. Pladsen under denne 100 % brugerkapacitetsmarkør svarer til den serverudnyttelsesværdi, der er synlig i administratorbrugergrænsefladen. Hvis mængden af deduplikerede data, der er gemt på en datapartition på en node, når 65%, bliver Avamar-systemet skrivebeskyttet og nægter yderligere sikkerhedskopieringsdata.

Vi kan nu forstå, at brugeren fra Avamar Administrator UI har synlighed over plads, som sikkerhedskopier har brugt, men de har ikke synlighed over plads, der forbruges i operativsystemets datapartitioner.

Hvorfor et Avamar-system ikke bør køres tæt på grænsen for "Brugerkapacitet".

Forholdet mellem høj brugerkapacitet og kontrolpunkt-overhead er sammensat således, at når et system bliver mere og mere fuldt, kan selv små stigninger i sikkerhedskopieringsdata forårsage store stigninger i kontrolpunkt-overhead. En fuldstændig diskussion af, hvorfor dette er tilfældet, ligger uden for denne artikels anvendelsesområde, men det vigtige at huske er:

• Jo tættere et Avamar-system er på 100 % brugerkapacitet, jo mindre operativsystemkapacitet er der til rådighed for kontrolpunktets faste omkostninger.

På et komplet system, som vi kan se i diagrammet ovenfor, er kontrolpunktets omkostninger begrænset til 20% af den samlede operativsystemplads i datapartitionerne.

Hvis et Avamar-system skal køre pålideligt ved høj "brugerkapacitet", skal det opfylde følgende kriterier:

• Systemet skal have en lav andel af dagligt ændrede data (højst 1 %.)
• Kapaciteten skal være i stabil tilstand (som beskrevet i afsnittet "Administration af kapacitet" i Avamar Operational Best Practices Guide). De vejledninger, der er relevante for dit driftsmiljø, kan findes her: Sådan finder du Avamar-dokumentationen på Dells supportwebsted.
• Der skal fuldføres vedligeholdelsesopgaver hver dag.

Hvis nogen af disse udsagn går fra sandt til falsk, kan kontrolpunktets omkostninger forventes gradvist at stige eller pludselig stige og forårsage alvorlige driftsproblemer.

Faktorer, der bidrager til kontrolpunkt-overhead:

Følgende faktorer kan forårsage, at kontrolpunkt-overhead øges.

• Asynkron knusning af striber (aktiveret som standard)
• Antallet af kontrolpunkter, der er gemt i systemet
• Checkpoint-validering fuldføres ikke korrekt hver dag.
• Hvor tomme striber er, når Avamar-serveren genbruger dem (bliver mere alvorlige med højere serverudnyttelse)
• Den daglige ændringshastighed for backup<

En systemadministrator har en vis grad af kontrol over disse faktorer. Konfiguration af asynkron crunching er kun til support, men administratorer kan fjerne overskydende kontrolpunkter, undersøge kontrolpunktfejl og påvirke serverudnyttelsen og den daglige dataændringshastighed.

Sådan overvåges udnyttelsen af datapartitioner:

Den korrekte måde at overvåge udnyttelsen af operativsystemets datapartition på er at bruge følgende Avamar-kommando fra Avamar-hjælpeprogramnoden.

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"

Dette output giver en reel læsning af operativsystemets kapacitetsudnyttelse. På et gitter, hvor datanoder bruger en filpulje, vil Linux df Kommandoen giver ikke mening, fordi striberne er forudallokeret i filpuljen, og mange af striberne er muligvis ikke i brug.

Hvad sker der, hvis kapacitetsforbruget for operativsystemet kommer ud af kontrol?

Fra en brugers synspunkt sker den første indikation af, at udnyttelsen af datapartition er ude af kontrol, når den stiger over 85%.

Affaldsindsamlingen kan ikke længere køre og mislykkes med en MSG_ERR_DISKFULL Fejlmeddelelse.

Her opstår der ofte misforståelser.
Brugeren fortolker ofte MSG_ERR_DISKFULL Meddelelse for at betyde, at systemet ikke længere har plads til sikkerhedskopieringer.

Denne fortolkning er ikke korrekt, men brugeren kontrollerer normalt serverudnyttelsesværdien i Avamar Administrator-brugergrænsefladen og finder værdien acceptabel, f.eks. 60 %.

Brugeren kan forsøge at slette sikkerhedskopier fra Avamar UI's grænseflade til administration af sikkerhedskopiering. Selv hvis brugerkapacitetsniveauet var højt, ville sletning af sikkerhedskopier ikke afhjælpe situationen, da affaldsindsamling ikke er i stand til at køre og fjerne udløbne klumper af data fra systemet.

• Hvis et system både oplever et problem med høj operativsystemkapacitet og høj brugerkapacitet, skal du først fokusere på at løse problemet med høj operativsystemkapacitet.

I tilfælde af høj udnyttelse af operativsystemets kapacitet kan systemet løbe tør for plads til at oprette kontrolpunkter.

Hvad er årsagen til MSG_ERR_DISKFULL-meddelelsen?

Den mest typiske årsag er for højt kontrolpunkt-overhead. Typiske årsager til højt kontrolpunkt-overhead kan være:

• Validering af kontrolpunkt (HFScheck) er mislykkedes gentagne gange.
• HFScheck Fejl har mange mulige grundlæggende årsager (pludselig annullering, softwarefejl osv.).
• Systemet kører for fuldt og har en høj daglig dataændringshastighed.
• Systemet skal bruge flere datanoder til at håndtere dataændringshastigheden og gemme dataene.
• Systemet er konfigureret til at sikkerhedskopiere mere data eller flere klienter, end det er dimensioneret til.
• Der gemmes for mange kontrolpunkter (Avamar lagrer to kontrolpunkter som standard, et af dem er blevet valideret).
• Systemadministratoren oprettede overskydende kontrolpunkter.
• Der blev gennemført vedligeholdelse for nylig, men standardlagring af kontrolpunkter blev ikke genindsat.

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

Foranstaltninger, der skal undersøge og hjælpe med at afhjælpe høj kapacitet i operativsystemet.

1. Når den sidste HFScheck er færdig

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. Bekræft, om HFScheck kørte, eller om det mislykkedes.

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 vedligeholdelses Windows scheduler er 'deaktiveret', skal du aktivere den med kommandoen dpnctl start maint.

Når HFScheck er fuldført, og det ældste kontrolpunkt er "rullet af" systemet, bør operativsystemets kapacitet reduceres betydeligt.

Hvis kapaciteten i operativsystemet stadig er for høj, og affaldsindsamlingen fortsætter med at mislykkes med MSG_ERR_DISKFULL meddelelsen, kan Dell Support have brug for hjælp.

Ellers, hvis operativsystemkapaciteten er lav nok til at tillade affaldsindsamling, skal du arbejde på at sænke "Brugerkapacitet" og bringe tallet "Serverudnyttelse" ned.

 

Foranstaltninger til afhjælpning af høj brugerkapacitet:

I modsætning til operativsystemets kapacitet påvirkes brugerkapacitetsniveauerne lettere og direkte af Avamar-systemadministratoren.

1. Sørg for, at affaldsindsamlingen kører hver dag, og at den ikke bliver afbrudt af sikkerhedskopier.

Dette er det mest afgørende punkt, da selv et system i passende størrelse hurtigt oplever høj brugerkapacitet, hvis affaldsindsamling ikke kører regelmæssigt eller pålideligt.

Som vist tidligere skal du bekræfte, at vedligeholdelsesvinduet er aktiveret, og bruge scriptene capacity.sh og sched.sh til at kontrollere, at affaldsindsamlingen kører, og at den fjerner data.

Før Avamar v7.x kunne sikkerhedskopier ikke køre under vinduet "begrænsning" af affaldsindsamling.

Funktionen Hash Referenced Bit Maps, der blev introduceret med Avamar v7.x-funktionen, gør det muligt at foretage sikkerhedskopieringer under vedligeholdelsesaktiviteten for affaldsindsamlingen. Denne funktion kræver, at disse "kort" skal have mindst 5 minutters "stille" tid om dagen, hvor der ikke køres sikkerhedskopier, så de kan nulstilles.

Du kan få adgang til indhold om denne funktion ved hjælp af linket til artiklen Avamar: Fra Avamar v7 rapporterer Garbage Collection "sprunget hashes over", der ikke kan ryddes op på grund af "Hash Referenced Bit Maps", når dataene er i brug.

2. Stop med at føje nye klienter til nettet.

Når et Avamar-system nærmer sig kapaciteten, bør vi øjeblikkeligt stoppe med at tilføje nye klienter for at forhindre, at situationen forværres.

Hvis du har et andet Avamar-gitter, der kører på et lavere niveau af serverudnyttelse, kan du overveje at føje nye klienter til dette gitter i stedet for serveren, som er ved at blive fuld.

3. Find ud af, hvilke klienter der bruger mest lagerplads.

For at løse et kapacitetsproblem bør vi identificere, hvilke kunder der er ansvarlige for at tilføje flest data til Avamar-systemet.

Scriptet capacity.sh (kørt fra kommandolinjen i Avamar Utility Node) kan også bruges til at identificere, hvilke klienter der har den højeste ændringshastighed.

Dell-registrerede brugere kan få adgang til indholdet ved hjælp af linket til artiklen Avamar: Sådan administrerer du kapacitet med scriptet til capacity.sh for at få flere oplysninger om, hvordan du bruger scriptet til capacity.sh .

Det viser sig ofte, at de 'sulteste' klienter er dem, der sikkerhedskopierer SQL-databaser eller e-mail-servere, så vær særlig opmærksom på disse.

4. Revurder opbevaringspolitikker.

Når du har identificeret klienter med høj ændringsrate, skal du revurdere opbevaringspolitikker for at se, om nogen kan sænkes for at reducere lagerkravene til et acceptabelt niveau.

5. Migrer klienter til et alternativt Avamar-system.

Hvis der findes et andet Avamar-system, bør du overveje muligheden for at migrere klienter med stor ændringshastighed fra systemer med højere til mindre brugte systemer ved hjælp af Avamar Client Manager-grænsefladen.

6. Slet gamle sikkerhedskopier.

Hvis brugerkapacitetsniveauet er alvorligt (>90 %), kan det være nødvendigt at udløbe gamle sikkerhedskopier via Backup Management-grænsefladen eller med værktøjet modify-snapups. 

Dell-brugere kan få adgang til indholdet ved hjælp af linket til artiklen Avamar Capacity Management: Sådan sletter eller udløber du sikkerhedskopier i bulk med værktøjet "modify-snapups".

Sletning af sikkerhedskopier sænker ikke serverens udnyttelsesniveau med det samme. Hvad det gør er at tillade affaldsindsamling at begynde at fjerne dataene, næste gang affaldsindsamling kører. Sletning af gamle sikkerhedskopier er en kortsigtet løsning. Sikkerhedskopierne udskiftes i løbet af de kommende dage. Hvis sikkerhedskopier slettes, er det vigtigt også at tilpasse opbevaringspolitikkerne.

7. Overvåg dataændringer ved hjælp af capacity.sh.

Når sikkerhedskopier er blevet slettet, og opbevaringspolitikker er blevet ændret, skal du nøje overvåge mængden af data, der er ændret på systemet ved hjælp af capacity.sh scriptet. Du bør begynde at se, at dataværdien "fjernet" og værdien "Nettoændring" bør blive negativ. Efterhånden som overskydende data ryddes af systemet, begynder værdien "Removed" at vende tilbage til mere normale niveauer. Fortsæt med at overvåge værdien "Fjernet".

Hvis nettoændringsværdien ikke bliver negativ, skal du kontrollere affaldsindsamlingsloggen for at se, hvor længe affaldsindsamling kører, og hvor meget arbejde den opnår inden for vedligeholdelsesvinduet.

Dell-brugere kan få adgang til indholdet ved hjælp af linket til artiklen Avamar: Sådan administrerer du kapacitet med scriptet til capacity.sh for at få flere oplysninger om, hvordan du bruger scriptet til capacity.sh .

8. Udvidelse af Avamar-systemet

Ofte skyldes høj udnyttelse af Avamar-systemet naturlig og forventet datavækst. Der skal stilles mere plads til rådighed til at fortsætte sikkerhedskopiering af produktionen.

Hvordan dette kan gøres, afhænger af typen af Avamar-system.

• Systemer med enkeltnoder og Avamar Virtual Edition-systemer (AVE)

Disse kan ikke udvides. Isæt et andet, større Avamar-system, og bed Dell Professional Services om at udføre en systemmigrering fra det mindre til det større system. Professionelle services kan benyttes via Dells salgsrepræsentant.

Det nye system kan være et system med en enkelt node, AVE eller et system med flere noder, hvis det giver mere lagerplads end kilden.

• System med flere noder

Disse systemer kan udvides til op til 16 datanoder. Kontakt Dells salgsrepræsentant for at få flere oplysninger. Almindelige supportkanaler udfører ikke nodetilføjelser, så en serviceanmodning bør ikke åbnes for at anmode om dette arbejde.

• Integrer Data Domain

Integration af et Data Domain-system som en backend-storageenhed er en nyttig metode til at udvide den kapacitet, der er tilgængelig for klienter, som sikkerhedskopierer til Avamar. Tal om mulighederne med din Dell-salgsrepræsentant.

Nyttige værktøjer

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

Bedste fremgangsmåde:

• Forsøg at forhindre, at Avamar-serverens udnyttelsesværdi (brugerkapacitet) stiger til mere end 80 %.
• Lavere brugerkapacitet giver robusthed over for uventede ændringer i mængden af tilføjede data og kan beskytte mod, at systemet bliver ubrugeligt ved uventede fejl eller kortvarige problemer med vedligeholdelsesopgaver.
• Et Avamar-system, der kører med en brugerkapacitet på over 80 %, kræver mere omhyggelig overvågning fra systemadministratorens side for at sikre, at vedligeholdelsesopgaver fuldføres korrekt, og at systemet ikke bliver skrivebeskyttet.