Data Domain-operativsystemet understøtter ikke proaktiv rebalancering af data på tværs af storage efter udvidelse af kapaciteten i Data Domain-filsystemet

Som med mange storagesystemer kan kapaciteten på de fleste modeller af Data Domain Restorer (DDR) øges ved at tilføje eksterne lagerkabinethylder (ES30, DS60) til systemet og derefter udvide DDFS (Data Domain File System) på disse kabinethylder. Når dette udføres:

• Nye kabinethylder er fysisk fastgjort (kablet tændt)
• Data Domain Operating System (DDOS) scanner storage igen for at identificere eksistensen af nye kabinethylder
• Disse nye kabinethylder føjes derefter til et storageniveau i DDR (det aktive niveau eller en bestemt arkivenhed)
• Dette niveau kan derefter udvides online uden behov for et udfald til DDFS
• Alle nye data, der skrives til det pågældende storageniveau, skrives på tværs af eksisterende og nye hylder
• Data på eksisterende hylder rebalanceres imidlertid ikke på tværs af nye skabshylder

For at forklare dette yderligere:

• Inden for DDOS er enheden for datalagring en 4.5 Mb 'container'
• Efterhånden som de oprettes, skrives 4,5 Mb containere på tværs af alle kabinethylder i den tilsvarende niveauarkivenhed på en round robin måde
• Når der føjes yderligere kabinethylder til en niveauarkivenhed, begynder DDFS at skrive nye 4,5 Mb containere til disse kabinetter ud over eksisterende kabinetter (de nye kabinetter medfølger, når round robin-containeren skriver)
• DDOS gør imidlertid ikke noget specifikt forsøg (eller tilbyder nogen specifik funktionalitet) på at migrere eksisterende objektbeholdere på niveauet fra eksisterende til nye hyldekabinetter

Det betyder, at tilføjelsen af hyldekabinetter kan efterlade data 'ubalancerede' på tværs af vedhæftet lager. F.eks.:

• En DDR har oprindeligt et enkelt kabinet i sit aktive niveau, som er 90 % fuldt
• Der føjes et ekstra kabinet til det aktive niveau, og DDFS udvides til dette kabinet
• Skrivninger af nyoprettede 4,5 Mb containere er nu round robin på tværs af eksisterende og nye kabinetter
• Dette efterlader det eksisterende kabinet uden ledig plads, mens det nyligt tilføjede kabinet næsten er tomt

I dette scenarie giver mange storagesystemer en administrator mulighed for at rebalancere data på tværs af tilknyttede kabinetter og proaktivt migrere nogle data fra eksisterende kabinetter til nyligt tilføjede kabinetter for at sikre, at den anvendte kapacitet for alle kabinetter er omtrent den samme). Bemærk dog, at DDOS IKKE tilbyder denne funktionalitet, og på grund af designet af DDFS er det ikke nødvendigt, da rebalancering af data finder sted naturligt over tid.

Rebalancering af data udføres af to operationer:

• Rengøring af affaldsindsamling
• Lokalitet reparation

Hver af disse operationer, og hvordan de forårsager automatisk rebalancering af data, diskuteres mere detaljeret nedenfor.

Rengøring af

affaldsindsamlingRengøring af affaldsindsamling (GC) er en planlagt aktivitet, der kører regelmæssigt på en DDR (som standard en gang om ugen mod det aktive niveau og, forudsat at pladsgenvinding er aktiveret, når det kræves mod arkivenheder). Når det kører:

• Identificerer, hvilke fysiske data i niveauarkivenheden der er 'live' (bruges af en eller flere filer i filsystemet eller objekter som snapshots) eller 'døde' (uden reference til noget objekt, der derfor er overflødigt for systemet)
• Finder de 4,5 Mb containere, der indeholder størstedelen af de "døde" data i niveauarkivenheden
• Læser disse 4,5 MB containere og udtrækker eventuelle "live" data, de indeholder – dette "kopieres derefter videresendelse" til nyoprettede 4,5 Mb beholdere, som skrives på tværs af alle hylder i niveauarkivenheden
• Sletter de gamle 4,5 Mb containere og fjerner dermed de døde data, de indeholder, og frigør underliggende plads på disken til genbrug

Når GC kører på et system med nogen form for dataubalance, forventes det, at de fleste gamle data (og derfor de fleste døde data) opbevares på ældre hyldekabinetter i niveauarkivenheden. Som følge heraf er de fleste af de containere, der læses, kopieres fremad fra og slettes, på ældre hyldeskabe. De nyoprettede containere er dog skrevet i et round robin-format mellem alle hylder i niveauet. Som følge heraf er det meste plads, der frigøres af GC, på ældre hylder, mens nyforbrugt plads er på tværs af alle hylder.

Som et simpelt eksempel:

• Det aktive niveau i en DDR indeholder to hylder - den første hylde indeholder 10000 4,5 Mb containere, mens den anden hylde indeholder 100 4,5 Mb containere (for hver container på den anden hylde er der 100 containere på den første hylde)
• GC kører og kopierer videresendelsesdata fra 5000 containere på første hylde
• Live data inden for disse 5000 containere medfører, at der oprettes 1000 nye 4,5 Mb containere
• Disse 1000 nye 4,5 Mb beholdere er skrevet på tværs af begge hylder
• Når GC er færdig, rummer den første hylde derfor 5500 4.5Mb containere, mens den anden hylde rummer 600 containere (for hver container på den anden hylde er der cirka ni containere på den første hylde)
• I en enkelt serie af GC er ubalancen i containere mellem første og anden hylde reduceret med en faktor 10 - dette forventes at blive reduceret yderligere under efterfølgende kørsler af GC, hvilket betyder, at data rebalanceres naturligt på tværs af hylder over tid

Lokalitet reparation:

Når en fil skrives til en DDR, udføres følgende handlinger på højt niveau:

• Filen er opdelt i logiske bidder (kaldet segmenter) på 4-12 Kb i størrelse
• Hvert segment kontrolleres for at se, om det allerede findes på disken på det niveau, som filen skrives til
• Hvis segmentet allerede findes, er det dublerede data, og segmentet i den nyskrevne fil erstattes med en markør til eksisterende data på disken
• Hvis segmentet ikke eksisterer, er det unikke data og pakkes derfor i en ny 4,5 Mb container og skrives til disk

Alle filer har begrebet 'lokalitet', hvor sekventielle segmenterne af data, der henvises til af den fil, er på disken på DDR. Det er klart, at filer, der oplever høje deduplikeringsforhold (indeholder en stor mængde duplikatdata), sandsynligvis har dårligere lokalitet end en unik fil, da deres data, når de indtages, erstattes med henvisninger til eksisterende data, som kan være spredt over containere / diske inden for den tilsvarende niveauarkivenhed.

At opnå god læseydelse af data på en DDR kræver, at filen har god 'lokalitet' (dens data er relativt sekventielle på disken), således at DDFS read ahead-algoritmer kan fungere optimalt. Bemærk også, at DDFS antager, at den fil, der mest sandsynligt læses fra (til gendannelse eller replikering), er den seneste kopi af en given sikkerhedskopi. Som følge heraf udføres en proces kaldet 'lokalitetsreparation' for visse typer data (såsom virtuelle syntetiske stoffer) for at 'optimere' lokaliteten af nyskrevne fildata. Ved kørsel, lokalitetsreparation:

• Undersøg data, der refereres til af filen, og se efter sektioner, hvor data ikke er sekventielle på disken (viser dårlig placering)
• Læs disse ikke-sekventielle data fra disken, og skriv dem igen sekventielt (som dublerede data) til nyoprettede 4,5 Mb beholdere

Det forventes derefter, at den gamle (ikke-sekventielle) kopi af duplikatdata vil blive identificeret som 'død' under den næste kørsel af GC og fjernet fra systemet. Resultatet er følgende:

• På systemer, hvor der er en dataubalance, forventes det, at de fleste gamle ikke-sekventielle data findes på gamle, mere fuldt udfyldte kabinethylder
• Når disse data omskrives sekventielt som dublerede data, placeres de i nye 4,5 Mb containere, som er round robin på tværs af alle kabinetter på det tilsvarende niveau
• Som følge heraf findes størstedelen af 'døde' (gamle duplikatdata), der er oprettet ved lokalitetsreparation, på gamle, mere fuldt befolkede hylder
• Når GC kører, findes størstedelen af 'døde' data derefter på gamle, mere fuldt udfyldte hylder og fjernes (frigør plads på disse hylder) som beskrevet ovenfor

Konklusion

Takket være normal brug af GC-funktionalitet (locality repair and cleaning) kan en DDR derfor på transparent vis genbalancere data på tværs af hylder over tid. Dette sker uden yderligere input fra administratorer og betyder, at der ikke er behov for dedikerede funktioner til databalancering, som det nogle gange ses på andre storagesystemer. For at øge den hastighed, hvormed rebalanceringen finder sted, er det derfor nødvendigt enten:

• Forøg den hastighed, hvormed data "churns" på DDR
• Forøg mængden af data, der repareres lokalt på DDR

Hvis du vil diskutere en af disse muligheder yderligere, skal du kontakte den supportudbyder, du har indgået kontrakt med, og få oplyst oplysninger om denne artikel.