Mecanismos de Replicación Disaster Recovery & Cloud Análisis de herramientas de replicación Estrategias de Replicación Mantenimiento del DR

1. Disaster
Recovery
& Cloud
-1-

2. Antes de empezar…
RTO / RPO
Días Horas Minutos Minutos Horas Días
¿Cuánta información puedo ¿Cuánto puedo esperar a
perder? recuperar el servicio?
Consistency (Consistencia)
Crash consistency Transaction / Application
• Se mantiene el orden de escrituras de datos a disco • La de transacción garantiza la atomicidad de una
de forma que es posible recuperarse de una transacción (no hay transacciones a medias). Ejemplo:
interrupción inesperada. transacciones de bases de datos.
• La aplicación que maneja los datos debe tener • La consistencia de aplicación garantiza un conjunto de
mecanismos para depurar las operaciones no transacciones relacionadas en el marco de una o varias
finalizadas y arrancar correctamente. aplicaciones. Ejemplo: Creación de un usuario en Active
• Garantiza el arranque del sistema operativo y la Directory.
capacidad de leer los ficheros
-2-

3. Antes de empezar…
En entornos virtuales Múltiples Estrategias de DR
VMware ESX acknowledges a write or
read to a guest operating system only
after that write or read is acknowledged
by the hardware controller to ESX. R
P
Applications running inside virtual O
machines on ESX are afforded the same
crash consistency guarantees as
applications running on physical
machines or physical disk controllers.
Semanas Días Horas Minutos Segundos 0
RTO
La virtualización no añade nada nuevo a
los viejos conceptos sobre consistencia.
Nos centraremos en aquellas
estrategias con RTO de horas o menos y
RPO de 1 día como máximo.
-3-

4. Disaster Recovery & Cloud
Mecanismos de
Replicación
-4-

5. Antes y Después del Cloud
Sin Cloud Con Cloud
x2
• Duplicamos la infraestructura y • Pago por uso. Pagamos una tarifa muy
complicamos la gestión de los cambios. Se reducida por el “stand by”.
duplican los costes.
• Puede ser casi transparente para la gestión
• A menudo se sugiere aceptar una de cambios (cloud2cloud)
degradación de los niveles de calidad de
servicio a cambio de relajar los requisitos • Capacidad elástica (no es necesario
de infraestructura en el sitio secundario. Lo preocuparse por la capacidad del sitio
que aumenta entonces es la complejidad secundario)
en la gestión de cambios. • Planes de recuperación automatizados y
simulacros menos costosos.
-5-

6. Mecanismos de Replicación
Basada en Hipervisor
• El hipervisor replica las imágenes de las VM’s.
• Hace una primera copia completa y a partir de
aquí va actualizando con snapshots más
Cloud Cloud
pequeños.
• No requiere ninguna instalación en la VM y es
independiente del sistema operativo. Su gestión
es sencilla porque no depende en absoluto del
que contenga la máquina.
• No supone una sobrecarga significativa para el
servidor replicado (entre un 2% y un 6% de Crash Consistency
sobrecarga)
• Permite una recuperación de la máquina virtual
en minutos.
Minutos Minutos Horas
• Permite la automatización parcial o total de los
planes de recuperación (puesto que el hipervisor
tiene el control de todos los servidores y a
¿Cuánta información ¿Cuánto puedo esperar a
menudo del direccionamiento de red) puedo perder? recuperar el servicio?
RPO RTO
-6-

7. Mecanismos de Replicación
Basada en SAN
• Se establece una comunicación directa (alta
velocidad) entre 2 cabinas SAN compatibles y se Cloud Cloud
lleva a cabo una replicación en tiempo real de
todas las escrituras a la cabina de origen.
• Es completamente transparente para las
máquinas protegidas. Físico Físico
• No supone ninguna carga de trabajo para los
servidores protegidos.
• Se pueden conseguir RPO’s muy bajos
(segundos)
• Se puede utilizar para replicar los volúmenes que Crash Consistency
contienen las máquinas virtuales, para replicar
volúmenes de datos independientes del
hipervisor y almacenamiento SAN utilizado por Segundos Minutos Horas
servidores físicos.
¿Cuánta información ¿Cuánto puedo esperar a
puedo perder? recuperar el servicio?
RPO RTO
-7-

8. Mecanismos de Replicación
Basada en Agentes
• Se instalan agentes en cada uno de los
servidores que van a replicarse. Cloud Cloud
• Los agentes penalizan el rendimiento del
servidor (un 30% de impacto sobre las
operaciones de escritura en disco, según pruebas
de concepto de NEXICA) Físico Físico
• Los agentes requieren instalación
individualizada, monitorización y actualizaciones.
• No hay agentes para todos los sistemas
operativos y versiones.
• Es el único mecanismo capaz de replicar
Crash Consistency Application
servidores físicos sin necesidad de tener cabinas
Consistency
SAN compatibles en los dos extremos.
• Con agentes específicos para determinadas Segundos Minutos Horas
aplicaciones, se puede asegurar la consistencia a
nivel de aplicación
¿Cuánta información ¿Cuánto puedo esperar a
• Los planes de recuperación son manuales, y sólo puedo perder? recuperar el servicio?
se replican datos. La gestión de cambios está RPO RTO
duplicada
-8-

9. Mecanismos de Replicación
Nativa de Aplicación
• Algunas aplicaciones y bases de datos disponen
de mecanismos propios para la replicación entre Cloud Cloud
varias ubicaciones (ejemplos: SQL Server, Oracle
RAC o Dataguard, Exchange, Active Directory)
• Independientes de que los servidores de origen y
destino sean físicos o virtuales (cualquier Físico Físico
combinación es posible)
• Garantizan el nivel más alto de consistencia. Esto
es especialmente importante en bases de datos
(consistencia de transacciones, RPO tendiendo a
cero)
• Pueden funcionar también como mecanismos de Application
redundancia para el alta disponibilidad, incluso Consistency
en configuraciones activo/activo.
Segundos Minutos
¿Cuánta información ¿Cuánto puedo esperar a
puedo perder? recuperar el servicio?
RPO RTO
-9-

10. Mecanismos de Replicación
Backup Remoto
• Es similar a la replicación basada en agentes,
pero en este caso sólo se replican los datos a Cloud Cloud
nivel de aplicación (no los ficheros) con agentes
de Backup al lugar de recuperación.
• En el caso de servidores virtuales, el Backup de
datos puede copiar los ficheros que contienen Físico Físico
las máquinas virtuales (con el que se replicarían
datos y servidores).
• En el caso de servidores físicos, sería necesario
una virtualización periódica en origen
(manualmente) y copiarlos en el lugar de
recuperación mediante estos agentes de Backup.
Application
• En este caso los datos estarían sincronizados Consistency
cada 24 horas (no hay replicación continua en
agentes de Backup) y las configuraciones de los
Días Horas Horas
servidores lo estarían a periodos más largos
(entre 1 y 3 meses)
¿Cuánta información ¿Cuánto puedo esperar a
puedo perder? recuperar el servicio?
RPO RTO
-10-

11. Disaster Recovery & Cloud
Estrategias de
Replicación
-11-

12. Estrategia de Replicación
RTO: NBD – 1 hora RTO: 6 hores RTO: 2 hores
Replicación en Hipervisor SRM
Servidores Virtuales (RPO mínimo: 15 minutos)
sin BBDD’s Replicación en SAN
(RPO ~ 0)
Replicación Agentes Locales Double
Servidores Físicos (RPO: 5 minutos) Take
sin BBDD’s Replicación en SAN
(RPO ~ 0)
Servidores Virtuales o Replicación Nativa (Activo/Pasivo)
Físicos con BBDD’s (RPO 0)
Backup Diario de Datos + Virtualización
Servidores con BBDD’s (RPO 24 horas)
Oracle (barato) Oracle Streams / Golden Gate
(RPO ~ 0)
-12-

13. Calculando el RTO total
RTO total
Activación
Configuración post-
Encendido de
arranque
Servicios
Ence Conf. Activación
ndido P. A. Servicios
Activación de
Configuración post-arranque Servicios
-13-

14. Calculando el RTO total
RTO total
Activación
Configuración post-
Encendido de
arranque
Servicios
Declaración Ence Conf. Activación
del Desastre ndido P. A. Servicios
Activación de
Configuración post-arranque Servicios
-14-

15. Disaster Recovery & Cloud
Mantenimiento del DR
-15-

16. 3 Cuestiones Clave
• Hay que identificar claramente qué cambios afectan al DRP (aquellos que no se ejecutan
automáticamente en el site secundario).
Gestión de
• Es muy difícil (y costoso) mantener un DRP sin un proceso de gestión de cambios formal.
Cambios
• Tener en cuenta el impacto de cada solución en la gestión de cambios. La estrategia debe
optimizar el TCO de los servicios (no nos fijemos sólo en los costes de infraestructura)
• Automatización = Menos coste
Controles
• Menos coste = Más periodicidad
Periódicos
• Más periodicidad = Menos Riesgo
• Siempre hacemos planes, procedimientos y procesos suponiendo una serie de garantías (la
gente responderá racionalmente, aplicará el sentido común, vendrán a trabajar al día siguiente,
obedecerán a sus superiores, tendremos ordenadores y líneas telefónicas, etc.)
Recursos • Según la magnitud del desastre, ninguna de estas garantías puede darse por segura.
• Contar con recursos externos (que no se vean afectados por el desastre) puede ser una buena
idea.
-16-

17. Errores más frecuentes
• Cuando se trata de proteger comercios electrónicos o webs públicas, hay que tener en cuenta la
re-configuración de los DNS dentro del RTO.
DNS
• O bien modificamos el tiempo de actualización de los DNS (saltándonos buenas prácticas) o
recurrimos a soluciones de Global Load Balancing.
• Incluir direcciones IP dentro del código
DNS
Internos • No mantener la sincronización de los DNS’s internos que permita resolver los nombres de los
servidores internos
• No contar con herramientas de monitorización en el sitio secundario
Herramient
• No contar con herramientas de administración y soporte a la resolución de incidencias en el sitio
as de secundario (gestión de tickets, consolas de acceso, etc.)
Gestión
• Continuidad de servicios básicos de Telefonía y Correo
-17-

18. Disaster Recovery & Cloud
Recovery As A Service
-18-

19. ¿En qué consiste?
Hipervisor
Agentes
Nativa
NEXICA NEXICA
Cloud Barcelona Cloud Madrid
• Pago por Uso (en “stand by” las máquinas están apagadas, sólo se paga
almacenamiento)
• Todas las ventajas de SRM en entornos virtuales.
• Alcance variable en origen, capacidad en destino flexible
• Servicio 100% delegado (en plataformas gestionadas por NEXICA)
• Posibilidad de contratar Virtual Datacenters en plataformas gestionadas
por el cliente.
-19-

20. ¿Cómo se crea / instala el servicio?
Assessment Instalación y puesta en marcha
• Durante el assessment se determina: • Configuración de las replicaciones a nivel de hipervisor y cabina
• El mecanismo de replicación • Si es necesario, instalación de servidores y reconfiguración de los actuales para las
idóneo para cada aplicación replicaciones propias de cada aplicación que lo requiera (por ejemplo, replicación de
(hipervisor, backup de datos, Exchange 2010).
mecanismos propios de la • Creación de los scripts y reconfiguraciones necesarias (red, nomenclatura, dns) para el
aplicación). correcto funcionamiento del plan de recuperación.
• La consistencia mínima necesaria • Ejecución de las primeras pruebas de recuperación y establecimiento del RTO de
para que todas las aplicaciones referencia.
puedan iniciar sus servicios en el
sitio de contingencia (crash, • Creación de un Plan de Recuperación de Desastres. Se trata de un documento
application) consensuado con el cliente en el que se establece:
• El RTO que puede esperarse de • El protocolo para la declaración formal de un desastre y el procedimiento de
todo el plan a partir de las activación del sitio de contingencia. Esto incluye teléfonos de contacto, personas
aplicaciones y volumen de datos autorizadas, etc.
que conforman la plataforma • Los resultados de los primeros test de recuperación, que determinarán el RTO y RPO
protegida. objetivo que habrá de mantenerse en futuras pruebas (y que quedará reflejado en la
• El coste de la instalación y puesta SLA del servicio)
en marcha del servicio (ajuste de • Si existen terceras partes implicadas (desarrolladores, gestores de aplicaciones del
la oferta inicial para ajustar casos cliente), se establecerán los protocolos de entrega del servicio, que determinarán
especiales como la cuales son las responsabilidades de cada una de las partes en las pruebas periódicas
reconfiguración de servidores con y en el caso de desastre (por ejemplo, NEXICA puede ser responsable de asegurar el
mecanismos de replicación funcionamiento de las aplicaciones y los desarrolladores son los responsables de
nativos) validar que no ha habido corrupción de datos)
• Se establece la periodicidad y el alcance de las pruebas periódicas de recuperación.
• Tiempo medio de implantación: 1 a 4 semanas.
-20-

21. ¿Cómo se entrega / gestiona el servicio?
Controles Periódicos
• Pruebas Periódicas
• Una de las ventajas de utilizar la virtualización en el sitio de contingencia es la facilidad para 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 (cada 2 meses), a no ser que el cliente requiera pruebas adicionales (en cuyo
caso hay un incremento en el coste)
• Las pruebas periódicas nos ayudan a detectar cambios en el RTO y tomar acciones correctivas.
-21-