Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Resiliencia en la periferia

El pilar de la fiabilidad abarca la capacidad de una carga de trabajo para realizar la función prevista de forma correcta y coherente cuando se espera que lo haga. Esto incluye la capacidad de operar y probar la carga de trabajo durante todo su ciclo de vida. En este sentido, cuando diseñe una arquitectura resiliente en la periferia, primero debe considerar qué infraestructuras utilizará para implementar esa arquitectura. Existen tres combinaciones posibles que se pueden implementar utilizando Zonas locales de AWS y AWS Outposts: de Outpost a Outpost, de Outpost a zona local y de zona local a zona local, como se ilustra en el siguiente diagrama. Si bien existen otras posibilidades de arquitecturas resilientes, como la combinación de servicios AWS perimetrales con la infraestructura local tradicional Regiones de AWS, esta guía se centra en estas tres combinaciones que se aplican al diseño de servicios de nube híbrida

Consideraciones sobre infraestructura

En AWS resumen, uno de los principios fundamentales del diseño de servicios es evitar puntos únicos de falla en la infraestructura física subyacente. Debido a este principio, el AWS software y los sistemas utilizan varias zonas de disponibilidad y son resistentes a los fallos de una sola zona. At the Edge, AWS ofrece infraestructuras basadas en Zonas Locales y Outposts. Por lo tanto, un factor fundamental para garantizar la resiliencia en el diseño de la infraestructura es definir dónde se despliegan los recursos de una aplicación.

Zonas locales

Las zonas locales actúan de manera similar a las zonas de disponibilidad dentro de ellas Región de AWS, ya que se pueden seleccionar como ubicación de ubicación para AWS los recursos zonales, como subredes e EC2 instancias. Sin embargo, no se encuentran en un centro de TI Región de AWS, sino cerca de grandes centros de población, industriales y de TI que actualmente no Región de AWS existen. A pesar de ello, siguen manteniendo conexiones seguras y con un gran ancho de banda entre las cargas de trabajo locales de la zona local y las cargas de trabajo que se ejecutan en la misma. Región de AWS Por lo tanto, debe usar las Zonas Locales para implementar cargas de trabajo más cerca de sus usuarios para requisitos de baja latencia.

Outposts

AWS Outposts es un servicio totalmente gestionado que extiende la AWS infraestructura y las herramientas a su centro de datos. Servicios de AWS APIs La misma infraestructura de hardware que se utiliza en el Nube de AWS está instalada en su centro de datos. Los Outposts se conectan entonces a los más cercanos. Región de AWS Puedes usar Outposts para respaldar tus cargas de trabajo que tienen baja latencia o requisitos de procesamiento de datos local.

Zonas de disponibilidad principales

Cada zona local o puesto avanzado tiene una región principal (también denominada región de origen). La región principal es donde está anclado el plano de control de la infraestructura AWS perimetral (puesto avanzado o zona local). En el caso de las Zonas Locales, la región principal es un componente arquitectónico fundamental de una Zona Local y los clientes no pueden modificarla. AWS Outposts se extiende Nube de AWS a su entorno local, por lo que debe seleccionar una región y una zona de disponibilidad específicas durante el proceso de pedido. Esta selección ancla el plano de control de tu despliegue de Outposts a la AWS infraestructura elegida.

Al desarrollar arquitecturas de alta disponibilidad en la periferia, la región principal de estas infraestructuras, como Outposts o Local Zones, debe ser la misma, de modo que se pueda extender una VPC entre ellas. Esta VPC extendida es la base para crear estas arquitecturas de alta disponibilidad. Al definir una arquitectura altamente resiliente, es por eso que debe validar la región principal y la zona de disponibilidad de la región en la que estará (o estará) anclado el servicio. Como se ilustra en el siguiente diagrama, si deseas implementar una solución de alta disponibilidad entre dos Outposts, debes elegir dos zonas de disponibilidad diferentes para anclar los Outposts. Esto permite una arquitectura Multi-AZ desde la perspectiva del plano de control. Si desea implementar una solución de alta disponibilidad que incluya una o más Zonas Locales, primero debe validar la Zona de disponibilidad principal en la que está anclada la infraestructura. Para ello, utilice el siguiente AWS CLI comando:

aws ec2 describe-availability-zones --zone-ids use1-mia1-az1

Resultado del comando anterior:

