PBX: (593-2) 333 2191
Teléfono

Nunca he dudado de NetWorker. Parte I

Realmente NetWorker puede hacer maravillas, pero no las podemos ver, lo que vemos es solo una herramienta más de respaldos, que a pesar de que la tratamos de comparar con la competencia, nos aferramos en lo que le falta por hacer, pero, si me permiten contarles más, aquellas cosas que no se ven, pero están ahí y de hecho existen por una razón, le dedicare una serie de publicaciones mostrando algunas características.

Acelera la restauración. Desde que tenemos en manos la versión 19.1, todas las restauraciones que se realizan desde un Data Domain, van comprimidas, lo cual, reduce el consumo de tráfico en la red. Tener una buena tasa de transferencia para los respaldos es buena, pero para mí, es mejor tener la mejor tasa de restauración, porque seamos realistas, la data que vamos a restaurar la necesitamos y la necesitamos para ¡ayer!, así que, dejemos un poco más claro esto con unos pasos sobre lo que sucede:

1.  El usuario ejecuta la solicitud de restauración de datos (desde cualquier consola de NetWorker), y esta solicitud se convierte en una tarea.

2.  La tarea establece las sesiones entre el cliente (filesystem, app o DB) y el Data Domain.

3.  El Data Domain empieza a rehidratar los datos, luego,

4.  El Data Domain comprime los datos rehidratados.

5.  Los datos comprimidos son transmitidos sobre la red hacia el cliente.

6.  En el cliente se descomprimen los datos y estos quedan listos para ser usados.

Les muestro las estadísticas en el Data Domain de una prueba realizada en nuestros laboratorios al realizar una restauración.

Debo decir que el laboratorio es un Data Domain virtual de 0.5TB, y nuestra red es solo de 1GB. ¡Así que estos valores desde luego que pueden mejorarse en un ambiente en producción!

# ddboost stats show interval 1

Fig. Detalle de las conexiones DDBoost en el Data Domain.

En las columnas de “Restore KB/s” y “Network Out KB/s”, nos dicen la cantidad de datos que están siendo leídos en el Data Domain, y la cantidad de datos que están siendo transmitidos, respectivamente. Estos es aproximadamente 7:1 de radio de compresión. Nada mal ¿verdad?.

Claro que hay un par de detalles que no he mencionado para que esta magia sea posible.

Lo primero es lo primero, tener una versión superior de Networker 19.1, luego, el Data Domain debe contar con una versión superior de DDOS 6.0.0.30, y finalmente, el pool debe estar definido en el Networker como un device del tipo Data Domain, ya que esto no funciona en escenarios en los que se tiene una NAS o como le llama Networker, un dispositivo AFTD.

Nos leemos en la siguiente parte.

Por: Omar Córdova

Deja una respuesta