Documentos de Académico
Documentos de Profesional
Documentos de Cultura
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
Es tan eficiente la
solución en AWS Resumen Ejecutivo
que una vez Cuando una empresa u organización debe mantener un nivel de alta confiabilidad y
diseñado y disponibilidad en una aplicación o sistema siempre ha soñado con tener un centro de datos o
montado el centro medios alternativos que pudiesen reemplazar en muy poco tiempo aquellos recursos que por
de respaldo sólo algún desastre o error queden inutilizables.
pagaremos
cuando se use, es Digo que “siempre se ha soñado” porque normalmente esta solución pasaba por duplicar y
decir, cuando el 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
desastre se
de mantenimiento tampoco despreciable para tener una infraestructura que habitualmente
produzca. Si es
quedaba en una situación de infrautilización. Esta circunstancia dejaba los centros de datos
que se produce.
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.
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.
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.
Pág. 03 Recuperación de Desastres con AWS
Esto habilita a las El error humano es la causa de una gran parte del tiempo de inactividad de un sistema. AWS
organizaciones ofrece herramientas para permitir la separación de funciones para permitir un diseño basado en
para poner a el mínimo privilegio (dos de los principios básicos del Esquema Nacional de Seguridad). AWS
prueba los también le permite automatizar la implementación de entornos completos, lo que permite
cambios de escenarios pre-configurados (Amazon Cloud Formation).
configuración, Los entornos de prueba de DR en AWS se pueden levantar muy rápidamente, y pueden ser
actualizaciones y tratados como un recurso de “quita y pon”. Esto habilita a las organizaciones para poner a
pruebas en un prueba los cambios de configuración, actualizaciones y pruebas en un entorno duplicado antes
entorno duplicado de llevar los cambios de configuración al entorno de producción, sin la necesidad de un entorno
antes de llevar los de prueba a gran escala dedicado, que a menudo se infrautilizada.
cambios de
configuración al Tiempo Objetivo de Recuperación y Punto Objetivo de Recuperación
entorno de
producción. Usaremos las siguientes métricas de amplio reconocimiento para la planificación de la
recuperación de un desastre.
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.
Pág. 04 Recuperación de Desastres con AWS
Los servicios de Los departamentos de TI planifican soluciones para proporcionar de forma rentable la
negocio críticos recuperación del sistema basado en el RPO dentro de la línea de tiempo y nivel de servicio
se establecen y establecido por la RTO.
mantienen sobre
esta Prácticas habituales de inversión en Recuperación de Desastres
infraestructura y
Un enfoque tradicional de la DR implica diferentes niveles de la duplicación fuera de las
son probados a
instalaciones donde están los datos y la infraestructura.
intervalos
regulares. 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:
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.
Pág. 05 Recuperación de Desastres con AWS
Al reaccionar ante
un desastre, es
Servicios Esenciales de AWS para
fundamental, Recuperación de Desastres
provisionar de
Antes de discutir los distintos enfoques y estrategias de la DR, es importante revisar los servicios
forma rápida los
y funciones que son los más relevantes para la recuperación de desastres de AWS. En esta
recursos de
sección se ofrece un resumen.
computación para
hacer funcionar En la fase de preparación de la DR, es esencial tener en cuenta el uso de los servicios y
su sistema en funciones que soportan la migración de datos y almacenamiento duradero, ya que permiten a
AWS o para restaurar una copia de seguridad de datos críticos para AWS cuando ocurre un desastre. Para
lanzar la algunos de los escenarios que implican tanto a escala reducida o una implementación
conmutación por totalmente a escala de su sistema de AWS, se requerirán también recursos informáticos.
error de los
recursos ya se Al reaccionar ante un desastre, es fundamental, provisionar de forma rápida los recursos de
estén ejecutando computación para hacer funcionar su sistema en AWS o para lanzar la conmutación por error
en AWS. 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).
Pág. 06 Recuperación de Desastres con 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.
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.
Pág. 07 Recuperación de Desastres con AWS
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.
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.
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.
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.
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.
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.
Pág. 09 Recuperación de Desastres con AWS
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.
Pág. 10 Recuperación de Desastres con AWS
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.
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
Pág. 11 Recuperación de Desastres con AWS
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.
Pág. 12 Recuperación de Desastres con AWS
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.
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
Pág. 13 Recuperación de Desastres con AWS
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
Pág. 14 Recuperación de Desastres con AWS
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).
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
Pág. 16 Recuperación de Desastres con AWS
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.
Fase de preparación:
Fase de recuperación:
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).
Pág. 19 Recuperación de Desastres con AWS
• 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.
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.
Fase de preparación:
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.
Pág. 20 Recuperación de Desastres con AWS
Fase de recuperación:
• 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.
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).
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
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
Pág. 23 Recuperación de Desastres con AWS
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.
Pág. 24 Recuperación de Desastres con AWS
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":
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.
Pág. 25 Recuperación de Desastres con AWS
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.
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
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.
Pág. 26 Recuperación de Desastres con AWS
Licencias de software y DR
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.
Pág. 27 Recuperación de Desastres con AWS
Realizado por
Basado en:
Using AWS for Disaster Recovery White Paper | Glen Robinson, Ianni Vamvadelis, and Attila Narin