NetWorker : Problèmes de performances des tâches de clonage vProxy en mode capacité entre les systèmes Data Domain

• La vitesse de clonage vProxy est passée de Go/s à des vitesses plus conventionnelles et réalistes.
• La bande passante réseau a été écartée comme cause du goulot d’étranglement, restant bien en dessous du seuil lors du clonage.
• Les messages se trouvent dans les ddfs.logs d’informations se référant à un ou plusieurs fichiers *-flat.vmdk pour les disques de la machine virtuelle concernée contenant:
  • synthesized_vbytes 0 et se terminant par recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr pour le fichier de base et se terminant par un descripteur de fichier d’erreur est obsolète.
• Messages trouvés dans les logs d’action de clonage (lorsque le niveau de débogage du clone est de 3 ou plus) faisant référence à un ou plusieurs fichiers *-flat.vmdk pour les disques de la machine virtuelle concernée contenant:
  • La réplication synthétique ne peut pas être utilisée pour le fichier... chemin.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy utilise des sauvegardes synthétiques virtuelles pour tirer parti de l’API de suivi des blocs modifiés de VMware, ce qui offre des gains considérables pour les opérations de sauvegarde et de clonage. Cela nécessite une maintenance active des associations internes de l’hérédité du jeu de fichiers de machine virtuelle sur chaque Data Domain concerné. Si des problèmes surviennent lors de la préparation au clonage à l’aide de sauvegardes synthétiques virtuelles, NetWorker et Data Domain reviennent à l’aide du workflow de réplication par défaut. Cela nécessite le traitement de l’ensemble des fichiers de disque virtuel, plutôt que des blocs modifiés, par opposition aux seuls blocs modifiés fournis par l’API VMware, et même si peu de données sont finalement envoyées en raison de la déduplication, la durée de la tâche de clonage peut augmenter de plusieurs.
 
Les causes pouvant entraîner l’échec du suivi synthétique virtuel sont les suivantes:

• Différentes adresses IP résolues par NetWorker pour les périphériques Data Domain source ou cible entre les tâches: elles doivent rester cohérentes pour le suivi interne des sauvegardes synthétiques virtuelles
• Modification du data domain source ou de destination pour les sauvegardes ou les clones vProxy
• Plusieurs volumes source ou cible pour les sauvegardes ou les clones vProxy, ce qui peut entraîner le clonage simultané de plusieurs savesets dans la chaîne
• Plusieurs savesets vProxy nécessitant un clonage pour une machine virtuelle donnée, ce qui peut entraîner un clonage désordonné des savesets dans la chaîne
• Disques de machines virtuelles qui restent pendant de longues périodes sans modification (en particulier les périodes qui dépassent les périodes de rétention saveset, telles que 35 jours sans modification où la rétention est de 30 jours)
• Échec de l’utilisation de la propriété d’action d’ordre chronologique, si vous utilisez NetWorker 19.6 et les versions ultérieures

Étant donné qu’il existe de nombreuses causes potentielles, passez en revue les configurations Data Domain et NetWorker et assurez-vous que:

• Les ifgroups sont correctement configurés pour les data domains source (sauvegarde) et de destination (cible clone)
• Le serveur NetWorker, les nœuds de stockage et les data domains disposent tous d’entrées de fichier d’hôtes utilisant les adresses IP ifgroup appropriées par Data Domain, et d’un DNS fiable pour les clients (à l’aide des fichiers hôtes du client NetWorker selon les besoins).
• Data Domain unique pour chaque pool de sauvegardes et de clones.

Lorsque vous utilisez NetWorker 19.5 ou une version antérieure:

• Assurez-vous que les tâches de clonage sont exécutées en série et dans l’ordre des sauvegardes; Notez que cela ne peut pas être contrôlé lorsque plusieurs clones d’une machine virtuelle donnée se trouvent dans la même liste de tâches (action de clonage ou liste de fichiers saveset nsrclone).
• Assurez-vous qu’un seul volume de sauvegarde et de clonage par pool, afin d’éviter le clonage simultané lorsque plusieurs volumes sont disponibles pour la source.

À partir de NetWorker 19.6, vous devez toujours activer la fonction d’ordre chronologique pour les actions de clonage de saveset vProxy, qui peuvent être masquées dans l’interface utilisateur:

• Si vous utilisez la commande nsrclone, utilisez le commutateur -O pour appliquer cette nouvelle fonctionnalité lors de l’utilisation d’une liste de savesets avec plusieurs savesets dans la chaîne d’un client donné
• Pour activer dans la règle, utilisez l’une des deux commandes suivantes:

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

  • Dans l’invite nsradmin:

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

    • update Chronological order: Yes

      
       
• Une fois cette opération terminée, les restrictions mentionnées précédemment sur les volumes source et cible uniques, ainsi que les incréments à plusieurs instances par client de machine virtuelle, sont levées et peuvent être traitées correctement.

IMPORTANT : Certaines conditions peuvent être possibles pour que NetWorker et Data Domain puissent effectuer une restauration à partir de, où les savesets sont clonés hors ordre. Cela empêche certains d’utiliser VSR pour la réplication, mais une fois l’intégralité de la chaîne restaurée, le clonage VSR peut se poursuivre sans problème. En règle générale, le clonage hors commande, le clonage à plusieurs volumes et à plusieurs savesets peut suivre et revenir à un fonctionnement normal.
 
Toutefois, dans le cas où plusieurs adresses IP Data Domain ont déjà été utilisées ou modifient entièrement la source ou la destination de Data Domain, le seul moyen de revenir à une optimisation VSR régulière et cohérente consiste à forcer une nouvelle sauvegarde complète des machines virtuelles concernées pour réinitialiser le suivi des blocs modifiés et restaurer l’optimisation VSR. Cela doit être pris en compte lorsque les étapes précédentes ont été effectuées, mais que la consignation Data Domain et/ou NetWorker, ainsi que les vitesses de clonage, indiquent que des problèmes de performances persistent.