Avamar-Data Domain: Høy DD-utnyttelse på mål: Analyse og anbefalte fremgangsmåter

Summary: Kilde- og måldatadomenene forventes ikke å være nøyaktig like når det gjelder diskutnyttelse. Dette dokumentet beskriver de mulige årsakene til at måldatadomenet kan bruke høyere utnyttelse enn datadomenet for kilde. Det er viktig å merke seg at avviket i utnyttelse kan være et resultat av en kombinasjon av årsakene nedenfor. ...

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øyere utnyttelse enn Source Data Domain.

Cause

Fra Avamar-perspektivet:

Tilbakerulling
Hvis kilden Data Domain rulles tilbake, kan måldomenet inneholde ekstra dager med data, avhengig av tilbakerullingstiden. Dette avviket vil eksistere til de ekstra sikkerhetskopiene på destinasjonen utløper.

Eksempel: DD1 replikeres til DD2. Siden tilbakerullingen er 2 dager tilbake, ser vi at det er 3 sikkerhetskopier på kilden, men fem sikkerhetskopier replikert til destinasjon.

Delvise replikasjoner
Hvis en replikering ikke fullføres, lagres dataene som allerede er replikert, i minst sju dager og renses av Data Domain-rensingen.  Delvise replikeringer inneholder data og fingeravtrykk som gjør at den påfølgende replikeringen av data går raskere på nytt.
Overhead for delvis replikering kan være like høy som mengden replikerte data hvis replikeringene mislykkes rett før de er fullført.

Forskjell i oppbevaring
I Avamar-serverkonfigurasjonen er det mulig å angi at replikaene skal beholde replikaene på målserveren lenger enn en kilde. Dette vil føre til forskjeller i kapasitetsutnyttelsen.

Forskjeller
i Avamar-konfigurasjonEn sikkerhetskopi for sjekkpunkt på Avamar-serveren kan være betydelig stor. Hvis det bare konfigureres på mål-Avamar, øker det utnyttelsen av Data Domain på målet.

Fra Data Domain-perspektiv:

Fingeravtrykk.

Når data sendes til Data Domain under replikering, dedupliseres dedupliseringen. Et fingeravtrykk av dataene sendes først til destinasjonsdatadomenet for å sjekke om destinasjonen har dataene.

  • Hvis datadomenet returnerer at fingeravtrykket er der, trenger ikke dataene å sendes på nytt

  • Hvis Data Domain ikke returnerer at fingeravtrykket ikke blir funnet, betyr det at enten:

    • fingeravtrykket er ikke der

    • Destination Data Domain har fingeravtrykk, men vil at dataene skal sendes uansett for å forbedre den spesielle lokaliteten på Data Domain.

    • Data Domain er opptatt og ønsker ikke å fullføre hele søket.

Hvis dupliserte data sendes til Data Domain, dedupliseres dataene under opprydding ved å fjerne ekstra kopier av dataene.
Måldatadomenet utnyttes høyere, men variasjonen bør ikke være stor.

Metadata overhead.
Hver sikkerhetskopiert fil kommer med metadata for filinformasjon, og den inneholder også fingeravtrykk for hver.

Eksempel: For en fil på 1 TB er utnyttelseskostnaden 0.3% av filstørrelsen.

For en gjennomsnittlig 8 kB del av data er det 82B metadata.  Dette er omtrent 0,01 % overhead for post-comp-kapasitet.
Denne kostnaden øker også med Avamar-integrering siden Avamar kombinerer sikkerhetskopiene for å få en syntetisk fullstendig sikkerhetskopiering fra trinnvis hver gang sikkerhetskopieringen fullføres.
Vi observerer også at metadatakostnadene øker når sikkerhetskopier hoppes over, eller dataene replikeres i feil rekkefølge.
De eneste sikkerhetskopiene som ikke oppretter denne overheaden, er VM-sikkerhetskopier. Metadatakostnaden minimeres.

Eksempel: Når sikkerhetskopien replikeres i feil rekkefølge, oppretter den L0-sikkerhetskopi på målet, som har en mye større metadataoverhead enn Inc.  La oss si at vi har 5 dagers sikkerhetskopiering.

