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 driftsmiljø, kan findes her: Sådan finder du Avamar-dokumentationen på Dells supportwebsted.

• Opsummer de typer data, der er gemt i partitionerne /data*.
• Introducer begrebet "Operating System (OS) Capacity" og kontrast dette med begrebet "User Capacity" (undertiden kaldet "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.

Igen kan de vejledninger, der er relevante for dit driftsmiljø, findes her: Sådan finder du Avamar-dokumentationen på Dells supportwebsted.

Almindelige problemer, der påvirker eller er symptomer på høj OS-kapacitet, er:

• Validering af kontrolpunkt (hfscheck) mislykkes.
• Affaldsindsamling kører ikke og rapporterer MSG_ERR_DISKFULL.
• Fejl ved oprettelse af kontrolpunkt.

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

Denne artikel indeholder begreberne omkring Avamar Capacity Management-koncepter og -kurser.

Hvordan gemmes data på Avamar-gitteret?

Avamar-kapacitetsstyring vedrører de data, der findes i partitionerne /data* i alle Avamar-datanoder.

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

Både RAIN-paritets- og kontrolpunktdata 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 (GC) 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 er der en simpel repræsentation af, hvordan rummet bruges i datapartitionerne.

Værdien 100 % til venstre er defineret til at være den samlede mængde fysisk plads, der er tilgængelig for operativsystemet i datapartitionerne.

• 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 skrivebeskyttet og nægter yderligere sikkerhedskopieringsdata.

Baseret på ovenstående kan det forstås, at brugeren fra Avamar Administrator UI har synlighed af plads, som sikkerhedskopier har brugt, men ikke har synlighed af 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: Jotættere et Avamar-system er på 100 % brugerkapacitet, jo mindre operativsystemkapacitet er der til rådighed for kontrolpunktets faste drev.

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

• 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:

• 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 brugen af OS-datapartitionen på er at bruge følgende Avamar-kommando fra Avamar-hjælpenoden:

avmaint nodelist | grep fs-percent        

Eksempel på output:

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 retvisende aflæ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 et brugersynspunkt forekommer den første indikation af, at udnyttelsen af datapartition er ude af kontrol, når den stiger over 89%.

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

Her opstår misforståelser ofte: 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?

• Validering af kontrolpunkt (hfscheck) er mislykkedes gentagne gange.
• En 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 med MSG_ERR_DISKFULL Scenario: Avamar: Vedligeholdelsesopgaver mislykkes med MSG_ERR_DISKFULL, fordi operativsystemets kapacitet på en eller flere datapartitioner overstiger 89 procent

Tiltag til at undersøge og hjælpe med at afhjælpe høj kapacitet i operativsystemet:

1. Bestem, hvornår den sidste hfscheck Færdig. Dette kan gøres ved hjælp af enten Avamar-administratoren eller kommandolinjen på Avamar-hjælpeprogrammet:

• I Avamar Java Administrator UI:
  • Gå til fanen Administration af serverkontrolpunkter >
  • Kontroller seneste dato og klokkeslæt, der er angivet i kolonnen Checkpoint Validation (Kontrolpunktvalidering). Dette bør være inden for de seneste 24 timer.

--Eller--

• Brug af kommandolinjen Avamar Utility Node:
  • Kør kommandoen: 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

• • • • Det seneste validerede kontrolpunkt, der er angivet her, er dateret 14. januar kl. 11:14.
      • Det identificeres af flaget direkte efter den 'gyldige' markør.
      • Afhængigt af de typer kontrolpunktvalideringer, der er angivet på systemet, kan flaget være rol eller hfs.
      • Dette er et eksempel på en rol (rullende) hfscheck.

Hvis resultaterne viser, at det seneste validerede kontrolpunkt er ældre end 24 timer, skal du finde ud af hvorfor. Dette kan enten skyldes, at HFScheck kørte ikke, eller fordi det mislykkedes.

2. Bekræft, om HFScheck RAN, eller hvis det mislykkedes:

På Avamar Utility Node skal du køre status.dpn kommando og find linjen, der starter med "Sidste hfscheck".

For eksempel:

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

Notér, hvornår den var færdig, og hvad status var (i linjen ovenfor vises status som 'OK').

Hvis hfscheck Arbejdspladser har svigtet, dette bør undersøges straks.

Hvis hfscheck ikke har kørt for nylig, skal du kontrollere, at vedligeholdelsesplanlægningsprogrammet er aktiveret ved at køre kommandoen "dpnctl status maint" på Avamar Utility Node: .

admin@utilitynode:~/>: dpnctl status maint

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

• Hvis vedligeholdelsesvinduesplanlægningsprogrammet er nede, deaktiveret eller afbrudt, skal du aktivere det med kommandoen: dpnctl start maint
• Du kan også tage et nyt kontrolpunkt og køre hfscheck, eller vent på, at det næste planlagte vedligeholdelsesvindue er fuldført.

En gang en hfscheck er fuldført (efter at have løst eventuelle problemer eller genstartet vedligeholdelsesplanlæggeren), vil det ældste kontrolpunkt blive "rullet af", og operativsystemets kapacitet bør reduceres betydeligt.

• Hvis operativsystemets kapacitet stadig er for høj, og affaldsindsamlingen fortsætter med at mislykkes med MSG_ERR_DISKFULL , og søg derefter hjælp hos Dells tekniske supportteam.
• Ellers, hvis operativsystemkapaciteten er lav nok til, at affaldsindsamlingen kan fuldføres, 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 capacity.sh og sched.sh scripts til at kontrollere, at affaldsindsamling kører, 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 GC-vedligeholdelsesaktiviteten. 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.

Indhold om denne funktion kan tilgås 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-net nærmer sig kapaciteten, skal du straks stoppe med at tilføje nye klienter for at forhindre, at situationen forværres.

Hvis der er et andet Avamar-netværk, 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 skal du identificere, hvilke klienter der er ansvarlige for at føje flest data til Avamar-systemet.

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

Se Avamar: Sådan administrerer du kapaciteten med capacity.sh script for mere infomraiotn om, hvordan man bruger capacity.sh Script.

Det konstateres ofte, at de "mest sultne" klienter er dem, der sikkerhedskopierer SQL-databaser eller e-mailservere, så vær særligt opmærksomme 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.

Hvis systemet er gammelt nok til at være begyndt at udløbe de længste opbevarede sikkerhedskopier, kan du forvente at se en stigning i mængden af data, der fjernes hver dag ved affaldsindsamling, efter at opbevaringspolitikkerne er reduceret. Overvåg denne tendens med capacity.sh.

Hvis Avamar-systemet endnu ikke er gammelt nok til at have startet udløbne sikkerhedskopier, kan det være nødvendigt at ændre opbevaringspolitikkerne, så de ældste sikkerhedskopier nu begynder at udløbe.

Hvis det ikke er muligt at reducere opbevaringspolitikker på grund af lovkrav, bør du overveje at udvide Avamar-systemet eller migrere klienter til en anden, mindre brugt, Avamar.

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 modify-snapups . 

Dell-brugere kan få adgang til indholdet ved hjælp af linket til artiklen Avamar: Kapacitetsstyring - Sådan sletter eller udløber du flere sikkerhedskopier ad gangen med "modify-snapups" værktøj

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 Script. Dataværdien "fjernet" bør stige, og værdien for "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 "Removed"-værdien.

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

Se Avamar: Sådan administrerer du kapaciteten med capacity.sh script for at få flere oplysninger om, hvordan du bruger capacity.sh Script.

8. Udvid Avamar-systemet:

Den høje udnyttelse på Avamar-nettet skyldes ofte naturlig og forventet datavækst. Der skal stilles mere plads til rådighed til at fortsætte sikkerhedskopiering af produktionen.

• Enkeltnodegitre og Avamar Virtual Edition (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.
• Gitre med flere noder:

  • Disse systemer kan udvides til op til 16 datanoder.
    • Kontakt Dells salgsrepræsentant for at få flere oplysninger (Almindelige supportkanaler tilføjer ikke noder, 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

• 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.