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 »

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

En el artículo anterior revisamos el proceso de prueba de failover de un servidor utilizando vCloud Availability de VMware. A continuación, entraremos en tierra derecha analizando el proceso de failover y como se reflejan las actividades dentro de esta fase. Comencemos.

La situación previa al failover

Cuando realizamos la protección de nuestros servidores utilizando la herramienta vCloud Availability, lo que hacemos es crear una unidad de disco independiente que no queda asociada a máquina virtual alguna. Esta unidad se asocia a las réplicas que se realizan de cada servidor protegido; así podremos corroborar que, si no hemos aplicado failover a ningún servidor del Datacenter Principal, el Datacenter de Contingencia no tendrá máquinas encendidas, pero sí tendrá unidades de disco creadas según cuantas máquinas estemos protegiendo.

En el Datacenter Principal, tenemos 99 máquinas, de las cuales 89 están protegidas.

En el Datacenter de Contingencia, no hay servidores encendidos.

Sin embargo, en el Datacenter de Contingencia hay 89 discos independientes creados, los cuales están asociados a los 89 servidores protegidos.

Cuando creamos la protección hacia nuestro servidor de pruebas, vCloud Availability identifica la unidad de disco independiente que creó en el Datacenter de Contingencia. Esto podemos revisarlo haciendo clic en la sección Replication Tasks de la consola de administración de la herramienta.

Identificando el ID de Disco asociado al servidor de pruebas.

Esto lo podemos corroborar en el Datacenter de Contingencia, buscando los discos independientes por su ID.

Encontramos el disco independiente asociado a nuestro servidor de pruebas en el Datacenter de Contingencia.

Preparando el proceso de failover

Escribí este artículo al día siguiente de que establecí la protección del servidor de pruebas usando vCloud Availability. Esto lo hice para poder generar varios puntos de restauración y réplica durante la noche y así poder verificar que este trabajo se hizo adecuadamente para así realizar el failover más tarde.

Una vez ingresando en la consola principal de vCloud Availability, vamos a ir a la sección Outgoing Replications – To Cloud para buscar nuestro servidor y verificar el status del servicio de réplica.

Verificando el estado del servicio de réplicas para nuestro servidor de pruebas.

En el panel de control podremos corroborar rápidamente si nuestro servidor se encuentra en buen estado en cuanto a su servicio de réplicas, encontrando además información útil sobre el RPO, su última sincronización y el perfil de SLA que posee el mismo. Más abajo, podemos pinchar en Instances para visualizar el estado de la generación de instancias, en base a la política que definimos para el servidor al momento de crear la protección. Esta vista la podemos tener en formato lista o gráfico.

Vista de réplicas – Lista.

Vista de réplicas – Gráfica.

Como dato interesante, debido a la configuración del RPO, siempre se debe generar una réplica en un intervalo inferior al definido como RPO, lo cual pude corroborar dado que mientras sacaba las capturas de pantalla el sistema volvió a replicar.

Nueva réplica, 5 minutos después.

La visión de réplicas nos muestra gráficamente que cada 5 minutos aparece una nueva réplica, no persistente, que reemplaza la anterior, y adicionalmente a esto, cada 4 horas se genera una réplica persistente (o instancia), acorde a la configuración que aplicamos para la protección. Es momento entonces de ejecutar el proceso de failover. Y esto lo veremos en el siguiente artículo de esta serie. ¡No se lo pierdan!

Read Full Post »

Usando VCloud Availability para escenarios de Disaster Recovery (Parte 3)

En el artículo anterior revisamos el proceso de protección de un servidor utilizando vCloud Availability de VMware. A continuación, nos adentraremos en la siguiente fase del ciclo: el failover. Y para ello, utilizaremos una funcionalidad que posee vCloud Availability que se llama Test Failover. Comencemos.

Probando el failover sin afectar el servicio

En un proceso normal de failover, a partir del disco “oculto” en el Datacenter de Contingencia se crea un servidor de iguales características al original (manteniendo la configuración de disco, CPU, memoria y red), para posteriormente encenderlo y culminar el proceso.

Sin embargo, una estrategia atractiva utilizada para propósitos de troubleshooting o para realizar la primera prueba de un DRP es utilizar la opción de Test Failover de vCloud Availability. Esta opción permite levantar una copia de la máquina de origen en el Datacenter de Contingencia sin apagar el servidor original. Esto permite, por ejemplo, probar distintas instancias a fin de detectar cual de ellas no alcanzó a ser afectada por un malware y restablecer de manera definitiva el servidor afectado a partir de dicha instancia.

Por otro lado, la opción de Test Failover puede ayudar a realizar pruebas funcionales, aunque por lo general este proceso tiene limitantes a nivel de red. Esto porque al ser una copia del equipo replicado, conectar dicha máquina directamente a la red podría causar más de un conflicto.

Para realizar un test failover, debemos ubicar nuestro servidor en la consola principal de vCloud Availability y seleccionar la opción Test Failover.

Iniciando un proceso de Test Failover.

El asistente de este proceso es muy sencillo. En la primera opción podemos seleccionar si queremos o no encender la VM o si la queremos configurar a alguna red en particular. Una vez seleccionadas las opciones, damos clic en Next.

Configurando el test failover.

Posteriormente, debemos seleccionar la instancia de recuperación. Aquí aparecen dos opciones; la primera de ellas apunta a usar la última réplica existente (que debe estar dentro del rango de RPO configurado), o bien, utilizar una instancia anterior. Esto dependerá de la configuración de instancias que hayamos seleccionado cuando creamos la réplica para este servidor. El asistente, al seleccionar la segunda opción, muestra gráficamente las réplicas existentes, por lo que podemos seleccionar la que queramos utilizar.

Seleccionando la instancia para hacer el test.

Resumen del proceso.

El proceso de prueba del failover es por lo general bastante rápido y efectivo. Una vez completado, tendremos a nuestro servidor original en el Datacenter Principal funcionando de manera normal y una copia de dicho servidor en el Datacenter de Contingencia, el cual podremos abrir y revisar cuando estimemos conveniente. Una vez terminadas las pruebas, debemos seleccionar la opción Test Cleanup para borrar la máquina con la cual hicimos la prueba.

Realizando el cleanup para culminar el proceso.

Y esto es todo por hoy. En el siguiente artículo, haremos un failover, para medir tiempos, y estableceremos la protección reversa para asegurar la réplica desde el Datacenter de Contingencia hacia el Datacenter Principal. ¡Nos vemos!

Read Full Post »

Usando VCloud Availability para escenarios de Disaster Recovery (Parte 2)

En el artículo anterior describimos el proceso general de Disaster Recovery utilizando vCloud Availability de VMware. A continuación, nos adentraremos en las distintas fases del ciclo, para lo cual hemos montado en nuestro ambiente una máquina de pruebas con las siguientes especificaciones:

Especificación	Valor
Sistema Operativo	Windows Server 2012 R2 x64
Memoria RAM	2GB
CPU	1vCPU
Disco	50GB en una unidad

Especificaciones del servidor de pruebas.

Fase 1: Protección

En la primera fase del proceso, se debe habilitar el servicio de réplicas hacia el Datacenter de Contingencia. En esta etapa se definirán ciertos parámetros clave para el proceso, los cuales revisaremos en el paso a paso.

En la primera fase del proceso, se debe habilitar el servicio de réplicas hacia el Datacenter de Contingencia. En esta etapa se definirán ciertos parámetros clave para el proceso, los cuales revisaremos en el paso a paso.

