NetWorker: Problemer med ydeevne i kapacitetstilstand vProxy-klonjob mellem Data Domains

• vProxy-kloningshastigheden er faldet fra GB'er/sek. til mere konventionelle og realistiske hastigheder.
• Netværksbåndbredde er udelukket som årsag til flaskehals og forbliver langt under tærsklen under kloning.
• Meddelelser findes i ddfs.Infologfiler, der henviser til en eller flere *-flat.vmdk filer til de berørte VM-diske (virtuel maskine), der indeholder:
  • synthesized_vbytes 0 og slutter med recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr for basisfilen og slutter med fejlen Filhåndteringen er forældet.
• Meddelelser, der findes i klonhandlingslogfilerne (når klonedefejlretningsniveauet er 3 eller højere), og som henviser til en eller flere *-flat.vmdk-filer til den berørte VM's diske, der indeholder:
  • Syntetisk replikering kan ikke bruges til filen... sti.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy bruger virtuel syntetisk teknologi til at udnytte VMwares ændrede bloksporings-API, hvilket giver enorme gevinster til både sikkerhedskopierings- og kloningsoperationer. Dette kræver aktiv vedligeholdelse af interne tilknytninger af VM-filsætarvelighed på hvert involveret Data Domain. Hvis der opstår problemer under forberedelse til kloning ved hjælp af virtuel syntetisk metode, undlader NetWorker og Data Domain i stedet at bruge standardreplikeringsarbejdsprocessen. Dette kræver behandling af hele de virtuelle diskfiler i stedet for kun de ændrede blokke i modsætning til kun de ændrede blokke, der leveres af VMware API. Selvom der i sidste ende kun sendes få data på grund af deduplikering, kan varigheden af kloningsjobbet øges med multipla.
 
Årsager, der kan føre til fejl i virtuel syntetisk sporing, omfatter:

• Forskellige IP-adresser, der fortolkes i NetWorker for Data Domain-enheder på kilden eller destinationen mellem job. Disse skal forblive konsistente for virtuel syntetisk intern sporing
• Ændring af kilde- eller destinationsdatadomæne til vProxy-sikkerhedskopier eller -kloner
• Flere kilde- eller destinationsenheder til vProxy-sikkerhedskopier eller -kloner, hvilket kan føre til samtidig kloning af flere savesets i kæden
• Mere end ét vProxy-saveset, der kræver kloning for en given VM, hvilket kan føre til uordnet kloning af savesets i kæden
• VM-diske, der kan bruges i lange perioder uden ændringer (især perioder, der overskrider saveset-opbevaringsperioder, f.eks. 35 dage uden ændringer, hvor opbevaringen er 30 dage)
• Manglende brug af egenskaben ChronologicalOrder Action

Da der er mange potentielle årsager, bør du gennemse konfigurationerne Data Domain og NetWorker og sikre:

• ifgroups er konfigureret korrekt for både kilde- (sikkerhedskopiering) og destination (klonmål) Data Domains
• NetWorker-server, storagenoder og Data Domains har alle værtsfilposter ved hjælp af de relevante ifgroup IP-adresser pr. Data Domain og pålidelig DNS til klienter (ved hjælp af NetWorker-klienten hoster filer efter behov).
• Enkelt Data Domain for hver sikkerhedskopierings- og klonpulje.

Aktiver funktionen ChronologicalOrder til klonede handlinger for vProxy-gemte sæt, som kan være skjult i brugergrænsefladen:

• Hvis du bruger nsrclone kommando, skal du bruge -O Skift for at gennemtvinge denne nye funktion, når du bruger en liste over gemte sæt med flere lagringssæt i en given klients kæde
• Hvis du vil aktivere i politik, skal du bruge en af følgende to kommandoer:

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

• I nsradmin-prompten:

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

update Chronological order: Yes

• Når dette er fuldført, ophæves de tidligere nævnte begrænsninger på enkeltkilde- og destinationsdiskenheder samt trinvise tilføjelser til flere forekomster pr. VM-klient og kan behandles korrekt.

VIGTIGT: Nogle forhold kan være mulige for NetWorker og Data Domain at gendanne fra, hvor gemte sæt klones ude af drift. Dette medfører, at nogle ikke kan bruge VSR til replikering, men når hele kæden er gendannet, kan VSR-kloning fortsætte uden problemer. Generelt kan kloning uden for rækkefølge, kloning med flere volumener og flere gemte sæt indhente og vende tilbage til normal drift.
 
Hvis flere Data Domain IP-adresser allerede er blevet brugt eller helt ændrer Data Domain-kilden eller -destinationen, er den eneste måde at vende tilbage til regelmæssig og ensartet VSR-optimering på at gennemtvinge en ny fuld sikkerhedskopiering af de berørte VM'er for at nulstille den ændrede bloksporing og gendanne VSR-optimering. Dette bør overvejes, når de foregående trin er fuldført, men Data Domain- og/eller NetWorker-logføring og kloningshastigheder indikerer, at der stadig er problemer med ydeevnen.