Tres consejos para crear sistemas de alta disponibilidad en la nube de Amazon

Amazon Web Services constituye un buen negocio con sus zonas de disponibilidad (AZ), y recomienda que los clientes utilicen múltiples AZ para construir nubes que sean tolerantes a fallas, como la que la compañía ha experimentado recientemente.

Pero los expertos dicen que utilizar una segunda zona de disponibilidad cuando está empezando una instancia AWS no es una panacea para evitar que la aplicación descienda durante un apagón, ni es tan fácil de hacer como simplemente apretar un botón. Y va a costar más –a veces más del doble del costo de la implementación en una sola AZ.

Hay una gran variedad de herramientas para que los clientes creen sistemas de alta disponibilidad, tolerantes a fallas en la nube de Amazon. Una opción es utilizar los servicios propios de AWS, específicamente su balanceadores de carga elástica (ELB) que permiten mover las cargas de trabajo de una zona de disponibilidad a otra. Sin embargo, AWS reconoció en un informe post-mortem sobre el apagón de octubre que incluso sus ELB se vieron afectados.

1. Diseño arquitectónico

Hay una gran variedad de proveedores –algunos los llaman herramientas de administración de acceso a la nube– que se encargarán de este proceso de creación de sistemas de nubes de alta disponibilidad utilizando AWS. RightScale y enStratus son dos de los más populares. RightScale ofrece soluciones pre envasadas que se propagan a través de las cargas de trabajo AZs, o incluso de varios proveedores. Pero como dice el analista IaaS de Gartner, Kyle Hilgendorf: “Es una jugada costo versus riesgo. No es fácil, y no es barato”. Los sistemas de nubes de alta disponibilidad simplemente cuestan más y añaden complejidad.

Las aplicaciones tolerantes a fallas tienen que ser construidas para ser escalables horizontalmente. En un mundo ideal serían apátridas, lo que significa que no cambiarían constantemente nuevos datos que ingresen y se guarden. En la mayoría de los casos, se requiere hacer una copia de su sistema en otro lugar para asegurar la tolerancia a fallas durante un corte de luz. Aun cuando se tiene en cuenta todo esto, todavía puede haber problemas.

El CTO de RightScale, Thorsten von Eicken, señala que durante el último corte de Amazon, las operaciones internas dentro de RightScale tuvieron problemas de escala a través de zonas de disponibilidad en la nube de Amazon. AWS admitió que estaba “estrangulando” clientes, lo que significa que limitaban la cantidad de datos que podían transferir de una AZ a otra, algo que ha prometido no será tan agresivo en el futuro. El punto es que, incluso si un sistema está diseñado para ser tolerante a fallas, todavía pueden surgir problemas inesperados.

Sin embargo, hay muchas maneras de construir sistemas tolerantes a fallas, indica von Eicken. Los clientes pueden crear dos servicios activo-activo, o crear uno activo y un “clon” en espera, por ejemplo. Sin embargo, cada uno tiene sus propias ventajas y consideraciones de costos.

Tolerancia a fallas básica: En una arquitectura tolerante a fallas básicas, hay una arquitectura de producción y una “arquitectura clon” de modo de espera. Si hay una falla en la AZ maestra, entonces el sistema puede cambiar manualmente para utilizar la versión clonada, un proceso que generalmente no solo requiere un manual de conmutación, sino que las bases de datos se suelen replicar en Amazon Simple Storage Service (S3) aproximadamente cada 10 minutos, así que cuando una conmutación ocurre, podría perder un valor de datos de los últimos 10 minutos, afirma RightScale.

Sistema avanzado tolerante de fallas: Un sistema más avanzado crea dos sistemas activos que se ejecutan simultáneamente. En esta configuración activo-activo, cualquier instancia, o incluso una AZ completa puede fallar y el sistema automáticamente será capaz de completar todas sus funciones desde otra AZ que está pre-construida y lista para ejecutarse. RightScale señala que esta arquitectura va a costar más del doble del costo de una sola instalación AZ, porque todos los servicios de la AZ única no solo tienen que ser replicados, sino que hay costos de transferencia de datos que vienen con la garantía de que ambos sistemas se mantienen al día actualizados en tiempo real.

También hay otras opciones.

2. Diseño de aplicaciones

Sean Hull es una consultor independiente en escalabilidad y rendimiento en iHeavy de Nueva York, y poco después de la interrupción del servicio AWS fue autor de un blog titulado “AirBNB didn’t have to fail”, en referencia a la web de viajes que era una de las decenas de páginas web que cayeron cuando falló la nube de AWS. En el post, Hull sostiene que hay herramientas que los desarrolladores web pueden utilizar para tolerar interrupciones.

Un sitio web puede ser programado para desactivar ciertas funciones pero mantener la parte principal del sitio en funcionamiento si se caen partes del sistema. En este caso, alguien que navega al sitio todavía sería capaz de utilizar las funciones básicas de éste, pero puede no ser capaz de realizar una compra en el sitio. Si un sitio web se encuentra alojado en varios lugares, solo puede estar activo un modo de exploración, por lo que incluso si AWS se apaga, una versión básica de la web sigue siendo accesible para los usuarios.

3. Use a un tercero en el mercado de AWS

Otros proveedores de terceros ofrecen servicios dentro de los ecosistemas de AWS para que los clientes creen sistemas altamente disponibles. Amazon Web Services lanzó un mercado de aplicaciones y servicios que se han optimizado para funcionar con AWS.

Los clientes pueden elegir entre una variedad de balanceadores de carga de uno de estos socios, como la división de Riverbed, Stingray. Apurva Dave, vicepresidente de marketing de producto de la compañía, señala que hay un beneficio al tomar el enfoque “la mejor cosecha” para utilizar aplicaciones de terceros en lugar de simplemente confiar en AWS para servicios tales como el balanceo de carga.

“¿Ha estado alguna vez en el aeropuerto cuando un vuelo se cancela?” comenta, como una analogía. “Todo el mundo tiene prisa por llegar a la oficina de servicio al cliente y esperar en línea. Luego hay otras personas, que simplemente llaman a su agente de viajes directamente y el problema es atendido. Nosotros somos ese agente de viajes que dirige su tráfico hacia donde tiene que ir. “Riverbed Stingray redirige el tráfico inmediata y automáticamente a través de una red dedicada, evitando los cuellos de botella creados en el entorno de AWS. Al igual que la opción RightScale, hay varios niveles de servicio que los clientes pueden elegir, con precios que varían en función de la tolerancia a fallas del sistema.

Como señala Hilgendorf, y Dave está de acuerdo es un análisis de costo-beneficio para el negocio. “Hay algunas aplicaciones a las que no les pasa nada si se caen por una hora al mes”, señala Dave. “Pero hay muchas aplicaciones que no pueden soportar eso”.

Brandon Butler, Network World (EE.UU.)