NetWorker: Problemer med ydeevnen af kapacitetstilstanden i vProxy-kloningsjobbet mellem datadomæner

• vProxy-kloningshastigheden er faldet fra GB'er/sek. til mere traditionelle og realistiske hastigheder.
• Netværksbåndbredden kan udelukkes som årsag til flaskehalse, der forbliver langt under grænsen under kloning.
• Meddelelserne findes i ddf'erne.info-logfiler, der henviser til en eller flere *-flat.vmdk-filer for de berørte VM'ers diske, der indeholder:
  • synthesized_vbytes 0 og slutter med recipe_repl FALSK
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr for basisfil og slutter med fejl. Filhåndtering er forældet.
• Meddelelser, der findes i logfilerne for kloningshandlinger (når fejlfindingsniveauet for klon er 3 eller højere), der henviser til en eller flere *-flat.vmdk-filer for de berørte VM'er, der indeholder:
  • Replikering uden replikering kan ikke bruges til filen ... sti.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy bruger virtuelle teknikere til at udnytte VMwares ændrede bloksporings-API, hvilket giver yderligere fordele til både sikkerhedskopiering og kloning. Dette kræver aktiv vedligeholdelse af interne tilknytninger af VM-filsæt-enhed på hvert berørt Data Domain. Hvis der opstår problemer under forberedelse af kloning ved hjælp af virtuelle hovedtelefoner, vil NetWorker og Data Domain i stedet ikke vende tilbage til at bruge standardreplikeringsarbejdsgangen. 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 - og selvom små data i sidste ende sendes på grund af deduplikering, kan kloning af jobvarigheden øges med flere gange.
 
Årsager, der kan føre til fejl på virtuel sporing, omfatter:

• Forskellige IP-adresser, der løses af NetWorker for kilde- eller destinations-Data Domain-enheder mellem job - disse skal være konsistente for virtuelle enheders interne sporing
• Ændring af kilde- eller destinations-Data Domain for vProxy-sikkerhedskopieringer eller -kloner
• Flere kilde- eller destinationsdiskenheder til vProxy-sikkerhedskopieringer eller kloner, hvilket kan føre til samtidig kloning af flere lagringssæt i kæden
• Mere end ét vProxy saveset, der kræver kloning for en given VM, hvilket kan føre til kloning af lagringssæt i kæden
• VM-diske, der varer i lange perioder uden ændringer (især perioder, der overskrider opbevaringsperioder for lagring, f.eks. 35 dage uden ændring, hvor opbevaring er 30 dage)
• Manglende brug af kronologisk ordrehandlingsegenskab, hvis du bruger NetWorker 19.6 og derover

Da der er adskillige potentielle årsager, skal du gennemgå datadomæne- og NetWorker-konfigurationerne og sikre:

• ifgroups er konfigureret korrekt for både kilde (sikkerhedskopiering) og destination (kloning af mål) datadomæner
• NetWorker-server, lagernoder og Data Domains har alle værter filposter ved hjælp af de relevante ifgroup IP'er pr. Data Domain og pålidelig DNS til klienter (ved brug af NetWorker-klientværtsfiler efter behov).
• Enkelt Data Domain for hver sikkerhedskopierings- og klonpulje.

Ved brug af NetWorker 19.5 eller derunder:

• Sikre, at kloningsopgaver udføres serielt og i rækkefølgen af sikkerhedskopieringer; Bemærk, at dette ikke kan styres, når flere kloner for en given VM er på samme jobliste (kloningshandling eller nsrclone saveset-filliste).
• Sørg for en enkelt sikkerhedskopierings- og kloningsenhed pr. pulje for at undgå samtidig kloning, når der er flere diskenheder tilgængelige for kilden.

Fra og med NetWorker 19.6 skal du altid aktivere funktionenChronologicalOrder for vProxy saveset clone actions, som kan være skjult i brugergrænsefladen:

• Hvis du bruger nsrclone-kommandoen, skal du bruge -O-switchen til at gennemtvinge denne nye funktion, når du bruger en saveset-liste med flere lagringssæt i en given klientkæde
• For at aktivere politikken skal du bruge en af følgende to kommandoer:

  • nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] 

  • I nsradmin-prompt:

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

    • update Chronological order: Yes

      
       
• Når dette er fuldført, løftes tidligere nævnte begrænsninger på enkeltkilde- og destinationsdiskenheder samt trinvise multiforekomster pr. VM-klient og kan behandles korrekt.

VIGTIGT: Nogle betingelser kan være mulige, for at NetWorker og Data Domain kan gendannes fra, hvor gemninger er klonet i rækkefølge. 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 out-of-order kloning, multi-volume og multispare-kloning følge med og vende tilbage til normal drift.
 
Hvis flere Data Domain IP-adresser allerede er blevet brugt eller ændret Data Domain-kilde eller -destination helt, er den eneste måde at vende tilbage til regelmæssig og ensartet VSR-optimering at gennemtvinge en ny komplet sikkerhedskopi af de berørte VM'er for at nulstille den ændrede bloksporing og gendanne VSR-optimering. Dette bør tages i betragtning, når de foregående trin er udført, men Data Domain- og/eller NetWorker-logføring samt kloningshastigheder angiver, at der stadig er problemer med ydeevnen.