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 est exclue comme cause du goulot d’étranglement, restant bien en dessous du seuil lors du clonage.
• Les messages se trouvent dans le ddfs.journaux d’informations faisant référence à un ou plusieurs journaux *-flat.vmdk pour les disques de machine virtuelle (VM) concernés 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 une erreur Le descripteur de fichier est obsolète.
• Messages trouvés dans les logs d’actions 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és contenant :
  • La réplication synthétique ne peut pas être utilisée pour le fichier. chemin.../vm-vmnuméro-disque-clé-numéro-disque-plat.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 d’hérédité des jeux de fichiers de machine virtuelle sur chaque Data Domain concerné. Si des problèmes surviennent lors de la préparation du clonage à l’aide de sauvegardes synthétiques virtuelles, NetWorker et Data Domain effectuent un retour arrière vers l’utilisation 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 uniquement, par opposition aux blocs modifiés fournis par l’API VMware. 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 être multipliée par deux.
 
Les causes pouvant conduire à l’échec du suivi synthétique virtuel sont les suivantes :

• Différentes adresses IP résolues dans NetWorker pour les périphériques Data Domain source ou cible entre les tâches. Ceux-ci doivent rester cohérents pour le suivi interne des synthétiques virtuels
• Modification du Data Domain source ou cible pour les sauvegardes ou les clones vProxy
• Plusieurs volumes source ou cible pour les sauvegardes ou 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 machine virtuelle qui fonctionnent pendant de longues périodes sans aucune modification (en particulier, les périodes qui dépassent les périodes de rétention des savesets, par exemple 35 jours sans modification lorsque la rétention est de 30 jours)
• Échec de l’utilisation de la propriété d’action ChronologicalOrder

Comme il existe de nombreuses causes possibles, passez en revue les configurations Data Domain et NetWorker et vérifiez que :

• ifgroupsont correctement configurés pour les systèmes Data Domain source (sauvegarde) et cible (cible de clonage).
• Le serveur NetWorker, les nœuds de stockage et les systèmes Data Domain ont tous des entrées de fichier hôtes utilisant le ifgroup Adresses IP par Data Domain et DNS fiable pour les clients (utilisant les fichiers des hôtes clients NetWorker en fonction des besoins).
• Un seul Data Domain pour chaque pool de sauvegarde et de clonage.

Activez la fonction ChronologicalOrder pour les actions de clonage de saveset vProxy, qui peuvent être masquées dans l’interface utilisateur :

• Si vous utilisez nsrclone , utilisez la commande -O Commutateur permettant d’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 l’activer dans la stratégie, utilisez l’une des deux commandes suivantes :

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

• 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 sources et de destination uniques, ainsi que sur les incréments multi-instances par client de machine virtuelle, sont levées et peuvent être traitées correctement.

IMPORTANT : Certaines conditions peuvent être possibles pour la restauration de NetWorker et Data Domain, où les savesets sont clonés dans le désordre. Cela empêche certains d’utiliser VSR pour la réplication, mais une fois la chaîne entière restaurée, le clonage VSR peut se poursuivre sans problème. En règle générale, le clonage dans le désordre, le clonage de plusieurs volumes et le clonage de plusieurs savesets peuvent rattraper leur retard et revenir à un fonctionnement normal.
 
Dans le cas où plusieurs adresses IP Data Domain ont déjà été utilisées ou si vous modifiez entièrement la source ou la destination Data Domain, la seule façon 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 journalisation Data Domain et/ou NetWorker et les vitesses de clonage indiquent que des problèmes de performances persistent.