NetWorker: Prestatieproblemen met capaciteitsmodus vProxy kloontaak tussen datadomeinen

• vProxy kloonsnelheid is van GB's/sec naar conventionelere en realistischere snelheden gegaan.
• Netwerkbandbreedte is uitgesloten als oorzaak van knelpunt, maar blijft tijdens het klonen ruim onder de drempel.
• Berichten zijn te vinden in de ddfs.infologboeken die verwijzen naar een of meer *-flat.vmdk-bestanden voor de betreffende VM-schijven met:
  • synthesized_vbytes 0 en eindigend op recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr voor het basisbestand en eindigt met de foutmelding Bestandsinging is verlopen.
• Berichten in de kloonactielogboeken (wanneer het kloonopsporingsniveau 3 of hoger is) die verwijzen naar een of meer *-flat.vmdk-bestanden voor de schijven van de getroffen VM met:
  • 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 BLOCK Tracking API van VMware, wat enorme voordelen biedt voor zowel back-up- als kloonbewerkingen. Hiervoor is actief onderhoud van interne organisaties van VM-bestanden vereist voor elk betrokken Data Domain. Als zich problemen voordoen terwijl u zich voorbereidt op klonen met behulp van virtuele kunststoffen, kunnen NetWorker en Data Domain in plaats daarvan niet terugkeren naar het gebruik van de standaardreplicatieworkflow. Dit vereist verwerking van de volledige virtuele schijfbestanden, in plaats van alleen de gewijzigde blokken, in tegenstelling tot alleen de gewijzigde blokken die worden geleverd door de VMware API- en zelfs als er weinig data uiteindelijk worden verzonden vanwege deduplicatie, kan de duur van het klonen met meerdere keren toenemen.
 
Oorzaken die kunnen leiden tot het mislukken van virtuele, kunstmatige tracking zijn onder andere:

• Verschillende IP-adressen die door NetWorker worden opgelost voor de datadomeinapparaten van de bron of bestemming tussen taken: deze moeten consistent blijven voor interne tracering van virtuele kunststoffen
• Data Domain van bron of bestemming wijzigen voor vProxy back-ups of klonen
• Meerdere bron- of doelvolumes voor de vProxy back-ups of klonen, wat kan leiden tot gelijktijdige klonen van meerdere savesets in de keten
• Meer dan één vProxy saveset die klonen voor een bepaalde VM vereist, wat kan leiden tot ongeorderde klonen van savesets in de keten
• VM-schijven die lange perioden zonder wijzigingen gaan (met name perioden die de bewaarperioden van saveset overschrijden, zoals 35 dagen zonder wijziging waarbij retentie 30 dagen is)
• De eigenschap ChronologicalOrder Action niet gebruiken, bij gebruik van NetWorker 19.6 en hoger

Aangezien er tal van mogelijke oorzaken zijn, controleert u de Data Domain- en NetWorker-configuraties en zorgt u ervoor dat:

• ifgroups are correct setup for both source (backup) and destination (clone target) Data Domains
• NetWorker-server, storageknooppunten en Data Domains hebben allemaal bestandsvermeldingen voor hosts met behulp van de juiste ifgroup IP's per Data Domain en betrouwbare DNS voor clients (bij gebruik van NetWorker-clienthostbestanden wanneer dat nodig is).
• Eén Data Domain voor elke back-up- en kloongroep.

Bij gebruik van NetWorker 19.5 of lager:

• Ervoor zorgen dat kloontaken serieel en in de volgorde van back-ups worden uitgevoerd; Let op: dit kan niet worden beheerd wanneer meerdere klonen voor een bepaalde VM zich in dezelfde taaklijst bevinden (kloonactie of nsrclone saveset-bestandslijst).
• Zorg voor één back-up- en kloonvolume per pool om gelijktijdige klonen te voorkomen wanneer meerdere volumes beschikbaar zijn voor de bron.

Vanaf NetWorker 19.6 moet u altijd de functie ChronologicalOrder inschakelen voor vProxy saveset kloonacties, die mogelijk verborgen zijn in de gebruikersinterface:

• Als u de opdracht nsrclone gebruikt, gebruikt u de -O-switch om deze nieuwe functie af te dwingen bij het gebruik van een savesetlijst met meerdere savesets in de keten van een bepaalde client
• Als u policy wilt inschakelen, gebruikt u een van de volgende twee opdrachten:

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

  • 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 eerder genoemde beperkingen voor enkele bron- en doelvolumes, evenals incrementele incrementele multi-instance per VM-client, opgetild en kunnen ze correct worden verwerkt.

BELANGRIJK: Sommige voorwaarden kunnen voor NetWorker en Data Domain mogelijk worden hersteld, waarbij savesets buiten de volgorde worden gekloond. Dit zorgt ervoor dat sommige gebruikers 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 met meerdere volumes en multi-saveset klonen in de regel worden ingehaald en weer normaal worden uitgevoerd.
 
In het geval van meerdere Data Domain IP-adressen die al zijn gebruikt of de datadomeinbron of -bestemming volledig hebben gewijzigd, is de enige manier om terug te keren naar regelmatige en consistente VSR-optimalisatie, een nieuwe volledige back-up van de getroffen VM's te forceren om de gewijzigde blocktracking opnieuw in te stellen en VSR-optimalisatie te herstellen. Dit moet worden overwogen wanneer de vorige stappen zijn voltooid, maar Data Domain- en/of NetWorker-logboekregistratie, evenals de snelheid van klonen, geven aan dat prestatieproblemen blijven bestaan.