Este post es el cuarto y último de una serie de artículos sobre cómo diseñar arquitecturas para plataformas cloud según la aplicación y el fin para los cuales son requeridas. Las pasadas entregas han sido: Plataformas e-commerce, Exchange 2013 y Desktop as a Service.
Llamamos Disaster Recovery al plan de contingencia o plan de recuperación ante desastres, aquella solución que se activa en caso de ocurrir un desastre. Pero ¿qué consideramos como desastre?
En sentido amplio, un desastre es cualquier circunstancia que afecta a los procesos tecnológicos referentes al negocio y los beneficios que estos aportan. Esta delimitación abarca desde una caída del data center entero hasta un ataque malicioso sobre los equipos que hospedan la solución, pasando por corrupciones de las bases de datos y fallos humanos. Así, un plan de recuperación ante desastres busca asegurar que, sea cual sea el caso que se de, el servicio no se vea afectado en ningún sentido.
ARQUITECTURAS RECOMENDADAS
A grandes rasgos, una buena solución de Disaster Recovery debería seguir las siguientes directrices:
- Ser autosuficiente (sin dependencias de la plataforma principal).
- Tener un plan de acción detallado, con responsabilidades acotadas y motivos de activación claros y concisos.
- Definir los objetivos: Return Point Objective (el tiempo de datos que estamos dispuestos a perder) y Return Time Objective (el tiempo que podemos permitirnos estar parados).
- Determinar el nivel de degradación del servicio que estamos dispuestos a sostener.
- Usar un Global Traffic Manager o un servicio de DNS Global, como por ejemplo Amazon Route 53.
- Usar una CDN que permita mitigar la carga que recibirá el site secundario, como por ejemplo Amazon CloudFront o el servicio de Aceleración Web y Protección DoS de Claranet.
- En la medida de lo posible, aprovechar las funcionalidades del hypervisor de elección, si se trata de una plataforma on-premise, usando productos como Veeam Backup&Replication o VMware Site Recovery Manager (SRM), cuyas funcionalidades nos pueden aligerar de tareas en los planes de Disaster Recovery (por ejemplo, los cambios en las direcciones IP de las máquinas virtuales).
Con estas premisas, junto con las que facilite la parte de negocio, debemos poder elaborar el plan de contingencia y definir la arquitectura de nuestra solución de Disaster Recovery incluyendo servicios esenciales como computación, storage, networking o DNS, entre otros.
Para ilustrar un ejemplo de arquitectura recomendada de Disaster Recovery, incluiremos las dos plataformas tipo que hemos descrito en artículos anteriores de esta serie: Exchange 2013 y E-commerce.
Esta infraestructura se compone de una solución para una aplicación web y una aplicación corporativa, pero puede ser diseñada para cualquier tipo de aplicación. Como se puede observar, la arquitectura del primer data center está compuesta por dos entornos, que están replicados en un segundo centro.
En el caso del e-commerce, mediante un Global Traffic Manager o un DNS Global decidiremos el data center dónde dirigir los usuarios para que, allí, sean los balanceadores locales los encargados de distribuir la carga en la plataforma que ha de servir la aplicación. Así, en caso de desastre, el GTM/DNS Global cambiará el flujo del tráfico hacia el sitio secundario, donde mantendrá una copia sincronizada de los datos.
En el caso del Exchange, el uso de Database Avaliability Groups (DAGs) entre data centers nos permitirá tener una copia off-site de los buzones, pudiendo redirigir a los usuarios al sitio secundario.
Aunque cada solución de Disaster Recovery es particular y varía en función de la infraestructura inicial y las necesidades de negocio, a continuación detallamos algunas recomendaciones generales:
Asimismo, es aconsejable probar los planes de contingencia de forma periódica (por ejemplo, una vez cada dos meses) para supervisar que todos los procedimientos funcionen correctamente.
Contenidos relacionados: