REL10-BP01 Implementación de la carga de trabajo en varias ubicaciones

Distribuya los datos y los recursos de la carga de trabajo entre varias zonas de disponibilidad o, si es necesario, entre varias Regiones de AWS. Estas ubicaciones pueden ser tan diversas como sea necesario.

Uno de los principios fundamentales para el diseño de servicios en AWS es evitar puntos únicos de error en la infraestructura física subyacente. Esto nos motiva a desarrollar software y sistemas que utilizan múltiples zonas de disponibilidad y son resistentes a errores de una sola zona. Del mismo modo, los sistemas están diseñados para resistir los errores de un solo nodo de computación, un solo volumen de almacenamiento o una sola instancia de una base de datos. Cuando se desarrolla un sistema que depende de componentes redundantes, es importante asegurarse de que estos componentes funcionen de forma independiente y, en el caso de las regiones de Regiones de AWS, de forma autónoma. Los beneficios obtenidos a partir de los cálculos teóricos de la disponibilidad con componentes redundantes solo son válidos si esto es cierto.

Zonas de disponibilidad (AZ)

Las Regiones de AWS están compuestas por varias zonas de disponibilidad diseñadas para ser independientes entre sí. Cada zona de disponibilidad está separada por una gran distancia física de otras zonas para evitar situaciones de error correlacionadas debido a peligros ambientales como incendios, inundaciones o tornados. Además, cada zona de disponibilidad tiene una infraestructura de física independiente: conexiones exclusivas para el suministro eléctrico, fuentes de energía de reserva independientes, servicios mecánicos independientes y conectividad de red independiente dentro y fuera de la zona de disponibilidad. Este diseño limita los errores en cualquiera de estos sistemas exclusivamente a la zona de disponibilidad afectada. A pesar de estar separadas geográficamente, las zonas de disponibilidad se encuentran en la misma región, lo que permite establecer redes de alto rendimiento y baja latencia. Toda la Región de AWS (en todas las zonas de disponibilidad, compuestas por varios centros de datos independientes desde el punto de vista físico) se puede tratar como un único objetivo de implementación lógica para la carga de trabajo, incluida la capacidad de replicar datos de forma sincrónica (por ejemplo, entre bases de datos). De este modo, puede utilizar las zonas de disponibilidad en una configuración activa/activa o activa/en espera.

Las zonas de disponibilidad son independientes y, por lo tanto, la disponibilidad de la carga de trabajo se incrementa al diseñarla para que utilice varias zonas. Algunos servicios de AWS (incluido el plano de datos de instancias de Amazon EC2) se implementan como servicios exclusivamente de zona en los que han compartido el destino con la zona de disponibilidad en la que se encuentran. Sin embargo, las instancias de Amazon EC2 de las demás zonas de disponibilidad no se verán afectadas y seguirán funcionando. Del mismo modo, si un error en una zona de disponibilidad provoca un error en una base de datos de Amazon Aurora, una réplica de lectura de una instancia de Aurora que se encuentre en una zona de disponibilidad no afectada podrá promoverse automáticamente a instancia primaria. Por otro lado, los servicios regionales de AWS, como Amazon DynamoDB, utilizan internamente varias zonas de disponibilidad con una configuración activa/activa para lograr los objetivos de diseño de disponibilidad de ese servicio, sin necesidad de configurar la ubicación de la zona de disponibilidad.

Figura 9: Arquitectura de varios niveles implementada en tres zonas de disponibilidad. Tenga en cuenta que Amazon S3 y Amazon DynamoDB siempre se implementan automáticamente en varias zonas de disponibilidad (Multi-AZ). El ELB también se implementa en las tres zonas.

Si bien los planos de control de AWS suelen ofrecer la capacidad de administrar recursos dentro de toda la región (múltiples zonas de disponibilidad), ciertos planos de control (incluidos Amazon EC2 y Amazon EBS) pueden filtrar los resultados en una única zona de disponibilidad. Al hacerlo, la solicitud se procesa solo en la zona de disponibilidad indicada, lo que reduce la exposición a interrupciones en otras zonas de disponibilidad. Este ejemplo de la AWS CLI muestra cómo obtener información de la instancia de Amazon EC2 únicamente de la zona de disponibilidad us-east-2c:

 AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
  

Zonas locales de AWS

Las zonas locales de AWS actúan de manera similar a las zonas de disponibilidad dentro de su Región de AWS correspondiente, ya que se pueden seleccionar como ubicación de los recursos de zona de AWS, como las subredes e instancias de EC2. Lo que las hace especiales es que no están situadas en la Región de AWS asociada, sino cerca de los grandes núcleos de población, industria y TI en los que actualmente no existe ninguna Región de AWS. Sin embargo, mantienen una conexión de banda ancha segura entre las cargas de trabajo de la zona local y las que se ejecutan en la Región de AWS. Use las zonas locales de AWS para implementar las cargas de trabajo más cerca de sus usuarios cuando existan requisitos de baja latencia.

Red periférica global de Amazon

La red periférica global de Amazon está formada por ubicaciones periféricas en ciudades de todo el mundo. Amazon CloudFront utiliza esta red para entregar contenido a los usuarios finales con una menor latencia. AWS Global Accelerator le permite crear los puntos de conexión de la carga de trabajo en estas ubicaciones periféricas para permitir la incorporación a la red global de AWS cerca de sus usuarios. Amazon API Gateway permite que los puntos de conexión de la API optimizados para sistemas periféricos mediante una distribución de CloudFront faciliten el acceso de los clientes a través de la ubicación periférica más cercana.

Regiones de AWS

Las Regiones de AWS están diseñadas para ser autónomas; por lo tanto, si utiliza un enfoque multirregional, debería implementar copias dedicadas de los servicios en cada región.

El enfoque multirregional es habitual en las estrategias de recuperación de desastres para cumplir los objetivos de recuperación cuando se producen eventos puntuales a gran escala. Consulte Planificar para la recuperación de desastres (DR) para obtener más información sobre estas estrategias. Sin embargo, en este caso, nos centramos más bien en la disponibilidad, que busca alcanzar un objetivo de tiempo de actividad medio a lo largo del tiempo. En el caso de los objetivos de alta disponibilidad, se suele diseñar la arquitectura multirregional con una configuración activa/activa, en la que cada copia de servicio (en sus respectivas regiones) esté activa (atendiendo las solicitudes).

AWS le proporciona las capacidades necesarias para utilizar los servicios entre regiones. Por ejemplo, AWS proporciona una replicación continua y asíncrona de los datos mediante la replicación de Amazon Simple Storage Service (Amazon S3), réplicas de lectura de Amazon RDS (incluidas las réplicas de lectura de Aurora) y tablas globales de Amazon DynamoDB. Con la replicación continua, las versiones de los datos están disponibles para usarse casi de inmediato en cada una de las regiones activas.

Con AWS CloudFormation, puede definir la infraestructura e implementarla de manera uniforme entre las Cuentas de AWS y entre las Regiones de AWS. Además, AWS CloudFormation StackSets amplía esta funcionalidad al permitirle crear, actualizar o eliminar pilas de AWS CloudFormation en varias cuentas y regiones con una sola operación. En las implementaciones de instancias de Amazon EC2, se utiliza una AMI (imagen de máquina de Amazon) para proporcionar información como la configuración del hardware y el software instalado. Puede implementar una canalización del Generador de imágenes de Amazon EC2 que cree las AMI que necesite y copiarlas en sus regiones activas. Esto garantiza que estas AMI maestras tengan todo lo que necesita para implementar y escalar horizontalmente la carga de trabajo en cada región nueva.

Para dirigir el tráfico, Amazon Route 53 y AWS Global Accelerator permiten definir políticas que determinan qué usuarios van a cada punto de conexión regional activo. Con Global Accelerator, se configura un dial de tráfico para controlar el porcentaje de tráfico que se dirige a cada punto de conexión de la aplicación. Route 53 es compatible con este enfoque porcentual, así como muchas otras políticas disponibles, incluidas las basadas en la proximidad geográfica y la latencia. Global Accelerator aprovecha automáticamente la amplia red de servidores periféricos de AWS para incorporar el tráfico a la red troncal de AWS lo antes posible, lo que reduce las latencias de solicitud.

Todas estas capacidades funcionan para preservar la autonomía de cada región. Existen muy pocas excepciones a este enfoque, incluidos nuestros servicios que proporcionan entrega global de periferia (como Amazon CloudFront y Amazon Route 53), junto con el plano de control para el servicio de AWS Identity and Access Management (IAM). La mayoría de los servicios funcionan completamente en una sola región.

Centro de datos en las instalaciones

Para las cargas de trabajo que se ejecuten en un centro de datos en las instalaciones, siempre que sea posible diseñe una experiencia híbrida. AWS Direct Connect proporciona una conexión de red específica entre las instalaciones en las instalaciones y AWS para que pueda ejecutarlas en ambas.

Otra opción es ejecutar la infraestructura y los servicios de AWS en las instalaciones con AWS Outposts. AWS Outposts es un servicio completamente administrado que amplía la infraestructura de AWS, los servicios de AWS, las API y las herramientas a su centro de datos. La misma infraestructura de hardware que se usa en la Nube de AWS se instala en el centro de datos. AWS Outposts se conecta a la Región de AWS más cercana. Luego, puede utilizar AWS Outposts para respaldar las cargas de trabajo que tengan requisitos de baja latencia o de procesamiento local de los datos.

Nivel de riesgo expuesto si no se establece esta práctica recomendada: alto

Guía para la implementación

Recursos

Documentos relacionados:

Videos relacionados: