Feeds:
Entradas
Comentarios

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

7 septiembre, 2020 por luismontenegroit

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!

Publicado en Artículos de Seguridad, Continuidad del Negocio | Etiquetado , , | Leave a Comment »

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

4 septiembre, 2020 por luismontenegroit

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!

Publicado en Artículos de Seguridad, Continuidad del Negocio | Etiquetado , , , | Leave a Comment »

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

1 septiembre, 2020 por luismontenegroit

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!

Publicado en Artículos de Seguridad, Continuidad del Negocio | Etiquetado , , , | Leave a Comment »

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

31 agosto, 2020 por luismontenegroit

Ya hicimos todos los preparativos para realizar el proceso de Failover, así que ya es tiempo de ejecutar esta actividad y visualizar los cambios a nivel de ambos Datacenter con los equipos.

Para iniciar el proceso de failover, seleccionamos el servidor de pruebas en la consola principal de vCloud Availability y en la sección de Actions, seleccionamos Failover.

Iniciando el proceso de failover.

En la ventana emergente configuraremos las primeras opciones de nuestro proceso. En primer lugar, nos da la opción de realizar un consolidado de todas las instancias creadas, a fin de minimizar los problemas de integridad que puedan existir. Es una opción que, al habilitarla, incrementará el RTO del proceso (tiempo de recuperación). Posteriormente, nos entrega la opción de encender el servidor en el Datacenter de Contingencia una vez finalizado el failover y nos permite cambiar la configuración de red, conectando el servidor a otra VLAN. Esto es particularmente útil si el Datacenter de Contingencia no está extendido en Capa 2 al Datacenter Principal. Una vez seleccionadas las opciones, damos clic a Next.

Configuración inicial del failover.

Posteriormente, debemos definir el punto de restauración. Es importante saber que mientras más antiguo sea el punto que escojamos, mayor debería ser la cantidad de datos perdidos en el proceso. Generalmente, se utilizan puntos antiguos cuando el failover se realiza por problemas de integridad de datos más que por un evento disruptivo desde el ámbito de la continuidad. Una vez seleccionado el punto de recuperación, hacemos clic en Next.

Seleccionando el punto de failover.

En la ventana de resumen, damos clic en Finish para confirmar el proceso de failover.

Resumen del proceso.

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

Seguimiento en línea del proceso.

Una vez terminado el proceso de failover, podremos visualizar como nuestro servidor se ha encendido en el Datacenter de Contingencia.

Servidor creado en Datacenter de Contingencia.

Por otro lado, el servidor sigue encendido en el Datacenter Principal.

En el Datacenter Principal, nuestro servidor de pruebas se mantiene encendido.

Por otro lado, en el Datacenter de Contingencia el disco independiente que visualizamos en el artículo anterior ya está asociado al server que se encuentra prendido en dicho Datacenter.

La búsqueda en el Datacenter de Contingencia del disco independiente asociado a nuestro servidor de pruebas no da resultados.

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

Tareas de creación del servidor de pruebas en el Datacenter de Contingencia. Registro de vCloud Director.
Tareas de eliminación del disco independiente, una vez que está asociado a la nueva máquina creada en el Datacenter de Contingencia.

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.

Visualización de la transferencia de archivos durante el proceso de failover.

En el caso de un escenario de Disaster Recovery real, el Datacenter Principal no está habilitado. Por ende, una vez que se restituye el servicio de dicho Datacenter y para preparar la vuelta a operaciones normales, se debe realizar la protección reversa, vale decir, habilitar el servicio de réplica, pero esta vez desde el Datacenter de Contingencia hacia el Datacenter Principal. Este aspecto lo revisaremos en el próximo artículo de esta serie. ¡Nos vemos!

Publicado en Artículos de Seguridad, Continuidad del Negocio | Etiquetado , , | Leave a Comment »

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

29 agosto, 2020 por luismontenegroit

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!

Publicado en Artículos de Seguridad, Continuidad del Negocio | Etiquetado , | 1 Comment »

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

28 agosto, 2020 por luismontenegroit

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!

Publicado en Artículos de Seguridad, Continuidad del Negocio | Etiquetado , , | Leave a Comment »

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

27 agosto, 2020 por luismontenegroit

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ónValor
Sistema OperativoWindows Server 2012 R2 x64
Memoria RAM2GB
CPU1vCPU
Disco50GB 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.

Publicado en Artículos de Seguridad, Continuidad del Negocio | Etiquetado , | Leave a Comment »

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

22 agosto, 2020 por luismontenegroit

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!

Publicado en Continuidad del Negocio | Etiquetado , , | Leave a Comment »

Business Impact Analysis (BIA): El primer paso en la definición de la estrategia de la Continuidad de Negocio Corporativa (Tercera Parte)

9 septiembre, 2019 por luismontenegroit

Determinando el RTO – La clave para priorizar los procesos de negocio

Sin lugar a duda, el objetivo principal que persigue un BIA es entregar una manera objetiva de priorizar los procesos de una organización de cara a la continuidad de negocio. Y dicha priorización quedará definida en gran medida por dos parámetros relevantes, los cuales son los siguientes:

  • RTO (Recovery Time Objective). Corresponde al máximo tiempo admitido para resumir una actividad, recuperar recursos, o proveer servicios luego de que ocurre un evento disruptivo. Este período de tiempo objetivo debe ser lo suficientemente corto para asegurar que el impacto negativo de dicha disrupción sea inadmisible. (ISO 27031:2011, 3.45 Recovery Time Objective, RTO).
  • RPO (Recovery Point Obective). Corresponde a un objetivo de recuperación de datos. Es el punto en el cual la información o datos utilizados por una actividad deben ser restaurados luego de que ocurre un incidente disruptivo. (ISO 27031:2011, 3.44 Recovery Point Objective, RPO).

Una de las actividades que son llevadas a cabo durante la ejecución de un BIA (Business Impact Analysis) es la determinación de el RTO del proceso analizado. Y esto se puede lograr en base a la determinación del impacto que una disrupción produce en el negocio a lo largo del tiempo.

En este sentido, la primera tarea a la hora de diseñar este proceso es definir los diversos tipos de impacto que una disrupción puede causar en el negocio. Este punto dependerá de la naturaleza que tiene el negocio: posiblemente los factores que más se pueden ver impactados en una empresa del rubro financiero (como un banco) serán muy distintos a los que puedan afectar a una empresa de la educación o el gobierno. A continuación, se indican algunos de los principales tipos de impacto que pueden ser utilizados en un BIA:

  • Montos involucrados. Uno de los principales impactos que produce una disrupción en un negocio es la pérdida monetaria. Y dicha pérdida puede ser de manera directa (costo asociado a la recuperación de la operación, en horas hombre, equipamientos y otros) o indirecta (dinero no percibido por la interrupción de las actividades del negocio). El mejor ejemplo para utilizar para describir este impacto es el típico escenario de sin sistema en las cajas de un supermercado: Si las cajas quedan sin sistema, se deberá invertir en un equipo de personas que recuperen los sistemas, pero además los clientes abandonarán el supermercado sin terminar sus compras hasta que el sistema vuelva, lo cual también se transforma en pérdida. Para determinar estas pérdidas indirectas, se puede recurrir a datos estadísticos que permitan proyectar el ingreso generado por el proceso, dependiendo de la hora y fecha en la cual dicha disrupción ocurra.
  • Efecto en la imagen. Otro impacto que puede ocasionarse debido a una disrupción es el daño en la imagen corporativa de la compañía, el cual puede traducirse en pérdida de clientes actuales o alejamiento de potenciales clientes de esta. En este sentido, el auge de las redes sociales y los medios de denuncia masivos hacen de que dicho factor pueda transformarse en relevante a la hora de determinar un RTO.
  • Impacto normativo. En las compañías que están sujetas a entes reguladores, el impacto de una disrupción a nivel normativo puede traducirse en observaciones, sanciones e incluso restricciones para la operación de la compañía que se ve afectada por una disrupción.
  • Impacto a nivel operacional. Como bien es sabido, rara vez un proceso de negocio será totalmente independiente del resto de los procesos de la compañía. En este sentido, un proceso de disrupción que afecte un proceso de negocio puede terminar afectando otros procesos a nivel corporativo.
  • Masividad. El impacto que una interrupción de un proceso de negocio produce puede medirse en base a la cantidad de transacciones que se ven interrumpidas o la cantidad de clientes que se puede ver afectados.

Una vez que se definen los factores que serán medidos para determinar el RTO, se debe crear una matriz que permita determinar el nivel de impacto en base a una escala. A continuación, se presenta un ejemplo de ello.

Factores de Impacto (Ejemplo)

