Data Domain: El sistema de archivos DDFSY entra en estado de alarma si se configuró la replicación de MTREE para la unidad de almacenamiento Veeam DDBOOST

Cuando se utiliza VEEAM, o cualquier otra aplicación de respaldo que utilice BOOST para realizar respaldos, se utiliza la función Sintéticos virtuales, se crean nuevos respaldos a partir de los existentes mediante la unión de partes de los respaldos anteriores en el DD y, a continuación, se agregan las diferencias. Los respaldos anteriores utilizados para la unión se denominan "archivos base".

La mayoría de las aplicaciones de respaldo leerán, pero no modificarán los archivos base utilizados para la creación de nuevas imágenes de respaldo; sin embargo, VEEAM funciona de manera diferente cuando se realizan respaldos, sobrescribe partes de los archivos base que ya están en el disco.

Cuando se configura la replicación saliente de MTree para esta LSU/MTree de VEEAM, es posible que BOOST modifique un archivo de respaldo que se está replicando durante la síntesis de nuevos archivos de respaldo. Si el DD de origen ejecuta DDOS 6.x y la replicación de receta está habilitada (una opción de optimización de velocidad/rendimiento en DDOS 6.x y superior), esto puede provocar que las sumas de comprobación incorrectas lleguen al DD de destino, lo que podría provocar que el FS (sistema de archivos) falle repetidamente con mensajes como los siguientes:

27 de febrero de 04:05:19 mtree-repl-dd.example.com ddfs[10654]: ERROR: MSG-INTRNL-00001: PANIC: ddr/repl/mrepl_replica.c: mrepl_finish_file_transfer_common: 3712: ! (orig_chksum == repl_chksum).

En la forma en que VEEAM sintetiza los nuevos respaldos de los existentes, podría haber sobrescrituras de algunas partes de los archivos que se replican cuando se utilizan como un archivo base para la reescritura de nuevas imágenes de respaldo. Esto crea confusión para la replicación de receta cuando la unidad de almacenamiento de VEEAM también está configurada para usarse como parte de la replicación de MTree, lo que posiblemente provoca que el DD de destino entre en estado PANIC.

Tenga en cuenta que este defecto solo se aplica al extremo de destino para la replicación de MTree cuando el origen es:

• Ejecución de DDOS 6.0.1.0 o anterior (por ejemplo, todos los DDOS 6.0.0.x se verían afectados)
• Ejecución de DDOS 6.x anterior a DDOS 6.0.2.0 o 6.1.1.1
• Ejecución de respaldos de VEEAM en una LSU/MTree, y ese mismo MTree se replica en el destino mediante la replicación de MTree
• Los respaldos de BOOST con respaldos sintéticos virtuales habilitados se realizan en la misma LSU/MTree
•  Cuando se encuentra este defecto, puede provocar que el MTree de destino replicado no esté disponible con varios reinicios del proceso de FS. Se recomienda a aquellos que estén utilizando esta configuración o que planean configurar sus sistemas de esta manera que empleen la solución alternativa que se explica a continuación o actualicen a DDOS 6.0.2.0 o 6.1.1.1 fijos (o a cualquier versión posterior).

Nota: Es posible que se produzca la misma cadena PANIC en el extremo de destino para la replicación de MTree para problemas distintos de este, ya que el error simplemente indica que una suma de comprobación en la instantánea de replicación de MTree no coincidió. Si tiene dudas sobre el problema que se describe aquí o cómo eludir un problema, comuníquese con su proveedor de soporte contratado y mencione este número de artículo de la base de conocimientos 491049.

El equipo de ingeniería de DD identificó la causa raíz de las PANIC de FS en el nodo de destino y confirmó una corrección en las siguientes versiones:

• DDOS 6.0.2.0 y versiones posteriores
• DDOS 6.1.1.1 y versiones posteriores

Se recomienda que cualquier persona afectada por este defecto o que planee configurar una configuración similar actualice el DD de origen a las versiones mencionadas lo antes posible.

Para aquellos que no están dispuestos a actualizar o aquellos que enfrentan el problema antes de que la versión fija esté disponible, existe una solución alternativa.
Consiste en deshabilitar la optimización de la replicación de receta en el sistema DDOS 6.x de origen.
Esta optimización solo está presente en DDOS 6.x y versiones posteriores, la única desventaja de deshabilitarla sería reducir las velocidades de replicación para que sean iguales a las logradas en DDOS 5.7.