Replikering fra eldste til nyeste:

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

Nyest til eldst:

Alle replikasjoner vil være L0 fordi n-1 dag ikke er tilgjengelig for å basere Inc på.
5xL0

Replikering hopper over en sikkerhetskopi:

La oss si at backupen på dag 3 var dyktig.  Dag 1 er L0, dag 2 er Inc, så vil Day4 igjen være L0.
L0+Inc+L0+Inc


Filsporing
Data Domain må vite hvordan de skal bygge hver fil fra de dedupliserte segmentene. Hvis Data Domain ikke har denne informasjonen, må de gjenoppbygge den og opprette fingeravtrykkskjeden på nytt. Dette kan føre til en betydelig økning i kapasiteten.
Det finnes to scenarier som kan føre til en betydelig økning i kapasiteten på måldatadomenet:


1. Filsporing går tapt:

Eksempel: Hvis destination Data Domain er angitt i DNS med flere IP-adresser og IP-adressene distribueres i round robin, vil kildedatadomenet koble til forskjellige IP-adresser hver gang. Kopien av data som ble sendt i går ville ikke bli gjenkjent og mer data ble sendt, noe som også øker metadatakostnaden.

2. Filsporing er ikke aktivert:
Eksempel: SFS_BFT_ENABLED må settes til sann for å sikre at Base File Tracking kan syntetisere sikkerhetskopier på målsystemet. Dette gjør at innkommende replikeringer kan optimaliseres for lagring. Hvis SFS_BFT_ENABLED er satt til usann, lagres dataene på den endelige sikkerhetskopiplasseringen på DD er lik de innkommende dataene før kompatibelt.

Dette problemet kan oppstå når SFS_BFT_ENABLED er igjen som falsk etter at tilbakerullingen av Avamar-serveren er fullført.

Dette kan resultere i et svært stort avvik.  Plassen frigjøres igjen når sikkerhetskopiene utløper.

Innebygd deduplisering
Data Domain ber om dupliserte data på opptil 6 % av en logisk størrelse på dataene for å optimalisere den innebygde dupliseringen.

Forskjell i deduplisering og komprimering.
Data Domains gjør sin egen deduplisering og komprimering av data på sin lokale lagring uavhengig, og avhengig av hvordan destinasjonsdataene lagres, vil dette ikke være likt, noe som forårsaker forskjell i utnyttelse.

Rengjøring
av Data DomainHvis datadomenene for kilde og destinasjon kjører opprydding på forskjellige dager, eller hvis et av datadomenene kjører det oftere eller lenger, vil det være avvik i kapasitetsutnyttelsen.

Resolution

Beste framgangsmåte:

Siden det vil være avvik i bruken mellom de to Data Domain-systemene, kilde og destinasjon, er det noen gode fremgangsmåter som kan bidra til å minimere forskjellen:

  1. Minimer muligheten for tilbakestilling ved å delta på hfscheck-feil og maskinvarefeil så snart de oppstår.

  2. Kontroller at replikeringene er fullført. Hvis det er et pågående problem med at replikeringer er fullført, kan du kontakte Dell Technologies' kundestøtte for å gjennomgå konfigurasjonen.

  3. Hvis du trenger å beholde de to datadomenene ved lik utnyttelse, må du beholde den samme oppbevaringen av kilde- og målkopiene av sikkerhetskopiene, og sørge for at sikkerhetskopien for sjekkpunktet er angitt likt på begge Avamar-serverne.

  4. Kontroller at replikeringene alltid er eldst til nyeste, og at ingen sikkerhetskopier hoppes over.

  5. Hvis Data Domain er konfigurert med flere IP-adresser, må du sørge for at IP-adressene ikke distribueres på round-robin-måten.

  6.  Få både Data Domain-systemer, kilde og destinasjon, til å kjøre rengjøring på samme dag og klokkeslett.

  7. Har SFS_BFT_ENABLED satt til true.  Dette må aktiveres av teknisk støtte (ta opp en SR &referer 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.