Avamar: Koncept och utbildning för kapacitetshantering

För kapacitetshanteringsproblem som rör Data Domain, se avsnittet "Återta lagring på ett fullständigt Data Domain-system" i Systemintegreringsmanualen för Avamar och Data Domain. Guiderna som är relevanta för din driftmiljö finns i Hitta Avamar-dokumentationen på Dells supportwebbplats.

Mål för den här artikeln:

• Sammanfatta de typer av data som lagras i partitionerna /data*.
• Introducera begreppet "operativsystemkapacitet" och kontrastera detta med begreppet "användarkapacitet" (kallas ibland "GSAN-kapacitet").
• Förklara varför Avamar inte ska köras nära gränsen för användarkapacitet.
• Visa en lista över de faktorer som bidrar till kontrollpunktskostnader.
• Beskriv hur du övervakar användningen av datapartitioner.
• Beskriv de symtom som uppstår om operativsystemets kapacitet blir okontrollerbar.
• Lista typiska orsaker till MSG_ERR_DISKFULL Meddelande.
• Beskriv de återställningsmetoder som används när hög operativsystemskapacitet påverkar normal systemdrift.
• Beskriv de symptom som uppstår om användarkapaciteten överskrider gränsen för användarkapacitet.
• Diskutera hur du återställer från en situation med hög användarkapacitet.

Den här artikeln förutsätter att läsaren är bekant med avsnittet "Hantera kapacitet" i Avamar Operational Best Practices Guide. Guiderna som är relevanta för din driftmiljö finns i Hitta Avamar-dokumentationen på Dells supportwebbplats. Vanliga problem som påverkar, eller är symptom på, för hög operativsystemskapacitet är:

• Validering av kontrollpunkt (HFS-kontroll) misslyckas.
• Det går inte att köra skräpinsamlingen och rapporterar med en MSG_ERR_DISKFULL.
• Det gick inte att skapa kontrollpunkter.

Vanliga symptom som är nära associerade med för hög användarkapacitet är:

• Säkerhetskopieringar misslyckas.
• Inkommande replikeringsjobb misslyckas.
• Administrator-gränssnittet visar systemet i ”Admin”-läge under säkerhetskopieringsperioden.

Läs mer i avsnittet Upplösning.

Hur lagras data i Avamar-rutnätet?

Avamar-kapacitetshantering avser de data som finns i /data*-partitionerna för alla Avamar-datanoder. Detta består av:

• Deduplicerade säkerhetskopieringsdata
• RAIN-paritetsdata
• Omkostnadsdata för kontrollpunkter

Både RAIN-paritet och kontrollpunktsdata är redundanslager som är tillgängliga för Avamar utöver RAID och replikering.

Ledigt utrymme i datapartitionerna krävs också för att underhållsuppgifter som skräpinsamling och asynkron stripe crunching ska kunna köras korrekt.

Nedan visas en grafisk representation av det fysiska lagringsutrymmet som finns tillgängligt i datapartitionerna på Avamar-lagringsnoderna.

Hur lagras data i datapartitionerna?

I diagrammet ovan ser vi en enkel representation av hur utrymmet används i datapartitionerna.

Värdet 100 % till vänster definieras som den totala mängden fysiskt utrymme som är tillgängligt för operativsystemet i datapartitionerna.

Om någon av datapartitionerna förbrukar mer än 85 % av det totala utrymmet kan skräpinsamlingen inte köras.

Markören 100 % användarkapacitet (skrivskyddad gräns) anger att upp till 65 % av det totala utrymmet i datapartitionen är tillgängligt för lagring av deduplicerade data. Utrymmet under markören för 100 % användarkapacitet motsvarar värdet för serveranvändning som visas i administratörsgränssnittet. Om mängden deduplicerade data som lagras på en datapartition på en nod når 65 % blir Avamar-systemet skrivskyddat och nekar ytterligare säkerhetskopierade data.

Från Avamar Administrator-användargränssnittet kan vi nu förstå att användaren har insyn i det utrymme som säkerhetskopiorna har förbrukat, men inte i operativsystemets datapartitioner.

Varför ett Avamar-system inte ska köras nära gränsen för användarkapacitet.

Förhållandet mellan hög användarkapacitet och kontrollpunktspålägg är att när ett system blir allt mer fullt kan även små ökningar av säkerhetskopieringsdata leda till stora ökningar i kontrollpunktspålägg. En fullständig diskussion om varför så är fallet ligger utanför ramen för den här artikeln, men det viktiga att komma ihåg är:

• Ju närmare ett Avamar-system är 100 % användarkapacitet, desto mindre operativsystemskapacitet är tillgänglig för kontrollstationskostnader.

I ett fullständigt system, som vi kan se i diagrammet ovan, är kontrollpunktskostnaderna begränsade till 20 % av det totala operativsystemets utrymme i datapartitionerna.

För att ett Avamar-system ska kunna köras tillförlitligt med höga nivåer av "användarkapacitet" måste det uppfylla följande kriterier:

• Systemet måste ha en låg frekvens av dagliga ändrade data (inte högre än 1 %.)
• Kapaciteten måste vara stabil (enligt beskrivningen i avsnittet "Hantera kapacitet" i Avamar Operational Best Practices Guide)). De guider som är relevanta för din driftmiljö finns här: Hitta Avamar-dokumentationen på Dells supportwebbplats.
• Underhållsuppgifter ska slutföras utan problem varje dag.

Om någon av dessa påståenden ändras från sant till falskt kan kontrollpunktskostnaderna förväntas öka gradvis eller plötsligt öka och orsaka allvarliga driftsproblem.

Faktorer som bidrar till kontrollpunktspålägg:

Följande faktorer kan leda till att kontrollpunktspålägg ökar.

• Asynkron crunching av ränder (aktiverat som standard)
• Antalet kontrollpunkter som lagras i systemet
• Valideringen av kontrollpunkten slutförs inte varje dag.
• Hur tomma stripes är när Avamar-servern återanvänder dem (blir allvarligare med högre serveranvändning)
• Den dagliga ändringshastigheten för säkerhetskopiering<

En systemadministratör har en viss grad av kontroll över dessa faktorer. Konfiguration av asynkron crunching är endast för support, men administratörer kan ta bort överflödiga kontrollpunkter, undersöka kontrollpunktsfel och påverka serveranvändning och daglig dataändringshastighet.

Så här övervakar du användningen av datapartitioner:

Det korrekta sättet att övervaka användningen av operativsystemets datapartition är att använda följande Avamar-kommando från Avamar-verktygsnoden.

Till exempel:

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"

Denna utdata ger dig en sann avläsning av operativsystemets kapacitetsanvändning. I ett rutnät där datanoder använder en filpool df Kommandot är inte meningsfullt eftersom stripes är förallokerade i filpoolen och många av stripes kanske inte används.

Vad händer om operativsystemets kapacitetsanvändning hamnar utom kontroll?

Ur en användares synvinkel inträffar den första indikationen på att datapartitionsanvändningen är utom kontroll när den stiger över 85 %.

Skräpinsamlingen kan inte längre köras och misslyckas med en MSG_ERR_DISKFULL Felmeddelande.

Det är här som missförstånd ofta uppstår.
Användaren tolkar ofta MSG_ERR_DISKFULL innebär att det inte längre finns utrymme för säkerhetskopior i systemet.

Den här tolkningen är inte korrekt, men användaren kontrollerar vanligtvis serveranvändningsvärdet i Avamar Administrator-användargränssnittet och finner att värdet är acceptabelt, till exempel 60 %.

Användaren kan försöka ta bort säkerhetskopior från Avamar-gränssnittets gränssnitt för säkerhetskopieringshantering. Även om användarkapacitetsnivån var hög skulle borttagning av säkerhetskopior inte lindra situationen eftersom skräpinsamling inte kan köras och ta bort utgångna datasegment från systemet.

• Om ett system har både problem med hög operativsystemskapacitet och hög användarkapacitet ska du fokusera på att lösa problemet med hög operativsystemskapacitet först.

Vid hög kapacitetsanvändning i operativsystemet kan systemet få ont om utrymme för att skapa kontrollpunkter.

Vad är det som orsakar meddelandet MSG_ERR_DISKFULL?

Den vanligaste orsaken är för höga kontrollpunktspålägg. Vanliga orsaker till höga kontrollpunktspålägg kan vara:

• Validering av kontrollpunkt (HFScheck) har misslyckats upprepade gånger.
• HFScheck Fel har många möjliga rotorsaker (plötslig avbokning, programvarufel och så vidare).
• Systemet är för fullt och har en hög daglig dataändringshastighet.
• Systemet behöver fler datanoder för att hantera dataändringshastigheten och lagra data.
• Systemet är konfigurerat för att säkerhetskopiera mer data eller klienter än det var storleksanpassat för.
• För många kontrollpunkter lagras (Avamar lagrar två kontrollpunkter som standard, av vilka en har validerats).
• Systemadministratören har skapat överflödiga kontrollpunkter.
• Underhåll har nyligen utförts, men standardkvarhållandet av kontrollpunkter har inte återställts.

Se följande artikel för att lösa problemet MSR_ERR_DISKFULL situation: Avamar maintenance tasks fail with "MSG_ERR_DISKFULL" due to data partition operating system capacity >89%.

Åtgärder för att undersöka och hjälpa till att avhjälpa hög operativsystemkapacitet.

1. När den sista HFS-kontrollen avslutades

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äfta om HFScheck kördes eller om den misslyckades.

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.

Om schemaläggaren för underhållsfönster är "inaktiverad" aktiverar du den med kommandot dpnctl start maint.

När HFScheck har slutförts utan problem och den äldsta kontrollpunkten har "rullats av" systemet, bör operativsystemets kapacitet minska avsevärt.

Om operativsystemets kapacitet fortfarande är för hög och skräpinsamlingen fortsätter att misslyckas med det MSG_ERR_DISKFULL meddelandet kan Dells support behöva hjälp.

Annars, om operativsystemets kapacitet är tillräckligt låg för att tillåta skräpinsamling, bör du arbeta med att sänka "User Capacity" och sänka siffran för "server utilization".

 

Åtgärder för att avhjälpa hög användarkapacitet:

Till skillnad från operativsystemkapaciteten kan användarkapacitetsnivåerna lättare och mer direkt påverkas av Avamar-systemadministratören.

1. Se till att skräpinsamlingen körs varje dag och att den inte avbryts av säkerhetskopieringar.

Detta är den mest avgörande punkten eftersom även ett system av tillräcklig storlek snabbt upplever hög användarkapacitet om skräpinsamlingen inte körs regelbundet eller tillförlitligt.

Som du såg tidigare bekräftar du att underhållsperioden är aktiverad och använder skripten capacity.sh och sched.sh för att kontrollera att skräpinsamling körs och att data tas bort.

Före Avamar v7.x gick det inte att köra säkerhetskopieringar under fönstret för begränsning

av skräpsamling.Funktionen Hash-refererade bitkartor som introducerades med Avamar v7.x-funktionen gör att säkerhetskopieringar kan utföras under underhållsaktiviteten för skräpsamlingen. Funktionen kräver att mappningarna har minst 5 minuters tyst tid per dag då inga säkerhetskopieringar körs så att de kan återställas.

Innehåll om den här funktionen kan nås via länken till artikeln Avamar: Från Avamar v7 rapporterar skräpinsamlingen "överhoppade hashvärden" som inte kan rensas på grund av "hash-refererade bitkartor" när data används.

2. Sluta lägga till nya klienter i rutnätet.

När ett Avamar-system närmar sig full kapacitet bör vi omedelbart sluta lägga till nya klienter för att förhindra att situationen förvärras.

Om du har ett annat Avamar-rutnät som körs på en lägre serveranvändningsnivå bör du överväga att lägga till nya klienter i det rutnätet i stället för servern som börjar bli full.

3. Ta reda på vilka klienter som förbrukar mest lagringsutrymme.

För att åtgärda ett kapacitetsproblem bör vi identifiera vilka klienter som är ansvariga för att lägga till mest data i Avamar-systemet.

Det capacity.sh skriptet (som körs från kommandoraden för Avamar Utility Node) kan också användas för att identifiera vilka klienter som har den högsta ändringshastigheten.

Registrerade Dell-användare kan komma åt innehållet genom att klicka på länken till artikeln Avamar: Hantera kapacitet med capacity.sh-skriptet för mer information om hur du använder capacity.sh-skriptet .

Det visar sig ofta att de "hungrigaste" klienterna är de som säkerhetskopierar SQL-databaser eller e-postservrar, så var särskilt uppmärksam på dessa.

4. Gör en ny bedömning av kvarhållandepolicyer.

När du har identifierat klienter med hög ändringsfrekvens utvärderar du kvarhållningsprinciperna på nytt för att se om några kan sänkas för att minska lagringskraven till en acceptabel nivå.

5. Migrera klienter till ett alternativt Avamar-system.

Om ett annat Avamar-system finns tillgängligt bör du överväga möjligheten att migrera klienter med stor eller hög ändringsfrekvens från system med högre till lägre användning med hjälp av Avamar Client Manager-gränssnittet.

6. Ta bort gamla säkerhetskopior.

Om användarkapacitetsnivån är allvarlig (>90 %) kan det krävas att gamla säkerhetskopior går ut via gränssnittet för säkerhetskopieringshantering eller med verktyget modify-snapups. 

Dell-användare kommer åt innehållet via länken till artikeln Avamar Capacity Management: Så här tar du bort eller gör flera säkerhetskopior i anspråk samtidigt med verktyget "modify-snapups".

Att ta bort säkerhetskopior sänker inte omedelbart serveranvändningsnivån. Vad den gör är att skräpinsamlingen kan börja ta bort data nästa gång skräpinsamlingen körs. Att ta bort gamla säkerhetskopior är en kortsiktig lösning. Säkerhetskopiorna byts ut under de kommande dagarna. Om säkerhetskopior tas bort är det viktigt att även finjustera kvarhållningsprinciperna.

7. Övervaka dataändringar med hjälp av capacity.sh.

När säkerhetskopior har tagits bort och kvarhållningsprinciper har ändrats övervakar du noggrant mängden data som ändras i systemet med hjälp av capacity.sh skriptet. Du bör börja se att det "borttagna" datavärdet ökar och värdet "Nettoförändring" bör bli negativt. Så småningom, när överskottsdata rensats bort från systemet börjar värdet ”Removed” att återgå till mer normala nivåer. Fortsätt att övervaka värdet "Removed".

Om nettoändringsvärdet inte blir negativt kontrollerar du skräpinsamlingsloggen för att se hur länge skräpinsamlingen körs och hur mycket arbete den utför inom underhållsperioden.

Dell-användare kommer åt innehållet via länken till artikeln Avamar: Hantera kapacitet med capacity.sh-skriptet för mer information om hur du använder capacity.sh-skriptet .

8. Utöka Avamar-systemet

Ofta beror den höga kapacitetsanvändningen i Avamar-systemet på en naturlig och förväntad datatillväxt. Mer utrymme måste göras tillgängligt för att fortsätta produktionssäkerhetskopieringen.

Hur detta kan göras beror på typen av Avamar-system.

• System med en nod och Avamar Virtual Edition-system (AVE)

Dessa kan inte utökas. Driftsätt ett andra, större Avamar-system och begär Dell Professional Services för att utföra en systemmigrering från det mindre till det större systemet. Professionella tjänster kan anlitas via Dells Account Manager.

Det nya systemet kan vara en enda nod, AVE, eller ett flernodssystem, om det ger mer lagringsutrymme än källan.

• System med flera noder

Dessa system kan utökas till upp till 16 datanoder. Kontakta en Dell Account Manager om du vill ha mer information. Vanliga supportkanaler utför inte nodtillägg, så en tjänstebegäran bör inte öppnas för att begära detta arbete.

• Integrera Data Domain

Att integrera ett Data Domain-system som en backend-lagringsenhet är ett användbart sätt att utöka kapaciteten som är tillgänglig för klienter som säkerhetskopierar till Avamar. Diskutera olika alternativ med din Account manager på Dell.

Användbara verktyg

• status.dpn
• capacity.sh
• Avalanche
• DPN-sammanfattningsrapport
• replcnt.sh
• Avamar Client Manager

Bästa praxis:

• Försök att förhindra att värdet på Avamar Server-användningen (användarkapaciteten) överstiger 80 %.
• Lägre användarkapacitet ger motståndskraft mot oväntade förändringar i mängden data som läggs till och kan skydda mot att systemet blir oanvändbart om oväntade fel eller kortsiktiga problem med underhållsuppgifter uppstår.
• Ett Avamar-system med en kapacitet på över 80 % kräver noggrannare övervakning av systemadministratören för att säkerställa att underhållsåtgärder slutförs utan problem och att systemet inte blir skrivskyddat.