Successfully reported this slideshow.
DisasterRecovery& Cloud  -1-
Antes de empezar… RTO / RPO                      Días      Horas     Minutos           Minutos      Horas      Días       ...
Antes de empezar… En entornos virtuales                       Múltiples Estrategias de DRVMware ESX acknowledges a write o...
Disaster Recovery & CloudMecanismos deReplicación     -4-
Antes y Después del Cloud Sin Cloud                                               Con Cloud                              x...
Mecanismos de ReplicaciónBasada en Hipervisor• El hipervisor replica las imágenes de las VM’s.• Hace una primera copia com...
Mecanismos de ReplicaciónBasada en SAN• Se establece una comunicación directa (alta  velocidad) entre 2 cabinas SAN compat...
Mecanismos de ReplicaciónBasada en Agentes• Se instalan agentes en cada uno de los  servidores que van a replicarse.      ...
Mecanismos de ReplicaciónNativa de Aplicación• Algunas aplicaciones y bases de datos disponen  de mecanismos propios para ...
Mecanismos de ReplicaciónBackup Remoto• Es similar a la replicación basada en agentes,  pero en este caso sólo se replican...
Disaster Recovery & CloudEstrategias deReplicación    -11-
Estrategia de Replicación                         RTO: NBD – 1 hora              RTO: 6 hores                RTO: 2 hores ...
Calculando el RTO total                                                     RTO total                                     ...
Calculando el RTO total                                                    RTO total                                      ...
Disaster Recovery & CloudMantenimiento del DR    -15-
3 Cuestiones Clave              • Hay que identificar claramente qué cambios afectan al DRP (aquellos que no se ejecutan  ...
Errores más frecuentes               • Cuando se trata de proteger comercios electrónicos o webs públicas, hay que tener e...
Disaster Recovery & CloudRecovery As A Service    -18-
¿En qué consiste?                                  Hipervisor                                    Agentes                  ...
¿Cómo se crea / instala el servicio?Assessment                                     Instalación y puesta en marcha• Durante...
¿Cómo se entrega / gestiona el servicio?Controles Periódicos• Pruebas Periódicas      • Una de las ventajas de utilizar la...
Seminario 'Sistemas de Recuperación de Aplicaciones ante Desastres (RaaS)'
Upcoming SlideShare
Loading in …5
×

Seminario 'Sistemas de Recuperación de Aplicaciones ante Desastres (RaaS)'

656 views

Published on

Más allá del alojamiento de aplicaciones, el cloud computing permite a los proveedores ofrecer nuevos servicio basados en IaaS, como por ejemplo RaaS, que permite ofrecer backup de sistemas y aplicaciones a precios asequibles.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Seminario 'Sistemas de Recuperación de Aplicaciones ante Desastres (RaaS)'

  1. 1. DisasterRecovery& Cloud -1-
  2. 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. 3. Antes de empezar… En entornos virtuales Múltiples Estrategias de DRVMware ESX acknowledges a write orread to a guest operating system onlyafter that write or read is acknowledgedby the hardware controller to ESX. R PApplications running inside virtual Omachines on ESX are afforded the samecrash consistency guarantees asapplications running on physicalmachines 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. 4. Disaster Recovery & CloudMecanismos deReplicación -4-
  5. 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. 6. Mecanismos de ReplicaciónBasada 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. 7. Mecanismos de ReplicaciónBasada 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. 8. Mecanismos de ReplicaciónBasada 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. 9. Mecanismos de ReplicaciónNativa 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. 10. Mecanismos de ReplicaciónBackup 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. 11. Disaster Recovery & CloudEstrategias deReplicación -11-
  12. 12. Estrategia de Replicación RTO: NBD – 1 hora RTO: 6 hores RTO: 2 hores Replicación en Hipervisor SRMServidores Virtuales (RPO mínimo: 15 minutos)sin BBDD’s Replicación en SAN (RPO ~ 0) Replicación Agentes Locales DoubleServidores Físicos (RPO: 5 minutos) Takesin 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ónServidores con BBDD’s (RPO 24 horas)Oracle (barato) Oracle Streams / Golden Gate (RPO ~ 0) -12-
  13. 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. 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. 15. Disaster Recovery & CloudMantenimiento del DR -15-
  16. 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 costeControles • Menos coste = Más periodicidadPerió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. 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 secundarioHerramient • 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. 18. Disaster Recovery & CloudRecovery As A Service -18-
  19. 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. 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. 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-

×