Data Domain-operativsystemet støtter ikke proaktiv rebalansering av data på tvers av lagring etter utvidelse av kapasiteten til Data Domain-filsystemet

Som med mange lagringsarrayer kan kapasiteten til de fleste modeller av Data Domain Restorer (DDR) økes ved å legge til eksterne lagringshyller (ES30, DS60) til systemet og deretter utvide Data Domain File System (DDFS) til disse kabinetthyllene. Når dette utføres:

• Nye kabinetter: hyller er fysisk festet (kablet slått på)
• Data Domain Operating System (DDOS) skanner lagring på nytt for å identifisere eksistensen av nye kabinetter hyller
• Disse nye kabinetthyllene legges deretter til et lagringsnivå i DDR (det aktive nivået eller en bestemt arkivenhet)
• Dette nivået kan deretter utvides på nett uten behov for nedetid for DDFS
• Alle nye data som skrives til dette lagringsnivået, skrives på tvers av eksisterende og nye hyller
• Data på eksisterende hyller blir imidlertid ikke rebalansert på tvers av nye kapslingshyller

For å forklare dette nærmere:

• Innenfor DDOS er enheten for datalagring en 4,5 Mb "beholder"
• Etter hvert som de opprettes, skrives 4,5 Mb beholdere over alle kapslingshyller i den tilsvarende lagarkivenheten på en rund robin-måte
• Når flere kabinetter hyller legges til en lagarkivenhet, begynner DDFS å skrive nye 4,5 Mb beholdere til disse kabinettene i tillegg til eksisterende kabinetter (de nye kabinettene er inkludert når round robin-beholderen skriver)
• DDOS gjør imidlertid ikke noe spesifikt forsøk (eller tilbyr noen spesifikk funksjonalitet) for å migrere eksisterende containere i nivået fra eksisterende til nye hyllekabinetter

Dette betyr at tillegg av hyllekabinetter kan etterlate data "ubalansert" på tvers av tilknyttet lagring. Eksempel:

• En DDR har i utgangspunktet ett enkelt kabinett i sitt aktive nivå som er 90 % fullt
• Et ekstra kabinett legges til på det aktive nivået, og DDFS utvides til dette kabinettet
• Nyopprettede beholdere på 4,5 Mb skrives nå rundt på tvers av eksisterende og nye kabinetter
• Dette etterlater det eksisterende kabinettet lite ledig plass, mens det nylig lagt kabinettet er nesten tomt

I dette scenariet lar mange lagringsarrayer en administrator balansere data på tvers av tilkoblede kabinetter, proaktivt migrere noen data fra eksisterende kabinetter til nylig tilføyde kabinetter for å sikre at den brukte kapasiteten til alle kabinetter er omtrent lik). Vær imidlertid oppmerksom på at DDOS IKKE tilbyr denne funksjonaliteten, og på grunn av utformingen av DDFS er det ikke nødvendig da rebalansering av data skjer naturlig over tid.

Rebalansering av data utføres av to operasjoner:

• Rengjøring av søppel
• Lokal reparasjon

Hver av disse operasjonene og hvordan de forårsaker automatisk rebalansering av data er nærmere omtalt nedenfor.

Rengjøring av

søppelRengjøring av søppelhenting (GC) er en planlagt aktivitet som kjøres regelmessig på en DDR (som standard én gang i uken mot det aktive nivået og, forutsatt at plassgjenvinning er aktivert, når det kreves mot arkivenheter). Når den kjører den:

• Identifiserer hvilke fysiske data i nivåarkivenheten som er aktive (brukes av én eller flere filer i filsystemet eller objekter som øyeblikksbilder) eller døde (uten referanser av noe objekt, og dermed overflødige for systemet)
• Bestemmer beholderne på 4,5 Mb som inneholder majoriteten av de «døde» dataene i nivåarkivenheten
• Leser disse 4,5 Mb beholdere og trekker ut eventuelle "live" data de inneholder - dette er deretter "kopiert fremover" til nyopprettede 4,5 MB beholdere som er skrevet over alle hyllene i tier arkiv enheten
• Sletter de gamle 4,5 Mb-beholderne og fjerner dermed de døde dataene de inneholder, og frigjør underliggende plass på disken for gjenbruk

Når GC kjører på et system med noen form for dataubalanse, forventes det at de fleste gamle data (og derfor de fleste døde data) vil bli holdt på eldre hyller vedlegg innenfor tier arkivenheten. Som et resultat er de fleste beholderne som leses, kopieres fremover fra og slettes, på eldre hyllevedlegg. De nyopprettede beholderne er imidlertid skrevet i et rundt robin-format mellom alle hyllene i tieren. Som et resultat er det meste av plassen frigjort av GC på eldre hyller, mens nykonsumert plass er på tvers av alle hyller.

Som et enkelt eksempel:

• Den aktive tier av en DDR inneholder to hyller - den første hyllen inneholder 10000 4,5 MB containere, mens den andre hyllen inneholder 100 4,5 MB containere (for hver beholder på andre hylle er det 100 containere på første hylle)
• GC kjører og kopierer videresender data fra 5000 containere på første hylle
• Sanntidsdata i disse 5000 beholderne fører til at 1000 nye 4,5 Mb beholdere opprettes
• Disse 1000 nye 4,5 Mb beholderne er skrevet over begge hyllene
• Når GC er ferdig, inneholder den første hyllen derfor 5500 4,5 MB containere, mens den andre hyllen inneholder 600 containere (for hver container på den andre hyllen er det omtrent ni containere på første hylle)
• I en enkelt kjøring av GC har ubalansen i containere mellom første og andre hylle blitt redusert med en faktor på 10 - dette forventes å bli redusert ytterligere under påfølgende kjøringer av GC, noe som betyr at data rebalanseres naturlig over hyller over tid

Lokal reparasjon:

Når en fil skrives til en DDR, utføres følgende operasjoner på høyt nivå:

• Filen er delt inn i logiske biter (kalt segmenter) på 4-12 Kb i størrelse
• Hvert segment kontrolleres for å se om det allerede finnes på disken på nivået filen skrives til
• Hvis segmentet allerede finnes, er det like data, og segmentet i den nylig skrevne filen erstattes med en peker til eksisterende data på disken
• Hvis segmentet ikke finnes, er det unike data og blir derfor pakket inn i en ny beholder på 4,5 Mb og skrevet til disken

Alle filer har begrepet "lokalitet", hvor sekvensielle segmentene av data referert av den filen er på disken på DDR. Åpenbart filer som opplever høye de-duplisering forhold (inneholder en stor mengde dupliserte data) er sannsynlig å ha verre lokalitet enn en unik fil som når inntatt sine data er erstattet med pekere til eksisterende data som kan være spredt over beholdere / disker innenfor tilsvarende tier arkiv enhet.

Å oppnå god leseytelse av data på en DDR krever at filen har god "lokalitet" (dataene er relativt sekvensielle på disken) slik at DDFS-avlesningsalgoritmer kan fungere optimalt. Vær også oppmerksom på at DDFS antar at filen som mest sannsynlig leses fra (for gjenoppretting eller replikering), er den nyeste kopien av en gitt sikkerhetskopi. Som et resultat, for visse typer data (for eksempel virtuell syntetikk), utføres en prosess som kalles 'lokalitetsreparasjon' for å 'optimalisere' lokaliteten til nyskrevne fildata. Ved kjøring, reparasjon av lokalitet:

• Undersøk data referert av filen på jakt etter seksjoner der data ikke er sekvensielle på disken (viser dårlig lokalitet)
• Les disse ikke-sekvensielle dataene fra disken, og skriv dem deretter på nytt (som dupliserte data) til nyopprettede beholdere på 4,5 Mb

Det forventes da at den gamle (ikke-sekvensielle) kopien av dupliserte data vil bli identifisert som "død" under neste kjøring av GC og fjernet fra systemet. Resultat:

• På systemer hvor det er en dataubalanse at det forventes at de fleste gamle ikke-sekvensielle data finnes på gamle, mer fullt befolkede kapslingshyller
• Når disse dataene skrives om sekvensielt som dupliserte data, plasseres de i nye 4,5 Mb-beholdere som er runde robin på tvers av alle kabinetter i det tilsvarende nivået
• Som et resultat eksisterer flertallet av "døde" (gamle dupliserte data) opprettet av lokalitetsreparasjon på gamle, mer fullt befolkede hyller
• Når GC kjører, blir flertallet av "døde" data funnet på gamle mer fullt befolkede hyller og fjernet (frigjør plass på disse hyllene) som beskrevet ovenfor

Konklusjon

Som et resultat, gjennom normal bruk av lokal reparasjon og rengjøringsfunksjonalitet (GC), kan en DDR transparent balansere data på tvers av hyller over tid. Dette skjer uten ekstra innspill fra administratorer og betyr at det ikke er behov for dedikert funksjonalitet for databalanseringsoperasjoner, slik man noen ganger ser på andre lagringsarrayer. For å øke hastigheten på rebalanseringen er det derfor nødvendig å enten:

• Øk frafallshastigheten for data på DDR
• Øk mengden data som repareres lokalt på DDR

Hvis du vil diskutere ett av disse alternativene ytterligere, kan du kontakte den avtalte støtteleverandøren og oppgi informasjon om denne artikkelen.