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.
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?
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.
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.
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?
¿Cómo utilizar el Cloud como centro de contingencia?
- Sincronización de volúmenes y levantamiento automatizado.
- 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
- 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
- Coste de servicios de nube (almacenamiento): Bajo
- Coste de gestión, personal: Bajo
- RTO y RPO: Bajo
- ¿Cómo funciona DRaaS?
- 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.