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

• La velocidad de clonación de vProxy se redujo de GB/s a velocidades más convencionales y realistas.
• El ancho de banda de red se descarta como causa del cuello de botella, que permanece 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 *-flat.vmdk archivos para los discos de la máquina virtual (VM) afectados que contengan:
  • synthesized_vbytes 0 y terminando con recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr para el archivo base y termina con el error El identificador del archivo está obsoleto.
• Mensajes encontrados en los registros de acciones de clonación (cuando el nivel de depuración de clones es 3 o superior) que hacen referencia a uno o más archivos *-flat.vmdk para los discos de la VM afectada que contienen:
  • La replicación sintética no se puede utilizar para el archivo... ruta.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy utiliza sintéticos virtuales para aprovechar la API de seguimiento de bloques modificados de VMware, lo que proporciona enormes ganancias para las operaciones de respaldo y clonación. Esto requiere el mantenimiento activo de asociaciones internas de la herencia de conjuntos de archivos de VM en cada Data Domain involucrado. Si surgen problemas durante la preparación para clonar mediante sintéticos virtuales, NetWorker y Data Domain conmutan por recuperación para utilizar el 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. Incluso si finalmente se envían pocos datos debido a la desduplicación, la duración del trabajo de clonación puede aumentar por múltiplos.
 
Entre las causas que pueden provocar una falla del seguimiento sintético virtual, se incluyen las siguientes:

• Diferentes direcciones IP que se resuelven en NetWorker para los dispositivos Data Domain de origen o destino entre trabajos. Estos deben permanecer coherentes para el seguimiento interno de los sintéticos virtuales
• Cambio de origen o destino de Data Domain para respaldos o clones de vProxy
• Varios volúmenes de origen o destino para los respaldos o clones de vProxy, lo que puede llevar a la clonación simultánea de varios savesets en la cadena
• Hay 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 largos períodos sin cambios (específicamente, 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)
• Error al usar la propiedad ChronologicalOrder Action

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

• ifgroupEstán configurados correctamente para los Data Domains de origen (respaldo) y destino de destino (clonación)
• NetWorker Server, los nodos de almacenamiento y los Data Domains tienen entradas de archivos de hosts que utilizan la ifgroup IP por Data Domain y DNS confiable para los clientes (mediante archivos de hosts de cliente de NetWorker según sea necesario).
• Data Domain único para cada pool de respaldo y clonación.

Habilite la función ChronologicalOrder para las acciones de clonación de savesets de vProxy, que pueden estar ocultas en la interfaz de usuario:

• Si usa nsrclone , utilice el comando -O Cambie para aplicar esta nueva función cuando se usa 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] <yes|no>

• En el símbolo del sistema de 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 únicos de origen y destino, así como los incrementales de múltiples instancias por cliente de VM, se levantan y se pueden procesar correctamente.

IMPORTANTE: Es posible que NetWorker y Data Domain se recuperen en algunas condiciones, en las que los savesets se clonan fuera de orden. 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 puede continuar sin problemas. Por lo general, la clonación fuera de servicio, la clonación de varios volúmenes y varios savesets pueden ponerse al día y volver al funcionamiento normal.
 
En el caso de que ya se hayan utilizado varias direcciones IP de Data Domain o que cambien por completo el origen o el 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 seguimiento de bloques modificados y restaurar la optimización de VSR. Esto se debe considerar cuando se hayan completado los pasos anteriores, pero el registro y las velocidades de clonación de Data Domain o NetWorker indican que los problemas de rendimiento persisten.