Data Domain: Lösa problem med stor utrymmesanvändning eller brist på tillgänglig kapacitet på DDR-enheter (Data Domain Restorer)

 

• Det är den del av disken där nyligen inhämtade filer/data lagras, och på de flesta DDR:er ligger filerna kvar här tills de har gått ut/tagits bort av ett program för klientsäkerhetskopiering
• På DDR:er som konfigurerats med utökad lagring eller långsiktig lagring kan dataförflyttningen köras regelbundet för att migrera gamla filer från den aktiva nivån till arkiv- eller molnnivåer
• Det enda sättet att frigöra utrymme på den aktiva nivån som används av borttagna/migrerade filer är att köra en skräpinsamling/rensning

• Den aktiva nivån kan börja få slut på tillgängligt utrymme vilket gör att varningar/meddelanden som påminner om nedanstående visas:

• Om den aktiva nivån är 100 % full går det inte att skriva några nya data till DDR-enheten, vilket kan leda till att det inte går att genomföra säkerhetskopiering/replikering. I det scenariot kan följande varningar/meddelanden visas:

• När den aktiva nivån blir full kan det ibland leda till att Data Domain File System (DDFS) skrivskyddas och att befintliga filer därmed inte kan tas bort

• förklara varför den aktiva nivån kan bli full
• Beskriver en enkel uppsättning kontroller som kan utföras för att fastställa orsaken till hög användning av den aktiva nivån och motsvarande åtgärdssteg

• Den här artikeln är inte heltäckande (dvs. det kan finnas ett litet antal situationer där utrymmet på den aktiva nivån på en DDR-enhet utnyttjas i hög grad/blir fullt av en anledning som inte tas upp i det här dokumentet), men avsikten är att artikeln ska omfatta de vanligaste orsakerna/problemen
• Den här artikeln omfattar inte stor utrymmesanvändning på arkiv- eller molnnivåer

  Användningsgraden på den aktiva nivån i en DDR-enhet kan vara högre än förväntat av olika anledningar:

• Säkerhetskopior/sparuppsättningar anges inte som inaktuella eller tas inte bort på rätt sätt av klientprogram för säkerhetskopiering på grund av felaktig lagringspolicy eller konfiguration av säkerhetskopieringsprogrammet
• Replikeringsfördröjning gör att en stor mängd gamla data lagras på den aktiva nivån i väntan på replikering till kopior
• Data som skrivs till den aktiva nivån har lägre totalt komprimeringsförhållande än förväntat
• Systemet har inte storleksanpassats korrekt, dvs. det är helt enkelt för litet för den mängd data som det förväntas rymma
• Säkerhetskopior består av ett stort antal mycket små filer – dessa filer förbrukar mycket mer utrymme än vad som förväntas när de först skrivs. Det utrymmet bör emellertid frigöras under rensning/skräpinsamling
• Dataöverföring körs inte regelbundet på system som är konfigurerade med ER/LTR, vilket gör att gamla filer som borde migreras till arkiv-/molnnivåer finns kvar på den aktiva nivån
• Rensning/skräpinsamling körs inte regelbundet
• För många eller gamla mtree-snapshots finns på DDR-enheten, vilket förhindrar att utrymme återtas från borttagna filer/data vid rensningen

Steg 1 – Ta reda på om en rensning av den aktiva nivån måste köras

Data Domain Operating System (DDOS) försöker upprätthålla en räknare som kallas ”Cleanable GiB” för den aktiva nivån. Det här är en uppskattning av hur mycket fysiskt utrymme (efter komprimering) som potentiellt kan frigöras på den aktiva nivån när en rensning/skräpinsamling körs. Den här räknaren visas med kommandona ”filesys show space”/”df”:
 
Om något av följande gäller:

• Värdet för ”Cleanable GiB” är stort
• DDFS är 100 % fullt (och är därför skrivskyddat)

ska rensningen utföras och köras tills den avslutas innan du går vidare med några andra steg i det här dokumentet. Starta rensningen med kommandot ”filesys clean start”, dvs.:
 
Kontrollera att rensningen har startats som förväntat med kommandot ”filesys status”, dvs.:
 
Observera följande:

• Om det inte går att starta rensningen kontaktar du den kontrakterade supportleverantören för att få ytterligare hjälp. Det här problemet kan tyda på att ett fel med att segment saknas har inträffat på systemet och gjort att rensningen har avaktiverats.
• Om rensning redan körs visas följande meddelande när du försöker starta en rensning:

• Inget utrymme på den aktiva nivån frigörs/återtas förrän rensningen når kopieringsfasen (som standard fas 9 i DDOS 5.4.x och tidigare och fas 11 i DDOS 5.5.x och senare). Mer information om faserna för rensningen finns i: https://support.emc.com/kb/446734
• Det kan hända att den mängd utrymme som anges av ”Cleanable GiB” inte frigörs vid rensningen eftersom det värdet i själva verket är en uppskattning. Mer information om detta finns i: https://support.emc.com/kb/485637
• Det kan hända att inte allt potentiellt utrymme frigörs i en enda körning – det beror på att rensningen på DDR-enheter som innehåller mycket stora datauppsättningar körs mot den del av filsystemet som innehåller mest överflödiga data (för att ge bästa möjliga resultat vad gäller ledigt utrymme under den tid som det tar att köra rensningen). I vissa fall kanske rensning måste köras flera gånger innan allt möjligt utrymme har frigjorts
• Om värdet för ”Cleanable GiB” är mycket stort kan det tyda på att rensning inte har körts regelbundet – kontrollera att ett rensningsschema har ställts in:

När rensningen är klar använder du kommandona ”filesys show space”/”df” för att kontrollera om problemen med utrymmesanvändning har lösts. Om användningsgraden fortfarande är hög går du vidare med återstående steg i den här artikeln.

Steg 2 – Kontrollera om det förekommer stor replikeringsfördröjning mot källreplikeringskontexter

Intern Data Domain-replikering är utformad efter konceptet med replikeringskontexter. Till exempel när data måste replikeras mellan olika system:

• Replikeringskontexter skapas på käll- och mål-DDR-enheter
• Kontexterna initieras
• När initieringen är klar skickar replikeringen med jämna mellanrum uppdateringar/deltan från källa till mål för att hålla data i systemen synkroniserade

Om det förekommer fördröjning för en källreplikeringskontext kan det leda till att gamla data lagras på disken i källsystemet (observera att replikeringskontexter med fördröjning inte kan orsaka för hög användningsgrad på målsystemet):

• Katalogreplikeringskontexter (används vid replikering av ett träd för en enda katalog under /data/col1/backup mellan system):

•  Mtree-replikeringskontexter (används vid replikering av andra mtree-strukturer än /data/col1/backup mellan system):

• Replikeringskontexter för insamling (används vid replikering av hela innehållet på en DDR-enhet till ett annat system):

 Ta reda på om det förekommer fördröjning för replikeringskontexter genom att gå igenom följande steg:

• Ta reda på värdnamnet för det aktuella systemet:

• Ta reda på datum/tid för det aktuella systemet:

• Visa en lista över replikeringskontexter som har konfigurerats på systemet och information om den tidpunkt när de synkroniserades. Observera att de kontexter som är av intresse är de där målet INTE innehåller värdnamnet för det aktuella systemet (vilket betyder att det aktuella systemet är källan) och där tidpunkten för när de synkroniserades ligger påtagligt långt tillbaka i tiden:

Kontexter för vilka det aktuella systemet är källan och som har betydande fördröjning eller kontexter som inte längre behövs bör brytas. Det gör du genom att köra följande kommando på käll- och målsystemet:
 
Om du till exempel vill bryta de kontexter som är ”av intresse” som visas ovan körs följande kommandon på käll- och målenhet:
 
