Fases de Implantación

Assessment

Fase previa del proyecto. En esta fase se analizan las necesidades y se establecen las condiciones del servicio (RTO, mecanismos de replicación, etc). Durante el assessment se determina:

• El mecanismo de replicación idóneo para cada aplicación (hipervisor, agente, mecanismos propios de la aplicación).
• La consistencia mínima necesaria para que todas las aplicaciones puedan iniciar sus servicios en el sitio de contingencia (crash, file, application).
• El RTO que puede esperarse de todo el plan a partir de las aplicaciones y volumen de datos que conforman la plataforma protegida.

Instalación y puesta en marcha

En esta fase se procederá a la configuración de las replicaciones a nivel de hipervisor, cabina y, si es necesario, la instalación de servidores para las replicaciones propias de cada aplicación que lo requiera (por ejemplo, replicación de Exchange 2010). También en esta fase se procederá a:

• Creación de los scripts y reconfiguraciones necesarias (red, nomenclatura, dns) para el correcto funcionamiento del plan de recuperación.
• Ejecución de las primeras pruebas de recuperación y establecimiento del RTO de referencia.
• Creación de un Plan de Recuperación de Desastres. Se trata de un documento consensuado con el cliente en el que se establece:

o    El protocolo para la declaración formal de un desastre y el procedimiento de activación del sitio de contingencia. Esto incluye teléfonos de contacto, personas autorizadas, etc.

o  Los resultados de los primeros test de recuperación, que determinarán el RTO y RPO objetivo que habrá de mantenerse en futuras pruebas (y que quedará reflejado en la SLA del servicio).

o  Si existen terceras partes implicadas (desarrolladores, gestores de aplicaciones del cliente), se establecerán los protocolos de entrega del servicio, que determinarán cuales son las responsabilidades de cada una de las partes en las pruebas periódicas y en el caso de desastre.

Gestión del Servicio

Una vez iniciado el proyecto, se realizaran pruebas periódicas que permitan garantizar la respuesta óptima en caso de desastre.

• Al utilizar  virtualización en el sitio de contingencia, podemos llevar a cabo simulacros de recuperación sin afectar al sitio protegido.
• Esta facilidad reduce el riesgo de fallos en la recuperación cuando esta sea necesaria. Durante la prueba se simula la recuperación total de los servicios y se detecta cualquier discrepancia entre el plan de recuperación y los cambios que hayan podido hacerse en el sitio protegido. De este modo el plan de recuperación se mantiene actualizado.
• Las pruebas de recuperación son bimestrales, a no ser que se requieran pruebas adicionales.
• Las pruebas periódicas nos ayudan a detectar cambios en el RTO y tomar acciones correctivas.

Modalidades

Virtual RaaS

· Todos los dispositivos del sitio primario que deben ser protegidos están virtualizados (plataforma VMWare de NEXICA).
· No hay dispositivos de red dedicados, o estos pueden ser omitidos en la replicación.
· La consistencia mínima requerida es crash consistancy.
· El RPO puede ser de horas

Cloud RaaS

Mismas características que Virtual RaaS, pero en la plataforma vCloud Director y cuando se requieran configuraciones adicionales para sustituir las funcionalidades del Cloud no replicadas (aislamiento de red, NAT’s, etc.).

Hybrid RaaS

· Existen servidores o dispositivos de red físicos que deben ser protegidos.
· La replicación se establece siempre a través de DoubleTake (no existe replicación a nivel de aplicación).
· La consistencia mínima requerida es crash consistancy (aunque en muchos casos se garantizará a nivel de fichero o aplicación)
· El RPO puede ser de horas (es decir, el cliente acepta perder algunas horas de datos).

Complex RaaS

Cualquier escenario en el que sea necesario establecer replicaciones a nivel de aplicación para garantizar la consistencia a nivel de aplicación y un RPO de minutos o segundos. Por ejemplo:

• Exchange 2010 (replicación nativa).
• Oracle RAC (Data Guard).
• Active Directory (replicación nativa).

* El RTO depende de muchos factores, como la cantidad de servidores protegidos, el volumen de información a recuperar, el tiempo que se tarda en declarar el desastre, etc.
** Para las aplicaciones replicadas con mecanismos propios, el RPO es de minutos o segundos. Para el resto de la plataforma, de horas.