{     "AvailabilityZones": [         
          {
             "State": "available",
             "OptInStatus": "opted-in",
             "Messages": [],
             "RegionName": "us-east-1",
             "ZoneName": "us-east-1-mia-1a",
             "ZoneId": "use1-mia1-az1",
             "GroupName": "us-east-1-mia-1",
             "NetworkBorderGroup": "us-east-1-mia-1",
             "ZoneType": "local-zone",
             "ParentZoneName": "us-east-1d",
             "ParentZoneId": "use1-az2"
         }
     ]
 }

En este ejemplo, la zona local de Miami (us-east-1d-mia-1a1) está anclada en la zona de us-east-1d-az2 disponibilidad. Por lo tanto, si necesita crear una arquitectura resiliente en la periferia, debe asegurarse de que la infraestructura secundaria (Outposts o Zonas Locales) esté anclada a una zona de disponibilidad distinta de. us-east-1d-az2 Por ejemplo, us-east-1d-az1 sería válido.

El siguiente diagrama proporciona ejemplos de infraestructuras perimetrales de alta disponibilidad.

Consideraciones sobre redes

En esta sección se analizan las consideraciones iniciales sobre las redes periféricas, principalmente en lo que respecta a las conexiones de acceso a la infraestructura perimetral. Repasa las arquitecturas válidas que proporcionan una red resiliente para el enlace de servicio.

Redes de resiliencia para Zonas Locales

Las Zonas Locales están conectadas a la región principal mediante enlaces múltiples, redundantes, seguros y de alta velocidad que le permiten utilizar cualquier servicio regional, como Amazon S3 y Amazon RDS, sin problemas. Usted es responsable de proporcionar conectividad desde su entorno local o sus usuarios a la zona local. Independientemente de la arquitectura de conectividad que elija (por ejemplo, VPN o VPN AWS Direct Connect), la latencia que debe lograrse a través de los enlaces de red debe ser equivalente para evitar cualquier impacto en el rendimiento de la aplicación en caso de que se produzca un fallo en un enlace principal. Si la utiliza AWS Direct Connect, las arquitecturas de resiliencia aplicables son las mismas que las utilizadas para acceder a una Región de AWS, tal y como se documenta en las recomendaciones de AWS Direct Connect resiliencia. Sin embargo, hay escenarios que se aplican principalmente a las Zonas Locales internacionales. En el país donde la zona local está habilitada, tener un solo AWS Direct Connect PoP hace que sea imposible crear las arquitecturas recomendadas para la AWS Direct Connect resiliencia. Si tiene acceso a una sola AWS Direct Connect ubicación o necesita resiliencia más allá de una sola conexión, puede crear un dispositivo VPN en Amazon EC2 y AWS Direct Connect, como se ilustra y analiza en la entrada del AWS blog, habilitar la conectividad de alta disponibilidad desde las instalaciones hasta Zonas locales de AWS.

Redes de resiliencia para Outposts

A diferencia de las Zonas Locales, los Outposts tienen conectividad redundante para acceder a las cargas de trabajo desplegadas en Outposts desde tu red local. Esta redundancia se consigue mediante dos dispositivos ONDs de red Outposts (). Cada OND requiere al menos dos conexiones de fibra a 1 Gbps, 10 Gbps, 40 Gbps o 100 Gbps a su red local. Estas conexiones deben configurarse como un grupo de agregación de enlaces (LAG) para permitir la adición escalable de más enlaces.

Para obtener más información sobre esta conectividad, consulta Conectividad de red local para Outposts Racks en la documentación. AWS Outposts

Para una experiencia y una resiliencia óptimas, se AWS recomienda utilizar una conectividad redundante de al menos 500 Mbps (1 Gbps es mejor) para la conexión de enlace de servicio al. Región de AWS Puede utilizar AWS Direct Connect una conexión a Internet para el enlace de servicio. Este mínimo le permite lanzar EC2 instancias, adjuntar volúmenes de EBS y acceder a ellos Servicios de AWS, como Amazon EKS, Amazon EMR y métricas. CloudWatch

El siguiente diagrama ilustra esta arquitectura para una conexión privada de alta disponibilidad.

El siguiente diagrama ilustra esta arquitectura para una conexión pública de alta disponibilidad.

Escalar las implementaciones de racks de Outposts con racks ACE

El rack Aggregation, Core, Edge (ACE) sirve como punto de agregación crítico para las implementaciones de AWS Outposts varios racks y se recomienda principalmente para instalaciones que superen los tres racks o para planificar una futura expansión. Cada rack ACE cuenta con cuatro enrutadores que admiten conexiones de 10 Gbps, 40 Gbps y 100 Gbps (100 Gbps es lo óptimo). Cada rack se puede conectar a hasta cuatro dispositivos de cliente ascendentes para obtener la máxima redundancia. Los racks ACE consumen hasta 10 kVA de energía y pesan hasta 705 libras. Los beneficios clave incluyen una reducción de los requisitos de redes físicas, menos enlaces ascendentes de cableado de fibra y una disminución de las interfaces virtuales de VLAN. AWS supervisa estos racks mediante datos de telemetría a través de túneles VPN y trabaja en estrecha colaboración con los clientes durante la instalación para garantizar una disponibilidad de energía adecuada, una configuración de red y una ubicación óptima. La arquitectura de rack ACE proporciona un valor cada vez mayor a medida que las implementaciones se amplían y simplifica de forma eficaz la conectividad, a la vez que reduce la complejidad y los requisitos de puertos físicos en instalaciones de mayor tamaño.  Para obtener más información, consulte la AWS entrada del blog Cómo escalar las implementaciones en AWS Outposts rack con ACE Rack.

Distribución de instancias en Outposts y Zonas Locales

Los Outposts y las Zonas Locales tienen un número finito de servidores de cómputo. Si la aplicación implementa varias instancias relacionadas, estas instancias podrían implementarse en el mismo servidor o en servidores del mismo rack, a menos que estén configuradas de forma diferente. Además de las opciones predeterminadas, puede distribuir las instancias entre los servidores para mitigar el riesgo de ejecutar instancias relacionadas en la misma infraestructura. También puede distribuir las instancias en varios racks mediante grupos de ubicación de particiones. Esto se denomina modelo de distribución de racks dispersos. Utilice la distribución automática para distribuir las instancias entre las particiones del grupo o despliegue las instancias en las particiones de destino seleccionadas. Al implementar instancias en las particiones de destino, puede implementar los recursos seleccionados en el mismo rack y, al mismo tiempo, distribuir otros recursos entre los racks. Outposts también ofrece otra opción llamada spread host que te permite distribuir tu carga de trabajo a nivel de anfitrión. En el siguiente diagrama se muestran las opciones de distribución por rack y por servidor de dispersión.

Amazon RDS Multi-AZ en AWS Outposts

Cuando utiliza despliegues de instancias Multi-AZ en Outposts, Amazon RDS crea dos instancias de base de datos en dos Outposts. Cada Outpost se ejecuta en su propia infraestructura física y se conecta a diferentes zonas de disponibilidad de una región para ofrecer una alta disponibilidad. Cuando dos Outposts se conectan a través de una conexión local gestionada por el cliente, Amazon RDS gestiona la replicación sincrónica entre las instancias de base de datos principal y en espera. En caso de que se produzca un error en el software o la infraestructura, Amazon RDS promoverá automáticamente la instancia en espera a la función principal y actualizará el registro DNS para que apunte a la nueva instancia principal. Para implementaciones Multi-AZ, Amazon RDS crea una instancia de base de datos principal en un Outpost de y replica sincrónicamente los datos en una instancia de base de datos en espera en otro Outpost. Los despliegues Multi-AZ en Outposts funcionan como los despliegues Multi-AZ en Regiones de AWS, con las siguientes diferencias:

Las implementaciones Multi-AZ están disponibles para todas las versiones compatibles de MySQL y PostgreSQL en Amazon RDS en Outposts. Las copias de seguridad locales no son compatibles con las implementaciones en zonas de disponibilidad múltiples.

El siguiente diagrama muestra la arquitectura de Amazon RDS en las configuraciones Multi-AZ de Outposts.

Mecanismos de conmutación por error

Equilibrio de carga y escalado automático

Elastic Load Balancing (ELB) distribuye automáticamente el tráfico entrante de las aplicaciones entre todas las EC2 instancias que esté ejecutando. ELB ayuda a administrar las solicitudes entrantes al enrutar el tráfico de manera óptima para que ninguna instancia se vea abrumada por sí sola. Para usar ELB con su grupo de Amazon EC2 Auto Scaling, adjunte el balanceador de carga a su grupo de Auto Scaling. Esto registra el grupo en el balanceador de carga, que actúa como punto de contacto único para todo el tráfico web entrante a su grupo. Cuando usa ELB con su grupo de Auto Scaling, no es necesario registrar EC2 instancias individuales en el balanceador de cargas. Las instancias lanzadas por el grupo de Auto Scaling se registran automáticamente en el balanceador de carga. Del mismo modo, las instancias canceladas por su grupo de Auto Scaling se cancelan automáticamente del balanceador de cargas. Después de adjuntar un balanceador de cargas a su grupo de Auto Scaling, puede configurar su grupo para que use métricas de ELB (como el recuento de solicitudes del Application Load Balancer por destino) para escalar el número de instancias del grupo a medida que fluctúa la demanda. Si lo desea, puede añadir comprobaciones de estado de ELB a su grupo de Auto Scaling para que Amazon EC2 Auto Scaling pueda identificar y reemplazar las instancias en mal estado en función de estas comprobaciones de estado. También puedes crear una CloudWatch alarma de Amazon que te notifique si el número de anfitriones en buen estado del grupo objetivo es inferior al permitido.

El siguiente diagrama ilustra cómo un Application Load Balancer gestiona las cargas de trabajo en Amazon in. EC2 AWS Outposts

El siguiente diagrama ilustra una arquitectura similar para Amazon EC2 en las Zonas Locales.

Amazon Route 53 para conmutación por error de DNS

Si tiene más de un recurso que realiza la misma función (por ejemplo, varios servidores HTTP o de correo), puede configurar Amazon Route 53 para comprobar el estado de sus recursos y responder a las consultas de DNS utilizando únicamente los recursos en buen estado. Por ejemplo, supongamos que su sitio web está alojado en dos example.com servidores. Un servidor está en una zona local y el otro en un Outpost. Puede configurar Route 53 para comprobar el estado de esos servidores y responder a las consultas de DNS example.com utilizando solo los servidores que están en buen estado actualmente. Si usa registros de alias para enrutar el tráfico a AWS recursos seleccionados, como los balanceadores de carga ELB, puede configurar Route 53 para evaluar el estado del recurso y enrutar el tráfico solo a los recursos que estén en buen estado. Al configurar un registro de alias para evaluar el estado de un recurso, no es necesario crear una comprobación del estado de ese recurso.

El siguiente diagrama ilustra los mecanismos de conmutación por error de Route 53.

Amazon Route 53 Resolver activado AWS Outposts

Amazon Route 53 Resolverestá disponible en los estantes de Outposts. Proporciona a tus servicios y aplicaciones locales una resolución de DNS local directamente desde Outposts. Los puntos finales locales de Route 53 Resolver también permiten la resolución de DNS entre Outposts y su servidor DNS local. Route 53 Resolver on Outposts ayuda a mejorar la disponibilidad y el rendimiento de las aplicaciones locales.

Uno de los casos de uso típicos de Outposts es implementar aplicaciones que requieren acceso de baja latencia a sistemas locales, como equipos de fábrica, aplicaciones comerciales de alta frecuencia y sistemas de diagnóstico médico.

Si opta por utilizar los Resolvers de Route 53 locales en Outposts, las aplicaciones y los servicios seguirán beneficiándose de la resolución de DNS local para detectar otros servicios, incluso si se pierde la conectividad con uno de los Región de AWS padres. Los solucionadores locales también ayudan a reducir la latencia de las resoluciones de DNS, ya que los resultados de las consultas se almacenan en caché y se sirven localmente desde los Outposts, lo que elimina los viajes de ida y vuelta innecesarios al servidor principal. Región de AWS Todas las resoluciones de DNS para las aplicaciones de Outposts VPCs que utilizan DNS privados se proporcionan de forma local.

Además de habilitar los Resolvers locales, este lanzamiento también habilita los puntos finales de Resolver locales. Los puntos de conexión salientes de Route 53 Resolver permiten a los Route 53 Resolver reenviar las consultas de DNS a los solucionadores de DNS que usted administra, por ejemplo, en la red local. Por el contrario, los puntos finales entrantes de Route 53 Resolver reenvían las consultas de DNS que reciben desde fuera de la VPC al Resolver que se ejecuta en Outposts. Te permite enviar consultas de DNS para servicios desplegados en una VPC privada de Outposts desde fuera de esa VPC. Para obtener más información sobre los puntos de enlace entrantes y salientes, consulte Resolución de consultas de DNS entre su red VPCs y su red en la documentación de Route 53.