Durante la ejecución del BIA, se medirá el impacto de cada uno de los factores de impacto a lo largo del tiempo. En este punto, se deben definir las escalas de RTO posible (Menor a 1 hora, entre 1 y 2 horas, entre 2 a 6 horas, etc.) y se debe determinar cual será el impacto de la disrupción en los diversos factores. Una vez que se determina que el impacto global es inadmisible, se define el RTO. La definición de qué será considerado inadmisible se puede realizar dentro del diseño del BIA (puede ser, por ejemplo, la primera banda donde exista al menos un impacto en nivel catastrófico).

Ejemplo de cálculo de RTO.

El RTO, en conjunto con el RPO, se transforman en dos factores claves que permitirán definir cuales son los procesos más críticos del negocio de cara a la continuidad operativa. Una vez que el análisis BIA se ha realizado a todos los procesos relevantes de la organización, se puede determinar en que casos es relevante generar planes de continuidad del negocio (BCP). Esto lo abordaremos en un próximo capítulo. ¡Hasta entonces!

Publicado en Artículos de Seguridad, Continuidad del Negocio | Etiquetado , , | Leave a Comment »

Business Impact Analysis (BIA): El primer paso en la definición de la estrategia de la Continuidad de Negocio Corporativa (Segunda Parte)

18 agosto, 2019 por luismontenegroit

Identificando los componentes críticos del proceso

Uno de los principales objetivos que debe perseguir un análisis de impacto de negocio (BIA) es la identificación de los componentes críticos que cada proceso tiene, de cara a la continuidad del negocio. Es por esto que la ficha BIA debe contener sí o sí un conjunto de secciones que permitan identificar, para cada proceso analizado, los siguientes componentes:

Aspectos críticos del proceso de cara a la continuidad del negocio.
  • Personal crítico del proceso. Dentro de este ítem se deben identificar aquellas personas que son clave en la ejecución del proceso, dentro de los que destacan los siguientes:
    • Responsable del proceso y su respectivo backup.
    • Administradores funcionales y técnicos de las aplicaciones clave utilizadas por el proceso y sus respectivos backups.
    • Número de personas dedicadas a tiempo completo para la ejecución del proceso.
    • Número de personas que están dedicadas a otros procesos y que podrían ejecutar el proceso en modalidad de backup.
    • Número mínimo de personas necesarias para ejecutar el proceso con normalidad.
    • Detalle del personal crítico del proceso, indicando sus nombres, datos de contacto y función específica dentro del proceso.
  • Aplicaciones clave del proceso. En este punto, es importante determinar, en la medida de lo posible, los siguientes aspectos:
    • Aplicaciones indispensables para la ejecución del proceso (aplicaciones que de estar ausentes el proceso no funciona con normalidad)
    • Aplicaciones alternativas para la ejecución del proceso, en caso de ausencia de aplicaciones críticas
    • Aplicaciones relacionadas con la ejecución del proceso (por ejemplo, correo electrónico)
  • Relación entre las aplicaciones críticas y los servidores. Este punto está relacionado con los conceptos de mapa aplicativo o CMDB. En la medida de lo posible, un BIA debería permitir identificar los servidores críticos para la ejecución de los procesos analizados. Este punto es uno de los más complejos a la hora de realizar esta actividad, debido a que la generación de un mapa aplicativo, sobre todo en empresas grandes, puede ser un proceso extremadamente complejo.
  • Registros vitales. En caso de que los procesos requieran como entrada para su ejecución ciertos registros (ya sea físicos o virtuales), estos deben ser debidamente identificados. Además, es ideal determinar su ubicación y las políticas de respaldos asociados a dichos registros.
  • Ubicaciones de ejecución de los procesos. Para el caso de aquellos procesos que se realicen de forma física, se debe determinar las ubicaciones donde dichos procesos deben ser realizados, y se debe determinar la ubicación alternativa donde dichos procesos puedan ser realizados.
  • Proveedores involucrados. Para el caso de aquellos procesos que sean ejecutados parcial o totalmente por proveedores, se deben identificar los siguientes aspectos:
    • Nombre de los proveedores involucrados y su función dentro del proceso
    • Gestor de contrato responsable de los proveedores
    • Proveedores de backup para el proceso, en caso de que existan

La recopilación de estos componentes permitirá comprender la estructura del proceso de cara a la continuidad de negocio e identificar los puntos de falla que permitirán alimentar el proceso del RIA.

En el próximo capítulo de esta serie, les compartiré algunos tips para determinar el RPO y el RTO de un proceso, dentro del análisis BIA.

Publicado en Continuidad del Negocio | Etiquetado , | Leave a Comment »

Older Posts »