NetWorker: Problemas de rendimiento del trabajo de clonación de vProxy en el modo de capacidad entre Data Domains

• La velocidad de clonación de vProxy disminuyó de GB por segundo a velocidades más convencionales y realistas.
• El ancho de banda de red se descartó como causa del cuello de botella y se mantuvo muy por debajo del umbral durante la clonación.
• Los mensajes se encuentran en ddfs.registros de información que hacen referencia a uno o más archivos *-flat.vmdk para los discos de la VM afectada que contienen:
  • synthesized_vbytes 0 y termina con recipe_repl FALSO
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr para el archivo base y el identificador del archivo de error está obsoleto.
• Mensajes encontrados en los registros de acción de clonación (cuando el nivel de depuración de clonación es 3 o superior) que hacen referencia a uno o más archivos *-flat.vmdk para los discos de la MÁQUINA virtual afectados que contienen:
  • La replicación sintética no se puede utilizar para el archivo... ruta.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy utiliza respaldos sintéticos virtuales para aprovechar la API de rastreo de bloques modificados de VMware, lo que proporciona enormes ganancias para las operaciones de respaldo y clonación. Esto requiere el mantenimiento activo de las asociaciones internas de la heredidad del conjunto de archivos de VM en cada Data Domain involucrado. Si surgen problemas durante la preparación para clonar mediante respaldos sintéticos virtuales, NetWorker y Data Domain realizan una conmutación por recuperación al flujo de trabajo de replicación predeterminado. Esto requiere el procesamiento de los archivos de disco virtual completos, en lugar de solo los bloques modificados, en lugar de solo los bloques modificados proporcionados por la API de VMware, e incluso si en última instancia se envían pocos datos debido a la desduplicación, la duración del trabajo de clonación puede aumentar en múltiplos.
 
Las causas que pueden provocar la falla del rastreo sintético virtual incluyen:

• Diferentes direcciones IP que resuelve NetWorker para los dispositivos Data Domain de origen o destino entre trabajos: deben permanecer coherentes para el rastreo interno de los sintéticos virtuales
• Cambio de Data Domain de origen o destino para respaldos o clones de vProxy
• Varios volúmenes de origen o destino para los respaldos o clones de vProxy, lo que puede provocar la clonación simultánea de varios savesets en la cadena
• Más de un saveset de vProxy que requiere clonación para una VM determinada, lo que puede provocar una clonación desordenada de savesets en la cadena
• Discos de VM que pasan por períodos largos sin cambios (en especial, períodos que superan los períodos de retención del saveset, como 35 días sin cambios donde la retención es de 30 días)
• Falla en el uso de la propiedad Acción cronológica de orden si se utiliza NetWorker 19.6 y versiones posteriores

Dado que hay numerosas causas potenciales, revise las configuraciones de Data Domain y NetWorker y asegúrese de lo siguiente:

• los ifgroups se configuran correctamente para Data Domain de origen (respaldo) y de destino (clon de destino)
• El servidor de NetWorker, los nodos de almacenamiento y Data Domain tienen entradas de archivos de hosts que utilizan las IP de ifgroup adecuadas por Data Domain y DNS confiable para los clientes (mediante los archivos de hosts de cliente de NetWorker que necesiten).
• Data Domain único para cada pool de respaldo y clonación.

Cuando se utiliza NetWorker 19.5 o versiones anteriores:

• Asegúrese de que los trabajos de clonación se realicen en serie y en orden de respaldos; Tenga en cuenta que esto no se puede controlar cuando varios clones para una máquina virtual determinada se encuentran en la misma lista de trabajos (lista de archivos de acción de clonación o saveset de nsrclone).
• Asegúrese de que haya un solo volumen de respaldo y clon por pool para evitar la clonación simultánea cuando haya varios volúmenes disponibles para el origen.

A partir de NetWorker 19.6, siempre debe habilitar la función CronológicaOrder para las acciones de clonación de savesets de vProxy, que pueden estar ocultas en la interfaz del usuario:

• Si utiliza el comando nsrclone, utilice el switch -O para aplicar esta nueva función cuando utilice una lista de savesets con varios savesets en la cadena de un cliente determinado
• Para habilitar en la política, utilice uno de los siguientes dos comandos:

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

  • En el indicador nsradmin:

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

    • update Chronological order: Yes

      
       
• Una vez que esto se completa, las restricciones mencionadas anteriormente en los volúmenes de origen y destino únicos, así como los incrementos de múltiples instancias por cliente de VM, se levantan y se pueden procesar correctamente.

IMPORTANTE: Es posible que se puedan recuperar algunas condiciones de NetWorker y Data Domain, en las que los savesets se clonan fuera de servicio. Esto hace que algunos no puedan utilizar VSR para la replicación, pero una vez que se restaura toda la cadena, la clonación de VSR podría continuar sin problemas. Por lo general, la clonación fuera de pedido, la clonación de varios volúmenes y de múltiples savesets puede ponerse al día y volver al funcionamiento normal.
 
Sin embargo, en el caso de que varias direcciones IP de Data Domain ya se hayan utilizado o cambiado completamente el origen o destino de Data Domain, la única manera de volver a la optimización de VSR regular y coherente es forzar un nuevo respaldo completo de las VM afectadas para restablecer el rastreo de bloques modificados y restaurar la optimización de VSR. Esto se debe considerar cuando se hayan completado los pasos anteriores, pero el registro de Data Domain o NetWorker, así como las velocidades de clonación, indican que los problemas de rendimiento permanecen.