Data Domain: Fremgangsmåte for å løse problemer med stor plassbruk eller manglende ledig kapasitet på DDR-er (Data Domain Restorer)

 

• Dette er diskområdet der nylig inntatte filer/data er plassert, og på de fleste DDR-er blir filene værende her til de utløper eller slettes av sikkerhetskopiapplikasjon på klienten
• På DDR-er som er konfigurert med ER (Extended Retention) eller LTR (Long Term Retention), kan det hende at dataflyttingsprosessen kjøres regelmessig for å migrere gamle filer fra det aktive nivået til arkiv- eller nettskynivåer
• Den eneste metoden for å frigjøre plass på det aktive nivået som ble brukt av slettede/migrerte filer, er å kjøre søppelinnsamling/opprydding

• Det aktive nivået kan begynne å gå tomt for plass, og dette resulterer i varsler/meldinger som ligner på følgende:

• Hvis det aktive nivået blir 100 % fullt, kan ingen nye data skrives til DDR-en, og sikkerhetskopieringer/replikering vil mislykkes. I dette scenariet kan du motta varsler/meldinger som ligner på følgende:

• Hvis det aktive nivået blir fullt, kan dette i enkelte tilfeller forårsake at DDFS (Data Domain File System) blir skrivebeskyttet, slik at eksisterende filer ikke kan slettes

• Forklare hvorfor det aktive nivået kan bli fullt
• Beskrive et enkelt sett med kontroller som kan utføres for å fastslå årsaken til stor bruk av det aktive nivået, og tilhørende utbedringstrinn

• denne artikkelen ikke er altomfattende (dvs. at det kan oppstå enkelte situasjoner der årsaken til stor plassbruk / oppfylling på det aktive nivået av en DDR ikke er drøftet i dette dokumentet), men skal dekke de vanligste årsakene/problemene
• denne artikkelen ikke dekker stor plassbruk på arkiv- eller nettskynivåer

  Bruken av det aktive nivået i en DDR kan være høyere enn forventet av en rekke årsaker:

• Sikkerhetskopifiler/lagringssett blir ikke riktig slettet av sikkerhetskopiapplikasjoner for klienter grunnet feil oppbevaringspolicy eller feil konfigurasjon av sikkerhetskopiapplikasjonen
• Forsinket replikering fører til at en stor mengde gamle data blir oppbevart på det aktive nivået i påvente av replikering til replika
• Data som skrives til det aktive nivået, har lavere generelt komprimeringsforhold enn forventet
• Systemet har ikke riktig størrelse, dvs. det er for lite for mengden data som blir forsøkt lagret på det
• Sikkerhetskopier består av et stort antall svært små filer – disse filene bruker mye mer plass enn forventet når de først blir skrevet, men denne plassen blir frigjort under opprydding/søppelinnsamling
• Dataflytting blir ikke regelmessig utført på systemer som er konfigurert med ER/LTR, og dette fører til at gamle filer som skal migreres til arkiv-/nettskynivåer, blir værende på det aktive nivået
• Opprydding/søppelinnsamling blir ikke regelmessig utført
• Overflødige eller gamle mtree-øyeblikksbilder på DDR-en hindrer oppryddingen i å frigjøre plass fra slettede filer/data

Trinn 1 – Fastslå om opprydding på aktivt nivå må kjøres

Data Domain-operativsystemet (DDOS) prøver å opprettholde en teller kalt "Cleanable GiB" for det aktive nivået. Dette er et estimat av hvor mye fysisk plass (etter komprimering) som potensielt kan frigjøres av opprydding/søppelinnsamling på det aktive nivået. Du kan vise denne telleren ved hjelp av "filesys show space"- / "df"-kommandoen:
 
Hvis ett av følgende er tilfelle:

• Verdien for "Cleanable GiB" er høy
• DDFS er 100 % fullt (og derfor skrivebeskyttet)

Opprydding må fullføres før du fortsetter med eventuelle andre trinn i dette dokumentet. "filesys clean start"-kommandoen skal brukes til å starte oppryddingen:
 
Hvis du vil bekrefte at oppryddingen har startet som forventet, kan du bruke "filesys status"-kommandoen:
 
Vær oppmerksom på at:

• Hvis oppryddingen ikke kan starte, kan du kontakte kundestøtteleverandøren din for å få ytterligere hjelp – dette kan tyde på at det har oppstått en feil grunnet manglende segment i systemet, noe som har ført til at opprydding er deaktivert
• Hvis opprydding allerede kjører og du prøver å starte den, vises følgende melding:

• Ingen plass på det aktive nivået blir frigjort før oppryddingen går inn i kopieringsfasen (som standard fase 9 i DDOS 5.4.x og eldre, og fase 11 i DDOS 5.5.x og nyere). Hvis du vil ha informasjon om fasene i oppryddingen, kan du gå til: https://support.emc.com/kb/446734
• Det kan hende at oppryddingen ikke frigjør plassmengden som er angitt av "Cleanable GiB", ettersom denne verden i hovedsak er et estimat. Hvis du vil ha mer informasjon om dette, kan du gå til: https://support.emc.com/kb/485637
• Opprydding vil ikke frigjøre all potensiell plass i én runde. Grunnen til dette er at opprydding på DDR-er som inneholder svært store datasett, vil jobbe mot delen av filsystemet som inneholder den største mengden overflødige data (dvs. for å frigjøre mest mulig plass i forhold til tiden det tar å fullføre oppryddingen). I enkelte scenarier må opprydding kjøres flere ganger for å frigjøre all potensiell plass
• Hvis verdien for "Cleanable GiB" var svært høy, kan det tyde på at oppryddingen ikke har kjørt i regelmessige intervaller – kontroller at en tidsplan for opprydding er angitt:

Når oppryddingen er fullført, bruker du "filesys show space"- / "df"-kommandoen til å fastslå om bruksproblemene er løst. Hvis bruken fortsatt er høy, utfører du de gjenværende trinnene i denne artikkelen.

Trinn 2 – Se etter store mengder forsinket replikering mot kildereplikeringskontekster

Opprinnelig Data Domain-replikering er utformet rundt konseptet med "replikeringskontekster". For eksempel når data må replikeres mellom systemer:

• Replikeringskontekster opprettes på kilde- og mål-DDR-er
• Kontekstene er initialisert
• Når initialiseringen er fullført, vil replikering sende jevnlige oppdateringer/deltaer fra kilden til målet for å holde data på systemene synkronisert

Hvis en kildereplikeringskontekst er forsinket, kan det føre til at gamle data blir oppbevart på disk i kildesystemet (vær oppmerksom på at forsinkede replikeringskontekser ikke kan føre til overdreven bruk på målsystemet):

• Katalogreplikeringskontekster (brukes ved replikering av ett enkelt katalogtre under /data/col1/backup mellom systemer):

•  Mtree-replikeringskontekster (brukes ved replikering av andre mtree-er enn /data/col1/backup mellom systemer):

• Samlingsreplikeringskontekster (brukes ved replikering av alt innhold på en DDR til et annet system):

 Hvis du skal fastslå om replikeringskontekster er forsinket, utfører du følgende trinn:

• Fastslå vertsnavnet til gjeldende system:

• Fastslå dato/klokkeslett på gjeldende system:

• Oppgi replikeringskontekster som er konfigurert på systemet, sammen med "synkronisert fra og med"-tidspunktet. Vær oppmerksom på at relevante kontekster er kontekster der "destinasjonen" (målet) IKKE inneholder vertsnavnet til gjeldende system (noe som indikerer at gjeldende system er kilden), og at "synced as of time"-tidspunktet (synkronisert fra og med) er signifikant gammelt:

Kontekster som har gjeldende system som kilde, og som er svært forsinket eller har kontekster som ikke lenger er nødvendige, bør brytes. Dette kan utføres ved å kjøre følgende kommando på kilde- og målsystemet:
 
Hvis du for eksempel skal bryte de "relevante" kontekstene som vises ovenfor, kjører du følgende kommando på kilden og målet:
 
Vær oppmerksom på at:

• Når kontekster brytes, må opprydding utføres på det aktive nivået for å frigjøre potensiell plass
• Hvis du bruker mtree-replikering når kontekster blir brutt, kan øyeblikksbilder av mtree-replikering bli værende på disken. Sørg for å utføre trinn 5 for å fjerne eventuelle overflødige øyeblikksbilder før du kjører opprydding
• Hvis kilde- og mål-mtree er konfigurert for å overføre data til arkiv- eller nettskynivåer, må du være forsiktig når du bryter tilsvarende mtree-replikeringskontekster, ettersom disse kontekstene kanskje ikke kan opprettes/initialiseres på nytt i fremtiden. Grunnen til dette er at når en mtree-replikeringskontekst blir initialisert, blir det opprettet et mtree-øyeblikksbilde på kildesystemet som inneholder informasjon om alle filer i mtree-et (uavhengig av nivå). Dette øyeblikksbildet blir deretter fullstendig replikert til det aktive nivået av målet. Hvis det aktive nivået av målet ikke har tilstrekkelig med ledig plass til å ta inn alle mtree-dataene fra kilden, kan ikke initialiseringen fullføres. Hvis du vil ha mer informasjon om dette problemet, kan du kontakte kundestøtteleverandøren din
• Hvis en samlingsreplikeringskontekst blir brutt, kan ikke konteksten opprettes/initialiseres på nytt før DDFS-forekomsten på mål-DDR-en er ødelagt (og alle data på dette systemet går tapt). Dette fører til at en påfølgende initialisering kan ta lang tid / bruke mye nettverksbåndbredde, siden alle data fra kilden må replikeres fysisk på målet igjen

Trinn 3 – Se etter mtree-er som ikke lenger er nødvendige

Innholdet i DDFS er logisk inndelt i mtree-er. Det er vanlig at individuelle sikkerhetskopiapplikasjoner/-klienter skriver til individuelle mtree-er. Hvis en sikkerhetskopiapplikasjon er deaktivert, kan den ikke lenger skrive data til / slette data fra DDR-en, noe som kan etterlate gamle/overflødige mtree-er på systemet. Data i disse mtree-ene vil fortsette å eksistere og bruke plass på disken i DDR-en. Dette betyr at alle slike overflødige mtree-er bør slettes. Eksempel:

• Hente en liste over mtree-er i systemet:

• Alle mtree-er som ikke lenger er nødvendige, bør slettes med "mtree delete"-kommandoen, dvs.:

• Plassen som det slettede mtree-et brukte på disken, blir frigjort neste gang det utføres en opprydding/søppelinnsamling på det aktive nivået.

Vær oppmerksom på at:

• Den tilsvarende replikeringskonteksten til mtree-er som er mål for mtree-replikering (dvs. har status som RO/RD i utdataene på mtree-listen), bør brytes før mtree-et slettes
• Det kan hende at mtree-er som brukes som logiske DDBoost-lagringsenheter (LSU-er) eller utvalg for virtuelle båndbibliotek (VTL), ikke kan slettes ved hjelp av "mtree delete"-kommandoen – se administrasjonsveiledningen for Data Domain hvis du vil ha mer informasjon om sletting av slike mtree-er
• Mtree-er som er konfigurert for retensjonslås (dvs. har status som RLCE eller RLGE), kan ikke slettes – eventuelle retensjonslåser for individuelle filer i mtree-et må i stedet reverseres og slettes individuelt. Se administrasjonsveiledninger for Data Domain hvis du vil ha mer informasjon

Trinn 4 – Se etter gamle/overflødige mtree-øyeblikksbilder

Et Data Domain-øyeblikksbilde representerer et øyeblikksbilde av tilhørende mtree. Resultat:

• Øyeblikksbildet vil referere til alle filer som eksisterer i mtree-et når øyeblikksbildet opprettes
• Øyeblikksbildet fortsetter å eksistere selv om disse filene blir fjernet/slettet, men en opprydding kan ikke frigjøre den fysiske plassen de bruker på disken. Grunnen er at dataene må bli værende på systemet i tilfelle kopien av filen i øyeblikksbildet blir åpnet senere

Hvis du vil fastslå om eventuelle mtree-er har gamle/overflødige øyeblikksbilder, utfører du følgende trinn:

• Hent en liste over mtree-er i systemet ved hjelp av "mtree list"-kommandoen, som vist i trinn 3
• Bruk "snapshot list"-kommandoen til å vise øyeblikksbildene som eksisterer for hvert mtree:

• Der det finnes øyeblikksbilder, kan du bruke utdataene fra "snapshot list mtree [navn på mtree]" til å fastslå øyeblikksbilder som:

• Hvis "snapshot list"-kommandoen kjøres på nytt, vil disse øyeblikksbildene nå vises som utløpt:

Vær oppmerksom på at:

• Det er ikke mulig å fastslå hvor mye fysiske data et individuelt øyeblikksbilde eller et sett med øyeblikksbilder oppbevarer på en disk. Den eneste plassverdien som er knyttet til et øyeblikksbilde, er en indikasjon på den forhåndskomprimerte (logiske) størrelsen på mtree-et når øyeblikksbildet ble opprettet (som vist i utdataene ovenfor)
• Øyeblikksbilder kalt "REPL-MTREE-AUTO-ÅÅÅÅ-MM-DD-TT-MM-SS" administreres av mtree-replikering, og trenger vanligvis ikke å fjernes manuelt (replikering vil fjerne disse øyeblikksbildene automatisk når de ikke lenger er nødvendige). Hvis slike øyeblikksbilder er svært gamle, tyder det på at tilsvarende replikeringskontekst sannsynligvis er svært forsinket (som beskrevet i trinn 2)
• Øyeblikksbilder kalt "REPL-MTREE-RESYNC-RESERVE-ÅÅÅÅ-MM-DD-TT-MM-SS" blir opprettet av mtree-replikering når en mtree-replikeringskontekst blir brutt. De kan brukes for å unngå en fullstendig omstrukturering av replikeringsdata hvis den brutte konteksten opprettes på nytt senere (for eksempel hvis konteksten ble brutt ved en feil). Hvis replikeringen ikke blir gjenopprettet, kan disse kontekstene fjernes manuelt, som beskrevet ovenfor
• Utløpte øyeblikksbilder vil fortsette å eksistere på systemet til neste opprydding/søppelinnsamling utføres. På dette tidspunktet blir de fysisk slettet og fjernet fra utdataene fra "snapshot list mtree [navn på mtree]". Deretter kan en opprydding frigjøre plassen som disse øyeblikksbildene brukte på disken

Trinn 5 – Se etter et uventet antall gamle filer i systemet

Autosupport fra DDR-en inneholder histogrammer som viser en oversikt over filene på DDR-en etter alder, for eksempel:
 
Dette kan være nyttig for å fastslå om det finnes filer i systemet som klientens sikkerhetskopiapplikasjon ikke har fjernet/slettet som forventet. Hvis for eksempel en sikkerhetskopiapplikasjon skrev til systemet ovenfor, og den maksimale oppbevaringsperioden for enhver fil var 6 måneder, er det tydelig at sikkerhetskopiapplikasjonen ikke fjerner/sletter filer som forventet, da det finnes ca. 80 000 filer på DDR-en som er eldre enn 6 måneder.

Merk:

• Sikkerhetskopiapplikasjonen har ansvaret for å utføre all fjerning/sletting av filer
• En DDR vil aldri fjerne/slette filer automatisk. Med mindre sikkerhetskopiapplikasjonen har bedt den om å slette en fil, vil filen bli værende på DDR-en og bruke plass

Slike problemer må først undersøkes av kundestøtteteamet til leverandøren av sikkerhetskopiapplikasjonen.

Hvis det er nødvendig, kan Data Domain-kundestøtten levere tilleggsrapporter for å gjøre følgende:

• Oppgi navnet på / endringstidspunktet for alle filene på en DDR etter alder (slik at navnet på / plasseringen til alle gamle data kan fastslås)
• Legge histogrammer av filalder i separate rapporter for det aktive nivået / arkivnivået / nettskynivået (der ER-/LTR-funksjonene er aktivert)

Slik gjør du dette:

• Samle inn evidens som beskrevet i avsnittet om innsamling av sfs_dump i merknadsdelen av dette dokumentet
• Åpne en serviceforespørsel med kundestøtteleverandøren din

Når gamle/overflødige filer blir slettet, må opprydding/søppelinnsamling utføres på det aktive nivået for å fysisk frigjøre plass

Trinn 6 – Se etter sikkerhetskopier som inkluderer et stort antall små filer

Utformingen av DDFS gjør at små filer (i hovedsak alle filer som er mindre enn ca. 10 Mb) kan bruke mye plass når de først blir skrevet til DDR-en. Dette skyldes at SISL-arkitekturen (Stream Informed Segment Layout) får små filer til å bruke flere individuelle 4,5 Mb blokker med plass på disken. En 4 Kb fil kan faktisk bruke opptil 9 Mb med fysisk diskplass når den først blir skrevet.

Denne plassen blir senere frigjort under opprydding/søppelinnsamling (når data fra små filer blir aggregert til et mindre antall 4,5 Mb blokker), men kan føre til overdreven bruk og oppfylling av mindre DDR-modeller når slike sikkerhetskopieringer kjøres.

Autosupport inneholder histogrammer av filer sortert etter størrelse, for eksempel:
 
Hvis det er tegn på at sikkerhetskopieringer skriver svært store antall med små filer, kan systemet blir berørt av store midlertidige økninger i bruk mellom hver opprydding/søppelinnsamling. I dette scenariet er det best å bytte sikkerhetskopieringsmetode for å inkludere alle små filer i ett enkelt større arkiv (for eksempel en tar-fil) før de skrives til DDR-en. Vær oppmerksom på et slikt arkiv ikke må komprimeres eller krypteres (siden det vil skade komprimeringsforholdet/gjendupliseringsforholdet til disse dataene).

Trinn 7 – Se etter gjendupliseringsforhold som er lavere enn forventet

Hovedformålet med en DDR er å gjenduplisere og komprimere dataene som enheten tar inn. Gjendupliserings-/komprimeringsforholdet er svært avhengig av systemets brukstilfelle og typen data det oppbevarer, men i mange tilfeller vil det være et "forventet" generelt komprimeringsforhold basert på resultater fra konseptutprøving og lignende. Hvis du vil fastslå systemets gjeldende generelle komprimeringsforhold (og finne ut om det oppfyller forventningene), kan du bruke "filesys show compression"-kommandoen. Eksempel:
 
I eksempelet ovenfor oppnår systemet et generelt komprimeringsforhold på 65,3x for den aktive enheten (noe som er svært bra). Hvis denne verdien viser at det generelle komprimeringsforholdet ikke oppfyller forventningene, må man sannsynligvis undersøke mer. Vær oppmerksom på at undersøkelse av komprimeringsforhold som er lavere enn forventet, er et komplisert tema som kan ha mange rotårsaker. Les følgende artikkel hvis du vil ha mer informasjon om slike undersøkelser: https://support.emc.com/kb/487055

Trinn 8 – Sjekke om systemet er en kilde for samlingsreplikering

Hvis du bruker samlingsreplikering, og kildesystemet er fysisk større enn målet, blir størrelsen på kildesystemet kunstig begrenset slik at det samsvarer med målet (dvs. at et diskområde på kilden vil være merket som ubrukelig). Grunnen til dette er at når du bruker samlingsreplikering, må målet være en blokknivåkopi av kilden. Hvis kilden er fysisk større enn målet, kan det imidlertid hende at overflødige data blir skrevet til kilden, som deretter ikke kan replikeres til målet (siden det allerede er fullt). Dette scenariet kan forhindres ved å begrense størrelsen på kilden slik at den samsvarer med målet.

• Sjekk om systemet er en kilde for samlingsreplikering ved hjelp av kommandoene i trinn 2. Hvis du skal gjøre dette, kjører du ''replication status" for å fastslå om det finnes replikeringskontekster som begynner på "col://" (indikerer samlingsreplikering), og som IKKE inneholder vertsnavnet til det lokale systemet i målet (indikerer at dette systemet må være en kilde for replikeringskonteksten)
• Hvis systemet er en kilde for samlingsreplikering, må du sjekke størrelsen på det aktive nivået i hvert system ved å logge på begge to, kjøre "filesys show space"-kommandoen og sammenligne "post-comp"-størrelsen (etter komprimering) på de aktive nivåene i hvert system
• Hvis kilden er betydelig større enn målet, blir størrelsen på det aktive nivået kunstig begrenset
• Hvis du skal tillate at all plass på kilden kan brukes til data, gjør du følgende:

Trinn 9 – Sjekke om dataflytting blir utført regelmessig

Hvis DDR-en er konfigurert med ER (Extended Retention) eller LTR (Long Term Retention), vil den har et ekstra tilknyttet lagringsnivå (arkivnivå for ER eller nettskynivå for LTR). I dette scenariet er retningslinjene for dataflytting sannsynligvis konfigurert mot mtree-er for å migrere gamle/uendrede data som krever langsiktig oppbevaring, fra det aktive nivået til det alternative lagringsnivået. Dette gjør at plassen som disse filene opptar på det aktive nivået, kan frigjøres fysisk ved hjelp av opprydding/søppelinnsamling. Hvis retningslinjene for dataflytting er feilkonfigurert, eller hvis dataflyttingsprosessen ikke blir regelmessig utført, vil det føre til at gamle data blir værende på det aktive nivået lenger enn forventet og fortsetter å oppta fysisk plass på disken.

• Kontroller først om systemet er konfigurert for ER eller LTR ved å kjøre "filesys show space" og se om det finnes et arkiv- eller nettskynivå. Vær oppmerksom på hvis disse alternative lagringsnivåene skal kunne brukes, må de ha en størrelse på > 0 Gb etter komprimering:

• Hvis systemet er konfigurert med ER/LTR, må du kontrollere retningslinjene for dataflytting mot mtree-er for å sikre at disse er som forventet, og at de er angitt slik at gamle data blir flyttet til det alternative lagringsnivået:

• Hvis systemet er konfigurert med ER/LTR, må du sjekke at det er opprettet en tidsplan for å kjøre dataflytting i regelmessige intervaller, og fysisk migrere filer/data fra det aktive nivået til alternativ lagring:

• Hvis systemet er konfigurert for ER/LTR, må du sjekke når siste dataflytting ble utført:

• Når dataflyttingen er fullført, må du kjøre opprydding på det aktive nivået (vær oppmerksom på at opprydding kan konfigureres til å starte automatisk når dataflytting er fullført) for å sikre at plassen som ble brukt av migrerte filer på det aktive nivået, blir fysisk frigjort:

Trinn 10 – Legge til ekstra lagringsplass på det aktive nivået

Hvis alle tidligere trinn er utført, og opprydding på det aktive nivået er fullført, men det fortsatt er for lite ledig plass på det aktive nivået, har systemet sannsynligvis feil størrelse i forhold til arbeidsmengden det mottar. I så fall må du gjøre ett av følgende:

• Reduser arbeidsmengden som sendes til systemet, for eksempel ved å gjøre dette:

• Legg til ekstra lagringsplass på det aktive nivået for å utvide det:

Data Domain-kundestøtten kan generere en rekke rapporter som viser følgende informasjon:

• En liste over alle filer på et bestemt nivå (f.eks. aktivt/arkiv/nettsky) etter alder
• Estimert størrelse og komprimeringsforhold etter mtree/hovedkatalogtre
• En liste over alle filer i et bestemt mtree etter alder
• og så videre

Følgende informasjon må samles inn for at dette skal være mulig:

• En ny støttebunt fra DDR – se følgende for mer informasjon: https://support.emc.com/kb/323283
• Utdataene fra "sfs_dump" eller "sfs_dump -c":

• En filplasseringsrapport (påkrevd hvis systemet er konfigurert for ER eller LTR):

Hvis du trenger hjelp med å samle inn det ovennevnte eller med å utføre trinnene i denne arkivoppryddingen, kan du kontakte kundestøtteleverandøren din.