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.

Pág. 02


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.

Pág. 03


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.

Pág. 04


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.

Pág. 05


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.

Pág. 06


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.

Pág. 07


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

Pág. 08


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.

Pág. 09


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


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

Pág. 11


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


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

Pág. 13


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


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.

Pág. 15


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


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

Pág. 17


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).

Pág. 18


• 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).

Pág. 19


• 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.

Pág. 20


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.

Pág. 21



• 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.

Pág. 22


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

Pág. 23


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


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.

Pág. 25


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.

Pág. 26


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.

Pág. 27


Realizado por

Francisco Javier Jiménez Urbano

[email protected] | grayhats.eu

Basado en:

Using AWS for Disaster Recovery White Paper | Glen Robinson, Ianni Vamvadelis, and Attila Narin

mailto:[email protected]

http://grayhats.eu/

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

Software