Observera följande:

• När kontexterna har brutits måste rensning av den aktiva nivån utföras så att potentiellt utrymme på den aktiva nivån frigörs
• Om du använder mtree-replikering när kontexterna är brutna kan snapshots lämnas kvar på disken. Se till att steg 5 utförs så att alla överflödiga snapshots anges som inaktuella innan rensning körs
• Om käll-/mål-mtree-strukturen har konfigurerats för att migrera data till arkiv- eller molnnivåer bör du vara försiktig när du bryter motsvarande mtree-replikeringskontexter eftersom dessa kontexter kanske inte kan återskapas/initieras på nytt i framtiden. Anledningen till detta är att när en mtree-replikeringskontext initieras skapas en mtree-snapshot i källsystemet och den innehåller information om alla filer i mtree-strukturen (oavsett nivå). Denna snapshot replikeras sedan i sin helhet till den aktiva nivån på målenheten. Om den aktiva nivån på målenheten inte har tillräckligt med ledigt utrymme för att ta emot alla mtree-data från källenheten kan det hända att det inte går att slutföra initieringen. Om du vill ha mer information om det här problemet kontaktar du den kontrakterade supportleverantören
• Om en replikeringskontext för insamling bryts kan kontexten inte återskapas/initieras utan att först förstöra DDFS-instansen på mål-DDR-enheten (och förlora alla data i systemet). Det kan därför ta lång tid eller krävas mycket nätverksbandbredd för initiering av kontexten senare, eftersom alla data från källenheten måste replikeras fysiskt till målenheten igen

Steg 3 – Kontrollera om det finns mtree-strukturer som inte längre behövs

Innehållet i DDFS är logiskt uppdelat i mtree-strukturer. Det är vanligt att enskilda säkerhetskopieringsprogram/säkerhetskopieringsklienter skriver till enskilda mtree-strukturer. Om ett säkerhetskopieringsprogram tas ur drift kan det inte längre skriva data till/ta bort data från DDR-enheten, vilket kan innebära att gamla/överflödiga mtree-strukturer lämnas kvar i systemet. Data i de mtree-strukturerna finns kvar på obestämd tid och tar upp utrymme på disken på DDR-enheten. Därför bör alla sådana överflödiga mtree-strukturer tas bort. Till exempel:

• Ta fram en lista med mtree-strukturer i systemet:

• Alla mtree-strukturer som inte längre behövs bör tas bort med kommandot ”mtree delete”, dvs.:

• Det utrymme som den borttagna mtree-strukturen upptog på disken frigörs nästa gång rensning/skräpinsamling körs på den aktiva nivån.

Observera följande:

• För mtree-strukturer som är mål för mtree-replikering (dvs. har status RO/RD i utdata i mtree-listan) ska motsvarande replikeringskontext brytas innan mtree-strukturen tas bort
• Det kan hända att det inte går att ta bort mtree-strukturer som används som DDBoost-LSU:er (Logical Storage Units) eller VTL-pooler (Virtual Tape Library) med kommandot ”mtree delete” – mer information om hur du tar bort sådana mtree-strukturer finns i administrationshandboken till Data Domain
• Det går inte att ta bort mtree-strukturer som är konfigurerade med kvarhållningslås (dvs. har status RLCE eller RLGE). Istället måste kvarhållningslåset för enskilda filer i mtree-strukturen återställas och filerna tas bort individuellt – mer information finns i administrationshandboken till Data Domain

Steg 4 – Sök efter gamla/överflödiga mtree-snapshots

En Data Domain-snapshot är en snapshot för en viss tidpunkt för motsvarande mtree. Ett resultat av det är att:

• Snapshoten refererar till de filer som finns i mtree-strukturen när snapshoten skapas
• Eftersom snapshoten finns kvar även om dessa filer tas bort går det inte att frigöra det fysiska utrymme som de upptar på disken med rensning – det beror på att data måste finnas kvar i systemet i händelse av att kopian av filen i snapshoten senare används

Ta reda på om några mtree-strukturer har gamla/överflödiga snapshots genom att gå igenom följande steg:

• Ta fram en lista med mtree-strukturer i systemet med hjälp av kommandot ”mtree list” som visas i steg 3
• Visa en lista med snapshots för varje mtree med hjälp av kommandot ”snapshot list”:

• Där snapshots finns använder du utdata från "snapshot list mtree [mtree name]" för att avgöra vilka snapshots som:

• Om kommandot ”snapshot list” körs igen visas nu dessa snapshots som inaktuella:

Observera följande:

• Det går inte att fastställa hur mycket fysiska data en enskild snapshot eller uppsättning snapshots innehåller på disken – det enda värdet för utrymme som är associerat med en snapshot är en indikation på den förkomprimerade (logiska) storleken för mtree-strukturen när snapshoten skapades (som visas i utdata ovan)
• Snapshots som heter ”REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS” hanteras med mtree-replikering och ska under normala omständigheter inte behöva anges som inaktuella manuellt (vid replikering anges dessa snapshots som inaktuella när de inte längre behövs). Om sådana snapshots är mycket gamla tyder det på att det troligen förekommer fördröjning för motsvarande replikeringskontext (vilket beskrivs i steg 2)
• Snapshots som heter ”REPL-MTREE-RESYNC-RESERVE-YYYY-MM-DD-HH-MM-SS” skapas vid mtree-replikering när en replikeringskontext bryts. Syftet är att de ska kunna användas för att undvika fullständig omsynkronisering av replikeringsdata om den brutna kontexten återskapas senare (till exempel om kontexten bröts av misstag). Om replikering inte återupprättas kan dessa kontexter anges som inaktuella manuellt enligt beskrivningen ovan
• Inaktuella snapshots finns kvar i systemet tills nästa rensning/skräpinsamling körs – de tas då bort fysiskt och tas bort i utdata från ”snapshot list mtree [mtree-namn]” – det utrymme som dessa snapshots tog upp på disken kan då frigöras vid rensningen

Steg 5 – Kontrollera om det finns ett oväntat antal gamla filer i systemet

Autosupport från DDR-enheten innehåller histogram som visar en detaljerad lista över filer på DDR-enheten sorterade efter ålder – till exempel:
 
Detta kan vara användbart för att avgöra om det finns filer i systemet som inte har angetts som inaktuella/tagits bort som förväntat av klientsäkerhetskopieringsprogrammet. Om ett säkerhetskopieringsprogram till exempel skrev till ovanstående system, där den maximala kvarhållningsperioden för enskilda filer var sex månader, är det omedelbart uppenbart att filer inte anges som inaktuella/tas bort som förväntat av säkerhetskopieringsprogrammet eftersom det finns cirka 80 000 filer som är äldre än sex månader på DDR-enheten.

Observera att:

• Det är säkerhetskopieringsprogrammet som ska ange filer som inaktuella eller ta bort filer
• Filer anges aldrig som inaktuella/tas aldrig bort automatiskt på en DDR-enhet – om inte du uppmanas att uttryckligen ta bort en fil av säkerhetskopieringsprogrammet finns filen kvar på DDR-enheten och tar upp utrymme på obestämd tid

Det innebär att problem som dessa först bör undersökas av supportteamet för säkerhetskopieringsprogram.

Data Domain-support kan vid behov tillhandahålla ytterligare rapporter för att:

• ange namn/ändringstid för alla filer på en DDR-enhet sorterade efter ålder (så att namn/sökväg för gamla data kan fastställas)
• Dela upp filarkiv i separata rapporter för nivån active/archive/cloud (där ER/LTR-funktionerna är aktiverade)

Så här gör du:

• Samla in evidens enligt beskrivningen i stycket ”Collecting sfs_dump” i kommentarsavsnittet i det här dokumentet
• Skapa en tjänstebegäran hos den kontrakterade supportleverantören

När gamla/överflödiga filer tas bort måste du köra en rensning/skräpinsamling för att frigöra fysiskt utrymme på den aktiva nivån

Steg 6 – Kontrollera om det finns säkerhetskopior som innehåller ett stort antal små filer

På grund av utformningen av DDFS kan små filer (i stort sett alla filer som är mindre än cirka 10 MB i storlek) ta upp mycket utrymme när de först skrivs till DDR-enheten. Det beror på att SISL-arkitekturen (Stream Informed Segment Layout) gör att små filer tar upp flera enskilda 4,5 MB-block med ledigt utrymme på disken. Till exempel kan en fil på 4 kB i själva verket uppta upp till 9 MB fysiskt diskutrymme vid den första skrivningen.

Det här överdrivet stora utrymmet frigörs sedan när rensning/skräpinsamling körs (eftersom data från små filer då aggregeras till ett mindre antal 4,5 MB-block) men det kan göra att mindre DDR-modeller visar för stor utrymmesanvändning och att utrymmet fylls upp när sådana säkerhetskopieringar körs.

Autosupport innehåller histogram som visar detaljerad information om filer sorterade efter storlek, exempelvis:
 
Om det finns tecken på att säkerhetskopior skriver mycket stora antal små filer kan systemet påverkas av avsevärd tillfällig ökning av utrymmesanvändning mellan varje anrop av rensning/skräpinsamling. I det scenariot rekommenderar vi att du byter säkerhetskopieringsmetod så att alla små filer inkluderas i ett enda större arkiv (t.ex. en tar-fil) innan de skrivs till DDR-enheten. Observera att sådana arkiv inte ska komprimeras eller krypteras (eftersom detta skadar komprimerings-/dedupliceringsförhållandet för de data som ingår).

Steg 7 – Kontrollera om dedupliceringsförhållandet är lägre än förväntat

Huvudsyftet med en DDR-enhet är att deduplicera och komprimera data som läggs till på enheten. Deduplicerings-/komprimeringsförhållandet är till stor del beroende av användningsfallet och typen av data på systemet, men i många fall finns ett ”förväntat” övergripande komprimeringsförhållande baserat på resultat som erhållits genom konceptbevistestning eller liknande. Du kan använda kommandot ”filersys show compression” för att fastställa det aktuella övergripande komprimeringsförhållandet för systemet (och därmed om det motsvarar förväntningarna). Till exempel:
 
I ovanstående exempel uppnår systemet ett totalt kompressionsförhållande på 65,3x för den aktiva nivån (vilket är extremt bra). Om värdet visar att det övergripande komprimeringsförhållandet inte motsvarar förväntningarna är det sannolikt att vidare undersökning krävs. Observera att undersökning av ett komprimeringsförhållande som är lägre än förväntat är ett komplext ämne och problemet kan ha många bakomliggande orsaker. Mer information om hur du går vidare med undersökningen finns i följande artikel: https://support.emc.com/kb/487055

Steg 8 – Kontrollera om systemet är källa för insamlingsreplikering

När du använder insamlingsreplikering och källsystemet är fysiskt större än målet begränsas storleken på källsystemet artificiellt så att den är densamma som målet (dvs. det finns ett diskområde på källsystemet som markeras som oanvändbart). Anledningen till detta är att när en insamlingsreplikering används måste målet vara en blocknivåkopia av källan, men om källan är fysiskt större än målet finns det risk för att för mycket data skrivs till källan som då inte kan replikeras till målet (eftersom det redan är fullt). Undvik det scenariot genom att begränsa storleken på källan så att den är densamma som målet.

• Med hjälp av kommandona från steg 2 kontrollerar du om systemet är källa för insamlingsreplikering. Det gör du genom att köra ”'replication status” och kontrollera om det förekommer replikeringskontexter som börjar med ”col://” (vilket står för insamlingsreplikering (”collection replication”)) och INTE innehåller värdnamnet för det lokala systemet på målet (vilket anger att systemet måste vara källa för replikeringskontexten)
• Om systemet är källa för insamlingsreplikering kontrollerar du storleken för den aktiva nivån på båda systemen genom att logga in på systemen och köra kommandot ”filesys show space” – jämför storleken för de aktiva nivåerna efter komprimering på båda systemen
• Om källan är betydligt större än målet begränsas storleken på den aktiva nivån på källan artificiellt
• Så här gör du för att ange att allt utrymme på källan ska vara användbart för data:

Steg 9 – Kontrollera om dataöverföring körs regelbundet

Om DDR-enheten är konfigurerad med antingen Extended Retention (ER) eller Long Term Retention (LTR) har den en andra lagernivå (arkivnivå för ER eller molnnivå för LTR). I det scenariot är dataöverföringspolicyer troligen konfigurerade mot mtree-strukturer för migrering av äldre/ej ändrade data som kräver långsiktig lagring från den aktiva nivån ut till den alternativa lagringsnivån, så att det utrymme som används av de här filerna på den aktiva nivån kan frigöras fysiskt genom rensning/skräpinsamling. Om dataöverföringspolicyer är felaktigt konfigurerade eller om dataöverföringsprocessen inte körs regelbundet finns gamla data kvar på den aktiva nivån längre än förväntat och fortsätter att använda fysiskt utrymme på disken.

• Kontrollera först om systemet är konfigurerat för ER eller LTR genom att köra ”filesys show space” och kontrollera om det finns en arkiv- eller molnnivå – observera att för att det ska gå att använda de alternativa lagringsnivåerna måste de ha en storlek på > 0 GB efter komprimering:

• Om systemet har konfigurerats med ER/LTR kontrollerar du dataöverföringspolicyerna mot mtree-strukturerna för att se till att de motsvarar förväntningarna och är konfigurerade så att gamla data överförs till den alternativa lagringsnivån:

• Om systemet är konfigurerat med ER/LTR kontrollerar du att dataöverföring har schemalagts för att köras med regelbundna intervall för fysisk migrering av filer/data från den aktiva nivån till alternativ lagring:

• Om systemet är konfigurerat för ER/LTR kontrollerar du när dataöverföring senast kördes:

• När dataöverföringen är klar ska rensning av den aktiva nivån köras (observera att den kan konfigureras så att den startas automatiskt när dataöverföringen är klar) för att säkerställa att det utrymme som användes av de migrerade filerna på den aktiva nivån frigörs fysiskt:

Steg 10 – Lägg till mer lagringsutrymme på den aktiva nivån

Om alla föregående steg har utförts och rensning av den aktiva nivån har slutförts men det ändå inte finns tillräckligt med utrymme på den aktiva nivån är det troligt att systemet inte har rätt storlek för den arbetsbelastning som det tar emot. I så fall gör du något av följande:

• Minska den arbetsbelastning som systemet tar emot – till exempel:

• Lägg till mer lagringsutrymme på den aktiva nivån i systemet och utöka storleken för det:

Data Domain-support kan generera ett antal rapporter som till exempel visar följande information:

• En lista över alla filer på en viss nivå (dvs. aktiv/arkiv/moln) sorterade efter ålder
• Beräknad storlek och komprimeringsförhållande per mtree/trädstruktur för större katalog
• En lista över alla filer i en viss mtree-struktur sorterade efter ålder
• och så vidare

För att det här ska vara möjligt ska följande information samlas in:

• Ett nytt supportpaket från DDR-enheten – mer information finns på https://support.emc.com/kb/323283
• Utdata för ”sfs_dump” eller ”sfs_dump -c”:

• En filsökvägsrapport (krävs om systemet är konfigurerat för ER eller LTR):

Om du behöver hjälp med att samla in ovanstående eller med något av stegen i den här arkivrensningen kontaktar du den kontrakterade supportleverantören.