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 »

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

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!

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 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 »

Fundamentos de un DRP (Disaster Recovery Plan)

Un plan de recuperación de desastres (conocido según la ISO 27031:2011 como ICT Disaster Recovery Plan o ICT DRP) es un plan claramente definido y documentado que permite recuperar las capacidades de tecnologías de información y comunicación (Information and Communication Technologies) cuando ocurre una disrupción. (ISO 27031:2011, 3.8 ICT DRP).

La ISO 27031 (Information Technology — Security techniques — Guidelines for information and Communication Technology readiness for business Continuity) define además una disrupción como un incidente, ya sea previsible (como por ejemplo un huracán) o no previsible (como por ejemplo un corte general de energía eléctrica, un terremoto o un ataque físico o lógico a la arquitectura de ICT) que pueda causar una interrupción al curso normal de las operaciones de una organización o empresa (27031:2011, 3.6 Disruption).

El desarrollo de un plan de recuperación de desastres es una de las actividades clave dentro de la gestión de la continuidad del negocio. La gestión de la continuidad del negocio, conocida por sus siglas en inglés BCM (Business Continuity Management) es un proceso de gestión holístico que identifica los potenciales impactos que amenacen la continuidad de las actividades de negocio de una compañía, entregando un marco de trabajo que permita construir resiliencia y capacidad de respuesta efectiva que proteja los intereses de una organización de las disrupciones.

Como tal, el plan de recuperación de desastres corresponderá a una serie de actividades que permitirán al negocio reaccionar de manera efectiva y eficiente ante la ocurrencia de un incidente. Estas actividades se pueden describir en las siguientes fases, cuya relación se ilustra en la figura 1.

• Detección. Corresponde a la fase inmediatamente posterior a la ocurrencia del incidente. En líneas generales, la detección del incidente debería realizarse de forma proactiva, (como parte del proceso de gestión de eventos y monitoreo) o reactiva (a través de un proceso de gestión de incidentes).
• Activación del plan. Una vez que el incidente está declarado, se debe realizar el proceso de activación del plan de recuperación de desastres, el cual implica el desarrollo de un proceso comunicacional entre el cliente y su proveedor de servicios que permita autorizar la aplicación del plan y la posterior formalización de dicha autorización hacia los equipos del proveedor que estarán a cargo de la resolución del incidente y la recuperación de las operaciones normales del cliente. Cabe destacar que la activación de un plan de recuperación de desastres debe ser realizada siempre por parte de este último.
• Recuperación. La fase de recuperación, posterior a la activación del plan, corresponde al desarrollo de dos procesos en paralelo, que son los siguientes:
  • Plan de operación alternativo. Corresponde a las actividades orientadas a restablecer las operaciones críticas del cliente en el menor tiempo posible. En algunos casos, este proceso de operación alternativo puede suponer la reposición parcial del servicio, priorizando las funciones primordiales del negocio por sobre otras componentes del servicio secundarias.
  • Resolución del incidente que ocasionó la disrupción. En paralelo a la aplicación del plan de operación alternativo, el proveedor deberá trabajar en la resolución del incidente que causó la condición de desastre. Esto implica la detección de la causa raíz del incidente y la gestión posterior para resolverlo. Esto podría implicar ajustes de configuración, reemplazo de equipos u otras actividades que permitan establecer las condiciones necesarias para volver a la operación normal.
• Retorno a operaciones normales. Una vez que los procesos de recuperación están completos y el servicio está en condiciones de volver a operar con normalidad, se debe gatillar el proceso de vuelta atrás del plan de operación alternativo. Dependiendo de la estrategia de recuperación definida en el plan, este proceso de vuelta atrás podría ser transparente para el cliente o podría tener impacto en la continuidad de sus servicios. En ese sentido, en la fase de retorno a operaciones normales se deben definir estrategias para autorizar, programar y ejecutar este proceso de manera de minimizar el impacto que dichas actividades puedan ocasionar en la continuidad de la prestación de los servicios involucrados.

Pronto nos vemos con otro artículo sobre Continuidad del Negocio o Seguridad de la Información!

Read Full Post »