seminario raas - disaster recovery as a service

-1-

Disaster Recovery & Cloud

-2-

Antes de empezar…

RTO / RPO

Minutos Horas Días Días Horas Minutos

¿Cuánta información puedo perder?

¿Cuánto puedo esperar a recuperar el servicio?

Consistency (Consistencia)

Crash consistency Transaction / Application

• Se mantiene el orden de escrituras de datos a disco de forma que es posible recuperarse de una interrupción inesperada.

• La aplicación que maneja los datos debe tener mecanismos para depurar las operaciones no finalizadas y arrancar correctamente.

• Garantiza el arranque del sistema operativo y la capacidad de leer los ficheros

• La de transacción garantiza la atomicidad de una transacción (no hay transacciones a medias). Ejemplo: transacciones de bases de datos.

• La consistencia de aplicación garantiza un conjunto de transacciones relacionadas en el marco de una o varias aplicaciones. Ejemplo: Creación de un usuario en Active Directory.

-3-

Antes de empezar…

En entornos virtuales

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.

Applications running inside virtual 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

RPO

RTO

Múltiples Estrategias de DR

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.

-4-


Mecanismos de

Replicación

-5-

Antes y Después del Cloud

Sin Cloud Con Cloud

x 2

• Duplicamos la infraestructura y complicamos la gestión de los cambios. Se duplican los costes.

• A menudo se sugiere aceptar una degradación de los niveles de calidad de servicio a cambio de relajar los requisitos de infraestructura en el sitio secundario. Lo que aumenta entonces es la complejidad en la gestión de cambios.

• Pago por uso. Pagamos una tarifa muy reducida por el “stand by”.

• Puede ser casi transparente para la gestión de cambios (cloud2cloud)

• Capacidad elástica (no es necesario preocuparse por la capacidad del sitio secundario)

• Planes de recuperación automatizados y simulacros menos costosos.

-6-

Mecanismos de Replicación

Cloud Cloud

Crash Consistency

Minutos Horas Minutos


RPO


RTO

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 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 sobrecarga)

• Permite una recuperación de la máquina virtual en minutos.

• 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 menudo del direccionamiento de red)

-7-

Basada en SAN

• Se establece una comunicación directa (alta velocidad) entre 2 cabinas SAN compatibles y se 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.

• 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 contienen las máquinas virtuales, para replicar volúmenes de datos independientes del hipervisor y almacenamiento SAN utilizado por servidores físicos.


Cloud Cloud

Crash Consistency

Segundos Horas Minutos


RPO


RTO

Físico Físico

-8-

Basada en Agentes

• Se instalan agentes en cada uno de los servidores que van a replicarse.

• 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)

• 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 servidores físicos sin necesidad de tener cabinas SAN compatibles en los dos extremos.

• Con agentes específicos para determinadas aplicaciones, se puede asegurar la consistencia a nivel de aplicación

• Los planes de recuperación son manuales, y sólo se replican datos. La gestión de cambios está duplicada


Cloud Cloud

Application Consistency

Segundos Horas Minutos


RPO


RTO

Físico Físico

Crash Consistency

-9-

Nativa de Aplicación

• Algunas aplicaciones y bases de datos disponen de mecanismos propios para la replicación entre 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 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 redundancia para el alta disponibilidad, incluso en configuraciones activo/activo.


Cloud Cloud


Segundos Minutos


RPO


RTO

Físico Físico

-10-

Backup Remoto

• Es similar a la replicación basada en agentes, pero en este caso sólo se replican los datos a 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 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.

• En este caso los datos estarían sincronizados cada 24 horas (no hay replicación continua en agentes de Backup) y las configuraciones de los servidores lo estarían a periodos más largos (entre 1 y 3 meses)


Cloud Cloud


Días Horas


RPO


RTO

Físico Físico

Horas

-11-


Estrategias de

Replicación

-12-

Estrategia de Replicación

RTO: NBD – 1 hora RTO: 6 hores

Replicación en Hipervisor (RPO mínimo: 15 minutos) Replicación en SAN (RPO ~ 0)

Replicación Agentes Locales (RPO: 5 minutos) Replicación en SAN (RPO ~ 0)

Replicación Nativa (Activo/Pasivo) (RPO 0)

RTO: 2 hores

Servidores Virtuales sin BBDD’s

Servidores Físicos sin BBDD’s

Servidores Virtuales o Físicos con BBDD’s

Servidores con BBDD’s Oracle (barato)

Backup Diario de Datos + Virtualización (RPO 24 horas) Oracle Streams / Golden Gate (RPO ~ 0)

SRM

DoubleTake

-13-

Calculando el RTO total

Encendido Configuración post-

arranque

Activación de

Servicios

Encendido

Conf. P. A.

Activación Servicios

Configuración post-arranque Activación de

Servicios

RTO total

-14-

Calculando el RTO total

Encendido Configuración post-

arranque

Activación de

Servicios

Encendido

Conf. P. A.

Activación Servicios

Configuración post-arranque Activación de

Servicios

RTO total

Declaración del Desastre

-15-


Mantenimiento del DR

-16-

3 Cuestiones Clave

Gestión de Cambios

Controles Periódicos

Recursos

• Hay que identificar claramente qué cambios afectan al DRP (aquellos que no se ejecutan automáticamente en el site secundario).

• Es muy difícil (y costoso) mantener un DRP sin un proceso de gestión de cambios formal.

• 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

• Menos coste = Más periodicidad

• 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.)

• 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.

-17-

Errores más frecuentes

DNS

DNS Internos

Herramientas de

Gestión

• 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.

• 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

• 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

• No contar con herramientas de administración y soporte a la resolución de incidencias en el sitio secundario (gestión de tickets, consolas de acceso, etc.)

• Continuidad de servicios básicos de Telefonía y Correo

-18-


Recovery As A Service

-19-

¿En qué consiste?

Hipervisor

NEXICA Cloud Barcelona

NEXICA Cloud Madrid

Agentes

Nativa

• 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.

-20-

¿Cómo se crea / instala el servicio?

• Durante el assessment se determina:

• El mecanismo de replicación idóneo para cada aplicación (hipervisor, backup de datos, 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, application)

• El RTO que puede esperarse de todo el plan a partir de las aplicaciones y volumen de datos que conforman la plataforma protegida.

• El coste de la instalación y puesta en marcha del servicio (ajuste de la oferta inicial para ajustar casos especiales como la reconfiguración de servidores con mecanismos de replicación nativos)

• Configuración de las replicaciones a nivel de hipervisor y cabina

• Si es necesario, instalación de servidores y reconfiguración de los actuales para las replicaciones propias de cada aplicación que lo requiera (por ejemplo, replicación de Exchange 2010).

• 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:

• 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.

• 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)

• 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 (por ejemplo, NEXICA puede ser responsable de asegurar el funcionamiento de las aplicaciones y los desarrolladores son los responsables de 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.

Assessment Instalación y puesta en marcha

-21-

¿Cómo se entrega / gestiona el servicio?

• 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.

Controles Periódicos

seminario raas - disaster recovery as a service

Technology