Antes de la implementación, primero debe confirmar si esta solución alternativa se aplica a la configuración actual:

1. Compruebe si el DD de origen ejecuta DDOS 6.x antes de la versión que se corrigió (error corregido en DDOS 6.0.2.0 y 6.1.1.1 en adelante)
2. Confirme que el DD configurado para los respaldos de VEEAM también esté configurado para la replicación de MTree para el asunto LSU/MTree como origen (comprobar un ASUP reciente sería la manera más fácil de confirmar), por ejemplo:

CTX: 20 Mode: source Destination: mtree://destination-dd.example.com/data/col1/destination_MTree Enabled: yes

 Si se aplican todas estas condiciones anteriores, este sistema podría estar sujeto a los defectos mencionados anteriormente y podría provocar que el FS de replicación de destino se bloquee finalmente.

Para aplicar la solución alternativa, primero debe asegurarse de que no haya copias de seguridad de BOOST o de replicación en ejecución y, a continuación, realizar el cambio en la configuración del registro, lo que no requiere tiempo de inactividad. Antes de comenzar este proceso, lea la declaración DE PRECAUCIÓN que se encuentra debajo del paso final de este procedimiento.

1. Asegúrese de que la replicación de DD a DD esté deshabilitada en el DD de origen que ejecuta DDOS 6.x:

# replicación deshabilitar todo

2. Además, asegúrese de que no haya respaldos de BOOST en curso o MFR de BOOST hacia o desde el LSU/MTree de VEEAM potencialmente infractor antes de aplicar la configuración de registro. Si es necesario, deshabilite temporalmente los respaldos y la MFR hacia o desde esta LSU:

# ddboost file-replication show active all
# ddboost file-replication show stats

3. Este cambio de registro requiere privilegios de modo SE.

4. En el modo SE, cambie la configuración del registro para desactivar el uso de la replicación de receta:

# se sysparam set RECIPE_REPL_ENABLED=FALSE

5. Confirme que el parámetro del sistema se configuró correctamente y se muestre como "FALSO" (deshabilitado)

# se sysparam show RECIPE_REPL_ENABLED
Descripción del nombre Reemplazo predeterminado actual
-------------------   ------------------------------------------------   -------   -------   --------
RECIPE_REPL_ENABLED Habilitar replicación de receta (aplicar solo a la fuente) FALSO TRUE RPC
-------------------   ------------------------------------------------   -------   -------   --------

6. Ahora puede volver a habilitar la replicación de DD a DD y reanudar los respaldos de BOOST y la MFR de BOOST hacia o desde la LSU:

# replicación habilitar todo

PRECAUCIÓN: Si se deshabilitó el procesamiento de recetas en un sistema de origen de Data Domain que también está configurado como un extremo de destino para la replicación, los sistemas de origen para esos contextos también deberán realizar el proceso anterior (replicación de receta deshabilitada).

Además, tenga en cuenta que, una vez que actualice a una versión fija (DDOS 6.0.2.0 o 6.1.1.1), se deberá restaurar la configuración para poder aprovechar la replicación de recetas, la actualización no restablecerá la clave de registro. Después de completar la actualización, vuelva a habilitar la replicación de recetas iniciando sesión en DD, ingrese al modo de privilegio de SE y ejecute lo siguiente:

  # se sysparam reset RECIPE_REPL_ENABLED

Si no está seguro del proceso descrito anteriormente, póngase en contacto con el proveedor de soporte contratado y mencione este artículo de la base de conocimientos 491049.

Siempre existe la posibilidad de que las PANIC se deban a un problema diferente y es posible que la solución alternativa aplicada no funcione mientras continúan las alarmas de FS en el DD de destino.

En tal caso, la recomendación es que los DD de origen y destino se actualicen al código seguro (versiones de DDOS mencionadas anteriormente) y que los contextos de replicación infractores se rompan (no se configuren), las instantáneas existentes vencidas y los contextos de replicación se vuelvan a agregar y volver a inicializar. Dado que este es un proceso potencialmente lento y puede haber varios contextos de replicación que podrían ser la causa del problema, comuníquese con su proveedor de soporte contratado y mencione este número de artículo de la base de conocimientos y cualquier acción realizada hasta ahora para obtener ayuda.