NetWorker: Ytelsesproblemer med vProxy-kloning av kapasitetsmodus mellom datadomener

• vProxy-kloningshastigheten har falt fra GB/sek til mer konvensjonelle og realistiske hastigheter.
• Nettverksbåndbredde er utelukket som årsak til flaskehals, og forblir godt under terskelen under kloning.
• Du finner meldinger i ddfs.Informasjonslogger som refererer til én eller flere *-flat.vmdk filer for berørte VM-disker som inneholder:
  • synthesized_vbytes 0 og slutter med recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr for basisfilen og slutter med feil Filhåndtaket er foreldet.
• Meldinger funnet i klonehandlingsloggene (når feilsøkingsnivået for kloner er 3 eller høyere) som refererer til én eller flere *-flat.vmdk-filer for de berørte VM-diskene som inneholder:
  • Syntetisk replikering kan ikke brukes for filen... bane.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy bruker virtuell syntetikk for å utnytte VMwares endrede blokksporings-API, noe som gir enorme gevinster for både sikkerhetskopiering og kloning. Dette krever aktivt vedlikehold av interne assosiasjoner av VM-filsettarvelighet på hvert Data Domain som er involvert. Hvis det oppstår problemer når du forbereder kloning ved hjelp av virtuell syntetikk, mislykkes NetWorker og Data Domain i stedet tilbake til å bruke standard replikeringsarbeidsflyt. Dette krever behandling av hele de virtuelle diskfilene, i stedet for bare de endrede blokkene, i motsetning til bare de endrede blokkene som tilbys av VMware API. Selv om lite data til slutt sendes på grunn av deduplisering, kan varigheten av kloningsjobber øke med multipler.
 
Årsaker som kan føre til feil i virtuell syntetisk sporing inkluderer:

• Ulike IP-adresser som løses i NetWorker for Data Domain-enheter for kilde eller destinasjon mellom jobber. Disse må forbli konsistente for virtuelle syntetiske mediers interne sporing
• Endre kilde- eller måldatadomene for vProxy-sikkerhetskopier eller kloner
• Flere kilde- eller målvolumer for vProxy-sikkerhetskopier eller kloner, noe som kan føre til samtidig kloning av flere lagringssett i kjeden
• Mer enn ett vProxy-saveset som krever kloning for en gitt virtuell maskin, noe som kan føre til uordnet kloning av lagringssett i kjeden
• VM-disker som går i lange perioder uten endringer (spesielt perioder som overskrider lagrede oppbevaringsperioder, for eksempel 35 dager uten endring der oppbevaring er 30 dager)
• Unnlatelse av å bruke egenskapen ChronologicalOrder Action

Siden det er mange mulige årsaker, bør du gå gjennom Data Domain og NetWorker-konfigurasjoner og sikre:

• ifgroups er konfigurert riktig for både kilde (sikkerhetskopiering) og destinasjon (klonemål) datadomener
• NetWorker-server, lagringsnoder og datadomener har alle vertsfiloppføringer som bruker riktig ifgroup IP-adresser per datadomene og pålitelig DNS for klienter (ved hjelp av NetWorker-klienten er vert for nødvendige filer).
• Enkelt datadomene for hvert sikkerhetskopierings- og kloneutvalg.

Aktiver ChronologicalOrder-funksjonen for vProxy-lagre settklonehandlinger, som kan være skjult i brukergrensesnittet:

• Hvis du bruker nsrclone -kommandoen, bruker du -O Bytt for å håndheve denne nye funksjonen når du bruker en lagringssettliste med flere lagringssett i en gitt kundekjede
• Bruk en av følgende to kommandoer for å aktivere policyen:

nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] <yes|no>

• I ledeteksten nsradmin:

. type nsr protection policy action; policy name: policy; workflow: workflow: name: action

update Chronological order: Yes

• Når dette er fullført, fjernes tidligere nevnte begrensninger for enkeltkilde- og målvolumer, samt intervaller for flere forekomster per VM-klient, og kan behandles på riktig måte.

VIKTIG: Noen betingelser kan være mulige for NetWorker og Data Domain å gjenopprette fra, der lagringssett klones i feil rekkefølge. Dette fører til at noen ikke kan bruke VSR til replikering, men når hele kjeden er gjenopprettet, kan VSR-kloningen fortsette uten problemer. Vanligvis kan kloning som ikke er i rekkefølge, kloning av flere volumer og flere lagringssett, ta igjen og gå tilbake til vanlig drift.
 
Hvis flere Data Domain IP-adresser allerede har blitt brukt eller endrer Data Domain-kilden eller destinasjonen helt, er den eneste måten å gå tilbake til regelmessig og konsekvent VSR-optimalisering å tvinge en ny fullstendig sikkerhetskopi av de berørte virtuelle maskinene til å tilbakestille den endrede blokksporingen og gjenopprette VSR-optimaliseringen. Dette bør tas i betraktning når de forrige trinnene er fullført, men Data Domain- og/eller NetWorker-logging og klonehastigheter indikerer at ytelsesproblemene vedvarer.