NetWorker: Kapacitetsläge vProxy klonar problem med jobbprestanda mellan Data Domains

• vProxy-kloningshastigheten har sjunkit från GB:er/s till mer konventionella och realistiska hastigheter.
• Nätverksbandbredden är utesluten som en orsak till flaskhals och ligger fortfarande långt under tröskelvärdet under kloningen.
• Meddelanden finns i ddfs.informationsloggar som hänvisar till en eller flera *-flat.vmdk-filer för den berörda virtuella datorns diskar som innehåller:
  • synthesized_vbytes 0 och slutar med recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr för basfil och slutar med felfilreferensen är inaktuell.
• Meddelanden som finns i klonens åtgärdsloggar (när klonens felsökningsnivå är 3 eller högre) hänvisar till en eller flera *-flat.vmdk-filer för den berörda virtuella datorns diskar som innehåller:
  • Syntetisk replikering kan inte användas för filen ... sökväg .../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy använder virtuella syntetmaterial för att utnyttja VMwares ändrade API för blockspårning, vilket ger betydande vinster vid både säkerhetskopiering och kloning. Detta kräver aktivt underhåll av interna associationer av VM-filuppsättningar på varje berörd Data Domain. Om problem uppstår när du förbereder kloning med hjälp av virtuella syntetiseringar återgår NetWorker och Data Domain istället till att använda det förvalda replikeringsarbetsflödet. Detta kräver bearbetning av hela de virtuella diskfilerna, snarare än bara de ändrade blocken, i stället för endast de ändrade blocken som tillhandahålls av VMware API: t och även om få data slutligen skickas på grund av deduplicering kan kloningens varaktighet öka med flera.
 
Orsaker som kan leda till fel i virtuell syntetisk spårning är bland annat:

• Olika IP-adresser som löses av NetWorker för datadomänens käll- eller målenheter mellan jobben. Dessa måste förbli konsekventa för virtuell syntetisk intern spårning
• Ändra käll- eller mål-Data Domain för vProxy-säkerhetskopiering eller -kloner
• Flera käll- eller målvolymer för vProxy-säkerhetskopieringar eller -kloner, vilket kan leda till samtidig kloning av flera sparuppsättningar i kedjan
• Mer än en vProxy-sparuppsättning som kräver kloning för en viss virtuell dator, vilket kan leda till oordnad kloning av sparuppsättningar i kedjan
• VM-diskar som används under långa perioder utan ändringar (särskilt perioder som överskrider sparuppsättningslagringsperioder, t.ex. 35 dagar utan förändring där kvarhållandet är 30 dagar)
• Det går inte att använda den chronologiskorderåtgärdsegenskap om du använder NetWorker 19.6 och senare

Eftersom det finns många potentiella orsaker kan du granska Data Domain- och NetWorker-konfigurationerna och säkerställa:

• ifgroups är korrekt konfigurerade för både käll- (säkerhetskopiering) och mål (klonmål) Data Domains
• NetWorker-servrar, lagringsnoder och Data Domains har alla värdars filposter med lämpliga IP-adresser för ifgroup per Data Domain och tillförlitlig DNS för klienter (med netWorker-klientvärdfiler vid behov).
• En Data Domain för varje säkerhetskopierings- och klonpool.

När du använder NetWorker 19.5 eller tidigare:

• Se till att kloningsjobb utförs seriellt och i ordningsföljd för säkerhetskopior; Observera att detta inte kan kontrolleras när flera kloner för en viss virtuell dator finns i samma jobblista (klona action- eller nsrclone-fillistan för saveset).
• Säkerställ en enda säkerhetskopierings- och kloningsvolym per pool för att undvika samtidig kloning när flera volymer är tillgängliga för källan.

Från och med NetWorker 19.6 bör du alltid aktivera chronologicalOrder-funktionen för kloning av vProxy-sparuppsättningar, som kan döljas i användargränssnittet:

• Om du använder kommandot nsrclone använder du -O-switchen för att verkställa den här nya funktionen när du använder en sparuppsättningslista med flera sparuppsättningar i en viss klientkedja
• Använd något av följande två kommandon för att aktivera policyn:

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

  • I nsradmin-kommandotolken:

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

    • update Chronological order: Yes

      
       
• När detta är klart lyfts tidigare nämnda begränsningar för volymer med en källa och mål, samt inkrementella flera instanser per VM-klient, och kan bearbetas korrekt.

VIKTIGT! Vissa villkor kan vara möjliga för NetWorker och Data Domain att återställa från, där sparuppsättningar klonas i fel ordning. Det leder till att vissa inte kan använda VSR för replikering, men när hela kedjan har återställts kan VSR-kloning fortsätta utan problem. Kloning utan beställning, kloning i flera volymer och flera sparuppsättningar kan komma ikapp och återgå till normal drift.
 
Om flera Data Domain IP-adresser redan har använts eller ändrat Data Domains källa eller mål helt och hållet är det enda sättet att återgå till regelbunden och konsekvent VSR-optimering att tvinga fram en ny fullständig säkerhetskopiering av de berörda virtuella datorerna för att återställa den ändrade blockspårningen och återställa VSR-optimeringen. Detta bör övervägas när föregående steg har slutförts, men Data Domain- och/eller NetWorker-loggning, samt kloningshastigheter, indikerar att prestandaproblem kvarstår.