NetWorker: Capaciteitsmodus vProxy kloont prestatieproblemen tussen Data Domains

• De vProxy-kloonsnelheid is gedaald van GB's/sec naar meer conventionele en realistische snelheden.
• Netwerkbandbreedte is uitgesloten als oorzaak van knelpunten en blijft tijdens het klonen ruim onder de drempelwaarde.
• Berichten zijn te vinden in de ddfs.infologs die verwijzen naar een of meer *-flat.vmdk Bestanden voor de betreffende virtuele machine (VM) met daarin:
  • synthesized_vbytes 0 en eindigend met recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr voor basisbestand en eindigend met fout Bestandshandle is verouderd.
• Berichten gevonden in de kloonactielogboeken (wanneer het kloonfoutopsporingsniveau 3 of hoger is) die verwijzen naar een of meer *-flat.vmdk-bestanden voor de schijven van de getroffen VM die het volgende bevatten:
  • Synthetische replicatie kan niet worden gebruikt voor het bestand... pad.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy maakt gebruik van virtuele kunststoffen om gebruik te maken van de gewijzigde API voor het bijhouden van blokken van VMware, wat enorme voordelen oplevert voor zowel back-up- als kloonbewerkingen. Dit vereist actief onderhoud van interne associaties van de erfelijkheid van VM-bestandssets op elk betrokken datadomein. Als er zich problemen voordoen tijdens de voorbereiding van het klonen met behulp van virtuele kunststoffen, kunnen NetWorker en Data Domain in plaats daarvan teruggaan naar het gebruik van de standaard replicatieworkflow. Hiervoor moeten de volledige virtuele schijfbestanden worden verwerkt, in plaats van alleen de gewijzigde blokken, in tegenstelling tot alleen de gewijzigde blokken die door de VMware API worden geleverd. Zelfs als er uiteindelijk weinig data worden verzonden als gevolg van deduplicatie, kan de duur van de kloontaak met veelvouden toenemen.
 
Oorzaken die kunnen leiden tot het mislukken van virtuele synthetische tracking zijn onder meer:

• Verschillende IP-adressen die worden opgelost in NetWorker voor de bron- of doel-Data Domain-apparaten tussen taken. Deze moeten consistent blijven voor de interne tracking van virtuele kunststoffen
• Bron of bestemming wijzigen Data Domain voor vProxy-back-ups of -klonen
• Meerdere bron- of doelvolumes voor de vProxy-back-ups of klonen, wat kan leiden tot gelijktijdig klonen van meerdere savesets in de keten
• Meer dan één vProxy-saveset waarvoor klonen vereist is voor een bepaalde VM, wat kan leiden tot ongeordend klonen van savesets in de keten
• VM-schijven die gedurende lange perioden zonder wijzigingen worden gebruikt (met name perioden die de bewaarperioden van Savset overschrijden, zoals 35 dagen zonder wijziging bij een retentieperiode van 30 dagen)
• Kan de eigenschap ChronologischeVolgorde-actie niet gebruiken

Aangezien er tal van mogelijke oorzaken zijn, moet u de Data Domain- en NetWorker-configuraties controleren en het volgende controleren:

• ifgroups correct zijn ingesteld voor zowel bron (back-up) als bestemming (kloondoel) Data Domains
• NetWorker-server, storageknooppunten en Data Domains hebben allemaal hostbestandsvermeldingen met behulp van de juiste ifgroup IP's per Data Domain en betrouwbare DNS voor clients (met behulp van NetWorker-clienthostbestanden indien nodig).
• Eén Data Domain voor elke back-up- en kloongroep.

Schakel de functie Chronologische volgorde in voor vProxy-kloonacties voor het opslaan van sets, die mogelijk verborgen zijn in de gebruikersinterface:

• Bij gebruik van nsrclone commando, gebruikt u de -O Schakel over om deze nieuwe functie af te dwingen bij het gebruik van een lijst met opgeslagen sets met meerdere opslagsets in de keten van een bepaalde client
• Als u in policy wilt inschakelen, gebruikt u een van de volgende twee opdrachten:

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

• In de nsradmin-prompt:

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

update Chronological order: Yes

• Zodra dit is voltooid, worden de eerder genoemde beperkingen op één bron- en doelvolume, evenals incrementele volumes met meerdere instanties per VM-client, opgeheven en kunnen deze correct worden verwerkt.

BELANGRIJK: NetWorker en Data Domain kunnen zich herstellen van bepaalde omstandigheden waarbij opslagsets niet in de juiste volgorde worden gekloond. Dit leidt ertoe dat sommigen VSR niet kunnen gebruiken voor replicatie, maar zodra de hele keten is hersteld, kan het klonen van VSR zonder problemen worden voortgezet. Over het algemeen kunnen klonen in ongebruikte volgorde, klonen met meerdere volumes en meerdere opslagsets inhalen en terugkeren naar de normale werking.
 
In het geval dat er al meerdere Data Domain IP-adressen zijn gebruikt of de bron of bestemming van Data Domain volledig zijn gewijzigd, is de enige manier om terug te keren naar normale en consistente VSR-optimalisatie het forceren van een nieuwe volledige back-up van de betrokken VM's om de gewijzigde bloktracering te resetten en de VSR-optimalisatie te herstellen. Hiermee moet rekening worden gehouden wanneer de vorige stappen zijn voltooid, maar Data Domain en/of NetWorker logboekregistratie en kloonsnelheden geven aan dat er prestatieproblemen blijven bestaan.