Una vez que ya iniciamos sesión en la herramienta (que está previamente instalada tanto en el Datacenter Principal como en el de Contingencia, debemos ingresar a la sección Outgoing Replications. En esta sección aparecerán todos aquellos servidores para los cuales el servicio de réplica esté habilitado, tanto hacia otro Datacenter en la nube como hacia plataformas On-Premise. En este caso, utilizaremos la sección To Cloud y pincharemos All Actions, para luego dar clic en New Protection.

Configurando la protección en vCloud Availability.

Después de iniciar sesión con las credenciales de vCloud Availability en el Datacenter de Contingencia, en la ventana emergente, localizamos el servidor al cual habilitaremos la réplica, para luego hacer clic en Next.

Definiendo el servidor a replicar.

En la siguiente ventana, se deben configurar las políticas de storage y la organización de destino en donde se instalará el servicio de réplica. Una vez configurado esto, daremos clic en Next para pasar a la configuración medular de la réplica.

Definiendo Datacenter de Destino.

Definiendo política de storage.

El primer punto que configurar tiene relación con el RPO. El RPO o Recovery Point Objetive guarda relación con la cantidad de data que estamos dispuestos a perder en caso de existir un escenario de desastre. Esto cobra especial relevancia en los servidores transaccionales, que deberían apuntar a un RPO bastante pequeño a fin de que, en caso de una pérdida de servicio que obligue a un proceso de failover, disminuya la cantidad de transacciones perdidas o corruptas. En los servicios no transaccionales, se puede configurar un RPO mayor ya que no se espera que estos servidores sufran grandes cambios a nivel estructural en el tiempo.

Configuración de la protección.

RPO.

Ahora bien, la definición de RPO impacta directamente en la frecuencia de réplicas que tiene el servicio. Herramientas como vCloud Availability realizar réplicas similares a un backup incremental y su frecuencia dependerá directamente de la configuración del parámetro de RPO. Esto quiere decir que si configuro un RPO de 5 minutos, el sistema tiene como máximo 5 minutos entre réplicas, a fin de garantizar que en caso de que se tenga que aplicar un failover, la data recreada en el Datacenter de Contingencia tenga a lo sumo 5 minutos de antigüedad. Esta herramienta permite parametrizar el RPO en un rango que varía desde los 5 minutos hasta las 24 horas.

Otro punto relevante en la configuración del servicio de réplicas guarda relación con las instancias.

Configurando instancias.

El servicio de réplica, al realizarse de manera tan continua (podrían realizarse como máximo 288 réplicas diarias) podría impactar fuertemente en el uso de disco. Para evitar esto, el servicio está diseñado para mantener solamente la réplica más reciente como disponible, vale decir, cada réplica va “pisando” la anterior. Esta característica de diseño implica un riesgo inherente al servicio: si la máquina de origen por algún motivo queda corrupta (malware, borrado accidental de datos, etc.), en cosa de minutos será replicada al Datacenter de Contingencia en las mismas condiciones. Por este motivo, si el failover está motivado, por citar un ejemplo, en un evento de ramsonware, no solucionará el problema, sino que lo replicará al Datacenter de Contingencia. En estos casos y como una alternativa al uso de respaldos, es que el servicio de réplicas usa el concepto de instancias.

Las instancias son réplicas persistentes, y vCloud Availability permite almacenar hasta 24 instancias para tener puntos de restauración adicionales que permitan volver a un momento anterior al de la última réplica realizada. Esto permitiría recuperar equipos que han sido afectados a nivel de integridad de datos a un estado previo al evento. Además de configurar el número de instancias (desde 1 a 24) se puede configurar el tiempo en el cual se quieren distribuir estos puntos, lo que varía desde 1 día hasta 1 año. Así, si se configura una política de 24 instancias en 1 día, esto quiere decir que se generarán puntos de réplica persistentes cada 60 minutos.

Considerando que el proceso de protección generará una réplica inicial del total del disco del servidor a proteger, se ha añadido la alternativa de programar esta réplica inicial a una fecha y hora posterior, a fin de minimizar el impacto a nivel de redes que pueda ocasionar este proceso.

Configuración de primera réplica.

Finalmente, se puede configurar una exclusión de discos no necesarios para optimizar el proceso o usar una copia antigua de otras máquinas ya protegidas para reducir el tráfico de red. A esto último se le llama Seed VMs o Máquinas semilla.

Configuraciones adicionales.

Una vez que damos clic en Next, muestra un cuadro resumen de la configuración y podemos dar clic en Finish para terminar el proceso de protección.

Resumen de configuración.

Una vez que se inicia el proceso de configuración, vCloud Availability crea un objeto de disco en el Datacenter de Contingencia, el cual queda oculto y no queda asociado a ninguna máquina. Posterior a eso, se establece el proceso de réplica inicial, en el cual se envía en formato comprimido el disco utilizado al Datacenter de Contingencia. Para propósitos de esta prueba, el sistema se demoró cerca de 8 minutos en sincronizar aproximadamente 9,5 GB iniciales de Datos.

Estadísticas de flujo de datos en tiempo real durante la primera réplica.

Datos sobre las réplicas creadas.

Y ¡esto ha sido todo por hoy! El próximo artículo será para ahondar en el proceso de failover, pasando primero por la prueba de este. Nos vemos en otra ocasión.

Read Full Post »

Usando VCloud Availability para escenarios de Disaster Recovery (Parte 1)

Una de las estrategias de Disaster Recovery más utilizadas en los entornos de Datacenter virtualizados es el uso de herramientas de réplica de máquinas virtuales entre un Datacenter Principal y un Datacenter Secundario (o de Contingencia). Estas herramientas están continuamente replicando en segundo plano los cambios a nivel de configuración y contenido de los servidores hacia el segundo Datacenter, manteniendo los servidores en dicho Datacenter apagados hasta el momento en que sea necesario aplicar un proceso de Failover. En este sentido, las herramientas de réplica constituyen una estrategia de contingencia que, si bien es manual, es muy eficiente, dado que el proceso de Failover de un servidor puede resolverse en cosa de minutos.

En los siguientes artículos, revisaremos como funciona el proceso de Disaster Recovery usando una herramienta de réplica nativa de VMware: vCloud Availability.

Según indica VMware en su descripción de producto (https://www.vmware.com/cl/products/cloud-director-availability.html), vCloud Availability es una herramienta de tipo DRaaS (Disaster Recovery as a Service), la cual se ha diseñado para ofrecer diversos servicios de incorporación, migración y recuperación ante desastres a través de un proceso sencillo, seguro y rentable, entre Datacenters Virtuales (VDC).  Esta solución forma parte de la plataforma de proveedor de nube de VMware (VMware Cloud Provider Platform) y como tal se integra de forma nativa con VMware Cloud Director. Por otra parte y en cuanto a seguridad, que es un aspecto siempre relevante en este tipo de soluciones, los datos en reposo y en circulación asociados al servicio de réplica se encuentran cifrados, además de ofrecer compresión integrada del tráfico de replicación y cifrado TLS integral.

El proceso de Disaster Recovery utilizando vCloud Availability consiste en una serie de fases, que se describen en el siguiente diagrama y que serán analizados en los siguientes artículos:

Fases de un proceso de Disaster Recovery usando vCloud Availability.

• Protección. Corresponde a la fase inicial del proceso, en donde se establece la primera réplica del servidor desde el Datacenter Principal al Datacenter de Contingencia y se configura el servicio de réplica continua.
• Failover. Corresponde a la primera actividad propia de un proceso de Disaster Recovery. En esta fase, se activa el Servidor en el Datacenter de Contingencia usando una réplica disponible desde el Datacenter Principal. En caso de que el servidor en el Datacenter Principal aún estuviese encendido, en esta fase dicho servidor es apagado.
• Protección Reversa: Una vez que el servidor ya se encuentra operativo en el Datacenter de Contingencia, se debe habilitar el servicio de réplica en el sentido inverso, vale decir desde el Datacenter de Contingencia hacia el Datacenter Principal.
• Failback (Failover inverso). De manera similar al proceso de Failover, en esta fase de vuelta a operaciones normales se utiliza una réplica disponible desde el Datacenter de Contingencia para volver a habilitar el servidor en el Datacenter Principal.
• Reprotección: Una vez vuelto el servidor a operaciones normales, se habilita nuevamente el servicio de réplica hacia el Datacenter de Contingencia, cerrando el ciclo.

En el próximo artículo, revisaremos la primera fase de este proceso: La protección de los servidores.

¡Nos vemos!

Read Full Post »