NetWorker: Prestandaproblem för vProxy-klonjobb i kapacitetsläge mellan Data Domains

• vProxy-kloningshastigheten har sjunkit från GBs/s till mer konventionella och realistiska hastigheter.
• Nätverksbandbredd utesluts som orsak till flaskhals och förblir långt under tröskelvärdet under kloning.
• Meddelanden finns i ddfs.Informationsloggar som refererar till en eller flera *-flat.vmdk filer för de berörda virtuella datordiskarna (VM) som innehåller:
  • synthesized_vbytes 0 och slutar med recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr för basfilen och slutar med felet Filhandtaget är inaktuellt.
• Meddelanden som finns i klonåtgärdsloggarna (när klonfelsökningsnivån är 3 eller högre) som refererar 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 virtuell syntetisk för att utnyttja VMwares ändrade blockspårnings-API, vilket ger enorma vinster för både säkerhetskopierings- och kloningsoperationer. Detta kräver aktivt underhåll av interna associationer för VM-filuppsättningens ärftlighet på varje berörd Data Domain. Om det uppstår problem när du förbereder kloning med virtuell syntetisk teknik återgår NetWorker och Data Domain i stället till att använda standardarbetsflödet för replikering. Detta kräver bearbetning av hela de virtuella diskfilerna i stället för bara de ändrade blocken, till skillnad från endast de ändrade blocken som tillhandahålls av VMware API. Även om lite data i slutändan skickas på grund av deduplicering kan kloningsjobbets varaktighet öka med multiplar.
 
Orsaker som kan leda till att virtuell syntetisk spårning misslyckas är bland annat:

• Olika IP-adresser som matchas i NetWorker för käll- eller mål-Data Domain-enheter mellan jobb. 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äkerhetskopior 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 går under långa perioder utan några ändringar (särskilt perioder som överskrider kvarhållningsperioderna för lagringsuppsättningar, till exempel 35 dagar utan ändring där kvarhållningen är 30 dagar)
• Det gick inte att använda egenskapen ChronologicalOrder-åtgärd

Eftersom det finns många möjliga orsaker bör du granska Data Domain- och NetWorker-konfigurationerna och säkerställa:

• ifgroups är korrekt konfigurerade för både källdata (säkerhetskopiering) och mål (klonmål) Data Domains
• NetWorker-server, lagringsnoder och Data Domains har alla värdfilposter med lämpliga ifgroup IP-adresser 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.

Aktivera funktionen ChronologicalOrder för kloningsåtgärder för vProxy-sparuppsättning, som kan vara dolda i användargränssnittet:

• Om du använder nsrclone använder du kommandot -O Växla för att tillämpa den här nya funktionen när du använder en lista över sparade uppsättningar med flera sparuppsättningar i en klients kedja
• Om du vill aktivera i principen använder du något av följande två kommandon:

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 detta är klart tas tidigare nämnda begränsningar för enskilda käll- och målvolymer, samt inkrementella åtgärder med flera instanser per VM-klient, bort och kan bearbetas korrekt.

VIKTIGT! Vissa förhållanden kan vara möjliga för NetWorker och Data Domain att återställa från, där sparuppsättningar klonas i fel ordning. Detta gör 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. I allmänhet kan kloning i oordning, kloning av flera volymer och flera lagringsuppsättningar komma ikapp och återgå till normal drift.
 
Om flera IP-adresser för Data Domain redan har använts eller om Data Domain-källan eller -målet ändras 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 de föregående stegen har slutförts, men Data Domain- och/eller NetWorker-loggning och kloningshastigheter indikerar att prestandaproblem kvarstår.