Estrategias de recuperacion de desastres y alta disponibilidad con amazon web services

Estrategias de
Recuperación de
Desastres con
Amazon Web
Services
INFORME 2013
En este informe se describen algunos enfoques típicos de recuperación de
desastres y alta disponibilidad de sistemas, que van desde reposición de copias
de seguridad a disponibilidad a gran escala y la tolerancia a fallos.

Tabla de contenido
Contenido
Resumen Ejecutivo ___________________________________________________________ 1
Recuperación de Desastres ____________________________________________________ 2
Servicios Esenciales de AWS para Recuperación de Desastres ________________________ 5
Estrategias de Recuperación de Desastres _______________________________________ 10
Replicación de Datos ________________________________________________________ 22
Mejoras al plan de DR________________________________________________________ 24
Realizado por ______________________________________________________________ 27

Pág. 01 Recuperación de Desastres con AWS
Resumen Ejecutivo
Cuando una empresa u organización debe mantener un nivel de alta confiabilidad y
disponibilidad en una aplicación o sistema siempre ha soñado con tener un centro de datos o
medios alternativos que pudiesen reemplazar en muy poco tiempo aquellos recursos que por
algún desastre o error queden inutilizables.
Digo que “siempre se ha soñado” porque normalmente esta solución pasaba por duplicar y
replicar las infraestructuras del centro de datos principal para después mantener y alimentar
este segundo centro de datos. Esto supone un considerable gasto de inversión primero y otro
de mantenimiento tampoco despreciable para tener una infraestructura que habitualmente
quedaba en una situación de infrautilización. Esta circunstancia dejaba los centros de datos
alternativos o de respaldo sólo al alcance de muy pocos y en el terreno de los sueños para los
demás.
La computación en la nube y más concretamente los Servicios Web de Amazon (Amazon Web
Services, AWS) dan una solución de pago por uso que nos evita los gastos de inversión y la
mayoría de los de mantenimiento de este centro de datos alternativo.
Es tan eficiente la solución en AWS que una vez diseñado y montado el centro de respaldo sólo
pagaremos cuando se use, es decir, cuando el desastre se produzca. Si es que se produce.
En grayhats hemos estudiado muchas plataformas y opciones de IaaS (Infraestructura como
Servicio) e identificado a AWS como la mejor y la más adecuada para este tipo de solución.
A principios de 2013 grayhats se convierte en partner consultor certificado de AWS y está
habilitado para proveer soluciones a través de dicha plataforma.
Es tan eficiente la
solución en AWS
que una vez
diseñado y
montado el centro
de respaldo sólo
pagaremos
cuando se use, es
decir, cuando el
desastre se
produzca. Si es
que se produce.

Recuperación de Desastres
La recuperación de desastres (Disaster Recovery, DR) trata la preparación y la recuperación de
un desastre. Cualquier evento que tiene un impacto negativo en la continuidad o las finanzas o
reputación de su negocio u organización podría denominarse un desastre. Esto podría ser fallo
de hardware o software, un corte en la red, un corte de energía, el daño físico a un edificio como
un incendio o inundación, error humano o algún otro desastre importante.
Para minimizar el impacto de un desastre en el negocio, las empresas invierten tiempo y
recursos para planificar, preparar, ensayar, documentar, dimensionar y actualizar los procesos
para hacer frente a los acontecimientos. El total de la inversión para la planificación de
recuperación de desastres de un sistema en particular puede variar enormemente dependiendo
del coste potencial de una parada. En este informe se describen algunos enfoques típicos que
van desde inversiones mínimas a disponibilidad a gran escala y la tolerancia a fallos.
La preparación adecuada de DR es una necesidad, y este informe se esbozan algunas de las
mejores prácticas para mejorar los planes y procesos de DR.
La recuperación de desastres es un proceso continuo de análisis y mejora, a medida de que las
empresas y los sistemas evolucionan. Para cada servicio de negocio, los clientes necesitan para
establecer un punto de recuperación aceptable y el tiempo, y luego construir una solución DR
apropiada.
En un entorno físico tradicional, un enfoque típico implicaría normalmente la duplicación de la
infraestructura para garantizar la disponibilidad de capacidad de repuesta en un escenario de
desastre. Esta infraestructura tiene que ser adquirida, instalada y mantenida de modo que esté
lista para hacer frente a los requisitos de carga de trabajo prevista. En condiciones normales de
funcionamiento, es decir cuando la infraestructura principal no falla, esta infraestructura
alternativa sería típicamente subutilizada o sobredimensionada.
AWS permite escalar una infraestructura en base a necesidades coyunturales. El cliente accede
a la misma infraestructura altamente escalable, rápida y segura, confiable, eficiente y de bajo
coste que Amazon utiliza para ejecutar su propia red mundial de sitios web y sólo paga por lo
que usa. Para una solución de recuperación de desastres (DR), esto se traduce en importantes
ahorros de costes. También permite una mayor agilidad para cambiar y optimizar los recursos
durante un escenario DR.

El error humano es la causa de una gran parte del tiempo de inactividad de un sistema. AWS
ofrece herramientas para permitir la separación de funciones para permitir un diseño basado en
el mínimo privilegio (dos de los principios básicos del Esquema Nacional de Seguridad). AWS
también le permite automatizar la implementación de entornos completos, lo que permite
escenarios pre-configurados (Amazon Cloud Formation).
Los entornos de prueba de DR en AWS se pueden levantar muy rápidamente, y pueden ser
tratados como un recurso de “quita y pon”. Esto habilita a las organizaciones para poner a
prueba los cambios de configuración, actualizaciones y pruebas en un entorno duplicado antes
de llevar los cambios de configuración al entorno de producción, sin la necesidad de un entorno
de prueba a gran escala dedicado, que a menudo se infrautilizada.
Tiempo Objetivo de Recuperación y Punto Objetivo de Recuperación
Usaremos las siguientes métricas de amplio reconocimiento para la planificación de la
recuperación de un desastre.
TIEMPO OBJETIVO DE RECUPERACIÓN (RTO): Esta es la duración de tiempo en el que el proceso
de negocio debe ser restaurado después de un desastre (o interrupción) para evitar
consecuencias inaceptables derivados de una ruptura en la continuidad del negocio. Por
ejemplo, si se produce un desastre a las 12:00 PM (mediodía) y el RTO es de 8 horas, el proceso
de DR aseguraría la recuperación al nivel de servicio aceptable sería posible antes de las 8:00
AM. Definir un RTO es básico para definir políticas de nivel de servicio así como planificar
recuperaciones de desastres.
PUNTO OBJETIVO DE RECUPERACIÓN (RPO): Esto describe la cantidad aceptable de pérdida de
datos medida en tiempo. Daría una medida de cuanto somos capaces de acercar el punto de
recuperación al punto del desastre. Por ejemplo, si el RPO es de 1 hora, y se recupera el
sistema, contendría todos los datos hasta un punto en el tiempo, que no es posterior a las 11:00
AM debido a que el desastre ocurrió al mediodía.
Una empresa u organización normalmente fija un valor RTO y RPO aceptable basado en el
impacto cuando los sistemas no están disponibles. El impacto financiero se suele evaluar al
considerar muchos factores, como la pérdida de negocio y el daño a su reputación debido a la
inactividad y la falta de disponibilidad de los sistemas.
Esto habilita a las
organizaciones
para poner a
prueba los
cambios de
configuración,
actualizaciones y
pruebas en un
entorno duplicado
antes de llevar los
cambios de
configuración al
entorno de
producción.

Los departamentos de TI planifican soluciones para proporcionar de forma rentable la
recuperación del sistema basado en el RPO dentro de la línea de tiempo y nivel de servicio
establecido por la RTO.
Prácticas habituales de inversión en Recuperación de Desastres
Un enfoque tradicional de la DR implica diferentes niveles de la duplicación fuera de las
instalaciones donde están los datos y la infraestructura.
Los servicios de negocio críticos se establecen y mantienen sobre esta infraestructura y son
probados a intervalos regulares. La ubicación del entorno de recuperación de desastres y la
infraestructura de código deben estar a una distancia física significativa separados para
asegurar que el entorno de recuperación de desastres se aísla de fallos que podrían afectar el
sitio de origen.
La infraestructura necesaria para apoyar el entorno duplicado debería incluir, pero no limitarse
a lo siguiente:
• Instalaciones para albergar la infraestructura incluyendo la energía y la refrigeración.
• Seguridad para asegurar la protección física de los activos.
• Capacidad adecuada para escalar el entorno.
• Apoyo a la reparación, sustitución y actualización de la infraestructura.
• Los acuerdos contractuales con un proveedor de servicios de Internet (ISP) para
proporcionar conectividad a Internet que pueda sostener la utilización de ancho de banda
para el medio ambiente con una carga completa.
• Infraestructura de red tales como firewalls, routers, switches y equilibradores de carga.
• Capacidad del servidor suficiente para hacer funcionar todos los servicios de misión
crítica, incluyendo dispositivos de almacenamiento para los datos de apoyo y servidores
para ejecutar aplicaciones y servicios de back-end, tales como la autenticación de
usuarios, el Sistema de Nombres de Dominio (DNS), Dynamic Host Configuration
Protocol (DHCP), monitoreo y alerta.
Dependiendo de la criticidad de los servicios, el entorno duplicado podría ser configurado con
tolerancia a fallos. Esto normalmente implica la duplicación de toda la infraestructura
enumerados anteriormente.
Los servicios de
negocio críticos
se establecen y
mantienen sobre
esta
infraestructura y
son probados a
intervalos
regulares.

Servicios Esenciales de AWS para
Recuperación de Desastres
Antes de discutir los distintos enfoques y estrategias de la DR, es importante revisar los servicios
y funciones que son los más relevantes para la recuperación de desastres de AWS. En esta
sección se ofrece un resumen.
En la fase de preparación de la DR, es esencial tener en cuenta el uso de los servicios y
funciones que soportan la migración de datos y almacenamiento duradero, ya que permiten a
restaurar una copia de seguridad de datos críticos para AWS cuando ocurre un desastre. Para
algunos de los escenarios que implican tanto a escala reducida o una implementación
totalmente a escala de su sistema de AWS, se requerirán también recursos informáticos.
Al reaccionar ante un desastre, es fundamental, provisionar de forma rápida los recursos de
computación para hacer funcionar su sistema en AWS o para lanzar la conmutación por error
de los recursos ya se estén ejecutando en AWS. Las piezas esenciales de infraestructura aquí
incluyen DNS, funciones de red y diversos recursos de Amazon Elastic Compute Cloud (Amazon
EC2). Estas funciones se describen a continuación.
Regiones
Los servicios web de Amazon están disponibles en múltiples regiones, para que pueda elegir el
lugar más adecuado para hospedar centro de recuperación de desastres. En este momento,
AWS está disponible en cinco regiones: EE.UU. Este (Norte de Virginia), EE.UU. Oeste (Norte
de California), UE (Irlanda), Asia Pacífico (Singapur) y Asia Pacífico (Tokio).
Almacenamiento
Amazon Simple Storage Service (Amazon S3) proporciona una infraestructura de
almacenamiento muy duradera, diseñada para el almacenamiento de datos de misión crítica y
primaria. Los objetos se almacenan de forma redundante en múltiples dispositivos a través de
múltiples instalaciones dentro de una región. AWS ofrece protección adicional para la retención
de datos y archivo de versiones a través de Amazon S3, AWS autenticación multifactorial, las
políticas de almacenes de datos, y gestión de identidad y acceso (IAM).
Al reaccionar ante
un desastre, es
fundamental,
provisionar de
forma rápida los
recursos de
computación para
hacer funcionar
su sistema en
AWS o para
lanzar la
conmutación por
error de los
recursos ya se
estén ejecutando
en AWS.

Amazon Elastic Block Store (Amazon EBS) ofrece la posibilidad de crear instantáneas de
punto en el tiempo de los volúmenes de datos. Estas instantáneas se pueden utilizar como punto
de partida para los nuevos volúmenes de Amazon EBS, y para proteger los datos a largo plazo.
Una vez que se crea un volumen, a continuación, se puede conectar a una instancia de Amazon
EC2 en funcionamiento. Los volúmenes de Amazon EBS pueden mantenerse fuera de la
instancia de computación para la que fueron creados. Es un recurso independiente.
Normalmente se usa este tipo de almacenamiento para emular el disco duro de sistema de una
máquina.
Amazon Glacier es un servicio de almacenamiento de coste extremadamente bajo, que ofrece
almacenamiento seguro y duradero para realizar copias de seguridad y archivar datos. Para
mantener un bajo coste, Amazon Glacier está optimizado para datos a los que se accede con
poca frecuencia y para cuando los tiempos de recuperación de varias horas son necesarios (3-
5 horas tras la solicitud). Amazon Glacier permite a los clientes almacenar con seguridad
cantidades pequeñas o grandes de datos por apenas 0,01 USD por gigabyte al mes, lo que
representa un ahorro significativo en comparación con una solución centralizada en una
empresa.
AWS Import / Export está pensado para el movimiento de grandes cantidades de datos dentro
y fuera de AWS usando para ello dispositivos portátiles de almacenamiento y siendo estos
transportados por la red de paquetería y de alta velocidad de Amazon y sin pasar por Internet.
Para tamaños significativos de datos, AWS Import / Export es a menudo más rápido que la
transferencia de Internet y mucho más rentable que hacer una mejora sustancial en su conexión
para tal efecto.
Computación
Amazon Elastic Compute Cloud (Amazon EC2) proporciona capacidad de computación de
tamaño variable en la nube. En cuestión de minutos, se pueden crear instancias de EC2 (que
son máquinas virtuales) sobre las que se tiene control completo bien por SSH o RDP. En el
contexto del DR, esta capacidad de crear rápidamente máquinas virtuales que se pueden
controlar es fundamental. Describir todas las características de Amazon EC2 está fuera del
alcance de este documento, nos centraremos en los aspectos de Amazon EC2 que son más
relevantes para DR.

Amazon Machine Images (AMI) son máquinas virtuales que están pre configuradas con los
sistemas operativos y aplicaciones. En el contexto de la DR, se recomienda encarecidamente
se tengan baterías de AMIs configurados e identificados para que puedan poner en marcha
como parte de su proceso de recuperación. Estas AMI debe ser pre configuradas con cualquier
sistema operativo y conjunto de aplicaciones.
Instancias reservadas de Amazon EC2 a menudo se utilizan para recibir un descuento
significativo en el costo de funcionamiento de una instancia EC2, tienen otra ventaja que es
especialmente relevante para DR. Instancias reservadas ayudan a asegurar que la capacidad
que necesita está a su disposición cuando sea necesario.
Zonas de Disponibilidad (AZ) son lugares distintos que se han diseñado para ser aislados de
fallas en otras zonas de disponibilidad y proporcionan conectividad de red de latencia bajo costo,
baja a otras zonas de disponibilidad de la misma región. Con el lanzamiento de los casos en
zonas de disponibilidad por separado, usted puede proteger sus aplicaciones de la falla de un
solo lugar. Regiones consisten en una o más zonas de disponibilidad.
Servicio de importación EC2 VM Amazon le permite importar imágenes de máquinas virtuales
de su entorno existente a instancias de Amazon EC2.
Networking
Cuando se trata de un desastre, es muy probable que se tenga que modificar la configuración
de red que está fallando a otro sitio.
Amazon Route 53 es un sistema de nombres de dominio altamente disponible y escalable
(DNS) de servicios web. Está diseñado para dar a los desarrolladores y empresas una manera
extremadamente fiable y rentable para los usuarios finales ruta para las aplicaciones de Internet.
Dispone de opciones de balanceo de carga Round Robin y por peso configurable además de
chequeos de “salud” en servicios y conmutación por error, lo que convierte a este servicio en
una de las piedras angulares de la recuperación de desastres.
Elastic IP las direcciones IP elásticas son direcciones IP diseñadas para la computación
dinámica en la nube. A diferencia de las direcciones IP estáticas tradicionales, sin embargo, las
direcciones IP elásticas permiten enmascarar instancia o disponibilidad fallas de zona mediante
posibilidad de reasignar las direcciones IP públicas a instancias de su cuenta en una región

particular o a otra instancia de máquina o servicio. Para DR, también puede asignar previamente
algunas direcciones IP para los sistemas más críticos para que sus direcciones IP ya se conocen
antes de que ocurra un desastre. Esto puede simplificar la ejecución del plan de DR.
Elastic Load Balancer distribuye automáticamente el tráfico entrante de aplicaciones a través
de múltiples instancias de Amazon EC2. Esto le permite alcanzar una mayor tolerancia a fallos
en las aplicaciones, proporcionando la perfección la cantidad de capacidad de balanceo de
carga necesaria en respuesta al tráfico de aplicación entrante. Así como usted puede pre-
asignar direcciones IP elásticas, usted puede pre-asignar su Elastic Load Balancer para que su
nombre DNS, lo que puede simplificar la ejecución de su plan de DR.
Amazon Virtual Private Cloud (Amazon VPC) le permite aprovisionar una sección privada y
aislada de la nube de Amazon Web Services en la que puede iniciar los recursos de AWS en
una red virtual que defina. Con AVPC se tiene el control completo sobre el entorno de red virtual,
incluyendo la selección de su propio rango de direcciones IP, la creación de subredes, y la
configuración de las tablas de rutas y puertas de enlace de la red. Esto permitirá crear una
conexión VPN entre su centro de datos corporativo y la VPC y aprovechar la nube de AWS
como una extensión de su centro de datos corporativo. En el contexto de la DR, se puede utilizar
Amazon VPC para replicar la topología de red existente a la nube, lo que puede ser
especialmente apropiado cuando se replican las aplicaciones de empresa que suelen estar en
la red interna.
Amazon Direct Connect se trata de una conexión de red dedicada a su centro de datos con el
entorno AWS. En muchos casos, esto puede reducir sus costes de red, aumentar el rendimiento
de ancho de banda y proporcionar una experiencia de red más consistente que las conexiones
de Internet.
AWS Direct Connect ofrece conexiones de 1 Gbps y 10 Gbps, y puede proporcionar fácilmente
varias conexiones si necesita más capacidad o alta disponibilidad. También puede utilizar AWS
Direct Connect en lugar de establecer una conexión VPN a través de Internet con su Amazon
VPC, evitando la necesidad de utilizar el hardware de VPN, que normalmente no admite
velocidades de transferencia de datos por encima de 4 Gbps.

Bases de datos
Para la base de datos, se podría considerar el uso de estos servicios de AWS:
Amazon Relational Database Service (Amazon RDS) es una base de datos relacional en la
nube. Se podría utilizar Amazon RDS ya sea en la fase de preparación para la DR para mantener
sus datos críticos en una base de datos replicada y / o en la fase de recuperación para ejecutar
la base de datos de producción. Se ofrece la posibilidad de establecer RDS bajo Oracle,
Microsoft SQL Server y MySQL. Permiten reservar por cantidad de almacenamiento o por IOPS.
Amazon SimpleDB es una base de datos no relacional, muy rápida, de alta disponibilidad y
muy flexible que minimiza el trabajo de administración sobre la base de datos. También se
puede utilizar en la preparación y la fase de recuperación de DR.
También puede instalar y ejecutar su opción de software de base de datos en Amazon EC2 y
podrás elegir entre una gran variedad de sistemas de bases de datos líderes.
Despliegue
En Amazon EC2 se puede utilizar herramientas de automatización de la implementación y
procesos de instalación / configuración del software que se ejecutará posterior al lanzamiento.
Se recomienda usar e invertir cierto tiempo en esto pues acelerará el RTO. Esto puede ser muy
útil en la fase de recuperación para crear el conjunto necesario de recursos de forma
automatizada.
AWS Cloud Formation ofrece a los desarrolladores y administradores de sistemas una manera
fácil de crear una colección de recursos de AWS relacionados en forma ordenada y predecible.
Puede crear plantillas para sus entornos y desplegar colecciones asociadas de recursos
(llamada pila), según sea necesario.
Seguridad
Hay muchas características relacionadas con la seguridad en los servicios de AWS. AWS
también proporciona información de cumplimiento y más en el Centro de seguridad de AWS.
Una discusión completa de la seguridad está fuera del alcance de este documento.

Estrategias de Recuperación de Desastres
En esta sección discutiremos a través de cuatro escenarios de DR en los que AWS es
especialmente apropiado y compara AWS con otros métodos tradicionales de DR:
1. Estrategia de copia de seguridad y restauración
2. Estrategia Luz Piloto
3. Estrategia Warm Standby
4. Estrategia Multi-site
Es importante tener en cuenta que estos son sólo ejemplos de los posibles enfoques y las
variaciones y combinaciones de los mismos son posibles.
Estrategia de copia de seguridad y restauración
Copia de seguridad y restauración con Amazon S3
En los entornos más tradicionales, los datos se guardan en una copia de seguridad en cinta y
se envía fuera del sitio con regularidad. Su tiempo de recuperación será el más largo con este
método. Amazon S3 se propone como un destino ideal para los datos de copia de seguridad,
ya que está diseñado para proporcionar 99.999999999% (11 9s) la disponibilidad de los objetos
durante en un año. La transferencia de datos hacia y desde Amazon S3 se realiza normalmente
a través de la red, y por lo tanto es accesible desde cualquier lugar. Hay muchas soluciones de
copia de seguridad comerciales y de código abierto, por línea de comandos que hacen copia de
seguridad en Amazon S3. Si el volumen de datos es mayor el servicio de importación /
exportación AWS permite la transferencia de grandes cantidades de datos mediante el envío de
dispositivos de almacenamiento directamente a AWS a través del servicio de paquetería de
Amazon.
Para los sistemas que se ejecutan en AWS, los clientes también hacen su copia de seguridad
en Amazon S3. Las instantáneas de los volúmenes Elastic Block Store (EBS) y copias de
seguridad de Amazon RDS se almacenan en Amazon S3. Como alternativa, puede copiar los
archivos directamente en Amazon S3, o puede optar por crear archivos de copia de seguridad
y copiarlos en Amazon S3. Hay muchas soluciones de copia de seguridad que se almacenan

los datos de copia de seguridad de Amazon S3, y estos pueden ser utilizados en sistemas EC2
de Amazon también.
La recuperación de datos en un escenario de desastre tiene que ser testada de forma rápida y
fiable. Los clientes deben asegurarse de que sus sistemas están configurados para el
mantenimiento adecuado de los datos, la seguridad de los datos, y chequear que se han puesto
a prueba sus procesos de recuperación de información.

Copia de seguridad y recuperación con Amazon Glacier
Amazon Glacier está pensado para las copias de seguridad de larga duración, es decir, aquellas
copias de ejercicios anteriores que previsiblemente no vamos a tener que tocar.
Es un servicio de almacenamiento en la nube muy barato ($0,01 por GB / mes) pero en
contrapartida requiere un tiempo algo más extendido para las tareas de copia y recuperación.
Para la copia, se entiende de un gran volumen de datos, se puede hacer o bien por internet, por
Amazon Direct Connect o por el servicio de paquetería de Amazon Import/Export considerando
los tiempos que sean pertinentes según la cantidad de datos.
Para la recuperación desde que se hace una solicitud a Amazon Glacier hasta que te lo puedes
descargar hay un lapso de entre 3 y 5 horas más el tiempo que se tarde en recibir los datos por
cualquiera de los tres métodos mencionados anteriormente.
Estrategia luz piloto
La idea del piloto es una analogía que viene del calentador de gas. En un calentador de gas,
una pequeña llama que siempre está encendida puede encender rápidamente todo el horno
para calentar una casa. Este escenario es similar a la estrategia de copia de seguridad y
restauración, sin embargo, hay que asegurarse de que dispone de los elementos básicos más
importantes de su sistema ya configurado y funcionando en AWS. A esto le llamaremos el piloto.
Cuando llegue el momento de la recuperación, se armará rápidamente un entorno de
producción a gran escala alrededor del núcleo crítico al que llamamos piloto.
Los elementos de infraestructura para el propio piloto suelen incluir los servidores de bases de
datos. Dependiendo del sistema, puede haber otros datos críticos fuera de la base de datos que
necesitarían ser replicados a AWS. Este es el núcleo fundamental del sistema (el piloto)
alrededor de la cual todas las demás piezas de infraestructura de AWS pueden ser rápidamente
aprovisionados para restaurar el sistema completo.
Para poner en servicio el resto de la infraestructura necesaria para restablecer los servicios
críticos del negocio, lo más habitual es que los servidores más importantes estén pre-
configurados agrupados como Amazon Machine Images (AMI), y que estén listos para ponerse
en marcha en cualquier momento. Al inicio de la recuperación, dichas AMIs encontrarán su

papel dentro del entorno que se genere alrededor del piloto. Desde el punto de vista de la red,
puede utilizar las direcciones IP elásticas (que pueden ser pre asignadas en la fase de
preparación para DR) y asociarlos con sus respectivas máquinas, o utilizar Elastic Load
Balancing para distribuir el tráfico a múltiples instancias. A continuación, solo habrá que
actualizar los registros DNS para que apunte a la instancia de Amazon EC2 o al Elastic Load
Balancer utilizando un CNAME.
En los sistemas menos críticos que permitan un mayor RTO otra visión sería tener los paquetes
de instalación e información de configuración disponible en AWS, por ejemplo, en una
instantánea con EBS (recordemos que esto es parecido a una copia de un disco duro de
sistema). Esto acelerará la configuración del servidor de aplicaciones, ya que se puede crear
rápidamente varios volúmenes en varias zonas de disponibilidad, para adjuntar a las instancias
de EC2. A continuación, puede instalar y configurar con gran parte del trabajo ya hecho.
La estrategia luz piloto le dará un tiempo de recuperación más rápido que el escenario anterior
"copia de seguridad y restauración", debido a que las piezas centrales del sistema ya están en
marcha y se mantienen continuamente actualizados. Todavía habrá que hacer algunas tareas
de instalación y configuración para recuperar completamente las aplicaciones pero con esta
estrategia ganaremos bastante velocidad. AWS permite automatizar el aprovisionamiento y la
configuración de sus recursos de infraestructura, que puede resultar un beneficio significativo
para ahorrar tiempo y ayudar a proteger contra los errores humanos típicos de cuando se trabaja
con prisa y bajo la presión levantar un sistema de producción caído.
Fase de preparación:
En la siguiente figura se muestra la fase de preparación, en la que es necesario tener los datos
cambian regularmente replican en el piloto, el pequeño núcleo alrededor del cual se iniciará el

entorno completo en la fase de recuperación. Sus datos menos actualizados con frecuencia,
como los sistemas operativos y las aplicaciones pueden ser actualizados periódicamente y se
almacena como Amazon Machine Images (AMI).
Puntos clave para la preparación:
• Establecer instancias de EC2 para replicar o duplicar sistemas o datos.
• Asegúrese de que existan paquetes de software personalizados disponibles en AWS.
• Crear y Mantener Amazon Machine Images (AMI) de servidores de claves que requieren
una rápida recuperación.
• Ejecutar regularmente estos servidores, ponerlos a prueba, y aplicar las actualizaciones
de software y cambios de configuración.
• Considere la posibilidad de automatizar el aprovisionamiento de recursos de AWS.

Fase de recuperación:
Para recuperar el entorno del piloto, se empezaría por levantar sus sistemas a partir de Amazon
Machine Images (AMI) y en cuestión de minutos tendría sus servidores principales funcionando.
Para los servidores de datos dinámicos, puede cambiar su tamaño para acomodar los
volúmenes de datos de producción según sea necesario en ese momento o agregar capacidad
de la manera que estime oportuna. El escalamiento horizontal, si es posible, a menudo es la
mejor manera de escalar un sistema y el enfoque para añadir capacidad de un sistema, sin
embargo, también es posible escalar verticalmente y usar grandes instancias de EC2. Desde
una perspectiva de red, las actualizaciones DNS pertinentes se pueden realizar en paralelo.
Una vez recuperado, debe asegurarse de que la redundancia se restablezca lo antes posible.
Si bien es poco probable una caída de su entorno DR poco después de que se convierta en su
entorno de producción, es un riesgo que existe, por lo que es recomendado seguir tomando
copias de seguridad e incluso considerar una capa adicional de redundancia en la capa de datos

Puntos clave para la recuperación:
• Iniciar las instancias de los servidores desde las AMI.
• Cambiar el tamaño y / o el escalado de las bases de datos, en caso necesario.
• Cambiar DNS para apuntar a los servidores EC2.
• Instalación y configuración de los sistemas no basados en AMI, idealmente de forma
automatizada.
Dominios Públicos y DNS Globales
En caso de que tengamos direcciones y dominios públicos apuntando a nuestros servicios y
aplicaciones y no los tengamos asociados a una IP elástica de Amazon habrá que tener en
cuenta el tiempo que tardan en actualizarse y replicarse estos nombres de dominio a nivel global
para que los DNS de todo el mundo apunten a nuestra nueva dirección IP. Esto puede tomar
horas incluso días según el TTL configurado en nuestros registros, por lo que es un aspecto a
estudiar en la planificación del DR.
Estrategia Warm Standby
La estrategia Warm Standby va un poco más allá que las anteriores. Se trata de configurar el
sistema como un clúster activo-pasivo, la parte pasiva de reducido tamaño para pagar lo
mínimo. Su factor clave es que disminuye aún más el tiempo de recuperación debido a que en
este caso, dejamos algunos servicios más siempre funcionando. Mediante la identificación de
los sistemas críticos de producción, se podrán duplicar totalmente estos sistemas de AWS y
tenerlos siempre funcionando.
Estos servidores se pueden ejecutar en una flota de tamaño mínimo de instancias de EC2 en
los tamaños más pequeñas posibles. Esta solución no se dimensiona para acomodar una carga
plena como si realmente estuviese en producción, pero debe ser completamente funcional.
Puede ser utilizado como entorno de no producción, como las pruebas, control de calidad o uso
interno.
En caso de desastre, el sistema se escala rápidamente para manejar la carga real de
producción. En AWS, esto se puede hacer mediante la adición de más instancias al balanceador
de carga y / o cambiando el tamaño de los servidores de pequeña capacidad para funcionar en

grandes tipos de instancias de EC2. Como se indicó anteriormente, la escala horizontal, si es
posible, se prefiere habitualmente al escalado vertical.
El siguiente diagrama muestra la fase de preparación de una estrategia Warm Standby, en la
que el centro de datos original y principal funciona cara a cara con otro replicado a escala
pequeña en AWS.
• Crear instancias de EC2 para replicar o duplicar datos.
• Crear y mantener Amazon Machine Images (AMI).

• Ejecutar la aplicación mediante una huella mínima de instancias EC2 o infraestructura de
AWS.
• Revisión y actualización de software y los archivos de configuración de acuerdo con su
entorno real.
En el caso de fallo del sistema de producción, el entorno de espera se ampliará para carga de
producción y los registros DNS se cambian para dirigir todo el tráfico a AWS.
• Iniciar las aplicaciones en grandes tipos de instancia EC2, según sea necesario (escalado
vertical).
• Aumentar el tamaño de las flotas en servicio EC2 con el equilibrador de carga (escala
horizontal).

• Cambiar los registros DNS de manera que todo el tráfico se encamina al entorno AWS.
• Considere el uso de la escala automática a derecha el tamaño de la flota, o acomodar el
aumento de la carga.
Estrategia Multi-Site
Una solución multi sitio ejecuta el centro de datos principal de producción replicado
completamente en AWS con una configuración activo-activo. El método de replicación de datos
a emplear estará determinado por sus requerimientos de punto objetivo de recuperación RPO.
Como veremos más adelante existen varios métodos de replicación que habrá que manejar para
cada situación.
Un servicio de DNS balanceado, como podría ser Amazon Route 53, se utilizará para dirigir el
tráfico de producción a los diferentes sitios. Una porción de tráfico se destinará a la
infraestructura de AWS, y el resto se destinará a su infraestructura propia o centro de datos
principal.
En una situación de desastre en el centro de datos principal, se puede ajustar la ponderación
de tráfico en el DNS y enviar todo el tráfico a los servidores de AWS. La capacidad del servicio
y el dimensionamiento de AWS podrán aumentarse rápidamente para manejar la carga de
trabajo de producción del momento. El servicio de escalado automático de EC2 se puede usar
para automatizar este proceso. Es posible que se necesite preparar la aplicación para detectar
la insuficiencia de los servicios de base de datos principal, escalarla y detener los servicios de
bases de datos paralelas que se ejecuten en AWS.
El coste de este escenario se determina por la cantidad de tráfico de producción está a cargo
de AWS en funcionamiento normal y el tamaño de sus instancias. En la fase de recuperación,
usted sólo paga por lo que usa, además y por el tiempo que se requiere el entorno DR a escala
completa. Se pueden reducir aún más los costes del escenario con la compra de instancias
reservadas para el "always on" de los servidores en AWS.
En la figura siguiente, vemos el uso de DNS para dirigir una parte del tráfico al sitio AWS. La
aplicación en AWS puede acceder a fuentes de datos en el sistema de producción en el lugar.
Los datos se replican o refleja a la infraestructura AWS.

Puntos clave para la preparación:
• Configure su entorno de AWS para duplicar el entorno de producción.
• Establecer ponderación DNS o tecnología similar para distribuir las solicitudes de entrada
a ambos sitios.
La siguiente figura muestra lo que ocurre cuando se produce un desastre en el datacenter
principal. El tráfico se corta a la infraestructura AWS mediante la actualización de DNS.

• Cambiar la ponderación de DNS, de modo que todas las peticiones son enviadas al sitio
de AWS.
• Tener lógica de la aplicación para la conmutación por error de utilizar los servidores de
bases de datos locales de AWS.
• Considere el uso de la escala automática para automáticamente justo el tamaño de la
flota de AWS.
Puede aumentar aún más la disponibilidad de su solución multi-site mediante el diseño de
arquitecturas Multi-AZ.

Replicación de Datos
Cuando la replicación de datos a una ubicación remota, hay algunos factores a tener en cuenta.
• Distancia entre los sitios: distancias más grandes por lo general son objeto de mayor
latencia y / o inestabilidad. Hay que manejar esto.
• Ancho de banda disponible
• La velocidad de datos requerida por la aplicación: velocidad de datos debe ser menor que
el ancho de banda disponible.
• La tecnología de replicación debe ser paralelo (por lo que se puede utilizar la red de
manera efectiva).
Hay dos enfoques principales en la replicación de datos: síncrona y asíncrona.
Replicación sincrónica
Los datos se actualizan atómicamente en múltiples ubicaciones. Esto supone una dependencia
grande en el rendimiento y la disponibilidad de la red.
Replicación asíncrona
Los datos no se actualizan atómicamente en varias ubicaciones. Se transfiere en base al
rendimiento de la red y la disponibilidad lo permita, y la aplicación continúa escribiendo datos
que pueden no ser completamente todavía replicados. Esto supone
Muchos de los sistemas de bases de datos soportan la replicación de datos asincrónica. La
réplica de base de datos puede ser situada a distancia, y la réplica no tiene que estar
completamente sincronizado con el servidor de base de datos principal. Esto es aceptable en
muchos escenarios, por ejemplo, como una fuente de copia de seguridad o informes / de sólo
lectura casos de uso.
Aconsejamos a los clientes a comprender la tecnología de replicación utilizada en su solución
de software. Un análisis detallado de las diferentes tecnologías de replicación se encuentra
fuera del alcance de este documento.
En AWS, zonas de disponibilidad dentro de una región están bien conectados, pero físicamente
separados. Por ejemplo, cuando se despliega en el modo "Multi-AZ", el servicio de base de

datos relacional Amazon utiliza replicación sincrónica para duplicar los datos en una segunda
zona de disponibilidad. Esto asegura que los datos no se pierden si la zona de disponibilidad
principal no esté disponible.
Las Regiones de AWS son completamente independientes unas de otras, pero no hay
diferencias en la forma de acceder a ellos y utilizarlos por lo que para los usuarios es
transparente. Esto permite a los clientes crear procesos de recuperación de desastres que
abarcan distancias continentales, sin los problemas o los costos que esto suele incurrir. Los
clientes pueden realizar una copia de seguridad de datos y sistemas de dos o más regiones de
AWS permiten la restauración del servicio, incluso en el caso de que desastres muy grandes
geográficamente pudiesen ocurrir. Los clientes pueden utilizar AWS Regiones para servir a sus
clientes finales en todo el mundo, con relativamente baja complejidad de sus procesos
operativos.

Mejoras al plan de DR
Se deben seguir algunos pasos importantes con el fin de tener un plan de DR sólido. En esta
sección se describen algunos de esos pasos principales.
Pruebas
Después de que su solución de DR esté en su lugar, tiene que ser probado. Un "Game Day" es
cuando se hace ejercicio una conmutación por error para el entorno DR, se debe asegurar que
exista suficiente documentación disponible para hacer el proceso lo más simple posible por si
el desastre real tiene lugar. La práctica de conmutar a un entorno duplicado para probar la
hipótesis del game day es rápido y rentable en AWS y normalmente no es necesario tocar el
entorno de producción. Se puede utilizar AWS CloudFormation para implementar entornos
completos de AWS.
Categorizar las pruebas es fundamental para asegurar que se está cubierto contra una multitud
de diferentes tipos de desastres. Los siguientes son ejemplos de escenarios de "Game Day":
• Pérdida de suministro eléctrico a un sitio o un conjunto de máquinas
• La pérdida de conectividad ISP a un solo sitio
• Infección por malware en los servicios de negocio que afecten a múltiples sitios
• Error del usuario que provocó la pérdida de los datos y que requiere una restauración a
punto en el tiempo.
Supervisión y alertas
Es necesario tener controles periódicos y la supervisión suficiente en el lugar para que le avise
cuando su entorno de DR se ha visto afectada por un fallo del servidor, problemas de
conectividad, y las cuestiones de aplicación. Amazon CloudWatch proporciona acceso a
métricas sobre recursos de AWS. Las alarmas se pueden configurar en base a los umbrales
definidos en cualquiera de los indicadores y, cuando se requiera el servicio de notificación de
mensajes simples Amazon se puede usar para alertar en caso de un comportamiento
inesperado.
También puede seguir utilizando cualquier herramienta de alerta de que su empresa utiliza para
monitorear las métricas de instancia, así como sistema operativo invitado estadísticas y estado
de las aplicaciones actuales de vigilancia y control.

Las copias de seguridad
Una vez que haya conmutado a su entorno de DR, se deben continuar haciendo copias de
seguridad periódicas. Hacer pruebas de copia de seguridad y restauración con regularidad es
esencial como solución de refuerzo.
AWS da la flexibilidad para hacer pruebas de DR frecuentes y baratas sin necesidad de la
infraestructura de DR que esté siempre levantada.
Acceso de Usuario
AWS le permite proteger el acceso a los recursos de su entorno DR mediante el uso de Identity
Access Management (IAM). De esta manera se pueden crear políticas de seguridad basadas
en segregación de responsabilidades de los usuarios mientras trabajan en el entorno de DR.
Automatización
Puede automatizar el despliegue de aplicaciones en los servidores basados en AWS y los
servidores de correo locales mediante el uso de la gestión de configuración o software de
automatización. Esto permitirá manejar la aplicación y gestionar los cambios de configuración
en entornos DR con facilidad. AWS CloudFormation le permitirá automatizar las tareas y trabajar
con herramientas de infraestructura. Los datos de usuario se pueden pasar a una primera
instancia en el arranque y después entregarse a una herramienta de gestión de la configuración
para determinar el tipo de instancia o papel para asegurarse de que el software y la
configuración correcta se despliegan. El objetivo general debería ser que sus servicios terminan
en el estado final en el que los necesita tan automáticamente como sea posible.
El Auto Escalado de Amazon se puede utilizar para asegurarse de que el grupo de instancias
es del tamaño adecuado para satisfacer la demanda en base a los parámetros que se
especifiquen en CloudWatch. Esto significa que en una situación DR, ya que su base de
usuarios comienza a utilizar el entorno de más, la solución puede escalar de forma dinámica
para satisfacer esta creciente demanda. Después de terminado el evento y el uso potencial
disminuye, la solución puede escalar de nuevo a un nivel mínimo de servidores.

Licencias de software y DR
Asegurarse de que está correctamente licenciado dentro de su entorno de AWS es tan
importante como la concesión de licencias en cualquier otro entorno. Amazon ofrece una
variedad de modelos para hacer que las licencias sean fáciles de manejar. La más típica sería
el modelo (BYOL, Bring Your Own License) en la que cada instancia de máquina en AWS se
podría licenciar con licencias existentes o compradas al efecto. Como alternativa, hay una gama
de software en Amazon Market Place en las que el costo de la licencia está incluida en la tarifa
por hora. Esto se conoce como "licencia incluida".
Si utiliza sus propias licencias le permitirá aprovechar sus inversiones de software existentes
durante un desastre. "Licencia Incluida" minimiza los costos de licencia iniciales para un sitio de
DR que no se acostumbra usar en el día a día, y que se usará durante una prueba o caso de
DR.
Conclusión
Existen muchas opciones y variaciones para DR, y el presente documento pone de manifiesto
alguno de los patrones comunes, que van desde la simple copia de seguridad y restauración
simple de datos a soluciones multi-sitio tolerantes a fallos. AWS le da control pormenorizado y
una solución modular para construir la solución DR apropiada, dadas sus objetivos DR (RTO y
RPO) y el presupuesto.
Los servicios de AWS están disponibles a la carta y sólo se paga por lo que usa. Esta es una
ventaja clave para DR, donde se necesita rápidamente la infraestructura significativa, pero sólo
en el caso de un desastre.

Realizado por
Francisco Javier Jiménez Urbano
grhs@grayhats.eu | grayhats.eu
Basado en:
Using AWS for Disaster Recovery White Paper | Glen Robinson, Ianni Vamvadelis, and Attila Narin

Estrategias de recuperacion de desastres y alta disponibilidad con amazon web services

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Estrategias de recuperacion de desastres y alta disponibilidad con amazon web services

Similar a Estrategias de recuperacion de desastres y alta disponibilidad con amazon web services (20)

Estrategias de recuperacion de desastres y alta disponibilidad con amazon web services