Avamar: Felsökning, problem och frågor om kapacitet – all kapacitet (lösningssökväg)
Summary: Den här artikeln om lösningssökväg kan användas som utgångspunkt för alla problem med Avamar-kapacitet.
Symptoms
Kapacitet kan ses som de data eller det diskutrymme som används på en server av klientsäkerhetskopieringar av klientdata.
Kapacitetsproblem kan förhindra normal serverfunktionalitet från att lägga till nya data, eller ibland tillåta att gamla data rensas och tas bort.
- Träning
- Utbildning
- Frågor
- Problem med fel vid skräpinsamling (GC)
- Kapacitetsproblem i operativsystemet (OS)
GSANKapacitetsproblem- Problem med metadatakapacitet
- Problem med Data Domain-integreringskapacitet (DD)
Cause
Den här lösningen hjälper till att fastställa vilken typ av problem som har upplevts och sätt att åtgärda det.
Resolution
Kontrollera att varje felsökningssteg nedan gäller för din miljö. Varje steg innehåller instruktioner eller en länk till ett dokument för att eliminera möjliga orsaker och vidta korrigerande åtgärder vid behov. Stegen ordnas i den lämpligaste ordningen för att isolera problemet och identifiera rätt lösning. Hoppa inte över ett steg. Om det finns flera problem som uppstår på olika sätt med kapacitet måste de också åtgärdas i en viss ordning.
Även om Avamar nämns i de flesta av stegen kan integreringar av både Avamar – NetWorker och Avamar – Data Domain ändå ge upphov till många av problemen nedan.
Steg 1: Insamling av information: Om du vill förstå Avamar-kapacitetsproblem behöver du i allmänhet "måla upp en bild" för att se hela problemet och situationen. Ibland kan en aspekt av kapaciteten påverka en annan, eller så kanske vissa inte inser från början att det finns flera problem. Du måste ha fullständig förståelse för problemet för att felsökning ska kunna inledas.
Se Avamar: Hur du samlar in information som krävs för att felsöka kapacitetsproblem för informationsinsamling.
Steg 2: Utbildning: Om en kund vill ha utbildning eller förståelse för hur kapacitet fungerar, vad vissa värden betyder och så vidare kan den här artikeln användas. Det är fortfarande en bra idé att förstå deras problem och "måla upp en bild" eftersom frågor eller utbildning ofta kan vara resultatet av kapacitetsproblem.
Se Avamar Capacity General Training – Resolution Path för utbildningsrelaterade kapacitetsproblem.
Steg 3: Hög OS-kapacitet: Kontrollera värdena för operativsystemskapacitet från de insamlade utdata i steg 1. OS-kapaciteten begränsas av det HÖGSTA användningsvärdet i alla partitioner, även om andra är lägre. Det högsta värdet är den "begränsande faktorn" och måste minskas.
Om det högsta användningsvärdet för en nodpartition överstiger 89 % läser du Avamar OS-kapacitet (lösningssökväg)
Steg 4: Skräpinsamlingsfel eller fel: Om ett Avamar-skräpinsamlingsjobb matar ut felmeddelanden från insamlade utdata måste det åtgärdas härnäst innan återstående typer av kapacitetsproblem.
Information om den här typen av problem finns i Avamar – Felsöka fel vid skräpinsamling (GC) (lösningssökväg)
Steg 5: Hög GSAN-kapacitet: Om det inte finns några problem med OS-kapaciteten och GC inte visar felmeddelanden från insamlade utdata granskar du GSAN Kapacitetsvärden:
Från status.dpninnebär ett värde på 65 % att rutnätet är fullt (även kallat "admin"-läge eller skrivskyddat) och att det inte finns något utrymme kvar för kapacitetstillväxt.
GSAN kapaciteten är cirka 63 % (på grund av något som kallas disknormaldelta)
Information om dessa situationer finns i Avamar GSAN (eller användare) Kapacitet (lösningssökväg)
Steg 6: Metadatakapacitet: När en Data Domain integreras med Avamar introduceras en ny kapacitetsgräns – Metadata Capacity. Metadatakapacitet är kapacitet som finns på Avamar.
Med Data Domain-integreringar kan data dirigeras och skickas till Data Domain för lagring, men Avamar innehåller fortfarande säkerhetskopieringsfilernas metadata på Avamar. Avamar spårar den här kapaciteten för metadata som metadatakapacitet.
När steg 1–5 har granskats och eventuella kapacitetsrelaterade problem åtgärdats kan du granska Upplösning av metadatakapacitet i Avamar Metadata Capacity Resolution Path.
Steg 7: Hög Data Domain-kapacitet: När en Data Domain är integrerad med Avamar kan Data Domain-servern fylla sin kapacitet.
Följande artikel om lösningssökväg: hjälper till att avgöra:
- Vilka potentiella problem från Avamar kan leda till att Data Domain-kapaciteten växer eller blir full.
- Vissa Data Domain-specifika problem
- Om Data Domain är fullt av skäl som inte är relaterade till Avamar.
När steg 1–6 har granskats och eventuella kapacitetsrelaterade problem åtgärdats kan du läsa Data Domain sökväg med hög kapacitet från Avamar-integreringsupplösning
Övriga frågor: Dessa kan fortfarande ses som problem eller problem som påverkar kapaciteten:
- Replikeringskälla och målkapacitet matchar inte: När du replikerar data med Avamar eller andra integrerade produkter finns det en förväntan att kapaciteten matchar i rutnäten för replikeringskälla och replikeringsmål.
GSAN kapacitet på BÅDA rutnäten, men kräver alltid att ytterligare valideringar utförs kring replikeringskonfigurationen och jobbstatus om det finns andra kapacitetsrelaterade problem: Avamar: Ett replikerande par visar olika nivåer av kapacitetsanvändning. Hur man undersöker orsakerna.
- Management Console Server (MCS) rapporterar följande meddelande:
2012/10/06-21:11:09.75264 {0.4} [manage:3070] ERROR: <0001> diskinfo::update invalid disk space parameters dev=831 total=1906261MB avail=1675818MB reserved=223410MB maxmb=223978MB newavail=1675818MB reservedoverflow=1 availmboverflow=0
Det här är ett rapporteringsproblem om stripe-kapacitet i MC-användargränssnittet (UI) som endast är vagt relaterat till de andra kapacitetsavsnitten som diskuteras här. Det finns ingen identifierad effekt av detta förutom att meddelandet visas i användargränssnittet.
- Rapporter om kapacitetsprognoser: