Data Domain: Sådan løser du problemer med stor anvendelse af plads eller manglende tilgængelig kapacitet på Data Domain Restorers (DDRs)

 

• Dette er det område af disken, hvor nyligt indlagte filer/data er gemt – og på de fleste DDRs forbliver filerne her, indtil de udfases/slettes af et klientsikkerhedsreplikeringsprogram
• På DDRs, der er konfigureret med Extended Retention (ER) eller Long Term Retention (LTR), kan dataflytningsprocessen køres regelmæssigt for at overføre gamle filer fra det aktive niveau til arkiv- eller cloud-niveauer
• Den eneste måde at frigøre plads på det aktive niveau, der blev brugt af slettede/flyttede filer, er ved at køre en garbage collection/rensningsproces (GC)

• Det aktive niveau kan begynde at løbe tør for ledig plads, hvilket betyder, at der bliver vist advarsler/meddelelser som f.eks. følgende:

• Hvis det aktive niveau bliver 100% fyldt, vil der ikke kunne skrives nye data til DDR’en, hvilket kan forårsage, at sikkerhedsreplikeringer/replikeringer mislykkes – i dette scenarie kan advarsler/meddelelser som f.eks. det følgende vises:

• I nogle tilfælde vil det aktive niveau blive fyldt, hvilket vil medføre, at Data Domain File System (DDFS) bliver skrivebeskyttet, så eksisterende filer ikke kan slettes

• Forklare, hvorfor det aktive niveau kan blive fyldt op
• Beskrive et simpelt sæt af kontroleftersyn, du kan udføre for at bestemme årsagen til en stor udnyttelse af det aktive niveau og tilsvarende afhjælpende foranstaltninger

• Denne artikel er ikke udtømmende (dvs. der kan være nogle få situationer, hvor det aktive niveau i en DDR bliver meget anvendt/fyldt af en grund, der ikke er beskrevet i dette dokument), men det er dog meningen, at dette burde dække de mest almindelige årsager/problemer
• Denne artikel dækker ikke stor udnyttelse af arkiv-eller cloud-niveauer

  Det aktive niveau i en DDR kan opleve større udnyttelse end forventet af forskellige årsager:

• Sikkerhedsreplikeringsfiler/save sets er ikke blevet korrekt udfaset/slettet af klientens sikkerhedsreplikeringsprogrammer på grund af forkert opbevaringspolitik eller konfiguration af sikkerhedsreplikeringsprogrammer.
• Replikeringsforsinkelse, der resulterer i, at en stor mængde gamle data skal opbevares på det aktive niveau, som afventer replikering til kopier
• De data, der skrives til det aktive niveau, har samlet set en lavere komprimeringsfaktor end forventet
• Systemet har ikke den rigtige størrelse, dvs. at det simpelthen er for lille til den mængde data, som forsøges gemt på det
• Sikkerhedsreplikeringer består af et stort antal meget små filer – disse filer optager meget mere plads end forventet, når de er skrevet til at begynde med, men denne plads bør kunne genvindes under rensning/garbage collection
• Dataflytning, der ikke køres jævnligt på systemer, der er konfigureret med ER/LTR, betyder, at gamle filer skal overføres til arkiv/cloud-niveauer for at forblive på det aktive niveau
• Rensning/garbage collection bliver ikke kørt jævnligt
• For mange eller for gamle mtree snapshots eksisterer på DDR’en og forhindrer rensningen i at genvinde plads fra slettede filer/data

Trin 1 – Find ud af, om der skal køres rensning af det aktive niveau

Data Domain Operating System (DDOS) forsøger at opretholde en tæller, der hedder ''Cleanable GiB'' for det aktive niveau. Det er et skøn over, hvor meget fysisk (post-comp) plads der potentielt kan frigøres i det aktive niveau ved at køre rensning/garbage collection. Denne tæller vises med "filesys show space"/"df"-kommandoerne:
 
Hvis enten:

• Værdien for "Cleanable GiB" er stor
• DDFS er blevet 100% fyldt (og er derfor skrivebeskyttet)

Rensning skal udføres og have tilladelse til at køre til fuldførelse, før du fortsætter med nogen yderligere trin i dette dokument. For at begynde rensningen skal kommandoen "Filesys Clean Start" anvendes, dvs.:
 
For at bekræfte, at rensning er startet som forventet, kan "filesys status"-kommandoen anvendes, dvs.:
 
Bemærk, at:

• Hvis rensning ikke kan starte, skal du kontakte din supportudbyder for at få yderligere hjælp – dette kan indikere, at systemet har registreret en "missing segment error", der medfører, at rensning er deaktiveret
• Hvis rensning allerede kører, bliver følgende meddelelse vist, når den forsøges startet:

• Der vil ikke blive frigjort/genvundet plads i det aktive niveau, før rensningen når dens kopifase (som standard fase 9 i DDOS 5.4.x og ældre, fase 11 i DDOS 5.5.x og nyere). Du kan finde flere oplysninger om de faser, der bruges til rensning, på: https://support.emc.com/kb/446734
• Rensning kan ikke frigøre den mængde plads, der er angivet af "Cleanable GiB", da denne værdi hovedsagelig er et skøn. Du kan finde yderligere oplysninger om dette på: https://support.emc.com/kb/485637
• Rensning kan ikke frigøre al potentiel plads i en enkelt kørsel – det skyldes, at rensningen på DDRs med meget store datasæt vil arbejde i forhold til den del af filsystemet, der indeholder de fleste overflødige data (dvs. at give det bedste udbytte af ledig plads i forhold til den tid, det tager for rensningen at køre). I visse scenarier skal rensningen køres flere gange, før al potentiel plads frigøres
• Hvis værdien for "Cleanable GiB" var meget stor, kan det indikere, at rensning ikke har kørt med jævne mellemrum – kontrollér, at der er angivet en tidsplan for rensning:

Når rensningen er gennemført, skal du bruge kommandoerne "filesys show space"/"df" til at bestemme, om problemerne med anvendelse er blevet løst. Hvis anvendelsen stadig er stor, skal du udføre de resterende trin i denne artikel.

Trin 2 – Kontrollér, om der er store mængder Replikeringsforsinkelser i forhold til kildens replikeringssammenhænge

Native Data Domain-replikering er designet omkring konceptet "replication contexts". F.eks. når data skal replikeres mellem systemer:

• Sammenhænge for replikering oprettes på kilde- og destinations-DDRs
• Sammenhængene er initialiseret
• Når initialisering er fuldført, vil replikeringen jævnligt sende opdateringer/deltas fra kilde til destination for at holde data på systemerne synkroniseret

Hvis der er forsinkelse i en replikeringssammenhæng for en kilde, kan det medføre, at gamle data stadig opbevares på disken i kildesystemet (bemærk, at forsinkede replikeringssammenhænge ikke kan forårsage ekstremt stor anvendelse på destinationssystemet):

• replikeringssammenhænge for mapper (bruges ved replikering af et enkelt directory tree på /data/col1/backup between systems):

•  Mtree-replikeringssammenhænge (anvendes ved replikering af enhver mtree på nær /data/col1/backup between systems):

• Indsamling af replikeringssammenhænge (anvendes ved replikering af hele indholdet af en DDR til et andet system):

 For at finde ud af, om replikeringssammenhænge er forsinkede, skal du udføre følgende trin:

• Fastlæg værtsnavnet for det aktuelle system:

• Fastlæg datoen/klokkeslættet på det aktuelle system:

• Angiv replikeringssammenhænge, der er konfigureret på systemet sammen med deres "synced as of time". Bemærk, at interessesammenhænge er dem, hvor "destinationen" IKKE indeholder værtsnavnet på det aktuelle system (der angiver, at det aktuelle system er kilden), og at "synced as of time" er signifikant gammel:

De sammenhænge, som det aktuelle system er kilden til, og som viser signifikante forsinkelser eller sammenhænge, som ikke længere er nødvendige, skal brydes. Dette kan udføres ved at køre følgende kommando på kilde-og destinationssystemet:
 
For at bryde de "interessante" sammenhænge, der er vist ovenfor, vil følgende kommandoer køre på kilde og destination:
 
Bemærk, at:

• Når sammenhænge er brudt, vil der skulle udføres rensning af det aktive niveau for at frigøre potentiel plads i det aktive niveau.
• Hvis du bruger mtree-replikering, vil der muligvis – når sammenhængene er brudt – stadig være snapshots fra mtree-replikeringen tilbage på disken. Sørg for, at trin 5 bliver fulgt for at udfase alle overflødige snapshots, inden der køres en rensning
• Hvis kilde/destination-mtree’en er konfigureret til at overføre data til arkiv- eller cloud-niveauer, skal du være opmærksom på, at korresponderende mtree-replikeringssammenhænge som disse sammenhænge muligvis ikke kan genoprettes/initialiseres igen i fremtiden. Årsagen til dette er, at når der initialiseres en mtree-replikeringskontekst, bliver der dannet et mtree-snapshot på kildesystemet, der indeholder oplysninger om alle filerne i mtree (uanset niveauet). Dette snapshot bliver derefter fuldt ud kopieret til destinationens aktive niveau. Resultatet af, at destinationens aktive niveau ikke har tilstrækkelig med ledig plads til at indsende alle mtrees data fra kilden, vil være, at initialisering ikke vil kunne gennemføres. Du kan få flere oplysninger om dette problem ved at kontakte din supportudbyder.
• Hvis en indsamlingsreplikeringsstilstand bliver brudt, vil sammenhængen ikke være i stand til at blive oprettet/initialiseret uden først at ødelægge forekomsten af DDFS på destinations-DDR’en (og miste alle data på dette system). Det betyder, at en efterfølgende initialisering kan kræve lang tid/netværksbåndbredde, da alle data fra kilden rent fysisk skal kopieres til destinationen igen

Trin 3 – Kontrollér for mtrees, der ikke længere er påkrævede

Indholdet af DDFS er logisk opdelt i mtrees. Det er normalt for individuelle sikkerhedsreplikeringsprogrammer/klienter at skrive til en individuel mtrees. Hvis et sikkerhedsreplikeringsprogram er deaktiveret, vil det ikke længere være muligt at skrive data til/slette data fra DDR’en, hvilket kan efterlade gamle/overflødige mtrees på systemet. Data i disse mtrees vil fortsætte med at eksistere i det uendelige og optage diskplads på DDR’en. Som et resultat heraf bør en sådan overflødig mtrees slettes. F.eks.:

• Hent en liste over mtrees på systemet:

• Alle mtrees, der ikke længere er nødvendige, skal slettes med kommandoen "mtree delete", dvs.:

• Pladsen, der bliver brugt på disken for den slettede mtree, vil blive frigjort, næste gang rensning/garbage collection køres for det aktive niveau.

Bemærk, at:

• Mtrees, der er destinationer til mtree-replikering (dvs. har status som RO/RD i outputtet på mtree-listen), skal have deres korresponderende replikeringssammenhæng brudt, før mtree kan slettes.
• Mtrees, der anvendes som DDBoost Logical Storage Units (LSUs'er) eller som Virtual Tape Library (VTL-puljer), kan muligvis ikke slettes via kommandoen "mtree delete" – se i Data Domain Administration Guide for at få flere oplysninger om, hvordan du sletter sådanne mtrees
• Mtrees, der er konfigureret til opbevaringslåsning (dvs. har statussen RLCE eller RLGE), kan ikke slettes – i stedet skal alle individuelle filer i mtree’en have deres opbevaringslåsning tilbageført og slettes individuelt – se i Data Domain Administration Guide for at få flere oplysninger.

Trin 4 – Søg efter gamle/overflødige mtree snapshots

Et Data Domain-snapshot repræsenterer et øjebliksbillede for den korresponderende mtree. Resultatet er følgende:

• Alle filer, som findes i mtree’en, når snapshottet oprettes, vil blive henvist til snapshottet
• Selvom snapshottet bliver ved med at eksistere, selvom disse filer fjernes/slettes, vil det gennem rensning ikke være muligt at frigøre noget fysisk plads, de bruger på disken – det skyldes, at dataene skal blive på systemet, hvis man senere skal tilgå kopien af filen i snapshottet.

Du kan finde ud af, om nogen mtrees har gamle/overflødige snapshots, ved at udføre følgende trin:

• Hent en liste over mtrees på systemet ved hjælp af kommandoen "mtree list" som vist i trin 3
• Anfør snapshots, der findes for hver mtree ved hjælp af kommandoen "snapshot list":

• Hvor der findes snapshots, skal du bruge outputtet fra "snapshot list mtree [mtree name]" til at bestemme snapshots, som:

• Hvis kommandoen for snapshotliste køres igen, vil disse snapshots nu blive vist som udløbet:

Bemærk, at:

• Det er ikke muligt at afgøre, hvor mange fysiske data et enkelt snapshot eller sæt af snapshots optager på en disk – den eneste værdi for "plads", der er knyttet til et snapshot, er en indikation af den forkomprimerede (logiske) størrelse af mtree’en, da snapshottet blev oprettet (som vist i ovenstående output).
• Snapshots, der er navngivet "REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS", administreres af mtree-replikering, og under normale omstændigheder bør de ikke have brug for at blive udskiftet manuelt (replikering vil automatisk udfase disse snapshots, når de ikke længere er nødvendige). Hvis sådanne snapshots er ekstremt gamle, betyder det, at den tilsvarende replikeringssammenhæng sandsynligvis viser signifikant forsinkelse (som beskrevet i trin 2).
• Snapshots, der er navngivet med navnet "REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS", oprettes ved mtree-replikering, når en mtree-replikeringssammenhæng brydes. Formålet med dem er, at de kan bruges til at undgå en fuldstændig synkronisering af replikeringsdata, hvis den brudte sammenhæng senere bliver gendannet (f.eks. hvis sammenhængen blev brudt ved en fejl). Hvis replikering ikke bliver genoprettet, kan disse sammenhænge være udfaset manuelt som beskrevet ovenfor
• Udløbne snapshots vil fortsat findes på systemet, indtil næste gang en rensning/garbage collection køres – her vil de blive slettet fysisk og fjernet fra outputtet på "snapshot list mtree [mtree name]" – rensning kan derefter frigøre noget plads, som disse snapshots optog på disken

Trin 5 – Kontrollér, om der er et uventet antal gamle filer på systemet

Automatisk understøttelse fra DDR’en indeholder histogrammer, der viser en opdeling af filerne på DDR’en efter alder – f.eks.:
 
Dette kan være nyttigt for at afgøre, om der er filer på systemet, der ikke er blevet udfaset/slettet som forventet af klientens sikkerhedsreplikeringsprogram. Hvis f.eks. det ovenstående system blev skrevet til et sikkerhedsreplikeringsprogram, hvor den maksimale opbevaringsperiode for en enkelt fil var 6 måneder, er det straks indlysende, at sikkerhedsreplikeringsprogrammet ikke udfaser/sletter filer som forventet, da der er ca. 80.000 filer, der er ældre end 6 måneder på DDR’en.

Bemærk, at:

• Det er sikkerhedsreplikeringsprogrammets ansvar at udføre alle udfasninger/sletninger af filer
• En DDR vil aldrig udfase/slette filer – medmindre det udtrykkeligt er angivet af sikkerhedsreplikeringsprogrammet at slette en fil, vil filen stadig være til stede på DDR’en og optage plads på ubestemt tid

Det kan betyde, at sådanne tilfælde først skal undersøges af sikkerhedsreplikeringsprogrammets supportteam.

Om nødvendigt kan Data Domain-support levere ekstra rapporter for at:

• Give navnet/ændringstidspunktet på alle filer i en DDR sorteret efter alder (så navnet/placeringen af alle gamle data kan bestemmes)
• Opdele histogrammer for filens alder i separate rapporter for det aktive/arkiv/cloud-niveau (hvor ER/LTR-funktionerne er aktiveret)

For at udføre dette skal du:

• Indsamle bevis som beskrevet i afsnittet om "indsamling af sfs_dump" i noteafsnittet i dette dokument
• Åbne en serviceanmodning med din supportudbyder

Når gamle/overflødige filer slettes, skal der køres rensning/garbage collection for fysisk at frigøre plads i det aktive niveau

Trin 6 – Kontrollér for sikkerhedsreplikeringer, der indeholder et stort antal små filer

På grund af designet af DDFS, kan små filer (i princippet alle filer, der er mindre end ca. 10 MB) optage for meget plads, når de oprindeligt er skrevet til DDR’en. Dette skyldes "SISL-arkitekturen" (Stream Informed Segment Layout), der betyder, at små filer optager flere individuelle 4,5 MB-blokke af plads på disken. F.eks. kan en 4 kB-fil faktisk optage op til 9 MB fysisk diskplads, når den er skrevet initialt.

Denne unormalt megen plads bliver efterfølgende frigivet, når rensning/garbage collection køres (da data fra små filer derefter bliver samlet i et mindre antal 4,5 MB-blokke), men det kan forårsage, at mindre DDR-modeller vil vise ekstremt stor anvendelse og opfyldning, når sådanne sikkerhedsreplikeringer køres.

Autosupports indeholder histogrammer af filer, der er opdelt efter størrelse, f.eks.:
 
Hvis der er bevis for, at sikkerhedsreplikeringer skriver meget store mængder af små filer, kan systemet blive påvirket af signifikante midlertidige forøgelser i anvendelsen mellem hver aktivering af rensning/garbage collection. I dette scenarie er det bedst at ændre sikkerhedsreplikeringsmetodikken, så den indføjer alle små filer i et enkelt større arkiv (f.eks. en tar file), inden de skrives til DDR’en. Bemærk, at et sådant arkiv ikke bør komprimeres eller krypteres (da dette vil beskadige komprimeringsfaktor/deduplikeringsforholdet på disse data).

Trin 7 – Kontrollér for deduplikeringsforhold, der er lavere end forventet

Hovedformålet med en DDR er at deduplikere og komprimere indarbejdelsen af data i enheden. Forholdet mellem deduplikering/komprimering afhænger meget af systemets anvendelsesformål og den type data, det indeholder – men i mange tilfælde vil der være et forventet samlet komprimeringsfaktor, der er baseret på resultater, der er kommet gennem proof of concept-tests eller lignende. For at bestemme systemets aktuelle totale komprimeringsfaktor (og altså om det lever op til forventningerne) kan kommandoen "filesys show compression" bruges. F.eks.:
 
I ovenstående eksempel opnår systemet et samlet komprimeringsfaktor på 65.3x for det aktive niveau (som er ekstremt godt). Hvis denne værdi imidlertid viser, at det totale komprimeringsfaktor ikke lever op til forventningerne, vil det sandsynligvis være nødvendigt at foretage yderligere undersøgelser. Bemærk, at undersøgelse af komprimeringsfaktor, der er lavere end forventet, er et komplekst emne, der kan have mange grundlæggende årsager. Du kan finde flere oplysninger om den videre undersøgelse i følgende artikel: https://support.emc.com/kb/487055

Trin 8 – Kontrollér, om systemet er en kilde til replikering af samlinger

Hvis du bruger replikering af samlinger, hvor kildesystemet er fysisk større end destinationen, vil størrelsen på kildesystemet være kunstigt begrænset til at stemme overens med det på destinationen (dvs. der vil være et diskområde på kilden, der vil blive angivet som ubrugeligt). Årsagen til dette er, at når du bruger replikering af samlinger, skal destinationen være en kopi af blokniveauet for kilden, men hvis kilden er fysisk større end destinationen, er der risiko for, at der skrives for mange data til kilden, der ikke kan kopieres til destinationen (da den allerede er fuld). Dette scenarie undgås ved at begrænse kildens størrelse, så den passer til destinationen.

• Ved at bruge kommandoerne fra trin 2 kan du kontrollere, om systemet er en kilde til replikering af samlinger. For at gøre dette skal du køre ''replication status" og bestemme, om der er nogen replikeringssammenhænge, der starter med "col://" (der angiver replikering af samlinger), der IKKE indeholder værtsnavnet på det lokale system i destinationen (der angiver, at systemet skal være en kilde for replikeringssammenhængen)
• Hvis systemet er en kilde til replikering af samlinger, skal du kontrollere størrelsen på hvert systems aktive niveau ved at logge ind på begge og køre kommandoen "filesys show space" – og sammenligne det aktive niveaus "post-comp"-størrelse på hver
• Hvis kilden er signifikant større end destinationen, så er størrelsen på dens aktive niveau kunstigt begrænset
• For at tillade at al plads på kilden kan være brugbar for data, skal du udføre følgende:

Trin 9 – Kontrollér, om dataflytning skal køres regelmæssigt

Hvis DDR’en er konfigureret med enten Extended Retention (ER) eller Long Term Retention (LTR), vil den have et andet niveau af lager tilkoblet (arkivniveau for ER eller cloud-niveau for LTR). I dette scenarie kan dataflytningspolitikker ikke konfigureres i forhold til mtrees for at overflytte ældre/uændrede data, der kræver langvarig opbevaring, fra det aktive niveau til den alternative lagerplacering, så den plads, der bruges af disse filer i det aktive niveau, fysisk kan regenereres af en rensning/garbage collection. Hvis dataflytningspolitikker er forkert konfigureret, eller hvis dataflytningsprocessen ikke er blevet kørt regelmæssigt, vil gamle data forblive i det aktive niveau længere end forventet og vil fortsat optage fysisk plads på disken.

• Bekræft til at begynde med, om systemet er konfigureret til ER eller LTR ved at køre "filesys show space" og kontrollere, om der findes et arkiv- eller cloud-niveau – bemærk, at for at være brugbare skal disse alternative lagerniveauer have "post-comp"-størrelse på > 0Gb:

• Hvis systemet er konfigureret med ER/LTR, skal du kontrollere dataflytningspolitikker i forhold til mtrees for at sikre, at disse er som forventet og angive, at gammelt data skal skubbes ud til det alternative lagerniveau:

• Hvis systemet er konfigureret med ER/LTR, skal du kontrollere, at dataflytningen er planlagt til at køre med jævne mellemrum for fysisk at flytte filer/data fra det aktive niveau til alternativt lager:

• Hvis systemet er konfigureret til ER/LTR, skal du kontrollere, hvornår dataflytningen sidst blev kørt:

• Når dataflytningen er færdig, skal du køre rensning af det aktive niveau (bemærk, at den muligvis er konfigureret til at starte automatisk, når dataflytningen er afsluttet) for at sikre, at den plads, der bruges af de flyttede filer i det aktive niveau, er fysisk frigjort:

Trin 10 – Føj ekstra lagerplads til det aktive niveau

Hvis alle foregående trin er blevet udført, er kørslen for rensning af det aktive niveau afsluttet, men er der stadig ikke tilstrækkelig med plads på det aktive niveau, er det sandsynligt, at systemet ikke har haft den rigtige størrelse i forhold til det workload, det modtager. I dette tilfælde skal en af følgende udføres:

• Reducer det workload, der rammer systemet – f.eks.:

• Føj ekstra lagerplads til systemets aktive niveau, og udvid dets størrelse:

Data Domain-support kan generere en række rapporter, der viser oplysninger som f.eks.:

• En liste over alle filer på et bestemt niveau (dvs. aktiv/arkiv/cloud) sorteret efter alder
• Estimeret størrelse og kompressionsfaktor ved mtree/major directory tree
• En liste over alle filer i en bestemt mtree sorteret efter alder
• osv.

For at tillade dette skal følgende oplysninger indsamles:

• En ny supportpakke fra DDR’en – du kan finde flere oplysninger i det følgende:https://support.emc.com/kb/323283
• Outputtet fra "sfs_dump" eller "sfs_dump -c":

• En filplaceringsrapport (påkrævet hvis systemet er konfigureret til ER eller LTR):

Hvis du har brug for hjælp til at indsamle ovenstående eller med nogen af trinene i denne arkivrensning, skal du kontakte din supportleverandør.