Siniestros Natalia Maurer Arquitectura Avanzada CAECE 2011
Algunas definiciones Siniestro [RAE] Daño de cualquier importancia que puede ser indemnizado por una compañía aseguradora. [WIKIPEDIA] Se refiere a un accidente o incidente que ha causado graves daños a personas o a la propiedad. Contingencia [RAE] posibilidad de que algo suceda o no suceda. Riesgo. Plan de continuidad del negocio o BCP Define las acciones a tomar en caso que una determinada contingencia inhabilite algún área de operaciones o tecnología. El objetivo del plan es permitir la recuperación de las operaciones críticas del negocio. El BCP incluye al plan de recuperación ante desastres o DRP (Disaster Recovery Plan). Plan de recuperación ante desastres o DRP Define las acciones a tomar en caso que una determinada contingencia inhabilite el centro de cómputos. Su objetivo es permitir la recuperación de las operaciones críticas de IT. Es el conjunto de políticas, procedimientos, normas y lineamientos relacionados con la recuperación luego de un desastre natural o inducido por humanos.
Recuperación ante desastres o DR DR es crítico para la continuidad del negocio. La supervivencia de la compañía depende de su habilidad para replicar los sistemas de IT y los datos que posee DR DEL MODO TRADICIONAL En una primera instancia, para soportar DR dentro de las instalaciones de la organización debemos: Usar redundancia de los sistemas/datos: por ejemplo usando RAID. Asegurar la provisión constante de energía: sin sobretensiones o picos. Proteger a los sistemas de acceso físico no autorizado. Medidas de seguridad para evitar y controlar incendios. Implementar IDS, IPS y otras medidas de seguridad. El próximo nivel en la estrategia organizaciones para DR consiste en: Resguardo de datos usando cintas Resguardo de datos en data centers remotos. Alta disponibilidad de la infraestructura de IT usando una ubicación off-site replicada. PROBLEMA: GASTO Y LA IMPOSIBILDIAD DE PREVER EL CRECIMIENTO
Ventajas de hacer DR en la nube Le permite a la organización enfocar sus inversiones en las actividades del negocio en lugar de usarlas para centros de DR. En la nube los servidores están virtualizados, entonces en lugar de solo resguardar los datos, ahora podemos resguardar el servidor completo off-site. Permite reducir el RTO. Permite incrementar la infraestructura, aunque no haya sido previsto durante la planificación del DR. Existes múltiples proveedores de servicios en la nube en múltiples ubicaciones geográficas. Esto permite resguardar en distintas áreas alrededor del mundo. Reduce la necesidad de espacio en data centers, infraestructura y recursos de IT. Permite que compañías más pequeñas tengan soluciones de DR que antes solo se encontraban en grandes empresas. Pueden incorporarse recursos a la nube rápidamente con costos que escalan lentamente sin requerir grandes inversiones anticipadas.
Desventajas hacer DR en la nube Si la empresa no tiene conexión a internet por interrupciones de servicio, ya sea debido al proveedor o a un DoS distribuido, va a perder su acceso a la nube. Cuestiones de seguridad que hay que tener en cuenta a la hora de decidir qué cosas van a estar en la nube. Es muy importante elegir un proveedor confiable que este alineado con los requisitos de la compañía. Es importante asegurarse que el data center que la empresa elija se tome la seguridad en serio. Lo importante es saber en qué data center y en qué servidor se están almacenando los datos. También se puede verificar que estén aplicando las medidas de seguridad necesarias: Ver si son auditados en SSAE 16 o SAS 70 Ver si tienen clientes que son certificados HIPPA o PCI. Si ofrecen firewalls, antivirus y detección de intrusos.
DRaaS (Disaster Recovery as a Service) Stacks Tecnológicos en la nube DRaaS. Plataforma virtual automatizada
DRaaS Las compañías se están dando cuenta que muchas aplicaciones pueden ponerse a disposición como servicios y DR no es la excepción. Esto da como resultado el modelo de Disaster Recovery as a Service (DRaas) o DR bajo demanda. Modelo pay as you use Plataforma virtual automatizada: en una primera instancia solo se sincronizan a la nube una pequeña porción de los datos, pero al detectar un desastre se sincronizan todos los recursos adicionales El plan puede probarse periódicamente en un tiempo reducido Lo ideal es tener una conexión WAN optimizada entre la empresa y el proveedor
Requisitos clave de un servicio de DR Los requerimientos pueden estar basados en decisiones del negocio, como el costo monetario del tiempo de inactividad de los sistemas o la pérdida de datos, o en el rendimiento y la precisión de las aplicaciones. RECOVERY POINT OBJECTIVE (RPO): tolerancia de pérdida de datos. En un sistema de DR representa el punto en el tiempo del resguardo de datos más reciente previo al fallo. RECOVERY TIME OBJECTIVE (RTO): tiempo de inactividad aceptado del sistema. incluye el tiempo para detectar el fallo, preparar los servidores que sean necesarios en el sitio alternativo, inicializar la aplicación fallida y realizar la reconfiguración necesaria de la red. Tener un RTO muy bajo permite la continuidad del negocio, permitiendo que una aplicación aparente haber permanecido operativa a pesar del desastre. RENDIMIENTO: impacto en la operación normal luego de la recuperación. para que un servicio de DR sea útil, debería tener un impacto mínimo en la performance de la aplicación. CONSISTENCIA: precisión en los datos de la aplicación y las salidas. el servicio de DR debe asegurar que luego de que ocurre un fallo, la aplicación puede recuperarse en un estado consistente. SEPARACIÓN GEOGRÁFICA: el sitio de DR nunca debería ser impactado por el mismo desastre que el primario. ambos sitios deberían estar geográficamente separados para asegurar que un único desastre no impacte a ambos.
Categorías de DR El nivel de protección de datos y la velocidad de recuperación dependen mecanismo de backup utilizado y la los recursos disponibles en el sitio alternativo. En general, los servicios de DR caen bajo una de las siguientes categorías: Hot Backup Site: proporciona un conjunto de servidores espejados que están en standby disponibles para correr las aplicaciones cuando ocurre el desastre, proporcionando RTO y RPO mínimos. Suelen usar replicación asincrónica para prevenir la pérdidas de datos ocasionadas por el desastre. Warm Backup Site: busca mantener el sitio alternativo al día usando replicación sincrónica o asincrónica dependiendo del RPO necesario. También existen servidores en stand-by disponibles en caso de un desastre, pero se mantienen en un estado warm, lo cual significa que puede llevar un tiempo corto que estén online. Cold Backup site: los datos suelen replicarse periódicamente al sitio alternativo, lo cual conlleva un RPO más elevado. Los servidores en el sitio alternativo no están inmediatamente disponibles, sino que pueden pasar horas o días hasta que el hardware está disponible luego del desastre. Menor costo.
Plan de DR en la nube 1. Identificar y priorizar las aplicaciones, los servicios y los datos. 2. Determinar para cada uno el downtime aceptado. 3. Elegir la alternativa de DR que más se ajuste a las necesidades. DR TRADICIONAL Un sitio secundario de DR significa invertir en espacio adicional de data center, conectividad y servidores. También conlleva costos operativos adicionales (energía, hvac, mantenimiento, personal). El tiempo que toma ponerlo operativo es mayor que en el caso de DR en la nube, resultando en una pérdida de datos. Si no hay conectividad disponible con el sitio secundario, se pueden llegar a requerir operaciones manuales para iniciar las operaciones en el sitio de DR. DR EN LA NUBE Proporciona instantáneas de máquinas virtuales de servidores físicos o virtuales del data center primario. La empresa solo paga la iaas en caso de un desastre para poner online el substituto del sitio primario. El sitio de DR en la nube puede tenerse online en segundos o minutos. Esto se traduce en una pérdida de datos de ese intervalo de tiempo solamente. El sitio de DR en la nube puede dispararse usando una notebook con acceso a internet desde cualquier lado.
ALTERNATIVAS DE DR EN LA NUBE Aplicaciones y DR administrados por el proveedor Tanto el sitio primario como el sitio de DR están la nube. Se elimina de esta forma la necesidad infraestructura dentro de la compañía. La elección del proveedor del servicio y la negociación de los acuerdos de nivel de servicio (SLA) son de vital importancia. Resguardo y recuperación desde la nube En este caso, las aplicaciones y los datos permanecen dentro de la organización. Los datos son resguardados en la nube y recuperados a hardware de la empresa en caso de un desastre. Resguardo y recuperación en la nube Los datos no se recuperan a la infraestructura propia de la empresa, sino a máquinas virtuales en la nube. Esto requiere tanto almacenamiento como recursos en la nube. La recuperación puede realizarse cuando ocurre el desastre o de forma continua (pre-staging) para mantener las virtuales relativamente al día a través de resguardos programados. Replicación a máquinas virtuales en la nube Para aplicaciones que requieren RTO y RPO agresivos, la replicación es la opción a elegir. La replicación a máquinas virtuales puede usarse para proteger tanto las instancias de producción locales de la empresa como las de la nube. La replicación sirve tanto para cloud-vm-to-cloud-vm como para on-premises-to-cloud-vm.
Un ejemplo práctico: Online Tech Online Tech es una empresa estadounidense que maneja data centers. Online Tech movió toda su infraestructura IT (23 servidores) a una nube privada propia a fines del 2009. Tomaron sus 23 servidores, los convirtieron en servidores virtuales y en la actualidad corren sus 23 servidores virtuales en 2 servidores físicos y un entorno SAN (storage área network). En lo que respecta a la recuperación ante desastres, lo que hacen es resguardar los 23 servidores virtuales a un data center secundario a 90 kilómetros de distancia y también tienen un servidor separado (un warm site) para levantar esos servidores en caso de que algo le ocurra a su infraestructura primaria. La experiencia de Online Tech fue muy positiva: Su trabajo es mucho más sencillo desde que pasaron a la nube, tanto en el despliegue como en sus resguardos diarios. Prueban su DRP cada seis meses y les lleva solamente 4 horas. Su RTO bajó dramáticamente. Bajaron sus costos.
Conclusión DRaaS es una solución emergente para organizaciones que quieren controlar su propia infraestructura pero no mantener sistemas de DR ellos mismos. Con DRaaS una organización no construye directamente un sitio para contingencias, sino que confía en un proveedor para que lo haga. Las ventajas que proporciona la nube en cuanto a elasticidad y reducción de costos son beneficios significativos en un escenario de DR. Sin embargo, muchas de las complejidades siguen existiendo y es esencial llevar a cabo el proceso con cuidado y responsabilidad para asegurarse que el plan de contingencia va a funcionar y proveer el nivel de servicio requerido.
Referencias http://resource.onlinetech.com/private-cloudcomputing-how-it-changes-disaster-recovery/ http://cssinnovations.blogspot.com/2010/11/howcloud-computing-can-help-in.html http://www.prnewswire.com/newsreleases/moving-into-the-cloud-essential-forsmall-business-disaster-recovery-123805424.html http://blog.netmagicsolutions.com/article/disasterrecovery-as-a-service-draas/