Data Domain: En oversigt over DDFS-faser (data Domain File System) Clean/spildopsamling (GC)

Datadomain-filsystemet (DDFS) adskiller sig fra mange almindelige filsystem implementeringer i det tidspunkt, hvor en fil slettes fra det filsystem, som den pågældende fil bruger, ikke er umiddelbart tilgængelig for genbrug. Årsagen er, at data Domain Restorer (DDR) ikke med det samme er at finde ud af, om data, som blev henvist af den slettede fil, også bliver fjernet fra andre filer, og derfor er det sikkert at fjerne disse data eller ej.

Rengøring (nogle gange kaldet spildopsamling/GC) er den proces, hvorved en DDR:

• Bestemmer, hvilke data på disken der er superfluous (dvs. er ikke længere refereret af objekter som f. eks. filer eller snapshots)
• Fjerner fysisk superfluous-data, der gør den underliggende diskplads tilgængelig til genbrug (dvs. indlevering af nye data)

Ren/GC er normalt planlagt til at køre med jævne mellemrum (som standard starter med at 6am hver tirsdag) og kan være:

• Længe kører
• Kostbart dyrt

Bemærk imidlertid, at der ikke er nogen anden måde end ved at køre Clean/GC i hvilke data kan fjernes/frigøres fysisk på en data Domain-Restorer (dvs. der er ingen genveje for at gøre denne proces hurtigere).

Denne artikel beskriver Clean/GC med mere detaljeret forklaring:

• De faser, der generelt kører
• De forskellige rene algoritmer, der anvendes i forskellige versioner af DDOS

Ingen

Hver gang, der skal forudindstilles/udrulles, er det i første omgang at finde frem til superfluous-data på DDR-en kort oversigt over, hvordan dette sker, er som følger:

• Clean/GC optæller indholdet af DDFS-filsystemet og søger efter objekter, såsom filer, Snapshots og logfiler for replikering, som aktuelt findes på systemet
• Det bestemmer derefter alle fysiske data på disken, der aktivt henvises til af disse objekter
• Data, der aktivt henvises til, siges at være ' live ' og kan ikke fjernes fra DDR ellers vil de objekter, der refererer til disse data, blive beskadiget (de vil ikke længere kunne læses, da de underliggende data, som de er afhængige af, ikke længere findes på disken)
• Data, som ikke aktivt refereres til af noget objekt, siges at være ' dødt ' og er superfluous-disse data kan fjernes sikkert fra systemet
• Alle data på en DDR er pakket ind i objekter med 4,5 MB i en størrelse kendt som beholdere
• Med optællingen ren/GC kan bestemme, hvilke 4,5 MB beholdere der indeholder inaktive data og mængden af døde data i hver
• Som standard vil Clean/GC vælge 4,5 MB containere, der holder > 8% døde data til ' behandling '

For det andet skal det fjerne døde data på DDR – a kort forklaring af, hvordan dette gøres, er som følger:

• Beholdere valgt til behandling kontrolleres igen for at bekræfte, at de har en god mængde døde data
• Levende data udtrækkes fra disse beholdere og skrives til nye 4,5 MB-beholdere i slutningen af filsystemet.
• Når det er gennemført, slettes de valgte beholdere (herunder de døde data, de indeholder) fra disken fysisk frigørelse af diskplads

Oprydningsprocessen opdeles i et antal ' faser ' med den totale fase tælling, der er afhængig af:

• Den version af DDOS, der bruges på DDR (så den rene algoritme, som standard bruges, af den version af DDOS)
• Konfigurationen/indholdet af systemet

Generelt foretages der imidlertid en proces med at finde "uanbringelige" data og valg af tilsvarende beholdere på tværs af en række faser, hvorimod fjernelse af døde data finder sted i en enkelt fase, benævnt» kopi «. F. eks. vil visse versioner af DDOS køre rene faser som følger:

1. Forudoptælling-Optæl indholdet af DDFS-filsystemet
2. Før fletning-Udfør en DDFS indeks fletning for at sikre, at den seneste kopi af indeks informationen er tømt på disken
3. Pre-filter-afgør, om der er dublerede data i DDFS-filsystemet, og hvis det så det er
4. Pre-Select-afgør, hvilke 4,5 MB-beholdere der skal behandles ' ved rensning
5. Kopier-fysisk udtræk direkte data fra udvalgte beholdere, Skriv dette til nye beholdere, og slet de valgte beholdere
6. Oversigt-genopbyge oversigts vektorer (som bruges som en optimering under indlevering af nye data)

I ovenstående eksempel er 1-4 faserne anvendt til at bestemme, hvor der findes "døde" data på DDR (omtales som "optællings faser" i resten af dette dokument), mens fase 5 (kopi) anvendes til fysisk fjernelse af disse data.

Bemærk, at der ikke er nogen plads fysisk frigivet på systemet, før ren/GC når en kopi fase. Dette kan medføre, at der er en væsentlig forsinkelse mellem ren start og afstand til frigørelse (på grund af Optællingsprocessen, der er først at køre for at fuldføre). Det er ikke tilladt at udfylde 100%, før ren/GC påbegyndes.

Optællings faser er ofte dyrt med hensyn til CPU-udnyttelse (dvs. de er generelt CPU-bundet), mens kopi fasen er dyrt i både CPU og I/O (dvs. de er generelt CPU'en og I/O-bundet). Det er dog muligt at sige, at:

• Den totale længde af optællings faser afhænger af mængden af data på det DDR, der skal optælles
• Den samlede længde af kopierings fasen afhænger af mængden af døde data på DDR, der skal fjernes, og hvordan "fragmenteret" data er på disken (beskrevet herunder)

Antallet/funktionen af optællings faser afhænger af den frigivelse af DDOS, der anvendes på en DDR.

DDOS 5,4 (og tidligere)-fuld ren-algoritme: Kører 6 eller 10 faser (som vist ovenfor):

• Indholdet af DDFS-filsystemet er optalt oppefra og ned (dvs. det er centreret)
• DDFS registrerer alle filer, som findes på DDR og derefter scanner hver fil for at finde ud af, hvilke data der refereres til af denne fil.
• Dette gør det muligt for ren/GC at bestemme, hvilke data på disken der er ' live '

DDOS 5,5 (og nyere)-fysisk ren algoritme (PGC): Kører 7 eller 12 faser:

• Indholdet af DDFS optælles forneden (dvs. det ikke længere scanner enkelte filer)
• DDFS registrerer filsystemers metadata, der henviser til fysiske data på disken og scanner metadata for at finde ud af, hvilke data der refereres til
• Dette gør det muligt for ren/GC at bestemme, hvilke data på disken der er ' live '
• Dette opnås ved at tilføje en ' analyse fase (derved forøges antallet af faser over den fulde rene algoritme)
• I de fleste tilfælde forventes det, at den totale rensnings varighed er kortere end komplet ren for det samme system (trods bestående af flere individuelle faser)

DDOS 6,0 (og nyere)-perfekt fysisk ren-algoritme (PPGC):

• Dette er simpelthen en optimering af den fysiske rene algoritme og omtales yderligere nedenfor

Bemærk, at DDOS, der er skiftet fra den fulde rene algoritme til den fysiske rene-algoritme for at forbedre skaleringen/ydeevnen af Optællingsprocessen, på grund af den mest opfyldte rene-algoritme, at den ikke skal skaleres godt ind på DDRs med enten:

• Et stort antal små filer (som kontekst kontakt ved flytning fra optælling af én fil til den næste var dyrt/langsom)
• Forholdet mellem høj værdi duplikering (som flere filer har reference til de samme fysiske data, så de samme data blev optalt flere gange)

DDRs switche automatisk fra fulde til Physical Clean-algoritmer, når den opgraderes fra DDOS 5,4 (eller ældre) til 5,5 (eller nyere). Den eneste undtagelse til dette er systemer, der er konfigureret med Extended retention, hvor indholdet af DDFS skal kontrolleres for "spanning"-filer, inden den fysiske rensning kan aktiveres-en diskussion af denne proces er uden for omfanget af dette dokument, men denne kontrol udføres automatisk, efter at opgraderingen og den fysiske rensning er aktiveret ved fuldførelse af denne check, uden manuel handling påkrævet.

På samme måde DDRs switche fra Physical to Perfect Physical fysiske Clean-algoritmer automatisk, når der opgraderes fra DDOS 5. x til 6,0 (eller nyere). Bemærk imidlertid, at den perfekte fysiske rene kræver indeksering for at være i formatet ' index 2,0 ', før den kan bruges. Bemærk, at:

• Formatet ' index 2,0 ' blev introduceret med DDOS 5,5 (så alle filsystemer oprettet på 5,5 eller nyere vil allerede bruge indeks 2,0)
• Det filsystem, der er oprettet på 5,4 eller tidligere, vil begynde med at have indeks i indeks 1,0-formatet. Når det er opgraderet til DDOS 5,5 (eller nyere), vil indeksene blive konverteret til indekset 2,0-format-konverteringen foretages, hver gang der bare skal ske en "~ 1% af indeksene omregnes under hver rensning, så det kan tage op til 2 år (hvis en ren kører ugentligt) for at konvertere indeksene til 2,0-formatet

DDRs, der oprindeligt kører DDOS 5,4 (eller tidligere), men som efterfølgende er blevet opgraderet til DDOS 5,5 (eller nyere), kan tvinges til at konvertere indeks til indeks 2,0-formatet med et tidspunkt ' indeks rebuild '. Bemærk imidlertid at en indeks gendannelse kræver en længere periode, mens indeksene er fysisk gendannet. Dette tager normalt 2-8 timer at udføre denne handling alt afhængigt af størrelsen/mængden af data på DDR. For at diskutere udførelse af et indeks gendannelse skal du kontakte din kontrakterede supportleverandør.

Som nævnt ovenfor, uanset om der anvendes ren/GC-algoritme, kan renten kræve et variabelt antal faser – for eksempel en fuld ren algoritme kan kræve 6 eller 10 faser. Årsagen er, at:

• Når DDFS startes, reserveres en fast mængde hukommelse, der skal bruges af Clean/GC
• I denne hukommelse opretter Clean/GC datastrukturer for at beskrive resultaterne af optællingen (dvs. hvor der findes Live vs inaktive data på disken)
• Når en DDR indeholder en forholdsvis lille mængde data, kan hele indholdet af DDFS-filsystemet beskrives i dette hukommelsesområde
• På mange systemer er det imidlertid ikke muligt, og dette hukommelsesområde vil blive tømt, før hele indholdet af DDFS-filsystemet blev optalt
• Som et resultat betyder det, at systemerne udfører ' prøveudtagning ', der øger antallet af påkrævede rene faser

Når der anvendes stikprøveudtagning, skal ren/GC:

• Udfør et prøveudtagnings gennemløb for optælling på tværs af hele filsystemet. Bemærk, at denne optælling ikke er ' fuldført ' (dvs. at den ikke registrerer alle oplysninger om hver del af filsystemet, men i stedet nærmer sig oplysningerne for hver del af filsystemet)
• Brug denne information for at finde ud af, hvilken del af DDFS-filsystemet der vil have fordel af renten fra at have ren/GC-kørsel mod det (dvs. hvor en del af filsystemet vil give de bedste resultater i tilfælde af, at der frigøres plads, hvis det blev renset)
• Udføre en ekstra rund gennemført optælling mod den valgte del af filsystemet, hvis indhold nu kan være fuldt beskrevet i den hukommelse, der er reserveret til GC

Udtagning er automatisk aktiveret under ren/GC, hvis det er påkrævet, men det vil medføre:

• En forøgelse af antallet af hovedaktiviteter, der skal udføres af ren/GC
• En tilsvarende forøgelse af den totale varighed af Clean/GC

Inden DDOS 6,0 størstedelen af DDRs foretage udtagning af stikprøver under ren/GC (medmindre de er relativt små data sæt). Den perfekte fysiske rene-algoritme inkluderer imidlertid forskellige optimeringer for at reducere den mængde hukommelse, der kræves af Clean/GC, når data optælles i filsystemet. Det betyder, at mange systemer, som var i stand til at udføre en sampling under ren/GC på DDOS 5. x vil ikke længere kræve sampling på DDOS 6,0-Dette reducerer derfor antallet af faser, som er udført af cleane og forårsager en tilsvarende formindskelse i den totale ventetid (dvs. forbedringer i en ren ydelse).

Der er ingen tilgængelige oplysninger, der direkte kan afgøre, om et system har skiftet fra den fysiske oprydnings algoritme til den perfekte fysiske oprydnings algoritme, som ikke er:

• Når systemet kørte fysisk rensning på DDOS 5,5-5,7, var det blevet udført 12 faser under en ren
• Efter den system, der opgraderes til DDOS 6,0 (eller nyere), udfører det kun 7 faser under en ren

Hvis et system, der kører DDOS 6,0, stadig skal foretage sampling, vil det blive aktiveret automatisk under rensning, og det vil gå tilbage til at køre 12 faser under Clean.

Uanset den rene algoritme, der bruges kopierings fasen (hvor døde data fysisk fjernes fra systemet) fungerer på samme måde på tværs af alle versioner. Kopierings fasens ydelse er generelt afhængig af:

• Mængden af ' dødt ' data, som skal fjernes
• ' Fragmentering ' af disse inaktive data (dvs. hvordan det spredes på tværs af disken)

Som det er beskrevet ovenfor, skal du vælge 4,5 MB-beholdere, der har de døde data, og udtrække alle levende data fra disse beholdere og skrive dem, som passer til nye beholdere, så de oprindeligt markerede beholdere Følgende eksempler beskriver, hvorfor fragmentering af døde data er vigtig:

Eksempel 1:

• 10 beholdere er valgt til kopiering (45Mb total data)
• Alt, hvis disse beholdere ikke har nogen dynamiske data (dvs. de data, som de indeholder, er fuldstændigt ikke-refererede/døde)
• Som en resultat kopi skal du blot markere disse beholdere som slettet for at frigøre 45Mb fysisk plads på disken.

Eksempel 2:

• 100 beholdere er valgt til kopiering (450Mb total data)
• Hver af disse beholdere indeholder 90% Live data/10% uanbringelige data
• For at behandle disse beholdere skal kopien have:

Tydeligt en væsentlig større mængde i/O og CPU er påkrævet for at kunne udføre den kopi, der er beskrevet i eksempel 2, når det sammenlignes med det i eksempel 1, så det vil tage betydeligt længere tid at frigøre 45Mb fysisk plads i dette eksempel.

Brugere har generelt ikke kontrol over ' fragmentering ' af inaktive data på disken på en DDR som den er meget afhængig af use casen/typen af data, der skrives til systemet. Bemærk dog, at ren/GC vedligeholder statistik, der hjælper med at afgøre, hvilken fragmentering af døde data der er opstået under kopierings fasen (som derfor lader en bruger afgøre, om denne fragmentering kan forklare en potentielt lang, kopi fase). Sådanne statistikker fra den seneste fase af ren/GC indsamles i automatisk support. F. eks. viser en kopi fase, hvor der er en rimelig sammenhængende data (dvs. størstedelen af de beholdere, der er valgt til kopiering, der har været mest døde data):

procent af de levende data, som er blevet kopieret:              3,6% 4,3%

Når det er omvendt, vises en kopi fase, hvor døde data er fragmenteret (dvs. størstedelen af de beholdere, der er valgt til kopien, der opbevares hovedsageligt dynamiske data):

procent af de levende data, som er blevet kopieret:             70,9% 71,5%

Som beskrevet ovenfor er Clean/GC nødvendigt at udføre sammenlignende meget mere arbejde i det andet scenario for at få fysisk fri plads på DDR, hvilket vil medføre, at kopierings fasen bliver større for at reducere.

Kopier fasernes overførsel kan også være negativ påvirket af:

• Brug af kryptering: Data skal muligvis dekrypteres/genkrypteres under kopieringen, hvilket øger den nødvendige CPU-mængde
• Brug af lav båndbredde optimering: Beholdere kan have behov for at få brug for en skitse information, der skal genereres under kopieringen, hvilket også medfører en væsentlig forøgelse af det nødvendige CPU-beløb

Bemærk, at hvis lav båndbredde optimering og/eller kryptering for nyligt er blevet aktiveret alle eksisterende beholdere (uanset om de er valgt til kopiering eller ej) muligvis skal krypteres, og/eller der genereres skitse informationer mod dem under en senere rensning, kan det medføre, at handlingen Clean (specifikt kopierings fasen) tager betydeligt længere tid end normalt.

Yderligere bemærkninger om check/ændring af rene skemaer og Throttle er tilgængelige i følgende KB artikel: https://support.emc.com/kb/306100

Bemærk dog:

• I almindelige omstændigheder skal det planlægges, at det skal køres mindst én gang i løbet af ugen. det kan medføre, at data på disken er meget fragmenteret (dvs. en ringe for dårlig fysisk afstands lokalitet), hvilket kan resultere i en dårlig læsning/replikering/data bevægelses ydelse
• Rengøring af gashåndtaget påvirker ikke den samlede mængde CPU-og I/O-båndbredde, der bruges af ren-i stedet for, hvor følsom ren er for anden belastning på systemet. F.eks.:

• Som standard indstilles gashåndtaget til 50-det er brugeren, der har ansvaret for at teste, at det kører rent med forskellige regulatore-indstillinger, mens DDRs erfaringens normale arbejdsbelastning for at bestemme en indstilling for gashåndtag, hvilket giver mulighed for:

• Bemærk, at en langvarig rengøring ikke er nødvendigvis et problem, så længe:

• System, der bruger Extended opbevarings funktioner, skal konfigureres således:

• Alle oplysninger fra den seneste rene handling er inkluderet i automatisk support og detaljer: