¿Cuántas veces hemos escuchado frases como "si algo puede fallar, fallará, y en el peor momento" o hemos hecho referencia a la Ley de Murphy? Probablemente miles de veces, especialmente en nuestra área. Aunque solemos bromear al respecto, ¿cuántos de nosotros realmente tomamos estas frases en serio y planificamos con la posibilidad de que ocurra lo peor?
Planificar para lo inesperado es esencial para garantizar que nuestro negocio podrá mantenerse a flote, permitiendo que nuestras cargas de trabajo soporten el embate de eventos desafortunados.
Estos eventos pueden variar desde situaciones de pequeña o mediana escala hasta incidentes de proporciones épicas. Para amenazas comunes y de magnitud controlable, los esquemas de alta disponibilidad (HA) ofrecen una protección adecuada. Sin embargo, los eventos de gran magnitud requieren un enfoque más robusto: la implementación de estrategias de Recuperación ante Desastres, que es precisamente el tema en el que nos queremos enfocar.
Algunos conceptos básicos detrás del DR
¿Qué es un desastre?
Un desastre puede definirse como cualquier evento desafortunado que impide que la carga de trabajo logre su cometido. Aunque estos eventos son poco comunes, suelen ser graves: desastres naturales, fallas técnicas catastróficas o errores humanos, ya sean intencionados o no.
¿Cuál es el costo de un desastre?
La respuesta es variable y como diría un colega y amigo depende, y de qué depende, de la criticidad que tenga la carga de trabajo (definamos carga de trabajo como cualquier conjunto de servicios, sistemas etc. que generan valor) para nuestro negocio, una salida de operación de un sistema critico puede ser caro en dinero, en costo de oportunidad, en imagen ninguna excluyente. Imaginemos una tienda en línea que se ve afectada por un desastre en Black Friday o en Cyber Monday, un total desastre.
Para definir que tan critica es nuestra carga de trabajo el negocio, nos debe definir dos parámetros importantes los cuales corresponden por sus siglas en inglés a RPO y RTO
- Recovery Point Objective (RPO): La pérdida máxima de datos que el negocio puede tolerar.
- Recovery Time Objective (RTO): El tiempo máximo que un sistema puede estar fuera de servicio.
Fuente: Arquitectura de Recuperación ante Desastres en AWS, Parte 1
Esta imagen ilustra muy bien los conceptos anteriores, en términos simples significan cuantos datos puedo perder desde el último respaldo al momento del incidente y cuanto tiempo después del incidente se dispone como máximo para restablecer la operación.
Dependiendo de la criticidad de la carga las respuestas variarán, en algunos casos recibiremos de un mismo cliente un variopinto de duplas RTO y RPO para sus distintas cargas de trabajo, por ejemplo, en una entidad financiera, el sistema a cargo del control de vacaciones tendrá valores más laxos en sus RPO y RTO que los del Core Bancario. Por supuesto entre mas exigentes los valores establecidos más compleja y por lo tanto más onerosa la solución.
En resumen, estos conceptos responden a: ¿cuántos datos puedo perder y cuánto tiempo puedo estar sin servicio?
Estrategias de Recuperación ante Desastres
Tal y como mencionamos anteriormente, entre más complejo el escenario mayor el costo, existen diversas estrategias que aplican dependiendo de los criterios del negocio, en la siguiente figura se visualizan las principales estrategias.
Me concentraré en este artículo en solamente dos de ellas
Backup and Restore
Es una estrategia esencial en cualquier plan de recuperación, especialmente cuando los tiempos de RPO y RTO permitidos son altos, lo que la convierte en una solución económica pero no rápida. Es crucial no descartar esta estrategia bajo ninguna circunstancia, ya que resulta indispensable en casos como la necesidad de retroceder en el tiempo para corregir errores o recuperar datos tras ataques como ransomware, entre otros. Este enfoque actúa como la base mínima para garantizar la recuperación de información crítica
Luz Piloto (Pilot Light)
Diseñada para tiempos de recuperación más exigentes, generalmente entre 10 y 12 minutos, con una pérdida mínima de datos. Este esquema mantiene un subconjunto de elementos replicados y componentes básicos activos, mientras los principales permanecen inactivos hasta que son necesarios. Esto permite acelerar significativamente la recuperación manteniendo los costos controlados, ya que no implica operar dos ambientes activos simultáneamente.
Implementando una estrategia Luz Piloto con AWS Elastic Disaster Recovery
Al definir una estrategia de recuperación, es fundamental considerar varios aspectos clave: primero, garantizar que satisfaga los criterios de criticidad del negocio; segundo, que se implemente de manera costo-efectiva; tercero, asegurar que el mecanismo de recuperación sea práctico y factible de ejercitar, ya que una estrategia que no se prueba regularmente es equivalente a no tener ninguna; y, por último, que el proceso de failback sea simple y eficiente.
¿Por qué AWS Elastic Disaster Recovery?
En el contexto descrito, AWS ofrece Elastic Disaster Recovery como una solución ideal para implementar una estrategia de Luz Piloto. Además de ser una opción costo-efectiva, esta herramienta destaca por las siguientes bondades:
- Facilita la creación de un entorno de recuperación independientemente de la ubicación original de las cargas de trabajo, ya sea que estas se encuentren on-premise, en otra nube o en una región de AWS
- Permite cumplir con tiempos de recuperación (RTO) en cuestión de minutos.
- Ofrece la capacidad de lograr objetivos de punto de recuperación (RPO) extremadamente bajos.
- Simplifica la ejecución de ejercicios de recuperación, haciéndolos accesibles y prácticos.
Consideraciones importantes
No es mi intención en este artículo replicar el manual de instalación de EDR pero tras nuestra experiencia me gustaría destacar puntos importantes del proceso.
Staging Area Subnet:
Componente crítico se encuentra definida dentro de la VPC de destino en AWS, actúa como un área de preparación temporal para los servidores de replicación, facilitando una transición segura y controlada durante el proceso de recuperación. Factores clave a considerar:
- Comunicación de Servidores: Habilitación del puerto 1500 entre servidores de origen y la subnet de staging, para permitir la trasferencia de datos durante la replicación
- Conectividad con Endpoint de EDR: se debe habilitar la comunicación directa mediante puerto 443 (HTTPS)
Agentes de Replicación:
Es requerido la instalación de agentes de replicación en los servidores origen, la cual es permitida tanto para servidores con sistemas operativos Windows o Linux, se debe realizar una validación previa de las versiones soportadas
Desafíos de Seguridad:
En el caso de que se utilicen herramientas de seguridad empresarial como por ejemplo con Kaspersky Endpoint Security Cloud se requiere que previo a la instalación se habilite de manera explicas las rutas en las que se estará instalando el agente, esto previene bloqueos durante la implementación del agente
Gestión del Ancho de Banda:
En condiciones normales, EDR es capaz de gestionar el ancho de banda, pero ante limitaciones económicas y alta cantidad de transferencia se puede optar por un enfoque secuencial, con algo de paciencia en ante limitaciones de este tipo es perfectamente posible abordar la sincronización inicial.
Simulacros de Recuperación
Los ejercicios de replicación pueden ser dolorosos complejos y suelen convertirse en un dolor de cabeza en escenarios tradicionales. Con EDR es muy sencillo realizar un ensayo. Entre sus fortalezas puedo citar :
- Flexibilidad para realizar pruebas en uno o todos los servidores
- No se interrumpe la operación principal
- El costo de infraestructura es viable pues luego del ejercicio el ambiente se destruye con facilidad
- El tiempo de despliegue es en promedio de 12 minutos
La ejecución de simularos es estratégica pues permite a los responsables practicar que deben hacer ante un desastre y aplicamos la filosofía de la práctica hace al maestro
Conclusión
La implementación de un sitio de recuperación de desastres requiere algo más que una instalación. Es fundamental desarrollar un plan detallado, documentado y probado regularmente.
Simulacros regulares validan la estrategia técnica y preparan al equipo, minimizando el impacto operativo, económico y sobre la reputación de la organización.
AWS Elastic Disaster Recovery es una excelente opción para la implementación de nuestra estrategia con un costo efectivo y con la agilidad requerida para que nuestro equipos adquieran la pericia que requerirán ante un desastre real.
Top comments (0)