Data Domain: Prácticas recomendadas para la replicación de directorios y pools

Prácticas recomendadas para la replicación de directorios

PROPÓSITO

En este artículo, se definen las prácticas recomendadas para configurar la replicación de directorios.

SE APLICA A

• Todos los sistemas Data Domain
• Todas las versiones de software

RECOMENDACIONES

1. Distribuya la carga de trabajo en tantos contextos como sea posible.
   El rendimiento ideal de un solo contexto precomprimido se encuentra en el rango de 200 a 300 MB/s. En configuraciones en las que está disponible el streaming múltiple, el rendimiento ideal de un solo contexto es similar al rendimiento ideal de múltiples contextos; Sin embargo, hay varias variables que limitan la eficacia del streaming múltiple:

   • Si el DDR de origen tiene muchos contextos de replicación, la lógica para dividir flujos de streaming múltiple entre contextos limita la cantidad disponible de flujos.
   • El streaming múltiple no está activo durante la inicialización/recuperación basada en instantáneas. De manera predeterminada, una inicialización basada en instantáneas está vigente si el contexto de origen tiene más de 1 millón de entradas.
   • Desde la versión 5.0 en adelante, se introdujo el streaming múltiple para replicar datos CIFS.

   El rendimiento ideal de multicontexto precomprimido por modelo varía de aproximadamente 200 MB/s a 500 MB/s o más.

2. Diseñe la carga de trabajo con archivos de tamaño moderado.
   El tamaño del archivo puede tener un impacto significativo en el rendimiento general de cualquier contexto de replicación. En general, los archivos con un tamaño inferior a 10 MB no se pueden replicar de manera eficiente.

   Además, cuando un par de replicación se vuelve a conectar después de una desconexión inesperada, el origen debe reiniciarse desde el principio del archivo que se estaba replicando durante la desconexión. Si el archivo es muy grande y hay desconexiones frecuentes (por ejemplo, debido a una red poco confiable), la replicación puede volverse efectivamente ?atascada? Intentar replicar el mismo archivo una y otra vez. Esto se observa con mayor frecuencia en archivos que superan los 100 GB de tamaño. No hay implicaciones de rendimiento debido al tamaño del archivo en sí.

3. Diseñe la carga de trabajo para aprovechar la programación de la replicación.
   Los archivos se ponen en cola para replicación cuando se cierran internamente. El momento en que se cierra el archivo es el siguiente:

   Cuando se cierra un archivo modificado, se genera un registro de "cierre" del registro de replicación para el archivo. La replicación pone en cola los datos nuevos en el archivo para su envío. Si no hay otras operaciones de replicación delante de ella en la línea de espera (es decir, registros sin procesar), los nuevos datos se envían de inmediato. De lo contrario, el archivo se replicará después de que se procesen las entradas de registro anteriores.

   • 10 minutos después del último acceso, NFS cerrará el archivo.
   • Todos los archivos se cierran cada hora, independientemente de la fecha de escritura reciente.
   • Si se accede a muchos archivos o se escriben estos, es posible que los archivos se cierren antes de lo que indican las reglas anteriores. El software de respaldo que escribe archivos en fragmentos más pequeños (por ejemplo, 1 MB) puede provocar que la replicación se inicie antes debido a la cantidad de archivos que se generan.

4. Utilice una red dedicada si es posible.
   Las tasas de pérdida de paquetes tan bajas como el 0,1 % pueden degradar gravemente el rendimiento de la red, especialmente para las redes con gran retraso en el ancho de banda. Para redes con ancho <de banda = T2, el RTT (tiempo de ida y vuelta) de hasta un segundo proporciona un buen rendimiento. Para las redes de >= T3, hay una degradación significativa del rendimiento a partir de un RTT de 300-500 ms.

   De manera más general, el rendimiento bajo pérdida de paquetes es aproximadamente
   Throughput = MSS /(RTT * sqrt(p)) donde MSS := tamaño mínimo del segmento (típicamente 1460 bytes) RTT := tiempo de ida y vuelta p := probabilidad de pérdida de paquetes

5. Evalúe la replicación delta (optimización de ancho de banda bajo).
   En DD OS 4.8 y versiones posteriores, la replicación delta, también denominada "optimización de ancho de banda bajo", puede aumentar el rendimiento virtual de la replicación de directorios o pools en enlaces con menos de 6 megabits por segundo (Mbps) de ancho de banda disponible. La replicación delta incurre en una sobrecarga adicional significativa de CPU y de I/O en los sistemas Data Domain de origen y destino. Si se habilita la optimización de ancho de banda bajo en enlaces con más de 6 Mbps de ancho de banda, es poco probable que se logre una ganancia en el rendimiento virtual. En términos generales, si:

   • Los datos que se replicarán son idénticos en menos del 96 % a los datos que ya existen en el sistema de destino
   • Hay menos de 6 Mbps de ancho de banda disponible
   • Ambos sistemas tienen CPU de repuesto y capacidad de I/O

     La optimización de bajo ancho de banda debe estar habilitada. Monitoree el resultado de "replication show history" durante varias semanas. La relación "Low-bw-optim" debe promediar 2,00 o más, y el rendimiento de la red (bytes de red divididos por el intervalo de tiempo) no debe ser mucho menor que el ancho de banda disponible. Si la relación "Low-bw-optim" no tiene un promedio de 2,00 o más, es probable que la compresión delta no sea eficaz en el conjunto de datos y se deba deshabilitar. Si el rendimiento de la red es mucho menor que el ancho de banda disponible, lo más probable es que uno o ambos sistemas Data Domain no tengan suficiente CPU de repuesto o capacidad de I/O para admitir la replicación delta, por lo que se debe deshabilitar.

6. Siga las prácticas recomendadas para otros componentes y aplicaciones de respaldo de otros fabricantes.
   Nuestras guías de prácticas recomendadas se escribieron teniendo en cuenta el rendimiento general. Las desviaciones de las prácticas recomendadas sugeridas por Data Domain pueden tener implicaciones significativas en el rendimiento en varias áreas, aunque es posible que no sean evidentes de inmediato.

REFERENCIA

Solución de problemas del retraso en la replicación 180482