Estrategia de Disaster Recovery

Cuando hablamos de contingencia y de recuperación ante desastres, a menudo nos topamos con dos cuestiones:

¿Cuál es el impacto económico de una caída de servidores?
(En función de la respuesta a la pregunta anterior)
¿Cuánto debo invertir en mi entorno de contingencia y en la operativa de recuperación de datos?

En este artículo haremos un repaso de las alternativas que tenemos disponibles y daremos nuestro punto de vista sobre aquellas que entendemos más adecuadas en función de la criticidad y el modelo de negocio.

AWS disaster recovery 3 Desafortunadamente, llego ese día que nunca debería haber llegado: Tu centro de datos ha tenido un problema crítico y no es capaz de ofrecer servicio, por lo que tu operativa se ve impactada y no es posible continuar con tu negocio con normalidad.

En este momento, saltan todas las alarmas y comienza a buscarse la forma más rápida y eficaz de poner en marcha los servicios IT que sirven como base a los procesos de negocio de la empresa.

En un mundo ideal, tendrías otro centro de datos alternativo (centro de contingencia) que, en esta situación, cogería el testigo y comenzaría a ofrecer servicio, partiendo del último punto en que el centro de datos principal ofreció servicio correctamente y sin perdida de datos.

RPO* = 0 y RTO** = 0

"Sin corte en el servicio y recuperación de manera instantánea"

*Recovery Point Objective

**Recovey Time Objective

¿Tu estrategia de Disaster Recovery ofrece el RTO y el RPO requeridos por negocio?

Aquí está la clave, en la inmensa mayoría de las compañías no se dan estas condiciones por factores como:

Disponibilidad de recursos económicos para duplicar la IT (Hardware, Licencias, CPD, Gestión, etc).
Disponibilidad de equipos dedicados a mantener estos recursos “de emergencia” para que estén listos para entrar en acción cuando sea necesario, 24x7.

Al final, todo se reduce a que no se suele disponer de una partida económica que habilite a duplicar la IT con el objetivo de tener RTO y RTO = 0.

En este sentido, la experiencia que hemos obtenido en Neteris gracias al trabajo realizado en varios de nuestros clientes nos dice que lo ideal es entender cuáles son las necesidades reales de negocio en torno a los valores que realmente se necesitan de RTO y RPO combinados con la partida presupuestaria disponible.

¿Qué aspectos he de tener en cuenta al elaborar mi estrategia de Disaster Recovery?

Como viene siendo de costumbre, desde Neteris apostamos por entender la necesidad y proponer la mejor solución a la misma, ya que, en función de la tipología de negocio, la solución y el Plan de Contingencia podrá ser uno u otro.

Los factores a tener en cuenta son los siguientes:

uno 1 Criticidad de los entornos: Hay que establecer unas prioridades que van desde críticos productivos hasta no críticos y no productivos.

En caso de desastre, lo más seguro es que no pensemos en el entorno de desarrollo, sino en mantener la producción viva hasta que se estabilice la situación.

dos 2 Dependencias entre los entornos: Puede darse el caso de que varios aplicativos trabajen conjuntamente con un mismo fin, por lo que hemos de agruparlos para evitar que haya alguno de ellos quede fuera y evite que el conjunto siga trabajando.

tres 3

Coste de la parada de servicio: Sin importar la naturaleza de la perdida, ya sea por pérdida económica directa, por penalizaciones, por incumplimiento de SLAs o por perdidas asociadas a perjuicio en la imagen de marca. De aquí obtendremos el RPO y RTO requeridos por negocio.

Disponibilidad de recursos y de conocimiento: Para elaborar una estrategia e implantar una metodología que garantice el RTO y RPO definido de cada grupo de aplicativos y/o entornos en función de su criticidad e impacto en negocio.

¿Qué opciones tengo a la hora de desplegar un entorno de Disaster Recovery, si mi entorno permanece en On Premise?

Como es lógico, la primera opción que se nos podemos plantear es montar un centro de datos gemelo al que ya tenemos. No obstante, los costes de adquisición, mantenimiento y ciclo de vida, la disponibilidad de equipos, y demás, hace que no suela ser la solución más popular. Lo ideal es buscar un equilibrio entre coste, RTO, RPO y complejidad de gestión y mantenimiento.

Pensemos en una situación adversa acontecida en nuestro centro de datos principal, como un pico de carga al que no somos capaces de responder, que aparece sin previo aviso y que tiene una criticidad máxima.

Siempre decimos que el Cloud es la mejor solución para cargas de trabajo que requieren agilidad, escalabilidad y elasticidad, lo cual describe a la perfección una situación de contingencia como esta.

¿Cómo utilizar el Cloud como centro de contingencia?

Las opciones que tenemos son las siguientes:

- Sincronización de volúmenes y levantamiento automatizado.

Es la solución más manual, puesto que mantenemos los volúmenes de datos en la nube sincronizados con los volúmenes en On Premise y establecemos la operativa de levantamiento de los servicios mediante Infraestructura como Código, ya que habremos definido previamente el mapa de infraestructura en alguna tecnología como Terraform.

Coste de servicios de nube (almacenamiento): Muy bajo
Coste de gestión, personal: Alto
RTO y RPO: Alto

- Centro de datos gemelo en la nube

Sería el equivalente a la solución ideal que planteábamos en el inicio pero en la nube pública. Tendríamos levantado nuestro centro de datos en la nube listo para entrar en juego ante un fallo en nuestro centro de datos On Premise.

Coste de servicios de nube (almacenamiento): Muy Alto
Coste de gestión, personal: Medio
RTO y RPO: Bajo

- Soluciones Disaster Recovery as a Service – DRaaS

Una vez vistos los 2 extremos, terminamos comentando la solución más demandada, ya que optimiza el uso de recursos usados en la nube (con lo cual ahorramos frente a la opción de gemelo en la nube), sin tener gran penalización de RTO y RPO, al gestionarse el levantamiento del entorno de contingencia de una manera más automatizada y ágil, así como con menor coste de gestión y personal.

Coste de servicios de nube (almacenamiento): Bajo
Coste de gestión, personal: Bajo
RTO y RPO: Bajo

- ¿Cómo funciona DRaaS?

Si entramos más en detalle, las soluciones DRaaS no son más que soluciones que facilitan y agilizan las tareas que han de formar parte de una estrategia de contingencia:

Sincronización de datos continua, manteniendo los datos en la nube sincronizados con los datos en las instalaciones On Premise.
Test de contingencia, permitiendo probar que el plan de recuperación de desastres funciona correctamente.
Mantenimiento del ecosistema IT, mediante monitorización y pruebas periódicas.
Failover, es decir, lanzamiento de las instancias en la nube pública, las cuales partirán del último estado sincronizado en el instante anterior a la situación de contingencia.
Failback, o vuelta a la normalidad, replicando los cambios producidos en el centro de datos de contingencia y retornando las cargas hacia el centro de datos principal.

Con este tipo de servicios, podemos hablar de escenarios con RPO de pocos segundos y RTO de pocos minutos, en función de la complejidad de la infraestructura a levantar y la volumetría de datos a mantener sincronizados, entre otros factores.

Evalúa y analiza con nosotros cuál es la mejor combinación de opciones para optimizar costes y evitar tiempos de parada en tus entornos críticos

Blogs relacionados:

> Automatiza tu plan de AWS Disaster Recovery

> Ciberseguridad y Cloud ¿Amigos o Enemigos?