Usando vCloud Availability para escenarios de Disaster Recovery (Parte 8 y final)

En esta serie de artículos hemos revisado a nivel de detalle el proceso de Disaster Recovery de servidores virtuales, utilizando la herramienta vCloud Availability de VMware. Este proceso parte con la protección, el failover, la protección reversa (para establecer la réplica en sentido inverso), el failback o failover reverso y posteriormente la re-protección.

El proceso de Disaster Recovery con vCloud Availability.

Sin embargo, vCloud Availability tiene una opción adicional para hacer el proceso de failover, llamado migrate. ¿Qué diferencias tiene con el failover y cuál es el rendimiento de este proceso? Vamos a revisar esta opción en el último artículo de esta serie.

Usando la opción migrate.

El primer detalle relevante al utilizar esta opción es que el asistente nos indica inmediatamente que el servidor del Datacenter Principal, una vez terminado el proceso, se apagará. En este sentido, el proceso de migración, a diferencia del proceso de failover, está pensado para escenarios en donde ambos datacenters se encuentran operativos. En ese sentido, el servidor migrado se debe apagar en el Datacenter Principal para no causar conflictos a nivel de red.

Configuración del proceso.

Otro aspecto relevante de este proceso es que no permite seleccionar instancias anteriores. Se sincroniza siempre con la última réplica.

Resumen del proceso.

Seguimiento del proceso.

Podemos visualizar que en el Datacenter Principal, apenas inicia el proceso, el servidor de pruebas cambia a estado de ejecución parcial.

Cambio de estado del servidor en el Datacenter Principal.

El proceso de migración duró 3 minutos, comparado con el proceso de failover para el mismo servidor que duró poco más de un minuto.

Comparación de tiempos del proceso.

Una vez finalizado el proceso de migración, el servidor en nuestro Datacenter Principal se ha detenido, mientras aparece en ejecución en nuestro Datacenter de Contingencia.

Situación del servidor en el Datacenter Principal una vez terminada la migración.

Situación del servidor en el Datacenter de Contingencia una vez terminada la migración.

El resto del proceso es similar; toca ahora hacer la reversa.

Realizando la protección reversa.

Confirmando la protección reversa.

Seguimiento del proceso.

El servidor ahora aparece en Incoming Replications.

Rendimiento de red en la protección reversa.

Una vez terminada la protección reversa, el servidor desaparece del Datacenter Principal.

El proceso de sincronización reversa duró 6 minutos, bastante más que los 2 minutos que duró la protección reversa cuando aplicamos la opción de failover.

Duración de la protección reversa.

Luego realizaremos el failback utilizando la misma opción de migración, para comparar los tiempos de ejecución de las actividades.

Esta vez, el servidor en nuestro Datacenter de Contingencia entra en un estado de ejecución parcial mientras comienza la migración a su Datacenter de Origen.

Paralelamente, comienza a levantarse el servidor en nuestro Datacenter Principal.

Posteriormente, el servidor en el Datacenter de Contingencia queda detenido.

Al igual que como sucedió en el proceso de failover, el failback utilizando la opción de migración tomó más tiempo que el proceso de failback que realizamos anteriormente.

Comparación de los tiempos de failback.

Para finalizar las pruebas, haremos la re-protección y cerraremos así el proceso. Lamentablemente para propósitos de esta prueba, el proceso de re-protección se realizó en paralelo con la sincronización de un servidor altamente transaccional, por lo cual los tiempos de sincronización no son comparables.

En resumen, utilizar la opción de migración en vez de utilizar la opción de failover en vCloud Availability tiene como principal diferencia el hecho de que no deja utilizar instancias anteriores para el proceso, además del hecho de que apaga forzosamente el servidor en el Datacenter de Origen una vez finalizado el proceso. Si bien las pruebas realizadas no son 100% concluyentes, se puede indicar que el proceso de migración es ligeramente más lento que el proceso de failover, ya que añade tareas adicionales que el proceso anteriormente mencionado.  Es un proceso pensado para utilizar en escenarios donde ambos Datacenters se encuentren operativos.

Con esto terminamos esta serie de artículos sobre esta herramienta de DRP como servicio, nativa de VMware y que ha mejorado una enormidad desde su primera versión. ¡Nos vemos pronto en otro artículo de seguridad y continuidad de negocio!

Read Full Post »

Usando vCloud Availability para escenarios de Disaster Recovery (Parte 7)

En el capítulo anterior de esta serie, dejamos preparado el escenario de vuelta atrás, al realizar una protección reversa de nuestro servidor ya ubicado en el Datacenter de Contingencia. Esto nos permite habilitar el servicio de réplica desde dicho Datacenter al Datacenter Principal, para que una vez que nos den luz verde, poder iniciar el proceso de failback o failover reverso.

Antes de eso había olvidado comentarles algo relevante. La consola de vCloud Availability existe en ambos Datacenter, y podemos operar de manera cruzada desde cualquiera de las dos consolas. Para propósitos de este artículo, toda la operación la hemos realizado desde la consola del Datacenter Principal.

Partiremos nuestro failback revisando el estado de las réplicas de nuestro servidor de pruebas. Para ello, iremos a la consola de vCloud Availability de nuestro Datacenter Principal y en la sección Incoming Replications pincharemos en nuestro servidor, para ir a la pestaña Instances. Si hacemos esta misma acción en la consola de nuestro Datacenter de Contingencia, la única diferencia es que esta tarea deberemos hacerla en la sección Outgoing Replications.

Estado de las réplicas de nuestro servidor de pruebas.

Podemos visualizar rápidamente que todo se encuentra OK. Es importante acá considerar que como este es un servidor de pruebas no transaccional, las réplicas son muy pequeñas, ya que el servidor no ha tenido transaccionalidad alguna en estos días.

Sin embargo, podemos visualizar que el server ha generado un disco activo de unos 12 GB, los cuales se replicaron inicialmente a gran velocidad gracias a los algoritmos de compresión de la herramienta.

Uso de disco en el servicio de réplica.

Llegó entonces el momento de realizar el failback. Para ello, en la consola de vCloud Availability, seleccionamos nuestro servidor y en Actions seleccionamos Failover.

Iniciando el proceso de failover.

De manera similar a lo que vimos un par de artículos atrás, configuraremos las opciones de nuestro proceso.

Configuración del proceso.

Posteriormente a esto, se debe seleccionar el punto de recuperación utilizado para el failback. Como este artículo lo escribí después de realizar el anterior, existen más puntos de recuperación creados.

Seleccionando el punto de restauración o failback.

Finalmente, en el cuadro de resumen de la operación se destaca que el proceso se realizará hacia el Datacenter Principal. Una vez que demos clic en Finish comenzará el proceso.

Cuadro resumen del proceso.

Gráficamente, podemos ver como comienza el proceso de failback.

Seguimiento del proceso de failback.

Una vez terminado el proceso de failback, podremos visualizar como nuestro servidor se ha encendido en el Datacenter Principal. Es importante recalcar que, en esta ocasión, se crea una nueva vApp, sin eliminar la anterior.

Status del servidor en el Datacenter Principal.

Por otro lado, el servidor sigue encendido en el Datacenter de Contingencia.

Status del servidor en el Datacenter de Contingencia.

Se puede visualizar, además, en el Datacenter Principal, las tareas asociadas al proceso de failback.

Tareas asociadas al proceso de failback. Se visualiza la eliminación del disco independiente asociado al servicio de réplica.

Una vez terminado el proceso de failover, que para el caso del servidor de pruebas duró algunos segundos, se puede visualizar que, a nivel de tráfico de red, la cantidad de datos que se movieron de un Datacenter a otro fue irrelevante.

Transferencia de archivos asociados al proceso.

Para cerrar el ciclo del DRP, debemos realizar la re-protección del servidor. Con esta tarea, se reestablecerá el servicio de réplica desde el Datacenter Principal hacia el Datacenter de Contingencia, lo cual eliminará el servidor desde el segundo Datacenter.

Para ello, iremos a nuestro servidor de pruebas y seleccionaremos Reprotect dentro del listado de acciones.

Iniciando la re-protección.

En la ventana emergente, daremos clic a Reverse para iniciar el proceso de re-protección.

Podemos seguir el status del proceso de re-protección en la consola principal.

Seguimiento al proceso de reprotección.

Al igual como pasó anteriormente, al cabo de unos segundos el servidor desaparecerá de la sección Incoming Replications, para volver a la sección Outgoing Replications como estaba originalmente.

El servidor ahora aparece en Outgoing Replications, tal como estaba al comienzo de todo el proceso.

Podemos visualizar, en el Datacenter de Contingencia, como el servidor ha sido borrado y su vApp ha quedado en estado Detenida.

Una vez iniciada la réplica asociada a la reprotección, desaparece el servidor del Datacenter de Contingencia.

Podemos visualizar en el registro como se eliminó el servidor y como se ha creado el disco independiente asociado al servicio de réplica.

Tareas asociadas a la re-protección del servidor en el Datacenter de Contingencia.

Para propósitos de esta prueba, el proceso de re-protección duró casi 10 minutos.

Duración del proceso.

Una vez finalizado el proceso, podemos borrar manualmente las vApps que quedaron huérfanas en ambos Datacenters y renombrar nuestra vApp en el Datacenter Principal, para mantener el orden de estas.

Eliminando la vApp que quedó vacía.

Confirmando la eliminación.

Renombrando la vApp al valor original.

Y con esto hemos concluido nuestro artículo de hoy. Para finalizar, en el último artículo de esta serie veremos las diferencias entre efectuar un failover y una migración del servidor. ¡Será hasta la próxima!

Read Full Post »

Usando vCloud Availability para escenarios de Disaster Recovery (Parte 6)

En el capítulo anterior de esta serie, realizamos un proceso de Failover de nuestro servidor de pruebas hacia el Datacenter de Contingencia. Hoy, comenzaremos a preparar el proceso de vuelta a operaciones normales realizando la protección reversa del servidor en el Datacenter de Contingencia, para así habilitar el servicio de réplica inversa que finalmente permitirá realizar el proceso de Failback o Failover inverso. Veamos cómo se hace.

En la consola de vCloud Availability, seleccionamos nuestro servidor y en Actions seleccionamos Reverse.

Comenzando la protección reversa.

En la ventana emergente, confirmamos haciendo clic en Reverse. Esto nos indica que se establecerá el proceso de réplica inversa.

Confirmando la protección reversa.

Seguimiento a la tarea de protección reversa.

Al cabo de algunos segundos, veremos cómo nuestro servidor ha desaparecido del Datacenter Principal. Para poder volver a visualizarlo, debemos buscarlo en la sección Incoming Replications, ya que ahora se encuentra operando desde el Datacenter de Contingencia.

Esta vez, el servidor se encuentra realizando la sincronización desde el Datacenter de Contingencia hacia el Datacenter Principal.

¿Y qué ha sucedido con nuestros servidores en ambos Datacenter? Una vez terminada la sincronización reversa, en el Datacenter Principal la máquina original ¡ha desaparecido!

Status de la vApp en el Datacenter Principal.

La máquina virtual ha desaparecido una vez terminada la protección reversa.

Por otro lado, se ha creado un disco independiente en el Datacenter Principal, el cual está asociado al proceso de réplica inversa.

Creación de la réplica en el Datacenter Principal.

Podemos visualizar que el ID de disco independiente es equivalente al indicado en vCloud Availability.

Finalmente, podemos visualizar el proceso de réplica inversa en relación con el rendimiento, el cual se realizó de manera muy rápida.

Tiempos de ejecución de la réplica inversa.

En el próximo artículo de esta serie, realizaremos el proceso de failover reverso, paso clave en el proceso de vuelta a operaciones normales. ¡Nos vemos!

Read Full Post »