Avamar-Data Domain: Høj DD-udnyttelse på mål: Analyse og bedste praksis

Summary: Kilde- og måldatadomænerne forventes ikke at være nøjagtigt ens i diskudnyttelse. I dette dokument beskrives de mulige årsager til, at Data Domain-destinationsdomænet kan vise højere udnyttelse end kildedomænet. Det er vigtigt at bemærke, at uoverensstemmelsen i udnyttelsen kan være et resultat af en kombination af nedenstående årsager. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

Target Data Domain viser højere udnyttelse end Source Data Domain.

Cause

Fra Avamars perspektiv:

Rollback
I tilfælde af en annullering af kildedomænet kan destinationsdomænet for Data Domain tilbageholde ekstra dage med data afhængigt af gendannelsestiden. Denne uoverensstemmelse vil eksistere, indtil de ekstra sikkerhedskopier på destinationen udløber.

Eksempel: DD1 replikeres til DD2. Da gendannelsen er 2 dage tilbage, ser vi, at der er 3 sikkerhedskopier på kilden, men fem sikkerhedskopier replikeret til destinationen.

Delvise replikeringer
Hvis en replikering ikke fuldføres, gemmes de data, der allerede er replikeret, i mindst syv dage og renses af Data Domain-rensningen.  Delvise replikeringer indeholder data og fingeraftryk, der gør det muligt at køre hurtigere efterfølgende replikering af data igen.
De delvise replikeringsomkostninger kan være lige så høje som mængden af replikerede data, hvis replikeringer mislykkes, lige før de er fuldført.

Forskel i fastholdelse
I Avamar-serverkonfiguration er det muligt at indstille til at beholde replikaerne på destinationsserveren i længere tid end en kilde. Dette vil medføre forskelle i kapacitetsudnyttelsen.

Avamar – Konfigurationsforskelle
En sikkerhedskopiering af kontrolpunkter på Avamar-serveren kan være betydeligt stor. Hvis den kun er konfigureret på destinationen Avamar, vil det øge udnyttelsen af Data Domain på destinationen.

Fra Data Domain-perspektiv:

Fingeraftryk.

Når data sendes til Data Domain under replikering, fjernes dublæsningen. Der sendes først et fingeraftryk af dataene til destinationsdatadomænet for at kontrollere, om destinationen har dataene.

  • Hvis Data Domain returnerer, at fingeraftrykket er der, behøver dataene ikke at blive sendt igen

  • Hvis Data Domain ikke returnerer, at fingeraftrykket ikke er fundet, betyder det, at enten:

    • fingeraftrykket er der ikke

    • Destination Data Domain har fingeraftryk, men ønsker, at dataene sendes alligevel for at forbedre den særlige lokalitet på Data Domain.

    • Data Domain er optaget og ønsker ikke at fuldføre hele søgningen.

Hvis der sendes dublerede data til Data Domain, deduplikeres dataene under rensningen ved at fjerne ekstra kopier af dataene.
Destinationsdatadomænet vil have højere udnyttelse, men variationen bør ikke være stor.

Metadata overhead.
Hver sikkerhedskopieret fil leveres med sine filinformationsmetadata, og den indeholder også fingeraftryk for hver.

Eksempel: For en fil på 1 TB er udnyttelsesomkostningerne 0,3 % af filstørrelsen.

For en gennemsnitlig 8kB del af data er der 82B metadata.  Dette er ca. 0,01% overhead for post-comp kapacitet.
Disse faste omkostninger øges yderligere med Avamar-integrationen, da Avamar kombinerer sikkerhedskopieringerne for at få en syntetisk fuld sikkerhedskopiering fra trinvis, hver gang sikkerhedskopieringen fuldføres.
Vi bemærker også, at omkostningerne til metadata øges, når sikkerhedskopier, der springes over, bliver sprunget over, eller dataene replikeres ude af drift.
De eneste sikkerhedskopier, der ikke opretter disse omkostninger, er VM-sikkerhedskopieringer. Omkostningerne til metadata minimeres.

Eksempel: Når sikkerhedskopien replikeres ude af drift, opretter den L0-sikkerhedskopi på målet, som har en meget større metadataomkostning end Inc.  Lad os sige, at vi har 5 dages sikkerhedskopier.

Replikering ældste til nyeste:

Første replikering vil være L0, derefter vil alle efterfølgende være Inc.
1 x L0 + 4 x Inc

Replikering nyeste til ældste:

Alle replikeringer vil være L0, fordi n-1 dag ikke er tilgængelig at basere Inc på.
5xL0

Replikering springer en sikkerhedskopiering over:

Lad os sige, at sikkerhedskopien på dag 3 var dygtig.  Dag 1 er L0, dag 2 er Inc, så vil dag 4 igen være L0.
L0+Inc+L0+Inc


Filsporing
Data Domain skal vide, hvordan man opbygger hver fil fra de deduplikerede bidder. Hvis Data Domain ikke har disse oplysninger, skal de genopbygge dem og genskabe fingeraftrykskæden. Dette kan medføre en betydelig kapacitetsforøgelse.
Der er to scenarier, der kan medføre en betydelig forøgelse af kapaciteten på destinationsdatadomænet:


1. Filsporing går tabt:

Eksempel: Hvis destinationsdatadomænet er angivet i DNS med flere IP-adresser, og IP'erne distribueres i round robin, opretter kildedomænet forbindelse til forskellige IP'er hver gang. Kopien af data, der blev sendt i går, ville ikke blive genkendt, og flere data sendes, hvilket også øger metadataomkostningerne.

2. Filsporing er ikke aktiveret:
Eksempel: Den SFS_BFT_ENABLED skal indstilles til true for at sikre, at Base File Tracking kan syntetisere sikkerhedskopier på destinationssystemet. Dette gør det muligt at optimere indgående replikeringer til lagring. Hvis SFS_BFT_ENABLED er indstillet til false, gemmes dataene på den endelige sikkerhedskopieringsplacering på DD er lig med de indgående data før comp.

Dette problem kan opstå, når SFS_BFT_ENABLED efterlades som falsk, efter at Avamar-servergendannelsen er fuldført.

Dette kan resultere i en meget stor uoverensstemmelse.  Pladsen genvindes, når sikkerhedskopierne udløber.

Integreret deduplikering
Data Domain beder om duplikerede data på op til 6 % af den logiske størrelse af dataene for at optimere deres indbyggede deduplikering.

Forskel i deduplikering og komprimering.
Data Domains udfører deres egen deduplikering og komprimering af data på deres lokale lager uafhængigt, og afhængigt af hvordan destinationsdataene gemmes, vil dette ikke være det samme, hvilket forårsager forskel i udnyttelsen.

Data Domain-rensning
Hvis kilde- og destinationsdatadomænerne kører rensning på forskellige dage, eller hvis et af datadomænerne kører det oftere eller længere, vil der være uoverensstemmelse i den udnyttede kapacitet.

Resolution

Bedste fremgangsmåde:

Da der vil være uoverensstemmelser i udnyttelsen mellem de to Data Domain-systemer, kilde og destination, er der nogle bedste fremgangsmåder, der kan hjælpe med at minimere forskellen:

  1. Minimer muligheden for tilbagekaldelse ved at tage hånd om hfscheck-fejl og hardwarefejl, så snart de opstår.

  2. Sørg for, at replikeringer fuldføres korrekt. Hvis der er et vedvarende problem med at fuldføre replikeringer, skal du kontakte Dell Technologies support for at gennemgå konfigurationen.

  3. Hvis du har brug for at beholde de to datadomæner med samme udnyttelse, skal du beholde den samme opbevaring på kilde- og målkopier af sikkerhedskopierne og sikre, at sikkerhedskopieringen af kontrolpunktet er indstillet ens på begge Avamar-servere.

  4. Sørg for, at replikeringer altid er ældste til nyeste, og at ingen sikkerhedskopieringer springes over.

  5. Hvis Data Domain er konfigureret med flere IP-adresser, skal du sørge for, at IP'erne ikke distribueres på round-robin-måde.

  6.  Få både Data Domain-systemer, kilde og destination, til at køre rensning på samme dag og tidspunkt.

  7. Har SFS_BFT_ENABLED indstillet til sand.  Dette skal aktiveres af teknisk support (opret en SR, & henvis til denne KB# - 182755)

Affected Products

Avamar Server
Article Properties
Article Number: 000182755
Article Type: Solution
Last Modified: 20 Sept 2024
Version:  6
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.